Integer arithmetic overflow

[Wobo]

Hello,

currently using IPP 2021.6.0 for Windows. There I got some compiler warnings when working with a 32bit C++ compiler (< C++11) concerning "integer arithmetic overflow" when using constants defined in ipptypes.h like ippCPUID_AVX512IFMA (or bigger). I found in ipptypes.h a piece of code that seems a bit odd and which is the cause for the compiler warnings:

#if defined( _WIN32 ) || defined ( _WIN64 )
#define INT64_SUFFIX(name) name##L
#else
#define INT64_SUFFIX(name) name##LL
#endif

#define ippCPUID_AVX512IFMA INT64_SUFFIX(0x100000000) /* Intel(R) Advanced Vector Extensions 512 IFMA (PMADD52) instruction set */
#define ippCPUID_NOCHECK INT64_SUFFIX(0x8000000000000000) /* Force ippSetCpuFeatures to set CPU features without check */
#define ippCPUID_GETINFO_A INT64_SUFFIX(0x616f666e69746567) /* Force ippGetCpuFeatures to work as cpuid instruction */
#define ippAVX512_ENABLEDBYOS INT64_SUFFIX(0x200000000) /* Intel(R) Advanced Vector Extensions 512 is supported by OS */
#define ippCPUID_AVX512VPOPCNTDQ INT64_SUFFIX(0x400000000) /* Intel(R) Advanced Vector Extensions 512 VPOPCNTDQ instruction set */
#define ippCPUID_AVX512_BITALG INT64_SUFFIX(0x800000000) /* Intel(R) Advanced Vector Extensions 512 BITALG instruction set */
#define ippCPUID_AVX512_FP16 INT64_SUFFIX(0x1000000000) /* Intel(R) Advanced Vector Extensions 512 16-bit floating point (FP16) instruction set */

If you use a 32bit C++ compiler (_WIN32 is true, until C++11), the line "#define INT64_SUFFIX(name) name##L" tries to put a value ippCPUID_AVX512IFMA (or bigger) that is greater than max unsigned long int (unsigned 32bit integer) into 32bit integer (until C++11), which is impossible and causes an integer arithmetic overflow (at least as a compiler warning, real code depends on what the specific compiler makes of it).

I used reference: https://en.cppreference.com/w/cpp/language/integer_literal

However, a simple solution for me, to get rid of these compiler warnings, is just to hack a bit ipptypes.h in a way that looks like:

/* #if defined( _WIN32 ) || defined ( _WIN64 )
#define INT64_SUFFIX(name) name##L
#else */

#define INT64_SUFFIX(name) name##LL

/* #endif */

The line "#define INT64_SUFFIX(name) name##LL" does it for every purpose, at least for my 32bit and my 64bit compilers.

Maybe these not so safe macro definitions in ipptypes.h can be improved a bit in a next IPP version, so that this personal quick hack is no longer necessary...

Regards

[ShanmukhS_Intel]

Hi,

Thank you for posting on Intel Communities.

Thank you for sharing the details. Could you please share us a sample reproducer, so that we could try investigating the mentioned compiler warning at our end.

Best Regards,

Shanmukh.SS

[Wobo]

I use the 32bit compiler "classic Borland Compiler" (< C++11) from the current Embarcadero C++ Builder IDE. With this compiler, _WIN32 is defined and because of that, the macro "#define INT64_SUFFIX(name) name##L" (from ipptypes.h) is in effect if you simply do:

Ipp64u xyz=ippCPUID_AVX512IFMA;

If you remember, ippCPUID_AVX512IFMA is defined in ipptypes.h as "#define ippCPUID_AVX512IFMA INT64_SUFFIX(0x100000000)" and INT64_SUFFIX(0x100000000) would act in this case as "name##L", it is clear, a < C++11 compiler must complain about trying to put a bigger than 32bit integer value (0x100000000) in a 32bit value only ("name##L" instead of "name##LL").

