Created attachment 42842 [details] test case I thought there was already a bug for this, but can't find it right now. When &&labels are put into static arrays the LTO partitioner can put the static into a different partition, which causes an assembler error because the code labels are local. This breaks Linux kernel LTO builds. See attached test case. I think ipa-comdats should put the function and the static into the same partition, but for some reason it doesn't work. Attached test case shows the problem with -flto-partition=1to1 -flto -O2
Actually -flto-partition=max
Confirmed, let me take a look.
> I thought there was already a bug for this, but can't find it right now. > You maybe confused that with the issue abould global asm statements that go to a random partition and cause issues with LTO? In this case, it's not work for IPA comdat, because this is pure C code. cgraph situation: f/2 (f) @0x7ff1b1d73000 Type: function definition analyzed Visibility: externally_visible prevailing_def_ironly public References: data.1957/4 (read)x/0 (read)x/0 (write)y/1 (read)y/1 (write)x/0 (read)x/0 (write)y/1 (read)y/1 (write) Referring: Read from file: /tmp/ccRhP0dr.o First run: 0 Function flags: count: 1073741826 (estimated locally) Called by: main/3 (1073741825 (estimated locally),1.00 per call) Calls: data.1957/4 (data) @0x7ff1b1d71200 Type: variable definition analyzed Visibility: prevailing_def_ironly References: Referring: f/2 (read) Read from file: /tmp/ccRhP0dr.o Availability: not-ready Varpool flags: initialized I suggest to extend LTO partitioning to find all functions with a computed goto. And for these, put simply all static variables into a same partition. I expect computed goto as quite rare feature. More fine approach would be to investigate DECL_INITIAL for LABELs. Honza what do you think?
So Honza is suggesting to introduce IPA_REF_LABEL_ADDR and then do proper LTO partitioning. Let me do this for GCC 9.
I consider label refs not so common for LTO, thus deferring for now...
This breaks Linux kernel LTO builds. I currently have a workaround (disabling LTO for that file), but I don't think your "is not common" argument is valid.
(In reply to Andi Kleen from comment #6) > This breaks Linux kernel LTO builds. I currently have a workaround > (disabling LTO for that file), but I don't think your "is not common" > argument is valid. Well, I guess pushing LTO into Linux kernel would be difficult task to achieve. Can you please point me to a source file where it's used? Note that I did experiments with openSUSE distribution and I haven't seen it for any core package when using -flto.
> > This breaks Linux kernel LTO builds. I currently have a workaround > > (disabling LTO for that file), but I don't think your "is not common" > > argument is valid. > > Well, I guess pushing LTO into Linux kernel would be difficult task to achieve. > Can you please point me to a source file where it's used? > Note that I did experiments with openSUSE distribution and I haven't seen it > for any core package when using -flto. In most cases we get lucky as we home variables into same partition as function, so the issue does not trigger that often. Still will try to find time to fix it this stage1. Honza
It's in kernel/bpf/core.c It won't happen every time on a build unless you force 1on1 partitioning.
Dup of bug 50676. *** This bug has been marked as a duplicate of bug 50676 ***