Re: powerpc gcc option -many passed to assembler

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

Am 11.04.2011 um 17:54 schrieb Bryan Hundven:

> 
> On Apr 11, 2011 4:19 AM, "Titus von Boxberg" <titus@v9g.de> wrote:
> >
> > Am Mo, 11.04.2011, 11:19 schrieb Bryan Hundven:
> > > On Thu, Mar 31, 2011 at 6:13 AM, Titus von Boxberg <titus@v9g.de> wrote:
> > >> Hi,
> > >>
> > >> just in case someone is interested:
> > >> Calling as with option -many is hardcoded in gcc.
> > >>
> > >> A colleague found those links which might be helpful
> > >> for seeing the "reasoning" behind:
> > >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21091
> > >> http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01244.html
> > >> http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01247.html
> > >> http://sources.redhat.com/ml/binutils/2004-05/msg00376.html
> > >> http://sources.redhat.com/ml/binutils/2004-05/msg00357.html
> > >>
> > >> The problem I had was that the compiler/assemler accepts
> > >> e.g. dcbzl for an e500v2 which leads to a SIGILL.
> > >
> > > Neat. I've not seen this one yet.
> > > Do you have some example code or a test-case I could try that cause the SIGILL?
> >
> > asm("dcbzl 3,13");
> >
> > >
> > >> The solution for me is up to now
> > >> - to patch away -many in gcc
> > >> - to allow sync / eieio (in addition to equivalent msync/mbar) in as
> > >>  for e500 because otherwise you cannot compile almost nothing
> > >>  of the tool chain.
> > >>
> > >> Aditionally, in binutils 2.20 there is the mistake that
> > >> an e500 was believed to be an e500mc (but this has apparently
> > >> been corrected in 2.21).
> > >
> > > With logs located at: http://bryanhundven.com/ct-ng/powerpc-e500v2-linux-gnuspe/
> > >
> > > ...I built a gcc-4.5.1/binutils-2.21/eglibc-2.12 toolchain, and I was
> > > able to build u-boot (HEAD:17e967b) for P2020RDB board and the linux
> > > kernel. I didn't notice any issues.
> > >
> > > Maybe I do not fully understand the issue you are seeing.
> > What issue do you mean here?
> > The problem I had is explained above: It is false permissiveness
> > of the assembler when invoked by the compiler.
> > Building a tool chain has not been the problem.
> >
> > BTW: The patched toolchain I'm using seems to work fine (up to now ;-)
> >
> > Regards
> > Titus
> 
> Again. I don't see any problem here with crosstool-ng.
> Maybe this conversation belongs on gcc-help@
Bryan,

I can only guess why you cannot see the problem.
This might be a combination of
- you misinterpret the main subject of the list as ct-ng@sourceware.org
- you misinterpret the goal of ct-ng as "reliably produce a cross tool chain whose
  components return an exit code of 0 given syntactical correctness of the input".
- you overlooked my original question "is there a knob to turn off that behaviour",
  which - as far as I understand - definitely would belong to ct-ng.
- I already answered my question ("no, there is no such knob, it's hardwired")
  in case someone might be interested, and you did not see that answer.
- You overlooked that a big deal of ct-ng is about to patch toolchain sources into
  reliably useable shape, thus my patches might interest others as well.
- you cannot grasp that a toolchain is inherently unreliable when the compiler
  deliberately accepts (inline assembly) instructions that cannot be executed
  (here, refer back to point 2).

HTH

Regards
Titus


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