From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19020 invoked by alias); 13 Jan 2011 18:51:27 -0000 Received: (qmail 19010 invoked by uid 22791); 13 Jan 2011 18:51:27 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_IV X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 13 Jan 2011 18:51:21 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id F3066CB024D; Thu, 13 Jan 2011 19:51:18 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sSISXw1BsSd; Thu, 13 Jan 2011 19:51:18 +0100 (CET) Received: from [192.168.1.2] (bon31-9-83-155-120-49.fbx.proxad.net [83.155.120.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id D099BCB020C; Thu, 13 Jan 2011 19:51:18 +0100 (CET) From: Eric Botcazou To: Richard Henderson Subject: Re: [patch] Fix PR middle-end/46894 Date: Thu, 13 Jan 2011 18:57:00 -0000 User-Agent: KMail/1.9.9 Cc: gcc-patches@gcc.gnu.org References: <201101131720.52843.ebotcazou@adacore.com> <201101131814.20674.ebotcazou@adacore.com> <4D2F3FBB.1080900@redhat.com> In-Reply-To: <4D2F3FBB.1080900@redhat.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <201101131947.42178.ebotcazou@adacore.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-01/txt/msg00871.txt.bz2 > How's that? If S_D_O is not defined here, then the ifdef would not have > triggered before either. Or do you simply mean that we're currently > always aligning, perhaps hiding problems with the default definition of > S_D_O from function.c? Yes, I thought this was clear enough in the chunk of text you quoted, but re-reading it, this might indeed have been ambiguous. To rephrase, since 2003-10-07 Geoffrey Keating * function.c (pad_to_arg_alignment): Take STACK_POINTER_OFFSET into account when aligning arguments. * calls.c (STACK_POINTER_OFFSET): Move default from here ... * defaults.h (STACK_POINTER_OFFSET): ... to here. STACK_POINTER_OFFSET has always been defined, so we have always aligned in allocate_dynamic_stack_space. On the 4.5 branch there is in defaults.h: #ifndef STACK_POINTER_OFFSET #define STACK_POINTER_OFFSET 0 #endif and in allocate_dynamic_stack_space: #if defined (STACK_DYNAMIC_OFFSET) || defined (STACK_POINTER_OFFSET) #define MUST_ALIGN 1 #else #define MUST_ALIGN (PREFERRED_STACK_BOUNDARY < BIGGEST_ALIGNMENT) #endif if (MUST_ALIGN) { size = force_operand (plus_constant (size, BIGGEST_ALIGNMENT / BITS_PER_UNIT - 1), NULL_RTX); if (flag_stack_usage_info) stack_usage_size += BIGGEST_ALIGNMENT / BITS_PER_UNIT - 1; known_align_valid = false; } [...] if (MUST_ALIGN) { /* CEIL_DIV_EXPR needs to worry about the addition overflowing, but we know it can't. So add ourselves and then do TRUNC_DIV_EXPR. */ target = expand_binop (Pmode, add_optab, target, GEN_INT (BIGGEST_ALIGNMENT / BITS_PER_UNIT - 1), NULL_RTX, 1, OPTAB_LIB_WIDEN); target = expand_divmod (0, TRUNC_DIV_EXPR, Pmode, target, GEN_INT (BIGGEST_ALIGNMENT / BITS_PER_UNIT), NULL_RTX, 1); target = expand_mult (Pmode, target, GEN_INT (BIGGEST_ALIGNMENT / BITS_PER_UNIT), NULL_RTX, 1); } -- Eric Botcazou