On Sep 4, 2014, at 12:22 , Richard Biener wrote:
> So I tend to think that removing / delaying traps is ok unless you
> can catch them within the active EH scheme.
> Certainly that Oliver excludes loads/stores (but not integer
> division!) points at the fact that preserving the order of
> traps
On Thu, Sep 04, 2014 at 12:22:33PM +0200, Richard Biener wrote:
> But then the proposed patch pessimizes code too much IMHO.
Yeah. IMHO if Ada wants to __builtin_longjmp from synchronous signal handlers
(SIGFPE, SIGSEGV, ...) then the middle-end needs to be aware of that and
have it represented i
On Thu, Sep 4, 2014 at 11:04 AM, Eric Botcazou wrote:
>> Well, but that's a bug in the Ada frontend if it does exceptions behind
>> GCCs back. ISTR that the middle-end also supports a SJLJ EH scheme?
>
> No and yes respectively. As already explained multiple times, GNAT uses an
> SJLJ scheme whi
> Well, but that's a bug in the Ada frontend if it does exceptions behind
> GCCs back. ISTR that the middle-end also supports a SJLJ EH scheme?
No and yes respectively. As already explained multiple times, GNAT uses an
SJLJ scheme which is entirely managed by the front-end and (manually) lowere
On Sep 3, 2014, at 15:27 , Richard Biener wrote:
> Eventually the FE can still simply set flag_exeptions /
> flag_non_call_exceptions?
> It will still not be correct for all cases
> but at least external throw predicates would work ...
Yes, these would work. I have always been worried about th
On Wed, Sep 3, 2014 at 3:25 PM, Olivier Hainque wrote:
>
> On Sep 3, 2014, at 15:05 , Richard Biener wrote:
>> Well, but that's a bug in the Ada frontend if it does exceptions behind
>> GCCs back.
>
> I agree that this is a problem and that could_throw_p is a better
> predicate. I wasn't convin
On Sep 3, 2014, at 15:05 , Richard Biener wrote:
> Well, but that's a bug in the Ada frontend if it does exceptions behind
> GCCs back.
I agree that this is a problem and that could_throw_p is a better
predicate. I wasn't convinced by my own answer but hadn't really
pinpointed why before hitt
On Wed, Sep 3, 2014 at 2:49 PM, Olivier Hainque wrote:
> Hi Richard,
>
> (Thanks for your feedback)
>
> On Sep 3, 2014, at 12:52 , Richard Biener wrote:
>> I don't quite follow this reasoning. Why would a trapping FP operation
>> not be undefined behavior without -fnon-call-exceptions? That is,
Hi Richard,
(Thanks for your feedback)
On Sep 3, 2014, at 12:52 , Richard Biener wrote:
> I don't quite follow this reasoning. Why would a trapping FP operation
> not be undefined behavior without -fnon-call-exceptions? That is,
> don't you want to check stmt_could_throw_p?
>
> That is, what'
On Wed, Sep 3, 2014 at 12:28 PM, Olivier Hainque wrote:
> Hello,
>
> For the testcase below, the tree-ssa-sink pass sinks the first a = b + c;
> assignment within the if branch.
>
> This is problematic when the + operation on floats could trap, as it gets
> moved
> out of the path that dominates
Hello,
For the testcase below, the tree-ssa-sink pass sinks the first a = b + c;
assignment within the if branch.
This is problematic when the + operation on floats could trap, as it gets moved
out of the path that dominates the call in the else branch and a trap on the
original + should prevent
11 matches
Mail list logo
