This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/37992] ICE while resolving charlen for rejected statements
- From: "mikael at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 5 Nov 2008 17:02:25 -0000
- Subject: [Bug fortran/37992] ICE while resolving charlen for rejected statements
- References: <bug-37992-13404@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #7 from mikael at gcc dot gnu dot org 2008-11-05 17:02 -------
(In reply to comment #6)
> It should not be necessary to do anything to the cl_list. As long as nothing
> points to a member, it can do nothing and gets cleaned up at the end of
> compilation. The reason for this is that any number, including zero, of
> typespecs can point to it, so it is very risky to delete a cl_list member.
Yes, but as we remove elements in the reject_statement function, any typespec
pointing to it should have been released already (as long as we remove new
elements only).
Patch coming. I don't know why it didn't work the first time.
>
> Paul
>
> Paul
>
No need to insist, we know it's you :p
This is not a regression, I have this failing as well with 4.3.2:
function foo(x)
integer :: x
character(len=10) :: y
character(len=len(y)) :: foo,x
end function foo
Changing summary, from:
[4.4 Regression] ICE segfault for "character(len=len(x)) :: foo,x"
to:
ICE while resolving charlen for rejected statements
--
mikael at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[4.4 Regression] ICE |ICE while resolving charlen
|segfault for |for rejected statements
|"character(len=len(x)) :: |
|foo,x" |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992