[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

2018-04-04 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976

--- Comment #11 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #10)
> I think I have finally found the culprit.  Took me a couple of hours...
> 
> The type in question is introduced in gimple-match-head.c, in

... or not there, rather somewhere in gimple-fold.c.

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

2018-04-04 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976

--- Comment #10 from Thomas Koenig  ---
I think I have finally found the culprit.  Took me a couple of hours...

The type in question is introduced in gimple-match-head.c, in

763 return (gimple_resimplify2 (seq, rcode,
764 boolean_type_node, ops, valueize)
765 || valueized);

This is probably where the wrong type is being generated.

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

2018-02-20 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976

--- Comment #9 from Thomas Koenig  ---
FWITW, here's a shorter test case:

PROGRAM main

TYPE :: test_typ
REAL, ALLOCATABLE :: a(:)
END TYPE

TYPE(test_typ) :: yy
TYPE(test_typ), ALLOCATABLE :: conc(:)

conc = [ yy ]

END PROGRAM main

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

2017-11-16 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

2017-11-15 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976

--- Comment #8 from Thomas Koenig  ---
What I meant was this part of resolve_mask_arg :

  /* In the library, we access the mask with a GFC_LOGICAL_1
 argument.  No need to waste memory if we are about to create
 a temporary array.  */
  if (mask->expr_type == EXPR_OP && mask->ts.kind != 1)
{
  ts.type = BT_LOGICAL;
  ts.kind = 1;
  gfc_convert_type_warn (mask, , 2, 0);

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

2017-11-15 Thread jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976

--- Comment #7 from Janne Blomqvist  ---
(In reply to Thomas Koenig from comment #6)
> I cannot check at the moment, but I remember changing
> the KIND of mask arguments generated by the compiler to kind=1,
> to save memory. This is quite a few years ago, the PR
> to go with it escapes me at the moment.
> 
> Dunno if this helps.

I've seen code doing this, but only for the forall and where statements, which
aren't present in this testcase. Neither are masks in any other statement. Or
am I missing something?

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

2017-11-15 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #6 from Thomas Koenig  ---
I cannot check at the moment, but I remember changing
the KIND of mask arguments generated by the compiler to kind=1,
to save memory. This is quite a few years ago, the PR
to go with it escapes me at the moment.

Dunno if this helps.

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

2017-11-15 Thread jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976

--- Comment #5 from Janne Blomqvist  ---
So the problem is the logical(kind=1) one, it should be the same type as the
LHS.

It seems it originates from (from .003t.original):

logical(kind=4) D.3603;
...
D.3603 = (struct test_typ[0:] * restrict) conc.data == 0B;

Then in the .177t.thread3 dump this has become:

_15 = _34 == _6;

Then finally in the 178t.dom3 dump with -fdump-tree-all-details (this is the
pass where it ICE's):

Optimizing statement _15 = _34 == _6;
  Replaced '_34' with variable '_13'
  Replaced '_6' with constant ''
gimple_simplified to _15 = 0;
  Folded to: _15 = 0;
LKUP STMT _15 = 0
 ASGN _15 = 0


I have gone through uses of EQ_EXPR (and NE_EXPR, and boolean_type_node, and
boolean_true_node, and boolean_false_node) in the frontend and I haven't found
a place where it would use boolean_type_node (i.e. logical(kind=1) instead of
logical_type_node (logical(kind=4)). So at the moment I'm a bit stuck. Does the
above give you any kind of hint what the problem might be?

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

2017-11-14 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976

--- Comment #4 from Martin Liška  ---
So for following GIMPLE stmt:

$ (gdb) p debug_gimple_stmt(stmt)
_54 = 0;

RHS (kind == 1) is created here:

(gdb) bt
#0  make_int_cst (len=1, ext_len=1) at ../../gcc/tree.c:2286
#1  0x0139516a in build_new_int_cst (type=0x76827b28, cst=...) at
../../gcc/tree.c:1280
#2  0x01395ef3 in wide_int_to_tree (type=0x76827b28, pcst=...) at
../../gcc/tree.c:1529
#3  0x01010b84 in set_min_and_max_values_for_integral_type
(type=0x76827b28, precision=8, sgn=UNSIGNED) at
../../gcc/stor-layout.c:2680
#4  0x01010cfa in fixup_unsigned_type (type=0x76827b28) at
../../gcc/stor-layout.c:2711
#5  0x01010016 in make_unsigned_type (precision=8) at
../../gcc/stor-layout.c:2538
#6  0x013b4983 in build_common_tree_nodes (signed_char=false) at
../../gcc/tree.c:9562
#7  0x0091167e in gfc_init_decl_processing () at
../../gcc/fortran/f95-lang.c:506
#8  0x00910f2a in gfc_init () at ../../gcc/fortran/f95-lang.c:242
#9  0x01020600 in lang_dependent_init (name=0x7fffe202
"/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/realloc_on_assign_16.f90")
at ../../gcc/toplev.c:1819
#10 0x01020b37 in do_compile () at ../../gcc/toplev.c:2045
#11 0x01020e84 in toplev::main (this=0x7fffdc6e, argc=16,
argv=0x7fffdd68) at ../../gcc/toplev.c:2194
#12 0x01c3e1d2 in main (argc=16, argv=0x7fffdd68) at
../../gcc/main.c:39

LHS here:

(gdb) bt
#0  make_ssa_name_fn (fn=0x769c10b0, var=0x76833348,
stmt=0x7662aa00, version=0) at ../../gcc/tree-ssanames.c:313
#1  0x012ee868 in copy_ssa_name_fn (fn=0x769c10b0,
name=0x7661a750, stmt=0x7662aa00) at ../../gcc/tree-ssanames.c:691
#2  0x012eeccf in duplicate_ssa_name_fn (fn=0x769c10b0,
name=0x7661a750, stmt=0x7662aa00) at ../../gcc/tree-ssanames.c:752
#3  0x010dc1a0 in duplicate_ssa_name (var=0x7661a750,
stmt=0x7662aa00) at ../../gcc/tree-ssanames.h:134
#4  0x010e3605 in create_new_def_for (old_name=0x7661a750,
stmt=0x7662aa00, def=0x7662aa40) at ../../gcc/tree-into-ssa.c:2949
#5  0x01079665 in gimple_duplicate_bb (bb=0x7661bea0) at
../../gcc/tree-cfg.c:6186
#6  0x00a76d6c in duplicate_block (bb=0x7661bea0, e=0x0, after=0x0)
at ../../gcc/cfghooks.c:1077
#7  0x012cc659 in create_block_for_threading (bb=0x7661bea0,
rd=0x2a8c950, count=0, duplicate_blocks=0x7fffd6e0) at
../../gcc/tree-ssa-threadupdate.c:336
#8  0x012cde44 in ssa_create_duplicates (slot=0x2c3be30,
local_info=0x7fffd6d0) at ../../gcc/tree-ssa-threadupdate.c:1124
#9  0x012d182d in hash_table::traverse_noresize
(this=0x2c3bdf0, argument=0x7fffd6d0) at ../../gcc/hash-table.h:969
#10 0x012d0d0f in hash_table::traverse
(this=0x2c3bdf0, argument=0x7fffd6d0) at ../../gcc/hash-table.h:990
#11 0x012ce4e0 in thread_block_1 (bb=0x7661bea0, noloop_only=true,
joiners=false) at ../../gcc/tree-ssa-threadupdate.c:1387
#12 0x012ce5b6 in thread_block (bb=0x7661bea0, noloop_only=true) at
../../gcc/tree-ssa-threadupdate.c:1431
#13 0x012d03a4 in thread_through_all_blocks
(may_peel_loop_headers=false) at ../../gcc/tree-ssa-threadupdate.c:2298
#14 0x011afcb9 in (anonymous namespace)::pass_dominator::execute
(this=0x2aa0470, fun=0x769c10b0) at ../../gcc/tree-ssa-dom.c:749
#15 0x00ef7b1f in execute_one_pass (pass=0x2aa0470) at
../../gcc/passes.c:2497
#16 0x00ef7e70 in execute_pass_list_1 (pass=0x2aa0470) at
../../gcc/passes.c:2586
#17 0x00ef7ea1 in execute_pass_list_1 (pass=0x2a9e270) at
../../gcc/passes.c:2587
#18 0x00ef7ef9 in execute_pass_list (fn=0x769c10b0, pass=0x2a9e090)
at ../../gcc/passes.c:2597
#19 0x00ab8076 in cgraph_node::expand (this=0x769d3170) at
../../gcc/cgraphunit.c:2139
#20 0x00ab86b2 in expand_all_functions () at
../../gcc/cgraphunit.c:2275
#21 0x00ab9206 in symbol_table::compile (this=0x76817100) at
../../gcc/cgraphunit.c:2623
#22 0x00ab947b in symbol_table::finalize_compilation_unit
(this=0x76817100) at ../../gcc/cgraphunit.c:2716
#23 0x0101e4c8 in compile_file () at ../../gcc/toplev.c:480
#24 0x01020b97 in do_compile () at ../../gcc/toplev.c:2059
#25 0x01020e84 in toplev::main (this=0x7fffdc6e, argc=16,
argv=0x7fffdd68) at ../../gcc/toplev.c:2194
#26 0x01c3e1d2 in main (argc=16, argv=0x7fffdd68) at
../../gcc/main.c:39

