Bug 11131 - [3.4 Regression]Unrelated declaration removes inline flag from function
Summary: [3.4 Regression]Unrelated declaration removes inline flag from function
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.4.0
: P1 critical
Target Milestone: 3.4.0
Assignee: Jan Hubicka
URL:
Keywords: missed-optimization
Depends on:
Blocks:
 
Reported: 2003-06-09 12:51 UTC by Wolfgang Bangerth
Modified: 2004-01-17 04:22 UTC (History)
1 user (show)

See Also:
Host:
Target: i686-pc-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed: 2003-06-09 14:25:39


Attachments
cvs diff -c3p -D "Fri Jul 11 21:17:03 UTC 2003" -D "Sat Jul 12 04:01:24 UTC 2003" (14.19 KB, application/gzip)
2003-07-29 09:26 UTC, Steven Bosscher
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Bangerth 2003-06-09 12:51:00 UTC
This is a weird failure: for this code, calling FOO=foo1
yields worse results than FOO=foo2 (despite the throw() specification)
if and only the forward declaration of the specialization of UNRELATED
is present:
-----------------------------------
template <int>
struct A {
    void foo1 () throw ();
    void foo2 ();

    void UNRELATED ();
};

template <> void A<0>::UNRELATED ();

template <int dim> inline void A<dim>::foo1 () throw () {}
template <int dim> inline void A<dim>::foo2 ()          {}

void bar (A<0> &a) {
  a.FOO ();
}
-----------------------------------

Compiling on an x86 box with present mainline like this
    c++ -O2 -fPIC -S x.cc -o 1.s -DFOO=foo1
    c++ -O2 -fPIC -S x.cc -o 2.s -DFOO=foo2
yields two assembler files for the cases where bar either
calls A<2>::foo1 or A<2>::foo2. One would expect the
output to be the same, since neither foo1 not foo2 can
throw exceptions, so the exception specification seems
redundant to what the compiler can infer anyway.

Alas, this is not the case. The output for calling foo2 is optimal
(labels etc deleted): 
   _Z3barR1AILi0EE:
	pushl	%ebp
	movl	%esp, %ebp
	popl	%ebp
	ret
The output for calling foo1, on the other hand, is outrageously bad:
   _Z3barR1AILi0EE:
	pushl	%ebp
	movl	%esp, %ebp
	pushl	%ebx
	subl	$4, %esp
	movl	8(%ebp), %eax
	call	.LPR3
	addl	$_GLOBAL_OFFSET_TABLE_, %ebx
	movl	%eax, (%esp)
	call	_ZN1AILi0EE4foo1Ev@PLT
	popl	%eax
	popl	%ebx
	popl	%ebp
	ret

   _ZN1AILi0EE4foo1Ev:
	pushl	%ebp
	movl	%esp, %ebp
	popl	%ebp
	ret

   .LPR3:
	movl	(%esp), %ebx
	ret

First, A<2>::foo not inlined, and the call to LPR3 is really atrocious!
The really mysterious thing is that calling foo1 produces exactly the
same (optimal) code as for foo2 when the specialization declaration of
UNRELATED is not present, or if it is for some other template value
than the one that is also used in bar(). In other words, the right
questions seems not why foo2 is better than foo1, but: what has
UNRELATED to do with it?

Now, admittedly the problem also goes away if one uses -O3 instead of
-O2, or more precisely -finline-functions, but that flag is somewhat
unpopular due to its compile time implications. The code is so
obviously wrong that I think it would be worthwhile to figure out what
the specialization has to do with it. Something's really not right
with that and it might be that this might lead to problems with -O3 in
other contexts.

I tried to poke a little at what goes on in the compiler, but the
output for the two cases generated by -da differs right from the first
phase, x.cc.00.rtl. Note that UNRELATED does not appear even once in
the output files of -da, so the problem is really due to something
that seems to be in the front-end.

The obvious thing that UNRELATED strips the "inline" attribute from
the _next_ function is also not true, since exchanging the definitions
of foo[12] does not change the result. On the other hand, placing the
declaration of the specialization _after_ foo[12] _does_ make the
problem go away. I fear this is about as far as I can help...

