Re: [PATCH][4.3] Deprecate -ftrapv

Re: [PATCH][4.3] Deprecate -ftrapv

[FX Coudert]

> C: integer overflow undefined, checking desirable at least for
> debugging purposes.
>
> I think latest Fortran is same as C, can someone confirm?

Yes, it is. Overflow undefined and no checking required; I think very  
few Fortran users actually use (or would use) checking on signed  
overflow.

FX

-- 
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

FX Coudert wrote:
>> C: integer overflow undefined, checking desirable at least for
>> debugging purposes.
>>
>> I think latest Fortran is same as C, can someone confirm?
> 
> Yes, it is. Overflow undefined and no checking required; I think very  
> few Fortran users actually use (or would use) checking on signed  
> overflow.

But assuming the gcc is playing C-style games, it is probably a useful
thing to be able to verify that your code is free of such possibilities.
> 
> FX
> 

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Guenther]

On Sat, 1 Mar 2008, Richard Guenther wrote:

> 
> This is a request to depcrecate -ftrapv which has numerous problems
> making it not work as expected since a long time.  As nobody seems
> to have the energy to ensure it is working I propose to deprecate it
> for GCC 4.3 to make it possible to remove it during 4.4 (and not
> block removing libcall notes by it).

Actually not wrapping libcall notes around the libcalls will fix
some bugs with -ftrapv (not that it would work then -- the tree
optimizers break it completely, then expansion, then the
libcall notes and then libgcc itself).  Still, -ftrapv is broken
and we should get rid of it.  But there is probably no hurry to
do so for 4.3, it just would be nice to see it all gone in 4.4 ;)

Richard.

Re: [PATCH][4.3] Deprecate -ftrapv

[Mark Mitchell]

Richard Guenther wrote:
> This is a request to depcrecate -ftrapv which has numerous problems
> making it not work as expected since a long time.  As nobody seems
> to have the energy to ensure it is working I propose to deprecate it
> for GCC 4.3 to make it possible to remove it during 4.4 (and not
> block removing libcall notes by it).

Why doesn't it work?  Can it be made to work relatively easily?  Do we 
need functionality like this for Ada or Java?

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Kenner]

> Why doesn't it work?  Can it be made to work relatively easily?  Do we 
> need functionality like this for Ada or Java?

Ada currently has to do this itself, precisely because -ftrapv doesn't
work, so it's not the case that Ada "needs" it.

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Richard Kenner wrote:
>> Why doesn't it work?  Can it be made to work relatively easily?  Do we 
>> need functionality like this for Ada or Java?
> 
> Ada currently has to do this itself, precisely because -ftrapv doesn't
> work, so it's not the case that Ada "needs" it.

Well no one "needs" anything in this sense, any interfaced is Turing
complete so there is *always* a work around deficiencies in the back 
end. But right now, the "do this itself" is really horribly inefficient:

> procedure k (x : out integer; y,z : integer) is
> begin
>    x := y + z;
> end;

> procedure k (x : out integer; y : integer; z : integer) is
> begin
>    [constraint_error when
>      not (long_long_integer?(y) + long_long_integer?(z) in
>        -16#8000_0000# .. 16#7FFF_FFFF#)
>      "overflow check failed"]
>    x := integer?(long_long_integer?(y) + long_long_integer?(z));
>    return;
> end k;


assembly language (-O2) with -gnato to enable overflow checking

> __ada_k:
> LFB3:
>         pushl   %ebp
> LCFI0:
>         movl    %esp, %ebp
> LCFI1:
>         pushl   %ebx
> LCFI2:
>         subl    $4, %esp
> LCFI3:
>         movl    8(%ebp), %eax
>         movl    12(%ebp), %ecx
>         movl    %eax, %edx
>         movl    %ecx, %ebx
>         sarl    $31, %edx
>         sarl    $31, %ebx
>         addl    %eax, %ecx
>         adcl    %edx, %ebx
>         movl    %ecx, %eax
>         addl    $-2147483648, %eax
>         movl    %ebx, %edx
>         adcl    $0, %edx
>         cmpl    $0, %edx
>         jbe     L6
>         pushl   %eax
>         pushl   %eax
>         pushl   $3
>         pushl   $LC0
> LCFI4:
>         call    ___gnat_rcheck_10
>         .p2align 4,,7
> L6:
>         movl    %ecx, %eax
>         movl    -4(%ebp), %ebx
>         leave
>         ret

pretty gruesome :-(

Re: [PATCH][4.3] Deprecate -ftrapv

[Joseph S. Myers]

On Fri, 29 Feb 2008, Robert Dewar wrote:

> Well no one "needs" anything in this sense, any interfaced is Turing
> complete so there is *always* a work around deficiencies in the back end. But
> right now, the "do this itself" is really horribly inefficient:

You can see the C code in libgcc2.c (__addvSI3 etc.) used by -ftrapv (that 
code depends on signed overflow wrapping as has been noted before, it 
should of course be written with unsigned types).  It does use 
double-width types for multiplication (and some more complicated code for 
multiplication of types that are already double-width).

If it were done at gimplification time I imagine something like the libgcc 
code would be used, but with conversions to/from unsigned inserted as 
needed.  It would be possible to do optimizations at gimplification time 
if one argument is constant (converting to a range check).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Joseph S. Myers wrote:
> On Fri, 29 Feb 2008, Robert Dewar wrote:
> 
>> Well no one "needs" anything in this sense, any interfaced is Turing
>> complete so there is *always* a work around deficiencies in the back end. But
>> right now, the "do this itself" is really horribly inefficient:
> 
> You can see the C code in libgcc2.c (__addvSI3 etc.) used by -ftrapv (that 
> code depends on signed overflow wrapping as has been noted before, it 
> should of course be written with unsigned types).  It does use 
> double-width types for multiplication (and some more complicated code for 
> multiplication of types that are already double-width).
> 
> If it were done at gimplification time I imagine something like the libgcc 
> code would be used, but with conversions to/from unsigned inserted as 
> needed.  It would be possible to do optimizations at gimplification time 
> if one argument is constant (converting to a range check).

Well presumably one would want to use target dependent stuff for
detecting overflow where it exists (sticky overflow bits on
power, O flag on PC, trapping add on MIPS etc).
> 

Re: [PATCH][4.3] Deprecate -ftrapv

[Joseph S. Myers]

On Fri, 29 Feb 2008, Robert Dewar wrote:

> > If it were done at gimplification time I imagine something like the libgcc
> > code would be used, but with conversions to/from unsigned inserted as
> > needed.  It would be possible to do optimizations at gimplification time if
> > one argument is constant (converting to a range check).
> 
> Well presumably one would want to use target dependent stuff for
> detecting overflow where it exists (sticky overflow bits on
> power, O flag on PC, trapping add on MIPS etc).

On the whole I think you'd want to benefit from tree-ssa optimizing 
overflow checks where possible (including optimizing them away with VRP), 
if you hope for a -ftrapv that could be turned on by default for Ada with 
performance impact as small as possible.  That would suggest back ends 
matching overflow-check patterns (including any that might have been 
written manually in the user's code) and converting them into such 
instructions.  (Or expand or a late tree-ssa pass doing so.)  But you 
could choose to use built-in functions corresponding to the present libgcc 
functions to represent overflow-checking operations, rather than expanding 
inline, and you could make the choice of whether to do so 
target-dependent.  (One possibility is also using such builtins at 
gimplification time and then optimizing them later in tree-ssa - for 
example, converting a built-in checked multiplication to a range check if 
other optimizers make one argument into a constant.)

The only targets defining the <operation>v<mode> insn patterns at present 
appear to be alpha and pa.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH][4.3] Deprecate -ftrapv

[Paolo Bonzini]

>> Well presumably one would want to use target dependent stuff for
>> detecting overflow where it exists (sticky overflow bits on
>> power, O flag on PC, trapping add on MIPS etc).
> 
> On the whole I think you'd want to benefit from tree-ssa optimizing 
> overflow checks where possible (including optimizing them away with VRP), 
> if you hope for a -ftrapv that could be turned on by default for Ada with 
> performance impact as small as possible.  That would suggest back ends 
> matching overflow-check patterns and converting them into such
> instructions.

Yes, fully fully agreed.

Paolo

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Kenner]

> > Ada currently has to do this itself, precisely because -ftrapv doesn't
> > work, so it's not the case that Ada "needs" it.
> 
> Well no one "needs" anything in this sense, any interfaced is Turing
> complete so there is *always* a work around deficiencies in the back 
> end. But right now, the "do this itself" is really horribly inefficient:

Clearly.  My point was that Ada doesn't need a *broken* -ftrapv.  So if
there's no hope of fixing it, we might as well deprecate it.

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Richard Kenner wrote:
> Clearly.  My point was that Ada doesn't need a *broken* -ftrapv.  So if
> there's no hope of fixing it, we might as well deprecate it.

Sure, but right now we have the start of a constructive discussion of
how to fix it, so the best thing would be to contribute positively to
that and see where it gets us :-)

No one needs a broken anything, but we have to be careful about
deprecating things just because they are broken! We have to be
really sure that there's no hope of fixing it. In this case, the
feature would be very useful in debugging C (especially given
GCC's aggressive use of the undefinedness of arithmetic overflow
in C, it would definitely be nice to be able to test at -O0 -ftrapv
and have this find overflows).

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Kenner]

> No one needs a broken anything, 

