|[25 earlier articles]|
|Re: Undefined Behavior Optimizations in C email@example.com (gah4) (2023-01-18)|
|Re: Undefined Behavior Optimizations in C firstname.lastname@example.org (Alexei A. Frounze) (2023-01-19)|
|Re: Undefined Behavior Optimizations in C email@example.com (gah4) (2023-01-20)|
|Re: Undefined Behavior Optimizations in C firstname.lastname@example.org (Thomas Koenig) (2023-01-20)|
|Re: Undefined Behavior Optimizations in C Keith.S.Thompsonemail@example.com (Keith Thompson) (2023-01-20)|
|Re: Undefined Behavior Optimizations in C firstname.lastname@example.org (2023-01-21)|
|Re: Undefined Behavior Optimizations in C email@example.com (Kaz Kylheku) (2023-01-22)|
|Re: Undefined Behavior Optimizations in C firstname.lastname@example.org (2023-01-22)|
|Re: Undefined Behavior Optimizations in C email@example.com (Martin Ward) (2023-01-23)|
|Re: Undefined Behavior Optimizations in C firstname.lastname@example.org (gah4) (2023-01-23)|
|Re: Undefined Behavior Optimizations in C email@example.com (2023-01-28)|
|From:||Kaz Kylheku <firstname.lastname@example.org>|
|Date:||Sun, 22 Jan 2023 07:04:26 -0000 (UTC)|
|Organization:||A noiseless patient Spider|
|References:||23-01-027 <email@example.com> 23-01-031 23-01-041 23-01-062 23-01-065 23-01-067|
|Injection-Info:||gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="70091"; mail-complaints-to="firstname.lastname@example.org"|
|Posted-Date:||22 Jan 2023 12:20:49 EST|
On 2023-01-20, Thomas Koenig <email@example.com> wrote:
> Alexei A. Frounze <firstname.lastname@example.org> schrieb:
>> I believe in a case like this a modern C/C++ compiler reasons that x must be
>> less than the maximum representable value and it generates code according
>> to this, possibly removing dead code that depends on x being the maximum
>> representable value. If the compiler's assumption that x is less than the
>> maximum is wrong, it's perfectly fine, it's UB, any "broken" code generated
>> is allowed.
> There are cases when compilers don't even use this knowledge.
> Take the function
> int add (int a, int b)
> return a+b;
> on an instruction set architecture which has only 64-bit
> arithmetic, such as POWER. This is translated by gcc,
> with optimization, to
> add 3,3,4
> extsw 3,3
> (which is an addition followed by a sign extension). The POWER ABi
> specifies that all values passed in registers are sign-extended,
> so the content of a register has the same value independent of
> the width of the signed integer it is being considered as.
> So, the compiler would be within its right to _not_ extend the sign
> of the result, because it could assume that no overflow occurs.
Indeed. If overflow occurs, then there could be an unexpected results if
the, say, result of the addition is converted to a 64 bit type.
Suppose that a 32 to 64 conversion is actually a no-op, because the
register values are assumed to be sign-extended, like the ABI says.
Then, say a and b are positives values that fit into the 32 bit
range, such that the a + b sum does not; it wraps negative
in 32 bits.
The programmer might thus expect expect (long) (a + b) to be
that wrapped negative value.
But since the addition is done in 64 bits, it doesn't overflow;
there is a positive 64 bit result. If conversion to long is a noop,
a positive value of long will result, as if the expression were
(long) a + (long) b.
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Return to the
Search the comp.compilers archives again.