--00000000000007bb54056e240cc4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I regularly the go through the situation where a function might be
considered dead code due to LTO, but the functions are actually used by
dynamic loading, so I end up adding an __attribute(used) or alike in a
toolchain-dependant macro.

Since there is already a [[maybe_unused]], I'd like to get feedback about a
[[used]] function- (and possibly symbol- ) level attribute to prevent link
optimizers to remove them.

--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-3%3DXHDyFw1rt%3Dg9oYn4U6fHvAfgkpaOWWZfVhB=
bM8SfXg%40mail.gmail.com.

--00000000000007bb54056e240cc4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I regularly the go through the situation where a function =
might be considered dead code due to LTO, but the functions are actually us=
ed by dynamic loading, so I end up adding an __attribute(used) or alike in =
a toolchain-dependant macro.<div><br></div><div>Since there is already a [[=
maybe_unused]], I&#39;d like to get feedback about a [[used]] function- (an=
d possibly symbol- ) level attribute to prevent link optimizers to remove t=
hem.<br><div><div><br>-- <br><div class=3D"gmail_signature" data-smartmail=
=3D"gmail_signature">Who=E2=80=99s got the sweetest disposition?<br>One gue=
ss, that=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argument?<br>=
Who never shows a bit of temperament?<br>Who&#39;s never wrong but always r=
ight?<br>Who&#39;d never dream of starting a fight?<br>Who get stuck with a=
ll the bad luck? </div>
</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3%3DXHDyFw1rt%3Dg9oYn4U6fHvAfg=
kpaOWWZfVhBbM8SfXg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3%3DXH=
DyFw1rt%3Dg9oYn4U6fHvAfgkpaOWWZfVhBbM8SfXg%40mail.gmail.com</a>.<br />

--00000000000007bb54056e240cc4--

.

On Friday, 8 June 2018 12:39:42 EDT dgutson . wrote:
> I regularly the go through the situation where a function might be
> considered dead code due to LTO, but the functions are actually used by
> dynamic loading, so I end up adding an __attribute(used) or alike in a
> toolchain-dependant macro.

LTO cannot remove a function in a library if it is globally visible. LTO is
not the same as -fwhole-program, where the compiler (including during LTO) can
see the  -- as the name says -- the whole program.

So are you sure the function is being removed and you're creating a library?

Or are you creating the application? If so, does -fno-whole-program help
during the LTO phase? Maybe use -fPIC instead of -fPIE.

> Since there is already a [[maybe_unused]], I'd like to get feedback about a
> [[used]] function- (and possibly symbol- ) level attribute to prevent link
> optimizers to remove them.

They don't, for libraries. For executables, you shouldn't write code like
that, since it's not portable anyway. And I mean that in the sense that you
can't usually get symbols from executables, not in the sense of the C++
standard. You need special linker options on Linux for the linker to generate
a symbol table in the first place, in which case you should argue with your
compiler/linker vendor that their LTO step should not remove globally-visible
functions under those conditions.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3031731.BKzO8ehfaP%40tjmaciei-mobl1.

.

--0000000000001b18cb056e2c80ec
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El vie., 8 de junio de 2018 22:53, Thiago Macieira <thiago@macieira.org>
escribi=C3=B3:

> On Friday, 8 June 2018 12:39:42 EDT dgutson . wrote:
> > I regularly the go through the situation where a function might be
> > considered dead code due to LTO, but the functions are actually used by
> > dynamic loading, so I end up adding an __attribute(used) or alike in a
> > toolchain-dependant macro.
>
> LTO cannot remove a function in a library if it is globally visible. LTO
> is
> not the same as -fwhole-program, where the compiler (including during LTO=
)
> can
> see the  -- as the name says -- the whole program.
>
> So are you sure the function is being removed and you're creating a
> library?
>
> Or are you creating the application? If so, does -fno-whole-program help
> during the LTO phase? Maybe use -fPIC instead of -fPIE.
>
> > Since there is already a [[maybe_unused]], I'd like to get feedback
> about a
> > [[used]] function- (and possibly symbol- ) level attribute to prevent
> link
> > optimizers to remove them.
>
> They don't, for libraries. For executables, you shouldn't write code like
> that, since it's not portable anyway. And I mean that in the sense that
> you
> can't usually get symbols from executables, not in the sense of the C++
> standard. You need special linker options on Linux for the linker to
> generate
> a symbol table in the first place, in which case you should argue with
> your
> compiler/linker vendor that their LTO step should not remove
> globally-visible
> functions under those conditions.
>

