This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Optimisations and undefined behaviour
- From: David Brown <david dot brown at hesbynett dot no>
- To: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>, Andrew Haley <aph at redhat dot com>, Florian Weimer <fweimer at redhat dot com>
- Cc: Segher Boessenkool <segher at kernel dot crashing dot org>, "[gcc-help]" <gcc-help at gcc dot gnu dot org>
- Date: Tue, 10 Nov 2015 12:56:47 +0100
- Subject: Re: Optimisations and undefined behaviour
- Authentication-results: sourceware.org; auth=none
- References: <563BC190 dot 7080406 at hesbynett dot no> <563C7EB6 dot 9050401 at redhat dot com> <563C9DD3 dot 9030407 at hesbynett dot no> <563F9E4C dot 5000504 at redhat dot com> <20151108193430 dot GA28206 at gate dot crashing dot org> <56407162 dot 7050106 at redhat dot com> <56408D14 dot 2090101 at redhat dot com> <5640A8D3 dot 8060706 at redhat dot com> <5640AAC5 dot 9090509 at redhat dot com> <5640ADC5 dot 4090604 at redhat dot com> <5640B40C dot 9000906 at foss dot arm dot com> <5640B51F dot 1080401 at redhat dot com> <5640B632 dot 9040802 at foss dot arm dot com> <5640BA3E dot 3030508 at redhat dot com> <5640C248 dot 7040904 at hesbynett dot no> <5640CA59 dot 8090300 at redhat dot com> <5641B6C9 dot 6050806 at hesbynett dot no> <5641C415 dot 7050204 at foss dot arm dot com> <5641CA93 dot 3090302 at hesbynett dot no> <5641CFBF dot 8010902 at foss dot arm dot com>
On 10/11/15 12:06, Richard Earnshaw wrote:
> On 10/11/15 10:44, David Brown wrote:
>> But consider if integer overflow were made "unspecified" rather than
>> "undefined" - i.e., it were guaranteed to return a valid integer, but
>> you know nothing about /which/ integer it is. For efficiency, that
>> would require that the hardware does not have enforced traps on
>> overflow. But the compiler is still able to optimise "x * 3 / 6" to "x
>> / 2", and still able to assume that "x + 1 > x". But given "x = 1290;
>> foo(); y = x * x * x;" it is no longer able to eliminate the call to "foo".
>>
>
> I /think/ you've just said that x86 can no-longer use its divide
> instruction. That instruction faults if you have n/0 or INT_MIN/-1.
>
That's why it's good that there are lots of people thinking together on
these specifications, and not just one person! Or perhaps we should all
switch to using ARM chips...
Annex L allows traps or exceptions as part of "bounded undefined
behaviour". But if an instruction can trap, then it is more difficult
to move around - a trap is (presumably) observable behaviour, whereas
something that produces an unspecified but valid result is not
observable and can be re-arranged more easily.