Not necessarily and perhaps not in this case.  Let's suppose there was
an implementation of -ftrapv that did trap, but only about 80% of the
time.  Such an implementation would nevertheless be useful in C since
there overflow is not a required feature of the language, but merely
useful, and you could well argue that it's better to catch 80% of the
overflows than 0%. But for Ada, it's a language requirement that we
catch *all* overflows, so an implementation that was 80% correct there
isn't useful at all since an alternate one is required.

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Richard Kenner wrote:
>> No one needs a broken anything, 
> 
> Not necessarily and perhaps not in this case.  Let's suppose there was
> an implementation of -ftrapv that did trap, but only about 80% of the
> time.  Such an implementation would nevertheless be useful in C since
> there overflow is not a required feature of the language, but merely
> useful, and you could well argue that it's better to catch 80% of the
> overflows than 0%. But for Ada, it's a language requirement that we
> catch *all* overflows, so an implementation that was 80% correct there
> isn't useful at all since an alternate one is required.

Might still be useful as the default behavior if it was significantly
more efficient than the complete mechanism, and if in practice the
intent was to catch the other 20% over time.

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Guenther]

On Fri, 29 Feb 2008, Mark Mitchell wrote:

> Richard Guenther wrote:
> > This is a request to depcrecate -ftrapv which has numerous problems
> > making it not work as expected since a long time.  As nobody seems
> > to have the energy to ensure it is working I propose to deprecate it
> > for GCC 4.3 to make it possible to remove it during 4.4 (and not
> > block removing libcall notes by it).
> 
> Why doesn't it work?  Can it be made to work relatively easily?  Do we need
> functionality like this for Ada or Java?

The tree optimizers do not recognize +-* of singed integers as
possibly trapping which causes functions to become const/pure that
should not and causes 'dead' code to be removed that should not.

We do expand +-* allowing LIBCALL_WIDEN which will for example
use DImode on x86_64 where the libgcc implementation then of course
traps on DImode overflow rather than whatever smaller mode we
were interested in.

We wrap the libcalls inside libcall notes using REG_EQUAL notes
which indicate the libcalls compute non-trapping +-* (there's no
RTX code for the trappingness), so we combine and simplify the
operations making the libcall possibly dead and remove it again.

Just to mention the few problems I stumbled over while looking
at PR19020 some time ago.

Richard.

Re: [PATCH][4.3] Deprecate -ftrapv

[Mark Mitchell]

Richard Guenther wrote:

> The tree optimizers do not recognize +-* of singed integers as
> possibly trapping which causes functions to become const/pure that
> should not and causes 'dead' code to be removed that should not.

Thanks for the explanations.  It seems like tree-ssa should in theory 
make it easier to implement this; for example, at the point of 
gimplification one could insert checks, and then just let everything 
else do its thing.  I don't see how libcalls and such would matter in 
that scheme.  I'm not denying that this is a project, though.

I fully agree that claiming things work when they don't is bad -- we 
don't want to lie to the users!  But, is the failure mode that we issue 
run-time errors when we shouldn't, or that we don't issue run-time 
errors when we should?  The latter is much less severe than the former.

I guess you've withdrawn the deprecation request, so maybe this is 
something of a moot point now?  I certainly agree that we shouldn't let 
a non-working feature stand in the way of improvements in 4.4.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [PATCH][4.3] Deprecate -ftrapv

[Joseph S. Myers]

On Fri, 29 Feb 2008, Mark Mitchell wrote:

> Thanks for the explanations.  It seems like tree-ssa should in theory make it
> easier to implement this; for example, at the point of gimplification one
> could insert checks, and then just let everything else do its thing.  I don't
> see how libcalls and such would matter in that scheme.  I'm not denying that
> this is a project, though.

Obviously you need to keep the functions in libgcc in any event for the 
sake of old object code (just as we keep __eprintf there), even if you 
make GCC generate inline code rather than libcalls or remove the option 
entirely.

You also need to deal with fold, which will optimize away potentially 
trapping computations with -ftrapv and runs before gimplification 
(possibly in association with making fold run at gimplification time and 
not before).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH][4.3] Deprecate -ftrapv

[Mark Mitchell]

Joseph S. Myers wrote:

> You also need to deal with fold, which will optimize away potentially 
> trapping computations with -ftrapv and runs before gimplification 
> (possibly in association with making fold run at gimplification time and 
> not before).

Indeed.  However, errors missed due to fold eliminating them before 
gimplification would be a false negative, so less of a problem.  Since 
this feature is designed to crash your program when it has a bug, 
crashing your program somewhat less often doesn't make the feature 
useless; just less useful.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Guenther]

On Sat, 1 Mar 2008, Joseph S. Myers wrote:

> On Fri, 29 Feb 2008, Mark Mitchell wrote:
> 
> > Thanks for the explanations.  It seems like tree-ssa should in theory make it
> > easier to implement this; for example, at the point of gimplification one
> > could insert checks, and then just let everything else do its thing.  I don't
> > see how libcalls and such would matter in that scheme.  I'm not denying that
> > this is a project, though.
> 
> Obviously you need to keep the functions in libgcc in any event for the 
> sake of old object code (just as we keep __eprintf there), even if you 
> make GCC generate inline code rather than libcalls or remove the option 
> entirely.
> 
> You also need to deal with fold, which will optimize away potentially 
> trapping computations with -ftrapv and runs before gimplification 
> (possibly in association with making fold run at gimplification time and 
> not before).

It should not - at least we have various tests in place to ensure fold
does not remove traps nor insert traps.  Of course this is a very badly
tested part of the compiler, so possibly both may happen.

Richard.

Re: [PATCH][4.3] Deprecate -ftrapv

[Joseph S. Myers]

On Sat, 1 Mar 2008, Richard Guenther wrote:

> > You also need to deal with fold, which will optimize away potentially 
> > trapping computations with -ftrapv and runs before gimplification 
> > (possibly in association with making fold run at gimplification time and 
> > not before).
> 
> It should not - at least we have various tests in place to ensure fold
> does not remove traps nor insert traps.  Of course this is a very badly
> tested part of the compiler, so possibly both may happen.

But arbitrary arithmetic expressions aren't marked as potentially trapping 
/ having side-effects with -ftrapv, so cases such as

int f(int a, int b) { return 0 * (a + b); }

get the potentially trapping arithmetic folded away.  If -ftrapv is to 
have properly defined semantics, those must include trapping if (a + b) 
overflows in the above code.

