This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Should -ftrapv check type conversion?


On Mon, 17 Sep 2007, Ken Raeburn wrote:

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

See my message <http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02026.html> 
for the definition of -ftrapv as I understand it.  I think expanding to 
cover division by 0 and shift counts that are negative or too large would 
make sense, though at some point maybe users will want the option split up 
so they get traps for some operations only.

Potentially trapping operations may need to be marked at tree level as 
having side-effects to avoid them getting optimized away.  This will be 
easier when flags such as -ftrapv are represented as bits on the affected 
operations rather than only as global flag variables.

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

It's not undefined, it's implementation-defined, and the implementation 
duly defines it in implement-c.texi.

> 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

Again, implementation-defined.

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

Yes, implementation-defined.

Out-of-range conversions to signed integer types can be 
implementation-defined to raise an implementation-defined signal as an 
alternative to returning an implementation-defined value.  We could add an 
option to do so, but I think it should be separate from -ftrapv.

> 3) Is Fortran 90 different?

My definition of the option is as language semantics for C and C-family 
languages; I can't judge what may be useful for other supported languages.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]