[Bug tree-optimization/65551] New: [5 Regression] FAIL: 26_numerics/complex/50880.cc execution test

[Bug tree-optimization/65551] New: [5 Regression] FAIL: 26_numerics/complex/50880.cc execution test

[jgreenhalgh at gcc dot gnu.org]

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

            Bug ID: 65551
           Summary: [5 Regression]  FAIL: 26_numerics/complex/50880.cc
                    execution test
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: thopre01 at gcc dot gnu.org
          Reporter: jgreenhalgh at gcc dot gnu.org
              Host: arm-none-linux-gnueabihf
            Target: arm-none-linux-gnueabihf

As of r220390 we've started to FAIL this test from libstdc++ on
arm-none-linux-gnueabihf:

FAIL: 26_numerics/complex/50880.cc execution test
./50880.exe
50880.exe:
/work/jamgre01/gcc-src/libstdc++-v3/testsuite/26_numerics/complex/50880.cc:36:
void test01_do() [with T = double]: Assertion `cra.real() > T(0)' failed.
Aborted

Bisect pinpointed the failure to this commit:

Author: thopre01 <thopre01@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Wed Feb 4 08:22:45 2015 +0000

    2015-02-04  Thomas Preud'homme  <thomas.preudhomme@arm.com>

        gcc/
        PR middle-end/62103
        * tree-ssa-sccvn.c (fully_constant_vn_reference_p): Use TYPE_PRECISION
        to compute size of referenced value in the constant case.

        gcc/testsuite/
        PR middle-end/62103
        * gcc.c-torture/execute/bitfld-7.c: New test adapted from bitfld-6.c
        to use 24 bits for bitfield b.

Compiler configured with: /work/jamgre01//gcc-src/configure
--with-cpu=cortex-a9 --with-fpu=neon-fp16 --with-mode=thumb --with-float=hard
--enable-languages=c,c++,fortran --prefix=/work/jamgre01//gcc-install
--with-build-config=bootstrap-time

[Bug tree-optimization/65551] [5 Regression] FAIL: 26_numerics/complex/50880.cc execution test

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-03-25
                 CC|                            |vries at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from vries at gcc dot gnu.org ---
I see the same failure on arm-linux-gnueabihf.

[Bug tree-optimization/65551] [5 Regression] FAIL: 26_numerics/complex/50880.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And powerpc64le-unknown-linux-gnu

[Bug tree-optimization/65551] [5 Regression] FAIL: 26_numerics/complex/50880.cc execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
   Target Milestone|---                         |5.0

[Bug tree-optimization/65551] [5 Regression] FAIL: 26_numerics/complex/50880.cc execution test

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That tree-ssa-sccvn.c change is just bogus.
TYPE_PRECISION meaning is dependent on what the type is.
For INTEGRAL_TYPE_P it supposedly does what you want, haven't checked the
details.  Not so sure already about scalar floating point types, why should the
precision be relevant?  But, e.g. for the complex types, TYPE_PRECISION is just
0, for vector types it is log2 of TYPE_VECT_SUBPARTS, etc.
So if TYPE_PRECISION is really what you want for INTEGRAL_TYPE_P, supposedly
--- gcc/tree-ssa-sccvn.c    2015-02-10 22:58:23.572010447 +0100
+++ gcc/tree-ssa-sccvn.c    2015-03-26 13:58:41.145949566 +0100
@@ -1352,7 +1352,11 @@ fully_constant_vn_reference_p (vn_refere
            || TYPE_PRECISION (ref->type) % BITS_PER_UNIT == 0))
     {
       HOST_WIDE_INT off = 0;
-      HOST_WIDE_INT size = TYPE_PRECISION (ref->type);
+      HOST_WIDE_INT size;
+      if (INTEGRAL_TYPE_P (ref->type))
+    size = TYPE_PRECISION (ref->type);
+      else
+    size = tree_to_shwi (TYPE_SIZE (ref->type));
       if (size % BITS_PER_UNIT != 0
       || size > MAX_BITSIZE_MODE_ANY_MODE)
     return NULL_TREE;

?

[Bug tree-optimization/65551] [5 Regression] FAIL: 26_numerics/complex/50880.cc execution test

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Bootstrapping/regtesting this now on powerpc64le-linux.

[Bug tree-optimization/65551] [5 Regression] FAIL: 26_numerics/complex/50880.cc execution test

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Thu Mar 26 19:17:44 2015
New Revision: 221702

URL: https://gcc.gnu.org/viewcvs?rev=221702&root=gcc&view=rev
Log:
    PR tree-optimization/65551
    * tree-ssa-sccvn.c (fully_constant_vn_reference_p): Use
    TYPE_PRECISION only for INTEGRAL_TYPE_P types.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/65551] [5 Regression] FAIL: 26_numerics/complex/50880.cc execution test

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.