> On Wed, 2019-12-18 at 10:26 +0100, Jan Hubicka wrote:
> > Hi,
> > sorry I forgot to include cgraph and varpool changes in the patch.
> >
> > Index: varpool.c
> > ===
> > --- varpool.c (revision 279467)
> > +++ varpool.c
On Wed, 2019-12-18 at 10:26 +0100, Jan Hubicka wrote:
> Hi,
> sorry I forgot to include cgraph and varpool changes in the patch.
>
> Index: varpool.c
> ===
> --- varpool.c (revision 279467)
> +++ varpool.c (working copy)
> @@ -539,8 +
> On 2019-12-19 19:12 +0800, Xi Ruoyao wrote:
> > On 2019-12-19 11:06 +0100, Jan Hubicka wrote:
> > > - /* See if we have linker information about symbol not being used or
> > > - if we need to make guess based on the declaration.
> > > + /* Limitation of gas requires us to output targets of
On 2019-12-19 19:12 +0800, Xi Ruoyao wrote:
> On 2019-12-19 11:06 +0100, Jan Hubicka wrote:
> > - /* See if we have linker information about symbol not being used or
> > - if we need to make guess based on the declaration.
> > + /* Limitation of gas requires us to output targets of symver ali
On 2019-12-19 11:06 +0100, Jan Hubicka wrote:
> This is variant of your patch I comitted. It also adds verification so
> we get ICE rather then wrong code. In addition I moved the checks away
> rom used_from_object_file. This function is about non-LTO objects
> linked into the DSO and thus does n
> On 2019-12-18 14:19 +0100, Jan Hubicka wrote:
> > The problem here is that we lie to the compiler (by pretending that
> > foo_v2 is exported from DSO while it is not) and force user to do the
> > same.
> >
> > We support two ways to hide symbol - either at compile time via
> > attribute((visibil
On 2019-12-18 14:19 +0100, Jan Hubicka wrote:
> The problem here is that we lie to the compiler (by pretending that
> foo_v2 is exported from DSO while it is not) and force user to do the
> same.
>
> We support two ways to hide symbol - either at compile time via
> attribute((visibility("hidden"))
On 2019-12-18 14:19 +0100, Jan Hubicka wrote:
> > ICE here.
> >
> > lto1: internal compiler error: tree check: expected identifier_node, have
> > function_decl in ultimate_transparent_alias_target, at varasm.c:1308
> > 0x6f9cfe tree_check_failed(tree_node const*, char const*, int, char const*,
> >
> ICE here.
>
> lto1: internal compiler error: tree check: expected identifier_node, have
> function_decl in ultimate_transparent_alias_target, at varasm.c:1308
> 0x6f9cfe tree_check_failed(tree_node const*, char const*, int, char const*,
> ...)
> ../../gcc/gcc/tree.c:9685
> 0x714541 tree_c
On 2019-12-18 10:26 +0100, Jan Hubicka wrote:
> Hi,
> sorry I forgot to include cgraph and varpool changes in the patch.
>
> Index: varpool.c
> ===
> --- varpool.c (revision 279467)
> +++ varpool.c (working copy)
> @@ -539,8 +539,7 @@
Hi,
sorry I forgot to include cgraph and varpool changes in the patch.
Index: varpool.c
===
--- varpool.c (revision 279467)
+++ varpool.c (working copy)
@@ -539,8 +539,7 @@ varpool_node::assemble_aliases (void)
{
varpo
On 2019-12-17 18:47 +0100, Jan Hubicka wrote:
> > Would it be equivalent to:
> > 1) output foo_v2 local
> > 2) producing static alias with local name (.L1)
> > 3) do .symver .L1,foo@@@VERS_2
> > That is somewhat more systematic and would not lead to false
> > visibilities.
>
> I spent some time pl
> Would it be equivalent to:
> 1) output foo_v2 local
> 2) producing static alias with local name (.L1)
> 3) do .symver .L1,foo@@@VERS_2
> That is somewhat more systematic and would not lead to false
> visibilities.
I spent some time playing with this. An in order to
1) be able to handle foo_v2
> Hi Jan,
>
> I'm using GNU ld 2.33.1.
>
> I'll attach a testcase simplified from fuse-3.9 code. "local: *;" in the
> versioning script triggers the issue. Without it there would be no problem.
Thanks.
You are right that I did not play with local:. Now I wonder what is the
intended behaviour h
On 2019-12-17 09:32 +0100, Jan Hubicka wrote:
> > Hi,
> > with Jan's patch commited in r278878 we can use symver attribute for
> > functions
> > and variables. The symver attribute is designed for replacing toplevel asm
> > statements containing ".symver" which may be removed by LTO. Unfortunatel
> Hi,
> with Jan's patch commited in r278878 we can use symver attribute for functions
> and variables. The symver attribute is designed for replacing toplevel asm
> statements containing ".symver" which may be removed by LTO. Unfortunately,
> a quick test shown GCC still generates buggy so file
16 matches
Mail list logo
