This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/60427] [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 05 Mar 2014 11:51:03 +0000
- Subject: [Bug lto/60427] [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto
- Auto-submitted: auto-generated
- References: <bug-60427-4 at http dot gcc dot gnu dot org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427
--- Comment #1 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 5 Mar 2014, dominiq at lps dot ens.fr wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427
>
> Bug ID: 60427
> Summary: [4.9 Regression] r208312 causes ICE and wrong code for
> Fortran with -flto
> Product: gcc
> Version: 4.9.0
> Status: UNCONFIRMED
> Severity: normal
> Priority: P3
> Component: lto
> Assignee: unassigned at gcc dot gnu.org
> Reporter: dominiq at lps dot ens.fr
> CC: pmatos at gcc dot gnu.org, rguenth at gcc dot gnu.org
>
> After r208312 (+ the fix in r208315) I get
>
> FAIL: gfortran.dg/pr33794.f90 -g -flto execution test
>
> with both -m32/-m64, and
>
> FAIL: gfortran.dg/nint_2.f90 -g -flto (internal compiler error)
>
> with -m64 (r208311 + the fix in r208315 is OK).
>
> The ICE occurs for the following reduced test
>
> real(kind=8) :: a
> integer(kind=8) :: i1
>
> ! a = nearest(0.5_8,-1.0_8)
> ! i1 = nint(a)
>
> a = 0.5_8
> i1 = nint(a)
>
> ! a = nearest(0.5_8,1.0_8)
> ! i1 = nint(a)
>
> end
>
> [Book15] f90/bug% /opt/gcc/gcc4.9p-208312/bin/gfortran -flto nint_2_red.f90
> nint_2_red.f90: In function 'MAIN__':
> nint_2_red.f90:8:0: internal compiler error: Segmentation fault: 11
> i1 = nint(a)
>
> The wong code is produced with '-O1 -ffast-math -flto' for
> gfortran.dg/pr33794.f90 as well as the polyhedron test fatigue.f90.
Hmm, this is because mathfn_built_in_1 does
if (TYPE_MAIN_VARIANT (type) == double_type_node)
fcode2 = fcode;
else if (TYPE_MAIN_VARIANT (type) == float_type_node)
fcode2 = fcodef;
else if (TYPE_MAIN_VARIANT (type) == long_double_type_node)
fcode2 = fcodel;
else
return NULL_TREE;
and we now have "two" double_type_nodes (the global tree built
by lto1 and the one that is now streamed literally).
IMHO we want to revert the patch at this point.