https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118705
--- Comment #3 from kargls at comcast dot net ---
(In reply to Ryan Koehler from comment #2)
> Hmm that is interesting.
>
> That fix seemed to work. Its been a while since I read the ISO standard, but
> I don't think what I sent over is out-of-spec. I do really appreciate that
> you found a really simple solution to unblock me in the short term. I am
> getting another internal compiler error though. Ill get that error isolated
> and submitted in another ticket.
You're welcome. Sorry about the issue. I don't use the 'module'
prefix in my own code. I would have thought that an import
statement is needed, like below
module heading_mod
use classification_mod, only: classification_t
implicit none
private
public :: HEADING
interface
module subroutine HEADING (class_)
import classification_t
type(classification_t), intent(in) :: class_
end subroutine HEADING
end interface
end module heading_mod
But this leads to an error!
% gfcx -c a.f90
a.f90:33:19:
33 | import classification_t
| 1
Error: F2008: C1210 IMPORT statement at (1) is not permitted in a module
procedure interface body
If I remove the 'module' prefix, then the code refuses to compile
without the import statement! With the import statement, it compiles.
Fun with Fortran!
A quick debug session shows the needed information is available
where the ICE occurs, but a data structure is missing!
(gdb) p *g
$1 = {specific_st = 0x2042703c0, specific = 0x0, next = 0x0,
is_operator = true}
(gdb) p *g->specific_st
$2 = {priority = 6462, left = 0x0, right = 0x0,
name = 0x204a1e6b0 "isprestressed", ambiguous = 0, n = {sym = 0x2042bfa00,
uop = 0x2042bfa00, common = 0x2042bfa00, tb = 0x2042bfa00,
omp_udr = 0x2042bfa00}}
Unfortunately, the code wants to look into g->specific to find
(gdb) (list)
4686 target = g->specific->u.specific->n.sym;
4687
and then it returns g->specific. g->specific_st->n.sym has the
missing information.
