MPC55xx, <spe.h>, and <stdlib.h> and who owns what

[Joel Sherrill]

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
>> -----------------
>> Peter Dufault
>> HD Associates, Inc.      Software and System Engineering
>>
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users