- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is it OK that the code compiled with -ip option is incompatible with the code compiled without -ip?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You'd need to be more explicit about what kind of problem you observe, and whether options such as -debug:inline-debug-info or Qip-no-inlining resolve them.
I could imagine that you might require an externally linkable copy of a function which is in-lined, but we'd need more specifics to comment.
In-lining also may expose or hide bugs, for example by offering more opportunities for data over-run to cause problems. It's intended to facilitate some transformations such as vectorization and elision of parentheses, where -fp:source might be needed to prevent numerical differences.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Tim!
Ok. Consider an executable A and two shared objects B and C. A is linked with B and loads C via dlopen().
Both B and C instantiate the same template. In my case it was std::map<std::string, unsigned int>. When C is loaded into memory it uses body of instantiated methods located in B. B was compiled with -ip and C was compiled without it. When C issued an insertion to the map via operator[], my program segfaults in some cases. It may segfault or may continue to work, but valgrind in both cases shows a problem in _M_insert_unique method - something like condition or move is based on uninitialized value. When I compiled C with -ip option, the problem disappeared.
I use the latest Intel C++ 2013 SP1 Update 2. The host platform is CentOS 6.5 (x86-64). It comes with gcc 4.4.7 and appropriate standart library. Both modules were compiled also with -O3. Shared object B is boost regex library version 1.55.0, if that matters. Boost by default builds with -ip if chosen toolset is intel-linux.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Max,
There should not be any "incompatibility" issue with -ip. That said, it's just pure luck that it worked after you compiled C with -ip. The problem could be something else and we'll have to debug further to identify the real cause.
_Kittur
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Max, did you have a chance to investigate further knowing that -ip should not have any incompatibility issue? -thx
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Kittur, I've tried to make a simple test of three object files as I described above. Everything is fine. But when object B is libboost_regex compiled with Intel C++ 14, happens what I said above. I use boost 1.55 compiled with intel-linux toolset and by default it is compiled with -ip flag. If module C is also compiled with -ip, then it is OK.
I must say that module C doesn't even call anything from libboost_regex explicitly. Just the fact, that A is linked to libboost_regex is enough to reproduce.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Max, can you attach the sources of the small modules you say created the issue and the compile options you used? -thx
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Kittur,
I've attached the test and a Makefile. You should rename Makefile.txt to Makefile and change BOOSTLIBDIR variable to point to directory that contains your boost shared libraries. Or just copy boost_regex to the current directory. Then simply type:
$ make
You are ready to execute test. Don't forget to set LD_LIBRARY_PATH to current directory. Otherwise libtestc.so wouldn't be found.
The test source code is not that pretty simple but I've stripped the code to the state when any line removal would make the test to run without the problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Kittur, I reproduce the problem on several machines running CentOS 6.5 and Scientific Linux 6.5, all of them running 64-bit OS. May be you can share the name of distro which you are using to reproduce the problem?
Also please check using ldd that testa links with correct version of boost. It may link with some other version of boost installed in your system in /usr/lib.
Also there is a chance that test executes successfully, because you have different stack or heap layout which can depend on various patches used by distro maintainers to strengthen security.
Anyway you could also try to run the test with valgrind. It can show problem event if it doesn't cause segfault. This is what I get when I run this test:
==21367== Memcheck, a memory error detector
==21367== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==21367== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==21367== Command: ./testa
==21367==
==21367== Conditional jump or move depends on uninitialised value(s)
==21367== at 0x4108CF: __intel_proc_init_ftzdazule (in /home/dmitrmax/work/tests/intel/testa)
==21367== by 0x401B26: __intel_new_feature_proc_init (in /home/dmitrmax/work/tests/intel/testa)
==21367== by 0x401482: main (in /home/dmitrmax/work/tests/intel/testa)
==21367==
==21367== Conditional jump or move depends on uninitialised value(s)
==21367== at 0x4108E4: __intel_proc_init_ftzdazule (in /home/dmitrmax/work/tests/intel/testa)
==21367== by 0x401B26: __intel_new_feature_proc_init (in /home/dmitrmax/work/tests/intel/testa)
==21367== by 0x401482: main (in /home/dmitrmax/work/tests/intel/testa)
==21367==
==21367== Conditional jump or move depends on uninitialised value(s)
==21367== at 0x5139D59: std::_Rb_tree<std::string, std::pair<std::string const, unsigned int>, std::_Select1st<std::pair<std::string const, unsigned int> >, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned int> > >::_M_insert_unique(std::pair<std::string const, unsigned int> const&) (in /home/dmitrmax/work/boost-1.55/lib/libboost_regex-il-mt-1_55.so.1.55.0)
==21367== by 0x93455B0: std::map<std::string, unsigned int, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned int> > >::operator[](std::string const&) (in /home/dmitrmax/work/tests/intel/libtestc.so)
==21367== by 0x9342006: func2 (in /home/dmitrmax/work/tests/intel/libtestc.so)
==21367== by 0x4014FD: main (in /home/dmitrmax/work/tests/intel/testa)
==21367==
==21367== Invalid read of size 8
==21367== at 0x5139D6B: std::_Rb_tree<std::string, std::pair<std::string const, unsigned int>, std::_Select1st<std::pair<std::string const, unsigned int> >, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned int> > >::_M_insert_unique(std::pair<std::string const, unsigned int> const&) (in /home/dmitrmax/work/boost-1.55/lib/libboost_regex-il-mt-1_55.so.1.55.0)
==21367== by 0x93455B0: std::map<std::string, unsigned int, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned int> > >::operator[](std::string const&) (in /home/dmitrmax/work/tests/intel/libtestc.so)
==21367== by 0x9342006: func2 (in /home/dmitrmax/work/tests/intel/libtestc.so)
==21367== by 0x4014FD: main (in /home/dmitrmax/work/tests/intel/testa)
==21367== Address 0xffffffffffffffe8 is not stack'd, malloc'd or (recently) free'd
==21367==
==21367==
==21367== Process terminating with default action of signal 11 (SIGSEGV)
==21367== Access not within mapped region at address 0xFFFFFFFFFFFFFFE8
==21367== at 0x5139D6B: std::_Rb_tree<std::string, std::pair<std::string const, unsigned int>, std::_Select1st<std::pair<std::string const, unsigned int> >, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned int> > >::_M_insert_unique(std::pair<std::string const, unsigned int> const&) (in /home/dmitrmax/work/boost-1.55/lib/libboost_regex-il-mt-1_55.so.1.55.0)
==21367== by 0x93455B0: std::map<std::string, unsigned int, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned int> > >::operator[](std::string const&) (in /home/dmitrmax/work/tests/intel/libtestc.so)
==21367== by 0x9342006: func2 (in /home/dmitrmax/work/tests/intel/libtestc.so)
==21367== by 0x4014FD: main (in /home/dmitrmax/work/tests/intel/testa)
==21367== If you believe this happened as a result of a stack
==21367== overflow in your program's main thread (unlikely but
==21367== possible), you can try to increase the size of the
==21367== main thread stack using the --main-stacksize= flag.
==21367== The main thread stack size used in this run was 8388608.
==21367==
==21367== HEAP SUMMARY:
==21367== in use at exit: 1,481 bytes in 7 blocks
==21367== total heap usage: 8 allocs, 1 frees, 1,665 bytes allocated
==21367==
==21367== LEAK SUMMARY:
==21367== definitely lost: 16 bytes in 1 blocks
==21367== indirectly lost: 0 bytes in 0 blocks
==21367== possibly lost: 29 bytes in 1 blocks
==21367== still reachable: 1,436 bytes in 5 blocks
==21367== suppressed: 0 bytes in 0 blocks
==21367== Rerun with --leak-check=full to see details of leaked memory
==21367==
==21367== For counts of detected and suppressed errors, rerun with: -v
==21367== Use --track-origins=yes to see where uninitialised values come from
==21367== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 9 from 9)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Kittur, I hope that your devs will have more luck. Anyway, I noticed that wrong GCC was used on your test environment.
[%]$ gcc --version
gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5)
While I wrote that this issue is reproducible when GCC 4.4.7 is used which is default on EL 6.x and its derived distributions (like CentOS or Scientific Linix). This may play a key role, since GCC 4.7.0 possibly comes with different standard library which contains affected std::map implementation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good news - I'm not mad :) Hope this will be fixed in the next release.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page