Related articles |
---|
Undefined Behavior Optimizations in C lucic71@ctrl-c.club (Lucian Popescu) (2023-01-05) |
Re: Undefined Behavior Optimizations in C spibou@gmail.com (Spiros Bousbouras) (2023-01-05) |
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-05) |
Re: Undefined Behavior Optimizations in C anton@mips.complang.tuwien.ac.at (2023-01-06) |
Re: Undefined Behavior Optimizations in C anton@mips.complang.tuwien.ac.at (2023-01-06) |
Re: Undefined Behavior Optimizations in C david.brown@hesbynett.no (David Brown) (2023-01-06) |
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-06) |
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-06) |
Re: Undefined Behavior Optimizations in C spibou@gmail.com (Spiros Bousbouras) (2023-01-07) |
Re: Undefined Behavior Optimizations in C 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-09) |
Re: Undefined Behavior Optimizations in C 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-09) |
Re: Undefined Behavior Optimizations in C david.brown@hesbynett.no (David Brown) (2023-01-10) |
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-10) |
[22 later articles] |
From: | gah4 <gah4@u.washington.edu> |
Newsgroups: | comp.compilers |
Date: | Fri, 6 Jan 2023 10:33:29 -0800 (PST) |
Organization: | Compilers Central |
References: | 23-01-009 23-01-011 23-01-012 23-01-017 |
Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="52443"; mail-complaints-to="abuse@iecc.com" |
Keywords: | code, history, comment |
Posted-Date: | 06 Jan 2023 13:49:53 EST |
In-Reply-To: | 23-01-017 |
On Friday, January 6, 2023 at 9:03:30 AM UTC-8, David Brown wrote:
(snip, I wrote)
> > Most important when debugging, is that you can trust the compiler to
> > do what you said. That they don't, has always been part of
> > optimization, but these UB make it worse.
> The trouble with undefined behaviour is that, in general, you cannot
> trust the compiler to "do what you say" because it cannot know what you
> have said.
Well, yes. But sometimes ...
This is reminding me, last year I was working on a program that I worked
on (but didn't write) in 1977. Writting in, as close as it could be, to
standard Fortran 66. (Except that it makes some assumptions about
the use of values read in, and written out, with A format. Like that you
can compare such values.)
In any case, I wanted to compile with bounds check on because it wasn't
working right. (The version I had was not the exact one from 1977.)
It turns out, though, to have a fair number of statements like:
IF(I.GT.0.AND.X(I).EQ.3) ...
That is, test the subscript and use it in the same IF statement.
Now, this would not be a problem at all in C, with short-circuit IF
evaluation required, but even now Fortran doesn't do short
circuit IF evaluation. The way Fortran did static allocation in 1977,
there was pretty much no chance that you would access outside
your address space evaluating X(0). There is a chance, though,
that the value 3 is stored there.
Pretty much what I say in this case, is that I rely on the system
memory protection, and don't need the compiler to ignore the
test on I, which I suspect is one of the UB that C compilers do.
Anyway, in this case I know exactly what I said, and the compiler
does, too. And as long as subscript checks are off, it most
likely works.
[Both Fortran 66 and 77 could do short-circuit evaluation, but it's
not required. I think most compilers did, since it was easy, but
of course you couldn't count on it. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.