From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-368768-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 9369 invoked by alias); 26 Sep 2011 14:41:48 -0000
Received: (qmail 9335 invoked by uid 22791); 26 Sep 2011 14:41:47 -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; Mon, 26 Sep 2011 14:41:31 +0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/50527] New: inconsistent vla align
Date: Mon, 26 Sep 2011 14:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-50527-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2011-09/txt/msg01945.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527

             Bug #: 50527
           Summary: inconsistent vla align
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: vries@gcc.gnu.org


Created attachment 25367
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25367
testcase, modified from pr43513.c testcase

To reproduce on x86_64:
...
$ gcc -Os pr43513-align.c --param large-stack-frame=30
$ ./a.out 
16byte aligned
7fff5c4ce00c
...

The address of the vla is printed, and it's not 16-byte aligned (ends in 'c').
Nevertheless the test whether the address is 16-byte aligned succeeds, and the
string '16byte aligned' is printed.

During compilation the following scenario happens:
- During the propagation of the first ccp phase, the align of the alloca (16)
  is progagated to the lhs results.0D.3306_13 as lattice value
  'CONSTANT 0x00000000000000000 (0xfffffffffffffffffffffffffffffff0)'.
- This not propagated through 'D.3307_14 = &*results.0D.3306_13'. The
  propagation does not look at the lattice value of results.0D.3306_13, but at
  the alignment of the ptr_info, which at this point is not initialised yet.
- During the finalize of the first ccp phase, ptr_info of results.0D.3306_13 is
  initialized with align 16, based on the lattice value.
- During the propagation of the second ccp phase, the align of the ptr_info
  of results.0D.3306_13 of 16 is used to propagate through to the comparison
  'if (D.3309_16 == 0)', which makes sure the '16byte aligned' string is
  printed.
- During the finalize of the second ccp phase, the alloca is folded, and
  the new declared array gets an align of 4 bytes.