Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

OneAPI float128/Quad support

Robert_B_6
Beginner
2,225 Views

Hello,

We're in the process of migrating a legacy project from Intel 19.1 to Intel OneAPI, to target both Windows and Linux.  In doing so, we've ran into a few hiccup's, and are hoping for help.

In summary, it would seem that although OneAPI is aware of the Quad type (and associated compiler options), it doesn't provide implementations for basic functionality.  We experimented by incorporating a subset of the softfp library from gcclib and that successfully deals with compilation and linking issues.  However, we then ran into (and are continuing to encounter) runtime issues that appear to be related to struct/type alignment.  By changing alignments of specific classes (or specifically float128 members of specific members of some classes), we can get code to run with OneAPI, but subsequent development then breaks executables and it's trial and error to resolve the issues.

We're wondering if/when full float128 (Quad) support will be incorporated into OneAPI and/or what compilation options are recommended for correct integration of softfp into this project, to be compiled with OneAPI.  We are eager to finish migration from Intel 19.1 so we can (a) move onto the current builds of Visual Studio 2019, and (b) use the same compilers for both Windows and Linux targets.

Our current code base will execute properly with Intel 19.1 (Windows) and GCC (Linux) but will not execute (after dealing with mentioned compilation and linking issues) with Intel OneAPI.

0 Kudos
8 Replies
PrasanthD_intel
Moderator
2,194 Views

Hi Robert,


Are you trying to use Quadruple precision on GPU using dpcpp? or in CPU using icc/icl?

If you are facing issues while running on CPU then can you please provide us a sample code of yours so we can debug from our side?

To use 128 bit floats on windows with intel compilers please add the following flags -Qoption,cpp,--extended_float_type

For example : icl <test.cpp> -Qoption,cpp,--extended_float_type

On Linux use __float128 in place of _Quad.


If you are trying to run on GPU let us know.



Regards

Prasanth


0 Kudos
Robert_B_6
Beginner
2,166 Views

Thanks for the response.

Apologies if I posted in the wrong forum.  The problem is strictly native C++ built on Window & Linux, no GPU work.  We've conditionally typedef'd _Quad and __float128 to be synonyms.  Please move if/as appropriate.

We are actually having troubles reproducing the problems in a very small example, perhaps because linking errors indicate that unresolved externals are dependencies from a referenced lib that we also build, not in the target binary, and my example is trying to work with only one target.  I'll try recreating fresh project files this weekend, as well as an example that creates on lib used in one exe.  The current project files date back generations of the MSVC compiler.

We already addressed compilation options.  For additional options within MSVC, we have: "/Qoption,cpp,--extended_float_types /Qlong-double /Qdiag-disable:1885"  (note that --extended_float_type" doesn't work, it must be --extended-float_types).

Anyway, here's some more info from some experimentation:

1.) When building the Release targets, we have to disable Intel's Interprocedural Optimization when building our libraries, or the target binary, using MSLINK, complains that the supplied lib is invalid.  "fatal error LNK1107: invalid or corrupt file: cannot read at 0x39714A".  I'm wondering if this is a hint (incompatibilities in the lib file definitions) that there's a problem with referencing __float128 built-in's.

2.) When building either Debug or Release targets, the fix to get the program running is we've had to introduce code to pull a parameter passed by reference or pointer, to a local temporary, then work with the temporary.  Code then looks like this:

void aFunction(__float128 &accuracy) {

[...]

#ifdef __INTEL_LLVM_COMPILER
__float128 a(accuracy);
bool test_approx = (a > (__float128)(0.0));
#else
bool test_approx = (accuracy > (__float128)(0.0));
#endif

[...]

}

If this isn't done, then this crash is consistently reported: : 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.  (this is copied from an exception caught in softfp's __multf3)  It's always (hex)-1.

4.) There are no problems linking to built-in's in Debug,  But when linking in Release, if we don't explicitly include our softfp source tree, we get linking errors such as:
2>lld-[...]-86a31c..obj : : error LNK2001: unresolved external symbol __unordtf2
2>lld-lto-4af6e7.obj : : error LNK2001: unresolved external symbol __trunctfxf2
2>lld-lto-4af6e7.obj : : error LNK2001: unresolved external symbol __extenddftf2
[...]

Note that the code base has worked for years, and continues to work (compile, link, run), with various combinations of Intel-legacy and MSVC.  These problems are all new.  And do not occur in my small test example where I'm trying to reproduce the problem for you.

0 Kudos
Robert_B_6
Beginner
2,108 Views

I’ve attached a minimal example showing the linking error mentioned in the prior post. Look in testdouble.h and there is a line near the top that can be commented/uncommented to toggle the error. The error is caused by the combination of __declspec(export) and Intel’s interprocedural optimization (/Qipo). You have to disable at least one of the two to get it to link.  We have chosen to abandon the interprocedural optimization option for now.

0 Kudos
PrasanthD_intel
Moderator
1,936 Views

Hi Robert,


Thanks for providing us with the sample.

We are working on it and will get back to you soon.


Regards

Prasanth


0 Kudos
Viet_H_Intel
Moderator
1,912 Views

I don't see the usage of _Quad type name on Lib1.cpp nor testdouble.cpp. __float128 type doesn't support on Windows. So, _Quad needs to be used along with  /Qoption,cpp,--extended_float_type.

 

#include <iostream>

