The following does not compile with -O0, but does with -O2. It used to work well on gcc-3.2 and gcc-3.1 $ cat t.cc template <class T> inline void Foo(T) __attribute__((always_inline)); template <class T> inline void Foo(T) {} int main() { int i; Foo(i); } $ $gcc34/bin/g++ -c t.cc t.cc: In function `int main()': t.cc:2: sorry, unimplemented: inlining failed in call to 'void Foo(T) [with T = int]': function body not available t.cc:6: sorry, unimplemented: called from here When compiled with -O, it works OK. When the same is done without templates it works OK: $ cat t2.cc inline void Foo(int) __attribute__((always_inline)); inline void Foo(int) {} int main() { int i; Foo(i); } This is inconsistent. $ $gcc34/bin/g++ -v Reading specs from /home/veksler/gcc/lib/gcc/i686-pc-linux-gnu/3.4.0/specs Configured with: ../gcc-3.4.0-20040406/configure --prefix=/home/veksler/gcc --enable-languages=c++ Thread model: posix gcc version 3.4.0 20040407 (prerelease)
Confirmed, a regression from 3.3.3 but fixed on the mainline already (most likely from a merge for cgraph from the tree-ssa or some other patch).
*** Bug 15045 has been marked as a duplicate of this bug. ***
*** Bug 15040 has been marked as a duplicate of this bug. ***
Note this causes libjava to fail to build at -O1.
The problem here is that we do only in order inlining with -fno-unit-at-a-time. The C++ frontend is deffering the functions until they are really used so the Foo is not passed to cgraph code before main is called and thus it can't be inlined. I am not sure how to cope with this problem. (except for fact explaining people that using Linux headers definig alwaysinline by default is bad idea). Reorganizing C++ frontend to sanely finalize all functions and rely on cgraph code to output only needed one is quite drastical step for 3.4.x series (tought I definitly can try do it if it sounds sane - it basically means to add flag to cgraph code teaching non-unit-at-a-time to not be too active about compiling functions that don't seem to be needed and kill the non-unit-at-a-time code in the C++ frontend. If we get lucky, this might work.) Perhaps we can make always_inline failures warnings in non-unit-at-a-time mentioning that alwyas_inline works reliably only in unit-at-a-time? Concerning the always_inline&Linux kernel isses, perhaps we can either teach fixincludes to fix that or do sanity check in the configure erroring out and asking user to use glibc includes istead? Honza
As far as I know, there is no "linux kernel issue" that is part of this bug. The discussion of Linux kernel configurations and kernel memory leakage in bug 15040 only shows that at least some cases where this bug is produced succeed when there is more virtual memory available.
This bug report currently lists 3.5.0 on the "known to work" line. I assume that there is no 3.5.0 release yet, but, rather a cvs branch somewhere. I was wondering if anyone had actually reproduced the breakage under 3.4.0 and verified that 3.5.0 succeeds in the same case. I thought that I'd try to do that, but I get "connection timed out" when I try to check out the cvs gcc-3_5-branch from savannah.gnu.org (following the instructions at http://gcc.gnu.org/cvs.html ).
Note tehe "3.5" branch is the top of the tree.
Subject: Bug 14950 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: hubicka@gcc.gnu.org 2004-06-22 10:36:16 Modified files: gcc/cp : ChangeLog pt.c Log message: PR C++/14950 * pt.c (instantiate_decl): Clean TI_PENDING_TEMPLATE_FLAG before expanding the function. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.126&r2=1.3892.2.127 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.816.2.32&r2=1.816.2.33
Fixed.
I can still reproduce on 3.4.2 with the original test case, using "g++ -g -c t.cpp". There is a proposal in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14950#c5 to stop support for always_inline + no-unit-at-a-time. But it is only a proposal - no conscious decision was taken or documented.
Postponed until GCC 3.4.4.
There is more to this bug than the compilation of code specified always_inline at -O0. I have some template code that compiles fine at -O2 but gives lots of inlining warning at -O1. Without template, it works OK. With template, it gives the same warning as below (replacing sorry unimplemented with warning). Here's a sample of the code : class Vector { template <class T> void Evaluate(const T& e) { v[0]=e[0]; v[1]=e[1]; v[2]=e[2]; } };
Sorry I meant above.
Woops.
*** Bug 20275 has been marked as a duplicate of this bug. ***
*** Bug 20340 has been marked as a duplicate of this bug. ***
*** Bug 23520 has been marked as a duplicate of this bug. ***
Fixed in 4.0.0 and higher. Won't fix for 3.4.6
fixed. Not suspended. Silly bugzilla.