This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c/9700: va_start gets __offset wrong in some situations
- From: Aron Griffis <agriffis at gentoo dot org>
- To: nobody at gcc dot gnu dot org, bjb at gentoo dot org, gcc-gnats at gcc dot gnu dot org,agriffis at gentoo dot org, gcc-bugs at gcc dot gnu dot org, wwoods at gentoo dot org,msterret at coat dot com, gcc-prs at gcc dot gnu dot org
- Date: Fri, 14 Feb 2003 20:58:29 -0500
- Subject: Re: c/9700: va_start gets __offset wrong in some situations
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