This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: __builtin_va_arg rfc


At 19:49 25.04.99 , Franz Sirl wrote:
>Am Sun, 25 Apr 1999 schrieb Richard Henderson:
>>On Sat, Apr 24, 1999 at 07:23:58PM -0600, Jeffrey A Law wrote:
>>> An FYI, I don't think we should try to deal with this for egcs-1.2, even
>>> though the primary motivation is to fix a ppc varargs/stdarg problem.
>>
>>Ok.
>>
>>There is another way to solve the problem for PPC -- Alpha, which
>>also uses a struct with weird initializations, builds the whole thing
>>internally and passes it out like so
>>
>>/* Call __builtin_next_arg even though we aren't using its value, so that
>>   we can verify that firstarg is correct.  */
>>
>>#define va_start(pvar, firstarg)                                \
>>  (__builtin_next_arg (firstarg),                               \
>>   (pvar) = *(__gnuc_va_list *) __builtin_saveregs ())
>>
>>All that's needed is for ppc to hide quite a lot of magic in
>>expand_builtin_saveregs and suffer the cost of a structure copy.
>
>Damned, I just started writing the PPC backend for Richards patch :-).
>
>I'm willing to implement anything as long as it will go into 1.2. But from my
>point of view it would make more sense to include Richards patch for 1.2 but
>not to use it, except on PPC. This would make it possible for me to
>easily backport any fixes in the mainline and possibly this stuff might be
>enabled in 1.2.1 or later for other platforms too?

So which way to go now for 1.2? I just had another idea on how to get a 
low-invasive patch. We could do the following in case BUILT_IN_ARGS_INFO in 
expr.c:

        #ifdef CUMULATIVE_ARG_INFO_IS_RTX
        if (CUMULATIVE_ARG_INFO_IS_RTX(wordnum))
          return word_ptr[wordnum];
        #endif
        return GEN_INT (word_ptr[wordnum]);

That's even easier than my first __builtin_varargs_save_area patch and 
wouldn't be as complex to implement as Richard's suggestion above. The 
other stuff needed would be completely in the rs6000 backend now and is 
nearly identical to my __builtin_varargs_save_area patch, only one new 
field in CUMULATIVE_ARGS and the macro CUMULATIVE_ARG_INFO_IS_RTX have to 
be added.

So what do you think?

Franz.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]