Re: Undefined Behavior Optimizations in C

"Alexei A. Frounze" <alexfrunews@gmail.com>
Thu, 19 Jan 2023 21:18:52 -0800 (PST)

          From comp.compilers

Related articles
[20 earlier articles]
Re: Undefined Behavior Optimizations in C tkoenig@netcologne.de (Thomas Koenig) (2023-01-12)
Re: Undefined Behavior Optimizations in C antispam@math.uni.wroc.pl (2023-01-13)
Re: Undefined Behavior Optimizations in C 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-15)
Re: Undefined Behavior Optimizations in C spibou@gmail.com (Spiros Bousbouras) (2023-01-18)
Re: Undefined Behavior Optimizations in C david.brown@hesbynett.no (David Brown) (2023-01-18)
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-18)
Re: Undefined Behavior Optimizations in C alexfrunews@gmail.com (Alexei A. Frounze) (2023-01-19)
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-20)
Re: Undefined Behavior Optimizations in C tkoenig@netcologne.de (Thomas Koenig) (2023-01-20)
Re: Undefined Behavior Optimizations in C Keith.S.Thompson+u@gmail.com (Keith Thompson) (2023-01-20)
Re: Undefined Behavior Optimizations in C anton@mips.complang.tuwien.ac.at (2023-01-21)
Re: Undefined Behavior Optimizations in C 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-22)
Re: Undefined Behavior Optimizations in C anton@mips.complang.tuwien.ac.at (2023-01-22)
[3 later articles]
| List of all articles for this month |

From: "Alexei A. Frounze" <alexfrunews@gmail.com>
Newsgroups: comp.compilers
Date: Thu, 19 Jan 2023 21:18:52 -0800 (PST)
Organization: Compilers Central
References: 23-01-027 <sympa.1673343321.1624.383@lists.iecc.com> 23-01-031 23-01-041 23-01-062
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="1115"; mail-complaints-to="abuse@iecc.com"
Keywords: C, optimize
Posted-Date: 20 Jan 2023 11:16:59 EST
In-Reply-To: 23-01-062

On Wednesday, January 18, 2023 at 8:35:40 AM UTC-8, Spiros Bousbouras wrote:
...
> I have encountered several times the claim that compilers assume that UB does
> not happen and I don't understand it. Lets consider 2 examples :
>
> x + 1 > x
>
> in C where x is a signed integer. Compilers will often treat this as
> always true with the following reasoning :
>
> - if x does not have the maximum value which fits in its type then the
> meaning of the C expressions is the same as their mathematical meaning
> so the expression evaluates to true.
>
> - if x has the maximum value which fits in its type then x + 1 is not
> defined so any translation (including treating the whole expression as
> true) is valid.
>
> There's no assumption that UB (undefined behaviour) will not happen, both
> possibilities are accounted for.


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.


Alex


Post a followup to this message

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