It appears that giving the regparm(1) attribute on a destructor does not cause it to pass the |this| pointer in a register. However, it will pass it in a register if I give -mregparm=1 on the command line. This works fine for normal methods, so it seems to be specific to destructors.
Created attachment 5136 [details] testcase source
Created attachment 5137 [details] assembly output without -mregparm Compiled with: c++ -fno-exceptions -Os -S -o test_regparm_dtor1.S test_regparm_dtor.cpp with a CVS trunk build from Oct 27.
Created attachment 5138 [details] assembly output with -mregparm=1 Compiled the same as previous attachment but with -mregparm=1.
Regression from 2.95.3.
I attempted to debug this today... I didn't quite figure out the problem but maybe this will trigger someone's memory: The regparm attribute is successfully parsed and attached to the destructor via decl_attributes(). This calls build_type_attribute_variant() which clones the node; the attributes are attached to the cloned node. This happens exactly the same way for a destructor and a normal method. When generating the assembly, init_cumulative_args() is called in i386.c which checks the regparm attribute. For a normal method, the fntype parameter to this method is the cloned node from build_type_attribute_variant, which has the attribute(s) attached to it. For the destructor, however, fntype is neither the node passed to decl_attributes nor the clone that was made. Whatever it is, it has a null attributes pointer, so no parameters are passed in registers.
(In reply to comment #5) > attribute(s) attached to it. For the destructor, however, fntype is neither the > node passed to decl_attributes nor the clone that was made. Whatever it is, it > has a null attributes pointer, so no parameters are passed in registers. > It looks like the node that init_cumulative_args() is called with for the destructor call is allocated from here: #1 0x082dc86b in make_node (code=METHOD_TYPE) at ../../gcc/gcc/tree.c:273 #2 0x082dd061 in build_method_type_directly (basetype=0x58, rettype=0x4022ac3c, argtypes=0x4022d94c) at ../../gcc/gcc/tree.c:3899 #3 0x08063dc2 in grokdeclarator (declarator=0x402f6640, declspecs=0x0, decl_context=FIELD, initialized=0, attrlist=0xbfffe570) at ../../gcc/gcc/cp/decl.c:8073 #4 0x0808651d in grokfield (declarator=0x58, declspecs=0x10, init=0x0, asmspec_tree=0x0, attrlist=0x402ec9d8) at ../../gcc/gcc/cp/decl2.c:874 This node does not get the destructor's attributes put onto it.
Subject: Bug 13057 CVSROOT: /cvs/gcc Module name: gcc Changes by: mmitchel@gcc.gnu.org 2004-01-06 02:26:14 Modified files: gcc/cp : ChangeLog class.c Log message: PR c++/13057 * class.c (build_clone): Copy type attributes from the original function to the clone. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.3858&r2=1.3859 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&r1=1.592&r2=1.593
Fixed in GCC 3.4.
Subject: Re: [3.3/3.4 Regression] regparm attribute not applied to destructor "cvs-commit at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | PR c++/13057 | * class.c (build_clone): Copy type attributes from the original | function to the clone. I've looked at this patch. I'm wondering if you believe a backport would be safe for branch. -- Gaby
Patch applies cleanly to branch.
Subject: Bug 13057 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_3-branch Changes by: gdr@gcc.gnu.org 2004-01-21 05:52:30 Modified files: gcc/cp : ChangeLog class.c Log message: Backport from mainline 2004-01-05 Mark Mitchell <mark@codesourcery.com> PR c++/13057 * class.c (build_clone): Copy type attributes from the original function to the clone. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.3076.2.239&r2=1.3076.2.240 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.499.2.26&r2=1.499.2.27
Fixed with backport from mainline.