Re: gcc dynamic_bitset bug
Hi, This mailing list is for automated mails from our bug database, not for reporting bugs. Please see https://gcc.gnu.org/bugs/ for how to report bugs, although it looks like this was already reported as Bug 115399. Thanks for finding the bug though.
Re: GCC Installation breaks older header files
This mailing list is for automated mail from our bugzilla database, not for reporting bugs. It looks like you should be using the gcc-help mailing list anyway, not reporting a bug. I've CC'd that list. Please remove the gcc-bugs mailing list from the CC list when replying. On 20/05/24 20:48 +, novaTopFlex wrote: For system information results as necessary: Result from uname -a: Linux ubuntu-macbookpro 6.5.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Mar 12 10:22:43 UTC 2 x86_64 x86_64 x86_64 GNU/Linux The system information is not very relevant, but you haven't even said what version of GCC you're using. Also, there is no specific software or hardware being affected; this is a large-scale issue for developers needing to switch versions of the cross-compiler. Sent with [Proton Mail](https://proton.me/) secure email. On Monday, May 20th, 2024 at 4:45 PM, novaTopFlex wrote: I am sorry to report that existing header files may have been broken by the installation of a newer version of GCC. I have continuously attempted to compile newer versions of GCC from source but my system continuously fails to compile the code. I am not sure if there is any recovery path to restore success for applications that had depended on these headers. Sorry for the interruption. Nobody can help you with such a vague description of the problem. What do you mean "broken"? Which header files? What happens? What command are you running, and what errors do you get? Where did you install the new GCC? Did you overwrite an old version, or install to a different location? How did you configure and build GCC? Maybe you just need to run the mkheaders script as documented at https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Fixed-Headers.html
Re: ’ ] ' is displayed.
This mailing list is for automated emails from our bug database, not for reporting bugs directly. See https://gcc.gnu.org/bugs/ for how to report bugs, thanks.
Re: Strange compile error when g++ work with std=c++20.
This mailing list is for automated email from our Bugzilla bug database, not for reporting bugs directly. Please see https://gcc.gnu.org/bugs/ for instructions on how to report bugs. However, Andrew already explained why GCC is correct and this is not a GCC bug. Just use DECLARE_SINGLETON(ReceiverManager) to fix your code. The constructor should be declared as ReceiverManager() just like your destructor is declared as ~ReceiverManager(), not as ~ReceiverManager().
Re: C++ undefined behaviour sanitiser bug when compiled with optimization
This mailing list is for automated email from our bug tracker, it's not for reporting bugs directly. Emails sent to this list are likely to be missed, and definitely won't get entered into the bug tracker. Please use Bugzilla to report bugs, as described at https://gcc.gnu.org/bugs/
Re: GNU C raw string literals not documented?
> Not sure if this is the right mailing list for this. It's not. This mailing list is for automated email from our bug tracker. If you want to report a bug, please use that bug tracker instead of an email. See https://gcc.gnu.org/bugs/ for instructions. Thanks!
Re: Stack Canary Security Issue in gcc-arm-none-eabi-9
On 18/05/23 12:01 +0100, Jonathan Wakely wrote: This mailing list is for automated email from our bugzilla database. To report a bug, please don't email the list, use bugzilla as documented at https://gcc.gnu.org/bugs/ - thanks. Note however, that GCC 9 is no longer supported by gcc.gnu.org, and the GCC project does not create CVEs. You should probably report this to vendors who are distributing gcc-arm-none-eabi-9 so they can fix it and get a CVE if needed.
Re: Stack Canary Security Issue in gcc-arm-none-eabi-9
This mailing list is for automated email from our bugzilla database. To report a bug, please don't email the list, use bugzilla as documented at https://gcc.gnu.org/bugs/ - thanks.
Re: printf behaviour
This mailing list is for automated mails from our Bugzilla bug tracker system. If you want to report a bug, please see https://gcc.gnu.org/bugs/ If you want to ask a question, use the gcc-h...@gcc.gnu.org list, not the gcc-bugs list. Please direct any follow-up discussion there instead. There is nothing wrong with printf. Yes, it's the sttic variable. Before printf is called, every argument has to be evaluated. Since every call to timestamp returns the same pointer, you just print that string four times, and whatever it happens to contain at that time is printed four times.
Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
On Fri, 5 May 2023 at 12:13, Florian Weimer wrote:
>
> * Puneet Kumar Yatnal via Gcc-bugs:
>
> > What is next step here? How do I post this in Bugzilla and get
> > support.
>
> This issue has already been fixed with this commit:
>
> commit 80fe172ba9820199c2bbce5d0611ffca27823049
> Author: Jonathan Wakely
> Date: Tue Nov 9 23:45:36 2021 +
>
> libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133]
Indeed, as pointed out in bugzilla after the discussion moved there:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
>
> Since Glibc 2.34 all pthreads symbols are defined directly in libc not
> libpthread, and since Glibc 2.32 we have used __libc_single_threaded to
> avoid unnecessary locking in single-threaded programs. This means there
> is no reason to avoid linking to libpthread now, and so no reason to use
> weak symbols defined in gthr-posix.h for all the pthread_xxx functions.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/100748
> PR libstdc++/103133
> * config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK):
> Define for glibc 2.34 and later.
>
> It's been backported to GCC 10, but not GCC 9. Backporting to 9
> requires some messaging to get into 9 which lacks commit
> b11c74b0e357652a1f1f0d93 ("libstdc++: Avoid calling undefined
> __gthread_self weak symbol [PR 95989]").
>
> Thanks,
> Florian
>
Re: About initialization of automatic variables
The gcc-bugs@gcc.gnu.org list is for automated email from our Bugzilla database, please don't use it to report bugs or to ask questions about how GCC works. For questions about using GCC send email to gcc-h...@gcc.gnu.org and to report bugs please use bugzilla: https://gcc.gnu.org/bugs/ Thanks!
Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
On Mon, 17 Apr 2023, 09:27 Puneet Kumar Yatnal (QUIC), <
quic_pune...@quicinc.com> wrote:
> 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
>
Yes, I understand that.
Like Andrew said, please file it in bugzilla. Somebody will create your
account later today.
>
> *From:* Jonathan Wakely
> *Sent:* Monday, April 17, 2023 12:53 PM
> *To:* Andrew Pinski
> *Cc:* Puneet Kumar Yatnal (QUIC) ; gcc-help <
> gcc-h...@gcc.gnu.org>; gcc-bugs@gcc.gnu.org
> *Subject:* Re: Y2038: GCC gthr-posix.h weakref symbol invoking function
> has impact on time values
>
>
>
> *WARNING:* This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
>
>
>
> On Mon, 17 Apr 2023, 07:54 Andrew Pinski via Gcc-help, <
> gcc-h...@gcc.gnu.org> wrote:
>
> On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via
> Gcc-bugs wrote:
> >
> >
> > ++
> > From: Puneet Kumar Yatnal (QUIC)
> > Sent: Monday, April 17, 2023 9:26 AM
> > To: gcc-h...@gcc.gnu.org
> > Subject: Y2038: GCC gthr-posix.h wekref symbol invoking function has
> impact on time values
>
> First gcc-bugs@ is not the right place to report a bug report as
> gcc-bugs is mainly for automated emails from bugzilla. Please use
> bugzilla first.
>
> >
> > 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.
>
> Note libstdc++ does ABI changes too which is NOT part of that ABI design.
> This is where the symbol
> __gthread_cond_timedwait/__gthrw_pthread_cond_timedwait are used. So
> any changes you might do to fix __gthrw_pthread_cond_timedwait is not
> really going to work without wider ABI fixes to libstdc++.
> I don't know any one who is making those changes/fixes. So you should
> file an bug requesting it. And maybe even have a design document ready
> for it. There are many/some classes which have timespec inside them
>
>
>
> I don't think that's true. We don't use timespec members, they're just
> local variables, and very occasionally function parameters.
>
>
>
>
>
>
>
> and not just the mutex related ones.
>
> Thanks,
> Andrew
>
> >
> > 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, );
> > }
> > #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
> >
>
>
Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
On Mon, 17 Apr 2023, 07:54 Andrew Pinski via Gcc-help,
wrote:
> On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via
> Gcc-bugs wrote:
> >
> >
> > ++
> > From: Puneet Kumar Yatnal (QUIC)
> > Sent: Monday, April 17, 2023 9:26 AM
> > To: gcc-h...@gcc.gnu.org
> > Subject: Y2038: GCC gthr-posix.h wekref symbol invoking function has
> impact on time values
>
> First gcc-bugs@ is not the right place to report a bug report as
> gcc-bugs is mainly for automated emails from bugzilla. Please use
> bugzilla first.
>
> >
> > 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.
>
> Note libstdc++ does ABI changes too which is NOT part of that ABI design.
> This is where the symbol
> __gthread_cond_timedwait/__gthrw_pthread_cond_timedwait are used. So
> any changes you might do to fix __gthrw_pthread_cond_timedwait is not
> really going to work without wider ABI fixes to libstdc++.
> I don't know any one who is making those changes/fixes. So you should
> file an bug requesting it. And maybe even have a design document ready
> for it. There are many/some classes which have timespec inside them
I don't think that's true. We don't use timespec members, they're just
local variables, and very occasionally function parameters.
and not just the mutex related ones.
>
> Thanks,
> Andrew
>
> >
> > 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, );
> > }
> > #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
> >
>
Re: gcc-12: FTBFS on hurd-i386
Hello, This mailing list is for automated mail from Bugzilla. Emails sent directly to this list are liable to be missed or just ignored. Please report bugs to Bugzilla instead, see https://gcc.gnu.org/bugs/ Patches should be sent to the gcc-patches mailing list, not gcc-bugs: https://gcc.gnu.org/contribute.html#patches Thanks!
Re: Weird struct behavior on ESA S390
This mailing list is for automated emails from our bugzilla database, not for reporting bugs directly. To report a bug please follow the instructions at https://gcc.gnu.org/bugs/ Your email doesn't look like a bug report anyway, maybe you meant to send it to the gcc-help mailing list? Thanks.
Re: Compilation of rust-demangle.c fails on MinGW
> The libiberty README says to report bugs to gcc-bugs@gcc.gnu.org. Well that needs to be fixed. It should point to https://gcc.gnu.org/bugs/ instead.
Re: Compilation of rust-demangle.c fails on MinGW
In GCC's bugzilla. You could also report it to the sourceware.org bugzilla for binutils, but I think GCC is the upstream for libiberty.
Re: RISC-V: Parsing custom extension that is version 0
The gcc-bugs mailing list is for automated mails from our Bugzilla database. Bug reports should be entered into Bugzilla, and discussions should happen in Bugzilla or on a more apppropriate mailing list (because most GCC devs do not routinely read the gcc-bugs mails).
Re: How to fix GCC Upgrade issues(which always disappeared by add some trace prints)?
This mailing list is for automated mails from our bug database. Please use the gcc-help mailing list for questions like this.
Re: stdc++ issue: extremely long compile time with large number of string literals
> I'm not sure if this is the right mailing list for asking about No it's not, this list is for automated mails from our bug database. > (possible) g++ issues. If not, I'd appreciate it if someone can point > me to the right one. See https://gcc.gnu.org/lists.html which tells you that gcc-help is the right list.
Re: How GCC treats ice-on-invalid-code?
> These are the “true” ice-on-invalid-code bugs, i.e. those that are > meant to be classified as “ice-on-invalid-code” instead of “error-recovery” > in bugzilla. They generally get much more attention than “error-recovery” > bugs. And even those are lower priority than ice-on-valid bugs, and IMHO lower priority than rejects-valid bugs. It's fine to file these ice-on-invalid bugs, but don't be surprised if nobody has time to work on bugs that are only triggered by unrealistic garbage input.
Re: How GCC treats ice-on-invalid-code?
> I am sorry maybe I send this in a wrong place, I have sent this again in > gcc-bug-requ...@gcc.gun.org. Well that's even more wrong. g...@gcc.gnu.org would be the right place.
Re: bug in bit structure compilation
I know you've realised the problem here now, but ... This mailing list is for automated mails from our bugzilla database. To report a bug please use bugzilla. Sending email directly to the list will often be ignored, and will never create a bugzilla report. See https://gcc.gnu.org/bugs/ for details. Thanks!
