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: 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=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();
> c.add(
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=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() {
> +{
>
: 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=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
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.
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=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 (&
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
>
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)
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!
: 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
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) {
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92696
--- Comment #5 from Stephan Bergmann ---
...but something that needs proper documentation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
++
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 a
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.)
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=93238
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
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
++
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
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 *);
>
: 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 not
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 not
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 #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
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 to
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Happens with both Fedora's gcc-4.8.1-1.fc19.x86_64 as well as a local build of
plain :
> $ cat test.cc
> struct R1 { virtual void f1() = 0; };
> struct R2: R1 {};
> struct
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
At least with a trunk revision 201654 (aka LATEST-4.9) build (on Fedora 18
x86_64):
> $ cat test1.cc
> #include
> namespace {}
> $ ~/gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53274
Bug #: 53274
Summary: /*struct*/ S (__cdecl * f)(); fails to compile
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52770
Bug #: 52770
Summary: RFE: Letting compiler know asm block can call function
that can throw
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFI
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=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 visi
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(); };
> s
: 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)
> Copy
: 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
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
> all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71102
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
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
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: ---
With recent trunk "g++ (GCC) 8.0.1 20180119 (experimental)" towards GCC 8:
> $ cat test.cc
> enum class E {
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;
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
: 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
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, cwd
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.
++
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 {
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
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]/
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 parameter
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,
present
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 (w
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
++
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 #18 from Stephan Bergmann ---
(In reply to Jonathan Wakely from comment #17)
> Yes please.
bug 87378
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 in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56067
Bug #: 56067
Summary: Removal of -Wsynth from doc didn't remove example
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
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
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
rmal
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) { re
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;
> voi
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(bool);
&
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
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
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 20170214 (experimental)
> Copy
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
IRMED
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
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 if a
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; see th
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 use
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 s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20710
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
At least on recent trunk (r208675),
> $ cat test.cc
> #define _GLIBCXX_DEBUG
> #include
> int main() {
> s
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
When libstdc++ sits on top of glibc, including stdlib.h does not provide an
abs(long) overload (unlike including cstdlib providing a std::abs(long)
overload).
Similarly for C++11 abs(long long
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
Quoting <https://gcc.gnu.org/ml/gcc/2015-11/msg00017.html> "Re: abi_tag
questions" by Jonathan Wakely:
> On 4 November 2015 at 14:37, Stephan Bergman
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68257
--- Comment #3 from Stephan Bergmann ---
(In reply to Jakub Jelinek from comment #1)
> So, if there is a bug, I'd say just that this is not well documented.
See the attached Fix-abi_tag-doc.patch.
(In reply to Jonathan Wakely from comment #2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52770
--- Comment #2 from Stephan Bergmann ---
Created attachment 36972
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36972&action=edit
proposed documentation patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52770
Stephan Bergmann changed:
What|Removed |Added
Attachment #36972|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68257
--- Comment #4 from Stephan Bergmann ---
Created attachment 36973
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36973&action=edit
proposed documentation patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68257
--- Comment #6 from Stephan Bergmann ---
Created attachment 36974
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36974&action=edit
updated documentation patch
(In reply to Jonathan Wakely from comment #5)
> is used as the ABI tag
yeah, pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68257
--- Comment #8 from Stephan Bergmann ---
So if the documentation patch is acceptable and somebody with commit rights can
push it, we can close this issue as NOTABUG then.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With current trunk sources:
> $ gcc/trunk/inst/bin/g++ -v
> Using built-in specs.
> COLLECT_GCC=gcc/trunk/inst/bin/g++
> COLLECT
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With recent trunk GCC,
> $ cat test.cc
> struct S {
> constexpr S(int & x): n(x) {}
> int & n;
> };
> constexpr S f1(int & x) { retur
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
> $ cat test.cc
> #include
> #include
> struct S {
> template S(char const (&)[N]);
> };
> struct T { S s; };
> void f(std::initi
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61460
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=99446
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
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 comme
: 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
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.
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
: 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=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.
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: ---
Since
<https://github.com/llvm/llvm-p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105291
Stephan Bergmann changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
1 - 100 of 118 matches
Mail list logo
