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: Olivier Hainque <hainque at adacore dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Olivier Hainque <hainque at adacore dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 3 Sep 2014 14:49:54 +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>
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.
Olivier