From patchwork Fri Dec 17 15:38:27 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Kraft X-Patchwork-Id: 75910 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 0F5DA1007D3 for ; Sat, 18 Dec 2010 02:31:27 +1100 (EST) Received: (qmail 4628 invoked by alias); 17 Dec 2010 15:31:23 -0000 Received: (qmail 4611 invoked by uid 22791); 17 Dec 2010 15:31:21 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from tatiana.utanet.at (HELO tatiana.utanet.at) (213.90.36.46) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 17 Dec 2010 15:31:14 +0000 Received: from pam.xoc.tele2net.at ([213.90.36.6]) by tatiana.utanet.at with esmtp (Exim 4.72) (envelope-from ) id 1PTcH1-0007an-DQ; Fri, 17 Dec 2010 16:31:11 +0100 Received: from d86-32-214-183.cust.tele2.at ([86.32.214.183] helo=[192.168.1.18]) by pam.xoc.tele2net.at with esmtpa (Exim 4.72) (envelope-from ) id 1PTcH1-0001uV-A8; Fri, 17 Dec 2010 16:31:11 +0100 Message-ID: <4D0B83F3.2020600@domob.eu> Date: Fri, 17 Dec 2010 16:38:27 +0100 From: Daniel Kraft User-Agent: Thunderbird 2.0.0.0 (X11/20070425) MIME-Version: 1.0 To: Tobias Burnus CC: Fortran List , gcc-patches Subject: Re: [Patch, Fortran] PR fortran/46794: Fix ICE with powers of integers References: <4CF97314.4000206@domob.eu> <4CFA00A1.6020101@net-b.de> In-Reply-To: <4CFA00A1.6020101@net-b.de> Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Tobias Burnus wrote: > Dear Daniel, > > Daniel Kraft wrote: >> I do not entirely like the way this is done in the patch (with the two >> variables and "special casing"), but don't see a better implementation >> -- what do you think? > > I think it is OK - at least I have trouble finding a better solution. > >> Regression-tested on x86_64-unknown-linux-gnu without failures -- >> though the run somehow looked strange to me (on the compile-farm); >> I'll try again to be sure. Ok for trunk? > > OK for the trunk. Can you check whether one needs to likewise for the > 4.5 and 4.4 branch? (I think one should check on source level - the > verify_tree might not always catch it. For some reasons, it ICEs here > with 4.4 and 4.6 but not with 4.5; however, I think that's rather by > chance and not because of a proper casting.) Finally after 4.5 is open again, I committed the attached as test-case fix for 4.5 after a successful test on x86_64-unknown-linux-gnu. Closing the PR now. Daniel Index: gcc/testsuite/gfortran.dg/power2.f90 =================================================================== --- gcc/testsuite/gfortran.dg/power2.f90 (revision 167582) +++ gcc/testsuite/gfortran.dg/power2.f90 (working copy) @@ -13,6 +13,9 @@ INTEGER(KIND=1) :: k1 INTEGER(KIND=2) :: k2 + k1 = 1_1 + k2 = 1_2 + k1 = 1_1 + 1_1**k1 k2 = 1_2 + 1_2**k2