Bug 20343 - __always_inline__ fails on STL templatized function
Summary: __always_inline__ fails on STL templatized function
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-06 10:52 UTC by Yuri
Modified: 2005-07-23 22:49 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri 2005-03-06 10:52:27 UTC
Another example of failed inlining, now also existent in 4.0 as of 2005-02-13:

When I tried to compile with -O5 -Dinline=__attribute__\(\(__always_inline__\)\)
I get the error message below.

Interestingly there's no "inline" word here, it must have been taken from some
global declaration ?

--- code from include/c++/4.0.0/bits/ostream.tcc ---
  template<typename _CharT, typename _Traits>
    basic_ostream<_CharT, _Traits>&
    basic_ostream<_CharT, _Traits>::
    operator<<(__ostream_type& (*__pf)(__ostream_type&))
    {
...

--- error message ---
xxx.h|39| sorry, unimplemented: called from here
Comment 1 Paolo Carlini 2005-03-06 11:39:22 UTC
I think this can be closed as duplicate of tree-optimization/3713. See also
libstdc++/14078 for explanations.
Comment 2 Andrew Pinski 2005-03-06 15:12:55 UTC
There is no preprocessed source here or even a source?
Could you read http://gcc.gnu.org/bugs.html and attach the needed information?
Comment 3 Yuri 2005-03-06 18:10:31 UTC
Sorry about this, this appears to be more complex to reporduce than I thought.

Compile the following with the options:
-O5 -Dinline=__attribute__\(\(__always_inline__\)\)
to see the error message.

(gcc 4.0 cvs updeted on 2005-02-13 and compiled with default options)

What's strange is that error is only generated when both "vector" and "cout <<
endl;" parts are there

Yuri

--- code ---
#include <iostream>
#include <vector>
using namespace std;

int main() {
  vector<int> v;
  v.resize(100);
  v[10] = atoi("5");
  cout << endl;
  return (10);
}

-- error ---
/usr/local/gcc-4.0-20050213/lib/gcc/i386-unknown-freebsd5.3/4.0.0/../../../../include/c++/4.0.0/bits/ostream.tcc:67:
sorry,unimplemented: inlining failed in call to 'std::basic_ostream<_CharT,
_Traits>& std::basic_ostream<_CharT,
_Traits>::operator<<(std::basic_ostream<_CharT, _Traits>&
(*)(std::basic_ostream<_CharT, _Traits>&)) [with _CharT = char, _Traits =
std::char_traits<char>]': function not inlinable
m.C:9: sorry, unimplemented: called from here
Comment 4 Andrew Pinski 2005-03-06 18:16:33 UTC
Actually this is not a bug.

You need to define inline as inline __attribute__((always_inline)).
Comment 5 Paolo Carlini 2005-03-06 18:18:21 UTC
In anyone paying attention to my comment #1 ? This is a *known issue*, basically
we cannot inline currently pointers to functions.
Comment 6 Andrew Pinski 2005-03-06 18:21:24 UTC
(In reply to comment #5)
> In anyone paying attention to my comment #1 ? This is a *known issue*, basically
> we cannot inline currently pointers to functions.

Yes but his definition of inline is incorrect as inline in C++ also changes the linkage.
Comment 7 Yuri 2005-03-06 19:37:30 UTC
> You need to define inline as inline __attribute__((always_inline))
Did this, same error message.

In my project I NEED to specify explicitely inlining of the functions.
Including STL since vector::operator[] or similar is being called zillion times
even when very aggressive gcc inlining options are set. Regular inlining
decisions are not enough for me since I see performance gains with any new
inline of functio in the performance path.

I understand this causes code explosion -- it's ok w/in the current limits.

So to solve the problem with vector::operator[] and similar I use
__attribute__((always_inline)) but it fails. How can I solve the problem than ?
Comment 8 Paolo Carlini 2005-03-06 19:49:12 UTC
The error message that you are seeing is triggered by 'std::endl', a "manipulator"
in standard terms, that cannot currently inlined. I have trouble believing that
the performance bottleneck of your application is 'std::endl'... Just change
it for '\n' and flush only when really needed.