From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 952 invoked by alias); 9 Aug 2011 12:20:12 -0000 Received: (qmail 916 invoked by uid 22791); 9 Aug 2011 12:20:07 -0000 X-SWARE-Spam-Status: No, hits=-2.9 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; Tue, 09 Aug 2011 12:19:54 +0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/49937] [4.7 Regression] g++.dg/tree-ssa/fwprop-align.C X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Status Component AssignedTo 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: Tue, 09 Aug 2011 12:20: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-08/txt/msg00933.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49937 Richard Guenther changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Component|middle-end |tree-optimization AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #3 from Richard Guenther 2011-08-09 12:19:20 UTC --- The folding happens (and is supposed to happen) in CCP for x86_64 (that was the idea when removing the forwprop duplicate, which has correctness issues, instead of "fixing" it). CCP uses get_value_from_alignment, the difference between x86_64 and the cross is: Visiting statement: D.2090_3 = (long int) foo; which is likely CONSTANT Lattice value changed to CONSTANT Lattice value changed to CONSTANT 0x00000000000000000 (0xfffffffffffffffffffffffffffffffe). Adding SSA edges to worklist. Visiting statement: D.2091_4 = D.2090_3 & 1; which is likely CONSTANT Lattice value changed to CONSTANT 0. Adding SSA edges to worklist. vs. cris: Visiting statement: D.1722_3 = (long int) foo; which is likely CONSTANT Lattice value changed to VARYING. Adding SSA edges to worklist. Visiting statement: D.1723_4 = D.1722_3 & 1; which is likely CONSTANT Lattice value changed to CONSTANT Lattice value changed to CONSTANT 0x00000000000000000 (0x00000000000000001). Adding SSA edges to worklist. which is because else if (base && ((align = get_object_alignment (base, BIGGEST_ALIGNMENT)) > BITS_PER_UNIT)) even though the FUNCTION_DECL has align 16, BIGGEST_ALIGNMENT is 8 on cris (which means we can't rely on any DECL_ALIGN or other stuff get_object_alignment uses if it is bigger than that value?). Thus, the get_object_alignment_1 hunk if (DECL_P (exp) && TREE_CODE (exp) != LABEL_DECL) { if (TREE_CODE (exp) == FUNCTION_DECL) { /* Function addresses can encode extra information besides their alignment. However, if TARGET_PTRMEMFUNC_VBIT_LOCATION allows the low bit to be used as a virtual bit, we know that the address itself must be 2-byte aligned. */ if (TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_pfn) align = 2 * BITS_PER_UNIT; else align = BITS_PER_UNIT; } is non-functional for cris. >>From looking at the docs for BIGGEST_ALIGNMENT I wonder why we use that for all callers of get_object_alignment and not, for example, MAX_OFILE_ALIGNMENT? CCP certainly doesn't care - as long as it can trust the value returned. CCP wants to use get_object_alignment_1 anyway. hp, can you maybe answer the question about correctness for aligns bigger than BIGGEST_ALIGNMENT? And eventually audit other callers?