public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug fortran/64416] New: RFE: Support REAL128 on arm @ 2014-12-26 23:25 orion at cora dot nwra.com 2014-12-30 21:20 ` [Bug fortran/64416] " joseph at codesourcery dot com 2015-01-15 14:34 ` rearnsha at gcc dot gnu.org 0 siblings, 2 replies; 3+ messages in thread From: orion at cora dot nwra.com @ 2014-12-26 23:25 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64416 Bug ID: 64416 Summary: RFE: Support REAL128 on arm Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: orion at cora dot nwra.com SUBROUTINE PMPI_Sizeof_complex128_scalar(x, size, ierror) USE, INTRINSIC :: iso_fortran_env, ONLY: REAL128 COMPLEX(REAL128)::x INTEGER, INTENT(OUT) :: size INTEGER, INTENT(OUT) :: ierror size = storage_size(x) / 8 ierror = 0 END SUBROUTINE PMPI_Sizeof_complex128_scalar gfortran -c psizeof_f.f90 psizeof_f.f90:3.21: COMPLEX(REAL128)::x 1 Error: Kind -1 not supported for type COMPLEX at (1) Linux fedora-rawhide-arm 3.18.1-2.fc22.armv7hl+lpae #1 SMP Fri Dec 19 00:19:30 UTC 2014 armv7l armv7l armv7l GNU/Linux Is it possible to add support for this, or can the architecture not handle it? ^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug fortran/64416] RFE: Support REAL128 on arm 2014-12-26 23:25 [Bug fortran/64416] New: RFE: Support REAL128 on arm orion at cora dot nwra.com @ 2014-12-30 21:20 ` joseph at codesourcery dot com 2015-01-15 14:34 ` rearnsha at gcc dot gnu.org 1 sibling, 0 replies; 3+ messages in thread From: joseph at codesourcery dot com @ 2014-12-30 21:20 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64416 --- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- The Procedure Call Standard for the ARM Architecture does not include a 128-bit floating-point type, so if you want to support such a type in GCC for ARM you should first work with arm.eabi@arm.com to define the associated ABI and get a new version of AAPCS released. Or you could use AArch64 - AAPCS64 does include such a type. ^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug fortran/64416] RFE: Support REAL128 on arm 2014-12-26 23:25 [Bug fortran/64416] New: RFE: Support REAL128 on arm orion at cora dot nwra.com 2014-12-30 21:20 ` [Bug fortran/64416] " joseph at codesourcery dot com @ 2015-01-15 14:34 ` rearnsha at gcc dot gnu.org 1 sibling, 0 replies; 3+ messages in thread From: rearnsha at gcc dot gnu.org @ 2015-01-15 14:34 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64416 Richard Earnshaw <rearnsha at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |EH Target| |arm Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Richard Earnshaw <rearnsha at gcc dot gnu.org> --- I suspect it's unlikely the EABI will be expanded in this direction; at least until (unless) these types get implemented in hardware. Furthermore, there's a high chance that if HW did implement 128-bit types, it would be done in a way that was incompatible with any design choices we made now, rendering a necessary ABI break or significant performance penalty. My inclination is to close this as 'WONTFIX', with the understanding that if a new ABI with such an extension does appear, support for it would be an automatic step to implementing that ABI revision. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-01-15 14:34 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-12-26 23:25 [Bug fortran/64416] New: RFE: Support REAL128 on arm orion at cora dot nwra.com 2014-12-30 21:20 ` [Bug fortran/64416] " joseph at codesourcery dot com 2015-01-15 14:34 ` rearnsha 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).