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 2004-08-15 at 12:36:04 Lennert Buytenhek wrote:

> I think making all three cases do something different is confusing
> enough in itself :)  To me, it would make sense that if you've configured
> gcc with --with-float=soft, that passing -msoft-float to the resulting
> compiler would then give the same behaviour as passing no soft-float
> option at all.

> And conversely, with --with-float=hard and -mhard-float.

Yes, that is probably what people would expect.


> Yeah.  It's better not to have hard-float/soft-float mess with the
> float byte ordering.

So something like --with-float-order=fpa/vfp etc?  As an argument to
gcc configure, I mean.


> In my case (a port of Fedora Core 2 to the arm/xscale), what would
> be the best option, hard-float or soft-float?  I'm inclined to go
> for hard-float.

For a distro aimed at general users, I'd certainly go for hard-float.
The kernel FPU emulator will handle most user's needs, and the
performance junkies will not likely run a standard distro anyway. :)


> (But that then gives me ICEs when I try to build the compiler with
> itself, aiiieee.)

Hmm, I've seen your posts, but never encountered this before.  This
needs some investigation...


>> > BTW, Why are you forcing mcpu=xscale if no mcpu is specified? This
>> > would seem like you're introducing a bug, no?
[...]
> Can we just take that bit out?

Of course, gcc will obviously get its own default cpu setting from
somewhere, I guess.


> I see.  Makes sense.  But do you want these files in libgcc also if
> you're using hardfloat, or does your patch only add them to libgcc
> if softfloat is being used?

It adds them always, but it doesn't matter if you use -mhard-float,
because the compiler will not generate any calls to those functions.
They shouldn't be linked into your final result, in that case.

Obviously, that was the intention of the separate libfloat.a library,
but I haven't been able to figure out how to get gcc's build process
generate and install it.

Attachment: pgp00000.pgp
Description: PGP signature


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