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; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104816
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #13
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=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=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=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=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=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
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=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=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=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 #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=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=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=105467
Ben Boeckel changed:
What|Removed |Added
CC||bugzilla.gcc at me dot
benboeckel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111635
--- Comment #1 from Amyspark ---
Created attachment 56014
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56014&action=edit
Full compiler version
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: amy at amyspark dot me
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 56013
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56013&action=edit
Full build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111529
--- Comment #2 from Maxim Plyushkin ---
It appears that this regression happened between 8.3 and 8.4, not between 10.1
and 11.1.
dot me
Target Milestone: ---
template
void f() {
[](auto c) {
#pragma GCC unroll 9
for (int i = c; i; --i) {
}
};
}
int main() {
f<0>();
}
compiles with -std=c++14 but with -std=c++17 generates
: In instantiation of 'void f() [with int x = 0]':
:11:7: re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111441
--- Comment #3 from mengli ming ---
Um..regarding the warning about "stack-based buffer over-read", it's a FP.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111441
--- Comment #2 from mengli ming ---
(In reply to Andrew Pinski from comment #1)
> Created attachment 55916 [details]
> testcase
>
> Please next time attach or place the testcase inline instead of just linking
> to godbolt .
Thanks for the remi
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dale.mengli.ming at proton dot me
Target Milestone: ---
Thanks for taking the time to look into this case.
See it live: https://godbolt.org/z/Errh1v5rr.
When the line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110529
--- Comment #6 from mengli ming ---
(In reply to David Malcolm from comment #5)
> Should be fixed on trunk for gcc 14 by the above commit.
Thanks a lot for your hard work!
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dale.mengli.ming at proton dot me
Target Milestone: ---
Hi, this case (https://godbolt.org/z/98PMz1KKz) contains an out-of-bound error
(stmt: `return arr[9];`). At -O0, the analyzer can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589
Peter Frost changed:
What|Removed |Added
CC||mail at pfrost dot me
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110529
--- Comment #2 from mengli ming ---
Um, would you be available to take a look at this case? Your insights would be
greatly appreciated!
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/sKPxGrG8z), the array `l_1322` has a
capacity of 7. However, in relation to the `return
1 - 100 of 726 matches
Mail list logo
