This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/38863] WHERE with multiple elemental defined assignments gives wrong answer
- From: "dick dot hendrickson at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 18 Jan 2009 21:37:06 -0000
- Subject: [Bug fortran/38863] WHERE with multiple elemental defined assignments gives wrong answer
- References: <bug-38863-15620@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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