llvm dev - Jun 2020 - compiler-rt uses non-existent macro: __SOFT_FP__

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

My question is : when - if ever - should __SOFT_FP__ be defined?

The obvious answer is "when compiling for a soft-float target".

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.

Since we need to build compiler-rt libraries for a couple of our soft-float
targets at Wind River, we want to make sure we're building them in the
"right" way. Currently we do *not* define __SOFT_FP__ for soft-float
targets (and our tests pass!).

Regards,
Salim

Salim Nasser | Compilers | Wind River


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200609/abcd744d/attachment.html>

+Renato Golin <renato.golin at linaro.org>

On Mon, Jun 8, 2020 at 5:21 PM Nasser, Salim via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>
>
>
> My question is : when - if ever - should __SOFT_FP__ be defined?
>
>
>
> The obvious answer is “when compiling for a soft-float target”.
>
>
>
> 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.
>
>
>
> Since we need to build compiler-rt libraries for a couple of our
> soft-float targets at Wind River, we want to make sure we’re building them
> in the “right” way. Currently we do **not** define __SOFT_FP__ for
> soft-float targets (and our tests pass!).
>
>
>
I believe that this is an accidental misspelling and went unnoticed.  This
should be `__SOFTFP__` instead.

> Regards,
> Salim
>
>
>
> Salim Nasser | Compilers | Wind River
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200608/05da62c7/attachment.html>

>  I believe that this is an accidental misspelling and went unnoticed.  This
should be `__SOFTFP__` instead.
Thanks Saleem. I’ve filed the following PR:

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

Regards,
Salim.

From: Saleem Abdulrasool <compnerd at compnerd.org>
Sent: Monday, June 8, 2020 7:10 PM
To: Nasser, Salim <salim.nasser at windriver.com>; rengolin at gmail.com
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] compiler-rt uses non-existent macro: __SOFT_FP__

+Renato Golin<mailto:renato.golin at linaro.org>

On Mon, Jun 8, 2020 at 5:21 PM Nasser, Salim via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
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

My question is : when - if ever - should __SOFT_FP__ be defined?

The obvious answer is “when compiling for a soft-float target”.

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.

Since we need to build compiler-rt libraries for a couple of our soft-float
targets at Wind River, we want to make sure we’re building them in the “right”
way. Currently we do *not* define __SOFT_FP__ for soft-float targets (and our
tests pass!).


I believe that this is an accidental misspelling and went unnoticed.  This
should be `__SOFTFP__` instead.

Regards,
Salim

Salim Nasser | Compilers | Wind River


_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200612/cbe07b54/attachment.html>