From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26224 invoked by alias); 27 Sep 2011 11:08:18 -0000 Received: (qmail 26210 invoked by uid 22791); 27 Sep 2011 11:08:16 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_TM 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, 27 Sep 2011 11:08:03 +0000 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/50527] inconsistent vla align Date: Tue, 27 Sep 2011 11:25:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de 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: 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 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-09/txt/msg02021.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527 --- Comment #7 from rguenther at suse dot de 2011-09-27 11:08:01 UTC --- On Tue, 27 Sep 2011, vries at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527 > > --- Comment #6 from vries at gcc dot gnu.org 2011-09-27 10:49:23 UTC --- > > I think we can check if the size is constant in evaluate_stmt and > > compute alignment according to that. > > We can only do that in the last ccp phase that does folding of vla-alllocas. > > If the argument is not constant, it will not be folded in this phase, but it > might be folded during the next ccp phase, when the argument does turn > constant. > > If the argument is constant, it might not be folded in this phase, but it still > might be folded during the next ccp phase. > > Therefore, in evaluate_stmt, we cannot predict whether the alloca will be > folded, unless we're in the last ccp phase. And the propagation of alignment of > alloca starts in the first ccp phase. > > > It should only change from > > non-constant to constant, thus properly go down the lattice during > > propagation. > > Currently, the result of an alloca is always constant, to be precise, constant > 0 with only lower bits valid. This is independent of whether the argument is > constant. The parameter I meant. But yes if we don't fold alloca in ccp1 we might fold away alignment tests based on BIGGEST_ALIGNMENT while later ccp might fold it and use less alignment. Maybe don't assume any particular alignment for allocas for vlas then. Richard.