[Bug fortran/53576] New: Very unhelpful error message: "Unclassifiable statement" instead of "Can't convert TYPE to ..."

[Bug fortran/53576] New: Very unhelpful error message: "Unclassifiable statement" instead of "Can't convert TYPE to ..."

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53576

             Bug #: 53576
           Summary: Very unhelpful error message: "Unclassifiable
                    statement" instead of "Can't convert TYPE to ..."
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org


The following program is invalid; gfortran rejects it, but with a completely
unhelpful error message. The problem is that the "amn(jj)" should be
"amn%value(jj).


Current error message:

    wfn &
    1
Error: Unclassifiable statement at (1)


Expected error (or something similar):

       = amn(jj)
         1
Error: Can't convert TYPE(amn_t) to COMPLEX(4) at (1)



Note: gfortran prints the proper error message if the loop bound is changed
from "amn%nsites" to, e.g., "5". (That's how I got the type-conversion error
message.)



program simple_wf_op_gen
  type :: amn_t
    integer :: nsites = 0
    complex :: value(1)
  end type amn_t

  type(amn_t) :: amn
  integer :: jj
  complex :: wfn

  do jj = 1, amn%nsites
    wfn &
       = amn(jj)
  end do
end program simple_wf_op_gen

[Bug fortran/53576] Very unhelpful error message: "Unclassifiable statement" instead of "Can't convert TYPE to ..."

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53576

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-10-08
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Still present on trunk (6.0) at r228594.