https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
--- Comment #3 from Marc Glisse ---
Does profile feedback (so we have an idea on the loop count) make any
difference? It seems clear that for a loop that in practice just copies one
long, having to arrange the arguments, make a function call, tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94093
Bug ID: 94093
Summary: -malign-double changes alignment of double type only
and not long double
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94093
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2020-03-09
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94072
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94093
--- Comment #2 from Andrew Pinski ---
This might be just like PR 47120.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94086
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94094
Bug ID: 94094
Summary: [meta-bug] store-merging and/or bswap
load/store-merging missed optimizations
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94088
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94082
--- Comment #3 from Jonathan Wakely ---
(In reply to Deniz Bahadir from comment #1)
> Reading P0202 (wg21.link/p0202) (which made it into C++20) it sounds as if
> `__builtin_memcpy` should be usable from a `constexpr` context.
Why? std::memcpy i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
--- Comment #4 from Richard Biener ---
With profile feedback we (target or middle-end) can produce specialized
RTL expansion doing small copies inline and larget ones offline. The
idea of GIMPLE level pattern detection is that even for small siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94093
Richard Biener changed:
What|Removed |Added
Known to fail||2.95.2, 3.2.3, 3.4.6, 4.0.0
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94093
Richard Biener changed:
What|Removed |Added
Known to fail|2.95.2 |
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94095
Bug ID: 94095
Summary: Modifier 'a' do not work as described
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92648
Jonathan Wakely changed:
What|Removed |Added
CC||bruno-gcc at defraine dot net
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88086
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94096
Bug ID: 94096
Summary: amdgcn build instructions missing
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94097
Bug ID: 94097
Summary: GCC fails to allocate "rm" input constraint when no
more register is left
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: rejects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94098
Bug ID: 94098
Summary: [10 Regression] ICE: canonical types differ for
identical types 'int(void*, void*)' and 'int(void*,
void*)'
Product: gcc
Version: 10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94082
--- Comment #4 from Deniz Bahadir ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Deniz Bahadir from comment #1)
> > Reading P0202 (wg21.link/p0202) (which made it into C++20) it sounds as if
> > `__builtin_memcpy` should be usab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93781
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94076
--- Comment #3 from Jakub Jelinek ---
Well, 64-bit time_t/off_t/ino_t on an arch where they weren't previously 64-bit
is an ABI change which of course needs to have support added to various parts
of the toolchain, including libsanitizer (for whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94082
--- Comment #5 from Jonathan Wakely ---
(In reply to Deniz Bahadir from comment #4)
> (In reply to Jonathan Wakely from comment #3)
> > (In reply to Deniz Bahadir from comment #1)
> > > Reading P0202 (wg21.link/p0202) (which made it into C++20) i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94088
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94088
--- Comment #2 from Jakub Jelinek ---
Guess *testqi_ext_3 needs to be adjusted to test CCZmode instead of CCNOmode if
the constant we'll be created matches the new testdi_1 conditions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94082
--- Comment #6 from Deniz Bahadir ---
(In reply to Jonathan Wakely from comment #5)
>
> It definitely doesn't mean __builtin_memcpy has to be used. It means "we
> don't want to change std::memcpy, implementations must use some other method
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
Carlos O'Ryan changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #8 from Jonathan Wakely ---
Sorry, I read "Creating and using **a** `std::random_device` object fails when
used from multiple threads" to mean creating one object, and then apparently
didn't read the code properly to dispel my misunde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94088
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94098
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94098
Martin Liška changed:
What|Removed |Added
Known to fail||10.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94099
Bug ID: 94099
Summary: ICE in make_region_for_unexpected_tree_code, at
analyzer/region-model.cc:4874
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94100
Bug ID: 94100
Summary: ICE: tree check: accessed elt 1 of 'tree_vec' with 0
elts in tsubst_pack_expansion, at cp/pt.c:12765
Product: gcc
Version: unknown
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94099
Martin Liška changed:
What|Removed |Added
Summary|ICE in |ICE in
|make_region_for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94094
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94063
--- Comment #2 from Jonathan Wakely ---
The test case for Cygwin (which is expected to fail on other targets) is
#include
#include
using std::filesystem::path;
int main()
{
path p;
p = "/";
p += path("/x");
assert( p.has_root_name(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94045
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93800
--- Comment #4 from Jakub Jelinek ---
commit r10-7087-g314b91220a07bd63f13c58e37f1b5b9430a3702b
Author: Martin Liska
Date: Mon Mar 9 14:13:04 2020 +0100
Restore alignment in rs6000 target.
PR target/93800
* config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94050
--- Comment #5 from Jakub Jelinek ---
commit r10-7089-g8475f2902a2e2ca5f7ace8bc5265bd1a815dda20
Author: Marek Polacek
Date: Thu Mar 5 14:07:25 2020 -0500
c++: Fix ABI issue with alignas on armv7hl [PR94050]
The static_assert in the f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94100
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2020-03-09
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93800
Martin Liška changed:
What|Removed |Added
Summary|[9/10 Regression] GCC adds |[9 Regression] GCC adds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #29 from Vladimir Makarov ---
Sorry for all the troubles with my latest patch and thank you for fair
criticism. I've decided to revert the patch as soon as git starts working.
I'll work to find a better solution after this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94066
--- Comment #6 from Jakub Jelinek ---
The standard seems to say a union member becomes active when the constructor
finishes, not when it starts, so what wording prevents changing the active
member during the construction?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94050
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #30 from Segher Boessenkool ---
I cannot reproduce the problem, btw (I cannot build a 32-bit hosted toolchain).
Martin, you have a working recipe?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #31 from Martin Liška ---
(In reply to Segher Boessenkool from comment #30)
> I cannot reproduce the problem, btw (I cannot build a 32-bit hosted
> toolchain).
> Martin, you have a working recipe?
Go to gcc110 machine and do:
$ CC="g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #27 from Jeffrey A. Law ---
So I just prototyped a bit of code that might help with this BZ.
This seems better suited for match.pd, except that match.pd doesn't seem to
want to handle BIT_FIELD_REF nodes. So I did the prototype in f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #32 from Segher Boessenkool ---
Sigh. No, this is *not* a target bug (or we certainly do not know it is),
please stop marking it that.
It seems to be a bug in shrink-wrapping, but the dump does not show enough
information (only cont
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #33 from Segher Boessenkool ---
(In reply to Martin Liška from comment #31)
> (In reply to Segher Boessenkool from comment #30)
> > I cannot reproduce the problem, btw (I cannot build a 32-bit hosted
> > toolchain).
> > Martin, you ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #34 from Segher Boessenkool ---
(In reply to Vladimir Makarov from comment #29)
> Sorry for all the troubles with my latest patch and thank you for fair
> criticism. I've decided to revert the patch as soon as git starts working.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #35 from Martin Liška ---
(In reply to Segher Boessenkool from comment #33)
> (In reply to Martin Liška from comment #31)
> > (In reply to Segher Boessenkool from comment #30)
> > > I cannot reproduce the problem, btw (I cannot build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93930
--- Comment #3 from Jakub Jelinek ---
The cost changes affect the RTL LIM.-Set in insn 22 is invariant (0), cost 32,
depends on
-Set in insn 27 is invariant (1), cost 32, depends on
-Set in insn 32 is invariant (2), cost 32, depends on
-Set in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94066
--- Comment #7 from Hubert Tong ---
(In reply to Jakub Jelinek from comment #6)
> The standard seems to say a union member becomes active when the constructor
> finishes, not when it starts, so what wording prevents changing the active
> member d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94101
Bug ID: 94101
Summary: Variadic template deduction guide issue - error: 'In
instantiation of'
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94102
Bug ID: 94102
Summary: Variadic template deduction guide issue - error: 'In
instantiation of'
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94102
--- Comment #1 from rosemberg at ymail dot com ---
The work around to solve it was to add the follow deduction guide:
template
Merged (T0, T ...)
-> Merged, std::decay_t...>;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94102
--- Comment #2 from rosemberg at ymail dot com ---
*** Bug 94101 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94101
rosemberg at ymail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94095
--- Comment #1 from Andrew Pinski ---
The problem is just 'a' in the first (Modifier) column is wrong, it should have
been 'A'. I will commit the patch in a few minutes. Operand column is correct
to use 'A'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91638
Carl Love changed:
What|Removed |Added
CC||cel at us dot ibm.com
--- Comment #7 from Ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94095
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91638
Bill Schmidt changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93922
--- Comment #5 from Jakub Jelinek ---
Testcase modified to be usable in the testsuite:
// PR c++/93922
// { dg-do link { target c++11 } }
template
struct A {
A () {}
template
A (A const &) {}
~A () {}
};
int t;
struct B {};
struct C :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
Bug ID: 94103
Summary: Wrong optimization: reading value of a variable
changes its representation for optimizer
Product: gcc
Version: 10.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
--- Comment #1 from Alexander Cherepanov ---
Example with decimal floating-point:
--
#include
#include
int main()
{
_Decimal32 x = 999; // maximum significand
uns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
--- Comment #2 from Andrew Pinski ---
long double has padding bits on x86_64 so that is not shocking there.
_Decimal3 is a different issue all together.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93922
--- Comment #6 from Jakub Jelinek ---
The problem as I understand it is that
#1 0x00abeb95 in mark_used (decl=, complain=3) at ../../gcc/cp/decl2.c:5686
#2 0x00987243 in build_over_call (cand=0x375c910, flags=35,
complain=3) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #36 from Segher Boessenkool ---
> > I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
> > but that builds stage2 as 64-bit?
>
> Hm, that's possible. But the stage2 should not crash right?
It doesn't work, of c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #37 from Segher Boessenkool ---
Oh wait. I am dumb I guess? You did those dumps with a stage1 compiler?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #38 from Segher Boessenkool ---
Then, how did you do that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #39 from Vladimir Makarov ---
I've reverted the patch in trouble:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commitdiff;h=5dc1390b41db5c1765e25fd21dad1a930a015aac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #40 from Martin Liška ---
(In reply to Segher Boessenkool from comment #36)
> > > I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
> > > but that builds stage2 as 64-bit?
> >
> > Hm, that's possible. But the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #41 from Martin Liška ---
Ok, the way how we build our compiler is to use:
./configure --with-cpu=default32
that should also lead to the ICE. I'm checking that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94104
Bug ID: 94104
Summary: Request for diagnostic improvement
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94105
Bug ID: 94105
Summary: ICE in get_region, at analyzer/region-model.h:1744
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94106
Bug ID: 94106
Summary: error on a function redeclaration with attribute
transaction_safe
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94107
Bug ID: 94107
Summary: Infinite loop with malformed requires-expression
inside a static_assert
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94106
Martin Sebor changed:
What|Removed |Added
Summary|error on a function |[8/9/10 Regression] error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94108
Bug ID: 94108
Summary: transaction memory attributes not documented
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
Bug ID: 94109
Summary: Memory leak introduced in 8.3.0->8.3.1
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94110
Bug ID: 94110
Summary: Erroneous code compiling
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94074
--- Comment #2 from Marek Polacek ---
And this should be diagnosed but isn't:
struct X {
int i;
};
template
struct S {
const X x;
constexpr S(int) : x{}
{
const_cast(x).i = 19; // { dg-error "modifying a const object" }
}
};
con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94067
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94111
Bug ID: 94111
Summary: Wrong optimization: decimal floating-point infinity
casted to double -> zero
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #42 from Segher Boessenkool ---
Okay, I see your dumps are 64-bit as well. But mine are very different, huh.
Still, it crashes in pretty much the same way.
The bug 94085 that I reported at 2020-03-07 06:26 appears to be one of
a half dozen that lost their comments due to the server move. I've
been standing by as instructed, but I wonder when or if corrections
will happen. Will these comments be restored, or should I reconstruct
them?
Also, I create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
--- Comment #3 from Alexander Cherepanov ---
*** Bug 92824 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92824
Alexander Cherepanov changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94068
--- Comment #4 from Marek Polacek ---
commit d417b4f5414d9076300ab41974a14424f722688c
Author: Marek Polacek
Date: Fri Feb 28 16:57:04 2020 -0500
c++: Fix convert_like in template [PR91465, PR93870, PR92031, PR94068]
The point of this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94068
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91465
Marek Polacek changed:
What|Removed |Added
Summary|[9/10 Regression] |[9 Regression] unexpected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92031
Marek Polacek changed:
What|Removed |Added
Summary|[9/10 Regression] Incorrect |[9 Regression] Incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93870
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94112
Bug ID: 94112
Summary: Please add a warning for potentially throwing code in
noexcept function
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94098
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94113
Bug ID: 94113
Summary: Apparently incorrect register allocation in inline asm
when using CMOV.
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94113
--- Comment #1 from Paul ---
Created attachment 48002
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48002&action=edit
The original C file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94113
--- Comment #2 from Paul ---
Created attachment 48003
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48003&action=edit
The assembly output.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94114
Bug ID: 94114
Summary: [10 Regression] ICE in gimplify_modify_expr, at
gimplify.c:5936
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-cod
1 - 100 of 104 matches
Mail list logo
