On Mon, 2007-01-01 at 10:00 -0800, Paul Eggert wrote: > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > > Also, it does not make sense to me to lump together all potentially > > troublesome optimizations under a single name. > > As a compiler developer, you see the trees. But most users just see a > forest and want things to be simple. Even adding a single binary > switch (-fno-risky/-frisky) will be an extra level of complexity that > most users don't particularly want to know about. Requiring users to > worry about lots of little switches (at least -fwrapv/-fundefinedv/-ftrapv, > -fstrict-signed-overflow/-fno-strict-signed-overflow, and > -fstrict-aliasiang/-fno-strict-aliasing, and probably more) makes GCC > harder to use conveniently, and will make things more likely to go > wrong in practical use.
Then the question is why does C developers act differently than Fortran developers when it comes to undefinedness? Look at Fortran argument aliasing, we get almost no bugs about that undefinedness. We have an option to change the way argument aliasing works, in the same way we have an option for signed overflow. I don't see why overflow will be any different from argument aliasing. Maybe the problem is that C (and C++) developers don't know the language they writing in and expect anything to work they wrote. I think this is a problem with the teaching of C (and C++) today and it is hard for us to fix that issue. We can try educate people by adding we treat signed overflow as undefined in the documentation in more obvious place but this is not going to help in general as developers don't read the docs. The problem with the current signed overflow undefined optimizations is that conflict in some are wrapping, others are saturation (most of the VRP and a-'0'>9) and then more are extending (a*10/5). Thanks, Andrew Pinski
