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
prev parent 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).