* [Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL
2014-07-29 15:13 [Bug middle-end/61950] New: [4.10 regression] Many 64-bit fortran allocate tests FAIL ro at gcc dot gnu.org
@ 2014-07-29 15:13 ` ro at gcc dot gnu.org
2014-07-30 9:59 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: ro at gcc dot gnu.org @ 2014-07-29 15:13 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL
2014-07-29 15:13 [Bug middle-end/61950] New: [4.10 regression] Many 64-bit fortran allocate tests FAIL ro at gcc dot gnu.org
2014-07-29 15:13 ` [Bug middle-end/61950] " ro at gcc dot gnu.org
@ 2014-07-30 9:59 ` rguenth at gcc dot gnu.org
2014-07-30 10:19 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-07-30 9:59 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL
2014-07-29 15:13 [Bug middle-end/61950] New: [4.10 regression] Many 64-bit fortran allocate tests FAIL ro at gcc dot gnu.org
2014-07-29 15:13 ` [Bug middle-end/61950] " ro at gcc dot gnu.org
2014-07-30 9:59 ` rguenth at gcc dot gnu.org
@ 2014-07-30 10:19 ` rguenth at gcc dot gnu.org
2014-07-30 12:20 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-07-30 10:19 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL
2014-07-29 15:13 [Bug middle-end/61950] New: [4.10 regression] Many 64-bit fortran allocate tests FAIL ro at gcc dot gnu.org
` (2 preceding siblings ...)
2014-07-30 10:19 ` rguenth at gcc dot gnu.org
@ 2014-07-30 12:20 ` ro at CeBiTec dot Uni-Bielefeld.DE
2014-07-31 10:40 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2014-07-30 12:20 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL
2014-07-29 15:13 [Bug middle-end/61950] New: [4.10 regression] Many 64-bit fortran allocate tests FAIL ro at gcc dot gnu.org
` (3 preceding siblings ...)
2014-07-30 12:20 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2014-07-31 10:40 ` rguenth at gcc dot gnu.org
2014-07-31 11:50 ` [Bug fortran/61950] " rguenth at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-07-31 10:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug fortran/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL
2014-07-29 15:13 [Bug middle-end/61950] New: [4.10 regression] Many 64-bit fortran allocate tests FAIL ro at gcc dot gnu.org
` (4 preceding siblings ...)
2014-07-31 10:40 ` rguenth at gcc dot gnu.org
@ 2014-07-31 11:50 ` rguenth at gcc dot gnu.org
2014-07-31 14:03 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-07-31 11:50 UTC (permalink / raw)
To: gcc-bugs
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
{
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug fortran/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL
2014-07-29 15:13 [Bug middle-end/61950] New: [4.10 regression] Many 64-bit fortran allocate tests FAIL ro at gcc dot gnu.org
` (5 preceding siblings ...)
2014-07-31 11:50 ` [Bug fortran/61950] " rguenth at gcc dot gnu.org
@ 2014-07-31 14:03 ` ro at CeBiTec dot Uni-Bielefeld.DE
2014-08-11 7:49 ` rguenth at gcc dot gnu.org
2014-08-11 7:50 ` rguenth at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2014-07-31 14:03 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug fortran/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL
2014-07-29 15:13 [Bug middle-end/61950] New: [4.10 regression] Many 64-bit fortran allocate tests FAIL ro at gcc dot gnu.org
` (6 preceding siblings ...)
2014-07-31 14:03 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2014-08-11 7:49 ` rguenth at gcc dot gnu.org
2014-08-11 7:50 ` rguenth at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-11 7:49 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug fortran/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL
2014-07-29 15:13 [Bug middle-end/61950] New: [4.10 regression] Many 64-bit fortran allocate tests FAIL ro at gcc dot gnu.org
` (7 preceding siblings ...)
2014-08-11 7:49 ` rguenth at gcc dot gnu.org
@ 2014-08-11 7:50 ` rguenth at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-11 7:50 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread