Re: c/9700: va_start gets __offset wrong in some situations

[Aron Griffis <agriffis@gentoo.org>]

The following reply was made to PR c/9700; it has been noted by GNATS.

From: Aron Griffis <agriffis@gentoo.org>
To: bangerth@dealii.org, bjb@gentoo.org, gcc-bugs@gcc.gnu.org,
	gcc-prs@gcc.gnu.org, msterret@coat.com, nobody@gcc.gnu.org,
	wwoods@gentoo.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c/9700: va_start gets __offset wrong in some situations
Date: Fri, 14 Feb 2003 21:28:13 -0500

 bangerth@dealii.org wrote:[Fri Feb 14 2003, 09:10:12PM EST]
 >     Admittedly I only looked at the program given in the first
 >     report. So, let me ask again: I think that that program
 >     does exactly what should be expected, is this right? If so,
 >     the comment in that program about expectations is wrong.
 
 Ah, this is where we're not communicating.  The comment is accurate.  I
 can rephrase it as follows, perhaps this is more clear:
 
     /*
      * This is the first invocation of va_arg.  The argument list is as
      * follows:
      *
      * 		a = 0
      * 		b = 0
      * 		c = 0
      * 		d = 0
      * 		e = 0
      * 		ap = { undef, undef }
      * 		first_custom = "one"
      * 		... = "two", "three"
      *
      * Therefore va_arg should return "two".  However in this example it
      * erroneously returns "one", which is first_custom.
      */
 
 >     Second question: if the program in the first report doesn't
 >     show the problem at all, is it demonstrated in the second?
 >     If so, I'll be happy to take a look at that one on Monday.
 
 It is demonstrated in both, but most clearly in the second, where __base
 is clearly pointing 8-bytes prior to the correct location.  It seems
 like the alignment of __base in the single instance is being corrected
 downward instead of upward.
 
 Note you will need an Alpha to build the second example program since
 the definition of va_list is different on x86.  However it might not be
 necessary since I've posted the output.
 
 Aron