[llvm-bugs] [Bug 39536] New: __VFP_FP__ not defined for Cortex-M3

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=39536

            Bug ID: 39536
           Summary: __VFP_FP__ not defined for Cortex-M3
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jsshin at sor.snu.ac.kr
                CC: llvm-bugs at lists.llvm.org, richard-llvm at metafoo.co.uk

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

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20181102/04c11f1a/attachment.html>