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: -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)



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