This is the mail archive of the gcc-patches@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] prevent tree sinking of trapping stmts


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
>
>
>
>


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