This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


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: [arm-linux target] better support for soft-float and default cpu


Nick Clifton wrote:

> Hi Jeroen,
> 
>   Thanks very much for submitting your patch.  There are a few small
> points which need to be fixed, but with those taken care of I believe
> that the revisedversion will be acceptable - with one major caveat:
> Do you have a gcc copyright assignment on file with the FSF ?  Without
> such an assignment we cannot accept your patch :-(
> 


Not yet. I'll look into that.


> Anyway here are my comments:
> 
> 
[..]

> 
>>+ #if !defined(TARGET_CPU_DEFAULT_NAME) && (TARGET_CPU_DEFAULT == TARGET_CPU_arm2)
>>+ #define TARGET_CPU_DEFAULT_NAME arm2
>>+ #endif
>>+ 
>>+ #if !defined(TARGET_CPU_DEFAULT_NAME) && (TARGET_CPU_DEFAULT == TARGET_CPU_arm250)
>>+ #define TARGET_CPU_DEFAULT_NAME arm250
>>+ #endif
>>....
>>
> 
> This whole section could be more efficiently coded as:
> 
>   #ifndef TARGET_CPU_DEFAULT_NAME
>   #if TARGET_CPU_DEFAULT == TARGET_CPU_arm2
>   #define TARGET_CPU_DEFAULT_NAME arm2
> 
>   #if TARGET_CPU_DEFAULT == TARGET_CPU_arm250
>   #define TARGET_CPU_DEFAULT_NAME arm250
>   ....
>   #endif
> 


It would, if all the definitions of TARGET_CPU_xxx would be unique,
but unfortunately, they aren't.
This method will result in the first name with the same 'id'.

[..]

>>
> 
> This looks wrong to me.  Surely if the default is for soft float then
> this ought to be:
> 
>     #ifdef TARGET_CPU_DEFAULT_USE_SOFTFLOAT
>     #define LIBGCC_SPEC "%{!mhard-float:-lfloat} -lgcc"
>     #else
>     #define LIBGCC_SPEC "%{msoft-float:-lfloat} -lgcc"
>     #endif



Ok. But in that case, I need to get a 'libfloat.a'.
How can I build this ?

[..]

> 
>>+ # inhibit libc (for bootstrapping on systems without libc)
>>+ TARGET_LIBGCC2_CFLAGS += -Dinhibit_libc -D__gthr_posix_h
>>
> 
> Why is __gthr_posix_h being defined here ?
> 

Hmm. it probably shouldn't.


Greetings,
--
Jeroen Dobbelaere
Embedded Software Engineer

ACUNIA Embedded Solutions
http://www.acunia.com



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]