copy of http://gcc.gnu.org/ml/fortran/2007-09/msg00121.html:
I have done some investigation about the recent failure of gfortran.dg/c_char_tests.f03. First the failure disappears with -fno-inline or -fno-inline-functions: [karma] f90/bug% gfc c_char_tests_db.f03 -O3 -fno-inline c_char_driver_db.c [karma] f90/bug% a.out [karma] f90/bug% gfc c_char_tests_db.f03 -O3 -fno-inline-functions c_char_driver_db.c [karma] f90/bug% a.out Second, if I remove the line" sub0();" in c_char_driver.c, the test succeeds, so the C driver can be reduced to: [karma] f90/bug% cat c_char_driver_red.c void sub0(void); int main(int argc, char **argv) { char my_char = 'y'; sub0(); return 0; } with the same behavior. Now the stange part: if I try the following reduced code: ! { dg-do run } ! { dg-additional-sources c_char_driver.c } ! Verify that character dummy arguments for bind(c) procedures can work both ! by-value and by-reference when called by either C or Fortran. ! PR fortran/32732 module c_char_tests use, intrinsic :: iso_c_binding, only: c_char implicit none contains subroutine param_test(my_char) bind(c) character(c_char), value :: my_char call sub1(my_char) end subroutine param_test subroutine sub0() bind(c) call param_test('y') end subroutine sub0 subroutine sub1(my_char_ref) bind(c) character(c_char) :: my_char_ref if(my_char_ref /= c_char_'y') call abort() end subroutine sub1 end module c_char_tests ! { dg-final { cleanup-modules "c_char_tests" } } I get: [karma] f90/bug% gfc c_char_tests_red.f03 -O3 -fno-inline-functions c_char_driver_red.c [karma] f90/bug% a.out Abort [karma] f90/bug% gfc c_char_tests_red.f03 -O3 -fno-inline-functions -fno-inline c_char_driver_red.c [karma] f90/bug% a.out Wierd, isn't it? So if one wants an immediate clean test suite, add -fno-inline-functions. Now clearly the new version of GCC inlines more than the previous one, with two failing cases. The first one (do_3) is a very borderline one, testing folding after integer overflows and I think the addition of -fno-strict-overflow is enough. In my opinion, the second case requires further investigation, but I don't think it would be a good idea to try to prevent the new inlining (unless we discover that it open another Pandora box). -- Summary: [gfortran] inlining problem Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc-apple-darwin8 GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33330