-pch option always causes compiler to crash, or other strange errors

[jdictos]

I'm using intel compiler version 11.0 on Mac OSX 10.5. We have many c++ files that all include the same header, which includes a lot of other headers, some of which are c++ stl headers. Well we are trying to use the pch header feature of the intel compiler (of course the microsoft compiler works fine), but each time we try to use the -pch option, the compiler either crashes after compiling the second source file, or there are a ton of errors like so:

stxxres.utf

"yglobalbase.cpp": creating precompiled header file "yglobalbase.pchi"

"yglobalapi.cpp": using precompiled header file "yglobalbase.pchi"

/usr/include/c++/4.0.0/bits/stl_iterator_base_types.h(150): error: identifier "_Tp" is undefined

typedef _Tp value_type;

^

detected during:

instantiation of class "std::iterator_traits [with _Tp=unsigned long]" at line 2627 of "/usr/include/c++/4.0.0/bits/stl_algo.h"

instantiation of "_ForwardIterator std::lower_bound(_ForwardIterator, _ForwardIterator, const _Tp &) [with _ForwardIterator=const unsigned long *, _Tp=unsigned long]" at line 229 of "/usr/include/c++/4.0.0/ext/hashtable.h"

/usr/include/c++/4.0.0/bits/stl_iterator_base_types.h(152): error: identifier "_Tp" is undefined

typedef const _Tp* pointer;

^

detected during:

instantiation of class "std::iterator_traits [with _Tp=unsigned long]" at line 2627 of "/usr/include/c++/4.0.0/bits/stl_algo.h"

instantiation of "_ForwardIterator std::lower_bound(_ForwardIterator, _ForwardIterator, const _Tp &) [with _ForwardIterator=const unsigned long *, _Tp=unsigned long]" at line 229 of "/usr/include/c++/4.0.0/ext/hashtable.h"

Without the -pch option, everything compiles fine.

The commandline used in this case was:

/Users/jason/compile/macport/source:/opt/intel/Compiler/11.0/059/bin/ia32/icpc -c -cxxlib -D_REENTRANT -D_LARGE_INTEGER -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -no-vec -Wreturn-type -Wwrite-strings -Wuninitialized -wd654,1125,186 -pch -pch-dir /macport/source/sup/macdbg_sup/x86 -fpack-struct -DBUILD_MAC -DPROC_X86 -DBUILD_KERNEL -g -O0 -DBUILD_DEBUG -DBUILD_SUP -I/macport/common/plat/mac/inc -I/opt/intel/Compiler/11.0/059/include -I/usr/include/c++/4.0.0 -I/usr/include/c++/4.0.0/ext -I/usr/include/c++/4.0.0/bits -I/macport/source/sup++ -I/macport/source/sup++ -I/macport/common/plat/common/boost -I/macport/source/sup/macdbg_sup/x86 -I/macport/source/sup -I/macport/source/crs -I/macport/source/crs/macdbg_crs/x86 -I/macport/source/sup -I/macport/source/sup++ -I/macport/source/sup/macdbg_sup/x86 -I/macport/source/stb -I/macport/source/dcs -I/macport/source/dcs/macdbg_dcs/x86 -I/macport/source/ods -I/macport/source/ods++ -I/macport/source/ods/macdbg_ods/x86 -I/macport/source/dtb -I/macport/source/dtb++ -I/macport/source/dtb/macdbg_dtb/x86 -I/macport/source/drm -I/macport/source/drm/macdbg_drm/x86 -I/macport/source/ysi -I/macport/source/scr -I/macport/source/scr/macdbg_scr/x86 -I/macport/source -I/macport/source/dcs/dev -I/macport/source/dcs/ctl -I/macport/source/dcs/ltf -I/macport/common/plat/common/tinyxpath1.3.1/inc -I/macport/common/plat/common/boost /macport/source/sup++/yglobalbase.cpp -o /macport/source/sup/macdbg_sup/x86/yglobalbase.obj

