public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/63250] New: Complex fp16 arithmetic uses nonexistent libgcc functions
@ 2014-09-12 20:42 jsm28 at gcc dot gnu.org
  2014-09-23  0:49 ` [Bug target/63250] " jsm28 at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2014-09-12 20:42 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63250

            Bug ID: 63250
           Summary: Complex fp16 arithmetic uses nonexistent libgcc
                    functions
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jsm28 at gcc dot gnu.org
            Target: arm*-*-*

If on ARM you declare complex __fp16 values using __attribute__((mode(HC)))
(because you can't use _Complex __fp16 directly, the ARM analogue of bug
32187), this is accepted, but multiplication and division of those values
produces references to libgcc functions __mulhc3 and __divhc3 that don't exist.
 E.g., compiled with -O2 -mfp16-format=ieee:

typedef _Complex float fp16c __attribute__((mode(HC)));
fp16c a, b;
fp16c f (void) { return a * b; }

Just as __fp16 values are promoted to float for arithmetic, so should complex
fp16 values probably be promoted to complex float.  (Were TS 18661-3
implemented, there would be various differences from the existing __fp16 and
__float128 support in GCC, but there would still be no need for HCmode
operations as distinct from promoting to SCmode then converting results back to
HCmode at some point, whether you define FLT_EVAL_METHOD to 32, which would be
the closest equivalent to the existing promotion, or treat the promotion as an
implementation detail and truncate after every operation.)


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug target/63250] Complex fp16 arithmetic uses nonexistent libgcc functions
  2014-09-12 20:42 [Bug target/63250] New: Complex fp16 arithmetic uses nonexistent libgcc functions jsm28 at gcc dot gnu.org
@ 2014-09-23  0:49 ` jsm28 at gcc dot gnu.org
  2015-01-16 15:58 ` ramana at gcc dot gnu.org
  2015-01-16 16:33 ` joseph at codesourcery dot com
  2 siblings, 0 replies; 4+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2014-09-23  0:49 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63250

--- Comment #1 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
Author: jsm28
Date: Tue Sep 23 00:48:46 2014
New Revision: 215491

URL: https://gcc.gnu.org/viewcvs?rev=215491&root=gcc&view=rev
Log:
Remove LIBGCC2_LONG_DOUBLE_TYPE_SIZE target macro.

This patch removes the target macro LIBGCC2_LONG_DOUBLE_TYPE_SIZE.

After recent changes, this macro was used in two ways in libgcc: to
determine the mode of long double in dfp-bit.h, and to determine
whether a particular mode has excess precision for use in complex
multiplication.

The former is concerned specifically with long double: it relates to
use of strtold for converting between decimal and binary floating
point.  This is replaced by comparing __LDBL_MANT_DIG__ with the
appropriate __LIBGCC_*_MANT_DIG__ macro.  The latter is replaced
__LIBGCC_*_EXCESS_PRECISION__ predefined macros.

Remarks:

* Comparing (__LDBL_MANT_DIG__ == __LIBGCC_XF_MANT_DIG__) is more
  fragile than it looks; it's possible for XFmode to have 53-bit
  mantissa (TARGET_96_ROUND_53_LONG_DOUBLE, on FreeBSD and
  DragonFlyBSD 32-bit), in which case such a comparison would not
  distinguish XFmode and DFmode as possible modes for long double.
  Fortunately, no target supporting that form of XFmode also supports
  long double = double (but if some target did, we'd need e.g. an
  additional macro giving the exponent range of each mode).

  Furthermore, this code doesn't actually get used for x86 (or any
  other target with XFmode support), because x86 uses BID not DPD and
  BID has its own conversion code (which handles conversions for both
  XFmode and TFmode without needing to go via strtold).  And FreeBSD
  and DragonFlyBSD aren't among the targets with DFP support.  So
  while in principle this code is fragile and it's a deficiency that
  it can't support both XFmode and TFmode at once (something that
  can't be solved with the string conversion approach without libc
  having TS 18661 functions such as strtof128), all these issues
  should not be a problem in practice.

