Segmentation fault with sample files on Mac + Intel compilers

[GoogleCodeExporter]

src$ icpc -c pugixml.cpp
... produces a bunch of assert(const) #279 warnings, but that's irrelevant ....
samples$ icpc traverse_base.cpp -o traverse_base.exe ../../src/pugixml.o 
-I../../src/
samples$ ./traverse_base.exe
Segmentation fault

Version: pugixml 1.0
Compiler: Intel C++ compiler for Mac, Version 11.1
architecture: x86_64
MacOS 10.6 (Snow Leopard)

NOTE: the GNU C++ compiled samples work fine.
There are no issues with the intel compiler because I use it exclusively all 
the time for my simulations.

Original issue reported on code.google.com by piz...@gmail.com on 7 Oct 2011 at 1:32

[GoogleCodeExporter]

Warnings are fixed in trunk.

As for the segmentation fault, I can't reproduce it with icc 12.1 for MacOS 
10.5 - samples work fine as well as the full test suite.

Note that it's quite possible that ICC 11.1 had a bug; the fact that it works 
for your code does not mean that pugixml code compiles fine. Still, it's 
unusual that there is a segfault without any optimizations.

I'll try to find a copy of icc 11.1 for MacOS; in the meantime, providing some 
more information would help to get a possible reason (for example, you can try 
compiling the code with debug information, and launching the resulting 
executable from gdb to get a callstack).

Original comment by arseny.k...@gmail.com on 8 Oct 2011 at 4:26

[GoogleCodeExporter]

icpc by default uses the optimization -O2. 
it turns out that the problem is with the inlining. Using -inline-levels=0 the 
problems disappear. I will investigate the matter later.

Original comment by piz...@gmail.com on 8 Oct 2011 at 8:04

[GoogleCodeExporter]

this solves the problem:
add attribute noinline:
    __attribute__((noinline)) strconv_attribute_t get_strconv_attribute(const unsigned int optmask)
in plugixml.cpp around line 1840

But it might indeed be intel's fault. I have seen such problems before in my 
own code.

Original comment by piz...@gmail.com on 8 Oct 2011 at 9:16

[GoogleCodeExporter]

I can't reproduce this with Intel C++ Compiler 11.1.084 (20100203).
At any rate, this is likely a code generation bug in the compiler; I'm closing 
the issue for now.

Original comment by arseny.k...@gmail.com on 15 Nov 2011 at 5:50

• Changed state: WontFix