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] |
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
Return to the
comp.compilers page.
Search the
comp.compilers archives again.