[Bug fortran/59997] New: c_pointer = c_loc(...) internal compiler error

[Bug fortran/59997] New: c_pointer = c_loc(...) internal compiler error

[chrisonian at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59997

            Bug ID: 59997
           Summary: c_pointer = c_loc(...) internal compiler error
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chrisonian at gmail dot com

The following program cannot compile with gfortran 4.8.1:
gfortran gfortran_c_ptr_bug.f90
gfortran_c_ptr_bug.f90:14:0: internal compiler error: Segmentation fault
 c_string_ptr = c_loc(X%c_line)
 ^

Changing X%c_line to X%c_line(1) removes the error. 

-----gfortran_c_ptr_bug.f90-------
program test
use iso_c_binding
implicit none
type scratch
  character(c_char) :: c_line(2)
end type
type(scratch), target :: X
type(c_ptr) :: c_string_ptr
character(1) :: line

line = 'a'
X%c_line(1) = line
X%c_line(2) = c_null_char
c_string_ptr = c_loc(X%c_line)

end program
----------------------------------

gfortran -v -save-temps gfortran_c_ptr_bug.f90
Driving: gfortran -v -save-temps gfortran_c_ptr_bug.f90 -l gfortran -l m
-shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/nfs/cms/sw/install/slc6_amd64_gcc481/external/gcc/4.8.1/bin/../libexec/gcc/x86_64-redhat-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-redhat-linux-gnu
Configured with: ../configure
--prefix=/build/davidlt/build-BOOTSTRAP_slc6_amd64_gcc481/b/tmp/BUILDROOT/e55a93caf1185342d60da645a6c0626d/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1
--disable-multilib --disable-nls --with-zlib=no
--enable-languages=c,c++,fortran --enable-gold=yes --enable-ld=default
--enable-lto
--with-gmp=/build/davidlt/build-BOOTSTRAP_slc6_amd64_gcc481/b/tmp/BUILDROOT/e55a93caf1185342d60da645a6c0626d/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1
--with-mpfr=/build/davidlt/build-BOOTSTRAP_slc6_amd64_gcc481/b/tmp/BUILDROOT/e55a93caf1185342d60da645a6c0626d/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1
--with-mpc=/build/davidlt/build-BOOTSTRAP_slc6_amd64_gcc481/b/tmp/BUILDROOT/e55a93caf1185342d60da645a6c0626d/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1
--with-isl=/build/davidlt/build-BOOTSTRAP_slc6_amd64_gcc481/b/tmp/BUILDROOT/e55a93caf1185342d60da645a6c0626d/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1
--with-cloog=/build/davidlt/build-BOOTSTRAP_slc6_amd64_gcc481/b/tmp/BUILDROOT/e55a93caf1185342d60da645a6c0626d/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1
--enable-checking=release --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --enable-libstdcxx-time=rt --enable-shared
CC='gcc -fPIC' CXX='c++ -fPIC' CPP=cpp CXXCPP='c++ -E'
Thread model: posix
gcc version 4.8.1 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'

/nfs/cms/sw/install/slc6_amd64_gcc481/external/gcc/4.8.1/bin/../libexec/gcc/x86_64-redhat-linux-gnu/4.8.1/f951
gfortran_c_ptr_bug.f90 -quiet -dumpbase gfortran_c_ptr_bug.f90 -mtune=generic
-march=x86-64 -auxbase gfortran_c_ptr_bug -version -fintrinsic-modules-path
/nfs/cms/sw/install/slc6_amd64_gcc481/external/gcc/4.8.1/bin/../lib/gcc/x86_64-redhat-linux-gnu/4.8.1/finclude
-o gfortran_c_ptr_bug.s
GNU Fortran (GCC) version 4.8.1 (x86_64-redhat-linux-gnu)
    compiled by GNU C version 4.8.1, GMP version 5.1.0, MPFR version 3.1.1, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.8.1 (x86_64-redhat-linux-gnu)
    compiled by GNU C version 4.8.1, GMP version 5.1.0, MPFR version 3.1.1, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
gfortran_c_ptr_bug.f90: In function 'test':
gfortran_c_ptr_bug.f90:14:0: internal compiler error: Segmentation fault
 c_string_ptr = c_loc(X%c_line)
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug fortran/59997] c_pointer = c_loc(...) internal compiler error

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59997

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
                 CC|                            |janus at gcc dot gnu.org