(If we go with converting trapping arithmetic at gimplification time, we 
could also avoid doing much folding before gimplification with -ftrapv, 
and so maybe avoid needing to treat all arithmetic as having 
side-effects.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Joseph S. Myers wrote:

> But arbitrary arithmetic expressions aren't marked as potentially trapping 
> / having side-effects with -ftrapv, so cases such as
> 
> int f(int a, int b) { return 0 * (a + b); }
> 
> get the potentially trapping arithmetic folded away.  If -ftrapv is to 
> have properly defined semantics, those must include trapping if (a + b) 
> overflows in the above code.

Interestingly enough, Ada semantics allow the overflow in this case. The
rule in Ada is that if an arithmetic operation overflows, it must either
raise an exception or yield the correct value. Now if you say:

    A := B + C;

Then even if you allow an overflowed value for B+C it will be caught
by the normal required range check on the assignment to A, so this rule
is really only relevant for intermediate results. A canonical example
where this rule is likely to be useful is

    A := B * C / D;

where it is fine to do a double length multiply followed by a division
that brings the result back in range, even if B*C is out of range.

Given that there are no predefined semantics requiring exceptions in
C, it would not be terrible to have the same semantics in C if there
are some cases where this is unavoidable (I agree it would be preferable
to avoid these kinds of "optimizations", even in Ada, it's probably
cleaner to catch the intermediate overflow. It's hard to believe the
performance degradation is significant, and if you are really concerned
about this in Ada, you can turn off checks (locally or globally).
> 
> (If we go with converting trapping arithmetic at gimplification time, we 
> could also avoid doing much folding before gimplification with -ftrapv, 
> and so maybe avoid needing to treat all arithmetic as having 
> side-effects.)

Sounds better if it works

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Guenther]

On Sat, 1 Mar 2008, Robert Dewar wrote:

> Joseph S. Myers wrote:
> 
> > But arbitrary arithmetic expressions aren't marked as potentially trapping /
> > having side-effects with -ftrapv, so cases such as
> > 
> > int f(int a, int b) { return 0 * (a + b); }
> > 
> > get the potentially trapping arithmetic folded away.  If -ftrapv is to have
> > properly defined semantics, those must include trapping if (a + b) overflows
> > in the above code.
> 
> Interestingly enough, Ada semantics allow the overflow in this case. The
> rule in Ada is that if an arithmetic operation overflows, it must either
> raise an exception or yield the correct value. Now if you say:
> 
>    A := B + C;
> 
> Then even if you allow an overflowed value for B+C it will be caught
> by the normal required range check on the assignment to A, so this rule
> is really only relevant for intermediate results. A canonical example
> where this rule is likely to be useful is
> 
>    A := B * C / D;
> 
> where it is fine to do a double length multiply followed by a division
> that brings the result back in range, even if B*C is out of range.

IMHO this semantics asks for the frontend to implement the overflow
check.  Does the above mean that Ada does intermediate arithmetics
in wider types?  I don't see how you could catch the B + C case
otherwise (assuming the range check for the assignment to A covers
all of As range of valid values).

Richard.

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Richard Guenther wrote:

> IMHO this semantics asks for the frontend to implement the overflow
> check.  Does the above mean that Ada does intermediate arithmetics
> in wider types?  I don't see how you could catch the B + C case
> otherwise (assuming the range check for the assignment to A covers
> all of As range of valid values).

So here's exactly what happens now in Ada

1. If -gnato is not set (no overflow checking)

In this case, the situation is exactly the same as C, and the front end
ignores the possibility of overflow. The official Ada semantics are that
if you suppress overflow checks, and an overflow occurs (intermediate or
otherwise), the executino is erroneous (undefined in C-speak). So Ada
with checks off is in all respects identical to C semantics. No problem.

2. If -gnato is set (overflow checking on)

In this case, the front end does generate all overflow checks (there
is an example of this earlier in the thread from me, which shows
the original Ada source, the pseudo-Ada expanded source from the
front end, and the final assembly. In this mode, we don't bother
trying to allow cases like (B*C)/D, if the B*C overflows it will
raise an exception.

The approach is to do double length arithmetic and range check
the result, unless we are at 64-bits, in which case we call
library routines that do the arithmetic overflow checking.

Note that in Ada, you can often avoid one or both ends of
the range check, e.g.

     type R is integer range 1 .. 10;

     RV : R;

     R := R + 1;

no need for double length arithmetic here, you just check that the
result is not greater than 10.

Now of course what we would hope for is a back end -ftrapv mode
that at least in some cases on some targets is more efficient,
e.g. in -gnatOs mode at least on the ia32, we would generate
INTO instructions, and on the MIPS trapping adds.
> 
> Richard.

Re: [PATCH][4.3] Deprecate -ftrapv

[Florian Weimer]

* Robert Dewar:

> So here's exactly what happens now in Ada
>
> 1. If -gnato is not set (no overflow checking)
>
> In this case, the situation is exactly the same as C, and the front end
> ignores the possibility of overflow.

It's C in -fwrapv mode, isn't it?  (Otherwise, you can't really get the
other constraint checks to work, including bounds checking for array
access.)

> The official Ada semantics are that if you suppress overflow checks,
> and an overflow occurs (intermediate or otherwise), the executino is
> erroneous (undefined in C-speak). So Ada with checks off is in all
> respects identical to C semantics. No problem.

Uh-oh, this is really, really surprising.

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Florian Weimer wrote:
> * Robert Dewar:
> 
>> So here's exactly what happens now in Ada
>>
>> 1. If -gnato is not set (no overflow checking)
>>
>> In this case, the situation is exactly the same as C, and the front end
>> ignores the possibility of overflow.
> 
> It's C in -fwrapv mode, isn't it?  (Otherwise, you can't really get the
> other constraint checks to work, including bounds checking for array
> access.)

No, it is exactly C, if an arithmetic operation causes overflow
and you do not have -gnato set, and overflow occurs, the program
execution is erroneous. I reread the last para above more than once
but cannot guess what you are getting.
> 
>> The official Ada semantics are that if you suppress overflow checks,
>> and an overflow occurs (intermediate or otherwise), the executino is
>> erroneous (undefined in C-speak). So Ada with checks off is in all
>> respects identical to C semantics. No problem.
> 
> Uh-oh, this is really, really surprising.

Why is it surprising, if you suppress overflow checks you are saying
that overflow does not occur, just as you say this for *any* C program.

I don't understand the surprise or the concern here, can you
elucidate?

If you think your program might have integer overflow, and
you want to check for this, you must use -gnato.

Re: [PATCH][4.3] Deprecate -ftrapv

[Florian Weimer]

* Robert Dewar:

> Florian Weimer wrote:
>> * Robert Dewar:
>>
>>> So here's exactly what happens now in Ada
>>>
>>> 1. If -gnato is not set (no overflow checking)
>>>
>>> In this case, the situation is exactly the same as C, and the front end
>>> ignores the possibility of overflow.
>>
>> It's C in -fwrapv mode, isn't it?  (Otherwise, you can't really get the
>> other constraint checks to work, including bounds checking for array
>> access.)
>
> No, it is exactly C, if an arithmetic operation causes overflow
> and you do not have -gnato set, and overflow occurs, the program
> execution is erroneous. I reread the last para above more than once
> but cannot guess what you are getting.

Are we talking about the Ada semantics or GNAT without -gnato?  In the
latter case, the documentation disagrees with you:

     The reason that we distinguish overflow checking from other kinds
     of range constraint checking is that a failure of an overflow
     check can generate an incorrect value, but cannot cause erroneous
     behavior. This is unlike the situation with a constraint check on
     an array subscript, where failure to perform the check can result
     in random memory description, or the range check on a case
     statement, where failure to perform the check can cause a wild
     jump.

And to avoid erroneous execution on integer overflow, I think you have
to specify the equivalent -fwrapv (otherwise, the middle end might do
nasty things to your range checks).

> Why is it surprising, if you suppress overflow checks you are saying
> that overflow does not occur, just as you say this for *any* C
> program.
>
> I don't understand the surprise or the concern here, can you
> elucidate?

The documentation says something else, that's why it's surprising. 8-)

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Florian Weimer wrote:

> Are we talking about the Ada semantics or GNAT without -gnato?  In the
> latter case, the documentation disagrees with you:
> 
>      The reason that we distinguish overflow checking from other kinds
>      of range constraint checking is that a failure of an overflow
>      check can generate an incorrect value, but cannot cause erroneous
>      behavior. This is unlike the situation with a constraint check on
>      an array subscript, where failure to perform the check can result
>      in random memory description, or the range check on a case
>      statement, where failure to perform the check can cause a wild
>      jump.
> 
> And to avoid erroneous execution on integer overflow, I think you have
> to specify the equivalent -fwrapv (otherwise, the middle end might do
> nasty things to your range checks).

The documentation needs minor adjustment, I will remove the word
erroneous, and rephrase it as:

> The reason that we distinguish overflow checking from other kinds of
> constraint checking is that a failure of an overflow check, unlike
> for example the failure of a range check, can result in an incorrect
> value, but cannot cause random memory destruction (like an out of range
> subscript), or a wild jump (from an out of range case value). Overflow
> checking is also quite expensive in time and space, since in general it
> requires the use of double length arithmetic.

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Robert Dewar wrote:

>> The reason that we distinguish overflow checking from other kinds of
>> constraint checking is that a failure of an overflow check, unlike
>> for example the failure of a range check, can result in an incorrect
>> value, but cannot cause random memory destruction (like an out of range
>> subscript), or a wild jump (from an out of range case value). Overflow
>> checking is also quite expensive in time and space, since in general it
>> requires the use of double length arithmetic.

Just to be clear, although theoretically in Ada semantics, the program
execution is erroneous if an overflow check fails and -gnato is off, but
in practice with GNAT, the range of possible effects does not include
memory destruction or wild jumps. Similarly with GCC and C, the failure
of an overflow check is theoretically undefined and unlimited (just like
erroneous in Ada), but in practice the back end will not turn an 
overflow into unexpected memory destruction or a wild jump, at least
not often :-)

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Kenner]

> IMHO this semantics asks for the frontend to implement the overflow
> check.  Does the above mean that Ada does intermediate arithmetics
> in wider types? 

No, it means that it must *either* do the arithmetic in wider types *or*
use arithmetic in the narrower types that checks for overflow.

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Guenther]

On Sat, 1 Mar 2008, Joseph S. Myers wrote:

> On Sat, 1 Mar 2008, Richard Guenther wrote:
> 
> > > You also need to deal with fold, which will optimize away potentially 
> > > trapping computations with -ftrapv and runs before gimplification 
> > > (possibly in association with making fold run at gimplification time and 
> > > not before).
> > 
> > It should not - at least we have various tests in place to ensure fold
> > does not remove traps nor insert traps.  Of course this is a very badly
> > tested part of the compiler, so possibly both may happen.
> 
> But arbitrary arithmetic expressions aren't marked as potentially trapping 
> / having side-effects with -ftrapv, so cases such as
> 
> int f(int a, int b) { return 0 * (a + b); }
> 
> get the potentially trapping arithmetic folded away.  If -ftrapv is to 
> have properly defined semantics, those must include trapping if (a + b) 
> overflows in the above code.

Sure, the only clean way to do this is to introduce new tree codes for
trapping arithmetic.  Then the usual mechanisms of omit_one_operand
and friends like tree_could_trap_p can work.  VRP can for example then
optimize trapping codes to non-trapping codes.

Richard.

Re: [PATCH][4.3] Deprecate -ftrapv

[Joseph S. Myers]

On Sat, 1 Mar 2008, Richard Guenther wrote:

> > But arbitrary arithmetic expressions aren't marked as potentially trapping 
> > / having side-effects with -ftrapv, so cases such as
> > 
> > int f(int a, int b) { return 0 * (a + b); }
> > 
> > get the potentially trapping arithmetic folded away.  If -ftrapv is to 
> > have properly defined semantics, those must include trapping if (a + b) 
> > overflows in the above code.
> 
> Sure, the only clean way to do this is to introduce new tree codes for
> trapping arithmetic.  Then the usual mechanisms of omit_one_operand
> and friends like tree_could_trap_p can work.  VRP can for example then
> optimize trapping codes to non-trapping codes.

Yes, new tree codes (or flags on existing ones) to distinguish trapping / 
wrapping / undefined arithmetic are a clean approach.  Then -ftrapv and 
-fwrapv would be used only when front ends build trees, and not 
subsequently to affect the semantics of given GIMPLE trees.  It might be 
useful for optimizers to understand two expressions being equivalent in 
one direction only (if you have an overflow-undefined version of an 
expression, and an overflow-wrapping or overflow-trapping version, you can 
just evaluate the latter version and use the result for the 
overflow-undefined version, but not vice versa).

Depending on the target (whether it has instruction patterns for these 
operations), and on other flags such as -Os, and on the particular types 
involved, the trapping codes might then get converted to wrapping codes 
plus inline checks at some point through tree-ssa (especially if one 
argument is a constant), or might make it all the way to expand.  If given 
bit-field types, Ada types with special ranges, etc. (types not having the 
full range of their mode, or checked arithmetic on char or short where we 
don't provide libgcc functions because such arithmetic won't arise in C 
because of promotions), inline checks would definitely be needed since 
there wouldn't be suitable libgcc functions.  (The inline checks for 
special cases could simply be: do the checked arithmetic in the full width 
of the mode where there is a libgcc function, then add inline range checks 
on the result for the exact range desired.)

