> > Andrew Pinski <[EMAIL PROTECTED]> writes: > > | > > | > C has been a portable assembler for years before it got normalized and > | > optimizing compilers took over. > | > | 18 years. And now it has been 17 years since C has been standardized so > | you can say C has been standardized now for half its life. 18 years is a > | long time when it comes to computers. I know one problem is that most > | people who learn C don't learn about the undefined behaviors until they hit > | it. > > But did you learn the history of how and why those "undefined > behaviour" came into existence in the first place?
Tell us then. Aliasing, signed type overflow and sequence points are already the most interesting parts of C anyways so tell us why it became undefined/unspecified. It might give us a better idea of why we should keep GCC the way it is currently. Over those 17 years, C has not changed that much. Even Fortran defined integer overflow (Fortran does not have unsigned types) as undefined back in at least 1977 so I don't see why we should punish the Fortran people on what we decide with C. So if we decide we need we should only treat signed type overflow as undefined inside loops, then we need an option so Fortran does not get punished for what is decided for the C family of languages. Fortran also has a "stricter" aliasing than even C, which is why we have -fargument-noalias-global. We also added -fwrapv in fact to support Java where the language is very specific at integer overflow is defined as wrapping. It was added to disable the already added optimizations in 2003 (2 years before VRP was added), why did nobody raise the issue then? Instead we are now talking about almost 4 years later about the same issue we should have discussed back then when the option to turn on overflow as wrapping was added. Thanks, Andrew Pinski
