This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][4.3] Deprecate -ftrapv
- From: Robert Dewar <dewar at adacore dot com>
- To: Ross Ridge <rridge at csclub dot uwaterloo dot ca>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 02 Mar 2008 18:27:53 -0500
- Subject: Re: [PATCH][4.3] Deprecate -ftrapv
- References: <20080302222845.662E273D8C@caffeine.csclub.uwaterloo.ca>
Ross Ridge wrote:
Robert Dewar writes:
Yes, and that is what we would want for Ada, so I am puzzled by your
sigh. All Ada needs to do is to issue a constraint_error exception,
it does not need to know where the exception came from or why except
in very broad detail.
Unless printing "This application has requested the Runtime to terminate
it in an unusual way." counts an issuing a contraint_error in Ada,
it seems to me that -ftrapv and Ada have differing requirements.
How can you portabilty and correctly generate a constraint_error if
the code generated by -ftrapv calls the C runtime function abort()?
On Unix-like systems you can catch SIGABRT, but even there how do you
tell that it didn't come from CTRL-\, a signal sent from a different
process, or abort() called fom some other context? With INTO I don't
see any way distignuish the SIGSEGV it generates on Linux from any of
the myriad other ways a SIGSEGV can be generated.
The normal action of the Ada run time on encountering a SIGSEGV is to
issue a constraint_Error, that's standard, and works fine. There is
no requirement for the kind of distinction you are talking about.
In answer to the question about abort(), we can certainly override
that routine if we need to but I don't think we need to. This of
course is OS dependent, but it's the sort of problem we deal with
in other contexts on all operating systems.
it's fine to have Ctrl-\, signal from a different process or
abort() called from some other context generate a constraint
error exception if it is not possible to distinguish the cases.