--- Comment #1 from janus at gcc dot gnu.org ---
I can confirm the ICE with 4.8 and earlier. However, it seems to be fixed on
4.9 trunk ...

[Bug fortran/59997] c_pointer = c_loc(...) internal compiler error

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59997

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-02-09
     Ever confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Likely fixed by r197053.

>From pr56378 comment 12:

> ... Since this looks way too large for backporting, I guess it will not be 
> fixed on the 4.7 and 4.8 branches, right?

[Bug fortran/59997] c_pointer = c_loc(...) internal compiler error

[drikosev at otenet dot gr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59997

drikosev at otenet dot gr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |drikosev at otenet dot gr

--- Comment #3 from drikosev at otenet dot gr ---
Created attachment 35294
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35294&action=edit
gcc48-pr59997.patch


Hi,

The above patch is quite small and perhaps solves the problem in branch 4-8.

I've coded it before I read the code convention rules for patches. In case the
patch indeed solves the problem, we'll adjust it accordingly.

So, one has to apply it, test and after discard it until we create the final
version (with change log & proper spacing).

Regards,
Ev. Drikos

[Bug fortran/59997] c_pointer = c_loc(...) internal compiler error

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59997

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> The above patch is quite small and perhaps solves the problem in branch 4-8.

> I've coded it before I read the code convention rules for patches.
> In case the patch indeed solves the problem, we'll adjust it accordingly.

I have tested the following patch (test for fsym->as as done elsewhere)

--- ../4.8_clean/gcc/fortran/trans-expr.c    2015-03-26 14:08:19.000000000
+0100
+++ gcc/fortran/trans-expr.c    2015-04-11 10:59:51.000000000 +0200
@@ -3730,7 +3730,7 @@ conv_isocbinding_procedure (gfc_se * se,
       /* We should want it to do g77 calling convention.  */
       f = (fsym != NULL)
         && !(fsym->attr.pointer || fsym->attr.allocatable)
-        && fsym->as->type != AS_ASSUMED_SHAPE;
+        && fsym->as && fsym->as->type != AS_ASSUMED_SHAPE;
       f = f || !sym->attr.always_explicit;

       gfc_conv_array_parameter (se, arg->expr, f, NULL, NULL, NULL);

For the test case you should have a look at
https://gcc.gnu.org/wiki/HowToPrepareATestcase, in particular to the section {
dg-do <action> }:

! { dg-do compile } 

is equivalent to compiling the code with -S, so there is no need for the line

+! { dg-options "-c" }

Now when fixing an ICE on valid code, one has to check that the ICE (not good)
is not replaced with wrong code (evil). Fortunately the test
gfortran.dg/c_loc_test_20.f90 yields an ICE without the patch, but compiles and
runs with it.

I am planning to answer your post on fortran@gcc.gnu.org later today.

[Bug fortran/59997] c_pointer = c_loc(...) internal compiler error

[drikosev at otenet dot gr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59997

--- Comment #5 from drikosev at otenet dot gr ---
On Apr 11, 2015, at 3:30 PM, dominiq at lps dot ens.fr
<gcc-bugzilla@gcc.gnu.org> wrote:

> For the test case you should have a look at
> https://gcc.gnu.org/wiki/HowToPrepareATestcase, in particular to the section {
> dg-do <action> }:
> 
> ! { dg-do compile } 
> 
> is equivalent to compiling the code with -S, so there is no need for the line
> 
> +! { dg-options "-c” }
> 

Thanks for the data.

> Now when fixing an ICE on valid code, one has to check that the ICE (not good)
> is not replaced with wrong code (evil). Fortunately the test
> gfortran.dg/c_loc_test_20.f90 yields an ICE without the patch, but compiles and
> runs with it.
> 
> I am planning to answer your post on fortran@gcc.gnu.org later today.
> 

I hadn’t seen that a test case was already available in trunk but I’ve run:

make check-fortran

No Test Case Failed and further I had compared a working example with gcc5.

The only suspicious thing is that the C function had to be underscored. In
example, I had
to create a C function named “cfun_” to run the example with both gcc4.8 & gcc5
at:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59997

Perhaps, this is ok or solved with an additional argument in the command line
but I’d
like to mention it here.

Also, I’ve sent to gcc@gcc.gnu.org a request for a copyright assignment form
but I guess
the process cannot be finalized the next one or two weeks.   


Regards,
Ev. Drikos
>From gcc-bugs-return-483399-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Apr 11 13:53:53 2015
Return-Path: <gcc-bugs-return-483399-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23257 invoked by alias); 11 Apr 2015 13:53:53 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23219 invoked by uid 55); 11 Apr 2015 13:53:49 -0000
From: "drikosev at otenet dot gr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/59997] c_pointer = c_loc(...) internal compiler error
Date: Sat, 11 Apr 2015 13:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: major
X-Bugzilla-Who: drikosev at otenet dot gr
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59997-4-zSBXQS87N0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59997-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59997-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg00951.txt.bz2
Content-length: 1604

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59997

