From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11901 invoked by alias); 9 Jun 2011 17:16:18 -0000 Received: (qmail 11480 invoked by uid 22791); 9 Jun 2011 17:16:16 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 09 Jun 2011 17:16:02 +0000 From: "yufeng at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/46003] cond5.C fails for ARM EABI tests. X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: yufeng at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: yufeng at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Thu, 09 Jun 2011 17:16:00 -0000 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: 2011-06/txt/msg00788.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46003 Yufeng Zhang changed: What |Removed |Added ---------------------------------------------------------------------------- CC|yufeng.zhang at arm dot com | --- Comment #8 from Yufeng Zhang 2011-06-09 17:15:14 UTC --- (In reply to comment #6) > Shouldn't this be fixed by the commit of PR c++/49134 ? (In reply to comment #7) > Test g++.dg/template/cond5.C starts passing for arm-none-linux-gnueabi with > r174682, the fix for PR49134 mentioned in comment 6. Thanks for pointing out the related bug fix. The test case g++.dg/template/cond5.C indeed starts 'passing' now, as the fix for PR c++/49134 has essentially loosened the same checking where assertion had blown up. I'll spend some more time looking into the underlying issue and put more information here later. If it turns out to be necessary, I'll close this bugzilla and open a new one for it.