[Patch, fortran] PR35680 - [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[Dominique Dhumieres]

Paul,

> The symbol_attributes are cleared on allocation.  I did not anticipate
> resetting the flag after use - it is meant to indicate that symbol is
stuffed.  However, this is not right, is it?  It is incorrectly
> referenced and it is really the expression that is not right.  I will
think about this before committing, even though this is the last
> non-darwin9 regression.

I am not sure to fully understand you. The problem I have noticed is exposed
by the following code:

! { dg-do compile }

! PR fortran/35723
! Check that a dummy-argument array with non-restricted subscript is
! rejected and some more reference-checks.

PROGRAM main
  IMPLICIT NONE
  CALL test (5, (/ 1, 2, 3, 4, 5, 6, 7, 8, 9 /), "0123456789" )

CONTAINS

  SUBROUTINE test (n, arr, str)
    IMPLICIT NONE
    INTEGER :: n, arr(:)
    CHARACTER(len=10) :: str

    INTEGER :: i = 5
    INTEGER :: ok1(arr(n)), ok2(LEN_TRIM (str(3:n)))
    INTEGER :: wrong1(arr(i)) ! { dg-error "'i' cannot appear" }
    INTEGER :: wrong2(LEN_TRIM (str(i:n))) ! { dg-error "'i' cannot appear" }
  END SUBROUTINE test

END PROGRAM main

where the second error is not detected. I have checked that if I remove
sym->attr.error=1, the second error reappears (indeed doubled).
This leads me to think that sym->attr.error should be reset to zero
when the statement (or part of the parsing) has been processed.

> I see that I inadvertently fixed PR37319.

As I have reported the failure is gone. If you understand why, could you
say it in the pr and close it.

> On PR36463 - what do we do about it?

I cannot answer this question. However I am not sure that the required
components to compile it (and friends) have been fully implemented
in gfortran (Daniel?).

Cheers

Dominique