So far, the LTO work has concentrated on proving the concept by allowing 
real programs such as GCC and SPEC (but in a single language and built 
with a single set of options) to be built and linked using the LTO 
infrastructure.  (In the earlier days there was also all the work on 
reducing memory usage; unfortunately most of the miscellaneous tree 
trimming changes from that are still languishing on the oldlto branch 
without having been merged to trunk, despite many having been preapproved 
to go on trunk after 4.3 branched.)  To complete LTO it will be necessary 
to change all implicit GIMPLE semantics (in global variables or langhooks) 
into explicit semantics directly encoded in the GIMPLE - including 
flag_trapv and flag_wrapv among many others, but I don't know when that 
part of the LTO work might happen.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Kenner]

> int f(int a, int b) { return 0 * (a + b); }
> 
> get the potentially trapping arithmetic folded away.  If -ftrapv is to 
> have properly defined semantics, those must include trapping if (a + b) 
> overflows in the above code.

Why?  Is there any language that requires such semantics?

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Guenther]

On Sat, 1 Mar 2008, Richard Kenner wrote:

> > int f(int a, int b) { return 0 * (a + b); }
> > 
> > get the potentially trapping arithmetic folded away.  If -ftrapv is to 
> > have properly defined semantics, those must include trapping if (a + b) 
> > overflows in the above code.
> 
> Why?  Is there any language that requires such semantics?

Not exactly.  -ftrapv semantics are defined _very_ sparsely.

"This option generates traps for signed overflow on addition,
subtraction and multiplication operations."

it doesn't say if it preserves traps on dead code, so Josephs
interpretation is one possible valid one.

Richard.

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Richard Guenther wrote:
> On Sat, 1 Mar 2008, Richard Kenner wrote:
> 
>>> int f(int a, int b) { return 0 * (a + b); }
>>>
>>> get the potentially trapping arithmetic folded away.  If -ftrapv is to 
>>> have properly defined semantics, those must include trapping if (a + b) 
>>> overflows in the above code.
>> Why?  Is there any language that requires such semantics?
> 
> Not exactly.  -ftrapv semantics are defined _very_ sparsely.
> 
> "This option generates traps for signed overflow on addition,
> subtraction and multiplication operations."
> 
> it doesn't say if it preserves traps on dead code, so Josephs
> interpretation is one possible valid one.

And anyway, no point in doing energetic exergesis on vague language
defining an option that has never worked anyway :-)

Part of "fixing" -ftrapv should be to carefully document exactly
what it does/is-intended-to-do (hopefully those are the same :-))
> 
> Richard.

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Richard Kenner wrote:
>> int f(int a, int b) { return 0 * (a + b); }
>>
>> get the potentially trapping arithmetic folded away.  If -ftrapv is to 
>> have properly defined semantics, those must include trapping if (a + b) 
>> overflows in the above code.
> 
> Why?  Is there any language that requires such semantics?

For C, the above fragment of code is undefined if a+b overflows. Since
the purpose of -ftrapv for C, it is desirable that it catch this case
as well, since gcc might otherwise do peculiar things, or on some other
compiler you might get other peculiar things or a trap etc.

Obviously the C language does not require this, since it does not
require -ftrapv in the first place, that's just a handy addition
that we make to gcc, and we get to decide what's most useful.

For Ada, as I discussed in my last note, max performance says
you can ignore the check here, but generally for max performance
you turn off checks anyway. It is certainly allowed to optimize
this to zero ..

in fact there are two rules that let you optimize the above to
zero in Ada.

1. The rule about correct results for intermediate computations
being OK even if they are out of range.

2. The rule about not doing operations whose only purpose is
to see if they raise a predfined exception.

Certainly it is acceptable to do the check in the Ada case,
and if you are concerned about writing maximally portable
Ada code, desirable.

Re: [PATCH][4.3] Deprecate -ftrapv

[Paolo Bonzini]

Richard Kenner wrote:
>> int f(int a, int b) { return 0 * (a + b); }
>>
>> get the potentially trapping arithmetic folded away.  If -ftrapv is to 
>> have properly defined semantics, those must include trapping if (a + b) 
>> overflows in the above code.
> 
> Why?  Is there any language that requires such semantics?

Not C, since trapping overflow is just one facet of "undefined behavior" 
and we can define that facet as we wish! :-)

Paolo

Re: [PATCH][4.3] Deprecate -ftrapv

[Joseph S. Myers]

On Sat, 1 Mar 2008, Richard Kenner wrote:

> > int f(int a, int b) { return 0 * (a + b); }
> > 
> > get the potentially trapping arithmetic folded away.  If -ftrapv is to 
> > have properly defined semantics, those must include trapping if (a + b) 
> > overflows in the above code.
> 
> Why?  Is there any language that requires such semantics?

They are the natural interpretation of -ftrapv that's simplest to describe 
in terms of the abstract machine of the C standard: any signed integer 
arithmetic overflow in the abstract machine (and maybe integer division by 
0, signed or unsigned) should be guaranteed to yield a trap at runtime.

http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02026.html
http://gcc.gnu.org/ml/gcc/2007-09/msg00399.html

describe my understanding of these natural semantics.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH][4.3] Deprecate -ftrapv

[Mark Mitchell]

Joseph S. Myers wrote:

>>> int f(int a, int b) { return 0 * (a + b); }

> They are the natural interpretation of -ftrapv that's simplest to describe 
> in terms of the abstract machine of the C standard: any signed integer 
> arithmetic overflow in the abstract machine (and maybe integer division by 
> 0, signed or unsigned) should be guaranteed to yield a trap at runtime.

I agree with everything you've written, including, in particular, that 
making this explicit in the IL (via special tree codes for, e.g., 
trapping-add) would be best.

However, I don't think doing all of that work is required to make this 
feature useful to people.  You seem to be focusing on making -ftrapv 
capture 100% of overflows, so that people could depend on their programs 
crashing if they had an overflow.  That might be useful in two 
circumstances: (a) getting bugs out (though for an example like the one 
above, I can well imagine many people not considering that a bug worth 
fixing), and (b) in safety-critical situations where it's better to die 
than do the wrong thing.

But, I think that (a) has been the most common use of -ftrapv, and for 
bug-detection, it's not vital that we get 100% of the overflows. 
Detecting some/most bugs is a lot better than nothing!

If you set the bar for the feature too high, we may end up not having 
-ftrapv at all -- because nobody gets around to implementing it -- 
rather than having an -ftrapv that catches some, but not all overflow 
errors.  And that seems unfortunate.

I think there's a staged implementation plan here that delivers value 
early, but still allows us to gradually progress towards the ideal state 
over time.  In particular:

1. Move the checks from expand to GIMPLE, turning them into explicit 
checks in the IL, or into calls to library functions (but not necessary 
libcalls per se).  This might be more expensive at run-time than the old 
implementation, but no worse than what the Ada front-end is already doing.

2. Introduce new tree codes and change the GIMPLE code to only insert 
the checks for operations using those codes -- but after gimplification 
these tree codes are no longer used.

3. Plumb the new operations through the TREE-SSA optimizers, add support 
for generating the checks during expand for those trapping operations 
that make it to that point, and disable the insertion of checking at 
GIMPLE-time.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Guenther]

On Sun, 2 Mar 2008, Mark Mitchell wrote:

> Joseph S. Myers wrote:
> 
> > > > int f(int a, int b) { return 0 * (a + b); }
> 
> > They are the natural interpretation of -ftrapv that's simplest to describe
> > in terms of the abstract machine of the C standard: any signed integer
> > arithmetic overflow in the abstract machine (and maybe integer division by
> > 0, signed or unsigned) should be guaranteed to yield a trap at runtime.
> 
> I agree with everything you've written, including, in particular, that making
> this explicit in the IL (via special tree codes for, e.g., trapping-add) would
> be best.
> 
> However, I don't think doing all of that work is required to make this feature
> useful to people.  You seem to be focusing on making -ftrapv capture 100% of
> overflows, so that people could depend on their programs crashing if they had
> an overflow.  That might be useful in two circumstances: (a) getting bugs out
> (though for an example like the one above, I can well imagine many people not
> considering that a bug worth fixing), and (b) in safety-critical situations
> where it's better to die than do the wrong thing.
> 
> But, I think that (a) has been the most common use of -ftrapv, and for
> bug-detection, it's not vital that we get 100% of the overflows. Detecting
> some/most bugs is a lot better than nothing!
> 
> If you set the bar for the feature too high, we may end up not having -ftrapv
> at all -- because nobody gets around to implementing it -- rather than having
> an -ftrapv that catches some, but not all overflow errors.  And that seems
> unfortunate.
> 
> I think there's a staged implementation plan here that delivers value early,
> but still allows us to gradually progress towards the ideal state over time.
> In particular:
> 
> 1. Move the checks from expand to GIMPLE, turning them into explicit checks in
> the IL, or into calls to library functions (but not necessary libcalls per
> se).  This might be more expensive at run-time than the old implementation,
> but no worse than what the Ada front-end is already doing.
> 
> 2. Introduce new tree codes and change the GIMPLE code to only insert the
> checks for operations using those codes -- but after gimplification these tree
> codes are no longer used.
> 
> 3. Plumb the new operations through the TREE-SSA optimizers, add support for
> generating the checks during expand for those trapping operations that make it
> to that point, and disable the insertion of checking at GIMPLE-time.

Nice plan.  Though I doubt that even this simple one will be carried out,
as even the simple bugs in the current implementation stay around for at
least 5 years.

Even I think that there are more useful things to spend time on than
making -ftrapv work.  Especially fixing its counter-part, -fwrapv, thus
the encoding of integer overflow in our IL, should be tackled with
higher priority.  With the same solutions basically - add variants of
the tree codes to note "may overflow".

