"Roland Schwarz" <roland.schwarz@chello.at> wrote in message news:457D58D3.4020802@chello.at...

I am getting even more errors when doing

bjam --v2 toolset=msvc-6.6 in libs/test/test

Complaints about base classes missing and zero divisions and the like...

What is msvc-6.6?? Gennadiy

"Roland Schwarz" <roland.schwarz@chello.at> wrote in message news:457D8E00.3090006@chello.at...

Gennadiy Rozental wrote:

...

What is msvc-6.6??

a typo. 6.5 of course.

Compare with regression results. If some of the tests failing that are passing in regression tables, you probably doing something wrong. Gennadiy

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

"Anthony Williams" <anthony_w.geo@yahoo.com> wrote in message news:hcw2ehd4.fsf@yahoo.com...

...

Hi all,

There are a lot of tests that are causing Internal Compiler Errors on msvc-6.5~release. Several of them are in the tests for the test library itself, such as this one:

http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/ou...

and this one:

http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/ou...

Both these failures occur on a seemingly innocuous BOOST_CHECK_EQUAL.

Any ideas?

I don't have this compiler anymore. Someone interested in msvc 6.5 need to look into this.

Why is this happening now, as we approach release? Did Boost.Test unfreeze on the release branch, or did tests for this compiler just come online, or is it something else? -- Dave Abrahams Boost Consulting www.boost-consulting.com

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

"David Abrahams" <dave@boost-consulting.com> wrote in message

...

Why is this happening now, as we approach release? Did Boost.Test unfreeze on the release branch, or did tests for this compiler just come online, or is it something else?

Don't really know. I did not make any changes. Guys introduced some minor fixes with dllexport/dllimport declarators, but that about it.

Can you force-disable inlining on that compiler in your library binary (or something like that) so that these failures turn into passes? -- 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:87vekfkgsz.fsf@pereiro.luannocracy.com...

...

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

...

"David Abrahams" <dave@boost-consulting.com> wrote in message

...

Why is this happening now, as we approach release? Did Boost.Test unfreeze on the release branch, or did tests for this compiler just come online, or is it something else?

Don't really know. I did not make any changes. Guys introduced some minor fixes with dllexport/dllimport declarators, but that about it.

Can you force-disable inlining on that compiler in your library binary (or something like that) so that these failures turn into passes?

First of all I am not sure what you suggesting. What inlining? And how is it related to the problems we experience?

And second I'd prefer not to make blind changes. IOW someone with compiler access need to make and test any changes we could agree upon.

I can test changes. I just don't have the time to investigate the cause. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk

Rene Rivera <grafikrobot@gmail.com> writes:

David Abrahams wrote:

...

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

Why is this happening now, as we approach release? Did Boost.Test unfreeze on the release branch, or did tests for this compiler just come online, or is it something else?

I think it's just the difference of building the tests with the release variant, i.e. the optimizations.

I see, thanks. -- Dave Abrahams Boost Consulting www.boost-consulting.com

David Abrahams <dave@boost-consulting.com> writes:

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

...

"Anthony Williams" <anthony_w.geo@yahoo.com> wrote in message news:hcw2ehd4.fsf@yahoo.com...

...

Hi all,

There are a lot of tests that are causing Internal Compiler Errors on msvc-6.5~release. Several of them are in the tests for the test library itself, such as this one:

http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/ou...

and this one:

http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/ou...

Both these failures occur on a seemingly innocuous BOOST_CHECK_EQUAL.

Any ideas?

I don't have this compiler anymore. Someone interested in msvc 6.5 need to look into this.

Why is this happening now, as we approach release? Did Boost.Test unfreeze on the release branch, or did tests for this compiler just come online, or is it something else?

I appear to be the only regression test runner doing "release" builds --- these toolsets are all tagged ~release to differentiate them from everyone else, at Thomas' request. I finally got round to adding in msvc-6.5 and msvc-6.5~release last week, and Boost.Test appears to be broken on msvc-6.5~release, causing Internal Compiler Errors. It works fine in the "normal" msvc-6.5 toolset (debug build). Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk

Roland Schwarz <roland.schwarz@chello.at> writes:

Anthony Williams wrote:

...

Both these failures occur on a seemingly innocuous BOOST_CHECK_EQUAL.

I found a note in test_tss.cpp (dated back to bill kempf) saying: // Dont't call BOOST_CHECK_EQUAL directly, as it doesn't appear to // be thread safe. Must evaluate further.

...

Any ideas?

Maybe this is of interest? Maybe someone could "evaluate further" ?

BOOST_CHECK_EQUAL is definitely not thread safe. Nor are most of the BOOST_CHECK macros. I haven't tested all of them. The thread-lib tests, are careful to protect such usage with a mutex. In any case, the problems here are in just about every library, and most of the tests are not threaded. In particular, there are a lot of ICE failures in the tests of the test lib. This does not bode well for the testing the rest of boost on msvc-6.5~release. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk

"Roland Schwarz" <roland.schwarz@chello.at> wrote in message news:457DA1F3.2070003@chello.at...

Anthony Williams wrote:

...

In particular, there are a lot of ICE failures in the tests of the test lib.

Sorry, my innocent question: what are ICE failures?

Internal Compiler Error

"Roland Schwarz" <roland.schwarz@chello.at> wrote in message news:457DB8DF.8080509@chello.at...

Gennadiy Rozental wrote:

...

Internal Compiler Error

Oh, thank you.

If these are MT related issues, why then would they affect only msvc-6.5?

I don't think they are related. Marjory of Boost unit tests excluding Boost.Thread lib are single threaded as far as I know. Gennadiy

Roland Schwarz <roland.schwarz@chello.at> writes:

Anthony Williams wrote:

...

Hi all,

There are a lot of tests that are causing Internal Compiler Errors on msvc-6.5~release. Several of them are in the tests for the test library itself, such as this one:

I reproduced the error locally, and then I found the following:

http://support.microsoft.com/kb/226110

Does us that help in any way?

I don't think so. The line number of the error is different (main.c line 494 rather than msc1.cpp line 1794). Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk

Roland Schwarz <roland.schwarz@chello.at> writes:

Anthony Williams wrote:

...

I don't think so. The line number of the error is different (main.c line 494 rather than msc1.cpp line 1794).

True. I got the 1794 after having tried to run with <optimization>off.

I've not seen that in what I've tried.

The compiler help tells to run with /Bd to show the phase. Trying this gives me an access violation message box.

Same here.

However the original message also indicates the P2 phase, which the compiler help pages says could be related to optimization.

Yes. It's the /Ob1 inline expansion switch (implied by /Ox or /O2) that causes the problem. Pretty much any combination of other optimization switches is fine. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk

Roland Schwarz <roland.schwarz@chello.at> writes:

Anthony Williams wrote:

...

I don't think so. The line number of the error is different (main.c line 494 rather than msc1.cpp line 1794).

This one is about line 494: http://support.microsoft.com/?scid=kb%3Ben-us%3B259244&x=13&y=11

Hmm __assume() ?

I saw that, and figured it wasn't relevant because of the __assume. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk

Roland Schwarz <roland.schwarz@chello.at> writes:

Replacing:

BOOST_CHECK_EQUAL(a,b)

by

BOOST_CHECK(a == b)

also makes the internal compiler error go away...

Gennadiy, what do you think about #define BOOST_CHECK_EQUAL(a,b) BOOST_CHECK((a) == (b)) for this compiler? -- Dave Abrahams Boost Consulting www.boost-consulting.com

Gennadiy Rozental wrote:

We could do this #if !defined(NDEBUG) && BOOST_WORKAROUND(BOOST_MSVC,<=1200)

I put into "test_tools.hpp" : #if defined(NDEBUG) && BOOST_WORKAROUND(BOOST_MSVC, <=1200) #define BOOST_WARN_EQUAL( L, R ) BOOST_WARN( (L) == (R) ) #define BOOST_CHECK_EQUAL( L, R ) BOOST_CHECK( (L) == (R) ) #define BOOST_REQUIRE_EQUAL( L, R ) BOOST_REQUIRE( (L) == (R) ) #else #define BOOST_WARN_EQUAL( L, R ) \ BOOST_CHECK_WITH_ARGS_IMPL( ::boost::test_tools::tt_detail::equal_impl_frwd(), "", WARN, CHECK_EQUAL, (L)(R) ) #define BOOST_CHECK_EQUAL( L, R ) \ BOOST_CHECK_WITH_ARGS_IMPL( ::boost::test_tools::tt_detail::equal_impl_frwd(), "", CHECK, CHECK_EQUAL, (L)(R) ) #define BOOST_REQUIRE_EQUAL( L, R ) \ BOOST_CHECK_WITH_ARGS_IMPL( ::boost::test_tools::tt_detail::equal_impl_frwd(), "", REQUIRE, CHECK_EQUAL, (L)(R) ) #endif (Sorry the wrong line breaks are from my mailer) Which I tested for libs/thread/test with msvc-6.5 release/debug msvc-7.1 release/debug If you have no objections, I can check this in if you like. Btw.: Do you have anything to say about my asynch-exeptions question? Roland

Gennadiy Rozental wrote:

Heh, I don't really like putting this kinda cludge into Boost.Test code. But if no one sees any alternatives go ahead

If it was only about the threading lib, I have no problems of doing this just for this one library. But what about the others?

...

Btw.: Do you have anything to say about my asynch-exeptions question?

