https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105684
Richard Biener changed:
What|Removed |Added
Blocks||56456
--- Comment #2 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105685
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105686
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105668
Roger Sayle changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #6 from Richard Biener ---
The libgcc_s.so link shouldn't reference anything from libstdc++ so this is
really odd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105689
Richard Biener changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #9 from Andrew Pinski ---
Also can you provide the full output of "env" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #10 from Artem S. Tashkinov ---
(In reply to Andrew Pinski from comment #8)
> Do you have the full log?
The full build log? I can generate one right away.
(In reply to Andrew Pinski from comment #9)
> Also can you provide the full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105675
--- Comment #5 from Ruslan Mkoyan ---
Created attachment 53018
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53018&action=edit
0.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105697
Bug ID: 105697
Summary: GCC trunk failed to detect a stack buffer-overflow
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105675
--- Comment #6 from Ruslan Mkoyan ---
By the way, there is one more file (attached 0.cpp.gz).
gcc-9 0.cpp is processed but gcc-12 0.cpp - segfault. With extension .c its ok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105698
Bug ID: 105698
Summary: misleading -Wmisleading-indentation and -Wreturn-type
when extra ) is at the end of the statement afterwards
Product: gcc
Version: 12.0
Status: U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105675
--- Comment #7 from Andrew Pinski ---
Again this is just a limitation in the stack size.
Try doing:
ulimit -s unlimited
and you will most likely see they both work.
We could change the parser not to be as recusive function calls here but this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105690
Richard Biener changed:
What|Removed |Added
Component|c |ipa
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105699
Bug ID: 105699
Summary: [Concepts] Constrained virtual functions are accepted
by GCC
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105695
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700
Bug ID: 105700
Summary: GCC miscompiles? wine when using -march=pentium-m
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700
--- Comment #1 from Artem S. Tashkinov ---
If I enable core dump gdb rejects the resulting core file as invalid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700
--- Comment #2 from Artem S. Tashkinov ---
This bug doesn't require any extensive debugging.
You just
1. wget https://dl.winehq.org/wine/source/7.x/wine-7.9.tar.xz
2. tar xf wine-7.9.tar.xz
3. cd wine-7.9
4. build using the instructions above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459
--- Comment #9 from Kewen Lin ---
inline_call will force reload global optimization.
/* Reload global optimization flags. */
if (reload_optimization_node && DECL_STRUCT_FUNCTION (to->decl) == cfun)
set_cfun (cfun, true);
It looks that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105695
--- Comment #3 from Jonathan Wakely ---
(In reply to Richard Biener from comment #2)
> is required pre C++11 for std::swap.
Right, it got moved to for C++11. GCC 10 uses C++98 so needs
for std::swap.
As noted at https://gcc.gnu.org/gcc-12/p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59423
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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=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=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 w
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 r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105678
Jonathan Wakely changed:
What|Removed |Added
Keywords||documentation
Status|UNCO
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 missin
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: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105629
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
S
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=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 #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=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=98410
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91159
Jonathan Wakely changed:
What|Removed |Added
CC||thelordlucas at gmail dot com
--- Comm
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=105686
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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 (&m_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=104949
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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 firstpriva
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=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=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 des
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103871
Alfred Agrell changed:
What|Removed |Added
CC||blubban at gmail dot com
--- Comment #1
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=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
Keywo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105683
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIR
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
--- 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
> initializer-li
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 has
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
Keywo
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=105692
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|internal compiler e
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=105686
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105378
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2022-05-23
Status|UNCONFIRM
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=105688
--- Comment #11 from Artem S. Tashkinov ---
Created attachment 53020
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53020&action=edit
gcc-11.3.0.build.log.xz
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
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
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=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=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 derefe
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=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 annotations
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=104257
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
-L/tmp/OBJD
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=91134
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
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
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105705
Andrew Pinski changed:
What|Removed |Added
Summary|std::equal triggers |[12/13 Regression]
|i
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
Severit
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=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=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
Francisco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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 = &me_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=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=105707
Andrew Pinski changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #1 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105707
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
St
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=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://www.open-std.org/jtc1/sc22/wg21/docs/cwg_activ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105678
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Assignee|unassigne
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=105688
--- Comment #14 from Artem S. Tashkinov ---
Created attachment 53022
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53022&action=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=105708
Bug ID: 105708
Summary: libgcc: aarch64: init_lse_atomics can race with
user-defined constructors
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: norm
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=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 wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
Sam James changed:
What|Removed |Added
CC||toolchain at gentoo dot org
--- Comment #17
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 10:
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=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 A
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
suc
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: normal
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.
1 - 100 of 137 matches
Mail list logo
