This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/38863] WHERE with multiple elemental defined assignments gives wrong answer



------- Comment #2 from dick dot hendrickson at gmail dot com  2009-01-18 21:37 -------
Subject: Re:  WHERE with multiple elemental defined assignments gives wrong
answer

On Sun, Jan 18, 2009 at 2:40 PM, mikael at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #1 from mikael at gcc dot gnu dot org  2009-01-18 20:40 -------
> I suspect the following  is invalid as the arguments to the defined assignment
> alias.
>

Why do you think it is invalid?  I cut this down from a larger program, but the
arguments look good to me.  For what it's worth, the test case compiles
successfully with a different compiler.  The larger program compiles with
several other compilers.

Dick Hendrickson

>      WHERE(LDA)
>        TLA2L = TLA2L(1:3,1:2)%L     !removing this line fixes problem
>        TLA2L = TLA2L(1:3,1:2)%I
>      ELSEWHERE
>        TLA2L = -1
>      ENDWHERE
>
> However, the following is valid (I think):
>
>     module m
>
>     type t
>        integer :: i,j
>     end type t
>
>     interface assignment (=)
>             procedure i_to_t
>     end interface
>
>     contains
>
>     elemental subroutine i_to_t (p, q)
>
>     type(t), intent(out) :: p
>     integer, intent(in)  :: q
>
>     p%i = q
>
>     end subroutine
>
>     end module
>
>     use m
>
>     type(t), target :: a(3)
>     type(t), target  :: b(3)
>
>     type(t), dimension(:), pointer :: p
>     logical :: l(3)
>
>     a%i = 1
>     a%j = 2
>     b%i = 3
>     b%j = 4
>
>     p => b
>     l = .true.
>
>
>     where (l)
>          a = p%i
>     end where
>
>     print *, a%j
>
>     end
>
> The output I get is:
>       32758       32758           0
> instead of:
>           2           2           2
>
>
> The problem is that we create a temporary for the defined assignment, but we
> don't copy the values of the lhs (before calling the function) to it as they
> will be overwritten by the rhs's ones. However, if the assignment function
> doesn't set all the members of the derived type, the unset members keep the
> values of the temporary, and are copied to the lhs.
> Thus, confirmed
>
>
> --
>
> mikael at gcc dot gnu dot org changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|UNCONFIRMED                 |NEW
>     Ever Confirmed|0                           |1
>           Keywords|                            |wrong-code
>   Last reconfirmed|0000-00-00 00:00:00         |2009-01-18 20:40:05
>               date|                            |
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38863
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>


-- 


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]