------=_Part_380_1919838418.1516214829870
Content-Type: multipart/alternative;
 boundary="----=_Part_381_982785838.1516214829870"

------=_Part_381_982785838.1516214829870
Content-Type: text/plain; charset="UTF-8"

I searched in the forums but could not find a similar proposal. Instead, I found
a discussion
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r1pWsCgV550>
that may be related, but I'm not sure if my proposal completely fulfills
the author's needs.

[[always_inline]] is a hint that would substitute
__attribute__((always_inline)), __forceinline and similar compiler-specific
hints. The intention is for it to be semantically different from C++'s
inline (e.g. as a mechanism for ODR realization) and be more on par with
the compiler-dependent attributes it substitutes and C99's inline (e.g. try
to inline the function call to avoid stack growth).

Instead of using macros, like in:


#ifdef _MSC_VER
#   define always_inline __forceinline
#elif defined(__GNUC__)
#   define always_inline __attribute__((always_inline)) inline
#else
#   define always_inline inline
#endif

struct Test {
    always_inline void function() {}
}


One would use insead:

struct Test {
    [[always_inline]] void function() {}
}


It could be named [[try_inline]] or [[force_inline]], perhaps.

Was this discussed before? Could there be any unforeseen consequence if
such an attribute was standardized? I don't believe it would change the
semantic of the program (or perhaps it would, in the case of e.g. member
function pointers? but then, again, it's just a hint).

--
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/aca97504-7a52-4b7d-8e2a-36144d63c9a0%40isocpp.org.

------=_Part_381_982785838.1516214829870
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I searched in the forums but could not find a similar prop=
osal. Instead, I <a href=3D"https://groups.google.com/a/isocpp.org/forum/#!=
topic/std-proposals/r1pWsCgV550">found a discussion</a> that may be related=
, but I&#39;m not sure if my proposal completely fulfills the author&#39;s =
needs.<div><br></div><div><font face=3D"courier new, monospace" style=3D"ba=
ckground-color: rgb(238, 238, 238);">[[always_inline]]</font>=C2=A0is a hin=
t that would substitute <font face=3D"courier new, monospace" style=3D"back=
ground-color: rgb(238, 238, 238);">__attribute__((always_inline))</font>, <=
font face=3D"courier new, monospace" style=3D"background-color: rgb(238, 23=
8, 238);">__forceinline</font> and similar compiler-specific hints. The int=
ention is for it to be semantically different from C++&#39;s <span style=3D=
"background-color: rgb(238, 238, 238);"><font face=3D"courier new, monospac=
e">inline</font></span>=C2=A0(e.g. as a mechanism for ODR realization) and =
be more on par with the compiler-dependent attributes it substitutes and C9=
9&#39;s <font face=3D"courier new, monospace" color=3D"#000000" style=3D"ba=
ckground-color: rgb(238, 238, 238);">inline</font>=C2=A0(e.g. try to inline=
 the function call to avoid stack growth).</div><div><br></div><div>Instead=
 of using macros, like in:</div><blockquote style=3D"margin: 0 0 0 40px; bo=
rder: none; padding: 0px;"><div><font face=3D"courier new, monospace"><br><=
/font></div><div><div><font face=3D"courier new, monospace">#ifdef _MSC_VER=
</font></div></div><div><div><font face=3D"courier new, monospace"># =C2=A0=
 define always_inline __forceinline</font></div></div><div><div><font face=
=3D"courier new, monospace">#elif defined(__GNUC__)</font></div></div><div>=
<div><font face=3D"courier new, monospace"># =C2=A0 define always_inline __=
attribute__((always_inline)) inline</font></div></div><div><div><font face=
=3D"courier new, monospace">#else</font></div></div><div><div><font face=3D=
"courier new, monospace"># =C2=A0 define always_inline inline</font></div><=
/div><div><div><font face=3D"courier new, monospace">#endif</font></div></d=
iv><div><font face=3D"courier new, monospace"><br></font></div><div><font f=
ace=3D"courier new, monospace">struct Test {</font></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 always_inline void function() {}</fo=
nt></div><div><font face=3D"courier new, monospace">}</font></div></blockqu=
ote><div><br></div><div>One would use insead:</div><div><br></div><blockquo=
te style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><fon=
t face=3D"courier new, monospace">struct Test {</font></div></div><div><div=
><font face=3D"courier new, monospace">=C2=A0 =C2=A0 [[always_inline]] void=
 function() {}</font></div></div><div><div><font face=3D"courier new, monos=
pace">}</font></div></div></blockquote><div><font face=3D"courier new, mono=
space"><br></font></div><div><font face=3D"arial, sans-serif">It could be n=
amed </font><font face=3D"courier new, monospace" style=3D"background-color=
: rgb(238, 238, 238);">[[try_inline]]</font><font face=3D"arial, sans-serif=
"> or </font><font face=3D"courier new, monospace" style=3D"background-colo=
r: rgb(238, 238, 238);">[[force_inline]]</font><font face=3D"arial, sans-se=
rif">, perhaps.</font></div><div><font face=3D"arial, sans-serif"><br></fon=
t></div><div><font face=3D"arial, sans-serif">Was this discussed before? Co=
uld there be any unforeseen consequence if such an attribute was standardiz=
ed? I don&#39;t believe it would change the semantic of the program (or per=
haps it would, in the case of e.g. member function pointers? but then, agai=
n, it&#39;s just a hint).</font></div><div><font face=3D"arial, sans-serif"=
><br></font></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/aca97504-7a52-4b7d-8e2a-36144d63c9a0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/aca97504-7a52-4b7d-8e2a-36144d63c9a0=
%40isocpp.org</a>.<br />

------=_Part_381_982785838.1516214829870--

------=_Part_380_1919838418.1516214829870--

.

On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=B4a wrote:
> I searched in the forums but could not find a similar proposal. Instead, =
I found=20
> a discussion=20
> <https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r1pWs=
CgV550>=20
> that may be related, but I'm not sure if my proposal completely fulfills=
=20
> the author's needs.
>=20
> [[always_inline]] is a hint that would substitute=20
> __attribute__((always_inline)), __forceinline and similar compiler-specif=
ic=20
> hints. The intention is for it to be semantically different from C++'s=20
> inline (e.g. as a mechanism for ODR realization) and be more on par with=
=20
> the compiler-dependent attributes it substitutes and C99's inline (e.g. t=
ry=20
> to inline the function call to avoid stack growth).

One of the points of always_inline is that the compiler ain't allowed to ig=
nore
it. As such it can't be an attribute.

/MF

--=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/20180117213553.GA9823%40noemi.bahnhof.se.

.

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

On Wed, Jan 17, 2018 at 4:35 PM, Magnus Fromreide <magfr@lysator.liu.se>
wrote:

> On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=B4a wrote:
> > I searched in the forums but could not find a similar proposal. Instead=
,
> I found
> > a discussion
> > <https://groups.google.com/a/isocpp.org/forum/#!topic/std-
> proposals/r1pWsCgV550>
> > that may be related, but I'm not sure if my proposal completely fulfill=
s
> > the author's needs.
> >
> > [[always_inline]] is a hint that would substitute
> > __attribute__((always_inline)), __forceinline and similar
> compiler-specific
> > hints. The intention is for it to be semantically different from C++'s
> > inline (e.g. as a mechanism for ODR realization) and be more on par wit=
h
> > the compiler-dependent attributes it substitutes and C99's inline (e.g.
> try
> > to inline the function call to avoid stack growth).
>
> One of the points of always_inline is that the compiler ain't allowed to
> ignore
> it. As such it can't be an attribute.
>
>
But it also can't be a keyword, as it is outside the language - the
language doesn't define compiling to another representation (that may or
may not mash functions together).
An implementation that interprets your code instead of compiling it could
be a valid C++ implementation.

So an attribute is right, but the naming is tricky.

[[really_srsly_inline_please]

--=20
Be seeing you,
Tony

--=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/CAOHCbitk0kiuep4%2BFSqCocoE3_rGAPb6YtM5XmnUpwJfA=
MTuPQ%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Jan 17, 2018 at 4:35 PM, Magnus Fromreide <span dir=3D"ltr">&lt=
;<a href=3D"mailto:magfr@lysator.liu.se" target=3D"_blank">magfr@lysator.li=
u.se</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D=
"">On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=B4a wrote:=
<br>
&gt; I searched in the forums but could not find a similar proposal. Instea=
d, I found<br>
&gt; a discussion<br>
</span>&gt; &lt;<a href=3D"https://groups.google.com/a/isocpp.org/forum/#!t=
opic/std-proposals/r1pWsCgV550" rel=3D"noreferrer" target=3D"_blank">https:=
//groups.google.com/a/<wbr>isocpp.org/forum/#!topic/std-<wbr>proposals/r1pW=
sCgV550</a>&gt;<br>
<span class=3D"">&gt; that may be related, but I&#39;m not sure if my propo=
sal completely fulfills<br>
&gt; the author&#39;s needs.<br>
&gt;<br>
&gt; [[always_inline]] is a hint that would substitute<br>
&gt; __attribute__((always_inline))<wbr>, __forceinline and similar compile=
r-specific<br>
&gt; hints. The intention is for it to be semantically different from C++&#=
39;s<br>
&gt; inline (e.g. as a mechanism for ODR realization) and be more on par wi=
th<br>
&gt; the compiler-dependent attributes it substitutes and C99&#39;s inline =
(e.g. try<br>
&gt; to inline the function call to avoid stack growth).<br>
<br>
</span>One of the points of always_inline is that the compiler ain&#39;t al=
lowed to ignore<br>
it. As such it can&#39;t be an attribute.<br>
<br></blockquote><div><br></div><div>But it also can&#39;t be a keyword, as=
 it is outside the language - the language doesn&#39;t define compiling to =
another representation (that may or may not mash functions together).</div>=
<div>An implementation that interprets your code instead of compiling it co=
uld be a valid C++ implementation.</div><div><br></div><div>So an attribute=
 is right, but the naming is tricky.</div><div><br></div><div>[[really_srsl=
y_inline_please]<br></div><div>=C2=A0<br></div></div>-- <br><div class=3D"g=
mail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be=
 seeing you,<br></div>Tony<br></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/CAOHCbitk0kiuep4%2BFSqCocoE3_rGAPb6Yt=
M5XmnUpwJfAMTuPQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitk0kiuep=
4%2BFSqCocoE3_rGAPb6YtM5XmnUpwJfAMTuPQ%40mail.gmail.com</a>.<br />

--94eb2c095d70c5194a056300034c--

.

------=_Part_886_1907596867.1516227442668
Content-Type: multipart/alternative;
 boundary="----=_Part_887_914650194.1516227442668"

------=_Part_887_914650194.1516227442668
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wednesday, January 17, 2018 at 4:36:00 PM UTC-5, Magnus Fromreide wrote:
>
> On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=B4a wrote:=
=20
> > I searched in the forums but could not find a similar proposal. Instead=
,=20
> I found=20
> > a discussion=20
> > <
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r1pWsC=
gV550>=20
>
> > that may be related, but I'm not sure if my proposal completely fulfill=
s=20
> > the author's needs.=20
> >=20
> > [[always_inline]] is a hint that would substitute=20
> > __attribute__((always_inline)), __forceinline and similar=20
> compiler-specific=20
> > hints. The intention is for it to be semantically different from C++'s=
=20
> > inline (e.g. as a mechanism for ODR realization) and be more on par wit=
h=20
> > the compiler-dependent attributes it substitutes and C99's inline (e.g.=
=20
> try=20
> > to inline the function call to avoid stack growth).=20
>
> One of the points of always_inline is that the compiler ain't allowed to=
=20
> ignore=20
> it. As such it can't be an attribute.=20
>

If the compiler doesn't implement the concept of `always_inline`, then I=20
don't see the problem. That is, if the compiler has no compiler-specific=20
inlining attribute, then it shouldn't be a surprise that [[always_inline]]=
=20
won't inline it either.

What we want is a cross-platform way to say what we can already say. People=
=20
who genuinely need forced inlining use compilers that support forced=20
inlining. If some compiler can't do it, they simply won't use that compiler=
..

This is a QOI issue. Let compilers handle it as they see fit.

--=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/6f0fd472-4629-4a8e-83a8-c9094dcec679%40isocpp.or=
g.

------=_Part_887_914650194.1516227442668
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, January 17, 2018 at 4:36:00 PM UTC-5, Magnus=
 Fromreide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jan 1=
7, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=B4a wrote:
<br>&gt; I searched in the forums but could not find a similar proposal. In=
stead, I found=20
<br>&gt; a discussion=20
<br>&gt; &lt;<a onmousedown=3D"this.href=3D&#39;https://groups.google.com/a=
/isocpp.org/forum/#!topic/std-proposals/r1pWsCgV550&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!topi=
c/std-proposals/r1pWsCgV550&#39;;return true;" href=3D"https://groups.googl=
e.com/a/isocpp.org/forum/#!topic/std-proposals/r1pWsCgV550" target=3D"_blan=
k" rel=3D"nofollow">https://groups.google.com/a/<wbr>isocpp.org/forum/#!top=
ic/std-<wbr>proposals/r1pWsCgV550</a>&gt;=20
<br>&gt; that may be related, but I&#39;m not sure if my proposal completel=
y fulfills=20
<br>&gt; the author&#39;s needs.
<br>&gt;=20
<br>&gt; [[always_inline]] is a hint that would substitute=20
<br>&gt; __attribute__((always_inline))<wbr>, __forceinline and similar com=
piler-specific=20
<br>&gt; hints. The intention is for it to be semantically different from C=
++&#39;s=20
<br>&gt; inline (e.g. as a mechanism for ODR realization) and be more on pa=
r with=20
<br>&gt; the compiler-dependent attributes it substitutes and C99&#39;s inl=
ine (e.g. try=20
<br>&gt; to inline the function call to avoid stack growth).
<br>
<br>One of the points of always_inline is that the compiler ain&#39;t allow=
ed to ignore
<br>it. As such it can&#39;t be an attribute.
<br></blockquote><div><br></div><div>If the compiler doesn&#39;t implement =
the concept of `always_inline`, then I don&#39;t see the problem. That is, =
if the compiler has no compiler-specific inlining attribute, then it should=
n&#39;t be a surprise that [[always_inline]] won&#39;t inline it either.</d=
iv><div><br></div><div>What we want is a cross-platform way to say what we =
can already say. People who genuinely need forced inlining use compilers th=
at support forced inlining. If some compiler can&#39;t do it, they simply w=
on&#39;t use that compiler.</div><div><br></div><div>This is a QOI issue. L=
et compilers handle it as they see fit.<br></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/6f0fd472-4629-4a8e-83a8-c9094dcec679%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6f0fd472-4629-4a8e-83a8-c9094dcec679=
%40isocpp.org</a>.<br />

------=_Part_887_914650194.1516227442668--

------=_Part_886_1907596867.1516227442668--

.

------=_Part_911_833398373.1516229573900
Content-Type: multipart/alternative;
 boundary="----=_Part_912_1492255019.1516229573900"

------=_Part_912_1492255019.1516229573900
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thats not actually true.... always_inline means "do inlining on this=20
function even in O0".  Some compilers will increase the required weight to=
=20
cause the inlining, but they still make a decision based on whether to=20
inline separately.

On Wednesday, January 17, 2018 at 1:36:00 PM UTC-8, Magnus Fromreide wrote:
>
> On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=B4a wrote:=
=20
> > I searched in the forums but could not find a similar proposal. Instead=
,=20
> I found=20
> > a discussion=20
> > <
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r1pWsC=
gV550>=20
>
> > that may be related, but I'm not sure if my proposal completely fulfill=
s=20
> > the author's needs.=20
> >=20
> > [[always_inline]] is a hint that would substitute=20
> > __attribute__((always_inline)), __forceinline and similar=20
> compiler-specific=20
> > hints. The intention is for it to be semantically different from C++'s=
=20
> > inline (e.g. as a mechanism for ODR realization) and be more on par wit=
h=20
> > the compiler-dependent attributes it substitutes and C99's inline (e.g.=
=20
> try=20
> > to inline the function call to avoid stack growth).=20
>
> One of the points of always_inline is that the compiler ain't allowed to=
=20
> ignore=20
> it. As such it can't be an attribute.=20
>
> /MF=20
>

