Le 09/05/2024 à 22:30, Harald Anlauf a écrit :
Hi Mikael,
Am 09.05.24 um 21:51 schrieb Mikael Morin:
Hello,
Le 06/05/2024 à 21:33, Harald Anlauf a écrit :
Dear all,
I've been contemplating whether to submit the attached patch.
It addresses an ICE-on-invalid as reported in the PR, and also
fixes an accepts-invalid (see testcase), plus maybe some more,
related due to incomplete checking of symbol attribute conflicts.
The fix does not fully address the general issue, which is
analyzed by Steve: some of the checks do depend on the selected
Fortran standard, and under circumstances such as in the testcase
the checking of other, standard-version-independent conflicts
simply does not occur.
Steve's solution would fix that, but unfortunately leads to issues
with error recovery in notoriously fragile parts of the FE: e.g.
testcase pr87907.f90 needs adjusting, and minor variations
of it will lead to various other horrendous ICEs that remind
of existing PRs where parsing or resolution goes sideways.
I therefore propose a much simpler approach: move - if possible -
selected of the standard-version-dependent checks after the
version-independent ones. I think this could help in getting more
consistent error reporting and recovery. However, I did *not*
move those checks that are critical when processing interfaces.
(-> pr87907.f90 / (sub)modules)
Your patch looks clean, but I'm concerned that the order of the checks
should be the important ones first, regardless of their standard
version. I'm trying to look at the ICE caused by your other tentative
patch at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635#c6 but I
can't reproduce the problem. Do you by any chance have around some of
the variations causing "horrendous" ICEs?
Oh, that's easy. Just move the block
conf_std (allocatable, dummy, GFC_STD_F2003);
conf_std (allocatable, function, GFC_STD_F2003);
conf_std (allocatable, result, GFC_STD_F2003);
towards the end of the gfc_check_conflict before the return true.
While the error messages for the original gfortran.dg/pr87907.f90
look harmless, commenting out the main program p I get:
pr87907.f90:15:18:
15 | subroutine g(x) ! { dg-error "mismatch in argument" }
| 1
Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'g' at (1)
f951: internal compiler error: Segmentation fault
0x13b8ec2 crash_signal
../../gcc-trunk/gcc/toplev.cc:319
0xba530e free_sym_tree
../../gcc-trunk/gcc/fortran/symbol.cc:4026
0xba5319 free_sym_tree
../../gcc-trunk/gcc/fortran/symbol.cc:4026
0xba5319 free_sym_tree
../../gcc-trunk/gcc/fortran/symbol.cc:4026
0xba5319 free_sym_tree
../../gcc-trunk/gcc/fortran/symbol.cc:4026
0xba5609 gfc_free_namespace(gfc_namespace*&)
../../gcc-trunk/gcc/fortran/symbol.cc:4168
0xba39c1 gfc_free_symbol(gfc_symbol*&)
../../gcc-trunk/gcc/fortran/symbol.cc:3173
0xba3b89 gfc_release_symbol(gfc_symbol*&)
../../gcc-trunk/gcc/fortran/symbol.cc:3216
0xba5339 free_sym_tree
../../gcc-trunk/gcc/fortran/symbol.cc:4029
0xba5609 gfc_free_namespace(gfc_namespace*&)
../../gcc-trunk/gcc/fortran/symbol.cc:4168
0xba58ef gfc_symbol_done_2()
../../gcc-trunk/gcc/fortran/symbol.cc:4236
0xb12ec8 gfc_done_2()
../../gcc-trunk/gcc/fortran/misc.cc:387
0xb4ac7f clean_up_modules
../../gcc-trunk/gcc/fortran/parse.cc:7057
0xb4af02 translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.cc:7122
0xb4b735 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.cc:7413
0xbb626f gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.cc:241
Restoring the main program but simply adding "end subroutine g"
where it is naively expected gives:
pr87907.f90:15:18:
15 | subroutine g(x) ! { dg-error "mismatch in argument" }
| 1
Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'g' at (1)
pr87907.f90:16:9:
16 | end subroutine g
| 1
Error: Expecting END SUBMODULE statement at (1)
pr87907.f90:20:7:
20 | use m ! { dg-error "has a type" }
| 1
21 | integer :: x = 3
22 | call g(x) ! { dg-error "which is not consistent
with" }
|
2
Error: 'g' at (1) has a type, which is not consistent with the CALL at (2)
f951: internal compiler error: in gfc_free_namespace, at
fortran/symbol.cc:4164
0xba55e1 gfc_free_namespace(gfc_namespace*&)
../../gcc-trunk/gcc/fortran/symbol.cc:4164
0xba39c1 gfc_free_symbol(gfc_symbol*&)
../../gcc-trunk/gcc/fortran/symbol.cc:3173
0xba3b89 gfc_release_symbol(gfc_symbol*&)
../../gcc-trunk/gcc/fortran/symbol.cc:3216
0xba5339 free_sym_tree
../../gcc-trunk/gcc/fortran/symbol.cc:4029
0xba5609 gfc_free_namespace(gfc_namespace*&)
../../gcc-trunk/gcc/fortran/symbol.cc:4168
0xba58ef gfc_symbol_done_2()
../../gcc-trunk/gcc/fortran/symbol.cc:4236
0xb12ec8 gfc_done_2()
../../gcc-trunk/gcc/fortran/misc.cc:387
0xb4ac7f clean_up_modules
../../gcc-trunk/gcc/fortran/parse.cc:7057
0xb4af02 translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.cc:7122
0xb4b735 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.cc:7413
0xbb626f gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.cc:241
Now adding -std=f2018 to the compiler flags I get:
pr87907.f90:15:18:
15 | subroutine g(x) ! { dg-error "mismatch in argument" }
| 1
Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'g' at (1)
pr87907.f90:16:9:
16 | end subroutine g
| 1
Error: Expecting END SUBMODULE statement at (1)
pr87907.f90:20:7:
20 | use m ! { dg-error "has a type" }
| 1
21 | integer :: x = 3
22 | call g(x) ! { dg-error "which is not consistent
with" }
|
2
Error: 'g' at (1) has a type, which is not consistent with the CALL at (2)
free(): invalid pointer
f951: internal compiler error: Aborted
0x13b8ec2 crash_signal
../../gcc-trunk/gcc/toplev.cc:319
0xba584f gfc_free_namespace(gfc_namespace*&)
../../gcc-trunk/gcc/fortran/symbol.cc:4207
0xba39c1 gfc_free_symbol(gfc_symbol*&)
../../gcc-trunk/gcc/fortran/symbol.cc:3173
0xba3b89 gfc_release_symbol(gfc_symbol*&)
../../gcc-trunk/gcc/fortran/symbol.cc:3216
0xba5339 free_sym_tree
../../gcc-trunk/gcc/fortran/symbol.cc:4029
0xba5609 gfc_free_namespace(gfc_namespace*&)
../../gcc-trunk/gcc/fortran/symbol.cc:4168
0xba58ef gfc_symbol_done_2()
../../gcc-trunk/gcc/fortran/symbol.cc:4236
0xb12ec8 gfc_done_2()
../../gcc-trunk/gcc/fortran/misc.cc:387
0xb4ac7f clean_up_modules
../../gcc-trunk/gcc/fortran/parse.cc:7057
0xb4af02 translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.cc:7122
0xb4b735 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.cc:7413
0xbb626f gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.cc:241
I'll stop here...
Thanks. Go figure, I have no problem reproducing today.
It's PR99798 (and there is even a patch for it).
We currently do not recover well from errors, and the prevention
of corrupted namespaces is apparently a goal we aim at.
Yes, and we are not there yet. But at least there is a sensible error
message before the crash.
Cheers,
Harald
The patch therefore does not require any testsuite update and
should not give any other surprises, so it should be very safe.
The plan is also to leave the PR open for the time being.
Regtesting on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
