: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
The asm in a naked function may reasonably expect the argument registers and
the
return address register (if present) to be live
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109707
--- Comment #1 from Fangrui Song ---
I came here from a PR for Clang:
https://github.com/llvm/llvm-project/issues/62504
-project/issues/62504 makes sense to me: the only
one reasonable way is probably to skip naked functions.
The Linux kernel ran into this combination in 2009 and they switched to use
__attribute__((naked)) and __attribute__((__no_instrument_function__)) together
in https://git.kernel.o
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: me at manueljacob dot de
Target Milestone: ---
When tar is not installed, building GCC under Linux will fail, at least with
the default configuration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109709
--- Comment #3 from Manuel Jacob ---
(In reply to Richard Biener from comment #1)
> Huh, can you post how it fails?
if [ -d ../prev-gcc ]; then \
cd ../prev-gcc && \
make real-install-headers-tar DESTDIR=`pwd`/../gcc/ \
libsubdir=. ; \
seem reasonable to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105576
--- Comment #6 from Fangrui Song ---
(In reply to Hongtao.liu from comment #4)
> constraint "i" + "%p0"?
>
> asm (".pushsection .xxx,\"aw\"; .dc.a %p0; .popsection" :: "i"(addr)); //
> supported on aarch64 and riscv
> asm (".pushsection .xx
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amy at amyspark dot me
Target Milestone: ---
Hi,
Coming from
https://github.com/msys2/MINGW-packages/pull/16968#issuecomment-1541465457.
I've found a crash in cc1plus 13.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
--- Comment #3 from Amyspark ---
Created attachment 55046
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55046&action=edit
ZIP copy of the Github gist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
--- Comment #4 from Amyspark ---
(In reply to Richard Biener from comment #2)
> Likely a duplicate of a bug where ranger runs out of stack on windows
> targets.
I think you mean bug 109695? If so, it affects GCC 13 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
--- Comment #9 from Amyspark ---
(In reply to Andrew Pinski from comment #7)
> Simple testcase:
> ```
> struct basic_string {
> ~basic_string() { }
> };
> const basic_string data[] = { {} };
> ```
>
> This fails with `ulimit -s 1024` which is
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=102241
Oliver Jahn changed:
What|Removed |Added
CC||oliverjahn at proton dot me
--- Comment
++
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=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`.
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=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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467
Ben Boeckel changed:
What|Removed |Added
CC||bugzilla.gcc at me dot
benboeckel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111213
--- Comment #3 from mengli ming ---
(In reply to David Malcolm from comment #1)
> (In reply to mengli ming from comment #0)
>
> Thanks for filing this bug.
>
> > Hi, this case (https://godbolt.org/z/98PMz1KKz) contains an out-of-bound
> > erro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110520
--- Comment #2 from mengli ming ---
(In reply to David Malcolm from comment #1)
> Thanks for filing this bug.
>
> With trunk (for gcc 14) I correctly get a NPD warning (true positive):
> https://godbolt.org/z/a5h38cz7d
>
> With gcc 13.2, I d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111095
--- Comment #3 from mengli ming ---
(In reply to David Malcolm from comment #1)
> Thanks for filing this bug.
>
> This looks similar to bug 111213.
>
> Adding -fdump-ipa-analyzer=stderr shows that at -O1 and above, the entire
> body of the fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111441
--- Comment #4 from mengli ming ---
Hi, I've checked recently and the crash still persists, even with the -O0
optimization level.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111095
--- Comment #4 from mengli ming ---
(In reply to David Malcolm from comment #1)
> Thanks for filing this bug.
>
> This looks similar to bug 111213.
>
> Adding -fdump-ipa-analyzer=stderr shows that at -O1 and above, the entire
> body of the fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111095
--- Comment #5 from mengli ming ---
Created attachment 56202
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56202&action=edit
Under the `-O0` optimization level, irrelevant code affects whether the
analyzer will report an out-of-bound warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111635
--- Comment #6 from Amyspark ---
I need to recover my GCC installation post Homebrew forcing an OS upgrade to
Monterey. Still, I think this needs to be tested against the x64 target -- I've
seen some issues only happening when targeting it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111635
--- Comment #7 from Amyspark ---
I can confirm this is no longer reproducible with macOS Monterey 12.7, Xcode
14.2, and the following linker version:
@(#)PROGRAM:ld PROJECT:ld64-820.1
BUILD 20:07:01 Nov 7 2022
configured to support archs: arm
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amy at amyspark dot me
Target Milestone: ---
Created attachment 55181
--> https://gcc.gnu.org/bugzilla/attachment.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016
--- Comment #2 from Amyspark ---
We've seen failures both in Windows (all ABI flavors) and macOS only when
compiled with GCC -- AppleClang, Clang, and MSVC (in its three flavors) all
work without issue. So I'm doubtful it's a logical issue, espe
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
Clang introduced `__builtin_memcpy_inline` (https://reviews.llvm.org/D73543) in
2020 and `__builtin_memset_inline` (https://reviews.llvm.org/D126903) in 2022.
The two builtin functions expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456
--- Comment #8 from gccriscvuser at proton dot me ---
Thoughts?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456
--- Comment #12 from gccriscvuser at proton dot me ---
Updating the documentation is good, but there should also be an error
diagnostic, right?
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ryanpholt at me dot com
Target Milestone: ---
Created attachment 55423
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55423&action=edit
Reproduction file
Compiling the attached example with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110472
--- Comment #2 from Ryan Holt ---
(In reply to Andrew Pinski from comment #1)
> I think it is just wrong iv-opt choices.
>
> Works just fine on aarch64-linux-gnu too:
> ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ~/upstream-gcc/bin/gcc t4.c -O2
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dale.mengli.ming at proton dot me
Target Milestone: ---
Hi,in this case (https://godbolt.org/z/4Md3o94Gx), the `ptr` is a null pointer,
but the analyzer doesn't report an NPD wi
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dale.mengli.ming at proton dot me
Target Milestone: ---
Hi, in this case (https://godbolt.org/z/azzTd94hz), the `p` is a null poinetr,
but the analyzer doesn't report an NPD with it.
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dale.mengli.ming at proton dot me
Target Milestone: ---
Hi,
```c
void foo(int pc) {
int *arr[2] = {&&x, &&y};
int var = 0;
goto *arr[pc];
x:
ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110529
--- Comment #1 from mengli ming ---
It's a little odd that there is no output (https://godbolt.org/z/GhshzvaTq) for
`_analyzer_eval(1)` in line 9 and line 13.
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mrks2023 at proton dot me
Target Milestone: ---
I think I found a missed optimization involving std::max() for -march=znver2
(sorry if it was already reported, but I didn't
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
Noticed by Ziwei Mao.
% cat a.c
void f() {}
void g() {}
void h() {}
% gcc -ffunction-sections -fpatchable-function-entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467
--- Comment #8 from Ben Boeckel ---
> Some people even claim that properly supporting Make to build C++ modules is
> not possible if you want to make it actually production quality and reliable.
It is possible, but, AFAIK, requires at least on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467
--- Comment #9 from Ben Boeckel ---
> unless autoconf/automake started relying on the non-GNU `fdep` [1] project.
Gah, editing gone awry. This was about Fortran module support in
autoconf/autotools, not C++ module support (they have similar bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105576
--- Comment #8 from Fangrui Song ---
I've encountered another use case related to metadata sections (establish an
artificial reference for linker garbage collection purposes)
namespace ns { extern int var; } // defined in another translation u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
--- Comment #19 from Amyspark ---
Working on it. Is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315 the patch
you referred to earlier, Richard?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Amyspark changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104816
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #13
|--- |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; }
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
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
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
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
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 #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?
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=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=115242
Alisa Sireneva changed:
What|Removed |Added
CC||me at purplesyringa dot moe
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
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.
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.
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=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=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=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.
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!
: 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
: 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
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.
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 #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=117992
--- Comment #7 from Icenowy Zheng ---
Does -flto imply -pie ? I cannot understand the discussion here now...
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
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
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
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
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
: 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
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.
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
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
: 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=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
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
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
.
||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=79748
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #4 from
++
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=107953
Ethan Hancock changed:
What|Removed |Added
CC||ethanhancock at me dot com
--- Comment
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=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 #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=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 #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
: 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
601 - 700 of 753 matches
Mail list logo
