Re: Someone has caused regressions in gfortran (c_char_tests_red.f03)

[dominiq at lps dot ens dot fr (Dominique Dhumieres)]

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).

Cheers

Dominique