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: [PATCH] RFC new builtin to fix PPC/SYSV varargs bug



On 19-Apr-99 Franz Sirl wrote:
> Hi,
> 
> I have a possible solution now for the varargs problem on PPC/SYSV, as 
> tested by gcc.c-torture/execute/980608-1.c and currently FAILing on 
> PPC/SYSV. The problem is that at the time when cum->varargs_offset is set 
> in setup_incoming_varargs, the value of current_function_outgoing_args_size 
> is not yet known. I was able to overcome this for the prolog code, but I 
> didn't find a good solution for fixing __builtin_args_info(4), which 
> accesses cum->varargs_offset. My suggestion is to introduce a new builtin 
> like __builtin_varargs_save_area.
> 
> This is a quick testhack to show the principle. I would like to know if 
> such a patch would be accepted or if I have to look for a different 
> solution (a more general solution might be to introduce a new virtual_rtx 
> in global_rtl). Do I have to modify additional files to correctly insert 
> the new builtin? Which builtin should I use as a good template? I used 
> __builtin_frame_address for now, but I don't need the parameter and I don't 
> know what all the stuff in c-decl.c means :-) A few hints would be good.
> 
> With this patch I was able to produce assembler files that look OK as far I 
> can see.
> 
> If the principle of the patch is OK, I would introduce a new target macro 
> like VARARGS_SAVE_AREA_RTX_FUNC, defined to be 
> "plus_constant(virtual_stack_vars_rtx, -RS6000_VARARGS_SIZE)" for PPC/SYSV 
> and would error out in expr.c if the macro is not defined.
> 

Franz,

Does this change (or the other part you're working on if it's separate) fix
the problem of outgoing function arguments destroying the varargs space?  This
is a problem I've seen, and I have patched the compiler to generate a warning
when it occurs.  The problem is that the size (hence placement) of the stack
space required for outgoing function calls is not known at prologue generation
time.  It ends up placing these arguments in the same stack space as the
varargs control structure occupies.

Thanks for any info/comments.


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