--=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/7350a7bd-74da-4494-b615-50b3aa410fa6%40isocpp.or=
g.

------=_Part_912_1492255019.1516229573900
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thats not actually true.... always_inline means &quot;do i=
nlining on this function even in O0&quot;.=C2=A0 Some compilers will increa=
se the required weight to cause the inlining, but they still make a decisio=
n based on whether to inline separately.<br><br>On Wednesday, January 17, 2=
018 at 1:36:00 PM UTC-8, Magnus Fromreide wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lis=
b=C3=B4a wrote:
<br>&gt; I searched in the forums but could not find a similar proposal. In=
stead, I found=20
<br>&gt; a discussion=20
<br>&gt; &lt;<a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topi=
c/std-proposals/r1pWsCgV550" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!topic/s=
td-proposals/r1pWsCgV550&#39;;return true;" onclick=3D"this.href=3D&#39;htt=
ps://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r1pWsCgV550=
&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org/forum/#!top=
ic/std-<wbr>proposals/r1pWsCgV550</a>&gt;=20
<br>&gt; that may be related, but I&#39;m not sure if my proposal completel=
y fulfills=20
<br>&gt; the author&#39;s needs.
<br>&gt;=20
<br>&gt; [[always_inline]] is a hint that would substitute=20
<br>&gt; __attribute__((always_inline))<wbr>, __forceinline and similar com=
piler-specific=20
<br>&gt; hints. The intention is for it to be semantically different from C=
++&#39;s=20
<br>&gt; inline (e.g. as a mechanism for ODR realization) and be more on pa=
r with=20
<br>&gt; the compiler-dependent attributes it substitutes and C99&#39;s inl=
ine (e.g. try=20
<br>&gt; to inline the function call to avoid stack growth).
<br>
<br>One of the points of always_inline is that the compiler ain&#39;t allow=
ed to ignore
<br>it. As such it can&#39;t be an attribute.
<br>
<br>/MF
<br></blockquote></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/7350a7bd-74da-4494-b615-50b3aa410fa6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7350a7bd-74da-4494-b615-50b3aa410fa6=
%40isocpp.org</a>.<br />

------=_Part_912_1492255019.1516229573900--

------=_Part_911_833398373.1516229573900--

.

On 01/18/18 01:52, Erich Keane wrote:
> On Wednesday, January 17, 2018 at 1:36:00 PM UTC-8, Magnus Fromreide wrot=
e:
>     On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=B4a wro=
te:
>      > I searched in the forums but could not find a similar proposal.
>     Instead, I found
>      > a discussion
>      >
>     <https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r=
1pWsCgV550
>     <https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r=
1pWsCgV550>>
>=20
>      > that may be related, but I'm not sure if my proposal completely
>     fulfills
>      > the author's needs.
>      >
>      > [[always_inline]] is a hint that would substitute
>      > __attribute__((always_inline)), __forceinline and similar
>     compiler-specific
>      > hints. The intention is for it to be semantically different from
>     C++'s
>      > inline (e.g. as a mechanism for ODR realization) and be more on
>     par with
>      > the compiler-dependent attributes it substitutes and C99's inline
>     (e.g. try
>      > to inline the function call to avoid stack growth).
>=20
>     One of the points of always_inline is that the compiler ain't
>     allowed to ignore
>     it. As such it can't be an attribute.
>=20
> Thats not actually true.... always_inline means "do inlining on this=20
> function even in O0".

It's not even that strong, not in case of gcc, at least. Basically,=20
__attribute__((always_inline)) makes the function always inlined _when=20
it is considered for inlining by the optimizer_. -O0 disables the=20
optimizer entirely, making the attribute have no effect.

--=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/bf0fff1c-0f58-2450-bf91-5dc564d9bdb0%40gmail.com=
..

.

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

On Wed, Jan 17, 2018 at 6:28 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

> On Wednesday, January 17, 2018 at 10:47:09 AM UTC-8, Fl=C3=A1vio Lisb=C3=
=B4a wrote:
>>
>>
>> [[always_inline]] is a hint that would substitute
>> __attribute__((always_inline)), __forceinline and similar
>> compiler-specific hints. The intention is for it to be semantically
>> different from C++'s inline (e.g. as a mechanism for ODR realization)
>> and be more on par with the compiler-dependent attributes it substitutes
>> and C99's inline (e.g. try to inline the function call to avoid stack
>> growth).
>> [...snip highly motivating example code...]
>> Was this discussed before? Could there be any unforeseen consequence if
>> such an attribute was standardized? I don't believe it would change the
>> semantic of the program (or perhaps it would, in the case of e.g. member
>> function pointers? but then, again, it's just a hint).
>>
>
> Yep, seems like a slam-dunk to me. (And [[always_inline]] is the correct
> name, for historical reasons. Let's not inflict another NIHism like
> [[maybe_unused]] on the world. Although I'll admit, even though I resente=
d
> [[nodiscard]] at the time, it's probably a good thing that we no longer
> have to teach the historically-correct but impossible-to-remember
> [[warn_unused_result]].)
>
> Kind of a thread-hijack, but I have thought for a long time that what
> would be really nice in a C-style language is a reification of something
> kind of like Lisa Lippincott's "basic interface" ideas. In the following
> metaphor, the function call-site is like a Javascript client, and the
> out-of-line function body is like a remote server. Quite often we have a
> function with a bunch of (metaphorical) "client-side checks" stuffed in
> front of the "server-side code":
>
>     extern int some_function_unchecked(int *x, int n, int i);
>     inline int some_function(int *x, int n, int i) {
>         if (x =3D=3D nullptr) throw "oops";
>         if (n < 0) throw "oops";
>         if (!(0 <=3D i && i < n)) return 0;
>         return some_function_unchecked(x, n, i);
>     }
>
> and it would be nice to indicate directly to the compiler, without having
> to play tricks with helper functions, that those "client-side checks"
> should be inlined, and then the (metaphorical) "server-side logic" should
> not be inlined. Because if you can inline the "client-side checks," you'l=
l
> usually find that they are optimized out entirely; whereas the benefit of
> inlining the "server-side logic" might actually be negative.
>

I really like that idea (and all of the bigger stuff from Lisa's work).
No idea what the syntax would be, other than { } with an annotation, like
[[no_inline]] for that block.


--=20
Be seeing you,
Tony

--=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/CAOHCbiu6Bpor%3D_Tyxs4xXF0%2BKKRMBy7nj-%2BOLByX4=
aDRBnD30g%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Jan 17, 2018 at 6:28 PM, Arthur O&#39;Dwyer <span dir=3D"ltr">&=
lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.=
odwyer@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><span class=3D"">On Wednesday, January 17, 2018 at 10:47:09 =
AM UTC-8, Fl=C3=A1vio Lisb=C3=B4a wrote:</span><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><span class=3D""><div><br></div><div><font sty=
le=3D"background-color:rgb(238,238,238)" face=3D"courier new, monospace">[[=
always_inline]]</font>=C2=A0is a hint that would substitute <font style=3D"=
background-color:rgb(238,238,238)" face=3D"courier new, monospace">__attrib=
ute__((always_inline))</font><wbr>, <font style=3D"background-color:rgb(238=
,238,238)" face=3D"courier new, monospace">__forceinline</font> and similar=
 compiler-specific hints. The intention is for it to be semantically differ=
ent from C++&#39;s <span style=3D"background-color:rgb(238,238,238)"><font =
face=3D"courier new, monospace">inline</font></span>=C2=A0(e.g. as a mechan=
ism for ODR realization) and be more on par with the compiler-dependent att=
ributes it substitutes and C99&#39;s <font style=3D"background-color:rgb(23=
8,238,238)" face=3D"courier new, monospace" color=3D"#000000">inline</font>=
=C2=A0(e.g. try to inline the function call to avoid stack growth).</div></=
span><div>[...snip highly motivating example code...]</div><span class=3D""=
><div><font face=3D"arial, sans-serif">Was this discussed before? Could the=
re be any unforeseen consequence if such an attribute was standardized? I d=
on&#39;t believe it would change the semantic of the program (or perhaps it=
 would, in the case of e.g. member function pointers? but then, again, it&#=
39;s just a hint).</font></div></span></div></blockquote><div><br></div><di=
v>Yep, seems like a slam-dunk to me. (And [[always_inline]] is the correct =
name, for historical reasons. Let&#39;s not inflict another NIHism like [[m=
aybe_unused]] on the world. Although I&#39;ll admit, even though I resented=
 [[nodiscard]] at the time, it&#39;s probably a good thing that we no longe=
