[Bug middle-end/44583] New: [4.6 Regression] c-c++-common/torture/complex-sign-add.c

[Bug middle-end/44583] New: [4.6 Regression] c-c++-common/torture/complex-sign-add.c

[hjl dot tools at gmail dot com]

On Linux/ia64, revision 160916 gave

FAIL: c-c++-common/torture/complex-sign-add.c  -O0  execution test
FAIL: c-c++-common/torture/complex-sign-sub.c  -O0  execution test

Revision 160869 is OK.


-- 
           Summary: [4.6 Regression] c-c++-common/torture/complex-sign-add.c
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl dot tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583

[Bug middle-end/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2010-06-19 10:39 -------
Likely mine.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-06-19 10:39:00
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583

[Bug middle-end/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2010-06-19 10:58 -------
Bah - gigantic testcases.

And maybe not mine (I tought r160903 is the cause).  But the testcase
do not even run into gimplify_modify_expr_complex_part.  And I do not
see any references to uninitialized data in the .optimized dump
(just testing i?86 here).

HJ, can you reduce one of the execute fails to a single type and arith?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
         AssignedTo|rguenth at gcc dot gnu dot  |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW
   Target Milestone|---                         |4.6.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583

[Bug middle-end/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c

[sje at cup dot hp dot com]

------- Comment #3 from sje at cup dot hp dot com  2010-06-25 20:21 -------
I see this failure on ia64 linux and hp-ux.  The interesting thing is that it
fails when compiled with C++ but not when compiled with C.  Here is a smaller
test case that shows that the imaginary part of c1 is +0 in the good case
(compiled with C) and -0 in the bad case (compiled with C++).  This only shows
up when not doing any optimization (-O0) because with optimization everything
seems to get correctly folded.

#ifdef __cplusplus
extern "C" {
#endif
extern void exit(int);
int printf(const char *format, ...);
#ifdef __cplusplus
}
#endif

int main (void) {

 _Complex float a1, b1, c1;

 a1 = 0.0f + 0.0if;
 b1 = 0.0f - 0.0if;

 c1 = a1 + b1;
 if (__builtin_copysignf (1.0, __imag__ (a1)) != + 1.0) printf("one\n");
 if (__builtin_copysignf (1.0, __imag__ (b1)) != - 1.0) printf("two\n");
 if (__builtin_copysignf (1.0, __imag__ (c1)) != + 1.0) printf("three\n");
 printf("%f\n",__imag__ (c1));
 exit (0);
}


-- 

sje at cup dot hp dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sje at cup dot hp dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583

[Bug middle-end/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2010-06-25 20:51 -------
Can you verify that reverting r160903 fixes the issue and attach differences
in -fdump-rtl-expand-details and assembly (and maybe point me to the
important difference?)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583

[Bug middle-end/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c

[sje at cup dot hp dot com]

------- Comment #5 from sje at cup dot hp dot com  2010-06-25 22:47 -------
I verified that this works in r160902 and fails in 160903.


In 160902 I get this (partial) psuedo-code:

  IMAGPART_EXPR <a1> = 0.0;
  D.1749_4 = -0.0;
  IMAGPART_EXPR <b1> = D.1749_4;
  D.1760_12 = IMAGPART_EXPR <a1>;
  D.1762_14 = IMAGPART_EXPR <b1>;
  D.1764_16 = D.1760_12 + D.1762_14;
  IMAGPART_EXPR <c1> = D.1764_16;
  D.1754_9 = IMAGPART_EXPR <c1>;
  D.1755_10 = (double) D.1754_9;
  printf (&"%f\n"[0], D.1755_10);

In 160903 I get:

  b1$imag_4 = -0.0;
  c1$imag_10 = b1$imag_4 + 0.0;
  D.1749_7 = c1$imag_10;
  D.1750_8 = (double) D.1749_7;
  printf (&"%f\n"[0], D.1750_8);

I am not sure if it is significant that in the first one I have:

        D.1764_16  = 0.0 + (- 0.0)

and in the second one I have:

        c1$imag_10 = (- 0.0) + 0.0

I.e. the order of the -0.0 is different.

Looking at the assembly code in 160902 I see (paraphrasing):

 fmov f8 = f0
 fneg f6 = f0
 fadd.s f6 = f8, f6

and in 160903 I see:

 fneg f6 = f0
 fadd.s f6 = f6, f0

Changing the new code by hand to swap the arguments to fadd around does
seem to fix things in the new code.  But, oddly enough, if I swap the
arguments around in the old (good) code it doesn't break, I am not sure why.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583

[Bug middle-end/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c

[rguenther at suse dot de]

------- Comment #6 from rguenther at suse dot de  2010-06-26 09:18 -------
Subject: Re:  [4.6 Regression]
 c-c++-common/torture/complex-sign-add.c

On Fri, 25 Jun 2010, sje at cup dot hp dot com wrote:

> ------- Comment #5 from sje at cup dot hp dot com  2010-06-25 22:47 -------
> I verified that this works in r160902 and fails in 160903.

Thanks for further investigating.

> In 160902 I get this (partial) psuedo-code:
> 
>   IMAGPART_EXPR <a1> = 0.0;
>   D.1749_4 = -0.0;
>   IMAGPART_EXPR <b1> = D.1749_4;
>   D.1760_12 = IMAGPART_EXPR <a1>;
>   D.1762_14 = IMAGPART_EXPR <b1>;
>   D.1764_16 = D.1760_12 + D.1762_14;
>   IMAGPART_EXPR <c1> = D.1764_16;
>   D.1754_9 = IMAGPART_EXPR <c1>;
>   D.1755_10 = (double) D.1754_9;
>   printf (&"%f\n"[0], D.1755_10);
> 
> In 160903 I get:
> 
>   b1$imag_4 = -0.0;
>   c1$imag_10 = b1$imag_4 + 0.0;
>   D.1749_7 = c1$imag_10;
>   D.1750_8 = (double) D.1749_7;
>   printf (&"%f\n"[0], D.1750_8);
> 
> I am not sure if it is significant that in the first one I have:
> 
>         D.1764_16  = 0.0 + (- 0.0)
> 
> and in the second one I have:
> 
>         c1$imag_10 = (- 0.0) + 0.0
> 
> I.e. the order of the -0.0 is different.

Even floating-point addition is commutative.  The difference
is because we canonicalize 0.0 + b1$imag_4 to have the
constant in 2nd place.

> Looking at the assembly code in 160902 I see (paraphrasing):
> 
>  fmov f8 = f0
>  fneg f6 = f0
>  fadd.s f6 = f8, f6
> 
> and in 160903 I see:
> 
>  fneg f6 = f0
>  fadd.s f6 = f6, f0

I suppose f0 is a special register for 0.0?  Googling around
finds me references that f0 is treated specially wrt zero
signs at least when used in fmadd operations.

> Changing the new code by hand to swap the arguments to fadd around does
> seem to fix things in the new code.  But, oddly enough, if I swap the
> arguments around in the old (good) code it doesn't break, I am not sure why.

Which would hint at this is exactly the problem.

Thus, with -fsigned-zeros we cannot use the f0 register in
arithmetic but have to copy it to a regular register first?

So, does

   fneg f6 = f0
   fmov f8 = f0
   fadd.s f6 = f6, f8

work?

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583

[Bug target/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2010-06-26 09:28 -------
Another way would probably be to ensure that f0 always appears as first operand
by adjusting the various patterns in ia64.md to only allow fr_reg_operand
in the 2nd operand slot of addsf3 (and maybe other patterns).

At least the *maddsf4 pattern incorrectly allows fr_reg_or_fp01_operand
for the third operand which is not correct if signed zeros are supported.

HJ, can you investigate?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583

[Bug target/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2010-06-26 10:05 -------
Testcase which should fail at all optimization levels
(assuming that fadd.s f4, f0 is internally going through the
mac unit as fmac.s f4, f1, f0)

float __attribute__((noinline))
foo (float x)
{
  float y = x + 0.0;
  return __builtin_copysignf (1.0, y);
}
int main()
{
  if (foo (-0.0) != 1.0)
    __builtin_abort ();
  return 0;
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583

[Bug target/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c fails for signed zeros

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2010-07-23 12:04 -------
CCing another IA64 maintainer.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583

[Bug target/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c fails for signed zeros

[sje at cup dot hp dot com]

------- Comment #10 from sje at cup dot hp dot com  2010-07-29 21:32 -------
I have posted a patch for this bug to gcc-patches.

http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02302.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583

[Bug target/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c fails for signed zeros

[sje at gcc dot gnu dot org]

------- Comment #11 from sje at gcc dot gnu dot org  2010-08-04 18:32 -------
Subject: Bug 44583

Author: sje
Date: Wed Aug  4 18:32:37 2010
New Revision: 162869

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162869
Log:
2010-07-29  Steve Ellcey  <sje@cup.hp.com>

        PR target/44583
        * config/ia64/constraints.md (Z): New.
        * config/ia64/predicates.md (fr_reg_or_signed_fp01_operand): New.
        (xfreg_or_signed_fp01_operand): New.
        * config/ia64/ia64.md (addsf3): Replace fr_reg_or_fp01_operand
        with fr_reg_or_signed_fp01_operand and constraint G with Z.
        (subsf3): Ditto.
        (*maddsf4): Ditto.
        (*msubsf4): Ditto.
        (adddf3): Ditto.
        (adddf3_trunc): Ditto.
        (subdf3): Ditto.
        (*subdf3_trunc): Ditto.
        (*madddf4): Ditto.
        (*madddf4_trunc): Ditto.
        (*msubdf4): Ditto.
        (*msubdf4_trunc): Ditto.
        (addxf3): Replace xfreg_or_fp01_operand with
        xfreg_or_signed_fp01_operand and constraint G with Z.
        (*addxf3_truncsf): Ditto.
        (*addxf3_truncdf): Ditto.
        (subxf3): Ditto.
        (*subxf3_truncsf): Ditto.
        (*subxf3_truncdf): Ditto.
        (*maddxf4): Ditto.
        (*maddxf4_truncsf): Ditto.
        (*maddxf4_truncdf): Ditto.
        (*msubxf4): Ditto.
        (*msubxf4_truncsf): Ditto.
        (*msubxf4_truncdf): Ditto.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/ia64/constraints.md
    trunk/gcc/config/ia64/ia64.md
    trunk/gcc/config/ia64/predicates.md


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583

[Bug target/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c fails for signed zeros

[sje at cup dot hp dot com]

------- Comment #12 from sje at cup dot hp dot com  2010-08-04 19:25 -------
Fixed on ToT.


-- 

sje at cup dot hp dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583