From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16585 invoked by alias); 18 Oct 2008 17:03:29 -0000 Received: (qmail 16420 invoked by alias); 18 Oct 2008 17:02:06 -0000 Date: Sat, 18 Oct 2008 17:03:00 -0000 Message-ID: <20081018170206.16419.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dick dot hendrickson at gmail dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-10/txt/msg01213.txt.bz2 ------- Comment #11 from dick dot hendrickson at gmail dot com 2008-10-18 17:02 ------- Subject: Re: wrong result for vector subscripted array expression in MVBITS Also, MVBITS is a special case. See the top of page 215 in the F95 standard. The FROM and TO arguments are allowed to be the same variable. The other thing about overlapping variables is (2) on page 205, which is a long way from the section header and is often overlooked (at least I missed it once). I'm off to help paint my granddaughter's bedroom, so I can't think much about this. Somewhere, along time ago, there was a smallish test program of the form subroutine xxx(a,b) b = b+1 print *, a,b end and then a ton of call statements of the forms a = 99 call xxx ((a),a) or call xxx( 1*a,a) or call xxx(a+0, a) ... which might be a good thing to invent as a way to check that you aren't oversimplifing actual expressions. Dick Hendrickson On Sat, Oct 18, 2008 at 6:36 AM, burnus at gcc dot gnu dot org wrote: > > > ------- Comment #10 from burnus at gcc dot gnu dot org 2008-10-18 11:36 ------- > Somehow reading the bug report first before replying helps ... Ignore the crap > I just wrote. > > Dick's (comment 0) > CALL MVBITS ((ILA1(NFV3)), 2, 4, ILA1, 3) !fails > is valid as the first and the fourth argument don't refer to the same variable > - the first argument is an expression for which a temporary needs to be > created. > > Ditto for FX's (comment 1) > call mvbits ((ILA1((/9/))), 2, 4, ILA1, 3) > > However, comment 7's > CALL copy (a((/ 2, 1 /)), a) > is wrong as one passes twice the same variable - once as array section and once > as whole array. There an outer ( ... ) is missing which is needed to makes this > an expression. > > For a lengthy answer including where to find it in the standard, see: > > http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/160867d13fd90927/ > > > Seemingly somewhere (x) is simplified to x (= EXPR_VARIABLE) and thus no > temporary is created - or something like that. For non-elemental procedures > this was fixed in gfortran 4.3; before foo((x),x) was optimized to foo((x),x). > > One can probably ignore all examples after comment 1 and start with looking why > no temporary is created for comment 1 - afterwards one needs to check comment > 0. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681