https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105710
--- Comment #4 from Sergey Fedorov ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Sergey Fedorov from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > >TLS enabled
> > >
> > > TLS support for powerpc darwin was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105078
--- Comment #8 from Andrew Pinski ---
*** Bug 105709 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105709
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105706
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105709
--- Comment #10 from Sam James ---
Thanks Siddhesh. I was suspicious of how contorted the minimised version was
but I went with it given it still crashed.
And I think I get what the issue is with the original code now too. Cheers for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105710
--- Comment #3 from Andrew Pinski ---
(In reply to Sergey Fedorov from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > >TLS enabled
> >
> > TLS support for powerpc darwin was never added.
>
> Iain writes that emulated TLS is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105710
--- Comment #2 from Sergey Fedorov ---
(In reply to Andrew Pinski from comment #1)
> >TLS enabled
>
> TLS support for powerpc darwin was never added.
Iain writes that emulated TLS is supported on all Darwin versions starting from
10.5:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105710
--- Comment #1 from Andrew Pinski ---
>TLS enabled
TLS support for powerpc darwin was never added.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105710
Bug ID: 105710
Summary: libitm/alloc_c.cc:40:1: internal compiler error: in
extract_insn, at recog.c:2770
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105709
--- Comment #9 from Siddhesh Poyarekar ---
>From a quick check of non-reduced-qt.cxx, clang appears to fail to fortify the
readlink function, which may explain why you see the failure with gcc but not
clang. Also the reduced reproducer in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674
Vineet Gupta changed:
What|Removed |Added
CC||kito at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104493
Ye Luo changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #8 from Andrew Pinski ---
Oh one more note, the performance of the initialization code is going to be
very minor. So fixing this won't change the overall performance.
This is again a minor issue and you still might end up with LL/SC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #7 from Keno Fischer ---
I'm probably talking in circles at this point, but let me try just one more
time. I just want to clarify that I understand that this is not technically a
libgcc bug. But it's not really an rr bug either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105709
--- Comment #8 from Sam James ---
Let me try hack something to reduce but test with Clang where possible. It's
hard because the mkspecs stuff which leaks into the preprocessed original
source doesn't build with Clang.
In the meantime, could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105709
--- Comment #7 from Andrew Pinski ---
Even this reduced testcase works:
# include
# include
# include
#include
#include
namespace Qt {
enum Initialization {} Uninitialized;
}
struct QArrayData {
int size;
char *d;
};
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #6 from Andrew Pinski ---
Again the bug is still in RR and RR should figure out a better way of fixing
this. If RR wants to support aarch64, they need to fix their code. I am sorry
but ARMv8-a requires ll/sc and any code which uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #5 from Keno Fischer ---
Yes, rr cannot record ll/sc. I'm happy to go into depth here, but this is not
really an aarch64 issue. rr doesn't work on ppc64le either for this reason. The
introduction of lse has made rr feasible on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105709
--- Comment #6 from Andrew Pinski ---
the reduced testcase fails for me with clang.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105709
--- Comment #5 from Sam James ---
Created attachment 53025
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53025=edit
reduced-qt.cxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105709
--- Comment #4 from Sam James ---
Created attachment 53024
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53024=edit
non-reduced-qt.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105709
--- Comment #3 from Sam James ---
Created attachment 53023
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53023=edit
non-reduced-qt.cxx
(I've attached `non-reduced-qt.cxx` in case it's more illustrative. I didn't do
much to it, just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105709
--- Comment #2 from Sam James ---
```
$ gcc --version
gcc (Gentoo Hardened 12.1.1_p20220521 p5) 12.1.1 20220521
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105709
--- Comment #1 from Sam James ---
Minimised reproducer works with Clang but fails with GCC 12 w/ F_S=3:
qt.cxx:
```
extern "C" void __readlink_chk(char *, char *, long, long);
char readlink___path, readlink___buf;
namespace Qt {
enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #4 from Andrew Pinski ---
rr needs to be able to emulate ll/sc really. If it can't then there is not much
GCC can do because again people can and do use both in their programs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105709
Bug ID: 105709
Summary: FORTIFY_SOURCE=3 (*** buffer overflow detected ***:
terminated) on Qt
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #3 from Keno Fischer ---
> I am going to close it as won't fix as the problem is with the rr emulator
> which needs to emulate ll/sc for correctness.
No currently shipping aarch64 chip provides hardware support that would allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #2 from Andrew Pinski ---
There is no correctness issue here either since the check for atomics always
fall back to ll/sc style atomics if init_have_lse_atomics has not been run.
Once init_have_lse_atomics runs then it will use the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104441
--- Comment #6 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:f1a80c05db8b08e71741bae8170f9e77e94bfc35
commit r13-718-gf1a80c05db8b08e71741bae8170f9e77e94bfc35
Author: H.J. Lu
Date: Mon May 23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
Sam James changed:
What|Removed |Added
CC||toolchain at gentoo dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #16 from Andrew Pinski ---
(In reply to Artem S. Tashkinov from comment #14)
> Created attachment 53022 [details]
> lddebug.tar.xz
Thanks this confirms that it is working like it should be and something is
setting LD_LIBRARY_PATH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #15 from Andrew Pinski ---
Hmm, now this might be a libtool issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
Bug ID: 105708
Summary: libgcc: aarch64: init_lse_atomics can race with
user-defined constructors
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #14 from Artem S. Tashkinov ---
Created attachment 53022
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53022=edit
lddebug.tar.xz
(In reply to Andrew Pinski from comment #13)
> Can you run the following command:
>
> In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
--- Comment #16 from Sam James ---
I think I might have hit the same thing in qt_readlink:
https://bugs.gentoo.org/847145. Martin, did you chase down the Qt issue you
had?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105678
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105699
--- Comment #1 from Roy Jacobson ---
I want to suggest to also consider the case of overloading virtual functions
with non-virtual constrained functions. There's an open CWG issue about this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105707
--- Comment #3 from Adrien Grassein ---
Thanks,
sorry for opening a wrong bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105707
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105707
Andrew Pinski changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105707
Bug ID: 105707
Summary: Bug will including file in a namespace
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105689
--- Comment #2 from Martin Sebor ---
It is because of CSE. The warning sees this IL:
_1 = _3(D)->sub.field1;
access_1 (_1);
access_2 (_1);
and so it warns for the second call because the size of me->sub.field1 passed
to it is smaller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105678
Francisco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105678
--- Comment #6 from Andrew Pinski ---
Try:
g++ -std=gnu++2b cpp_file.cpp -lstdc++_libbacktrace
That is put the library after the source file. Static libraries are always
order depedendent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105678
--- Comment #5 from Francisco ---
I have no idea of what's happening, I have tried
```bash
g++ -std=gnu++2b -lstdc++_libbacktrace cpp_file.cpp
```
and
```bash
g++ -std=gnu++2b -L/usr/lib/libstdc++_libbacktrace.a cpp_file.cpp
```
(also tried
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105666
--- Comment #3 from Vineet Gupta ---
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595428.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105706
Bug ID: 105706
Summary: [13 regression] gcc.target/powerpc/pr78604.c fails
after r13-707-g68e0063397ba82
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105705
Andrew Pinski changed:
What|Removed |Added
Summary|std::equal triggers |[12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105705
Bug ID: 105705
Summary: std::equal triggers incorrect -Wnonnull warning
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91134
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105620
pc at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #13 from Andrew Pinski ---
Can you run the following command:
LD_DEBUG=all LD_DEBUG_OUTPUT=ldout /tmp/OBJDIR/./gcc/xgcc -shared-libgcc
-B/tmp/OBJDIR/./gcc -nostdinc++
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104257
pc at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104257
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by Paul Clarke :
https://gcc.gnu.org/g:41b1ff05e2686a9b47c2b3c95b3961d5f176fa50
commit r10-10756-g41b1ff05e2686a9b47c2b3c95b3961d5f176fa50
Author: Paul A. Clarke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105704
--- Comment #2 from Richard Earnshaw ---
Arm uses mapping symbols, which are special symbols in the object file that are
used by disassemblers to understand the content of code sections. But that's
not the primary reason we use such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104257
--- Comment #4 from CVS Commits ---
The releases/gcc-11 branch has been updated by Paul Clarke :
https://gcc.gnu.org/g:d81a2efb2a704b2d95d40f0fa538c2283de2e98d
commit r11-10027-gd81a2efb2a704b2d95d40f0fa538c2283de2e98d
Author: Paul A. Clarke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105684
--- Comment #3 from sagebar at web dot de ---
>The issue is that 'result->data0.a' is (*result).data0.a, and so to GCC you are
>accessing an object of type 'obj' for which there isn't enough allocated space.
Technically true, and yes: not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105704
--- Comment #1 from Andrew Pinski ---
Note what you are proposing won't work IIRC. The way arm and aarch64 handle it
is via a separate section to record if it is data or code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105704
Bug ID: 105704
Summary: jump tables are not marked with @STT_OBJECT,
disassembly wrong
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105632
--- Comment #2 from Lance Fredrickson ---
Seems similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104799
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #11 from Artem S. Tashkinov ---
Created attachment 53020
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53020=edit
gcc-11.3.0.build.log.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105668
Roger Sayle changed:
What|Removed |Added
Assignee|roger at nextmovesoftware dot com |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105378
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2022-05-23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105686
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105694
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105692
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|internal compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105697
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105703
Bug ID: 105703
Summary: Add fix-it for missing nested-name-specifier on
non-member function using 'this'
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105702
--- Comment #1 from Jonathan Wakely ---
Although it's possible this could be trying to define B::operator= or some
other member function, we should assume from the return type and parameter type
that it's A::operator=, which was declared and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105683
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> The problem is that you have vector{val} where val can be converted
> to type value. The standard says that this should be interpreted as an
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83264
Jonathan Wakely changed:
What|Removed |Added
CC||jeanmichael.celerier@gmail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105683
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105702
Bug ID: 105702
Summary: Add fix-it for missing nested-name-specifier on
out-of-class assignment operator
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105683
Jonathan Wakely changed:
What|Removed |Added
Summary|[12/13 Regression] Infinite |Infinite loop (at runtime)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103871
Alfred Agrell changed:
What|Removed |Added
CC||blubban at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700
--- Comment #10 from Artem S. Tashkinov ---
I'm not a programmer at all (not to mention that I know nothing about CPU
instruction set, assembler, etc.), debugging GCC (!) and Wine (!) libraries is
quite complicated for me, so I have a strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700
--- Comment #9 from Artem S. Tashkinov ---
The crash is in ntdll.dll.so but that's a huge library:
$ ls -la ntdll*so*
-rwxr-xr-x. 1 root root 926240 May 23 09:42 ntdll.dll.so.o2
-rwxr-xr-x. 1 root root 950816 May 23 09:46 ntdll.dll.so.pentiumm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105683
--- Comment #3 from Jonathan Wakely ---
So this looks like another variation of PR 83264.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90742
--- Comment #5 from Tobias Burnus ---
On OpenMP side, firstprivate() (on 'target') should work fine for scalars to my
knowledge, including defaultmap. For arrays, it works since PR104949.
Except: Not working is firstprivate() with deep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104949
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105683
--- Comment #2 from Jonathan Wakely ---
Don't use braced-init here:
case Type::Type8:
new (_impl.m_value8)
std::vector{std::move(other.m_impl.m_value8)};
If you use parens, it works as you expect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105686
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700
--- Comment #8 from Artem S. Tashkinov ---
(In reply to Richard Biener from comment #7)
> It's only a guess but since GCC 12 we enable vectorization by default and
> with wine and 32bit apps the stack might not be always aligned properly. So
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91159
Jonathan Wakely changed:
What|Removed |Added
CC||thelordlucas at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98410
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105701
Bug ID: 105701
Summary: Warn about unused initializer for virtual base
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700
--- Comment #7 from Richard Biener ---
It's only a guess but since GCC 12 we enable vectorization by default and with
wine and 32bit apps the stack might not be always aligned properly. So I'd try
to use -fno-tree-vectorize as additional flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700
--- Comment #6 from Artem S. Tashkinov ---
(In reply to Alexander Monakov from comment #5)
> (In reply to Artem S. Tashkinov from comment #4)
> > > There should be a note in dmesg when a process segfaults outside of a
> > > debugger. If you run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700
--- Comment #5 from Alexander Monakov ---
(In reply to Artem S. Tashkinov from comment #4)
> > There should be a note in dmesg when a process segfaults outside of a
> > debugger. If you run wine without gdb, and winedevice.exe crashes, is there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105629
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104949
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:49d1a2f91325fa8cc011149e27e5093a988b3a49
commit r13-706-g49d1a2f91325fa8cc011149e27e5093a988b3a49
Author: Tobias Burnus
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105678
--- Comment #4 from Jonathan Wakely ---
(In reply to Francisco from comment #0)
> Maybe I am missing something,
Yes, you need to link to the extra lib that gets built by the extra configure
option you gave.
> maybe the documentation is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105678
Jonathan Wakely changed:
What|Removed |Added
Keywords||documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64758
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> I suggest that we should notice that ": bar" is bad, give an error about
> "bar" being undeclared, and then act as though no enum-base was present for
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700
--- Comment #4 from Artem S. Tashkinov ---
(In reply to Alexander Monakov from comment #3)
> It seems you're already getting some good advice on the Wine Bugzilla
> (thanks for linking it in the URL field).
>
> There should be a note in dmesg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64758
--- Comment #4 from Jonathan Wakely ---
For this code:
enum class foo : bar { baz };
auto x = foo::baz;
We give:
e.C:1:6: warning: elaborated-type-specifier for a scoped enum must not use the
‘class’ keyword
1 | enum class foo : bar { baz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64758
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59423
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
1 - 100 of 132 matches
Mail list logo