I believe at last years summit Ian told me that someone at google was
working on this -- Ian is this still true?

Thanks,
Richard.

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Richard Guenther wrote:

> Nice plan.  Though I doubt that even this simple one will be carried out,
> as even the simple bugs in the current implementation stay around for at
> least 5 years.

Well let's see .. we (AdaCore) will try to focus more attention on this
to evaluate whether it is feasible to get this feature working well
enough to use in GNAT.

Re: [PATCH][4.3] Deprecate -ftrapv

[Eric Botcazou]

> Well let's see .. we (AdaCore) will try to focus more attention on this
> to evaluate whether it is feasible to get this feature working well
> enough to use in GNAT.

We already did that several times: -ftrapv is too broken to be used for Ada.

-- 
Eric Botcazou

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Eric Botcazou wrote:
>> Well let's see .. we (AdaCore) will try to focus more attention on this
>> to evaluate whether it is feasible to get this feature working well
>> enough to use in GNAT.
> 
> We already did that several times: -ftrapv is too broken to be used for Ada.

In its current form, that's true, the question is what would it take for
-ftrapv to be usable. The requirements for a useful feature for C
debugging and a feature to implement required overflow checking in
Ada are not that far apart.

Re: [PATCH][4.3] Deprecate -ftrapv

[Ian Lance Taylor]

Richard Guenther <rguenther@suse.de> writes:

> I believe at last years summit Ian told me that someone at google was
> working on this -- Ian is this still true?

Unfortunately that person moved on to other projects.

Ian

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Mark Mitchell wrote:

> However, I don't think doing all of that work is required to make this 
> feature useful to people.  You seem to be focusing on making -ftrapv 
> capture 100% of overflows, so that people could depend on their programs 
> crashing if they had an overflow.  That might be useful in two 
> circumstances: (a) getting bugs out (though for an example like the one 
> above, I can well imagine many people not considering that a bug worth 
> fixing), and (b) in safety-critical situations where it's better to die 
> than do the wrong thing.

I don't agree with this list, first it misses

(c) be useful for Ada conformance, where 100% of cases must be caught

Second, generally speaking in safety-critical systems, you don't want
overflow checking, because

a) it would generate deactivated code intefering with certification

b) in sc code, you have to make sure a priori that there are no
overflows (see http://www.praxis-cs.com/pdfs/Industrial_strength.pdf
for one approach).

c) exceptions can be safety hazards if you don't carefully consider
what to do with them (think about Ariane 5).

So for me, the two uses of -ftrapv are debugging in languages
like C and Fortran, and for debugging and language conformance
in languages like Ada.

Certainly for the debugging use, a solution that is not 100%
is still useful.

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Kenner]

> I agree with everything you've written, including, in particular, that 
> making this explicit in the IL (via special tree codes for, e.g., 
> trapping-add) would be best.

I'd be in favor of flags rather than new codes.  For the most part, all
processing of non-trapping operations and trapping operations are the
same and we already have predicates for when operations trap that we
can use to tell the difference.  I think that flag aproach would be
far less work because adding new operations to all the various switch
statements is a lot of work.

> However, I don't think doing all of that work is required to make this 
> feature useful to people.  You seem to be focusing on making -ftrapv 
> capture 100% of overflows, so that people could depend on their programs 
> crashing if they had an overflow.  That might be useful in two 
> circumstances: (a) getting bugs out (though for an example like the one 
> above, I can well imagine many people not considering that a bug worth 
> fixing), and (b) in safety-critical situations where it's better to die 
> than do the wrong thing.

You forgot the third: if Ada is to use it rather than its own
approach, it must indeed be 100% reliable.  Robert is correct that if
it's sufficiently more efficient than Ada's approach, it can be made
the default, so that by default range-checking is on in Ada, but not
in a 100% reliable fashion.  This means there's be three states:
explicitly enabled, using Ada's mechanism, suppressed, using neither,
or the default, using GCC's.  But if GCC's mechanism also did things
like called functions that did special arithmetic, there'd be no point
in Ada using this.

Re: [PATCH][4.3] Deprecate -ftrapv

[Frank Ch. Eigler]

Mark Mitchell <mark@codesourcery.com> writes:

> [...]  You seem to be focusing on making -ftrapv capture 100% of
> overflows, so that people could depend on their programs crashing if
> they had an overflow.  That might be useful in two circumstances:
> (a) getting bugs out (though for an example like the one above, I
> can well imagine many people not considering that a bug worth
> fixing), and (b) in safety-critical situations where it's better to
> die than do the wrong thing.

Are you including in "safety-critical" all the security-related
software, where signed-overflow is a popular exploit?  If so, you are
undervaluing the "better to die than do the wrong thing" principle.
(This has come up several times here in the past, but not recently
AFAICT.)

- FChE

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Frank Ch. Eigler wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> 
>> [...]  You seem to be focusing on making -ftrapv capture 100% of
>> overflows, so that people could depend on their programs crashing if
>> they had an overflow.  That might be useful in two circumstances:
>> (a) getting bugs out (though for an example like the one above, I
>> can well imagine many people not considering that a bug worth
>> fixing), and (b) in safety-critical situations where it's better to
>> die than do the wrong thing.
> 
> Are you including in "safety-critical" all the security-related
> software, where signed-overflow is a popular exploit?  If so, you are
> undervaluing the "better to die than do the wrong thing" principle.
> (This has come up several times here in the past, but not recently
> AFAICT.)

Safety-critical and security-critical software are two totally different
concepts. Be careful not to confuse them. In safety-critical software,
e.g. avionics system, it is not acceptable for the system to crash.
In this context, the metaphorical "better to die", becomes all too real!

For security-critical software that is not safety-critical, e.g. a
banking terminal, it is indeed better to crash than to compromise
security.

However, in practice, it is hard to imagine a security-critical
piece of software that would not take equal care to avoid any
possibility of exceptional conditions at run time.

For general security issues, especially with type unsafe
languages, anything you can do at run-time to increase
type safety certainly helps. However, I would suspect that
-ftrapv is likely to be viewed and used only as a debugging
aid in C, rather than something you routinely deploy in
delivered software to improve security.
> 
> - FChE

Re: [PATCH][4.3] Deprecate -ftrapv

[Frank Ch. Eigler]

Hi -

On Sun, Mar 02, 2008 at 09:30:25AM -0500, Robert Dewar wrote:

> [...]  Safety-critical and security-critical software are two
> totally different concepts. Be careful not to confuse them. In
> safety-critical software, e.g. avionics system, it is not acceptable
> for the system to crash.  In this context, the metaphorical "better
> to die", becomes all too real!

(Off topic, but I'd expect that avionics software is engineered with
enough layers of protection, including catching traps, so that a
-ftrapv hit would not cause a deep impact.)


> [...] However, in practice, it is hard to imagine a
> security-critical piece of software that would not take equal care
> to avoid any possibility of exceptional conditions at run time.

Maybe, but we just don't live in that world.

> For general security issues, especially with type unsafe languages,
> anything you can do at run-time to increase type safety certainly
> helps. 

Right, but gcc's approach is unsympathetic.  With -fstrict-overflow
becoming default in the usual "-O2 -g" builds, latent signed-overflow
bugs might become even harder to find.  It's as if GCC is sending the
a message like "Security is your problem - we favour 100% Pure C
Code.".

> However, I would suspect that -ftrapv is likely to be viewed and
> used only as a debugging aid in C, rather than something you
> routinely deploy in delivered software to improve security.

I guess it depends on how robust (=> predictable to experts) the
mechanism becomes.  The glibc fortify widget (enabled by some robust
gcc extensions) has found lots of use.

- FChE

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Frank Ch. Eigler wrote:
> Hi -
> 
> On Sun, Mar 02, 2008 at 09:30:25AM -0500, Robert Dewar wrote:
> 
>> [...]  Safety-critical and security-critical software are two
>> totally different concepts. Be careful not to confuse them. In
>> safety-critical software, e.g. avionics system, it is not acceptable
>> for the system to crash.  In this context, the metaphorical "better
>> to die", becomes all too real!
> 
> (Off topic, but I'd expect that avionics software is engineered with
> enough layers of protection, including catching traps, so that a
> -ftrapv hit would not cause a deep impact.)

As I say, it is more usual in avionics software to rely on proving
or demonstrating during the certification process that the code
is correct. DER's do not look too kindly on code that says
"if something is wrong do bla", they want to be convinced
that nothing can go wrong.

And don't be sure about impact, as I mentioned the Ariane-5
disaster was caused by a run time exception not handled
properly, the rocket would have been fine if there had
been no overflow test in place. Non-critical wrong answers
are better than having to blow up the rocket some times :-)

>> [...] However, in practice, it is hard to imagine a
>> security-critical piece of software that would not take equal care
>> to avoid any possibility of exceptional conditions at run time.
> 
> Maybe, but we just don't live in that world. 

I am not sure who "we" is here, those of us who live in the
DO-178B and MILS worlds definitely do take that kind of care.

>> However, I would suspect that -ftrapv is likely to be viewed and
>> used only as a debugging aid in C, rather than something you
>> routinely deploy in delivered software to improve security.
> 
> I guess it depends on how robust (=> predictable to experts) the
> mechanism becomes.  The glibc fortify widget (enabled by some robust
> gcc extensions) has found lots of use.

Again, the issue is whether such things are for finding bugs during
development, or defending against bugs that make it through the
entire development process. Even in the Ada world, it is normal
to turn off exceptions in safety-critical code for the final
delivered software that runs on planes.
> 
> - FChE

Re: [PATCH][4.3] Deprecate -ftrapv

[Frank Ch. Eigler]

Hi -

