* Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes)
@ 2021-09-22 17:59 Carlos O'Donell
2021-09-22 18:33 ` Siddhesh Poyarekar
2021-09-23 7:20 ` Paul Zimmermann
0 siblings, 2 replies; 7+ messages in thread
From: Carlos O'Donell @ 2021-09-22 17:59 UTC (permalink / raw)
To: libc-alpha
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes)
2021-09-22 17:59 Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes) Carlos O'Donell
@ 2021-09-22 18:33 ` Siddhesh Poyarekar
2021-09-23 7:20 ` Paul Zimmermann
1 sibling, 0 replies; 7+ messages in thread
From: Siddhesh Poyarekar @ 2021-09-22 18:33 UTC (permalink / raw)
To: Carlos O'Donell, libc-alpha
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes)
2021-09-22 17:59 Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes) Carlos O'Donell
2021-09-22 18:33 ` Siddhesh Poyarekar
@ 2021-09-23 7:20 ` Paul Zimmermann
2021-09-23 7:54 ` Florian Weimer
1 sibling, 1 reply; 7+ messages in thread
From: Paul Zimmermann @ 2021-09-23 7:20 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes)
2021-09-23 7:20 ` Paul Zimmermann
@ 2021-09-23 7:54 ` Florian Weimer
2021-09-23 8:01 ` Paul Zimmermann
0 siblings, 1 reply; 7+ messages in thread
From: Florian Weimer @ 2021-09-23 7:54 UTC (permalink / raw)
To: Paul Zimmermann; +Cc: Carlos O'Donell, libc-alpha
* 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes)
2021-09-23 7:54 ` Florian Weimer
@ 2021-09-23 8:01 ` Paul Zimmermann
2021-09-23 8:08 ` Florian Weimer
0 siblings, 1 reply; 7+ messages in thread
From: Paul Zimmermann @ 2021-09-23 8:01 UTC (permalink / raw)
To: Florian Weimer; +Cc: carlos, libc-alpha
> > 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes)
2021-09-23 8:01 ` Paul Zimmermann
@ 2021-09-23 8:08 ` Florian Weimer
2021-09-23 18:01 ` Tulio Magno Quites Machado Filho
0 siblings, 1 reply; 7+ messages in thread
From: Florian Weimer @ 2021-09-23 8:08 UTC (permalink / raw)
To: Paul Zimmermann; +Cc: carlos, libc-alpha
* 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes)
2021-09-23 8:08 ` Florian Weimer
@ 2021-09-23 18:01 ` Tulio Magno Quites Machado Filho
0 siblings, 0 replies; 7+ messages in thread
From: Tulio Magno Quites Machado Filho @ 2021-09-23 18:01 UTC (permalink / raw)
To: Florian Weimer, Paul Zimmermann; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-09-23 18:01 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-22 17:59 Linux Plumbers Conference: GNU Tools Track: glibc BoF (notes) Carlos O'Donell
2021-09-22 18:33 ` Siddhesh Poyarekar
2021-09-23 7:20 ` Paul Zimmermann
2021-09-23 7:54 ` Florian Weimer
2021-09-23 8:01 ` Paul Zimmermann
2021-09-23 8:08 ` Florian Weimer
2021-09-23 18:01 ` Tulio Magno Quites Machado Filho
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).