- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
I am using latest Intel compiler C++ 2022 and my application return some ULP precision errors when I use long double data type. Previously I used Intel C++ compiler 19.3 and I got expected results.
So binary compiled on in the same Visual Studio, machine, with different compiler versions produce different results. I am using the following compiler properties for compilation:
/Qlong-double /Qpc80 -fp:strict
Is there anybody who can help me.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thanks for posting in Intel Communities.
Could you please let us know the Visual Studio version you are using?
Could you please provide us with the sample reproducer code and steps to reproduce the error at our end? And also, could you please provide us with a screenshot of the expected results?
Thanks & Regards,
Varsha
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for answer.
I've attached two exe files one compiled using Intel C++ compiler 19.1 (icc.exe) and Intel compiler 2022(icx.exe) in the same env MSVC 2019. You can find there as well two screen shots from output. I see errors in group of math functions that this exe is able to test. The test is official Khronos Conformance test for OpenCL API (link below). For reproduction purpose lets focus on one of them "atanh". Shortly the test calculate reference value on CPU and take results from calculation on GPU. To run this test you have to have Intel GPU driver in you environment with OpenCL support and cl_khr_fp64 extension (eg. platforms Coffee Lake, Kaby Lake, Sky Lake). From my experiments I conclude that icx ( version 2022) compiler calculate different values in case of long double data type comparing to icc compiler (version 19.01)
reproduction:
test_bruteforce.exe -w atanh -f -1
options:
( -w less input values, -f do not test fp32, -1 only scalar data types)
result:
1: atanh fp64 ....
ERROR: atanh: 35369785491456.000000 ulp error at -0x1.0000000000000p-39 (0xbd80000000000000): *-0x1.0000000002000p-39 vs. -0x1.000155588891ap-7
ERROR: atanh: 137441755136.000000 ulp error at -0x1.0000000000000p-39 (0xbd80000000000000): *-0x1.0000000002000p-39 vs. -0x1.0000000155555p-15
ERROR: atanh: 536870976.000000 ulp error at -0x1.0000000000000p-39 (0xbd80000000000000): *-0x1.0000000002000p-39 vs. -0x1.0000000000015p-23
ERROR: atanh: 2097152.000000 ulp error at -0x1.0000000000000p-39 (0xbd80000000000000): *-0x1.0000000002000p-39 vs. -0x1.0000000000000p-31
ERROR: atanh: 8192.000000 ulp error at -0x1.0000000000000p-39 (0xbd80000000000000): *-0x1.0000000002000p-39 vs. -0x1.0000000000000p-39
ERROR: atanh: 32.000000 ulp error at -0x1.0000000000000p-39 (0xbd80000000000000): *-0x1.0000000002000p-39 vs. -0x1.0000000000000p-47
ERROR: atanh: 6.000000 ulp error at -0x1.a900000000000p-35 (0xbdca900000000000): *-0x1.a900000058322p-35 vs. -0x1.a900000000000p-51
How to understand the output:
Error ULP difference, input value printed as cl_double (input value printed as cl_ulong), reference value (cpu), output value (gpu)
Link to source code:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Not sure if it makes a difference, but isn't the correct syntax for Windows /fp:strict ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
For settings "/Qlong-double /Qpc80 /fp:strict" the same
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
We are investigating your issue at our end.
Thanks & Regards,
Varsha
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
As per the confirmation from you through email, we are closing this thread.
If you need any additional information, please post a new question as this thread will no longer be monitored by Intel.
Thanks & Regards,
Varsha

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page