--- Comment #6 from drikosev at otenet dot gr ---
On Apr 11, 2015, at 3:30 PM, dominiq at lps dot ens.fr
<gcc-bugzilla@gcc.gnu.org> wrote:

> For the test case you should have a look at
> https://gcc.gnu.org/wiki/HowToPrepareATestcase, in particular to the section {
> dg-do <action> }:
> 
> ! { dg-do compile } 
> 
> is equivalent to compiling the code with -S, so there is no need for the line
> 
> +! { dg-options "-c” }
> 

Thanks for the data.

> Now when fixing an ICE on valid code, one has to check that the ICE (not good)
> is not replaced with wrong code (evil). Fortunately the test
> gfortran.dg/c_loc_test_20.f90 yields an ICE without the patch, but compiles and
> runs with it.
> 
> I am planning to answer your post on fortran@gcc.gnu.org later today.
> 

I hadn’t seen that a test case was already available in trunk but I’ve run:

make check-fortran

No Test Case Failed and further I had compared a working example with gcc5.

The only suspicious thing is that the C function had to be underscored. In
example, I had
to create a C function named “cfun_” to run the example with both gcc4.8 & gcc5
at:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59997

Perhaps, this is ok or solved with an additional argument in the command line
but I’d
like to mention it here.

Also, I’ve sent to gcc@gcc.gnu.org a request for a copyright assignment form
but I guess
the process cannot be finalized the next one or two weeks.   


Regards,
Ev. Drikos
>From gcc-bugs-return-483401-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Apr 11 13:57:49 2015
Return-Path: <gcc-bugs-return-483401-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28851 invoked by alias); 11 Apr 2015 13:57:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 28763 invoked by uid 55); 11 Apr 2015 13:57:46 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/65554] [5 Regression] ICE: verify_gimple failed
Date: Sat, 11 Apr 2015 13:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-checking, ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65554-4-XNMOZvMasS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65554-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65554-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg00953.txt.bz2
Content-length: 439

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide554

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Sat Apr 11 13:57:11 2015
New Revision: 222009

URL: https://gcc.gnu.org/viewcvs?rev"2009&root=gcc&view=rev
Log:
    PR middle-end/65554
    * g++.dg/opt/pr65554.C: Use __SIZE_TYPE__ instead of unsigned long.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/opt/pr65554.C

[Bug fortran/59997] c_pointer = c_loc(...) internal compiler error

