"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:

"David Abrahams" <dave@boost-consulting.com> wrote in message news:ulksobi0k.fsf@boost-consulting.com...

...

In trying to run release-build regression tests on the Serialization library, I found a Borland 5.6 crasher in the test library. It's surely a codegen bug, but it left me wondering why, if I have to link to the test library anyway, the library is putting retrieve_framework_parameter in an unnamed namespace, making me compile it into each **translation unit** of my test. This non-templated function, it seems to me, could be compiled into the test library.

I am not quite sure what you are talking about. retrieve_framework_parameter is defined in unit_test_parameters.ipp and is not supposed to appear in any other translation unit.

An ipp file is not typically a translation unit by itself. It is included by test_tools.hpp, which gets included in many of the serialization tests... or at least, it is indirectly included by libs/serialization/test/test_exported.cpp, and the only test header I can see there is boost/test/test_tools.hpp. I assume more than one TU are allowed to include test_tools.hpp.

...

Among other things, would allow the test library author to handle the codegen bug once and for all (e.g. by specifying build requirements).

Among other things you could mention what bug and what building requirements you are referring to.

I don't know how to describe the bug; the test program crashes inside the initialization of a vector inside of retrieve_framework_parameter. The following build command reproduces the problem for me: myjam -sTOOLS="borland" -sSPIRIT_ROOT=c:/src/spirit-1.6 -sBUILD="release <debug-symbols>on" -sBOOST_ARCHIVE_LIST=text_archive.hpp test_exported_text_archive -- dave Abrahams Boost Consulting www.boost-consulting.com

"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:

...

An ipp file is not typically a translation unit by itself.

Ignoring technicalliy it is in my case.

I don't know what you mean.

...

It is included by test_tools.hpp

It's not. unit_test_parameters.ipp is only included by ":included" components of Boost.Test.

I don't know what that means either.

...

which gets included in many of the serialization tests... or at least, it is indirectly included by libs/serialization/test/test_exported.cpp, and the only test header I can see there is boost/test/test_tools.hpp.

So, if not via test_tools.hpp, then how does it end up in that translation unit?

I assume more than one

...

TU are allowed to include test_tools.hpp.

Yes.

Although if your claim is true (that unit_test_parameters.ipp isn't included by test_tools.hpp) that's irrelevant.

...

...

...

Among other things, would allow the test library author to handle the codegen bug once and for all (e.g. by specifying build requirements).

Among other things you could mention what bug and what building requirements you are referring to.

I don't know how to describe the bug; the test program crashes inside the initialization of a vector inside of retrieve_framework_parameter. The following build command reproduces the problem for me:

myjam -sTOOLS="borland" -sSPIRIT_ROOT=c:/src/spirit-1.6 -sBUILD="release <debug-symbols>on" -sBOOST_ARCHIVE_LIST=text_archive.hpp test_exported_text_archive

I couldn't find this target in appropriate Jamfile

That's because you're not a human Jam interpreter. It's in there.

and I don't have spirit to replicate the error.

So download it. It takes about ten seconds over a fast connection. Or don't, if you don't want to look at this problem. But my question remains: why is that function in a header when it could be compiled into the library? Seems pretty inefficient, at least for Boost, which runs many many tests using your library, to compile that function body over and over. -- Dave Abrahams Boost Consulting www.boost-consulting.com

"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:

"David Abrahams" <dave@boost-consulting.com> wrote in message news:m2d5e05btv.fsf@coppi.local...

...

"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:

...

...

An ipp file is not typically a translation unit by itself.

Ignoring technicalliy it is in my case.

I don't know what you mean.

My TU is

#define BOOST_TEST_SOURCE #include <boost/test/impl/unit_test_parameters.ipp>

OK. Not important.

...

...

...

It is included by test_tools.hpp

It's not. unit_test_parameters.ipp is only included by ":included" components of Boost.Test.

I don't know what that means either.

"included" means here a single header that includes whole implementation of Boost.Test component. For example

boost/test/included/unit_test.hpp

Okay.

...

...

...

which gets included in many of the serialization tests... or at least, it is indirectly included by libs/serialization/test/test_exported.cpp, and the only test header I can see there is boost/test/test_tools.hpp.

So, if not via test_tools.hpp, then how does it end up in that translation unit?

No idea. Maybe you somehow modified sources? Or maybe compiler somehow peaks into implementation (I expirienced something similar with sunpro compiler). Though I don't know how is it possible.

Well, looking at the preprocessed sources, I don't see it there. So I must've been wrong about that all along.

...

...

and I don't have spirit to replicate the error.

So download it. It takes about ten seconds over a fast connection. Or don't, if you don't want to look at this problem.

I don't even know where to look for it.

I gave you the exact command to launch that test. What more do you need?

...

But my question remains: why is that function in a header when it could be compiled into the library? Seems pretty inefficient, at least for Boost, which runs many many tests using your library, to compile that function body over and over.

IT'S NOT. Why are you so sure it's my problem?

W.R.T. the above paragraph, I'm sorry. I must've mis-analyzed the situation. I don't think the crash is your problem exactly; it's surely a codegen bug. However, I believe it's in your power to work around the bug.

Gennadiy

P.S. I do have an access to borland 5.6.4. And I do not have any problems compiling with it.

The only compile-time problem here is in the compiler. You can only experience that problem at runtime :) -- Dave Abrahams Boost Consulting www.boost-consulting.com

