On Thu, Oct 04, 2018 at 05:36:58PM +0000, Joseph Myers wrote: > On Thu, 4 Oct 2018, Stafford Horne wrote: > > > +or1k-*-linux*) > > + tmake_file="$tmake_file or1k/t-or1k" > > + tmake_file="$tmake_file t-softfp-sfdf t-softfp-excl t-softfp" > > + md_unwind_header=or1k/linux-unwind.h > > + ;; > > +or1k-*-*) > > + tmake_file="$tmake_file or1k/t-or1k" > > + tmake_file="$tmake_file t-softfp-sfdf t-softfp-excl t-softfp" > > + extra_parts="$extra_parts crti.o crtn.o" > > + ;; > > Could you clarify why you are using t-softfp-excl? > > In general, for soft-float configurations it's best not to use > t-softfp-excl - meaning the floating-point operations from libgcc2.c get > implemented directly in soft-fp, rather than through libgcc2.c wrapping > other soft-fp operations. While for hard-float configurations it's best > not to use soft-fp at all. > > If you have hard-float configurations using a soft-float ABI, that thus > need to provide all the functions in question so soft-float objects / > programs can be linked with hard-float libgcc, t-hardfp should be used > instead when building a hard-float multilib. (It's possible to have more > complicated mixtures in cases where some operations or types come from > hardfp and others from softfp; some mips and powerpcspe configurations > do.)
Hello, I don't know of a reason for using t-softfp-excl, I think Richard or I was just copying from what we saw similar targets do. I just removed it and reran some of the tests and don't see any regressions. We will be patching in hardfp post upstreaming, so the notes above are very helpful. -Stafford
