Re: Optimization techniques and undefined behavior

On 02/05/2019 15:51, David Brown wrote:
> On 01/05/2019 14:53, Bart wrote:


>> That's just kicking the can further down the road.
>>
>
> Yes (especially for the use of a larger signed type).  That's fine.  C
> let's you easily kick the can a /long/ way down the road.  How often do
> you need integers that will overflow a 64-bit type?


Most of your post seems to take the premise that 64-bit types have such
a wide range that you can forget about overflow problems.


But the principle is actually the same: two values A and B represented
within N-bit types could overflow when performing arithmetic. It doesn't
matter if N is 32 or 64.


The subject in UB, and whether the possibility of overflow can just be
ignored by a language, a language that deals with low-level
machine-sized types.


You seem OK with a C compiler assuming that overflow cannot happen so
that it can generate slightly faster benchmarks.


I prefer a language acknowledging that it could happen, and stipulating
exactly what does happen.




>> If you have two unknown values A and B, and need to multiply, you won't
>> know if the result will overflow.
>>
>
> First off, how often do you actually have unknown values to deal with?
> Usually you know something at least.


The example here was reading values from a file. So they are external
data, and will be unknown.


> bytes_per_pixel is not going to be more than, say, 16 - that's for
> 32-bit per colour, including alpha channel.


It shouldn't be, but you might be reading it from a file.


> (And one thing we can be sure of here - having two's complement wrapping
> arithmetic certainly will not help.)


No; neither is unsigned number wrapping. But having gcc do something
weird instead, at odds with nearly every other compiler and language, is
even less help.

Return to the comp.compilers page.
Search the comp.compilers archives again.