Plug-ins development usually require that libraries need symbols provided
by the (main) executable. We have that in linux (-rdynamic), windows and
mac (it happens that i don't remember the options, can bring them on
Monday).
I agree with your comments above regarding the prelinker (collect2) and the
(real) linker but I don't see why we need to go so deep into those
toolchain details.
Whatever the scenario is, the attribute I'm lightly proposing is as mean
for the developer to provide a hint to the toolchain about the intention:
the function will be used, leave it alone.



> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3031731.BKzO=
8ehfaP%40tjmaciei-mobl1
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-2HA8cozhHAxCEXBVRvz%2BjJU1ConB8sJVh2jL3U%=
3DL9u-w%40mail.gmail.com.

--0000000000001b18cb056e2c80ec
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
El vie., 8 de junio de 2018 22:53, Thiago Macieira &lt;<a href=3D"mailto:th=
iago@macieira.org">thiago@macieira.org</a>&gt; escribi=C3=B3:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">On Friday, 8 June 2018 12:39:42 EDT dgutson . wr=
ote:<br>
&gt; I regularly the go through the situation where a function might be<br>
&gt; considered dead code due to LTO, but the functions are actually used b=
y<br>
&gt; dynamic loading, so I end up adding an __attribute(used) or alike in a=
<br>
&gt; toolchain-dependant macro.<br>
<br>
LTO cannot remove a function in a library if it is globally visible. LTO is=
 <br>
not the same as -fwhole-program, where the compiler (including during LTO) =
can <br>
see the=C2=A0 -- as the name says -- the whole program.<br>
<br>
So are you sure the function is being removed and you&#39;re creating a lib=
rary?<br>
<br>
Or are you creating the application? If so, does -fno-whole-program help <b=
r>
during the LTO phase? Maybe use -fPIC instead of -fPIE.<br>
<br>
&gt; Since there is already a [[maybe_unused]], I&#39;d like to get feedbac=
k about a<br>
&gt; [[used]] function- (and possibly symbol- ) level attribute to prevent =
link<br>
&gt; optimizers to remove them.<br>
<br>
They don&#39;t, for libraries. For executables, you shouldn&#39;t write cod=
e like <br>
that, since it&#39;s not portable anyway. And I mean that in the sense that=
 you <br>
can&#39;t usually get symbols from executables, not in the sense of the C++=
 <br>
standard. You need special linker options on Linux for the linker to genera=
te <br>
a symbol table in the first place, in which case you should argue with your=
 <br>
compiler/linker vendor that their LTO step should not remove globally-visib=
le <br>
functions under those conditions.<br></blockquote></div></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">Plug-ins development usually require that =
libraries need symbols provided by the (main) executable. We have that in l=
inux (-rdynamic), windows and mac (it happens that i don&#39;t remember the=
 options, can bring them on Monday).</div><div dir=3D"auto">I agree with yo=
ur comments above regarding the prelinker (collect2) and the (real) linker =
but I don&#39;t see why we need to go so deep into those toolchain details.=
</div><div dir=3D"auto">Whatever the scenario is, the attribute I&#39;m lig=
htly proposing is as mean for the developer to provide a hint to the toolch=
ain about the intention: the function will be used, leave it alone.</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- <br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer noreferrer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" rel=3D"noreferrer noreferrer" target=3D"_blank">kde.org=
</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3031731.BKzO8ehfaP%40tjmaciei-mobl1" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://groups.google.com/a=
/isocpp.org/d/msgid/std-proposals/3031731.BKzO8ehfaP%40tjmaciei-mobl1</a>.<=
br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2HA8cozhHAxCEXBVRvz%2BjJU1ConB=
8sJVh2jL3U%3DL9u-w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2HA8co=
zhHAxCEXBVRvz%2BjJU1ConB8sJVh2jL3U%3DL9u-w%40mail.gmail.com</a>.<br />

--0000000000001b18cb056e2c80ec--

.