Multi-file optimization - bug ???

Multi-file optimization - bug ???

Hi,

Sorry, I am writing about the problem that was presented in the forum last year (Mar 24, 2002), but in my opinion the problem is very important for peoples using standard input-output operation and that need fast run-time code. Meanwhile I have changed Microsoft Compiler and Intel Compiler ? now I use the newest Microsoft Visual C++ NET 2003 and Intel C++ 7.1.018, but the problem is not resolved so far.

The problem appears when we try to compile a program that uses the standard input-output operation cin and cout and the stringstream container (see my program below) with multi-file optimizations. This program works well if it is compiled by Visual C++ NET or by Intel C++ 6.0, 7.0 or 7.1 compiler without multi-file optimizations. But if this program is compiled by Intel C++ 6.0, 7.0 or 7.1 with /Qipo options (multi-file optimizations) I am getting run-time error.

Debugger shows that error is in ostream standard header in line 44:

explicit basic_ostream(basic_streambuf<_Elem, _Traits> *_Strbuf,
bool _Isstd = false)
{ // construct from a stream buffer pointer
_Myios::init(_Strbuf, _Isstd);
}

Could somebody tell me where is the error: in Intel compiler or in Visual Studio C++ .NET?
Any ideas anyone, as we compile programs having stringstream containers and input-output operations cin and cout with multi-file optimizations.

My program:

//test-io.cpp
#include
#include "classA.h"
main()
{
using namespace std;
classA A;
cout<<"Test done"<//..
return 0;
}
///////////////////////////////
//classA.cpp
#include "classA.h"
classA::classA()
{
using namespace std;
cout<<"ClassA done"<//..
}
////////////////////////////
//classA.h
#include
#include
class classA {
public:
std::stringstream header;
classA();
};
///////////////////////

Even simpler program having only one file and using iostream and stringstream (or fstream) generate the same problem !

For example, look at the program:

//test-io2.cpp
#include
#include
#include

main()
{
using namespace std;
stringstream header;
fstream inoutput;
clog<<"Done"<return 0;
}
////

If I use -Qipo and -Od (no optimize) options this program works, but if I use -Qipo
and -O1, -O2 or -O3 options I get run-time error:
Unhandled exception at 0x00401af9 in test-io2.exe: 0xC0000005: Access violation reading location 0x00000004.

Debugger shows that error is in ostream standard header in line 44:
explicit basic_ostream(basic_streambuf<_Elem, _Traits> *_Strbuf,
bool _Isstd = false)
{ // construct from a stream buffer pointer
_Myios::init(_Strbuf, _Isstd);
}

The full options list showing by Visual studio is:
Compiler:

a) with /Od option (no optimize) ? program works
/c /GL /Zi /nologo /W3 /Od /Ob1 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /GF /FD /EHsc /ML /GS /Gy /Fo"Release/" /Fd"Release/vc70.pdb" /Gd /TP

b) without /Od option (no optimize) but with /O1, /O2 or /O3 options (optimize) ? program does not work
/c /GL /Zi /nologo /W3 /O2 /Ob1 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /GF /FD /EHsc /ML /GS /Gy /Fo"Release/" /Fd"Release/vc70.pdb" /Gd /TP

Linker:
/NOLOGO /LTCG /OUT:"Release/test-io2.exe" /INCREMENTAL:NO /DEBUG /PDB:"Release/test
-io2.pdb" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /TLBID:1 /MACHINE:IX86 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

The same error I am getting in program test-io2 then I remove lines:

#include
and
stringstream header;

or lines:

#include
fstream inoutput;

So, I have question:
Is it possible to use multi-file optimizations and speed optimization (-O3) of program that uses the standard input-output operation cin and cout and the stringstream container ???

Thanks,

Jerzy

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Looks like ICL 7.1 optimization bug because of latest ICL 8.0 beta produces EXE without any Access Violation for all your examples.

Is ICL 8.0 beta available for tests? If yes, how I can get it.
The newest version available for me is ICL 7.1.018 (from Intel Premium Support).

I found the reason of this access violation (and found several possible workarounds :). It is really ICL 7.1 IPO bug. Test program is using fsream (or stringstream) which have base class basic_iostream with bases basic_istream (the first) and basic_ostream (the second). Each of them has virtual public base basic_ios with diffrence that basic_isream should initialize virtual base (corresponding parameter is equal to 1) and basic_ostream - not (parameter value = 0). IPO optimizer works in such a way that basic_istream code ALWAYS initialize basic_ios and basic_ostream - NEVER doing so.
But the same basic ostream code is called in startup during cout initialization (with parameter value = 1).
But conditional check for virtual base is absent in code (due to IPO optimization) and we have Access Violation.

Tricky is that both .obj and .asm files produced using
additional /Qipo_c or /Qipo_S (and object part of combined
file obtained using /Qipo_obj) CONTAIN this conditionally virtual base initialization, error is only in mock code.

So there are possible workarounds:
1. Use 2 stage compile/link process.
Compilation is with additional /Qipo_c switch (produces
ipo_out.obj file). and link stages uses ordinary MS link
with this ipo_out.obj.
2. Add fake ostream in the user code.
//test-io2.cpp
#include
#include
#include

main()
{
using namespace std;
//Fake ostream
stringbuf sb;
ostream os(&sb);
//
stringstream header;
fstream inoutput;
cout<<"Done"<return 0;
}
This ostream inclusion results to valid basic_ostream code.

Leave a Comment

Please sign in to add a comment. Not a member? Join today