[Bug tree-optimization/93042] New: bit-field optimizations get in the way of interchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93042
Bug ID: 93042
Summary: bit-field optimizations get in the way of interchange
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
#define N 100
#define M
struct S { int a : 3; int b : 17; int c : 12; };
struct S A[N][M];
int __attribute__((noinline))
foo (void)
{
int i, j;
for( i = 0; i < M; i++)
for( j = 0; j < N; j++)
{
int t = 0;
struct S s1 = A[j][i];
if (s1.b)
t++;
A[j][i].a = t;
}
return A[0][0].a + A[N-1][M-1].a;
}
- CUT
If we change the loop slightly, to not to use a temp struct or even add a temp
var to hold s1.b, the loop can be interchanged.
That is:
int __attribute__((noinline))
foo1 (void)
{
int i, j;
for( i = 0; i < M; i++)
for( j = 0; j < N; j++)
{
int t = 0;
if (A[j][i].b)
t++;
A[j][i].a = t;
}
return A[0][0].a + A[N-1][M-1].a;
}
int __attribute__((noinline))
foo2 (void)
{
int i, j;
for( i = 0; i < M; i++)
for( j = 0; j < N; j++)
{
int t = 0;
struct S s1 = A[j][i];
int t1 = s1.b;
if (t1)
t++;
A[j][i].a = t;
}
return A[0][0].a + A[N-1][M-1].a;
}
- CUT
This shows up slightly different when I add lowering of bit-field accesses but
in a different way.
[Bug analyzer/93032] analyzer fails to detect FILE * leak in zlib/contrib/minizip/mztools.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93032
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #1 from David Binderman ---
The resource leak is fixed by this patch:
Index: zlib/contrib/minizip/mztools.c
===
--- zlib/contrib/minizip/mztools.c (revision 279700)
+++ zlib/contrib/minizip/mztools.c (working copy)
@@ -38,7 +38,7 @@
FILE* fpZip = fopen(file, "rb");
FILE* fpOut = fopen(fileOut, "wb");
FILE* fpOutCD = fopen(fileOutTmp, "wb");
- if (fpZip != NULL && fpOut != NULL) {
+ if (fpZip != NULL && fpOut != NULL && fpOutCD != NULL) {
int entries = 0;
uLong totalBytes = 0;
char header[30];
I am not sure if local patches to zlib are normally applied and kept
for future versions. I have given this patch to the zlib maintainers.
[Bug c++/93043] New: fails to compile comparison between pointer and convertible to nullptr_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93043
Bug ID: 93043
Summary: fails to compile comparison between pointer and
convertible to nullptr_t
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugbjorn at fahller dot se
Target Milestone: ---
Created attachment 47541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47541&action=edit
Failing example program
For all versions of gcc, but specifically 9.2.1 and trunk 20191215, the
following program fails to compile:
#include
struct indirect_null {
inline operator std::nullptr_t() const;
};
int* pi = nullptr;
bool b = pi == indirect_null{};
The error message is:
bf :-) confuciusornis /tmp> g++-9 -std=c++17 t.cpp
t.cpp:8:13: error: no match for ‘operator==’ (operand types are ‘int*’ and
‘indirect_null’)
8 | bool b = pi == indirect_null{};
| ~~ ^~ ~~~
| | |
| int* indirect_null
bf :-( confuciusornis /tmp> g++-9 --version
g++-9 (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
A more elaborate test program version can be found on
https://godbolt.org/z/aCerqy
which shows that the test works for user defined types with a matching
operator== as a member function, but not for a fundamental pointer type.
[Bug tree-optimization/93044] New: extra cast is not removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93044
Bug ID: 93044
Summary: extra cast is not removed
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
While looking into some bit-field code generation, I found a case where we
don't remove a cast. A slightly different testcase GCC does.
Take:
void f(signed char *a, unsigned char *c)
{
unsigned short b = *a;
*c = ((unsigned char)b);
}
CUT ---
We are not able to remove the cast there.
But if we change it to:
void f1(signed char *a, unsigned char *c)
{
signed short b = *a;
*c = ((unsigned char)b);
}
CUT
We are able to remove it.
[Bug tree-optimization/93044] extra cast is not removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93044
--- Comment #1 from Andrew Pinski ---
Note this is the original testcase where I saw the issue (even without the
bit-field lowering pass; that I am working on):
#define N 100
#define M
struct S { int a : 3; int b : 17; int c : 12; };
struct S A[N][M];
int __attribute__((noinline))
foo (void)
{
int i = 0, j = 0;
A[j][i].a = A[j][i].a*5;
return 0;
}
[Bug tree-optimization/93044] extra cast is not removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93044 --- Comment #2 from Marc Glisse --- In match.pd && ((inter_unsignedp && inter_prec > inside_prec) == (final_unsignedp && final_prec > inter_prec)) looks suspicious.
[Bug fortran/92976] [8/9/10 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92976 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Target Milestone|--- |10.0
[Bug libstdc++/93034] variant not constexpr in c++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93034 --- Comment #2 from rene.r...@fu-berlin.de --- ok, thanks for the heads up. best regards
[Bug c/52981] Separate -Wpadded into two options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52981 --- Comment #9 from David Stone --- It might further be worth giving the "you can rearrange to save sapce" option two warning levels. The highest level would warn for all cases where rearranging can reduce size, and the lowest level would warn for all cases where rearranging only the private data members can reduce size. This is a potentially important point because rearranging public / protected data members can affect the API of your type by changing how it interacts with structured bindings, and, if it is also an aggregate, aggregate construction. The important new consideration that has the potential for a third warning option is the handling of empty types. It could be useful to have a warning that alerts the user that marking a data member with [[no_unique_address]] would reduce the size of their structure. A potential name for this is -Wempty-data-member-wastes-space or -Wmissing-no-unique-address. Cross posted to the equivalent clang bug report: https://bugs.llvm.org/show_bug.cgi?id=22442#c5
[Bug fortran/92873] ICE in unmodified_parm_or_parm_agg_item, at ipa-fnsummary.c:1166
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92873 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Adding a declaration of sub as elemental seems to avoid the ICE: elemental subroutine sub (x) character(*), intent(in) :: x end subroutine sub whereas a non-elemental version does not help: subroutine sub (x) character(*), intent(in) :: x(:) end subroutine sub
[Bug fortran/91960] ICE: backend decl for module variable 'j' already exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91960 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-22 CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. We fail to detect that j is used in an initialization expression. As a consequence, we end up with junk later on. E.g.: module m implicit none integer :: i, j integer, parameter :: a(3) = [1, 2, 3] integer, parameter :: c= a(j) integer:: d= c end produces: pr91960b.f90:6:30: 6 | integer:: d= c | 1 Error: non-constant initialization expression at (1)
[Bug c/52981] Separate -Wpadded into two options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52981 Eric Gallager changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-22 CC||egallager at gcc dot gnu.org See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=22442 Ever confirmed|0 |1 --- Comment #10 from Eric Gallager --- (In reply to Aaron S. Kurland from comment #1) > I just realized that my original message was referring to the wrong option. > I meant: -Wpadded > > I am therefore requesting two new options: > > -Wpadded-element and -Wpadded-structure > > Sorry for the confusion. Confirmed, I have wanted a split like this as well. (In reply to Manuel López-Ibáñez from comment #4) > > [*] (I like David Stone's proposal of -Wpadded-in-middle and > -Wpadded-at-end, but whoever implements it gets to choose the names) Those are good name suggestions too.
[Bug middle-end/88518] Function call defeats -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88518
--- Comment #5 from Eric Gallager ---
(In reply to Matthew Wilcox from comment #2)
> Thanks! What I actually want to do is annotate g() to the effect that it
> reads the pointed-to variable before it writes it. IOW, I want to write
> something like:
>
> void g(unsigned long __attribute__((read_before_write)) *p);
> void h(void);
>
> void f(void)
> {
> unsigned long i;
>
> h();
> g(&i);
> }
>
> and have gcc emit a warning that i is used uninitialised. I tried adding i
> = i prior to the call of g() through macro trickery, but was surprised that
> it didn't trigger, and simplified down to this test-case.
>
> Any chance I could get that attribute or something like it?
The object access attributes that Martin Sebor added recently might work
somewhat along these lines, but I haven't actually tested yet...
[Bug c/82179] Optionally compile free calls in such a way that the passed pointer is clobbered after the call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82179 --- Comment #6 from Eric Gallager --- (In reply to Eric Gallager from comment #5) > (In reply to Federico Bento from comment #1) > > > > https://sourceware.org/ml/libc-alpha/2017-09/msg00238.html > > https://sourceware.org/ml/libc-alpha/2017-09/msg00423.html > > > > In this, Martin said, "David Malcolm has done some preliminary work > on a GCC maaloc/free optimization and diagnostic pass that might be > well suited to this sort of instrumentation," so cc-ing him. The static analyzer he's developing might also be relevant for things like this
[Bug c/88737] RFE: Track ownership moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88737
--- Comment #8 from Eric Gallager ---
(In reply to Neal H. Walfield from comment #0)
> I would like an attribute to indicate that ownership of an argument is moved
> to the function. That is, any subsequent accesses to the variable should be
> considered invalid, and gcc should emit a warning, if possible.
>
> Consider the following example:
>
> ```
> #include
> #include
>
> int
> main(int argc, char *argv[]) {
> int *a = malloc(sizeof(int));
> *a = 1;
> printf("%d\n", *a);
> free(a);
> printf("%d\n", *a);
>
> return 0;
> }
> ```
>
> Compiling this with -Wall (using gcc 6.3.0-18+deb9u1 from Debian) does not
> emit a warning even though there is a use-after-free bug.
>
> Although freeing a variable is the most obvious example of this pattern,
> this pattern often arises when dealing with pointers.
>
> This RFE is based on my experience using Rust's lifetimes, which prevent
> this type of error in Rust.
I tested this with David Malcolm's static analyzer branch on Godbolt and it
catches it: https://godbolt.org/z/LWzGA5
Output:
: In function 'main':
:7:6: warning: dereference of possibly-NULL 'a' [CWE-690]
[-Wanalyzer-possible-null-dereference]
7 | *a = 1;
| ~~~^~~
'main': events 1-2
|
|6 | int *a = malloc(sizeof(int));
| |^~~
| ||
| |(1) this call could return NULL
|7 | *a = 1;
| | ~~
| | |
| | (2) 'a' could be NULL: unchecked value from (1)
|
:10:3: warning: use after 'free' of 'a' [CWE-416]
[-Wanalyzer-use-after-free]
10 | printf("%d\n", *a);
| ^~
'main': events 1-4
|
|6 | int *a = malloc(sizeof(int));
| |^~~
| ||
| |(1) allocated here
|7 | *a = 1;
| | ~~
| | |
| | (2) assuming 'a' is non-NULL
|8 | printf("%d\n", *a);
| | ~~
| | |
| | (3) freed here
|9 | free(a);
| 10 | printf("%d\n", *a);
| | ~~
| | |
| | (4) use after 'free' of 'a'; freed at (3)
|
:10:3: warning: use after 'free' of 'a' [CWE-416]
[-Wanalyzer-use-after-free]
10 | printf("%d\n", *a);
| ^~
'main': event 1
|
|
Compiler returned: 0
[Bug tree-optimization/90906] diagnose returning pointers to freed memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90906
--- Comment #2 from Eric Gallager ---
(In reply to Martin Sebor from comment #0)
> GCC doesn't diagnose returning a freed pointer as in the function below:
>
> void* f (void *p)
> {
> __builtin_free (p);
> // ...
> return p;
> }
>
> It could, by performing an analysis similar to -Wreturn-local-addr. The
> detection would make it possible to find among other things bugs in C++ code
> due to returning pointers into local containers, such as:
>
> #include
>
> int* f ()
> {
> std::vector v (3, 5);
> return v.data ();
> }
I tested both of these with David Malcolm's static analyzer branch on Godbolt
and it was silent on the first one, but ICEd on the second one:
https://godbolt.org/z/L38Fa_
Output:
during IPA pass: analyzer
:7:3: internal compiler error: Segmentation fault
7 | }
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug testsuite/90806] Warray-bounds-2.c fail on cross-aarch64 on RH6 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806 Eric Gallager changed: What|Removed |Added Blocks||84774 --- Comment #7 from Eric Gallager --- (In reply to Martin Sebor from comment #5) > Are the same messages issued by GCC when the test is compiled by hand? Are > the translation units for the test the same? The test #includes > when __has_include () is true so making sure that behaves the same > way would be my first step. The warning is issued by the -Wrestrict pass so > the -fdump-tree-wrestrict output would be the next thing to look at. That seems odd for the -Wrestrict pass to emit -Warray-bounds warnings; I would generally expect passes named for warnings to only emit warnings that share that name... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774 [Bug 84774] [meta-bug] bogus/missing -Wrestrict
[Bug c/47781] warnings from custom printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 --- Comment #21 from Eric Gallager --- (In reply to Cj Welborn from comment #20) > Has anything changed since 2017 that would let me use > register_printf_specifier and -Wformat warnings at the same time? Not that I know of; people still can't agree on a proper design AFAIK... contributions welcome: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps
[Bug c/47781] warnings from custom printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 --- Comment #22 from Cj Welborn --- Thank you for the reply. It's probably out of my league, but I might take a look when I get time.
[Bug c/93045] New: gc bug with test "start_unit-test-1.c"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93045 Bug ID: 93045 Summary: gc bug with test "start_unit-test-1.c" Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rjiejie at me dot com Target Milestone: --- /lhome/software/jojo/csky-toolchain-build-riscv/build-riscv64-linux-glibc-opt4mabi-lp64_march-rv64gc/gcc-riscv/build-gcc-linux-stage2/gcc/xgcc -B/lhome/software/jojo/csky-toolchain-build-riscv/build-riscv64-linux-glibc-opt4mabi-lp64_march-rv64gc/gcc-riscv/build-gcc-linux-stage2/gcc/ /lhome/software/jojo/csky-toolchain-build-riscv/gcc-riscv/riscv-gcc/gcc/testsuite/gcc.dg/plugin/start_unit-test-1.c -march=rv64gc -mabi=lp64 -mcmodel=medlow -fno-diagnostics-show-caret -fdiagnostics-color=never -fplugin=./start_unit_plugin.so -O -S -o start_unit-test-1.s fake_var not INTEGER_TYPE FAIL: gcc.dg/plugin/start_unit-test-1.c -fplugin=./start_unit_plugin.so (test for excess errors) Excess errors: fake_var not INTEGER_TYPE
[Bug ipa/92794] [10 Regression] ICE in decide_about_value, at ipa-cp.c:5186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92794 Arseny Solokha changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Arseny Solokha --- Fixed on the trunk.
[Bug rtl-optimization/26190] combine misses some distributivity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26190 --- Comment #8 from Eric Gallager --- Does the new combine2 pass proposed for GCC 10 fix any of this?
[Bug rtl-optimization/18395] [meta-bug] combine needs to be templatized like a peepholer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18395 --- Comment #4 from Eric Gallager --- Does the new combine2 pass proposed for GCC 10 address any of these issues?
[Bug middle-end/53917] Wuninitialized warning points to place where variable doesn't occur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53917 Eric Gallager changed: What|Removed |Added Last reconfirmed|2017-09-24 00:00:00 |2019-12-23 --- Comment #7 from Eric Gallager --- (In reply to Eric Gallager from comment #3) > > gcc still gets this one wrong though: > > $ /usr/local/bin/gcc -c -Os -S -Wall -Wextra 53917_a.c > 53917_a.c: In function ‘fn4’: > 53917_a.c:38:8: warning: ‘valid’ may be used uninitialized in this function > [-Wmaybe-uninitialized] > if (fn3 (&p_t1_rw_fsm_data.tag_mem_config)) > ^ > $ > > So confirmed for the second testcase. Reconfirming that, despite improvements to location info in general, it's still bad here.
[Bug tree-optimization/83336] [meta-bug] Issues with displaying inlining chain for middle-end warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83336 Eric Gallager changed: What|Removed |Added Keywords||meta-bug CC||egallager at gcc dot gnu.org Depends on||79872 Summary|Issues with displaying |[meta-bug] Issues with |inlining chain for |displaying inlining chain |middle-end warnings |for middle-end warnings --- Comment #7 from Eric Gallager --- making this a meta-bug and having it depend on bug 79872 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79872 [Bug 79872] document placeholder %K in gcc-internal-format
[Bug tree-optimization/92644] [9 Regression] ICE in wide_int_to_tree_1, at tree.c:1530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92644 --- Comment #9 from Arseny Solokha --- I believe, it can be closed now, as the gcc 8 branch is not affected?
[Bug c++/91770] warn on #includes inside extern C regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91770 --- Comment #2 from Eric Gallager --- I wonder how hard it would be to get the interaction with -Wsystem-headers right here, given how many other issues with -Wsystem-headers there are...
[Bug c++/91777] No warning for iterator going out of scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91777
--- Comment #8 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #7)
> It's also diagnosed by libstdc++ Debug Mode:
>
> /home/jwakely/gcc/10/include/c++/10.0.0/debug/safe_iterator.h:294:
> In function:
> __gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>::reference
> __gnu_debug::_Safe_iterator<_Iterator, _Sequence,
> _Category>::operator*() const [with _Iterator =
> std::__cxx1998::_List_const_iterator; _Sequence =
> std::__debug::list; _Category = std::forward_iterator_tag;
> __gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>::reference
> = const int&]
>
> Error: attempt to dereference a singular iterator.
>
> Objects involved in the operation:
> iterator "this" @ 0x0x7b1db7f0 {
> type = std::__cxx1998::_List_const_iterator (constant iterator);
> state = singular;
> }
> Aborted (core dumped)
>
>
> I don't think it's feasible to warn about this. As far as the compiler
> knows, the iterator is just a value type. It's not practical to expect the
> compiler to track that it contains a pointer to a node that is about to be
> destroyed by a container going out of scope.
Maybe not in the compiler proper; could be material for someone to write a
plugin for...
[Bug c++/93046] New: [10 Regression] ICE in cp_gimplify_init_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93046
Bug ID: 93046
Summary: [10 Regression] ICE in cp_gimplify_init_expr
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-10.0.0-alpha20191222 snapshot (r279712) ICEs when compiling the following
testcase, reduced from clang/testsuite/CodeGenCXX/cxx1z-copy-omission.cpp (and
several others) from the clang 9.0.1 test suite:
struct id {
id (int);
operator bool ();
};
id
o9 ()
{
return id (1) ?: id (2);
}
% g++-10.0.0-alpha20191222 -c fxrshtnj.cpp
fxrshtnj.cpp: In function 'id o9()':
fxrshtnj.cpp:9:25: internal compiler error: Segmentation fault
9 | return id (1) ?: id (2);
| ^
0xf529d0 crash_signal
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/toplev.c:328
0x8939d8 cp_gimplify_init_expr
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/cp/cp-gimplify.c:531
0x8939d8 cp_gimplify_expr(tree_node**, gimple**, gimple**)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/cp/cp-gimplify.c:734
0xccb881 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/gimplify.c:13475
0xccfdf5 gimplify_stmt(tree_node**, gimple**)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/gimplify.c:6814
0xce205d gimplify_cond_expr
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/gimplify.c:4232
0xcccdb6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/gimplify.c:13523
0xccfdf5 gimplify_stmt(tree_node**, gimple**)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/gimplify.c:6814
0xcd7815 gimplify_and_add(tree_node*, gimple**)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/gimplify.c:486
0xcd7815 gimplify_return_expr
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/gimplify.c:1659
0xccd4a9 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/gimplify.c:13827
0xce5243 gimplify_stmt(tree_node**, gimple**)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/gimplify.c:6814
0xce5243 gimplify_cleanup_point_expr
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/gimplify.c:6556
0xccc7c7 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/gimplify.c:13958
0xce47a4 gimplify_stmt(tree_node**, gimple**)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/gimplify.c:6814
0xce47a4 gimplify_body(tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/gimplify.c:14814
0xce4bec gimplify_function_tree(tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/gimplify.c:14958
0xb350f2 cgraph_node::analyze()
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/cgraphunit.c:669
0xb379ee analyze_functions
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/cgraphunit.c:1212
0xb385e8 symbol_table::finalize_compilation_unit()
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/cgraphunit.c:2958
r279576 seems to be a possible culprit.
