Re: [patch] prevent tree sinking of trapping stmts

[Olivier Hainque]

Hi Richard,

(Thanks for your feedback)

On Sep 3, 2014, at 12:52 , Richard Biener <richard.guent...@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.

Olivier