21.string.cons.cpp test fails on 64-bit MSVC (8.0 and 9.0)
The 21.string.cons.cpp test fails with 16 assertions on 64-bit MSVC
(8.0 and 9.0).
http://people.apache.org/~sebor/stdcxx/results/win_xp_1-em64t-msvc-8.0.h
tml
http://people.apache.org/~sebor/stdcxx/results/win_2003_1-em64t-msvc-8.0
.html
http://people.apache.org/~sebor/stdcxx/results/win_vista_0-em64t-msvc-8.
0.html
The reason is the bad code generation of the compiler. JIRA is not
available
at the moment, so I'll create the issue later. Unfortunately I cannot
make
the simple testcase to reproduce the problem. The problem detected only
in
optimized builds (8{s|d}, 12{s|d}). As the temporary workaround might be
definition of the __rw::__rw_new_capacity as __declspec (noinline).
Also maybe this problem would be accidentally fixed thus resolving the
issue named something like floating point operation in
__rw_new_capacity
(I've seen this issue before).
--
Index: include/string
===
--- include/string (revision 593511)
+++ include/string (working copy)
@@ -1528,8 +1528,13 @@
// more specialized version for basic_string; may be further
specialized
// in user code for example on a user-defined allocator
+#if !defined (_WIN64) || !defined (_MSC_VER) || defined
(__INTEL_COMPILER)
template class _CharT, class _Traits, class _Allocator
inline _RWSTD_STRING_SIZE_TYPE
+#else// _WIN64 _MSC_VER !__INTEL_COMPILER
+template class _CharT, class _Traits, class _Allocator
+__declspec (noinline) _RWSTD_STRING_SIZE_TYPE
+#endif // !_WIN64 || !_MSC_VER || __INTEL_COMPILER
__rw_new_capacity (_RWSTD_STRING_SIZE_TYPE __size,
const _STD::basic_string_CharT, _Traits,
_Allocator*)
{
--
Farid.
RE: library and build sizes on Windows
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Monday, November 12, 2007 7:18 AM To: stdcxx-dev@incubator.apache.org Subject: library and build sizes on Windows I enhanced the cross-build scripts to extract the date of the build and the sizes of the library and of the bildspace (before and after running the clean target). This works on UNIX but not on Windows where the date has a different format On unix: --- ### date: Wed Oct 31 09:38:50 UTC 2007 --- On windows: --- Wed Nov 07 22:23:49 2007: Loading solution... --- The difference in date format is the only UTC before year on unix :) and the sizes aren't being reported. Would it be possible to change the Windows infrastructure to add this info to the logs? The cleaning targets performing by the BATMAN, so to add the sizes to the logs the BATMAN scripts should be changed. Farid.
RE: [RFC] stdcxx release process, second draft
Overall, I'd say it's a pretty good start. All of the major elements are there: goals/objectives, tasks/procedures, definitions/roles, etc. As it evolves though, you'll probably want to break the process definitions into two separate documents: one for the development process and one for the release process. Also, the versioning policy is currently intwined with the release process. They're closely related of course but they should be more easily distinguished. Were they separate documents at one time? Just my personal preference, but I like to see each policy statement in a separate document since a process is usually defined to enact one or more policies. I also noticed the Version Policy and Definitions are listed in the opposite order in the Index at the top from that given in the content. Brad. -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Monday, November 12, 2007 9:06 PM To: stdcxx-dev@incubator.apache.org Subject: [RFC] stdcxx release process, second draft I've incorporated everyone's feedback and committed an updated version with a number of enhancements of my own. Among the most important are the new Goals section with suggested frequencies of releases, and the integration of the Version Policy (I plan to delete versions.html). Let me know what you think. http://incubator.apache.org/stdcxx/releases.html Martin Sebor wrote: I've checked in the first draft of a document outlining our release process. It should be read along with the versioning policy that was circulated earlier. I would like to integrate both into one coherent policy in the near future and put it in place for 4.2.1. http://incubator.apache.org/stdcxx/releases.html http://incubator.apache.org/stdcxx/versions.html Please respond with suggestions for changes, additions, corrections, comments, and/or questions. Thanks Martin -- View this message in context: http://www.nabble.com/-RFC--stdcxx-release-process-tf4729351.h tml#a13719498 Sent from the stdcxx-dev mailing list archive at Nabble.com.
Re: library and build sizes on Windows
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Monday, November 12, 2007 7:18 AM To: stdcxx-dev@incubator.apache.org Subject: library and build sizes on Windows I enhanced the cross-build scripts to extract the date of the build and the sizes of the library and of the bildspace (before and after running the clean target). This works on UNIX but not on Windows where the date has a different format On unix: --- ### date: Wed Oct 31 09:38:50 UTC 2007 --- On windows: --- Wed Nov 07 22:23:49 2007: Loading solution... --- The difference in date format is the only UTC before year on unix :) Right. The problem is the line above it. The script looks for the RE ^### date: and takes the whole line below it as the date. We could have it look for the Windows-specific string on Windows (and strip what follows the timestamp) and the UNIX one on UNIX but I'd rather we standardize on the same data format than complicate the script logic. and the sizes aren't being reported. Would it be possible to change the Windows infrastructure to add this info to the logs? The cleaning targets performing by the BATMAN, so to add the sizes to the logs the BATMAN scripts should be changed. Okay. We'll move this part (the script that runs the whole build) to stdcxx very soon so we'll have direct control over its format. Martin
RE: [RFC] build result views
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, November 13, 2007 6:18 AM To: stdcxx-dev@incubator.apache.org Subject: [RFC] build result views I'm looking for feedback on the two sets of nightly result pages we currently publish: http://people.apache.org/~sebor/stdcxx/results/ and http://people.apache.org/~sebor/stdcxx/results/builds Specifically, I'm wondering what would people think about replacing the first page with the second, or something like it. Do you find yourself using the first page more or do you prefer the second one, and why? The first page is useful to see the overall status of the library. I'm using it just for sure that Windows builds are green :) Of cource the second page is more convinient to see what examples or tests are failed and how these fails dependent from the build type. I would like to have the possibility to merge the results of the multiple platforms into the one page, i.e.: - all windows builds (MSVC and ICC); - all MSVC builds; - all ICC/windows builds; - all ICC builds (windows and linux); - all MSVC 8.0 build + all gcc 4.2.0 builds; ... It might be realized as the current page (http://people.apache.org/~sebor/stdcxx/results/builds) but with the checkboxes on the each line of the table and button Next somewhere on the page. If neither, how do you analyze build results and why do you find your system preferable to what we have? What does your ideal result page look like? What data should it show and how should it be presented? Farid.
Re: missing build line for 22.locale.codecvt.out
Travis Vitek wrote: [...] So now we are pretty sure we know what is happening. All target names that end in .out will match to the pattern rule for generating .out files first. The question is how to fix it. Here are the options I see. Thanks for the analysis! 1. rename the source file so the generated executable will not end in .out 2. change the .out rule to generate output files with some other extension 3. create an rule that is a better match than %.out so that rule is selected for 22.locale.codecvt.out 4. create a new makefile that includes the original GNUmakefile.tst, but defines the more explicit rule mentioned in 3 I dislike option 3 the most, Between 2 and 3 I think I actually like 3 better. It seems general enough to eliminate all ill-effects of the overly generic %.out: % rule. And it's very simple (at least in my tests it was): %.foo: %.foo.c touch $@ and from the sound of it you won't want to use option 1. So how does option 2 sound? Another possibility might be to enable the %.out: % rule only for examples and disable it for tests and everything else work? We don't need to create .out files anywhere else, do we? Martin
[jira] Updated: (STDCXX-543) test suite failures due excessively long command lines
[ https://issues.apache.org/jira/browse/STDCXX-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-543: Severity: Runtime Error Set severity. test suite failures due excessively long command lines -- Key: STDCXX-543 URL: https://issues.apache.org/jira/browse/STDCXX-543 Project: C++ Standard Library Issue Type: Bug Components: Utilities Affects Versions: trunk Environment: Windows 2000 Reporter: Martin Sebor Assignee: Farid Zaripov Priority: Critical Fix For: 4.2.1 The test infrastructure (the exec utility to be exact) fails on platforms such as Windows 2000 that impose a low limit on the length of the command line. See the following post: http://www.nabble.com/RE%3A-Windows-build-failures-p12508639.html As Farid says in his post, to prevent such failures, excessively long command lines need to be written to a temporary file by the infrastructure and subsequently read from it by the exec utility. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-543) test suite failures due excessively long command lines
[ https://issues.apache.org/jira/browse/STDCXX-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542180 ] Martin Sebor commented on STDCXX-543: - I think we should to be careful when changing the Fix Version/s field so as not to give the impression that the problem still exists. We fixed the test suite failures due to excessively long command lines on Windows 2000 in 4.2.0, so the issue really was completely resolved in 4.2.0. We can (and should) improve the implementation of the fix but that seems like a separate task, unrelated to this issue. test suite failures due excessively long command lines -- Key: STDCXX-543 URL: https://issues.apache.org/jira/browse/STDCXX-543 Project: C++ Standard Library Issue Type: Bug Components: Utilities Affects Versions: trunk Environment: Windows 2000 Reporter: Martin Sebor Assignee: Farid Zaripov Priority: Critical Fix For: 4.2.1 The test infrastructure (the exec utility to be exact) fails on platforms such as Windows 2000 that impose a low limit on the length of the command line. See the following post: http://www.nabble.com/RE%3A-Windows-build-failures-p12508639.html As Farid says in his post, to prevent such failures, excessively long command lines need to be written to a temporary file by the infrastructure and subsequently read from it by the exec utility. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-653) [IBM XLC++ 9.0/AIX 5.3] SIGSEGV in 27.istream.fmat.arith
[
https://issues.apache.org/jira/browse/STDCXX-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor updated STDCXX-653:
Assignee: Travis Vitek
Looks like it might be. In 32-bit (ILP32) builds sizeof(long) sizeof(long
long) but in 64-bit (LP64) ones they are the same size, which does suggest that
there is a relationship. Recent 32-bit build results with XLC++ also are free
of this error.
Travis, could you verify this?
[IBM XLC++ 9.0/AIX 5.3] SIGSEGV in 27.istream.fmat.arith
Key: STDCXX-653
URL: https://issues.apache.org/jira/browse/STDCXX-653
Project: C++ Standard Library
Issue Type: Bug
Components: Tests
Affects Versions: 4.2.0
Reporter: Travis Vitek
Assignee: Travis Vitek
Fix For: 4.2.1
Appears to only affect 32-bit builds.
# INFO (S1) (4 lines):
# TEXT: std::istream::operator(long long)
# CLAUSE: istream.formatted.arithmetic
# LINE: 677
Segmentation fault in memchr.memchr at 0xd020ea10
0xd020ea10 (memchr+0x18) 8ca40001 lbzu r5,0x1(r4)
(dbx) where
memchr.memchr(??, ??, ??) at 0xd020ea10
collate.memchr(const void*,int,unsigned long)(0x, 0x0, 0x1), line 125
in string.h
unnamed block $b702, line 221 in memattr.cpp
unnamed block $b700, line 221 in memattr.cpp
__rw_memattr(const void*,unsigned long,int)(addr = 0x, nbytes =
4294967295, attr = -1), line 221 in memattr.cpp
printf.strlen(const char*)(0x2ff20d58, 0x2ff21420, 0x, 0x,
0x3), line 1939 in printf.cpp
unnamed block $b505, line 2897 in printf.cpp
_rw_vasnprintf_ext(FmtSpec*,unsigned long,Buffer,const char*,VarArgs*)(pspec
= 0x2ff20c08, paramno = 7, buf = (...), fmt = #s, pva = 0x2ff22248), line
2897 in printf.cpp
unnamed block $b520, line 810 in printf.cpp
unnamed block $b518, line 810 in printf.cpp
_rw_pvasnprintf(Buffer,const char*,VarArgs*)(buf = (...), fmt = ,
whitespace = %{#s}, numpunct = { .dp=%{#c}, .ts=%{#c}, .grp=%{#s}, .fn=%{#s},
.tn=%{#s} }, pva = 0x2ff22248), line 810 in printf.cpp
unnamed block $b482, line 3031 in printf.cpp
_rw_fmtexpr(FmtSpec,Buffer,VarArgs*)(spec = (...), buf = (...), pva =
0x2ff22248), line 3031 in printf.cpp
_rw_vasnprintf_ext(FmtSpec*,unsigned long,Buffer,const char*,VarArgs*)(pspec
= 0x2ff21a38, paramno = 0, buf = (...), fmt = $FUNCALL!:@, pva =
0x2ff22248), line 2959 in printf.cpp
unnamed block $b520, line 810 in printf.cpp
unnamed block $b518, line 810 in printf.cpp
_rw_pvasnprintf(Buffer,const char*,VarArgs*)(buf = (...), fmt =
%{$FUNCALL!:@}, pva = 0x2ff22248), line 810 in printf.cpp
rw_vasnprintf(char**,unsigned long*,const char*,char*)(pbuf = 0x2ff222d0,
pbufsize = 0x2ff222d4, fmt = %{$FUNCALL!:@}, varg = ^P!\322\300), line
1013 in printf.cpp
_rw_vfprintf(rw_file*,const char*,char*)(file = (nil), fmt =
%{$FUNCALL!:@}, va = ^P!\322\300), line 3401 in printf.cpp
rw_fprintf(rw_file*,const char*,...)(file = (nil), fmt = %{$FUNCALL!:@},
... = 0x1021d2c0, 0x1, 0x1021d078, 0x1021db24, 0x1021db2c, 0x1), line 3453 in
printf.cpp
27.istream.fmat.arith.void
test_extractorchar,std::char_traitschar,long(char*,std::char_traitschar*,long*,const
char*,const char*,const char*,int,const char*,const char*,unsigned
long,const LocaleData,int,int,int,int,int,int,int,long,long)( = (nil), =
(nil), = (nil), cname = char, tname = std::char_traitschar, aname =
long, line = 489, valfmt = %lli, cbuf = , cbuf_size = 0, locale_data =
(...), flags = 671092738, init_state = 0, exceptions = 0, expect_exception =
0, expect_state = 6, expect_extract = 0, fail_when = 0, init_value = 1,
expect_value = 1), line 331 in 27.istream.fmat.arith.cpp
27.istream.fmat.arith.void
test_extractorchar,std::char_traitschar,long(char*,std::char_traitschar*,long*,const
char*,const char*,const char*,const char*)( = (nil), = (nil), = (nil),
cname = char, tname = std::char_traitschar, aname = long, fmt =
%lli), line 489 in 27.istream.fmat.arith.cpp
27.istream.fmat.arith.void test_llongchar,std::char_traitschar
(char*,std::char_traitschar*,const char*,const char*)( = (nil), = (nil),
cname = char, tname = std::char_traitschar), line 1028 in
27.istream.fmat.arith.cpp
27.istream.fmat.arith.void test_extractorchar,std::char_traitschar
(char*,std::char_traitschar*,const char*,const char*)( = (nil), = (nil),
cname = char, tname = std::char_traitschar), line 1283 in
27.istream.fmat.arith.cpp
run_test(int,char**)( = 1, = 0x2ff22a70), line 1320 in
27.istream.fmat.arith.cpp
rw_vtest(int,char**,const char*,const char*,const
char*,int(*)(int,char**),const char*,char*)(argc = 1, argv = 0x2ff22a70,
file_name =
/amd/devco/vitek/stdcxx-trunk/tests/iostream/27.istream.fmat.arith.cpp,
clause = istream.formatted.arithmetic, comment = (nil), fun = 0x200109a8,
optstr = |-char~
Re: [RFC] build result views
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, November 13, 2007 6:18 AM To: stdcxx-dev@incubator.apache.org Subject: [RFC] build result views I'm looking for feedback on the two sets of nightly result pages we currently publish: http://people.apache.org/~sebor/stdcxx/results/ and http://people.apache.org/~sebor/stdcxx/results/builds Specifically, I'm wondering what would people think about replacing the first page with the second, or something like it. Do you find yourself using the first page more or do you prefer the second one, and why? The first page is useful to see the overall status of the library. I'm using it just for sure that Windows builds are green :) :) That's how I've been using it too. The danger of colorizing entire builds the way we do on that page is in making it easy to miss important failures occurring only in a small number of tests. I.e., you might see green even when a critical piece of the library is broken (recall the recent binary incompatibility with XLC++ exception). Anyway, sounds like adding colorization either to builds.html or to the Logs and Columns table on each Multi-platform Test Result View is one enhancement you'd like to see, correct? What about data? Do you use any of the data from the colorized page? E.g., the number of components (examples, tests, locales) vs the number of those that failed? I personally don't think they are terribly useful but adding them shouldn't be too hard. I do plan on adding the duration column (with a lot more detail, such as how long the library took to build in user, system, and wall clock time, and the same for all examples, the test driver, tests, and locales). Anything else? Of cource the second page is more convinient to see what examples or tests are failed and how these fails dependent from the build type. I would like to have the possibility to merge the results of the multiple platforms into the one page, i.e.: - all windows builds (MSVC and ICC); - all MSVC builds; - all ICC/windows builds; - all ICC builds (windows and linux); - all MSVC 8.0 build + all gcc 4.2.0 builds; This is something I'd like to be able to do as well, and I have in a small number of cases. It can easily be done by changing the genxviews script to generate whatever combination of builds you need (we should move the data out of the script to make it possible to do this without modifying the script itself). After making the changes you just run your custom genxviews like this: $ genxviews $HOME/public_html/stdcxx/results/builds.html Of course, the ultimate implementation would let you do it on demand (e.g., as you suggest below). One thing to keep in mind is that the more builds you squeeze on a page the harder it becomes to see them all at the same time. At a certain point it starts to defeat the purpose of the page because you end up scrolling it left and right to see the results for all the platforms. ... It might be realized as the current page (http://people.apache.org/~sebor/stdcxx/results/builds) but with the checkboxes on the each line of the table and button Next somewhere on the page. That would be pretty cool. The only thing is that generating the pages takes quite a bit of time (you can see how long in the Time column), so you might have to wait a few minutes to get the results for a custom selection. We could probably optimize it to just a few seconds by pre-processing the individual logs so as not to make the script work so hard. Martin If neither, how do you analyze build results and why do you find your system preferable to what we have? What does your ideal result page look like? What data should it show and how should it be presented? Farid.