[drikosev at otenet dot gr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59997

--- Comment #7 from drikosev at otenet dot gr ---
The option of omitting the trailing underscore (-fno-underscoring) is explained
at https://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html

In the above link, there is also a wish (hope) that in future versions of GNU
Fortran this issue will be improved. I guess the future is not here yet! 

So, the program seems to be ok.


Regards,
Ev. Drikos

[Bug fortran/59997] c_pointer = c_loc(...) internal compiler error

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59997

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
I am confused by the comments 5 to 7, probably because my comment 4 was
confusing.

What I have tested is 4.8.5 with the patch for fortran/trans-expr.c plus the
additional tests

diff -upN ../4.8_clean/gcc/testsuite/gfortran.dg/c_loc_test_20.f90
gcc/testsuite/gfortran.dg/c_loc_test_20.f90
--- ../4.8_clean/gcc/testsuite/gfortran.dg/c_loc_test_20.f90    1970-01-01
01:00:00.000000000 +0100
+++ gcc/testsuite/gfortran.dg/c_loc_test_20.f90    2013-03-25
18:07:07.000000000 +0100
@@ -0,0 +1,34 @@
+! { dg-do run }
+!
+! PR fortran/38829
+! PR fortran/40963
+! PR fortran/38813
+!
+!
+program testcloc
+    use, intrinsic :: iso_c_binding
+    implicit none
+
+    type obj
+        real :: array(10,10)
+        real, allocatable :: array2(:,:)
+    end type
+
+    type(obj), target :: obj1
+    type(c_ptr) :: cptr
+    integer :: i
+    real, pointer :: array(:)
+
+    allocate (obj1%array2(10,10))
+    obj1%array  = reshape ([(i, i=1,100)], shape (obj1%array))
+    obj1%array2 = reshape ([(i, i=1,100)], shape (obj1%array))
+
+    cptr = c_loc (obj1%array)
+    call c_f_pointer (cptr, array, shape=[100])
+    if (any (array /= [(i, i=1,100)])) call abort ()
+
+    cptr = c_loc (obj1%array2)
+    call c_f_pointer (cptr, array, shape=[100])
+    if (any (array /= [(i, i=1,100)])) call abort ()
+end program testcloc
+
diff -upN ../4.8_clean/gcc/testsuite/gfortran.dg/pr59997.f90
gcc/testsuite/gfortran.dg/pr59997.f90
--- ../4.8_clean/gcc/testsuite/gfortran.dg/pr59997.f90    1970-01-01
01:00:00.000000000 +0100
+++ gcc/testsuite/gfortran.dg/pr59997.f90    2015-04-11 11:00:43.000000000
+0200
@@ -0,0 +1,29 @@
+! { dg-do compile }
+
+program test
+    use iso_c_binding
+    implicit none
+
+interface
+function cfun(a) ! should be subroutine if saythis returns void
+import :: c_ptr
+type(c_ptr), value :: a
+end function cfun
+end interface
+
+
+    type scratch
+        character(c_char) :: c_line(11)
+        end type
+    type(scratch), target :: X
+    type(c_ptr) :: c_string_ptr
+    character(10) :: line
+    integer cerr ;
+
+    line = 'my text'
+    X%c_line = line
+    X%c_line(11) = c_null_char
+    c_string_ptr = c_loc(X%c_line)
+    cerr = cfun(c_string_ptr);
+    write (*,*) "cerr= " , cerr ;
+end program

gfortran.dg/pr59997.f90 is a small modified version of the test proposed in
comment 3. This test can only be compiled because cfun is not present. If you
want to extend the test to run it, you should have a look at the several tests
checking the C/Fortran interoperability, e.g., gfortran.dg/c_ptr_tests*.

gfortran.dg/c_loc_test_20.f90 is a copy of the test found in the 4.9 branch or
in trunk. I have checked that compiling this test with a clean 4.8.5 gives an
ICE while the test compiles and runs with the patch.