Re: [patch,fortran] Fix ICE in transfert to C_PTR (PR 34199)

[FX Coudert <fxcoudert at gmail dot com>]

*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>