From patchwork Wed Apr 20 06:35:02 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Merrill X-Patchwork-Id: 92091 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 2ECA7B7054 for ; Wed, 20 Apr 2011 16:35:23 +1000 (EST) Received: (qmail 32294 invoked by alias); 20 Apr 2011 06:35:21 -0000 Received: (qmail 32155 invoked by uid 22791); 20 Apr 2011 06:35:21 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 Apr 2011 06:35:03 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p3K6Z2qi017244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 20 Apr 2011 02:35:02 -0400 Received: from [127.0.0.1] (ovpn-113-102.phx2.redhat.com [10.3.113.102]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p3K6Z2fW003254 for ; Wed, 20 Apr 2011 02:35:02 -0400 Message-ID: <4DAE7E96.2000009@redhat.com> Date: Tue, 19 Apr 2011 23:35:02 -0700 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: gcc-patches List Subject: C++ PATCH for c++/46304 (ICE with _Complex) 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 In this bug, the underlying problem was that we had a COMPLEX_EXPR representing a complex constant rather than a COMPLEX_CST. There was also the issue that 4.5 didn't deal with this very well, but fixing the testcase to use COMPLEX_CST (by folding the COMPLEX_EXPR case like we do everything else in cp_build_binary_op) fixes the ICE. Tested x86_64-pc-linux-gnu, applied to trunk, 4.5 and 4.6. commit 58d863dc8ff1f357a7f8f4064c204779a2b2c2eb Author: Jason Merrill Date: Tue Apr 19 17:58:20 2011 -0700 PR c++/46304 * typeck.c (cp_build_binary_op): Fold COMPLEX_EXPR. diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c index 89d3247..dcdc790 100644 --- a/gcc/cp/typeck.c +++ b/gcc/cp/typeck.c @@ -4357,7 +4357,11 @@ cp_build_binary_op (location_t location, gcc_unreachable(); } } - return build2 (COMPLEX_EXPR, result_type, real, imag); + real = fold_if_not_in_template (real); + imag = fold_if_not_in_template (imag); + result = build2 (COMPLEX_EXPR, result_type, real, imag); + result = fold_if_not_in_template (result); + return result; } /* For certain operations (which identify themselves by shorten != 0) diff --git a/gcc/testsuite/g++.dg/ext/complex7.C b/gcc/testsuite/g++.dg/ext/complex7.C new file mode 100644 index 0000000..9d5463f --- /dev/null +++ b/gcc/testsuite/g++.dg/ext/complex7.C @@ -0,0 +1,6 @@ +// { dg-options "" } + +class A +{ + static const _Complex double x = 1.0 + 2.0i; +};