r have to teach the historically-correct but impossible-to-remember [[warn_=
unused_result]].)</div><div><br></div><div>Kind of a thread-hijack, but I h=
ave thought for a long time that what would be really nice in a C-style lan=
guage is a reification of something kind of like Lisa Lippincott&#39;s &quo=
t;basic interface&quot; ideas. In the following metaphor, the function call=
-site is like a Javascript client, and the out-of-line function body is lik=
e a remote server. Quite often we have a function with a bunch of (metaphor=
ical) &quot;client-side checks&quot; stuffed in front of the &quot;server-s=
ide code&quot;:</div><div><br></div><div>=C2=A0 =C2=A0 extern int some_func=
tion_unchecked(int *x, int n, int i);</div><div>=C2=A0 =C2=A0 inline int so=
me_function(int *x, int n, int i) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 i=
f (x =3D=3D nullptr) throw &quot;oops&quot;;</div><div>=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 if (n &lt; 0) throw &quot;oops&quot;;</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 if (!(0 &lt;=3D i &amp;&amp; i &lt; n)) return 0;</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 return some_function_unchecked(x, n, i);</div><div=
>=C2=A0 =C2=A0 }</div><div><br></div><div>and it would be nice to indicate =
directly to the compiler, without having to play tricks with helper functio=
ns, that those &quot;client-side checks&quot; should be inlined, and then t=
he (metaphorical) &quot;server-side logic&quot; should not be inlined. Beca=
use if you can inline the &quot;client-side checks,&quot; you&#39;ll usuall=
y find that they are optimized out entirely; whereas the benefit of inlinin=
g the &quot;server-side logic&quot; might actually be negative.</div></div>=
</blockquote><div><br></div><div>I really like that idea (and all of the bi=
gger stuff from Lisa&#39;s work).</div><div>No idea what the syntax would b=
e, other than { } with an annotation, like [[no_inline]] for that block.<br=
></div><br clear=3D"all"></div><br>-- <br><div class=3D"gmail_signature" da=
ta-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></=
div>Tony<br></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/CAOHCbiu6Bpor%3D_Tyxs4xXF0%2BKKRMBy7n=
j-%2BOLByX4aDRBnD30g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu6Bp=
or%3D_Tyxs4xXF0%2BKKRMBy7nj-%2BOLByX4aDRBnD30g%40mail.gmail.com</a>.<br />

--001a1134ef5284e92a056301eff2--

.

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

On 17 January 2018 at 15:12, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On 01/18/18 01:52, Erich Keane wrote:
>
>> On Wednesday, January 17, 2018 at 1:36:00 PM UTC-8, Magnus Fromreide
>> wrote:
>>     On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=B4a wr=
ote:
>>      > I searched in the forums but could not find a similar proposal.
>>     Instead, I found
>>      > a discussion
>>      >
>>     <https://groups.google.com/a/isocpp.org/forum/#!topic/std-pr
>> oposals/r1pWsCgV550
>>     <https://groups.google.com/a/isocpp.org/forum/#!topic/std-pr
>> oposals/r1pWsCgV550>>
>>
>>      > that may be related, but I'm not sure if my proposal completely
>>     fulfills
>>      > the author's needs.
>>      >
>>      > [[always_inline]] is a hint that would substitute
>>      > __attribute__((always_inline)), __forceinline and similar
>>     compiler-specific
>>      > hints. The intention is for it to be semantically different from
>>     C++'s
>>      > inline (e.g. as a mechanism for ODR realization) and be more on
>>     par with
>>      > the compiler-dependent attributes it substitutes and C99's inline
>>     (e.g. try
>>      > to inline the function call to avoid stack growth).
>>
>>     One of the points of always_inline is that the compiler ain't
>>     allowed to ignore
>>     it. As such it can't be an attribute.
>>
>> Thats not actually true.... always_inline means "do inlining on this
>> function even in O0".
>>
>
> It's not even that strong, not in case of gcc, at least. Basically,
> __attribute__((always_inline)) makes the function always inlined _when it
> is considered for inlining by the optimizer_. -O0 disables the optimizer
> entirely, making the attribute have no effect.


Your claim is trivially falsified: https://godbolt.org/g/bahckm

And the GCC documentation explicitly covers this, saying "GCC does not
inline any functions when not optimizing unless you specify the
=E2=80=98always_inline=E2=80=99 attribute for the function".

The actual rules for the attribute are (per the GCC documentation):

"""
always_inline

Generally, functions are not inlined unless optimization is specified. For
functions declared inline, this attribute inlines the function independent
of any restrictions that otherwise apply to inlining. Failure to inline
such a function is diagnosed as an error. Note that if such a function is
called indirectly the compiler may or may not inline it depending on
optimization level and a failure to inline an indirect call may or may not
be diagnosed.
"""

--=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/CAOfiQqkOPsYRFHnZO79O2dQ_%3Dw-tOPwUbTAnZmOrM3uF_=
wdFkg%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
7 January 2018 at 15:12, Andrey Semashev <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gmail.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><span class=3D"gmail-">On 01/18/18 01:52, Erich Keane wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"gma=
il-">
On Wednesday, January 17, 2018 at 1:36:00 PM UTC-8, Magnus Fromreide wrote:=
<br>
=C2=A0 =C2=A0 On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=
=B4a wrote:<br>
=C2=A0 =C2=A0 =C2=A0&gt; I searched in the forums but could not find a simi=
lar proposal.<br>
=C2=A0 =C2=A0 Instead, I found<br>
=C2=A0 =C2=A0 =C2=A0&gt; a discussion<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 &lt;<a href=3D"https://groups.google.com/a/isocpp.org/forum/#=
!topic/std-proposals/r1pWsCgV550" rel=3D"noreferrer" target=3D"_blank">http=
s://groups.google.com/a/i<wbr>socpp.org/forum/#!topic/std-pr<wbr>oposals/r1=
pWsCgV550</a><br>
=C2=A0 =C2=A0 &lt;<a href=3D"https://groups.google.com/a/isocpp.org/forum/#=
!topic/std-proposals/r1pWsCgV550" rel=3D"noreferrer" target=3D"_blank">http=
s://groups.google.com/a/i<wbr>socpp.org/forum/#!topic/std-pr<wbr>oposals/r1=
pWsCgV550</a>&gt;&gt;<br>
<br>
=C2=A0 =C2=A0 =C2=A0&gt; that may be related, but I&#39;m not sure if my pr=
oposal completely<br>
=C2=A0 =C2=A0 fulfills<br>
=C2=A0 =C2=A0 =C2=A0&gt; the author&#39;s needs.<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 =C2=A0&gt; [[always_inline]] is a hint that would substitute<=
br>
=C2=A0 =C2=A0 =C2=A0&gt; __attribute__((always_inline))<wbr>, __forceinline=
 and similar<br>
=C2=A0 =C2=A0 compiler-specific<br>
=C2=A0 =C2=A0 =C2=A0&gt; hints. The intention is for it to be semantically =
different from<br>
=C2=A0 =C2=A0 C++&#39;s<br>
=C2=A0 =C2=A0 =C2=A0&gt; inline (e.g. as a mechanism for ODR realization) a=
nd be more on<br>
=C2=A0 =C2=A0 par with<br>
=C2=A0 =C2=A0 =C2=A0&gt; the compiler-dependent attributes it substitutes a=
nd C99&#39;s inline<br>
=C2=A0 =C2=A0 (e.g. try<br>
=C2=A0 =C2=A0 =C2=A0&gt; to inline the function call to avoid stack growth)=
..<br>
<br>
=C2=A0 =C2=A0 One of the points of always_inline is that the compiler ain&#=
39;t<br>
=C2=A0 =C2=A0 allowed to ignore<br>
=C2=A0 =C2=A0 it. As such it can&#39;t be an attribute.<br>
<br></span><span class=3D"gmail-">
Thats not actually true.... always_inline means &quot;do inlining on this f=
unction even in O0&quot;.<br>
</span></blockquote>
<br>
It&#39;s not even that strong, not in case of gcc, at least. Basically, __a=
ttribute__((always_inline)) makes the function always inlined _when it is c=
onsidered for inlining by the optimizer_. -O0 disables the optimizer entire=
ly, making the attribute have no effect.</blockquote><div><br></div><div>Yo=
ur claim is trivially falsified:=C2=A0<a href=3D"https://godbolt.org/g/bahc=
km">https://godbolt.org/g/bahckm</a></div><div><br></div><div>And the GCC d=
ocumentation explicitly covers this, saying &quot;GCC does not inline any f=
unctions when not optimizing unless you specify the =E2=80=98always_inline=
=E2=80=99 attribute for the function&quot;.</div><div><br></div><div>The ac=
tual rules for the attribute are (per the GCC documentation):</div><div><br=
></div><div>&quot;&quot;&quot;</div><div><div>always_inline</div><div><br><=
/div><div>Generally, functions are not inlined unless optimization is speci=
fied. For functions declared inline, this attribute inlines the function in=
dependent of any restrictions that otherwise apply to inlining. Failure to =
inline such a function is diagnosed as an error. Note that if such a functi=
on is called indirectly the compiler may or may not inline it depending on =
optimization level and a failure to inline an indirect call may or may not =
be diagnosed.</div><div>&quot;&quot;&quot;</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/CAOfiQqkOPsYRFHnZO79O2dQ_%3Dw-tOPwUbT=
AnZmOrM3uF_wdFkg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkOPsYRFH=
nZO79O2dQ_%3Dw-tOPwUbTAnZmOrM3uF_wdFkg%40mail.gmail.com</a>.<br />

--001a113cee84135075056301f9b1--

.

------=_Part_1298_1203566440.1516239313312
Content-Type: multipart/alternative;
 boundary="----=_Part_1299_260002723.1516239313313"

------=_Part_1299_260002723.1516239313313
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Thursday, January 18, 2018 at 1:23:32 PM UTC+13, Richard Smith wrote:
>
> On 17 January 2018 at 15:12, Andrey Semashev <andrey....@gmail.com=20
> <javascript:>> wrote:
>
>> On 01/18/18 01:52, Erich Keane wrote:
>>
>>> On Wednesday, January 17, 2018 at 1:36:00 PM UTC-8, Magnus Fromreide=20
>>> wrote:
>>>     On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=B4a w=
rote:
>>>      > I searched in the forums but could not find a similar proposal.
>>>     Instead, I found
>>>      > a discussion
>>>      >
>>>     <
>>> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r1pW=
sCgV550
>>>     <
>>> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r1pW=
sCgV550
>>> >>
>>>
>>>      > that may be related, but I'm not sure if my proposal completely
>>>     fulfills
>>>      > the author's needs.
>>>      >
>>>      > [[always_inline]] is a hint that would substitute
>>>      > __attribute__((always_inline)), __forceinline and similar
>>>     compiler-specific
>>>      > hints. The intention is for it to be semantically different from
>>>     C++'s
>>>      > inline (e.g. as a mechanism for ODR realization) and be more on
>>>     par with
>>>      > the compiler-dependent attributes it substitutes and C99's inlin=
e
>>>     (e.g. try
>>>      > to inline the function call to avoid stack growth).
>>>
>>>     One of the points of always_inline is that the compiler ain't
>>>     allowed to ignore
>>>     it. As such it can't be an attribute.
>>>
>>> Thats not actually true.... always_inline means "do inlining on this=20
>>> function even in O0".
>>>
>>
>> It's not even that strong, not in case of gcc, at least. Basically,=20
>> __attribute__((always_inline)) makes the function always inlined _when i=
t=20
>> is considered for inlining by the optimizer_. -O0 disables the optimizer=
=20
>> entirely, making the attribute have no effect.
>
>
> Your claim is trivially falsified: https://godbolt.org/g/bahckm
>
> And the GCC documentation explicitly covers this, saying "GCC does not=20
> inline any functions when not optimizing unless you specify the=20
> =E2=80=98always_inline=E2=80=99 attribute for the function".
>
> The actual rules for the attribute are (per the GCC documentation):
>
> """
> always_inline
>
> Generally, functions are not inlined unless optimization is specified. Fo=
r=20
> functions declared inline, this attribute inlines the function independen=
t=20
> of any restrictions that otherwise apply to inlining. Failure to inline=
=20
> such a function is diagnosed as an error. Note that if such a function is=
=20
> called indirectly the compiler may or may not inline it depending on=20
> optimization level and a failure to inline an indirect call may or may no=
t=20
> be diagnosed.
> """
>

Richard
I think the OP's idea to standardize always inline is a good one
I generally find the rules on when functions are inlined or not a bit=20
confusing.
It seems it would be good to standardize this area if possible?
In that aim, if we are going to address always inline which I'd like, it=20
seems it would make sense for the Standard to address no inline. i.e.:
https://stackoverflow.com/questions/1474030/how-can-i-tell-gcc-not-to-inlin=
e-a-function
https://docs.microsoft.com/en-nz/cpp/cpp/noinline=20
msvc and gcc and clang all seem to have noinline so it would be good if=20
that could be standardized.

--=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/cd376bdd-6ac8-4da8-bf68-58555ae8087d%40isocpp.or=
g.

------=_Part_1299_260002723.1516239313313
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, January 18, 2018 at 1:23:32 PM UTC+13=
, Richard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote">On 17 January 2018 at 15:12, Andrey Semashev <span=
 dir=3D"ltr">&lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return=
 true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"=
javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"Hu=
fKFhFJAgAJ">andrey....@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><span>On 01/18/18 01:52, Erich Keane wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex=
; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wid=
th: 1px; border-left-style: solid;"><span>
On Wednesday, January 17, 2018 at 1:36:00 PM UTC-8, Magnus Fromreide wrote:=
<br>
=C2=A0 =C2=A0 On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=
=B4a wrote:<br>
=C2=A0 =C2=A0 =C2=A0&gt; I searched in the forums but could not find a simi=
lar proposal.<br>
=C2=A0 =C2=A0 Instead, I found<br>
=C2=A0 =C2=A0 =C2=A0&gt; a discussion<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 &lt;<a onmousedown=3D"this.href=3D&#39;https://groups.google.=
com/a/isocpp.org/forum/#!topic/std-proposals/r1pWsCgV550&#39;;return true;"=
 onclick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#=
!topic/std-proposals/r1pWsCgV550&#39;;return true;" href=3D"https://groups.=
google.com/a/isocpp.org/forum/#!topic/std-proposals/r1pWsCgV550" target=3D"=
_blank" rel=3D"nofollow">https://groups.google.com/a/<wbr>isocpp.org/forum/=
#!topic/std-<wbr>proposals/r1pWsCgV550</a><br>
=C2=A0 =C2=A0 &lt;<a onmousedown=3D"this.href=3D&#39;https://groups.google.=
com/a/isocpp.org/forum/#!topic/std-proposals/r1pWsCgV550&#39;;return true;"=
 onclick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#=
!topic/std-proposals/r1pWsCgV550&#39;;return true;" href=3D"https://groups.=
google.com/a/isocpp.org/forum/#!topic/std-proposals/r1pWsCgV550" target=3D"=
_blank" rel=3D"nofollow">https://groups.google.com/a/<wbr>isocpp.org/forum/=
#!topic/std-<wbr>proposals/r1pWsCgV550</a>&gt;&gt;<br>
<br>
=C2=A0 =C2=A0 =C2=A0&gt; that may be related, but I&#39;m not sure if my pr=
oposal completely<br>
=C2=A0 =C2=A0 fulfills<br>
=C2=A0 =C2=A0 =C2=A0&gt; the author&#39;s needs.<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 =C2=A0&gt; [[always_inline]] is a hint that would substitute<=
br>
=C2=A0 =C2=A0 =C2=A0&gt; __attribute__((always_inline))<wbr>, __forceinline=
 and similar<br>
=C2=A0 =C2=A0 compiler-specific<br>
=C2=A0 =C2=A0 =C2=A0&gt; hints. The intention is for it to be semantically =
different from<br>
=C2=A0 =C2=A0 C++&#39;s<br>
=C2=A0 =C2=A0 =C2=A0&gt; inline (e.g. as a mechanism for ODR realization) a=
nd be more on<br>
=C2=A0 =C2=A0 par with<br>
=C2=A0 =C2=A0 =C2=A0&gt; the compiler-dependent attributes it substitutes a=
nd C99&#39;s inline<br>
=C2=A0 =C2=A0 (e.g. try<br>
=C2=A0 =C2=A0 =C2=A0&gt; to inline the function call to avoid stack growth)=
..<br>
<br>
=C2=A0 =C2=A0 One of the points of always_inline is that the compiler ain&#=
39;t<br>
=C2=A0 =C2=A0 allowed to ignore<br>
=C2=A0 =C2=A0 it. As such it can&#39;t be an attribute.<br>
<br></span><span>
Thats not actually true.... always_inline means &quot;do inlining on this f=
unction even in O0&quot;.<br>
</span></blockquote>
<br>
It&#39;s not even that strong, not in case of gcc, at least. Basically, __a=
ttribute__((always_inline)) makes the function always inlined _when it is c=
onsidered for inlining by the optimizer_. -O0 disables the optimizer entire=
ly, making the attribute have no effect.</blockquote><div><br></div><div>Yo=
ur claim is trivially falsified:=C2=A0<a onmousedown=3D"this.href=3D&#39;ht=
tps://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2Fbahckm\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHMOXKVC7tDuzW39CIDwfOhri2XJQ&#39;;return =
true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A=
%2F%2Fgodbolt.org%2Fg%2Fbahckm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHMOX=
KVC7tDuzW39CIDwfOhri2XJQ&#39;;return true;" href=3D"https://godbolt.org/g/b=
ahckm" target=3D"_blank" rel=3D"nofollow">https://godbolt.<wbr>org/g/bahckm=
</a></div><div><br></div><div>And the GCC documentation explicitly covers t=
his, saying &quot;GCC does not inline any functions when not optimizing unl=
ess you specify the =E2=80=98always_inline=E2=80=99 attribute for the funct=
ion&quot;.</div><div><br></div><div>The actual rules for the attribute are =
(per the GCC documentation):</div><div><br></div><div>&quot;&quot;&quot;</d=
iv><div><div>always_inline</div><div><br></div><div>Generally, functions ar=
e not inlined unless optimization is specified. For functions declared inli=
ne, this attribute inlines the function independent of any restrictions tha=
t otherwise apply to inlining. Failure to inline such a function is diagnos=
ed as an error. Note that if such a function is called indirectly the compi=
ler may or may not inline it depending on optimization level and a failure =
to inline an indirect call may or may not be diagnosed.</div><div>&quot;&qu=
ot;&quot;</div></div></div></div></div></blockquote><div><br></div><div>Ric=
hard</div><div>I think the OP&#39;s idea to standardize always inline is a =
good one</div><div>I generally find the rules on when functions are inlined=
=C2=A0or not=C2=A0a bit confusing.</div><div>It seems it=C2=A0would be good=
 to standardize=C2=A0this area if possible?</div><div>In that aim, if we ar=
e going to address=C2=A0always inline which I&#39;d like, it seems it would=
 make sense=C2=A0for the Standard=C2=A0to=C2=A0address=C2=A0no inline. i.e.=
:</div><div><a href=3D"https://stackoverflow.com/questions/1474030/how-can-=
i-tell-gcc-not-to-inline-a-function">https://stackoverflow.com/questions/14=
74030/how-can-i-tell-gcc-not-to-inline-a-function</a></div><div><div><a hre=
f=3D"https://docs.microsoft.com/en-nz/cpp/cpp/noinline">https://docs.micros=
oft.com/en-nz/cpp/cpp/noinline</a>=C2=A0</div></div><div>msvc and gcc and c=
lang all seem to have=C2=A0noinline=C2=A0so it=C2=A0would be good if that c=
ould be standardized.</div><div><br></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/cd376bdd-6ac8-4da8-bf68-58555ae8087d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cd376bdd-6ac8-4da8-bf68-58555ae8087d=
%40isocpp.org</a>.<br />

------=_Part_1299_260002723.1516239313313--

------=_Part_1298_1203566440.1516239313312--

.

On Wednesday, 17 January 2018 13:35:53 PST Magnus Fromreide wrote:
> One of the points of always_inline is that the compiler ain't allowed to
> ignore it. As such it can't be an attribute.

Actually, it is, because inlining has no visible behaviour. A function that is
inlined behaves exactly the same way as its not-inlined copy. ODR still
applies.

The difference is whether it can be used without the inline keyword. The MSVC
__forceinline keyword replaces inline and forces the inlining, whereas the GCC
& family __attribute__((inline)) attribute is just a very strong hint, but
does not actually replace the inline keyword.

--
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/2470681.fzRteWNda1%40tjmaciei-mobl1.

.

On 2018-01-18 03:45, Thiago Macieira wrote:
> On Wednesday, 17 January 2018 13:35:53 PST Magnus Fromreide wrote:
>> One of the points of always_inline is that the compiler ain't allowed to
>> ignore it. As such it can't be an attribute.
>
> Actually, it is, because inlining has no visible behaviour. A function that is
> inlined behaves exactly the same way as its not-inlined copy. ODR still
> applies.
>
> The difference is whether it can be used without the inline keyword. The MSVC
> __forceinline keyword replaces inline and forces the inlining, whereas the GCC
> & family __attribute__((inline)) attribute is just a very strong hint, but
> does not actually replace the inline keyword.
>

The __forceinline doesn't actually force inlining either, it is just a
strong hint as well. In some cases the compiler is not ABLE to inline
some function, period.

Historically this has been everything from functions with a local array,
functions returning a large, complex object or an object with a throwing
copy constructor, to having local objects with a throwing destructor.

Where are we going to set the bar?


     Bo Persson

--
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/p3q5qn%244ok%241%40blaine.gmane.org.

.

On 01/18/18 03:23, Richard Smith wrote:
> On 17 January 2018 at 15:12, Andrey Semashev <andrey.semashev@gmail.com=
=20
> <mailto:andrey.semashev@gmail.com>> wrote:
>=20
>     On 01/18/18 01:52, Erich Keane wrote:
>=20
>         Thats not actually true.... always_inline means "do inlining on
>         this function even in O0".
>=20
>     It's not even that strong, not in case of gcc, at least. Basically,
>     __attribute__((always_inline)) makes the function always inlined
>     _when it is considered for inlining by the optimizer_. -O0 disables
>     the optimizer entirely, making the attribute have no effect.
>=20
> Your claim is trivially falsified: https://godbolt.org/g/bahckm
>=20
> And the GCC documentation explicitly covers this, saying "GCC does not=20
> inline any functions when not optimizing unless you specify the=20
> =E2=80=98always_inline=E2=80=99 attribute for the function".
>=20
> The actual rules for the attribute are (per the GCC documentation):
>=20
> """
> always_inline
>=20
> Generally, functions are not inlined unless optimization is specified.=20
> For functions declared inline, this attribute inlines the function=20
> independent of any restrictions that otherwise apply to inlining.=20
> Failure to inline such a function is diagnosed as an error. Note that if=
=20
> such a function is called indirectly the compiler may or may not inline=
=20
> it depending on optimization level and a failure to inline an indirect=20
> call may or may not be diagnosed.
> """

Hmm, I was sure I've seen cases when gcc would not inline functions with=20
-O0 and would inline on higher optimization levels. I think, it happened=20
in the context of Boost.Atomic and ultimately caused atomic operations=20
to always have seq_cst semantics regardless of what the user specified.=20
Maybe I'm misremembering the cause of the problem...

--=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/d6bc4990-a474-18b7-9556-12e607eaa17a%40gmail.com=
..

.

------=_Part_3913_1871541743.1516309013947
Content-Type: multipart/alternative;
 boundary="----=_Part_3914_682326886.1516309013947"

------=_Part_3914_682326886.1516309013947
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I agree with you. The language doesn't make it clear when inlining occurs,=
=20
and in fact I believe it does not even talk about such an optimization, so=
=20
a programmer must know some implementation detail to optimize in this case.

Still, inlining is something that all common compilers can do in one way or=
=20
another for a long time. If we have have [[deprecated]], [[noreturn]] and=
=20
others, as a way to standardize common compiler attributes, I don't see why=
=20
an [[always_inline]] (or whatever it's named) could be done as well. If the=
=20
compiler doesn't implement (or disables) inlining, I believe the attribute=
=20
can be safely ignored, and the function can be compiled as part of a=20
translation unit, respecting ODR as usual.

In the specific case of GCC's always_inline, I think [[always_inline]]=20
would be a misnomer, or some other attribute should be used, because GCC=20
diagnoses the program with an error in case inlining is not possible. I=20
believe this would change program semantics, wouldn't it? An=20
example: https://godbolt.org/g/eBqrBM (I understand this example is a bit=
=20
far-fetched, but still...)

If not an attribute, should the language introduce inlining at the language=
=20
level instead (I mean, as in C99)?

Em quarta-feira, 17 de janeiro de 2018 20:17:22 UTC-2, Nicol Bolas escreveu=
:
>
> On Wednesday, January 17, 2018 at 4:36:00 PM UTC-5, Magnus Fromreide wrot=
e:
>>
>> On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=B4a wrote:=
=20
>> > I searched in the forums but could not find a similar proposal.=20
>> Instead, I found=20
>> > a discussion=20
>> > <
>> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r1pWs=
CgV550>=20
>>
>> > that may be related, but I'm not sure if my proposal completely=20
>> fulfills=20
>> > the author's needs.=20
>> >=20
>> > [[always_inline]] is a hint that would substitute=20
>> > __attribute__((always_inline)), __forceinline and similar=20
>> compiler-specific=20
>> > hints. The intention is for it to be semantically different from C++'s=
=20
>> > inline (e.g. as a mechanism for ODR realization) and be more on par=20
>> with=20
>> > the compiler-dependent attributes it substitutes and C99's inline (e.g=
..=20
>> try=20
>> > to inline the function call to avoid stack growth).=20
>>
>> One of the points of always_inline is that the compiler ain't allowed to=
=20
>> ignore=20
>> it. As such it can't be an attribute.=20
>>
>
> If the compiler doesn't implement the concept of `always_inline`, then I=
=20
> don't see the problem. That is, if the compiler has no compiler-specific=
=20
> inlining attribute, then it shouldn't be a surprise that [[always_inline]=
]=20
> won't inline it either.
>
> What we want is a cross-platform way to say what we can already say.=20
> People who genuinely need forced inlining use compilers that support forc=
ed=20
> inlining. If some compiler can't do it, they simply won't use that compil=
er.
>
> This is a QOI issue. Let compilers handle it as they see fit.
>