"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:

"David Abrahams" <dave@boost-consulting.com> wrote in message news:uirnq7tta.fsf@boost-consulting.com...

...

...

...

...

and I don't have spirit to replicate the error.

So download it. It takes about ten seconds over a fast connection. Or don't, if you don't want to look at this problem.

I don't even know where to look for it.

I gave you the exact command to launch that test. What more do you need?

I do not know the location of spirit

http://spirit.sourceforge.net/download.html. For Borland you want Spirit 1.6.3.

...

...

...

But my question remains: why is that function in a header when it could be compiled into the library? Seems pretty inefficient, at least for Boost, which runs many many tests using your library, to compile that function body over and over.

IT'S NOT. Why are you so sure it's my problem?

W.R.T. the above paragraph, I'm sorry. I must've mis-analyzed the situation. I don't think the crash is your problem exactly; it's surely a codegen bug. However, I believe it's in your power to work around the bug.

At the moment I do not see why you came to this conclusion. I do not see indication this could/should be addressed in Boost.Test sources.

Not in the sources, but in the build requirements. You could turn off optimization in the release build for borland, for example.

...

...

P.S. I do have an access to borland 5.6.4. And I do not have any problems compiling with it.

The only compile-time problem here is in the compiler. You can only experience that problem at runtime :)

According to metacomm regression tests run all my unit test that supposed to work for this compiler work. And I don't know about any runtime problems with specifying CLA either.

Sorry, I don't know what CLA have to do with it. -- Dave Abrahams Boost Consulting www.boost-consulting.com

"Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote in message news:e5bbmb$p1i$1@sea.gmane.org...

...

...

At the moment I do not see why you came to this conclusion. I do not see indication this could/should be addressed in Boost.Test sources.

Not in the sources, but in the build requirements. You could turn off optimization in the release build for borland, for example.

Since I do not explecetly turn off any optimization and not failiar closely

Sorry - meant "turn on"

"David Abrahams" <dave@boost-consulting.com> wrote in message news:u64jq5n2j.fsf@boost-consulting.com...

"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:

...

...

...

At the moment I do not see why you came to this conclusion. I do not see indication this could/should be addressed in Boost.Test sources.

Not in the sources, but in the build requirements. You could turn off optimization in the release build for borland, for example.

Since I do not explecetly turn off any optimization and not failiar closely with this compiler somebody else will have to do this (if it's possible)

Sheesh, Gennadiy. You don't have to be familiar with the compiler; that's the whole point of Boost.Build. Just use

<borland><*><optimization>off

You may find it difficult to believe, but I am no expect in Boost Build and above not something I could come up with on my own. I don't even understand 100% what it means.

in your build requirements. Or maybe you need

<borland><*><inlining>off.

And for BBv2 it'd be, e.g.

<toolset>borland:<inlining>off

And about BBv2 I know nothing at all. I never wrote single Jamfile for it. I don't even know where this should be put at. Do you want me to put these lines in Jamfile? I need specific instructions. But, even better, commit it in yourself (by "yourself" I mean somebody familiar with Boost Build). Gennadiy