https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016
--- Comment #6 from Marc Singer ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Marc Singer from comment #4)
> > I found that there are cases in the same program where it does compile.
>
> Yes there might be some cases where stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016
--- Comment #4 from Marc Singer ---
I found that there are cases in the same program where it does compile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016
--- Comment #1 from Marc Singer ---
Created attachment 61825
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61825&action=edit
Preprocessed version of the failing source file.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: beewoolie at proton dot me
Target Milestone: ---
Greetings,
I will attach the preprocessed source to this message. I think I see what the
compiler doesn't accept.
/** *** FIXME: code generates a compiler error when enc
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: moorabbit at proton dot me
Target Milestone: ---
While working on implementing __builtin_stack_address() for Clang, I noticed
that GCC can produce different results for this
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: a.horodniceanu at proton dot me
Target Milestone: ---
With a sample program
-
deprecated void foo () {}
void bar () { foo; }
-
And invoking gdc with both -Werror and -Wno-error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120799
--- Comment #5 from Justus ---
I understand that C considers this UB, but I don't understand how this is
different from, say, _mm_storel_epi64? It's also technically UB. The only
difference is one takes a double * and the other takes an __m128i
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: justus2510 at proton dot me
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120686
--- Comment #1 from Egor Bychin ---
FYI: clang has a similar issue
https://github.com/llvm/llvm-project/issues/144540
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: e.siga at proton dot me
Target Milestone: ---
template
struct constant {};
template
auto fast_tuple(Args... args)
{
return
[...args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120613
--- Comment #9 from P. Ruber ---
Thank you very much for all the feedback! Will notify downstream.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120613
--- Comment #5 from P. Ruber ---
(In reply to Andrew Pinski from comment #3)
> or might it be a dup of bug 98845 . Both were fixed in Feburary .
Should these be backported to GCC 14 by upstream or Red Hat?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120613
--- Comment #4 from P. Ruber ---
Created attachment 61611
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61611&action=edit
Preprocessed source
Source attached.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120613
--- Comment #1 from P. Ruber ---
*** Bug 120612 has been marked as a duplicate of this bug. ***
Assignee: unassigned at gcc dot gnu.org
Reporter: redhat.bugzilla at proton dot me
Target Milestone: ---
Resolution: DUPLICATE
Status: RESOLVED
gcc version 14.2.1 20250110 (Red Hat 14.2.1-7) on Almalinux 10
Options:
./configure CFLAGS='-O2 -march=n
Assignee: unassigned at gcc dot gnu.org
Reporter: redhat.bugzilla at proton dot me
Target Milestone: ---
gcc version 14.2.1 20250110 (Red Hat 14.2.1-7) on Almalinux 10
Options:
./configure CFLAGS='-O2 -march=native' --prefix=/usr/local/php848 --enable-intl
--w
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ethanhancock at me dot com
Target Milestone: ---
https://godbolt.org/z/TaGbYr33r
GCC accepts the following:
int main() {
auto l = [](){ return 42; };
return l._FUN();
}
The static member _FUN is exposed and usable.
This does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120511
--- Comment #7 from Chris Leonard ---
The function `process_init_element` in source file gcc/c/c-typeck.cc clears
`constructor_zeroinit` if `!integer_zerop (value.value)`.
The problem is triggered by using a floating-point type for the initial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120511
--- Comment #6 from Chris Leonard ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > >struct test t = {0};
> >
> > Stopped warning in GCC 5. So maybe this is just on accident.
>
> Looks like that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120511
--- Comment #2 from Chris Leonard ---
Note that the exact same code using an int instead of a double has no warning.
So either the code using int needs a warning, or this code needs no warning.
Elements in an array of structs should be initial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120511
--- Comment #3 from Chris Leonard ---
(In reply to Chris Leonard from comment #2)
> Note that the exact same code using an int instead of a double has no
> warning. So either the code using int needs a warning, or this code needs
> no warning.
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chris.j.leonard at proton dot me
Target Milestone: ---
The following C source causes an erroneous -Wmissing-field-initializers warning
on the penultimate line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119590
Alisdair Meredith changed:
What|Removed |Added
CC||alisdairm at me dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107953
Ethan Hancock changed:
What|Removed |Added
CC||ethanhancock at me dot com
--- Comment
++
Assignee: unassigned at gcc dot gnu.org
Reporter: kongmingd234 at proton dot me
Target Milestone: ---
Created attachment 61452
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61452&action=edit
This code does not compile.
The code given in the file does not compile,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79748
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #4 from
.
||me
--- Comment #3 from stephematician ---
I encountered what I believe is the same bug while compiling an R package for
CRAN.
I reduced the code to the following example which produces errors on 12.4,
13.1-13.3, 14.1-14.2.
An array-bounds warning occurs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120056
--- Comment #1 from catsith at me dot com ---
The source code comment is wrong; std::expected template arguments do matter -
replacing int with void removes the issue.
The use of function pointers isn't necessary to trigger this; also ha
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: catsith at me dot com
Target Milestone: ---
Created attachment 61265
--> https://gcc.gnu.org/bugzi
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kongmingd234 at proton dot me
Target Milestone: ---
Created attachment 61259
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61259&action=edit
This program
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kptas at proton dot me
Target Milestone: ---
Compiler: latest gcc 16.0 built from git.
When using c++ modules, put primary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119899
--- Comment #6 from Frederik vom Hofe ---
Thx, good it!
Basically template libraries might want to make heavy use of
function-name-brackets, e.g. (invoke), to prevent the lookup using pulled in
namespaces from parameter types.
: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: frederik.hofe at pm dot me
Target Milestone: ---
I get a name collision with std::invoke when using my custom invoke with a
std::ref parameter, without pulling in the
: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: a.horodniceanu at proton dot me
Target Milestone: ---
The following was reduced from the onedrive client application:
```object.d
module object;
```
```onedrive.d
module onedrive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022
--- Comment #17 from Fangrui Song ---
I hope that we just remove this malloc+memset => calloc transformation. Even in
the malloc-dom-memset and memset-postdom-malloc case, calloc might not be an
optimization. It is not worth the extra code comple
turn) type,
inside other lambda template
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frederik.hofe at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119081
Ben Boeckel changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #5 f
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arvo at me dot com
Target Milestone: ---
Created attachment 60174
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60174&
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: crab.delicieux at pm dot me
Target Milestone: ---
Created attachment 60033
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60033&action=edit
Archive containing original source code + .ii output from GCC + ful
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: uwu at icenowy dot me
Target Milestone: ---
Created attachment 59911
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59911&action=edit
The sour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117992
--- Comment #11 from Icenowy Zheng ---
Checked gcc -v, there's really enable-default-pie, and in the output of "gcc
main.c -fhardened -O2 -flto -v", the COLLECT_GCC_OPTIONS lists really include
"-pie".
Thus the explanation by Ruoyao looks reaso
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117992
--- Comment #7 from Icenowy Zheng ---
Does -flto imply -pie ? I cannot understand the discussion here now...
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: emilia144 at proton dot me
Target Milestone: ---
Hello, I am compiling the following code with g++ 11.4.0, -std=c++20, on WSL
(Windows Subsystem for Linux) Ubuntu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117913
--- Comment #4 from Alisdair Meredith ---
In this case, clang and MSVC are not even considering the destroying delete
within the noexcept operator within a static_assert --- I am not sure at what
point that breaks down though. The runtime tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117913
--- Comment #3 from Alisdair Meredith ---
Clang and MSVC have bigger bugs that I am filing bug reports on shortly!
EDG gets this correct and passes all parts of the test, including the
"expected" undefined behavior:
https://godbolt.org/z/EG3EP5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117913
--- Comment #1 from Alisdair Meredith ---
Sorry, I made no effort to verify how far back this bug goes, but I expect it
has been an issue ever since destroying delete was first implemented.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
According to [except.spec] 14.5p9, "A deallocation function (6.7.6.5.3) with no
explicit noexcept-specifier has a non-thr
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anstro.pleuton at proton dot me
Target Milestone: ---
This happens when I create a custom type that inherits std::span, and add
deduction guide to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115016
--- Comment #2 from Mark Starovoytov ---
This issue is still reproducible with 14.2 and trunk.
Another godbolt example (very similar): https://godbolt.org/z/3xrMGMYx7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116098
--- Comment #25 from Laria Chabowski ---
Sorry for the late reply, I have now checked the current trunk with the program
where I originally saw this bug. It's fixed now. Many thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61379
--- Comment #6 from k4lizen at proton dot me ---
I understand what you're saying but I'm hoping that there would be *some*
solution for annotating such functions as noreturn. It's highly
counterintuitive that even after marking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61379
--- Comment #4 from k4lizen at proton dot me ---
re: jakub
Does what you're saying also apply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117337 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535
--- Comment #15 from Alisdair Meredith ---
I suggest either INVALID or WONTFIX would be appropriate, depending on whether
you think the original report on a change of behavior was valid.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: k4lizen at proton dot me
Target Milestone: ---
Created attachment 59481
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59481&action=edit
source file
Versions:
g++ (GCC) 14.2.1 20240910
6.11.3-artix1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115242
--- Comment #5 from Alisa Sireneva ---
Sorry for spam, just wanted to add some more context and maybe take back some
of my conclusions. This has gotten more offtopic than I expected, so please
tell me if I need to file another bug.
According
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115242
Alisa Sireneva changed:
What|Removed |Added
CC||me at purplesyringa dot moe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92034
--- Comment #6 from Alisdair Meredith ---
Minor update: in the current standard, the paragraph number is now p12, and per
my last comment, I still believe the use of "shall" makes this ill-formed, and
without "no diagnostic required" wording it s
stopped looking for which
version has the fix as that would mean installing multiple compilers for me :)
I believe this issue can be closed, but not sure what the right resolution
category would be.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117067
--- Comment #5 from Lobel Krivic ---
Sorry, I am not able to follow you. Could you please explain it a bit more? Is
this a bug in the code or in the compiler?
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: a.horodniceanu at proton dot me
Target Milestone: ---
The following code causes an ICE since
964fd402c9b48eb4da91fb3e4e45d4560d6c676c:
--
module object;
enum Foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116961
--- Comment #4 from Andrei Horodniceanu ---
Sorry for the wait:
-
$ cat repro.d
module object;
struct Gcx
{
float thing = 0.0;
}
$ /root/build/./gcc/gdc -B/root/build/./gcc/
-B/tmp/gcc/x86_64-pc-linux-gnu/bin/ -B/tmp/gcc/x86_64-pc-linux-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117067
--- Comment #2 from Lobel Krivic ---
Comment on attachment 59312
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59312
the preprocessed file
I had to compress it since it was a bit more than 1000KB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117067
--- Comment #1 from Lobel Krivic ---
Created attachment 59312
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59312&action=edit
the preprocessed file
I had to compress it since it was a bit more than 1000KB.
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lobel.krivic at proton dot me
Target Milestone: ---
The following source code:
```
#include
#include
#include
#include
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: a.horodniceanu at proton dot me
Target Milestone: ---
Reported first at https://bugs.gentoo.org
ilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240903 (experimental) (GCC)
Also reproducible on godbolt.org, which apparently uses this version for trunk:
g++
(Compiler-Explorer-Build-gcc-1735917cee41fe680d9dd3c0c26b45520c17413a-binutils-2.42)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287
--- Comment #7 from Alisdair Meredith ---
Late comment: according to [intro.multithread.general] it is a requirement for
hosted implementations to support more than one thread of execution, but
implementation defined for a free-standing implement
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amy at amyspark dot me
Target Milestone: ---
Hi all,
I have the following test case that compiles in Clang 20.0.0 commit
7d5281a66d5d42c65cfb9d95eaf9aa01afb089fb :
```c
xample code in the issue also compiles fine for me, I don't know what's
with that.
Anyways, the PR does fix the issue. Thank you for the quick response.
: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: a.horodniceanu at proton dot me
Target Milestone: ---
The following code produces an ICE beginning with commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116368
--- Comment #2 from delacroix777 at proton dot me ---
So you've known about the existence of this bug for 7 years now, but still no
fix?
++
Assignee: unassigned at gcc dot gnu.org
Reporter: delacroix777 at proton dot me
Target Milestone: ---
The exact version of GCC:
gcc version 14.2.0 (Rev1, Built by MSYS2 project) - the latest version
package mingw-w64-ucrt-x86_64-gcc
The system type:
Windows 11 64-bit 23H2
The options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90960
--- Comment #4 from Alisdair Meredith ---
I now believe my original bug report is invalid, due to a rarely consulted
paragraph of the standard, [temp.spec.general]p8.
If a function declaration acquired its function type through a dependent type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116191
--- Comment #5 from ilija.tovilo ---
That's true ofc, but if you look at the example:
__attribute__((cold)) extern void cold_func(void);
Simply removing the cold attribute will cause zend_string_release() to be
inlined, so it is indeed involve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116191
--- Comment #3 from ilija.tovilo ---
(In reply to Andi Kleen from comment #2)
> I suppose it depends on the programing style if it's a good idea. Sometimes
> inlining allows to constant propagate and collapse a lot of code, and you
> definitely
Assignee: unassigned at gcc dot gnu.org
Reporter: ilija.tovilo at me dot com
Target Milestone: ---
Note that I raised this issue on the mailing list first, but was asked to
create a bug report instead.
https://gcc.gnu.org/pipermail/gcc/2024-July/244509.html
I noticed that, in our
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93022
Amyspark changed:
What|Removed |Added
CC||amy at amyspark dot me
--- Comment #1 from
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: laria at laria dot me
Target Milestone: ---
Created attachment 58762
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58762&action=edit
preprocessed test-O1.i
I have encoun
: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: mail+gcc at nh2 dot me
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Please see:
"Why does my OpenMP app sometimes use only 1 thread, sometimes 3, sometimes all
cores?"
https://stackov
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: a.horodniceanu at proton dot me
Target Milestone: ---
Given the two source files:
a.cpp:
-
struct Foo { };
void bar(Foo foo);
int main() {
bar
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cody at tapscott dot me
Target Milestone: ---
Created attachment 58334
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58334&action=edit
reduced test case
The `__builtin_sub_o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105576
--- Comment #14 from Fangrui Song ---
> Is there a way to capture a method address in inline asm that works in
> -fPIC mode? Specifically I want to capture the address of a static
> method that's in a class that's local to a function. I'm able t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115190
--- Comment #6 from Ben Boeckel ---
> The line ending of last line is also required. Personally feel strange.
This is explicitly handled (as a "no, not supported" case):
https://github.com/gcc-mirror/gcc/blob/4efa7ec85a85c6024d0907a0e735ad5df7f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115190
--- Comment #1 from Ben Boeckel ---
My analysis points to the change needing to happen in
1module_resolver::read_tuple_file` in `c++tools/resolver.cc`.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: lobel.krivic at proton dot me
Target Milestone: ---
Created attachment 58183
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58183&action=edit
the preprocessed file
The following source code:
```
#include
#include
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102241
Oliver Jahn changed:
What|Removed |Added
CC||oliverjahn at proton dot me
--- Comment
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fried.ink at pm dot me
Target Milestone: ---
Created attachment 57875
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57875&action=edit
Example code demonstrating the issue
Example code attached which demon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #17 from
++
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
Clang supports [[clang::no_destroy]] (alternative form:
`__attribute__((no_destroy))`) to disable exit-time destructors of variables of
static or thread local storage duration.
* July
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111555
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114217
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114171
--- Comment #3 from Andrei Horodniceanu ---
(In reply to Hongtao Liu from comment #2)
> on rtl level,we get
>
> (insn 7 6 8 2 (set (reg:CCZ 17 flags)
> (compare:CCZ (mem:TI (plus:DI (reg/f:DI 100 [ _5 ])
> (const_int
: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: a.horodniceanu at proton dot me
Target Milestone: ---
I've hit this initially in the tests of D-Scanner but I've reduced it to:
---
struct Token {
st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987
--- Comment #1 from Fangrui Song ---
BTW,
https://github.com/llvm/llvm-project/blob/main/clang/test/SemaCXX/uninitialized.cpp
has many member initializer list examples
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
https://godbolt.org/z/G7ndsTv5c (from
https://github.com/llvm/llvm-project/pull/81179#issuecomment-1937082113
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710
Amyspark changed:
What|Removed |Added
CC||amy at amyspark dot me
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113769
--- Comment #1 from SymbioticFemale ---
Notably, it occurs with -Wall -Wextra -O2, etc. Integer size is irrelevant.
Changing the function do_nothing to 'static inline' does not make a difference.
It occurs with either pthread_mutex_t or pthread
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: symbioticfemale at cumallover dot me
Target Milestone: ---
// The "used uninitialized" warning is not produced on both GCC and Tiny
Compiler. Clang recognizes the error. (-Wall on all compilers). See lin
|--- |FIXED
--- Comment #11 from Fangrui Song ---
Thanks to HJ for landing the GCC patch (milestone: 15?) for me.
Note that I made a typo in the commit message. "Ws" should typically be used
with the modifier 'p'
```
namespace ns { extern int var; }
1 - 100 of 753 matches
Mail list logo
