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]
Other format: [Raw text]

Re: va-arg-25.c still fails on i686-linux


> 
> On 12/01/2004, at 4:37 PM, Jan Hubicka wrote:
> 
> >>Jan Hubicka <hubicka@ucw.cz> writes:
> >>
> >>>>
> >>>>On 09/01/2004, at 11:06 PM, Zack Weinberg wrote:
> >>>>
> >>>>>
> >>>>>I am still seeing va-arg-25.c fail at all optimization levels on
> >>>>>i686-linux.  It has done so, as far as I can tell, ever since it
> >>>>>was introduced.  Could you please either fix it or XFAIL it?
> >>>>>
> >>>>I think it would be better if an x86 port maintainer looked at this
> >>>>failure.  The testcase does not fail on powerpc-Darwin.
> >>>
> >>>It don't even need x86 port maintainer :)
> >>>The problem is wrong aligning of va_arg inside builtins.c when 
> >>>argument
> >>>alignment exceeds PARM_BOUNDARY.
> >>>
> >>>Additionally I noticed some problems with SSE enabled (we mistakely 
> >>>used
> >>>SSE regiser for variadic call and output warning)
> >>>
> >>>Note that I am not quite sure about the PAD_VARARGS_DOWN check, it 
> >>>just
> >>>seems appropriate at that place.
> >>>
> >>>Bootstrapping/regtesting in progress, OK if it passes?
> >>
> >>The concept looks good but I am nervous about a change in
> >>machine-independent code.  Can you arrange testing on a few more
> >>architectures?  (especially ones with complicated rules about
> >>arguments being passed in registers - ia64 comes to mind).
> >
> >Every architecture passing arguments in registers use it's own va_arg
> >expander (see ia64_va_arg).  This code triggers only in quite specific
> >case of architecture having no register passing convention but still
> >requiring larger alignment than word for some operands.  I know only of
> >i386 being such a crazy creature.
> 
> ppc does this, in fact that was the motivation for this testcase.

I see, it has it's own implementation tought as the default is simply
broken.  Can you please check whether my new code makes it possible to
remove the altivec conditional inside rs6000_va_arg?

I was arguing that the code shall be safe in a way that it should not
break any existing port as it would be either broken or never trigger
this code.  This still seems to hold.

Honza


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