W.
Comment 1 Andrew Pinski 2003-06-09 13:06:28 UTC
I see the same behivour on powerpc-apple-darwin6.6 on the mainline (20030609) :
[zhivago2:~/src/gccPRs] pinskia% gcc -O2 -S -o - pr11131.cc -DFOO=foo1;echo -----
;echo ----- ;gcc -O2 -S -o - pr11131.cc -DFOO=foo2
.text
        .align 2
        .globl __Z3barR1AILi0EE
__Z3barR1AILi0EE:
LFB5:
        stw r31,-4(r1)   <--- save the pic register
LCFI0:
        lwz r31,-4(r1) <-- restore the pic register
        b L__ZN1AILi0EE4foo1Ev$stub
LFE5:
        .align 2
__ZN1AILi0EE4foo1Ev:
L__ZN1AILi0EE4foo1Ev$stub:
LFB7:
L3:
        blr
LFE7:
.data
.constructor
.data
.destructor
        .align 1
-----
-----
.text
        .align 2
        .globl __Z3barR1AILi0EE
__Z3barR1AILi0EE:
LFB6:
        blr
LFE6:
.data
.constructor
.data
.destructor
        .align 1

This looks like it is exception handlering related in *.00.rtl extra for -DFOO=foo1:

;; Function void A<<anonymous> >::foo1() [with int <anonymous> = 0]

(note 2 0 3 NOTE_INSN_DELETED)

(insn 3 2 4 (set (reg/v/u/f:SI 118 [ this ])
        (reg:SI 3 r3 [ this ])) -1 (nil)
    (expr_list:REG_EQUIV (mem/u/f:SI (reg/f:SI 113 virtual-incoming-args) [4 this+0 S4 
A32])
        (nil)))

(note 4 3 5 NOTE_INSN_FUNCTION_BEG)

(note 5 4 6 NOTE_INSN_DELETED)

(note 6 5 7 1 NOTE_INSN_EH_REGION_BEG)

(note 7 6 8 0x1080180 NOTE_INSN_BLOCK_BEG)

(note 8 7 9 NOTE_INSN_DELETED)

(note 9 8 10 NOTE_INSN_DELETED)

(note 10 9 11 NOTE_INSN_DELETED)

(note 11 10 12 0x1080180 NOTE_INSN_BLOCK_END)

(note 12 11 13 1 NOTE_INSN_EH_REGION_END)

(jump_insn 13 12 14 (set (pc)
        (label_ref 19)) -1 (nil)
    (nil))

(barrier 14 13 15)

(code_label 15 14 16 3 "" [0 uses])

(insn 16 15 17 (set (reg:SI 3 r3)
        (reg:SI 119)) -1 (nil)
    (nil))

(call_insn 17 16 18 (parallel [
            (call (mem:SI (symbol_ref:SI ("&L___cxa_call_
unexpected$stub")) [0 S4 A8])

 
           
 
   (const_int 32 [0x20]))
      
      (use (const_int 0 [0x0]))
            (clobber (scratch:SI))
        ]) -1 (nil)
    (expr_list:REG_NORETURN (const_int 
0 [0x0])
        (nil))
    (expr_list
 (use (reg:SI 3 r3))
        (nil))
)

(barrier 18 17 19
)

(code_label 19 18 20 4 "" [0 uses])

(note 20
 19 22 NOTE_INS
N_FUNCTION_END)

(code_label 22 20 
0 2 "" [0 uses])

Comment 2 Wolfgang Bangerth 2003-06-09 13:13:47 UTC
Subject: Re:  Unrelated declaration removes inline flag from
 function


> I see the same behivour on powerpc-apple-darwin6.6 on the mainline (20030609) :

Can you verify as well that removing the specialization "fixes" the 
pessimization? I really think that that is the underlying cause of the 
problem,

W.

PS: Thanks for the quick confirmation at such early times -- is Ohio still 
EST or already CST? :-)

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/


Comment 3 Andrew Pinski 2003-06-09 13:21:29 UTC
Subject: Re:  Unrelated declaration removes inline flag from function


On Monday, Jun 9, 2003, at 09:13 US/Eastern, Wolfgang Bangerth wrote:

>
>> I see the same behivour on powerpc-apple-darwin6.6 on the mainline  
>> (20030609) :
>
> Can you verify as well that removing the specialization "fixes" the
> pessimization? I really think that that is the underlying cause of the
> problem,

Yep that fixes it.
This seems like a weird bug which might be hard to debug if it is a  
memory corruption bug.
It could just be setting something in the wrong spot.

>
> W.
>
> PS: Thanks for the quick confirmation at such early times -- is Ohio  
> still
> EST or already CST? :-)

It is Eastern Daylight Time (but I had an exam at 7:30 this morning so I
am in between exams).

>
> ----------------------------------------------------------------------- 
> --
> Wolfgang Bangerth              email:             
> bangerth@ices.utexas.edu
>                                www:  
> http://www.ices.utexas.edu/~bangerth/
>
>
>
>

Comment 4 Wolfgang Bangerth 2003-06-09 13:26:08 UTC
Subject: Re:  Unrelated declaration removes inline flag from
 function


> This seems like a weird bug which might be hard to debug if it is a  
> memory corruption bug.
> It could just be setting something in the wrong spot.

I have no clue about how g++ works. I thought maybe the specialization 
leads to forking the data structure for the class and not all data is 
copied properly. But that's just speculation, I'll leave this to those 
with clues ;-)

