public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/100917] New: Bind(c): errors handling long double real
@ 2021-06-04 20:05 jrfsousa at gcc dot gnu.org
2021-06-04 20:05 ` [Bug fortran/100917] " jrfsousa at gcc dot gnu.org
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: jrfsousa at gcc dot gnu.org @ 2021-06-04 20:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917
Bug ID: 100917
Summary: Bind(c): errors handling long double real
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jrfsousa at gcc dot gnu.org
Target Milestone: ---
Created attachment 50945
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50945&action=edit
Fortran code showing problem
Hi All!
Wrong type and kind on handling long double real. Since kind is not related to
elem_len there seems to be no way to infer it.
Seen on:
GNU Fortran (GCC) 10.3.1 20210526
GNU Fortran (GCC) 11.1.1 20210526
GNU Fortran (GCC) 12.0.0 20210529 (experimental)
Thank you very much.
Best regards,
José Rui
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/100917] Bind(c): errors handling long double real
2021-06-04 20:05 [Bug fortran/100917] New: Bind(c): errors handling long double real jrfsousa at gcc dot gnu.org
@ 2021-06-04 20:05 ` jrfsousa at gcc dot gnu.org
2021-06-13 18:41 ` jrfsousa at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jrfsousa at gcc dot gnu.org @ 2021-06-04 20:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917
--- Comment #1 from José Rui Faustino de Sousa <jrfsousa at gcc dot gnu.org> ---
Created attachment 50946
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50946&action=edit
C code for bind(c)
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/100917] Bind(c): errors handling long double real
2021-06-04 20:05 [Bug fortran/100917] New: Bind(c): errors handling long double real jrfsousa at gcc dot gnu.org
2021-06-04 20:05 ` [Bug fortran/100917] " jrfsousa at gcc dot gnu.org
@ 2021-06-13 18:41 ` jrfsousa at gcc dot gnu.org
2021-06-13 18:42 ` jrfsousa at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jrfsousa at gcc dot gnu.org @ 2021-06-13 18:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917
--- Comment #2 from José Rui Faustino de Sousa <jrfsousa at gcc dot gnu.org> ---
Patch posted:
https://gcc.gnu.org/pipermail/fortran/2021-June/056154.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/100917] Bind(c): errors handling long double real
2021-06-04 20:05 [Bug fortran/100917] New: Bind(c): errors handling long double real jrfsousa at gcc dot gnu.org
2021-06-04 20:05 ` [Bug fortran/100917] " jrfsousa at gcc dot gnu.org
2021-06-13 18:41 ` jrfsousa at gcc dot gnu.org
@ 2021-06-13 18:42 ` jrfsousa at gcc dot gnu.org
2021-06-26 23:35 ` sandra at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jrfsousa at gcc dot gnu.org @ 2021-06-13 18:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917
--- Comment #3 from José Rui Faustino de Sousa <jrfsousa at gcc dot gnu.org> ---
Please ignore patch wrong PR...
Sorry for the inconvenience.
Best regards,
José Rui
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/100917] Bind(c): errors handling long double real
2021-06-04 20:05 [Bug fortran/100917] New: Bind(c): errors handling long double real jrfsousa at gcc dot gnu.org
` (2 preceding siblings ...)
2021-06-13 18:42 ` jrfsousa at gcc dot gnu.org
@ 2021-06-26 23:35 ` sandra at gcc dot gnu.org
2021-06-29 3:35 ` sandra at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: sandra at gcc dot gnu.org @ 2021-06-26 23:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917
sandra at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sandra at gcc dot gnu.org
--- Comment #4 from sandra at gcc dot gnu.org ---
I've observed this bug in my own testing as well, and traced it to the same
cause: the GFC descriptor structure doesn't encode the kind, only the
elem_len, so the runtime can't convert it to a valid C descriptor.
IIUC the GFC descriptor needs to encode the kind to support assumed-type
arguments in functions that are not declared bind(c) (for example, a subroutine
with Fortran binding that acts as a wrapper around a C function). I imagine
any proper fix for this would involve an ABI change affecting programs that
don't even use bind(c).
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/100917] Bind(c): errors handling long double real
2021-06-04 20:05 [Bug fortran/100917] New: Bind(c): errors handling long double real jrfsousa at gcc dot gnu.org
` (3 preceding siblings ...)
2021-06-26 23:35 ` sandra at gcc dot gnu.org
@ 2021-06-29 3:35 ` sandra at gcc dot gnu.org
2021-07-11 20:55 ` sandra at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: sandra at gcc dot gnu.org @ 2021-06-29 3:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917
--- Comment #5 from sandra at gcc dot gnu.org ---
Here's a related problem: the GFC descriptor representation can't distinguish
between
CHARACTER(kind=ucs4, len=1)
and
CHARACTER(kind=c_char, len=4)
because all it has is elem_len == 4.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/100917] Bind(c): errors handling long double real
2021-06-04 20:05 [Bug fortran/100917] New: Bind(c): errors handling long double real jrfsousa at gcc dot gnu.org
` (4 preceding siblings ...)
2021-06-29 3:35 ` sandra at gcc dot gnu.org
@ 2021-07-11 20:55 ` sandra at gcc dot gnu.org
2021-09-02 23:42 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: sandra at gcc dot gnu.org @ 2021-07-11 20:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917
--- Comment #6 from sandra at gcc dot gnu.org ---
I've been thinking some more about this issue. It seems to me that a "proper"
solution is either (1) Add a kind field to the GFC descriptor or (2) Do away
with GFC descriptors and use the C descriptor layout and encodings everywhere.
Both of these break ABI. (2) is more work to implement but more maintainable
long term, also more efficient at runtime.
To be more specific about the problem here.... on x86 targets, real(kind=10)
in Fortran or long double in C is an 80-bit representation. On 32-bit
processors it has size 12 but on 64-bit processors it needs to be padded to 16
bytes. Thus, if we only have elem_len=16 in the descriptor, we can't tell if
it is the 80-bit representation or the true 128-bit _float128 representation
when that is also available.
For a workaround that does not change the ABI, the best ideas I've had are
either mapping CFI_type_long_double and CFI_type_float128 to the same value on
targets where the two types both have size 16, or one of them to a negative
value to indicate it's not interoperable on that target. In practice it's
probably rare for user code to have to use the typecode to distinguish between
floating-point formats -- you define your C function to accept the type of
arguments you intend to pass into it.
Anyway, a workaround for the floating-point stuff still leaves the character
size vs character length problem unaccounted for.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/100917] Bind(c): errors handling long double real
2021-06-04 20:05 [Bug fortran/100917] New: Bind(c): errors handling long double real jrfsousa at gcc dot gnu.org
` (5 preceding siblings ...)
2021-07-11 20:55 ` sandra at gcc dot gnu.org
@ 2021-09-02 23:42 ` cvs-commit at gcc dot gnu.org
2021-09-03 0:04 ` sandra at gcc dot gnu.org
2021-10-22 16:33 ` sandra at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-09-02 23:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Sandra Loosemore <sandra@gcc.gnu.org>:
https://gcc.gnu.org/g:93b6b2f614eb692d1d8126ec6cb946984a9d01d7
commit r12-3321-g93b6b2f614eb692d1d8126ec6cb946984a9d01d7
Author: Sandra Loosemore <sandra@codesourcery.com>
Date: Wed Aug 18 07:22:03 2021 -0700
libgfortran: Further fixes for GFC/CFI descriptor conversions.
This patch is for:
PR100907 - Bind(c): failure handling wide character
PR100911 - Bind(c): failure handling C_PTR
PR100914 - Bind(c): errors handling complex
PR100915 - Bind(c): failure handling C_FUNPTR
PR100917 - Bind(c): errors handling long double real
All of these problems are related to the GFC descriptors constructed
by the Fortran front end containing ambigous or incomplete
information. This patch does not attempt to change the GFC data
structure or the front end, and only makes the runtime interpret it in
more reasonable ways. It's not a complete fix for any of the listed
issues.
The Fortran front end does not distinguish between C_PTR and
C_FUNPTR, mapping both onto BT_VOID. That is what this patch does also.
The other bugs are related to GFC descriptors only containing elem_len
and not kind. For complex types, the elem_len needs to be divided by
2 and then mapped onto a real kind. On x86 targets, the kind
corresponding to C long double is different than its elem_len; since
we cannot accurately disambiguate between a 16-byte kind 10 long
double from __float128, this patch arbitrarily prefers to interpret that as
the standard long double type rather than the GNU extension.
Similarly, for character types, the GFC descriptor cannot distinguish
between character(kind=c_char, len=4) and character(kind=ucs4, len=1).
But since the front end currently rejects anything other than len=1
(PR92482) this patch uses the latter interpretation.
2021-09-01 Sandra Loosemore <sandra@codesourcery.com>
José Rui Faustino de Sousa <jrfsousa@gmail.com>
gcc/testsuite/
PR fortran/100911
PR fortran/100915
PR fortran/100916
* gfortran.dg/PR100911.c: New file.
* gfortran.dg/PR100911.f90: New file.
* gfortran.dg/PR100914.c: New file.
* gfortran.dg/PR100914.f90: New file.
* gfortran.dg/PR100915.c: New file.
* gfortran.dg/PR100915.f90: New file.
libgfortran/
PR fortran/100907
PR fortran/100911
PR fortran/100914
PR fortran/100915
PR fortran/100917
* ISO_Fortran_binding-1-tmpl.h (CFI_type_cfunptr): Make equivalent
to CFI_type_cptr.
* runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc): Fix
handling of CFI_type_cptr and CFI_type_cfunptr. Additional error
checking and code cleanup.
(gfc_desc_to_cfi_desc): Likewise. Also correct kind mapping
for character, complex, and long double types.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/100917] Bind(c): errors handling long double real
2021-06-04 20:05 [Bug fortran/100917] New: Bind(c): errors handling long double real jrfsousa at gcc dot gnu.org
` (6 preceding siblings ...)
2021-09-02 23:42 ` cvs-commit at gcc dot gnu.org
@ 2021-09-03 0:04 ` sandra at gcc dot gnu.org
2021-10-22 16:33 ` sandra at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: sandra at gcc dot gnu.org @ 2021-09-03 0:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917
--- Comment #8 from sandra at gcc dot gnu.org ---
There is a workaround for this included in commit
93b6b2f614eb692d1d8126ec6cb946984a9d01d7
that doesn't fully solve the problem: when "long double" and "float128" are
different types with the same storage size (as on x86_64), it assumes that size
maps onto the standard type "long double" instead of the GNU extension type.
Tobias is presently rewriting the front-end code to build CFI descriptors
directly instead of calling a library function, so as part of that change it
should be possible to properly capture the kind of the type as well as its
size.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/100917] Bind(c): errors handling long double real
2021-06-04 20:05 [Bug fortran/100917] New: Bind(c): errors handling long double real jrfsousa at gcc dot gnu.org
` (7 preceding siblings ...)
2021-09-03 0:04 ` sandra at gcc dot gnu.org
@ 2021-10-22 16:33 ` sandra at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: sandra at gcc dot gnu.org @ 2021-10-22 16:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917
sandra at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
--- Comment #9 from sandra at gcc dot gnu.org ---
This is fully fixed now. I think the testcases in the c-interop testsuite are
adequate, so nothing more to do here.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-10-22 16:33 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-04 20:05 [Bug fortran/100917] New: Bind(c): errors handling long double real jrfsousa at gcc dot gnu.org
2021-06-04 20:05 ` [Bug fortran/100917] " jrfsousa at gcc dot gnu.org
2021-06-13 18:41 ` jrfsousa at gcc dot gnu.org
2021-06-13 18:42 ` jrfsousa at gcc dot gnu.org
2021-06-26 23:35 ` sandra at gcc dot gnu.org
2021-06-29 3:35 ` sandra at gcc dot gnu.org
2021-07-11 20:55 ` sandra at gcc dot gnu.org
2021-09-02 23:42 ` cvs-commit at gcc dot gnu.org
2021-09-03 0:04 ` sandra at gcc dot gnu.org
2021-10-22 16:33 ` sandra at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).