--=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/40e9d970-2d26-4dbe-89cd-54d1be5f9a94%40isocpp.or=
g.

------=_Part_3914_682326886.1516309013947
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I agree with you. The language doesn&#39;t make it clear w=
hen inlining occurs, and in fact I believe it does not even talk about such=
 an optimization, so a programmer must know some implementation detail to o=
ptimize in this case.<div><br></div><div>Still, inlining is something that =
all common compilers can do in one way or another for a long time. If we ha=
ve have [[deprecated]], [[noreturn]] and others, as a way to standardize co=
mmon compiler attributes, I don&#39;t see why an [[always_inline]] (or what=
ever it&#39;s named) could be done as well. If the compiler doesn&#39;t imp=
lement (or disables) inlining, I believe the attribute can be safely ignore=
d, and the function can be compiled as part of a translation unit, respecti=
ng ODR as usual.<div><div><br></div><div>In the specific case of GCC&#39;s =
always_inline, I think [[always_inline]] would be a misnomer, or some other=
 attribute should be used, because GCC diagnoses the program with an error =
in case inlining is not possible. I believe this would change program seman=
tics, wouldn&#39;t it? An example:=C2=A0https://godbolt.org/g/eBqrBM (I und=
erstand this example is a bit far-fetched, but still...)</div><div><br></di=
v><div>If not an attribute, should the language introduce inlining at the l=
anguage level instead (I mean, as in C99)?</div><div><br>Em quarta-feira, 1=
7 de janeiro de 2018 20:17:22 UTC-2, Nicol Bolas  escreveu:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr">On Wednesday, January 17, 201=
8 at 4:36:00 PM UTC-5, Magnus Fromreide wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=B4=
a wrote:
<br>&gt; I searched in the forums but could not find a similar proposal. In=
stead, I found=20
<br>&gt; a discussion=20
<br>&gt; &lt;<a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topi=
c/std-proposals/r1pWsCgV550" rel=3D"nofollow" target=3D"_blank" onmousedown=
=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!topic/s=
td-proposals/r1pWsCgV550&#39;;return true;" onclick=3D"this.href=3D&#39;htt=
ps://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r1pWsCgV550=
&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org/forum/#!top=
ic/std-<wbr>proposals/r1pWsCgV550</a>&gt;=20
<br>&gt; that may be related, but I&#39;m not sure if my proposal completel=
y fulfills=20
<br>&gt; the author&#39;s needs.
<br>&gt;=20
<br>&gt; [[always_inline]] is a hint that would substitute=20
<br>&gt; __attribute__((always_inline))<wbr>, __forceinline and similar com=
piler-specific=20
<br>&gt; hints. The intention is for it to be semantically different from C=
++&#39;s=20
<br>&gt; inline (e.g. as a mechanism for ODR realization) and be more on pa=
r with=20
<br>&gt; the compiler-dependent attributes it substitutes and C99&#39;s inl=
ine (e.g. try=20
<br>&gt; to inline the function call to avoid stack growth).
<br>
<br>One of the points of always_inline is that the compiler ain&#39;t allow=
ed to ignore
<br>it. As such it can&#39;t be an attribute.
<br></blockquote><div><br></div><div>If the compiler doesn&#39;t implement =
the concept of `always_inline`, then I don&#39;t see the problem. That is, =
if the compiler has no compiler-specific inlining attribute, then it should=
n&#39;t be a surprise that [[always_inline]] won&#39;t inline it either.</d=
iv><div><br></div><div>What we want is a cross-platform way to say what we =
can already say. People who genuinely need forced inlining use compilers th=
at support forced inlining. If some compiler can&#39;t do it, they simply w=
on&#39;t use that compiler.</div><div><br></div><div>This is a QOI issue. L=
et compilers handle it as they see fit.<br></div></div></blockquote></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/40e9d970-2d26-4dbe-89cd-54d1be5f9a94%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/40e9d970-2d26-4dbe-89cd-54d1be5f9a94=
%40isocpp.org</a>.<br />

