Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| [19 earlier articles] |
| Re: Undefined Behavior Optimizations in C Keith.S.Thompson+u@gmail.com (Keith Thompson) (2023-01-12) |
| 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) |
| [4 later articles] |
| From: | gah4 <gah4@u.washington.edu> |
| Newsgroups: | comp.compilers |
| Date: | Wed, 18 Jan 2023 21:10:55 -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 23-01-063 |
| Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="12660"; mail-complaints-to="abuse@iecc.com" |
| Keywords: | analysis |
| Posted-Date: | 19 Jan 2023 12:25:23 EST |
| In-Reply-To: | 23-01-063 |
On Wednesday, January 18, 2023 at 3:55:49 PM UTC-8, David Brown wrote:
(snip)
> From your example above, we can see that the compiler can transform (a)
> into "y++;" - there is no need for the conditional. But the compiler
> can /also/ transform (b) into ";" - it is allowed to reason that if x
> /were/ equal to INT_MAX, statement (a) would be undefined behaviour
> (even though it was transformed away) and there is no value for x which
> would result in "y = 10" being executed without also executing UB.
This is reminding me of some quantum mechanics rules described here:
https://www.sciencenews.org/wp-content/uploads/2010/11/baseball.pdf
It is interesting reading for those interested in the physics, but also
for those who aren't. It doesn't take much physics thought.
It has to do with what quantum mechanics allows when you don't
actually measure something.
And, similarly, compilers shouldn't try to make too many assumptions
about things not measured.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.