- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I run at some problem when I tried to convert some code from MSVC to Intel C++ compiler (32-bit mode). Code sequence thatreproduces the problem:
From disassembly it seems that compiler does not understand that rand_s can change referenced variable (rand_s has parameter declared as unsigned int*, so there is no const problem), andstores t in register. After call to rand_s, t is not reloaded.
Declaring t as volatile solves the problem, however I would prefer not to go through all of the sources to find all such instances.
Is there some workaround (i.e. some compiler switch I am not aware of) that would solve the problem? I tired with disabling IPO and various optimization level,but the problem persists unless I disable optimizations.
[cpp]#define _CRT_RAND_S #includeFunction rand_s is used as example: it is only important that it is imported from dll or static lib.If previous code is build in 'debug' mode, everything works as expected: it prints64 random numbers. If compiled in 'release' mode, it prints 64 zeros.#include int main(int argc, char* argv[]) { for ( int i = 0; i < 64; ++i ) { unsigned int t = 0; rand_s ( &t ); printf ( "%X ", t ); } return 0; } [/cpp]
From disassembly it seems that compiler does not understand that rand_s can change referenced variable (rand_s has parameter declared as unsigned int*, so there is no const problem), andstores t in register. After call to rand_s, t is not reloaded.
Declaring t as volatile solves the problem, however I would prefer not to go through all of the sources to find all such instances.
Is there some workaround (i.e. some compiler switch I am not aware of) that would solve the problem? I tired with disabling IPO and various optimization level,but the problem persists unless I disable optimizations.
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It might be interesting to check whether the pre-processor gets the same result about definition of rand_s() under ICL as under CL. I don't think the definition in is portable. Your example refuses to compile under gcc (the only compiler my employer as permitted me to install on this platform).
It does look like a problem report on your premier.intel.com account would be in order, in particular as the compiler doesn't appear justified in taking rand_s() as a pure function.
It does look like a problem report on your premier.intel.com account would be in order, in particular as the compiler doesn't appear justified in taking rand_s() as a pure function.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I used rand_s just as example: the original problem arised with propietary DLL.
You can remove #define _CRT_RAND_S from begining of the file, and just type declaration after includes, as follows:
(Remove __declspec(dllimport) if compiling with DLL run-time library instead of static one). It has the same effect. And preprocessor generates the same definitions in all four cases (MSVC debug, MSVC release, ICL debug and ICL release), the same as aformetioned one.
Anyway, I will follow your advice and report problem.
You can remove #define _CRT_RAND_S from begining of the file, and just type declaration after includes, as follows:
[cpp]#include#include __declspec(dllimport) errno_t _cdecl rand_s ( unsigned int *ptr ); int main(int argc, char* argv[]) { for ( int i = 0; i < 64; ++i ) { unsigned int t = 0; rand_s ( &t ); printf ( "%X ", t ); } return 0; } [/cpp]
(Remove __declspec(dllimport) if compiling with DLL run-time library instead of static one). It has the same effect. And preprocessor generates the same definitions in all four cases (MSVC debug, MSVC release, ICL debug and ICL release), the same as aformetioned one.
Anyway, I will follow your advice and report problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Vladimir,
I can reproduce the problem. Did you get a chance to report this issue via Premier Support?
If not, I can file a report on this issue and let you know when the problem is resolved.
Thanks,
--mark
I can reproduce the problem. Did you get a chance to report this issue via Premier Support?
If not, I can file a report on this issue and let you know when the problem is resolved.
Thanks,
--mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Looks like an optimization issue at /O2. It prints the expected results when compiled at /O2.
--mark
--mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Vladimir,
I filed a report on this issue and will let you know when I get an update.
Thanks,
--mark
I filed a report on this issue and will let you know when I get an update.
Thanks,
--mark

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