__VFP_FP__ not defined for Cortex-M3

[Quuxplusone]

Bugzilla Link	PR39536
Status	NEW
Importance	P normal
Reported by	Jangseop Shin (jsshin@sor.snu.ac.kr)
Reported on	2018-11-02 06:17:19 -0700
Last modified on	2018-11-02 13:02:41 -0700
Version	trunk
Hardware	PC Linux
CC	efriedma@quicinc.com, llvm-bugs@lists.llvm.org, richard-llvm@metafoo.co.uk
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

arm-none-eabi-gcc defines __VFP_FP__ but clang does not define it.
This caused problem in the newlib build for ARM Cortex-M3.

Following is a code taken from newlib. Since __VFP_FP__ is not defined,
__IEEE_BIG_ENDIAN is defined instead of __IEEE_LITTLE_ENDIAN, which caused
serious problem.

The comments say that __VFP_FP__ will be defined even if soft-float, but clang
seems to only define it when VFP is actually used.

==== newlib/libc/include/machine/ieeefp.h ========

#if (defined(__arm__) || defined(__thumb__)) && !defined(__MAVERICK__)
/* ARM traditionally used big-endian words; and within those words the byte
ordering was big or little endian depending upon the target. Modern floating-
point formats are naturally ordered; in this case  __VFP_FP__ will be defined,
even if soft-float.  */
#ifdef __VFP_FP__
# ifdef __ARMEL__
#  define __IEEE_LITTLE_ENDIAN
# else
#  define __IEEE_BIG_ENDIAN
# endif
# if __ARM_FP & 0x8
#  define __OBSOLETE_MATH_DEFAULT 0
# endif
#else
# define __IEEE_BIG_ENDIAN
# ifdef __ARMEL__
#  define __IEEE_BYTES_LITTLE_ENDIAN
# endif
#endif
#endif

====================================

[Quuxplusone]

I was a little confused that we would always define VFP_FP even without an fp unit, so I did a little research. Apparently, some old ARM chips support a different floating point extension, called FPA, which uses an incompatible floating-point format. But LLVM doesn't support that, so it seems fine to define VFP_FP unconditionally.