Bug 54880 - [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013
Summary: [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.8.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2012-10-09 21:09 UTC by Sylwester Arabas
Modified: 2012-10-15 11:20 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-10-15 00:00:00


Attachments
testcase to trigger the ICE (546 bytes, application/x-gzip)
2012-10-09 21:09 UTC, Sylwester Arabas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sylwester Arabas 2012-10-09 21:09:44 UTC
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 
module solver_2D_m
  use adv_m
  type :: solver_2D_t
    class(adv_t), pointer :: adv
    contains
  end type 
  contains
  subroutine solver_2D_solve(this)
    class(solver_2D_t) :: this
  end subroutine
end module


$ cat m2.f95 
module adv_m
  type, abstract :: adv_t
    contains
    procedure(op_2D_i), deferred :: op_2D
  end type
  abstract interface
    subroutine op_2D_i(this)
      import :: adv_t
      class(adv_t) :: this
    end subroutine
  end interface
end module


$ cat m12.f95 
#include "m1.f95"
#include "m2.f95"


$ cat m21.f95 
#include "m2.f95"
#include "m1.f95"
program m21
end


$ cat trigger.sh 
#!/bin/bash
/usr/lib/gcc-snapshot/bin/gfortran -cpp m21.f95
/usr/lib/gcc-snapshot/bin/gfortran -cpp m12.f95


$ ./trigger.sh 
m1.f95:10:0: internal compiler error: in gfc_create_module_variable, at fortran/trans-decl.c:4013
   end subroutine
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-snapshot/README.Bugs> for instructions.
Comment 1 janus 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?
Comment 2 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
Comment 3 janus 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));
Comment 4 janus 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.