[Bug middle-end/33330] New: [gfortran] inlining problem

["dominiq at lps dot ens dot fr" <gcc-bugzilla at gcc dot gnu dot org>]

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