On Sun, Mar 02, 2008 at 10:20:30AM -0500, Robert Dewar wrote:
> [...]
> >(Off topic, but I'd expect that avionics software is engineered with
> >enough layers of protection, including catching traps, so that a
> >-ftrapv hit would not cause a deep impact.)
> 
> As I say, it is more usual in avionics software to rely on proving
> or demonstrating during the certification process that the code
> is correct. [... and exception trapping is sometimes disabled on
> deployed code ...]

Wow.  This gives one the impression of eschewing of defense in depth,
but I suppose the overall record (positive and negative) speaks for
itself.


> >>[...] However, in practice, it is hard to imagine a
> >>security-critical piece of software that would not take equal care
> >>to avoid any possibility of exceptional conditions at run time.
> >
> >Maybe, but we just don't live in that world. 
> 
> I am not sure who "we" is here, those of us who live in the
> DO-178B and MILS worlds definitely do take that kind of care.

If you're saying that security-related software written by people
working in DO-178B workflows tends to be as well cared-for as
saftery-related software, OK.  But most security-related software we
normal folks use is not written by such people / processes.


> [...]  Again, the issue is whether such things are for finding bugs
> during development, or defending against bugs that make it through
> the entire development process.

Those decisions may be made by separate people or even organizations.
An OS distributor can decide to use different compiler flags than the
code author - whether that be for extra trustworthiness, speed,
portability, compatibility.  Ideally, protective measures should be
usable for either subject.


> Even in the Ada world, it is normal to turn off exceptions in
> safety-critical code for the final delivered software that runs on
> planes.

(Drifting farther off topic onto my personal curiosity: are exception
handling paths just not considered powerful & robust enough to design
in and rely on?  Do these machines have e.g. watchdog timers?  Run -O2
vs. -O0 code?)


- FChE

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Frank Ch. Eigler wrote:
> Hi -
> 
> On Sun, Mar 02, 2008 at 10:20:30AM -0500, Robert Dewar wrote:
>> [...]
>>> (Off topic, but I'd expect that avionics software is engineered with
>>> enough layers of protection, including catching traps, so that a
>>> -ftrapv hit would not cause a deep impact.)
>> As I say, it is more usual in avionics software to rely on proving
>> or demonstrating during the certification process that the code
>> is correct. [... and exception trapping is sometimes disabled on
>> deployed code ...]
> 
> Wow.  This gives one the impression of eschewing of defense in depth,
> but I suppose the overall record (positive and negative) speaks for
> itself.

That's right, defense in depth is a concept that comes from dealing
with code that you assume might fail. Safety-critical avionics code
is code that you assume will never fail.

There has been at least one incident of a software bug in certified
code, but it is very rare, and the record is impressive (no life
has been lost because of a software bug in the history of commercial
aviation). And that's using an informal standard (DO-178B) and we
think we can do much better than this (e.g. in the MILS contexts,
where higher EAL levels require formal verification techniques to
be used, DO-178B has no such requirement).

> If you're saying that security-related software written by people
> working in DO-178B workflows tends to be as well cared-for as
> saftery-related software, OK.  But most security-related software we
> normal folks use is not written by such people / processes.

Right, and security-related (a nice term, which distinguishes itself
from security-critical) software can certainly benefit from defense
in depth. Even formally proved security-critical software can
benefit, because corrupting code or data by physical intrusion may
still be limited in effect because of such defenses
> 
> 
>> [...]  Again, the issue is whether such things are for finding bugs
>> during development, or defending against bugs that make it through
>> the entire development process.
> 
> Those decisions may be made by separate people or even organizations.
> An OS distributor can decide to use different compiler flags than the
> code author - whether that be for extra trustworthiness, speed,
> portability, compatibility.  Ideally, protective measures should be
> usable for either subject.

Yes indeed ...
> 
> 
>> Even in the Ada world, it is normal to turn off exceptions in
>> safety-critical code for the final delivered software that runs on
>> planes.
> 
> (Drifting farther off topic onto my personal curiosity: are exception
> handling paths just not considered powerful & robust enough to design
> in and rely on?  Do these machines have e.g. watchdog timers?  Run -O2
> vs. -O0 code?)

Usually you avoid -O2 in these contexts, too hard to establish the
required source-to-object traceability. We most typially use -O1 with a
couple of optimizations suppressed (e.g. if-conversion).

It is not that exception handling paths are not powerful or robust.

It is that

a) they should not be needed if the code is correct

b) they create a testing hazard, you can't have untested code
in an SC system, so you have to test the exception case, which
is tricky if in fact it is not possible for the exception to
occur. So you have to prove in any casea that the exception
can't occur to justify not testing it, and if you can convince
the certification authorities that testing is not required,
you have convinced them that the exception cannot happen,
so why leave in the code.

There are those who prefer to leave checks on in safety-critical
delivered code, the argument rages strongly on both sides :-)

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

> (Off topic, but I'd expect that avionics software is engineered with
> enough layers of protection, including catching traps, so that a
> -ftrapv hit would not cause a deep impact.)

Actually this discussion is not *so* off-topic.

if you regard -ftrapv as something that would be enabled in critical
code in the final production build, you have a much different view,
than if it is a debugging aid, which can help to find bugs, but makes
no guarantees.

Re: [PATCH][4.3] Deprecate -ftrapv

[Florian Weimer]

* Richard Kenner:

>> int f(int a, int b) { return 0 * (a + b); }
>> 
>> get the potentially trapping arithmetic folded away.  If -ftrapv is to 
>> have properly defined semantics, those must include trapping if (a + b) 
>> overflows in the above code.
>
> Why?  Is there any language that requires such semantics?

Standard ML.  I don't think there is a GCC front end (and it's not
likely that one will be feasible, at least until GCC supports a fitting
garbage collector).

Re: [PATCH][4.3] Deprecate -ftrapv

[Florian Weimer]

* Florian Weimer:

> * Richard Kenner:
>
>>> int f(int a, int b) { return 0 * (a + b); }
>>> 
>>> get the potentially trapping arithmetic folded away.  If -ftrapv is to 
>>> have properly defined semantics, those must include trapping if (a + b) 
>>> overflows in the above code.
>>
>> Why?  Is there any language that requires such semantics?
>
> Standard ML.  I don't think there is a GCC front end (and it's not
> likely that one will be feasible, at least until GCC supports a fitting
> garbage collector).

Oh, and a less obscure example is C# (Section 14.5.13 in ECMA-334, 4th
edition, June 2006).

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Florian Weimer wrote:
> * Richard Kenner:
> 
>>> int f(int a, int b) { return 0 * (a + b); }
>>>
>>> get the potentially trapping arithmetic folded away.  If -ftrapv is to 
>>> have properly defined semantics, those must include trapping if (a + b) 
>>> overflows in the above code.
>> Why?  Is there any language that requires such semantics?
> 
> Standard ML.  I don't think there is a GCC front end (and it's not
> likely that one will be feasible, at least until GCC supports a fitting
> garbage collector).

Why is it a GCC issue to support a GC for ML, I don't get it ...

Re: [PATCH][4.3] Deprecate -ftrapv

[Florian Weimer]

* Robert Dewar:

>> Standard ML.  I don't think there is a GCC front end (and it's not
>> likely that one will be feasible, at least until GCC supports a fitting
>> garbage collector).
>
> Why is it a GCC issue to support a GC for ML, I don't get it ...

ML programs are mostly functional and allocate lots of small objects
with very short lifespans.  Without GC support in GCC, you're basically
stuck with some sort of conservative collector.  And that is unlikely to
result in acceptable throughput.

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Florian Weimer wrote:
> * Robert Dewar:
> 
>>> Standard ML.  I don't think there is a GCC front end (and it's not
>>> likely that one will be feasible, at least until GCC supports a fitting
>>> garbage collector).
>> Why is it a GCC issue to support a GC for ML, I don't get it ...
> 
> ML programs are mostly functional and allocate lots of small objects
> with very short lifespans.  Without GC support in GCC, you're basically
> stuck with some sort of conservative collector.  And that is unlikely to
> result in acceptable throughput.

Not clear what "in GCC" means here, seems to me you could perfectly
well handle this with a combination of front end stuff and run time
routines.

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Guenther]

On Fri, 29 Feb 2008, Mark Mitchell wrote:

> Richard Guenther wrote:
> 
> > The tree optimizers do not recognize +-* of singed integers as
> > possibly trapping which causes functions to become const/pure that
> > should not and causes 'dead' code to be removed that should not.
> 
> Thanks for the explanations.  It seems like tree-ssa should in theory make it
> easier to implement this; for example, at the point of gimplification one
> could insert checks, and then just let everything else do its thing.  I don't
> see how libcalls and such would matter in that scheme.  I'm not denying that
> this is a project, though.

I missed once point noticed by Joseph also, that the libgcc implementation
uses signed types in the implementation of the trapping arithmetics.
Where we of course optimize away the overflow check, so the libgcc
routines will never trap.  (if it does work in some cases then this
would be a missed optimization, so sooner or later it is going to
break more)

I agree that all the problems can be fixed, but it's been several years
that they didn't get fixed and we still advertise that feature as working.

> I fully agree that claiming things work when they don't is bad -- we don't
> want to lie to the users!  But, is the failure mode that we issue run-time
> errors when we shouldn't, or that we don't issue run-time errors when we
> should?  The latter is much less severe than the former.

I believe it's both, as some optimizations still can introduce signed
overflow, especially in the view of our interesting middle-end sizetype
semantics.

> I guess you've withdrawn the deprecation request, so maybe this is something
> of a moot point now?  I certainly agree that we shouldn't let a non-working
> feature stand in the way of improvements in 4.4.

Yes, removing the libcall notes around these calls will actually improve
"workiness" of -ftrapv, so removing libcall notes will not make the
situation worse here.

Richard.

Re: [PATCH][4.3] Deprecate -ftrapv

