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