Re: powerpc gcc option -many passed to assembler

[Titus von Boxberg <titus at v9g dot de>]

Am 12.04.2011 um 11:53 schrieb Bryan Hundven:
> Soon crosstool-ng will have it's own mailing list and this kind of
> noise will go away.
Bryan, Yann, all,

I'd recommend not to narrow down the scope of this mailing list.
The traffic rate does not really blow up one's mail program,
and I see the subjects crossgcc and ct-ng as mutually dependent:
Who would even dare to build a (linux-)crossgcc manually when ct-ng is at hand,
and correctness of the tool chains generated (for the 
overseeable future this will not be clang, I guess) should be a
ct-ng issue as well. For my understanding this correctness is one reason for
ct-ng maintaining patch sets for the tools (and all their versions).

At least I am strongly interested to read these kind of problem reports
from other ct-ng users (and to possibly answer).
That's why it did not come to my mind that this thread might be
regarded as "noise".

> 
> The patch might be useful to others as well as ct-ng.
Maybe, yes.

> But is removing -many for e500/e500mc/603e correct? I meant to suggest
> to verify with gcc-help@
Discussing and cleanly correcting this is way beyond my
inside knowledge of all the parts affected (basically all existing software
with inline ppc assembler) and my available spare time.
That's why I documented my findings alongside with a simple
"almost correct" solution on this list.
I doubt that it is easy to get gcc/gas spec (instruction set documentation)
conformant (which I'd regard as "correct").
Just take "sync" vs. "msync". There is no "sync" instruction in my copy
of the insn set document. It is "correct" for gas to reject that insn
for e500.
But it's use is quite widespread. That's why I chose to
patch binutils to allow this mnemonic (along with "eieio") also for e500.
That is sorta Evil Hack, just as (in my opinion) passing -many is.

> Not trying to insult you. Sorry for not being clear.
Did not take it as insulting, but I believe that this kind of questions
definitely should stay on this list, see above.

> Maybe it would be better fixed upstream then patched in crosstool-ng?
> 
> My understanding of crosstool-ng is that it is a build system for the
> components of source code that make up a cross toolchain. There are a
> few types of cross toolchains (native, cross-native, cross,
> cross-canadian, and cross-back. I'm sure there are stranger
> combinations) where patches are needed to aid that type of build as
> well as different build procedures/semantics.
Presumably, some of the patches in ctng are required to make the
generated tool chain produce working executables.

Regards
Titus


--
For unsubscribe information see http://sourceware.org/lists.html#faq