This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


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: problem with crosstool 0.28-pre28 supplied patch for gcc 3.3.[23] softfloat on ARM


On Mon, Aug 16, 2004 at 12:28:38AM +0200, Dimitry Andric wrote:

> > Runtime switching between VFP and FPA seems to be about as useful to
> > me as being able to switch between ELF and COFF at runtime.  Why can't
> > you tell people to just hack gcc's header files and recompile, or
> > make it a gcc build-time option (as parameter to configure or so)?
> 
> Well, there are some uses for it, and the best example I think is the
> ARM Linux kernel itself, which uses -msoft-float everywhere.

Shouldn't we then just have an option -mdont-emit-fpu-instructions-at-all
for this?  (Like, -mno-fpu?)


> Indeed,
> as you say later on, this is more about what the defaults are if you
> don't specify anything.  And I agree that should probably be hardware
> FPA, for various reasons, which have already been discussed.

Yup.


> >> arm-unknown-linux-gcc without options generates hardware FPA.
> >> arm-unknown-linux-gcc -msoft-float generates software FPA.
> >> arm-unknown-linux-gcc -mhard-float generates hardware FPA, i.e. the
> >> same as without options!
> 
> > This makes sense to me, though, since you get the same behaviour with
> > many other options, like the ones of the form -f{,no-}some-option (for
> > example, -f{,no-}strict-aliasing.)
> 
> But please, let's not introduce -mno-soft-float etc, because we'll all
> go crazy with confusion. ;)

no-soft-float = hard-float?  uhhhmmm... :)


> > My thought right now is that fpa/vfp should be fixed at gcc compile time.
> > Do you have any compelling reasons why this shouldn't be so? :)
> 
> Yes, that is quite reasonable.  Once you're on a certain platform,
> you'll never switch it anymore anyway.

Then again.. and sorry to contradict myself here.. the endianness on
the ARM platform is also settable at compile time.. so what _is_ the
right criterion here?  One could also argue that one should be able
to compile code for all ARM targets with the same ARM compiler binary.

-mbig-endian/-mlittle-endian

-mfloat-format=vfp/-mfloat-format=fpa

-mfloat=hard/-mfloat=soft/-mfloat=off

Too many options :(


--L

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


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