[macstl-dev] Re: Good news (finally) about gcc 4.0 problems
glen.low at pixelglow.com
Sat Sep 24 09:38:13 WST 2005
On 24/09/2005, at 8:02 AM, Ilya Lipovsky wrote:
> Good news:
> (I just saved a bunch of money on my car insurance... (Just
> kidding, that was just taken from a U.S. commercial... :-D ) )
> Seriously, the good news is that it strongly appears that I was
> able to solve the problems with FSF's gcc 4.0 generating bad code
> on Linux PPC. I am very thankful to Andrew Pinski (a gcc
> maintainer) for his suggestion.
> Essentially all I needed to do was to modify altivec.h to change
> all instances of simple "inline" into "INLINE" defined as "inline
> __attribute__ ((always_inline))", a familiar macro.
> I know, I know: I should've noticed it earlier. Sometimes you miss
> things that, as you think later on, were staring you in the face
> (but who would doubt a standard header?).
> So, to reiterate, the stuff that previously ran so badly (in terms
> of generating correct results) now runs *well and fast*.
> I am going to implement similar changes in the altivec.h file that
> belongs to gcc 3.4. Also, I am going to add some macro logic to the
> config.h file to conditionally include the appropriate versions of
> the manually changed altivec.h. We should not use the standard
> altivec.h header.
> Andrew Pinski mentioned in a (later) email to me that gcc 4.0.3
> will possibly have the fast header. He also claimed in the letter
> before the above that the future FSF gcc 4.1 should expand the
> vec_* routines into builtins directly, avoiding going through the
> definitions in altivec.h (just like what Apple gcc does). We'll see.
> At some point I still want to submit a bug report about gcc 4.0. As
> it stands right now, however, the "INLINE" macro is a very
> successful hack.
That's good news. Here's a suggestion that appeals to my hacker self
but offends my architect self:
Before we #include <altivec.h>, we could #define inline INLINE, and
then after it #undef inline. Don't know if that would work (does
#defining a macro which would #include itself cause the compiler
conniptions, or does it use the reserved word correctly in the 2nd
invocation? does #undefing a macro that references a reserved word go
back to allowing the reserved word?), but it might avoid having to
muck around with the innards of a standard header.
Given that gcc 3.4 has no problems with inlining, and the non-
inlining bug would be fixed in the gcc 4.0.x branch, we shouldn't be
incorporating the modified <altivec.h> in the standard macstl
distribution. Otherwise we're saddled with having to synchronize our
version with theirs.
Cheers, Glen Low
pixelglow software | simply brilliant stuff
More information about the macstl-dev