This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: PR33749 - Wrong evaluation of expressions in lhs of assignment statements
- From: "Paul Richard Thomas" <paul dot richard dot thomas at gmail dot com>
- To: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, "Paul Brook" <paul at codesourcery dot com>
- Date: Sun, 14 Oct 2007 18:53:38 +0200
- Subject: Re: PR33749 - Wrong evaluation of expressions in lhs of assignment statements
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=KHlP/0KsYnS2OqXRR/3RTMb5zttIiQCZAYEGB/wnP8g=; b=lLIaC3O26WoE0V5zM22WwNeEXA6D1drUSlLnkAE0Nj3u3UqJvgNN5li0sS9QprpoP9kgt2BilvMr2OsjVUZlW0yrAhcVyz4Uas2Fl64DlmgPDpI3bBKLQZKi9uWG8KbEg8yQVj/PjTKDIV+RfhgzHl1e0Ycro35cMmsmJuYRc5U=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QvBI65VxncvAgcz7O2hVFOWTpU/8xrMAxrMOiA078tbEYmHXwvnarcl4yjKxx1PnSSDvdpcH31Liz7WtHDxj5M87N9rzm9M6uVlZaEr3VWN+gjhbpdlasHDKxqw5R7B2uU0EEM5mtLNFM576p8t5Q6espZZUe29omwGfwhlxeNw=
- References: <339c37f20710121221r132b7aa2y6a44c9ca4de21cf5@mail.gmail.com>
Dear All,
> This bug only appears in -m32 or, rather, it disappears in -m64. What
> is odd is that an entire block of code produced by the scalarizer
> appears and disappears according to the mode. What is even odder is
> that I cannot even figure out how the correct code is ever produced.
>
> This:
>
> integer(4) :: p(4) = (/2,4,1,3/)
> p(p) = (/(i, i = 1, 4)/)
> print *, p
> end
The problem is that the expression for the index in p(p) gets
correctly identified as a variable in -m32 but becomes a function in
-m64. The latter causes need_tmp to be set, which than "corrects"
this problem.
I have a patch for PR33749 but will have to fix the above first,
otherwise it will lurk undetected and get us in other ways. I wonder
how often unnecessary temporaries are created in -m64?
Cheers
Paul