| Issue |
170228
|
| Summary |
Regression(?): isfinite() is leaked to global namespace
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
juj
|
Previously, we have been using LLVM 15 to compile to WebAssembly via Emscripten 3.1.38.
Attempting to update to newer Emscripten 4.0.19, which carries an update to [LLVM 20.1.4 libcxx](https://github.com/emscripten-core/emscripten/pull/24346), the following code, which used to compile before with the LLVM 15 branch, no longer does:
`a.cpp`
```
#include <cmath>
// C23: isfinite() is a macro, so undef it from existence
#ifdef isfinite
#undef isfinite
#endif
namespace math {
int isfinite(float x) {
return ((unsigned int)x & 0x7F800000u) != 0x7F800000u;
}
}
using namespace math;
int main() {
isfinite(1.f);
}
```
This produces an error
```
a.cpp:16:3: error: call to 'isfinite' is ambiguous
16 | isfinite(1.f);
| ^~~~~~~~
C:\emsdk\emscripten\main\cache\sysroot/include/c++/v1\__math/traits.h:71:83: note: candidate function
71 | [[__nodiscard__]] inline _LIBCPP_CONSTEXPR_SINCE_CXX23 _LIBCPP_HIDE_FROM_ABI bool isfinite(float __x) _NOEXCEPT {
| ^
a.cpp:9:7: note: candidate function
9 | int isfinite(float x) {
| ^
1 error generated.
```
It looks like the above code stopped compiling after this commit: https://github.com/llvm/llvm-project/commit/7f2bd53b142ec147da9f8bd98775be1d14457ba1
I am not 100% language spec lawyer here.. Is the program `a.cpp` malformed and the compilation error allowed by the spec?
The C++ standard does not state that a function `isfinite()` should exist in global scope, but only a `std::isfinite()` namespaced version should exist? (https://isocpp.org/files/papers/N4860.pdf page 1215 has `bool std::isfinite(float x);`)
The C23 standard talks about a `isfinite()` macro (although gives its declaration in a pseudo-function declaration form)
<img width="1266" height="606" alt="Image" src="" />
so the above code should not conflict on a global function from the C standard?
Hence, it does seem to me like it would be a regression bug that the above code `a.cpp` no longer compiles?
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs