On *-apple-darwin9, revision 135821, but also gfortran 4.3.0, I get:

pr36316.f90:52.5:

ZTEMP = PVAZG * SCALP_DV
    1
Error: Incompatible ranks 0 and 1 in assignment at (1)

Same thing with ifort 10.1 and g95.

Same here. With gfortran 4.1, 4.2 and 4.3 of openSUSE and with today's builds of 4.2, 4.3 and 4.4 I get the error message. Also valgrind does not show any problems.

Ugh, sorry, I see I included the wrong source.

Here's the correct one:

MODULE YOMCAIN

IMPLICIT NONE
SAVE

TYPE distributed_vector
REAL, pointer :: local(:)
INTEGER       :: global_length,local_start,local_end,nchnks
END TYPE distributed_vector

INTERFACE ASSIGNMENT (=)
MODULE PROCEDURE assign_ar_dv
END INTERFACE

INTERFACE OPERATOR (*)
MODULE PROCEDURE multiply_dv_dv
END INTERFACE

CONTAINS

SUBROUTINE assign_ar_dv (handle,pvec)

!         copy array to the distributed_vector

REAL,                      INTENT(IN)    :: pvec(:)
TYPE (distributed_vector), INTENT(INOUT) :: handle

handle%local(:) = pvec(:)

RETURN
END SUBROUTINE assign_ar_dv

FUNCTION multiply_dv_dv (handle1,handle2)

!         multiply two distributed_vectors

TYPE (distributed_vector), INTENT(IN) :: handle2
TYPE (distributed_vector), INTENT(IN) :: handle1
REAL, DIMENSION(handle1%local_start:handle1%local_end) ::multiply_dv_dv

multiply_dv_dv = handle1%local(:) * handle2%local(:)

RETURN
END FUNCTION multiply_dv_dv


SUBROUTINE CAININAD_SCALE_DISTVEC ()
TYPE (distributed_vector) :: PVAZG
TYPE (distributed_vector) :: ZTEMP
TYPE (distributed_vector) :: SCALP_DV

ZTEMP = PVAZG * SCALP_DV
END SUBROUTINE CAININAD_SCALE_DISTVEC
END MODULE YOMCAIN

Apologies ...

CONFIRM. Due to the missing checking it works with openSUSE's 4.1, 4.2, 4.3; however, if one studies the source code, it is also wrong in other 4.x besides 4.4. The current test case fails only on systems where c_intptr_t == 8, but it can easily be modified to show the same problem on c_intptr_t == 4 systems by changing in

  INTEGER       :: global_length,local_start,local_end,nchnks
END TYPE distributed_vector

INTEGER into INTEGER(8) (which in turn fixes the program in -m64 systems).


The original dump shows the problem:

caininad_scale_distvec ()
    integer(kind=8) D.1027;
    integer(kind=4) D.1026;
    integer(kind=4) D.1025;
    D.1023 = &pvazg;
    D.1025 = D.1023->local_start;
    D.1026 = D.1023->local_end;
    D.1027 = D.1026 - D.1025;  // which is integer(8) = integer(4) - integer(4)


D.1023->local_start; and D.1023->local_end; are used in:

  REAL, DIMENSION(handle1%local_start:handle1%local_end) ::multiply_dv_dv

Somewhere a 
  fold_convert (TREE_TYPE (to_tree), from_tree)
is missing, but I fail to see where. I think one could add a couple of those in trans-array.c; I think there is more than one missing.

(In reply to comment #5)
> Somewhere a 
>   fold_convert (TREE_TYPE (to_tree), from_tree)
> is missing, but I fail to see where. I think one could add a couple of those in
> trans-array.c; I think there is more than one missing.

An easy thing to do is to set a breakpoint in gfc_create_var or whatever routine creates these temporary variables, and hit 'c' under gdb until you have the correct D.number; then, the backtrace will tell you where it's created (and it's usually assigned to close to that).

Found it - took only 4 hours.
FIXED on the trunk (4.4.0). Thanks for reporting the bug.

Subject: Bug 36316

Author: burnus
Date: Tue May 27 19:22:01 2008
New Revision: 136052

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136052
Log:
2008-05-27  Tobias Burnus  <burnus@net-b.de>

        PR fortran/36316
        * trans-array.c (gfc_set_loop_bounds_from_array_spec):
        Add missing fold_convert.

2008-05-27  Tobias Burnus  <burnus@net-b.de>

        PR fortran/36316
        * gfortran.dg/assignment_3.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/assignment_3.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/testsuite/ChangeLog