Re: Optimization techniques and undefined behavior

David Brown <david.brown@hesbynett.no>
Tue, 7 May 2019 16:38:32 +0200

          From comp.compilers

Related articles
[29 earlier articles]
Re: Optimization techniques and undefined behavior martin@gkc.org.uk (Martin Ward) (2019-05-06)
Re: Optimization techniques and undefined behavior robin51@dodo.com.au (Robin Vowels) (2019-05-07)
Re: Optimization techniques and undefined behavior derek@_NOSPAM_knosof.co.uk (Derek M. Jones) (2019-05-06)
Re: Optimization techniques and undefined behavior david.brown@hesbynett.no (David Brown) (2019-05-07)
Re: Optimization techniques and undefined behavior david.brown@hesbynett.no (David Brown) (2019-05-07)
Re: Optimization techniques and undefined behavior david.brown@hesbynett.no (David Brown) (2019-05-07)
Re: Optimization techniques and undefined behavior david.brown@hesbynett.no (David Brown) (2019-05-07)
Re: Optimization techniques and undefined behavior martin@gkc.org.uk (Martin Ward) (2019-05-08)
Re: Optimization techniques and undefined behavior gneuner2@comcast.net (George Neuner) (2019-05-08)
Re: Optimization techniques and undefined behavior genew@telus.net (Gene Wirchenko) (2019-05-11)
| List of all articles for this month |

From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.compilers
Date: Tue, 7 May 2019 16:38:32 +0200
Organization: A noiseless patient Spider
References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> 19-04-021 19-04-024 19-04-038 19-05-010
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="27122"; mail-complaints-to="abuse@iecc.com"
Keywords: standards, errors
Posted-Date: 07 May 2019 18:47:26 EDT
Content-Language: en-GB

On 02/05/2019 19:18, Kaz Kylheku wrote:
> On 2019-04-28, David Brown <david.brown@hesbynett.no> wrote:
>> On 26/04/2019 04:26, Kaz Kylheku wrote:
>>> On 2019-04-25, David Brown <david.brown@hesbynett.no> wrote:
>>>> It knows that "x * 2 / 2" is "x". It knows that "x + 1 > x" is true.
>>>
>>> Also, we could have it so that multiplication wraps, and yet in the same
>>> breath allow algebraic reductions like this anyway.
>>>
>>> Basically it can be so that, if overflow takes place in the abstract
>>> semantics of "x * 2 / 2", the result can be either the truncated
>>> version, or just x, if the algebraic reduction took place.
>>>
>>
>> I am afraid I don't understand you here. Are you saying that you could
>> define the language's arithmetic so that, given "x * 2 / 2", the
>> compiler could return /either/ "x" or the result you would get from
>> wrapped overflow calculations? You are defining two possible "correct"
>> answers?
>
> I'm fairly comfortable with this, because it maps to the familiar ISO C
> concept of "unspecified behavior".


OK. I can appreciate that, and would consider "signed integer overflow
has unspecified behaviour" as a reasonable choice.


>
> For instance, this program can produce one of the results -12, -6, -2
> or 4, based on which of the six permutations over the order in which the
> three functions are called.
>
> #include <stdio.h>
>
> int x = 1;
>
> int add2(void)
> {
> x += 2;
> return 0;
> }
>
> int mul4(void)
> {
> x *= 4;
> return 0;
> }
>
> int neg(void)
> {
> x = -x;
> return 0;
> }
>
> void dummy(int a, int b, int c)
> {
> }
>
> int main()
> {
> dummy(add2(), mul4(), neg());
> printf("%d\n", x);
> }
>
> Unspecified behavior isn't exactly wonderful, but it's better than
> undefined behavior.
>


It /can/ be better, but it is not always better.


People often misunderstand what unspecified behaviour means. For
example, it is possible for different runs of your program here to
produce different results - unspecified results don't need to be
consistent on different runs.


But if you write:


int main() {
dummy(add2(), mul4(), neg());
if (x == 4) printf("X is 4\n");
if (x != 4) printf("X is not 4\n");
}


then for any run of the program, one of the two statements must be
printed. If "dummy" had undefined behaviour, /neither/ of them would
have to be printed. So undefined behaviour can give more optimisation
opportunities (not that they are helpful in this case).


And with dummy() giving unspecified behaviour, the compiler will accept
the code without complaint - otherwise you'd get endless realms of false
positive warnings. But if dummy() had undefined behaviour, a compiler
can warn you of your bug.


Still, I agree that unspecified values could sometimes be a nice
alternative.


Post a followup to this message

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