[Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL

[Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.10.0

[Bug middle-end/61950] New: [4.10 regression] Many 64-bit fortran allocate tests FAIL

[ro at gcc dot gnu.org]

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

            Bug ID: 61950
           Summary: [4.10 regression] Many 64-bit fortran allocate tests
                    FAIL
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: ebotcazou at gcc dot gnu.org, rguenth at gcc dot gnu.org
              Host: sparc-sun-solaris2.1[01]
            Target: sparc-sun-solaris2.1[01]
             Build: sparc-sun-solaris2.1[01]

Between 20140718 (r212815) and 20140725 (r213049) many 64-bit gfortran tests
started to FAIL on Solaris/SPARC, at -O1 and beyond only:

FAIL: gfortran.dg/allocate_class_3.f90   -O1  execution test
FAIL: gfortran.dg/allocate_class_3.f90   -O2  execution test
FAIL: gfortran.dg/allocate_class_3.f90   -O3 -fomit-frame-pointer  execution
test
FAIL: gfortran.dg/allocate_class_3.f90   -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/allocate_class_3.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/allocate_class_3.f90   -O3 -g  execution test
FAIL: gfortran.dg/allocate_class_3.f90   -Os  execution test
FAIL: gfortran.dg/class_19.f03   -O1  execution test
FAIL: gfortran.dg/class_19.f03   -O2  execution test
FAIL: gfortran.dg/class_19.f03   -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/class_19.f03   -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/class_19.f03   -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/class_19.f03   -O3 -g  execution test
FAIL: gfortran.dg/class_19.f03   -Os  execution test

and many more.

A reghunt revealed the following patch as the culprit:

2014-07-25  Richard Biener  <rguenther@suse.de>

    PR middle-end/61762
    PR middle-end/61894
    * fold-const.c (native_encode_int): Add and handle offset
    parameter to do partial encodings of expr.

The first test e.g aborts here:

#4  0x000000010000213c in MAIN__ ()
    at /var/gcc/reghunt/trunk/gcc/testsuite/gfortran.dg/allocate_class_3.f90:76
76            if (any (x%i .ne. [1,2])) call abort

  Rainer

[Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-07-30
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, sparc is big-endian.  I suppose my added big-endian testcases pass.
I'll see if a cross f951 to sparc-sun-solaris2.11 reveals anything.

[Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
The gimple for the cited line looks good to me:

  addarray1 (&class.25, &class.26);
  class.26 ={v} {CLOBBER};
  class.25 ={v} {CLOBBER};
  class.30._data = pt_43->p._data;
  SR.179_160 = MEM[(struct object_array_pointer *)pt_43];
  SR.181_102 = MEM[(struct object_array_pointer *)pt_43 + 12B];
  SR.182_94 = MEM[(struct object_array_pointer *)pt_43 + 16B];
  _53 = pt_43->p._vptr;
  _57 = SR.182_94 * SR.181_102;
  _58 = -_57;
  _60 = _53->_hash;
  switch (_60) <default: <L20>, case 37104555: <L111>>

<L111>:
  _243 = MEM[(struct t[0:] *)SR.179_160][0].i;
  if (_243 != 1)
    goto <bb 36>;
  else
    goto <bb 8>;

  <bb 8>:
  _62 = SR.182_94 + 1;
  _63 = _62 * SR.181_102;
  _64 = _63 - _57;
  _65 = MEM[(struct t[0:] *)SR.179_160][_64].i;
  if (_65 != 2)
    goto <bb 36>;
  else
    goto <bb 9> (<L20>);

we have constant-folded from the initializer of A.28 = [1, 2].

For the testcase (at -O1) we never call native_encode_expr with off != -1
so the only difference can be that we call native_encode_expr more
often or that the code-path for off == -1 changed (which it wasn't supposed
to).

Btw all calls to native_encode_expr are via fold_view_convert_expr ultimately
called from the frontend and all return NULL and thus fail.

So I wonder whether it rather is libgfortran that is miscompiled?  Can you
check running the testcases against an older version?

[Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
[...]
> So I wonder whether it rather is libgfortran that is miscompiled?  Can you
> check running the testcases against an older version?

After I initially saw the failures during a regular bootstrap, I tried
with the libgfortran.so.3 bundled with Solaris 11 (from gcc 4.5 or gcc
4.8), and the testcase fails just the same.

    Rainer

[Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Pat Haugen from comment #4)
> Seeing the same on powerpc64-unknown-linux-gnu (big-endian).

Ok, that HW I have availabe.  Digging.

[Bug fortran/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
          Component|middle-end                  |fortran

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
So we have (reduced from class_19.f03)

  <bb 6>:
  __builtin_memcpy (_10, &__def_init_foo_mod_Foo_outer, 0);
  _22 = MEM[(struct foo_outer *)_10].int._data;
  if (_22 != 0B)
    goto <bb 7>;
  else
    goto <bb 8>;

  <bb 7>:
  _gfortran_abort ();

from

      (struct __vtype_foo_mod_Foo_outer *) try3._vptr =
&__vtab_foo_mod_Foo_outer;
      (void) __builtin_memcpy ((void *) try3._data, (void *)
try3._vptr->_def_init, (unsigned long) try3._vptr->_size);
      if (try3._data->int._data != 0B)
        {
          _gfortran_abort ();
        }

see how the size argument to memcpy is zero!  FRE does that:

Value numbering _17 stmt = _17 = try3._vptr;
Setting value number of _17 to &__vtab_foo_mod_Foo_outer (changed)
Value numbering _18 stmt = _18 = _17->_size;
RHS _17->_size simplified to 0 has constants 1

fold_ctor_reference (type=0xfffb5930738, ctor=0xfffb5908e20, offset=32, size=
    32, from_decl=0xfffb5ab9fb0) at ../../trunk/gcc/gimple-fold.c:3059
3059      if (useless_type_conversion_p (type, TREE_TYPE (ctor))
(gdb) p debug_generic_expr (ctor)
{._hash=13054828, ._size=16, ._extends=0B,
._def_init=&__def_init_foo_mod_Foo_outer, ._copy=__copy_foo_mod_Foo_outer,
._final=__final_foo_mod_Foo_outer}
$241 = void

where we recurse through fold_nonarray_ctor_reference to

fold_ctor_reference (type=0xfffb5930738, ctor=0xfffb5900eb8, offset=0, size=
    32, from_decl=0xfffb5ab9fb0) at ../../trunk/gcc/gimple-fold.c:3059
3059      if (useless_type_conversion_p (type, TREE_TYPE (ctor))
(gdb) p debug_generic_expr (ctor)
16

but despite _size being 32bit in size:

    idx <field_decl 0xfffb59d89c0 _size
        type <integer_type 0xfffb5930738 integer(kind=4) public SI size
<integer_cst 0xfffb5901098 32> unit size <integer_cst 0xfffb59010b0 4>

the actual value in the initializer is of sizetype:

(gdb) p debug_tree (ctor)
 <integer_cst 0xfffb5900eb8 type <integer_type 0xfffb5930150 sizetype> constant
16>

so there is a mismatch created by the frontend here.

Frontend bug fixed by

Index: fortran/trans-expr.c
===================================================================
--- fortran/trans-expr.c        (revision 213342)
+++ fortran/trans-expr.c        (working copy)
@@ -6260,7 +6260,9 @@ gfc_conv_structure (gfc_se * se, gfc_exp
       else if (cm->ts.u.derived && strcmp (cm->name, "_size") == 0)
        {
          val = TYPE_SIZE_UNIT (gfc_get_derived_type (cm->ts.u.derived));
-         CONSTRUCTOR_APPEND_ELT (v, cm->backend_decl, val);
+         CONSTRUCTOR_APPEND_ELT (v, cm->backend_decl,
+                                 fold_convert (TREE_TYPE (cm->backend_decl),
+                                               val));
        }
       else
        {

[Bug fortran/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
With the patch, the previously failing gfortran.dg/allocate_class_3.f90
testcase works fine on 64-bit SPARC.

Thanks.
        Rainer

[Bug fortran/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.

[Bug fortran/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Mon Aug 11 07:49:30 2014
New Revision: 213809

URL: https://gcc.gnu.org/viewcvs?rev=213809&root=gcc&view=rev
Log:
2014-08-11  Richard Biener  <rguenther@suse.de>

        PR fortran/61950
    * trans-expr.c (gfc_conv_structure): Initialize _size with
    a value of proper type.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-expr.c