https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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
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
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
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 ?
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096
Xi Ruoyao changed:
What|Removed |Added
Build|loongarch64-linux-gnu |
Summary|[13 regression] ICE
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.
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
:).
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
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.
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
>
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
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:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106088
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104461
Xi Ruoyao changed:
What|Removed |Added
CC||jwakely.gcc at gmail dot com,
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?
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
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
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
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...
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
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).
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104851
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104842
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104843
Xi Ruoyao changed:
What|Removed |Added
Target||mips
Blocks|
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104817
Xi Ruoyao changed:
What|Removed |Added
Target||mips64
Known to fail|
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
Xi Ruoyao changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100010
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment
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.
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.
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101751
--- Comment #5 from Xi Ruoyao ---
Will the patch be backported to gcc-11 branch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103306
--- Comment #19 from Xi Ruoyao ---
Fixed on trunk.
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
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
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?
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.
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823
--- Comment #7 from Xi Ruoyao ---
New patch, for both PR 80047 and this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101922
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101922
Xi Ruoyao changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Xi Ruoyao ---
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 =
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.
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
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
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.
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101132
Xi Ruoyao changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101396
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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
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
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?
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
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.
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,
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71367
--- Comment #7 from Xi Ruoyao ---
Any progress on this (after two years? :)
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94780
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101132
Xi Ruoyao changed:
What|Removed |Added
Keywords||patch
--- Comment #8 from Xi Ruoyao ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101110
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment
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
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
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 ---
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100760
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100761
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100762
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77443
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100466
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100466
Xi Ruoyao changed:
What|Removed |Added
Component|libstdc++ |c++
Summary|compilation of
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|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100466
--- Comment #1 from Xi Ruoyao ---
clang-12 handles this correctly.
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment
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
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
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.
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
1 - 100 of 110 matches
Mail list logo
