Bug 14950 - [3.4 Regression] [non unit-at-a-time] always_inline does not mix with templates and -O0
[3.4 Regression] [non unit-at-a-time] always_inline does not mix with templat...
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: c++
3.4.0
: P2 minor
: 4.0.0
Assigned To: Jan Hubicka
: build, rejects-valid
: 15040 15045 20275 20340 23520 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-14 06:48 UTC by Michael Veksler
Modified: 2006-01-22 03:13 UTC (History)
9 users (show)

See Also:
Host: i686-pc-linux-gnu
Target:
Build:
Known to work: 4.0.0 3.3.3
Known to fail: 3.4.2
Last reconfirmed: 2006-01-06 15:24:23


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Veksler 2004-04-14 06:48:52 UTC
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)
Comment 1 Andrew Pinski 2004-04-14 11:19:04 UTC
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).
Comment 2 Andrew Pinski 2004-04-21 15:23:51 UTC
*** Bug 15045 has been marked as a duplicate of this bug. ***
Comment 3 Andrew Pinski 2004-04-22 23:46:55 UTC
*** Bug 15040 has been marked as a duplicate of this bug. ***
Comment 4 Andrew Pinski 2004-04-22 23:49:18 UTC
Note this causes libjava to fail to build at -O1.
Comment 5 Jan Hubicka 2004-05-05 20:21:45 UTC
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 
Comment 6 adam 2004-05-06 04:10:32 UTC
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.
Comment 7 adam 2004-05-06 06:28:14 UTC
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 ).
Comment 8 Andrew Pinski 2004-05-06 11:38:21 UTC
Note tehe "3.5" branch is the top of the tree.
Comment 9 CVS Commits 2004-06-22 10:36:23 UTC
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

Comment 10 Andrew Pinski 2004-06-22 15:39:22 UTC
Fixed.
Comment 11 Michael Veksler 2004-10-13 11:23:08 UTC
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.
Comment 12 Mark Mitchell 2004-10-31 02:43:01 UTC
Postponed until GCC 3.4.4.
Comment 13 Jean-Michel Gilbert 2005-01-26 16:22:01 UTC
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];
    }
};
Comment 14 Jean-Michel Gilbert 2005-01-26 16:23:50 UTC
Sorry I meant above.
Comment 15 Andrew Pinski 2005-02-12 21:12:33 UTC
Woops. 
Comment 16 Andrew Pinski 2005-03-02 06:53:04 UTC
*** Bug 20275 has been marked as a duplicate of this bug. ***
Comment 17 Andrew Pinski 2005-03-06 15:10:09 UTC
*** Bug 20340 has been marked as a duplicate of this bug. ***
Comment 18 Andrew Pinski 2005-08-22 20:54:40 UTC
*** Bug 23520 has been marked as a duplicate of this bug. ***
Comment 19 Gabriel Dos Reis 2006-01-22 03:00:31 UTC
Fixed in 4.0.0 and higher.  Won't fix for 3.4.6
Comment 20 Gabriel Dos Reis 2006-01-22 03:13:41 UTC
fixed.  Not suspended.  Silly bugzilla.