[Bug fortran/85138] [8 regression] ICE with generic function

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138

--- Comment #9 from Thomas Koenig  ---
OK, so I am beginning to understand...

Part of the problem seems that, in check_pure_function,

  else if (gfc_pure (NULL))
{
  gfc_error ("Reference to impure function %qs at %L "
 "within a PURE procedure", name, >where);
  return false;
}

is checking the current namespace for PUREness; this seems not
to be initialized when gfc_reduce_init_expr (which in turn calls
gfc_resolve_expr) is called.

[Bug fortran/85138] [8 regression] ICE with generic function

[kargl at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138

--- Comment #8 from kargl at troutmask dot apl.washington.edu  ---
On Mon, Apr 02, 2018 at 05:50:30PM +, tkoenig at gcc dot gnu.org wrote:
> 
> --- Comment #7 from Thomas Koenig  ---
> First, I have renamed the function "len" to "llen" in the original
> test case to avoid confusion with the intrinsic.
> 
> The problem seems to be that, at the entry of pure_function(),
> there are different opinions about purity:
> 
> (gdb) p e->symtree->n.sym->name
> $6 = 0x7743b078 "llen"
> (gdb) p e->symtree->n.sym->attr.pure
> $7 = 0
> (gdb) p e->value.function
> $8 = {actual = 0x2515700, name = 0x77438a80 "str_real_sp_fmt_len", isym =
> 0x0, esym = 0x2581200}
> (gdb) p e->value.function.esym->attr.pure
> $9 = 1
> 
> (Why this problem is exposed by Steve's patch, I have no idea).
> 

I don't have time to look, but if the gfc_reduce_init_expr() is
now being invoked from my patch I suspect that you either have
e->symtree->n.sym->attr.pure overwriting e->value.function.esym->attr.pure
or vice versa.

[Bug fortran/85138] [8 regression] ICE with generic function

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #7 from Thomas Koenig  ---
First, I have renamed the function "len" to "llen" in the original
test case to avoid confusion with the intrinsic.

The problem seems to be that, at the entry of pure_function(),
there are different opinions about purity:

(gdb) p e->symtree->n.sym->name
$6 = 0x7743b078 "llen"
(gdb) p e->symtree->n.sym->attr.pure
$7 = 0
(gdb) p e->value.function
$8 = {actual = 0x2515700, name = 0x77438a80 "str_real_sp_fmt_len", isym =
0x0, esym = 0x2581200}
(gdb) p e->value.function.esym->attr.pure
$9 = 1

(Why this problem is exposed by Steve's patch, I have no idea).

Investigating further...

[Bug fortran/85138] [8 regression] ICE with generic function

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138

--- Comment #6 from Dominique d'Humieres  ---
The following variant gives the same ICE

module fox_m_fsys_format
  interface mylen
 module procedure str_real_sp_len, str_real_sp_fmt_len
  end interface
contains
  pure function str_real_sp_fmt_len(x, fmt) result(n)
real, intent(in) :: x
character(len=*), intent(in) :: fmt
if (.not.checkFmt()) then
endif
  end function str_real_sp_fmt_len
  pure function str_real_sp_len(x) result(n)
real, intent(in) :: x
n = mylen(x, "")
  end function str_real_sp_len
  function str_real_dp_matrix(xa) result(s)
real, intent(in) :: xa
character(len=mylen(xa)) :: s
  end function str_real_dp_matrix
end module fox_m_fsys_format

[Bug fortran/85138] [8 regression] ICE with generic function

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #3)
> (In reply to Dominique d'Humieres from comment #2)
> > Up to revision r258235 (2018-03-04) compiling the test gave the error
> > 
> >  if (.not.checkFmt(fmt)) then
> >  1
> > Error: Reference to impure function 'checkfmt' at (1) within a PURE 
> > procedure
> > 
> > After revision r258362 (2018-03-08) I get the ICE. This has been back ported
> > to 7.3.1.
> > 
> > In this range I see only r258281, r258305, and r258347, but r258305 has not
> > been back ported.
> 
> Bizarrely it is r258347 that is the trigger. It has been backported without
> any ill effects.
>

It's probably not bizarre when a user does something like overloading
the name of an intrinsic subprogram and then tries to use it in a
specification statement.  Something that the contributor of r258347
and of very little brain would never do.  The simple fix is to not
be too clever.

   interface length
  module procedure alen, blen  ! renamed to shorter symbols for debugging
   end interface

  function str_real_dp_matrix(xa) result(s)
 real, intent(in) :: xa
 character(len=length(xa)) :: s
  end function str_real_dp_matrix

% gfc -c a.f90
a.f90:12:18:

  if (.not.checkFmt(fmt)) then
  1
Error: Reference to impure function 'checkfmt' at (1) within a PURE procedure

If I had to guess the gfc_reduce_init_expr() in r258347 is
disabling the reporting of errors at some point when
len=len(xa) is being reduced.

[Bug fortran/85138] [8 regression] ICE with generic function

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138

--- Comment #4 from Andrew Benson  ---
A related but possibly different ICE:


module fox_m_fsys_format
  interface len
module procedure str_real_dp_len, str_real_dp_fmt_len
  end interface
contains
  pure function str_real_dp_fmt_len(x, fmt) result(n)
real, intent(in) :: x
character(len=*), intent(in) :: fmt
if (.not.checkFmt(fmt)) then
endif
  end function str_real_dp_fmt_len
  pure function str_real_dp_len(x) result(n)
real, intent(in) :: x
  end function str_real_dp_len
  pure function str_real_dp_array_len(xa) result(n)
real, dimension(:), intent(in) :: xa
  end function str_real_dp_array_len
  pure function str_real_dp_array_fmt_len(xa, fmt) result(n)
real, dimension(:), intent(in) :: xa
character(len=*), intent(in) :: fmt
  end function str_real_dp_array_fmt_len
  pure function str_real_dp_fmt(x, fmt) result(s)
real, intent(in) :: x
character(len=*), intent(in) :: fmt
character(len=len(x, fmt)) :: s
  end function str_real_dp_fmt
  pure function checkFmt(fmt) result(good)
character(len=*), intent(in) :: fmt
logical :: good
  end function checkFmt
end module fox_m_fsys_format


$ gfortran -c  tmp6.F90

 if (.not.checkFmt(fmt)) then

internal compiler error: Segmentation fault
0xd2f4cf crash_signal
../../gcc-trunk/gcc/toplev.c:325
0x7f434bb321ef ???
   
/data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x881660 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc-trunk/gcc/fortran/trans-expr.c:4890
0x886eaa gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.c:7922
0x889cc7 gfc_conv_expr_val(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.c:7975
0x889d61 gfc_conv_unary_op
../../gcc-trunk/gcc/fortran/trans-expr.c:2799
0x887060 gfc_conv_expr_op
../../gcc-trunk/gcc/fortran/trans-expr.c:3317
0x887060 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.c:7918
0x889cc7 gfc_conv_expr_val(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.c:7975
0x8c00d7 gfc_trans_if_1
../../gcc-trunk/gcc/fortran/trans-stmt.c:1427
0x8c8dba gfc_trans_if(gfc_code*)
../../gcc-trunk/gcc/fortran/trans-stmt.c:1464
0x84ca37 trans_code
../../gcc-trunk/gcc/fortran/trans.c:1916
0x878a2d gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.c:6507
0x850cc1 gfc_generate_module_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans.c:
0x80333b translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.c:6108
0x80333b gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:6324
0x849b8f gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/85138] [8 regression] ICE with generic function

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138

Paul Thomas  changed:

   What|Removed |Added

 CC||kargl at troutmask dot 
apl.washing
   ||ton.edu

--- Comment #3 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #2)
> Up to revision r258235 (2018-03-04) compiling the test gave the error
> 
>  if (.not.checkFmt(fmt)) then
>  1
> Error: Reference to impure function 'checkfmt' at (1) within a PURE procedure
> 
> After revision r258362 (2018-03-08) I get the ICE. This has been back ported
> to 7.3.1.
> 
> In this range I see only r258281, r258305, and r258347, but r258305 has not
> been back ported.

Bizarrely it is r258347 that is the trigger. It has been backported without any
ill effects.

Paul

[Bug fortran/85138] [8 regression] ICE with generic function

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Priority|P3  |P4
  Known to work||6.4.0, 7.3.0
   Target Milestone|--- |8.0
  Known to fail||8.0.1

--- Comment #2 from Dominique d'Humieres  ---
Up to revision r258235 (2018-03-04) compiling the test gave the error

 if (.not.checkFmt(fmt)) then
 1
Error: Reference to impure function 'checkfmt' at (1) within a PURE procedure

After revision r258362 (2018-03-08) I get the ICE. This has been back ported to
7.3.1.

In this range I see only r258281, r258305, and r258347, but r258305 has not
been back ported.

[Bug fortran/85138] [8 regression] ICE with generic function

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-31
 CC||pault at gcc dot gnu.org
Summary|ICE with generic function   |[8 regression] ICE with
   ||generic function
 Ever confirmed|0   |1

--- Comment #1 from Paul Thomas  ---
Confirmed as a regression in 8-branch.

Earlier branches give

 if (.not.checkFmt(fmt)) then
 1
Error: Reference to impure function ‘checkfmt’ at (1) within a PURE procedure

Adding:
  interface
 pure logical function checkFmt(arg)
character(len = *), intent(in) :: arg
 end function
  end interface

makes the problem go away.

Paul