[Bug lto/61635] LTO partitioner does not handle &&label in statics

["andi at firstfloor dot org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61635

--- Comment #2 from andi at firstfloor dot org ---
Test case

git clone https://github.com/andikleen/linux-misc -b lto-linus-3.15
Build with the attached kernel config (copy to .config in the build dir) and
4.9

-Andi

On Fri, Jun 27, 2014 at 11:04:00PM +0000, hubicka at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61635
> 
> Jan Hubicka <hubicka at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |ASSIGNED
>    Last reconfirmed|                            |2014-06-27
>                  CC|                            |hubicka at gcc dot gnu.org
>            Assignee|unassigned at gcc dot gnu.org      |hubicka at gcc dot gnu.org
>      Ever confirmed|0                           |1
> 
> --- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> Yep, this is a known problem. We do not represent labels in symbol table and
> thus LTO partitioner has no clue about them. I would be interested to see the
> example that fails - theoretically the problematic static variable should
> always end up in the same partition as the function using it, because that
> function is no inline and no clone and should not get duplicated. So kernel &
> friends should fail only with -flto-partition=1to1 not with ballanced/none/one
> algorithms.
> 
> I plan correct solution - I already implemented labels for symtab some time ago
> but I would like to re-do it on the new API.
> The poor-man's class hiearchy in C was not very pretty and a lot of code is
> still not updated to nots assume two basic types of symbols (variables and
> functions). With Martin Liska we are updating the APIs and once it is done I
> will add symbols for non-local labels and const_decls.
> 
> -- 
> You are receiving this mail because:
> You reported the bug.
>