In other source files, like our c++ qt gui code, the compiler just bombs out entirely.

"guicommon.cpp": creating precompiled header file "guicommon.pchi"

"about.cpp": using precompiled header file "guicommon.pchi"

(0): internal error: backend signals

Interesting to note, this problem does NOT happen with our C code, only when we compile C++ source objects does this occur.

[Dale_S_Intel]

Quoting - jdictos

I'm using intel compiler version 11.0 on Mac OSX 10.5. We have many c++ files that all include the same header, which includes a lot of other headers, some of which are c++ stl headers. Well we are trying to use the pch header feature of the intel compiler (of course the microsoft compiler works fine), but each time we try to use the -pch option, the compiler either crashes after compiling the second source file, or there are a ton of errors like so:

...

Without the -pch option, everything compiles fine.

...

Interesting to note, this problem does NOT happen with our C code, only when we compile C++ source objects does this occur.

I'm a little confused, when you say "the microsoft compiler works fine", do you mean gcc? MS doesn't have a compiler for Mac that I'm aware of. Also, if you can post some sort of reproducible test case that would help immensely. Also, are you using XCode or the command line for your build?

Thanks!

Dale

[jdictos]

Quoting - Dale Schouten (Intel)

I'm a little confused, when you say "the microsoft compiler works fine", do you mean gcc? MS doesn't have a compiler for Mac that I'm aware of. Also, if you can post some sort of reproducible test case that would help immensely. Also, are you using XCode or the command line for your build?

Thanks!

Dale

Guess I should've clarified, this same code base compiles fine on our windows (same code base basically). We use the intel compiler for our linux, and mac osx compilation of this same code base. Both linux and mac basically blow up whenever we try to use the -pch option. We've tried using all sorts of combinations of command line options, including manually creating pch headers using the -pch-create option, and the -pch-use options. No amount of fiddling makes it work. Oh and we've read the docs you guys have about pch headers as well, using #pragma hdrstop to preventpre-compiledheaders from being created, etc, all to no avail.

I'm not using xcode, all from the command line with our own build process.

I'll try to reproduce this with a simple test case, but even if I can't duplicate it with a simple test case, its gotta be pretty obvious to you guys that there's something wrong withpre-compiledheader support in this compiler, given all the postings on this subject.

Are there any beta builds I can try out that address pch issues? Do you have any fixes in the pipeline for pch issues?

-Jason

[jdictos]

The problem appears to be because of the stack size limit on mac osx. We had a similar problem on linux, and on linux we are able to get it to work by using "ulimit -s unlimited". Osx seems to have some harder restrictions on stack sizes.

Got any suggestions on a workaround?

[Dale_S_Intel]

Quoting - jdictos

The problem appears to be because of the stack size limit on mac osx. We had a similar problem on linux, and on linux we are able to get it to work by using "ulimit -s unlimited". Osx seems to have some harder restrictions on stack sizes.

Got any suggestions on a workaround?

Unfortunately I haven't seen this problem. Can you give any clues as to how I might reproduce the problem? Also, you might give 11.1 a try, which I think is available now. I don't know that it fixes this problem, but that would be the latest one to try, just to make sure.

Dale

[aazue]

Quoting - Dale Schouten (Intel)

Quoting - jdictos

The problem appears to be because of the stack size limit on mac osx. We had a similar problem on linux, and on linux we are able to get it to work by using "ulimit -s unlimited". Osx seems to have some harder restrictions on stack sizes.

Got any suggestions on a workaround?

Unfortunately I haven't seen this problem. Can you give any clues as to how I might reproduce the problem? Also, you might give 11.1 a try, which I think is available now. I don't know that it fixes this problem, but that would be the latest one to try, just to make sure.

Dale

