$ cat LONG_MIN.c

#include <stdio.h>
#include <limits.h>

int main(void) {
  printf("%ld %ld\n", LONG_MIN, -LONG_MIN);
  return 0;
}

$ gcc -o LONG_MIN LONG_MIN.c
LONG_MIN.c: In function ‘main’:
LONG_MIN.c:6:33: warning: integer overflow in expression ‘-92233720368
+54775808’ of type ‘long int’ results in ‘-9223372036854775808’ [-Wove
+rflow]
    6 |   printf("%ld %ld\n", LONG_MIN, -LONG_MIN);
      |                                 ^

$ ./LONG_MIN
-9223372036854775808 -9223372036854775808
[download]

-fwrapv gives implementation defined behaviour for wrapping variables but not constants.

#include <limits.h>
#include <stdio.h>

int
main()
{
    printf(" LONG_MIN %ld\n", LONG_MIN);
    printf(" LONG_MAX  %ld\n", LONG_MAX);
    printf("-LONG_MAX %ld\n", -LONG_MIN); // line 9

    long lval = LONG_MIN;
    lval = lval * -1; // this is okay with -fwrapv
    printf("wrap lval  %ld\n", lval);
}
[download]

$ gcc -Wall -Wextra -Woverflow -fwrapv -fsanitize=undefined t.c -o t &
+& ./t
t.c: In function ‘main’:
t.c:9:31: warning: integer overflow in expression ‘-922337203685477580
+8’ of type ‘long int’ results in ‘-9223372036854775808’ [-Woverflow]
    9 |     printf("-LONG_MAX %ld\n", -LONG_MIN); // line 9
      |                               ^
 LONG_MIN -9223372036854775808
 LONG_MAX  9223372036854775807
-LONG_MAX -9223372036854775808
wrap lval  9223372036854775807
[download]

I see that the patch fixes it by changing to unsigned int so it seems the wrapping is irrelevant there.

I've since noticed that -fwrapv is omitted from CCFLAGS when I build perl on Windows using gcc-10.2.0. So I created an issue about that, wherein I again queried the need for the -fwrapv switch. In that thread, Tomasz Konojacki (@xenu) explains it clearly:

<quote>
-fwrapv basically means "signed integer overflow won't cause undefined behavior".
In practice, gcc with this flag disabled will still wrap signed integers on overflow, because that's how virtually all CPUs implement signed integer arithmetic.
However, what does change is the behavior of the optimizer: it will assume that all signed integers will never overflow.
Because of that, the breakage caused by omission of this flag is very subtle and unpredictable, and there's no reasonable way to test for it.
</quote>

That makes good sense to me, and I also provided a patch to win32/GNUmakefile that fixes that issue with gcc-10.x.x and (presumably) later.

Cheers,
Rob

In the past I've noted a lot of change for the sake of change. Not to say it is the case here, but that is the case nonetheless in bleed.

In the past I've noted a lot of change for the sake of change. Not to say it is the case here, ...

Yes, I don't think it's the case here.
There's good evidence that this change was deemed necessary.

However, I've just built perl-5.33.8 on Windows, without -fwrapv, and all tests passed.
This was using gcc-10.3.0. Maybe Windows was never affected, or maybe something has changed with gcc-10.3.0.
I'll test more extensively with perl-5.33.9 when it comes out (either later today or tomorrow), and add a report to https://github.com/Perl/perl5/issues/13690 if I can't find any need for -fwrapv

C:\comp-1020\perl-5.33.9\win32>..\perl -I..\lib -V:archname
archname='MSWin32-x64-multi-thread';

C:\comp-1020\perl-5.33.9\win32>..\perl -I..\lib -V:d_nv_preserves_uv
d_nv_preserves_uv='undef';

C:\comp-1020\perl-5.33.9\win32>..\perl -I..\lib -V:nv_preserves_uv_bit
+s
nv_preserves_uv_bits='53';

C:\comp-1020\perl-5.33.9\win32>..\perl -I..\lib -V:ccflags
ccflags=' -DWIN32 -DWIN64 -fdiagnostics-color=never -DPERL_TEXTMODE_SC
+RIPTS -DPERL_IMPLICIT_CONTEXT
 -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D__USE_MINGW_ANSI_STDIO -fno-strict
+-aliasing -mms-bitfields';

C:\comp-1020\perl-5.33.9\win32>..\perl -I..\lib -le "print $];"
5.033008
[download]

Cheers,
Rob