[PATCH] Fix PR fortran/26994, transfer with a constant (CONST_DECL) vs the inliner

[Andrew Pinski <pinskia at gmail dot com>]

Hi,
  The problem here is the after inlining the middle-end no longer thinks
the address of a CONST_DECL from the inlined function is invariant.
This causes ICEs, either we get an invalid operand to unary operand or
in newer GCCs, "control flow in the middle of basic block".

This patch fixes the problem by marking the CONST_DECL as "static".

OK? Bootstrapped and tested on i686-linux-gnu with no regressions.

Thanks,
Andrew Pinski

ChangeLog:

	* trans-expr.c (gfc_conv_expr_reference): Set TREE_STATIC on the
	new CONST_DECL.

	* gfortran.fortran-torture/compile/transfer-1.f90: New testcase.

Index: fortran/trans-expr.c
===================================================================
--- fortran/trans-expr.c	(revision 118717)
+++ fortran/trans-expr.c	(working copy)
@@ -3104,6 +3104,7 @@ gfc_conv_expr_reference (gfc_se * se, gf
     {
       var = build_decl (CONST_DECL, NULL, TREE_TYPE (se->expr));
       DECL_INITIAL (var) = se->expr;
+      TREE_STATIC (var) = 1;
       pushdecl (var);
     }
   else
Index: testsuite/gfortran.fortran-torture/compile/transfer-1.f90
===================================================================
--- testsuite/gfortran.fortran-torture/compile/transfer-1.f90	(revision 0)
+++ testsuite/gfortran.fortran-torture/compile/transfer-1.f90	(revision 0)
@@ -0,0 +1,22 @@
+! Bigendian test posted by Perseus in comp.lang.fortran on 4 July 2005.
+   integer(1), parameter :: zero = 0
+   LOGICAL, PARAMETER :: bigend = IACHAR(TRANSFER(1,"a")) == zero
+   LOGICAL :: bigendian
+   call foo ()
+contains
+   subroutine foo ()
+   integer :: chr, ans
+   if (bigend) then
+     ans = 1
+   else
+     ans = 0
+   end if
+   chr = IACHAR(TRANSFER(1,"a"))
+   bigendian =  chr == 0_4
+   if (bigendian) then
+     ans = 1
+   else
+     ans = 0
+   end if
+   end subroutine foo
+end