2010-07-24 Tobias Burnus <burnus@net-b.de>
PR fortran/40011
* parse.c (gfc_parse_file): Do not override
gfc_global_ns_list items.
2010-07-24 Tobias Burnus <burnus@net-b.de>
PR fortran/40011
* gfortran.dg/whole_file_21.f90: New.
* gfortran.dg/integer_exponentiation_3.F90: Use
-ffloat-store only for i?86/x86-64 -m32.
===================================================================
@@ -0,0 +1,27 @@
+! { dg-do link }
+! PR fortran/40011
+!
+! Contributed by Joost VandeVondele
+!
+!
+! Before no "one" function was generated with -fwhole-file.
+!
+!
+SUBROUTINE one ( )
+END SUBROUTINE one
+
+SUBROUTINE two ( )
+END SUBROUTINE two
+
+MODULE mod
+CONTAINS
+ SUBROUTINE three ( )
+ CALL two ( )
+ END SUBROUTINE three
+ SUBROUTINE four ( )
+ CALL one ( )
+ END SUBROUTINE four
+END MODULE mod
+END
+
+! { dg-final { cleanup-modules "m" } }
===================================================================
@@ -1,8 +1,8 @@
! { dg-do run { xfail spu-*-* } }
! FAILs on SPU because of wrong compile-time rounding mode
-! { dg-options "-ffloat-store" }
+! { dg-options "" }
+! { dg-options "-ffloat-store" { target { { i?86-*-* x86_64-*-* } && ilp32 } } }
!
-! -ffloat-store needed for x87
!
module mod_check
implicit none
===================================================================
@@ -4414,7 +4414,11 @@ prog_units:
later and all their interfaces resolved. */
gfc_current_ns->code = s.head;
if (next)
- next->sibling = gfc_current_ns;
+ {
+ for (; next->sibling; next = next->sibling)
+ ;
+ next->sibling = gfc_current_ns;
+ }
else
gfc_global_ns_list = gfc_current_ns;
PR 40011 was a quite interesting bug. As it turned out, the linker error /tmp/ccN7F1tB.o: In function `__mod_MOD_four': test.f90:(.text+0x3): undefined reference to `one_' is fully correct: gfortran simply did not generate the function "one" at all - only the call. The reason is that the gfc_global_ns_list gets overridden. Initially, it contains "two" with gfc_global_ns_lis->sibling being "one" (and no other following sibling). Somehow, gfortran decides to generate after "two" the main function - while "next" points to "two". What happens now that "next->sibling" is set to "MAIN__", breaking the link to "one", which is then never been generated. The fix is obvious. I included the test case as simple "dg-do link" test, but one can also do it fancier. Build, regtested (RUNTESTFLAGS="--target_board=unix/{-m64,-m32} - and also libgomp tested) on x86-64-linux. Committed as Rev. 162500. Tobias