This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Optimisations and undefined behaviour
- From: Florian Weimer <fweimer at redhat dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Segher Boessenkool <segher at kernel dot crashing dot org>, David Brown <david dot brown at hesbynett dot no>, "[gcc-help]" <gcc-help at gcc dot gnu dot org>
- Date: Mon, 9 Nov 2015 13:09:56 +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>
On 11/09/2015 11:11 AM, Andrew Haley wrote:
> On 08/11/15 19:34, Segher Boessenkool wrote:
>> The compiler is free to transform it to
>>
>> int foo(int x) {
>> int t = x*x*x;
>> if (x > 1290) {
>> printf("X is wrong here %d, but we don't care\n", x);
>> }
>> return t;
>> }
>>
>> because x*x*x does not have any observable behaviour, and then it is
>> obvious it _can_ remove the printf and conditional.
I'm not sure if this is a valid transformation for printf, even if
targets stdout and does not use any custom format specifiers. Isn't it
a cancellation point? But let's assume it's not.
> Yes, that is correct. And, indeed, the hardware is free to do taht
> too. With speculative execution, the "as if" rule is not limited to
> the compiler.
Can we disallow that optimization as a quality-of-implementation matter?
What would be the benefit of such optimizations, other than
discouraging programmers from using C or C++?
I'm worried that this particular line of argument would also allow the
movement of undefined behavior which occurs after an infinite loop in
front of it, even if this loop performs I/O.
Florian