[llvm-bugs] [Bug 46294] New: compiler-rt soft float support guarded by the wrong macro ( __SOFT_FP__ instead of __SOFTFP__)

[via llvm-bugs]

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

            Bug ID: 46294
           Summary: compiler-rt soft float support guarded by the wrong
                    macro ( __SOFT_FP__ instead of __SOFTFP__)
           Product: compiler-rt
           Version: 10.0
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: builtins
          Assignee: unassignedbugs at nondot.org
          Reporter: salim.nasser at windriver.com
                CC: llvm-bugs at lists.llvm.org

A handful of files in compiler-rt/builtins use the macro “__SOFT_FP__”. All the
uses are along the same lines. Here’s a representative example from
compiler-rt/lib/builtins/fixdfdi.c:

#ifndef __SOFT_FP__
// Support for systems that have hardware floating-point; can set the invalid
// flag as a side-effect of computation.
…
#else
// Support for systems that don't have hardware floating-point; there are no
// flags to set, and we don't want to code-gen to an unknown soft-float
// implementation.
…
#endif

The expectation seems to be that code guarded by #ifdef __SOFT_FP__ will be
used in soft float configurations.

However: __SOFT_FP__ is never set by the compiler (neither clang nor GCC). 

Nor (as far as I can tell) does it appear in any compiler-rt header file, build
script, or Makefile. In fact the only occurrences of this macro anywhere in the
llvm-project and GCC source trees are the aforementioned uses under
compiler-rt/builtins.

On the other hand both clang and GCC *do* set an alarmingly similar looking
macro - “__SOFTFP__” (no middle underscore) -  when compiling for soft-float.

So it appears that compiler-rt is using the wrong macro. Presumably this also
means that the "soft float" code has not actually been tested, since that code
path has never been enabled.

-- 
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/20200612/6227f3f4/attachment.html>