From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6916 invoked by alias); 29 Aug 2007 14:37:30 -0000 Received: (qmail 6504 invoked by uid 22791); 29 Aug 2007 14:37:28 -0000 X-Spam-Check-By: sourceware.org Received: from scrub.xs4all.nl (HELO scrub.xs4all.nl) (194.109.195.176) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 29 Aug 2007 14:37:23 +0000 Received: from roman (helo=localhost) by scrub.xs4all.nl with local-esmtp (Exim 3.36 #1 (Debian)) id 1IQOg2-0007lj-00; Wed, 29 Aug 2007 16:37:50 +0200 Date: Wed, 29 Aug 2007 14:57:00 -0000 From: Roman Zippel To: Kazu Hirata cc: gcc-patches@gcc.gnu.org, law@redhat.com, schwab@suse.de, nathan@codesourcery.com Subject: Re: [patch] m68k: Fix binary compatibility problem with -mno-strict-align. (Take 2) In-Reply-To: <200708251536.l7PFa18t031289@sparrowhawk.codesourcery.com> Message-ID: References: <200708251536.l7PFa18t031289@sparrowhawk.codesourcery.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: 2007-08/txt/msg02082.txt.bz2 Hi, On Sat, 25 Aug 2007, Kazu Hirata wrote: > Hi, > > Attached is a revised patch to fix binary compatibility problem with > -mno-strict-align on m68k-elf. > > The previous iteration of this patch is at: > > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01437.html > > In this iteration, Nathan has made a change to effectively comment out > TARGET_RETURN_IN_MEMORY and m68k_return_in_memory if > M68K_HONOR_TARGET_STRICT_ALIGNMENT is defined. This way, this patch > has no effect on m68k-linux, preserving the ABI. Looking at this a little closer, I'm not sure why this is related to alignment in first place. Whether a structure is returned in a register should be controlled by -fpcc-struct-return/-freg-struct-return and the DEFAULT_PCC_STRUCT_RETURN value in the config. In function.c:aggregate_value_p there is shortly after the return_in_memory hook the following test: if (flag_pcc_struct_return && AGGREGATE_TYPE_P (type)) return 1; IMO the alignment should have no influence here, so where is this coming from? Looking at the default value of DEFAULT_PCC_STRUCT_RETURN: $ grep DEFAULT_PCC_STRUCT_RETURN gcc/*.c gcc/config/m68k/*.h gcc/toplev.c:#ifndef DEFAULT_PCC_STRUCT_RETURN gcc/toplev.c:#define DEFAULT_PCC_STRUCT_RETURN 1 gcc/toplev.c:int flag_pcc_struct_return = DEFAULT_PCC_STRUCT_RETURN; gcc/config/m68k/linux.h:#define DEFAULT_PCC_STRUCT_RETURN 0 gcc/config/m68k/m68kemb.h:#define DEFAULT_PCC_STRUCT_RETURN 0 gcc/config/m68k/netbsd-elf.h:#undef DEFAULT_PCC_STRUCT_RETURN gcc/config/m68k/netbsd-elf.h:#define DEFAULT_PCC_STRUCT_RETURN 1 gcc/config/m68k/openbsd.h:#define DEFAULT_PCC_STRUCT_RETURN 0 m68k-elf includes m68kemb.h, which sets this to 0, so why isn't this honored? bye, Roman