Re: -funsafe-loop-optimizations

[Paul Schlie <schlie at comcast dot net>]

> From: Paul Schlie <schlie@comcast.net>
>> From: Robert Dewar <dewar@adacore.com>
>>> Paul Schlie wrote:
>>> I suspect we're not referring to the same thread of context; I made the
>>> comment in response to: http://gcc.gnu.org/ml/gcc/2005-01/msg00084.html
>>> which I didn't interpret as referring to the portability of the compiler,
>>> but rather code compiled by it having potentially different semantics as
>>> a function of the "target's" type-sizes,
>> 
>> That's not a compiler issue, the author was simply pointing out that code
>> of the type we are talking about is inherently non-portable. If you have
>> a loop that is infinite if the size of unsigned is 16 and well behaved if
>> the size of unsigned is 32, as required by the standard, then you have simply
>> written non-portable code. This is nothing to do with the compiler. Indeed
>> if anything the improper "optimization" might have the effect of increasing
>> portability in practice of this incorrect code. What MK was noting was that
>> even though this code is non-portable, in practice, it may be portable to
>> 32-bit architectures. That's nothing new, and nothing to do with the code
>> that gcc generates. C is a language where it is very easy to write non-
>> portable code if you are not very careful. The compiler cannot somehow
>> magically correct such programs.
> 
> Agreed, my mistake.

(but would point out that if an explicit size were used i.e. uint16 etc.,
 the behavior would be expected to be portable across all targets which
 supported the type-size.)