MPC55xx, <spe.h>, and <stdlib.h> and who owns what
joel.sherrill at oarcorp.com
Wed Nov 26 15:29:59 UTC 2014
On 11/26/2014 07:10 AM, Sebastian Huber wrote:
> The last time I looked at the<spe.h> it was horribly broken. Its a
> shame that it found its way into the GCC sources.
> This<machine/stdlib.h> is from Newlib.
> On 26/11/14 13:56, Peter Dufault wrote:
>> I'm trying to figure out who to report a bug to.
>> One of my clients started using<spe.h> for the MPC55XX Signal Processing Extensions, and that header has some problems. It defines it's own versions of int32_t and friends that conflict with what's in<stdint.h>, and it has definitions of some SPE functions, for example these:
>> /* The SPE PIM says these are declared in<spe.h>, although they are
>> not provided by GCC: they must be taken from a separate
>> library. */
>> extern short int atosfix16 (const char *);
>> extern int atosfix32 (const char *);
>> extern long long atosfix64 (const char *);
>> and these functions have conflicting definitions in<machine/stdlib.h>.
>> <spe.h> is obviously from GCC, but I don't see a copyright in<machine/stdlib.h>
>> Who owns that file? Are these both part of GCC? Does anyone know if it is kosher to suggest including<stdlib.h> in<spe.h> to get around these problems?
It is gcc/config/rs6000/spe.h I think. If that's the same file, then file
a GCC PR and add myself and Sebastian on it.
>> Peter Dufault
>> HD Associates, Inc. Software and System Engineering
>> users mailing list
>> users at rtems.org
More information about the users