[Bug lto/83375] partitioner partitions static arrays with label references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Andrew Pinski --- Dup of bug 50676. *** This bug has been marked as a duplicate of bug 50676 ***
[Bug lto/83375] partitioner partitions static arrays with label references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375 --- Comment #9 from andi at firstfloor dot org --- It's in kernel/bpf/core.c It won't happen every time on a build unless you force 1on1 partitioning.
[Bug lto/83375] partitioner partitions static arrays with label references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375 --- Comment #8 from Jan Hubicka --- > > 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
[Bug lto/83375] partitioner partitions static arrays with label references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #7 from Martin Liška --- (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.
[Bug lto/83375] partitioner partitions static arrays with label references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375 --- Comment #6 from Andi Kleen --- 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.
[Bug lto/83375] partitioner partitions static arrays with label references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375 Martin Liška changed: What|Removed |Added Target Milestone|9.0 |--- --- Comment #5 from Martin Liška --- I consider label refs not so common for LTO, thus deferring for now...
[Bug lto/83375] partitioner partitions static arrays with label references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|--- |9.0 --- Comment #4 from Martin Liška --- So Honza is suggesting to introduce IPA_REF_LABEL_ADDR and then do proper LTO partitioning. Let me do this for GCC 9.
[Bug lto/83375] partitioner partitions static arrays with label references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375 --- Comment #3 from Martin Liška --- > 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?
[Bug lto/83375] partitioner partitions static arrays with label references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-12-18 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, let me take a look.
[Bug lto/83375] partitioner partitions static arrays with label references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375 --- Comment #1 from Andi Kleen --- Actually -flto-partition=max
