From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19898 invoked by alias); 29 Aug 2007 15:14:51 -0000 Received: (qmail 19847 invoked by uid 22791); 29 Aug 2007 15:14:50 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 29 Aug 2007 15:14:44 +0000 Received: (qmail 300 invoked from network); 29 Aug 2007 15:14:42 -0000 Received: from unknown (HELO ?192.168.1.136?) (kazu@127.0.0.2) by mail.codesourcery.com with ESMTPA; 29 Aug 2007 15:14:42 -0000 Message-ID: <46D58D5B.6070104@codesourcery.com> Date: Wed, 29 Aug 2007 15:26:00 -0000 From: Kazu Hirata User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Roman Zippel 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) References: <200708251536.l7PFa18t031289@sparrowhawk.codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg02089.txt.bz2 Hi Roman, > 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? STRICT_ALIGNMENT affects us in compute_record_mode and default_return_in_memory. (Note that m68k_return_in_memory emulates default_return_in_memory with STRICT_ALIGNMENT 1.) Given a return type, compute_record_mode computes a return mode. If STRICT_ALIGNMENT is 1, compute_record_mode chooses BLKmode for the type. (See the last "if" block in compute_record_mode.) default_return_in_memory simply returns 1 if it sees BLKmode. > 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? When the return mode is BLKmode, we don't get to evaluate flag_pcc_struct_return in aggregate_value_p because targetm.calls.return_in_memory is called earlier. Kazu Hirata