Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Andrew Pinski <pinskia@physics.uc.edu> writes:

| > 
| > Andrew Pinski <pinskia@physics.uc.edu> 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.

The question was not rhetorical, but genuine.  

I gather from your answer that you don't know; that is OK.  C existed
before it got a standard (which was expected to be finalized circa
1983-84, but miraculously got delayed for a couple of years).  C
existed before C++ (which unofficially turned 25 a couple of months ago).

It is incorrect to assert that

 # Over those 17 years, C has not changed that much.

The C standard, in effect, has an appendix (Annex H) that was not
there in the C89 edition, and that talks about the very specific issue
at hand 

       H.2.2  Integer types

       [#1] The signed C integer types int,  long  int,  long  long
       int,  and  the  corresponding  unsigned types are compatible
       with LIA-1.  If an implementation adds support for the LIA-1
       exceptional  values  ``integer_overflow'' and ``undefined'',
       then those types are LIA-1 conformant types.   C's  unsigned
       integer  types  are  ``modulo''  in  the LIA-1 sense in that
       overflows  or  out-of-bounds  results  silently  wrap.    An
       implementation  that  defines  signed  integer types as also
       being modulo need not  detect  integer  overflow,  in  which
       case, only integer divide-by-zero need be detected.

[...]


Returning to my question, which was genuine, you might get a sense of
what the C committee decided to cover by "undefined bahviour" by
looking at "The Rationale":

   http://www.lysator.liu.se/c/rat/a.html#1-7


   Undefined behavior gives the implementor license not to catch
   certain program errors that are difficult to diagnose.  It also
   identifies areas of possible conforming language extension: the
   implementor may augment the language by providing a definition of
   the officially undefined behavior. 

| It was added to disable the already added optimizations in 2003 (2
| years before VRP was added), why did nobody raise the issue then?  

maybe you don't remember this is not the first time the issue is
coming up -- almost invariably with the same answers.  That is OK too.
Next time, we will ask why are discussing this only now instead of x
years ago?

-- Gaby