[PATCH] Add testcase for possible bug in gcc-4_4 ix86 branch

[asharif tools]

The jump was only there because I narrowed down the problem code from
a C file and the jump was in the original code.

I was able to reproduce the problem with a simpler testcase, which is
below. This fails with this patch
(http://gcc.gnu.org/viewcvs?view=revision&revision=153780), but passes
otherwise. It passes on gcc trunk as well (I tested after configuring
--with-target= i386 and x86_64).

Comments? OK for a resubmission?

Index: gcc/testsuite/gcc.target/i386/max-stack-align.c
===================================================================
--- gcc/testsuite/gcc.target/i386/max-stack-align.c	(revision 0)
+++ gcc/testsuite/gcc.target/i386/max-stack-align.c	(revision 0)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-fomit-frame-pointer" } */
+/* { dg-require-effective-target lp64 } */
+
+void foo()
+{
+  int a=0, b=0, c=0, e=0, f=0, g=0, h=0, i=0;
+	__asm__ __volatile__ ("addl 	%%rbp,%%rbp"
+		: "=rbp"(a)
+		: "rbp"(b)
+		: "rbp"
+	);
+}
+
~/a/gcc-svn-rw/trunk


On Mon, Dec 13, 2010 at 5:00 PM, Ian Lance Taylor <iant@google.com> wrote:
> asharif tools <asharif.tools@gmail.com> writes:
>
>> Index: gcc/testsuite/gcc.target/i386/max-stack-align.c
>> ===================================================================
>> --- gcc/testsuite/gcc.target/i386/max-stack-align.c   (revision 0)
>> +++ gcc/testsuite/gcc.target/i386/max-stack-align.c   (revision 0)
>> @@ -0,0 +1,13 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-fomit-frame-pointer" } */
>> +/* { dg-require-effective-target lp64 } */
>> +
>> +void foo()
>> +{
>> +  int a=0, b=0, c=0, e=0, f=0, g=0, h=0, i=0;
>> +label:
>> +     __asm__ volatile( " jb label "
>> +                       : : "c" (a), "d" (a), "S" (a), "D" (a), "r" (a), "a" (a) ,"r" (a), "r" (a)
>> +                       : "%""rbp" );
>> +}
>
> I don't understand why you want to have a jump in the asm.  But, if you
> do need one, you need to also define the label in the asm, not in the C
> code.  The C label "label" is not going to be named "label" in the
> assembler code.
>
> Ian
>