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