Re: Optimisations and undefined behaviour

[David Brown <david dot brown at hesbynett dot no>]

On 06/11/15 16:48, Andrew Haley wrote:
> On 11/06/2015 02:44 PM, David Brown wrote:

> > 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.

I don't think that is unreasonable.  I certainly think that fixing any 
UB bugs in the users' code is the best possibility, and I'm glad gcc is 
getting steadily better at helping here (recent versions have had many 
new and helpful warnings, including several for UB, as well as the 
runtime sanatization options).

My aim with this discussion here was really to get an idea of how gcc 
developers feel about these things.  My inspiration was from some posts 
in comp.lang.c newsgroup, from others who feel that C compilers should 
not try to be "too smart" and that aggressive optimisations "risk 
breaking perfectly good code" (in their eyes).  I guess that is why you 
still have "-O0" and "-O1" optimisation levels!

Personally, I do agree that the compiler should be free to exploit 
undefined behaviour in many ways - I just also want developers 
(including myself) to have the best chances of spotting code errors as 
soon as possible, and to avoid errors in one part of the code 
manifesting themselves as symptoms in apparently unrelated areas of code.

> > 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.

I know /I/ have the right language (well, I also use C++ a little - but 
everything that applies to C here also applies to C++), and the right 
compiler.  But certainly not everyone who writes in C has the right 
language - I think many who use it would be better using a different 
language, for all sorts of reasons, including UB, bounds and range 
checked, etc.  (Many may also feel safer using "-O1 -fwrapv -Wall 
-Wextra" - in my experience, a lot of users are unaware of most gcc flags.)

> > 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!
> :-)

I have sometimes used a cast to void as a way of telling the compiler 
that I know a value is not being used (such as after reading from a 
volatile hardware register in a microcontroller).  What we need here is 
a cast /from/ void!

Anyway, thanks for your time and thoughts.  I believe I have the answers 
I was looking for at the moment.

David