[Bug rtl-optimization/30957] New: Misscompare with variable expansion optimization

[Bug rtl-optimization/30957] New: Misscompare with variable expansion optimization

[eres at il dot ibm dot com]

Compiling mzero6.c with -fvariable-expansion-in-unroller flag causes unexpected
abortion of the executable.

testsuite/gcc.c-torture/execute/ieee/mzero6.c  -w  -O2  -fno-show-column  -lm  
-funroll-loops --fast-math -O2  -fvariable-expansion-in-unroller -o out


-- 
           Summary: Misscompare with variable expansion optimization
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: eres at il dot ibm dot com


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[eres at il dot ibm dot com]

------- Comment #1 from eres at il dot ibm dot com  2007-02-25 11:33 -------
Created an attachment (id=13105)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13105&action=view)
RTL unroller's dump (compiled with -fvariable-expansion-in-unroller)

reg:DF 137 is the new variable expansion created to expand the accumulator
reg:DF 120 [ add_acc.0 ].


-- 


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[eres at il dot ibm dot com]

------- Comment #2 from eres at il dot ibm dot com  2007-02-25 14:50 -------
The execution fails also when acc is float (and not double)


-- 


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[eres at il dot ibm dot com]

------- Comment #3 from eres at il dot ibm dot com  2007-02-25 14:52 -------
Created an attachment (id=13107)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13107&action=view)
testcase for MVE

Running the executable of the attached testcase (compiled with MVE)
succeeded.  This looks strange as it seems mzero6.c and this tetscase have
similar loop structure:

 double acc = 0.0;
       for (int i = 0; i <= n; i++)
         acc += d;
       return acc;


-- 


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[eres at il dot ibm dot com]

------- Comment #4 from eres at il dot ibm dot com  2007-02-26 11:46 -------
Created an attachment (id=13113)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13113&action=view)
assembly file (PPC)

It seems that problem is in the initialization of the expansion
(which related to the sign of the init value).

The original accumulator is been initialized as follows:
fmr 0,1
rlwinm 0,3,0,29,31

while the expansion is been initialized as follows:
lis 11,.LC0@ha
lfs 13,.LC0@l(11)

when the expansion is been initialized with the value of the original
accumulator the program executed as expected.


-- 


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[eres at il dot ibm dot com]

------- Comment #5 from eres at il dot ibm dot com  2007-02-26 13:51 -------
The reason that this tescase fails is because the expansion is been initialized
with +0, which means that it's final result will be +0  and not -0 as expected.

expansion += d --> expansion += -0 --> +0


-- 


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[eres at il dot ibm dot com]

------- Comment #6 from eres at il dot ibm dot com  2007-02-26 15:01 -------
It seems that initializing the expansion with -zero (instead of +zero)
will solve this problem.

According IEEE standard if we have -

x += something; initializing x with -0 will cause x to get the sign of
something.

-0 + (-0) = -0
-0 + (+0) = +0


-- 


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2007-02-26 17:57 -------
-ffast-math violates the IEEE standard in some cases so why is this option
being used to test an ieee math testcase?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[eres at il dot ibm dot com]

------- Comment #8 from eres at il dot ibm dot com  2007-02-26 18:11 -------
MVE is enabled with -funsafe-math-optimizations as it changes the order of 
summation.  I think it should honor signed zero, which it does not in the
current implantation.  I agree that -funsafe-math-optimizations is more 
suitable than -fast-math as in the later signed zero is not been honored.


-- 


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2007-02-26 18:24 -------
Both -ffast-math and -funsafe-math-optimizations violate IEEE math specs so
this is an invalid bug.  At one point -funsafe-math-optimizations used to not
honor signed zero but recently you have:
-flag_signed_zeros with
2007-01-19  Roger Sayle  <roger@eyesopen.com>

        * common.opt (fsigned-zeros): New command line option.
        * flags.h (HONOR_SIGNED_ZEROS): Control via flag_signed_zeros instead
        of flag_unsafe_math_optimizations.
        * opts.c (set_fast_math_flags): The -ffast-math command line option
        implies -fno-signed-zeros.
        (fast_math_flags_set_p): Likewise.

But -funsafe-math-optimizations still says you can reassiocate so maybe this is
just the case where we want a flag for reassiocating.


-- 


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[eres at il dot ibm dot com]

------- Comment #10 from eres at il dot ibm dot com  2007-02-26 18:34 -------
I think that the way -fnsafe-math-optimization violates ieee is important.
Introducing flag_signed_zeros, as you mensioned before, enforce
-fnsafe-math-optimization to honor signed zero. So I think MVE should honor
that too. 


-- 


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[patchapp at dberlin dot org]

------- Comment #11 from patchapp at dberlin dot org  2007-04-22 07:25 -------
Subject: Bug number PR30957

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01378.html


-- 


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-04-22 07:29:14
               date|                            |


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[pinskia at gcc dot gnu dot org]

------- Comment #12 from pinskia at gcc dot gnu dot org  2007-05-09 07:27 -------
This testcase (gcc.dg/pr30957-1.c) fails on spu-elf because spu-elf's float
almost always treat -0.0 as 0.0.


-- 


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[ghazi at gcc dot gnu dot org]

