On Fri, Jul 18, 2025 at 04:32:58PM +0200, Florian Weimer wrote:
> > On Mon, Jul 14, 2025 at 03:03:46PM -0700, Florian Weimer wrote:
> >> > -fwrapv is a great way to get slower code, too. Is there something in
> >> > your code that does not work without this reality-distorting flag?
> >>
> >> It really depends on the code. In many cases, -fwrapv enables
> >> additional optimizations. For example, it's much easier to use (in C
> >> code) the implicit sign bit many CPUs compute for free.
> >
> > -fwrapv says "I want something that is not valid C code". Code that
> > requires -fwrapv to work as intended is not valid C code (will have UB).
>
> It would be just another extension, and one that many compilers already
> enable by default. Even GCC makes casting from unsigned to int defined
> in all cases because doing that in a standard-conforming way is way too
> painful.
("All cases", where that means "one very specific case").
(It is trivial to implement it as two's complement, just inconvenient.
For standard behaviour of course *anything goes*, UB is UB).
-fwrapv makes code that is not valid C code (because it exhibits
undefined behaviour) compile without error. So it changes behaviour in
a very real way. In a way that prevents many optimisations, too.
The "unsigned to signed conversion" thing is documented implementation-
defined behaviour. As the GCC manual says:
> The result of, or the signal raised by, converting an integer to a
> signed integer type when the value cannot be represented in an object
> of that type (C90 6.2.1.2, C99 and C11 6.3.1.3, C23 6.3.2.3). For
> conversion to a type of width N, the value is reduced modulo 2^N to be
> within range of the type; no signal is raised.
Segher
