Re: Optimisations and undefined behaviour

[Andrew Haley <aph at redhat dot com>]

On 11/06/2015 02:44 PM, David Brown wrote:
> On 06/11/15 14:42, Andrew Haley wrote:
>> On 11/06/2015 12:32 PM, David Brown wrote:
>>
>>> Is it at least possible to put some restrictions or guarantees in
>>> how far the compiler will go in its optimisations, or how far it
>>> will go without warnings? 
>>
>> AFAICS that is the intention of Appendix L.  I don't know how to bound
>> undefined behaviour in the way it suggests; it may turn out to be
>> difficult.
>>
>>> I don't want to limit the generation of code, I want it to be harder
>>> for there to be a mismatch between what the compiler generates and
>>> what the programmer intended.
>>
>> I don't think you can have both.
> 
> I think it is possible - warnings (especially enabled by -Wall,
> rather than needing explicit options) can warn when optimisation
> changes code in certain ways. 

Not without adding a lot of false positives.  The undefinedness of
integer overflow is used more than perhaps you think.

> But I can certainly see that minimising false positives and false
> negatives is extremely difficult.

Yes.  That's why we added -fsanitize=undefined.  It moves the
detection to runtime.

>>> And when there /is/ a mismatch, I want it to be easier to find -
>>> applying undefined behaviour backwards in the code can make it
>>> extremely difficult for the programmer to find the real problem.
>>
>> The undefinedness of integer overflow allows us to transform
>>
>>    x*3/3 -> x
>>
>> It's not a bug, it's a feature.
> 
> I agree.  It is a useful feature, allowing such transforms.
> 
> However, when it is also used to transform other code logically
> before the line with (potentially) undefined behaviour, the
> usefulness becomes less clear - and at the very least, warnings
> would help programmers get their code right.

You are contradicting yourself.  If you allow that example, you
allow the same transformations to be used everywhere.

>> C is a particular language which has been specified in a particular
>> way in order to allow these kinds of optimizations.  If people don't
>> want that kind of language there are plenty of others, most of which
>> don't have the same properties.
>>
>> I really think you are talking to the wrong people.  If you want to
>> control what optimizations are allowed in a C implementation you
>> should appeal to the C standard technical committe, not compiler
>> writers.  Appendix L is interesting, and perhaps is a way forward for
>> those who agree with you.
> 
> I am not sure I want to /control/ the kind of optimisations allowed
> in C - it's more that I want to understand them, and in particular I
> want to understand how they may be implemented in future versions of
> real-world compilers (gcc in particular). 

Anything not excluded by the standard may be implemented.  There is no
other safe assumption.  From time to time compiler writers choose not
to implement a particular optimization because it doesn't gain much
and it's too likely to break code.  But speaking for myself, I'm happy
to fix UB bugs in my code and let the compiler optimize as much as
possible.

> There is no doubt that compilers have been getting smarter (for
> which the gcc developers deserve praise and thanks) - but it opens
> more possibilities for people to write code that they think is
> correct, but is actually wrong.  So I believe I am talking to the
> correct people, although I might not be expressing myself very well
> - I am interested in the implementations of C here, rather than the
> standards.  It is the implementations that have made more aggressive
> use of undefined behaviour in recent years - the standards haven't
> changed in this respect (except for Annex L).

But if you write in C you won't be affected at all.  It's only people
writing undefined code who will be affected by the issues we have
discussed.  And the correct solution to your problem, IMHO, would be
to redefine "undefined" in a way that excludes the behaviour that you
think people find unexpected.  But again, I think you've got the wrong
language: there are other languages without these pitfalls.

> Incidentally, what do you think of the possibility of a "dont_care()"
> expression?  I believe it would allow programmers to be clearer to the
> compiler that they are not interested in the exact results, but they
> don't want /undefined/ behaviour.

It would be interesting to see if such a thing can be defined in a
semantically rigorous way.  And explained to "ordinary" programmers!
:-)

Andrew.