Hi
With reserve ....
Add to -I(path include concerned) /*.pch (same is informed in Makefile sometime for hpp header typed) ???
or add option way -pch_dir ..........
I not understand where relation (/usr/include/c++/4.0.0/bits/stl_iterator_base_types.h(150): error: identifier "_Tp" is undefined) ???
_Tp defined in an pch precompiled header ???
Best regards

[jdictos]

Well it seems to be related to BIG projects, not small test cases. In our case we have one header that includes a ton of other headers, stl, and boost. So the sheer amount of stuff being precompiled is exceeding the stack space I assume.

So just try including a ton of headers, that include headers, that include headers, etc. and see what happens.

[aazue]

Quoting - jdictos

Well it seems to be related to BIG projects, not small test cases. In our case we have one header that includes a ton of other headers, stl, and boost. So the sheer amount of stuff being precompiled is exceeding the stack space I assume.

So just try including a ton of headers, that include headers, that include headers, etc. and see what happens.

Hi
So just try including a ton of headers, that include headers, that include headers, etc. and see what happens.
I think is not the problem ....
when i compile program same Firefox or Kernel or GCC full all options or big mainframe, sometimei use Make with option
--jobs-=16 and i have not problem stack, ProbablyI think shared busy precompiled objects in wait can be * 10 that you can having with your headers...

Actually if you must change value stack default to ulimit (recent O/S) you having incorrect programming in some points.
also if you having big program use Makefile for an best contol at step (link)
Best regards

[jdictos]

Quoting - bustaf

Actually if you must change value stack default to ulimit (recent O/S) you having incorrect programming in some points.

Well I agree, but in this case its not our program thats requiring huge stack space, its intel's compiler.

[aazue]

Quoting - jdictos

Well I agree, but in this case its not our program thats requiring huge stack space, its intel's compiler.

Hi
(its intel's compiler.) You can test compile chapter Shakespeare if you want, command line have no restricted rule.....

The problem appears to be because of the stack size limit on mac osx. We had a similar problem on linux, and on linux we are able to get it to work by using "ulimit -s unlimited". Osx seems to have some harder restrictions on stack sizes.
(LINUX) Must be increased stack with g and ICC ??? or only ICC ???
I have see in www that some users same problem..
make the test with compile wrapped mpich2 if really problem stack
can be showed appropriate message i think.
I not dispute that you think about your interpretation errors ,can be true
Only the message that you give not corresponding overflow stack
I can reproduce same style errors (ton errors) when i make manually lib .SO or.a with ( ar,ranlib... ext...) and depending header incorrect (repertory) patched..
i am with doubt and interesting to understandor confirmif icc take greater part of stack that gcc ??
(without Tbb,Mpi or Omp or ClooG ext...)
Best regards

Added
you answer....
Well I agree, but in this case its not our program thats requiring huge stack space, its intel's compiler.
Can not be icc ,you receiving messages errors from compiler , if compiler in status overflow you receiving (stack overflow..) from the system.
if really stack problem ? is in your program ...

[jdictos]

Honestly, not sure what you are arguing about here. I'm just reporting a crash in the intel compiler when we are compiling our application, with the -pch option(s).

The only reason I was thinking it was related to the stack size limit, is because on Linux (we compile the same application on linux, as well as osx, and windows), we had a similar problem, and by issuing a "ulimit -s unlimited", prior to using the intel compiler, the problem went away.

[aazue]

Quoting - jdictos

Honestly, not sure what you are arguing about here. I'm just reporting a crash in the intel compiler when we are compiling our application, with the -pch option(s).

The only reason I was thinking it was related to the stack size limit, is because on Linux (we compile the same application on linux, as well as osx, and windows), we had a similar problem, and by issuing a "ulimit -s unlimited", prior to using the intel compiler, the problem went away.

Hi jdictos
Not problem, resulting probably my bad control for correctly understand English language..
also i think my help translator program must increase size stack.. for better results ......
Best regards

[jdictos]

Quoting - bustaf

also i think my help translator program must increase size stack.. for better results ......

Haha