Hi, >> here is a patch for an ICE-on-invalid bug, which concerns the >> allocation of CLASS variables. The ICE is fixed by changing the order >> of the checks which are done in gfc_match_allocate, so that an error >> is triggered before the ICE can occur. >> >> Regtested on x86_64-unknown-linux-gnu. Ok for trunk? > > > Okay. Thanks for the patch!
Thanks. Will commit soon. >> [Side note: The piece of code which I'm moving contains a FIXME >> comment, which I don't quite understand, so I'm not sure whether it is >> still valid. It was added by Steve in >> http://gcc.gnu.org/viewcvs?view=revision&revision=145331. Does anyone >> have an opinion on this?] > > > Good question. I read the FIXME such that one still needs to add a > diagnostic for a%comp and nonalloc_array(4,4). Though, one can also read it > the other way round. I tend to read it the other way round, but that reading does not really make sense to me. > In any case, for those two, it does not trigger but one > gets later (resolve?) the error: > > Error: Allocate-object at (1) must be ALLOCATABLE or a POINTER Then I guess one can just remove the FIXME. > Regarding the error: > > Error: Allocate-object at (1) is neither a nonprocedure pointer nor an > allocatable variable > > I wonder whether one should put parentheses around nonprocedure; I tend to > misread it; namely: > > Error: Allocate-object at (1) is neither a (nonprocedure) pointer nor an > allocatable variable One could also use "... is neither a data pointer ...", which should have the same meaning (there are two kinds of pointers in the Fortran standard: data pointers and procedure pointers). This also fits better the wording in the F08 standard: C628 (R632) Each allocate-object shall be a data pointer or an allocatable variable. A new version of the patch is attached, which removes the FIXME and changes the wording of the error message (will re-check for regressions due to the changed wording). Cheers, Janus
pr52552.diff
Description: Binary data