Such a line causes (in my compiler) the compiler warning: "Integer arithmetic overflow" because it is an compiler < C++11.
(see also: https://en.cppreference.com/w/cpp/language/integer_literal)

You probaly use other comilers than me, hence it does not make sense to provide you a small C++ Builder project for reproduction. To see the thing and possibly modify the macros to the better is quite obvious I think and needs not necessarily a project file.

Regards

[ShanmukhS_Intel]

Hi,

Meanwhile, we look into your issue further using intel/ intel compatible compilers, We would like to provide you with the list of compilers supported under the below system requirements link. 

https://www.intel.com/content/www/us/en/developer/articles/system-requirements/intel-oneapi-intel-integrated-performance-primitives-system-requirements.html

Best Regards,

Shanmukh.SS

[Wobo]

Hi,

thank you for the link. However, the described issue is not only related to a specific compiler, it is also related to the used C++ standard. For C++ compilers < C++11 the macro is likely to "fail", for C++ starting with C++11, "##L" can also be interpreted as "long long int", see 3rd row in table "Type of the literal" under link: https://en.cppreference.com/w/cpp/language/integer_literal. In this case the macro will not "fail", respectively the compiler will not issue the mentioned warning.

Regards

[ShanmukhS_Intel]

Hi Wobo,

We are trying to reproduce the issue at our environment. We will get back to you on this with updated and our findings.

Best Regards,

Shanmukh.SS

[ShanmukhS_Intel]

Hi,

Could you please share us a sample reproducer, so that we could try reproducing the issue and work on it further? as we have an environmental issue at our end to generate the compiler warnings mentioned. 

Best Regards,

Shanmukh.SS

[Wobo]

Hello,

my projects/source files are incompatible to your compilers. So it is of no use for you.

-#define ippCPUID_AVX512IFMA INT64_SUFFIX(0x100000000) /* Intel(R) Advanced Vector Extensions 512 IFMA (PMADD52) instruction set */
-#define INT64_SUFFIX(name) name##L => max unsigned long int for compilers less than C++11
-0x100000000 is bigger than unsigned long int

To reproduce/test it, just use this source code line (as can be found already in my post from 06-13-2022):

Ipp64u xyz=ippCPUID_AVX512IFMA;

My 32 bit compiler (Embarcadero 32 bit "classic Borland Compiler", _WIN32 is defined with this compiler) issues a warning "Integer arithmetic overflow" (because of "ippCPUID_AVX512IFMA") because it is a
compiler less than C++11, hence it has to do it according to:
https://en.cppreference.com/w/cpp/language/integer_literal (l or L => long int or unsigned long int)

and because the macro in effect (from ipptypes.h):
#if defined( _WIN32 ) || defined ( _WIN64 )
#define INT64_SUFFIX(name) name##L
...

A compiler greater or equal to C++11 will normally not issue such a warning because of https://en.cppreference.com/w/cpp/language/integer_literal, see table "The type of the literal" row 3 (l or L => also
long long int or unsigned long long int).

For alle my compilers I use from Embarcadero, the line:

#define INT64_SUFFIX(name) name##LL

is good enough to make all things work and silence the 32 bit compiler warning, mentioned in these posts.

I have my solution just to patch/hack ipptypes.h macro just to that:
/* #if defined( _WIN32 ) || defined ( _WIN64 )
#define INT64_SUFFIX(name) name##L
#else */

#define INT64_SUFFIX(name) name##LL

/* #endif */

Regards

[ShanmukhS_Intel]

Hi,

We are able to generate the compiler warning mentioned. We are working on this internally, we will get back to you soon with an update.

Best Regards,

Shanmukh.SS

[Wobo]

>>We are able to generate the compiler warning mentioned. We are working on this internally, we will get back

>>to you soon with an update.

Ok, good to know.

Thank you.

Regards

[Ruqiu_C_Intel]

Hello Wobo,

Thank you to contact to us.

Good to know you have workaround for your own 32-bit compiler.

For IPP supports compilers list in IPP release notes here: https://www.intel.com/content/www/us/en/developer/articles/system-requirements/intel-oneapi-intel-integrated-performance-primitives-system-requirements.html

Supported Compilers

Linux*

• Intel® C++ Compiler 19.1 for Linux* OS and later
• GNU Compilers 4.8 and higher
• Glibc version 2.4 or higher

Windows*

• Intel® C++ Compiler 19.1 for Windows* OS and later
• Microsoft Visual Studio* 2017 - help file and environment integration
• Microsoft Visual Studio* 2019 - help file and environment integration
• Microsoft Visual Studio* 2022 Community, Enterprise and Professional Editions with 'Desktop development with C++' component installed are supported, except for use with Intel® Inspector and Intel® Advisor.

macOS*

• Xcode* 10
• Xcode* 11

[Ruqiu_C_Intel · Accepted solution]

The founding will put into our backlog. For now, this issue is closing and we will no longer respond to this thread. If you require additional assistance from Intel, please start a new thread. 

Any further interaction in this thread will be considered community only. 

Best,

Ruqiu