[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE

2019-05-11 Thread tkoenig at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Thomas Koenig  ---
Fixed on trunk, closing.

[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE

2019-05-10 Thread tkoenig at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968

--- Comment #9 from Thomas Koenig  ---
Author: tkoenig
Date: Fri May 10 20:14:22 2019
New Revision: 271076

URL: https://gcc.gnu.org/viewcvs?rev=271076=gcc=rev
Log:
2019-05-10  Thomas Koenig  

PR fortran/61968
* interface.c (compare_actual_formal): Do not create a vtab if
the actual argument is assumed type.

2019-05-10  Thomas Koenig  

PR fortran/61968
* gfortran.dg/assumed_type_10.f90: New test case.
* gfortran.dg/assumed_type_11.f90: New test case.


Added:
trunk/gcc/testsuite/gfortran.dg/assumed_type_10.f90
trunk/gcc/testsuite/gfortran.dg/assumed_type_11.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE

2019-05-01 Thread tkoenig at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968

Thomas Koenig  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #8 from Thomas Koenig  ---
Index: interface.c
===
--- interface.c (Revision 270622)
+++ interface.c (Arbeitskopie)
@@ -2989,7 +2989,8 @@
 polymorphic formal arguments.  */
   if (UNLIMITED_POLY (f->sym)
  && a->expr->ts.type != BT_DERIVED
- && a->expr->ts.type != BT_CLASS)
+ && a->expr->ts.type != BT_CLASS
+ && a->expr->ts.type != BT_ASSUMED)
gfc_find_vtab (>expr->ts);

   if (a->expr->expr_type == EXPR_NULL

seems to do the trick.

[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE

2019-05-01 Thread tkoenig at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968

--- Comment #7 from Thomas Koenig  ---
Hmm... some analysis.  This is a strange piece of code...

  interface
subroutine test_lib (a, len) bind(C, name="test")
  use iso_c_binding, only: c_size_t
  !GCC$ ATTRIBUTES NO_ARG_CHECK :: a
  type(*), dimension(*) :: a

OK, so type(*) in a C binding just means a void * pointer on
the C side.  But that does not matter: If the BIND(C) is removed,
the assembly failure still happens.

The failure does _not_ happen with

  interface test
procedure :: test_32
!procedure :: test_array
  end interface test

And if we replace the call to the generic "test" with
a call to the non-generic test_32, all is well.

With the following diff

--- pr1.f90 2019-05-01 22:05:46.317369154 +0200
+++ pr2.f90 2019-05-01 22:05:42.829339353 +0200
@@ -36,5 +36,5 @@
 use testmod
 type(*), dimension(*) :: a
 integer(c_int32_t), value :: len
-call test (a, len)
+call test_32 (a, len)
   end subroutine

between two files (pr1 calls the generic function, pr2 the
non-generic one) we get the following diff in the dumps:

--- pr1.dump2019-05-01 22:06:07.257548088 +0200
+++ pr2.dump2019-05-01 22:06:14.577610648 +0200
@@ -137,24 +137,10 @@
   symtree: '__iso_c_binding'|| symbol: '__iso_c_binding' 
 type spec : (UNKNOWN 0)
 attributes: (MODULE  INTRINSIC)
-  symtree: '__vtab_TYPE(*)_0_'|| symbol: '__vtab_TYPE(*)_0_' 
-type spec : (DERIVED __vtype_TYPE(*)_0_)
-attributes: (VARIABLE PUBLIC IMPLICIT-SAVE TARGET)
-value: __vtype_TYPE(*)_0_(49723565 , 8_8 , NULL() , NULL() ,
__copy_TYPE(*)_0_:__copy_TYPE(*)_0_ , NULL())
   symtree: '__vtab__STAR'|| symbol: '__vtab__STAR' 
 type spec : (DERIVED __vtype__STAR)
 attributes: (VARIABLE IMPLICIT-SAVE TARGET USE-ASSOC(testmod))
 value: __vtype__STAR(0 , () , () , () , () , NULL() , ())
-  symtree: '__vtype_TYPE(*)_0_'|| symbol: '__vtype_TYPE(*)_0_' 
-type spec : (UNKNOWN 0)
-attributes: (DERIVED PUBLIC )
-components: 
-(_hash (INTEGER 4) () PRIVATE) 
-(_size (INTEGER 8) () PRIVATE) 
-(_extends (VOID 0) POINTER () PRIVATE) 
-(_def_init (VOID 0) POINTER () PRIVATE) 
-(_copy (UNKNOWN 0) PPC () PRIVATE) 
-(_final (UNKNOWN 0) PPC () PRIVATE)
   symtree: '__vtype__STAR'|| symbol: '__vtype__STAR' 
 type spec : (UNKNOWN 0)
 attributes: (DERIVED  USE-ASSOC(testmod))
@@ -212,23 +198,5 @@
   code:
   CALL test_32 ((test_32_:a(FULL)) (test_32_:len))

-CONTAINS
-
-  Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
-  procedure name = __copy_TYPE(*)_0_
-symtree: '__copy_TYPE(*)_0_'|| symbol: '__copy_TYPE(*)_0_' 
-  type spec : (UNKNOWN 0)
-  attributes: (PROCEDURE  SUBROUTINE ELEMENTAL PURE)
-  Formal arglist: src dst
-symtree: 'dst' || symbol: 'dst'  
-  type spec : (TYPE(*))
-  attributes: (VARIABLE  DUMMY(INOUT))
-symtree: 'src' || symbol: 'src'  
-  type spec : (TYPE(*))
-  attributes: (VARIABLE  DUMMY(IN))
-
-code:
-ASSIGN __copy_TYPE(*)_0_:dst __copy_TYPE(*)_0_:src
-

so there is indeed a bogus vtab being generated somewhere and
somehow.

[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE

2019-05-01 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968

--- Comment #6 from Dominique d'Humieres  ---
On darwin I don't see the "Assembler messages".

[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE

2019-05-01 Thread tkoenig at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968

--- Comment #5 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #4)
> With gcc-9, gcc-8 and trunk I get

To be more precise, with a current gcc-9 snapshot:

$ gfortran -c pr61968.f90 
/tmp/ccqFh8vs.s: Assembler messages:
/tmp/ccqFh8vs.s:121: Error: unrecognized symbol type ""
/tmp/ccqFh8vs.s:121: Error: junk at end of line, first unrecognized character
is `('
/tmp/ccqFh8vs.s:122: Error: invalid character '(' in mnemonic
/tmp/ccqFh8vs.s:142: Error: expected comma after name `__copy_TYPE' in .size
directive
/tmp/ccqFh8vs.s:171: Error: unrecognized symbol type ""
/tmp/ccqFh8vs.s:171: Error: junk at end of line, first unrecognized character
is `('
/tmp/ccqFh8vs.s:172: Error: expected comma after name `__vtab_TYPE' in .size
directive
/tmp/ccqFh8vs.s:173: Error: invalid character '(' in mnemonic
/tmp/ccqFh8vs.s:179: Error: junk at end of line, first unrecognized character
is `('
$ gfortran -c -O pr61968.f90 
$

[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE

2019-05-01 Thread tkoenig at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968

Thomas Koenig  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||tkoenig at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #4 from Thomas Koenig  ---
With gcc-9, gcc-8 and trunk I get

/tmp/ccyyPrsg.s: Assembler messages:
/tmp/ccyyPrsg.s:121: Error: unrecognized symbol type ""
/tmp/ccyyPrsg.s:121: Error: junk at end of line, first unrecognized character
is `('
/tmp/ccyyPrsg.s:122: Error: invalid character '(' in mnemonic
/tmp/ccyyPrsg.s:142: Error: expected comma after name `__copy_TYPE' in .size
directive
/tmp/ccyyPrsg.s:171: Error: unrecognized symbol type ""
/tmp/ccyyPrsg.s:171: Error: junk at end of line, first unrecognized character
is `('
/tmp/ccyyPrsg.s:172: Error: expected comma after name `__vtab_TYPE' in .size
directive
/tmp/ccyyPrsg.s:173: Error: invalid character '(' in mnemonic
/tmp/ccyyPrsg.s:179: Error: junk at end of line, first unrecognized character
is `('

[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE

2017-08-03 Thread egallager at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #2)
> Is the problem fixed? Without feedback I'll assume yes.

No feedback so we can assume yes.

[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE

2015-10-10 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968

--- Comment #2 from Dominique d'Humieres  ---
Is the problem fixed? Without feedback I'll assume yes.

[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE

2014-08-16 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-08-16
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr ---
I don't get an ICE on x86_64-apple-darwin13 at r213892, but

Undefined symbols for architecture x86_64:
  _test, referenced from:
  ___testmod_MOD_test_array in ccZ9AqLx.o
  ___testmod_MOD_test_32 in ccZ9AqLx.o
  _test_32__ in ccZ9AqLx.o
 (maybe you meant: _test_32__, ___testmod_MOD_test_32 ,
___testmod_MOD___vtab__STAR , ___testmod_MOD_test_array )
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

Compiling the code with 4.9.1 gives

pr61968.f90:31.35:

call test_lib (a, int (sizeof (a), kind=c_size_t))
   1
Error: Assumed-rank argument at (1) is only permitted as actual argument to
intrinsic inquiry functions