> Compilers sometimes have bugs, and gcc and egcs have some (even some in
> common). That's why there are some new release, no?
>
> I'm talking about real bugs.
OK. I was fairly sure we were actually agreeing, and we were.
BTW, in case LAME folks don't know about it yet (this is a major bug and it's
just becoming widely known):
The glibc bug I mentioned is just now becoming widely known (we just discovered
it over on the Vorbis development project). All versions of linux glibc for
x86 (and therefore x87) to date (I have not looked at other platforms, I expect
the bug is there too) use hardwired hand-rolled assembly calls in the math
inlines for common math functions like log(), sin(), etc... EGCS does not have
control over these calls and nothing inspects the asm contents until the
assembly stage. Because FP stack usage mapping happens earlier, any of these
calls that pushes onto the FP stack will overflow it if EGCS has already used
all eight stack entries. Until glibc is widely fixed, -D__NO_MATH_INLINES is
necessary for working FP code.
(gcc 2.8+ and egcs are affected. Previous versions are not affected because
glibc explicity excludes the inlined headers for gcc 2.7.x and earlier)
> Hopefully, sometimes the compiler is smart
> enough to see that it has some bugs: "internal compiler error, please submit
> a bug report". You've never seen it? It's very rare, but sometimes
> happens... (I only saw 1 bug with -O9 under gcc,
I'll guess it was the 2.7 loop unrolling bug where the compiler initialized the
wrong part of the resulting code? That's the one I found.
(BTW, my idiosyncratic number is -O20. I use it for everything including
Vorbis and the kernels on my boxen :-)
Monty
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
