public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized
@ 2022-03-03 16:01 redi at gcc dot gnu.org
2022-03-03 16:11 ` [Bug libstdc++/104772] " redi at gcc dot gnu.org
` (13 more replies)
0 siblings, 14 replies; 15+ messages in thread
From: redi at gcc dot gnu.org @ 2022-03-03 16:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
Bug ID: 104772
Summary: std::numeric_limits<__float128> should be specialized
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Depends on: 99708, 98202
Target Milestone: ---
We should provide a specialization of numeric_limits<__float128> when that type
is valid (even if is_floating_point_v<__float128> is false due to
__STRICT_ANSI__ being defined).
It might also be useful to do the same for __float80 on x86, although that's
less widely used. That could be done fairly easily:
#ifdef __SIZEOF_FLOAT80__
template<>
numeric_limits<__float80> : numeric_limits<long double> { };
#endif
For __float128 we need to define it fully. The compiler gives us the info we
need:
#define __FLT128_DECIMAL_DIG__ 36
#define __FLT128_DENORM_MIN__ 6.47517511943802511092443895822764655e-4966F128
#define __FLT128_DIG__ 33
#define __FLT128_EPSILON__ 1.92592994438723585305597794258492732e-34F128
#define __FLT128_HAS_DENORM__ 1
#define __FLT128_HAS_INFINITY__ 1
#define __FLT128_HAS_QUIET_NAN__ 1
#define __FLT128_IS_IEC_60559__ 2
#define __FLT128_MANT_DIG__ 113
#define __FLT128_MAX_10_EXP__ 4932
#define __FLT128_MAX_EXP__ 16384
#define __FLT128_MAX__ 1.18973149535723176508575932662800702e+4932F128
#define __FLT128_MIN_10_EXP__ (-4931)
#define __FLT128_MIN_EXP__ (-16381)
#define __FLT128_MIN__ 3.36210314311209350626267781732175260e-4932F128
#define __FLT128_NORM_MAX__ 1.18973149535723176508575932662800702e+4932F128
The F128 suffixes are a problem though, see PR 98202 comment 7.
Detecting __float128 reliably is blocked by PR 99708 comment 8.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98202
[Bug 98202] C++ cannot parse F128 suffix for float128 literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
[Bug 99708] __SIZEOF_FLOAT128__ not defined on powerpc64le-linux
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized
2022-03-03 16:01 [Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized redi at gcc dot gnu.org
@ 2022-03-03 16:11 ` redi at gcc dot gnu.org
2022-03-03 16:20 ` redi at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: redi at gcc dot gnu.org @ 2022-03-03 16:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Strictly speaking, the __FLT128_* macros relate to _Float128 which is not
defined for C++ even when __float128 is (and in theory a target could have a
non-IEEE __float128 which would have different properties from _Float128).
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized
2022-03-03 16:01 [Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized redi at gcc dot gnu.org
2022-03-03 16:11 ` [Bug libstdc++/104772] " redi at gcc dot gnu.org
@ 2022-03-03 16:20 ` redi at gcc dot gnu.org
2022-03-08 0:24 ` redi at gcc dot gnu.org
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: redi at gcc dot gnu.org @ 2022-03-03 16:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2022-03-03
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Oh, and likewise for __gnu_cxx::__numeric_traits_floating
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized
2022-03-03 16:01 [Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized redi at gcc dot gnu.org
2022-03-03 16:11 ` [Bug libstdc++/104772] " redi at gcc dot gnu.org
2022-03-03 16:20 ` redi at gcc dot gnu.org
@ 2022-03-08 0:24 ` redi at gcc dot gnu.org
2023-04-26 6:55 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: redi at gcc dot gnu.org @ 2022-03-08 0:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |13.0
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized
2022-03-03 16:01 [Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized redi at gcc dot gnu.org
` (2 preceding siblings ...)
2022-03-08 0:24 ` redi at gcc dot gnu.org
@ 2023-04-26 6:55 ` rguenth at gcc dot gnu.org
2023-05-16 18:53 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-04-26 6:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|13.0 |13.2
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized
2022-03-03 16:01 [Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized redi at gcc dot gnu.org
` (3 preceding siblings ...)
2023-04-26 6:55 ` rguenth at gcc dot gnu.org
@ 2023-05-16 18:53 ` jakub at gcc dot gnu.org
2023-05-16 18:57 ` redi at gcc dot gnu.org
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-16 18:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Perhaps we could change that
if (cxx_dialect < cxx23)
pedwarn (input_location, OPT_Wpedantic,
"%<f%d%> or %<F%d%> suffix on floating constant only "
"available with %<-std=c++2b%> or %<-std=gnu++2b%>",
n, n);
into
if (cxx_dialect < cxx23 && !in_system_header_at (input_location))
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized
2022-03-03 16:01 [Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized redi at gcc dot gnu.org
` (4 preceding siblings ...)
2023-05-16 18:53 ` jakub at gcc dot gnu.org
@ 2023-05-16 18:57 ` redi at gcc dot gnu.org
2023-05-31 12:21 ` cvs-commit at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: redi at gcc dot gnu.org @ 2023-05-16 18:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
That would be great :-)
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized
2022-03-03 16:01 [Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized redi at gcc dot gnu.org
` (5 preceding siblings ...)
2023-05-16 18:57 ` redi at gcc dot gnu.org
@ 2023-05-31 12:21 ` cvs-commit at gcc dot gnu.org
2023-05-31 12:32 ` redi at gcc dot gnu.org
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-05-31 12:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:
https://gcc.gnu.org/g:f150a084e25eaa98afaf25e2211001047ecc8d44
commit r14-1433-gf150a084e25eaa98afaf25e2211001047ecc8d44
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Wed May 17 14:02:14 2023 +0100
libstdc++: Add std::numeric_limits<__float128> specialization [PR104772]
As suggested by Jakub in the PR, this just hardcodes the constants with
a Q suffix, since the properties of __float128 are not going to change.
We can only define it for non-strict modes because the suffix gives an
error otherwise, even in system headers:
limits:2085: error: unable to find numeric literal operator 'operator""Q'
libstdc++-v3/ChangeLog:
PR libstdc++/104772
* include/std/limits (numeric_limits<__float128>): Define.
* testsuite/18_support/numeric_limits/128bit.cc: New test.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized
2022-03-03 16:01 [Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized redi at gcc dot gnu.org
` (6 preceding siblings ...)
2023-05-31 12:21 ` cvs-commit at gcc dot gnu.org
@ 2023-05-31 12:32 ` redi at gcc dot gnu.org
2023-05-31 13:51 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: redi at gcc dot gnu.org @ 2023-05-31 12:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|13.2 |14.0
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I've added the specialization to trunk, but as the commit msg says, it's
disabled for strict modes due to the Q suffix giving an error. Let's keep this
open until it's also specialized for strict modes.
Jakub, should I file a separate FE bug for the !system_header change you
suggested in comment 4?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized
2022-03-03 16:01 [Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized redi at gcc dot gnu.org
` (7 preceding siblings ...)
2023-05-31 12:32 ` redi at gcc dot gnu.org
@ 2023-05-31 13:51 ` jakub at gcc dot gnu.org
2023-05-31 13:59 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-31 13:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Dunno.
I think you can add support even without any compiler changes, at least if
_GLIBCXX_DOUBLE_IS_IEEE_BINARY64:
#ifdef __STRICT_ANSI__
static _GLIBCXX_CONSTEXPR __float128
min() _GLIBCXX_USE_NOEXCEPT
{ return __extension__ 3.36210314311209350626267781732175260e-4932Q; }
static _GLIBCXX_CONSTEXPR __float128
max() _GLIBCXX_USE_NOEXCEPT
{ return __extension__ 1.18973149535723176508575932662800702e+4932Q; }
static _GLIBCXX_CONSTEXPR __float128
epsilon() _GLIBCXX_USE_NOEXCEPT
{ return __extension__ 1.92592994438723585305597794258492732e-34Q; }
static _GLIBCXX_CONSTEXPR __float128
denorm_min() _GLIBCXX_USE_NOEXCEPT
{ return __extension__ 6.47517511943802511092443895822764655e-4966Q; }
#else
static _GLIBCXX_CONSTEXPR __float128
_S_1pm4088 () _GLIBCXX_USE_NOEXCEPT
{ return __float128 (0x1.0p-1022) * 0x1.0p-1022 * 0x1.0p-1022 *
0x1.0p-1022; }
static _GLIBCXX_CONSTEXPR __float128
_S_1pm16352 () _GLIBCXX_USE_NOEXCEPT
{ return _S_1pm4088 () * _S_1pm4088 () * _S_1pm4088 () * _S_1pm4088 (); }
static _GLIBCXX_CONSTEXPR __float128
_S_1p4064 () _GLIBCXX_USE_NOEXCEPT
{ return __float128 (0x1.0p+1016) * 0x1.0p-1016 * 0x1.0p-1016 *
0x1.0p-1016; }
static _GLIBCXX_CONSTEXPR __float128
_S_1p16256 () _GLIBCXX_USE_NOEXCEPT
{ return _S_1p4064 () * _S_1p4064 () * _S_1p4064 () * _S_1p4064 (); }
static _GLIBCXX_CONSTEXPR __float128
min() _GLIBCXX_USE_NOEXCEPT
{ return /* 0x1.0p-16382Q */ 0x1.0p-30 * _S_1pm16352 (); }
static _GLIBCXX_CONSTEXPR __float128
max() _GLIBCXX_USE_NOEXCEPT
{ return /* 0x1.ffffffffffffffffffffffffffffp+16383Q */
(__float128 (0x1.fffffffffffffp+127) + 0x0.fffffffffffffp+75
+ 0x0.ffp+23) * _S_1p16256 (); }
static _GLIBCXX_CONSTEXPR __float128
epsilon() _GLIBCXX_USE_NOEXCEPT
{ return 0x1.0p-112; }
static _GLIBCXX_CONSTEXPR __float128
denorm_min() _GLIBCXX_USE_NOEXCEPT
{ return /* 0x1.0p-16494Q */ 0x1.0p-142 * _S_1pm16352 (); }
#endif
Except that the FE errors in C++98/11/14 modes on the hexadecimal constants.
I guess one could replace them with decimal constants (except those in comments
of course), but better use explicit double(whatever) to make sure they aren't
evaluated in higher precision. Anyway, I think the above computations should
(at least assuming the decimal constants map to those hexadecimal ones) always
be exact and so should produce such results in all rounding modes.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized
2022-03-03 16:01 [Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized redi at gcc dot gnu.org
` (8 preceding siblings ...)
2023-05-31 13:51 ` jakub at gcc dot gnu.org
@ 2023-05-31 13:59 ` jakub at gcc dot gnu.org
2023-05-31 14:00 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-31 13:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Sorry, 0x1.0p-1016 * 0x1.0p-1016 * 0x1.0p-1016 obviously should have been
0x1.0p+1016 * 0x1.0p+1016 * 0x1.0p+1016, I tested it on a testcase where I used
different names etc.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized
2022-03-03 16:01 [Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized redi at gcc dot gnu.org
` (9 preceding siblings ...)
2023-05-31 13:59 ` jakub at gcc dot gnu.org
@ 2023-05-31 14:00 ` jakub at gcc dot gnu.org
2023-06-06 15:59 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-31 14:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And the reason for the helper functions is C++11 which would not like
temporaries in constexpr functions.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized
2022-03-03 16:01 [Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized redi at gcc dot gnu.org
` (10 preceding siblings ...)
2023-05-31 14:00 ` jakub at gcc dot gnu.org
@ 2023-06-06 15:59 ` cvs-commit at gcc dot gnu.org
2023-06-06 16:19 ` redi at gcc dot gnu.org
2024-04-10 15:48 ` meissner at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-06-06 15:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:
https://gcc.gnu.org/g:6261d10521f9fdc2a43d54b4dc365025288aa8e9
commit r14-1582-g6261d10521f9fdc2a43d54b4dc365025288aa8e9
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Mon Jun 5 16:14:29 2023 +0100
libstdc++: Make std::numeric_limits<__float128> more portable [PR104772]
This redefines std::numeric_limits<__float128> so that it works with
non-GCC compilers. The previous definition didn't work with Clang, due
to it not supporting __builtin_high_valq, __builtin_nanq, and
__builtin_nansq. It also didn't work in strict modes, due to using Q
literal suffixes.
The new definition uses the Q suffixes when supported, or calculates the
correct values using __float128 arithmetic from double values. Ideally
the values would be defined as hexadecimal-floating-point-literals, but
that won't work for C++14 and older.
The only member that can't be defined this way is signaling_NaN() which
still requires a built-in. If __builtin_nansq is not supported, try to
use __builtin_nansf128 (with a possibly-redundant bit_cast) and if that
isn't supported, return a quiet NaN and define has_signaling_NaN and
is_iec754 to be false.
libstdc++-v3/ChangeLog:
PR libstdc++/104772
* include/std/limits: (numeric_limits<__float128>): Define
for __STRICT_ANSI__ as well.
* testsuite/18_support/numeric_limits/128bit.cc: Remove
check for __STRICT_ANSI__.
Co-authored-by: Jakub Jelinek <jakub@redhat.com>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized
2022-03-03 16:01 [Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized redi at gcc dot gnu.org
` (11 preceding siblings ...)
2023-06-06 15:59 ` cvs-commit at gcc dot gnu.org
@ 2023-06-06 16:19 ` redi at gcc dot gnu.org
2024-04-10 15:48 ` meissner at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: redi at gcc dot gnu.org @ 2023-06-06 16:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Thanks, Jakub. That works nicely.
Fixed for GCC 14.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized
2022-03-03 16:01 [Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized redi at gcc dot gnu.org
` (12 preceding siblings ...)
2023-06-06 16:19 ` redi at gcc dot gnu.org
@ 2024-04-10 15:48 ` meissner at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: meissner at gcc dot gnu.org @ 2024-04-10 15:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
Bug 104772 depends on bug 99708, which changed state.
Bug 99708 Summary: __SIZEOF_FLOAT128__ not defined on powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2024-04-10 15:48 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-03 16:01 [Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized redi at gcc dot gnu.org
2022-03-03 16:11 ` [Bug libstdc++/104772] " redi at gcc dot gnu.org
2022-03-03 16:20 ` redi at gcc dot gnu.org
2022-03-08 0:24 ` redi at gcc dot gnu.org
2023-04-26 6:55 ` rguenth at gcc dot gnu.org
2023-05-16 18:53 ` jakub at gcc dot gnu.org
2023-05-16 18:57 ` redi at gcc dot gnu.org
2023-05-31 12:21 ` cvs-commit at gcc dot gnu.org
2023-05-31 12:32 ` redi at gcc dot gnu.org
2023-05-31 13:51 ` jakub at gcc dot gnu.org
2023-05-31 13:59 ` jakub at gcc dot gnu.org
2023-05-31 14:00 ` jakub at gcc dot gnu.org
2023-06-06 15:59 ` cvs-commit at gcc dot gnu.org
2023-06-06 16:19 ` redi at gcc dot gnu.org
2024-04-10 15:48 ` meissner at gcc dot gnu.org
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).