Long list of failures at http://tinyurl.com/8pbw5 It looks as if non-equlity operator fails for all member functions Compiler used is release (not RC nor beta; it's RTM recently published in MSDN downloads) version. Error won't go away with new compiler build, as there won't be any in forseeable future. Peter, do you need help tracing this error? B.
Bronek Kozicki wrote:
Long list of failures at http://tinyurl.com/8pbw5 It looks as if non-equlity operator fails for all member functions
Compiler used is release (not RC nor beta; it's RTM recently published in MSDN downloads) version. Error won't go away with new compiler build, as there won't be any in forseeable future.
Peter, do you need help tracing this error?
This is either a compiler bug, or it is the linker folding the two member functions into one. I'm not sure whether we need to do anything to address the failure; the behavior looks decidedly non-conforming to me. You should report it to MS.
"Peter Dimov" <pdimov@mmltd.net> skrev i meddelandet news:00ac01c5df98$aa43f2d0$6401a8c0@pdimov2...
Bronek Kozicki wrote:
Long list of failures at http://tinyurl.com/8pbw5 It looks as if non-equlity operator fails for all member functions
Compiler used is release (not RC nor beta; it's RTM recently published in MSDN downloads) version. Error won't go away with new compiler build, as there won't be any in forseeable future.
Peter, do you need help tracing this error?
This is either a compiler bug, or it is the linker folding the two member functions into one.
The linker is known to fold identical code blocks. That is MS' way of removing redundant instantiatiations of the same template. A side effect is removing some instantiations of different templates.
I'm not sure whether we need to do anything to address the failure; the behavior looks decidedly non-conforming to me. You should report it to MS.
They already know about it. Bo Persson
Bo Persson wrote:
"Peter Dimov" <pdimov@mmltd.net> skrev i meddelandet news:00ac01c5df98$aa43f2d0$6401a8c0@pdimov2...
I'm not sure whether we need to do anything to address the failure; the behavior looks decidedly non-conforming to me. You should report it to MS.
They already know about it.
They know about what? Link?
"Peter Dimov" <pdimov@mmltd.net> skrev i meddelandet news:00a901c5dfdf$683e1f90$6401a8c0@pdimov2...
Bo Persson wrote:
"Peter Dimov" <pdimov@mmltd.net> skrev i meddelandet news:00ac01c5df98$aa43f2d0$6401a8c0@pdimov2...
I'm not sure whether we need to do anything to address the failure; the behavior looks decidedly non-conforming to me. You should report it to MS.
They already know about it.
They know about what? Link?
It is known that the linker optimizations remove identical code blocks to save code space. See /OPT:ICF in the linker reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html... MS only claims about 98% conformance, so some non-conformance is to be expected. :-( Bo Persson
Bo Persson wrote:
It is known that the linker optimizations remove identical code blocks to save code space. See /OPT:ICF in the linker reference:
I have three ideas: 1. make body of test functions different (tricky, as compiler might optimize away anything that does not have detectable side-effects) or 2. put information in the XML that failure is expected together with explanation 3. compile regression test without this particular optimization (hm, I thought that regression tests do not run optimized code?) Personally I would prefer 3 B.
Bronek Kozicki wrote:
Bo Persson wrote:
It is known that the linker optimizations remove identical code blocks to save code space. See /OPT:ICF in the linker reference:
I have three ideas: 1. make body of test functions different (tricky, as compiler might optimize away anything that does not have detectable side-effects) or 2. put information in the XML that failure is expected together with explanation 3. compile regression test without this particular optimization (hm, I thought that regression tests do not run optimized code?)
Personally I would prefer 3
(2) is the way to go, IMO.
Bo Persson wrote:
"Peter Dimov" <pdimov@mmltd.net> skrev i meddelandet news:00a901c5dfdf$683e1f90$6401a8c0@pdimov2...
Bo Persson wrote:
"Peter Dimov" <pdimov@mmltd.net> skrev i meddelandet news:00ac01c5df98$aa43f2d0$6401a8c0@pdimov2...
I'm not sure whether we need to do anything to address the failure; the behavior looks decidedly non-conforming to me. You should report it to MS.
They already know about it.
They know about what? Link?
It is known that the linker optimizations remove identical code blocks to save code space. See /OPT:ICF in the linker reference:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html...
Yes, this is well known; but the fact that VC8 as shipped fails a Boost test may be unknown to them. It wasn't clear to me which of the two you had in mind. It should be possible to not fold blocks that have both of their addresses taken, so they (MS) may consider fixing it if it's reported.
At 17:08 2005-11-02, Bronek Kozicki wrote:
Peter Dimov wrote:
Yes, this is well known; but the fact that VC8 as shipped fails a Boost test may be unknown to them. It wasn't clear to me which of the two you had in
yet another reason to ask them to run regression tests before support for vc8 goes official
has the problem been fixed? the results from metacomm show that my run at 2005/11/02T2200 has no failures in bind.
B. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
On 11/3/05, Victor A. Wagner Jr. <vawjr@rudbek.com> wrote:
has the problem been fixed? the results from metacomm show that my run at 2005/11/02T2200 has no failures in bind.
I can definitely see failed test in my today's results. B. -- Bronek Kozicki brok@spamcop.net http://b.kozicki.pl/
I wrote:
I can definitely see failed test in my today's results.
on second thought, maybe "-sBUILD=<debug-symbols>off" passed to bjam is responsible for the problem? I will rerun vc8 tests without this option B. -- Bronek Kozicki brok@spamcop.net http://b.kozicki.pl/
on second thought, maybe "-sBUILD=<debug-symbols>off" passed to bjam is responsible for the problem? I will rerun vc8 tests without this option
I just checked, and yes, I can confirm that problem is due to this option. Without it the test passes. B. -- Bronek Kozicki brok@spamcop.net http://b.kozicki.pl/
participants (5)
-
Bo Persson -
Bronek Kozicki -
Bronek Kozicki -
Peter Dimov -
Victor A. Wagner Jr.