1>D:\\Lucru\\Unelte\\wxWidgets-2.8.8\\src\\common\\string.cpp(716) (col. 1): internal error: 0_1599
1>compilation aborted for ..\\..\\src\\common\\string.cpp (code 4)
part of string.cpp:
[bash]714:wxStringBase& wxStringBase::replace(size_t nStart, size_t nLen,Compiling in debug mode works fine. Is this a known issue and is there some work around?
715: const wxChar *sz)
717: wxASSERT_MSG( nStart <= length(),
718 _T("index out of bounds in wxStringBase::replace") );
I did not get this error with 11.1 latest compiler or even 1-2 minor releases (11.1 ) before that.
I tried with both Debug & Release build and used 2008 IDE.
Did you change anything in Project Properties etc etc.
Please try using latest 11.1 compiler.
Since the application is very huge, you can just go to
And you would be able to test compilation in a few seconds.
I think I did a mistake. I used 32-bit , and I think what you asked was for 64-bit.
Anyhow, in case you know about the build result for 32-bit, or used 11.1 compiler, please let me know.
I even could not reproduce your issue in Intel64 with 11.0.066 or 11.1 compilers.
(please tell architecture also, eg., are you testing in Itanium-64, AMD64 etc?? )
I also tested using Release & Debug builds.
Are you using batch builds, or DLL configuration or something?
What are the steps & configuration you are using to buildthewholeproject.
I am also using wxwidgets 2.8.8 release.
Please let me know , your environment, machine, and steps in more detail, for me to reproduce at my end.
I am using wxwidgets 2.8.8, I have an Intel Quad COre Q9450 (so I assume AMD64 - or how does intel call its 64 bit architecture because everytime I download smth I selected the AMD64 arhitecture) and Windows XP Professional 64-bit with Microsoft Visual Studio 2005. Debug version works, but I cannot compile the base project in release. I have not changed a thing in the project settings...they are I have downloaded them. Some compile options in the project:
Run-Time Library: Multi-threaded DLL (/MD)
Optimization: Maximize Speed (/O2)
Inline Function Expansion: Only __inline (/Ob1)
All Intel Specific options are Set to :"No" except
Floating-Point Speculation: Fast (/Qfp-speculationfast)
/c /O2 /Ob1 /I "..\..\lib\vc_lib\msw" /I "..\..\include" /I "..\..\src\tiff" /I "..\..\src\jpeg" /I "..\..\src\png" /I "..\..\src\zlib" /I "..\..\src\regex" /I "..\..\src\expat\lib" /D "WIN32" /D "_LIB" /D "__WXMSW__" /D "wxUSE_GUI=0" /D "wxUSE_BASE=1" /D "_VC80_UPGRADE=0x0600" /GF /EHsc /MD /GS /Gy /fp:fast /Fo".\vc_msw\base/" /W4 /nologo /Qfp-speculationsafe /EHsc
I also tried compiling sans precompiled header. I still receive the error.
To my knowledge, precompiled headers (and also IPO/lto/whole program optimization) aren't compatible between MSVC and ICL objects, so you can't use them when you are using both compilers, and must allow the entire project to be rebuilt if you shift compilers while using them.
/fp:fast in MSVC is roughly equivalent to /fp:source in ICL, while /fp:fast is more aggressive.
Any internal error report from the compiler is a defect, even if it comes out from erroneous usage, so Milind was hoping you would give sufficient information for him to reproduce it. The questions you would have to answer, should you file the report on premier.intel.com, are intended to help in that respect.
Ok. It reproduces with the default options that came with the download, with the Release build.
I forgot to change Win32 to X64 configuration platform, and hence missed that error. Now it reproduces, quite easily.
internal error: 0_1599 with string.cpp .
Will look at how it could be escalated as a minimal test-code, and would keep you in the loop.
Thanks for the issue, and sorry for the confusion.
I noticed this error only with 11.0 .
Others such as 10.1 or 11.1 does not reproduce this error, reason I do not know.
If you could download 11.1 compiler at your end, and confirm this thing, it would carry more weight to escalate this internal error if it comes.
Also, try not using
Secondly, if you want to use Precompiled headers, I think in the same drop-down , select
And its not easy to classify this error as it comes from within the compiler itself , eg. due to stack it cannot allocate, or exceptions/crash inside its own code, or other ways the compiler code itself is at fault.
For general brief on this typical error, you can see this link:--
As the reason is unknown, to fix it will be needed a minimal test-code, and that was the reason I tried with latest compiler 11.1 to check whether this works, and let you know so you could use it straightway.
Also, I did some search through our defect records and did not see bug filed with 0_1599 code for the internal error.