[Paolo Bonzini]

> I missed once point noticed by Joseph also, that the libgcc implementation
> uses signed types in the implementation of the trapping arithmetics.
> Where we of course optimize away the overflow check, so the libgcc
> routines will never trap.  (if it does work in some cases then this
> would be a missed optimization, so sooner or later it is going to
> break more)

In theory, if -ftrapv worked properly and at the compiler level (no 
libcalls), the implementation of __addvsi3 could be just

   return a + b;

compiled with -ftrapv itself...

Paolo

Re: [PATCH][4.3] Deprecate -ftrapv

[Joseph S. Myers]

On Sat, 1 Mar 2008, Richard Guenther wrote:

> I missed once point noticed by Joseph also, that the libgcc implementation
> uses signed types in the implementation of the trapping arithmetics.
> Where we of course optimize away the overflow check, so the libgcc
> routines will never trap.  (if it does work in some cases then this
> would be a missed optimization, so sooner or later it is going to
> break more)

This is of course trivial to fix.  OK to commit the following patch?  
Bootstrapped with no regressions on i686-pc-linux-gnu.

2008-03-02  Joseph Myers  <joseph@codesourcery.com>

	* libgcc2.c (__addvSI3, __addvsi3, __addvDI3, __subvSI3,
	__subvsi3, __subvDI3, __negvSI2, __negvsi2, __negvDI2, __absvSI2,
	__absvsi2, __absvDI2): Use unsigned arithmetic.

