Re: c++/10573: empty destructor not optimized away with 2 levels of inheritance and member with explicit destructor

Re: c++/10573: empty destructor not optimized away with 2 levels of inheritance and member with explicit destructor

[bangerth]

Synopsis: empty destructor not optimized away with 2 levels of inheritance and member with explicit destructor

State-Changed-From-To: open->closed
State-Changed-By: bangerth
State-Changed-When: Thu May  1 00:19:57 2003
State-Changed-Why:
    Confirmed, but already fixed. 3.3 gives this code:
    	pushl	%ebp
    	xorl	%eax, %eax
    	movl	%esp, %ebp
    	subl	$24, %esp
    	andl	$-16, %esp
    	movl	%ebp, %esp
    	popl	%ebp
    That's still silly, but at least better.
    
    Thanks anyway for the report. Let us know if you find any
    problems with gcc3.3 along the same lines.
    
      Wolfgang

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10573

c++/10573: empty destructor not optimized away with 2 levels of inheritance and member with explicit destructor

[dbaron]

>Number:         10573
>Category:       c++
>Synopsis:       empty destructor not optimized away with 2 levels of inheritance and member with explicit destructor
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Apr 30 23:26:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     dbaron@dbaron.org
>Release:        gcc version 3.2.2
>Organization:
>Environment:
> uname -srm
Linux 2.4.20-9smp i686
> cat /etc/redhat-release
Red Hat Linux release 9 (Shrike)
>Description:
gcc has optimizations that cause no code to be generated for empty destructors.  In a case that is important to Mozilla (for Mozilla's string classes), this optimization does not work as well as it could.

What follows is a reduced testcase for the problem in Mozilla (although the real code in Mozilla, for some reason, requires an additional level of inheritance to see the problem).

----------[string-dtor-opt.cpp]
struct M {
    ~M() {}
};
 
struct I {
    virtual ~I() {}
};
 
struct I2 : public I {
};
 
struct C : public I2 {
    M m;
};
 
int main()
{
    C c;
    return 0;
}
----------

This generates (when compiled with -O2 and -fno-exceptions) assembly for main that looks like this:

main:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $40, %esp
        movl    $_ZTV2I2+8, -24(%ebp)
        leal    -24(%ebp), %eax
        andl    $-16, %esp
        movl    %eax, (%esp)
        call    _ZN1ID2Ev
        movl    %ebp, %esp
        xorl    %eax, %eax
        popl    %ebp
        ret

When any one of the following changes is made:
 * the member variable |m| is removed
 * |struct C| inherits from |I| instead of |I2|
 * |struct M| has no explicit destructor
then the following assembly is generated:

main:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $24, %esp
        andl    $-16, %esp
        movl    %ebp, %esp
        xorl    %eax, %eax
        popl    %ebp
        ret

It would be a help to code size and performance in Mozilla (and probably in other programs as well) if this latter assembly were also generated for the code provided above.
>How-To-Repeat:
/usr/local/gcc-3.2.2/bin/g++ -S -o string-dtor-opt.s -O2 -fno-exceptions string-dtor-opt.cpp
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: