Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Kaz Kylheku <864-117-4973@kylheku.com> Newsgroups: comp.compilers Subject: Re: Undefined Behavior Optimizations in C Date: Sun, 22 Jan 2023 07:04:26 -0000 (UTC) Organization: A noiseless patient Spider Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <23-01-070@comp.compilers> References: <23-01-027@comp.compilers> <23-01-031@comp.compilers> <23-01-041@comp.compilers> <23-01-062@comp.compilers> <23-01-065@comp.compilers> <23-01-067@comp.compilers> Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="70091"; mail-complaints-to="abuse@iecc.com" Keywords: C, optimize Posted-Date: 22 Jan 2023 12:20:49 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:3338 On 2023-01-20, Thomas Koenig wrote: > Alexei A. Frounze 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 > blr > > (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 Mastodon: @Kazinator@mstdn.ca