int main()

{

  _Quad tf1 = 4000;

  _Quad tf2 = 1000;

  _Quad tf3 = tf1 * tf2;

  int* i1 = static_cast<int*>((void*)&tf3);

 

  for (int i = 0; i < 4; i++)

  {

    std::cout << i1[i] << " ";

  }

  std::cout << std::endl;

 

  long double xf1 = 4000;

  long double xf2 = 1000;

  long double xf3 = xf1 * xf2;

  int* i2 = static_cast<int*>((void*)&xf3);

 

  for (int i = 0; i < 4; i++)

  {

    std::cout << i2[i] << " ";

  }

  std::cout << std::endl;

 

  std::cout << "Hello World!\n";

}

C:\Users\vahoang\Desktop\TestClang\Lib1>icl lib1.cpp /Qoption,cpp,--extended_float_type

Intel(R) C++ Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.1.2 Build 20201208_000000

Copyright (C) 1985-2020 Intel Corporation. All rights reserved.

 

lib1.cpp

Microsoft (R) Incremental Linker Version 14.28.29333.0

Copyright (C) Microsoft Corporation. All rights reserved.

 

-out:lib1.exe

lib1.obj

 

C:\Users\vahoang\Desktop\TestClang\Lib1>lib1.exe

0 0 0 1075112008

0 1095664768 0 1075112008

Hello World!

 

C:\Users\vahoang\Desktop\TestClang\Lib1>

 

Can you provide us a test case, which compiled successfully with ICL19.1, but failed with OneAPI?

Thanks,

 

0 Kudos
Robert_B_6
Beginner
1,904 Views

*sigh* here's another upload with very minor tweaks, no meaningful change to the code that fails in the first example that I uploaded.

Steps:

1.) Open SLN file in Visual Studio.

2.) Select target "Release 19.1".  Build TestDLL (Intel C++ 19.1) and observe that it has your mentioned compiler options "/Qoption,cpp,--extended_float_types /Qlong-double /Qdiag-disable:1885", and compiles and links as reported:

Build started...
1>------ Build started: Project: TestDll, Configuration: Release 19.1 x64 ------
1>testdouble.cpp
1> Creating library R:\testclang\TestClang\x64\Release 19.1\TestDll.lib and object R:\testclang\TestClang\x64\Release 19.1\TestDll.exp
1>TestDll.vcxproj -> R:\testclang\TestClang\x64\Release 19.1\TestDll.dll
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

3.) Select target "Release".   Observe that under compiler options, Command Line already includes "/Qoption,cpp,--extended_float_types /Qlong-double /Qdiag-disable:1885 " (it was there in the first example).

4.) Compile TestDLL (Intel C++ 2021)".  Observe that output is as reported:

Build started...
1>------ Build started: Project: TestDll, Configuration: Release x64 ------
1>clang-cl: : warning : unknown argument ignored in clang-cl: '-Qdiag-disable:1885' [-Wunknown-argument]
1>lld-link: : error : undefined symbol: __multf3
1>>>> referenced by R:\testclang\TestClang\TestDll\testdouble.cpp:13
1>>>> R:\testclang\TestClang\x64\Release\TestDll.dll.lto.obj:(public: struct __clang::__float128 __cdecl TestClass<struct __clang::__float128>::doWork(struct __clang::__float128, struct __clang::__float128))
1>
1>lld-link: : error : undefined symbol: __divtf3
1>>>> referenced by R:\testclang\TestClang\TestDll\testdouble.cpp:13
1>>>> R:\testclang\TestClang\x64\Release\TestDll.dll.lto.obj:(public: struct __clang::__float128 __cdecl TestClass<struct __clang::__float128>::doWork(struct __clang::__float128, struct __clang::__float128))
1>Done building project "TestDll.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

This linking error is one of the issues I've reported.

5.) Open up testdouble.h.  Comment out line 3.  Hit compile.  Observe that the build is successful.

Build started...
1>------ Build started: Project: TestDll, Configuration: Release x64 ------
1>clang-cl: : warning : unknown argument ignored in clang-cl: '-Qdiag-disable:1885' [-Wunknown-argument]
1>TestDll.vcxproj -> R:\testclang\TestClang\x64\Release\TestDll.dll
1>Done building project "TestDll.vcxproj".
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

6.) Uncomment line 3 of testdouble.h.  Turn off "Interprocedural Optimization" (it is originally set to Multifile).  Compile and observe that it is successful:

Build started...
1>------ Build started: Project: TestDll, Configuration: Release x64 ------
1>clang-cl: : warning : unknown argument ignored in clang-cl: '-Qdiag-disable:1885' [-Wunknown-argument]
1>TestDll.vcxproj -> R:\testclang\TestClang\x64\Release\TestDll.dll
1>Done building project "TestDll.vcxproj".
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

 

This illustrates that:

- the example always included the compilation options you state are needed (in the Release target)

- the code builds with 19.1.

- the code does not build with 2021 when exporting from a DLL, with interprocedural optimization turned on

0 Kudos
Robert_B_6
Beginner
1,901 Views

Oh yeah, change __float128 to _Quad on line 23 of testdouble.cpp, and repeat the tests, you get the same results.  That isn't the problem.

0 Kudos
Viet_H_Intel
Moderator
1,889 Views

Thanks for the testcase. Let me work on it and get back to you.


0 Kudos
Reply