RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds

[dt71 at gmx.com]

Konstantin Belousov wrote, On 11/30/2013 13:56:
> The compiler authors take the undefined part there as a blanket to perform
> optimizations which are assuming that signed overflow cannot happen.

Personally, when I first heard about such assumptions, it was inspiring to write code in a way that automatically gives the compiler certain ``overflow cannot happer'' (for example, because the input values given are always small) hints, such as turning some uses of ``unsigned int'' (where a negative value logically doesn't make sense, such as in a size/length value) into ``signed int''. However, I quickly found that this way of thinking leads to counter-production: coding becomes slower, the resulting code becomes less readable, while the performance gain remains questionable. It would be much better if hints could be given to the compiler using assert() (which would have effect even in non-debug mode). How do others feel?

Konstantin Belousov wrote, On 12/01/2013 08:59:
> It is written in C, but no useful program can be written in the pure
> standard C.  We must rely on the assumptions about underlying architecture,
> and compiler must provide sane access to the features of the underlying
> architecture to be useful.

But what behavior do you want for signed arithmetic? Modular, saturating, or some other? And how do you signal that? Or maybe you just want to check for (signed/unsigned) integer overflow (which can't be done "cleanly and efficiently" in C), in which case someone should write a check_add_overflow() function...