[Bug tree-optimization/110062] missed vectorization in graphicsmagick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110062 --- Comment #7 from Hongtao.liu --- > pixel$red_60(D)(10)>, type of def: internal > t.c:18:27: missed: no optab. > t.c:18:27: missed: not vectorized: relevant stmt not supported: _29 = > (unsigned char) pixel$red_78; > t.c:18:27: note: Building vector operands of 0x4215e90 from scalars instead > > that's float -> unsigned char > A patch is posted to support vectorization between float and unsigned char https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620402.html
[Bug target/110235] [14 Regression] Wrong use of us_truncate in SSE and AVX RTL representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110235 --- Comment #8 from Hongtao.liu --- Fixed for GCC 14, the bug is latent on all release branches, but would not be exposed without rtl us/ss_truncate simplification.
[Bug target/110235] [14 Regression] Wrong use of us_truncate in SSE and AVX RTL representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110235 --- Comment #7 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:f8e02702726d4514b8ff9f5481c9c1f5d34e1787 commit r14-1917-gf8e02702726d4514b8ff9f5481c9c1f5d34e1787 Author: liuhongt Date: Thu Jun 15 16:46:14 2023 +0800 Refined 256/512-bit vpacksswb/vpackssdw patterns. The packing in vpacksswb/vpackssdw is not a simple concat, it's an interweave from src1 and src2 for every 128 bit(or 64-bit for the ss_truncate result). .i.e. dst[192-255] = ss_truncate (src2[128-255]) dst[128-191] = ss_truncate (src1[128-255]) dst[64-127] = ss_truncate (src2[0-127]) dst[0-63] = ss_truncate (src1[0-127] The patch refined those patterns with an extra vec_select for the interweave. gcc/ChangeLog: PR target/110235 * config/i386/sse.md (_packsswb): Substitute with .. (sse2_packsswb): .. this, .. (avx2_packsswb): .. this and .. (avx512bw_packsswb): .. this. (_packssdw): Substitute with .. (sse2_packssdw): .. this, .. (avx2_packssdw): .. this and .. (avx512bw_packssdw): .. this. gcc/testsuite/ChangeLog: * gcc.target/i386/avx512bw-vpackssdw-3.c: New test. * gcc.target/i386/avx512bw-vpacksswb-3.c: New test.
[Bug target/110235] [14 Regression] Wrong use of us_truncate in SSE and AVX RTL representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110235 --- Comment #6 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:58e61a3ab1c13b6d5b07d86a30cf48a46e0345c8 commit r14-1916-g58e61a3ab1c13b6d5b07d86a30cf48a46e0345c8 Author: liuhongt Date: Wed Jun 14 10:34:32 2023 +0800 Reimplement packuswb/packusdw with UNSPEC_US_TRUNCATE instead of original us_truncate. packuswb/packusdw does unsigned saturation for signed source, but rtl us_truncate means does unsigned saturation for unsigned source. So for value -1, packuswb will produce 0, but us_truncate produces 255. The patch reimplement those related patterns and functions with UNSPEC_US_TRUNCATE instead of us_truncate. gcc/ChangeLog: PR target/110235 * config/i386/i386-expand.cc (ix86_split_mmx_pack): Use UNSPEC_US_TRUNCATE instead of original us_truncate for packusdw/packuswb. * config/i386/mmx.md (mmx_packswb): Substitute with .. (mmx_packsswb): .. this and .. (mmx_packuswb): .. this. (mmx_packusdw): Use UNSPEC_US_TRUNCATE instead of original us_truncate. (s_trunsuffix): Removed code iterator. (any_s_truncate): Ditto. * config/i386/sse.md (_packuswb): Use UNSPEC_US_TRUNCATE instead of original us_truncate. (_packusdw): Ditto. * config/i386/i386.md (UNSPEC_US_TRUNCATE): New unspec_c_enum.
[Bug target/80353] AVX512: _mm512_slli_epi32, the last argument must be an 8-bit immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80353 Andrew Pinski changed: What|Removed |Added CC||denis.yaroshevskij at gmail dot co ||m --- Comment #3 from Andrew Pinski --- *** Bug 110303 has been marked as a duplicate of this bug. ***
[Bug target/110303] With -O0, _mm_shuffle_epi32 with a constexpr function argument does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110303 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 80353. constexpr function does not have to be a full constexpression in many cases. *** This bug has been marked as a duplicate of bug 80353 ***
[Bug target/110303] With -O0, _mm_shuffle_epi32 with a constexpr function argument does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110303 --- Comment #2 from Andrew Pinski --- so _mm_shuffle_epi32 requires a constant but since it is an argument, the argument, it is not a constant expression requirement.
[Bug target/110303] Without -O0, _mm_shuffle_epi32 with a constexpr function argument does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110303 Andrew Pinski changed: What|Removed |Added Summary|In debug mode, gcc does not |Without -O0, |force compile time |_mm_shuffle_epi32 with a |evaluation for immediate|constexpr function argument |arguments |does not compile Component|c++ |target --- Comment #1 from Andrew Pinski --- I think this is correct behavior really.
[Bug c++/110303] New: In debug mode, gcc does not force compile time evaluation for immediate arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110303
Bug ID: 110303
Summary: In debug mode, gcc does not force compile time
evaluation for immediate arguments
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.yaroshevskij at gmail dot com
Target Milestone: ---
Minimum example:
The following code
```
#include "immintrin.h"
constexpr int f() { return 0; }
__m128i shuffle(__m128i x) { return _mm_shuffle_epi32(x, f()); }
```
Does not compile in debug
Godbolt: https://godbolt.org/z/x7bfhr4vY
[Bug ipa/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #35 from Jan Hubicka --- seems inlining works correctly since gcc12. It may be nice to turn that into a testcase.
[Bug libstdc++/110287] _M_check_len is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
--- Comment #5 from Jan Hubicka ---
> Do you mean something like this?
I sent my own version, but yours looks nicer.
>
> diff --git a/libstdc++-v3/include/bits/stl_vector.h
> b/libstdc++-v3/include/bits/stl_vector.h
> index 70ced3d101f..a4dbfeb8b5b 100644
> --- a/libstdc++-v3/include/bits/stl_vector.h
> +++ b/libstdc++-v3/include/bits/stl_vector.h
> @@ -1902,6 +1902,21 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> return (__len < size() || __len > max_size()) ? max_size() : __len;
>}
>
> + // Called by _M_insert_aux etc.
> + _GLIBCXX20_CONSTEXPR
> + size_type
> + _M_check_len_1(const char* __s) const
> + {
> + if (__builtin_constant_p(size()))
Perhaps ruling this out for 32bit ports? Or can we assume that half of
address space can never be allocated in single block?
> + {
> + if (size() == 0)
> + return 1;
> + else if (size() < max_size() / 2)
I think even this conditional is safe to be assumed to be true,
since we can not allocate half of 64bit address space.
In general it is importnat to not fall through to _M_check_len.
As I noticed, we may want to use assume attribute to make clear that
retval <= max_size ()
to avoid other unnecesary throws downstream.
Honza
[Bug modula2/110284] [14 Regression] Bootstrap failures with m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110284 Gaius Mulley changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #8 from Gaius Mulley --- optimistically closing - thanks!
[Bug preprocessor/58770] GCC very slow compiling with #pragma once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58770 --- Comment #8 from Sam James --- (See the thread at https://inbox.sourceware.org/gcc-patches/6027e3bb-99f9-573b-ff5e-ea1a48882...@acm.org/.)
[Bug modula2/110284] [14 Regression] Bootstrap failures with m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110284 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Sure. It will take a week or two to be sure it worked, but I can always reopen if it didn't.
[Bug tree-optimization/110301] [14 Regression] x264 regression on Neoverse-N1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110301 --- Comment #2 from Andrew Pinski --- OR: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4e31e63ea7edffd1212fc17ce8d50672035bb64b But I don;t think that would change anything here.
[Bug tree-optimization/110301] [14 Regression] x264 regression on Neoverse-N1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110301 --- Comment #1 from Andrew Pinski --- Maybe: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ea616f687dccbe42012f786c0ebade5b05850206 https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=710b8dec61a73cbbf5dadbdd2070a85e690e8184
[Bug tree-optimization/110301] [14 Regression] x264 regression on Neoverse-N1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110301 Andrew Pinski changed: What|Removed |Added Summary|x264 regression on |[14 Regression] x264 |Neoverse-N1 |regression on Neoverse-N1 Version|13.1.0 |14.0 Target Milestone|--- |14.0
[Bug tree-optimization/110302] New: libquantum regression on zen3 with LTO and PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110302 Bug ID: 110302 Summary: libquantum regression on zen3 with LTO and PGO Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- Seen here https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=474.210.0 between g:067a8c7cb897b6a1ea5b1d26df8e89ccc7f0659c and g:59946a4c0c97c842ac5a34de5b1aadb73b738809
[Bug modula2/110284] [14 Regression] Bootstrap failures with m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110284 --- Comment #6 from Gaius Mulley --- ok to close?
[Bug tree-optimization/110301] New: x264 regression on Neoverse-N1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110301 Bug ID: 110301 Summary: x264 regression on Neoverse-N1 Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- This happen between g:9e3607e19bcd34e1fc857ca44ae30a8a1a4f5e20 and g:57446d1bc9757ee1fb030600d38fa9487231f2a4 (Jun 16 2023) https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=581.377.0
[Bug modula2/110284] [14 Regression] Bootstrap failures with m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110284 --- Comment #5 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:24f75498ea59be94ae3eb1b82aa0b9de6ebfa232 commit r14-1911-g24f75498ea59be94ae3eb1b82aa0b9de6ebfa232 Author: Gaius Mulley Date: Sun Jun 18 21:07:59 2023 +0100 PR modula2/110284 Remove stor-layout.o and backend header files This patch removes stor-layout.o from the front end and also removes back end header files from gcc-consolidation.h. gcc/m2/ChangeLog: PR modula2/110284 * Make-lang.in (m2_OBJS): Assign $(GM2_C_OBJS). (GM2_C_OBJS): Remove m2/stor-layout.o. (m2/stor-layout.o): Remove rule. * gm2-gcc/gcc-consolidation.h (rtl.h): Remove include. (df.h): Remove include. (except.h): Remove include. Signed-off-by: Gaius Mulley
[Bug fortran/92887] [F2008] Passing nullified/disassociated pointer or unalloc allocatable to OPTIONAL + VALUE dummy fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92887 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #55356|0 |1 is obsolete|| --- Comment #4 from anlauf at gcc dot gnu.org --- Created attachment 55360 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55360=edit Patch v2, handles most of pr92887 and pr92178 This patch tries to gather temporary handling as needed by pr92887 and pr92178 and implements a simple "conditional temporary" for the case that we cannot dereference a disassociated pointer or unallocated allocatable (also only scalar version for now). There is still the issue for character variables and expression, which I think is independent of the present pr. I'll need broader feedback, so unless someone adds to this pr, I'll submit the present patch - with testcases - to get attention. Regtests ok here, BTW.
[Bug tree-optimization/95185] Failure to optimize specific kind of sign comparison check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185 --- Comment #5 from Andrew Pinski --- _1 = x_4(D) >= 0; _2 = y_5(D) <= 0; _3 = _1 == _2; Something like: Prefer ^ over == ``` (for cmp (for cmpN (for neeq (simplify (neeq:c (cmp @0 @1) @3 (if (cmpN == inverseof(cmp, TREE_TYPE (type)) (bit_xor (cmpN @0 @1) @3) ) ) ))) ``` This is what clang seems to do rather than any magic around == really. I do wonder if we should try to expand bool == bool as bool^bool^1 .
[Bug modula2/110284] [14 Regression] Bootstrap failures with m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110284 --- Comment #4 from Gaius Mulley --- Also now bootstrapped successfully on ppc64le - so I'll git commit the changes.
[Bug middle-end/53669] suboptimal small switch - 3-way jump with only 1 comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53669 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-06-18 Ever confirmed|0 |1 Component|rtl-optimization|middle-end --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/89582] Suboptimal code generated for floating point struct in -O2 compare to -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89582 Andrew Pinski changed: What|Removed |Added Summary|Suboptimal code generated |Suboptimal code generated |for floating point struct |for floating point struct |in -O3 compare to -O2 |in -O2 compare to -O1 --- Comment #9 from Andrew Pinski --- Note since GCC 12, it is worse at -O2 since GCC 12 enables the vectorizer by default.
[Bug tree-optimization/95929] Failure to optimize tautological comparisons of comparisons to a single one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95929 --- Comment #3 from Andrew Pinski --- On the GCC 13+ we get: _1 = a_5(D) != 0; _8 = a_5(D) == 0; // _1^1 _2 = b_3(D) != 0; _13 = _2 ? _8 : _1; _6 = (int) _13; or rather _13 = _2 ? _1 ^ 1 : _1 But we don't match that. We could dosoemthing like: ``` (for cmp (for cmpN (simplify (cond @0 (cmpN @1 @2) (cmp@3 @1 @2)) (if (inverseof(cmp, TREE_TYPE (@1)) == cmpN) (bit_xor (convert @0) @3) ) ) ) ) ``` And that would fix this I think.
[Bug c++/105512] compilation with -fmodules-ts and std=c++20 leads to segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105512
David Truby changed:
What|Removed |Added
CC||gnu.w2nnu at simplelogin dot
com
--- Comment #1 from David Truby ---
I also see this issue and have a reproducer here:
main.cpp
#include
#include
import test;
int main() {
std::cout << tester();
}
test.cpp
module;
#include
export module test;
export std::string tester() {
return "hello world\n";
}
Interestingly the issue also goes away if -D_GLIBCXX_USE_CXX11_ABI=0 is passed
to both TUs so I suspect there's an issue with the module file not exporting
the correct ABI for `std::string`
[Bug c++/110300] Template disambiguator accepted for non-template function with the function from a dependent base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110300
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-06-18
Status|UNCONFIRMED |NEW
Summary|Template disambiguator |Template disambiguator
|accepted for non-template |accepted for non-template
|function|function with the function
||from a dependent base class
Known to fail||4.1.2
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Reduced C++98 code:
```
template
struct Bar{
void setNumber(int) {}
};
template
struct Asd : public Bar{
void doSomething();
};
template
void Asd::doSomething() {
this->template setNumber(N);
}
int main() {
Asd<42> obj;
obj.doSomething();
}
```
Confirmed. not a regression as far as I can tell.
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #15 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:5a1ef1cfac005370d0a5a0f85798724cb2c9cf5e commit r14-1909-g5a1ef1cfac005370d0a5a0f85798724cb2c9cf5e Author: Honza Date: Sun Jun 18 18:58:26 2023 +0200 Analyze SRA candidates in ipa-fnsummary this patch extends ipa-fnsummary to anticipate statements that will be removed by SRA. This is done by looking for calls passing addresses of automatic variables. In function body we look for dereferences from pointers of such variables and mark them with new not_sra_candidate condition. This is just first step which is overly optimistic. We do not try to prove that given automatic variable will not be SRAed even after inlining. We now also optimistically assume that the transformation will always happen. I will restrict this in a followup patch, but I think it is useful to gether some data on how much code is affected by this. This is motivated by PR109849 where we fail to fully inline push_back. The patch alone does not solve the problem even for -O3, but improves analysis in this case. gcc/ChangeLog: PR tree-optimization/109849 * ipa-fnsummary.cc (evaluate_conditions_for_known_args): Add new parameter ES; handle ipa_predicate::not_sra_candidate. (evaluate_properties_for_edge): Pass es to evaluate_conditions_for_known_args. (ipa_fn_summary_t::duplicate): Handle sra candidates. (dump_ipa_call_summary): Dump points_to_possible_sra_candidate. (load_or_store_of_ptr_parameter): New function. (points_to_possible_sra_candidate_p): New function. (analyze_function_body): Initialize points_to_possible_sra_candidate; determine sra predicates. (estimate_ipcp_clone_size_and_time): Update call of evaluate_conditions_for_known_args. (remap_edge_params): Update points_to_possible_sra_candidate. (read_ipa_call_summary): Stream points_to_possible_sra_candidate (write_ipa_call_summary): Likewise. * ipa-predicate.cc (ipa_predicate::add_clause): Handle not_sra_candidate. (dump_condition): Dump it. * ipa-predicate.h (struct inline_param_summary): Add points_to_possible_sra_candidate. gcc/testsuite/ChangeLog: PR tree-optimization/109849 * g++.dg/ipa/devirt-45.C: Update template.
[Bug modula2/110284] [14 Regression] Bootstrap failures with m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110284 --- Comment #3 from Jakub Jelinek --- Comment on attachment 55359 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55359 Proposed fix Except for the stor-layout changes that is what I was trying, so if it works, great.
[Bug modula2/110284] [14 Regression] Bootstrap failures with m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110284 Gaius Mulley changed: What|Removed |Added CC||gaius at gcc dot gnu.org --- Comment #2 from Gaius Mulley --- Created attachment 55359 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55359=edit Proposed fix Thanks for the hints and diagnosis - very useful - especially as it should fail reliably. Here is a proposed patch based on your 2nd email using: m2_OBJS = $(GM2_C_OBJS) apologies for not seeing the 2nd email on Monday. I've seen the patch bootstrap successfully on lp64 amd64 using make -j 30.
[Bug c++/110300] New: Template disambiguator accepted for non-template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110300
Bug ID: 110300
Summary: Template disambiguator accepted for non-template
function
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: csaba_22 at yahoo dot co.uk
Target Milestone: ---
template
struct Bar{
void setNumber(int) {}
};
template
struct Asd : public Bar>{
void doSomething();
};
template
inline void Asd::doSomething() {
this->template setNumber(N);
}
int main() {
Asd<42> obj;
obj.doSomething();
}
(https://godbolt.org/z/xbs8GqG7h)
is accepted by GCC 13 and trunk, even though setNumber() is not a template
function.
https://stackoverflow.com/q/76500060/
[Bug c/110299] New: RISC-V: ICE when build RVV intrinsic widen with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110299
Bug ID: 110299
Summary: RISC-V: ICE when build RVV intrinsic widen with
"-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and
13.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pan2.li at intel dot com
Target Milestone: ---
Created attachment 55358
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55358=edit
Reproduce code
Given we have the below code.
#include "riscv_vector.h"
#include "riscv_vector.h"
vfloat32m1_t test_vfwredosum_vs_f16m1_f32m1(vfloat16m1_t vector, vfloat32m1_t
scalar, size_t vl) {
return __riscv_vfwredosum_vs_f16m1_f32m1(vector, scalar, vl);
}
There will be the ICE when build similar as "riscv64-unknown-elf-gcc
-march=rv64gc_zve64d -mabi=lp64 -O3 -Wno-psabi -c -S test-float.c -o -".
.text
test-widen.c: In function 'test_vfwredosum_vs_f16m1_f32m1':
test-widen.c:4:10: error: invalid argument to built-in function
4 | return __riscv_vfwredosum_vs_f16m1_f32m1(vector, scalar, vl);
| ^
during RTL pass: expand
test-widen.c:4:10: internal compiler error: Segmentation fault
0x1044343 crash_signal
../.././gcc/gcc/toplev.cc:314
0x7f76d0c4251f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xc5d1d7 store_expr(tree_node*, rtx_def*, int, bool, bool)
../.././gcc/gcc/expr.cc:6345
0xc5f500 expand_assignment(tree_node*, tree_node*, bool)
../.././gcc/gcc/expr.cc:6048
0xb2142c expand_call_stmt
../.././gcc/gcc/cfgexpand.cc:2829
0xb2142c expand_gimple_stmt_1
../.././gcc/gcc/cfgexpand.cc:3880
0xb2142c expand_gimple_stmt
../.././gcc/gcc/cfgexpand.cc:4044
0xb26770 expand_gimple_basic_block
../.././gcc/gcc/cfgexpand.cc:6096
0xb28837 execute
../.././gcc/gcc/cfgexpand.cc:6831