Umm, I must've missed it. What was it?

The test lib is being built with <asynch-exeptions>on. However the default for release builds is synchronous exceptions on. I do not know enough about this issue to be able to tell if this could lead to problems when linking them together. I thought you would be able to tell, since I think you have put this requirement into the build of the test lib. Roland

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

"Roland Schwarz" <roland.schwarz@chello.at> wrote in message news:4582E105.4050205@chello.at...

...

Gennadiy Rozental wrote:

...

Heh, I don't really like putting this kinda cludge into Boost.Test code. But if no one sees any alternatives go ahead

If it was only about the threading lib, I have no problems of doing this just for this one library. But what about the others?

...

...

Btw.: Do you have anything to say about my asynch-exeptions question?

Umm, I must've missed it. What was it?

The test lib is being built with <asynch-exeptions>on. However the default for release builds is synchronous exceptions on.

This is plain wrong. build with msvc compiler require async exception support to be enabled for Boost.Test to work properly.

The usage-requirements for the library targets exposed by the test Jamfile should be enforcing that, for those that use BBv2. -- Dave Abrahams Boost Consulting www.boost-consulting.com

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

"Roland Schwarz" <roland.schwarz@chello.at> wrote in message news:4582E105.4050205@chello.at...

...

Gennadiy Rozental wrote:

...

Heh, I don't really like putting this kinda cludge into Boost.Test code. But if no one sees any alternatives go ahead

If it was only about the threading lib, I have no problems of doing this just for this one library. But what about the others?

...

...

Btw.: Do you have anything to say about my asynch-exeptions question?

Umm, I must've missed it. What was it?

The test lib is being built with <asynch-exeptions>on. However the default for release builds is synchronous exceptions on.

This is plain wrong. build with msvc compiler require async exception support to be enabled for Boost.Test to work properly.

Huh? Why? Do you use Windows-native Structured Exception Handling? I thought that was the only reason for allowing async exceptions. Am I misunderstanding something? Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk

Anthony Williams <anthony_w.geo@yahoo.com> writes:

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

...

"Roland Schwarz" <roland.schwarz@chello.at> wrote in message news:4582E105.4050205@chello.at...

...

Gennadiy Rozental wrote:

...

Heh, I don't really like putting this kinda cludge into Boost.Test code. But if no one sees any alternatives go ahead

If it was only about the threading lib, I have no problems of doing this just for this one library. But what about the others?

...

...

Btw.: Do you have anything to say about my asynch-exeptions question?

Umm, I must've missed it. What was it?

The test lib is being built with <asynch-exeptions>on. However the default for release builds is synchronous exceptions on.

This is plain wrong. build with msvc compiler require async exception support to be enabled for Boost.Test to work properly.

Huh? Why? Do you use Windows-native Structured Exception Handling? I thought that was the only reason for allowing async exceptions. Am I misunderstanding something?

Yes, the Test library uses it to catch program bugs like invalid pointer dereferences. -- Dave Abrahams Boost Consulting www.boost-consulting.com

Anthony Williams wrote:

That's good as a workaround. It loses some of the error message benefits, but it's better than a compiler fault.

I tried to carefully follow the suggestions on the compiler help page for ICE's in P2: Turn off all optimizations (/O...) until the error goes away, then turn each one on. So I arrived at: <inlining>off This gives a clean compile. So it should be sufficient for this compiler to run the tests with this option. The page further suggest to find the function where the fault actually is triggered and disable the optimization by guarding with pragmas. I don't know if it is worth the effort. Since the compiler can be expected to be retired after RC_1_34_0 release. Yes? But what, if the error is not related to the test library? Would users compiling <variant>release be affected too? Another thing I noticed: The test library is built with <asynch-exceptions>on while every other is with synch exceptions (/EHs). I do not know about this issue to tell if it is a problem. Roland

David Abrahams wrote:

It would be better to modify the library so it didn't crash the compiler when inlining was enabled.

I just found out, that even in debug builds, i.e. NDEBUG is not defined, <inlinig>on will crash the compiler. So I strip also the #if defined(NDEBUG) and condition only on the compiler version. Roland

David Abrahams said: (by the date of Sat, 16 Dec 2006 17:20:02 -0500)

Roland Schwarz <roland.schwarz@chello.at> writes:

...

David Abrahams wrote:

...

It would be better to modify the library so it didn't crash the compiler when inlining was enabled.

I just found out, that even in debug builds, i.e. NDEBUG is not defined, <inlinig>on will crash the compiler.

So I strip also the #if defined(NDEBUG) and condition only on the compiler version.

Gennadiy, are you listening?

It is possible that he has a filter set up, that deletes any incoming email with word s p a m in the subject.... (spaces to fool his filter :) -- Janek Kozicki |