User account creation filtered due to spam.

Bug 32801 - USE of ISO_C_BINDING, ONLY: C_LOC causes compiler seg fault
Summary: USE of ISO_C_BINDING, ONLY: C_LOC causes compiler seg fault
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks: 32630
  Show dependency treegraph
 
Reported: 2007-07-17 23:57 UTC by Douglas Wells
Modified: 2007-08-06 09:20 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-07-18 11:24:34


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Douglas Wells 2007-07-17 23:57:56 UTC
The following program causes a fault in the compiler:
    c_loc_prob.f:0: internal compiler error: Segmentation fault: 11
This is the reduced program:

    PROGRAM c_loc_prob
      USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_LOC 
     !   USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_PTR, C_LOC
    END PROGRAM c_loc_prob

Additional information:
  - Options for optimization and warnings seem to not affect the errot.
  - If C_PTR is declared prior to C_LOC (as in the comment), the compiler
    doesn't fault.
  - In the original programs (from which this example is extracted, the
    declaration of C_PTR prior to C_LOC causes the compiler to erroneously
    diagnose various other constructs

Workarounds:
  At least two workaounds for this problem work in the other (much larger)
  programs:
    - Avoid use of ONLY: qualifier to ISO_C_BINDING, e.g.,
        USE, INTRINSIC :: ISO_C_BINDING
    - Replace C_LOC with LOC at the invocation and C_PTR with C_LONG at the
      INTERFACE declaration.
Comment 1 Francois-Xavier Coudert 2007-07-18 11:24:34 UTC
Backtrace on x86_64-linux:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000459311 in resolve_symbol (sym=0xf0bb90)
    at ../../../trunk3/gcc/fortran/resolve.c:7284
7284      if (sym->ts.type == BT_DERIVED && sym->ts.derived->components == NULL
(gdb) where
#0  0x0000000000459311 in resolve_symbol (sym=0xf0bb90)
    at ../../../trunk3/gcc/fortran/resolve.c:7284
#1  0x0000000000463d87 in traverse_ns (st=0xf09930, 
    func=0x458a90 <resolve_symbol>)
    at ../../../trunk3/gcc/fortran/symbol.c:2846
#2  0x0000000000455480 in resolve_types (ns=0xf0ae80)
    at ../../../trunk3/gcc/fortran/resolve.c:8330
#3  0x0000000000458a6d in gfc_resolve (ns=0xf0bb90)
    at ../../../trunk3/gcc/fortran/resolve.c:8409
#4  0x000000000044b528 in gfc_parse_file ()

(gdb) p sym->ts
$3 = {type = BT_DERIVED, kind = 0, derived = 0x0, cl = 0x0, is_c_interop = 0, 
  is_iso_c = 0, f90_type = BT_UNKNOWN}

sym->ts has type BT_DERIVED, but yet sym->ts.derived is NULL. Maybe this should be set earlier, or maybe the test on (sym->ts.type == BT_DERIVED && sym->ts.derived->components == NULL) just needs changing into (sym->ts.type == BT_DERIVED && sym->ts.derived && sym->ts.derived->components == NULL).

Christopher, any idea if this sym node is correct?
Comment 2 Chris Rickett 2007-07-18 20:18:59 UTC
(In reply to comment #1)

> sym->ts has type BT_DERIVED, but yet sym->ts.derived is NULL. Maybe this should
> be set earlier, or maybe the test on (sym->ts.type == BT_DERIVED &&
> sym->ts.derived->components == NULL) just needs changing into (sym->ts.type ==
> BT_DERIVED && sym->ts.derived && sym->ts.derived->components == NULL).
> 
> Christopher, any idea if this sym node is correct?
> 

the sym node was incorrect.  there is a simple error in generate_isocbinding_symbol that auto-generated c_funptr instead of the necessary c_ptr.  

Comment 3 patchapp@dberlin.org 2007-07-18 21:15:25 UTC
Subject: Bug number PR 32801

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01559.html
Comment 4 Tobias Burnus 2007-07-18 22:02:34 UTC
Subject: Bug 32801

Author: burnus
Date: Wed Jul 18 22:02:21 2007
New Revision: 126732

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126732
Log:
2007-07-18  Christopher D. Rickett  <crickett@lanl.gov>

	PR fortran/32801
	* symbol.c (generate_isocbinding_symbol): Fix bug where
	ISOCBINDING_FUNPTR was generated for C_LOC instead of the needed
	ISOCBINDING_PTR.


2007-07-18  Christopher D. Rickett  <crickett@lanl.gov>

	PR fortran/32801
	* gfortran.dg/pr32801.f03: New test case.


Added:
    trunk/gcc/testsuite/gfortran.dg/pr32801.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/symbol.c
    trunk/gcc/testsuite/ChangeLog

Comment 5 Tobias Burnus 2007-07-18 22:06:44 UTC
>  - In the original programs (from which this example is extracted, the
>    declaration of C_PTR prior to C_LOC causes the compiler to erroneously
>    diagnose various other constructs

The reported problem has been fixed. Could you test whether the other problems persist or whether they have been fixed as well?
Comment 6 kargl 2007-07-21 20:31:38 UTC
Subject: Bug 32801

Author: kargl
Date: Sat Jul 21 20:31:17 2007
New Revision: 126812

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126812
Log:
2007-07-21  Christopher D. Rickett  <crickett@lanl.gov>

        PR fortran/32801
        * symbol.c (generate_isocbinding_symbol): Remove unnecessary
        conditional.

        PR fortran/32804
        * resolve.c (gfc_iso_c_func_interface): Reject assumed-shape and
        deferred-shape arrays as args to C_LOC.  Fix bug in testing
        character args to C_LOC.

2007-07-21  Christopher D. Rickett  <crickett@lanl.gov>

        PR fortran/32804
        * gfortran.dg/c_loc_tests_9.f03: New test case.
        * gfortran.dg/c_loc_tests_10.f03: Ditto.


Added:
    trunk/gcc/testsuite/gfortran.dg/c_loc_tests_10.f03
    trunk/gcc/testsuite/gfortran.dg/c_loc_tests_9.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/symbol.c
    trunk/gcc/testsuite/ChangeLog

Comment 7 kargl 2007-07-21 20:41:16 UTC
Douglas,

Is this problem fixed for you, now?
Comment 8 Francois-Xavier Coudert 2007-08-06 09:20:08 UTC
Without any more news, let's consider this fixed. Douglas, if it so happens that your bug wasn't fixed by the patch, please reopen this bug-report.