This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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? > 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. > Regards > Titus > > Am Di, 22.03.2011, 14:49 schrieb Titus von Boxberg: >> Hi, >> >> I'm using ct-ng generated tool chains (gcc 4.5.1, binutils 2.20) >> for PowerPCs, a 603e and a e500v2. >> >> Both compilers pass -many to the assembler which disables >> checking the assembly code for cpu specific instructions >> (or better, for instructions the cpu does NOT provide). >> >> Does someone know what the reasoning is and if there's >> some knob to turn it off? > > > > > -- > For unsubscribe information see http://sourceware.org/lists.html#faq > > -Bryan -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |