public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/11131] New: Unrelated declaration removes inline flag from function
@ 2003-06-09 12:51 bangerth@dealii.org
  2003-06-09 13:06 ` [Bug c++/11131] " pinskia@physics.uc.edu
                   ` (19 more replies)
  0 siblings, 20 replies; 21+ messages in thread
From: bangerth@dealii.org @ 2003-06-09 12:51 UTC (permalink / raw)
  To: gcc-bugs

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11131

           Summary: Unrelated declaration removes inline flag from function
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Keywords: pessimizes-code
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: bangerth@dealii.org
                CC: gcc-bugs@gcc.gnu.org

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.


^ permalink raw reply	[flat|nested] 21+ messages in thread
end of thread, other threads:[~2003-07-29 17:51 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-09 12:51 [Bug c++/11131] New: Unrelated declaration removes inline flag from function bangerth@dealii.org
2003-06-09 13:06 ` [Bug c++/11131] " pinskia@physics.uc.edu
2003-06-09 13:13 ` bangerth@ices.utexas.edu
2003-06-09 13:21 ` pinskia@physics.uc.edu
2003-06-09 13:26 ` bangerth@ices.utexas.edu
2003-06-09 14:25 ` nathan@gcc.gnu.org
2003-06-09 14:26 ` nathan@gcc.gnu.org
2003-06-09 17:42 ` nathan@codesourcery.com
2003-06-09 20:20 ` bangerth@ices.utexas.edu
2003-06-10  0:00 ` bangerth@ices.utexas.edu
2003-06-10  7:24 ` cvs-commit@gcc.gnu.org
2003-06-10  7:24 ` cvs-commit@gcc.gnu.org
2003-06-10  7:24 ` cvs-commit@gcc.gnu.org
2003-06-11 17:02 ` cvs-commit@gcc.gnu.org
2003-06-11 17:04 ` mmitchel@gcc.gnu.org
2003-07-27 20:12 ` pinskia at physics dot uc dot edu
2003-07-27 20:12 ` [Bug c++/11131] [3.4 Regression]Unrelated " pinskia at physics dot uc dot edu
2003-07-29  9:16 ` steven at gcc dot gnu dot org
2003-07-29  9:28 ` steven at gcc dot gnu dot org
2003-07-29 17:42 ` cvs-commit at gcc dot gnu dot org
2003-07-29 17:51 ` hubicka at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).