svn commit: r300332 - in head/sys: amd64/amd64 i386/i386

[Konstantin Belousov]

On Sat, May 21, 2016 at 06:29:50PM -0700, Chris Torek wrote:
> On the other hand, since most C compilers don't bother to trap
> signed integer overflow, but some can, signed integers may behave
> just as badly.  :-)
> 
> Overall I personally find the rules simpler for unsigned integers
> (occasionally surprising, but predictable and provable behavior in
> the mod-2^k ring) than for signed integers (occasionally
> surprising, possible trap on overflow, possible nonsense on
> overflow, unpredictable and hence unprovable in general).
> 
> The ANSI C folks in 1989 made a mess with the "value preserving"
> rules where unsigned integers become signed integers if the
> widened type is capable of representing all the values of the
> narrower type, but become wider unsigned integers if the widened
> type is not capable of representing all these values.
The biggest mess in ANSI C is that STD left signed arithmetic undefined
on overflow for 2-complement machines. It might be too bold, but IMO
significant number, if not all, programmers have a model of signed
integer operations on the typical modern real-machine (x86 or riscs)
where signed op is done by bit-preserving convertion to unsigned and
then doing unsigned op.

It is quite possible that standard authors did not even considered that
a practically useful compiler could do this differently. The hole was
used by one of the compilers to get ever important additional .5% in an
artifical benchmarks. Unfortunately gcc went the same route, adopting
both undef behaviour claim and colored error messages.

We use -fwrapv for kernel.