* If other cases of excess precision are supported in future, the code
  for defining __LIBGCC_*_EXCESS_PRECISION__ may need updating.
  Although the most likely such cases might not actually involve
  excess precision for any mode used in libgcc - FLT_EVAL_METHOD being
  32 to do _Float16 arithmetic on _Float32 should have the effect of
  _Complex _Float16 arithmetic using __mulsc3 and __divsc3, rather
  than currently nonexistent __mulhc3 and __divhc3 as in bug 63250 for
  ARM.

* As has been noted in the context of simultaneous support for
  __float128 and __ibm128 on Power, the semantics of macros such as
  LONG_DOUBLE_TYPE_SIZE are problematic because they rely on a
  poorly-defined precision value for floating-point modes (which seems
  to be intended as the number of significant bits in the
  representation, e.g. 80 for XFmode which may be either 12 or 16
  bytes) uniquely identifying a mode (although defining an arbitrarily
  different value for one of the modes you wish to distinguish may
  work as a hack).  It would be cleaner to have a target hook that
  gives a machine mode directly for float, double and long double,
  rather than going via these precision values.  By eliminating all
  use of these macros (FLOAT_TYPE_SIZE, DOUBLE_TYPE_SIZE,
  LONG_DOUBLE_TYPE_SIZE) from code built for the target, this patch
  facilitates such a conversion to a hook (which I suppose would take
  some suitable enum as an argument to identify which of the three
  types to return a mode for).

  (The issue of multiple type support for DFP conversions would apply
  in that Power case.
  <https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01084.html> doesn't
  seem to touch on it, but it would seem reasonable to punt on it
  initially as hard to fix.  There would also be the issue of getting
  functions such as __powikf2, __mulkc3, __divkc3 defined, but that's
  rather easier to address.)

Bootstrapped with no regressions on x86_64-unknown-linux-gnu.

gcc:
    * doc/tm.texi.in (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    * doc/tm.texi: Regenerate.
    * system.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Poison.
    * config/alpha/alpha.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    * config/i386/i386-interix.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE):
    Remove.
    * config/i386/i386.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    * config/i386/rtemself.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    * config/ia64/ia64.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    * config/m68k/m68k.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    * config/m68k/netbsd-elf.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE):
    Remove.
    * config/mips/mips.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    * config/mips/n32-elf.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    * config/msp430/msp430.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    * config/rl78/rl78.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    * config/rs6000/rs6000.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    * config/rx/rx.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    * config/s390/s390.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    * config/sparc/freebsd.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    * config/sparc/linux.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    * config/sparc/linux64.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    * config/sparc/netbsd-elf.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE):
    Remove.

gcc/c-family:
    * c-cppbuiltin.c (c_cpp_builtins): Define
    __LIBGCC_*_EXCESS_PRECISION__ macros for supported floating-point
    modes.

