This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] prevent tree sinking of trapping stmts
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Olivier Hainque <hainque at adacore dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 3 Sep 2014 15:05:14 +0200
- Subject: Re: [patch] prevent tree sinking of trapping stmts
- Authentication-results: sourceware.org; auth=none
- References: <9D2C7E78-5C78-4A02-BD48-01E9A9F76157 at adacore dot com> <CAFiYyc2pLQ0oT=cxif+qfHiOVW+Q3xMHU9PvDd9qSOxVRh4Qgw at mail dot gmail dot com> <A532C7F6-B815-4495-AE31-9E07F6C15A32 at adacore dot com>
On Wed, Sep 3, 2014 at 2:49 PM, Olivier Hainque <hainque@adacore.com> wrote:
> Hi Richard,
>
> (Thanks for your feedback)
>
> On Sep 3, 2014, at 12:52 , Richard Biener <richard.guenther@gmail.com> 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's the "real" testcase you are trying to fix?
>
> The original testcase is an Ada ACATS test. It reduces to
> a miscompilation by gcc-4.7 of this excerpt:
>
> with Report;
> procedure P is
>
> X : Float;
>
> function Ident (X : Float) return Float;
> pragma Import (Ada, Ident);
>
> procedure Latch (X : Float);
> pragma Import (Ada, Latch);
> begin
> X := Ident(Float'Base'Last) + Float'Base'Last;
>
> Report.Failed("NO EXCEPTION RAISED BY LARGE '+'");
>
> Latch (X);
> exception
> when others => NULL;
> end;
>
>
> The observable problem is that the "+" operation gets moved past
> the call to Report.Failed: from .095t.sink
>
> Sinking x_19 = D.1629_17 + 3.4028234663852885981170418348451692544e+38;
> from bb 15 to bb 18
> ...
> <bb 15>:
> report_E$5_20 = report_E;
> if (report_E$5_20 == 0)
> goto <bb 16>;
> else
> goto <bb 17>;
>
> <bb 16>:
> .gnat_rcheck_PE_Access_Before_Elaboration ("p.adb", 15);
>
> <bb 17>:
> D.1633.P_ARRAY = "NO EXCEPTION RAISED BY LARGE \'+\'";
> D.1633.P_BOUNDS = &*.LC0;
> report.failed (D.1633);
>
> <bb 18>:
> x_19 = D.1629_17 + 3.4028234663852885981170418348451692544e+38;
> p.latch (x_19);
>
> This was for a port configured to use our front-end sjlj exception
> scheme, using builtin_setjmp and builtin_longjmp to manage exception
> regions and propagations.
>
> This operates without -fexceptions at all, so stmt_could_throw_p is false
> in this case unfortunately.
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?
Richard.
> Olivier
>
>
>
>