[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54880
Dominique d'Humieres changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Dominique d'Humieres ---
> One way to get rid of the error is to simply remove the assert that causes it
> (which was already constrained by Paul for PR43450). However, I'm not sure if
> that's justified.
The asserts were introduced at revision r139773 to solve a problem with COMMON
and DW_TAG_common_block (PRs 23057 and 29635). I fail to understand their
logic: why
TYPE_CONTEXT (decl) = sym->ns->proc_name->backend_decl;
if
TYPE_CONTEXT (decl) == sym->ns->proc_name->backend_decl?
Updated patch
--- ../_clean/gcc/fortran/trans-decl.c 2019-02-02 01:32:53.0 +0100
+++ gcc/fortran/trans-decl.c2019-02-02 09:32:15.0 +0100
@@ -4975,14 +4975,6 @@ gfc_create_module_variable (gfc_symbol *
decl = sym->backend_decl;
gcc_assert (sym->ns->proc_name->attr.flavor == FL_MODULE);
- if (!sym->attr.use_assoc && !sym->attr.used_in_submodule)
- {
- gcc_assert (TYPE_CONTEXT (decl) == NULL_TREE
- || TYPE_CONTEXT (decl) ==
sym->ns->proc_name->backend_decl);
- gcc_assert (DECL_CONTEXT (TYPE_STUB_DECL (decl)) == NULL_TREE
- || DECL_CONTEXT (TYPE_STUB_DECL (decl))
- == sym->ns->proc_name->backend_decl);
- }
TYPE_CONTEXT (decl) = sym->ns->proc_name->backend_decl;
DECL_CONTEXT (TYPE_STUB_DECL (decl)) = sym->ns->proc_name->backend_decl;
gfc_module_add_decl (cur_module, TYPE_STUB_DECL (decl));
> At least it does not introduce any regressions in the testsuite.
Removing an assert cannot introduce any regression.
[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54880 --- Comment #6 from Jakub Jelinek --- The assert is meaningful, it is a bug if something is created with one context once and then something tries to change that context to something else. So whatever wants to change that is doing something wrong, or it has been created in a wrong context initially.
[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54880 --- Comment #7 from Dominique d'Humieres --- > The assert is meaningful, it is a bug if something is created > with one context once and then something tries to change that > context to something else. So whatever wants to change that > is doing something wrong, or it has been created in a wrong > context initially. OK. However asserts are not user friendly. Is it due to the fact that m1.f95 compiles only if it finds an adv_m.mod file and m2.f95 generates its own file?
[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54880 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #8 from Dominique d'Humieres --- > OK. However asserts are not user friendly. ... Could you please suggest what the error should be?
[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54880 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #9 from Thomas Koenig --- It is not completely clear to me what the desired behavior should be. Reading in a module file from one file and then recompiling the same module sounds wrong. This should be caught. Putting module m1 use m2 end module m1 module m2 end module m2 into a single file also seems strange. Maybe try to catch this earlier and issue an error like "Trying to re-compile module %qs which was already read in from %qs would be clear? Definitely gcc 10 material.
[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54880 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|ICE in |[OOP] ICE in |gfc_create_module_variable, |gfc_create_module_variable, |at |at |fortran/trans-decl.c:4013 |fortran/trans-decl.c:4013 --- Comment #1 from janus at gcc dot gnu.org 2012-10-12 09:33:27 UTC --- Huh, the procedure to reproduce the bug is rather strange. However, I can confirm the error (with 4.7 and trunk). I could even reduce it a bit more: > cat m1.f95 module solver_2D_m use adv_m class(adv_t), pointer :: adv end module > cat m2.f95 module adv_m type :: adv_t end type end module > cat m12.f95 #include "m1.f95" #include "m2.f95" > cat trigger.sh #!/bin/bash gfortran-4.8 -c m2.f95 gfortran-4.8 -cpp -c m12.f95 The error on the second line only happens if the module file of 'adv_m' is present (created by the first line). The example seems very 'constructed' to me. Does it have any practical relevance to you?
[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54880 --- Comment #2 from Sylwester Arabas 2012-10-12 09:48:12 UTC --- Hi, I've came across it after simply switching the order of module definitions in a file (i.e. no preprocessor - I've used the preprocessor to simplify the test case). I would then answer: definitely YES! - fixing it might save someone a lot of time. Due to the ICE, and due the fact that the presence of the .mod file influences gfortran's behaviour here, figuring out what's wrong is really tricky and time consuming. Sylwester
[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54880
--- Comment #3 from janus at gcc dot gnu.org 2012-10-12 12:52:02 UTC ---
One way to get rid of the error is to simply remove the assert that causes it
(which was already constrained by Paul for PR43450). However, I'm not sure if
that's justified.
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 192392)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -4006,15 +4006,6 @@ gfc_create_module_variable (gfc_symbol * sym)
decl = sym->backend_decl;
gcc_assert (sym->ns->proc_name->attr.flavor == FL_MODULE);
- /* -fwhole-file mixes up the contexts so these asserts are unnecessary.
*/
- if (!(gfc_option.flag_whole_file && sym->attr.use_assoc))
-{
- gcc_assert (TYPE_CONTEXT (decl) == NULL_TREE
- || TYPE_CONTEXT (decl) == sym->ns->proc_name->backend_decl);
- gcc_assert (DECL_CONTEXT (TYPE_STUB_DECL (decl)) == NULL_TREE
- || DECL_CONTEXT (TYPE_STUB_DECL (decl))
- == sym->ns->proc_name->backend_decl);
-}
TYPE_CONTEXT (decl) = sym->ns->proc_name->backend_decl;
DECL_CONTEXT (TYPE_STUB_DECL (decl)) = sym->ns->proc_name->backend_decl;
gfc_module_add_decl (cur_module, TYPE_STUB_DECL (decl));
[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54880 --- Comment #4 from janus at gcc dot gnu.org 2012-10-12 14:19:37 UTC --- (In reply to comment #3) > One way to get rid of the error is to simply remove the assert that causes it > (which was already constrained by Paul for PR43450). However, I'm not sure if > that's justified. At least it does not introduce any regressions in the testsuite.
[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54880 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-15 Ever Confirmed|0 |1
