[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
[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
[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
[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
[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.