------- Comment #13 from ghazi at gcc dot gnu dot org  2008-01-09 18:13 -------
This testcase has an execution failure on i686-pc-linux-gnu when using
-fpic/-fPIC.

http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00366.html


-- 

ghazi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ghazi at gcc dot gnu dot org
   Last reconfirmed|2007-04-22 07:29:14         |2008-01-09 18:13:13
               date|                            |


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[eres at il dot ibm dot com]

------- Comment #14 from eres at il dot ibm dot com  2008-01-10 15:05 -------
-fassociative-math and -fsigned-zeros flags can not co-exist.
I guess this testcase should be removed.


-- 


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[ubizjak at gmail dot com]

------- Comment #15 from ubizjak at gmail dot com  2008-01-10 18:23 -------
(In reply to comment #13)
> This testcase has an execution failure on i686-pc-linux-gnu when using
> -fpic/-fPIC.

They also fail for non-pic compilations when the testcase _really_ executes the
test:

Index: testsuite/gcc.dg/pr30957-1.c
===================================================================
--- testsuite/gcc.dg/pr30957-1.c        (revision 131441)
+++ testsuite/gcc.dg/pr30957-1.c        (working copy)
@@ -7,7 +7,7 @@
 extern void abort (void);
 extern void exit (int);

-float
+float __attribute__((noinline))
 foo (float d, int n)
 {
   unsigned i;


-- 


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[eres at il dot ibm dot com]

------- Comment #16 from eres at il dot ibm dot com  2008-01-10 18:32 -------
This is because the test requires -fassociative-math for enabling the
variable-expansion as well as -fsigned-zeros for honor the sign of zero; but
they can not co-exist; also under -funsafe-math-optimizations.


-- 


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[ghazi at gcc dot gnu dot org]

------- Comment #17 from ghazi at gcc dot gnu dot org  2009-01-17 02:56 -------
Reconfirming that gcc.dg/pr30957-1.c still XFAILs for me on x86_64.


-- 

ghazi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|ghazi at gcc dot gnu dot org|
   Last reconfirmed|2008-01-09 18:13:13         |2009-01-17 02:56:20
               date|                            |


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[ghazi at gcc dot gnu dot org]

------- Comment #18 from ghazi at gcc dot gnu dot org  2009-11-22 18:01 -------
Still fails


-- 

ghazi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2009-01-17 02:56:20         |2009-11-22 18:01:42
               date|                            |


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[ghazi at gcc dot gnu dot org]

------- Comment #19 from ghazi at gcc dot gnu dot org  2010-03-30 17:16 -------
gcc.dg/pr30957-1.c still XFAILs on x86_64-unknown-linux-gnu


-- 

ghazi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2009-11-22 18:01:42         |2010-03-30 17:16:58
               date|                            |


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

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957

--- Comment #23 from vries at gcc dot gnu.org ---
I've made the test-case pr30957-1.c match the current compiler behaviour. The
test-case made sense for the time the committed code was working in the
compiler. It then regressed at some point, and was marked as xfail.

Xfailing means that the *only* information you can get out of this test-case is
that foo returns -0.0 again.

We're better off testing the expected compiler behaviour, which might also
regress for all sorts of reasons unrelated to this PR.

As a bonus, we stop generating core files for this test, which give us no
information, and stop overwriting other core files that may actually have
relevance and could be for failures that are difficult to reproduce.

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |WAITING
                 CC|                            |vries at gcc dot gnu.org
         Resolution|FIXED                       |---

--- Comment #22 from vries at gcc dot gnu.org ---
(In reply to mrs@gcc.gnu.org from comment #21)
> So, is there anything left as a bug in the compiler, or has this issue been
> fixed?

The compiler behaves in accordance with the semantics of the switches passed.
In that sense, there's no bug.

The code committed for this PR (using -0.0 instead of +0.0) in
insert_var_expansion_initialization currently looks like this:
...
          if (honor_signed_zero_p)
            zero_init = simplify_gen_unary (NEG, mode, CONST0_RTX (mode),
mode);
          else
            zero_init = CONST0_RTX (mode);
...

AFAIU, this has become dead code, because -fsigned-zeros cannot be true at the
same time as -fassociative-math.

The definition of -fno-signed-zeros is 'Allow optimizations for floating-point
arithmetic that ignore the signedness of zero'. So stricly speaking, if the
cost of -0.0 is the same as of +0.0, there's nothing that stops us from using
-0.0 here for -fno-signed-zeros (attempting to be a bit 'more' correct at zero
cost). My feeling is that this is not a good idea, but obviously others may
think otherwise. If we decide that we want to implement this, we should reopen
this bug. If we decide otherwise, we should mark this wontfix. Re-opening this
as waiting for appropriate maintainer(s) to make a decision on this.

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[mrs at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957

mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> changed:

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

--- Comment #21 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> ---
So, is there anything left as a bug in the compiler, or has this issue been
fixed?

[Bug rtl-optimization/30957] Misscompare with variable expansion optimization

[mrs at gcc dot gnu.org]

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

mrs@gcc.gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrs at gcc dot gnu.org

--- Comment #20 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2012-04-10 23:22:40 UTC ---
This testcase doesn't unroll for me without -funroll-all-loops.  Any downside
to using -funroll-all-loops over -funroll-loops?