From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19387 invoked by alias); 15 Feb 2003 01:56:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 19373 invoked by uid 71); 15 Feb 2003 01:56:01 -0000 Date: Sat, 15 Feb 2003 01:56:00 -0000 Message-ID: <20030215015601.19372.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Aron Griffis Subject: Re: c/9700: va_start gets __offset wrong in some situations Reply-To: Aron Griffis X-SW-Source: 2003-02/txt/msg00654.txt.bz2 List-Id: The following reply was made to PR c/9700; it has been noted by GNATS. From: Aron Griffis To: nobody@gcc.gnu.org, bjb@gentoo.org, gcc-gnats@gcc.gnu.org, agriffis@gentoo.org, gcc-bugs@gcc.gnu.org, wwoods@gentoo.org, msterret@coat.com, gcc-prs@gcc.gnu.org Cc: Subject: Re: c/9700: va_start gets __offset wrong in some situations Date: Fri, 14 Feb 2003 20:58:29 -0500 Hi, I realize you get a lot of bogus bug reports, but please take a closer look at what I'm reporting. The problem here is when the argument list is constructed in a certain way, then the first invocation of va_arg will return the *last named argument* instead of the first unnamed argument. Regarding your simpler example, you're right, it returns a pointer to "two" as is documented. In the more complex example I posted, va_arg returns a pointer to "one" instead. This problem exists on Alpha where the generic stdarg builtins are used. I've run some tests on x86 and the problem doesn't appear. Here is the output from the example program I posted in bug 9709. Sorry I omitted it from the original bug report. In each function invocation below, an additional char is prepended to the argument list. As you can see, va_arg returns the wrong argument in only one situation. -1 immediately preceeds 999 in the argument list and is the last named argument. 0: __base = 0x11ffff3f0 (999) 1: __base = 0x11ffff3f0 (999) 2: __base = 0x11ffff3f0 (999) 3: __base = 0x11ffff3f0 (999) 4: __base = 0x11ffff3f0 (999) 5: __base = 0x11ffff3e8 (-1) <<<<<<<<<<<<< 6: __base = 0x11ffff3f0 (999) 7: __base = 0x11ffff3f0 (999) 8: __base = 0x11ffff3f0 (999) 9: __base = 0x11ffff3f0 (999) 10: __base = 0x11ffff3f0 (999) 11: __base = 0x11ffff3f0 (999) 12: __base = 0x11ffff3f0 (999) 13: __base = 0x11ffff3f0 (999) 14: __base = 0x11ffff3f0 (999) 15: __base = 0x11ffff3f0 (999) 16: __base = 0x11ffff3f0 (999) 17: __base = 0x11ffff3f0 (999) 18: __base = 0x11ffff3f0 (999) 19: __base = 0x11ffff3f0 (999) 20: __base = 0x11ffff3f0 (999) 21: __base = 0x11ffff3f0 (999) 22: __base = 0x11ffff3f0 (999) 23: __base = 0x11ffff3f0 (999) 24: __base = 0x11ffff3f0 (999) 25: __base = 0x11ffff3f0 (999) 26: __base = 0x11ffff3f0 (999) 27: __base = 0x11ffff3f0 (999) 28: __base = 0x11ffff3f0 (999) 29: __base = 0x11ffff3f0 (999) 30: __base = 0x11ffff3f0 (999) 31: __base = 0x11ffff3f0 (999) 32: __base = 0x11ffff3f0 (999) 33: __base = 0x11ffff3f0 (999) 34: __base = 0x11ffff3f0 (999) 35: __base = 0x11ffff3f0 (999) 36: __base = 0x11ffff3f0 (999) 37: __base = 0x11ffff3f0 (999) 38: __base = 0x11ffff3f0 (999) 39: __base = 0x11ffff3f0 (999) As it turns out, the above run demonstrates that the problem is somewhere in setting up the __base pointer, not in the calculation of __offset as I originally thought. Thanks, Aron