Re: Undefined Behavior Optimizations in C

gah4 <gah4@u.washington.edu>
Mon, 23 Jan 2023 18:50:31 -0800 (PST)

          From comp.compilers

Related articles
[28 earlier articles]
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)
Re: Undefined Behavior Optimizations in C martin@gkc.org.uk (Martin Ward) (2023-01-23)
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-23)
Re: Undefined Behavior Optimizations in Fortran sgk@REMOVEtroutmask.apl.washington.edu (Steven G. Kargl) (2023-01-26)
Re: Undefined Behavior Optimizations in Fortran gah4@u.washington.edu (gah4) (2023-01-26)
Re: Undefined Behavior Optimizations in C dave_thompson_2@comcast.net (2023-01-28)
| List of all articles for this month |
From: gah4 <gah4@u.washington.edu>
Newsgroups: comp.compilers
Date: Mon, 23 Jan 2023 18:50:31 -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="16579"; mail-complaints-to="abuse@iecc.com"
Keywords: optimize, comment
Posted-Date: 26 Jan 2023 13:59:58 EST
In-Reply-To: 23-01-063

On Wednesday, January 18, 2023 at 3:55:49 PM UTC-8, David Brown wrote:


(snip)


> int x, y;
>
> if (x + 1 > x) y++;


OK, for now just considering this one.


And the only Fortran program I still remember from almost 50 years ago.
(It was summer 1972 when I first started learning Fortran, so not long after.)


| SUBROUTINE RANDU (IX, IY, YFL)
| IY = IX * 65539
| IF (IY) 5,6,6
|5 IY = IY + 2147483647 + 1
|6 YFL = IY
| YFL = YFL * .4656613E-9
| RETURN
| END


To avoid loss of indenting, I put in the |.


Since Fortran doesn't have unsigned integers, programs use signed integers.


And a lot of Fortran programs get translated to C.


But first, I suspect that many C programmers don't know, or don't remember
if they did, that two's complement overflow is UB.


And of those that know it is UB, I suspect many don't expect compilers to remove
statements that depend on it. Most C programmers don't carry around the
standard, and don't look up every operation.


Now, C programmers should know about unsigned int, and its properties.


But those translating Fortran programs to C won't always know when they
depend on it. RANDU is probably the most infamous random number generator,
that was popular for many years. It comes from the IBM Scientific Subroutine
Package that traces back to the early 1960's.


It conveniently depends on the fixed point overflow properties of the multiply,
and then the IF to correct for negative results.


As far as I can tell, Fortran makes no claims regarding fixed point overflow,
being undefined or system dependent.


Fortran does allow for fixed point values in any radix greater than one.
There are requirements for the number of decimal digits that types can
represent.


There are also, as part of the C interoperability feature, fixed point types
(KINDs in Fortran terms) with specific bit widths.


Now, the original subject of this thread, is the cost vs. benefit of such
optimizations. Not so obvious the benefit, but there is a cost when people
try to debug programs where things are optimized away.
[Gee, it's been a while since I thought about SSP. I believe that IBM wrote
it largely to give people code that would get reasonable numeric answers
with the 360's funky floating point. Then there were a few odds and ends
like RANDU. They never promised the code would work on anything other
than IBM 360 Fortran. -John]


Post a followup to this message

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