[Bug fortran/85526] [6/7/8/9 regression] ICE when calling a (pure) function from inside another pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from kargl at gcc dot gnu.org --- This is actually a duplicate of PR 85138. Comment #6 should be added to that PR. *** This bug has been marked as a duplicate of bug 85138 ***
[Bug fortran/85526] [6/7/8/9 regression] ICE when calling a (pure) function from inside another pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526
--- Comment #6 from Steve Kargl ---
On Thu, Apr 26, 2018 at 12:54:05AM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526
>
> --- Comment #3 from Steve Kargl ---
> On Wed, Apr 25, 2018 at 11:33:34PM +, dominiq at lps dot ens.fr wrote:
> > The code compiles with 6.4.0 and 7.3.0, but not with 6.4.1, 7.3.1,
> > 8.0.1 and trunk (9.0). This is likely r258347 for gcc8, r258367
> > for gcc7, and r258368 for gcc6.
>
> Bummer.
>
> Don't know how to fix this one.
>
> Workaround is to move checkFmt() to above its first use
> in another function.
>
Well, I understand the problem a bit now. In decl.c (lines 3229
to 3248), we have
/* If gfortran ends up here, then the len may be reducible to a
constant. Try to do that here. If it does not reduce, simply
assign len to the charlen. */
if (len && len->expr_type != EXPR_CONSTANT)
{
gfc_expr *e;
e = gfc_copy_expr (len);
gfc_reduce_init_expr (e);
if (e->expr_type == EXPR_CONSTANT)
{
gfc_replace_expr (len, e);
if (mpz_cmp_si (len->value.integer, 0) < 0)
mpz_set_ui (len->value.integer, 0);
}
else
{
gfc_free_expr (e);
}
cl->length = len;
}
'gfc_reduce_init_expr (e)' is causing the symbol checkFmt,
which has not previously been seen, to be committed to the
current namespace before the symbol has been resolved. So,
checkFmt() doesn't have a proper type and gfortran cannot
set it when she finally parses the function. During the
translation, checkFmt is implicitly typed, which can be
gleaned from
0x6ce630 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc8/gcc/fortran/trans-expr.c:7918
0x6d0967 gfc_conv_expr_val(gfc_se*, gfc_expr*)<-- from stepping in gdb
../../gcc8/gcc/fortran/trans-expr.c:7975
0x6fed87 gfc_trans_if_1
../../gcc8/gcc/fortran/trans-stmt.c:1427
0x70715a gfc_trans_if(gfc_code*)
What needs to be done is that symbols in the gfc_current_ns
must be save before the call to 'gfc_reduce_init_expr (e)'.
If reduction fails, then the old symbols need to be
restored in the gfc_current_ns and any new symbols added
by 'gfc_reduce_init_expr (e)' need to be removed.
Unfortunately, I don't know how to do this.
[Bug fortran/85526] [6/7/8/9 regression] ICE when calling a (pure) function from inside another pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526 --- Comment #5 from Steve Kargl --- On Thu, Apr 26, 2018 at 08:03:35AM +, mail at pietrodelugas dot it wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526 > > --- Comment #4 from Pietro Delugas --- > a quick and dirty workaround is to move all the routines in the "leng" > interface at the bottom of the file. But some compilers do not accept > this code as valid. > > A better solution is to move the leng subroutines in a module by > their own and import the interface. > With your original code, move checkFMT() to right after the CONTAINS statement. The code then compiles. No other functions need to move.
[Bug fortran/85526] [6/7/8/9 regression] ICE when calling a (pure) function from inside another pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526 --- Comment #4 from Pietro Delugas --- a quick and dirty workaround is to move all the routines in the "leng" interface at the bottom of the file. But some compilers do not accept this code as valid. A better solution is to move the leng subroutines in a module by their own and import the interface.
[Bug fortran/85526] [6/7/8/9 regression] ICE when calling a (pure) function from inside another pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.5
[Bug fortran/85526] [6/7/8/9 regression] ICE when calling a (pure) function from inside another pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526 --- Comment #3 from Steve Kargl --- On Wed, Apr 25, 2018 at 11:33:34PM +, dominiq at lps dot ens.fr wrote: > The code compiles with 6.4.0 and 7.3.0, but not with 6.4.1, 7.3.1, > 8.0.1 and trunk (9.0). This is likely r258347 for gcc8, r258367 > for gcc7, and r258368 for gcc6. Bummer. Don't know how to fix this one. Workaround is to move checkFmt() to above its first use in another function.
[Bug fortran/85526] [6/7/8/9 regression] ICE when calling a (pure) function from inside another pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||6.4.0, 7.3.0 Keywords||ice-on-valid-code Last reconfirmed||2018-04-25 Ever confirmed|0 |1 Summary|[6.4 regression] calling a |[6/7/8/9 regression] ICE |(pure) function from inside |when calling a (pure) |another pure function may |function from inside |cause segmentation fault|another pure function |during compilation | Known to fail||6.4.1, 7.3.1, 8.0.1 --- Comment #2 from Dominique d'Humieres --- The code compiles with 6.4.0 and 7.3.0, but not with 6.4.1, 7.3.1, 8.0.1 and trunk (9.0). This is likely r258347 for gcc8, r258367 for gcc7, and r258368 for gcc6.
