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 Mon, Feb 7, 2011 at 7:51 AM, Bryan Hundven <bryanhundven@gmail.com> wrote: > On Mon, Feb 7, 2011 at 3:29 AM, David Brown <david@westcontrol.com> wrote: >> On 07/02/2011 12:14, Titus von Boxberg wrote: >>> >>> Am Mo, 7.02.2011, 11:16 schrieb David Brown: >>>> >>>> On 06/02/2011 12:48, Titus von Boxberg wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I'm trying to use ct-ng (of approx. May 2010) to generate >>>>> cross gcc-4.5.1, glibc-2.9/linux for a powerpc e500v2 / SPE. >>>>> >>>>> Setting floating point to "hardware" results in a build >>>>> error in glibc where the assembler complains while compiling >>>>> an FP file about an unmatched constraint >>>>> (I could try to get the original message if it helps). >>>>> >>>>> The tool chain gets built when I set floating point support to >>>>> "software". >>>>> However, the resulting compiler does not emit hardware FP instructions >>>>> unless I give -mhard-float on the command line. >>>>> >>>>> Is my assumption correct that setting floating point to "hardware" turns >>>>> on >>>>> code generation for the standard PowerPC FPU which this target lacks? >>>>> >>>>> I'd like to avoid having a compiler which needs target specific flags >>>>> on the command line, thus: >>>>> Does anyone know which options to turn on to get a compiler that >>>>> emits correct SPE FP instructions without explicitly being told so >>>>> by -mhard-float? >>>>> >>>>> Regards >>>>> Titus >>>>> >>>> >>>> >>>> If you try to use >>>> -mhard-float, either as a command-line switch or by default in the >>>> build, things are going to go badly wrong, as it will generate PPC >>>> floating point instructions that are not implemented on the e500v2. >>> >>> That's wrong. The compiler configured for Soft FP / SPE generates the >>> correct >>> instructions (but only with -mhard-float), and the code is working as >>> well. >>> The tool chain build for hard fp indeed goes wrong. That's my problem. >>> >> >> OK, if you say so - I haven't tried building from source, and it was >> something like a year and a half ago that I tried the CodeSourcery toolchain >> for the e500. ÂIt could well be that SPE floating point was activated >> slightly differently then, and has since then been better integrated as a >> variant of hardware floating point. > > Titus, > > I use the e500v2 toolchain all the time. Please provide more info > about the build problem your having and what distribution/version you > are building on. > > I am also hoping to have an e500mc (32 and 64-bit) toolchain samples soon. > >>>> >>>> I would look at the CodeSourcery toolchain. ÂThey have support for SPE >>>> floating point in current releases, which you can get as source or >>>> pre-build binary. ÂI don't know whether this support has made it into >>>> the mainline FSF trees as yet (call me lazy, but I've just used the >>>> binaries from CodeSourcery), but if not then I'm sure it will >>>> eventually. ÂIt requires particular flags to enable the SPE floating >>>> point - it may be possible to build your own version that uses it by >>>> default. >>> >>> Thanks for the hint! >>> >>>> >>>> Remember that the SPE only supports single-precision floating point - be >>>> very careful to avoid doubles in your code (or use flags to force 32-bit >>>> "doubles"). ÂIt's easy to write "x = y * 1.5" instead of "x = y * 1.5f", >>>> and give your cpu a great deal more work. >>> >>> This SPE supports double. I think it is enabled by -mfloat-gprs=double >>> (or maybe also by default by the compiler configuration option >>> --enable-e500_double, >>> but I did not verify this yet). >>> >> >> Looking more carefully, I see you are correct. ÂI have only used the e500v1 >> core, which has only single-precision floating point SPE support. >> >> mvh., >> >> David >> > > There are some bugs with double precision in gcc in 4.4.6, and 4.5.3. Oops... This should have read: There are some bugs with double precision in gcc in 4.4 and 4.5. > Fixes originally went to trunk. The first two have been backported to > 4.4 and 4.5, but the last one is fixed only in trunk: and this should have read: Fixes originally went to trunk. The first two have been backported to 4.4.6 and 4.5.3, but the last one is fixed only in trunk: > http://gcc.gnu.org/PR44606 > http://gcc.gnu.org/PR44169 > http://gcc.gnu.org/PR44364 > > ... Just a heads up. > >> -- >> 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] |