From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117779 invoked by alias); 21 Oct 2016 09:02:43 -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 117766 invoked by uid 89); 21 Oct 2016 09:02:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=H*Ad:U*davem, 2.20, Hx-languages-length:1473, baseline X-HELO: mx6.bahnhof.se X-Spam-Score: 0.67 Message-ID: <5809D90E.1090005@gaisler.com> Date: Fri, 21 Oct 2016 09:02:00 -0000 From: Andreas Larsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Adhemerval Zanella , GNU C Library CC: David Miller Subject: Re: Remove sparcv8 support References: <48cdf008-b66a-d411-a07a-5a38595978b9@linaro.org> In-Reply-To: <48cdf008-b66a-d411-a07a-5a38595978b9@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00351.txt.bz2 On 2016-10-20 21:47, Adhemerval Zanella wrote: > The sparcv8 build is broken since GLIBC 2.23 due the new pthread > barrier implementation [1] and since then there is no thread or > interest on fixing it (Torvald has suggested some options on > 2.23 release thread). It won't help with both new pthread rdlock > and cond implementation, although I would expect that it relies > on same atomic primitive that was not present for pthread barrier. > > AFAIK, recent commercial sparc chips from Oracle all supports > sparcv9. The only somewhat recent sparc chip with just sparcv8 > support is LEON4, which I really doubt it cares for glibc support. Hi! We do care about GLIBC support for many different LEON3 and LEON4 systems. GLIBC support for sparcv8 is important for us and it is important for our customers. Both LEON3 and LEON4 are continuously used in new hardware designs. We are not always using the latest version of GLIBC (the latest step we took was to GLIBC 2.20), so unfortunately we missed this issue. We will look into what the extent of the missing support is. Any pointers are most welcome. Do you have a link to the suggested options on the 2.23 release thread? I dug around a bit in the archives, but did not find it. (As a side note, most of the recent LEON3 and LEON4 chips have CAS instruction support, but pure sparcv8 support is of course the baseline.) Best regards, Andreas Larsson Software Engineer Cobham Gaisler