Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes)

Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes)

[Carlos O'Donell]

2021-09-22: glibc BoF at the GNU Tools track at Linux Plumbers Conference.

https://linuxplumbersconf.org/event/11/contributions/1019/

I spoke briefly about:

Upcoming release: glibc 2.35 relase on February 1st 2022.
Open topics?
Patch review: Retrospective on 10 months of patch queue review?
Patch review: How do we make consensus easier for patch review and commit?
Feature: Are we ready for the ppc64le long double change in downstream?
CI/CD: Status of patchwork CI/CD? - format.useAutoBase came up.

These are my notes from the BoF.

Feature: Are we ready for the ppc64le long double change in downstream?
- libgfortran needs to be discussed for ppc64le to transition to long double.
- Jonathan Wakely: Open libstdc++ bug that needs fixing.

Patch review: Retrospective on 10 months of patch queue review?
- We aren't making through the patch review.
- Are we making it through the patch queue.
- Refocus on the queue for review. ****

Frangrui Song: Will glibc be happy with Clang buildability?
- Carlos: Yes, we could be happy with clang buildability.
- Florian: We may need nested functions to get away from relocations in bootstrap.
- Joseph: Patches should be split into logical changes.

Joseph Myers: Could we do better bugzilla triage?
- Bug queue review is a process.
- Yes, we need to clean up our process and do something weekly.
- Segher: gcc hooks to log commits against bugs help.
- Carlos: The switch to the adacore hooks broke this. Fix this. ****
- Michael: Keep the bug open until I do the backport.
- Patrick: Put a comment in the bug when you're going to move the bug downstream.
- Florian: Needs to close the bugs for the NEWS file generation logic.

Jeff Law: Explicit loader invocations result in different memory layout.
- Florian: Yes, it's a kernel issue, and ASLR defaults impact this.
  - We have seen this in the past.
  - More explicit loader invocations will happen because env-vars 
    have their own issues.
- Changes in memory layout should not impact things due to ASLR.

Florian Weimer: Mailing list and from rewriting
- Annoying issues with git-am and patchwork.
- Formal request for a change in configuration via overseers.
- Nick Alcock: The rule is don't change anything.
- The only way to avoid from rewriting is to allow all email.
- Refuse mail that contains html? Troublesome dropped email that they are rejected.
- Send back an SMTP rejection code, and bouncing is a source of spray (problem).
- Spam? Handled by spam filtering.
- Overseers: Request to stop rewriting email, and allow all email to the list.
- Mark: Talk to Frank and cgf.
- Can you use b4 with libc-alpha?
  - Yes, if you can point b4 at libc-alpha on public-inbo

-- 
Cheers,
Carlos.

Re: Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes)

[Siddhesh Poyarekar]

On 9/22/21 23:29, Carlos O'Donell via Libc-alpha wrote:
> - Can you use b4 with libc-alpha?
>    - Yes, if you can point b4 at libc-alpha on public-inbo

Technically yes, but in practice it doesn't seem that useful in the 
context of glibc because it has the same problems that patchwork has:

- We don't use git-send-email consistently, which often breaks patchwork 
mail processing and I suspect it will be the same for b4

- Patches in replies but without changing the subject line

- New versions are rarely sent in reply to the previous version, atleast 
as far as I could tell from a quick skim of the code.

In other words, b4 (as does patchwork) has pretty stringent patch email 
formatting requirements that we don't enforce.

Siddhesh

Re: Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes)

[Paul Zimmermann]

       Dear Carlos,

thank you for the report. Where can we get more information on the
"ppc64le long double change"?

Is that https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition?
On that page, by "128-bit IEEE format" you mean a 128-bit encoding, but
holding only 64 bits of significand (format called ldbl-96 in glibc)?

Paul

Re: Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes)

[Florian Weimer]

* Paul Zimmermann:

> thank you for the report. Where can we get more information on the
> "ppc64le long double change"?
>
> Is that https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition?
> On that page, by "128-bit IEEE format" you mean a 128-bit encoding, but
> holding only 64 bits of significand (format called ldbl-96 in glibc)?

Essentially it's about switching the distribution default from
sysdeps/ieee754/ldbl-128ibm to sysdeps/ieee754/ldbl-128.

The former is a pair of doubles, using Dekker's method, and the latter
is the regular binary128 IEEE quad-precision format.

Thanks,
Florian

Re: Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes)

[Paul Zimmermann]

> > thank you for the report. Where can we get more information on the
> > "ppc64le long double change"?
> >
> > Is that https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition?
> > On that page, by "128-bit IEEE format" you mean a 128-bit encoding, but
> > holding only 64 bits of significand (format called ldbl-96 in glibc)?
> 
> Essentially it's about switching the distribution default from
> sysdeps/ieee754/ldbl-128ibm to sysdeps/ieee754/ldbl-128.
> 
> The former is a pair of doubles, using Dekker's method, and the latter
> is the regular binary128 IEEE quad-precision format.

thank you Florian for the clarification. Then "long double" in C will
map to binary128, like _Float128?

Paul

Re: Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes)

[Florian Weimer]

* Paul Zimmermann:

>> > thank you for the report. Where can we get more information on the
>> > "ppc64le long double change"?
>> >
>> > Is that https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition?
>> > On that page, by "128-bit IEEE format" you mean a 128-bit encoding, but
>> > holding only 64 bits of significand (format called ldbl-96 in glibc)?
>> 
>> Essentially it's about switching the distribution default from
>> sysdeps/ieee754/ldbl-128ibm to sysdeps/ieee754/ldbl-128.
>> 
>> The former is a pair of doubles, using Dekker's method, and the latter
>> is the regular binary128 IEEE quad-precision format.
>
> thank you Florian for the clarification. Then "long double" in C will
> map to binary128, like _Float128?

Yes, but you can go back to double-double with a compiler flag if you
wish (-mabi=ibmlongdouble, I think).

Thanks,
Florian

Re: Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes)

[Tulio Magno Quites Machado Filho]

Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> writes:

> * Paul Zimmermann:
>
>> thank you Florian for the clarification. Then "long double" in C will
>> map to binary128, like _Float128?
>
> Yes, but you can go back to double-double with a compiler flag if you
> wish (-mabi=ibmlongdouble, I think).

Correct.  It works the same way as building with -mlong-double-64 nowadays: 

$ gcc-9 -mlong-double-64 tst-ldbl.c && ./a.out 
sizeof(long double) = 8
__LDBL_MANT_DIG__ = 53
$ gcc-9 -mlong-double-128 -mabi=ibmlongdouble tst-ldbl.c && ./a.out 
sizeof(long double) = 16
__LDBL_MANT_DIG__ = 106
$ gcc-9 -mlong-double-128 -mabi=ieeelongdouble -Wno-psabi tst-ldbl.c && ./a.out 
sizeof(long double) = 16
__LDBL_MANT_DIG__ = 113

Today, the default for most Linux distributions is the second build. The goal
is to move to the last build.

-- 
Tulio Magno