Is it helpful information, or should I investigate more?
Which is the problematic type?

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

2017-11-14 Thread jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976

--- Comment #3 from Janne Blomqvist  ---
Yes, the logical(kind=4) definitely comes from the frontend. If you compile
with -fdefault-integer-8 it changes to a logical(kind=8).

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

2017-11-14 Thread jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976

--- Comment #2 from Janne Blomqvist  ---
Hmm. I do think r254526 does the right thing (TM). Looking at
-ftree-dump-original the frontend doesn't generaty any logical(kind=1)
temporary variables. So presumably some optimization pass creates such a thing
and then it fails to make sure that type matches some logical(kind=4) variable
defines elsewhere (by the frontend, maybe).

I also checked with -fdump-tree-all, none of

gfortran -O3 realloc_on_assign_16.f90 -fdump-tree-all

gfortran -O3 -fno-tree-forwprop realloc_on_assign_16.f90 -fdump-tree-all

gfortran -O2 -fno-tree-forwprop realloc_on_assign_16.f90 -fdump-tree-all

had any logical(kind=1) variables in any of the tree dumps. It might be that
due to the ICE with "-O3 -fno-tree-forwprop" the culprit tree dump is never
generated.

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

2017-11-14 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-14
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed. The test compiles with '-O2 -fno-tree-forwprop' but not with'-O3
-fno-tree-forwprop'.

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

2017-11-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976

Richard Biener  changed:

   What|Removed |Added

Version|7.0 |8.0
   Target Milestone|--- |8.0