Index: libgcc2.c
===================================================================
--- libgcc2.c	(revision 132803)
+++ libgcc2.c	(working copy)
@@ -84,7 +84,7 @@
 Wtype
 __addvSI3 (Wtype a, Wtype b)
 {
-  const Wtype w = a + b;
+  const Wtype w = (UWtype) a + (UWtype) b;
 
   if (b >= 0 ? w < a : w > a)
     abort ();
@@ -95,7 +95,7 @@
 SItype
 __addvsi3 (SItype a, SItype b)
 {
-  const SItype w = a + b;
+  const SItype w = (USItype) a + (USItype) b;
 
   if (b >= 0 ? w < a : w > a)
     abort ();
@@ -109,7 +109,7 @@
 DWtype
 __addvDI3 (DWtype a, DWtype b)
 {
-  const DWtype w = a + b;
+  const DWtype w = (UDWtype) a + (UDWtype) b;
 
   if (b >= 0 ? w < a : w > a)
     abort ();
@@ -122,7 +122,7 @@
 Wtype
 __subvSI3 (Wtype a, Wtype b)
 {
-  const Wtype w = a - b;
+  const Wtype w = (UWtype) a - (UWtype) b;
 
   if (b >= 0 ? w > a : w < a)
     abort ();
@@ -133,7 +133,7 @@
 SItype
 __subvsi3 (SItype a, SItype b)
 {
-  const SItype w = a - b;
+  const SItype w = (USItype) a - (USItype) b;
 
   if (b >= 0 ? w > a : w < a)
     abort ();
@@ -147,7 +147,7 @@
 DWtype
 __subvDI3 (DWtype a, DWtype b)
 {
-  const DWtype w = a - b;
+  const DWtype w = (UDWtype) a - (UDWtype) b;
 
   if (b >= 0 ? w > a : w < a)
     abort ();
@@ -187,7 +187,7 @@
 Wtype
 __negvSI2 (Wtype a)
 {
-  const Wtype w = -a;
+  const Wtype w = -(UWtype) a;
 
   if (a >= 0 ? w > 0 : w < 0)
     abort ();
@@ -198,7 +198,7 @@
 SItype
 __negvsi2 (SItype a)
 {
-  const SItype w = -a;
+  const SItype w = -(USItype) a;
 
   if (a >= 0 ? w > 0 : w < 0)
     abort ();
@@ -212,7 +212,7 @@
 DWtype
 __negvDI2 (DWtype a)
 {
-  const DWtype w = -a;
+  const DWtype w = -(UDWtype) a;
 
   if (a >= 0 ? w > 0 : w < 0)
     abort ();
@@ -231,7 +231,7 @@
 #ifdef L_negvsi2
     w = __negvSI2 (a);
 #else
-    w = -a;
+    w = -(UWtype) a;
 
   if (w < 0)
     abort ();
@@ -249,7 +249,7 @@
 #ifdef L_negvsi2
     w = __negvsi2 (a);
 #else
-    w = -a;
+    w = -(USItype) a;
 
   if (w < 0)
     abort ();
@@ -270,7 +270,7 @@
 #ifdef L_negvdi2
     w = __negvDI2 (a);
 #else
-    w = -a;
+    w = -(UDWtype) a;
 
   if (w < 0)
     abort ();

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Guenther]

On Sun, Mar 2, 2008 at 2:00 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Sat, 1 Mar 2008, Richard Guenther wrote:
>
>  > I missed once point noticed by Joseph also, that the libgcc implementation
>  > uses signed types in the implementation of the trapping arithmetics.
>  > Where we of course optimize away the overflow check, so the libgcc
>  > routines will never trap.  (if it does work in some cases then this
>  > would be a missed optimization, so sooner or later it is going to
>  > break more)
>
>  This is of course trivial to fix.  OK to commit the following patch?
>  Bootstrapped with no regressions on i686-pc-linux-gnu.

Ok.

Thanks,
Richard.

>  2008-03-02  Joseph Myers  <joseph@codesourcery.com>
>
>         * libgcc2.c (__addvSI3, __addvsi3, __addvDI3, __subvSI3,
>         __subvsi3, __subvDI3, __negvSI2, __negvsi2, __negvDI2, __absvSI2,
>         __absvsi2, __absvDI2): Use unsigned arithmetic.
>
>  Index: libgcc2.c
>  ===================================================================
>  --- libgcc2.c   (revision 132803)
>  +++ libgcc2.c   (working copy)
>  @@ -84,7 +84,7 @@
>   Wtype
>   __addvSI3 (Wtype a, Wtype b)
>   {
>  -  const Wtype w = a + b;
>  +  const Wtype w = (UWtype) a + (UWtype) b;
>
>    if (b >= 0 ? w < a : w > a)
>      abort ();
>  @@ -95,7 +95,7 @@
>   SItype
>   __addvsi3 (SItype a, SItype b)
>   {
>  -  const SItype w = a + b;
>  +  const SItype w = (USItype) a + (USItype) b;
>
>    if (b >= 0 ? w < a : w > a)
>      abort ();
>  @@ -109,7 +109,7 @@
>   DWtype
>   __addvDI3 (DWtype a, DWtype b)
>   {
>  -  const DWtype w = a + b;
>  +  const DWtype w = (UDWtype) a + (UDWtype) b;
>
>    if (b >= 0 ? w < a : w > a)
>      abort ();
>  @@ -122,7 +122,7 @@
>   Wtype
>   __subvSI3 (Wtype a, Wtype b)
>   {
>  -  const Wtype w = a - b;
>  +  const Wtype w = (UWtype) a - (UWtype) b;
>
>    if (b >= 0 ? w > a : w < a)
>      abort ();
>  @@ -133,7 +133,7 @@
>   SItype
>   __subvsi3 (SItype a, SItype b)
>   {
>  -  const SItype w = a - b;
>  +  const SItype w = (USItype) a - (USItype) b;
>
>    if (b >= 0 ? w > a : w < a)
>      abort ();
>  @@ -147,7 +147,7 @@
>   DWtype
>   __subvDI3 (DWtype a, DWtype b)
>   {
>  -  const DWtype w = a - b;
>  +  const DWtype w = (UDWtype) a - (UDWtype) b;
>
>    if (b >= 0 ? w > a : w < a)
>      abort ();
>  @@ -187,7 +187,7 @@
>   Wtype
>   __negvSI2 (Wtype a)
>   {
>  -  const Wtype w = -a;
>  +  const Wtype w = -(UWtype) a;
>
>    if (a >= 0 ? w > 0 : w < 0)
>      abort ();
>  @@ -198,7 +198,7 @@
>   SItype
>   __negvsi2 (SItype a)
>   {
>  -  const SItype w = -a;
>  +  const SItype w = -(USItype) a;
>
>    if (a >= 0 ? w > 0 : w < 0)
>      abort ();
>  @@ -212,7 +212,7 @@
>   DWtype
>   __negvDI2 (DWtype a)
>   {
>  -  const DWtype w = -a;
>  +  const DWtype w = -(UDWtype) a;
>
>    if (a >= 0 ? w > 0 : w < 0)
>      abort ();
>  @@ -231,7 +231,7 @@
>   #ifdef L_negvsi2
>      w = __negvSI2 (a);
>   #else
>  -    w = -a;
>  +    w = -(UWtype) a;
>
>    if (w < 0)
>      abort ();
>  @@ -249,7 +249,7 @@
>   #ifdef L_negvsi2
>      w = __negvsi2 (a);
>   #else
>  -    w = -a;
>  +    w = -(USItype) a;
>
>    if (w < 0)
>      abort ();
>  @@ -270,7 +270,7 @@
>   #ifdef L_negvdi2
>      w = __negvDI2 (a);
>   #else
>  -    w = -a;
>  +    w = -(UDWtype) a;
>
>    if (w < 0)
>      abort ();
>
>
>
>  --
>  Joseph S. Myers
>  joseph@codesourcery.com
>

Re: [PATCH][4.3] Deprecate -ftrapv

[Ken Raeburn]

On Feb 29, 2008, at 19:13, Richard Guenther wrote:
> We wrap the libcalls inside libcall notes using REG_EQUAL notes
> which indicate the libcalls compute non-trapping +-* (there's no
> RTX code for the trappingness), so we combine and simplify the
> operations making the libcall possibly dead and remove it again.

My patch from September (http://gcc.gnu.org/ml/gcc-patches/2007-09/ 
msg01351.html) should help with the libcall issue a bit, by making  
the trapping libcalls not be considered dead, even if optimizations  
make the results not get used.  (Was I supposed to re-submit the  
patch in non-unidiff format?  I've had a couple of machine die on me  
recently, I might have to reconstruct the source tree.)  Of course,  
if the trapping math is optimized away before you get to emitting  
libcalls, that's a different bug.

Re: [PATCH][4.3] Deprecate -ftrapv

[David Daney]

Mark Mitchell wrote:
> Richard Guenther wrote:
>> This is a request to depcrecate -ftrapv which has numerous problems
>> making it not work as expected since a long time.  As nobody seems
>> to have the energy to ensure it is working I propose to deprecate it
>> for GCC 4.3 to make it possible to remove it during 4.4 (and not
>> block removing libcall notes by it).
> 
> Why doesn't it work?  Can it be made to work relatively easily?  Do we 
> need functionality like this for Ada or Java?
> 

Java only traps on integer division by zero.  As I understand it, this 
is handled by a different mechanism.

David Daney

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

David Daney wrote:
> Mark Mitchell wrote:
>> Richard Guenther wrote:
>>> This is a request to depcrecate -ftrapv which has numerous problems
>>> making it not work as expected since a long time.  As nobody seems
>>> to have the energy to ensure it is working I propose to deprecate it
>>> for GCC 4.3 to make it possible to remove it during 4.4 (and not
>>> block removing libcall notes by it).
>> Why doesn't it work?  Can it be made to work relatively easily?  Do we 
>> need functionality like this for Ada or Java?
>>
> 
> Java only traps on integer division by zero.  As I understand it, this 
> is handled by a different mechanism.

The situation is:

Ada: integer overflow checking required (it's off by default in GNAT,
but you get required standard behavior by using -gnato, the reason
it is off by default is that the code is so horrible).

Java: integer overflow checking is prohibited, wrap around semantics
is required (IMO a horrible choice, but there you are!)

C: integer overflow undefined, checking desirable at least for
debugging purposes.

I think latest Fortran is same as C, can someone confirm?
> 
> David Daney

Re: [PATCH][4.3] Deprecate -ftrapv

[Tom Tromey]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

Mark> Do we need functionality like this for Ada or Java?

It is not needed for Java.

Tom

Re: [PATCH][4.3] Deprecate -ftrapv

[Joseph S. Myers]

On Sat, 1 Mar 2008, Richard Guenther wrote:

> This is a request to depcrecate -ftrapv which has numerous problems
> making it not work as expected since a long time.  As nobody seems
> to have the energy to ensure it is working I propose to deprecate it
> for GCC 4.3 to make it possible to remove it during 4.4 (and not
> block removing libcall notes by it).
> 
> Ok for 4.3?  I'll prepare an entry for the changes.html as well.

If this does need to be deprecated (and it's a feature for which I hope 
someone will step forward to fix or reimplement it, since we know people 
have used it to find integer overflow bugs in their code, despite its 
known limitations), it should give a deprecation warning on all 
compilations using the option, not just be deprecated in documentation.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Guenther]

On Sat, 1 Mar 2008, Joseph S. Myers wrote:

> On Sat, 1 Mar 2008, Richard Guenther wrote:
> 
> > This is a request to depcrecate -ftrapv which has numerous problems
> > making it not work as expected since a long time.  As nobody seems
> > to have the energy to ensure it is working I propose to deprecate it
> > for GCC 4.3 to make it possible to remove it during 4.4 (and not
> > block removing libcall notes by it).
> > 
> > Ok for 4.3?  I'll prepare an entry for the changes.html as well.
> 
> If this does need to be deprecated (and it's a feature for which I hope 
> someone will step forward to fix or reimplement it, since we know people 
> have used it to find integer overflow bugs in their code, despite its 
> known limitations), it should give a deprecation warning on all 
> compilations using the option, not just be deprecated in documentation.

I seriously doubt anyone has used it for anything useful since at least
the advent of tree-ssa.  I see we for example warn for -fforce-mem
in 4.2, but that is a no-op there.  Do we have an option to disable
such warnings?  After all it would break -Werror.

Richard.

Re: [PATCH][4.3] Deprecate -ftrapv

[Joseph S. Myers]

On Sat, 1 Mar 2008, Richard Guenther wrote:

> I seriously doubt anyone has used it for anything useful since at least
> the advent of tree-ssa.  I see we for example warn for -fforce-mem
> in 4.2, but that is a no-op there.  Do we have an option to disable
> such warnings?  After all it would break -Werror.

-fforce-mem isn't an option affecting the semantics of code the same way 
as -ftrapv is, and -ftrapv is more likely to be used manually from time to 
time to check for certain types of bugs rather than in makefiles with 
-Werror.  Telling someone using it manually as a debugging tool that it's 
being deprecated seems useful.  (NB: we should be clear that it's only the 
particular implementation that's proposed for deprecation and removal, and 
not the principle of having the -ftrapv feature should someone wish to fix 
or reimplement it.)

Bruno Haible used -ftrapv to find bugs in GNU clisp a year ago 
<http://gcc.gnu.org/ml/gcc/2007-01/msg00294.html> (that message doesn't 
state whether the compiler version was post-tree-ssa).  Building without 
optimization, as in that case, would I suppose have avoided some of the 
-ftrapv bugs.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Richard Guenther wrote:
> This is a request to depcrecate -ftrapv which has numerous problems
> making it not work as expected since a long time.  As nobody seems
> to have the energy to ensure it is working I propose to deprecate it
> for GCC 4.3 to make it possible to remove it during 4.4 (and not
> block removing libcall notes by it).

Seems a pity, this feature is really needed for Ada, which requires
efficient overflow checking for signed arithmetic, and it seems
useful for C, where signed overflow is undefined, and it would be
nice to enable trapping.

Right now, Ada uses really horrible double length arithmetic to
do trapping.

So I would hestitate to deprecate it so quickly

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Guenther]

On Fri, 29 Feb 2008, Robert Dewar wrote:

> Richard Guenther wrote:
> > This is a request to depcrecate -ftrapv which has numerous problems
> > making it not work as expected since a long time.  As nobody seems
> > to have the energy to ensure it is working I propose to deprecate it
> > for GCC 4.3 to make it possible to remove it during 4.4 (and not
> > block removing libcall notes by it).
> 
> Seems a pity, this feature is really needed for Ada, which requires
> efficient overflow checking for signed arithmetic, and it seems
> useful for C, where signed overflow is undefined, and it would be
> nice to enable trapping.
> 
> Right now, Ada uses really horrible double length arithmetic to
> do trapping.
> 
> So I would hestitate to deprecate it so quickly

Maybe you should organize some resources to fix its implementation
then?

Richard.

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Richard Guenther wrote:

>> So I would hestitate to deprecate it so quickly
> 
> Maybe you should organize some resources to fix its implementation
> then?
> 
> Richard.

It's been on the list for over a decade, it's always harder to find
resources to fix performance problems that don't specifically show
up as blocking bugs. But we will see what we  can do!

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Paolo Bonzini wrote:
>> Seems a pity, this feature is really needed for Ada, which requires
>> efficient overflow checking for signed arithmetic, and it seems
>> useful for C, where signed overflow is undefined, and it would be
>> nice to enable trapping.
>>
>> Right now, Ada uses really horrible double length arithmetic to
>> do trapping.
> 
> It's not the only way to do it though, and it's best to reimplement 
> -ftrapv in terms of GIMPLE.

Right ... from Ada's point of view, it is of course only of limited
value to have an implementation of -ftrapv that is equally horrible :-)
> 
> I'm for deprecating -ftrapv and reimplementing it.  I could mentor a 
> GSOC project for reimplementation of -ftrapv.

Perhaps if the current implementation is too broken, that might be
the most constructive approach ...
> 
> Paolo

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Guenther]

On Sat, Mar 1, 2008 at 2:57 PM, Robert Dewar <dewar@adacore.com> wrote:
> Paolo Bonzini wrote:
>  >> Seems a pity, this feature is really needed for Ada, which requires
>  >> efficient overflow checking for signed arithmetic, and it seems
>  >> useful for C, where signed overflow is undefined, and it would be
>  >> nice to enable trapping.
>  >>
>  >> Right now, Ada uses really horrible double length arithmetic to
>  >> do trapping.
>  >
>  > It's not the only way to do it though, and it's best to reimplement
>  > -ftrapv in terms of GIMPLE.
>
>  Right ... from Ada's point of view, it is of course only of limited
>  value to have an implementation of -ftrapv that is equally horrible :-)
>
> >
>  > I'm for deprecating -ftrapv and reimplementing it.  I could mentor a
>  > GSOC project for reimplementation of -ftrapv.
>
>  Perhaps if the current implementation is too broken, that might be
>  the most constructive approach ...

I agree.

Richard.

Re: [PATCH][4.3] Deprecate -ftrapv

[Eric Botcazou]

> Perhaps if the current implementation is too broken, that might be
> the most constructive approach ...

That's my opinion and the current state of affairs is a hindrance, so I think 
that -ftrapv should be reimplemented from scratch if GCC is to be serious 
about overflow checking.  Of course we would be happy to lend a hand. :-)

-- 
Eric Botcazou

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Eric Botcazou wrote:
>> Perhaps if the current implementation is too broken, that might be
>> the most constructive approach ...
> 
> That's my opinion and the current state of affairs is a hindrance, so I think 
> that -ftrapv should be reimplemented from scratch if GCC is to be serious 
> about overflow checking.  Of course we would be happy to lend a hand. :-)

Reimplementing from scratch certainly might make sense if it is a
better path. Presumably some of the library routines to be used when
there is no hardware assist could be rescued.