This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/12219] New: inline doesn't always cause inlining, even when it's possible
- From: "dbaron at dbaron dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Sep 2003 22:57:31 -0000
- Subject: [Bug c++/12219] New: inline doesn't always cause inlining, even when it's possible
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12219
Summary: inline doesn't always cause inlining, even when it's
possible
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dbaron at dbaron dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
There are cases where inline doesn't cause inlining, but
__attribute__((always_inline)) causes inlining and improves the performance of
the code. Having to resort to __attribute__((always_inline)) is rather ugly,
especially in code that also has to compile on other compilers.
This is filed as suggested in bug 11680 comment 4.
A testcase is attachment 4487 (from bug 11680).
Steps to reproduce:
1. Compile attachment 4487 using -O2.
2. time "<executable> original" and "<executable> slow".
3. Modify the attachment to comment out the __attribute__((always_inline))
(and, if you want, add |inline|, although C++ says it's implied for methods
defined inside of class defitions, and it doesn't make a difference) in the
class ConvertUTF16toUTF8_slow
4. recompile
Expected results:
2. The two take the same amount of time.
4. There is no change in the size of the binary.
Actual results:
2. "slow" is faster than "original".
4. the binary is bigger without the __attribute__((always_inline))