This is the mail archive of the
mailing list for the GCC project.
Re: [RFA][PATCH] Isolate erroneous paths optimization
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Jakub Jelinek <jakub at redhat dot com>, Jeff Law <law at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>
- Date: Mon, 11 Nov 2013 19:55:25 +0100
- Subject: Re: [RFA][PATCH] Isolate erroneous paths optimization
- Authentication-results: sourceware.org; auth=none
- References: <5271F493 dot 4020308 at redhat dot com> <5074751 dot 6NjRsZ52j7 at polaris> <CAKOQZ8x6cwAMzjfWEgNPYdbPa2fc80Ac+WLAM7LOEZNTfKTkRg at mail dot gmail dot com>
> Simply trapping doesn't tell you anything about caused the trap.
> There are at least two distinct possibilities: NULL pointer
> dereference and integer division by zero. There should be some way to
> distinguish those two cases. It's reasonably easy to do so in a
> signal handler. When should we do if the compiler generate a call to
You would use the fallback code in the signal handler, throwing the exception
used when you don't know the precise cause of the erroneous execution. Or
else we could pass an argument to __builtin_throw, but we would need some low-
level convention to pass it on to the handler.