[patch,fortran] Fix ICE in transfert to C_PTR (PR 34199)
FX Coudert
fxcoudert@gmail.com
Sun Mar 23 16:39:00 GMT 2008
*ping*
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00546.html
Le 8 mars 08 à 19:09, FX Coudert a écrit :
> The attached patch fixes PR 34199, an ICE when we try to simplify a
> TRANSER whose return type is a C_PTR. I was a bit reluctant to
> submit it for review, and wanted someone else's opinion, but
> Christopher doesn't contribute anymore and Tobias is quite busy,
> and they're the ISO_C_BINDING experts :)
>
> Well, anyway: the trans-types.c and trans-expr.c are, I think, real
> fixes that need to go in. The first one sets the DECL_FIELD_OFFSET
> of the private component of the ISO_C_BINDING derived types: it
> should be set to zero, IMHO, otherwise the front-end can later have
> problems dealing with the RECORD_TYPE we've created. The second one
> deals with assignments of the form VAR = CONST, where CONST is a
> constant of one of the ISO_C_BINDING derived types. This doesn't
> happen often, but it does once we simplify TRANSFER, so it should
> be included in that if() condition (current behaviour is to fall
> into the wrong arm of the if-else, and ICE).
>
> The target-memory.c is a bit more of a hack. (I've added a comment
> to document it as such and reference the PR.) The way ISO_C_BINDING
> privates types are implemented, there is a special bit of code in
> gfc_typenode_for_spec() that changes the typespec under the feet of
> its caller, to automagically convert the derived type into its
> integer private component. I had forgotten that we do that (I knew
> it when we evaluated the ISO_C_BINDING code in the first place),
> and trankly I'm surprised it doesn't cause more errors elsewhere.
> But, in that particular case, if we change the typespec in the
> middle of simplifying TRANSFER, we'll just take incoherent
> codepaths in target-memory.c and ICE. So the hack is: before
> calling gfc_typenode_for_spec(), we store the derived type typespec
> and restore it after the call. (But still keep the typenode as an
> integer, and not a derived type, otherwise it fails later).
>
> I'm sorry this submission is so long, but I wanted the reviewer to
> be able to get a feeling of what I'm proposing, because I think
> it's only a hack (though probably quite a resistant one) and not a
> proper fix.
>
> Regtested on x86_64-linux, OK for mainline?
>
> FX
>
>
> --
> François-Xavier Coudert
> http://www.homepages.ucl.ac.uk/~uccafco/
> <pr34199.ChangeLog><pr34199.diff>
More information about the Gcc-patches
mailing list