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: [PATCH][4.3] Deprecate -ftrapv


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.


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