GCC Bugzilla Bug 14950

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.