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]

Re: toolchain for powerpc e500v2


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]