This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]