Sorry, but this is just wrong...
Posted May 31, 2011 17:39 UTC (Tue) by anton
In reply to: Sorry, but this is just wrong...
Parent article: What Every C Programmer Should Know About Undefined Behavior #3/3
Lots of platforms it was flaky because FPU was physically separate.
My code ran fine on systems with physically separate FPU (e.g., MIPS
R2000+R2010). Also, why should the separate FPU affect the types foo
Anyway, if there is a hardware issue that we have to deal with,
that's fine with me, and I will deal with it. But a compiler that
miscompiles on hardware that's perfectly capable of doing what I
intend (as evidenced by the fact that gcc-2.x -O and gcc-4.x -O0
achieve what I intend) is a totally different issue.
But then if you want low-level non-portable language... asm is always there.
I want a relatively portable low-level language, and gcc-2.x -O and
(for now) gcc-4.x -O0 provide that, and my code ports nicely to all
the hardware I can get my hands on (and to some more that I cannot);
that's definitely not the case for asm, and it's not quite the case
with gcc-4.x -O. For now we work around the breakage of gcc-4.x, but
the resulting code is not as fast and small as it could be; and we did
not have to endure such pain with gcc-2.x.
And new gcc releases are the biggest source of problems for my
code. New hardware is much easier.
Or, alternatively, you can actually read specifications and see what the language actually supports.
The C standard specification is very weak, and has more holes than
content (was it 190 undefined behaviours? Plus implementation-defined
behaviours). Supposedly the holes are there to support some exotic
platforms (such as ones-complement machines where signed addition
traps on overflow). Sure, people who want to port to such platforms
will have to avoid some low-level-coding practices, and will have to
suffer the pain that you want to inflict on all of us.
But most of us and our code will never encounter such platforms
(these are deservedly niche platforms, and many of these niches become
smaller and smaller over time) and we can make our code faster and
smaller with these practices, at least if we have a language that
supports them. The language implemented by gcc-2.x does support these
practices. We just need a compiler for this language that targets
So, the ANSI C specification and the language it specifies is
pretty useless, because of these holes. Even Chris Lattner admits
that "There is No Reliable Way to Determine if a Large Codebase
Contains Undefined Behavior". So what you suggest is just
impractical. Not just would it mean giving up on low-level code, the
compiler could still decide to format the hard disk if it likes to,
because most likely the code still contains some undefined behaviour.
It's kind of funny, but real low-level stuff (like OS kernels or portable on-bare-metal programs) usually survive "evil compilers" just fine.
I have seen enough complaints from kernel developers about breakage
from new gcc versions, and that despite that fact that Linux is
probably one of the few programs (apart from SPEC CPU) that the gcc
maintainers care for. The kernel developers do what we do, they try to
work around the gcc breakage, but I doubt that that's the situation
they wish for.
to post comments)