Re: _BitInt() as underlying enum type
On Sat, Jan 27, 2024 at 08:25:04PM -0800, Andrew Pinski via Gcc-bugs wrote: > Just an FYI, the clang issue was > https://github.com/llvm/llvm-project/issues/69619 . > With the following commit to the LLVM git repo as the fix: > https://github.com/llvm/llvm-project/commit/5175cd777c57190ab9860c304796d386e4df9b8f Indeed, the C23 draft I have specifies in 6.7.2.2/5: "If an enum type specifier is present, then the longest possible sequence of tokens that can be interpreted as a specifier qualifier list is interpreted as part of the enum type specifier. It shall name an integer type that is neither an enumeration nor a bit-precise integer type." Jakub
Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
On Fri, May 05, 2023 at 01:13:50PM +0200, Florian Weimer via Gcc-bugs 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]
>
> 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]").
GCC 9 is not supported anymore, so backporting anything to it (at least
upstream) is not possible.
Jakub
Re: report a bug of gcc implementation of std::vsnprintf()
On Thu, Mar 30, 2023 at 08:29:45AM +, Qiang Ren via Gcc-bugs wrote:
> I found a bug in the result of std::vsnprintf(), here is the test app that
> can reproduce it.
> I tested with g++ 11.2 and 12.2 and both have the bug, and this issue does
> not happen with visual c++.
gcc-bugs is not the right way to report GCC bugs, though in this case
the only bug is in your program.
You can't use the same va_list multiple times as you pass it to
std::vsnprintf, either you need to use va_copy before the first call
and use the copy in one of the two calls, or you need to va-end after
the first vsnprintf call and va_start again before the second call.
>
> #include
> #include
> #include
> #include
>
> int Sprintf(std::string& s, const char* pszFormat, ...) {
> va_list argptr;
> va_start(argptr, pszFormat);
>
> auto n = std::vsnprintf(nullptr, 0, pszFormat, argptr);
> char* buf = (char*)malloc(n + 1);
> n = std::vsnprintf(buf, n + 1, pszFormat, argptr);
> s = buf;
> free(buf);
>
> va_end(argptr);
> return n;
> }
Jakub
Re: gcc cannot build correctly famous hello program, clang does it correctly
On Wed, Sep 07, 2022 at 12:36:22PM +0200, Alex Ernst via Gcc-bugs wrote:
> $ gcc -v
> gcc version 10.2.1 20210110 (Debian 10.2.1-6)
>
> $ clang -v
> Debian clang version 11.0.1-2
>
> $ cat hello.c
> int i;main(){for(;i["] o, world!\n",'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}
Garbage in, garbage out. This invokes UB in several spots.
One is that read has the second argument implicitly int, you pass
a const char * argument to it and because write is also unprototyped,
the second argument to it is also int. Expecting that it passes
in the full pointer is wrong, it "happens to work" on most 32-bit
targets where pointers are the same size as integers and if they
are passed the same way.
This can be fixed by adding char*i; before {write,
but you need to change i/i to p/p or something similar because
you can't divide pointers.
But once you do that, there is another UB, i-- on the first iteration
is invalid pointer arithmetics - "Hello, world!\n"-1 .
Jakub
Re: [Bug lto/95548] ice in tree_to_shwi, at tree.c:7321
On Fri, Jun 05, 2020 at 12:46:15PM +0200, Jan Hubicka wrote: > > I think Honza ran into this himself. > Yep, i converted code to use wide-ints. But it is nice to have short > testcase. For the testsuite perhaps also add another one with __int128_t and/or __uint128_t enumerators (guarded with #ifdef __SIZEOF_INT128__). Jakub
