Re: std::isnan, std::isinf not working
Okay I found the answer it's a result of using optimization flags -Oz
--ffast-math. If you remove one of it - works correctly. Also behavior is
exactly same in clang++, so I think there is no error from emscripten.
My last test case:
#include
#include
#include
int main(int argc, char **argv) {
float val = std::numeric_limits::quiet_NaN();
printf("val '%.2f', isnan:%s\n", val,
std::isnan(val) ? "yes" : "no");
return 0;
}
ср, 2 мар. 2022 г. в 08:46, Александр Гурьянов :
> I tried to do this but in empty project it works correctly. I converted
> the float to int32_t like this:
>
> int32_t* val = (int32_t)
> printf("%d\n", *val);
>
> and the number was 2143289344, I created testcase:
>
> #include
> #include
>
> int main(int argc, char** argv) {
> int32_t nan = 2143289344;
> float* val = (float *)
>
> printf("val '%.2f', isnan:%s, isinf:%s\n", *val,
>std::isnan(*val) ? "yes" : "no",
>std::isinf(*val) ? "yes" : "no");
>
> return 0;
> }
>
> but it works correctly:
>
> val 'nan', isnan: yes, isinf: no
>
> Moreover in native build of project there is no NAN in problem place, it
> appears only in emscripten build. So, probably error happens somewhere
> else... Trying to understand.
>
> ср, 2 мар. 2022 г. в 00:18, 'Sam Clegg' via emscripten-discuss <
> emscripten-discuss@googlegroups.com>:
>
>> Perhaps if you print the actual bitpattern at the point of failure you
>> can use that to create a repro case? Without a repro case I think this
>> will be hard to make progress on. Once you have a repro please open an bug
>> report on github.
>>
>> chers,
>> sam
>>
>>
>> On Tue, Mar 1, 2022 at 8:38 AM Александр Гурьянов
>> wrote:
>>
>>> Hi, I faced problem that std::isnan return false for NAN. I added this
>>> debug printf to my project:
>>>
>>> printf("res %.2f %s %s\n", res,
>>>std::isnan(res) ? "isnan" : "notnan",
>>>std::isinf(res) ? "isinf" : "notinf");
>>>
>>> and when res is NAN, output is following:
>>>
>>> res nan notnan notinf
>>>
>>> I tried to make a simple test case, but in test case it works fine. So,
>>> I think this is a sort of UB, but I run project with valgrind - no errors.
>>> I tried -s ASSERTIONS=1 -s SAFE_HEAP=2, also no errors.
>>>
>>> Any suggestions what it can be?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVHMsym8-XQXp7fb5xz7kaG_fV-M19aj-kUzbdAEbxG7Yg%40mail.gmail.com
>>>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_hYHdYk7oercuCm4jHmhfo0tiZqoUM2O%3DTiONbpGsqZg%40mail.gmail.com
>>
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVGtzeNfAFWq%2BqOvH%2BTszifn2n0tP3xQ%3DTZUEZwe2BaqNw%40mail.gmail.com.
Re: std::isnan, std::isinf not working
I tried to do this but in empty project it works correctly. I converted the
float to int32_t like this:
int32_t* val = (int32_t)
printf("%d\n", *val);
and the number was 2143289344, I created testcase:
#include
#include
int main(int argc, char** argv) {
int32_t nan = 2143289344;
float* val = (float *)
printf("val '%.2f', isnan:%s, isinf:%s\n", *val,
std::isnan(*val) ? "yes" : "no",
std::isinf(*val) ? "yes" : "no");
return 0;
}
but it works correctly:
val 'nan', isnan: yes, isinf: no
Moreover in native build of project there is no NAN in problem place, it
appears only in emscripten build. So, probably error happens somewhere
else... Trying to understand.
ср, 2 мар. 2022 г. в 00:18, 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com>:
> Perhaps if you print the actual bitpattern at the point of failure you can
> use that to create a repro case? Without a repro case I think this will
> be hard to make progress on. Once you have a repro please open an bug
> report on github.
>
> chers,
> sam
>
>
> On Tue, Mar 1, 2022 at 8:38 AM Александр Гурьянов
> wrote:
>
>> Hi, I faced problem that std::isnan return false for NAN. I added this
>> debug printf to my project:
>>
>> printf("res %.2f %s %s\n", res,
>>std::isnan(res) ? "isnan" : "notnan",
>>std::isinf(res) ? "isinf" : "notinf");
>>
>> and when res is NAN, output is following:
>>
>> res nan notnan notinf
>>
>> I tried to make a simple test case, but in test case it works fine. So, I
>> think this is a sort of UB, but I run project with valgrind - no errors. I
>> tried -s ASSERTIONS=1 -s SAFE_HEAP=2, also no errors.
>>
>> Any suggestions what it can be?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVHMsym8-XQXp7fb5xz7kaG_fV-M19aj-kUzbdAEbxG7Yg%40mail.gmail.com
>>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_hYHdYk7oercuCm4jHmhfo0tiZqoUM2O%3DTiONbpGsqZg%40mail.gmail.com
>
> .
>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVGQm2Xg_u6OEL0h0denGWdL7pmJTYSK%2BysvAbvwhT_fYQ%40mail.gmail.com.
Re: std::isnan, std::isinf not working
Perhaps if you print the actual bitpattern at the point of failure you can
use that to create a repro case? Without a repro case I think this will
be hard to make progress on. Once you have a repro please open an bug
report on github.
chers,
sam
On Tue, Mar 1, 2022 at 8:38 AM Александр Гурьянов
wrote:
> Hi, I faced problem that std::isnan return false for NAN. I added this
> debug printf to my project:
>
> printf("res %.2f %s %s\n", res,
>std::isnan(res) ? "isnan" : "notnan",
>std::isinf(res) ? "isinf" : "notinf");
>
> and when res is NAN, output is following:
>
> res nan notnan notinf
>
> I tried to make a simple test case, but in test case it works fine. So, I
> think this is a sort of UB, but I run project with valgrind - no errors. I
> tried -s ASSERTIONS=1 -s SAFE_HEAP=2, also no errors.
>
> Any suggestions what it can be?
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVHMsym8-XQXp7fb5xz7kaG_fV-M19aj-kUzbdAEbxG7Yg%40mail.gmail.com
>
> .
>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_hYHdYk7oercuCm4jHmhfo0tiZqoUM2O%3DTiONbpGsqZg%40mail.gmail.com.
std::isnan, std::isinf not working
Hi, I faced problem that std::isnan return false for NAN. I added this
debug printf to my project:
printf("res %.2f %s %s\n", res,
std::isnan(res) ? "isnan" : "notnan",
std::isinf(res) ? "isinf" : "notinf");
and when res is NAN, output is following:
res nan notnan notinf
I tried to make a simple test case, but in test case it works fine. So, I
think this is a sort of UB, but I run project with valgrind - no errors. I
tried -s ASSERTIONS=1 -s SAFE_HEAP=2, also no errors.
Any suggestions what it can be?
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVHMsym8-XQXp7fb5xz7kaG_fV-M19aj-kUzbdAEbxG7Yg%40mail.gmail.com.
Re: Emscripten SDK and WASI filesystem access
For clarity, here is the linke to `O_RDONLY` for wasi: https://github.com/WebAssembly/wasi-libc/blob/ad5133410f66b93a2381db5b542aad5e0964db96/libc-bottom-half/headers/public/__header_fcntl.h#L20 On Saturday, February 26, 2022 at 5:21:11 PM UTC-5 scot...@gmail.com wrote: > Its the constants in fcntl.h / in wasi: __header_fcntl.h and api.h : > > ``` > > #define O_WASI_RDONLY (0x0400) > #define O_WASI_WRONLY (0x1000) > #define O_WASI_RDWR (O_WASI_RDONLY | O_WASI_WRONLY) > > > typedef uint16_t __wasi_oflags_t; > typedef uint16_t __wasi_fdflags_t; > > > #define WASI_OFLAGS_CREAT ((__wasi_oflags_t)(1 << 0)) > #define WASI_OFLAGS_EXCL ((__wasi_oflags_t)(1 << 2)) > #define WASI_OFLAGS_TRUNC ((__wasi_oflags_t)(1 << 3)) > #define WASI_FDFLAGS_SYNC ((__wasi_fdflags_t)(1 << 4)) > > > #define O_WASI_CREAT (WASI_OFLAGS_CREAT << 12) > #define O_WASI_EXCL (WASI_OFLAGS_EXCL << 12) > #define O_WASI_TRUNC (WASI_OFLAGS_TRUNC << 12) > #define O_WASI_SYNC WASI_FDFLAGS_SYNC #define O_WASI_CLOEXEC 0 > ``` > Remove the WASI_ from these and you see that in emscripten they are > different. E.g. for O_RDONLY in fcntl.h under system/lib/libc/musl/include > it is: > ``` > #define O_RDONLY 00 > ``` > But For WASI I "overwrite" it with 0x0400. It's a hack ( > https://github.com/dotnet/runtimelab/pull/1850/files#diff-5d86cce7b76e1bece0aec26ee2bc4830503046428aecbbdefbf845832573020f), > > and I do that switch with a "special" options flag. > > Interesting that these constants are different between emscripten and WASI > as both are musl. There must be some history there I suppose. > On Thursday, February 10, 2022 at 12:34:43 PM UTC-5 alon...@gmail.com > wrote: > >> I see... yeah, mixing and matching object files from different toolchains >> is not guaranteed to work. They need C ABI compatibility, I'm afraid. >> >> It is a little sad to need separate runtimes, though, so I hope we can >> find a way to avoid that for you. What is the specific code that would be >> different between the two runtimes? >> >> On Thu, Feb 10, 2022 at 5:23 AM yowl yowlxx wrote: >> >>> " (Of course, header constants *can* be an issue if you link wasm object >>> files together that were built using different SDKs or even different >>> versions of the same SDK.)" >>> >>> Yes, that is what I naively tried to do. The CoreCLR runtime is >>> compiled using emscripten's SDK, but I wanted to link it with the WASI SDK >>> libc++ to get file open support. What I'll probably have to do in the long >>> run is have two CoreCLR runtimes, one for Emscripten and one for WASI SDK. >>> >>> On Mon, 7 Feb 2022 at 14:39, Alon Zakai wrote: >>> Header constants like O_CREAT should not be a problem between wasm and the host. WASI defines a very clear API between wasm and the runtime, and those constants are not part of it. That is, "wasi-sdk host" is a confusing way to put it: there are VMs with WASI support, but they are not tied to the wasi-sdk toolchain, which is just one toolchain that emits WASI. (Of course, header constants *can* be an issue if you link wasm object files together that were built using different SDKs or even different versions of the same SDK.) Emscripten could add more complete WASI support, if that were useful - it's just a matter of implementing the APIs. PRs would be welcome! On Sat, Feb 5, 2022 at 9:59 AM scot...@gmail.com wrote: > My own observations mixing Emscripten and WASI-SDK are that some > constants, e.g. `O_CREAT` are different in Emscripten (0x64) to Wasi-SDK > (0x1000). Allowing emscripten to build something that would run > under > a wasi-sdk host, like wasmtime, is tricky - I think. > > On Friday, December 17, 2021 at 8:01:14 AM UTC-5 Floh wrote: > >> Ah alright, that toolchain file looks a lot simpler (it's under >> "share/cmake" in the SDK download). I'll use that as base for my own >> cmake >> toolchain file instead. Thanks! >> >> On Thursday, 16 December 2021 at 21:18:46 UTC+1 s...@google.com >> wrote: >> >>> On Thu, Dec 16, 2021 at 5:53 AM Floh wrote: >>> > Unless you plan to run those tools on the web then I think wasi-sdk is most likely the way to go. How do you plan to run the binaries BTW? Currently I'm using wasmtime. I was actually successful to build my shader compiler through wasi-sdk, and run it through wasmtime, the file system access worked as expected. Installing the wasi-sdk is just downloading and unpacking somewhere (e.g. no env-variables or search path updating needed), and then I created a cmake toolchain file which looks a lot like my Emscripten toolchain file, but with all the Emscripten-specific parts removed:
