From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <binutils-return-46439-listarch-binutils=sources.redhat.com@sourceware.org>
Received: (qmail 17681 invoked by alias); 15 Jun 2006 15:03:52 -0000
Received: (qmail 17673 invoked by uid 22791); 15 Jun 2006 15:03:51 -0000
X-Spam-Check-By: sourceware.org
Received: from smtp102.sbc.mail.mud.yahoo.com (HELO smtp102.sbc.mail.mud.yahoo.com) (68.142.198.201)     by sourceware.org (qpsmtpd/0.31) with SMTP; Thu, 15 Jun 2006 15:03:50 +0000
Received: (qmail 82018 invoked from network); 15 Jun 2006 15:03:48 -0000
Received: from unknown (HELO lucon.org) (hjjean@sbcglobal.net@71.146.67.96 with login)   by smtp102.sbc.mail.mud.yahoo.com with SMTP; 15 Jun 2006 15:03:48 -0000
Received: by lucon.org (Postfix, from userid 1000) 	id 5E97163EEC; Thu, 15 Jun 2006 08:03:47 -0700 (PDT)
Date: Thu, 15 Jun 2006 15:15:00 -0000
From: "H. J. Lu" <hjl@lucon.org>
To: Paul Brook <paul@codesourcery.com>
Cc: binutils@sourceware.org, Nick Clifton <nickc@redhat.com>
Subject: Re: PATCH: Add --alt-nops=short|long to x86/x86-64 assemblers
Message-ID: <20060615150347.GD7470@lucon.org>
References: <20060613190254.GB21884@lucon.org> <20060614172000.GA31328@lucon.org> <449111FC.8010909@redhat.com> <200606151544.12026.paul@codesourcery.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200606151544.12026.paul@codesourcery.com>
User-Agent: Mutt/1.4.2.1i
Mailing-List: contact binutils-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:binutils-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/binutils/>
List-Post: <mailto:binutils@sourceware.org>
List-Help: <mailto:binutils-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: binutils-owner@sourceware.org
X-SW-Source: 2006-06/txt/msg00248.txt.bz2

On Thu, Jun 15, 2006 at 03:44:11PM +0100, Paul Brook wrote:
> > > Maybe I should add -march= and -mtune= to assembler.
> >
> > It sounds like it would be a good idea, although if it is only to
> > support this new feature then you may not want to go that far.
> 
> FWIW I've found it more useful to add .cpu and/or .arch assembly directives. 
> Handling the gcc spec strings for commandline controls and making sure the 
> gcc and gas defaults are consistent can get painful, especially if gcc has 
> several different ways of specifying the cpu variant.

x86/x86-64 assembler support .arch. But I don't think gcc uses it. I
am not sure how well it will work with existing code bases if gcc
starts generating .arch.


H.J.