[Bug fortran/100917] New: Bind(c): errors handling long double real

[Bug fortran/100917] New: Bind(c): errors handling long double real

[jrfsousa at gcc dot gnu.org]

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

[Bug fortran/100917] Bind(c): errors handling long double real

[jrfsousa at gcc dot gnu.org]

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)

[Bug fortran/100917] Bind(c): errors handling long double real

[jrfsousa at gcc dot gnu.org]

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

[Bug fortran/100917] Bind(c): errors handling long double real

[jrfsousa at gcc dot gnu.org]

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

[Bug fortran/100917] Bind(c): errors handling long double real

[sandra at gcc dot gnu.org]

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).

[Bug fortran/100917] Bind(c): errors handling long double real

[sandra at gcc dot gnu.org]

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.

[Bug fortran/100917] Bind(c): errors handling long double real

[sandra at gcc dot gnu.org]

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.

[Bug fortran/100917] Bind(c): errors handling long double real

[cvs-commit at gcc dot gnu.org]

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.

[Bug fortran/100917] Bind(c): errors handling long double real

[sandra at gcc dot gnu.org]

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.

[Bug fortran/100917] Bind(c): errors handling long double real

[sandra at gcc dot gnu.org]

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.