------=_Part_3914_682326886.1516309013947--

------=_Part_3913_1871541743.1516309013947--

.

------=_Part_3970_1795712941.1516309066454
Content-Type: multipart/alternative;
 boundary="----=_Part_3971_1904190624.1516309066455"

------=_Part_3971_1904190624.1516309066455
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I fully agree with that. In fact, I was thinking about adding this=20
suggestion to the discussion. :)

Em quarta-feira, 17 de janeiro de 2018 23:35:13 UTC-2, gmis...@gmail.com=20
escreveu:
>
>
>
> On Thursday, January 18, 2018 at 1:23:32 PM UTC+13, Richard Smith wrote:
>>
>> On 17 January 2018 at 15:12, Andrey Semashev <andrey....@gmail.com>=20
>> wrote:
>>
>>> On 01/18/18 01:52, Erich Keane wrote:
>>>
>>>> On Wednesday, January 17, 2018 at 1:36:00 PM UTC-8, Magnus Fromreide=
=20
>>>> wrote:
>>>>     On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=B4a =
wrote:
>>>>      > I searched in the forums but could not find a similar proposal.
>>>>     Instead, I found
>>>>      > a discussion
>>>>      >
>>>>     <
>>>> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r1p=
WsCgV550
>>>>     <
>>>> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r1p=
WsCgV550
>>>> >>
>>>>
>>>>      > that may be related, but I'm not sure if my proposal completely
>>>>     fulfills
>>>>      > the author's needs.
>>>>      >
>>>>      > [[always_inline]] is a hint that would substitute
>>>>      > __attribute__((always_inline)), __forceinline and similar
>>>>     compiler-specific
>>>>      > hints. The intention is for it to be semantically different fro=
m
>>>>     C++'s
>>>>      > inline (e.g. as a mechanism for ODR realization) and be more on
>>>>     par with
>>>>      > the compiler-dependent attributes it substitutes and C99's inli=
ne
>>>>     (e.g. try
>>>>      > to inline the function call to avoid stack growth).
>>>>
>>>>     One of the points of always_inline is that the compiler ain't
>>>>     allowed to ignore
>>>>     it. As such it can't be an attribute.
>>>>
>>>> Thats not actually true.... always_inline means "do inlining on this=
=20
>>>> function even in O0".
>>>>
>>>
>>> It's not even that strong, not in case of gcc, at least. Basically,=20
>>> __attribute__((always_inline)) makes the function always inlined _when =
it=20
>>> is considered for inlining by the optimizer_. -O0 disables the optimize=
r=20
>>> entirely, making the attribute have no effect.
>>
>>
>> Your claim is trivially falsified: https://godbolt.org/g/bahckm
>>
>> And the GCC documentation explicitly covers this, saying "GCC does not=
=20
>> inline any functions when not optimizing unless you specify the=20
>> =E2=80=98always_inline=E2=80=99 attribute for the function".
>>
>> The actual rules for the attribute are (per the GCC documentation):
>>
>> """
>> always_inline
>>
>> Generally, functions are not inlined unless optimization is specified.=
=20
>> For functions declared inline, this attribute inlines the function=20
>> independent of any restrictions that otherwise apply to inlining. Failur=
e=20
>> to inline such a function is diagnosed as an error. Note that if such a=
=20
>> function is called indirectly the compiler may or may not inline it=20
>> depending on optimization level and a failure to inline an indirect call=
=20
>> may or may not be diagnosed.
>> """
>>
>
> Richard
> I think the OP's idea to standardize always inline is a good one
> I generally find the rules on when functions are inlined or not a bit=20
> confusing.
> It seems it would be good to standardize this area if possible?
> In that aim, if we are going to address always inline which I'd like, it=
=20
> seems it would make sense for the Standard to address no inline. i.e.:
>
> https://stackoverflow.com/questions/1474030/how-can-i-tell-gcc-not-to-inl=
ine-a-function
> https://docs.microsoft.com/en-nz/cpp/cpp/noinline=20
> msvc and gcc and clang all seem to have noinline so it would be good if=
=20
> that could be standardized.
>
>

--=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/bec340ae-0a9f-4e23-b6a1-c57b4ba15d05%40isocpp.or=
g.

------=_Part_3971_1904190624.1516309066455
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I fully agree with that. In fact, I was thinking about add=
ing this suggestion to the discussion. :)<br><br>Em quarta-feira, 17 de jan=
eiro de 2018 23:35:13 UTC-2, gmis...@gmail.com  escreveu:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>On Thursday, January 1=
8, 2018 at 1:23:32 PM UTC+13, Richard Smith wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-col=
or:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On 17 January 2018 at 15:12, Andre=
y Semashev <span dir=3D"ltr">&lt;<a rel=3D"nofollow">andrey....@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border=
-left-width:1px;border-left-style:solid"><span>On 01/18/18 01:52, Erich Kea=
ne wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;b=
order-left-style:solid"><span>
On Wednesday, January 17, 2018 at 1:36:00 PM UTC-8, Magnus Fromreide wrote:=
<br>
=C2=A0 =C2=A0 On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=
=B4a wrote:<br>
=C2=A0 =C2=A0 =C2=A0&gt; I searched in the forums but could not find a simi=
lar proposal.<br>
=C2=A0 =C2=A0 Instead, I found<br>
=C2=A0 =C2=A0 =C2=A0&gt; a discussion<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 &lt;<a href=3D"https://groups.google.com/a/isocpp.org/forum/#=
!topic/std-proposals/r1pWsCgV550" rel=3D"nofollow" target=3D"_blank" onmous=
edown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!to=
pic/std-proposals/r1pWsCgV550&#39;;return true;" onclick=3D"this.href=3D&#3=
9;https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r1pWsC=
gV550&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org/forum/=
#!topic/std-<wbr>proposals/r1pWsCgV550</a><br>
=C2=A0 =C2=A0 &lt;<a href=3D"https://groups.google.com/a/isocpp.org/forum/#=
!topic/std-proposals/r1pWsCgV550" rel=3D"nofollow" target=3D"_blank" onmous=
edown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!to=
pic/std-proposals/r1pWsCgV550&#39;;return true;" onclick=3D"this.href=3D&#3=
9;https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r1pWsC=
gV550&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org/forum/=
#!topic/std-<wbr>proposals/r1pWsCgV550</a>&gt;&gt;<br>
<br>
=C2=A0 =C2=A0 =C2=A0&gt; that may be related, but I&#39;m not sure if my pr=
oposal completely<br>
=C2=A0 =C2=A0 fulfills<br>
=C2=A0 =C2=A0 =C2=A0&gt; the author&#39;s needs.<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 =C2=A0&gt; [[always_inline]] is a hint that would substitute<=
br>
=C2=A0 =C2=A0 =C2=A0&gt; __attribute__((always_inline))<wbr>, __forceinline=
 and similar<br>
