fix for x86-64 failure of testsuite/gcc.dg/titype-1.c

fix for x86-64 failure of testsuite/gcc.dg/titype-1.c

[Jan Beulich]

The code in ix86_va_arg() previously assumed in once place that when
need_temp was set, container would always be a MEM (in another place,
the case of this being a register was explicitly excluded). The patch
below generally forces need_temp to off when the container for the
argument is a register, which fixes the failure of the test mentioned in
the subject. Regression tested on x86_64-unknown-linux-gnu.

2004-06-09 Jan Beulich <jbeulich@novell.com>

	* config/i386/i386.c (ix86_va_arg): Don't need temporary for
passing
	arguments the container for which are registers.

--- /usr/local/src/gcc-3.4.0/gcc/config/i386/i386.c	2004-02-25
01:40:54.000000000 +0100
+++ 3.4.0/gcc/config/i386/i386.c	2004-06-09 16:00:48.338662096
+0200
@@ -3180,7 +3190,7 @@
 		        &needed_intregs, &needed_sseregs);
 
 
-      need_temp = ((needed_intregs && TYPE_ALIGN (type) > 64)
+      need_temp = !REG_P (container) && ((needed_intregs && TYPE_ALIGN
(type) > 64)
 		   || TYPE_ALIGN (type) > 128);
 
       /* In case we are passing structure, verify that it is
consecutive block

Re: fix for x86-64 failure of testsuite/gcc.dg/titype-1.c

[Paolo Carlini]

Jan Beulich wrote:

>--- /usr/local/src/gcc-3.4.0/gcc/config/i386/i386.c	2004-02-25
>  
>
Did you get my message pointing out that, as a rule, patches should be 
diffed
against current CVS sources?

Thanks,
Paolo.

Re: fix for x86-64 failure of testsuite/gcc.dg/titype-1.c

[Gerald Pfeifer]

On Wed, 9 Jun 2004, Jan Beulich wrote:
> Yes, I did. But with all these burocratic rules I'm getting close to
> give up publishing fixes for bugs... I understand this for large scale
> changes, but for one-liners like this it doesn't seem appropriate. After
> all, keeping local stuff in sync with the cvs is not effortless, however
> much you try to automate it, especially when the number of changes you
> have on top of that is high. Or maybe I just don't know about the magics
> to resolve colliding patches automatically...

Especially in this case, where your local changes conflict with current
upstream sources it is important that you provide a patcht that applies
straight away.

Gerald
-- 
Gerald Pfeifer (Jerry)   gerald@pfeifer.com   http://www.pfeifer.com/gerald/

Re: fix for x86-64 failure of testsuite/gcc.dg/titype-1.c

[Jason Merrill]

On Wed, 09 Jun 2004 17:53:58 +0200, "Jan Beulich" <JBeulich@novell.com> wrote:

> Yes, I did. But with all these burocratic rules I'm getting close to give
> up publishing fixes for bugs... I understand this for large scale
> changes, but for one-liners like this it doesn't seem appropriate. After
> all, keeping local stuff in sync with the cvs is not effortless, however
> much you try to automate it, especially when the number of changes you
> have on top of that is high. Or maybe I just don't know about the magics
> to resolve colliding patches automatically...

For a patch like this, it's pretty straightforward to make your diff as
below, check out a copy of the same file from the trunk, apply your patch,
and make a new diff.  That's what I do when moving a patch between
branches.

If you have a lot of patches applied to your sources, I find that it helps
to check out another copy just for testing and submitting individual
patches.

Jason

Re: fix for x86-64 failure of testsuite/gcc.dg/titype-1.c

[Paolo Carlini]

Jan Beulich wrote:

>Yes, I did. But with all these burocratic rules I'm getting close to
>give up publishing fixes for bugs...
>
This would be very, very sad. However, I think you will understand that 
those
"burocratic rules" are followed by *everyone*: global maintainers, novices,
"normal" contributors... after a while things become rather smooth.

Paolo.

Re: fix for x86-64 failure of testsuite/gcc.dg/titype-1.c

[Jan Beulich]

Yes, I did. But with all these burocratic rules I'm getting close to
give up publishing fixes for bugs... I understand this for large scale
changes, but for one-liners like this it doesn't seem appropriate. After
all, keeping local stuff in sync with the cvs is not effortless, however
much you try to automate it, especially when the number of changes you
have on top of that is high. Or maybe I just don't know about the magics
to resolve colliding patches automatically... Sorry, Jan

>>> Paolo Carlini <pcarlini@suse.de> 09.06.04 17:40:13 >>>
Jan Beulich wrote:

>--- /usr/local/src/gcc-3.4.0/gcc/config/i386/i386.c	2004-02-25
>  
>
Did you get my message pointing out that, as a rule, patches should be

diffed
against current CVS sources?

Thanks,
Paolo.