[U-Boot-Users] FW: [PATCH][ARM] Rationalize ARM compiler options
-----Original Message----- From: Peter Pearse [mailto:peter.pearse@arm.com] Sent: 14 February 2008 13:59 To: 'wd@denx.de' Subject: RE: [U-Boot-Users] [PATCH][ARM] Rationalize ARM compiler options
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: 13 February 2008 22:51 To: Peter Pearse Cc: U-Boot-Users Subject: Re: [U-Boot-Users] [PATCH][ARM] Rationalize ARM compiler options
Please don't add too many empty lines.
OK - I'll change thie when I re-submit. I just like to be able to ripple thru my buffers to animate the differences between almost identical files.
Why exactly are you dropping -msoft-float here?
I was under the delusion that dropping this protected against incorporation of floating point instructions.
Have I now got a clear understanding of the position:-
" The use of floating point arithmetic in the U-Boot code is deprecated. However the ELDK toolchains provide floating point support and were built with the -msoft-float option. This option is supplied to the code to ensure any floating point arithmetic included links in the floating point support code correctly. "
If so I'll put -msoft-float in all arm config.mk files.
-# Make ARMv5 to allow more compilers to work, even though its v6. -PLATFORM_CPPFLAGS += -march=armv5 +PLATFORM_CPPFLAGS += -march=armv6
Why exactly are you changing this?
arm1136 is an ARM Architecture V6 processor.
My position is: " The main (arm) tree processor options should use the correct architecture option for the processor (provided this option is accepted without error or warning by the ELDK arm toolchains) Users using compilers which do not support the correct architecture should be made aware of this. Should they wish to use another compiler they can change this option locally. "
I would also accept (reluctantly, although it saves lots of space I could waste as empty lines ;-) )
" For simplicity, the main (arm) tree processor options use the lowest common architecture option (armv4), whatever the processor implements. Users can change this option locally. "
At present we have a mixture.....
Regards
Peter
On Mon, 18 Feb 2008 09:20:18 -0000 "Peter Pearse" peter.pearse@arm.com wrote:
The use of floating point arithmetic in the U-Boot code is deprecated.
I'd say it's more than deprecated -- we shouldn't be using floating point arithmetic at all in u-boot. IMNSHO.
Haavard
In message 20080218123300.5dfd6e56@dhcp-252-066.norway.atmel.com you wrote:
On Mon, 18 Feb 2008 09:20:18 -0000 "Peter Pearse" peter.pearse@arm.com wrote:
The use of floating point arithmetic in the U-Boot code is deprecated.
I'd say it's more than deprecated -- we shouldn't be using floating point arithmetic at all in u-boot. IMNSHO.
ACK. FP is forbidden. Period.
You may use FP in your standalone applications, but at your own risk and without any explicit support from the underlying U-Boot code.
Best regards,
Wolfgang Denk
Please don't add too many empty lines.
OK - I'll change thie when I re-submit. I just like to be able to ripple thru my buffers to animate the differences between almost identical files.
Why exactly are you dropping -msoft-float here?
I was under the delusion that dropping this protected against incorporation of floating point instructions.
Have I now got a clear understanding of the position:-
" The use of floating point arithmetic in the U-Boot code is deprecated. However the ELDK toolchains provide floating point support and were built with the -msoft-float option. This option is supplied to the code to ensure any floating point arithmetic included links in the floating point support code correctly. "
If so I'll put -msoft-float in all arm config.mk files.
Please DON'T! This *forces* you to compile U-Boot with a compiler suite which is configured to generate soft-float. If you happen to use a compiler which does not support soft-float, I.E: uses NWFPE, then the build will fail.
Also what happens if you have a toolchain built without V5 support? Will the build complete?
-# Make ARMv5 to allow more compilers to work, even though its v6. -PLATFORM_CPPFLAGS += -march=armv5 +PLATFORM_CPPFLAGS += -march=armv6
Why exactly are you changing this?
arm1136 is an ARM Architecture V6 processor.
My position is: " The main (arm) tree processor options should use the correct architecture option for the processor (provided this option is accepted without error or warning by the ELDK arm toolchains) Users using compilers which do not support the correct architecture should be made aware of this. Should they wish to use another compiler they can change this option locally. "
Why not make this user tunable. If you want to mess about with V4 vs V5 support you should, but don't enforce this for people that could care less.
I would also accept (reluctantly, although it saves lots of space I could waste as empty lines ;-) )
" For simplicity, the main (arm) tree processor options use the lowest common architecture option (armv4), whatever the processor implements. Users can change this option locally. "
At present we have a mixture.....
Regards
Peter
Best Regards Ulf Samuelsson
In message 9a3001c872b7$dc147910$0402a8c0@atmel.com you wrote:
If so I'll put -msoft-float in all arm config.mk files.
Please DON'T! This *forces* you to compile U-Boot with a compiler suite which is configured to generate soft-float.
I think this is not correct. Even if your compiler is not configured to generate soft-float by default, asking it to do so should cause no harm.
If you happen to use a compiler which does not support soft-float, I.E: uses NWFPE, then the build will fail.
Even if it's configured for NWFPE as default setting, it should still be able to generate soft-float.
And in the end, it should make no differece at all as we don't use FP in U-Boot.
Best regards,
Wolfgang Denk
In message 9a3001c872b7$dc147910$0402a8c0@atmel.com you wrote:
If so I'll put -msoft-float in all arm config.mk files.
Please DON'T! This *forces* you to compile U-Boot with a compiler suite which is configured to generate soft-float.
I think this is not correct. Even if your compiler is not configured to generate soft-float by default, asking it to do so should cause no harm.
In this case, reality and the map differs. NWFPE toolchains built by cross-tool, buildroot, and www.gnuarm.com not sure abnout the last) all bombs when they reach the "-msoft-float"
If you happen to use a compiler which does not support soft-float, I.E: uses NWFPE, then the build will fail.
Even if it's configured for NWFPE as default setting, it should still be able to generate soft-float.
It doesn't. If you think so, show me an ARM toolset which behaves in this way.
And in the end, it should make no differece at all as we don't use FP in U-Boot.
Without "-msoft-float", both the softfloat and NWFPE toolchains will complete the build since floating point is not used.. With "-msoft-float", NWFPE based toolchains for ARM appears to abort.
If it doesn't make any difference, and U-Boot does not use floating point then it make sense to remove all "-msoft-float" for ARM Makefiles.'
It is so easy to replace all fixed parameters with symbolic Makefile variable which can be modified by your make command
$ make "MYPARS=-msoft-float" uboot
With sensible defaults which can be overriddern, this would solve the problem, without having to locally *patch* the source. When you are building several u-boots for different ARM chips from the same source you really do not want to patch the source.
Best regards,
Wolfgang Denk
Best Regards Ulf Samuelsson ulf@atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM +46 (706) 22 44 57
On Wed, 20 Feb 2008 07:33:47 +0100 "Ulf Samuelsson" ulf@atmel.com wrote:
In this case, reality and the map differs. NWFPE toolchains built by cross-tool, buildroot, and www.gnuarm.com not sure abnout the last) all bombs when they reach the "-msoft-float"
You mean they don't recognize -msoft-float as an option? If so,
CFLAGS += $(call cc-option,-msoft-float)
should do the right thing, no?
Haavard
On Wed, 20 Feb 2008 07:33:47 +0100 "Ulf Samuelsson" ulf@atmel.com wrote:
In this case, reality and the map differs. NWFPE toolchains built by cross-tool, buildroot, and www.gnuarm.com not sure abnout the last) all bombs when they reach the "-msoft-float"
You mean they don't recognize -msoft-float as an option?
Not the one's I have tried.
If so,
CFLAGS += $(call cc-option,-msoft-float)
should do the right thing, no?
Haavard
Looks OK to me, but I never used "call cc-option".
I think there are a multitude of possibilities, unless the goal is to ensure that anyone trying something else than ELDK will run into trouble.
Best Regards Ulf Samuelsson
On Wed, 20 Feb 2008 18:58:27 +0100 "Ulf Samuelsson" ulf@atmel.com wrote:
Looks OK to me, but I never used "call cc-option".
cc-option will try to run the compiler with the option. If the compiler didn't complain, it evaluates to the option. If it failed, it evaluates to nothing.
Very useful if you want to introduce new compiler options without breaking compatibility with old or weird compilers. The Linux build system uses it all over the place -- I suspect we could prevent quite a few toolchain incompatibilies by using it more extensively in u-boot as well.
Of course, it won't help you if the compiler misbehaves in other ways than just refusing to accept the option.
Haavard
participants (4)
-
Haavard Skinnemoen -
Peter Pearse -
Ulf Samuelsson -
Wolfgang Denk