public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Thomas Fleischmann" <TFleischmann@gmx.de>
To: Dave Korn <dave.korn@artimi.com>, binutils@sourceware.org
Subject: RE: ERROR: already selected `xxxx' processor
Date: Wed, 05 Jul 2006 17:10:00 -0000	[thread overview]
Message-ID: <20060705171012.109040@gmx.net> (raw)
In-Reply-To: <030a01c6a051$2bc87370$a501a8c0@CAM.ARTIMI.COM>

> On 05 July 2006 17:00, Thomas Fleischmann wrote:
> 
> > Whilst the gcc doesn't support our used cpu MCF5213 100%, we use the
> > compilerswitch -m5200 to generate generic code for a MCF52xx. 
> > We also need to use inline assembly for the MCF5213 stuff (movec ...,
> > %rambar). So we have to apply a second compiler switch to be passed to
> gas
> > -Wa,-m5213 (-Wa,-mcpu=5213 for binutils 2.17).  
> > 
> > This is ok for binutils 2.16.1 but not for 2.17.
> > 
> > As the compiler passes two "cpu" selections to gas, one indirectly
> > generated by gcc's -m5200 and one direktly passed by -Wa,-mcpu=5213, gas
> is
> > "confused".  
> > File gas/config/tc-m68k.c checks this and produces an error, because of
> two
> > different selected cpu's. 
> > 
> > My suggestion is:
> > If gas is invoked with -mcpu=xxx, this should override the former
> settings.
> > Additional a warning will be produced. 
> > 
> > My included patch would produce this behavior.
> > Please could you check if I done everything right and if it is worth to
> be
> > applied to gas. 
> 
> 
>   You mean, let's patch gas to accept invalid command lines rather than
> you
> fix your invalid kludgey hacked-up build environment?  I suggest let's
> not!  I
> appreciate that you have a valid motive here owing to the disjunction
> between
> what cpus gcc understands and what cpus gas understands, but this surely
> isn't
> the way to resolve it.  The fact that it used to be accepted in 2.16.1 and
> now
> there's a check for it and it is specifically disallowed suggests that
> there
> may be some kind of problem.  Did you check the archives to see why this
> test
> was added?
> 
>   The correct fix for this situation would be to add a -m5213 option to
> gcc,
> not to try and persuade gas to accept two or more --cpu options at the
> same
> time.  It could be as simple as using the driver specs so that -m5213 gets
> turned into -m5200 when it's passed to cc1 in the CC1_SPEC and gets turned
> into -mcpu=5213 when it's passed to gas in the ASM_SPEC.  Wouldn't that do
> everything you need, and be a somewhat cleaner solution as well?

Ok, you're right :-)

As I had to find a quick solution, I forgot the gcc spec file ;-(
Your suggestion is what I was searching for.

thanks

Thomas Fleischmann
-- 


Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl

      reply	other threads:[~2006-07-05 17:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-05 16:00 Thomas Fleischmann
2006-07-05 16:36 ` Dave Korn
2006-07-05 17:10   ` Thomas Fleischmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060705171012.109040@gmx.net \
    --to=tfleischmann@gmx.de \
    --cc=binutils@sourceware.org \
    --cc=dave.korn@artimi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).