From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18914 invoked by alias); 7 Aug 2010 11:17:41 -0000 Received: (qmail 18899 invoked by uid 48); 7 Aug 2010 11:17:29 -0000 Date: Sat, 07 Aug 2010 11:17:00 -0000 Message-ID: <20100807111729.18898.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/44235] array temporary with high upper bound In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "tkoenig at gcc dot gnu dot org" 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: 2010-08/txt/msg00511.txt.bz2 ------- Comment #7 from tkoenig at gcc dot gnu dot org 2010-08-07 11:17 ------- (In reply to comment #6) Hi Dominique, > It turns out that the test in comment #0 was not fixed by the patch in comment > #5, but by revision 162966. However with the slight change > > a(4:23:3) = a(4:22:3) > > a temporary is still created. The patch in comment #5 avoid temporaries in > situations such as > > a(4:19:3) = a(7:22:3) > a(4:20:3) = a(7:22:3) > a(4:19:3) = a(7:23:3) > nl = 4 > nu = 20 > a(1:16:3) = a(4:nu:3) > a(1:16:3) = a(nl:20:3) > > but not for > > a(1:16:3) = a(nl:nu:3) the only unnecessary temporary still created with current trunk is your first example. I am more in favor of changing the upper bound to its actual value, probably during resolution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44235