public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
@ 2023-04-18 7:59 punitb20 at gmail dot com
2023-04-18 8:01 ` [Bug libgcc/109540] " punitb20 at gmail dot com
` (13 more replies)
0 siblings, 14 replies; 15+ messages in thread
From: punitb20 at gmail dot com @ 2023-04-18 7:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
Bug ID: 109540
Summary: Y2038: GCC gthr-posix.h weakref symbol invoking
function has impact on time values
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: punitb20 at gmail dot com
Target Milestone: ---
All
if we fallowed https://sourceware.org/glibc/wiki/Y2038ProofnessDesign for Y2038
fix(where all timer related variable moved to 64 bit instead of 32 bit ),
pthread_cond_timedwait function from gthr_posix.h is calling different function
in pthrea_cond_wait.c of glibc(due to weakref of symbol
pthread_cond_timedwait()) which impacting the time value.
From pthread.h
extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond,
pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict
__abstime) __asm__ ("" "__pthread_cond_timedwait64")
From gthread_posix.h:
static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait
__attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__
(pthread_cond_timedwait)));
__gthrw_(pthread_cond_timedwait) --> ___pthread_cond_timedwait invoking in
glibc instead of __pthread_cond_timedwait64 which is impacting time value as
__pthread_cond_timedwait is converting value from 32 bit to 64 bit.
normal pthread_cond_timedwait is invoking __pthread_cond_timedwait64 properly
and its working fine.
From: pthread_cond_wait.c
#if __TIMESIZE == 64
strong_alias (___pthread_cond_timedwait64, ___pthread_cond_timedwait)
#else
strong_alias (___pthread_cond_timedwait64, __pthread_cond_timedwait64)
libc_hidden_def (__pthread_cond_timedwait64)
int
___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex,
const struct timespec *abstime)
{
struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime);
return __pthread_cond_timedwait64 (cond, mutex, &ts64);
}
#endif /* __TIMESIZE == 64 */
versioned_symbol (libc, ___pthread_cond_timedwait,
pthread_cond_timedwait, GLIBC_2_3_2);
libc_hidden_ver (___pthread_cond_timedwait, __pthread_cond_timedwait)
#ifndef SHARED
strong_alias (___pthread_cond_timedwait, __pthread_cond_timedwait)
#endif
if add #defing GTHREAD_USE_WEAK 0 in libgcc/gthr-posix.h issue is resolved
but that is not correct way as it disable weakref for all symbol, please let me
know what is correct way to fix this, this i observed with gcc-9.3.0 gcc and
glibc 2.34
Regards
Puneet
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
2023-04-18 7:59 [Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values punitb20 at gmail dot com
@ 2023-04-18 8:01 ` punitb20 at gmail dot com
2023-04-18 10:15 ` redi at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: punitb20 at gmail dot com @ 2023-04-18 8:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #1 from Puneet B <punitb20 at gmail dot com> ---
Here issue is weakref symbol in gcc not using the __asm_ function pointed by
pthread.h instead its calling directly ___pthread_cond_timedwait which is
exposed by version_symbol in pthread_cond_wait.c of glibc
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
2023-04-18 7:59 [Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values punitb20 at gmail dot com
2023-04-18 8:01 ` [Bug libgcc/109540] " punitb20 at gmail dot com
@ 2023-04-18 10:15 ` redi at gcc dot gnu.org
2023-04-18 10:19 ` punitb20 at gmail dot com
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: redi at gcc dot gnu.org @ 2023-04-18 10:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
N.B. GCC 9 is no longer supported, so any changes will not help that version.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
2023-04-18 7:59 [Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values punitb20 at gmail dot com
2023-04-18 8:01 ` [Bug libgcc/109540] " punitb20 at gmail dot com
2023-04-18 10:15 ` redi at gcc dot gnu.org
@ 2023-04-18 10:19 ` punitb20 at gmail dot com
2023-04-18 11:12 ` redi at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: punitb20 at gmail dot com @ 2023-04-18 10:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #3 from Puneet B <punitb20 at gmail dot com> ---
It can be reproduceable in gcc master branch or latest release..dont look at it
as GCC particular version bug.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
2023-04-18 7:59 [Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values punitb20 at gmail dot com
` (2 preceding siblings ...)
2023-04-18 10:19 ` punitb20 at gmail dot com
@ 2023-04-18 11:12 ` redi at gcc dot gnu.org
2023-04-18 11:19 ` redi at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: redi at gcc dot gnu.org @ 2023-04-18 11:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, I know. I'm just pointing out that you're reporting a bug against an
unsupported version.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
2023-04-18 7:59 [Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values punitb20 at gmail dot com
` (3 preceding siblings ...)
2023-04-18 11:12 ` redi at gcc dot gnu.org
@ 2023-04-18 11:19 ` redi at gcc dot gnu.org
2023-04-18 12:59 ` punitb20 at gmail dot com
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: redi at gcc dot gnu.org @ 2023-04-18 11:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The description is a bit confusing, but the issue is that we define:
typedef struct timespec __gthread_time_t;
and then use that in several functions like this:
static inline int
__gthread_cond_timedwait (__gthread_cond_t *__cond, __gthread_mutex_t *__mutex,
const __gthread_time_t *__abs_timeout)
{
return __gthrw_(pthread_cond_timedwait) (__cond, __mutex, __abs_timeout);
}
If libc uses a 64-bit time_t in struct timespec then we need to use
__pthread_cond_timedwait64 instead of pthread_cond_timedwait, because the
latter expects a struct containing a 32-bit time_t instead of a 64-bit one.
The weak alias referenced by __gthrw_ is defined like so:
static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait
__attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__
(pthread_cond_timedwait)));
Where the _TIME_BITS=64 declaration of pthread_cond_timedwait is:
extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond,
pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict
__abstime) __asm__ ("" "__pthread_cond_timedwait64")
The reported issue is that weakref("pthread_cond_timedwait") binds to a symbol
of that name, rather than to __pthread_cond_timedwait64, so we end up passing a
64-bit timespec to the 32-bit pthread_cond_timedwait.
However, that's not what I observe when I test it.
If I compile with 32-bit time_t for i686 using GCC 12 and
glibc-2.36-9.fc37.i686 then a call to __gthread_cond_timedwait will resolve to
glibc's pthread_cond_timedwait which expects a 32-bit timespec:
(gdb)
13 __gthread_cond_timedwait(&cond, &mutex, &ts);
(gdb) step
__gthread_cond_timedwait (__cond=0x804c060 <cond>, __mutex=0x804c090 <mutex>,
__abs_timeout=0xffffc7e8)
at /usr/include/c++/12/x86_64-redhat-linux/32/bits/gthr-default.h:872
872 return __gthrw_(pthread_cond_timedwait) (__cond, __mutex,
__abs_timeout);
(gdb)
___pthread_cond_timedwait (cond=0x804c060 <cond>, mutex=0x804c090 <mutex>,
abstime=0xffffc7e8) at pthread_cond_wait.c:655
655 {
(gdb) l
650 libc_hidden_def (__pthread_cond_timedwait64)
651
652 int
653 ___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t
*mutex,
654 const struct timespec *abstime)
655 {
656 struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime);
657
658 return __pthread_cond_timedwait64 (cond, mutex, &ts64);
659 }
If I recompile the same code with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 then
the call to __gthread_cond_timedwait resolves to glibc's
__pthread_cond_timedwait64:
(gdb)
13 __gthread_cond_timedwait(&cond, &mutex, &ts);
(gdb) step
__gthread_cond_timedwait (__cond=0x804c060 <cond>, __mutex=0x804c090 <mutex>,
__abs_timeout=0xffffc7e0)
at /usr/include/c++/12/x86_64-redhat-linux/32/bits/gthr-default.h:872
872 return __gthrw_(pthread_cond_timedwait) (__cond, __mutex,
__abs_timeout);
(gdb)
___pthread_cond_timedwait64 (cond=0x804c060 <cond>, mutex=0x804c090 <mutex>,
abstime=0xffffc7e0) at pthread_cond_wait.c:632
632 {
(gdb) l
627
628 /* See __pthread_cond_wait_common. */
629 int
630 ___pthread_cond_timedwait64 (pthread_cond_t *cond, pthread_mutex_t
*mutex,
631 const struct __timespec64 *abstime)
632 {
633 /* Check parameter validity. This should also tell the compiler that
634 it can assume that abstime is not NULL. */
635 if (! valid_nanoseconds (abstime->tv_nsec))
636 return EINVAL;
So it seems to work fine. Do you actually observe a bug, or are you just
speculating from reading the wiki page and headers?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
2023-04-18 7:59 [Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values punitb20 at gmail dot com
` (4 preceding siblings ...)
2023-04-18 11:19 ` redi at gcc dot gnu.org
@ 2023-04-18 12:59 ` punitb20 at gmail dot com
2023-04-19 6:24 ` punitb20 at gmail dot com
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: punitb20 at gmail dot com @ 2023-04-18 12:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #6 from Puneet B <punitb20 at gmail dot com> ---
its not after refer the wiki, its observed on target where its clear that even
after compiling application with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 its
still calling ___pthread_cond_timedwait
More over if i call pthread_cond_timedwait directly its calling
__pthread_cond_timedwait64 directly as i already mentioned in this thread.
And
issue is resolved if i add #defing GTHREAD_USE_WEAK 0 in
libgcc/gthr-posix.h
it clears that weakref symbol is not working properly during linker stage.
both __gthrw_(pthread_cond_timedwait) and pthread_cond_timedwait are expected
to invoke same API.
let me know if you need any more inputs
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
2023-04-18 7:59 [Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values punitb20 at gmail dot com
` (5 preceding siblings ...)
2023-04-18 12:59 ` punitb20 at gmail dot com
@ 2023-04-19 6:24 ` punitb20 at gmail dot com
2023-04-20 7:19 ` punitb20 at gmail dot com
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: punitb20 at gmail dot com @ 2023-04-19 6:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #7 from Puneet B <punitb20 at gmail dot com> ---
Any pointers here help to debug further.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
2023-04-18 7:59 [Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values punitb20 at gmail dot com
` (6 preceding siblings ...)
2023-04-19 6:24 ` punitb20 at gmail dot com
@ 2023-04-20 7:19 ` punitb20 at gmail dot com
2023-04-20 11:04 ` redi at gcc dot gnu.org
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: punitb20 at gmail dot com @ 2023-04-20 7:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #8 from Puneet B <punitb20 at gmail dot com> ---
could some one provide some pointers here? if its observed in gcc.9.3.0 and
fixed in latest GCC, please point me the same, i will pick and validate quickly
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
2023-04-18 7:59 [Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values punitb20 at gmail dot com
` (7 preceding siblings ...)
2023-04-20 7:19 ` punitb20 at gmail dot com
@ 2023-04-20 11:04 ` redi at gcc dot gnu.org
2023-04-20 11:11 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: redi at gcc dot gnu.org @ 2023-04-20 11:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Ever confirmed|0 |1
Last reconfirmed| |2023-04-20
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It works correctly with 10.4.1 and 11.3.0 and 12.1.0 so it looks like this
isn't true:
(In reply to Puneet B from comment #3)
> It can be reproduceable in gcc master branch or latest release..dont look at
> it as GCC particular version bug.
You haven't provided a testcase though, so we don't know what you're seeing.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
2023-04-18 7:59 [Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values punitb20 at gmail dot com
` (8 preceding siblings ...)
2023-04-20 11:04 ` redi at gcc dot gnu.org
@ 2023-04-20 11:11 ` redi at gcc dot gnu.org
2023-04-20 11:12 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: redi at gcc dot gnu.org @ 2023-04-20 11:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Ah, it works for C++ because of r12-5108-g80fe172ba98201
With a recent glibc __gthread_cond_timedwait just calls pthread_cond_timedwait
directly, so use correctly redirected to __pthread_cond_timedwait64.
If you have glibc 2.34 then you can use -DGTHREAD_USE_WEAK=0 to disable the
weak refs in gthr-posix.h
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
2023-04-18 7:59 [Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values punitb20 at gmail dot com
` (9 preceding siblings ...)
2023-04-20 11:11 ` redi at gcc dot gnu.org
@ 2023-04-20 11:12 ` redi at gcc dot gnu.org
2023-04-20 14:16 ` punitb20 at gmail dot com
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: redi at gcc dot gnu.org @ 2023-04-20 11:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #10)
> If you have glibc 2.34 then you can use -DGTHREAD_USE_WEAK=0 to disable the
> weak refs in gthr-posix.h
I think that is indeed the correct fix, as you originally asked about. But only
for glibc 2.34 and later.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
2023-04-18 7:59 [Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values punitb20 at gmail dot com
` (10 preceding siblings ...)
2023-04-20 11:12 ` redi at gcc dot gnu.org
@ 2023-04-20 14:16 ` punitb20 at gmail dot com
2023-05-05 11:46 ` fw at gcc dot gnu.org
2024-04-08 22:11 ` pinskia at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: punitb20 at gmail dot com @ 2023-04-20 14:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #12 from Puneet B <punitb20 at gmail dot com> ---
Thanks for update , since we are using gcc-2.34 , this need to picked as fix.
but do you seen any side impact of this fix which need to be validated?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
2023-04-18 7:59 [Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values punitb20 at gmail dot com
` (11 preceding siblings ...)
2023-04-20 14:16 ` punitb20 at gmail dot com
@ 2023-05-05 11:46 ` fw at gcc dot gnu.org
2024-04-08 22:11 ` pinskia at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: fw at gcc dot gnu.org @ 2023-05-05 11:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
Florian Weimer <fw at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=103133
CC| |fw at gcc dot gnu.org
--- Comment #13 from Florian Weimer <fw at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Jonathan Wakely from comment #10)
> > If you have glibc 2.34 then you can use -DGTHREAD_USE_WEAK=0 to disable the
> > weak refs in gthr-posix.h
>
> I think that is indeed the correct fix, as you originally asked about. But
> only for glibc 2.34 and later.
Only glibc 2.34 and later have this problem because previous upstream versions
lack dual-API time64 support. I would like to claim that we did this
deliberately, but the version alignment between libpthread removal and the new
time64 support was a bit of a coincidence.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
2023-04-18 7:59 [Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values punitb20 at gmail dot com
` (12 preceding siblings ...)
2023-05-05 11:46 ` fw at gcc dot gnu.org
@ 2024-04-08 22:11 ` pinskia at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-04-08 22:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |DUPLICATE
Status|WAITING |RESOLVED
--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup of bug 78017 for new enough glibc (which is all of ones that support
time64_t IIRC).
*** This bug has been marked as a duplicate of bug 78017 ***
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2024-04-08 22:11 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-18 7:59 [Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values punitb20 at gmail dot com
2023-04-18 8:01 ` [Bug libgcc/109540] " punitb20 at gmail dot com
2023-04-18 10:15 ` redi at gcc dot gnu.org
2023-04-18 10:19 ` punitb20 at gmail dot com
2023-04-18 11:12 ` redi at gcc dot gnu.org
2023-04-18 11:19 ` redi at gcc dot gnu.org
2023-04-18 12:59 ` punitb20 at gmail dot com
2023-04-19 6:24 ` punitb20 at gmail dot com
2023-04-20 7:19 ` punitb20 at gmail dot com
2023-04-20 11:04 ` redi at gcc dot gnu.org
2023-04-20 11:11 ` redi at gcc dot gnu.org
2023-04-20 11:12 ` redi at gcc dot gnu.org
2023-04-20 14:16 ` punitb20 at gmail dot com
2023-05-05 11:46 ` fw at gcc dot gnu.org
2024-04-08 22:11 ` pinskia 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).