GCC 4.3.0 exposes a kernel bug

GCC 4.3.0 exposes a kernel bug

I don't think what people knew and/or concealed is relevant, but the fact that the behavior has existed for 15 years and exists in countless systems today matters a lot. 15 years of practice is a much stronger standard than any prescriptive document. I say the standard is that DF's value is undefined at entry to a function, and Gcc 4.3.0 fails to conform.

This is a classic dilemma. You can make Gcc right or you can make it work.

If you offered both versions to the public, very few would opt for the "right" one. That's not the last word, of course. I'm sure some people believe the Gcc project has higher goals than giving its users what they want.

But traditionally, prescriptive standards nearly always bow to what actual practice demands.

Claiming that it's standard "because GCC does it that way" completely ignores all the other
compilers that do *not* do it that way.

> But Gcc should continue to clear it too, because old Linux exists.

This does not buy you anything except slowing down all your code unnecessarily.  Any user
might use a binary built with some other compiler, like the precompiled commercial MySQL
server, or a game.  Software running through Wine is probably built with Visual Studio.  A JIT
like Mono or Java might generate code that doesn't reset DF.  A developer might be using TCC
for ultra-fast compiles.  There is also LLVM: I don't know, but it might not do the DF clear
either.

See what I mean about other compilers?  Do you wish to have every one of them also clear DF on
every function?

ICC has apparently never cleared DF. I guess nobody's ever tried compiling 
programs that make heavy use of asynchronous signal handlers with ICC on 
Linux...

> 15 years of practice is a much stronger standard
> than any prescriptive document.
...over at sco dotcom. :)

Well, IMHO trying to follow standards in a way which creates artifical and hard to debug
problems to the rest of the crowd *is* ignorance too.