User account creation filtered due to spam.
Created attachment 28405 [details]
testcase to trigger the ICE
Running the attached testcase with the current Debian's gcc-snapshot gfortran I get:
$ cat m1.f95
type :: solver_2D_t
class(adv_t), pointer :: adv
class(solver_2D_t) :: this
$ cat m2.f95
type, abstract :: adv_t
procedure(op_2D_i), deferred :: op_2D
import :: adv_t
class(adv_t) :: this
$ cat m12.f95
$ cat m21.f95
$ cat trigger.sh
/usr/lib/gcc-snapshot/bin/gfortran -cpp m21.f95
/usr/lib/gcc-snapshot/bin/gfortran -cpp m12.f95
m1.f95:10:0: internal compiler error: in gfc_create_module_variable, at fortran/trans-decl.c:4013
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-snapshot/README.Bugs> for instructions.
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
class(adv_t), pointer :: adv
> cat m2.f95
type :: adv_t
> cat m12.f95
> cat trigger.sh
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?
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.
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.
--- 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));
(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.