From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from szxga05-in.huawei.com ([45.249.212.191]:2051 "EHLO dggrg05-dlp.huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752315AbcLEKJh (ORCPT ); Mon, 5 Dec 2016 05:09:37 -0500 Subject: Re: ILP32 for ARM64: testing with glibc testsuite References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <20161107082359.GA19666@yury-N73SV> <20161109095650.GA22804@yury-N73SV> <1479419136.908.90.camel@caviumnetworks.com> From: "Zhangjian (Bamvor)" Message-ID: Date: Mon, 5 Dec 2016 17:58:09 +0800 MIME-Version: 1.0 In-Reply-To: <1479419136.908.90.camel@caviumnetworks.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Steve Ellcey , Maxim Kuvyrkov , Yury Norov Cc: arnd@arndb.de, catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-arch@vger.kernel.org, GNU C Library , schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, Andrew Pinski , broonie@kernel.org, "Joseph S. Myers" , christoph.muellner@theobroma-systems.com, Szabolcs Nagy , klimov.linux@gmail.com, Nathan_Lynch@mentor.com, agraf@suse.de, Prasun Kapoor , kilobyte@angband.pl, Geert Uytterhoeven , "Dr. Philipp Tomsich" , manuel.montezelo@gmail.com, linyongting@huawei.com, davem@davemloft.net, zhouchengming1@huawei.com, cmetcalf@ezchip.com, Adhemerval Zanella , "Zhangjian (Bamvor)" , Ding Tianhong , Hanjun Guo , "jijun (D)" , chenjianguo3@huawei.com, "liupeifeng (A)" Message-ID: <20161205095809._EqitE-esjmFAXRXywmeWYHiWWvxlIyc8OfZaMEJ_-8@z> Hi, Steve On 2016/11/18 5:45, Steve Ellcey wrote: > On Wed, 2016-11-16 at 15:22 +0400, Maxim Kuvyrkov wrote: >>> >>> On Nov 9, 2016, at 1:56 PM, Yury Norov >>> wrote: >>> >>>> >>>> Below is the results of glibc testsuite run for aarch64/lp64 > > I have been running the glibc testsuite as well. I have only run it on > an ILP32 enabled kernel. Using that kernel, top-of-tree glibc, and the > ILP32 glibc patches I have no LP64 regressions. There are 5 failures > in LP64 mode but I get them with vanilla top-of-tree glibc sources too. > They are: > nptl/eintr1 (I actually don't run this because it kills the 'make check') > debug/tst-backtrace5 > debug/tst-backtrace6 > nptl/tst-stack4 > nptl/tst-thread_local1 > > In ILP32 mode I get 33 failures, they include the above failures (minus > nptl/tst-thread_local1) plus: > > c++-types-check > conform/ISO11/inttypes.h/conform > conform/ISO11/stdint.h/conform > conform/ISO99/inttypes.h/conform > conform/ISO99/stdint.h/conform > conform/POSIX2008/inttypes.h/conform > conform/POSIX2008/stdint.h/conform > conform/XOPEN2K/inttypes.h/conform > conform/XOPEN2K/stdint.h/conform > conform/XOPEN2K8/inttypes.h/conform > conform/XOPEN2K8/stdint.h/conform > elf/tst-tls1 > elf/tst-tls1-static > elf/tst-tls2 > elf/tst-tls2-static > elf/tst-tls3 > math/check-abi-libm > math/test-double > math/test-double-finite > math/test-float > math/test-float-finite > misc/tst-sync_file_range > nptl/tst-cancel26 > nptl/tst-cancel27 > nptl/tst-sem3 > rt/tst-mqueue1 > rt/tst-mqueue2 > rt/tst-mqueue4 > rt/tst-mqueue7 > stdlib/tst-makecontext3 > > I am currently looking at these ILP32 regressions (starting with the > tls failures) to see if I can figure out what is happening with them. Is there some progresses on it? We could collabrate to fix those issues. Regards Bamvor > > Steve Ellcey > sellcey@caviumnetworks.com >