From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106197 invoked by alias); 13 Sep 2018 08:14:34 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 79883 invoked by uid 89); 13 Sep 2018 08:14:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,UNPARSEABLE_RELAY autolearn=no version=3.3.2 spammy=i'v, iv X-HELO: smtp2200-217.mail.aliyun.com X-Alimail-AntiSpam:AC=CONTINUE;BC=0.07444224|-1;CH=green;FP=0|0|0|0|0|-1|-1|-1;HT=e02c03295;MF=han_mao@c-sky.com;NM=1;PH=DS;RN=4;RT=4;SR=0;TI=SMTPD_---.CqEoz0L_1536826435; Date: Thu, 13 Sep 2018 08:14:00 -0000 From: Mao Han To: Joseph Myers Cc: c-sky_gcc_upstream@c-sky.com, gnu-csky@mentor.com, libc-alpha@sourceware.org Subject: Re: [PATCH v4 00/13] port C-SKY to glibc Message-ID: <20180913081354.GA4004@vmh-VirtualBox> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2018-09/txt/msg00174.txt.bz2 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 > suffice. > > * 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? Thanks, Han Mao