This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
- From: "tkoenig at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 14 Jan 2011 19:43:04 +0000
- Subject: [Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
- Auto-submitted: auto-generated
- References: <bug-38536-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
Thomas Koenig <tkoenig at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #20 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2011-01-14 19:42:58 UTC ---
(In reply to comment #19)
>
> Similarly, c_loc(comp(1:2)%elem) is valid as long as "elem" is the only item in
> the derived type *and* no padding is happening. (As padding often occurs, one
> could always reject it.)
I don't think so, at least not in F 2003. comp(1:2) is an array slice,
which is never interoperable. The language in F 2008 appears unchanged,
so I guess the same applies there.
> And comp(1:1)%elem is always contiguous - but that's also a strange way of
> writing it. (Actually, I think that comp(1:1)%elem _is_ simply contiguous -
> though I am not sure gfc_simply_contiguous does detect this.)
That would be fairly easy to change. Can you open a PR for this?