This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Richard Kenner wrote:
On the other hand, C does not have a way to tell the compiler:

"this is my loop variable, it must not be modified inside the loop"

neither you can say:

"this is the upper bound of the loop, it must not be modified"

either.

No, but the compiler can almost always trivially determine that nothing in the loop can modify the variable, so I'm not sure I understand your point.

My point in the quoted section is that:

  1. A programmer can accidentally modify the loop variable, or bound.
     It is more
     difficult for a programmer to catch such bugs, if the language
     does not help.
     Having a true "for" syntax will help to catch such bug.
  2. If there were a real "for" construct, there would be no question
     of termination
     in that common case. There would be no need to do the "overflow is
     undefined"
     hack.
     Among other things, complex termination conditions make it
     impossible  to
     figure out if the loop terminates. If a true "for" would have been
     defined by C,
     then the termination condition would be calculated and known in
     advance:

       FOR i:=0 TO foo()+1
       BEGIN
       ....
       END

   We don't care if foo()+1 wraps to MIN_INT. It would be undefined to
   have the
   upper bound smaller than the lower bound. Wrapping semantics can be
   used
   everywhere.
   Anyway, in most cases one knows the upper limit of the loop upfront.


Anyway, the main point of the complete mail was to propose semantics that is
strong enough for the "speed is all" camp, and predictable enough for the
"real world code assumes wrapping" camp.
--


Michael Veksler
http:///tx.technion.ac.il/~mveksler


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]