Re: c/5787: gcc-3.0.4 generates incorrect DEC ALPHA code in a varargs function

Re: c/5787: gcc-3.0.4 generates incorrect DEC ALPHA code in a varargs function

[rodrigc]

Synopsis: gcc-3.0.4 generates incorrect DEC ALPHA code in a varargs function

State-Changed-From-To: feedback->closed
State-Changed-By: rodrigc
State-Changed-When: Sat Apr 20 13:25:17 2002
State-Changed-Why:
    No feedback.

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

Re: c/5787: gcc-3.0.4 generates incorrect DEC ALPHA code in a varargs function

[rodrigc]

Synopsis: gcc-3.0.4 generates incorrect DEC ALPHA code in a varargs function

State-Changed-From-To: open->feedback
State-Changed-By: rodrigc
State-Changed-When: Tue Feb 26 16:30:39 2002
State-Changed-Why:
    Please contribute a complete, reproduceable testcase,
    as documented in: http://gcc.gnu.org/bugs.html

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

c/5787: gcc-3.0.4 generates incorrect DEC ALPHA code in a varargs function

[kbosley]

>Number:         5787
>Category:       c
>Synopsis:       gcc-3.0.4 generates incorrect DEC ALPHA code in a varargs function
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 26 10:06:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Kevin Bosley
>Release:        3.0.4
>Organization:
ArborText, Inc.
>Environment:
System: OSF1 labalpha1.arbortext.com V5.1 1885 alpha
Machine: alpha
	
host: alphaev56-dec-osf5.1
build: alphaev56-dec-osf5.1
target: alphaev56-dec-osf5.1
configured with: ../../gcc-3.0.4/configure --prefix=/ati/devel/tools/gcc-3.0.4/install/alpha --enable-shared --enable-threads
>Description:
	GCC version 3.0.4 generates bad subroutine prolog code for a varargs
	function on a DEC ALPHA platform.

	To be precise, it generates code which saves general registers 19, 20,
	21 and floating point registers f19, f20, and f21 outside of the 
	allocated stack frame.

	It generates the correct save instructions for registers 19, 20, and
	21 as well.

	Here is an excerpt of the generated prolog.  The comments
	to the right indicate the error:

test:
        .frame $15,64,$26,24
        .mask 0x4008000,-64
$test..ng:	
        lda $30,-64($30)	only 64 bytes allocated for frame
        stq $26,0($30)
        stq $15,8($30)
        mov $30,$15
        .prologue 0
        stq $16,16($15)
        mov $17,$1
        stq $18,32($15)

        stq $19,112($15)	---+
        stq $20,120($15)	   |
        stq $21,128($15)	   |
        stt $f19,64($15)	   => bad save code, writes past 64 byte frame
        stt $f20,72($15)	   |
        stt $f21,80($15)	---+

        stq $19,40($15)		correct save code for 19-21
        stq $20,48($15)
        stq $21,56($15)
        stl $1,24($15)
        mov $15,$30

>How-To-Repeat:

Here's the preprocessor output:

***** START OF PREPROCESSOR OUTPUT *****
# 35 "badprolog.c"
typedef struct
{
  char *w;
  long x;
  void *y;
  void *z;
} badtype;

void test(char *a, int b, char *c, badtype d, ...)
{
}
***** END OF PREPROCESSOR OUTPUT *****

>Fix:
	The only workaround I know of is to recode the function to take the 
	address of struct "badtype" as a parameter instead


Thanks for your assistance!

Kevin L. Bosley
Manager of Software Development
Arbortext, Inc.
1000 Victors Way
Ann Arbor, MI 48103
734-327-6077
>Release-Note:
>Audit-Trail:
>Unformatted: