Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
As seen with e.g. gcc-c++-12.2.1-4.fc37.x86_64, it does not reject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106881
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106891
Stephan Bergmann changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106891
--- Comment #1 from Stephan Bergmann ---
Created attachment 53553
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53553=edit
preprocessed source, gzipped to avoid bugzilla size limit
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Bisecting shows this started with
<ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106355
--- Comment #2 from Stephan Bergmann ---
(In reply to Richard Biener from comment #1)
> Did you see whether this is changed behavior from GCC 11?
I didn't check that myself, but the Debian LibreOffice maintainer claims that
he sees the same
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
(I ran into this when trying to build recent LibreOffice 7.5 master on Fedora
36 on s390x causing a crash in one of the executables generated during the
build. I tracked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87729
--- Comment #12 from Stephan Bergmann ---
(In reply to CVS Commits from comment #11)
> The master branch has been updated by Jason Merrill :
>
> https://gcc.gnu.org/g:81bec060e31b6ef2feeb3046c6f13a207c6f698a
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87729
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105291
Stephan Bergmann changed:
What|Removed |Added
Resolution|--- |FIXED
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
Since
<https://github.com/llvm/llvm-project/com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104030
--- Comment #7 from Stephan Bergmann ---
(In reply to Jakub Jelinek from comment #2)
> Of course, if something like libreoffice (I bet) carefully ensures it is
> paired, but constructs it from smaller separate literals, then it is fine.
(Or
: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
As discussed in the sub-thread starting at
<https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585710.html> "Re:
[PATCH] libcpp: Implement -Wbidi-chars f
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
Apparently a recent regression on GCC trunk:
> $ cat test.cc
> #include
> #include
> struct S { ~S() { std::abort(); } };
> int main() {
> new (std::nothrow
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
Apparently a recent regression on GCC trunk:
> $ cat test.cc
> struct S { ~S(); };
> int f() {
> S s;
> if
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
I think this is a recent regression on GCC 12 trunk (I'm at
basepoints/gcc-12-5818-g30a08286e67; it doesn't happen with e.g.
gcc-c++-11.2.1-1.fc35.x86_64):
> $ cat test
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
At least with GCC 11.2.1:
> $ cat test.cc
> #include
> int main() {
> std::valarray v;
> std::begin
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
CC: msebor at gcc dot gnu.org
Target Milestone: ---
On recent trunk (basepoints/gcc-12-3135-gdb3d4129b6f):
> $ cat test.cc
> #include
> #include
> long dummy();
> void * rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68257
--- Comment #10 from Stephan Bergmann ---
(In reply to Andrew Pinski from comment #9)
> There does seems some inconsitency though:
> inline namespace n __attribute__((__abi_tag__(""))) {}
> is rejected but
> inline namespace n
: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With recent GCC 12 trunk (but not with e.g. gcc-c++-11.1.1-3.fc34.x86_64):
> $ cat test.cc
> struct S1 { virtual ~S1(); };
> struct S2 { int m; };
> struct S3 { virtual ~S3(); };
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100797
--- Comment #6 from Stephan Bergmann ---
(In reply to Jason Merrill from comment #5)
> Stephan, can you verify that this fixes the LibreOffice issue?
Yes, thanks, tested the master branch fix and it fixes the LibreOffice issue
for me.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
(I stripped this down from an issue found in LibreOffice,
<https://git.libreoffice.org/c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99446
--- Comment #3 from Stephan Bergmann ---
(In reply to Stephan Bergmann from comment #2)
> At least with recent GCC master (bc2127767a0076afdbc9075fda29f97f82ef7ec6),
> I can consistently reproduce the following:
what I failed to include in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99446
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
At least with gcc-c++-10.2.1-9.fc33.x86_64 and with a local GCC 11 trunk build:
> $ cat test.cc
> struc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98305
--- Comment #3 from Stephan Bergmann ---
(In reply to Martin Sebor from comment #2)
> https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562141.html
Thanks; can confirm that fixes my LibreOffice build.
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With recent GCC 11 trunk (at git commit
8dede2411195eb2fd672d8d0c758f94732bd6d77):
> $ cat test.cc
> #include
> template struct Reference {};
> templa
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
At least with a local build of recent GCC 11 trunk and with
gcc-c++-10.2.1-1.fc32.x86_64:
> $ cat test.cc
> #include
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878
--- Comment #1 from Stephan Bergmann ---
A similar failure happens with typeid (but where the parentheses are not
redundant), and I naively assume it's the same underlying issue:
> $ cat test.cc
> #include
> template struct S { S(char const (&
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
At least with recent GCC 11 trunk and with gcc-c++-10.2.1-1.fc32.x86_64:
> $ cat test.cc
> template struct S {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
--- Comment #13 from Stephan Bergmann ---
FTR, with that second patch building recent LibreOffice succeeds without false
positives.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
--- Comment #11 from Stephan Bergmann ---
(In reply to Martin Sebor from comment #10)
> Patch for the static cast:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550231.html
LibreOffice runs into the same issue, but while the above patch
: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With a locally-built recent GCC 11 trunk (git rev
48b6386f5d0bdcbe5c901678a043516d544a9f7f), but not with e.g.
gcc-c++-10.1.1-1.fc32.x86_64:
> $ cat test.cc
> struct S1 { virtual ~S1(); };
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95103
--- Comment #2 from Stephan Bergmann ---
(In reply to Richard Biener from comment #1)
> Does it work placing the initial part of the function in a separate { }?
Yes,
> @@ -14,11 +14,13 @@
> return true;
> }
> void f3() {
> +{
>
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
I have seen this with at least some GCC 7, and still see it with GCC 10 and
with recent trunk:
> $ cat test.cc
> #include
> #include
> struct S {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92893
--- Comment #9 from Stephan Bergmann ---
(In reply to Martin Sebor from comment #2)
> Defining Str like so works for the test case:
>
> struct Str {
> template Str(Cat c)
> {
> struct Flex { char c, a[]; } *p = (Flex*)get();
>
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
At least with current GCC 10 trunk on Linux x86-64:
> $ cat test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93922
Stephan Bergmann changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #9 from Stephan
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
I came across this when building LibreOffice and its bundled Skia with recent
GCC 10 trunk and it failed to link due
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93824
--- Comment #5 from Stephan Bergmann ---
(In reply to Stephan Bergmann from comment #4)
> So users will have to be careful when they fix a -Wredundant-tags warning in
> an included file. They may have to introduce a forward declaration into the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93824
--- Comment #4 from Stephan Bergmann ---
(In reply to Martin Sebor from comment #3)
> Ah, I see. I'm not sure there's anything I can do about the first case --
> the warning there is by design.
So users will have to be careful when they fix a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93824
--- Comment #2 from Stephan Bergmann ---
(In reply to Martin Sebor from comment #1)
> The tag is redundant in both cases and can be removed without causing an
> ambiguity. Why do you think the warnings are wrong?
In the test2.cc case, S has
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
CC: msebor at gcc dot gnu.org
Target Milestone: ---
With recent GCC trunk (incl. the fix from bug 93801 comment 3, though I do
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
CC: msebor at gcc dot gnu.org
Target Milestone: ---
With recent GCC trunk and
> $ cat incA.h
> struct S {};
> $ cat incB.h
> void f(struct S *);
>
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
CC: msebor at gcc dot gnu.org
Target Milestone: ---
With recent GCC trunk:
> $ cat test.cc
> namespace N { struct S {}; }
> typename N::S s;
>
> $ g++ -fsyntax-on
0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With recent trunk (at g:ddd792fa53345180c782494aa597e438a73b6248):
> $ cat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93238
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
I think this only started recently on GCC trunk, I observe it at least with a
bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92893
--- Comment #4 from Stephan Bergmann ---
(FWIW, the amount of cases where this issue hits the build of LibreOffice seems
to have increased further with more recent GCC trunk builds after I filed the
issue.)
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
Recent GCC 10 trunk produces a -Wstringop-overflow warning that at least
gcc-c++-9.2.1-1.fc31.x86_64 does not produce. Unfortunately the minimal
reproducer I came up with is still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92696
--- Comment #5 from Stephan Bergmann ---
...but something that needs proper documentation?
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
At least with "gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)" and with recent GCC
10 trunk:
> $ cat test.c
> void f(int);
> void g(int b) {
&
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
At least with "gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)",
> $ cat test.cc
> name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92201
--- Comment #3 from Stephan Bergmann ---
(In reply to Jakub Jelinek from comment #2)
> Untested fix.
Building LibreOffice (from which I had distilled the reproducer) works fine for
me again with that patch. Thanks!
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With recent trunk:
> $ gcc/trunk/inst/bin/g++ --version
> g++ (GCC) 10.0.0 20191023 (experimental)
> Copyright (C)
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
CC: msebor at gcc dot gnu.org
Target Milestone: ---
With at least both GCC 9.2.1 and recent trunk towards GCC 10,
#include
struct S { S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71102
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91391
--- Comment #5 from Stephan Bergmann ---
(In reply to Stephan Bergmann from comment #0)
[...]
> template-parameter-list, and I wonder whether it should warn about a
> (hypothetical) comma expression in a call to an overloaded operator [] at
>
: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With recent git master (4ad9380bafd772cea54392c7189cab07a2121fc9 here):
> $ cat test.cc
> #include
> #include
> int main() {
> std::map, int> m;
> m[std::pair(0
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
Recent trunk (I'm at git rev 665de37f60068204ea9b4757dd79bc7f75588733) started
to miscompile
> $ cat test.cc
> struct S1 { virtual void f() = 0; };
> struct S2: S1 { virtu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90575
--- Comment #3 from Stephan Bergmann ---
Or, to put it differently: It looks odd that while `gcc -gsplit-dwarf -c
test.c -o /path/test.o` puts test.dwo next to test.o into /path/, `gcc
-gsplit-dwarf test.c -o /path/test` puts it into cwd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90575
--- Comment #2 from Stephan Bergmann ---
(In reply to Richard Biener from comment #1)
> But that's how -gsplit-dwarf is designed.
Shouldn't it then be documented where any .dwo files are stored? At least in
combination with -o in comment 0,
: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
At least with current GCC 9.1.1:
> $ mkdir testdir
> $ echo 'int main(void) { return 0; }' > testdir/test.c
> $ gcc -gsplit-dwarf testdir/test.c -o testdir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
I encountered this ICE with recent GCC trunk with
#include "boost/spirit/in
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
CC: caolanm at redhat dot com, msebor at gcc dot gnu.org
Target Milestone: ---
With current trunk (towards GCC 9),
> $ cat test.cc
> unsigned char const n = 128;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89009
--- Comment #8 from Stephan Bergmann ---
...and adding to the test.cc from comment 0 an additional
> $ cat main.cc
> void f1();
> struct S1 { static void f2(); };
> struct __attribute__ ((visibility("default"))) S2: S1 { static void f2(); };
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89009
--- Comment #6 from Stephan Bergmann ---
(In reply to Martin Liška from comment #5)
> Well, I believe the test-case is invalid as one can't have hidden visibility
> and then defined S1::f2 in a different translation unit.
Why? Isn't hidden
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
On Linux x86-64 with at least with GCC 8.2.1 (gcc-8.2.1-6.fc29.x86_64) and
recent trunk towards GCC 9, compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
--- Comment #18 from Stephan Bergmann ---
(In reply to Jonathan Wakely from comment #17)
> Yes please.
bug 87378
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
On recent trunk, with bug 87150 fixed (so that the compiler agrees that the
std::move is actually required):
> ~ cat test.cc
> #include
> struct S1 { S1(S1 &&); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
--- Comment #16 from Stephan Bergmann ---
(In reply to Stephan Bergmann from comment #15)
> I see that with the fix from comment 13 included, the slightly changed source
>
> #include
> struct S1 { S1(S1 &&); };
> struct S2: S1 {};
> S1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
--- Comment #15 from Stephan Bergmann ---
I see that with the fix from comment 13 included, the slightly changed source
#include
struct S1 { S1(S1 &&); };
struct S2: S1 {};
S1 f(S2 s) { return std::move(s); }
causes -Wredundant-move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
--- Comment #9 from Stephan Bergmann ---
(In reply to Marek Polacek from comment #8)
> It appears that the sentiment is that this testcase should actually be
> valid
Do you have a reference for that? The reason for this not to be valid,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
--- Comment #3 from Stephan Bergmann ---
(In reply to Jakub Jelinek from comment #2)
> This changed with r251035 aka PR80452 aka C++ Core issue 1579.
> So, is this really invalid?
but CWG1579 didn't change the "if the type of the first
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
struct S1 { S1(S1 &&); };
struct S2: S1 {};
S1 f(S2 s) { return s; }
is accepted by GCC 8.1 but violates [class.copy.elision]/
oduct: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With recent GCC trunk:
> $ cat test
: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With recent trunk (on Linux x86_64), and doesn't seem to be covered by existing
bugs referenced from meta bug 84774:
> $ gcc --version
> gcc (GCC) 9.0.0 20180618 (experimental)
> Copyright
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882
--- Comment #3 from Stephan Bergmann ---
(In reply to Jonathan Wakely from comment #2)
> 10.3.1.2 [namespace.memdef] p3 says "the lookup to determine whether the
> entity has been previously declared shall not consider any scopes outside
> the
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With recent trunk "g++ (GCC) 8.0.1 20180119 (experimental)" towards GCC 8:
> $ cat test.cc
> enum class E {
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
At least with current trunk towards GCC 8.0, but also with GCC 7.2.1:
> ~ cat test.cc
> #include
> #include
> void f1(
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
> $ g++ --version
> g++ (GCC) 8.0.0 20170810 (experimental)
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80354
--- Comment #5 from Stephan Bergmann ---
(In reply to Martin Sebor from comment #3)
> The warning does just what it's designed to do: point out the potential
> unhandled truncation.
But it is unusable in practice if there is no reliable way to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80354
--- Comment #2 from Stephan Bergmann ---
But that makes this warning extremely hard to use. Is it really useful for
-Wall in that case?
I came across this with a real-world use-case in the LibreOffice code base,
where some code deliberately
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With recent trunk
> $ gcc --version
> gcc (GCC) 7.0.1 20170406 (experimental)
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; se
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
At least with a recent GCC 7 trunk build ("gcc (GCC) 7.0.1 20170221
(experimental)"), I noticed that -Wformat-truncation warnings happen to
not be emitted i
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
At least with a recent GCC trunk build ("gcc (GCC) 7.0.1 20170221
(experimental)"), the below program does
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
At least with a recent GCC trunk build:
> $ g++ --version
> g++ (GCC) 7.0.1 20170220 (experimental)
> Copy
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
At least with a recent GCC trunk build:
> $ g++ --version
> g++ (GCC) 7.0.1 20170214 (experimental)
> Copyright (C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20710
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61460
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
At least with both GCC 6.1.1 and recent trunk, compiling
namespace { struct S; }
class C {
friend struct S;
static void f
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
My reading of the C++11-and-beyond Standard is that the name of a function with
extern "C" langu
normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With trunk@233631:
> $ cat test.cc
> struct S2 { virtual ~S2(); };
> struct S1 {
> virtual ~S1();
> S2 * f
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With recent trunk@233620:
> $ cat test.c
> typedef struct S {
> int a;
> void * b;
> int c;
> } S;
> v
normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With GCC built from trunk@233597:
> $ cat test.cc
> struct A { virtual ~A(); };
> struct B: A {};
> bool f(A & a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
--- Comment #24 from Stephan Bergmann ---
(In reply to Manuel López-Ibáñez from comment #23)
> That is weird. If you use "GCC diagnostic warning" instead of "ignored", you
> should be able to see some changes in locations between -O0 and -O1 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
--- Comment #22 from Stephan Bergmann ---
(In reply to Jakub Jelinek from comment #20)
> Does the http://gcc.gnu.org/ml/gcc-patches/2016-01/msg02347.html workaround
> help here in any way?
No, unfortunately not. Doesn't change the behaviour in
1 - 100 of 118 matches
Mail list logo