=C2=A0 =C2=A0 compiler-specific<br>
=C2=A0 =C2=A0 =C2=A0&gt; hints. The intention is for it to be semantically =
different from<br>
=C2=A0 =C2=A0 C++&#39;s<br>
=C2=A0 =C2=A0 =C2=A0&gt; inline (e.g. as a mechanism for ODR realization) a=
nd be more on<br>
=C2=A0 =C2=A0 par with<br>
=C2=A0 =C2=A0 =C2=A0&gt; the compiler-dependent attributes it substitutes a=
nd C99&#39;s inline<br>
=C2=A0 =C2=A0 (e.g. try<br>
=C2=A0 =C2=A0 =C2=A0&gt; to inline the function call to avoid stack growth)=
..<br>
<br>
=C2=A0 =C2=A0 One of the points of always_inline is that the compiler ain&#=
39;t<br>
=C2=A0 =C2=A0 allowed to ignore<br>
=C2=A0 =C2=A0 it. As such it can&#39;t be an attribute.<br>
<br></span><span>
Thats not actually true.... always_inline means &quot;do inlining on this f=
unction even in O0&quot;.<br>
</span></blockquote>
<br>
It&#39;s not even that strong, not in case of gcc, at least. Basically, __a=
ttribute__((always_inline)) makes the function always inlined _when it is c=
onsidered for inlining by the optimizer_. -O0 disables the optimizer entire=
ly, making the attribute have no effect.</blockquote><div><br></div><div>Yo=
ur claim is trivially falsified:=C2=A0<a href=3D"https://godbolt.org/g/bahc=
km" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http=
s://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2Fbahckm\x26sa\x3=
dD\x26sntz\x3d1\x26usg\x3dAFQjCNHMOXKVC7tDuzW39CIDwfOhri2XJQ&#39;;return tr=
ue;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2=
F%2Fgodbolt.org%2Fg%2Fbahckm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHMOXKV=
C7tDuzW39CIDwfOhri2XJQ&#39;;return true;">https://godbolt.<wbr>org/g/bahckm=
</a></div><div><br></div><div>And the GCC documentation explicitly covers t=
his, saying &quot;GCC does not inline any functions when not optimizing unl=
ess you specify the =E2=80=98always_inline=E2=80=99 attribute for the funct=
ion&quot;.</div><div><br></div><div>The actual rules for the attribute are =
(per the GCC documentation):</div><div><br></div><div>&quot;&quot;&quot;</d=
iv><div><div>always_inline</div><div><br></div><div>Generally, functions ar=
e not inlined unless optimization is specified. For functions declared inli=
ne, this attribute inlines the function independent of any restrictions tha=
t otherwise apply to inlining. Failure to inline such a function is diagnos=
ed as an error. Note that if such a function is called indirectly the compi=
ler may or may not inline it depending on optimization level and a failure =
to inline an indirect call may or may not be diagnosed.</div><div>&quot;&qu=
ot;&quot;</div></div></div></div></div></blockquote><div><br></div><div>Ric=
hard</div><div>I think the OP&#39;s idea to standardize always inline is a =
good one</div><div>I generally find the rules on when functions are inlined=
=C2=A0or not=C2=A0a bit confusing.</div><div>It seems it=C2=A0would be good=
 to standardize=C2=A0this area if possible?</div><div>In that aim, if we ar=
e going to address=C2=A0always inline which I&#39;d like, it seems it would=
 make sense=C2=A0for the Standard=C2=A0to=C2=A0address=C2=A0no inline. i.e.=
:</div><div><a href=3D"https://stackoverflow.com/questions/1474030/how-can-=
i-tell-gcc-not-to-inline-a-function" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2F=
stackoverflow.com%2Fquestions%2F1474030%2Fhow-can-i-tell-gcc-not-to-inline-=
a-function\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFNY_8-kuzNBMj5cOu8s6A7m2=
mkwg&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/=
url?q\x3dhttps%3A%2F%2Fstackoverflow.com%2Fquestions%2F1474030%2Fhow-can-i-=
tell-gcc-not-to-inline-a-function\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF=
NY_8-kuzNBMj5cOu8s6A7m2mkwg&#39;;return true;">https://stackoverflow.com/<w=
br>questions/1474030/how-can-i-<wbr>tell-gcc-not-to-inline-a-<wbr>function<=
/a></div><div><div><a href=3D"https://docs.microsoft.com/en-nz/cpp/cpp/noin=
line" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ht=
tps://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.microsoft.com%2Fen-nz%2Fcp=
p%2Fcpp%2Fnoinline\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFmb9CeMPLTPFFGU-=
BXucHshKb9uQ&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goo=
gle.com/url?q\x3dhttps%3A%2F%2Fdocs.microsoft.com%2Fen-nz%2Fcpp%2Fcpp%2Fnoi=
nline\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFmb9CeMPLTPFFGU-BXucHshKb9uQ&=
#39;;return true;">https://docs.microsoft.com/en-<wbr>nz/cpp/cpp/noinline</=
a>=C2=A0</div></div><div>msvc and gcc and clang all seem to have=C2=A0noinl=
ine=C2=A0so it=C2=A0would be good if that could be standardized.</div><div>=
<br></div></div></blockquote></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/bec340ae-0a9f-4e23-b6a1-c57b4ba15d05%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bec340ae-0a9f-4e23-b6a1-c57b4ba15d05=
%40isocpp.org</a>.<br />

------=_Part_3971_1904190624.1516309066455--

------=_Part_3970_1795712941.1516309066454--

.

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

On Thu, Jan 18, 2018 at 3:56 PM, Fl=C3=A1vio Lisb=C3=B4a <flisboa.costa@gma=
il.com>
wrote:

> I agree with you. The language doesn't make it clear when inlining occurs=
,
> and in fact I believe it does not even talk about such an optimization, s=
o
> a programmer must know some implementation detail to optimize in this cas=
e.
>
> Still, inlining is something that all common compilers can do in one way
> or another for a long time. If we have have [[deprecated]], [[noreturn]]
> and others, as a way to standardize common compiler attributes, I don't s=
ee
> why an [[always_inline]] (or whatever it's named) could be done as well. =
If
> the compiler doesn't implement (or disables) inlining, I believe the
> attribute can be safely ignored, and the function can be compiled as part
> of a translation unit, respecting ODR as usual.
>
> In the specific case of GCC's always_inline, I think [[always_inline]]
> would be a misnomer, or some other attribute should be used, because GCC
> diagnoses the program with an error in case inlining is not possible. I
> believe this would change program semantics, wouldn't it? An example:
> https://godbolt.org/g/eBqrBM (I understand this example is a bit
> far-fetched, but still...)
>
> If not an attribute, should the language introduce inlining at the
> language level instead (I mean, as in C99)?
>


It CANNOT be done at the language level.  It has no meaning at the language
level.



--=20
Be seeing you,
Tony

--=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/CAOHCbiv8c5_u6JuKN1WDJVXiJez65bs9jjaSD82zfNZ-rHp=
bcw%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Jan 18, 2018 at 3:56 PM, Fl=C3=A1vio Lisb=C3=B4a <span dir=3D"l=
tr">&lt;<a href=3D"mailto:flisboa.costa@gmail.com" target=3D"_blank">flisbo=
a.costa@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr">I agree with you. The language doesn&#39;t make it clear wh=
en inlining occurs, and in fact I believe it does not even talk about such =
an optimization, so a programmer must know some implementation detail to op=
timize in this case.<div><br></div><div>Still, inlining is something that a=
ll common compilers can do in one way or another for a long time. If we hav=
e have [[deprecated]], [[noreturn]] and others, as a way to standardize com=
mon compiler attributes, I don&#39;t see why an [[always_inline]] (or whate=
ver it&#39;s named) could be done as well. If the compiler doesn&#39;t impl=
ement (or disables) inlining, I believe the attribute can be safely ignored=
, and the function can be compiled as part of a translation unit, respectin=
g ODR as usual.<div><div><br></div><div>In the specific case of GCC&#39;s a=
lways_inline, I think [[always_inline]] would be a misnomer, or some other =
attribute should be used, because GCC diagnoses the program with an error i=
n case inlining is not possible. I believe this would change program semant=
ics, wouldn&#39;t it? An example:=C2=A0<a href=3D"https://godbolt.org/g/eBq=
rBM" target=3D"_blank">https://godbolt.org/<wbr>g/eBqrBM</a> (I understand =
this example is a bit far-fetched, but still...)</div><div><br></div><div>I=
f not an attribute, should the language introduce inlining at the language =
level instead (I mean, as in C99)?</div></div></div></div></blockquote><div=
><br></div><div><br></div><div>It CANNOT be done at the language level.=C2=
=A0 It has no meaning at the language level.</div><div><br></div><br clear=
=3D"all"></div><br>-- <br><div class=3D"gmail_signature" data-smartmail=3D"=
gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></di=
v></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/CAOHCbiv8c5_u6JuKN1WDJVXiJez65bs9jjaS=
D82zfNZ-rHpbcw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiv8c5_u6JuK=
N1WDJVXiJez65bs9jjaSD82zfNZ-rHpbcw%40mail.gmail.com</a>.<br />

--001a113598d0dc3b58056313e6ca--

.

On Wed, Jan 17, 2018 at 02:17:22PM -0800, Nicol Bolas wrote:
> On Wednesday, January 17, 2018 at 4:36:00 PM UTC-5, Magnus Fromreide wrot=
e:
> >
> > On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=B4a wrote=
:=20
> > > I searched in the forums but could not find a similar proposal. Inste=
ad,=20
> > I found=20
> > > a discussion=20
> > > <
> > https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r1pW=
sCgV550>=20
> >
> > > that may be related, but I'm not sure if my proposal completely fulfi=
lls=20
> > > the author's needs.=20
> > >=20
> > > [[always_inline]] is a hint that would substitute=20
> > > __attribute__((always_inline)), __forceinline and similar=20
> > compiler-specific=20
> > > hints. The intention is for it to be semantically different from C++'=
s=20
> > > inline (e.g. as a mechanism for ODR realization) and be more on par w=
ith=20
> > > the compiler-dependent attributes it substitutes and C99's inline (e.=
g.=20
> > try=20
> > > to inline the function call to avoid stack growth).=20
> >
> > One of the points of always_inline is that the compiler ain't allowed t=
o=20
> > ignore=20
> > it. As such it can't be an attribute.=20
> >
>=20
> If the compiler doesn't implement the concept of `always_inline`, then I=
=20
> don't see the problem. That is, if the compiler has no compiler-specific=
=20
> inlining attribute, then it shouldn't be a surprise that [[always_inline]=
]=20
> won't inline it either.

But an always_inline attribute that fails to always inline is obviously
misnamed.

> What we want is a cross-platform way to say what we can already say.

I agree that this would be a good thing, but there seem to be some disagree=
ment
regarding what it is we want to say here.

> People=20
> who genuinely need forced inlining use compilers that support forced=20
> inlining. If some compiler can't do it, they simply won't use that compil=
er.

So, you are telling me that I should use some magic at other places to dete=
ct
if [[always_inline]] actually do inline at all times as opposed to the
current state where I have to do some compiler-specific trickery.

I would then claim that

#ifdef __GNUC__
#define ALWAYS_INLINE __attribute__((always_inline))
#else
#error "No ALWAYS_INLINE on this compiler"
#endif

is better than the proposed

[[always_inline]]

since the former gives a hard error when the compiler ain't supporting it
while the latter is mandated to be silently ignored.

If I want to send the compiler a hint that some function should be inlined =
then
the language already provides that via the "inline" keyword so this propose=
d
[[always_inline]] will just provide a strength of the inlining hint,

Now, that is also a resonable idea but then it should be an attribute on th=
e
inline keyword since that is what it affects:

inline [[inline_harder]] void fun() { /* */ }

