[Bug target/106096] [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu because stage 2 gcc is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096 Xi Ruoyao changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #13 from Xi Ruoyao --- Fixed for trunk and gcc-12.
[Bug target/106096] [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu because stage 2 gcc is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096 --- Comment #9 from Xi Ruoyao --- Created attachment 53214 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53214=edit patch removing r13 from SIBCALL_REGS I'm testing this patch now. I suggest to apply this for trunk and gcc-12 branch first (as gcc-12 also miscompiles the test case). Then if the reordering of RA preference can improve performance, you may apply it later (and also adjust the changes in this patch again).
[Bug target/106096] [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu because stage 2 gcc is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096 --- Comment #7 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #6) > (In reply to chenglulu from comment #5) > > Created attachment 53213 [details] > > Modify the allocation order of caller saved registers. > > I think we need to completely prevent LARCH_PROLOGUE_TEMP from being used > for sibcall For example, the RISC-V change explicitly exclude x5 (their temp for epilogue): https://gcc.gnu.org/legacy-ml/gcc-patches/2019-10/msg01228.html
[Bug target/106096] [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu because stage 2 gcc is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096 --- Comment #6 from Xi Ruoyao --- (In reply to chenglulu from comment #5) > Created attachment 53213 [details] > Modify the allocation order of caller saved registers. I think we need to completely prevent LARCH_PROLOGUE_TEMP from being used for sibcall: diff --git a/gcc/config/loongarch/loongarch.h b/gcc/config/loongarch/loongarch.h index 4d107a42209..f9de9a6e4fb 100644 --- a/gcc/config/loongarch/loongarch.h +++ b/gcc/config/loongarch/loongarch.h @@ -511,7 +511,7 @@ enum reg_class #define REG_CLASS_CONTENTS \ { \ { 0x, 0x, 0x }, /* NO_REGS */ \ - { 0x001ff000, 0x, 0x }, /* SIBCALL_REGS */ \ + { 0x001fd000, 0x, 0x }, /* SIBCALL_REGS */ \ { 0xff90, 0x, 0x }, /* JIRL_REGS */\ { 0xfffc, 0x, 0x }, /* CSR_REGS */ \ { 0x, 0x, 0x }, /* GR_REGS */ \ Or even if LARCH_PROLOGUE_TEMP is less preferred, the register allocator may still use it for sibcall and blow something up again. (Above is for $r13, if you want to use $r12 instead as LARCH_PROLOGUE_TEMP you need to adjust it.)
[Bug target/106097] undefined behaviors regarding integer shifts in loongarch_build_integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106097 --- Comment #10 from Xi Ruoyao --- (In reply to chenglulu from comment #9) > Created attachment 53206 [details] > use LU52I_B and LU32I_B instead of hard coding those long > + codes[cost].value = (value & LU32I_B) > + | (sign51 ? LU52I_B : 0); nit: I think this can fit in one line. Otherwise LGTM. As the port maintainer you can push it directly into master. Normally we should bootstrap and regtest before applying a patch, but currently the bootstrap is blocked by PR106096 :(.
[Bug target/106096] [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu because stage 2 gcc is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096 Xi Ruoyao changed: What|Removed |Added Known to work|12.1.0 | --- Comment #4 from Xi Ruoyao --- Remove "known to work" because 12.1.0 miscompiles the test case too.
[Bug target/106096] [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu because stage 2 gcc is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096 Xi Ruoyao changed: What|Removed |Added Build|loongarch64-linux-gnu | Summary|[13 regression] ICE |[13 regression] ICE |building stage 2 libgcc on |building stage 2 libgcc on |loongarch64-linux-gnu since |loongarch64-linux-gnu |r13-911 |because stage 2 gcc is ||miscompiled Host|loongarch64-linux-gnu | --- Comment #3 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #2) > Created attachment 53208 [details] > reduced testcase For this testcase GCC generates: .L20: lu12i.w $r13,4096>>12 # 0x1000 add.d $r3,$r3,$r13 ld.d$r1,$r3,24 or $r4,$r23,$r0 ld.d$r23,$r3,16 la.local$r5,b addi.d $r3,$r3,32 jr $r13
[Bug target/106096] [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu since r13-911
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096 --- Comment #2 from Xi Ruoyao --- Created attachment 53208 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53208=edit reduced testcase It looks like a LoongArch code generation issue, not really related to the changes in r13-911.
[Bug target/106097] undefined behaviors regarding integer shifts in loongarch_build_integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106097 --- Comment #7 from Xi Ruoyao --- (In reply to chenglulu from comment #6) > Created attachment 53205 [details] > 0001-Fix-bug-for-PR16097.patch You can reuse LU32I_B and LU52I_B instead of hard coding those long constants :).
[Bug target/106096] [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu since r13-911
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096 --- Comment #1 from Xi Ruoyao --- Stage 1 GCC generates some very strange code for stage 2 GCC, jumping to "0x2000": .L747: beqz$r12,.L750 lu12i.w $r13,8192>>12 # 0x2000 ld.d$r5,$r26,8 add.d $r3,$r3,$r13 ld.d$r1,$r3,168 ld.d$r22,$r3,160 ld.d$r23,$r3,152 ld.d$r24,$r3,144 ld.d$r26,$r3,128 ld.d$r27,$r3,120 ld.d$r28,$r3,112 ld.d$r29,$r3,104 ld.d$r30,$r3,96 ld.d$r31,$r3,88 or $r4,$r25,$r0 ld.d$r25,$r3,136 addi.d $r3,$r3,176 jr $r13
[Bug target/106097] undefined behaviors regarding integer shifts in loongarch_build_integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106097 --- Comment #4 from Xi Ruoyao --- BTW I found this issue trying to triage PR106096, but I think it's not related to this one.
[Bug target/106097] undefined behaviors regarding integer shifts in loongarch_build_integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106097 --- Comment #5 from Xi Ruoyao --- And it actually does not need a reproducer: "x << 32 >> 32" for sign-extension is undefined by C++ standard if x is negative: > The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are > zero-filled. If E1 has an unsigned type, the value of the result is > E1 × 2^{E2}, reduced modulo one more than the maximum value representable in > the result type. Otherwise, if E1 has a signed type and non-negative value, > and E1 × 2^{E2} is representable in the corresponding unsigned type of the > result type, then that value, converted to the result type, is the resulting > value; otherwise, the behavior is undefined. And the result of right shifting negative numbers is implementation-defined (zext or sext), though GCC always uses sext.
[Bug target/106097] undefined behaviors regarding integer shifts in loongarch_build_integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106097 --- Comment #3 from Xi Ruoyao --- (In reply to Andrew Pinski from comment #2) > by using the --with-build-config=bootstrap-ubsan option at configure time or > BUILD_CONFIG variable to build time. > > See https://gcc.gnu.org/install/build.html The problem is -fsanitize=undefined does not work on LoongArch for now. But it can be reproduced by building a cross compile on x86_64: /path/to/gcc/configure --target=loongarch64-linux-gnu make {C,CXX}FLAGS="-O2 -g -fsanitize=undefined" all-gcc
[Bug target/106097] New: undefined behaviors regarding integer shifts in loongarch_build_integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106097 Bug ID: 106097 Summary: undefined behaviors regarding integer shifts in loongarch_build_integer Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang Target Milestone: --- UBSan reports these undefined behaviors building a cross compiler for loongarch64-linux-gnu on x86_64-linux-gnu: /home/xry111/git-repos/gcc-la-build/./gcc/xgcc -B/home/xry111/git-repos/gcc-la-build/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=../../gcc/gcc/testsuite/selftests ../../gcc/gcc/config/loongarch/loongarch.cc:1471:49: runtime error: left shift of 4294967296 by 32 places cannot be represented in type 'long int' ../../gcc/gcc/config/loongarch/loongarch.cc:1520:49: runtime error: left shift of negative value -524288 ../../gcc/gcc/config/loongarch/loongarch.cc:1515:38: runtime error: left shift of negative value -2048 /home/xry111/git-repos/gcc-la-build/./gcc/xgcc -B/home/xry111/git-repos/gcc-la-build/./gcc/ -xc++ -nostdinc /dev/null -S -o /dev/null -fself-test=../../gcc/gcc/testsuite/selftests ../../gcc/gcc/config/loongarch/loongarch.cc:1471:49: runtime error: left shift of 4294967296 by 32 places cannot be represented in type 'long int' ../../gcc/gcc/config/loongarch/loongarch.cc:1520:49: runtime error: left shift of negative value -524288 ../../gcc/gcc/config/loongarch/loongarch.cc:1515:38: runtime error: left shift of negative value -2048
[Bug target/106096] New: [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu since r13-911
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096 Bug ID: 106096 Summary: [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu since r13-911 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang Target Milestone: --- Since r13-911, bootstrapping on loongarch64-linux-gnu is broken because of an ICE building stage 2 libgcc. This issue is particularly diffcult to diagnose, due to the reasons: 1. r13-910 and r13-909 does not build, so it's hard to tell which change "really" triggers the issue. 2. r13-{909,910,911} consist a very large change. 3. GCC even fails to produce a stacktrace on the ICE. 4. It's not reproducible with a cross compiler on x86_64 host, even with ASan and UBSan. A backtrace gathered using GDB: #0 0x2000 in ?? () #1 0x000120b2157c in path_range_query::range_defined_in_block ( this=this@entry=0x121b3bb20, r=..., name=name@entry=0x755a17a0, bb=bb@entry=0x75598750) at ../../gcc/gcc/gimple-range-path.cc:354 #2 0x000120b21880 in path_range_query::compute_ranges_in_phis ( this=this@entry=0x121b3bb20, bb=bb@entry=0x75598750) at ../../gcc/gcc/gimple-range-path.cc:400 #3 0x000120b21b70 in path_range_query::compute_ranges_in_block ( this=this@entry=0x121b3bb20, bb=bb@entry=0x75598750) at ../../gcc/gcc/gimple-range-path.cc:448 #4 0x000120b225b8 in path_range_query::compute_ranges (this=0x121b3bb20, path=..., imports=) at ../../gcc/gcc/gimple-range-path.cc:665 #5 0x000120bb1ba0 in back_threader::find_taken_edge_cond ( this=0x7fff6d18, path=..., cond=0x75775f40) at ../../gcc/gcc/tree-ssa-threadbackward.cc:319 #6 0x000120bb1d9c in back_threader::find_taken_edge ( this=this@entry=0x7fff6d18, path=...) at ../../gcc/gcc/tree-ssa-threadbackward.cc:276 #7 0x000120bb2768 in back_threader::maybe_register_path ( this=this@entry=0x7fff6d18) at ../../gcc/gcc/tree-ssa-threadbackward.cc:232 #8 0x000120bb2f34 in back_threader::find_paths_to_names ( this=this@entry=0x7fff6d18, bb=, interesting=interesting@entry=0x7fff6c90) at ../../gcc/gcc/tree-ssa-threadbackward.cc:419 #9 0x000120bb317c in back_threader::resolve_phi ( interesting=, phi=, this=) at ../../gcc/gcc/tree-ssa-threadbackward.cc:396 #10 back_threader::resolve_phi (this=0x7fff6d18, phi=0x757a0d00, interesting=0x7fff6c90) at ../../gcc/gcc/tree-ssa-threadbackward.cc:356 #11 0x000120bb2cf0 in back_threader::find_paths_to_names ( this=this@entry=0x7fff6d18, bb=, interesting=interesting@entry=0x7fff6c90) at ../../gcc/gcc/tree-ssa-threadbackward.cc:444 #12 0x000120bb2ddc in back_threader::find_paths_to_names ( this=this@entry=0x7fff6d18, bb=, bb@entry=0x755986e8, interesting=interesting@entry=0x7fff6c90) at ../../gcc/gcc/tree-ssa-threadbackward.cc:459 #13 0x000120bb3408 in back_threader::find_paths (this=0x7fff6d18, bb=0x755986e8, name=0x755a1050) at ../../gcc/gcc/bitmap.h:955 #14 0x000120bb3620 in back_threader::thread_blocks ( this=this@entry=0x7fff6d18) at ../../gcc/gcc/tree-ssa-threadbackward.cc:901 #15 0x000120bb3694 in (anonymous namespace)::pass_thread_jumps::execute ( this=, fun=) at ../../gcc/gcc/tree-ssa-threadbackward.cc:1003 #16 0x00012082a10c in execute_one_pass (pass=pass@entry=0x1219d0550) at ../../gcc/gcc/passes.cc:2638 #17 0x00012082aa68 in execute_pass_list_1 (pass=0x1219d0550) at ../../gcc/gcc/passes.cc:2738 #18 0x00012082aa78 in execute_pass_list_1 (pass=0x1219cded0) at ../../gcc/gcc/passes.cc:2739 #19 0x00012082aad8 in execute_pass_list (fn=, pass=) at ../../gcc/gcc/passes.cc:2749 #20 0x0001203e1a1c in cgraph_node::expand (this=0x75609980) at ../../gcc/gcc/context.h:48 #21 cgraph_node::expand (this=0x75609980) at ../../gcc/gcc/cgraphunit.cc:1788 #22 0x0001203e3540 in expand_all_functions () at ../../gcc/gcc/cgraphunit.cc:1999 #23 symbol_table::compile (this=this@entry=0x7548c000) at ../../gcc/gcc/cgraphunit.cc:2349 #24 0x0001203e6be0 in symbol_table::compile (this=0x7548c000) at ../../gcc/gcc/cgraphunit.cc:2262 #25 symbol_table::finalize_compilation_unit (this=0x7548c000) at ../../gcc/gcc/cgraphunit.cc:2530 #26 0x00012092d148 in compile_file () at ../../gcc/gcc/toplev.cc:479 #27 0x0001201ca3d4 in do_compile (no_backend=false) at ../../gcc/gcc/toplev.cc:2144 #28 toplev::main (this=this@entry=0x7fff7148, argc=, argc@entry=3, argv=, argv@entry=0x7fff72d8) at ../../gcc/gcc/toplev.cc:2296 #29 0x0001201cba28 in main (argc=, argv=0x7fff72d8) at ../
[Bug target/106088] ld cannot find dependent libraries when cross compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106088 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #2 from Xi Ruoyao --- It means you've misconfigured ld. GCC has nothing to do with tracking DT_NEEDED entries in ELF shared objects.
[Bug c++/104461] cody requires -fmodule-mapper hostname to have an IPv6 address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104461 Xi Ruoyao changed: What|Removed |Added CC||jwakely.gcc at gmail dot com, ||xry111 at mengyan1223 dot wang --- Comment #1 from Xi Ruoyao --- It's because the paper (https://wg21.link/p1184) explicitly says "an ipv6 domain socket & port", I think. It's not clear if AI_V4MAPPED addresses are allowed. The problem is there is no "elegent" way for a distro maintainer to ensure an IPv6 address for localhost is available on Linux/GNU. If /etc/nsswitch.conf contains hosts: files dns (this is the default of Glibc and used by many distros), and /etc/hosts contains 127.0.0.1 localhost ::1 localhost By default Glibc will ignore "::1" for localhost, unless "multi on" is specified in /etc/host.conf. But Glibc doc explicitly says it may cause a performance issue (see man host.conf). On systems using systemd, the distro can specify nss_myhostname in /etc/nsswitch.conf, but it does not exist on non-systemd distros.
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #8 from Xi Ruoyao --- Shall I close it as FIXED, or keep it opening waiting for AMD response?
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024 --- Comment #34 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #33) > > So in struct B { int : 0; double a, b; }; it will go into GPR and FPR > > GCC trunk puts "a" into FPR, not GPR! So the "leading" zero-width > bit-fields are ignored (GCC does not think it's a part of any "64-bit > chunk"), but other zero-width bit-fields are accounted... This is just > puzzling to me. Remove this: I just forgot to rename ".C" to ".c" when I tested this with GCC 11. But still I think clang's behavior is better. > I'll make a patch to match the behavior of clang.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024 --- Comment #33 from Xi Ruoyao --- (In reply to Segher Boessenkool from comment #31) > Well, what do other compilers do? It's not such a good idea to break ABI > compatibility with the 1990's compilers ;-) Does someone have access to a Greenhills compiler here? (In reply to Jakub Jelinek from comment #32) > I think best would be to ignore them altogether, especially if other > compilers do that too. I agree the behavior of clang (or previous G++) is more "rational". To make things more "interesting": > So in struct B { int : 0; double a, b; }; it will go into GPR and FPR GCC trunk puts "a" into FPR, not GPR! So the "leading" zero-width bit-fields are ignored (GCC does not think it's a part of any "64-bit chunk"), but other zero-width bit-fields are accounted... This is just puzzling to me. I'll make a patch to match the behavior of clang.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024 --- Comment #30 from Xi Ruoyao --- (In reply to Jakub Jelinek from comment #28) > Also, what does LLVM do? clang-14 agree with gcc-12 on the return values, as we expected (the ABI documentation is clear enough). But clang-14 treats arguments differently: struct foo { int : 0; double a; int : 0; double b; int : 0; }; extern void func(struct foo); void pass_foo(void) { struct foo test; test.a = 114; test.b = 514; func(test); } It puts "a" into $f12 and "b" into $f13. So the behavior of clang-14 and clang++-14 handling arguments with zero-width bit-fields is same as g++-11, and different from g++-12, gcc-11, and gcc-12. I'm not sure if we should keep our current behavior, or change it to match LLVM.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024 --- Comment #29 from Xi Ruoyao --- > Is there somebody who can clarify the MIPS ABI intent? > Also, what does LLVM do? I've CC'ed Yunqiang and Fangrui. And I'll build clang for MIPS to see...
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024 --- Comment #27 from Xi Ruoyao --- (In reply to Jakub Jelinek from comment #23) > struct A { double a; int : 0; double b; }; For MIPS I've done some experiment with this and the result (with N64 ABI) is: With GCC trunk, G++ trunk, and GCC 11.2: argument passed via FPR $f12 and GPR $5, returned via GPR $2 and $3 With G++ 11.2: argument passed via FPR $f12 and $f13, returned via FPR $f0 and $f2 So I guess we need -Wpsabi for both mips_function_arg and mips_fpr_return_fields.
[Bug lto/97787] [10/11/12 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #29 from Xi Ruoyao --- GNU ld has added a workaround for this. But I'm not sure what will happen using other linkers (gold or lld).
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 104851, which changed state. Bug 104851 Summary: off-by-one out-of-bound access in supports_vec_convert_optab_p, at optabs-query.cc:725 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104851 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/104851] off-by-one out-of-bound access in supports_vec_convert_optab_p, at optabs-query.cc:725
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104851 Xi Ruoyao changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Xi Ruoyao --- Fixed for trunk.
[Bug tree-optimization/104851] New: off-by-one out-of-bound access in supports_vec_convert_optab_p, at optabs-query.cc:725
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104851 Bug ID: 104851 Summary: off-by-one out-of-bound access in supports_vec_convert_optab_p, at optabs-query.cc:725 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang Target Milestone: --- We have: 723: int end = mode == VOIDmode ? MAX_MACHINE_MODE : mode; 724: for (int i = start; i <= end; ++i) 725:if (VECTOR_MODE_P ((machine_mode) i)) Line 725, eventually expands to access mode_class[MAX_MACHINE_MODE] at the last iteration when mode is VOIDmode. However, the number of elements of mode_class is NUM_MACHINE_MODES, which equals to MAX_MACHINE_MODE. This causes ubsan alerts like: ../../gcc/gcc/optabs-query.cc:725:9: runtime error: index 69 out of bounds for type 'unsigned char [69]' ../../gcc/gcc/optabs-query.cc:725:9: runtime error: load of address 0x0126faa83d with insufficient space for an object of type 'const unsigned char'
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 104842, which changed state. Bug 104842 Summary: mips: signed overflow in LUI_OPERAND https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104842 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/104842] mips: signed overflow in LUI_OPERAND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104842 Xi Ruoyao changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Xi Ruoyao --- Fixed for trunk.
[Bug rtl-optimization/104843] signed overflow in compute_const_anchors, at cse.cc:1180
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104843 Xi Ruoyao changed: What|Removed |Added Target||mips Blocks||63426 --- Comment #1 from Xi Ruoyao --- It seems mips is the only target with const_anchor != 0... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug rtl-optimization/104843] New: signed overflow in compute_const_anchors, at cse.cc:1180
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104843 Bug ID: 104843 Summary: signed overflow in compute_const_anchors, at cse.cc:1180 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang Target Milestone: --- Bootstrapping GCC on mips64el with a WIP patch for sanitizer support and bootstrap-ubsan produces: ../../gcc/gcc/cse.cc:1180:19: runtime error: signed integer overflow: 9223372036854775807 - -9223372036854775808 cannot be represented in type 'long int'
[Bug target/104842] New: mips: signed overflow in LUI_OPERAND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104842 Bug ID: 104842 Summary: mips: signed overflow in LUI_OPERAND Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang Target Milestone: --- Found this building GCC on mips64el-linux-gnuabi64 with bootstrap-ubsan (testing a patch enabling ubsan for mips64*-linux-gnu*): ../../gcc/gcc/config/mips/predicates.md:382:11: runtime error: signed integer overflow: 9223372036854775807 + 65536 cannot be represented in type 'long int' That line uses LUI_INT (x), which expands to LUI_OPERAND (INTVAL (x)). LUI_OPERAND is defined as: #define LUI_OPERAND(VALUE) \ (((VALUE) | 0x7fff) == 0x7fff \ || ((VALUE) | 0x7fff) + 0x1 == 0) Obviously this will cause a signed overflow when INTVAL (x) is, for example, the maximum value of HOST_WIDE_INT.
[Bug target/104820] New: mips: ICE in int_mode_for_mode, at stor-layout.cc:407 with -fzero-call-used-regs=all -mips4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104820 Bug ID: 104820 Summary: mips: ICE in int_mode_for_mode, at stor-layout.cc:407 with -fzero-call-used-regs=all -mips4 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang Target Milestone: --- May be related to PR104817, but the stack backtrace is different: echo 'int t() {}' | /home/xry111/git-repos/gcc-test-mips/gcc/cc1 -nostdinc -fzero-call-used-regs=all -mips4 t Analyzing compilation unit Performing interprocedural optimizations <*free_lang_data> {heap 1208k} {heap 1208k} {heap 1208k} {heap 1208k} {heap 1208k} {heap 1208k} {heap 1208k} {heap 1208k}Streaming LTO {heap 1208k} {heap 1208k} {heap 1208k} {heap 1208k} {heap 1208k} {heap 1208k}Assembling functions: tduring RTL pass: zero_call_used_regs : In function ‘t’: :1:10: internal compiler error: in int_mode_for_mode, at stor-layout.cc:407 0x13498b9 int_mode_for_mode(machine_mode) ../../gcc/gcc/stor-layout.cc:407 0xdf06ea emit_move_via_integer ../../gcc/gcc/expr.cc:3615 0xdf10ea emit_move_ccmode ../../gcc/gcc/expr.cc:3834 0xdf17ff emit_move_insn_1(rtx_def*, rtx_def*) ../../gcc/gcc/expr.cc:3974 0xdf21ab emit_move_insn(rtx_def*, rtx_def*) ../../gcc/gcc/expr.cc:4125 0x135d39b default_zero_call_used_regs(HARD_REG_SET) ../../gcc/gcc/targhooks.cc:1040 0xe98230 gen_call_used_regs_seq ../../gcc/gcc/function.cc:5927 0xe99800 execute ../../gcc/gcc/function.cc:6697 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug target/104817] mips: ICE with -fzero-call-used-regs=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104817 Xi Ruoyao changed: What|Removed |Added Target||mips64 Known to fail||12.0 --- Comment #2 from Xi Ruoyao --- It seems mips_output_move is called to "move" a const zero to the hi (!) register :(.
[Bug target/104817] mips: ICE with -fzero-call-used-regs=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104817 --- Comment #1 from Xi Ruoyao --- Not sure if this is an regression: it triggers another ICE with 11.2.0.
[Bug target/104817] New: mips: ICE with -fzero-call-used-regs=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104817 Bug ID: 104817 Summary: mips: ICE with -fzero-call-used-regs=all Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang Target Milestone: --- $ echo 'int t() {}' | /home/xry111/git-repos/gcc-test-mips/gcc/cc1 -nostdinc -fzero-call-used-regs=all Analyzing compilation unit Performing interprocedural optimizations <*free_lang_data> {heap 1208k} {heap 1208k} {heap 1208k} {heap 1208k} {heap 1208k} {heap 1208k} {heap 1208k} {heap 1208k}Streaming LTO {heap 1208k} {heap 1208k} {heap 1208k} {heap 1208k} {heap 1208k} {heap 1208k}Assembling functions: tduring RTL pass: final : In function ‘t’: :1:10: internal compiler error: in mips_output_move, at config/mips/mips.cc:5323 0x1834ac9 mips_output_move(rtx_def*, rtx_def*) ../../gcc/gcc/config/mips/mips.cc:5323 0x1ead799 output_313 ../../gcc/gcc/config/mips/mips.md:4771 0xe21260 get_insn_template(int, rtx_insn*) ../../gcc/gcc/final.cc:2047 0xe234ab final_scan_insn_1 ../../gcc/gcc/final.cc:2827 0xe23933 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) ../../gcc/gcc/final.cc:2940 0xe21086 final_1 ../../gcc/gcc/final.cc:1997 0xe264d5 rest_of_handle_final ../../gcc/gcc/final.cc:4285 0xe26834 execute ../../gcc/gcc/final.cc:4363 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 Xi Ruoyao changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-help/2022-February/1 ||41279.html --- Comment #2 from Xi Ruoyao --- See option 4 of https://gcc.gnu.org/legacy-ml/gcc/2017-01/msg00167.html.
[Bug target/104688] New: gcc and libatomic can use SSE for 128-bit atomic loads on Intel CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 Bug ID: 104688 Summary: gcc and libatomic can use SSE for 128-bit atomic loads on Intel CPUs with AVX Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang Target Milestone: --- In Dec 2021, Intel updated the SDM and added the following content: > Processors that enumerate support for Intel® AVX (by setting the feature flag > CPUID.01H:ECX.AVX[bit 28]) guarantee that the 16-byte memory operations > performed by the following instructions will always be carried out atomically: > - MOVAPD, MOVAPS, and MOVDQA. > - VMOVAPD, VMOVAPS, and VMOVDQA when encoded with VEX.128. > - VMOVAPD, VMOVAPS, VMOVDQA32, and VMOVDQA64 when encoded with EVEX.128 and > k0 (masking disabled). > > (Note that these instructions require the linear addresses of their memory > operands to be 16-byte aligned.) (see Change 13, https://cdrdv2.intel.com/v1/dl/getContent/671294) So we can use SSE for Intel CPUs with AVX, instead of a loop with LOCK CMPXCHG16B. AMD has no such guarantee (at least for now), so we still need LOCK CMPXCHG16B on old Intel CPUs and (old or new) AMD CPUs.
[Bug lto/100010] [9/10/11/12 Regression] ICE in lto_output_node, at lto-cgraph.c:447 (-fdevirtualize-at-ltrans) since r6-6384-gceda2c69d5219719
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100010 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #5 from Xi Ruoyao --- Also breaks building texlive-20210325 with lto.
[Bug tree-optimization/104389] [12 Regression] HUGE_VAL * 0.0 is no longer a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #9 from Xi Ruoyao --- I think I need to paste my reply in gcc-patches here as a notice: > Sorry for the trouble, but some warning here: even with this patch > applied, Python would still need to replace inf * 0.0 with nan("") or > something. Now with folding for inf * 0.0 disabled, the multiplication > will be evaluated at runtime and raise FE_INVALID, which is likely > unwanted by Python. However, raising FE_INVALID is the correct behavior > no matter if we like or dislike it...
[Bug middle-end/95115] RISC-V 64: inf/inf division optimized out, invalid operation not raised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115 --- Comment #12 from Xi Ruoyao --- Should be fixed in trunk, and gcc-10 & 11 branch.
[Bug middle-end/95115] RISC-V 64: inf/inf division optimized out, invalid operation not raised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115 --- Comment #8 from Xi Ruoyao --- This is causing Glibc test failure on every port without hardware acos/asin instruction.
[Bug libstdc++/104085] New: mips: libstdc++ ABI check compares against wrong file if GCC is configured with --with-abi=(32|64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104085 Bug ID: 104085 Summary: mips: libstdc++ ABI check compares against wrong file if GCC is configured with --with-abi=(32|64) Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang Target Milestone: --- If GCC is configured with --with-abi={anything other than n32}, the directory layout produced by -print-multi-directory will be different with the layout of libstdc++-v3/config/abi/post/mips64-linux-gnu, causing ABI check failure.
[Bug testsuite/101751] asan_test.C fails with excess error with glibc-2.34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101751 --- Comment #5 from Xi Ruoyao --- Will the patch be backported to gcc-11 branch?
[Bug bootstrap/103306] [12 Regression] parallel build hangs since r12-5234-g04c5a9 when /usr/include includes broken symbolic links
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103306 --- Comment #19 from Xi Ruoyao --- Fixed on trunk.
[Bug bootstrap/103306] [12 Regression] parallel build hangs since r12-5234-g04c5a9 when /usr/include includes broken symbolic links
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103306 Xi Ruoyao changed: What|Removed |Added CC||bkorb at gnu dot org --- Comment #17 from Xi Ruoyao --- (In reply to Zdenek Sojka from comment #16) > (In reply to Xi Ruoyao from comment #15) > > patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584815.html > > Thank you for the patch; it fixes non-bootstrap build for me. I didn't check > full bootstrap yet. > > Is there a chance to check why is there the strange behavior now, with the > abort() in fixincludes? > - parallel build hangs (eg. no "Error" or "Waiting for unfinished jobs" > message from make) > - non-parallel build succeeds (even though fixincludes aborted) I think the reason is when fixinc.sh invokes fixincl executable, it does not check if fixincl succeeds. Then if fixincl fails, it may leave the building into a inconsistent status. On my system the parallel build fails with "cannot find config.status".
[Bug bootstrap/103306] [12 Regression] parallel build hangs since r12-5234-g04c5a9 when /usr/include includes broken symbolic links
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103306 --- Comment #15 from Xi Ruoyao --- patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584815.html
[Bug bootstrap/103306] [12 Regression] parallel build hangs since r12-5234-g04c5a9 when /usr/include includes broken symbolic links
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103306 --- Comment #12 from Xi Ruoyao --- I'll make a workaround in maybe an hour... But why should a distro ship broken symlinks?
[Bug bootstrap/80047] fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80047 --- Comment #10 from Xi Ruoyao --- Fixed in trunk. I'm not sure if this should be backported.
[Bug bootstrap/80047] fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80047 --- Comment #7 from Xi Ruoyao --- New patch for PR 21823 and this one: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584164.html
[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823 --- Comment #8 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #7) > New patch, for both PR 80047 and this one. https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584164.html
[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823 --- Comment #7 from Xi Ruoyao --- New patch, for both PR 80047 and this one.
[Bug target/101922] mips: illegal instruction at -O3 with -mmsa -mloongson-mmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101922 Xi Ruoyao changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Xi Ruoyao --- Fixed in trunk.
[Bug target/101922] mips: illegal instruction at -O3 with -mmsa -mloongson-mmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101922 Xi Ruoyao changed: What|Removed |Added Keywords||patch --- Comment #3 from Xi Ruoyao --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577849.html
[Bug target/101922] mips: illegal instruction at -O3 with -mmsa -mloongson-mmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101922 --- Comment #2 from Xi Ruoyao --- A "legal" testcase w/o UB (and may have some usage in practice): typedef __INT8_TYPE__ i8; typedef __INT32_TYPE__ i32; i8 d[16]; i32 f(i32 x) { int i; for (i = 0; i < 16; i++) { __INT32_TYPE__ t = (__INT32_TYPE__) d[i] >> 31; x &= t; } return x; }
[Bug target/101922] mips: illegal instruction at -O3 with -mmsa -mloongson-mmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101922 --- Comment #1 from Xi Ruoyao --- Technically the testcase above invokes UB, but this is reduced from a file in openssl-1.1.1k.
[Bug target/101922] New: mips: illegal instruction at -O3 with -mmsa -mloongson-mmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101922 Bug ID: 101922 Summary: mips: illegal instruction at -O3 with -mmsa -mloongson-mmi Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang Target Milestone: --- $ cat test.c int x = 0x; char d[16]; void f() { int i; for (i = 0; i < 16; i++) { int t = d[i] >> 8; x &= t; } } $ ~/git-repos/gcc-test-mips/gcc/cc1 test.c -O3 -mmsa -mloongson-mmi -nostdinc $ mips64el-unknown-linux-gnu-as test.s -mmsa -mloongson-mmi -mips64r2 test.s: Assembler messages: test.s:29: Error: operand 3 out of range `srai.b $w0,$w0,8'
[Bug sanitizer/101749] gcc -static-libasan broken because libasan.a needs __cxa_guard_release in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101749 --- Comment #4 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #3) > (In reply to Richard Biener from comment #2) > > This was last changed for PR100114 > > It's very strange that the fix is only backported to GCC 10 & 9, not 11. > > I think just backporting it can resolve this issue. Wrong comment, please disregard it (or better "mark it as a spam :)
[Bug sanitizer/101749] gcc -static-libasan broken because libasan.a needs __cxa_guard_release in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101749 --- Comment #3 from Xi Ruoyao --- (In reply to Richard Biener from comment #2) > This was last changed for PR100114 It's very strange that the fix is only backported to GCC 10 & 9, not 11. I think just backporting it can resolve this issue.
[Bug testsuite/101751] New: asan_test.C fails with excess error with glibc-2.34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101751 Bug ID: 101751 Summary: asan_test.C fails with excess error with glibc-2.34 Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang Target Milestone: --- Executing on host: /sources/gcc-11.2.0/build/gcc/testsuite/g++1/../../xg++ -B/sources/gcc-11.2.0/build/gcc/testsuite/g++1/../../ /sources/gcc-11.2.0/gcc/testsuite/g++.dg/asan/asan_test.C-fsanitize=address -g -I/sources/gcc-11.2.0/gcc/testsuite/../../libsanitizer/include -fdiagnostics-plain-output -nostdinc++ -I/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/include -I/sources/gcc-11.2.0/libstdc++-v3/libsupc++ -I/sources/gcc-11.2.0/libstdc++-v3/include/backward -I/sources/gcc-11.2.0/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -std=c++11 -fsanitize=address -fno-builtin -Wall -Werror -Wno-alloc-size-larger-than -Wno-stringop-overflow -g -DASAN_UAR=0 -DASAN_HAS_EXCEPTIONS=1 -DASAN_HAS_BLACKLIST=0 -DSANITIZER_USE_DEJAGNU_GTEST=1 -lasan -lpthread -ldl -DASAN_NEEDS_SEGV=1 -DASAN_AVOID_EXPENSIVE_TESTS=1 -msse2 -D__NO_INLINE__ /sources/gcc-11.2.0/gcc/testsuite/g++.dg/asan/asan_globals_test-wrapper.cc -dumpbase "" -B/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/./libsanitizer/ -B/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/./libsanitizer/asan/ -L/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/./libsanitizer/asan/.libs -L/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -B/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -L/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -B/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/./libitm/ -L/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/./libitm/.libs -lm -o ./asan_test.exe(timeout = 300) spawn -ignore SIGHUP /sources/gcc-11.2.0/build/gcc/testsuite/g++1/../../xg++ -B/sources/gcc-11.2.0/build/gcc/testsuite/g++1/../../ /sources/gcc-11.2.0/gcc/testsuite/g++.dg/asan/asan_test.C -fsanitize=address -g -I/sources/gcc-11.2.0/gcc/testsuite/../../libsanitizer/include -fdiagnostics-plain-output -nostdinc++ -I/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/include -I/sources/gcc-11.2.0/libstdc++-v3/libsupc++ -I/sources/gcc-11.2.0/libstdc++-v3/include/backward -I/sources/gcc-11.2.0/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -std=c++11 -fsanitize=address -fno-builtin -Wall -Werror -Wno-alloc-size-larger-than -Wno-stringop-overflow -g -DASAN_UAR=0 -DASAN_HAS_EXCEPTIONS=1 -DASAN_HAS_BLACKLIST=0 -DSANITIZER_USE_DEJAGNU_GTEST=1 -lasan -lpthread -ldl -DASAN_NEEDS_SEGV=1 -DASAN_AVOID_EXPENSIVE_TESTS=1 -msse2 -D__NO_INLINE__ /sources/gcc-11.2.0/gcc/testsuite/g++.dg/asan/asan_globals_test-wrapper.cc -dumpbase -B/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/./libsanitizer/ -B/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/./libsanitizer/asan/ -L/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/./libsanitizer/asan/.libs -L/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -B/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -L/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -B/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/./libitm/ -L/sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/./libitm/.libs -lm -o ./asan_test.exe In file included from /sources/gcc-11.2.0/gcc/testsuite/g++.dg/asan/asan_test.C:15: In function 'void* TSDWorker(void*)', inlined from 'void* TSDWorker(void*)' at /sources/gcc-11.2.0/gcc/testsuite/g++.dg/asan/asan_test.cc:141:7: /sources/gcc-11.2.0/gcc/testsuite/g++.dg/asan/asan_test.cc:143:24: error: 'int pthread_setspecific(pthread_key_t, const void*)' expecting 1 byte in a region of size 0 [-Werror=stringop-overread] In file included from /sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:35, from /sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr.h:148, from /sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/atomicity.h:35, from /sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:39, from /sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/include/string:55, from /sources/gcc-11.2.0/gcc/testsuite/g++.dg/asan/asan_test_config.h:19, from /sources/gcc-11.2.0/gcc/testsuite/g++.dg/asan/asan_test_utils.h:17, from /sources/gcc-11.2.0/gcc/testsuite/g++.dg/asan/asan_test.cc:11, from /sources/gcc-
[Bug sanitizer/101749] gcc -static-libasan broken because libasan.a needs __cxa_guard_release in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101749 --- Comment #1 from Xi Ruoyao --- I guess it's fixed in trunk by something in 90e46074e6b3561ae7d8ebd205127f286cc0c6b6: @@ -166,9 +158,10 @@ bool SupportsColoredOutput(fd_t fd) { #if !SANITIZER_GO // TODO(glider): different tools may require different altstack size. static uptr GetAltStackSize() { - // SIGSTKSZ is not enough. - static const uptr kAltStackSize = SIGSTKSZ * 4; - return kAltStackSize; + // Note: since GLIBC_2.31, SIGSTKSZ may be a function call, so this may be + // more costly that you think. However GetAltStackSize is only call 2-3 times + // per thread so don't cache the evaluation. + return SIGSTKSZ * 4; } Not tested though.
[Bug sanitizer/101749] New: gcc -static-libasan broken because libasan.a needs __cxa_guard_release in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101749 Bug ID: 101749 Summary: gcc -static-libasan broken because libasan.a needs __cxa_guard_release in libstdc++ Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Test summary: FAIL: c-c++-common/asan/pr59063-2.c -O0 (test for excess errors) UNRESOLVED: c-c++-common/asan/pr59063-2.c -O0 compilation failed to produce executable FAIL: c-c++-common/asan/pr59063-2.c -O1 (test for excess errors) UNRESOLVED: c-c++-common/asan/pr59063-2.c -O1 compilation failed to produce executable FAIL: c-c++-common/asan/pr59063-2.c -O2 (test for excess errors) UNRESOLVED: c-c++-common/asan/pr59063-2.c -O2 compilation failed to produce executable FAIL: c-c++-common/asan/pr59063-2.c -O3 -g (test for excess errors) UNRESOLVED: c-c++-common/asan/pr59063-2.c -O3 -g compilation failed to produce executable FAIL: c-c++-common/asan/pr59063-2.c -Os (test for excess errors) UNRESOLVED: c-c++-common/asan/pr59063-2.c -Os compilation failed to produce executable FAIL: c-c++-common/asan/pr59063-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) UNRESOLVED: c-c++-common/asan/pr59063-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none compilation failed to produce executable FAIL: c-c++-common/asan/pr59063-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) UNRESOLVED: c-c++-common/asan/pr59063-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects compilation failed to produce executable $ cc dummy.c -fsanitize=address -static-libasan /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib/libasan.a(sanitizer_posix_libcdep.o): in function `__sanitizer::SetAlternateSignalStack()': /sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/libsanitizer/sanitizer_common/../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:170: undefined reference to `__cxa_guard_acquire' /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib/libasan.a(sanitizer_posix_libcdep.o): in function `GetAltStackSize': /sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/libsanitizer/sanitizer_common/../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:170: undefined reference to `__cxa_guard_release' /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib/libasan.a(sanitizer_posix_libcdep.o): in function `__sanitizer::UnsetAlternateSignalStack()': /sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/libsanitizer/sanitizer_common/../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:170: undefined reference to `__cxa_guard_acquire' /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib/libasan.a(sanitizer_posix_libcdep.o): in function `GetAltStackSize': /sources/gcc-11.2.0/build/x86_64-pc-linux-gnu/libsanitizer/sanitizer_common/../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:170: undefined reference to `__cxa_guard_release' collect2: error: ld returned 1 exit status Not sure if this is because something has changed in glibc-2.34.
[Bug target/101132] [11/12 regression] [MIPS/MSA] internal compiler error: in do_store_flag, at expr.c:12541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101132 Xi Ruoyao changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Xi Ruoyao --- Fixed for trunk and releases/gcc-11.
[Bug ipa/101396] [12 Regression] ICE in decompose, at wide-int.h:984 with -flto and incompatible enum class definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101396 Xi Ruoyao changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Known to work||11.2.0 --- Comment #5 from Xi Ruoyao --- Fixed in trunk.
[Bug target/101593] New: mips: operands missing mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101593 Bug ID: 101593 Summary: mips: operands missing mode Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang Target Milestone: --- ../../gcc/gcc/config/mips/mips.md:5610:1: warning: source missing a mode? ../../gcc/gcc/config/mips/mips.md:5610:1: warning: source missing a mode? ../../gcc/gcc/config/mips/mips.md:6923:1: warning: operand 0 missing mode? ../../gcc/gcc/config/mips/mips.md:6943:1: warning: operand 1 missing mode? ../../gcc/gcc/config/mips/mips.md:6952:1: warning: operand 1 missing mode? ../../gcc/gcc/config/mips/mips.md:7011:1: warning: operand 0 missing mode? ../../gcc/gcc/config/mips/mips.md:7028:1: warning: operand 0 missing mode? ../../gcc/gcc/config/mips/mips.md:7085:1: warning: operand 1 missing mode? ../../gcc/gcc/config/mips/mips.md:7105:1: warning: operand 1 missing mode? ../../gcc/gcc/config/mips/mips.md:7151:1: warning: operand 1 missing mode? ../../gcc/gcc/config/mips/mips.md:7174:1: warning: operand 1 missing mode? ../../gcc/gcc/config/mips/mips.md:7457:1: warning: operand 0 missing mode? ../../gcc/gcc/config/mips/mips.md:7470:1: warning: operand 0 missing mode? ../../gcc/gcc/config/mips/mips-msa.md:2488:1: warning: operand 2 missing mode? ../../gcc/gcc/config/mips/mips-msa.md:2488:1: warning: operand 2 missing mode? ../../gcc/gcc/config/mips/mips-msa.md:2488:1: warning: operand 2 missing mode? ../../gcc/gcc/config/mips/mips-msa.md:2488:1: warning: operand 2 missing mode?
[Bug tree-optimization/101110] [12 regression] gcc.c-torture/execute/950704-1.c fails after r12-1546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101110 --- Comment #5 from Xi Ruoyao --- (In reply to Andrew Macleod from comment #4) > Does this still fail? When i look at a cross compiler listing I do not see > any differences from ranger in the listing. Should be fixed at d48320083c9a2bdf0ddac693f9d523755b8b29ec. Sorry for forgetting to mention the PR number in the commit.
[Bug ipa/97565] -flto -ipa-pta ICE: at cgraph_node::get_untransformed_body()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97565 --- Comment #4 from Xi Ruoyao --- This issue still exists in trunk. "-fno-builtin-abort" can be used as a workaround for SpiderMonkey though. Any progress?
[Bug ipa/101396] [12 Regression] ICE in decompose, at wide-int.h:984 with -flto and incompatible enum class definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101396 --- Comment #3 from Xi Ruoyao --- Patch sent to gcc-patches: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574890.html
[Bug ipa/101396] [12 Regression] ICE in decompose, at wide-int.h:984 with -flto and incompatible enum class definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101396 --- Comment #2 from Xi Ruoyao --- Created attachment 51128 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51128=edit proposed patch Patch proposed. Will bootstrap & regtest to make sure it correct.
[Bug ipa/101396] [12 Regression] ICE in decompose, at wide-int.h:984 building webkitgtk-2.32.2 with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101396 --- Comment #1 from Xi Ruoyao --- Testcase: $ cat a.cpp enum class A : __INT32_TYPE__ { a, b, c }; int main() { return (int) A::a; } $ cat b.cpp enum class A : __UINT64_TYPE__ { a, b, c }; int f(enum A x) { return (int) x; } $ ~/gcc-trunk/bin/g++ a.cpp b.cpp -flto during IPA pass: odr lto1: internal compiler error: in decompose, at wide-int.h:984
[Bug ipa/101396] New: ICE in decompose, at wide-int.h:984 building webkitgtk-2.32.2 with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101396 Bug ID: 101396 Summary: ICE in decompose, at wide-int.h:984 building webkitgtk-2.32.2 with -flto -fipa-pta Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang CC: marxin at gcc dot gnu.org Target Milestone: --- during IPA pass: odr lto1: internal compiler error: in decompose, at wide-int.h:984 0xafd9a6 wi::int_traits >::decompose(long*, unsigned int, generic_wide_int const&) ../../gcc/gcc/wide-int.h:984 0xafd5a2 wide_int_ref_storage::wide_int_ref_storage >(generic_wide_int const&, unsigned int) ../../gcc/gcc/wide-int.h:1034 0xafb82c generic_wide_int >::generic_wide_int >(generic_wide_int const&, unsigned int) ../../gcc/gcc/wide-int.h:790 0xafb728 bool wi::eq_p, generic_wide_int >(generic_wide_int const&, generic_wide_int const&) ../../gcc/gcc/wide-int.h:1857 0xd52726 bool wi::ne_p, generic_wide_int >(generic_wide_int const&, generic_wide_int const&) ../../gcc/gcc/wide-int.h:1894 0xd4fbc4 wi::binary_traits, generic_wide_int, wi::int_traits >::precision_type, wi::int_traits >::precision_type>::predicate_result operator!=, generic_wide_int >(generic_wide_int const&, generic_wide_int const&) ../../gcc/gcc/wide-int.h:3292 0xe86fa2 ipa_odr_read_section ../../gcc/gcc/ipa-devirt.c:4196 0xe87554 ipa_odr_summary_read ../../gcc/gcc/ipa-devirt.c:4310 0x10a5d5d ipa_read_summaries_1 ../../gcc/gcc/passes.c:2904 0x10a5dfe ipa_read_summaries() ../../gcc/gcc/passes.c:2929 0xa9d964 read_cgraph_and_symbols(unsigned int, char const**) ../../gcc/gcc/lto/lto-common.c:2919 0xa72c70 lto_main() ../../gcc/gcc/lto/lto.c:625 I'll do more investigation and attempt to make a testcase tomorrow.
[Bug libstdc++/71367] std::time_get does not implement 'r' or 'p'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71367 --- Comment #7 from Xi Ruoyao --- Any progress on this (after two years? :)
[Bug other/91085] fixincludes breaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085 --- Comment #17 from Xi Ruoyao --- Revised patch, matching __has_include(...): https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573789.html
[Bug other/91085] fixincludes breaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085 --- Comment #16 from Xi Ruoyao --- (In reply to Bruce Korb from comment #15) > Obviously, "print_quote()" was needed early on (1999) and then saved for > prosperity :). Your patch is inadequate because it will have to not expand > 'linux' in a line such as: > > #if __has_include() > > In other words, it will have to skip over three flavors of quote. Or just > two, if you omit apostrophe quotes. In any event, the '<' character will > have to be matched with '>', which is a tiny change to the logic. > > Don't forget to add tests in the final result. Simply skipping <...> can be problematic for something like: #if A < B && i386 && C > D #define USE_I386_WORKAROUND #endif
[Bug other/91085] fixincludes breaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #13 from Xi Ruoyao --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573676.html
[Bug target/94780] [8/9 Regression] ICE in walk_body at gcc/tree-nested.c:713 since r6-3632-gf6f69fb09c5f81df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94780 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #11 from Xi Ruoyao --- It's still not fixed on mips after one year :(. Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573464.html
[Bug target/101132] [11/12 regression] [MIPS/MSA] internal compiler error: in do_store_flag, at expr.c:12541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101132 Xi Ruoyao changed: What|Removed |Added Keywords||patch --- Comment #8 from Xi Ruoyao --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573312.html
[Bug target/101132] [11/12 regression] [MIPS/MSA] internal compiler error: in do_store_flag, at expr.c:12541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101132 --- Comment #6 from Xi Ruoyao --- I'm attempting to fix it by adding vec_cmp and vec_cmpu expand into mips-msa.md. Bootstrapped on mips64el-linux-gnu and regtest is running.
[Bug tree-optimization/101110] [12 regression] gcc.c-torture/execute/950704-1.c fails after r12-1546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101110 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #3 from Xi Ruoyao --- (In reply to Andrew Macleod from comment #2) > I think the patch for PR 101014 resolves this testcase... Let me know if > this is fixed on trunk now. This is still failing on mips64el. And there is really an UB (signed overflow) in the test: 950704-1.c:9:5: runtime error: signed integer overflow: -9223372036854775808 + -9223372036854775808 cannot be represented in type 'long long int' maybe we should add -fwrapv for this test.
[Bug target/101132] [11/12 regression] [MIPS/MSA] internal compiler error: in do_store_flag, at expr.c:12541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101132 --- Comment #4 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #3) > Another testcase (produced by cvise from mesa-21.1.3): Flag: -O3 -mmsa -fno-trapping-math
[Bug target/101132] [11/12 regression] [MIPS/MSA] internal compiler error: in do_store_flag, at expr.c:12541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101132 --- Comment #3 from Xi Ruoyao --- Another testcase (produced by cvise from mesa-21.1.3): unsigned float3_to_rgb9e5_gc_0; util_format_r9g9b9e5_float_pack_rgba_float_dst_row_bc_0; util_format_r9g9b9e5_float_pack_rgba_float_dst_row() { unsigned x; char *dst = util_format_r9g9b9e5_float_pack_rgba_float_dst_row; for (; x; x += 1) { int __trans_tmp_1, maxrgb_0; struct { unsigned u } f, max; if (f.u > 80) __trans_tmp_1 = 0; else __trans_tmp_1 = max.u; maxrgb_0 = __trans_tmp_1 > float3_to_rgb9e5_gc_0 ?: util_format_r9g9b9e5_float_pack_rgba_float_dst_row_bc_0; *dst = maxrgb_0; dst += 4; } }
[Bug target/101132] [11/12 regression] [MIPS/MSA] internal compiler error: in do_store_flag, at expr.c:12541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101132 Xi Ruoyao changed: What|Removed |Added Component|middle-end |target --- Comment #2 from Xi Ruoyao --- This seems mips specific.
[Bug middle-end/101132] [11/12 regression] [MIPS/MSA] internal compiler error: in do_store_flag, at expr.c:12541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101132 --- Comment #1 from Xi Ruoyao --- Forgot to mention: the flags triggering the ICE is -O3 -mmsa.
[Bug middle-end/101132] New: [11/12 regression] [MIPS/MSA] internal compiler error: in do_store_flag, at expr.c:12541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101132 Bug ID: 101132 Summary: [11/12 regression] [MIPS/MSA] internal compiler error: in do_store_flag, at expr.c:12541 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang Target Milestone: --- Reproducer: int r_0, q_0; void bar() { int i; for (i = 0; i < 96; i++) { r_0 = i << i ? 2 + i : -i; q_0 = r_0 > 2 ?: i; } } Error message: testcase.i: In function ‘bar’: testcase.i:2:6: internal compiler error: in do_store_flag, at expr.c:12541 2 | void bar() { | ^~~ 0xdacde9 do_store_flag ../../gcc/gcc/expr.c:12541 0xd9fecd expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ../../gcc/gcc/expr.c:9859 0xda2748 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:10409 0xd9aa61 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:8642 0xf0da1a expand_normal ../../gcc/gcc/expr.h:307 0xf18702 expand_vec_cond_optab_fn ../../gcc/gcc/internal-fn.c:2802 0xf1d85e expand_VCOND ../../gcc/gcc/internal-fn.def:143 0xf1f330 expand_internal_call(internal_fn, gcall*) ../../gcc/gcc/internal-fn.c:4093 0xf1f35b expand_internal_call(gcall*) ../../gcc/gcc/internal-fn.c:4101 0xbf2f30 expand_call_stmt ../../gcc/gcc/cfgexpand.c:2752 0xbf6fcf expand_gimple_stmt_1 ../../gcc/gcc/cfgexpand.c:3850 0xbf7659 expand_gimple_stmt ../../gcc/gcc/cfgexpand.c:4014 0xbff943 expand_gimple_basic_block ../../gcc/gcc/cfgexpand.c:6056 0xc01bea execute ../../gcc/gcc/cfgexpand.c:6782 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. It looks very similar to PR95830, but I'm not sure if they are really related.
[Bug target/100760] [mips + msa] ICE: maximum number of generated reload insns per insn achieved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100760 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #1 from Xi Ruoyao --- Patch proposed: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573213.html
[Bug target/100761] [mips+msa] ICE when using __builtin_convertvector to convert from u8x8 to u8x16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100761 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #1 from Xi Ruoyao --- Patch proposed: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573213.html
[Bug target/100762] [mips+msa] ICE when comparing 64 bit vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100762 --- Comment #4 from Xi Ruoyao --- Patch proposed: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573213.html
[Bug target/100762] [mips+msa] ICE when comparing 64 bit vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100762 --- Comment #3 from Xi Ruoyao --- There is some strange interaction between -mmsa and -mloongson-mmi causing this. It can be reproduced by building pixman (which enables -mloongson-mmi by default) with -mmsa.
[Bug target/100762] [mips+msa] ICE when comparing 64 bit vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100762 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #2 from Xi Ruoyao --- 11.1.0 also ICE with this case.
[Bug c++/77443] Empty initializer on huge object array member slow down the compilation dramatically with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77443 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #2 from Xi Ruoyao --- *** Bug 100466 has been marked as a duplicate of this bug. ***
[Bug c++/100466] compilation of assignment from initialization list to an object with array member T[N] and non-trivial constructor of T is very slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100466 Xi Ruoyao changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Xi Ruoyao --- Alright, there is PR77443 and PR84281. But the "fix" to PR84281 only fixed the memory issue, the compile time is still too excessive. I'll mark it as a dup of PR77443. *** This bug has been marked as a duplicate of bug 77443 ***
[Bug c++/100466] compilation of assignment from initialization list to an object with array member T[N] and non-trivial constructor of T is very slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100466 Xi Ruoyao changed: What|Removed |Added Component|libstdc++ |c++ Summary|compilation of assignment |compilation of assignment |from initialization list to |from initialization list to |std::array with |an object with array member |non-trivial constructor of |T[N] and non-trivial |T is very slow |constructor of T is very ||slow --- Comment #4 from Xi Ruoyao --- (In reply to Richard Biener from comment #3) > I think that's an old known C++ FE issue which should emit a loop for inits > instead of repeating assignments for each element. Change summary and component then. Is this a dup? I tried to search an existing PR but couldn't find it.
[Bug libstdc++/100466] compilation of assignment from initialization list to std::array with non-trivial constructor of T is very slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100466 Xi Ruoyao changed: What|Removed |Added Version|11.1.0 |12.0 Known to fail||10.3.0, 11.1.0, 12.0, ||8.3.0, 9.3.0 --- Comment #2 from Xi Ruoyao --- Updated version, based on the test result on godbolt.
[Bug libstdc++/100466] compilation of assignment from initialization list to std::array with non-trivial constructor of T is very slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100466 --- Comment #1 from Xi Ruoyao --- clang-12 handles this correctly.
[Bug libstdc++/100466] New: compilation of assignment from initialization list to std::array with non-trivial constructor of T is very slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100466 Bug ID: 100466 Summary: compilation of assignment from initialization list to std::array with non-trivial constructor of T is very slow Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang Target Milestone: --- Code: #include struct t { int a; t() : a(0) {} }; std::array g; int main() { g = {}; } $ for i in 10 100 1000 1 10; do > time g++ t.cc -DX=$i > done g++ t.cc -DX=$i 0.74s user 0.06s system 99% cpu 0.798 total g++ t.cc -DX=$i 0.74s user 0.05s system 99% cpu 0.794 total g++ t.cc -DX=$i 0.78s user 0.06s system 99% cpu 0.833 total g++ t.cc -DX=$i 1.08s user 0.08s system 99% cpu 1.167 total g++ t.cc -DX=$i 4.55s user 0.25s system 99% cpu 4.809 total With -O2, it's much worse: $ for i in 10 100 1000 1 10; do > time g++ t.cc -DX=$i -O2 > done g++ t.cc -DX=$i -O2 0.07s user 0.01s system 99% cpu 0.089 total g++ t.cc -DX=$i -O2 0.08s user 0.01s system 99% cpu 0.087 total g++ t.cc -DX=$i -O2 0.49s user 0.01s system 99% cpu 0.503 total g++ t.cc -DX=$i -O2 6.34s user 0.03s system 99% cpu 6.376 total g++ t.cc -DX=$i -O2 68.91s user 0.18s system 99% cpu 1:09.09 total And the resulted code seems "unrolling a loop" too excessively: 401040: 48 c7 05 95 aa 0e 00movq $0x0,0xeaa95(%rip)# 4ebae0 401047: 00 00 00 00 40104b: 31 c0 xor%eax,%eax 40104d: 48 c7 05 90 aa 0e 00movq $0x0,0xeaa90(%rip)# 4ebae8 401054: 00 00 00 00 401058: 48 c7 05 8d aa 0e 00movq $0x0,0xeaa8d(%rip)# 4ebaf0 40105f: 00 00 00 00 401063: 48 c7 05 8a aa 0e 00movq $0x0,0xeaa8a(%rip)# 4ebaf8 40106a: 00 00 00 00 ... ... 4874a7: 48 c7 05 a6 60 0c 00movq $0x0,0xc60a6(%rip)# 54d558 4874ae: 00 00 00 00
[Bug c++/52830] ICE: "canonical types differ for identical types ..." when attempting SFINAE with member type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #13 from Xi Ruoyao --- According to recent test results (for e.g., https://gcc.gnu.org/pipermail/gcc-testresults/2021-April/685744.html), it's no longer ice-on-valid-code, but reject-valid-code now.
[Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #24 from Xi Ruoyao --- (In reply to Richard Biener from comment #22) > There is target specific sanitizing of symbol names - if the name is really > the issue then it should be _much_ more prevalent since all IPA cloning uses > dots as well. clone_function_name produces them and ASM_FORMAT_PRIVATE_NAME > is the "sanitizer" that's supposed to mangle it to correct form. But as the > name suggests the definition of a local private symbol isn't supposed to go > away without all of its uses so the real issue must be elsewhere in > optimization. > (thus asking for IPA dumps, specifically the .000i.cgraph dump which should > mention when the compiler thinks the .LTHUNK5.lto_priv.0 goes away) IPA dumps (along with .ltrans* files) are uploaded: https://bf.mengyan1223.wang/assets/gcc-97787/libsass_lto_ipa_dump.tar.xz
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #21 from Xi Ruoyao --- (In reply to Richard Biener from comment #20) > Indeed already the name, .LTHUNK5.lto_priv.0, hints at that this should be a > local symbol. Not sure why we end up with a .reloc then. > > ld $25,%got_disp(.LTHUNK5.lto_priv.0)($28) > .LEHB26 = . > .reloc 1f,R_MIPS_JALR,.LTHUNK5.lto_priv.0 > 1: jalr$25 > > this seems to be in _ZN4Sass6Parser16parse_parametersEv > > Maybe it's possible to reduce the testcase by bisecting the object files > necessary to produce the bogus LTRANS assembly? From that one can start > reducing the source of the necessary object files. > > Another interesting bit would be to see the IPA dumps of the broken LTRANS > unit. If you add -fdump-ipa-all-details to the link command you should get > dump files alongside the ltrans temp files. I can confirm that the workaround in gas (released in binutils-2.36) "fixes" the problem. Some function aliases named ".LTHUNK%d" are created in C++ FE (cp/method.c, L232). With LTO those are cloned as ".LTHUNK%d.lto_priv.%d". Functions aliases should not be named ".xxx" IMO. Perhaps names like __gcc_lthunk.%d is better.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #19 from Xi Ruoyao --- gas has added a workaround. I'll test it tomorrow.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #18 from Xi Ruoyao --- Oh no. Now I think it's GCC side. According to gas doc https://sourceware.org/binutils/docs/as/Symbol-Names.html#Symbol-Names .LTHUNK5.lto_priv.0 should be a local label. But in our LTO output, this label is defined in libsass.so.1.0.0.ltrans1.s and used in other ltrans files.