14950 – [3.4 Regression] [non unit-at-a-time] always_inline does not mix with templates and -O0 (original) (raw)

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 inline void Foo(T) attribute((always_inline)); template 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 Drea 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 Drea Pinski 2004-04-21 15:23:51 UTC

*** Bug 15045 has been marked as a duplicate of this bug. ***

Comment 3 Drea Pinski 2004-04-22 23:46:55 UTC

*** [Bug 15040](show%5Fbug.cgi?id=15040 "RESOLVED DUPLICATE - numerous "sorry, unimplemented: inlining failed" failures") has been marked as a duplicate of this bug. ***

Comment 4 Drea 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](show%5Fbug.cgi?id=15040 "RESOLVED DUPLICATE - numerous "sorry, unimplemented: inlining failed" failures") 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 Drea Pinski 2004-05-06 11:38:21 UTC

Note tehe "3.5" branch is the top of the tree.

Comment 10 Drea 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 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 Drea Pinski 2005-02-12 21:12:33 UTC

Woops.

Comment 16 Drea Pinski 2005-03-02 06:53:04 UTC

*** Bug 20275 has been marked as a duplicate of this bug. ***

Comment 17 Drea Pinski 2005-03-06 15:10:09 UTC

*** Bug 20340 has been marked as a duplicate of this bug. ***

Comment 18 Drea 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.