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: Ada front-end depends on signed overflow


> From: Robert Dewar <dewar@adacore.com>
> Paul Schlie wrote:
> Fine, but then you are designing a different language from C.

- I'm not attempting to design a language, but just defend the statement
  that I made earlier; which was in effect that I contest the assertion
  that undefined evaluation semantics enable compilers to generate more
  efficient useful code by enabling them to arbitrarily destructively alter
  evaluation order of interdependent sub-expressions, and/or base the
  optimizations on behaviors which are not representative of their target
  machines.

  Because I simply observe that since an undefined behavior may also be
  non-deterministic even within a single program, it can't be relied upon;
  therefore enabling a compiler to produce garbage more efficiency is
  seems basically worthless, and actually even dangerous when the compiler
  can't even warn about resulting potentially non-deterministic ambiguities
  because it can't differentiate between garbage and reliably deterministic
  useful code, as it considers them equivalently legitimate.

  (With an exception being FP optimization, as FP is itself based
   only on the approximate not absolute representation of values.)

>> - Agreed, I would classify any expression as being ambiguous if any of
>>   it's operand values (or side effects) were sensitive to the allowable
>>   order of evaluation of it's remaining operands, but not otherwise.
> 
> But this predicate cannot be evaluated at compile time!

- Why not? The compiler should be able to statically determine if an
  expression's operands are interdependent, by determining if any of
  its operand's sub-expressions are themselves dependant on a variable
  value potentially modifiable by any of the other operand's sub-
  expressions. (Which is basically the same constraint imposed when
  rescheduling instructions, as an assignment can not be moved passed a
  reference to the same variable value, without potentially corrupting
  the effective semantics of the specified program, but may freely
  re-schedule assignments and references to distinct variable values
  past each other without any restrictions safely.)



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