Should -ftrapv check type conversion?

[Ken Raeburn <raeburn at raeburn dot org>]

I've been looking at -ftrapv and some simple cases it doesn't work  
right in.  (I've got a patch coming soon to address one case where  
__addvsi3 libcalls and the like get optimized away in RTL.)

I see a few reports in Bugzilla, many marked as duplicates of PR  
19020 though they cover a few different cases, which have me  
wondering about what the scope of -ftrapv ought to be.

(I'm assuming 32-bit int and 16-bit short below, for simplicity.)

1) What about conversions to signed types?

  unsigned int x = 0x80000000;
  int y = x;   /* trap? */

You get a negative number out of this if you define the conversion as  
wrapping twos-complement style, but I believe the spec says it's  
undefined.  It's not so much "overflow" from an arithmetic  
calculation as "out of range", but isn't that what the signed- 
overflow errors come down to, results that are out of range for the  
type used to represent them?

2) Conversions to narrower signed types?

  signed int x = 0xfffff;
  signed short y = x;  /* trap? */

It seems to me that a trap here would be desirable, though again it's  
an "out of range" issue.  However, a logical extension of this would  
be to possibly trap for "*charptr = x & 0xff" or "(char)(x & 0xff)"  
on a signed-char configuration, and that's probably pretty common code.

3) What about narrower-than-int types?

  signed short a = 0x7000, b = 0x7000, c = a+b;

Technically, I believe the addends are widened to signed int before  
doing the addition, so the result of the addition is 0xe000.  If the  
result is assigned to an int variable, there's no undefined  
behavior.  Converting that to signed short would be where the  
overflow question comes up, so this is actually a special case of #2.

3) Is Fortran 90 different?

PR 32153 shows tests in Fortran for 1-, 2-, 4-, and 8-byte types.  I  
know very little about the Fortran 90 spec, but if it doesn't say the  
narrower values get widened as in C, then -ftrapv should definitely  
cause traps for signed short or signed char arithmetic, even if we  
don't do it for the C type conversion cases above.

Ken