This is the mail archive of the gcc-patches@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]

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


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


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