but the name "always_inline" should not be used unlees you have the GCC
semantics of it beeing an error to fail to inline the function and in that
case it can't be an attribute.

I think one could express this in standardeese like this:

* The "always_inline" keyword ensures that the function declared so have no
  linkage.

This is similar to how "static" ensures no external linkage or how "inline"
allows vague linkage.

> This is a QOI issue. Let compilers handle it as they see fit.

I'd rather se no standardization here than a standardization of a broken
concept.

/MF

--=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/20180119071748.GA22633%40noemi.bahnhof.se.

.

On 01/19/18 10:17, Magnus Fromreide wrote:
> On Wed, Jan 17, 2018 at 02:17:22PM -0800, Nicol Bolas wrote:
>> On Wednesday, January 17, 2018 at 4:36:00 PM UTC-5, Magnus Fromreide wro=
te:
>>>
>>> On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=B4a wrote=
:
>>>> I searched in the forums but could not find a similar proposal. Instea=
d,
>>> I found
>>>> a discussion
>>>> <
>>> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r1pW=
sCgV550>
>>>
>>>> that may be related, but I'm not sure if my proposal completely fulfil=
ls
>>>> the author's needs.
>>>>
>>>> [[always_inline]] is a hint that would substitute
>>>> __attribute__((always_inline)), __forceinline and similar
>>> compiler-specific
>>>> hints. The intention is for it to be semantically different from C++'s
>>>> inline (e.g. as a mechanism for ODR realization) and be more on par wi=
th
>>>> the compiler-dependent attributes it substitutes and C99's inline (e.g=
..
>>> try
>>>> to inline the function call to avoid stack growth).
>>>
>>> One of the points of always_inline is that the compiler ain't allowed t=
o
>>> ignore
>>> it. As such it can't be an attribute.
>>>
>>
>> If the compiler doesn't implement the concept of `always_inline`, then I
>> don't see the problem. That is, if the compiler has no compiler-specific
>> inlining attribute, then it shouldn't be a surprise that [[always_inline=
]]
>> won't inline it either.
>=20
> But an always_inline attribute that fails to always inline is obviously
> misnamed.
>=20
>> What we want is a cross-platform way to say what we can already say.
>=20
> I agree that this would be a good thing, but there seem to be some disagr=
eement
> regarding what it is we want to say here.
>=20
>> People
>> who genuinely need forced inlining use compilers that support forced
>> inlining. If some compiler can't do it, they simply won't use that compi=
ler.
>=20
> So, you are telling me that I should use some magic at other places to de=
tect
> if [[always_inline]] actually do inline at all times as opposed to the
> current state where I have to do some compiler-specific trickery.

That's not necessarily the case. The program can be written to be=20
portable across compilers and use [[always_inline]] or whatever the=20
attribute name is. Users can test their compiler and see that it doesn't=20
actually inline the functions. Arguably, this results in bad=20
performance, so the users probably pick another compiler.

The point here is that there is benefit for the program developers=20
because they can just use [[always_inline]] portably, without having to=20
check for the particular compilers, possibly missing out some of them.=20
There may be benefit for users of the program, if their compiler was not=20
previously supported by it, when it did compiler-specific tricks like=20
__forceinline. For those unlucky few whose compiler genuinely does not=20
support forced inlining nothing changes - they had poor performance=20
before and they still have it now.

Forced inlining is not something unique. All major compilers have=20
support for it, so having it available under the same name would be useful.

--=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/a1b47ee9-167c-dec4-c410-c0bc85a0084d%40gmail.com=
..

.

------=_Part_338_531550177.1516397970904
Content-Type: multipart/alternative;
 boundary="----=_Part_339_1869184382.1516397970904"

------=_Part_339_1869184382.1516397970904
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Friday, January 19, 2018 at 2:17:53 AM UTC-5, Magnus Fromreide wrote:
>
> On Wed, Jan 17, 2018 at 02:17:22PM -0800, Nicol Bolas wrote:=20
> > On Wednesday, January 17, 2018 at 4:36:00 PM UTC-5, Magnus Fromreide=20
> wrote:=20
> > >=20
> > > On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=B4a wro=
te:=20
> > > > I searched in the forums but could not find a similar proposal.=20
> Instead,=20
> > > I found=20
> > > > a discussion=20
> > > > <=20
> > >=20
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r1pWsC=
gV550>=20
>
> > >=20
> > > > that may be related, but I'm not sure if my proposal completely=20
> fulfills=20
> > > > the author's needs.=20
> > > >=20
> > > > [[always_inline]] is a hint that would substitute=20
> > > > __attribute__((always_inline)), __forceinline and similar=20
> > > compiler-specific=20
> > > > hints. The intention is for it to be semantically different from=20
> C++'s=20
> > > > inline (e.g. as a mechanism for ODR realization) and be more on par=
=20
> with=20
> > > > the compiler-dependent attributes it substitutes and C99's inline=
=20
> (e.g.=20
> > > try=20
> > > > to inline the function call to avoid stack growth).=20
> > >=20
> > > One of the points of always_inline is that the compiler ain't allowed=
=20
> to=20
> > > ignore=20
> > > it. As such it can't be an attribute.=20
> > >=20
> >=20
> > If the compiler doesn't implement the concept of `always_inline`, then =
I=20
> > don't see the problem. That is, if the compiler has no compiler-specifi=
c=20
> > inlining attribute, then it shouldn't be a surprise that=20
> [[always_inline]]=20
> > won't inline it either.=20
>
> But an always_inline attribute that fails to always inline is obviously=
=20
> misnamed.
>

But since you cannot tell whether a function is inlined or not, what does=
=20
it matter to the standard?

> What we want is a cross-platform way to say what we can already say.=20
>
> I agree that this would be a good thing, but there seem to be some=20
> disagreement=20
> regarding what it is we want to say here.=20
>
> > People=20
> > who genuinely need forced inlining use compilers that support forced=20
> > inlining. If some compiler can't do it, they simply won't use that=20
> compiler.=20
>
> So, you are telling me that I should use some magic at other places to=20
> detect=20
> if [[always_inline]] actually do inline at all times as opposed to the=20
> current state where I have to do some compiler-specific trickery.
>

But here's the thing: the cases you're talking about would provoke a*=20
compile error* if it wasn't inlined. Since the standard cannot define the=
=20
circumstances where this could happen, there is no *portable* way for you=
=20
to enforce inlining to such a degree.

That is, consider this function:

[[always_inline]] void foo()
{
  ...
}

What is the `...` here that could cause use of this function to fail to=20
compile? If you can't spell that out, then any code you write there is=20
non-portable.

I would then claim that=20
>
> #ifdef __GNUC__=20
> #define ALWAYS_INLINE __attribute__((always_inline))=20
> #else=20
> #error "No ALWAYS_INLINE on this compiler"=20
> #endif=20
>
> is better than the proposed=20
>
> [[always_inline]]=20
>
> since the former gives a hard error when the compiler ain't supporting it=
=20
> while the latter is mandated to be silently ignored.

=20

If I want to send the compiler a hint that some function should be inlined=
=20
> then=20
> the language already provides that via the "inline" keyword so this=20
> proposed=20
> [[always_inline]] will just provide a strength of the inlining hint,
>

Yeah, that's not what the `inline` keyword does=20
<http://en.cppreference.com/w/cpp/language/inline>.
=20

> Now, that is also a resonable idea but then it should be an attribute on=
=20
> the=20
> inline keyword since that is what it affects:=20
>
> inline [[inline_harder]] void fun() { /* */ }=20
>
> but the name "always_inline" should not be used unlees you have the GCC=
=20
> semantics of it beeing an error to fail to inline the function and in tha=
t=20
> case it can't be an attribute.=20
>
> I think one could express this in standardeese like this:=20
>
> * The "always_inline" keyword ensures that the function declared so have=
=20
> no=20
>   linkage.


> This is similar to how "static" ensures no external linkage or how=20
> "inline"=20
> allows vague linkage.


`inline` does not cause "vague linkage". It cause internal linkage. That's=
=20
a very specific kind of linkage.

Also, I fail to see how "no linkage" is equivalent to enforced inlining. In=
=20
order to enforce inlining, you have to say something about whether inlining=
=20
is possible in specific circumstances. And what inlining is, for that=20
matter.

Linkage is ultimately about the accessibility of the name of an entity.=20
Forced inlining is about more than that; here, you're saying that the=20
entity flat-out doesn't exist.

> This is a QOI issue. Let compilers handle it as they see fit.=20
>
> I'd rather se no standardization here than a standardization of a broken=
=20
> concept.
>

And yet you're fine with GCC's "always_inline" which, as previously shown,=
=20
isn't *always* inline so much as "almost always inline".

--=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/3d587d63-0827-40e8-9825-9bbc8fa04c55%40isocpp.or=
g.

------=_Part_339_1869184382.1516397970904
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, January 19, 2018 at 2:17:53 AM UTC-5, M=
agnus Fromreide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, =
Jan 17, 2018 at 02:17:22PM -0800, Nicol Bolas wrote:
<br>&gt; On Wednesday, January 17, 2018 at 4:36:00 PM UTC-5, Magnus Fromrei=
de wrote:
<br>&gt; &gt;
<br>&gt; &gt; On Wed, Jan 17, 2018 at 10:47:09AM -0800, Fl=C3=A1vio Lisb=C3=
=B4a wrote:=20
<br>&gt; &gt; &gt; I searched in the forums but could not find a similar pr=
oposal. Instead,=20
<br>&gt; &gt; I found=20
<br>&gt; &gt; &gt; a discussion=20
<br>&gt; &gt; &gt; &lt;
<br>&gt; &gt; <a onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/forum/#!topic/std-proposals/r1pWsCgV550&#39;;return true;" onc=
lick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!top=
ic/std-proposals/r1pWsCgV550&#39;;return true;" href=3D"https://groups.goog=
le.com/a/isocpp.org/forum/#!topic/std-proposals/r1pWsCgV550" target=3D"_bla=
nk" rel=3D"nofollow">https://groups.google.com/a/<wbr>isocpp.org/forum/#!to=
pic/std-<wbr>proposals/r1pWsCgV550</a>&gt;=20
<br>&gt; &gt;
<br>&gt; &gt; &gt; that may be related, but I&#39;m not sure if my proposal=
 completely fulfills=20
<br>&gt; &gt; &gt; the author&#39;s needs.=20
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; [[always_inline]] is a hint that would substitute=20
<br>&gt; &gt; &gt; __attribute__((always_inline))<wbr>, __forceinline and s=
imilar=20
<br>&gt; &gt; compiler-specific=20
<br>&gt; &gt; &gt; hints. The intention is for it to be semantically differ=
ent from C++&#39;s=20
<br>&gt; &gt; &gt; inline (e.g. as a mechanism for ODR realization) and be =
more on par with=20
<br>&gt; &gt; &gt; the compiler-dependent attributes it substitutes and C99=
&#39;s inline (e.g.=20
<br>&gt; &gt; try=20
<br>&gt; &gt; &gt; to inline the function call to avoid stack growth).=20
<br>&gt; &gt;
<br>&gt; &gt; One of the points of always_inline is that the compiler ain&#=
39;t allowed to=20
<br>&gt; &gt; ignore=20
<br>&gt; &gt; it. As such it can&#39;t be an attribute.=20
<br>&gt; &gt;
<br>&gt;=20
<br>&gt; If the compiler doesn&#39;t implement the concept of `always_inlin=
e`, then I=20
<br>&gt; don&#39;t see the problem. That is, if the compiler has no compile=
r-specific=20
<br>&gt; inlining attribute, then it shouldn&#39;t be a surprise that [[alw=
ays_inline]]=20
<br>&gt; won&#39;t inline it either.
<br>
<br>But an always_inline attribute that fails to always inline is obviously
<br>misnamed.<br></blockquote><div><br></div><div>But since you cannot tell=
 whether a function is inlined or not, what does it matter to the standard?=
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; What=
 we want is a cross-platform way to say what we can already say.
<br>
<br>I agree that this would be a good thing, but there seem to be some disa=
greement
<br>regarding what it is we want to say here.
<br>
<br>&gt; People=20
<br>&gt; who genuinely need forced inlining use compilers that support forc=
ed=20
<br>&gt; inlining. If some compiler can&#39;t do it, they simply won&#39;t =
use that compiler.
<br>
<br>So, you are telling me that I should use some magic at other places to =
detect
<br>if [[always_inline]] actually do inline at all times as opposed to the
<br>current state where I have to do some compiler-specific trickery.<br></=
blockquote><div><br></div><div>But here&#39;s the thing: the cases you&#39;=
re talking about would provoke a<i> compile error</i> if it wasn&#39;t inli=
ned. Since the standard cannot define the circumstances where this could ha=
ppen, there is no <i>portable</i> way for you to enforce inlining to such a=
 degree.</div><div><br></div><div>That is, consider this function:</div><di=
v><br></div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, =
187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span class=3D"styl=
ed-by-prettify" style=3D"color: #660;">[[</span><span class=3D"styled-by-pr=
ettify" style=3D"color: #000;">always_inline</span><span class=3D"styled-by=
-prettify" style=3D"color: #660;">]]</span><span class=3D"styled-by-prettif=
y" style=3D"color: #000;"> </span><span class=3D"styled-by-prettify" style=
=3D"color: #008;">void</span><span class=3D"styled-by-prettify" style=3D"co=
lor: #000;"> foo</span><span class=3D"styled-by-prettify" style=3D"color: #=
660;">()</span><span class=3D"styled-by-prettify" style=3D"color: #000;"><b=
r></span><span class=3D"styled-by-prettify" style=3D"color: #660;">{</span>=
<span class=3D"styled-by-prettify" style=3D"color: #000;"><br>=C2=A0 </span=
><span class=3D"styled-by-prettify" style=3D"color: #660;">...</span><span =
class=3D"styled-by-prettify" style=3D"color: #000;"><br></span><span class=
=3D"styled-by-prettify" style=3D"color: #660;">}</span></div></code></div><=
div><br></div><div>What is the `...` here that could cause use of this func=
tion to fail to compile? If you can&#39;t spell that out, then any code you=
 write there is non-portable.</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">I would then claim that
<br>
<br>#ifdef __GNUC__
<br>#define ALWAYS_INLINE __attribute__((always_inline))
<br>#else
<br>#error &quot;No ALWAYS_INLINE on this compiler&quot;
<br>#endif
<br>
<br>is better than the proposed
<br>
<br>[[always_inline]]
<br>
<br>since the former gives a hard error when the compiler ain&#39;t support=
ing it
<br>while the latter is mandated to be silently ignored.</blockquote><block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-lef=
t: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bord=
er-left-style: solid;">=C2=A0</blockquote><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">If I want to send the compiler a hint that some function should=
 be inlined then
<br>the language already provides that via the &quot;inline&quot; keyword s=
o this proposed
<br>[[always_inline]] will just provide a strength of the inlining hint,<br=
></blockquote><div><br></div><div>Yeah, that&#39;s not <a href=3D"http://en=
..cppreference.com/w/cpp/language/inline">what the `inline` keyword does</a>=
..</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Now, t=
hat is also a resonable idea but then it should be an attribute on the
<br>inline keyword since that is what it affects:
<br>
<br>inline [[inline_harder]] void fun() { /* */ }
<br>
<br>but the name &quot;always_inline&quot; should not be used unlees you ha=
ve the GCC
<br>semantics of it beeing an error to fail to inline the function and in t=
hat
<br>case it can&#39;t be an attribute.
<br>
<br>I think one could express this in standardeese like this:
<br>
<br>* The &quot;always_inline&quot; keyword ensures that the function decla=
red so have no
<br>=C2=A0 linkage.<i></i></blockquote><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;">
<br>This is similar to how &quot;static&quot; ensures no external linkage o=
r how &quot;inline&quot;
<br>allows vague linkage.</blockquote><div><br></div><div>`inline` does not=
 cause &quot;vague linkage&quot;. It cause internal linkage. That&#39;s a v=
ery specific kind of linkage.</div><div><br></div><div>Also, I fail to see =
how &quot;no linkage&quot; is equivalent to enforced inlining. In order to =
enforce inlining, you have to say something about whether inlining is possi=
ble in specific circumstances. And what inlining is, for that matter.</div>=
<div><br></div><div>Linkage is ultimately about the accessibility of the na=
me of an entity. Forced inlining is about more than that; here, you&#39;re =
saying that the entity flat-out doesn&#39;t exist.</div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">&gt; This is a QOI issue. Let comp=
ilers handle it as they see fit.
<br>
<br>I&#39;d rather se no standardization here than a standardization of a b=
roken
<br>concept.<br></blockquote><div><br></div><div>And yet you&#39;re fine wi=
th GCC&#39;s &quot;always_inline&quot; which, as previously shown, isn&#39;=
t <i>always</i> inline so much as &quot;almost always inline&quot;.<br></di=
v></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/3d587d63-0827-40e8-9825-9bbc8fa04c55%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3d587d63-0827-40e8-9825-9bbc8fa04c55=
%40isocpp.org</a>.<br />

------=_Part_339_1869184382.1516397970904--

------=_Part_338_531550177.1516397970904--

.

------=_Part_974_659623588.1516231690879
Content-Type: multipart/alternative;
 boundary="----=_Part_975_1371636419.1516231690879"

------=_Part_975_1371636419.1516231690879
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wednesday, January 17, 2018 at 10:47:09 AM UTC-8, Fl=C3=A1vio Lisb=C3=B4=
a wrote:
>
>
> [[always_inline]] is a hint that would substitute=20
> __attribute__((always_inline)), __forceinline and similar=20
> compiler-specific hints. The intention is for it to be semantically=20
> different from C++'s inline (e.g. as a mechanism for ODR realization) and=
=20
> be more on par with the compiler-dependent attributes it substitutes and=
=20
> C99's inline (e.g. try to inline the function call to avoid stack growth)=
..
> [...snip highly motivating example code...]
> Was this discussed before? Could there be any unforeseen consequence if=
=20
> such an attribute was standardized? I don't believe it would change the=
=20
> semantic of the program (or perhaps it would, in the case of e.g. member=
=20
> function pointers? but then, again, it's just a hint).
>

Yep, seems like a slam-dunk to me. (And [[always_inline]] is the correct=20
name, for historical reasons. Let's not inflict another NIHism like=20
[[maybe_unused]] on the world. Although I'll admit, even though I resented=
=20
[[nodiscard]] at the time, it's probably a good thing that we no longer=20
have to teach the historically-correct but impossible-to-remember=20
[[warn_unused_result]].)

Kind of a thread-hijack, but I have thought for a long time that what would=
=20
be really nice in a C-style language is a reification of something kind of=
=20
like Lisa Lippincott's "basic interface" ideas. In the following metaphor,=
=20
the function call-site is like a Javascript client, and the out-of-line=20
function body is like a remote server. Quite often we have a function with=
=20
a bunch of (metaphorical) "client-side checks" stuffed in front of the=20
"server-side code":

    extern int some_function_unchecked(int *x, int n, int i);
    inline int some_function(int *x, int n, int i) {
        if (x =3D=3D nullptr) throw "oops";
        if (n < 0) throw "oops";
        if (!(0 <=3D i && i < n)) return 0;
        return some_function_unchecked(x, n, i);
    }

and it would be nice to indicate directly to the compiler, without having=
=20
to play tricks with helper functions, that those "client-side checks"=20
should be inlined, and then the (metaphorical) "server-side logic" should=
=20
not be inlined. Because if you can inline the "client-side checks," you'll=
=20
usually find that they are optimized out entirely; whereas the benefit of=
=20
inlining the "server-side logic" might actually be negative.

So this is what I think of whenever anyone suggests modifying the core=20
language around inlining.
But really, just getting a standard/portable C++11-style synonym for=20
[[always_inline]] would be an improvement on the status quo.

FYI, for at least GCC and Clang, you can use [[gnu::always_inline]].  (I=20
*think* Clang is respecting it, not just ignoring it.)
https://github.com/llvm-mirror/clang/blob/a38ba977/test/SemaCXX/cxx11-gnu-a=
ttrs.cpp#L39

=E2=80=93Arthur

--=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/43b9c733-ff33-415d-87ab-7460733f06d9%40isocpp.or=
g.

------=_Part_975_1371636419.1516231690879
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, January 17, 2018 at 10:47:09 AM UTC-8, Fl=C3=
=A1vio Lisb=C3=B4a wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div><br></div><div><font face=3D"courier new, monospace" style=
=3D"background-color:rgb(238,238,238)">[[always_inline]]</font>=C2=A0is a h=
int that would substitute <font face=3D"courier new, monospace" style=3D"ba=
ckground-color:rgb(238,238,238)">__attribute__((always_inline))</font><wbr>=
, <font face=3D"courier new, monospace" style=3D"background-color:rgb(238,2=
38,238)">__forceinline</font> and similar compiler-specific hints. The inte=
ntion is for it to be semantically different from C++&#39;s <span style=3D"=
background-color:rgb(238,238,238)"><font face=3D"courier new, monospace">in=
line</font></span>=C2=A0(e.g. as a mechanism for ODR realization) and be mo=
re on par with the compiler-dependent attributes it substitutes and C99&#39=
;s <font face=3D"courier new, monospace" color=3D"#000000" style=3D"backgro=
und-color:rgb(238,238,238)">inline</font>=C2=A0(e.g. try to inline the func=
tion call to avoid stack growth).</div><div>[...snip highly motivating exam=
ple code...]</div><div><font face=3D"arial, sans-serif">Was this discussed =
before? Could there be any unforeseen consequence if such an attribute was =
standardized? I don&#39;t believe it would change the semantic of the progr=
am (or perhaps it would, in the case of e.g. member function pointers? but =
then, again, it&#39;s just a hint).</font></div></div></blockquote><div><br=
></div><div>Yep, seems like a slam-dunk to me. (And [[always_inline]] is th=
e correct name, for historical reasons. Let&#39;s not inflict another NIHis=
m like [[maybe_unused]] on the world. Although I&#39;ll admit, even though =
I resented [[nodiscard]] at the time, it&#39;s probably a good thing that w=
e no longer have to teach the historically-correct but impossible-to-rememb=
er [[warn_unused_result]].)</div><div><br></div><div>Kind of a thread-hijac=
k, but I have thought for a long time that what would be really nice in a C=
-style language is a reification of something kind of like Lisa Lippincott&=
#39;s &quot;basic interface&quot; ideas. In the following metaphor, the fun=
ction call-site is like a Javascript client, and the out-of-line function b=
ody is like a remote server. Quite often we have a function with a bunch of=
 (metaphorical) &quot;client-side checks&quot; stuffed in front of the &quo=
t;server-side code&quot;:</div><div><br></div><div>=C2=A0 =C2=A0 extern int=
 some_function_unchecked(int *x, int n, int i);</div><div>=C2=A0 =C2=A0 inl=
ine int some_function(int *x, int n, int i) {</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 if (x =3D=3D nullptr) throw &quot;oops&quot;;</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 if (n &lt; 0) throw &quot;oops&quot;;</div><div>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 if (!(0 &lt;=3D i &amp;&amp; i &lt; n)) return 0;</di=
v><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return some_function_unchecked(x, n, i);=
</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div>and it would be nice to=
 indicate directly to the compiler, without having to play tricks with help=
er functions, that those &quot;client-side checks&quot; should be inlined, =
and then the (metaphorical) &quot;server-side logic&quot; should not be inl=
ined. Because if you can inline the &quot;client-side checks,&quot; you&#39=
;ll usually find that they are optimized out entirely; whereas the benefit =
of inlining the &quot;server-side logic&quot; might actually be negative.</=
div><div><br></div><div>So this is what I think of whenever anyone suggests=
 modifying the core language around inlining.</div><div>But really, just ge=
tting a standard/portable C++11-style synonym for [[always_inline]] would b=
e an improvement on the status quo.</div><div><br></div><div>FYI, for at le=
ast GCC and Clang, you can use [[gnu::always_inline]]. =C2=A0(I *think* Cla=
ng is respecting it, not just ignoring it.)</div><div>https://github.com/ll=
vm-mirror/clang/blob/a38ba977/test/SemaCXX/cxx11-gnu-attrs.cpp#L39<br></div=
><div><br></div><div>=E2=80=93Arthur</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/43b9c733-ff33-415d-87ab-7460733f06d9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/43b9c733-ff33-415d-87ab-7460733f06d9=
%40isocpp.org</a>.<br />

------=_Part_975_1371636419.1516231690879--

------=_Part_974_659623588.1516231690879--

.