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

[Peter Dufault]

> On Nov 26, 2014, at 10:29 , Joel Sherrill <Joel.Sherrill at oarcorp.com> wrote:
> 
> 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.
> 
>> 

If it's "horribly broken" I want to discourage him from using it instead of fixing a minor issue.  I need to understand its broken-ness.

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering