: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
The code:
```
struct S {
std::size_t len{s.size()};
std::string s{"A rather long string"};
};
```
warns on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110197
--- Comment #11 from Matt Godbolt ---
Thank you Patrick! Great news! About 1/3 of my build's output is this warning
right now :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110197
--- Comment #8 from Matt Godbolt ---
Fantastic: thanks everyone!
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
The following code, compiled on GCC 13.1 complains of a non-constexpr safe
array access:
```
#include
#include
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68274
--- Comment #5 from Matt Godbolt ---
Amazing: thank you Andrew!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020
--- Comment #13 from Matt Godbolt ---
Thanks Andrew!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020
--- Comment #6 from Matt Godbolt ---
I'm afraid to say I've been unable to make a repro case in the short time I had
to try - will get back to this but about to go on vacation (!). That's to say
dumping the files from CE and using:
CXX=/opt/com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020
--- Comment #5 from Matt Godbolt ---
Thanks! Understood re: cmake; I wouldn't have picked it but it was the easiest
way to repro something on compiler explorer for Howard at the time. I'm sure we
can get it down to a smaller cast and a shell scr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020
--- Comment #2 from Matt Godbolt ---
There are many hundreds of similar errors in that example; perhaps this example
is more of a clue:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/move.h:205:11:
warning: writing 1 byte into a regi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020
--- Comment #1 from Matt Godbolt ---
Apologies for the unreduced issue, if I get a chance I'll try and shorten it,
but I hoped someone might recognise what the issue is from just this.
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
When using Howard Hinnant's date library, and GCC 12.1 on x86, and then with
LTO enabled, ther
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #21 from Matt Godbolt ---
Thanks, I'd love to upgrade but in this instance I'm stuck on GCC 9.x until the
rest of my company can move to it. Nothing annoys me more than having to say
that, but ... at least we know what it is and that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #17 from Matt Godbolt ---
This is proprietary code (that the App and Sentry files didn't really contain
anything I was concerned about), and it links with a number of other libraries
which are much more proprietary (e.g. lwave env/li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #15 from Matt Godbolt ---
> Can you please try reproducing it locally with the 2 pre-processed file.
I'm not sure how to: if I don't have all the object files available in my link
line I get missing symbol errors before any lto1 inv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #13 from Matt Godbolt ---
Both attached. When they're built they're built with:
```
/home/mgodbolt/dev/wave/cmake-build-release/env/bin/x86_64-conda_cos6-linux-gnu-g++
-DSPDLOG_FMT_EXTERNAL -Igenerated -I../src -I../src/wave/common/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #12 from Matt Godbolt ---
Created attachment 51361
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51361&action=edit
preprocessed. gzipped, Sentry.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #11 from Matt Godbolt ---
Created attachment 51360
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51360&action=edit
preprocessed, gzipped App.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #10 from Matt Godbolt ---
Thanks! Will attach!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #5 from Matt Godbolt ---
> And can you please test a more recent compiler (gcc-10 or gcc-11)?
Unfortunately not easily; we have a whole ecosystem of libraries we link in
(not attached here).
If we get any more time we'll try and up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #4 from Matt Godbolt ---
Interestingly, if we extract (with nm x) the files in the library, and glob
them in instead of naming the library file, everything works. We're having
difficulty constructing a reduced case, as we need a whol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #2 from Matt Godbolt ---
Hi Martin!
Thanks for the quick reply. We don't have an easy way to do this in our current
setup: those files are built and published as a library by a different system.
We'll give it a go though.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Whillinking against a static library containing LTO objects, the `lto1` stage
crashes with a segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
--- Comment #2 from Matt Godbolt ---
Thanks: I was confused (as I think will many folks be). The examples for
designated initialisers in C++20 on cppreference cite this behaviour as being
useful^. Of course I understand it can be misused, and thi
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
The following code, with -Wall -Wextra, GCC 10.x or trunk, -std=c++20:
```
struct MyObj {
MyObj();
};
struct Test {
int a{};
MyObj obj;
};
Test t() {
Test t
++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Filing on behalf of @lunasorcery (on twitter):
The following code:
```
#include
struct S {
S(char const* message) {
puts(message);
}
};
void operator,(S,S){}
int main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94797
--- Comment #3 from Matt Godbolt ---
Thanks so much!
onent: other
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
With trunk gcc and latest binutils, `c++filt` does not demangle spaceship
operator, leaving `_ZNK3FoossERKS_` mangled.
[ see, e.g. https://github.com/mattgodbolt/com
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
It seems around GCC 7 an optimization was added turning multiple comparisons of
a small range into a bit-select. This optimization seems to
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
The code:
---snip
int func(int val, const int *ptr)
{
int res = val + 1234;
if (res == *ptr)
{
res = 0
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
In the following code:
---
struct S {
char uninit;
char initialised = 11;
char variable[];
};
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67632
Matt Godbolt changed:
What|Removed |Added
CC||matt at godbolt dot org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81004
--- Comment #24 from Matt Godbolt ---
Thanks so much for looking in to this Jan!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81004
--- Comment #16 from Matt Godbolt ---
I see the target milestone is 7.3, but this bug is still marked NEW. Has there
been any further thought on this? I realise this is a tough one, but we've had
to either disable LTO, or roll back to c++14 on ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837
Matt Godbolt changed:
What|Removed |Added
CC||matt at godbolt dot org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82299
--- Comment #7 from Matt Godbolt ---
Perfect! Thanks for clarifying, sorry for the confusion :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82299
--- Comment #5 from Matt Godbolt ---
NB the proposed patch above has a test that compiles with -std=c++11 -- this
bug only occurs with std=c++1z, not 11. The fix may be right, but I wonder if
the test needs to be changed? Unless I've misread some
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
The follow code:
```
// compile with -Wuseless-cast -std=c++1z
enum Enum : char { A = 0, B = 1 };
struct S {
Enum e { Enum
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Consider the C++ code:
```
#include
#include
constexpr auto get_tokens()
{
return std::array{"This is my stri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #34 from Matt Godbolt ---
Confirmed this fixes all the issues we were seeing. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48227
--- Comment #5 from Matt Godbolt ---
Seems to have been fixed in 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #32 from Matt Godbolt ---
Thanks! One thing, I probably misunderstand this, but you've put 7.1 in "known
to work" above: is this on purpose? 7.1 is the version the issue comes up in, I
assume it'll be fixed in an upcoming 7.2 release?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81004
--- Comment #14 from Matt Godbolt ---
I've just hit this same issue too (in only one of several projects I build with
7.1 and LTO). If anyone has any thoughts at a workaround I'd be very
appreciative. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #2 from Matt Godbolt ---
Thanks Martin!
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80629
--- Comment #1 from Matt Godbolt ---
This bug is noticeable in Compiler Explorer: https://godbolt.org/g/scFj7A for
example; the function is not colourised as CE uses the .locs to track how the
source lines map to asm. One can also see how the bug
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Firstly; I appreciate how tricky it is to keep track of debug information in
the presence of optimization and inlining, but I wonder if there's something
specific happ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80559
--- Comment #2 from Matt Godbolt ---
Thanks: it seems the command-line parameter `-std=c++1z` is needed to trigger
the segfault.
https://godbolt.org/g/6oDO6X
Apologies for not realising this in the initial report.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Build: GCC v8.0.0 (built from source 20170428)
The following code:
#include
template
struct Stack_t {};
template
constexpr
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Consider the following (unusual) code:
--
struct Foo { static constexpr bool hasBar() { return true; } };
void test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834
--- Comment #2 from Matt Godbolt ---
if constexpr is of course the right solution here, for certain.
I appreciate the compiler determining which if() branch to take in the
non-constexpr case is tricky.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #16 from Matt Godbolt ---
Just to be clear; I've been told GCC 6.2 is not required to compile the code I
linked; the earliest compiler it has been repro'd with is 4.9 (though we
haven't tested further back). It's also the mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #14 from Matt Godbolt ---
Created attachment 40101
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40101&action=edit
compile with gcc 6.2 -std=c++14
This reproduces the issue. Compile with g++ 6.2 and -std=c++14 to create a file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #13 from Matt Godbolt ---
We will try and get a small repro case. It comes from open source software:
it's from the compiling_tests.cpp program in trompeloeil
(https://github.com/rollbear/trompeloeil/blob/master/compiling_tests.cpp. T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414
Matt Godbolt changed:
What|Removed |Added
CC||matt at godbolt dot org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
Matt Godbolt changed:
What|Removed |Added
CC||matt at godbolt dot org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69188
--- Comment #15 from Matt Godbolt ---
I just tried on GCC 6.1; same issue (lto-symtab.c:119 similarly to anthony's
snapshot build).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69188
--- Comment #14 from Matt Godbolt ---
We confirm seeing the same issue (a large proprietary system, when building
optimized tests at -O3 but linking against test libraries compiled with -O2).
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Consider some code which tries to placement-new into an internal buffer (if the
object fits), else uses the heap:
--
#include
struct Test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70647
--- Comment #4 from Matt Godbolt ---
Agreed re: cast/FE.
I couldn't quite get your example to fail as the "o" parameter is unusued
(which would be a good clue!
#include // for std::move
struct B {
int a; int b;
B(B &&o)
: a(b),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70647
--- Comment #2 from Matt Godbolt ---
Thanks Manuel. Interestingly this does elicit a warning:
struct B {
int a; int b;
B(B &&o)
: a(static_cast(a)),
b(std::move(o.b)) {}
};
but this does not:
struct B {
int a; int b;
B(B
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Consider the following code:
#include // for std::move
struct A {
int a; int b;
A(A &&o)
: a(a), // I get a warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68274
--- Comment #2 from Matt Godbolt ---
Thanks for updating the bug. As a corollary, moving the unreachability above
the returns yields the same code as the non-unreachable: https://goo.gl/MdULOs
--
int test_with_unreach_First(Side side, const Foo
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
While experimenting with __builtin_unreachable I found that in some cases
adding it pessimizes the code. Consider the following code (also at
https://goo.gl/WmR8PX):
--
enum Side { Bid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68148
--- Comment #2 from Matt Godbolt ---
That would make sense for my second observation; but if it's a per-call thing
why is only one of the calls speculatively devirtualized?
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Given the code:
struct Interface {
virtual ~Interface() {}
virtual void virtualFunc() = 0;
virtual void virtualFunc2() = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809
Matt Godbolt changed:
What|Removed |Added
CC||matt at godbolt dot org
--- Comment #1
onent: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
The following code:
```
struct Foo {
Foo *next;
void release() {
Foo *tmp = 0;
for (Foo *it = next; it; it = tmp) {
tmp = it-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66259
--- Comment #7 from Matt Godbolt ---
I just tried with binutils 2.24 instead of 2.25, and the issue did not manifest
itself.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66259
Matt Godbolt changed:
What|Removed |Added
CC||matt at godbolt dot org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53730
Matt Godbolt changed:
What|Removed |Added
CC||matt at godbolt dot org
--- Comment #4
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
I noticed a missed opportunity in GCC that Clang and ICC seem to take advantage
of. All versions of GCC I tested (up to 4.9.0) seem to have the same trouble.
The following source (for x86_64) shows up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723
--- Comment #8 from Matt Godbolt ---
Thanks Nicholas :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723
Matt Godbolt changed:
What|Removed |Added
CC||matt at godbolt dot org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61412
Matt Godbolt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61412
--- Comment #12 from Matt Godbolt ---
I appreciate your patience on this! I'm also now confused. My 250k+
preprocessed file does not warn on a reordered constructor initializer, despite
there being no system code or macros involved in it. Compi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61412
--- Comment #5 from Matt Godbolt ---
I produced the file by preprocessing an existing file with g++ -E on an
existing file that exhibited the file (250k+ lines).
The full line I used to create the original preprocessed file is:
$ g++ -c -std=gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61412
--- Comment #3 from Matt Godbolt ---
Many apologies: this does indeed also happen with GCC 4.7.2! Thanks for
checking.
Also, re: the -Wsystem-headers, this does indeed fix this case but of course in
general isn't a good workaround as system head
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Some warnings appear to be lost when compiling a previously-preprocessed source
file (e.g. as a result of using ccache, which caches the intermediate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60955
--- Comment #1 from Matt Godbolt ---
The previous snippet wasn't quite as minimal as it could be. This single line
also reproduces it:
unsigned int erroneous_warning(register int a) { return (a); }
Jonathan Wakely mentioned this may be related
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
This short snippet, when compiled with GCC4.9.0 and -Wextra and -std=c++1y,
gives an erroneous warning about taking the address of a register:
===
$ cat test2.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52026
Matt Godbolt changed:
What|Removed |Added
CC||matt at godbolt dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
Bug #: 3
Summary: Segmentation fault when calling vector::push_back with
an initialized list
Classification: Unclassified
Product: gcc
Version: 4.8.0
St
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55532
--- Comment #1 from Matt Godbolt 2012-11-29 20:03:47
UTC ---
I can reproduce this on GCC 4.8 (rev 185382], and g++ 4.6.3. Adding -O makes
the issue go away (as the whole program is optimized to "return 0;").
From the assembler dump the segv ap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54206
Matt Godbolt changed:
What|Removed |Added
CC||matt at godbolt dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54801
Bug #: 54801
Summary: [c++11] static variables constructed with lambda
params inside member functions cause undefined errors
Classification: Unclassified
Product: gcc
Ve
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52837
Matt Godbolt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52759
Matt Godbolt changed:
What|Removed |Added
CC||matt at godbolt dot org
--- Comment #7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52837
--- Comment #3 from Matt Godbolt 2012-04-02 22:52:26
UTC ---
Created attachment 27072
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27072
Minimal reproducible test case
$ /site/apps/gcc-4.7.0-drw.2/bin/gcc -c gcc-4.7-ice-demangle.cc
gcc-4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52837
--- Comment #2 from Matt Godbolt 2012-04-02 22:51:14
UTC ---
After a little more research, I've managed to get a 4-line reproduction case.
(See attached).
I also confirmed this code compiles without error on GCC4.5 and GCC4.6.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52837
--- Comment #1 from Matt Godbolt 2012-04-02 22:17:15
UTC ---
Created attachment 27071
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27071
This is the .ii file that reproduces the problem. (gzipped to get past upload
limitations)
(attempt a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52837
Bug #: 52837
Summary: ICE in cp/mangle.c:3306
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
91 matches
Mail list logo
