Hello, The following code triggers an internal compiler error with gfortran 14.1.0 and 14.2.0: > cat ice_nml_profilern.f90 module mod_nml1 logical :: ldiag namelist /nam_nml1/ldiag end module mod_nml1 module mod_nml2 logical :: ldiag namelist /nam_nml2/ldiag end module mod_nml2 module mod_interm use mod_nml1 end module mod_interm program ice_nml use mod_nml1, ldiag_nml1 => ldiag use mod_nml2, ldiag_nml2 => ldiag use mod_interm integer :: ilu read(unit=ilu,nml=nam_nml1) end program ice_nml > gfortran ice_nml_profilern.f90 ice_nml_profilern.f90:24:29: 24 | read(unit=ilu,nml=nam_nml1) | 1 internal compiler error: Segmentation fault 0xe10cdf crash_signal ../../gcc-14.2.0-srcdir/gcc/toplev.cc:319 0x893878 gfc_build_cstring_const(char const*) ../../gcc-14.2.0-srcdir/gcc/fortran/trans-const.cc:124 0x8de9eb transfer_namelist_element ../../gcc-14.2.0-srcdir/gcc/fortran/trans-io.cc:1696 0x8e0792 build_dt ../../gcc-14.2.0-srcdir/gcc/fortran/trans-io.cc:2012 0x872b87 trans_code ../../gcc-14.2.0-srcdir/gcc/fortran/trans.cc:2551 0x8a38b4 gfc_generate_function_code(gfc_namespace*) ../../gcc-14.2.0-srcdir/gcc/fortran/trans-decl.cc:7880 0x813e26 translate_all_program_units ../../gcc-14.2.0-srcdir/gcc/fortran/parse.cc:7099 0x813e26 gfc_parse_file() ../../gcc-14.2.0-srcdir/gcc/fortran/parse.cc:7413 0x86fc0f gfc_be_parse_file ../../gcc-14.2.0-srcdir/gcc/fortran/f95-lang.cc:241 I'm not sure it is conforming to the Fortran standard but it shouldn't trigger an ICE. I think it could be related to the fix for bug 105847. This code compiles successfully with versions prior to 14.
(In reply to philippe.wautelet from comment #0) > > I'm not sure it is conforming to the Fortran standard but it shouldn't > trigger an ICE. > I agree with you about the ICE should not happen. Staring at F2023, I find the following constraint. C8107 (R871) The namelist-group-name shall not be a name accessed by use association. If I understand it, your code is nonstandard. But, I don't use namelist, so will need to read through the Fortran standard a bit more.
Reduced testcase: module mod_nml1 logical :: ldiag namelist /nam_nml1/ldiag end module mod_nml1 module mod_interm use mod_nml1 end module mod_interm program ice_nml ! Interchanging the following two lines fixes the ICE: use mod_nml1, ldiag_nml1 => ldiag use mod_interm integer :: ilu read(unit=ilu,nml=nam_nml1) end program ice_nml Works with Intel, NAG, Nvidia, flang. As written above, interchanging the use statements fixes the ICE.
Tentative obvious fix for NULL pointer dereference: diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc index 7ab82fa2f5b..de38f4a808f 100644 --- a/gcc/fortran/trans-io.cc +++ b/gcc/fortran/trans-io.cc @@ -1692,7 +1692,8 @@ transfer_namelist_element (stmtblock_t * block, const char * var_name, gcc_assert (sym || c); /* Build the namelist object name. */ - if (sym && !sym->attr.use_only && sym->attr.use_rename) + if (sym && !sym->attr.use_only && sym->attr.use_rename + && sym->ns->use_stmts->rename) string = gfc_build_cstring_const (sym->ns->use_stmts->rename->local_name); else string = gfc_build_cstring_const (var_name);
(In reply to kargls from comment #1) > (In reply to philippe.wautelet from comment #0) > > > > > I'm not sure it is conforming to the Fortran standard but it shouldn't > > trigger an ICE. > > > > I agree with you about the ICE should not happen. Staring at F2023, > I find the following constraint. > > C8107 (R871) The namelist-group-name shall not be a name accessed by use > association. > > If I understand it, your code is nonstandard. But, I don't use namelist, so > will need to read through the Fortran standard a bit more. This constraint applies to the namelist statement and does not apply to the issue here.
(In reply to anlauf from comment #4) > (In reply to kargls from comment #1) > > (In reply to philippe.wautelet from comment #0) > > > > > > > > I'm not sure it is conforming to the Fortran standard but it shouldn't > > > trigger an ICE. > > > > > > > I agree with you about the ICE should not happen. Staring at F2023, > > I find the following constraint. > > > > C8107 (R871) The namelist-group-name shall not be a name accessed by use > > association. > > > > If I understand it, your code is nonstandard. But, I don't use namelist, so > > will need to read through the Fortran standard a bit more. > > This constraint applies to the namelist statement and does not apply to the > issue here. Yeah, I needed to review more the Fortran, and you beat me to working out a patch. The '(R871)' above restricts the constraint to namelist statement. However, this did lead to module mod_nml1 implicit none logical :: ldiag namelist /nam_nml1/ldiag end module mod_nml1 program ice_nml use mod_nml1 implicit none integer :: ilu, j namelist /nam_nml1/j !<-- Does this violates C8107? ldiag = .false. j = 42 write(*,nml=nam_nml1) end program ice_nml % gfcx -o z a.f90 && ./z &NAM_NML1 LDIAG=F, J=42 , /
(In reply to anlauf from comment #3) > Tentative obvious fix for NULL pointer dereference: > > diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc > index 7ab82fa2f5b..de38f4a808f 100644 > --- a/gcc/fortran/trans-io.cc > +++ b/gcc/fortran/trans-io.cc > @@ -1692,7 +1692,8 @@ transfer_namelist_element (stmtblock_t * block, const > char * var_name, > gcc_assert (sym || c); > > /* Build the namelist object name. */ > - if (sym && !sym->attr.use_only && sym->attr.use_rename) > + if (sym && !sym->attr.use_only && sym->attr.use_rename > + && sym->ns->use_stmts->rename) > string = gfc_build_cstring_const > (sym->ns->use_stmts->rename->local_name); > else > string = gfc_build_cstring_const (var_name); Patch looks good. If it passes regression testing, you can commit it you want.
(In reply to kargls from comment #5) > (In reply to anlauf from comment #4) > > (In reply to kargls from comment #1) > > > (In reply to philippe.wautelet from comment #0) > > > > > > > > > > > I'm not sure it is conforming to the Fortran standard but it shouldn't > > > > trigger an ICE. > > > > > > > > > > I agree with you about the ICE should not happen. Staring at F2023, > > > I find the following constraint. > > > > > > C8107 (R871) The namelist-group-name shall not be a name accessed by use > > > association. > > > > > > If I understand it, your code is nonstandard. But, I don't use namelist, so > > > will need to read through the Fortran standard a bit more. > > > > This constraint applies to the namelist statement and does not apply to the > > issue here. > > Yeah, I needed to review more the Fortran, and you beat me > to working out a patch. The '(R871)' above restricts the > constraint to namelist statement. However, this did lead to > > module mod_nml1 > implicit none > logical :: ldiag > namelist /nam_nml1/ldiag > end module mod_nml1 > > program ice_nml > use mod_nml1 > implicit none > integer :: ilu, j > namelist /nam_nml1/j !<-- Does this violates C8107? Yes, that is illegal and rejected by Intel and NAG, e.g.: NAG Fortran Compiler Release 7.2(Shin-Urayasu) Build 7200 Error: iii.f90, line 11: Redeclaration of symbol NAM_NML1 from USEd module MOD_NML1 detected at /@NAM_NML1 Warning: iii.f90, line 15: Unused local variable ILU [NAG Fortran Compiler pass 1 error termination, 1 error, 1 warning] I think we should track that constraint violation separately (no regression) from the present PR (regression). > ldiag = .false. > j = 42 > write(*,nml=nam_nml1) > end program ice_nml > > % gfcx -o z a.f90 && ./z > &NAM_NML1 > LDIAG=F, > J=42 , > /
(In reply to kargls from comment #6) > (In reply to anlauf from comment #3) > > Tentative obvious fix for NULL pointer dereference: > > > > diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc > > index 7ab82fa2f5b..de38f4a808f 100644 > > --- a/gcc/fortran/trans-io.cc > > +++ b/gcc/fortran/trans-io.cc > > @@ -1692,7 +1692,8 @@ transfer_namelist_element (stmtblock_t * block, const > > char * var_name, > > gcc_assert (sym || c); > > > > /* Build the namelist object name. */ > > - if (sym && !sym->attr.use_only && sym->attr.use_rename) > > + if (sym && !sym->attr.use_only && sym->attr.use_rename > > + && sym->ns->use_stmts->rename) > > string = gfc_build_cstring_const > > (sym->ns->use_stmts->rename->local_name); > > else > > string = gfc_build_cstring_const (var_name); > > Patch looks good. If it passes regression testing, you can commit it you > want. Yes, it passed. I was just packaging it for submission, but given your OK I will push to master and inform the list.
The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>: https://gcc.gnu.org/g:6bfeba12c86b4d0dae27d99b484f64774dd49398 commit r15-3308-g6bfeba12c86b4d0dae27d99b484f64774dd49398 Author: Harald Anlauf <anlauf@gmx.de> Date: Thu Aug 29 21:21:39 2024 +0200 Fortran: fix ICE with use with rename of namelist member [PR116530] gcc/fortran/ChangeLog: PR fortran/116530 * trans-io.cc (transfer_namelist_element): Prevent NULL pointer dereference. gcc/testsuite/ChangeLog: PR fortran/116530 * gfortran.dg/use_rename_12.f90: New test.
Fixed on mainline so far.
The releases/gcc-14 branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>: https://gcc.gnu.org/g:5999dd8a610acbaff9dfb6bdeb67f33380336132 commit r14-10621-g5999dd8a610acbaff9dfb6bdeb67f33380336132 Author: Harald Anlauf <anlauf@gmx.de> Date: Thu Aug 29 21:21:39 2024 +0200 Fortran: fix ICE with use with rename of namelist member [PR116530] gcc/fortran/ChangeLog: PR fortran/116530 * trans-io.cc (transfer_namelist_element): Prevent NULL pointer dereference. gcc/testsuite/ChangeLog: PR fortran/116530 * gfortran.dg/use_rename_12.f90: New test. (cherry picked from commit 6bfeba12c86b4d0dae27d99b484f64774dd49398)
Backported to 14-branch. Closing. Thanks for the report!