-pch option always causes compiler to crash, or other strange errors
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<const _Tp *> [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<const _Tp *> [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.
| |
Re: -pch option always causes compiler to crash, or other strange errors
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
| |
Re: -pch option always causes compiler to crash, or other strange errors
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
prevent pre-compiled headers 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 with pre-compiled header 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
| |
Re: -pch option always causes compiler to crash, or other strange errors
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?
| |
Re: -pch option always causes compiler to crash, or other strange errors
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
| |
Re: -pch option always causes compiler to crash, or other strange errors
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
| |
Re: -pch option always causes compiler to crash, or other strange errors
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.
| |
Re: -pch option always causes compiler to crash, or other strange errors
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, sometime i use Make with option
--jobs-=16 and i have not problem stack, Probably I 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
| |
Re: -pch option always causes compiler to crash, or other strange errors
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.
| |
Re: -pch option always causes compiler to crash, or other strange errors
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
understand or confirm if 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 ...
| |
Re: -pch option always causes compiler to crash, or other strange errors
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.
| | |
