[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861 Scot Breitenfeld changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861 --- Comment #6 from Scot Breitenfeld --- Thanks for the standard reference. That is indeed what I was looking for. I understand now that, in this case, the INTENT refers to whether C_PTR can be changed and does not relate to the INTENT state of the target. I should change all my usage cases to INTENT(IN) since none of the Fortran wrappers allow changes to the pointer itself.
[Bug fortran/99982] INTERFACE selects wrong module procedure involving C_PTR and C_FUNPTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99982 --- Comment #11 from Scot Breitenfeld --- Thanks for the standard reference. That is indeed what I was looking for. I understand now that, in this case, the INTENT refers to whether C_PTR can be changed and does not relate to the INTENT state of the target. I should change all my usage cases to INTENT(IN) since none of the Fortran wrappers allow changes to the pointer itself.
[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861 --- Comment #3 from Scot Breitenfeld --- I see the same issue with NAG, regardless of the optimization level. Our CI testing had missed it because this was a parallel test, and we don't test parallel with NAG. I guess the issue is whether marking TYPE(C_PTR) as CLOBBER is correct. I looked through the 2018 standard and could not locate anything that addresses this use case. Are you interpreting the possibility that a TYPE(C_PTR) should not be declared INTENT(OUT)? I can instead change the subroutine to declare buf as INTEGER(C_INT), INTENT(OUT), TARGET :: buf and f_ptr = C_LOC(buf) and there is no issue. So it seems to depend on the TYPE of the argument being passed.
[Bug fortran/109861] New: Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861 Bug ID: 109861 Summary: Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault. Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: brtnfld at hdfgroup dot org Target Milestone: --- Created attachment 55085 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55085&action=edit Fortran/C/Makfile. Changing the optimization level in the makefile reproduces the behaviour. For a TYPE(C_PTR), INTENT(OUT), buf, which is being passed through a Fortran subroutine to get the value set in a C function, an optimization of >= -O1 gives the warning "used uninitialized [-Wuninitialized]" and then the program Segmentation faults - invalid memory reference. It works for gfortran 12 but fails for gfortran 13 and 14. It works if the INTENT is INOUT.
[Bug fortran/99982] INTERFACE selects wrong module procedure involving C_PTR and C_FUNPTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99982 --- Comment #9 from Scot Breitenfeld --- This is Great! Thank-you.
[Bug fortran/99982] INTERFACE selects wrong module procedure involving C_PTR and C_FUNPTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99982 --- Comment #5 from Scot Breitenfeld --- I removed the c_funptr interface in CGNS since it was not being used.
[Bug fortran/99982] INTERFACE selects wrong module procedure involving C_PTR and C_FUNPTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99982 --- Comment #4 from Scot Breitenfeld --- Is there an update on this issue, the CGNS fortran wrappers will not work with gfortran as there are no work arounds for this issue. Thanks.
[Bug fortran/100149] Seg fault passing to CHARACTER(*), DIMENSION(*), INTENT(IN), OPTIONAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100149 Scot Breitenfeld changed: What|Removed |Added Known to work||10.3.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Scot Breitenfeld --- For future reference, gfortran 10.3.0 does not have this issue. I've updated the Known to work. The bug report can be closed.
[Bug fortran/100149] Seg fault passing to CHARACTER(*), DIMENSION(*), INTENT(IN), OPTIONAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100149 --- Comment #2 from Scot Breitenfeld --- Thanks for the update; it is good to know that it was fixed in 11.0. I also tried it with GCC master (4.20.2021), and it worked. This is for an open-source library (CGNS), and it is a commonly used API; it is a show-stopper bug. Thanks again.
[Bug fortran/99982] INTERFACE selects wrong module procedure involving C_PTR and C_FUNPTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99982 --- Comment #1 from Scot Breitenfeld --- I checked with gcc master (4/20/2021), and it still has the same issue.
[Bug fortran/100149] New: Seg fault passing to CHARACTER(*), DIMENSION(*), INTENT(IN), OPTIONAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100149 Bug ID: 100149 Summary: Seg fault passing to CHARACTER(*), DIMENSION(*), INTENT(IN), OPTIONAL Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: brtnfld at hdfgroup dot org Target Milestone: --- Created attachment 50631 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50631&action=edit The program has two lines of doing that same thing, the lines are marked which fail. The attached program fails with: Program received signal SIGSEGV, Segmentation fault. 0x143c783f in __memmove_sse2_unaligned_erms () from /lib64/libc.so.6 The program worked with 10.1.0 (and 9.3.1, 7.5.0) and fails with 10.2.0
[Bug fortran/99982] New: INTERFACE selects wrong module procedure involving C_PTR and C_FUNPTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99982 Bug ID: 99982 Summary: INTERFACE selects wrong module procedure involving C_PTR and C_FUNPTR Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: brtnfld at hdfgroup dot org Target Milestone: --- Created attachment 50532 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50532&action=edit program uses interface and module procedure to select between subroutines with type C_PTR and C_FUNPTR The attached program always selects the TYPE(C_FUNPTR) when selecting between a (overloaded) subroutine with TYPE(C_PTR) and TYPE(C_FUNPTR), even when the variable type is TYPE(C_PTR). It does this for both passing a variable as the argument or using the C_LOC or c_funloc directly in the call. I tried it with 7.5.0, 10.2.0, same behavior. Intel and NAG both select the correct subroutine.
[Bug fortran/66973] Incorrect resolution of generic interface with TYPE(C_PTR)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973 --- Comment #6 from Scot Breitenfeld --- it also works if you add USE ISO_C_BINDING to the main program: PROGRAM main USE ISO_C_BINDING USE H5T IMPLICIT NONE REAL, TARGET :: val CALL pickone(C_LOC(val)) END PROGRAM main
[Bug fortran/66973] Incorrect resolution of generic interface with TYPE(C_PTR)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973 --- Comment #4 from Scot Breitenfeld --- The work around is instead to do: PROGRAM main USE H5T IMPLICIT NONE REAL, TARGET :: val TYPE(C_PTR) :: f_ptr f_ptr = C_LOC(val) CALL pickone(f_ptr) END PROGRAM main
[Bug fortran/66973] Incorrect resolution of generic interface with TYPE(C_PTR)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973 --- Comment #3 from Scot Breitenfeld --- (In reply to Scot Breitenfeld from comment #2) > The following sequence picks the f90 interface, when it should pick the f03 > (TYPE(C_PTR)) interface. > > gfortran -c H5Tff.F90 > gfortran fortranlib_test_F03.f90 -o H5Tff.o > > The program prints: > > PRINT*,'Inside pick_f90' I meant gfortran fortranlib_test_F03.f90 H5Tff.o
[Bug fortran/66973] Incorrect resolution of generic interface with TYPE(C_PTR)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973 --- Comment #2 from Scot Breitenfeld --- The following sequence picks the f90 interface, when it should pick the f03 (TYPE(C_PTR)) interface. gfortran -c H5Tff.F90 gfortran fortranlib_test_F03.f90 -o H5Tff.o The program prints: PRINT*,'Inside pick_f90'
[Bug fortran/66973] Incorrect resolution of generic interface with TYPE(C_PTR)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973 --- Comment #1 from Scot Breitenfeld --- Created attachment 36036 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36036&action=edit fortranlib_test_F03, main program
[Bug fortran/66973] New: Incorrect resolution of generic interface with TYPE(C_PTR)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973 Bug ID: 66973 Summary: Incorrect resolution of generic interface with TYPE(C_PTR) Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: brtnfld at hdfgroup dot org Target Milestone: --- Created attachment 36035 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36035&action=edit H5Tff.F90 -- contains the module The following sequence picks the f90 interface, when it should pick the
[Bug fortran/55891] Problem with shared library and EQUIVALENCE on darwin 11.4.2 x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55891 Scot Breitenfeld changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Scot Breitenfeld 2013-02-06 06:00:58 UTC --- That works for the simple example, but I still have problems with the larger code. But I have not been able to isolate the problem as of yet, so I'm no longer sure this is a bug in gfortran. I'll close the bug. It's good to know about those additional needed flags. Thanks.
[Bug fortran/55891] New: Problem with shared library and EQUIVALENCE on darwin 11.4.2 x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55891 Bug #: 55891 Summary: Problem with shared library and EQUIVALENCE on darwin 11.4.2 x86_64 Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: brtn...@hdfgroup.org On a x86_64 system with Darwin Kernel Version 11.4.2, and if you use to compile the programs: gfortran -shared -fPIC mod.f90 -o lib.so gfortran -fPIC main.f90 lib.so The main program does not receive the values from the module (i.e. the print statement will print 0,0). It works if you use a static library. main.f90: PROGRAM main USE LIB2 IMPLICIT NONE CALL f() PRINT*,i,j END PROGRAM main mod.f90: MODULE LIB2 INTEGER i INTEGER :: j EQUIVALENCE (j, i) CONTAINS SUBROUTINE f() IMPLICIT NONE j = 40 END SUBROUTINE f END MODULE LIB2 nm lib.so 0f9a T ___lib2_MOD_f 0f94 t __dyld_func_lookup 1010 S _lib2.eq.0_ U dyld_stub_binder 0f80 t dyld_stub_binding_helper
[Bug fortran/48404] SELECTED_REAL_KIND is returning KIND=16 when not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48404 Scot Breitenfeld changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #8 from Scot Breitenfeld 2011-04-06 01:36:28 UTC --- (In reply to comment #7) > (In reply to comment #3) I've played around with going between gcc 4.6, 4.5 and 4.4 and indeed it fixes the problem if you make sure to specify the correct LD_LIBRARY_PATH to the matching gcc version. For example, if I'm using gfortran4.6 then the library path LD_LIBRARY_PATH needs to find libgfortran.so at the installed 4.6 library path, for example /usr/local/lib/gcc46/. I did this for the test program and it works. It gave KIND=4,8,10,16 so gcc46 must of had libquadmath-support, and a program with KIND=16 compiles. My gcc4.5 and gcc4.4 apparently did not have libquadmath-support, so the test program gives KIND=4,8,10 which is fine. I also verified I could use the LD_LIBRARY_PATH at gcc4.5 for gcc4.4, so they are backward compatible assuming the libquadmath-support was the same (as it was in my case). Not much can be done if the packages get it wrong. Thanks for the help. I'll close the bug report.
[Bug fortran/48404] SELECTED_REAL_KIND is returning KIND=16 when not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48404 --- Comment #7 from Scot Breitenfeld 2011-04-05 18:46:26 UTC --- (In reply to comment #3) > Thus: How have you obtained the compiler? Are you sure that the correct > compiler/library combination is used? > One compiler was from Debian packages, other compilers were from compiling from source. Rolling back libgfortran to find an older version fixes the problem. I guess the best solution is to compile the code with -static to avoid the issue. Probably can close the bug report.
[Bug fortran/48404] SELECTED_REAL_KIND is returning KIND=16 when not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48404 --- Comment #2 from Scot Breitenfeld 2011-04-01 19:46:54 UTC --- (In reply to comment #1) > Works OK for me on 4.5 on Fedora 14. > > Please try compiling your test program with -static and run the test and > report > here please. with -static it does not return KIND=16, just KIND=4,8,10.
[Bug fortran/48404] New: SELECTED_REAL_KIND is returning KIND=16 when not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48404 Summary: SELECTED_REAL_KIND is returning KIND=16 when not available Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: brtn...@hdfgroup.org Testing for the REAL KIND available the program: PROGRAM test_kind IMPLICIT NONE INTEGER :: i, j, ii, ir, last, rkind_numbers(10) INTEGER :: jr, jd last = -1 ir = 0 DO i = 1,100 j = SELECTED_REAL_KIND(i) PRINT*,i,j IF(j .NE. last) THEN IF(last .NE. -1) THEN ir = ir + 1 rkind_numbers(ir) = last ENDIF last = j IF(j .EQ. -1) EXIT ENDIF ENDDO PRINT*,'KINDS SUPPORTED = ', rkind_numbers(1:ir) END PROGRAM test_kind returns KIND=4,8,10,16 but KIND=16 is not supported when using the same compiler on the same machine: REAL(KIND=16) :: x 1 Error: Kind 16 not supported for type REAL at (1) This happens for: Linux 2.6.18-194.3.1.el5PAE #1 SMP i686 i686 i386 GNU/Linux (gcc 4.5.2, 4.4.5, 4.3.5, *4.2.4 does not return KIND=16 ) Linux 2.6.18-194.32.1.el5 #1 SMP x86_64 x86_64 x86_64 GNU/Linux (gcc 4.5.2) FreeBSD 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0 amd64 (gcc 4.5.2) Does not happen (KIND!=16) for: Version 4.5.1 on Suse 11.4 Linux 2.6.37.1-1.2-desktop #1 SMP PREEMPT x86_64 x86_64 x86_64 GNU/Linux
[Bug fortran/45211] C interoperable error when compiling BIND(C) function in a module.
--- Comment #2 from brtnfld at hdfgroup dot org 2010-08-09 15:02 --- If the type declaration is moved to the module scope the code compiles. MODULE liter_cb_mod USE ISO_C_BINDING TYPE, BIND(C) :: MYFTYPE INTEGER(C_INT) :: I, J REAL(C_FLOAT) :: S END TYPE MYFTYPE CONTAINS FUNCTION liter_cb() bind(C) USE ISO_C_BINDING IMPLICIT NONE INTEGER(c_int) liter_cb TYPE(MYFTYPE) :: link_info liter_cb = 0 END FUNCTION liter_cb END MODULE liter_cb_mod There was a discussion about the matter in comp.lang.fortran under the topic "BIND(C) functions in a module error" as to the source of the problem. Since there seems to be a work around I downgraded the severity. -- brtnfld at hdfgroup dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45211
[Bug fortran/45211] New: C interoperable error when compiling BIND(C) function in a module.
gfortran (all versions 4.2-4.5) reports the error when trying to compile code
below:
Error: Type 'link_info' at (1) is a parameter to the BIND(C) procedure
'liter_cb' but is not C interoperable because derived type 'info_t' is not C
interoperable
when I remove the module and compile just the function it compiles fine. info_t
is interoperable with C
MODULE liter_cb_mod
USE ISO_C_BINDING
CONTAINS
FUNCTION liter_cb(link_info) bind(C)
USE ISO_C_BINDING
IMPLICIT NONE
INTEGER(c_int) liter_cb
TYPE, bind(C) :: info_t
INTEGER(c_int) :: type
END TYPE info_t
TYPE(info_t) :: link_info
liter_cb = 0
END FUNCTION liter_cb
END MODULE liter_cb_mod
--
Summary: C interoperable error when compiling BIND(C) function in
a module.
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brtnfld at hdfgroup dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45211
[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 #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/36771] Non-Standard addition for C_LOC and character strings
--- Comment #4 from brtnfld at hdfgroup dot org 2008-12-15 16:52 --- > > In any case: I tried ifort, g95, NAG f95, gfortran, and sunf95 - of these only > "ifort" allows it (even with all checking enabled - thus presumably only by > accident and not on purpose). > > Thus I wonder whether simply using the following "evil" workaround is better > than patching the compiler: > > f_ptr = C_LOC(X(1:1)) > > That works with gfortran, ifort, g95 and NAG f95. (It fails with sunf95, whose > C interoperability is a bit shaky in general.) As the string should be > contiguous in memory it should be the OK. Additionally, that is also what one > would do in C: > > char X[40]; > ptr = &X; // or equivalently: ptr = &X[0]; as you said using C_LOC(X(1:1)) works fine and that is what I ended up doing. BTW, ifort 11 and pgf90 7.2-1 also allow C_LOC(X). But, while using X(1:1) works fine in general, if I try to use it in a derived type gfortan (all versions) it fails to compile with an internal error, Internal Error at (1): Unexpected expression reference type in gfc_iso_c_func_interface for example: MODULE modtest USE ISO_C_BINDING TYPE test CHARACTER(LEN=2), DIMENSION(1:2) :: c INTEGER(C_INT) :: i END TYPE test END MODULE modtest PROGRAM main USE ISO_C_BINDING USE modtest TYPE(test), TARGET :: chrScalar TYPE(C_PTR) :: f_ptr f_ptr = c_loc(chrScalar%c(1)(1:1)) END PROGRAM main g95, ifort, and pgf90 all compile it. But this is maybe a separate issue. Since there is a work around (in most cases) and according to the standard a character must be length = 1 for X, I'm willing to withdrawal the request for the enhancement. As for the issue with the generic interface; none of the compilers can compile the code so generic resolution does not seem to have been extended to allow this behavior and it seems the requirement of matching Type, Kind and Rank trumps all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36771
[Bug fortran/38171] New: equivalence and nested modules broken
The following code worked for version 4.3 and 4.4 as of 9-28: MODULE HDF5 USE H5GLOBAL END MODULE HDF5 MODULE H5GLOBAL IMPLICIT NONE INTEGER :: H5P_flags INTEGER :: H5P_DEFAULT_F EQUIVALENCE(H5P_flags, H5P_DEFAULT_F) END MODULE H5GLOBAL PROGRAM fortranlibtest USE HDF5 IMPLICIT NONE INTEGER :: ii ii = H5P_DEFAULT_F END PROGRAM fortranlibtest The current version of 4.4 and 4.3 (Nov. 11) fails to compile the code with the error: gfortran43 H5f90global.o HDF5.o fortranlib_test.o -o test fortranlib_test.o(.text+0x19): In function `MAIN__': : undefined reference to `__h5global_MOD_h5p_default_f' collect2: ld returned 1 exit status *** Error code 1 4.2 compiles the code without a problem. NOTE: (1) If I remove the line EQUIVALENCE(H5P_flags, H5P_DEFAULT_F) it compiles fine. (2) If I move the contents of H5GLOBAL into the HDF5 module i.e. MODULE HDF5 IMPLICIT NONE INTEGER :: H5P_flags INTEGER :: H5P_DEFAULT_F EQUIVALENCE(H5P_flags, H5P_DEFAULT_F) END MODULE HDF5 it compiles fine. -- Summary: equivalence and nested modules broken Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brtnfld at hdfgroup dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38171
[Bug fortran/37498] Incorrect array value returned
--- Comment #5 from brtnfld at hdfgroup dot org 2008-09-12 19:38 --- (In reply to comment #3) > This may be due to an incompatibility between the 4.3 > and 4.4 libraries. > > What result do you get when you compile with "-static", > to make sure that you get the right library? > That fixed the problem, my mistake. Thanks for pointing that out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
[Bug fortran/37498] New: Incorrect array value returned
GNU Fortran (GCC) 4.3.3 20080904 (prerelease) FreeBSD 6.3-STABLE FreeBSD 6.3-STABLE, amd64 Given the program: ROGRAM test_kind IMPLICIT NONE INTEGER :: i, j INTEGER, DIMENSION(1:3) :: kind_numbers kind_numbers(1:3) = 3 DO i = 1, 3 j = kind_numbers(i) PRINT*,i,j ENDDO END PROGRAM test_kind gfortran43 gives: %a.out 1 3 2 0 3 3 gfortran44 and gfortran42 give the correct value of kind_numbers(2)=3 -- Summary: Incorrect array value returned Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brtnfld at hdfgroup dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
[Bug fortran/36771] Non-Standard addition for C_LOC and character strings
--- Comment #1 from brtnfld at hdfgroup dot org 2008-07-14 20:45 --- For the simple program, PROGRAM main USE ISO_C_BINDING CHARACTER(LEN=2, KIND=C_CHAR), TARGET :: chr TYPE(C_PTR) :: chr_ptr chr_ptr = C_LOC(chr) END PROGRAM main the work around is to: CHARACTER(LEN=1, KIND=C_CHAR), dimension(1:2), TARGET :: chr However, forcing it to be an array instead of a character(LEN>1) causes problems with generic interfaces. Take for example the following code which to me looks to be standard compliant, via the standard the CHARACTER(LEN=4) actual argument is allowed to match a CHARACTER(LEN=1,KIND=C_CHAR), DIMENSION(4) dummy argument (12.4.1.2). But the compiler will not recognize subroutine 'Two' as a valid interface for the call indicated since the dimensions check is not satisfied even though it is a valid interface. So if you are going by the standard you can not use a generic interface to handle a scalar character (len>1) and an array of characters (keeping in mind that all the subroutines have to have LEN=1 so that you can use C_LOC). MODULE modtest USE ISO_C_BINDING INTERFACE One MODULE PROCEDURE Two END INTERFACE CONTAINS SUBROUTINE Two( chr ) CHARACTER(LEN=1, KIND=C_CHAR), DIMENSION(1:4) :: chr END SUBROUTINE Two END MODULE modtest PROGRAM main USE ISO_C_BINDING USE modtest CHARACTER(LEN=4, KIND=C_CHAR) :: chrScalar chrScalar = 'Scal' ! This does not work, it will not find the interface. CALL One( chrScalar ) ! This works CALL Two( chrScalar ) END PROGRAM main It is simply not feasible to cast all character strings into character arrays. This problem would all go away if we did not have to recast the string as an array. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36771
[Bug fortran/36771] New: Non-Standard addition for C_LOC and character strings
Would it be possible to implement the non-standard extension for a character argument X in C_LOC(X) to have a LEN >1. Most if not all the current Fortran compilers provide this extension and I think it would be useful for other users of gfortran as well. The feature would allow: CHARACTER(LEN=80, KIND=C_CHAR), TARGET :: X f_ptr = C_LOC(X) or for an assumed size character in a subroutine: CHARACTER(LEN=*, KIND=C_CHAR), TARGET :: X f_ptr = C_LOC(X) Thanks -- Summary: Non-Standard addition for C_LOC and character strings Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brtnfld at hdfgroup dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36771
[Bug fortran/36759] C_LOC and characters greater then one in length.
--- Comment #5 from brtnfld at hdfgroup dot org 2008-07-09 14:24 --- The behavior conforms to the standard: For the C_LOC(X) function X must be interpretable and interpretable for a character the standard says: 15.2.1 Interoperability of intrinsic types A Fortran intrinsic 4 type with particular type parameter values is interoperable with a C type if the type and kind type 5 parameter value are listed in the table on the same row as that C type; if the type is character, inter 6 operability also requires that the length type parameter be omitted or be specified by an initialization 7 expression whose value is one. so it conforms to the standard by requiring CHARACTER(LEN=1, KIND=C_CHAR), TARGET :: chr(2) or CHARACTER(KIND=C_CHAR), TARGET :: chr(2) -- brtnfld at hdfgroup dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36759
[Bug fortran/36759] C_LOC and characters greater then one in length.
--- Comment #4 from brtnfld at hdfgroup dot org 2008-07-08 18:40 --- Subject: Re: C_LOC and characters greater then one in length. I reported it to intel , their flag (-e03) used for checking for non-standard Fortran 2003 features missed it. pgi compiler with -Mstandard also missed it. g95 does not check for non-standard Fortran. I guess the conclusion is that it is not a bug in gfortran. kargl at gcc dot gnu dot org wrote: > --- Comment #3 from kargl at gcc dot gnu dot org 2008-07-08 18:27 --- > (In reply to comment #2) > >> Subject: Re: C_LOC and characters greater then one in >> length. >> >> My mistake, I did not see that in the standard. >> >> It still would be nice however to have the non-standard feature for >> characters of LEN > 1. >> >> > > It also may be appropriate to report this bug to the vendors you cited > as proof that gfortran had a bug. > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36759
[Bug fortran/36759] C_LOC and characters greater then one in length.
--- Comment #2 from brtnfld at hdfgroup dot org 2008-07-08 17:43 --- Subject: Re: C_LOC and characters greater then one in length. My mistake, I did not see that in the standard. It still would be nice however to have the non-standard feature for characters of LEN > 1. burnus at gcc dot gnu dot org wrote: > --- Comment #1 from burnus at gcc dot gnu dot org 2008-07-07 22:41 > --- > >> A = c_loc(arg1) >>1 >> Error: CHARACTER argument 'arg1' to 'c_loc' at (1) must have a length of 1 >> >> I'm not sure where this restriction comes from (it's not part of the >> standard). >> > > One could argue that one should allow it as vendor extension, however, the > restriction is in the standard: > > "Interoperability of intrinsic types" > "A Fortran intrinsic type with particular type parameter values is > interoperable with a C type if the type and kind type parameter value are > listed in the table on the same row as that C type; if the type is character, > interoperability also requires that the length type parameter be omitted or be > specified by an initialization expression whose value is one." > > For interoperability one thus should use instead of > character(len=2) :: str > rather > character(len=1,kind=c_char) :: str(2) > > (This is also the case for dummy arguments of BIND(C) procedures, though there > one can as pass "a string" as actual argument, cf. "storage sequence".) > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36759
[Bug fortran/36759] New: C_LOC and characters greater then one in length.
When I compile the code:
PROGRAM main
USE, INTRINSIC :: ISO_C_BINDING
IMPLICIT NONE
CHARACTER(LEN=2), TARGET :: arg1 = '12'
TYPE(c_ptr) :: A
A = c_loc(arg1)
END PROGRAM main
I get the error:
A = c_loc(arg1)
1
Error: CHARACTER argument 'arg1' to 'c_loc' at (1) must have a length of 1
I'm not sure where this restriction comes from (it's not part of the standard).
All the other fortran compilers (at least g95, ifort, and pgf90) support
character LEN >1. Actually they support CHARACTER(LEN=*) when declared in a
subroutine.
--
Summary: C_LOC and characters greater then one in length.
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brtnfld at hdfgroup dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36759
