* [Bug fortran/37829] ICE in resolve_symbol
2008-10-14 20:09 [Bug fortran/37829] New: ICE in resolve_symbol jakub at gcc dot gnu dot org
@ 2008-11-28 21:25 ` dfranke at gcc dot gnu dot org
2008-12-08 21:07 ` mikael at gcc dot gnu dot org
` (13 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: dfranke at gcc dot gnu dot org @ 2008-11-28 21:25 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from dfranke at gcc dot gnu dot org 2008-11-28 21:23 -------
Confirmed.
$> gfortran-svn
gcc version 4.4.0 20081128 (experimental) (GCC)
(gdb) run pr37829.f90
Starting program:
/home/daniel/i686-pc-linux-gnu/gcc/libexec/gcc/i686-pc-linux-gnu/4.4.0/f951
pr37829.f90
Program received signal SIGSEGV, Segmentation fault.
resolve_symbol (sym=0x9f57f58) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:9229
9229 if (sym->ts.type == BT_DERIVED
(gdb) bt
#0 resolve_symbol (sym=0x9f57f58) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:9229
#1 0x080c737e in traverse_ns (st=0x9f57f38, func=0x80b9880 <resolve_symbol>)
at /home/daniel/svn/gcc-svn/gcc/fortran/symbol.c:3126
#2 0x080c736a in traverse_ns (st=0x9f585a0, func=0x80b9880 <resolve_symbol>)
at /home/daniel/svn/gcc-svn/gcc/fortran/symbol.c:3123
#3 0x080c736a in traverse_ns (st=0x9f5cdc0, func=0x80b9880 <resolve_symbol>)
at /home/daniel/svn/gcc-svn/gcc/fortran/symbol.c:3123
#4 0x080b59b2 in resolve_types (ns=<value optimized out>) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:10346
#5 0x080b985c in gfc_resolve (ns=0x9f5c4b0) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:10427
#6 0x080a6fbf in gfc_parse_file () at
/home/daniel/svn/gcc-svn/gcc/fortran/parse.c:3844
#7 0x080d721d in gfc_be_parse_file (set_yydebug=0) at
/home/daniel/svn/gcc-svn/gcc/fortran/f95-lang.c:236
#8 0x08391e7c in toplev_main (argc=2, argv=0xbfcef534) at
/home/daniel/svn/gcc-svn/gcc/toplev.c:968
#9 0xb7e20005 in __libc_start_main () from /lib/libc.so.6
--
dfranke at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dfranke at gcc dot gnu dot
| |org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail| |4.3.2 4.4.0
Last reconfirmed|0000-00-00 00:00:00 |2008-11-28 21:23:44
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] ICE in resolve_symbol
2008-10-14 20:09 [Bug fortran/37829] New: ICE in resolve_symbol jakub at gcc dot gnu dot org
2008-11-28 21:25 ` [Bug fortran/37829] " dfranke at gcc dot gnu dot org
@ 2008-12-08 21:07 ` mikael at gcc dot gnu dot org
2008-12-09 8:43 ` dominiq at lps dot ens dot fr
` (12 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: mikael at gcc dot gnu dot org @ 2008-12-08 21:07 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]
------- Comment #2 from mikael at gcc dot gnu dot org 2008-12-08 21:06 -------
reduced:
module modx
use, intrinsic :: iso_c_binding
end module modx
block data
use modx
end
A simple way to fix it would be this:
Index: resolve.c
===================================================================
--- resolve.c (révision 142546)
+++ resolve.c (copie de travail)
@@ -9263,6 +9263,7 @@ resolve_symbol (gfc_symbol *sym)
module function and is not PRIVATE. */
if (sym->ts.type == BT_DERIVED
&& sym->ts.derived->attr.use_assoc
+ && sym->ns->proc_name
&& sym->ns->proc_name->attr.flavor == FL_MODULE)
{
gfc_symbol *ds;
Paul, I'm adding you as you may know better what to do here.
see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295#c7
--
mikael at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pault at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] ICE in resolve_symbol
2008-10-14 20:09 [Bug fortran/37829] New: ICE in resolve_symbol jakub at gcc dot gnu dot org
2008-11-28 21:25 ` [Bug fortran/37829] " dfranke at gcc dot gnu dot org
2008-12-08 21:07 ` mikael at gcc dot gnu dot org
@ 2008-12-09 8:43 ` dominiq at lps dot ens dot fr
2008-12-09 13:54 ` mikael at gcc dot gnu dot org
` (11 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: dominiq at lps dot ens dot fr @ 2008-12-09 8:43 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from dominiq at lps dot ens dot fr 2008-12-09 08:41 -------
The patch in comment #2 fixes the ICE without regression on i686-apple-darwin9.
Is not the "obvious rule" applying here?
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] ICE in resolve_symbol
2008-10-14 20:09 [Bug fortran/37829] New: ICE in resolve_symbol jakub at gcc dot gnu dot org
` (2 preceding siblings ...)
2008-12-09 8:43 ` dominiq at lps dot ens dot fr
@ 2008-12-09 13:54 ` mikael at gcc dot gnu dot org
2008-12-09 17:30 ` burnus at gcc dot gnu dot org
` (10 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: mikael at gcc dot gnu dot org @ 2008-12-09 13:54 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from mikael at gcc dot gnu dot org 2008-12-09 13:53 -------
(In reply to comment #3)
> The patch in comment #2 fixes the ICE without regression on i686-apple-darwin9.
I didn't expect any regression with that patch.
However, I wonder whether we are not missing something.
For example, I tried to adapt the testcase in PR 33295 to the c_funloc case.
The resulting program is rejected with the following error:
Error: Can't convert TYPE(_gfortran_iso_c_binding_c_funptr) to TYPE(c_funptr)
at (1)
The question is: Is it valid/Do we want to support this?
module a
use iso_c_binding, only:c_funptr
end module a
module b
use iso_c_binding, only:c_funloc!,c_funptr
end module b
module f
contains
subroutine g() bind(c)
end subroutine
end module f
program c
use b
use a
use f
implicit none
type (c_funptr) :: d
d = c_funloc (g)
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] ICE in resolve_symbol
2008-10-14 20:09 [Bug fortran/37829] New: ICE in resolve_symbol jakub at gcc dot gnu dot org
` (3 preceding siblings ...)
2008-12-09 13:54 ` mikael at gcc dot gnu dot org
@ 2008-12-09 17:30 ` burnus at gcc dot gnu dot org
2008-12-15 12:50 ` dominiq at lps dot ens dot fr
` (9 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: burnus at gcc dot gnu dot org @ 2008-12-09 17:30 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from burnus at gcc dot gnu dot org 2008-12-09 17:28 -------
(In reply to comment #4)
> For example, I tried to adapt the testcase in PR 33295 to the c_funloc case.
> The resulting program is rejected with the following error:
> Error: Can't convert TYPE(_gfortran_iso_c_binding_c_funptr) to TYPE(c_funptr)
> at (1)
> The question is: Is it valid/Do we want to support this?
I don't see why it should be invalid (though I have not spend too much time on
finding a reason). It also compiles just fine with ifort and g95.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] ICE in resolve_symbol
2008-10-14 20:09 [Bug fortran/37829] New: ICE in resolve_symbol jakub at gcc dot gnu dot org
` (4 preceding siblings ...)
2008-12-09 17:30 ` burnus at gcc dot gnu dot org
@ 2008-12-15 12:50 ` dominiq at lps dot ens dot fr
2009-10-23 15:02 ` dominiq at lps dot ens dot fr
` (8 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: dominiq at lps dot ens dot fr @ 2008-12-15 12:50 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from dominiq at lps dot ens dot fr 2008-12-15 12:48 -------
Compiling the test in comment #4 gives:
pr37829_2.f90:21.6:
d = c_funloc (g)
1
Error: Can't convert TYPE(_gfortran_iso_c_binding_c_funptr) to TYPE(c_funptr)
at (1)
looking the gfortran sources for "c_funptr" I get:
in gcc/fortran/iso-c-binding.def, line 145
DERIVED_TYPE (ISOCBINDING_FUNPTR, "c_funptr", \
get_int_kind_from_node (ptr_type_node))
and in gcc/fortran/symbol.c, line 3507
generate_isocbinding_symbol (module_name, ptr_id == ISOCBINDING_NULL_PTR
? ISOCBINDING_PTR : ISOCBINDING_FUNPTR,
(const char *) (ptr_id ==
ISOCBINDING_NULL_PTR
? "_gfortran_iso_c_binding_c_ptr"
: "_gfortran_iso_c_binding_c_funptr"));
line 3591
if (iso_c_sym_id == ISOCBINDING_F_PROCPOINTER)
c_ptr_type = "_gfortran_iso_c_binding_c_funptr";
else
c_ptr_type = "_gfortran_iso_c_binding_c_ptr";
line 4158
(const char *)(s == ISOCBINDING_FUNLOC
? "_gfortran_iso_c_binding_c_funptr"
: "_gfortran_iso_c_binding_c_ptr"));
I fail to see what is the difference between "c_funptr" and
"_gfortran_iso_c_binding_c_funptr".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] ICE in resolve_symbol
2008-10-14 20:09 [Bug fortran/37829] New: ICE in resolve_symbol jakub at gcc dot gnu dot org
` (5 preceding siblings ...)
2008-12-15 12:50 ` dominiq at lps dot ens dot fr
@ 2009-10-23 15:02 ` dominiq at lps dot ens dot fr
2009-10-24 22:42 ` mikael at gcc dot gnu dot org
` (7 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: dominiq at lps dot ens dot fr @ 2009-10-23 15:02 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from dominiq at lps dot ens dot fr 2009-10-23 15:01 -------
It seems that the patch in comment #2 has been silently applied (I have been
unable to find when) and that the test in comment #0 no longer gives an ICE for
gfortran 4.3.4, 4.4.1, and trunk.
Apparently the failure of the test in comment #4 is due to the fact that
c_funptr is not mangled the way it is defined (through different modules and an
only clause). If I remove module 'a' and the comment in module 'b', the code
compiles.
This pr could probably be closed and a new one open for the problem of comment
#4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] ICE in resolve_symbol
2008-10-14 20:09 [Bug fortran/37829] New: ICE in resolve_symbol jakub at gcc dot gnu dot org
` (6 preceding siblings ...)
2009-10-23 15:02 ` dominiq at lps dot ens dot fr
@ 2009-10-24 22:42 ` mikael at gcc dot gnu dot org
2009-10-25 15:34 ` dominiq at lps dot ens dot fr
` (6 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: mikael at gcc dot gnu dot org @ 2009-10-24 22:42 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from mikael at gcc dot gnu dot org 2009-10-24 22:42 -------
(In reply to comment #7)
> It seems that the patch in comment #2 has been silently applied
Not exactly silently. It was pr38672
> Apparently the failure of the test in comment #4 is due to the fact that
> c_funptr is not mangled the way it is defined (through different modules and an
> only clause). If I remove module 'a' and the comment in module 'b', the code
> compiles.
The whole iso_c_binding is messy because it doesn't look like normal modules.
It hijacks functions everywhere to take care of iso_c_binding cases and doesn't
benefit from the general code. Here, the derived type of the function c_funloc
is given a mangled name because it is not wanted by the user.
This seems to fix it :
Index: symbol.c
===================================================================
--- symbol.c (revision 153473)
+++ symbol.c (working copy)
@@ -4397,8 +4397,8 @@
(mod_name, s == ISOCBINDING_FUNLOC
? ISOCBINDING_FUNPTR : ISOCBINDING_PTR,
(const char *)(s == ISOCBINDING_FUNLOC
- ? "_gfortran_iso_c_binding_c_funptr"
- : "_gfortran_iso_c_binding_c_ptr"));
+ ? "c_funptr"
+ : "c_ptr"));
tmp_sym->ts.u.derived =
get_iso_c_binding_dt (s == ISOCBINDING_FUNLOC
? ISOCBINDING_FUNPTR
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] ICE in resolve_symbol
2008-10-14 20:09 [Bug fortran/37829] New: ICE in resolve_symbol jakub at gcc dot gnu dot org
` (7 preceding siblings ...)
2009-10-24 22:42 ` mikael at gcc dot gnu dot org
@ 2009-10-25 15:34 ` dominiq at lps dot ens dot fr
2009-12-06 15:40 ` [Bug fortran/37829] ICE Incorrect name mangling with iso_c_binding jvdelisle at gcc dot gnu dot org
` (5 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: dominiq at lps dot ens dot fr @ 2009-10-25 15:34 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from dominiq at lps dot ens dot fr 2009-10-25 15:34 -------
(In reply to comment #8)
> > It seems that the patch in comment #2 has been silently applied
> Not exactly silently. It was pr38672
Thanks for the pointer. This PR has not been marked as a duplicate of pr38672
and while the later refers to this one, the converse was not true.
> The whole iso_c_binding is messy because it doesn't look like normal modules.
I have also noticed that!-)
> It hijacks functions everywhere to take care of iso_c_binding cases and doesn't
> benefit from the general code. Here, the derived type of the function c_funloc
> is given a mangled name because it is not wanted by the user.
> This seems to fix it :
> ...
I think the patch just papers over the problem. With it, the following (weird,
but legal?) code:
module b
use iso_c_binding, only:c_funloc!,c_funptr
end module b
program c
use b
implicit none
type c_funptr
integer :: i
end type
type (c_funptr) :: d
d = c_funptr(1)
end
now gives errors:
pr37829_2_red_1.f90:8.15:
type c_funptr
1
Error: Derived type name 'c_funptr' at (1) already has a basic type of
TYPE(c_funptr)
pr37829_2_red_1.f90:10.5:
end type
1
Error: Expecting END PROGRAM statement at (1)
pr37829_2_red_1.f90:12.6:
d = c_funptr(1)
1
Error: Components of structure constructor 'c_funptr' at (1) are PRIVATE
This is coherent if the mangling is used to hide symbols not wanted by the
user.
In my opinion the question is how to remove the mangling done in module b, when
the symbol is used in module a. From the little I understand that does seem
obvious for me.
Indeed using c_funloc in one module and defining the return type in another one
is asking for trouble.
Nevertheless if it is legal it should be accepted by gfortran. So either we
change the summary of this pr or close it, opening a new one for this use of
modules. It both cases the pr can be marked with a low priority and as an
enhancement.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] ICE Incorrect name mangling with iso_c_binding
2008-10-14 20:09 [Bug fortran/37829] New: ICE in resolve_symbol jakub at gcc dot gnu dot org
` (8 preceding siblings ...)
2009-10-25 15:34 ` dominiq at lps dot ens dot fr
@ 2009-12-06 15:40 ` jvdelisle at gcc dot gnu dot org
2010-07-09 8:39 ` [Bug fortran/37829] " burnus at gcc dot gnu dot org
` (4 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2009-12-06 15:40 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-12-06 15:40 -------
More descriptive summary. Low priority.
--
jvdelisle at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P4
Summary|ICE in resolve_symbol |ICE Incorrect name mangling
| |with iso_c_binding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] Incorrect name mangling with iso_c_binding
2008-10-14 20:09 [Bug fortran/37829] New: ICE in resolve_symbol jakub at gcc dot gnu dot org
` (9 preceding siblings ...)
2009-12-06 15:40 ` [Bug fortran/37829] ICE Incorrect name mangling with iso_c_binding jvdelisle at gcc dot gnu dot org
@ 2010-07-09 8:39 ` burnus at gcc dot gnu dot org
2010-07-09 8:48 ` burnus at gcc dot gnu dot org
` (3 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: burnus at gcc dot gnu dot org @ 2010-07-09 8:39 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from burnus at gcc dot gnu dot org 2010-07-09 08:38 -------
*** Bug 44814 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO|44814 |
nThis| |
CC| |jkrahn at nc dot rr dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] Incorrect name mangling with iso_c_binding
2008-10-14 20:09 [Bug fortran/37829] New: ICE in resolve_symbol jakub at gcc dot gnu dot org
` (10 preceding siblings ...)
2010-07-09 8:39 ` [Bug fortran/37829] " burnus at gcc dot gnu dot org
@ 2010-07-09 8:48 ` burnus at gcc dot gnu dot org
2010-08-05 17:51 ` mikael at gcc dot gnu dot org
` (2 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: burnus at gcc dot gnu dot org @ 2010-07-09 8:48 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from burnus at gcc dot gnu dot org 2010-07-09 08:48 -------
For intrinsic modules, we currently have:
use iso_c_binding, only: c_null_ptr
which use-associates a constant (PARAMETER) of the type "c_ptr" - but "c_ptr"
is not imported directly; to make the type information available, gfortran
currently imports "c_ptr" in a hidden way (_gfortran_...).
But the problem is the same for nonintrinsic modules. Thus, the question is:
How does it work there - it obviously does:
module m
type t; end type
end module m
module m2
use m
! private; public :: null
type(t), parameter :: null = t()
end module m2
module m3
use m
! private; public :: sub
contains
subroutine sub(x); type(t) :: x; end subroutine
end module m3
use m2, only: null
use m3, only: sub
call sub(null)
contains
subroutine sub2(); use m; type(t) :: y; y = null; end subroutine
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] Incorrect name mangling with iso_c_binding
2008-10-14 20:09 [Bug fortran/37829] New: ICE in resolve_symbol jakub at gcc dot gnu dot org
` (11 preceding siblings ...)
2010-07-09 8:48 ` burnus at gcc dot gnu dot org
@ 2010-08-05 17:51 ` mikael at gcc dot gnu dot org
2010-08-14 9:31 ` burnus at gcc dot gnu dot org
2010-08-14 16:24 ` burnus at gcc dot gnu dot org
14 siblings, 0 replies; 20+ messages in thread
From: mikael at gcc dot gnu dot org @ 2010-08-05 17:51 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from mikael at gcc dot gnu dot org 2010-08-05 17:51 -------
*** Bug 45190 has been marked as a duplicate of this bug. ***
--
mikael at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathewc at nag dot co dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] Incorrect name mangling with iso_c_binding
2008-10-14 20:09 [Bug fortran/37829] New: ICE in resolve_symbol jakub at gcc dot gnu dot org
` (12 preceding siblings ...)
2010-08-05 17:51 ` mikael at gcc dot gnu dot org
@ 2010-08-14 9:31 ` burnus at gcc dot gnu dot org
2010-08-14 16:24 ` burnus at gcc dot gnu dot org
14 siblings, 0 replies; 20+ messages in thread
From: burnus at gcc dot gnu dot org @ 2010-08-14 9:31 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from burnus at gcc dot gnu dot org 2010-08-14 09:31 -------
Cf.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/887251d8cd64eb02
Lightly tested patch. The ts.is_c_interop is only set when via
verify_bind_c_derived_type, which is called by resolve.c - and thus comes too
late.
I am not sure whether this now allows DT which are not BIND(C) and whether one
thus should add an !attr.resolved, but I assume that incompatibilities between
the BIND(C) attribute for the DT and the actual DT will be found at resolution
time. Thus, the patch should be fine.
Index: gcc/fortran/decl.c
===================================================================
--- gcc/fortran/decl.c (Revision 163239)
+++ gcc/fortran/decl.c (Arbeitskopie)
@@ -991,7 +991,7 @@ verify_c_interop_param (gfc_symbol *sym)
/* Make personalized messages to give better feedback. */
if (sym->ts.type == BT_DERIVED)
gfc_error ("Type '%s' at %L is a parameter to the BIND(C) "
- " procedure '%s' but is not C interoperable "
+ "procedure '%s' but is not C interoperable "
"because derived type '%s' is not C interoperable",
sym->name, &(sym->declared_at),
sym->ns->proc_name->name,
@@ -3612,7 +3612,8 @@ gfc_try
verify_c_interop (gfc_typespec *ts)
{
if (ts->type == BT_DERIVED && ts->u.derived != NULL)
- return (ts->u.derived->ts.is_c_interop ? SUCCESS : FAILURE);
+ return (ts->u.derived->ts.is_c_interop || ts->u.derived->attr.is_bind_c)
+ ? SUCCESS : FAILURE;
else if (ts->is_c_interop != 1)
return FAILURE;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] Incorrect name mangling with iso_c_binding
2008-10-14 20:09 [Bug fortran/37829] New: ICE in resolve_symbol jakub at gcc dot gnu dot org
` (13 preceding siblings ...)
2010-08-14 9:31 ` burnus at gcc dot gnu dot org
@ 2010-08-14 16:24 ` burnus at gcc dot gnu dot org
14 siblings, 0 replies; 20+ messages in thread
From: burnus at gcc dot gnu dot org @ 2010-08-14 16:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from burnus at gcc dot gnu dot org 2010-08-14 16:24 -------
Ignore comment 14 - that's PR fortran/45211. Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] Incorrect name mangling with iso_c_binding
[not found] <bug-37829-4@http.gcc.gnu.org/bugzilla/>
@ 2011-01-13 6:40 ` jvdelisle at gcc dot gnu.org
2011-11-09 14:02 ` burnus at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 20+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2011-01-13 6:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jvdelisle at gcc dot
| |gnu.org
Known to fail| |
--- Comment #16 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-01-13 05:46:01 UTC ---
>From c.l.f James Van Buskirk; Elusive bug PR37829
That bug bugs me so bad and it's hard to reproduce, but I found a
trigger:
C:\gfortran\clf\opengl2>type bug1.f90
module m3
use ISO_C_BINDING
implicit none
private
public kill_C_PTR
interface
function kill_C_PTR() bind(C)
import
implicit none
type(C_PTR) kill_C_PTR
end function kill_C_PTR
end interface
public kill_C_FUNPTR
interface
function kill_C_FUNPTR() bind(C)
import
implicit none
type(C_FUNPTR) kill_C_FUNPTR
end function kill_C_FUNPTR
end interface
end module m3
module m1
use m3
end module m1
program X
use m1
use ISO_C_BINDING
implicit none
type(C_PTR) cp
type(C_FUNPTR) fp
integer(C_INT),target :: i
interface
function fun() bind(C)
use ISO_C_BINDING
implicit none
real(C_FLOAT) fun
end function fun
end interface
cp = C_NULL_PTR
cp = C_LOC(i)
fp = C_NULL_FUNPTR
fp = C_FUNLOC(fun)
end program X
function fun() bind(C)
use ISO_C_BINDING
implicit none
real(C_FLOAT) fun
fun = 1.0
end function fun
function kill_C_PTR() bind(C)
use ISO_C_BINDING
implicit none
type(C_PTR) kill_C_PTR
integer(C_INT), pointer :: p
allocate(p)
kill_C_PTR = C_LOC(p)
end function kill_C_PTR
function kill_C_FUNPTR() bind(C)
use ISO_C_BINDING
implicit none
type(C_FUNPTR) kill_C_FUNPTR
interface
function fun() bind(C)
use ISO_C_BINDING
implicit none
real(C_FLOAT) fun
end function fun
end interface
kill_C_FUNPTR = C_FUNLOC(fun)
end function kill_C_FUNPTR
C:\gfortran\clf\opengl2>gfortran bug1.f90 -obug1
bug1.f90:44.8:
cp = C_NULL_PTR
1
Error: Can't convert TYPE(_gfortran_iso_c_binding_c_ptr) to TYPE(c_ptr) at
(1)
bug1.f90:45.8:
cp = C_LOC(i)
1
Error: Can't convert TYPE(_gfortran_iso_c_binding_c_ptr) to TYPE(c_ptr) at
(1)
bug1.f90:46.8:
fp = C_NULL_FUNPTR
1
Error: Can't convert TYPE(_gfortran_iso_c_binding_c_funptr) to
TYPE(c_funptr) at
(1)
bug1.f90:47.8:
fp = C_FUNLOC(fun)
1
Error: Can't convert TYPE(_gfortran_iso_c_binding_c_funptr) to
TYPE(c_funptr) at
(1)
bug1.f90:63.16:
kill_C_PTR = C_LOC(p)
1
Error: Can't convert TYPE(_gfortran_iso_c_binding_c_ptr) to TYPE(c_ptr) at
(1)
bug1.f90:77.19:
kill_C_FUNPTR = C_FUNLOC(fun)
1
Error: Can't convert TYPE(_gfortran_iso_c_binding_c_funptr) to
TYPE(c_funptr) at
(1)
It's the use of a function with result of TYPE(C_PTR) that kills
C_PTR subsequently and similarly the function with a result of
TYPE(C_FUNPTR) kills off C_FUNPTR. Abstract interfaces do the trick
as well as interfaces to realized functions. Note that directly
USEing module m3 in program X above isn't sufficient to trigger the
bug: m3 needs to be USEd in intermediate module m1 which then is
USEd in program X.
It's hard to set this one off, but when you do, look out! Note that
the last two failures occur in external functions that don't even
USE module m3 or m1 directly or indirectly, yet they still fall
victim once the compiler has come off the rails.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] Incorrect name mangling with iso_c_binding
[not found] <bug-37829-4@http.gcc.gnu.org/bugzilla/>
2011-01-13 6:40 ` jvdelisle at gcc dot gnu.org
@ 2011-11-09 14:02 ` burnus at gcc dot gnu.org
2011-11-16 21:58 ` burnus at gcc dot gnu.org
2011-11-16 22:21 ` burnus at gcc dot gnu.org
3 siblings, 0 replies; 20+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-11-09 14:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #17 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-09 13:55:29 UTC ---
Patch, which also fixes this bug:
http://gcc.gnu.org/ml/fortran/2011-11/msg00061.html
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] Incorrect name mangling with iso_c_binding
[not found] <bug-37829-4@http.gcc.gnu.org/bugzilla/>
2011-01-13 6:40 ` jvdelisle at gcc dot gnu.org
2011-11-09 14:02 ` burnus at gcc dot gnu.org
@ 2011-11-16 21:58 ` burnus at gcc dot gnu.org
2011-11-16 22:21 ` burnus at gcc dot gnu.org
3 siblings, 0 replies; 20+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-11-16 21:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
--- Comment #18 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-16 21:37:47 UTC ---
Author: burnus
Date: Wed Nov 16 21:37:43 2011
New Revision: 181425
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181425
Log:
gcc/fortran
2011-11-16 Tobias Burnus <burnus@net-b.de>
PR fortran/39427
PR fortran/37829
* decl.c (match_data_constant, match_data_constant,
* variable_decl,
gfc_match_decl_type_spec, access_attr_decl,
check_extended_derived_type, gfc_match_derived_decl,
gfc_match_derived_decl, gfc_match_derived_decl) Modified to deal
with DT constructors.
* gfortran.h (gfc_find_dt_in_generic,
gfc_convert_to_structure_constructor): New function prototypes.
* interface.c (check_interface0, check_interface1,
gfc_search_interface): Ignore DT constructors in generic list.
* match.h (gfc_match_structure_constructor): Update prototype.
* match.c (match_derived_type_spec): Ensure that one uses the DT
not the generic function.
* module.c (MOD_VERSION): Bump.
(dt_lower_string, dt_upper_string): New functions.
(find_use_name_n, find_use_operator, compare_true_names,
find_true_name, add_true_name, fix_mio_expr, load_needed,
read_module, write_dt_extensions, write_symbol): Changes to deal with
different symtree vs. sym names.
(create_derived_type): Create also generic procedure.
* parse.c (gfc_fixup_sibling_symbols): Don't regard DT and
* generic
function as the same.
* primary.c (gfc_convert_to_structure_constructor): New
* function.
(gfc_match_structure_constructor): Restructured; calls
gfc_convert_to_structure_constructor.
(build_actual_constructor, gfc_match_rvalue): Update for DT generic
functions.
* resolve.c (resolve_formal_arglist, resolve_structure_cons,
is_illegal_recursion, resolve_generic_f, resolve_variable,
resolve_fl_variable_derived, resolve_fl_derived0,
resolve_symbol): Handle DT and DT generic constructors.
* symbol.c (gfc_use_derived, gfc_undo_symbols,
gen_special_c_interop_ptr, gen_cptr_param,
generate_isocbinding_symbol, gfc_get_derived_super_type): Handle
derived-types, which are hidden in the generic type.
(gfc_find_dt_in_generic): New function
* trans-array.c (gfc_conv_array_initializer): Replace
* FL_PARAMETER
expr by actual value.
* trans-decl.c (gfc_get_module_backend_decl,
* gfc_trans_use_stmts):
Ensure that we use the DT and not the generic function.
* trans-types.c (gfc_get_derived_type): Ensure that we use the
* DT
and not the generic procedure.
gcc/testsuite/
2011-11-16 Tobias Burnus <burnus@net-b.de>
PR fortran/39427
PR fortran/37829
* gfortran.dg/constructor_1.f90: New.
* gfortran.dg/constructor_2.f90: New.
* gfortran.dg/constructor_3.f90: New.
* gfortran.dg/constructor_4.f90: New.
* gfortran.dg/constructor_5.f90: New.
* gfortran.dg/constructor_6.f90: New.
* gfortran.dg/use_only_5.f90: New.
* gfortran.dg/c_ptr_tests_17.f90: New.
* gfortran.dg/c_ptr_tests_18.f90: New.
* gfortran.dg/used_types_25.f90: New.
* gfortran.dg/used_types_26.f90: New
* gfortran.dg/type_decl_3.f90: New.
* gfortran.dg/function_types_3.f90: Update dg-error.
* gfortran.dg/result_1.f90: Ditto.
* gfortran.dg/structure_constructor_3.f03: Ditto.
* gfortran.dg/structure_constructor_4.f03: Ditto.
Added:
trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_17.f90
trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_18.f90
trunk/gcc/testsuite/gfortran.dg/constructor_1.f90
trunk/gcc/testsuite/gfortran.dg/constructor_2.f90
trunk/gcc/testsuite/gfortran.dg/constructor_3.f90
trunk/gcc/testsuite/gfortran.dg/constructor_4.f90
trunk/gcc/testsuite/gfortran.dg/constructor_5.f90
trunk/gcc/testsuite/gfortran.dg/constructor_6.f90
trunk/gcc/testsuite/gfortran.dg/type_decl_3.f90
trunk/gcc/testsuite/gfortran.dg/use_only_5.f90
trunk/gcc/testsuite/gfortran.dg/used_types_25.f90
trunk/gcc/testsuite/gfortran.dg/used_types_26.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/match.h
trunk/gcc/fortran/module.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/function_types_3.f90
trunk/gcc/testsuite/gfortran.dg/result_1.f90
trunk/gcc/testsuite/gfortran.dg/structure_constructor_3.f03
trunk/gcc/testsuite/gfortran.dg/structure_constructor_4.f03
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/37829] Incorrect name mangling with iso_c_binding
[not found] <bug-37829-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2011-11-16 21:58 ` burnus at gcc dot gnu.org
@ 2011-11-16 22:21 ` burnus at gcc dot gnu.org
3 siblings, 0 replies; 20+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-11-16 22:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #19 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-16 21:53:39 UTC ---
Should now be FIXED on the 4.7 trunk.
Thanks Jakub and Joe for the report(s).
^ permalink raw reply [flat|nested] 20+ messages in thread