Re: Is PRE architecture dependent? aarch64 vs x86_64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 18/07/2025 18:07, Segher Boessenkool wrote:
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.


I'm getting the feeling that we've got our wires crossed somewhere.

Signed integer /arithmetic/ overflow is UB in the C standards and in gcc (unless "-fwrapv" is in effect).

Conversion to a signed integer type, when the value cannot be preserved, is implementation-defined behaviour in the C standards, and in gcc (gcc defines it to be two's complement wrapping).

A "cast from unsigned to int" is a conversion, thus it is implementation-defined.

I think somewhere along the line in this thread, the conversions and signed integer arithmetic overflows have been mixed together.

David





[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux