* [Bug web/61782] always_inline incorrectly documented
2014-07-11 18:15 [Bug web/61782] New: always_inline incorrectly documented daniel.santos at pobox dot com
@ 2014-07-14 10:41 ` rguenth at gcc dot gnu.org
2014-07-14 15:34 ` daniel.santos at pobox dot com
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-07-14 10:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2014-07-14
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
?
@item always_inline
@cindex @code{always_inline} function attribute
Generally, functions are not inlined unless optimization is specified.
For functions declared inline, this attribute inlines the function even
if no optimization level is specified.
what exactly is unclear about this? "even if no optimization level is
specified"
The implemented behavior is that always_inline forces inlining of the function
under all circumstances and it is an error if the function cannot be inlined.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug web/61782] always_inline incorrectly documented
2014-07-11 18:15 [Bug web/61782] New: always_inline incorrectly documented daniel.santos at pobox dot com
2014-07-14 10:41 ` [Bug web/61782] " rguenth at gcc dot gnu.org
@ 2014-07-14 15:34 ` daniel.santos at pobox dot com
2014-07-15 9:12 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: daniel.santos at pobox dot com @ 2014-07-14 15:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #2 from Daniel Santos <daniel.santos at pobox dot com> ---
Hmm, I suppose I wasn't considering that interpretation of the language. Your
clarification helps though, and actually sounds pretty good: "always_inline
forces inlining of the function under all circumstances and it is an error if
the function cannot be inlined."
I know that I am not the only person who has read the original language and
interpreted it as marking the function inline-able, even if if inlining
(-finline-functions) isn't enabled, yet still subject to other considerations
for a determination as to rather or not the function body is actually inlined,
(i.e., the inline insn count).
So can we get some clarification similar to the language you used above?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug web/61782] always_inline incorrectly documented
2014-07-11 18:15 [Bug web/61782] New: always_inline incorrectly documented daniel.santos at pobox dot com
2014-07-14 10:41 ` [Bug web/61782] " rguenth at gcc dot gnu.org
2014-07-14 15:34 ` daniel.santos at pobox dot com
@ 2014-07-15 9:12 ` rguenth at gcc dot gnu.org
2014-07-15 10:17 ` redi at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-07-15 9:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Like
@item always_inline
@cindex @code{always_inline} function attribute
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 function is diagnosed as error.
Note that if such function is called indirectly the compiler may
or may not inline it dependent on optimization level and a failure
to inline an indirect call may or may not be diagnosed.
which matches how GCC behaves (last sentence)?
Corrections welcome (I am not a native speaker).
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug web/61782] always_inline incorrectly documented
2014-07-11 18:15 [Bug web/61782] New: always_inline incorrectly documented daniel.santos at pobox dot com
` (2 preceding siblings ...)
2014-07-15 9:12 ` rguenth at gcc dot gnu.org
@ 2014-07-15 10:17 ` redi at gcc dot gnu.org
2014-07-15 12:07 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: redi at gcc dot gnu.org @ 2014-07-15 10:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> Like
>
> @item always_inline
> @cindex @code{always_inline} function attribute
> 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 function is diagnosed as error.
Failure to inline such a function is diagnosed as an error.
^ ^^
> Note that if such function is called indirectly the compiler may
Note that if such a function is called indirectly the compiler may
^
> or may not inline it dependent on optimization level and a failure
I think I'd say s/dependent/depending/ here.
> to inline an indirect call may or may not be diagnosed.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug web/61782] always_inline incorrectly documented
2014-07-11 18:15 [Bug web/61782] New: always_inline incorrectly documented daniel.santos at pobox dot com
` (3 preceding siblings ...)
2014-07-15 10:17 ` redi at gcc dot gnu.org
@ 2014-07-15 12:07 ` rguenth at gcc dot gnu.org
2014-07-15 19:52 ` daniel.santos at pobox dot com
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-07-15 12:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Patch posted.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug web/61782] always_inline incorrectly documented
2014-07-11 18:15 [Bug web/61782] New: always_inline incorrectly documented daniel.santos at pobox dot com
` (4 preceding siblings ...)
2014-07-15 12:07 ` rguenth at gcc dot gnu.org
@ 2014-07-15 19:52 ` daniel.santos at pobox dot com
2014-07-16 7:54 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: daniel.santos at pobox dot com @ 2014-07-15 19:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #6 from Daniel Santos <daniel.santos at pobox dot com> ---
(In reply to Richard Biener from comment #3)
> Note that if such function is called indirectly the compiler may
> or may not inline it dependent on optimization level and a failure
> to inline an indirect call may or may not be diagnosed.
OMG!! Thank you SO much for this clarification! I'm the crazy C metaprogramming
guy and I depend upon -findirect-inline and always_inline to facilitate what
I'm calling "C pseudo-templates." This would explain some odd circumstances
where I've seen such functions not get inlined. I've been able to remedy this
(thus far) by marking the calling function with __attribute__((flatten)), but I
have to take great care to catch this, ensuring that that I check each value
that I expect to be constant with __builtin_constant_p and generate an error
when they aren't.
Portions of these functions (often the majority) I expect to be executed by the
compiler and the result emitted, rather than having the whole of the function
emitted as generated code. As the complexity of such functions grows, the cost
of failing to inline by indirection can be the explosion of the function to 10,
20 times or more of it's size when all inlining happens. (sorry, that's a
little off topic).
I like the verbiage and thank you!
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug web/61782] always_inline incorrectly documented
2014-07-11 18:15 [Bug web/61782] New: always_inline incorrectly documented daniel.santos at pobox dot com
` (5 preceding siblings ...)
2014-07-15 19:52 ` daniel.santos at pobox dot com
@ 2014-07-16 7:54 ` rguenth at gcc dot gnu.org
2014-07-16 7:54 ` rguenther at suse dot de
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-07-16 7:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Wed Jul 16 07:53:59 2014
New Revision: 212581
URL: https://gcc.gnu.org/viewcvs?rev=212581&root=gcc&view=rev
Log:
2014-07-16 Richard Biener <rguenther@suse.de>
PR other/61782
* doc/extend.texi (always_inline): Clarify.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug web/61782] always_inline incorrectly documented
2014-07-11 18:15 [Bug web/61782] New: always_inline incorrectly documented daniel.santos at pobox dot com
` (6 preceding siblings ...)
2014-07-16 7:54 ` rguenth at gcc dot gnu.org
@ 2014-07-16 7:54 ` rguenther at suse dot de
2014-07-16 7:54 ` rguenth at gcc dot gnu.org
2014-07-16 16:40 ` daniel.santos at pobox dot com
9 siblings, 0 replies; 11+ messages in thread
From: rguenther at suse dot de @ 2014-07-16 7:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 15 Jul 2014, daniel.santos at pobox dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
>
> --- Comment #6 from Daniel Santos <daniel.santos at pobox dot com> ---
> (In reply to Richard Biener from comment #3)
> > Note that if such function is called indirectly the compiler may
> > or may not inline it dependent on optimization level and a failure
> > to inline an indirect call may or may not be diagnosed.
>
> OMG!! Thank you SO much for this clarification! I'm the crazy C
> metaprogramming guy and I depend upon -findirect-inline and
> always_inline to facilitate what I'm calling "C pseudo-templates." This
> would explain some odd circumstances where I've seen such functions not
> get inlined. I've been able to remedy this (thus far) by marking the
> calling function with __attribute__((flatten)), but I have to take great
> care to catch this, ensuring that that I check each value that I expect
> to be constant with __builtin_constant_p and generate an error when they
> aren't.
Heh - I've been there as well and guess what - I invented
__attribute__((flatten)) because of this...
Note that flatten has the same issues as always_inline with respect
to indirect function calls (or virtual method calls, which are
indirect calls).
> Portions of these functions (often the majority) I expect to be executed by the
> compiler and the result emitted, rather than having the whole of the function
> emitted as generated code. As the complexity of such functions grows, the cost
> of failing to inline by indirection can be the explosion of the function to 10,
> 20 times or more of it's size when all inlining happens. (sorry, that's a
> little off topic).
Yeah, similar catastrophic things happened in the past with
profile-feedback where instrumentation was applied _before_ all
inlining... (I changed that as well).
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug web/61782] always_inline incorrectly documented
2014-07-11 18:15 [Bug web/61782] New: always_inline incorrectly documented daniel.santos at pobox dot com
` (7 preceding siblings ...)
2014-07-16 7:54 ` rguenther at suse dot de
@ 2014-07-16 7:54 ` rguenth at gcc dot gnu.org
2014-07-16 16:40 ` daniel.santos at pobox dot com
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-07-16 7:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |4.10.0
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed for 4.10.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug web/61782] always_inline incorrectly documented
2014-07-11 18:15 [Bug web/61782] New: always_inline incorrectly documented daniel.santos at pobox dot com
` (8 preceding siblings ...)
2014-07-16 7:54 ` rguenth at gcc dot gnu.org
@ 2014-07-16 16:40 ` daniel.santos at pobox dot com
9 siblings, 0 replies; 11+ messages in thread
From: daniel.santos at pobox dot com @ 2014-07-16 16:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #10 from Daniel Santos <daniel.santos at pobox dot com> ---
(In reply to rguenther@suse.de from comment #7)
> Heh - I've been there as well and guess what - I invented
> __attribute__((flatten)) because of this...
>
> Note that flatten has the same issues as always_inline with respect
> to indirect function calls (or virtual method calls, which are
> indirect calls).
>
> > Portions of these functions (often the majority) I expect to be executed by the
> > compiler and the result emitted, rather than having the whole of the function
> > emitted as generated code. As the complexity of such functions grows, the cost
> > of failing to inline by indirection can be the explosion of the function to 10,
> > 20 times or more of it's size when all inlining happens. (sorry, that's a
> > little off topic).
>
> Yeah, similar catastrophic things happened in the past with
> profile-feedback where instrumentation was applied _before_ all
> inlining... (I changed that as well).
Hah! That makes you my hero then! I haven't learned the internals of gcc yet,
so I still have to rely on others for this fringe stuff.
Thanks again everybody.
^ permalink raw reply [flat|nested] 11+ messages in thread