From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18916 invoked by alias); 15 Nov 2007 20:25:17 -0000 Received: (qmail 18596 invoked by uid 22791); 15 Nov 2007 20:25:15 -0000 X-Spam-Check-By: sourceware.org Received: from smtp.nildram.co.uk (HELO smtp.nildram.co.uk) (195.112.4.54) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 15 Nov 2007 20:25:09 +0000 Received: from firetop.home (84-12-20-70.dyn.gotadsl.co.uk [84.12.20.70]) by smtp.nildram.co.uk (Postfix) with ESMTP id CF6FD2B635C; Thu, 15 Nov 2007 20:25:03 +0000 (GMT) Received: from richard by firetop.home with local (Exim 4.63) (envelope-from ) id 1IslGs-00015L-Sq; Thu, 15 Nov 2007 20:25:06 +0000 From: Richard Sandiford To: Thiemo Seufer Mail-Followup-To: Thiemo Seufer ,"Joseph S. Myers" , binutils@sourceware.org, rsandifo@nildram.co.uk Cc: "Joseph S. Myers" , binutils@sourceware.org Subject: Re: [PATCH] MIPS: Add a GNU attribute for -mips32 -mfp64 objects References: <20071114202400.GT8363@networkno.de> <20071115004530.GU8363@networkno.de> Date: Thu, 15 Nov 2007 20:25:00 -0000 In-Reply-To: <20071115004530.GU8363@networkno.de> (Thiemo Seufer's message of "Thu\, 15 Nov 2007 00\:45\:30 +0000") Message-ID: <87k5ojl0il.fsf@firetop.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00179.txt.bz2 Thiemo Seufer writes: > Joseph S. Myers wrote: >> On Wed, 14 Nov 2007, Thiemo Seufer wrote: >> >> > While I wrote this patch I noticed that the tagging takes only place >> > when the respective gnu_attribute is found in the source code. This >> > leaves objects created from assembly untagged. I wonder if it is a good >> > idea to generally add a FP ABI attribute, derived from the assembler's >> > command line flags, unless this is overridden by a gnu_attribute >> > directive in the source. Is there a backward compatibility issue I fail >> > to see, or some other effect which makes this a bad idea? >> >> I didn't think the compiler passed the -msoft-float/-mhard-float ABI >> information to the assembler, so this could cause problems with incorrect >> tagging when older compilers are used with newer assemblers. > > The compiler currently doesn't pass down the -m*-float options. So > the assembler won't see the option, and therefore won't tag the object. > The -mfp64 is passed, but it is AFAICS unlikely to generate invalid > tagging: Presumably the reason to use the compiler's -mfp64 option is > to generate 64-bit FP code, which isn't compatible to the other variants > as soon as e.g. a mfhc1 instruction is used. > > The idea is to pass the relevent options to the assembler (at least for > .s/.S source files, for compiler generated files it would be redundant). I agree with Joseph here. Although it's redundant to specify -mfp64 with -msoft-float, it isn't actively wrong. The options have traditionally been orthogonal. I don't think the assembler should assume that -mfp64 implies -mhard-float. I agree that it's a good idea to make -mfp64 -mgp32 a separate value for the existing attribute (rather than introducing a new attribute, say). But at the moment, only the compiler or assembly programmer knows the right value for the attribute. FWIW, I think it would be perfectly OK to add an extra case to gcc's attribute code now, even though we're in stage 3. I'll volunteer to do that if you don't have a patch already. Richard