https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100525
--- Comment #4 from Richard Biener ---
Btw, the issue for the original testcase is that we run into
static void
c_parser_gimple_statement (gimple_parser &parser, gimple_seq *seq)
{
...
/* GIMPLE call statement without LHS. */
if (c_parser_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103498
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106364
Andrew Pinski changed:
What|Removed |Added
Keywords||compile-time-hog,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106364
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106492
--- Comment #4 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:8a16b9f983824b6b9a25275cd23b6bba8c98b800
commit r13-1997-g8a16b9f983824b6b9a25275cd23b6bba8c98b800
Author: Tobias Burnus
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #20 from Jeffrey Walton ---
Hi Andrew.
I went through the list of options that are enabled at -O2 from [1]. I built
the library with each option separately at "-DNDEBUG -g2 -O2 -fno-xxx".
Here is the list of suspects. I seem to rec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #19 from Jeffrey Walton ---
Created attachment 53427
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53427&action=edit
Test script to build library at -O2 with -fno-xxx
Test script to build library at -O2 with -fno-xxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65520
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106377
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65520
Andrew Pinski changed:
What|Removed |Added
CC||xmh970252187 at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106377
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #18 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #17)
> The other thing to try is -fstack-reuse=none.
No joy with -fstack-reuse=none. The crash is still present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106377
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-08-09
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #17 from Andrew Pinski ---
The other thing to try is -fstack-reuse=none.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #16 from Andrew Pinski ---
(In reply to Jeffrey Walton from comment #15)
> It looks like -fno-strict-aliasing cleared the crash. This is bad because I
> thought we did not violate aliasing rules.
>
> Let me try to find it.
Well sin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #15 from Jeffrey Walton ---
It looks like -fno-strict-aliasing cleared the crash. This is bad because I
thought we did not violate aliasing rules.
Let me try to find it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #14 from Jeffrey Walton ---
(In reply to Jeffrey Walton from comment #13)
> (In reply to Andrew Pinski from comment #12)
> > Can you try -fno-reorder-blocks-and-partition adding to the options?
> > This would not be the first time th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #13 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #12)
> Can you try -fno-reorder-blocks-and-partition adding to the options?
> This would not be the first time this option caused issues with EH.
No joy with -fno-r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
--- Comment #1 from Andrew Pinski ---
With -fno-toplevel-reorder, it can be detected.
I can't figure out why there is a difference really.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #12 from Andrew Pinski ---
Can you try -fno-reorder-blocks-and-partition adding to the options?
This would not be the first time this option caused issues with EH.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #11 from Andrew Pinski ---
(In reply to Jeffrey Walton from comment #9)
> (In reply to Andrew Pinski from comment #8)
> > (In reply to Jeffrey Walton from comment #7)
> >
> > Try putting a breakpoint on the following functions:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #10 from Jeffrey Walton ---
I'm not sure if this is helpful, but Valgrind is showing invalid reads in the
unwind gear:
$ valgrind ./cryptest.exe vv 51
==27339== Memcheck, a memory error detector
==27339== Copyright (C) 2002-2022, an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #9 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Jeffrey Walton from comment #7)
>
> Try putting a breakpoint on the following functions:
> _Unwind_RaiseException
> _Unwind_ForcedUnwind
> _Unwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #8 from Andrew Pinski ---
(In reply to Jeffrey Walton from comment #7)
>
> Thanks again Andrew.
>
> We have exception handlers for both CryptoPP::Exception& and std::exception&
> starting for main() around
> https://github.com/weid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #7 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #6)
> >And the program does not take the exception path. Instead it segfaults.
>
> If I read the backtrace correctly, it is trying to resume an unwind because
> it d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106380
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #6 from Andrew Pinski ---
>And the program does not take the exception path. Instead it segfaults.
If I read the backtrace correctly, it is trying to resume an unwind because it
didn't find a catch that would hit in main but the fol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #5 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #3)
> Though there might be an EH issue but there has not been an EH issue for a
> long time .
This is an interesting observation.
The stack trace shows frame #0 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #4 from Andrew Pinski ---
If there is a throw which is not being caught (correctly).
In gdb you can do:
catch throw
And then find where the throw was that is causing the issue (as this is an
_Unwind_Resume case).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |rtl-optimization
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #2 from Andrew Pinski ---
Note I really doubt reorder-blocks would cause any issues unless there is some
other undefined code in there. An example might be even aliasing violations
(where the is no undefined sanitizer yet).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
Bug ID: 106568
Summary: -freorder-blocks-algorithm appears to causes a crash
in stable code, no way to disable it
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P1
Summary|[13 regression] A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567
Marek Polacek changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567
Andrew Pinski changed:
What|Removed |Added
Keywords||rejects-valid
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567
--- Comment #1 from Ville Voutilainen ---
Repro without std::vector:
template
void urgh()
{
const V x[] = {V(0), V(1), V(2), V(0)};
[&]() {
for (auto& v : x) {}
}();
}
void no_urgh()
{
using V = int;
const V x[]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106556
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106556
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106556
--- Comment #3 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:ef623bb58594958a7959f8f031f65a50eb0e5890
commit r13-1995-gef623bb58594958a7959f8f031f65a50eb0e5890
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106379
--- Comment #4 from Andrew Macleod ---
Ranger actually appears to handle both cases the same. VRP1 gets it whilst
ranger does not. I believe this to be because we are match and simplifying
_1 = ~c_5(D);
_2 = _1 & s_4(D);
with c_5 == s_4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567
Bug ID: 106567
Summary: An array with a dependent type and initializer-deduced
bound is treated as an array of unknown bound when
captured in a lambda
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106566
Bug ID: 106566
Summary: [OpenMP]
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: openmp, rejects-valid
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106565
Bug ID: 106565
Summary: Using a transposed matrix in matmul (GCC-10.3.0) is
very slow
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106564
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106426
--- Comment #2 from CVS Commits ---
The master branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:053876cdbe8057210e6f4da4eec2df58f92ccd4c
commit r13-1994-g053876cdbe8057210e6f4da4eec2df58f92ccd4c
Author: Tom Honermann
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106564
Dimitar Dimitrov changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106564
Bug ID: 106564
Summary: PRU: Inefficient zero-extend from 32-bit to 64-bit
unsigned values
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106563
Iain Buclaw changed:
What|Removed |Added
Known to fail||12.1.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106563
Bug ID: 106563
Summary: [12/13 Regression] d: undefined reference to
pragma(inline) symbol
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106562
Dimitar Dimitrov changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106562
Bug ID: 106562
Summary: PRU: Inefficient code for zero check of 64-bit AND
result
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106552
--- Comment #3 from Jason Liam ---
Yes, msvc also accepts this but msvc also emits a diagnostic with the
flag *std:c++20
/W4 .*
On Mon, 8 Aug 2022, 22:03 pinskia at gcc dot gnu.org, <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106444
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106561
Bug ID: 106561
Summary: gfortran.dg/ieee/signaling_1.f90 fails with
--with-long-double-format=ieee
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106538
--- Comment #2 from dv at vollmann dot ch ---
Thanks for the detailed explanation (and the workarounds!).
I still think it's very surprising behaviour, but I'll probably leave it to
others to bring this to WG21.
Thanks again,
Detlef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106555
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106555
--- Comment #2 from CVS Commits ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:fc7166a7c409bf231d5f243636f30904deea6e6f
commit r12-8671-gfc7166a7c409bf231d5f243636f30904deea6e6f
Author: Iain Buclaw
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106555
--- Comment #1 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:4b0253b019943abf2cc5f4db0b7ed67caedffe4a
commit r13-1992-g4b0253b019943abf2cc5f4db0b7ed67caedffe4a
Author: Iain Buclaw
Date: Mon A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106556
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106556
--- Comment #1 from Andrew Pinski ---
Related to:
_22 = _20 < limit.3_38;
_7 = _22 != 0;
pos.1_30 = _7 ? S.4_37 : pos.1_39;
limit.3_31 = _7 ? _20 : limit.3_38;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106453
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106552
--- Comment #2 from Andrew Pinski ---
expr.prim.lambda.capture/6 seems to imply this is invalid code.
But the example is only with the parameter rather than a local variable ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106553
--- Comment #2 from Tamar Christina ---
(In reply to Alexander Monakov from comment #1)
> Are you sure the testcase is correctly reduced, i.e. does it show the same
> performance degradation? Latency-wise the scheduler is making the correct
> de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106552
--- Comment #1 from Andrew Pinski ---
clang is the only compiler I tried which rejects this ...
ICC, MSVC all accept this code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106556
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106560
--- Comment #5 from Andrew Pinski ---
(In reply to Karine EM from comment #4)
> Thanks! If it helps with the fix, here are two more examples of this crash:
The fix I have fixes both of these too.
I will add all three to the testsuite when I sub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106560
Karine EM changed:
What|Removed |Added
CC||k.even-mendoza at imperial dot
ac.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106560
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106560
--- Comment #2 from Andrew Pinski ---
The full backtrace:
t.c:4:1: warning: data definition has no type or storage class
4 | a;
| ^
t.c:4:1: warning: type defaults to ‘int’ in declaration of ‘a’ [-Wimplicit-int]
t.c:4:1: error: conflic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100525
--- Comment #3 from Andrew Pinski ---
(In reply to Karine EM from comment #2)
> I also got this error with a bit different trace/pass in GCC-13:
I think that is a different issue so I filed PR 106560 for that one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106560
--- Comment #1 from Andrew Pinski ---
:4:1: warning: data definition has no type or storage class
4 | a;
| ^
:4:1: warning: type defaults to 'int' in declaration of 'a'
[-Wimplicit-int]
:4:1: error: conflicting types for 'a'; have 'int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106560
Bug ID: 106560
Summary: ICE after conflicting types of redeclaration
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103645
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103645
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:21c7aab09805d0c8c7695c8a69c8715d673a739a
commit r13-1990-g21c7aab09805d0c8c7695c8a69c8715d673a739a
Author: Andrew Pinski
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
--- Comment #7 from qinzhao at gcc dot gnu.org ---
another testing case failed with the current "array_at_struct_end_p":
gcc/testsuite/gcc.target/aarch64/vadd_reduc-2.c
1 /* { dg-do compile } */
2 /* { dg-additional-options "-O3 -std=c99" } *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106559
Bug ID: 106559
Summary: Spurious warning format-truncation (regression from 9)
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599
Patrick Palka changed:
What|Removed |Added
CC||dv at vollmann dot ch
--- Comment #10 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106538
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106553
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106551
David Malcolm changed:
What|Removed |Added
CC||mir at gcc dot gnu.org
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106426
--- Comment #1 from Tom Honermann ---
A patch for this issue was submitted to the gcc-patches mailing list with the
patch series available at
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599240.html.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102218
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:5471f55f001af412e1125b04972ebaab9d4f7337
commit r13-1989-g5471f55f001af412e1125b04972ebaab9d4f7337
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102218
--- Comment #1 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:e6a8ae900b4141bbce1451da8f173d441662782d
commit r13-1988-ge6a8ae900b4141bbce1451da8f173d441662782d
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100525
Karine EM changed:
What|Removed |Added
CC||k.even-mendoza at imperial dot
ac.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674
--- Comment #8 from Richard Biener ---
Bumping MAX_CHAIN_LEN to 7 removes warnings of it being exceeded during
analysis but the diagnostic still happens.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
Bug ID: 106558
Summary: ASan failed to detect a global-buffer-overflow
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106557
Bug ID: 106557
Summary: nesting intrinsics ibset and transfer gives wrong
result
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106556
Bug ID: 106556
Summary: [13 Regression] ICE in as_a, at value-range.h:399
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106555
Bug ID: 106555
Summary: [12/13 Regression] d: internal compiler error: in
add_stack_var, at cfgexpand.cc:476
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105942
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106554
Bug ID: 106554
Summary: -fstack-usage result too low for variadic function on
Arm
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106553
Bug ID: 106553
Summary: pre-register allocation scheduler is now RMW aware
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #18 from Mathieu Malaterre ---
Brushed-up example (with Makefile):
% more Makefile bytes.cc demo.cc
::
Makefile
::
CXXFLAGS := -O2
demo: demo.o bytes.o
$(CXX) $(CXXFLAGS) -o $@ $^ -lhwy
clean:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106540
Richard Biener changed:
What|Removed |Added
Summary|[13 Regression] lto -g ICE |[10/11/12 Regression] lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106540
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:2a1448f2763a72c83e2ec496f78243a975b0d44e
commit r13-1987-g2a1448f2763a72c83e2ec496f78243a975b0d44e
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106334
--- Comment #9 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:2a1448f2763a72c83e2ec496f78243a975b0d44e
commit r13-1987-g2a1448f2763a72c83e2ec496f78243a975b0d44e
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106540
--- Comment #3 from Richard Biener ---
It's a regression introduced with r11-525-g03d90a20a1afcb, but also backported
as r10-8619-g1144d3cf1ff3d4. It might result in strange debug info references
as well so if it works out it's possibly worth b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106552
Bug ID: 106552
Summary: GCC accepts invalid redefinition of captured variable
inside lambda
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
1 - 100 of 103 matches
Mail list logo
