https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861
Scot Breitenfeld changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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
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
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
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=edit
Fortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99982
--- Comment #9 from Scot Breitenfeld ---
This is Great! Thank-you.
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.
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100149
Scot Breitenfeld changed:
What|Removed |Added
Known to work||10.3.0
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;
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.
: 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=edit
The program has two lines of do
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=edit
program uses interface and mod
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=36035action=edit
H5Tff.F90 -- contains the module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973
--- Comment #4 from Scot Breitenfeld brtnfld at hdfgroup dot org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973
--- Comment #1 from Scot Breitenfeld brtnfld at hdfgroup dot org ---
Created attachment 36036
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36036action=edit
fortranlib_test_F03, main program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973
--- Comment #2 from Scot Breitenfeld brtnfld at hdfgroup dot org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973
--- Comment #3 from Scot Breitenfeld brtnfld at hdfgroup dot org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973
--- Comment #6 from Scot Breitenfeld brtnfld at hdfgroup dot org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55891
Scot Breitenfeld brtnfld at hdfgroup dot org changed:
What|Removed |Added
Status|UNCONFIRMED
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48404
--- Comment #7 from Scot Breitenfeld brtnfld at hdfgroup dot org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48404
Scot Breitenfeld brtnfld at hdfgroup dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48404
--- Comment #2 from Scot Breitenfeld brtnfld at hdfgroup dot org 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
--- 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
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
--- 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
--- 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
--- 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
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
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
--- 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
--- 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
--- 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
: 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
--- 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
--- 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
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
39 matches
Mail list logo