libgcc:
    * dfp-bit.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.
    (__LIBGCC_XF_MANT_DIG__): Define if not already defined.
    (LONG_DOUBLE_HAS_XF_MODE): Define in terms of
    __LIBGCC_XF_MANT_DIG__.
    (__LIBGCC_TF_MANT_DIG__): Define if not already defined.
    (LONG_DOUBLE_HAS_TF_MODE): Define in terms of
    __LIBGCC_TF_MANT_DIG__.
    * libgcc2.c (NOTRUNC): Define in terms of
    __LIBGCC_*_EXCESS_PRECISION__, not LIBGCC2_LONG_DOUBLE_TYPE_SIZE.
    * libgcc2.h (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Remove.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-cppbuiltin.c
    trunk/gcc/config/alpha/alpha.h
    trunk/gcc/config/i386/i386-interix.h
    trunk/gcc/config/i386/i386.h
    trunk/gcc/config/i386/rtemself.h
    trunk/gcc/config/ia64/ia64.h
    trunk/gcc/config/m68k/m68k.h
    trunk/gcc/config/m68k/netbsd-elf.h
    trunk/gcc/config/mips/mips.h
    trunk/gcc/config/mips/n32-elf.h
    trunk/gcc/config/msp430/msp430.h
    trunk/gcc/config/rl78/rl78.h
    trunk/gcc/config/rs6000/rs6000.h
    trunk/gcc/config/rx/rx.h
    trunk/gcc/config/s390/s390.h
    trunk/gcc/config/sparc/freebsd.h
    trunk/gcc/config/sparc/linux.h
    trunk/gcc/config/sparc/linux64.h
    trunk/gcc/config/sparc/netbsd-elf.h
    trunk/gcc/doc/tm.texi
    trunk/gcc/doc/tm.texi.in
    trunk/gcc/system.h
    trunk/libgcc/ChangeLog
    trunk/libgcc/dfp-bit.h
    trunk/libgcc/libgcc2.c
    trunk/libgcc/libgcc2.h


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug target/63250] Complex fp16 arithmetic uses nonexistent libgcc functions
  2014-09-12 20:42 [Bug target/63250] New: Complex fp16 arithmetic uses nonexistent libgcc functions jsm28 at gcc dot gnu.org
  2014-09-23  0:49 ` [Bug target/63250] " jsm28 at gcc dot gnu.org
@ 2015-01-16 15:58 ` ramana at gcc dot gnu.org
  2015-01-16 16:33 ` joseph at codesourcery dot com
  2 siblings, 0 replies; 4+ messages in thread
From: ramana at gcc dot gnu.org @ 2015-01-16 15:58 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63250

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-16
                 CC|                            |ramana at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Joseph S. Myers from comment #1)
> Author: jsm28
> Date: Tue Sep 23 00:48:46 2014
> New Revision: 215491
> 
> URL: https://gcc.gnu.org/viewcvs?rev=215491&root=gcc&view=rev
> Log:
> Remove LIBGCC2_LONG_DOUBLE_TYPE_SIZE target macro.
> 
> This patch removes the target macro LIBGCC2_LONG_DOUBLE_TYPE_SIZE.

Joseph, how does this patch go towards "fixing" this issue as it doesn't even
touch the ARM backend ?


Confirming the bug though as I do see the calls to __mulhc3 as expected even
today on trunk.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug target/63250] Complex fp16 arithmetic uses nonexistent libgcc functions
  2014-09-12 20:42 [Bug target/63250] New: Complex fp16 arithmetic uses nonexistent libgcc functions jsm28 at gcc dot gnu.org
  2014-09-23  0:49 ` [Bug target/63250] " jsm28 at gcc dot gnu.org
  2015-01-16 15:58 ` ramana at gcc dot gnu.org
@ 2015-01-16 16:33 ` joseph at codesourcery dot com
  2 siblings, 0 replies; 4+ messages in thread
From: joseph at codesourcery dot com @ 2015-01-16 16:33 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63250

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 16 Jan 2015, ramana at gcc dot gnu.org wrote:

> > Remove LIBGCC2_LONG_DOUBLE_TYPE_SIZE target macro.
> > 
> > This patch removes the target macro LIBGCC2_LONG_DOUBLE_TYPE_SIZE.
> 
> Joseph, how does this patch go towards "fixing" this issue as it doesn't even
> touch the ARM backend ?

The patch *references* this issue in the write-up (I now use git-style 
commit messages with a summary line and full patch write-up as sent to 
gcc-patches, rather than just the ChangeLog entries):

* If other cases of excess precision are supported in future, the code
  for defining __LIBGCC_*_EXCESS_PRECISION__ may need updating.
  Although the most likely such cases might not actually involve
  excess precision for any mode used in libgcc - FLT_EVAL_METHOD being
  32 to do _Float16 arithmetic on _Float32 should have the effect of
  _Complex _Float16 arithmetic using __mulsc3 and __divsc3, rather
  than currently nonexistent __mulhc3 and __divhc3 as in bug 63250 for
  ARM.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-01-16 16:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-12 20:42 [Bug target/63250] New: Complex fp16 arithmetic uses nonexistent libgcc functions jsm28 at gcc dot gnu.org
2014-09-23  0:49 ` [Bug target/63250] " jsm28 at gcc dot gnu.org
2015-01-16 15:58 ` ramana at gcc dot gnu.org
2015-01-16 16:33 ` joseph at codesourcery dot com

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