This is the mail archive of the gcc-bugs@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]

[Bug lto/60427] [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto


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.


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