This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v4 00/13] port C-SKY to glibc
On Wed, Sep 12, 2018 at 12:31:24PM +0000, Joseph Myers wrote:
> On Wed, 12 Sep 2018, Mao Han wrote:
> > 38245425a9add7bd22f8732219e0085432f223b6 (6 sep). Two abi combinations
> > are supported with this patch: C-SKY ABIV2 with (soft float & little endian,
> > hard float & little endian). CK807(ef), CK810(ef), CK860 are the
> Could you please clarify whether those are the same ABI (compatible for
> function calling, structure layout for types from glibc headers, etc.) or
> different ABIs?
> If they are different ABIs, they should have different dynamic linker
> names (of course you need to make the GCC port reflect the dynamic linker
> name used for each ABI), and your bits/fenv.h should disable most of its
> contents for soft float, like e.g. MIPS does (define only __FE_UNDEFINED
> and FE_TONEAREST as rounding modes in that case, define FE_ALL_EXCEPT to 0
> and no other exception macros, do not define FE_NOMASK_ENV). Then you
> shouldn't need math-tests-exceptions.h and math-tests-rounding.h in the
> nofpu directory because things will be handled automatically when
> bits/fenv.h avoids defining unsupported things.
> If they are the same ABI, I don't see any use for the CSKY_HARD_FLOAT
> macro defined in preconfigure; nothing seems to test it, so it's only
> relevant if shlib-versions is testing it (i.e. if they are different ABIs
> with different dynamic linker names).
Hard float will use to vr to pass arguments, the ABI is imcompatible if the
function has any float-point arguments. I use the same dynamic linker names
because there is no float in ldso, the same ldso can be used on system with
soft float/hard float. Seems I still need to use different dynamic linker
names even if they are compatible, and distinct soft float/hard float in
bits/fenv.h to make glibc have correct definitions?
> Does C-SKY hard float support exception traps or not? math-tests-trap.h
> has a comment saying not. But you have an implementation of
> feenableexcept that implies it does support exception traps.
> * If exception traps are never supported, everything related to them
> (including the definition of FE_NOMASK_ENV) should be removed; the default
> feenableexcept and fedisableexcept and fegetexcept implementations should
> * If exception traps are always supported, your math-tests-trap.h is wrong
> and should be removed.
> * If they are conditionally supported, like on Arm and AArch64, your
> math-tests-trap.h is appropriate with a different comment explaining the
> conditional support - but various fenv.h functions like feenableexcept
> need to check for the support and give errors if asked to enable
> exception traps they are unable to enable (this includes fesetenv and
> feupdateenv passed FE_NOMASK_ENV - see Arm and AArch64 for examples).
Exception traps is design to be conditionally supported, seems define to no
for compatibility. All the cpu with fpu have exception traps support at
present and I have no method to check whether hardware support that, so I
prefer to remove math-tests-trap.h.
> > Several patches will be post to GCC and Binutils to fix some testcase fail
> > later this month, while the follow results have these patches applied.
> Note that glibc ports can't go in while they depend on such non-upstream
> patches for good results (see the ARC port discussion). You can send a
> list of all the patches required to get the given test results, but
> they'll need to be upstream (as will the Linux kernel port) before the
> port can go into glibc.
I can understand the glibc patch and test-result should base on upstreamed
gcc/binutils/linux. The purpose for this submission is to make sure there
is no big issue in this patchset itself. Once other components are ready
I can test the patch again and resubmit it easily.
I'v got another issue while using build-many-glibcs.py.
csky-linux-gnuabiv2-gcc can not recognise -profile during the make check
stage and stoped. but it can recognise --profile. Is this a problem will
block the c-sky glibc port goes in.
> > 5. The following cases fail due to gcc optimize change the sequence of
> > -a * b to -(a * b) and got 1ulps error.
> > math/test-double-tgamma
> > math/test-float-tgamma
> > math/test-float32-tgamma
> > math/test-float32x-tgamma
> > math/test-float64-tgamma
> > math/test-ldouble-tgamma
> So that needs a GCC bug fix (just like when the Arm and AArch64 ports of
> GCC used to have such a bug).
We have this bug tracked internally. Also need to report a bug on gcc bugzilla?