> 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
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 with LTO a
17 matches
Mail list logo
