GCC 4.3.0 exposes a kernel bug [LWN.net]

GCC 4.3.0 exposes a kernel bug

Posted Mar 14, 2008 21:21 UTC (Fri) by zlynx (subscriber, #2285)
In reply to: GCC 4.3.0 exposes a kernel bug by giraffedata
Parent article: GCC 4.3.0 exposes a kernel bug

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

(Log in to post comments)

GCC 4.3.0 exposes a kernel bug

Posted Mar 14, 2008 22:26 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

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

I think you got it backward. I claim it's standard because Linux does it that way. Linux is what violates the prescribed standard.

I also didn't state the de facto standard as precisely as I could have, because Linux clearly should change to clear the DF flag. But Gcc should continue to clear it too, because old Linux exists.

GCC 4.3.0 exposes a kernel bug

Posted Mar 14, 2008 22:42 UTC (Fri) by zlynx (subscriber, #2285) [Link]

> 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?

GCC 4.3.0 exposes a kernel bug

Posted Mar 15, 2008 0:07 UTC (Sat) by nix (subscriber, #2304) [Link]

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...

GCC 4.3.0 exposes a kernel bug

Posted Mar 15, 2008 2:23 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

OK, I see your point.