[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #25 from Tobias Burnus 2013-03-25 17:56:11 UTC --- FIXED on the 4.9 trunk. I think all remaining issues are now fixed. Regarding the string length: Only character(len=1) is interoperable, using a substring doesn't make it valid. However, for C_LOC even Fortran 2003 (since Technical Corrigendum 5) allows character(kind=C_char) with len > 1.
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #24 from Tobias Burnus 2013-03-25 15:54:01 UTC --- Author: burnus Date: Mon Mar 25 15:40:26 2013 New Revision: 197053 URL: http://gcc.gnu.org/viewcvs?rev=197053&root=gcc&view=rev Log: 2013-03-25 Tobias Burnus PR fortran/38536 PR fortran/38813 PR fortran/38894 PR fortran/39288 PR fortran/40963 PR fortran/45824 PR fortran/47023 PR fortran/47034 PR fortran/49023 PR fortran/50269 PR fortran/50612 PR fortran/52426 PR fortran/54263 PR fortran/55343 PR fortran/55444 PR fortran/55574 PR fortran/56079 PR fortran/56378 * check.c (gfc_var_strlen): Properly handle 0-sized string. (gfc_check_c_sizeof): Use is_c_interoperable, add checks. (is_c_interoperable, gfc_check_c_associated, gfc_check_c_f_pointer, gfc_check_c_f_procpointer, gfc_check_c_funloc, gfc_check_c_loc): New functions. * expr.c (check_inquiry): Add c_sizeof, compiler_version and compiler_options. (gfc_check_pointer_assign): Refine function result check. gfortran.h (gfc_isym_id): Add GFC_ISYM_C_ASSOCIATED, GFC_ISYM_C_F_POINTER, GFC_ISYM_C_F_PROCPOINTER, GFC_ISYM_C_FUNLOC, GFC_ISYM_C_LOC. (iso_fortran_env_symbol, iso_c_binding_symbol): Handle NAMED_SUBROUTINE. (generate_isocbinding_symbol): Update prototype. (get_iso_c_sym): Remove. (gfc_isym_id_by_intmod, gfc_isym_id_by_intmod_sym): New prototypes. * intrinsic.c (gfc_intrinsic_subroutine_by_id): New function. (gfc_intrinsic_sub_interface): Use it. (add_functions, add_subroutines): Add missing C-binding intrinsics. (gfc_intrinsic_func_interface): Add special case for c_loc. gfc_isym_id_by_intmod, gfc_isym_id_by_intmod_sym): New functions. (gfc_intrinsic_func_interface, gfc_intrinsic_sub_interface): Use them. * intrinsic.h (gfc_check_c_associated, gfc_check_c_f_pointer, gfc_check_c_f_procpointer, gfc_check_c_funloc, gfc_check_c_loc, gfc_resolve_c_loc, gfc_resolve_c_funloc): New prototypes. * iresolve.c (gfc_resolve_c_loc, gfc_resolve_c_funloc): New functions. * iso-c-binding.def: Split PROCEDURE into NAMED_SUBROUTINE and NAMED_FUNCTION. * iso-fortran-env.def: Add NAMED_SUBROUTINE for completeness. * module.c (create_intrinsic_function): Support subroutines and derived-type results. (use_iso_fortran_env_module): Update calls. (import_iso_c_binding_module): Ditto; update calls to generate_isocbinding_symbol. * resolve.c (find_arglists): Skip for intrinsic symbols. (gfc_resolve_intrinsic): Find intrinsic subs via id. (is_scalar_expr_ptr, gfc_iso_c_func_interface, set_name_and_label, gfc_iso_c_sub_interface): Remove. (resolve_function, resolve_specific_s0): Remove calls to those. (resolve_structure_cons): Fix handling. * symbol.c (gen_special_c_interop_ptr): Update c_ptr/c_funptr generation. (gen_cptr_param, gen_fptr_param, gen_shape_param, build_formal_args, get_iso_c_sym): Remove. (std_for_isocbinding_symbol): Handle NAMED_SUBROUTINE. (generate_isocbinding_symbol): Support hidden symbols and using c_ptr/c_funptr symtrees for nullptr defs. * target-memory.c (gfc_target_encode_expr): Fix handling of c_ptr/c_funptr. * trans-expr.c (conv_isocbinding_procedure): Remove. (gfc_conv_procedure_call): Remove call to it. (gfc_trans_subcomponent_assign, gfc_conv_expr): Update handling of c_ptr/c_funptr. * trans-intrinsic.c (conv_isocbinding_function, conv_isocbinding_subroutine): New. (gfc_conv_intrinsic_function, gfc_conv_intrinsic_subroutine): Call them. * trans-io.c (transfer_expr): Fix handling of c_ptr/c_funptr. * trans-types.c (gfc_typenode_for_spec, gfc_get_derived_type): Ditto. (gfc_init_c_interop_kinds): Handle NAMED_SUBROUTINE. 2013-03-25 Tobias Burnus PR fortran/38536 PR fortran/38813 PR fortran/38894 PR fortran/39288 PR fortran/40963 PR fortran/45824 PR fortran/47023 PR fortran/47034 PR fortran/49023 PR fortran/50269 PR fortran/50612 PR fortran/52426 PR fortran/54263 PR fortran/55343 PR fortran/55444 PR fortran/55574 PR fortran/560
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|mikael at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #23 from Mikael Morin 2012-08-26 09:14:16 UTC --- Unassigning.
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 --- Comment #22 from Tobias Burnus 2011-01-25 15:44:50 UTC --- Created attachment 23121 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23121 draft patch, working but too many warnings (cf. test suite failures) Currently c_loc(a(1:2)) produces the warning "Array section in '%s' call at %L" which is correct but possibly misleading as F2008 (contrary to F2003) allows it. What F2008 only requires is that the argument is contiguous. At http://gcc.gnu.org/ml/fortran/2011-01/msg00180.html was an early (and very buggy), attached a more advanced patch which gives the warning: "Array might be not contiguous in '%s' call at %L" However, the patch is also overzealous by warning for "a(1:2:5)" which is contiguous (as equivalent to "a(1:1)"). But it also warns elsewhere too much. I think it would be useful to only warn (or error out) if it is known to be noncontiguous of if one cuts down the number of warnings.
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 --- Comment #21 from Thomas Koenig 2011-01-22 17:30:27 UTC --- Author: tkoenig Date: Sat Jan 22 17:30:22 2011 New Revision: 169130 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169130 Log: 2011-01-22 Thomas Koenig PR fortran/38536 * resolve.c (gfc_iso_c_func_interface): For C_LOC, check for array sections followed by component references which are illegal. Also check for coindexed arguments. 2011-01-22 Thomas Koenig PR fortran/38536 * gfortran.dg/c_loc_tests_16.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/c_loc_tests_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 Thomas Koenig changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #20 from Thomas Koenig 2011-01-14 19:42:58 UTC --- (In reply to comment #19) > > Similarly, c_loc(comp(1:2)%elem) is valid as long as "elem" is the only item > in > the derived type *and* no padding is happening. (As padding often occurs, one > could always reject it.) I don't think so, at least not in F 2003. comp(1:2) is an array slice, which is never interoperable. The language in F 2008 appears unchanged, so I guess the same applies there. > And comp(1:1)%elem is always contiguous - but that's also a strange way of > writing it. (Actually, I think that comp(1:1)%elem _is_ simply contiguous - > though I am not sure gfc_simply_contiguous does detect this.) That would be fairly easy to change. Can you open a PR for this?
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 --- Comment #19 from Tobias Burnus 2011-01-14 09:00:20 UTC --- (In reply to comment #18) > (I asked on comp.lang.fortran) Cf. http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/4b65b1cd206ce9fe Or from the standard (F2008): "15.2.3.6 C LOC (X)": "Argument. X [...] shall not be a coindexed object. [...] If it is an array, it shall be contiguous and have nonzero size." > We just have to check for array sections along the references, and error > out if there are any. I was about to suggest to use gfc_simply_contiguous() but I then realized that -- for a simply contiguous array "array" -- also the following array section array([1,2,3,4]) is contiguous - even though it is not simply contiguous and in the general case the contiguity is not compile-time checkable. (vector-subscripts are notoriously difficult to check at compile time) Similarly, c_loc(comp(1:2)%elem) is valid as long as "elem" is the only item in the derived type *and* no padding is happening. (As padding often occurs, one could always reject it.) And comp(1:1)%elem is always contiguous - but that's also a strange way of writing it. (Actually, I think that comp(1:1)%elem _is_ simply contiguous - though I am not sure gfc_simply_contiguous does detect this.) Personally, I think one should give some diagnostic as soon as the argument is not simply contiguous -- be it a warning or an error. At least I cannot imagine any sensible program using non-simply contiguous arrays as argument for C_LOC. (The term simply contiguous is defined in section 6.5.4.) * * * When you add another check for C_LOC, can you include one for the following? You just need to add a "gfc_is_coindexed (expr)". use iso_c_binding type t integer :: A end type t type(t), target, allocatable :: x(:)[:] type(c_ptr) :: cptr allocate(x(1)[*]) cptr = c_loc(x(1)%a)! OK cptr = c_loc(x(1)[1]%a) ! Invalid end
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 --- Comment #18 from Thomas Koenig 2011-01-13 19:52:31 UTC --- (In reply to comment #6) > An other failure: > > use iso_c_binding > type t1 > integer :: i(5) > end type t1 > type t2 > type(t1) :: t(5) > end type t2 > > character(len=2),target :: str(2) > type(t2), target :: tt > type(C_PTR) :: p > p = c_loc(tt%t%i(1)) > end This is ice-on-invalid (I asked on comp.lang.fortran) because tt%t is an array section, which is not interoperable. We just have to check for array sections along the references, and error out if there are any.
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 --- Comment #17 from tkoenig at netcologne dot de 2011-01-09 16:00:14 UTC --- Am 09.01.2011 16:33, schrieb burnus at gcc dot gnu.org: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 > > --- Comment #15 from Tobias Burnus 2011-01-09 > 15:33:02 UTC --- > (In reply to comment #13) >> The test case from comment 6 gives an ICE (segfault) in >> gfc_conv_procedure_call's check for >> && fsym->as->type != AS_ASSUMED_SHAPE; >> (guess: "fsym->as" is NULL) > > Actually, it's in conv_isocbinding_procedure (which got inlined). The issue > seems to be that the code assumes that arg->expr->rank != 0 implies that > arg->expr->symtree->n.sym->as is set. However, the assumption fails for: > p = c_loc(tt%t%i(1)) > as "tt" is a scalar. > I'm looking at this.
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 --- Comment #16 from Thomas Koenig 2011-01-09 15:37:50 UTC --- Author: tkoenig Date: Sun Jan 9 15:37:47 2011 New Revision: 168614 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168614 Log: 2011-01-09 Thomas Koenig PR fortran/38536 * resolve.c (is_scalar_expr_ptr): For a substring reference, use gfc_dep_compare_expr to compare start and end expession. Add FIXME for using gfc_deb_compare_expr elsewhere. 2011-01-09 Thomas Koenig PR fortran/38536 * gfortran.dg/iso_c_binding_c_loc_char_1.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/iso_c_binding_c_loc_char_1.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 --- Comment #15 from Tobias Burnus 2011-01-09 15:33:02 UTC --- (In reply to comment #13) > The test case from comment 6 gives an ICE (segfault) in > gfc_conv_procedure_call's check for > && fsym->as->type != AS_ASSUMED_SHAPE; > (guess: "fsym->as" is NULL) Actually, it's in conv_isocbinding_procedure (which got inlined). The issue seems to be that the code assumes that arg->expr->rank != 0 implies that arg->expr->symtree->n.sym->as is set. However, the assumption fails for: p = c_loc(tt%t%i(1)) as "tt" is a scalar.
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 --- Comment #14 from Dominique d'Humieres 2011-01-09 15:31:09 UTC --- > Thomas posted his patch at: > http://gcc.gnu.org/ml/fortran/2011-01/msg00067.html With this patch, the test in comment #6 still gives an ICE: Segmentation fault. The backtrace is Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0008 0x0001000dd18d in gfc_conv_procedure_call (se=0x7fff5fbfd650, sym=0x141a21640, args=0x141a23000, expr=0x141a24680, append_args=0x0) at ../../work/gcc/fortran/trans-expr.c:2682 2682&& fsym->as->type != AS_ASSUMED_SHAPE; (gdb) bt #0 0x0001000dd18d in gfc_conv_procedure_call (se=0x7fff5fbfd650, sym=0x141a21640, args=0x141a23000, expr=0x141a24680, append_args=0x0) at ../../work/gcc/fortran/trans-expr.c:2682 #1 0x0001000de004 in gfc_conv_function_expr (se=0x7fff5fbfd650, expr=) at ../../work/gcc/fortran/trans-expr.c:4036 Previous frame inner to this frame (gdb could not unwind past this frame) No further testing yet.
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 --- Comment #13 from Tobias Burnus 2011-01-09 15:21:11 UTC --- (In reply to comment #10) > Can this be closed? Is there something left to do here? The first test case of comment 0 seems to be still unfixed (accepts-invalid - expected error not printed). The test case from comment 6 gives an ICE (segfault) in gfc_conv_procedure_call's check for f = (fsym != NULL) && !(fsym->attr.pointer || fsym->attr.allocatable) && fsym->as->type != AS_ASSUMED_SHAPE; (guess: "fsym->as" is NULL) Comment 7 fails - but that's seems to be fixed by the patch of comment 12 (cf. also below). * * * (In reply to comment #12) > > Error: CHARACTER argument 'buf' to 'c_loc' at (1) must have a length of 1 > This might be sufficient to fix it. Thomas posted his patch at: http://gcc.gnu.org/ml/fortran/2011-01/msg00067.html
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #12 from Thomas Koenig 2011-01-08
23:35:40 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > Can this be closed? Is there something left to do here?
> >
> As of gfortran 4.4.4 (and 4.5.1) the program in comment #7 does not compile
> but
> gives the same error:
>
> Error: CHARACTER argument 'buf' to 'c_loc' at (1) must have a length of 1
This might be sufficient to fix it.
Index: resolve.c
===
--- resolve.c (Revision 168596)
+++ resolve.c (Arbeitskopie)
@@ -2547,9 +2547,7 @@ is_scalar_expr_ptr (gfc_expr *expr)
switch (ref->type)
{
case REF_SUBSTRING:
- if (ref->u.ss.length != NULL
- && ref->u.ss.length->length != NULL
- && ref->u.ss.start
+ if (ref->u.ss.start
&& ref->u.ss.start->expr_type == EXPR_CONSTANT
&& ref->u.ss.end
&& ref->u.ss.end->expr_type == EXPR_CONSTANT)
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
--- Comment #11 from brtnfld at hdfgroup dot org 2010-05-03 14:50 --- (In reply to comment #10) > Can this be closed? Is there something left to do here? > As of gfortran 4.4.4 (and 4.5.1) the program in comment #7 does not compile but gives the same error: Error: CHARACTER argument 'buf' to 'c_loc' at (1) must have a length of 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
--- Comment #10 from dfranke at gcc dot gnu dot org 2010-05-02 15:09 --- Can this be closed? Is there something left to do here? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32630 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
--- Comment #9 from mikael at gcc dot gnu dot org 2009-01-04 13:01 --- Subject: Bug 38536 Author: mikael Date: Sun Jan 4 13:01:12 2009 New Revision: 143050 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143050 Log: 2009-01-04 Mikael Morin PR fortran/38536 * gfortran.h (gfc_is_data_pointer): Added prototype * resolve.c (gfc_iso_c_func_interface): Use gfc_is_data_pointer to test for pointer attribute. * dependency.c (gfc_is_data_pointer): Support pointer-returning functions. 2009-01-04 Mikael Morin PR fortran/38536 * gfortran.dg/c_loc_tests_13.f90: New test. * gfortran.dg/c_loc_tests_14.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/c_loc_tests_13.f90 trunk/gcc/testsuite/gfortran.dg/c_loc_tests_14.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
--- Comment #8 from dominiq at lps dot ens dot fr 2009-01-04 12:27 --- Withe the patch in comment #5 the problems reported in comment #4 disappear, the test in comment #6 gives a bus error at compile time: pr38536_3.f90: In function 'MAIN__': pr38536_3.f90:1: internal compiler error: Bus error and the test in comment #7 gives the reported error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
--- Comment #7 from brtnfld at hdfgroup dot org 2008-12-31 15:36 --- Additional failure: SUBROUTINE test(buf, buf2) USE, INTRINSIC :: ISO_C_BINDING IMPLICIT NONE CHARACTER(LEN=*), INTENT(INOUT), TARGET :: buf CHARACTER(LEN=*), INTENT(INOUT), DIMENSION(1:2), TARGET :: buf2 TYPE(C_PTR) :: f_ptr f_ptr = C_LOC(buf(1:1)) ! FAILS: ! Error: CHARACTER argument 'buf' to 'c_loc' ! at (1) must have a length of 1 f_ptr = C_LOC(buf2(1)(1:1)) ! PASSES END SUBROUTINE test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
--- Comment #6 from mikael at gcc dot gnu dot org 2008-12-30 22:47 --- An other failure: use iso_c_binding type t1 integer :: i(5) end type t1 type t2 type(t1) :: t(5) end type t2 character(len=2),target :: str(2) type(t2), target :: tt type(C_PTR) :: p p = c_loc(tt%t%i(1)) end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
--- Comment #5 from mikael at gcc dot gnu dot org 2008-12-27 23:23 --- Created an attachment (id=16994) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16994&action=view) another attempt, regression-tested Regression-tested, but with regressions :-(. They are probably unrelated anyway: FAIL fmt_g0_1.f08 It is about i/o, and there is a recent patch from Jerry about it. Note: it fails with trunk as well. FAIL is_iostat_end_eor_1.f90: this one doesn't fail with trunk. The error is: collect2: ld terminated with signal 11 [Segmentation fault] This is unrelated, don't ask, because I don't want to investigate. I suspect it is a new feature of the glibc-2.9 :-/ What this patch changes: remove the gcc_assert, and add handling for pointer-returning functions. -- mikael at gcc dot gnu dot org changed: What|Removed |Added Attachment #16989|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
--- Comment #4 from dominiq at lps dot ens dot fr 2008-12-27 13:00 ---
If I remove the assert gfortran.dg/repack_arrays_1.f90 passes, while
gfortran.dg/pr32601.f03 gives:
print *, c_loc(get_ptr()) ! { dg-error "has PRIVATE components" }
1
Error: Parameter 'get_ptr' to 'c_loc' at (1) must be either a TARGET or an
associated pointer
instead of
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/pr32601.f03:22.19:
print *, c_null_ptr, t ! { dg-error "has PRIVATE components" }
1
Error: Derived type 'c_ptr' at (1) has PRIVATE components
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/pr32601.f03:22.24:
print *, c_null_ptr, t ! { dg-error "has PRIVATE components" }
1
Error: Derived type 'c_ptr' at (1) has PRIVATE components
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/pr32601.f03:23.11:
print *, t ! { dg-error "has PRIVATE components" }
1
Error: Derived type 'c_ptr' at (1) has PRIVATE components
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/pr32601.f03:25.25:
print *, c_loc(get_ptr()) ! { dg-error "has PRIVATE components" }
1
Error: Derived type 'c_ptr' at (1) has PRIVATE components
Note that I do not understand a single word of this private business: what can
be the use of a PUBLIC derived type with PRIVATE components?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
--- Comment #3 from dominiq at lps dot ens dot fr 2008-12-27 11:40 --- With the patch in comment#2, I see two regressions: [ibook-dhum] f90/bug% gfc /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/pr32601.f03 /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/pr32601.f03:10: internal compiler error: in gfc_iso_c_func_interface, at fortran/resolve.c:2064 ... [ibook-dhum] f90/bug% gfc /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/repack_arrays_1.f90 f951: internal compiler error: in gfc_iso_c_func_interface, at fortran/resolve.c:2064 They are due to the new line: gcc_assert (args->expr->expr_type == EXPR_VARIABLE); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-26 23:04 --- Created an attachment (id=16989) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16989&action=view) patch, not regression-tested This patch fixes the ICE and accepts the following (valid, I think) program (rejected by trunk) USE ISO_C_BINDING IMPLICIT NONE TYPE test3 INTEGER, DIMENSION(5) :: b END TYPE test3 TYPE test2 TYPE(test3), DIMENSION(:), POINTER :: a END TYPE test2 TYPE test TYPE(test2), DIMENSION(2) :: c END TYPE test TYPE(test) :: chrScalar TYPE(C_PTR) :: f_ptr TYPE(test3), TARGET :: d(3) chrScalar%c(1)%a => d f_ptr = c_loc(chrScalar%c(1)%a(1)%b(1)) end -- mikael at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mikael at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
--- Comment #1 from mikael at gcc dot gnu dot org 2008-12-26 22:54 ---
About the second error:
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33497#c3
in resolve.c:
2095 else if (parent_ref != NULL && parent_ref->type != REF_COMPONENT)
2096 gfc_internal_error ("Unexpected expression reference type in "
2097 "gfc_iso_c_func_interface");
we expect either a terminating component ref, or a component ref followed by a
terminating array or substring ref.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