> It is Eastern Daylight Time (but I had an exam at 7:30 this morning

Insane!

W,

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/


Comment 5 Nathan Sidwell 2003-06-09 17:42:44 UTC
Subject: Re:  Unrelated declaration removes inline flag from
 function

Ok, what is going on here will be difficult to 'fix' without
pessimizing something.

the specialization
	template <> void A<0>::Unrelated () {}
causes an instantiation of A<0>. At that point A<O>::Foo1 is not declared
inline, but is declared NO_THROW. A<0>::Foo2 is also not declared
inline, but is not declared NO_THROW.

at the call
	a.Foo1 ();
we see the declaration of A<O>::Foo1 already exists. We note that it cannot
throw, so we continue and mark it for later instantiation. We then process the
body of bar for tree inlining and do not inline A<0>::Foo1, as it is not
marked as inline. At the end of compilation we instantiate A<0>::Foo1 using
the definition, and discover that it could be inlined.

At the call
	a.Foo2 ()
we see the declaration of A<0>::Foo1 already exists. We notice that we have
not determined whether it can or cannot throw, we also notice that bar currently
cannot throw. So we instantiate A<0>::Foo1 to see if it does infact turn out
to be a NO_THROW function. That instantiation picks up its inlineable flag.
Notice we would not have done the instantiation if we'd already determined
that Bar could throw.

To fix this bug requires instantiating at all call sites. We tried not
to do that as 'maintaining a stack of active functions is expensive'
(decl2.c:mark_used).

If/when we do whole translation unit optimization, this problem goes away.

nathan

Comment 6 Wolfgang Bangerth 2003-06-09 20:20:06 UTC
Subject: Re:  Unrelated declaration removes inline flag from
 function


Nathan, I'm deeply indebted to you for the quick analysis -- if I can make 
it to the next gcc summit and you should be there too, you're sure to have 
a free beer one night!


> To fix this bug requires instantiating at all call sites. We tried not
> to do that as 'maintaining a stack of active functions is expensive'
> (decl2.c:mark_used).

Let me try to see whether I understand you correctly: if the function has 
no throw specification, we have to look it up by instantiating the 
function. OTOH, if it has, the logic is that we can save this work because 
the programmer has already told the compiler.

What I don't understand is the thing about "expensive" -- if I understand 
things right, then we're only taking a short-cut, but if we would 
instantiate the function we would only use as much memory as if the 
programmer had not given a throw specification, right? I don't think that 
would qualify as "expensive", it is at most "just as expensive".

Or am I missing something?

Thanks
  W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/




Comment 7 Wolfgang Bangerth 2003-06-10 00:00:47 UTC
Subject: Re:  Unrelated declaration removes inline flag from
 function


Hi Nathan,
with your analysis of this morning, I did the minimal patch attached below 
-- by simply removing the short-cut. The patch fixes my testcase. In order 
to address your concerns about a run-time penalty: I did some tests, with 
unpatched and patched gcc, concerning compile- and run-time of my 
application with and without exception specifications.

The result:
- with the patch, gcc is slower (actually, I don't believe this, 
  it might be due to network/NFS interactions, I would have to repeat the 
  measurements)
- the patch fixes the testcase
- the test does not fix my real-world problem :-(

I have no opinion. What do you think?

W.


                          unpatched gcc      patched gcc

compile time
  without exc. spec.          15:01              15:27
  with exc. spec.             15:16              15:06

test code run time
  without exc. spec.         1:41.3             1:41.5
  with exc. spec.            1:43.8             1:43.6

static stripped code size
  without exc. spec.        2419480            2419480
  with exc. spec.           2393208            2455416



*** decl2.c.~1.627.~	2003-06-09 16:29:20.000000000 -0500
--- decl2.c	2003-06-09 18:06:33.000000000 -0500
***************
*** 4601,4612 ****
  
  	 However, if instantiating this function might help us mark
  	 the current function TREE_NOTHROW, we go ahead and
! 	 instantiate it now.  */
        defer = (!flag_exceptions
  	       || TREE_CODE (decl) != FUNCTION_DECL
- 	       /* If the called function can't throw, we don't need to
- 		  generate its body to find that out.  */
- 	       || TREE_NOTHROW (decl)
  	       || !cfun
  	       /* If we already know the current function can't throw,
  		  then we don't need to work hard to prove it.  */
--- 4601,4620 ----
  
  	 However, if instantiating this function might help us mark
  	 the current function TREE_NOTHROW, we go ahead and
! 	 instantiate it now.
! 
! 	 Previously, we would defer instantiation of functions for
! 	 which we know that they can't throw due to their declaration,
! 	 i.e. the condition had another case "|| TREE_NOTHROW
! 	 (decl)". However, this has the adverse effect that we missed
! 	 some inlining opportunities for functions with throw()
! 	 specifications that we wouldn't have missed if that
! 	 specification were not there, see PR 11131. Thus, do not
! 	 punish users that write throw specifications by deferring
! 	 such functions, even though we know that these functions
! 	 can't throw.  */
        defer = (!flag_exceptions
  	       || TREE_CODE (decl) != FUNCTION_DECL
  	       || !cfun
  	       /* If we already know the current function can't throw,
  		  then we don't need to work hard to prove it.  */






Comment 8 GCC Commits 2003-06-10 07:22:18 UTC
Subject: Bug 11131

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	mmitchel@gcc.gnu.org	2003-06-10 07:19:57

Modified files:
	gcc            : ChangeLog tree-inline.c 
	gcc/cp         : ChangeLog cp-tree.h decl2.c pt.c tree.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/opt: template1.C 

Log message:
	PR c++/11131
	* tree-inline.c (inlinable_function_p): Call the language-specific
	hook early.
	
	PR c++/11131
	* cp-tree.h (template_for_substitution): Declare.
	* decl2.c (mark_used): Use it when figuring out whether or not a
	function is inline.
	* pt.c (template_for_substitution): Give it external linkage.
	* tree.c (cp_cannot_inline_tree_fn): Instantiate as early as
	possible.
	
	PR c++/11131
	* g++.dg/opt/template1.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.18129&r2=1.18130
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-inline.c.diff?cvsroot=gcc&r1=1.60&r2=1.61
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.3407&r2=1.3408
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.849&r2=1.850
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.627&r2=1.628
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.697&r2=1.698
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gcc&r1=1.326&r2=1.327
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.2752&r2=1.2753
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/template1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1

Comment 9 GCC Commits 2003-06-10 07:22:27 UTC
Subject: Bug 11131

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	mmitchel@gcc.gnu.org	2003-06-10 07:19:57

Modified files:
	gcc            : ChangeLog tree-inline.c 
	gcc/cp         : ChangeLog cp-tree.h decl2.c pt.c tree.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/opt: template1.C 

Log message:
	PR c++/11131
	* tree-inline.c (inlinable_function_p): Call the language-specific
	hook early.
	
	PR c++/11131
	* cp-tree.h (template_for_substitution): Declare.
	* decl2.c (mark_used): Use it when figuring out whether or not a
	function is inline.
	* pt.c (template_for_substitution): Give it external linkage.
	* tree.c (cp_cannot_inline_tree_fn): Instantiate as early as
	possible.
	
	PR c++/11131
	* g++.dg/opt/template1.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.18129&r2=1.18130
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-inline.c.diff?cvsroot=gcc&r1=1.60&r2=1.61
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.3407&r2=1.3408
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.849&r2=1.850
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.627&r2=1.628
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.697&r2=1.698
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gcc&r1=1.326&r2=1.327
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.2752&r2=1.2753
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/template1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1

Comment 10 GCC Commits 2003-06-10 07:22:32 UTC
Subject: Bug 11131

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	mmitchel@gcc.gnu.org	2003-06-10 07:19:57

Modified files:
	gcc            : ChangeLog tree-inline.c 
	gcc/cp         : ChangeLog cp-tree.h decl2.c pt.c tree.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/opt: template1.C 

Log message:
	PR c++/11131
	* tree-inline.c (inlinable_function_p): Call the language-specific
	hook early.
	
	PR c++/11131
	* cp-tree.h (template_for_substitution): Declare.
	* decl2.c (mark_used): Use it when figuring out whether or not a
	function is inline.
	* pt.c (template_for_substitution): Give it external linkage.
	* tree.c (cp_cannot_inline_tree_fn): Instantiate as early as
	possible.
	
	PR c++/11131
	* g++.dg/opt/template1.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.18129&r2=1.18130
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-inline.c.diff?cvsroot=gcc&r1=1.60&r2=1.61
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.3407&r2=1.3408
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.849&r2=1.850
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.627&r2=1.628
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.697&r2=1.698
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gcc&r1=1.326&r2=1.327
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.2752&r2=1.2753
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/template1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1

Comment 11 GCC Commits 2003-06-11 17:02:18 UTC
Subject: Bug 11131

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	mmitchel@gcc.gnu.org	2003-06-11 17:02:14

Modified files:
	gcc/cp         : ChangeLog tree.c 

Log message:
	PR c++/11131
	* tree.c (cp_cannot_inline_fn): Check for "inline" before
	instantiation.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.3411&r2=1.3412
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gcc&r1=1.327&r2=1.328

Comment 12 Mark Mitchell 2003-06-11 17:04:11 UTC
Fixed with patches attached.
Comment 13 Andrew Pinski 2003-07-27 20:12:27 UTC
The test fails on i686-pc-linux-gnu for some reason but it does not fail on powerpc-apple-
darwin6.6, this on the mainline (20030727).
Comment 14 Steven Bosscher 2003-07-29 09:16:10 UTC
Don't you just love grep?  I used it to search the gcc-testresults archives, 
and found out this:

Last time test passed:
http://gcc.gnu.org/ml/gcc-testresults/2003-07/msg00668.html
LAST_UPDATED: Fri Jul 11 21:17:03 UTC 2003
686-unknown-openbsd3.1
                      
First time test failed:                                                          
http://gcc.gnu.org/ml/gcc-testresults/2003-07/msg00690.html
LAST_UPDATED: Sat Jul 12 04:01:24 UTC 2003
686-unknown-openbsd3.1
FAIL: g++.dg/opt/template1.C scan-assembler-not foo1

So in that ~7 hour window a patch was checked in that caused this regression. 
That shouldn't be too hard to find with the reghunt script.
Comment 15 Steven Bosscher 2003-07-29 09:26:48 UTC
Created attachment 4501 [details]
cvs diff -c3p -D "Fri Jul 11 21:17:03 UTC 2003" -D "Sat Jul 12 04:01:24 UTC 2003"

This looks like Honza's cgraph work re-introduced this bug.
Comment 16 Steven Bosscher 2003-07-29 09:28:34 UTC
Jan, you caused this :-P
Comment 17 GCC Commits 2003-07-29 17:42:36 UTC
Subject: Bug 11131

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	hubicka@gcc.gnu.org	2003-07-29 17:42:34

Modified files:
	gcc            : ChangeLog tree-inline.c 

Log message:
	PR C++/11131
	* tree-inline.c (expand_call_inline): Always call inlinable_function_p
	in !unit-at-a-time mode.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.643&r2=2.644
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-inline.c.diff?cvsroot=gcc&r1=1.70&r2=1.71

Comment 18 Jan Hubicka 2003-07-29 17:51:13 UTC
Should be fixed again by my patch. Sorry for breaking this.