This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -funsafe-loop-optimizations
- From: Paul Schlie <schlie at comcast dot net>
- To: <gcc at gcc dot gnu dot org>
- Date: Sat, 01 Jan 2005 22:01:45 -0500
- Subject: Re: -funsafe-loop-optimizations
> Paul Schlie wrote:
>> From: Robert Dewar <dewar@adacore.com>
>>> Paul Schlie wrote:
>>> As I believe stated earlier, it would seem the compiler arguably has no
>>> license to change semantics of the language;
>>
>> That's not right, it merely has to have a mode in which it operates in
>> a strictly standard manner. There
>> is nothing in the C standard that prevents a compiler from having options
>> for non-standard behavior.
>> GNU C already has non-standard extensions, this would just be another case
>> where, by setting certain options, you get non-standard behavior.
>
> Don't necessarily disagree, but wouldn't it be preferable if the ambiguity
> were explicitly removed in the code (or indirectly asserted as being desired
> by it's remaining presence), rather than assuming by default otherwise?
Although I don't mean to argue for it's development/inclusion; it would seem
that being able to assert and ideally statically verify an anticipated
restricted value range for any c/c++ variable or parameter assignment would
go a long way to assisting the authoring of more reliable, and optimize-able
code; therefore wonder if it may be worth longer-term consideration of some
clever way by which such assertions may be included in c/c++ source using
possibly defined macros(?) which GCC can parse/analyze while simultaneously
being defined to expand to empty/null c/c++ run-time source expressions, or
something like that? (sorry for rambling)