[Bug target/63250] Complex fp16 arithmetic uses nonexistent libgcc functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63250 James Greenhalgh changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from James Greenhalgh --- This should have been fixed by my work last year, I think.
[Bug target/63250] Complex fp16 arithmetic uses nonexistent libgcc functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63250 --- Comment #5 from James Greenhalgh --- Author: jgreenhalgh Date: Wed Nov 23 17:36:21 2016 New Revision: 242784 URL: https://gcc.gnu.org/viewcvs?rev=242784=gcc=rev Log: [Patch ARM 17/17] Enable _Float16 for ARM and fix PR target/63250 gcc/ PR target/63250 * config/arm/arm-builtins.c (arm_simd_floatHF_type_node): Rename to... (arm_fp16_type_node): ...This, make visibile. (arm_simd_builtin_std_type): Rename arm_simd_floatHF_type_node to arm_fp16_type_node. (arm_init_simd_builtin_types): Likewise. (arm_init_fp16_builtins): Likewise. * config/arm/arm.c (arm_excess_precision): New. (arm_floatn_mode): Likewise. (TARGET_C_EXCESS_PRECISION): Likewise. (TARGET_FLOATN_MODE): Likewise. (arm_promoted_type): Only promote arm_fp16_type_node. * config/arm/arm.h (arm_fp16_type_node): Declare. gcc/testsuite/ PR target/63250 * lib/target-supports.exp (add_options_for_float16): Add -mfp16-format=ieee when testign arm*-*-*. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-builtins.c trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp
[Bug target/63250] Complex fp16 arithmetic uses nonexistent libgcc functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63250 --- Comment #4 from James Greenhalgh --- Author: jgreenhalgh Date: Fri Sep 9 09:40:22 2016 New Revision: 240043 URL: https://gcc.gnu.org/viewcvs?rev=240043=gcc=rev Log: [Patch libgcc] Enable HCmode multiply and divide (mulhc3/divhc3) This patch arranges for half-precision complex multiply and divide routines to be built if __LIBGCC_HAS_HF_MODE__. This will be true if the target supports the _Float16 type. libgcc/ PR target/63250 * Makefile.in (lib2funcs): Build _mulhc3 and _divhc3. * libgcc2.h (LIBGCC_HAS_HF_MODE): Conditionally define. (HFtype): Likewise. (HCtype): Likewise. (__divhc3): Likewise. (__mulhc3): Likewise. * libgcc2.c: Support _mulhc3 and _divhc3. Modified: trunk/libgcc/ChangeLog trunk/libgcc/Makefile.in trunk/libgcc/libgcc2.c trunk/libgcc/libgcc2.h
[Bug target/63250] Complex fp16 arithmetic uses nonexistent libgcc functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63250 James Greenhalgh changed: What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2015-01-16 00:00:00 |2016-8-5 Assignee|unassigned at gcc dot gnu.org |jgreenhalgh at gcc dot gnu.org
[Bug target/63250] Complex fp16 arithmetic uses nonexistent libgcc functions
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=215491root=gccview=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.
[Bug target/63250] Complex fp16 arithmetic uses nonexistent libgcc functions
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.
[Bug target/63250] Complex fp16 arithmetic uses nonexistent libgcc functions
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=215491root=gccview=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
