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

[FX Coudert <fxcoudert at gmail dot com>]

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/

Attachment: pr34199.ChangeLog
Description: Binary data

Attachment: pr34199.diff
Description: Binary data