On Fri, 2007-01-12 at 11:35 +0100, Axel Thimm wrote:
> On Fri, Jan 12, 2007 at 11:02:10AM +0100, Ralf Corsepius wrote:
> > > > Errm? AFAICT, you must NOT pass -maltivec to cflags, because this
> > > > changes code generation and the ABI.
> > >
> > > I think you mean -mabi=altivec
> >
> > ??? -maltivec is a macro and comprises many options.
> >
> > What -maltivec does in detail is very complicated, much more complicated
> > than what most other -m* flags do. Also it has changed several times
> > over GCC's history.
>
> Well, we are talking about the present use of -maltivec, or not?
>
> > I.e. the code being generated using it, is not necessarily
> > guaranteed to be compatible nor to be runable on those ppc variants
> > Fedora/RH supports.
>
> According to the release notes Fedora currently supports G3 upwards,
> altivec is guaranteed only G4 upwards. So it looks like there can are
> altivec-less system on the support matrix.
I hope that's on New World G3s and later, like the B&W G3, not the beige
G3.
Furthermore, all the build systems POWER-based. They have no altivec.
So, if like OpenOffice, you compile tools early in the build process
that you will use _later_ in the build process at any point, or you run
automated tests on stuff you have built _using_ stuff you have built,
you will likely segfault or SIGILL.
Just a reminder not to exclusively target PPC machines with Altivec in
your packages (unless they are scientific or something). If you wish to
optimize sections of your code, you need to do it with runtime
selection, much like, say, cairo, the X server, or the GIMP do for MMX
or SSE accelerated pixbuf operations. i.e., lots of "if (MMX) {} else
{}".
Compiling with altivec is fine; but sticking altivec in CFLAGS for your
_entire_ build is usually not fine.
Dan
> Given the choice to drop G3 support or altivec, I'd suggest to drop
> G3. But that's not to decide on a package basis, and certainly not
> retrospective to a live release.
>
> > From my experience with GCC and altivec (I am co-maintainer of
> > powerpc-rtems-gcc), I am expecting it to break things, but I am not
> > sufficiently familiar with powerpc-redhat-gcc to be able to judge.
>
> > > > May-be somebody being more familiar with ppc-Fedora than I might
> > > > be able to comment.
>
> You seem familiar enough if you maintain a gcc backend ;)
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
