This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.31: hard freeze on Friday, 31st Jan
- From: Carlos O'Donell <codonell at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at gotplt dot org>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, libc-alpha at sourceware dot org
- Date: Fri, 31 Jan 2020 22:45:13 -0500
- Subject: Re: glibc 2.31: hard freeze on Friday, 31st Jan
- References: <78730bb4-4c3f-2cc6-bbdc-40ef1acfda27@gotplt.org> <0f8efc9a-a309-550f-8c5b-cf65d1d05299@redhat.com> <87ftfw3779.fsf@oldenburg2.str.redhat.com> <51ab716c-b07c-59f1-20a3-71c29dcfebd0@linaro.org> <fd249463-423f-948b-3095-dc38c8496c82@gotplt.org>
On 1/31/20 10:06 AM, Siddhesh Poyarekar wrote:
> On 31/01/20 17:03, Adhemerval Zanella wrote:
>> Based on the extended asm and local register variable usage with GCC on
>> the 'powerpc Linux scv support and scv system call ABI proposal' I think
>> we hit a nasty latent sparc issue I am seeing at least on sparc32 tests
>> (it clobbers the syscalls result and make some calls to clock_nanosleep
>> to not act as a cancellation entrypoint).
>>
>> I am working on a solution, do you think we should push it after the
>> release branch is created or can we hold a day or two?
>
> I see that this is documented in the 2.31 wiki, I think that's a
> reasonable compromise given the stage we're in. Lets stik to schedule
> and backport once there's consensus on the fix.
Agreed.
The sparc32 issue, while a regression, is not a blocker for the release.
We should document the regression and alert downstream that a fix is in progress.
--
Cheers,
Carlos.