User account creation filtered due to spam.

Bug 32957 - C/Fortran interoperability and -fdefault-integer-8
Summary: C/Fortran interoperability and -fdefault-integer-8
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: diagnostic
Depends on:
Blocks: 32630 32770
  Show dependency treegraph
Reported: 2007-08-01 14:56 UTC by Dominique d'Humieres
Modified: 2011-12-27 11:14 UTC (History)
2 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2007-10-05 12:44:03

patch to fix some failures with -fdefault-integer-8 (1.47 KB, text/plain)
2011-12-27 11:14 UTC, Dominique d'Humieres

Note You need to log in before you can comment on or make changes to this bug.
Description Dominique d'Humieres 2007-08-01 14:56:45 UTC
Many failures in the test suite with -fdefault-integer-8 come from tests mixing C and Fortran. While definitively not an expert in this area, I find pretty obvious that changing the default integer/real type on one side and not the other is asking for troubles. Apparently gfortran, but not the test suite, is finding some of them as in gfortran.dg/c_loc_tests_2.f03:

[karma] f90/bug% gfc -fdefault-integer-8 /opt/gcc/gcc-4.3-work/gcc/testsuite/gfortran.dg/c_loc_tests_2.f03

    if(test_array_address(my_c_ptr_1, 100) .ne. 1) then
Error: Type/rank mismatch in argument 'num_elements' at (1)

  use c_loc_tests_2
Fatal Error: Can't open module file 'c_loc_tests_2.mod' for reading at (1): No such file or directory

Using -fdefault-integer-8 with 'intrinsic :: iso_c_binding' should probably trigger an error or at least a warning.
Comment 1 kargl 2007-08-01 15:04:16 UTC
At this point, the easiest fix is probably going to be to document
that -fdefault-integer-8 should not be used with bind(c) code.  A
check of this option can be inserted at various locations during the
Comment 2 Dominique d'Humieres 2007-08-02 17:08:09 UTC
Subject: Re:  C/Fortran interoperability and

> A check of this option can be inserted at various locations during
> the parsing.

Certainly, but this will give a very interesting exercise to build test cases!
Comment 3 Dominique d'Humieres 2009-12-06 10:52:37 UTC
If I apply the following patch:

--- c_loc_tests_2.f03	2009-11-25 18:17:45.000000000 +0100
+++ c_loc_tests_2_db_1.f03	2009-12-06 11:43:31.000000000 +0100
@@ -44,13 +44,13 @@ contains
   end subroutine test0
   subroutine test1() bind(c)
-    integer, target, dimension(100) :: int_array_tar
+    integer(c_int), target, dimension(100) :: int_array_tar
     type(c_ptr) :: my_c_ptr_1 = c_null_ptr
     type(c_ptr) :: my_c_ptr_2 = c_null_ptr
-    int_array_tar = 100
+    int_array_tar = 100_c_int
     my_c_ptr_1 = c_loc(int_array_tar)
-    if(test_array_address(my_c_ptr_1, 100) .ne. 1) then
+    if(test_array_address(my_c_ptr_1, 100_c_int) .ne. 1) then
        call abort()
     end if
   end subroutine test1

the test passes with -fdefault-integer-8. Note that

gfc -fdefault-integer-8 c_loc_tests_2_db_1.f03 c_loc_tests_2_funcs.c

gives a warning:

cc1: warning: command line option "-fdefault-integer-8" is valid for Fortran but not for C

Although such warning can be trapped by adding in gcc/testsuite/lib/prune.exp lines such that

     regsub -all "(^|\n)cc1: warning: command line option .-fwhole-file. is valid for Fortran but not for C" $text "" text

it would be better to change the gfortran script to not pass gfortran options to other languages.

If there is any interest in updating the interoperability tests to works with -fdefault-*-8, I can comb the testsuite.
Comment 4 Dominique d'Humieres 2011-12-27 11:14:24 UTC
Created attachment 26187 [details]
patch to fix some failures with -fdefault-integer-8

I have this patch in my tree for a quite long time. It fixes some failures with -fdefault-integer-8 by replacing some implicit kinds with explicit ones.