Bug 13057 - [3.3 Regression] regparm attribute not applied to destructor
Summary: [3.3 Regression] regparm attribute not applied to destructor
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: 3.3.3
Assignee: Not yet assigned to anyone
URL:
Keywords: patch, wrong-code
Depends on:
Blocks:
 
Reported: 2003-11-14 21:16 UTC by Brian Ryner
Modified: 2004-01-21 05:52 UTC (History)
1 user (show)

See Also:
Host: i686-pc-linux-gnu
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2003-11-15 02:58:30


Attachments
testcase source (81 bytes, text/plain)
2003-11-14 21:16 UTC, Brian Ryner
Details
assembly output without -mregparm (240 bytes, text/plain)
2003-11-14 21:20 UTC, Brian Ryner
Details
assembly output with -mregparm=1 (233 bytes, text/plain)
2003-11-14 21:20 UTC, Brian Ryner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Ryner 2003-11-14 21:16:18 UTC
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.
Comment 1 Brian Ryner 2003-11-14 21:16:55 UTC
Created attachment 5136 [details]
testcase source
Comment 2 Brian Ryner 2003-11-14 21:20:06 UTC
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.
Comment 3 Brian Ryner 2003-11-14 21:20:50 UTC
Created attachment 5138 [details]
assembly output with -mregparm=1

Compiled the same as previous attachment but with -mregparm=1.
Comment 4 Andrew Pinski 2003-11-15 02:58:30 UTC
Regression from 2.95.3.
Comment 5 Brian Ryner 2003-11-16 02:22:12 UTC
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.
Comment 6 Brian Ryner 2003-11-16 03:59:24 UTC
(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.
Comment 7 CVS Commits 2004-01-06 02:26:20 UTC
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

Comment 8 Mark Mitchell 2004-01-06 02:28:01 UTC
Fixed in GCC 3.4.
Comment 9 Gabriel Dos Reis 2004-01-06 16:30:04 UTC
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
Comment 10 Dara Hazeghi 2004-01-21 03:41:53 UTC
Patch applies cleanly to branch.
Comment 11 CVS Commits 2004-01-21 05:52:38 UTC
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

Comment 12 Gabriel Dos Reis 2004-01-21 05:52:42 UTC
Fixed with backport from mainline.