Hi,

Janus Weil wrote:
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!

[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. 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

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


Tobias

2012-06-08  Janus Weil  <ja...@gcc.gnu.org>

        PR fortran/52552
        * match.c (gfc_match_allocate): Modify order of checks.


2012-06-08  Janus Weil  <ja...@gcc.gnu.org>

        PR fortran/52552
        * gfortran.dg/allocate_with_typespec_7.f90: New test case.

Reply via email to