Dave.

It was to fix this issue.

Thanks Dave.
I haven't managed to prove that the inclusion of -fwrapv achieves anything wrt perl, but there are some well credentialed perl developers saying that it does (or, at least, that it once did).
I'm not about to start arguing the point with them.
I guess, that if its inclusion does something useful then that's well and good. And if it doesn't do anything useful then it's harmless, anyway.

Interesting that the -SvIVX(sv) is still present in sv.c, because I think it's still undefined behaviour when SvIVX(sv) is IV_MIN (aka LONG_MIN), even if -fwrapv is somehow masking it when perl is involved.
UPDATE: The above sentence was incorrect. On reading the code properly (which involved minimal widening of my field of vision), I realize that -SvIVX(sv) is never reached if SvIVX(sv) is IV_MIN.

I haven't yet found any evidence that, in C, that switch ever alters anything.

$ 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]

The compilation warning relates only to "-LONG_MIN".
It's exactly the same (in every respect) when I compile using the -fwrapv switch, and -ftrapv catches nothing.

Cheers,
Rob

-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.

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.