https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91893
Bug ID: 91893
Summary: Bit-field larger than 32 bits has invalid type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91892
Bug ID: 91892
Summary: [5.x,6.x ARM] Having a global pair
causes code gen bug for init list of pair
Product: gcc
Version: 6.4.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91891
Bug ID: 91891
Summary: std::function with lambda default initializer in
aggregate construction causes ICE
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23409
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91876
--- Comment #2 from Young ---
(In reply to Jonathan Wakely from comment #1)
> The gdb backtrace shows your program is linked to the wrong libstdc++.so
> that comes from the gcc-4.4.7 system compiler, not the one from gcc-7.2.1
> that you compiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #11 from joseph at codesourcery dot com ---
Those -isystem paths are the *non-sysroot* kind of paths for headers for a
cross compiler.
There is no support for building a *non-sysroot* cross toolchain when its
libc is installed in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91890
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #10 from Stas Sergeev ---
(In reply to Jonathan Wakely from comment #9)
> It's possible the paths passed to -isystem should be prefixed with = when a
> sysroot is in use,
Great idea! Maybe it can even be unconditional,
as w/o --sysro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91890
Bug ID: 91890
Summary: [10 Regression] -Warray-bounds warning testing glibc
not suppressed by pragma
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91889
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91889
Bug ID: 91889
Summary: Boost does not build with top-of-tree GCC
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91887
Marek Polacek changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #3 from Marek Polacek ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #9 from Jonathan Wakely ---
It's possible the paths passed to -isystem should be prefixed with = when a
sysroot is in use, but prefixing them with $DESTDIR is definitely wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91880
--- Comment #1 from jcmvbkbc at gcc dot gnu.org ---
Minimal reproducer:
void f(unsigned int n, char *a, char *b)
{
int i;
for (i = 0; i <= n - 1; ++i)
a[i] = b[i];
}
The issue is that entry_bb is empty in the hwlo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #8 from Stas Sergeev ---
(In reply to Andrew Pinski from comment #7)
> Have you looked into --with-build-sysroot ?
Thanks! Very helpful.
But now it has the same problem when configuring libstdc++:
---
configure:4574:
/home/stas/src/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91888
Bug ID: 91888
Summary: GCC will write absolute paths into DW_AT_GNU_dwo_name
even with -fdebug-prefix-map
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91888
--- Comment #1 from Christian Biesinger ---
(sorry, copied the wrong revision. it's actually
ed342df533bf18eee2d5f84f1251a13f43d78505 from sep 21)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90309
Alexandre Duret-Lutz changed:
What|Removed |Added
CC||adl at gnu dot org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #7 from Andrew Pinski ---
(In reply to Stas Sergeev from comment #4)
> (In reply to Harald van Dijk from comment #1)
> > The ways to handle libc being installed in non-standard locations depend on
> > your specific use case. GCC provi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91887
Marek Polacek changed:
What|Removed |Added
Keywords|needs-bisection |
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91570
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91570
--- Comment #4 from Martin Sebor ---
Author: msebor
Date: Tue Sep 24 19:04:54 2019
New Revision: 276105
URL: https://gcc.gnu.org/viewcvs?rev=276105&root=gcc&view=rev
Log:
PR tree-optimization/91570 - ICE in get_range_strlen_dynamic on a conditio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91887
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91887
Bug ID: 91887
Summary: -fdebug-types-section ICE building chromium
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78752
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607
--- Comment #11 from Marek Polacek ---
Perhaps we should just remove the assert:
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1085,7 +1085,6 @@ constexpr_call_hasher::equal (constexpr_call *lhs,
constexpr_call *rhs)
{
tree l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607
--- Comment #10 from Marek Polacek ---
r266816 is already present gcc-9-branch but it didn't fix the ICE. I'm afraid
it's r272125, but alas that doesn't seem to be backportable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #6 from Stas Sergeev ---
(In reply to Jonathan Wakely from comment #5)
> Which makes sense, since the system headers are not part of GCC itself, so
> why would it expect them in the temporary staging area for GCC's own files?
OK, I u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91865
--- Comment #3 from Jozef Lawrynowicz ---
Created attachment 46936
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46936&action=edit
msp430-extendhipsi2.diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607
--- Comment #8 from Hannes Hauswedell ---
Anything I can do to help resolve this? We have library code that breaks
because of the issue and since 9.2 is deployed everywhere that 9.1 was used,
this is very disruptive...
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91865
--- Comment #2 from Jozef Lawrynowicz ---
A related issue can be observed if "char i" is made global instead of an
argument to func.
const int table[2] = {1, 2};
int foo;
char i;
void func(void)
{
foo = table[i];
}
Combine combines the zero
x) : "ws"(x), "ws"(y));
return x;
}
compiled to
fmax:
xsmaxdp 1, 1, 2
blr
now (gcc version 10.0.0 20190924) i get
fmax.c: In function 'fmax':
fmax.c:3:2: error: impossible constraint in 'asm'
3 | __asm__ ("xsmaxdp %x0, %x1, %x2" : "=ws"(x) : "ws"(x), "ws"(y));
| ^~~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87441
Jeff Chapman changed:
What|Removed |Added
CC||jeff.chapman.bugs at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86269
Jeff Chapman changed:
What|Removed |Added
CC||jeff.chapman.bugs at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86000
Jeff Chapman changed:
What|Removed |Added
CC||jeff.chapman.bugs at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85808
Jeff Chapman changed:
What|Removed |Added
CC||jeff.chapman.bugs at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85241
Jeff Chapman changed:
What|Removed |Added
CC||jeff.chapman.bugs at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #4 from Stas Sergeev ---
(In reply to Harald van Dijk from comment #1)
> The ways to handle libc being installed in non-standard locations depend on
> your specific use case. GCC provides the --with-sysroot and
> --with-native-system-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84140
Jeff Chapman changed:
What|Removed |Added
CC||jeff.chapman.bugs at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82794
Jeff Chapman changed:
What|Removed |Added
CC||jeff.chapman.bugs at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82740
Jeff Chapman changed:
What|Removed |Added
CC||jeff.chapman.bugs at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91885
Bug ID: 91885
Summary: ICE when compiling SPEC 2017 blender benchmark with
-O3 -fprofile-generate
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91871
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
See A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91871
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
See A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82507
Jeff Chapman changed:
What|Removed |Added
CC||jeff.chapman.bugs at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91884
Thomas Schwinge changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91884
Bug ID: 91884
Summary: libgomp testsuite: (not) using a specific driver for
C++, Fortran
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: openacc, op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80773
Jeff Chapman changed:
What|Removed |Added
CC||jeff.chapman.bugs at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91845
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91868
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80746
Jeff Chapman changed:
What|Removed |Added
CC||jeff.chapman.bugs at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91868
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Tue Sep 24 14:40:24 2019
New Revision: 276103
URL: https://gcc.gnu.org/viewcvs?rev=276103&root=gcc&view=rev
Log:
PR c++/91868 - improve -Wshadow location.
* name-lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91845
--- Comment #4 from Marek Polacek ---
Author: mpolacek
Date: Tue Sep 24 14:38:53 2019
New Revision: 276102
URL: https://gcc.gnu.org/viewcvs?rev=276102&root=gcc&view=rev
Log:
PR c++/91845 - ICE with invalid pointer-to-member.
* ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91882
--- Comment #1 from SztfG at yandex dot ru ---
Similar problem with other tautology:
unsigned int impl_bit(unsigned int a, unsigned int b) // bitwise implication
{
return (~a | b);
}
unsigned int eq_bit(unsigned int a, unsigned int b) // bitwi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91883
Bug ID: 91883
Summary: Division by a constant could be optimized for known
variables value range
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91882
Bug ID: 91882
Summary: boolean XOR tautology missed optimisation
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #18 from Martin Liška ---
I would like to see this also fixed. But I know Honza has some comments about
the patch. Honza?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91881
Bug ID: 91881
Summary: Value range knowledge of higher bits not used in
optimizations
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91816
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91877
--- Comment #2 from Marek Polacek ---
Reduced:
template class b {
public:
b(const a &);
};
struct {
int *c;
} d;
void e() { b(d.c); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79759
Jeff Chapman changed:
What|Removed |Added
CC||jeff.chapman.bugs at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91877
--- Comment #1 from Marek Polacek ---
Candidate fix:
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7382,8 +7382,7 @@ convert_like_real (conversion *convs, tree expr, tree fn,
int argnum,
tree type = TREE_TYPE (ref_type);
cp_lvalue_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91874
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Resolut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90825
Jakub Jelinek changed:
What|Removed |Added
CC||qux at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91866
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91866
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Tue Sep 24 12:45:13 2019
New Revision: 276096
URL: https://gcc.gnu.org/viewcvs?rev=276096&root=gcc&view=rev
Log:
PR middle-end/91866
* match.pd (((T)(A)) + CST -> (T)(A +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78752
Jeff Chapman changed:
What|Removed |Added
CC||jeff.chapman.bugs at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #3 from Stas Sergeev ---
(In reply to Harald van Dijk from comment #1)
> archive from the DESTDIR directory and extracting it elsewhere. It is not
> supposed to be used at configure time to pick up other software, only at
> install ti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69235
Jeff Chapman changed:
What|Removed |Added
CC||jeff.chapman.bugs at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91877
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #2 from Jonathan Wakely ---
(In reply to Stas Sergeev from comment #0)
> Hello.
>
> I tried to build gcc with non-empty DESTDIR.
What exact commands did you run?
I don't see why DESTDIR should matter until the 'make install' step.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91880
Bug ID: 91880
Summary: ICE: segfault in hwloop_optimize
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91872
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91831
Martin Jambor changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91831
--- Comment #3 from Martin Jambor ---
Author: jamborm
Date: Tue Sep 24 11:20:57 2019
New Revision: 276094
URL: https://gcc.gnu.org/viewcvs?rev=276094&root=gcc&view=rev
Log:
[PR 91831] Copy PARM_DECLs of artificial thunks
Hi,
I am quite surpris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68858
Jeff Chapman changed:
What|Removed |Added
CC||jeff.chapman.bugs at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91832
--- Comment #4 from Martin Jambor ---
Author: jamborm
Date: Tue Sep 24 11:16:57 2019
New Revision: 276093
URL: https://gcc.gnu.org/viewcvs?rev=276093&root=gcc&view=rev
Log:
[PR 91832] Do not ICE on negative offsets in ipa-sra
Hi,
IPA-SRA asser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
Bug ID: 91879
Summary: DESTDIR support seems incomplete
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91871
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91871
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Tue Sep 24 10:09:18 2019
New Revision: 276091
URL: https://gcc.gnu.org/viewcvs?rev=276091&root=gcc&view=rev
Log:
PR libstdc++/91871 fix Clang warnings in testsuite
PR libstdc++/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
Jonathan Wakely changed:
What|Removed |Added
Resolution|INVALID |WONTFIX
--- Comment #9 from Jonathan W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
--- Comment #8 from Jonathan Wakely ---
(In reply to Konstantin Kharlamov from comment #6)
> (In reply to Jonathan Wakely from comment #5)
>
> > No, that's not how undefined behaviour works. You are wrong to expect a
> > crash
>
> No, in conte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
--- Comment #7 from Konstantin Kharlamov ---
@Jonathan Wakely I think you accidentally closed the report, would you mind to
reopen it (I'm not seeing why would it be "invalid", people even confirmed that
more support for std containers is being a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
--- Comment #6 from Konstantin Kharlamov ---
(In reply to Jonathan Wakely from comment #5)
> No, that's not how undefined behaviour works. You are wrong to expect a crash
No, in context of the report I'm not. You're correct this is not how UB w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91860
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
--- Comment #4 from Konstantin Kharlamov ---
(In reply to Marc Glisse from comment #3)
> -D_GLIBCXX_DEBUG is the current way to add many checks to libstdc++, and it
> detects this.
Oh, cool, I'll make use of it, thanks for the hint!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
--- Comment #3 from Marc Glisse ---
-D_GLIBCXX_DEBUG is the current way to add many checks to libstdc++, and it
detects this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
--- Comment #1 from Konstantin Kharlamov ---
Btw, worth noting that clang 8.0.1 does not handle it either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
Bug ID: 91878
Summary: No sanitizer report for past-end access of std∷set
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91866
--- Comment #4 from Richard Biener ---
(In reply to Jakub Jelinek from comment #3)
> I meant something like:
> --- gcc/match.pd.jj 2019-09-21 23:53:52.108385196 +0200
> +++ gcc/match.pd 2019-09-24 10:18:58.804114496 +0200
> @@ -2265,8 +226
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91866
--- Comment #3 from Jakub Jelinek ---
I meant something like:
--- gcc/match.pd.jj 2019-09-21 23:53:52.108385196 +0200
+++ gcc/match.pd2019-09-24 10:18:58.804114496 +0200
@@ -2265,8 +2265,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91874
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91872
--- Comment #5 from Richard Biener ---
And indeed the RTL expansion ICE points to the very same issue via
context = decl_function_context (exp);
gcc_assert (!exp
...
|| context == current_function_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91872
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC|
1 - 100 of 118 matches
Mail list logo
