This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Ada front-end depends on signed overflow
- From: Paul Schlie <schlie at comcast dot net>
- To: Robert Dewar <dewar at adacore dot com>
- Cc: Andrew Pinski <pinskia at physics dot uc dot edu>,Florian Weimer <fw at deneb dot enyo dot de>,GCC List <gcc at gcc dot gnu dot org>,<bosch at gnat dot com>
- Date: Tue, 07 Jun 2005 09:31:42 -0400
- Subject: 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.)