Re: svn commit: r610849 - /incubator/stdcxx/branches/autotools/
Greetings Travis. Subversion does allow editing of change logs, though the process isn't the most straight forward. One description of the process can be found at http://svnbook.red-bean.com/en/1.4/svn.reposadmin.maint.html#svn.reposadmin.maint.setlog . I believe we have access to the 'svn propset' command. Updates made in this manner aren't processed by the JIRA hooks, so it isn't possible to go back and add a JIRA reference, and have the change be automatically added to the JIRA task. --Andrew Black Travis Vitek wrote: > Brad, > > We use a slightly modified version of the GNU ChangeLog format to > describe all changes that are committed to subversion for the stdcxx > project. There is a quick overview of the ChangeLog format at > http://incubator.apache.org/stdcxx/bugs.html#patches, and a more > detailed description at > http://www.gnu.org/prep/standards/html_node/Change-Logs.html. > > The two things that I believe are different from the GNU ChangeLog > format are that we use relative paths to describe files instead of just > filename, and we sometimes include multiple users on a single change. > I've linked to two changes below for reference. We only started doing > the relative path thing recently, so you won't see that in any of the > older changes. > > http://svn.apache.org/viewvc?view=rev&revision=425242 [multiple users] > http://svn.apache.org/viewvc?view=rev&revision=610576 [relative paths] > > That said, I believe that the general format for a ChangeLog when > branching is to use the branch name where the relative path would > usually go. Something like this... > > 2008-01-10 Brad Lemmings <[EMAIL PROTECTED]> > > * branches/autotools: New branch based off trunk/ at rev 610576 > > Now that the change has been committed, I don't know if there is > anything that can be done to change the log. Hopefully someone else will > jump in here and enlighten us. > > Travis > > > > > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> Sent: Thursday, January 10, 2008 9:44 AM >> To: [EMAIL PROTECTED] >> Subject: svn commit: r610849 - /incubator/stdcxx/branches/autotools/ >> >> Author: elemings >> Date: Thu Jan 10 09:44:11 2008 >> New Revision: 610849 >> >> URL: http://svn.apache.org/viewvc?rev=610849&view=rev >> Log: >> Experimental branch of trunk that adds support for GNU >> "Autotools" suite. >> >> Added: >>incubator/stdcxx/branches/autotools/ >> - copied from r610848, incubator/stdcxx/trunk/ >> >>
[jira] Commented: (STDCXX-683) implement notion of expected failures in the test suite
[ https://issues.apache.org/jira/browse/STDCXX-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553961 ] Andrew Black commented on STDCXX-683: - I think that a distinction between expected and unexpected NOUT states should be highlighted. This would permit us to easily spot non-regression tests which failed to produce any output. Without an XNOUT state, it would be necessary to check if each test is a regression test before looking past an NOUT row. In some cases, the regression notation (.stdcxx-NNN) may be trimmed, due to the length of the test name, making it harder to determine if a test is a regression test. Perhaps it would make more sense to use XNOUT for unexpected NOUT results and give it a yellow or red background. An unrelated thought I'm having is that it might make sense to check how accessible the color scheme is to someone who is red/green color blind. One tool I tracked down that can be used is http://colorfilter.wickline.org/ . The observation I'm having is that the dark green background used for the OK/XPASS states appears the same as the background used for the [SIG] state. > implement notion of expected failures in the test suite > --- > > Key: STDCXX-683 > URL: https://issues.apache.org/jira/browse/STDCXX-683 > Project: C++ Standard Library > Issue Type: New Feature > Components: Test Driver, Tests >Affects Versions: 4.2.0 >Reporter: Martin Sebor >Assignee: Martin Sebor >Priority: Critical > Attachments: codes.html, xcodes.html > > > Tests (or examples) that fail for known reasons that we haven't been able to > deal with should be distinguished from failures that haven't been analyzed > yet. For example, an example program that fails to compile on an older target > platform because of a compiler bug that we can't find a simple/elegant > workaround should be flagged as such in the test results. Similarly, a test > that fails one or more assertions due to compiler or libc bugs on a specific > platform (or a set of platforms) that we are unable to work around should be > reported as such. > This is important in order to reduce the currently fairly large number of > unexpected failures and to be able to make changes without having to worry > about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-683) implement notion of expected failures in the test suite
[ https://issues.apache.org/jira/browse/STDCXX-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553815 ] Andrew Black commented on STDCXX-683: - Looking at the revised xcodes.html file, I think it will be necessary to add an 'XNOUT' (expected NOUT) and 'XFMAT' (expected FMAT) assertion code. This is because we currently have tests which currently produce NOUT and FMAT status messages, and these messages are expected. Examples include NOUT messages from many regression tests (like 18.limits.stdcxx-436) and FORMAT (FMAT) messages from some driver tests (0.cmdopts, 0.strncmp, and 0.valcmp). > implement notion of expected failures in the test suite > --- > > Key: STDCXX-683 > URL: https://issues.apache.org/jira/browse/STDCXX-683 > Project: C++ Standard Library > Issue Type: New Feature > Components: Test Driver, Tests >Affects Versions: 4.2.0 >Reporter: Martin Sebor >Assignee: Martin Sebor >Priority: Critical > Attachments: codes.html, xcodes.html > > > Tests (or examples) that fail for known reasons that we haven't been able to > deal with should be distinguished from failures that haven't been analyzed > yet. For example, an example program that fails to compile on an older target > platform because of a compiler bug that we can't find a simple/elegant > workaround should be flagged as such in the test results. Similarly, a test > that fails one or more assertions due to compiler or libc bugs on a specific > platform (or a set of platforms) that we are unable to work around should be > reported as such. > This is important in order to reduce the currently fairly large number of > unexpected failures and to be able to make changes without having to worry > about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: _RWSTD_VER value on trunk
Martin Sebor wrote: > This has been bugging me -- when someone checks out trunk, does a build and > sends > us build results, we have no way of telling that the build results are, in > fact, for trunk and > not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is the > same. I > think we should change it so that the value is unique for each branch, or at > least distinct > from any release. > > Any suggestions for what would be a good value? The following is my suggestion for a scheme for _RWSTD_VER: Trunk: 0x Trunk feature branch: 0xFFxx Major branch: 0xMMFF Maintenance branch: 0xMMmmFF00 A trunk feature branch is a branch in subversion used for developing a specific feature, which isn't ready for inclusion in trunk, but is major enough that incremental testing is required. An example could be the implementation of concepts. The placeholder 'xx' is a non-FF value, unique to a feature branch. If the number of feature branches exceeds 255, it will be necessary to reuse numbers, but this isn't a likely occurrence in the near term. These numbers should be issued in the order the branches are created. A major branch is a branch in subversion used for ongoing development of a source compatible lineage. The placeholder MM represents the major version. An example would be ongoing maintenance of the 4.x version of stdcxx beyond 4.3, after the 5.0 release has been made. In the case of a 4.x maintenance branch, the version would be 0x04FF Maintenance branches are an established concept, with the 4.2.x branch being an example. The placeholder MM represents the major version, with the placeholder mm representing the minor version. In the case of 4.2.x, the version would be 0x0402FF00. Justification: My primary reason for using the 0xFF value as a placeholder (generally) is because it is greater than any particular released version number. This should allow checks which look for a specific version of the library (either older or newer) to function correctly. If someone wanted to exclude the trunk from these checks, it would be possible to simply perform a bitwise negation, and if the value of that negation is 0, it means the token references a trunk version. --Andrew Black
Re: [PING] Re: library and build sizes on Windows
Martin Sebor wrote: > Andrew Black wrote: [snip] >> >> The Batman script is build_stdcxx.bat, located along side the unix >> build_stdcxx script. This script is batch file, which calls into >> parse_runlog.wsf script for the purpose of processing the result log for >> batman. > > I suspect we're not going to want to touch that. But before the > script invokes parse_runlog.wsf it does this: > > echo ### Building solution / Creating HTML log > call build\build_%COMPILER%.bat %SHORT% > > echo ### Post-processing for Batman > cscript /nologo parse_runlog.wsf /BUILDTYPE:%SHORT% /CONFIG:%COMPILER% > > It seems that we'll be interested in making changes to this > build\build_%COMPILER%.bat script. Where does it come from? It's the batch file generated by the configure.bat script. --Andrew Black
Re: [PING] Re: library and build sizes on Windows
Martin Sebor wrote:
> Farid Zaripov wrote:
[snip]
>> But batman script also should to be updated to print the timestamp
>> of the build at the beginning ("### date:"); the duration of the
>> solution generating step ("### real time (builddir):") after execution
>> of the configure.bat and total time at the end after cleanup
>> ("### real time (total):"). All these actions are performed outside
>> the build.wsf script.
>
> Alright. We need to migrate this script from Batman over to stdcxx
> so we can enhance it ourselves. In addition to the timing info and
> the library size I also tried (but couldn't) to determine the name
> and version of the Windows OS so even the latest test result pages
> for Windows are incomplete.
>
> Andrew, I'm having trouble finding this script. Can you point me
> in the right direction?
The Batman script is build_stdcxx.bat, located along side the unix
build_stdcxx script. This script is batch file, which calls into
parse_runlog.wsf script for the purpose of processing the result log for
batman.
--Andrew Black
Re: mailing list for Jira issues?
Martin Sebor wrote: > STDCXX-546 suggests we create a separate mailing list to reflect Jira > traffic to so as to relieve stdcxx-dev from all the traffic. Since we > have just asked INFRA to move our mailing lists from the Incubator to > TLP (https://issues.apache.org/jira/browse/INFRA-1422) this would be > a good time to make this change. > > How does everyone feel about it? I would support this change (and filed a vote for the issue in Jira to reflect this). While it'd be possible to filter the jira messages without having a separate list, the filtering would be more reliable with having a separate list. --Andrew Black > > https://issues.apache.org/jira/browse/STDCXX-546 >
Re: Intel C++ 9.1/Win XP build timeouts
Travis Vitek wrote: > Martin Sebor wrote: >> Farid Zaripov wrote: >>> Maybe the BATMAN could do this before executing the batch file? >> Sounds like that would be the right place to make the change. Let >> me see if we can get it implemented on the Batman side of things, >> or in the build script. >> >> Travis, do you have enough experience with the Windows Scripting >> Host to modify the stdcxx build script that Batman invokes to do >> this? >> >> Martin >> > > No, I don't have mush experience with WSH. I don't even know the name of the > script that Batman invokes for building stdcxx. I'm sure I could figure it > out though. Batman invokes an internal glue script. That script in turn 'call's the generated build_.bat script. My understanding of the semantics of the call batch command is that it executes the script in question within the current process (like the unix . operator). --Andrew Black > > Unfortunately I'd prefer if we could find a solution outside of Batman. > Occasionally, I want to stop a build that I'm running locally. CTRL+C will > get my command prompt back, but it often leaves some of the other processes > running, or stuck in a bad state [devenv.exe, cscript.exe, exec.exe, ...]. > > Travis
Re: [VOTE] release stdcxx 4.2.0 (candidate 7)
Martin Sebor wrote:
> Andrew Black wrote:
>> I reviewed the README again, and I'm seeing a few nits, but I don't
>> think they're worth holding the release up for (someone else may
>> disagree).
>>
>> I feel the first paragraph of section 4.4 has a poorly worded or
>> inaccurate description of where the rwtest library lives.
>
> I'm not sure I see what you mean. Can you be more specific?
The wording in question is (in part) "... the test driver library,
rwtest, in ${TOPDIR}/tests/include/, ...". I believe the words "a set
of headers" were deleted by mistake in r586592. Adding these words back
in would make the quote read "... the test driver library, rwtest, a set
of headers, in ${TOPDIR}/tests/include/, ...". I wondered if it would
make sense to note where the rwtest library lives in this first
paragraph, but I think resolving this wording (as noted above) would
resolve my concerns.
--Andrew Black
Re: Problem configuring stdcxx-rc7 on Windows XP x64
I believe Brad is building Windows XP EM64T (I don't recall the name on the results page off the top of my head), though he didn't use that name. The issue feels like the Visual Studio integration problem we had when we first started working with 64-bit windows. Perhaps the integration hasn't been installed for 64-bit or something similar. --Andrew Black Martin Sebor wrote: > > Eric Lemings-2 wrote: >> >> >>> -Original Message- >>> From: Martin Sebor [mailto:[EMAIL PROTECTED] >>> Sent: Tuesday, October 23, 2007 4:40 PM >>> To: stdcxx-dev@incubator.apache.org >>> Subject: RE: Problem configuring stdcxx-rc7 on Windows XP x64 >>> >>> >>> >>> Eric Lemings-2 wrote: >>>> >>>> This error was produced from a 64-bit Visual C++ 8.0 >>> command line. The >>>> configure script works as expected in a 32-bit setup. >>>> >>>> >>> You mean Windows/IA64? I don't see it on our test matrix, either for >>> 4.2.0-rc-7 or trunk: >>> http://people.apache.org/~sebor/stdcxx-4.2.0-rc-7/results/ >>> http://people.apache.org/~sebor/stdcxx/results/ >>> >>> Martin >> Oh, well nevermind then. :P >> >> I assumed it was a supported platform, Windows XP x64 Professional >> (w/Intel Xeon). >> >> > > Supported by Rogue Wave? I suspect it's not otherwise we'd be testing with > it > (Andrew, can you confirm?) If you open an issue there's always a chance that > someone will feel motivated enough to work on it. > > Martin
Re: [VOTE] release stdcxx 4.2.0 (candidate 7)
I reviewed the README again, and I'm seeing a few nits, but I don't
think they're worth holding the release up for (someone else may disagree).
I feel the first paragraph of section 4.4 has a poorly worded or
inaccurate description of where the rwtest library lives. I also wonder
if the test harness needs to be better described, as it's referenced in
several places, but not talked much about.
In section 5, it is claimed that the BUILDDIR argument is required, but
this actually isn't the case, as the value will default to
${TOPDIR}/build . In section 5.1, no reference is made to the msvc-9.0
and msvc-9.0-x64 config options.
Section 7 still references the old runall.sh script in the final
paragraph, which may need to be rewritten. The paragraph before that
includes some 'best results' instructions, which also were related to
the old runall.sh script.
As far as test builds are concerned, I ran a couple tests. Both builds
were 11d. The first was on my local machine (OpenSUSE 10.2 -
2.6.18.8-0.5-xenpae, gcc version 4.1.2 20061115 (prerelease) (SUSE Linux))
On this host, 27.stringbuf.xsputn.stdcxx-515.cpp test fails to compile.
This seems consistent with Redhat 5 (though without the failure to
compile 22.locale.codecvt.out).
Test suite summary is as follows:
> PROGRAM SUMMARY:
> Programs:187
> Non-zero exit status: 0
> Signalled:11
> Compiler warnings: 0
> Linker warnings: 0
> Runtime warnings: 68
> Assertions: 11971783
> Failed assertions: 5341
The second build was on HPUX 11.23, using HPaCC 3.73. On this host, the
2.smartptr.shared.cpp, 20.auto.ptr.cpp, and
regress/27.stringbuf.xsputn.stdcxx-515.cpp tests failed to compile,
consistent with nightly testing.
Test suite summary is as follows:
> PROGRAM SUMMARY:
> Programs:187
> Non-zero exit status: 1
> Signalled: 8
> Compiler warnings: 0
> Linker warnings: 0
> Runtime warnings:222
> Assertions: 11528233
> Failed assertions: 4706
My vote on rc-7 is +1, despite the issues with the README.
--Andrew Black
Martin Sebor wrote:
> I just created the next stdcxx 4.2.0 release candidate tag,
> stdcxx-4.2.0-rc-7, that incorporates changes addressing issues
> pointed out in the original vote thread.
> http://svn.apache.org/repos/asf/incubator/stdcxx/tags/4.2.0-rc-7/
>
> The tarball containing the release candidate sources can be
> downloaded from my home directory at the following link:
> http://people.apache.org/~sebor/stdcxx-4.2.0-rc-7/stdcxx-incubating-4.2.0.tar.gz
>
>
> The MD5 sum for the tarball is: b43adeb0c72cf4747301818f4dff4fa1
>
> Instructions on unpacking the tarball, configuring and building
> the library and the set of examples and tests, are in the README
> file contained in the tarball and can also be viewed directly
> in Subversion:
> http://svn.apache.org/repos/asf/incubator/stdcxx/tags/4.2.0-rc-7/README
>
> The Jira "Release Notes" for 4.2.0 detailing the issues resolved
> in this release can be viewed here:
> http://tinyurl.com/ytzonz
>
> stdcxx 4.2.0 has been tested on the set of platforms listed in
> the README. The test results for most of the tested platforms
> can be be viewed on the following page:
> http://people.apache.org/~sebor/stdcxx-4.2.0-rc-7/results/
> (there are a few failures, most of them attributable to issues in
> the Rogue Wave test infrastructure; a small number of failures are
> due to known stdcxx issues).
>
> Please download and test the tarball and vote to approve the
> release and to request the approval of the Incubator PMC to publish
> it on the stdcxx site. In your vote, please include the names and
> versions of the compilers and operating systems that you tested on.
>
> As always, everyone is encouraged to vote, including non-committers.
>
> This vote will close in the usual 72 hours from now, i.e., on
> Tuesday, 10/23 at 5:00 PM US/Mountain time. Follow the link
> below for the countdown:
> http://tinyurl.com/2h5f73
>
Re: [VOTE] release stdcxx 4.2.0
My concern about using -rc-6 as the 4.2.0 release is that there are still several flaws in the readme file that have yet to be addressed. See my note in http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200710.mbox/[EMAIL PROTECTED] providing a list of these discrepancies. I provided a patch for the issues in section 10 (which need to be propagated to the website), but I am busy with other projects at work, and don't have time to work on the section 4 and 6 issues I noted. --Andrew Black Martin Sebor wrote: > I created what I'm hoping will be the final stdcxx 4.2.0 release > candidate, stdcxx-4.2.0-rc-6: > http://svn.apache.org/repos/asf/incubator/stdcxx/tags/4.2.0-rc-6/ > > along with a tarball containing the sources: > http://people.apache.org/~sebor/stdcxx/stdcxx-incubating-4.2.0.tar.gz > > The MD5 sum for the tarball is: f65ea507f7d82688d1cf241bce25dc01 > > Instructions on unpacking the tarball, configuring the library, > and building it along with the set of examples and tests, are > in the README file contained in the tarball. The file can also > be viewed directly in Subversion: > http://svn.apache.org/repos/asf/incubator/stdcxx/tags/4.2.0-rc-6/README > > The Jira "Release Notes" for 4.2.0 detailing the vast number of > issues resolved in this release can be found here: > http://tinyurl.com/ytzonz > > stdcxx 4.2.0 has been tested on the set of platforms listed in > the README. The test results for most of the tested platforms > can be be viewed on the following page: > http://people.apache.org/~sebor/stdcxx/results/ > (there are some failures, most of them due to the Rogue Wave test > infrastructure and IT issues; please disregard those). > > Please take the tarball for a spin and vote to approve the release > and to request the approval of the Incubator PMC to publish it on > our site. > > Everyone is encouraged to vote, including non-committers. > > This vote will close in the usual 72 hours.
Re: 4.2.0 README for review
Greetings all. Attached is a change that should address some of the issues in section 10. Someone else will need to double check that the state of the additional platforms noted is as desired. I probably won't have time to make any further changes in the near future. --Andrew Black Andrew Black wrote: > I have a few observations. > > Section 4.2 doesn't mention the exec or gencat utilities. Section 4.4 > references the old run_all.sh script, as does section 4.6. Section 4.6 > also overlooks the Windows build directory structure. Section 6 > predates the 'make install' target on unix, and doesn't cover > installation on windows. Section 10 has a few oversights in recorded > testing coverage. I'll toss a patch at the list in a bit with my > proposed changes. > > --Andrew Black > > Martin Sebor wrote: >> Martin Sebor wrote: >>> The 4.2.0 README is ready for review. Corrections, comments, >>> or suggestions for improvements are welcome. >> Hit the Send button too soon... A link to the README might be helpful: >> http://svn.apache.org/repos/asf/incubator/stdcxx/branches/4.2.0/README >> >>> Thanks >>> Martin Index: README === --- README (revision 585234) +++ README (working copy) @@ -1806,6 +1806,7 @@ o gcc 4.1.0, SuSE Linux Enterprise Server 10.0, EM64T o gcc 4.0.1, Mac OS X (Darwin), x86 o gcc 3.4.6, Red Hat Enterprise Linux 4, Update 4, AMD64 and EM64T +o gcc 3.4.4, Cygwin on Windows XP SP 2, x86 o gcc 3.4.4, FreeBSD 6.2, x86 o gcc 3.4.4, Red Hat Enterprise Linux 4, Update 2, IA64 o gcc 3.3.3, SuSE Linux Enterprise Server 9.1, AMD64 @@ -1817,6 +1818,19 @@ Ported to HP aCC 3.13 and later for PA-RISC, and 5.36 and later, and 6.0 and later for IPF. +This release tested with: + +o acc 3.63, HPUX 11.11, PARISC +o acc 3.73, HPUX 11.11, PARISC +o acc 5.57, HPUX 11.23, IA64 +o acc 6.00, HPUX 11.23, IA64 +o acc 6.13, HPUX 11.23, IA64 +o acc 3.63, HPUX 11.23, PARISC +o acc 3.73, HPUX 11.23, PARISC +o acc 3.63, HPUX 11.31, PARISC +o acc 3.73, HPUX 11.31, PARISC +o acc 3.74, HPUX 11.31, PARISC + 10.8 IBM VisualAge C++ --- @@ -1849,10 +1863,20 @@ Ported to Intel C++ 7.0 through 9.0 on Linux and Windows (x86, IA64, and EM64T). +This release tested with: + o Intel C++ 10.0, Red Hat Enterprise Linux 4, Update 4, AMD64 and EM64T o Intel C++ 10.0, SuSE Linux Enterprise Server 10.0, EM64T +o Intel C++ 10.0, Windows 2000 SP 4, x86 +o Intel C++ 10.0, Windows 2003 SP 1, EM64T and x86 +o Intel C++ 10.0, Windows XP SP 2, EM64T and x86 +o Intel C++ 10.0, Windows Vista, EM64T o Intel C++ 9.1, Red Hat Enterprise Linux 4, Update 4, AMD64 and EM64T +o Intel C++ 9.1, Red Hat Enterprise Linux 4, Update 2, IA64 o Intel C++ 9.1, SuSE Linux Enterprise Server 10.0, EM64T +o Intel C++ 9.1, Windows 2000 SP 4, x86 +o Intel C++ 9.1, Windows 2003 SP 1, x86 +o Intel C++ 9.1, Windows XP SP 2, x86 10.10 KAI C++ -- @@ -1867,12 +1891,20 @@ 10.12 Microsoft Visual Studio -- -Ported to Visual Studio .NET 2003 (AKA MSVC 7.0) through Visual +Ported to Visual Studio .NET 2002 (AKA MSVC 7.0) through Visual Studio .NET 2005 (AKA MSVC 8.0) on Windows (x86, IA64, and EM64T), and Visual Studio 2008 (AKA MSVC 9.0), Beta 2. +This release tested with: + o Visual Studio 2008 Beta 2, Windows XP, x86 -o Visual Studio 2005, Windows XP, +o Visual Studio 2005, Windows 2000 SP 4, x86 +o Visual Studio 2005, Windows 2003 SP 1, EM64T and x86 +o Visual Studio 2005, Windows XP SP 2, EM64T and x86 +o Visual Studio 2005, Windows Vista, EM64T +o Visual Studio 2003, Windows 2000 SP 4, x86 +o Visual Studio 2003, Windows 2003 SP 1, x86 +o Visual Studio 2003, Windows XP SP 2, x86 10.13 SGI MIPSpro @@ -1891,10 +1923,14 @@ Ported to Sun C++ 5.3 through 5.9 on Solaris and Linux (SPARC and x86_64). +This release tested with: + o Sun C++ 5.9, Red Hat Enterprise Linux 4, Update 4, AMD64 and EM64T o Sun C++ 5.9, SuSE Linux Enterprise Server 9.1, AMD64 -o Sun C++ 5.9, Solaris 10, AMD64 -o Sun C++ 5.8, Solaris 10, AMD64 -o Sun C++ 5.7, Solaris 9, SPARC +o Sun C++ 5.9, Solaris 10, AMD64 and SPARC +o Sun C++ 5.9, Solaris 9, SPARC +o Sun C++ 5.8, Solaris 10, AMD64 and SPARC +o Sun C++ 5.8, Solaris 8, SPARC +o Sun C++ 5.7, Solaris 10, SPARC o Sun C++ 5.6, Solaris 9, SPARC o Sun C++ 5.3, Solaris 8, SPARC
Re: 4.2.0 README for review
I have a few observations. Section 4.2 doesn't mention the exec or gencat utilities. Section 4.4 references the old run_all.sh script, as does section 4.6. Section 4.6 also overlooks the Windows build directory structure. Section 6 predates the 'make install' target on unix, and doesn't cover installation on windows. Section 10 has a few oversights in recorded testing coverage. I'll toss a patch at the list in a bit with my proposed changes. --Andrew Black Martin Sebor wrote: > Martin Sebor wrote: >> The 4.2.0 README is ready for review. Corrections, comments, >> or suggestions for improvements are welcome. > > Hit the Send button too soon... A link to the README might be helpful: > http://svn.apache.org/repos/asf/incubator/stdcxx/branches/4.2.0/README > >> >> Thanks >> Martin >
[jira] Closed: (STDCXX-109) [Mac OS X 10.2.8] Unable to build rwstderr.cat (no gencat utility)
[ https://issues.apache.org/jira/browse/STDCXX-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black closed STDCXX-109. --- Resolution: Fixed Closing as fixed with the change made in http://svn.apache.org/viewvc?rev=585143&view=rev and verified via simulation in manual testing. A future enhancement might be to provide more informative output regarding the consequences of the failure, and possibly making it fatal if the catalog failed to build for reasons other than a missing gencat utility, but these enhancements are outside the scope of this issue. > [Mac OS X 10.2.8] Unable to build rwstderr.cat (no gencat utility) > -- > > Key: STDCXX-109 > URL: https://issues.apache.org/jira/browse/STDCXX-109 > Project: C++ Standard Library > Issue Type: Bug > Components: Build > Environment: Mac OS X 10.2.8/Darwin 6.8 with GCC 3.1 >Reporter: Andrew Black >Assignee: Andrew Black > Fix For: 4.2 > > > When the make process gets to the point where it tries to build the > rwstderr.cat file, the make process fails with > gencat rwstderr.cat /Volumes/Orion/Work/stdcxx/src/rwstderr.msg > /bin/sh: gencat: command not found > make[2]: *** [rwstderr.cat] Error 127 > make[1]: *** [lib] Error 2 > make: *** [libstd] Error 2 > The most obvious cause is that there is no gencat utility installed on the > system in the $PATH hierarchy. I have not searched for the gencat utility > outside of the $PATH hierarchy at this point in time, though it would make > sense to do so. As this utility is referenced as a part of the makefile > rules, it would be difficult at best to control logic through the > characterization tests. > A possible way to detect if there is an accessable copy of gencat would be to > use the which command, redirecting the output to /dev/null, and using the > return code to detect the location. > Another possible tactic would be to make the failed execution of gencat a non > fatal problem (which likely would result in other problems if it failed in > other circumstances), then to touch the output file when done so that a file > is present (if empty) to be used in building the library. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: __rw_once warnings in non-reentrant Windows builds?
Martin Sebor wrote: > Andrew Black wrote: >> Martin Sebor wrote: >> [snip] >>>> CRT's, so the 11s builds are compiled with the same options as the 15s >>>> (11d == 15d, 8s|d == 12s|d). >>> Ugh. That means we've been doing a whole bunch of redundant builds >>> on Windows. >> >> I think it would be more accurate to say that some of the builds have >> been mislabeled and perhaps slightly misconfigured. Those builds would >> be the 8s and 11s builds with the Intel compiler. > > I'm not sure I understand. Are you saying that we haven't been > doing duplicate builds with MSVC? I see a few 11s builds but no > 11d's, and a number of 8s but no 12s. I've always thought the > choice of builds was essentially arbitrary and that some types > were simply not being exercised but it's beginning to look like > there's actually some deeper logic to the schedule. We've never intentionally done 8d and 11d builds on windows, as best I can remember. With MSVC 7.1 and GCC, we've been doing 8s, 11s, 12d and 15s. This has also been done with Intel 9.1 and 10.0 on 32-bit windows as a holdover from Intel 8.1 or 9.0, which used the MSVC 7.1 compiler. For MSVC 8.0 and Intel on 64-bit windows, we are doing only 12d and 15s builds. The logic behind these choices has been that 12d is the most common type of build for end-users, so 15s has been select to test the other half of the relevant logic trees in reentrant builds. For non-reentrant builds, we only performed 8s and 11s builds, as the compiler doesn't have switches for non-reentrant dynamic builds. Had non-reentrant dynamic builds been supported, we likely would have performed 8s and 11d builds, to test the release/static and debug/dynamic combinations. --Andrew Black
Re: __rw_once warnings in non-reentrant Windows builds?
Martin Sebor wrote: [snip] >> CRT's, so the 11s builds are compiled with the same options as the 15s >> (11d == 15d, 8s|d == 12s|d). > > Ugh. That means we've been doing a whole bunch of redundant builds > on Windows. I think it would be more accurate to say that some of the builds have been mislabeled and perhaps slightly misconfigured. Those builds would be the 8s and 11s builds with the Intel compiler. --Andrew Black
Re: __rw_once warnings in non-reentrant Windows builds?
I'm not certain this is relevant, but MSVC 8.0 doesn't support non-reentrant builds, at least where compiler switches are concerned. (MSVC 7.1 did support non-reentrant builds, but only when linked statically). By compiler switches, I'm referencing the /ML(d), /MT(d), and /MD(d) family of switches. I believe these switches control which C runtime library is used in linking. --Andrew Black Martin Sebor wrote: > In a manual 11d build I just did with MSVC 8.0 I'm seeing warning > C4297: 'function assumed not to throw an exception but does' for > __rw_once(). When I double-click on the warning in the debugger > output window it brings up the definition of __rw_once() that's > guarded by #ifdef _RWSTD_REENTRANT (it points to line 133 in > once.cpp), but the function text is grayed out, presumably because > the block of code is not included. This doesn't seem to make sense. > Why would the compiler give a warning for a function that's not > even compiled? OTOH, if it is being compiled in this build type, > it seems we have a problem (11d is not supposed to be reentrant). > Does any of you Visual Studio gurus have idea what's going on? > > Martin
Re: svn commit: r585143 - /incubator/stdcxx/trunk/etc/config/makefile.rules
Martin Sebor wrote: > [EMAIL PROTECTED] wrote: >> Author: ablack >> Date: Tue Oct 16 06:54:59 2007 >> New Revision: 585143 >> >> URL: http://svn.apache.org/viewvc?rev=585143&view=rev >> Log: >> 2007-10-15 Andrew Black <[EMAIL PROTECTED]> >> STDCXX-109 >> * etc/config/makefile.rules ($(CATFILE)): Make failure to execute >> the gencat utility non-fatal. > > Andrew, can please you correct the format of your change log > to conform to the documented style? Use svn propset --revprop > to make the change: > http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.ref.svn.c.propset > > If you're having trouble remembering the specifics of the > formatting style we use the Emacs add-change-log-entry command > will automatically format it for you. *shrugs* I did use the Emacs add-change-log-entry command when I generated the change. Perhaps I don't have the command configured correctly. Before I edit the change, I want to make certain I'm correcting the actual mistake. Is the correct formatting to have a blank line after the author name and indent the change number? --Andrew Black > > Martin > >> >> >> Modified: >> incubator/stdcxx/trunk/etc/config/makefile.rules >> >> Modified: incubator/stdcxx/trunk/etc/config/makefile.rules >> URL: >> http://svn.apache.org/viewvc/incubator/stdcxx/trunk/etc/config/makefile.rules?rev=585143&r1=585142&r2=585143&view=diff >> >> == >> >> --- incubator/stdcxx/trunk/etc/config/makefile.rules (original) >> +++ incubator/stdcxx/trunk/etc/config/makefile.rules Tue Oct 16 >> 06:54:59 2007 >> @@ -67,7 +67,7 @@ >> >> # create a catalog from text message files - see gencat(1) >> $(CATFILE): $(MSGFILES) >> -gencat $@ $^ >> +-gencat $@ $^ >> >> >> >> >> >
Re: [RFC] stdcxx acknowledgments
Greetings all. One thought that I have looking over the proposed patch is that it doesn't include the names of people who have contribute code to the release, but who aren't comitters. Scott Zhong and Travis Vitek both have changes attributed to them, but neither name appears in the list. I suspect there are others, but it would require a search through the change logs to locate the changes in question. --Andrew Black Martin Sebor wrote: > In the patch attached to the issue Marc proposes to replace > the names of the original Rogue Wave "contributors" to the > project (which included support engineers as well management) > with those of stdcxx committers (including Emeriti). I'd like > to request people's opinion on this change. I personally am > not entirely comfortable dropping all the contributors that > predate stdcxx, although perhaps it may not be inappropriate > (sorry for the double negative) to pare it down to people who > contributed significant code and/or documentation changes). > > What do others think? > > Martin > > Marc Betz (JIRA) wrote: >> [ >> https://issues.apache.org/jira/browse/STDCXX-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> ] >> >> Marc Betz updated STDCXX-505: >> - >> >> Attachment: (was: acknow.html) >> >>> Update the Acknowledgments page >>> --- >>> >>> Key: STDCXX-505 >>> URL: https://issues.apache.org/jira/browse/STDCXX-505 >>> Project: C++ Standard Library >>> Issue Type: Sub-task >>> Components: Documentation >>>Affects Versions: 4.1.2, 4.1.3, 4.1.4 >>>Reporter: Marc Betz >>>Assignee: Marc Betz >>> Fix For: 4.2 >>> >>> >> >> >
[jira] Commented: (STDCXX-440) 23_allocator test case can consume all system memory
[
https://issues.apache.org/jira/browse/STDCXX-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531833
]
Andrew Black commented on STDCXX-440:
-
Adding tests for the exec utility probably should be scheduled for 4.2.1, in a
separate JIRA issue.
One piece of fallout I'm observing is that examples on hpux-11.23-ia64 are
failing to run with messages like
./run (accumulate): execv ("./accumulate", ...) error: Not enough space
My reading of this error message, and the fact that it surfaced only after
r579307 was checked into subversion, is that 256 MB isn't a high enough as
limit for executables on this platform. As such, the solution likely is to
raise this limit, probably to 384 MB, though testing would be required. The
only other solution I see would be to reduce the memory usage of the library,
which likely isn't possible.
> 23_allocator test case can consume all system memory
>
>
> Key: STDCXX-440
> URL: https://issues.apache.org/jira/browse/STDCXX-440
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2
> Environment: RHAP 5 (possibly others)
> Reporter: Eric Lemings
>Assignee: Andrew Black
>Priority: Critical
> Fix For: 4.2
>
> Attachments: sample-top.txt
>
>
> The 22_allocator test case has been observed to consume all primary and
> virtual memory bringing the unfortunate system to its knees.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: 4.2.0-rc-5 plans
Travis Vitek wrote: > Andrew Black wrote: [snip] >> SVN trunk at r580086 should be identical to branches/4.2.0 at r580483, >> assuming the merge ran correctly. >> > > I don't know if that is a safe assumption or not. I believe that 4.2.1 > changes are happening on trunk but aren't being merged out to > branches/4.2.0. The change description for r580483 ( http://svn.apache.org/viewvc?rev=580483&view=rev ) indicates that Martin was intending to merge the head of trunk to the 4.2.0 branch. My concern about starting 4.2.1 development on trunk is that it would no longer be possible to perform merges like r580483. > >> Opinions, please? >> > > I don't really understand exactly what the tags are used for, so I don't > know how useful my feedback is. If these 'tags' are intended to indicate > release candidates, as implied by the name, then it wouldn't make sense > to skip changes that we know are going to make it into the release. Tags are a way of attaching names to a specific set of source files. Generally, a tag is a direct copy of trunk or a branch at a specific change, but it doesn't have to be. In Perforce terminology, it's equivalent to using the 'p4 tag' command. I guess I better way to put my question would be 'Should the changes to the 4.2.0 branch since r580483 be part of 4.2.0-rc-5 or 4.2.0-rc-6?' Again, I feel it makes more sense to have changes since r580483 be tagged as part of -rc-6, but I'm looking for feedback before I create the tag. --Andrew Black
Purify run results
Greetings all. As I mentioned in my previous email, I've performed a test build of the apache standard library using Rational PurifyPlus 7.0 ( http://www.ibm.com/software/awdtools/purifyplus/ ). This build was performed on an HPUX 11.23 machine, using the HP acc 3.73 compiler and subversion trunk at r580086 plus the makefile.rules part of the purify.diff patch attached to STDCXX-573. PURE_OPTS was set to '[EMAIL PROTECTED] -windows=no -append-logfile=yes [EMAIL PROTECTED] -always-use-cache-dir=yes -cache-dir=/tmp/ablack-purecache-stdcx'. If anyone wishes to look at the results of this build, it can be retrieved from http://people.apache.org/~ablack/stdcxx-4.2.0-rc-5-purify.tar.gz . This build was a 15d build, which was processed with `make clean` and `make dependclean` prior to being compressed. Note that some of the .log files were truncated by Purify during the run process due to their length. These files are 22.locale.money.put.log, tests/22.locale.moneypunct.log, tests/22.locale.num.get.log, tests/23.deque.modifiers.log, tests/25.find.end.log, and tests/25.search.log. --Andrew Black
4.2.0-rc-5 plans
Greetings all. On Friday, Martin performed a fairly major merge from trunk to branches/4.2.0. The current results of this merge from nightly testing can be found at http://people.apache.org/~ablack/4.2.0-rc5 . A handful of the platforms in the list (hpux-11.23-ia64, hpux-11.31-pa, irix-6.5-mips, solaris-10-sparc) don't have -rc5 results, either because the hardware used in the testing is offline (hpux-11.31-pa and irix-6.5-mips), or processing other requests (hpux-11.23-ia64 and solaris-10-sparc). The question I have is whether it makes sense to tag branches/4.2.0 as of r580483 (Martin's integration) as tags/4.2.0-rc-5, or whether it makes more sense to include the changes which were merged today as part of the 4.2.0-rc-5 tag. I would argue for the former, in part because I have some results from running the tests and examples under Rational PurifyPlus 7.0 ( http://www.ibm.com/software/awdtools/purifyplus/ ) which I plan to post shortly. This build was made using trunk at r580086 plus part of the patch attached to STDCXX-573. SVN trunk at r580086 should be identical to branches/4.2.0 at r580483, assuming the merge ran correctly. Opinions, please? --Andrew Black
Re: merging trunk to 4.2.0
Greetings Martin I suspect the cause of the subversion messages was because you were using a protocol of http, rather than https in the source tree. Rel branch testing should begin when the archives are rebuilt tonight, unless you'd like me to get the ball rolling sooner. --Andrew Black Martin Sebor wrote: > The merge to branches/4.2.0 is complete now. Assuming our testing > confirms that the merge was successful we'll tag it (4.2.0-rc-5) > sometime next week. The merge was very difficult because of the > large number of changes and because of what seems to be an svn > limitation: the command line client croaks on merges containing > added files with the following error: > > svn: Access scheme mixtures not yet supported > > I worked around it by copying the files from trunk over to the > branch via svn cp. Before checking everything in I did a diff > of all files to make sure they matched. Since some of them > weren't merged correctly for some odd reason I copied those as > well and repeated the process until there were no diffs (except > for $Id: keywords). I also verified the branch by building the > library, examples, tests, and utilities, with gcc 4.1 on Solaris. > So even though I'm pretty confident that merge went okay the > branch probably shouldn't be used for any serious work until > we've put it through a round of testing on a number of > platforms. > > Andrew, could you please you set up the head of the 4.2.0 branch > for nightly testing? > > Thanks > Martin > > Martin Sebor wrote: >> A typo introduced last night into one of the Rogue Wave build >> scripts has caused all last night's builds to fail. We've corrected >> the typo this morning and scheduled a new set of builds to take >> place ASAP. The planned merge will take place once we've >> seen at least a representative sample of the build results. >> >> Martin >> >> >> Martin Sebor wrote: >>> I'm planning to merge all of the trunk to branches/4.2.0 as soon >>> as the recently introduced build failures have cleared up in the >>> build results. This could be as early as tomorrow and hopefully >>> no later than early next week. Until then, I'd like to ask all >>> committers to be extra careful before checking in any library or >>> build and test infrastructure changes (including the test driver) >>> that might adversely impact multiple platforms. If you can't test >>> with *at least* two different compilers please hold off on checking >>> your changes in until after the merge. >>> >>> Thanks >>> Martin >>> >>> >> >
[jira] Updated: (STDCXX-573) Enable building with Purify
[ https://issues.apache.org/jira/browse/STDCXX-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black updated STDCXX-573: Attachment: purify.diff Attached (As purify.diff) is my first take at resolving this issue, though there are a few things that need to be fixed before the patch is included. I targeted this issue at 4.2.1, as it's too late in the 4.2.0 cycle for this sort of change. One major issue is that it doesn't instrument the utilities (exec, locale/localedef), and this likely would be desired. A second issue is that we'd want to update the windows infrastructure for feature parity. A smaller issue is that we need to determine the correct behavior if a user defines both PHDIR and PURE_OPTS. We may also wish to consider increasing the timeout used when running the tests and examples. Probably one other issue to consider is whether this should be extended to single step compilation and single step run compilation. Changelog: 2007-09-27 Andrew Black <[EMAIL PROTECTED]> * GNUmakefile: Document PURE_OPTS flag, add to generated makefile.in. * makefile.rules [PURE_OPTS]: Link executables using purify if PURE_OPTS is defined. > Enable building with Purify > --- > > Key: STDCXX-573 > URL: https://issues.apache.org/jira/browse/STDCXX-573 > Project: C++ Standard Library > Issue Type: Improvement > Components: Build >Reporter: Andrew Black >Priority: Minor > Fix For: 4.2.1 > > Attachments: purify.diff > > > It would be useful to be able to build and run the examples, utilities and > tests using Rational Purify. This could potentially allow us to detect > errors, such as memory leaks, which we might not otherwise detect. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-573) Enable building with Purify
Enable building with Purify --- Key: STDCXX-573 URL: https://issues.apache.org/jira/browse/STDCXX-573 Project: C++ Standard Library Issue Type: Improvement Components: Build Reporter: Andrew Black Priority: Minor Fix For: 4.2.1 It would be useful to be able to build and run the examples, utilities and tests using Rational Purify. This could potentially allow us to detect errors, such as memory leaks, which we might not otherwise detect. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-258) run_locale_utils.sh doesn't consider path to locale and localedef
[ https://issues.apache.org/jira/browse/STDCXX-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black closed STDCXX-258. --- Confirmed fixed in a manual test. How I tested was by creating a 'fake' locale and localedef script, which echoed an error message indicating that it wasn't the desired utility, then exited with a non-zero status. These scripts were placed in a directory which I prepended to $PATH, then used this PATH to run the sanity_test.sh and en_US.UTF-8.sh scripts. Both tests ran to completion. I could see a benefit in altering the test infrastructure so that it used this strategy as part of the tests, but that would be an enhancement for 4.2.1 or later. > run_locale_utils.sh doesn't consider path to locale and localedef > - > > Key: STDCXX-258 > URL: https://issues.apache.org/jira/browse/STDCXX-258 > Project: C++ Standard Library > Issue Type: Bug > Components: Build >Affects Versions: 4.1.2, 4.1.3 >Reporter: Andrew Black >Assignee: Martin Sebor >Priority: Minor > Fix For: 4.2 > > Attachments: run_utils1.diff > > > At this time, the run_locale_utils.sh script invoks the locale and localedef > utilities using the PATH environment variable to determine the location of > the utilities. This creates a problem if the bin subdirectory of the > buildspace isn't in the PATH variable (likely), or if a system copy of locale > or localedef is present in the PATH variable prior to the buildspace bin > subdirectory. > One possible solution is to alter the PATH variable when calling the > run_locale_utils.sh script, either manually or in the stub locale and > sanity_check scripts. The trade off of this method is that other programs > may be invoked incorrectly, if the altered PATH masks another utility used in > the script. > A second possibility is to alter the run_locale_utils.sh script to use > relative or absolute paths to the locale and localedef utilities. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Intel C++ build failures on Windows Vista
Travis Vitek wrote: > > > Martin Sebor wrote: >> Andrew Black wrote: >>> What changed was that I started testing with ICC on vista, where we >>> hadn't been before. Also started at the same time was 32 bit MSVC >>> builds on 64-bit windows XP and windows 2003, along with ECCP on >>> redhat 5, suse 9.1 and suse 10. >> I thought we were testing on Vista last week, but I could very >> well be misremembering. I trust you when you say we weren't. >> > > I seem to remember that we were also, but I could be wrong. Doesn't the > internal build infrastructure keep a history? We were only testing MSVC on vista, and if you look at the history for the requests in question through the internal infrastructure, this should reflect that. --Andrew Black
[jira] Updated: (STDCXX-426) infinite loop in exec utility
[ https://issues.apache.org/jira/browse/STDCXX-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black updated STDCXX-426: Severity: Inefficiency Fix Version/s: (was: 4.2) 4.2.1 The final resolution for this issue will involve rewriting the test output parser to search backwards in the file for the summary tag patterns. This change would be somewhat invasive, and as such shouldn't be made at this point in the release cycle. Therefore, I'm differing it to the 4.2.1 release cycle. > infinite loop in exec utility > - > > Key: STDCXX-426 > URL: https://issues.apache.org/jira/browse/STDCXX-426 > Project: C++ Standard Library > Issue Type: Bug > Components: Test Driver >Affects Versions: 4.2 > Environment: gcc 3.4.6 on Red Hat Advanced Server 4, 12D (shared, > wide, optimized, thread-safe) build > Reporter: Mark Brown >Assignee: Andrew Black >Priority: Critical > Fix For: 4.2.1 > > Attachments: strace.run-21.cwchar.log > > > Copied from > http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200705.mbox/[EMAIL > PROTECTED] > Original Message > Subject: infinite loop in exec > Date: Wed, 23 May 2007 14:28:47 -0600 > From: Martin Sebor <[EMAIL PROTECTED]> > Reply-To: stdcxx-dev@incubator.apache.org > Organization: Rogue Wave Software > To: stdcxx-dev@incubator.apache.org > I'm running into an (almost?) infinite loop when running some > of our tests under the exec utility on Linux (in a 12D build > with gcc 3.4.6 on Red Hat Advanced Server 4, I haven't tried > other configurations). The initial output of strace for one > of the tests, 21.cwchar, is in the attached file. The test > by itself runs fine to completion and doesn't produce any > unusual output (no NULs). > Andrew, when you have a chance, can you take a look at it? > If that's not going to be soon let me know if I should open > an issue. > Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Intel C++ build failures on Windows Vista
Martin Sebor wrote: > I'm afraid the Intel C++ 10.0 build errors we thought we had > successfully dealt with last week are back, this time on Vista: > > http://people.apache.org/~sebor/stdcxx/results/ > > I can't think of anything that has changed in the stdcxx build > scripts recently that could be causing this. Farid, can you? > > Andrew, do you have any idea if something might have changed > on skylight in the last days that could be responsible for > these failures? Any patches or any other software getting > installed by IT or anyone else? What changed was that I started testing with ICC on vista, where we hadn't been before. Also started at the same time was 32 bit MSVC builds on 64-bit windows XP and windows 2003, along with ECCP on redhat 5, suse 9.1 and suse 10. --Andrew Black > > Travis, was the error similar to what you saw when you did > a manual build on one of the XP boxes last week? Do you > think we should try to get the Intel compiler reinstalled? > > Martin
[jira] Resolved: (STDCXX-117) [Mac OS X 10.2.8] Missing header guards in utility source files
[ https://issues.apache.org/jira/browse/STDCXX-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black resolved STDCXX-117. - Resolution: Fixed It looks like the change to fix STDCXX-404 also resolved this issue. I've started a manual build with the latest svn trunk, and the locale/localedef utility appears to run correctly, excluding some of the more exotic character encodings- EUC-JP, Shift_JIS, and EUC-KR which appear to crash after stage one of the locale tests. I'm not certain what happened with the patch I'd started to create for this issue. Odds are it's probably living on my old computer. However, memory is saying that it was similar to the change which was committed for STDCXX-404. I believe what happened was I was uncertain on what the logic flow should be to handle the character conversions when neither iconv nor the windows functions were available. As a result progress was halted, though I neglected to update the status of this ticket to reflect this halt. > [Mac OS X 10.2.8] Missing header guards in utility source files > --- > > Key: STDCXX-117 > URL: https://issues.apache.org/jira/browse/STDCXX-117 > Project: C++ Standard Library > Issue Type: Bug > Components: Utilities > Environment: Mac OS X 10.2.8/Darwin 6.8 with GCC 3.1 >Reporter: Andrew Black >Assignee: Andrew Black > Fix For: 4.2 > > Attachments: utilguard.diff > > > Several files used in the building of the utilities (util/aliases.cpp, > util/charmap.cpp, util/charmap.h, util/locale.cpp) are missing guards on the > inclusion of the langinfo.h and iconv.h headers. I will be ataching a patch > for this shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-440) 23_allocator test case can consume all system memory
[ https://issues.apache.org/jira/browse/STDCXX-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black resolved STDCXX-440. - Resolution: Fixed Resolving issue as Fixed. The latest subversion change fixes the misbehavior observed. This change has been verified under manual testing. I think the reason this bug wasn't spotted before was because the only limit being set with any regularity was RLIMIT_CORE, which is the first limit which was being checked in the loop. Refactoring the common data shared between parse_limit_opts() and limit_process() is outside the scope of this issue and should probably be filed as an enhancement for 4.2.1. If it is necessary to reevaluate the limits being set, this issue can be reopened. > 23_allocator test case can consume all system memory > > > Key: STDCXX-440 > URL: https://issues.apache.org/jira/browse/STDCXX-440 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2 > Environment: RHAP 5 (possibly others) >Reporter: Eric Lemings >Assignee: Andrew Black >Priority: Critical > Fix For: 4.2 > > Attachments: sample-top.txt > > > The 22_allocator test case has been observed to consume all primary and > virtual memory bringing the unfortunate system to its knees. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Out of date platform support listing?
Greetings all. I am glancing at the list of platforms we claim to support on our index page, and I'm questioning how accurate it is. As an example, we claim support for the 7.0 version of the Intel compiler, despite not having systematic tested anything older than the 9.0 version of the compiler for some time. Similar discrepancies can be noted with nearly every other compiler. I believe it would make sense to update this listing prior to the 4.2.0 release, but some consensus needs to be reached on which versions we can claim support with. --Andrew Black
[jira] Closed: (STDCXX-173) [ICC 9.0/Redhat 4 IA64] Tests/Examples fail to link
[ https://issues.apache.org/jira/browse/STDCXX-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black closed STDCXX-173. --- Resolution: Fixed Fix Version/s: trunk A manual test with ICC 9.0.031 and subversion trunk head clears (and has for some time, based on the comments). We don't appear to have any computers available with an older version of the OS/compiler, so I can't test the pre-8.1 versions of the ICC compiler. Therefore, I'm closing this as fixed, and we can reopen things if problems are encountered with older compilers. > [ICC 9.0/Redhat 4 IA64] Tests/Examples fail to link > --- > > Key: STDCXX-173 > URL: https://issues.apache.org/jira/browse/STDCXX-173 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests > Environment: [EMAIL PROTECTED] examples]$ uname -a > Linux panama 2.6.9-22.EL #1 SMP Mon Sep 19 17:54:55 EDT 2005 ia64 ia64 ia64 > GNU/Linux > [EMAIL PROTECTED] examples]$ icc -v > Version 9.0 > Reporter: Andrew Black >Assignee: Andrew Black >Priority: Critical > Fix For: trunk > > > When building tests/examples, the output similar to the following is produced: > icc -Xc -no_cpprt -O2 -w1 -I/build/ablack/stdcxx/include/ansi > -D_RWSTD_USE_CONFIG -I/build/ablack/stdcxx-icc/include > -I/build/ablack/stdcxx/include -I/build/ablack/stdcxx/../rwtest > -I/build/ablack/stdcxx/../rwtest/include -I/build/ablack/stdcxx/tests/include > -L/build/ablack/stdcxx-icc/rwtest -lrwtest8D -L/build/ablack/stdcxx-icc/lib > -lstd8D /build/ablack/stdcxx/tests/algorithms/25.heap.cpp > /build/ablack/stdcxx-icc/lib/libstd8D.so > /build/ablack/stdcxx-icc/rwtest/librwtest8D.a -Bstatic -lcxa -lunwind > -Bdynamic > /nfs/packages/mdx/redhat/ia64/compilers/intel/cc_9.0.031/lib/crtxn.o -lm -o > 25.heap > /build/ablack/stdcxx-icc/rwtest/librwtest8D.a(printf.o)(.text+0x106f2): In > function `__sti__$E': > : undefined reference to `__dso_handle' > /build/ablack/stdcxx-icc/rwtest/librwtest8D.a(fmt_bits.o)(.text+0x2ff2): In > function `__sti__$E': > : undefined reference to `__dso_handle' > /nfs/packages/mdx/redhat/ia64/compilers/intel/cc_9.0.031/lib/crtxn.o(.gnu.linkonce.t.fini+0x20): > In function `__icrt_terminate()': > : undefined reference to `__dso_handle' > /usr/lib/libc_nonshared.a(atexit.oS)(.text+0x1): In function `atexit': > : undefined reference to `__dso_handle' > /usr/lib/libc_nonshared.a(atexit.oS)(.text+0x21): In function `atexit': > : undefined reference to `__dso_handle' > Based on comparisions with the compile/link lines used within RCB, it appears > to me that the cause of this problem is that the executables aren't being > linked with $(ICCDIR)/crtxi.o > Adding this to the begining of the LDLIBS macro and removing it from the end > of the LD macro in icc.config appears to resolve the issue on this platform, > but I haven't tested it in other places where it was building. > I believe this problem may have arrisen from the fact that tests and examples > are compiled in a single step, bypassing the use of the LD macro. This issue > only seems to show up in release builds on this platform, possibly due to > optimizer issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-518) std::string copy constructor slow
[
https://issues.apache.org/jira/browse/STDCXX-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Black updated STDCXX-518:
Severity: Inefficiency
Fix Version/s: 4.2.1
Updated Severity field to describe impact and scheduling for 4.2.1. We aren't
going to have time to look into this this cycle, but it is best looked into
sooner rather than later.
> std::string copy constructor slow
> -
>
> Key: STDCXX-518
> URL: https://issues.apache.org/jira/browse/STDCXX-518
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: 21. Strings
>Affects Versions: 4.1.3
> Environment: gcc 4.1.2, x86_64
>Reporter: Mark Brown
> Fix For: 4.2.1
>
>
> When thread safety is enabled in stdcxx the string copy constructor is more
> than ten times slower than when it's not, and twice as slow as the same copy
> constructor in gcc 4.1.2 on Linux (x86_64), but slightly faster than with
> STLport 5.1.3. The timings were done on Intel x86_64 at 2.4GHz:
> BUILDMODE=shared,optimized:
> $ time LD_LIBRARY_PATH=../lib ./string-copy 1
> real0m0.482s
> user0m0.480s
> sys 0m0.000s
> BUILDMODE=shared,optimized,pthread:
> $ time LD_LIBRARY_PATH=../lib ./string-copy 1
> real0m10.157s
> user0m10.041s
> sys 0m0.032s
> gcc 4.1.2 with -O2 -m64:
> $ time ./string-copy.gcc 1
> real0m4.280s
> user0m4.260s
> sys 0m0.020s
> gcc 4.1.2 with STLport 5.1.3 (-D_REENTRANT -O2 -m64 -lpthread):
> $ time ./string-copy.stlport 1
> real0m12.479s
> user0m12.473s
> sys 0m0.004s
> #include
> #include
> #include
> int main (int argc, char *argv[])
> {
> const unsigned long n = argc < 2 ? 0 : std::strtoul (argv [1], 0, 10);
> std::string strings [256];
> const std::size_t num_strings = sizeof strings / sizeof *strings;
> for (unsigned long i = 0; i != num_strings; ++i)
> strings [i].assign (i, 'x');
> for (unsigned long i = 0; i < n; ++i) {
> const std::size_t length = i % num_strings;
> const std::string str (strings [length]);
> assert (str.size () == length);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r577098 - in /incubator/stdcxx/trunk/include/loc: _messages.cc _messages.h
Greetings Martin
It appears to me that this change broke compilation of the library with
the Sunpro 5.6 and 5.8 compilers (5.3 is probably also affected, 5.9
isn't). The error message observed is as follows:
> CC -c -I$(TOPDIR)/include -I$(BUILDDIR)/include -library=%none -O
> -xarch=v9 +w -KPIC $(TOPDIR)/src/exception.cpp
> "$(TOPDIR)/include/loc/_messages.cc", line 52: Error:
> "std::messages::do_close(std::messages::catalog)
> const" was previously declared "std::messages::do_close(int)
> const".
--Andrew Black
[EMAIL PROTECTED] wrote:
> Author: sebor
> Date: Tue Sep 18 15:57:00 2007
> New Revision: 577098
>
> URL: http://svn.apache.org/viewvc?rev=577098&view=rev
> Log:
> 2007-09-18 Martin Sebor <[EMAIL PROTECTED]>
>
> * _messages.h (do_open, do_close): Outlined virtual functions
> to avoid code bloat due to compiler emitting their definition
> in every object file where the class is used.
> * _messages.cc: Same.
>
> Modified:
> incubator/stdcxx/trunk/include/loc/_messages.cc
> incubator/stdcxx/trunk/include/loc/_messages.h
>
> Modified: incubator/stdcxx/trunk/include/loc/_messages.cc
> URL:
> http://svn.apache.org/viewvc/incubator/stdcxx/trunk/include/loc/_messages.cc?rev=577098&r1=577097&r2=577098&view=diff
> ==
> --- incubator/stdcxx/trunk/include/loc/_messages.cc (original)
> +++ incubator/stdcxx/trunk/include/loc/_messages.cc Tue Sep 18 15:57:00 2007
> @@ -6,22 +6,23 @@
> *
> ***
> *
> - * Copyright 2005-2006 The Apache Software Foundation or its licensors,
> - * as applicable.
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed
> + * with this work for additional information regarding copyright
> + * ownership. The ASF licenses this file to you under the Apache
> + * License, Version 2.0 (the "License"); you may not use this file
> + * except in compliance with the License. You may obtain a copy of
> + * the License at
> *
> - * Copyright 2001-2006 Rogue Wave Software.
> - *
> - * Licensed under the Apache License, Version 2.0 (the "License");
> - * you may not use this file except in compliance with the License.
> - * You may obtain a copy of the License at
> - *
> - * http://www.apache.org/licenses/LICENSE-2.0
> + * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> - * distributed under the License is distributed on an "AS IS" BASIS,
> - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> - * See the License for the specific language governing permissions and
> - * limitations under the License.
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> + * implied. See the License for the specific language governing
> + * permissions and limitations under the License.
> + *
> + * Copyright 1994-2007 Rogue Wave Software, Inc.
> *
> **/
>
> @@ -33,6 +34,25 @@
>
> template
> _RW::__rw_facet_id messages<_CharT>::id;
> +
> +
> +template
> +_TYPENAME messages<_CharT>::catalog
> +messages<_CharT>::
> +do_open (const string& __fun, const locale&__loc) const
> +{
> +return _RW::__rw_cat_open (__fun, __loc);
> +}
> +
> +
> +template
> +void
> +messages<_CharT>::
> +do_close (catalog __cat) const
> +{
> +_RW::__rw_cat_close (__cat);
> +}
> +
>
> template
> _TYPENAME messages<_CharT>::string_type
>
> Modified: incubator/stdcxx/trunk/include/loc/_messages.h
> URL:
> http://svn.apache.org/viewvc/incubator/stdcxx/trunk/include/loc/_messages.h?rev=577098&r1=577097&r2=577098&view=diff
> ==
> --- incubator/stdcxx/trunk/include/loc/_messages.h (original)
> +++ incubator/stdcxx/trunk/include/loc/_messages.h Tue Sep 18 15:57:00 2007
> @@ -25,7 +25,7 @@
> * implied. See the License for the specific language governing
> * permissions and limitations under the License.
> *
> - * Copyright 1994-2006 Rogue Wave Software.
> + * Copyright 1994-2007 Rogue Wave Software, Inc.
> *
> *
[jira] Commented: (STDCXX-440) 23_allocator test case can consume all system memory
[ https://issues.apache.org/jira/browse/STDCXX-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528441 ] Andrew Black commented on STDCXX-440: - I'm not certain I agree with your conclusion about a misbehavior in the limit_process logic Martin. The flow control operator used in limit_process is a 'continue', not a 'break'. Unless I'm seriously mistaken, this essentially skips over the remainder of the for loop, sending the flow back to the start of the loop and incrementing the counter. > 23_allocator test case can consume all system memory > > > Key: STDCXX-440 > URL: https://issues.apache.org/jira/browse/STDCXX-440 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2 > Environment: RHAP 5 (possibly others) > Reporter: Eric Lemings >Assignee: Andrew Black >Priority: Critical > Fix For: 4.2 > > Attachments: sample-top.txt > > > The 22_allocator test case has been observed to consume all primary and > virtual memory bringing the unfortunate system to its knees. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Windows build failures
Greetings all.
As I mentioned earlier, I reloaded the nightly testing archives earlier
to recover from a failed glue script update. Most builds have re-run at
this point, so I'm going to try to annotate the list based on what I'm
seeing in the nightly testing system at the moment. These results (or
updated versions) will be exported tomorrow, though I'm going on
vacation for a couple days, so I'm trying to send this out before I go.
Martin Sebor wrote:
> We continue to be having serious problems in our latest results
> due to what looks like infrastructure or setup issues (we had no
> updates over the weekend due to a ssh permission issue I ran
> into last Friday). I isolated the problematic results into the
> attached page to make it easier to focus on them. Below is
> a digest summarizing the problems from the logs.
>
> Andrew, Farid: have you made any progress on these?
>
> win_2000-4-x86
> All builds still in DATA state. This includes MSVC 7.1 and Intel
> C++ 9.1 and 10.0.
See STDCXX-543. The state of these builds has improved, as the Intel
builds are now only lacking the test suite results, rather than all
results as had been the case before (due to compiler sanity check failures)
> win_*-em64t, msvc-8.0, 12D-win32
> All locale tests fail with exit status of 4. This includes all
> versions of Windows, including 2003, XP, and Vista.
This appears to have been resolved. We are still seeing several locale
tests terminate with an exit status of 4, but these failures appear to
be consistent with other build types.
>
> win_xp-1-em64t, icl-10.0, {12D,15S}-win32
> win_xp-2-x86, icl-9.1
> Library fails to build with "Cannot access data for the desired
> file since it is in a zombie state."
Resolved on XP em64t, not resolved for XP x86. I'm not certain if it's
a case of http://svn.apache.org/viewvc?rev=575000&view=rev not being
included in the archive, or if there is a subtle issue in the changes
for icl-9.1.
>
> win_xp-2-x86, msvc-8.0, 12d-win32
> Build fails at:
>
> checking system
> architectured:\bman5\builds\34027456\source-buildspace\etc\config\windows\configure.wsf(342,
> 10) Microsoft JScript runtime error: Permission denied
> Project : error PRJ0019: A tool returned an error code from "Performing
> Custom Build Step"
>
Resolved.
--Andrew Black
Re: Windows build failures
Martin Sebor wrote:
> Farid Zaripov wrote:
>>> -Original Message-
>>> From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday,
>>> September 11, 2007 10:01 PM
>>> To: stdcxx-dev@incubator.apache.org
>>> Subject: Re: Windows build failures
>>
>>> Andrew, Farid: have you made any progress on these?
>>>
>>> win_2000-4-x86
>>>All builds still in DATA state. This includes MSVC 7.1 and Intel
>>>C++ 9.1 and 10.0.
>>
>> As I sad I think the problem in very long command line. I'll manage
>> this problem by extending exec utility to support passing the programs
>> list through file.
>
> Ah, yes. I had a conversation with Andrew about this last week
> and we agreed that this was going to be the way to proceed.
> Somehow, making it happen or at least opening an issue for it
> slipped through the cracks.
You created an issue for it Martin:
https://issues.apache.org/jira/browse/STDCXX-543
>
>>
>>> win_*-em64t, msvc-8.0, 12D-win32
>>>All locale tests fail with exit status of 4. This includes all
>>>versions of Windows, including 2003, XP, and Vista.
>>
>>> win_xp-1-em64t, icl-10.0, {12D,15S}-win32 win_xp-2-x86, icl-9.1
>>>Library fails to build with "Cannot access data for the desired
>>>file since it is in a zombie state."
>>
>> Possibly the problem caused by that both ICC 9.1 and ICC 10.0
>> installed on the same machine. I think my current patch will help.
>> http://svn.apache.org/viewvc?rev=575000&view=rev
>
> Andrew, please keep an eye on this and if the patch doesn't do
> it help Farid figure out what's causing this.
Hopefully we'll get a fairly quick turnaround on this. I blotched a
change to the windows glue scripts yesterday, which I've fixed, and I am
in the process of rebuilding archives to get it into nightly testing. I
think Farid's change made it into the archive, but I'm not certain.
--Andrew Black
Re: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat generate.bat
Martin Sebor wrote: > Come to think of it, aren't we already using tar and gzip to > package up our builds? Andrew, can we switch to tar/gzip for > our sources as well? No. We still package the post-build archives on windows using jar, and I don't think the nightly testing system is capable of handling tar/gzip or tar/bzip source archives. --Andrew Black
Re: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat generate.bat
Farid Zaripov wrote: [snip] > > Because of that the filebuf example always fail with DIFF status on my > workstation > (the manual/out/filebuf.out is a symbolic link to manual/filebuf.cpp, > but on windows > the content of this file is just single line: "link ../filebuf.cpp"). > > I surprized how this example runs with status 0 in nightly builds. > > Farid. Greetings Farid. The reason the filebuf test succeeds in nightly testing is an artifact of the build process. The sources are synced down on a linux system, and then compressed using the jar utility. This compressed archive is then expanded by the nightly testing system when a build is performed. Somewhere during this process, the symlink (on unix) is turned into a real file, containing the expected input. --Andrew Black
Re: 4.2.0-rc-3 and results
Martin Sebor wrote: > Andrew Black wrote: >> Martin Sebor wrote: >> [...] >>> Btw., was there anything else besides creating a .htaccess file >>> in the results directory that I had to do to get Mozilla open >>> up the gzipped build logs? I copied the .htaccess file from the >>> -rc-1/results/ directory into -rc-3/results/ but I'm still >>> getting the darn "what should Mozilla do with this file?" >>> window. >> >> I don't think anything else was required, and a couple random files I've >> pulled up from the -rc-3/results directory are behaving normally. >> Perhaps it just took apache a couple minutes to pick up the .htaccess >> file? Alternately, perhaps Mozilla is caching the file with the wrong >> headers. > > I can open some but not this one: > http://people.apache.org/~sebor/stdcxx-4.2.0-rc-3/results/hpux-11.23-pa-acc-3.73-12d-569584-log.gz.txt > > > Can you open it? Opens for me - I blame Mozilla's cache. > > Martin
Re: 4.2.0-rc-3 and results
Martin Sebor wrote: [...] > > Btw., was there anything else besides creating a .htaccess file > in the results directory that I had to do to get Mozilla open > up the gzipped build logs? I copied the .htaccess file from the > -rc-1/results/ directory into -rc-3/results/ but I'm still > getting the darn "what should Mozilla do with this file?" > window. I don't think anything else was required, and a couple random files I've pulled up from the -rc-3/results directory are behaving normally. Perhaps it just took apache a couple minutes to pick up the .htaccess file? Alternately, perhaps Mozilla is caching the file with the wrong headers. --Andrew Black > > Martin
Re: 4.2.0-rc-3 and results
Greetings Martin I've created the -rc-3 branch, though I realized that I blotched the ChangeLog entry as I was reviewing the branch. Performing a -rc-2 result run would be fairly simple, and would only require updating the set of sources used for the release branch testing. However, I'd want to finish the current set of -rc-3 runs prior to doing this. The source file for the -rc-3 runs was updated last night thanks to a minor change to the legacy test driver. --Andrew Black Martin Sebor wrote: > I've added a page with the latest 4.2.0 results, soon to be tagged > -rc-3: > > http://people.apache.org/~sebor/stdcxx-4.2.0-rc-3/results/ > > The only difference between -rc-3 and -rc-2 is support for Sun C++ > 5.9. There are no -rc-2 results yet (we haven't created any; Andrew, > could we do that pretty easily?) The most recent results prior to > rc-3 are for -rc-1: > > http://people.apache.org/~sebor/stdcxx-4.2.0-rc-1/results/ > > I expect to create an -rc-4 once I'm done with STDCXX-501. If we can > get STDCXX-545 fixed soon, I'll include it in it as well. Otherwise, > it'll go in the next (and hopefully final) 4.2.0 release candidate. > > Martin
[jira] Commented: (STDCXX-545) [Sunpro 5.9 - x86] UBE compiling collate.ccp
[ https://issues.apache.org/jira/browse/STDCXX-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525468 ] Andrew Black commented on STDCXX-545: - These failures were observed in nightly testing, and I have not had time to reduce the file to a test case. The similarity of the error messages between the Linux and Solaris builds indicates to me that the fault lies in the architecture specific portion of the compiler. For reference, the following links point at run logs which include the failing behavior: http://people.apache.org/~sebor/stdcxx/results/solaris-10-amd64-sunpro-5.9-12S-572853-log.gz.txt (Solaris 10 AMD64) http://people.apache.org/~sebor/stdcxx/results/linux_suse-9.1-amd64-sunpro-5.9-12d-570904-log.gz.txt (Suse 9 AMD64) http://people.apache.org/~sebor/stdcxx/results/linux_redhat_el-4.4-amd64-sunpro-5.9-12d-573119-log.gz.txt (Redhat 4 AMD64) http://people.apache.org/~sebor/stdcxx/results/linux_redhat_el-4.4-em64t-sunpro-5.9-12d-570904-log.gz.txt (Redhat 4 EM64T) > [Sunpro 5.9 - x86] UBE compiling collate.ccp > - > > Key: STDCXX-545 > URL: https://issues.apache.org/jira/browse/STDCXX-545 > Project: C++ Standard Library > Issue Type: Bug > Components: Utilities >Affects Versions: trunk > Environment: CC: Sun C++ 5.9 SunOS_i386 2007/05/03 (SunOS marbles > 5.10 Generic_118855-33 i86pc i386 i86pc) > CC: Sun C++ 5.9 Linux_i386 2007/05/03 (Linux jacks 2.6.5-7.244-smp #1 SMP Mon > Dec 12 18:32:25 UTC 2005 x86_64 x86_64 x86_64 GNU/Linux) >Reporter: Andrew Black > > When compiling the locale utility in release mode on x86 hardware with the > Sunpro 5.9 compiler, a UBE error is triggered when attempting to build the > collate.cpp source. This appears to only trigger in wide mode (at least on > Solaris). > For Solaris on AMD64 hardware, the error observed is: > CC -c -mt -I$(TOPDIR)/include -I$(BUILDDIR)/include -library=%none -O -m64 > +w -errtags -erroff=hidef $(TOPDIR)/util/collate.cpp > ... > "collate.cpp", [__1cDDefNprocess_order6Mrn0ARcollate_section_t_rI_v_]:ube: > error: Assert has been violated at > '/set/mars/builds.intel-S2/nightly.Thu/intel-S2/lang/ube/machine/src/abi_call.c > 172'. > For Linux builds, the error observed is: > CC -c -mt -I$(TOPDIR)/include -I$(BUILDDIR)/include -library=%none -O > -xarch=generic +w $(TOPDIR)/util/collate.cpp > ... > "collate.cpp", [__1cDDefNprocess_order6Mrn0ARcollate_section_t_rI_v_]:ube: > error: Assert has been violated at > '/set/mars/builds.intel-Linux/nightly.Thu/intel-Linux/lang/ube/machine/src/abi_call.c > 172'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-545) [Sunpro 5.9 - x86] UBE compiling collate.ccp
[Sunpro 5.9 - x86] UBE compiling collate.ccp - Key: STDCXX-545 URL: https://issues.apache.org/jira/browse/STDCXX-545 Project: C++ Standard Library Issue Type: Bug Components: Utilities Affects Versions: trunk Environment: CC: Sun C++ 5.9 SunOS_i386 2007/05/03 (SunOS marbles 5.10 Generic_118855-33 i86pc i386 i86pc) CC: Sun C++ 5.9 Linux_i386 2007/05/03 (Linux jacks 2.6.5-7.244-smp #1 SMP Mon Dec 12 18:32:25 UTC 2005 x86_64 x86_64 x86_64 GNU/Linux) Reporter: Andrew Black When compiling the locale utility in release mode on x86 hardware with the Sunpro 5.9 compiler, a UBE error is triggered when attempting to build the collate.cpp source. This appears to only trigger in wide mode (at least on Solaris). For Solaris on AMD64 hardware, the error observed is: CC -c -mt -I$(TOPDIR)/include -I$(BUILDDIR)/include -library=%none -O -m64 +w -errtags -erroff=hidef $(TOPDIR)/util/collate.cpp ... "collate.cpp", [__1cDDefNprocess_order6Mrn0ARcollate_section_t_rI_v_]:ube: error: Assert has been violated at '/set/mars/builds.intel-S2/nightly.Thu/intel-S2/lang/ube/machine/src/abi_call.c 172'. For Linux builds, the error observed is: CC -c -mt -I$(TOPDIR)/include -I$(BUILDDIR)/include -library=%none -O -xarch=generic +w $(TOPDIR)/util/collate.cpp ... "collate.cpp", [__1cDDefNprocess_order6Mrn0ARcollate_section_t_rI_v_]:ube: error: Assert has been violated at '/set/mars/builds.intel-Linux/nightly.Thu/intel-Linux/lang/ube/machine/src/abi_call.c 172'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Windows build failures
Farid Zaripov wrote: >> -Original Message- >> From: Martin Sebor [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, September 04, 2007 8:28 PM >> To: stdcxx-dev@incubator.apache.org >> Subject: Windows build failures >> >> What is the status of the Windows builds on trunk? There >> still are a large number of severe failures that need to be >> resolved for the 4.2 release: >> >> win_2000-4-x86 icl-10.0all > The command call "%ICPP_COMPILER10%\IA32\Bin\iclvars.bat" failed with > error: > "The system cannot find the path specified." > >> win_2000-4-x86 icl-9.1 all > The command call "%ICPP_COMPILER91%\IA32\Bin\iclvars.bat" failed with > error: > "The system cannot find the path specified." > > Is needed to check whether that path valid or not. Andrew, can you > chek this? Greetings Farid The iclvars.bat scripts are being used to set up the environment from a theoretically empty state. In particular, the command 'call setenv icl-10.0' results in call "C:\Program Files\Intel\Compiler\C++\10.0.026\IA32\Bin\iclvars.bat" and the command 'call setenv icl-9.1' results in call "C:\Program Files\Intel\Compiler\C++\9.1\IA32\Bin\iclvars.bat" . Both of the calls to setenv (a pesky batch script) are made near the beginning of the build process. --Andrew Black
Re: svn commit: r570898 - /incubator/stdcxx/trunk/tests/regress/27.filebuf.virtuals.stdcxx-522.cpp
Greetings Martin Is this change what you intended it to be? It appears to me that you checked in a symlink pointing at a file residing outside the subversion repository. --Andrew Black [EMAIL PROTECTED] wrote: > Author: sebor > Date: Wed Aug 29 12:11:51 2007 > New Revision: 570898 > > URL: http://svn.apache.org/viewvc?rev=570898&view=rev > Log: > 2007-08-29 Martin Sebor <[EMAIL PROTECTED]> > > * 27.filebuf.virtuals.stdcxx-522.cpp: Regression test for STDCXX-522. > > Added: > incubator/stdcxx/trunk/tests/regress/27.filebuf.virtuals.stdcxx-522.cpp > (with props) > > Added: incubator/stdcxx/trunk/tests/regress/27.filebuf.virtuals.stdcxx-522.cpp > URL: > http://svn.apache.org/viewvc/incubator/stdcxx/trunk/tests/regress/27.filebuf.virtuals.stdcxx-522.cpp?rev=570898&view=auto > == > --- incubator/stdcxx/trunk/tests/regress/27.filebuf.virtuals.stdcxx-522.cpp > (added) > +++ incubator/stdcxx/trunk/tests/regress/27.filebuf.virtuals.stdcxx-522.cpp > Wed Aug 29 12:11:51 2007 > @@ -0,0 +1 @@ > +link /build/sebor/tmp/t.cpp > \ No newline at end of file > > Propchange: > incubator/stdcxx/trunk/tests/regress/27.filebuf.virtuals.stdcxx-522.cpp > -- > svn:eol-style = native > > Propchange: > incubator/stdcxx/trunk/tests/regress/27.filebuf.virtuals.stdcxx-522.cpp > -- > svn:keywords = Id > > Propchange: > incubator/stdcxx/trunk/tests/regress/27.filebuf.virtuals.stdcxx-522.cpp > -- > svn:special = * > > >
Re: Exec utility test group reporting
Mark Brown wrote: >> -Original Message- >> From: [EMAIL PROTECTED] >> Sent: Mon, 27 Aug 2007 09:11:51 -0600 >> To: stdcxx-dev@incubator.apache.org >> Subject: Re: Exec utility test group reporting >> >> Greetings Mark >> >> At this point, the validity, usability and accuracy of the Doxygen >> comments in the exec utility is a theoretical exercise, as I don't think >> anyone's ever taken the step of generating the documentation pages from >> the source files. That said, I've installed doxygen locally, and will >> share the results if I have time to play with it. > > Well, I tried generating documentation for the stdcxx/util directory to see > how Doxygen does. The result is published on my home page: > http://mark.g.brown.googlepages.com/stdcxxutil. This is my first attempt to > use the site so pardon the appearance of the entry page. In my opinion, it > doesn't look half bad, don't you think? Ascetically the pages look decent (with the exception of a 404 on http://mark.g.brown.googlepages.com/structtarget__opts.html ), however they feel a little light on content. Is there a switch to get doxygen to generate the documentation for variables and functions outside of classes? The bulk of the documentation for the exec utility is in these areas, rather than the structs which are used to pass data around. (Is there a C mode that you could force doxygen to use? The exec utility was written as a C program, though the files were given a .cpp suffix so they could build with the infrastructure.) > >> It would likely make sense to eventually store the generated docs >> somewhere in subversion, but the potential problem of documentation >> drift exists. I suppose this shouldn't count as a strike against using >> Doxygen, as that potential exists for all documentation. > > Would generating the documentation automatically be a solution? That would be a solution, but as best I can tell, you'd have to do the regeneration on the subversion server as part of a commit script, and I don't know if we have the ability to set such things up. --Andrew Black
Re: svn commit: r569584 - in /incubator/stdcxx/branches/4.2.0: GNUmakefile etc/config/GNUmakefile.cfg etc/config/makefile.rules etc/config/src/LIMITS.cpp etc/config/sunpro.config
*shrugs* I normally don't work with any part of subversion other than trunk, so I'm not as familiar with the procedures for working on the branches. I suppose I should have sent the proposed patch to the list while I was running the couple sanity builds, but I was more concerned with trying to get things recovered from the bad merge, along with other internal work. The nightly testing sources need to be updated for the 4.2.0 release branch, but provided we get decent results out of it I'm thinking we'll probably end up tagging it as -rc2. --Andrew Black Martin Sebor wrote: > [EMAIL PROTECTED] wrote: >> Author: ablack >> Date: Fri Aug 24 17:29:23 2007 >> New Revision: 569584 >> >> URL: http://svn.apache.org/viewvc?rev=569584&view=rev >> Log: >> 2007-08-24 Andrew Black <[EMAIL PROTECTED]> >> >> STDCXX-470 >> STDCXX-479 >> STDCXX-481 > > FWIW, this change doesn't fix these bugs, it just integrates > the already committed fixes to the [pre]release branch. So, > IMO, the bugs shouldn't be referenced here. The main reason > why I think it's wrong is because this commit is now recorded > in each of the issues, giving the impression that it's a patch > necessary to fix the bugs. > > In addition, quoting from the Committers section of our page > (http://incubator.apache.org/stdcxx/#committers), the policy > that we all voted in is: > > "For potentially unsafe changes or any changes to branches > all stdcxx committers follow the Review-Then-Commit policy > (RTC for short)." > > Martin > >> * etc/config/src/LIMITS.cpp: Revert >> http://svn.apache.org/viewvc?view=rev&revision=554421 , >> accidentally merged to 4.2.0 prematurely as part of >> http://svn.apache.org/viewvc?view=rev&revision=569152 . >> * GNUmakefile: Deploy >> http://svn.apache.org/viewcvs?view=rev&rev=555061 to enable >> building with Sun C++ 5.9 (Sun Studio 12). >> * etc/config/GNUmakefile.cfg: Ditto. >> * etc/config/sunpro.config: Ditto. >> * etc/config/makefile.rules: Ditto. >> >> Modified: >> incubator/stdcxx/branches/4.2.0/GNUmakefile >> incubator/stdcxx/branches/4.2.0/etc/config/GNUmakefile.cfg >> incubator/stdcxx/branches/4.2.0/etc/config/makefile.rules >> incubator/stdcxx/branches/4.2.0/etc/config/src/LIMITS.cpp >> incubator/stdcxx/branches/4.2.0/etc/config/sunpro.config >> >> Modified: incubator/stdcxx/branches/4.2.0/GNUmakefile >> URL: >> http://svn.apache.org/viewvc/incubator/stdcxx/branches/4.2.0/GNUmakefile?rev=569584&r1=569583&r2=569584&view=diff >> >> == >> >> --- incubator/stdcxx/branches/4.2.0/GNUmakefile (original) >> +++ incubator/stdcxx/branches/4.2.0/GNUmakefile Fri Aug 24 17:29:23 2007 >> @@ -588,7 +588,10 @@ >>&& echo "PICFLAGS = $(PICFLAGS)" >> >> $(MAKEFILE_IN) \ >>&& echo "CPPFLAGS = $(CPPFLAGS)" >> >> $(MAKEFILE_IN) \ >>&& echo "WARNFLAGS = $(WARNFLAGS)">> >> $(MAKEFILE_IN) \ >> - && echo "DEPENDFLAGS = $(DEPENDFLAGS)" >> >> $(MAKEFILE_IN) \ >> + && echo "DEPENDFLAGS = $(DEPENDFLAGS)" >> >> $(MAKEFILE_IN) \ >> + && echo "DEPENDFLAGS.cpp = $(DEPENDFLAGS.cpp)" >> >> $(MAKEFILE_IN) \ >> + && echo "DEPENDFLAGS$(AS_EXT) = $(value >> DEPENDFLAGS$(AS_EXT))"\ >> + >> >> $(MAKEFILE_IN) \ >>&& echo "AS_EXT = $(AS_EXT)" >> >> $(MAKEFILE_IN) \ >>&& echo "LD = $(LD)" >> >> $(MAKEFILE_IN) \ >>&& echo "LDFLAGS= $(LDFLAGS)" >> >> $(MAKEFILE_IN) \ >> >> Modified: incubator/stdcxx/branches/4.2.0/etc/config/GNUmakefile.cfg >> URL: >> http://svn.apache.org/viewvc/incubator/stdcxx/branches/4.2.0/etc/config/GNUmakefile.cfg?rev=569584&r1=569583&r2=569584&view=diff >> >> == >> >> --- incubator/stdcxx/branches/4.2.0/etc/config/GNUmakefile.cfg (original) >> +++ incubator/stdcxx/branches/4.2.0/etc/config/GNUmakefile.cfg Fri Au
[jira] Updated: (STDCXX-2) [MSVC] std::num_put bad formatting of 0.0 with precision and showpoint
[
https://issues.apache.org/jira/browse/STDCXX-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Black updated STDCXX-2:
--
Fix Version/s: 4.2.1
Affects Version/s: 4.1.3
4.1.4
Updating affects/fix versions to reflect STDCXX-497 (Should this be closed as a
duplicate?)
> [MSVC] std::num_put bad formatting of 0.0 with precision and showpoint
> --
>
> Key: STDCXX-2
> URL: https://issues.apache.org/jira/browse/STDCXX-2
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: Windows/MSVC
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2.1
>
>
> When compiled with MSVC (any version), the program below aborts at runtime.
> $ cat t.cpp && cl -D_RWCONFIG=11s_msvc_7_1
> -Ic:/contrib/cygwin/build/sebor/dev-hal/include -I./../../../../include
> -Ic:/contrib/cygwin/build/sebor/dev-hal/examples/stdlib/manual/../include
> -Ic:/contrib/cygwin/build/sebor/dev-hal/include/ansi -I./../../../..
> -Ic:/contrib/cygwin/build/sebor/dev-hal
> -Ic:/contrib/cygwin/build/sebor/dev-hal/examples/stdlib/manual -I. -nologo
> -GX -MLd -W3 -Zi -GA -GR -GF -GZ -c t.cpp && link -nologo
> /NODEFAULTLIB:libcpd /debug /LIBPATH:./../../../../lib /OUT:t.exe t.obj
> std11s_msvc_7_1.lib user32.lib t.cpp && ./t.exe
> #include
> #include
> int main ()
> {
> std::ostringstream strm;
> strm.setf (strm.showpoint);
> strm.precision (2);
> strm << 0.0;
> assert ("0.0" == strm.str ());
> }
> Assertion failed: "0.0" == strm.str (), file t.cpp, line 13
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-497) [MSVC 7.1] std::num_put bad formatting of 0.0 with precision and showpoint
[
https://issues.apache.org/jira/browse/STDCXX-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Black updated STDCXX-497:
Fix Version/s: 4.2.1
Affects Version/s: 4.1.2
4.1.4
I suspect this issue has been present a long time and isn't critical to the
4.2.0 release. Scheduling for 4.2.1
> [MSVC 7.1] std::num_put bad formatting of 0.0 with precision and showpoint
> --
>
> Key: STDCXX-497
> URL: https://issues.apache.org/jira/browse/STDCXX-497
> Project: C++ Standard Library
> Issue Type: Bug
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: MSVC 7.1
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2.1
>
>
> Moved from Rogue Wave Bugzilla:
> http://bugzilla.cvo.roguewave.com/show_bug.cgi?id=1550
> $ cat t.cpp && cl -D_RWCONFIG=11s_msvc_7_1
> -Ic:/contrib/cygwin/build/sebor/dev-hal/include
> -I./../../../../include
> -Ic:/contrib/cygwin/build/sebor/dev-hal/examples/stdlib/manual/../include
> -Ic:/contrib/cygwin/build/sebor/dev-hal/include/ansi -I./../../../..
> -Ic:/contrib/cygwin/build/sebor/dev-hal
> -Ic:/contrib/cygwin/build/sebor/dev-hal/examples/stdlib/manual -I.
> -nologo -GX -MLd -W3 -Zi -GA -GR -GF -GZ -c t.cpp && link -nologo
> /NODEFAULTLIB:libcpd /debug /LIBPATH:./../../../../lib /OUT:t.exe
> t.obj std11s_msvc_7_1.lib user32.lib
> t.cpp && ./t.exe
> #include
> #include
> int main ()
> {
> std::ostringstream strm;
> strm.setf (strm.showpoint);
> strm.precision (2);
> strm << 0.0;
> assert ("0.0" == strm.str ());
> }
> Assertion failed: "0.0" == strm.str (), file t.cpp, line 13
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Exec utility test group reporting
Greetings Mark At this point, the validity, usability and accuracy of the Doxygen comments in the exec utility is a theoretical exercise, as I don't think anyone's ever taken the step of generating the documentation pages from the source files. That said, I've installed doxygen locally, and will share the results if I have time to play with it. It would likely make sense to eventually store the generated docs somewhere in subversion, but the potential problem of documentation drift exists. I suppose this shouldn't count as a strike against using Doxygen, as that potential exists for all documentation. --Andrew Black Mark Brown wrote: > Hi Andrew, > > I found myself needing documentation for the test driver in the past. Since > you mentioned Doxygen comments in the exec utility, I'm wondering if there is > generated documentation available somewhere that I don't know about. Could > you point me in the right direction? > > Many thanks! > -- Mark > > >> -Original Message- >> From: [EMAIL PROTECTED] >> Sent: Thu, 23 Aug 2007 11:48:26 -0600 >> To: stdcxx-dev@incubator.apache.org >> Subject: Exec utility test group reporting >> >> Greetings all. >> >> Attached is a patch that aims to add some logic to the exec utility to >> report the type of executable being processed. Part of the purpose of >> this change is to assist in making the result parsing more robust. >> >> I am not particularly satisfied with this change for a couple reasons. >> One is because the doxygen comments are getting out of date, and need to >> be gone over. The second is the way data is passed from cmdopt.cpp to >> display.cpp. The current method used is to overload the target_opts >> struct to include the new parameter, but this feels like the wrong way >> to do things. This method was chosen because the verbose flag is >> currently included there, but the exec subsystem shouldn't care about >> either of these things. (The verbose output mode also feels like it was >> hacked on, but that's irrelevant to this topic.) >> >> Does anyone have thoughts on this patch? I should note that some >> changes to the windows infrastructure will be needed to keep the >> behavior in sync with the unix infrastructure. >> >> --Andrew Black > > > KEEP SPYWARE OFF YOUR COMPUTER - Protect your computer with Spyware > Terminator! > Visit http://www.spywareterminator.com/install and find out more!
[jira] Updated: (STDCXX-261) runall should parse tests and examples in the same manner
[ https://issues.apache.org/jira/browse/STDCXX-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black updated STDCXX-261: Fix Version/s: 4.2.1 Scheduling for 4.2.1, though it may be deferred again. > runall should parse tests and examples in the same manner > - > > Key: STDCXX-261 > URL: https://issues.apache.org/jira/browse/STDCXX-261 > Project: C++ Standard Library > Issue Type: Improvement > Components: Build > Reporter: Andrew Black >Priority: Minor > Fix For: 4.2.1 > > > At this time, several of the self tests (0.cmdopts.out, 0.printf.out, > 0.strncmp.out, 0.valcmp.out) produce output that lacks a summary section. > The runall.sh (or runall.c) utility should be able to compare the output of > these tests against a reference file in the same manner that the output is > compared for examples. > An extension of this concept is that it might make sense to unify the logic > used to check the test and example results, so that the same process would be > used for both tests and examples. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-366) Add benchmarking framework
[ https://issues.apache.org/jira/browse/STDCXX-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black updated STDCXX-366: Fix Version/s: 4.2.1 Scheduling for 4.2.1, though it may be differed again. > Add benchmarking framework > -- > > Key: STDCXX-366 > URL: https://issues.apache.org/jira/browse/STDCXX-366 > Project: C++ Standard Library > Issue Type: Wish > Components: Tests > Environment: N/A >Reporter: Andrew Black >Priority: Minor > Fix For: 4.2.1 > > > The Apache C++ Standard library is intended to be a high performance > implementation of the C++ Standard Library. To this end, we have created a > few benchmarking applications, but no systematic effort has been made to > create a set of benchmarking executables, and no infrastructure exists to > build and run such executables in a uniform manner. > We should create a benchmarking infrastructure, modeled on the test > infrastructure. This would likely include a makefile, some kind of benchmark > runner (similar to the exec utility), a (thin) benchmark driver library, and > a set of benchmark programs, each testing a particular class, method, or set > of methods. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-362) [Intel C++ 9.1.042/Linux] compiler hangs on 22.locale.money.put.cpp
[ https://issues.apache.org/jira/browse/STDCXX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black closed STDCXX-362. --- Resolution: Won't Fix Fix Version/s: (was: 4.2) Resolving as Won't Fix, as this can be resolved by upgrading to a newer version of the Intel 9.1 compiler. (4.2.0 will likely be certified with the 9.1.051 patch.) > [Intel C++ 9.1.042/Linux] compiler hangs on 22.locale.money.put.cpp > --- > > Key: STDCXX-362 > URL: https://issues.apache.org/jira/browse/STDCXX-362 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests > Environment: ICC l_cc_c_9.1.042 >Reporter: Andrew Black >Priority: Critical > > When compiling the 22.locale.money.put test with the ICC 9.1.042 compiler, > the compilation process hangs, causing the nightly testing process to stall. > While this doesn't inhibit the usage of the library in other programs, it > prevents nightly testing of stdcxx with this compiler. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-361) [Intel C++ 9.1.042] hangs compiling conditional initialization in template code
[ https://issues.apache.org/jira/browse/STDCXX-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black closed STDCXX-361. --- Resolution: Won't Fix Nightly testing has confirmed that this issue was resolved in later versions of the intel 9.1 compiler (Versions tested have included 9.1.049 and 9.1.051). I'm closing this issue, as it will likely be more efficient for a user to upgrade to a newer version of the compiler than to work around the bug. > [Intel C++ 9.1.042] hangs compiling conditional initialization in template > code > --- > > Key: STDCXX-361 > URL: https://issues.apache.org/jira/browse/STDCXX-361 > Project: C++ Standard Library > Issue Type: Bug > Components: External > Environment: l_cc_c_9.1.042 >Reporter: Andrew Black > Attachments: icc-9.1.042-hang.cpp > > > Intel 9.1.042 on Linux fails to terminate when compiling the attached test > case. This test case is attached as icc-9.1.042-hang.cpp. This has bug been > filed with Intel as issue 424719. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: help scheduling issues
Greetings all. I've taken a little time to glance over the open tasks which I reported but have not been assigned. My analysis of these issues is as follows: 336 (allow multiple config.h files in the same installation directory) Marked as critical for the 4.2.0 release, and not anywhere on our radar as far as I can tell. 361/362 ([Intel C++ 9.1.042] hangs compiling conditional initialization in template code (22.locale.money.put.cpp)) 361 is marked as Major, no Affects or Fix versions 362 is marked as Critical, fix 4.2.0. This pair of linked bugs affects a specific set compiler/platform combinations, and has been fixed by the compiler vendor in newer versions of the compiler. Given this, I think this pair should be reduced in priority and either rescheduled for 4.2.1 at the earliest, or closed. 261 (runall should parse tests and examples in the same manner) 366 (Add benchmarking framework) These are minor enhancements, without a specified Affects or Fix version. They probably can be left unscheduled, and I can't see a reason to assign either a release of anything earlier than 4.2.1. --Andrew Black
Re: Micro integration from trunk to branches/4.2.0
Looking at JIRA, it appears the files that will need to be branched for these changes are /incubator/stdcxx/trunk/GNUmakefile /incubator/stdcxx/trunk/etc/config/GNUmakefile.cfg /incubator/stdcxx/trunk/etc/config/makefile.rules /incubator/stdcxx/trunk/etc/config/sunpro.config In addition, we'll need to resolve a breakage that occurred as a result of the micro-integration. The following is a failure taken from nightly testing of the 4.2.0 branch (gcc 3.2.3 12S on redhat 3u8): > gcc -c -I$(TOPDIR)/include/ansi -pthread -I$(TOPDIR)/include > -I$(BUILDDIR)/include -pedantic -nostdinc++ -O2 -W -Wall -Wcast-qual > -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC > $(TOPDIR)/src/collate.cpp > In file included from $(TOPDIR)/src/collate.cpp:43: > $(TOPDIR)/include/limits:534: ` >_RWSTD_WCHAR_T_MIN' was not declared in this scope I should have run a basic sanity check run before checking in the integration, but I didn't. --Andrew Black Martin Sebor wrote: > Speaking of other changes that might need to be integrated > before we tag the branch, here are a couple more: > > https://issues.apache.org/jira/browse/STDCXX-479 > https://issues.apache.org/jira/browse/STDCXX-481 > > Martin > > Martin Sebor wrote: >> Andrew, we should be using the -rcN tag rather than the branch >> directly. The latest tag is 4.2.0-rc-2. Unless there are other >> changes that you need to integrate we should tag the 4.2.0 >> branch again and make a 4.2.0-rc-3. >> >> http://svn.apache.org/repos/asf/incubator/stdcxx/tags/4.2.0-rc-2/ >> >> Martin >> >> Andrew Black wrote: >>> Greetings all. >>> >>> A couple months ago, a 4.2.0 pre-release branch was created in >>> subversion. This branch allows for interested parties to preview the >>> upcoming release, with the understanding that the code isn't final. >>> >>> Within RogueWave, we recently stated using this branch as part of our >>> nightly testing process for the rest of our SourcePro family of >>> products. However, the 4.2.0 branch, at this time, contains a serious >>> bug in the code reported as >>> https://issues.apache.org/jira/browse/STDCXX-482 , and resolved in >>> http://svn.apache.org/viewvc?view=rev&rev=555106 . This bug leads to an >>> infinite loop while attempting to run the LIMITS.cpp config test. >>> >>> The nightly testing system for SourcePro is shared with STDCXX, and >>> hangs during the nightly testing process for SourcePro affect STDCXX by >>> preventing STDCXX builds from running. Therefore, unless any objections >>> are voiced, it is my intent to branch LIMITS.cpp from trunk to the 4.2.0 >>> branch in the next day or so. >>> >>> --Andrew Black >> >
[jira] Updated: (STDCXX-32) implement TR1 containers
[ https://issues.apache.org/jira/browse/STDCXX-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black updated STDCXX-32: --- Fix Version/s: 5.0 Affects Version/s: (was: 4.1.2) This task is a forward looking task for the next version of the C++ standard. As we are tentatively planning inclusion of most or all of the TR1 feature set in the 5.0 release, I am setting that release as a fix target. > implement TR1 containers > > > Key: STDCXX-32 > URL: https://issues.apache.org/jira/browse/STDCXX-32 > Project: C++ Standard Library > Issue Type: Sub-task > Components: TR1.6 - Containers > Environment: All >Reporter: Martin Sebor > Fix For: 5.0 > > > This is a placeholder task to implement the C++ Standard Library extensions > described in the Containers section of the Technical Report on C++ Library > Extensions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-33) implement TR1 regular expressions
[ https://issues.apache.org/jira/browse/STDCXX-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black updated STDCXX-33: --- Fix Version/s: 5.0 Affects Version/s: (was: 4.1.2) This task is a forward looking task for the next version of the C++ standard. As we are tentatively planning inclusion of most or all of the TR1 feature set in the 5.0 release, I am setting that release as a fix target. > implement TR1 regular expressions > - > > Key: STDCXX-33 > URL: https://issues.apache.org/jira/browse/STDCXX-33 > Project: C++ Standard Library > Issue Type: Sub-task > Components: TR1.7 - Regular Expressions > Environment: All >Reporter: Martin Sebor > Fix For: 5.0 > > > This is a placeholder task to implement the C++ Standard Library extensions > described in the Regular Expressions section of the Technical Report on C++ > Library Extensions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-31) implement TR1 numerical facilities
[ https://issues.apache.org/jira/browse/STDCXX-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black updated STDCXX-31: --- Fix Version/s: 5.0 Affects Version/s: (was: 4.1.2) This task is a forward looking task for the next version of the C++ standard. As we are tentatively planning inclusion of most or all of the TR1 feature set in the 5.0 release, I am setting that release as a fix target. > implement TR1 numerical facilities > -- > > Key: STDCXX-31 > URL: https://issues.apache.org/jira/browse/STDCXX-31 > Project: C++ Standard Library > Issue Type: Sub-task > Components: TR1.5 - Numerical Facilities > Environment: All >Reporter: Martin Sebor > Fix For: 5.0 > > > This is a placeholder task to implement the C++ Standard Library extensions > described in the Numerical Facilities section of the Technical Report on C++ > Library Extensions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-34) implement TR1 C compatibility features
[ https://issues.apache.org/jira/browse/STDCXX-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black updated STDCXX-34: --- Fix Version/s: 5.0 Affects Version/s: (was: 4.1.2) This task is a forward looking task for the next version of the C++ standard. As we are tentatively planning inclusion of most or all of the TR1 feature set in the 5.0 release, I am setting that release as a fix target. > implement TR1 C compatibility features > -- > > Key: STDCXX-34 > URL: https://issues.apache.org/jira/browse/STDCXX-34 > Project: C++ Standard Library > Issue Type: Sub-task > Components: TR1.8 - C Compatibility > Environment: All >Reporter: Martin Sebor > Fix For: 5.0 > > > This is a placeholder task to implement the C++ Standard Library extensions > described in the C Compatibility section of the Technical Report on C++ > Library Extensions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-30) implement TR1 metaprogramming facilities and type traits
[ https://issues.apache.org/jira/browse/STDCXX-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black updated STDCXX-30: --- Fix Version/s: 5.0 Affects Version/s: (was: 4.1.2) This task is a forward looking task for the next version of the C++ standard. As we are tentatively planning inclusion of most or all of the TR1 feature set in the 5.0 release, I am setting that release as a fix target. > implement TR1 metaprogramming facilities and type traits > > > Key: STDCXX-30 > URL: https://issues.apache.org/jira/browse/STDCXX-30 > Project: C++ Standard Library > Issue Type: Sub-task > Components: TR1.4 - Metaprogramming and Type Traits > Environment: All >Reporter: Martin Sebor > Fix For: 5.0 > > > This is a placeholder task to implement the C++ Standard Library extensions > described in the Metaprogramming and Type Traits section of the Technical > Report on C++ Library Extensions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-29) implement TR1 function objects
[ https://issues.apache.org/jira/browse/STDCXX-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black updated STDCXX-29: --- Fix Version/s: 5.0 Affects Version/s: (was: 4.1.2) This task is a forward looking task for the next version of the C++ standard. As we are tentatively planning inclusion of most or all of the TR1 feature set in the 5.0 release, I am setting that release as a fix target. > implement TR1 function objects > -- > > Key: STDCXX-29 > URL: https://issues.apache.org/jira/browse/STDCXX-29 > Project: C++ Standard Library > Issue Type: Sub-task > Components: TR1.3 - Function Objects > Environment: All >Reporter: Martin Sebor > Fix For: 5.0 > > > This is a placeholder task to implement the C++ Standard Library extensions > described in the Function Objects section of the Technical Report on C++ > Library Extensions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-28) implement TR1 general utilities
[ https://issues.apache.org/jira/browse/STDCXX-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black updated STDCXX-28: --- Fix Version/s: 5.0 Affects Version/s: (was: 4.1.2) This task is a forward looking task for the next version of the C++ standard. As we are tentatively planning inclusion of most or all of the TR1 feature set in the 5.0 release, I am setting that release as a fix target. > implement TR1 general utilities > --- > > Key: STDCXX-28 > URL: https://issues.apache.org/jira/browse/STDCXX-28 > Project: C++ Standard Library > Issue Type: Sub-task > Components: TR1.2 - General Utilities > Environment: All >Reporter: Martin Sebor > Fix For: 5.0 > > > This is a placeholder task to implement the C++ Standard Library extensions > described in the General Utilities section of the Technical Report on C++ > Library Extensions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-27) implement TR1 extensions
[ https://issues.apache.org/jira/browse/STDCXX-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black updated STDCXX-27: --- Fix Version/s: 5.0 Affects Version/s: (was: 4.1.2) This task is a forward looking task for the next version of the C++ standard. As we are tentatively planning inclusion of most or all of the TR1 feature set in the 5.0 release, I am setting that release as a fix target. > implement TR1 extensions > > > Key: STDCXX-27 > URL: https://issues.apache.org/jira/browse/STDCXX-27 > Project: C++ Standard Library > Issue Type: Task > Components: TR1 - Technical Report on C++ Library Extensions > Environment: All >Reporter: Martin Sebor > Fix For: 5.0 > > > This is a placeholder task to implement the facilities described in Technical > Report on C++ Library Extensions. > The latest draft of the document is here: > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1745.pdf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Exec utility test group reporting
Greetings all.
Attached is a patch that aims to add some logic to the exec utility to
report the type of executable being processed. Part of the purpose of
this change is to assist in making the result parsing more robust.
I am not particularly satisfied with this change for a couple reasons.
One is because the doxygen comments are getting out of date, and need to
be gone over. The second is the way data is passed from cmdopt.cpp to
display.cpp. The current method used is to overload the target_opts
struct to include the new parameter, but this feels like the wrong way
to do things. This method was chosen because the verbose flag is
currently included there, but the exec subsystem shouldn't care about
either of these things. (The verbose output mode also feels like it was
hacked on, but that's irrelevant to this topic.)
Does anyone have thoughts on this patch? I should note that some
changes to the windows infrastructure will be needed to keep the
behavior in sync with the unix infrastructure.
--Andrew Black
Index: etc/config/GNUmakefile.exm
===
--- etc/config/GNUmakefile.exm (revision 568748)
+++ etc/config/GNUmakefile.exm (working copy)
@@ -41,7 +41,7 @@
INCLUDES += -I$(EXMDIR)/include
-RUNFLAGS += -d $(EXMDIR) --ulimit=as:268435456
+RUNFLAGS += -d $(EXMDIR) --ulimit=as:268435456 --name=example
# No example should use more than 256MB of memory (Related to STDCXX-440).
# The magic number 268435456 is 256MB in bytes.
Index: etc/config/GNUmakefile.bin
===
--- etc/config/GNUmakefile.bin (revision 568748)
+++ etc/config/GNUmakefile.bin (working copy)
@@ -63,6 +63,8 @@
RUNTARGET := sanity_test.sh $(patsubst %,%.sh,$(LOCALES))
endif
+RUNFLAGS += --name=locale
+
ifneq ($(CXX_REPOSITORY),)
LDFLAGS += $(CPPFLAGS)
endif # ($(CXX_REPOSITORY),)
Index: etc/config/GNUmakefile.tst
===
--- etc/config/GNUmakefile.tst (revision 568748)
+++ etc/config/GNUmakefile.tst (working copy)
@@ -90,7 +90,7 @@
LDFLAGS += $(RPATH)$(LIBDIR):$(BUILDDIR)/rwtest
endif
-RUNFLAGS += --compat -x "--compat -O -" --ulimit=as:1073741824
+RUNFLAGS += --compat -x "--compat -O -" --ulimit=as:1073741824 --name=test
# No test should use more than 1 GB of memory (See STDCXX-440).
# The magic number 1073741824 is 1 GB in bytes.
Index: util/display.h
===
--- util/display.h (revision 568748)
+++ util/display.h (working copy)
@@ -57,7 +57,8 @@
/**
Prints the table preamble formatting, followed by the formatted header row.
*/
-extern void (*print_header) (const char* const argv[]);
+extern void (*print_header) (const char* const argv[],
+ const struct target_opts*);
/**
Prints the formatted header column for a target row.
@@ -89,7 +90,8 @@
/**
Prints the closing formatting for the table.
*/
-extern void (*print_footer) (int count, const struct target_status* status);
+extern void (*print_footer) (int count, const struct target_status* status,
+ const struct target_opts*);
#endif /* RW_DISPLAY_H */
Index: util/cmdopt.cpp
===
--- util/cmdopt.cpp (revision 568748)
+++ util/cmdopt.cpp (working copy)
@@ -108,6 +108,7 @@
"--ignore=sig Ignore the specified signal.\n"
"--ulimit=lim Set child process usage limits (see below).\n"
"--warn=alias Set compiler log warning pattern (see below).\n"
+"--name=val Set executable group tag to val (used in output).\n"
"\n"
" All short (single dash) options must be specified seperately.\n"
" If a short option takes a value, it may either be provided like\n"
@@ -505,6 +506,7 @@
const char opt_ulimit[] = "--ulimit";
const char opt_verbose[] = "--verbose";
const char opt_warn[] = "--warn";
+const char opt_name[] = "--name";
int i;
@@ -711,6 +713,16 @@
}
}
}
+else if ( sizeof opt_name - 1 <= arglen
+ && !memcmp (opt_name, argv [i], sizeof opt_name - 1)) {
+/* set executable group name */
+optname = opt_name;
+optarg = get_long_val (argv, &i, sizeof opt_name - 1);
+if (optarg && *optarg) {
+defaults->group = optarg;
+ break;
+}
+}
/* fall through */
}
default:
Index: util/display.cpp
===
--- util/display.cpp (revision 568748)
+++ util/display.cpp (working copy)
@@ -26,15 +26,16 @@
Micro integration from trunk to branches/4.2.0
Greetings all. A couple months ago, a 4.2.0 pre-release branch was created in subversion. This branch allows for interested parties to preview the upcoming release, with the understanding that the code isn't final. Within RogueWave, we recently stated using this branch as part of our nightly testing process for the rest of our SourcePro family of products. However, the 4.2.0 branch, at this time, contains a serious bug in the code reported as https://issues.apache.org/jira/browse/STDCXX-482 , and resolved in http://svn.apache.org/viewvc?view=rev&rev=555106 . This bug leads to an infinite loop while attempting to run the LIMITS.cpp config test. The nightly testing system for SourcePro is shared with STDCXX, and hangs during the nightly testing process for SourcePro affect STDCXX by preventing STDCXX builds from running. Therefore, unless any objections are voiced, it is my intent to branch LIMITS.cpp from trunk to the 4.2.0 branch in the next day or so. --Andrew Black
Re: STDCXX-522 - v2
Greetings Everton.
Your assistance is appreciated, but it is difficult to use (or
understand) your proposed changes without a context for the changes.
One piece of context we need to know is what sources you are making your
changes against - are you using the 4.1.3 release code, the 4.2.0
pre-release subversion branch, or subversion trunk? While it is
possible to work with changes against all of the listed sources, changes
against subversion trunk are the most usable, as they are the simplest
to commit.
If you wish to propose a change, the most usable format to share the
proposed change is in the form of a diff which is usable by the patch
utility. I, and a number of the other developers, have HTML rendering
turned off by default in our mail clients, so HTML formatted changes,
such as the one you provided, are very difficult to use.
One of the reasons changes against subversion trunk are preferred is
because the subversion client is able to produce the diff files which
the patch utility can use. If you use the subversion command line
client, you can run the 'svn diff' command in the root directory of your
subversion checkout and redirecting the output to a file. If you use
the TortoiseSVN client, one of the menu options in the explorer
integration is 'Create patch...'. If this command is run against the
root directory of you subversion checkout, it will also produce a usable
patch in a file. In either case, the generated file can be embedded in
or attached to an email. If you use outlook, use a '.txt' suffix for
the patch so the mailing list doesn't strip it.
Hopefully this information will make it easier to participate.
--Andrew Black
Everton Araujo wrote:
> Hi,
>
> Sorry, I was wrong about the fix of issue STDCXX-522 because it worked for
> issue test code, but I've forgot to run test 27 and we I ran that ...
> ps! 75% assertations :-(
> I went get more coffee and restart debugging, and with the following changes
> in fstream, test on both codes (issue and 27) was successfully.
>
> Following is the overflow code changed (diffs are bold):
>
> template
> _TYPENAME basic_filebuf<_CharT, _Traits>::int_type
> basic_filebuf<_CharT, _Traits>::
> overflow (int_type __c /* = eof () */)
> {
> _RWSTD_ASSERT (this->_C_is_valid ());
>
> if (!this->_C_is_out () || !is_open ())
> return traits_type::eof ();
>
> this->setg (0, 0, 0);// invalidate the get area
>
> const bool __unbuf = this->_C_is_unbuffered ();
>
> const char_type __c_to_char = traits_type::to_char_type (__c);
>
> if (this->pptr () == 0 && !__unbuf) {
> // put area not valid yet - just need to initialize it
> this->setp (this->_C_buffer, this->_C_buf_end ());
> }
> else if ( this->pptr () == this->epptr ()
> || this->_C_is_eof (__c)
> || __unbuf) {
>
> const char_type* __buf;
> _RWSTD_STREAMSIZE __nchars;
>
> if (__unbuf) {
> if(this->_C_is_eof(__c)){
> _C_cur_pos.state (0);
> __buf = 0;
> __nchars = 0;
> }
> else{
> __buf= &__c_to_char;
> __nchars = 1;
> }
> }
> else {
> // call xsputn() with a special value to have it flush
> // the controlled sequence to the file
> __buf= _RWSTD_REINTERPRET_CAST (char_type*, this);
> __nchars = this->pptr () - this->pbase ();
> }
>
> // typedef helps HP aCC 3.27
> typedef basic_filebuf _FileBuf;
>
> if (__nchars && __nchars != _FileBuf::xsputn (__buf, __nchars))
> return traits_type::eof (); // error while writing
> }
>
> // now that there's room in the buffer, call sputc() recursively
> // to actually place the character in the buffer (unless we're
> // in unbuffered mode because we just wrote it out)
> if (!this->_C_is_eof (__c) && !__unbuf)
> this->sputc (__c_to_char);
>
> this->_C_out_last (true); // needed by close ()
>
> return traits_type::not_eof (__c);
> }
>
> Hope it helps.
>
> Everton.
>
Re: Windows build results in the pink
Greetings Martin, all. After arguing with the nightly testing system to get it to keep usable post-build archives around, I finally managed to track down the cause of the failure on Solaris AMD64. The problem, perhaps not surprisingly, is the awk implementation used. (See http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200707.mbox/[EMAIL PROTECTED] , which is continued as http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200708.mbox/[EMAIL PROTECTED] for reference) > [EMAIL PROTECTED] source-buildspace]$ awk -f parse_runlog.awk runall.log | > tail -7 > warnings=0 > tests.run=0 > tests.good=0 > examples.run=0 > examples.good=0 > locales.run=0 > locales.good=0 > [EMAIL PROTECTED] source-buildspace]$ /usr/xpg4/bin/awk -f parse_runlog.awk > runall.log | tail -7 > warnings=0 > tests.run=0 > tests.good=0 > examples.run=135 > examples.good=129 > locales.run=166 > locales.good=162 > [EMAIL PROTECTED] source-buildspace]$ nawk -f parse_runlog.awk runall.log | > tail -7 > warnings=75 > tests.run=341 > tests.good=275 > examples.run=135 > examples.good=129 > locales.run=166 > locales.good=162 At this time we are using /usr/xpg4/bin/awk on both sparc and AMD64. Any thoughts? --Andrew Black Andrew Black wrote: > Greetings Martin, all. > > I had time on Friday to investigate the problem with the windows parser > script, and checked in a change which resolved the issue. I have not > looked into the issue with result parsing on solaris 10 for AMD64. > > --Andrew Black > > Andrew Black wrote: >> Greetings Martin >> >> I am currently occupied with another high-priority project, and hope to >> finish it in the next couple days. I'll look into these problems once >> the other project has been dealt with. >> >> --Andrew Black >> >> Martin Sebor wrote: >>> A similar problem exists in Solaris 10/AMD64 build results. There, >>> examples and locales look like they are being reported correctly >>> but tests are not. >>> >>> Martim >>> >>> Martin Sebor wrote: >>>> Our latest Windows results are still having problems. I suspect it's >>>> the fallout of the exec changes last week and the parsing script not >>>> having been (fully) updated to adjust. Andrew, this is rather urgent >>>> for us. Can you please look into it and let us know when we can >>>> expect a fix? >>>> >>>> Thanks >>>> Martin >>>>
Re: Windows build results in the pink
Greetings Martin, all. I had time on Friday to investigate the problem with the windows parser script, and checked in a change which resolved the issue. I have not looked into the issue with result parsing on solaris 10 for AMD64. --Andrew Black Andrew Black wrote: > Greetings Martin > > I am currently occupied with another high-priority project, and hope to > finish it in the next couple days. I'll look into these problems once > the other project has been dealt with. > > --Andrew Black > > Martin Sebor wrote: >> A similar problem exists in Solaris 10/AMD64 build results. There, >> examples and locales look like they are being reported correctly >> but tests are not. >> >> Martim >> >> Martin Sebor wrote: >>> Our latest Windows results are still having problems. I suspect it's >>> the fallout of the exec changes last week and the parsing script not >>> having been (fully) updated to adjust. Andrew, this is rather urgent >>> for us. Can you please look into it and let us know when we can >>> expect a fix? >>> >>> Thanks >>> Martin >>>
Re: Jira issues against trunk
The only benefit I can see in using -dev over trunk, is it would provide a view into what release the bug was discovered (and fixed) in. This assistance may be offset by the extra maintenance hassle of creating the new name every release, and having to deal with people inadvertently reporting bugs as being part of a previous trunk version. My tendency is to cast a vote for using 'trunk'. --Andrew Black Martin Sebor wrote: > It occurs to me that our current process of assigning bugs > to a yet unreleased branch (e.g., 4.2) might lead to the > misleading impression after the branch is released that it > was/is full of bugs even though all the bugs may have been > resolved before the release went out the door. I think we > need a separate version entry in Jira for regressions > introduced during development. Any suggestions for what > this entry ought to be? Would labeling them simply "trunk" > work or is there any benefit in being more specific (e.g., > -dev)? > > Martin
Re: svn commit: r564059 - in /incubator/stdcxx/trunk: include/limits src/limits_bits.cpp
Greetings Martin
I'm not completely certain, but I believe this change is leading to
failures on most or all operating systems. In particular, linker
warnings of
> ld: (Warning) Unsatisfied symbol "__rw::__rw_flt_infinity" in file
> $(BUILDDIR)/lib/libstd.sl
> ld: (Warning) Unsatisfied symbol "__rw::__rw_dbl_infinity" in file
> $(BUILDDIR)/lib/libstd.sl
> ld: (Warning) Unsatisfied symbol "__rw::__rw_ldbl_infinity" in file
> $(BUILDDIR)/lib/libstd.sl
are observed in static builds (on HPUX), and the same message is
observed when running the exec utility in dynamic builds.
--Andrew Black
[EMAIL PROTECTED] wrote:
> Author: sebor
> Date: Wed Aug 8 17:47:54 2007
> New Revision: 564059
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=564059
> Log:
> 2007-08-09 Martin Sebor <[EMAIL PROTECTED]>
>
> STDCXX-509
> * limits (__rw_flt_denorm_min, __rw_flt_infinity, __rw_flt_qNaN,
> __rw_flt_sNaN, __rw_dbl_denorm_min, __rw_dbl_infinity, __rw_dbl_qNaN,
> __rw_dbl_sNaN, __rw_ldbl_denorm_min, __rw_ldbl_infinity, __rw_ldbl_qNaN,
> __rw_ldbl_sNaN): Declared floating point constants with "C" language
> linkage to prevent "clever" compilers such as MSVC from mangling their
> type into their names and to permit them to be defined with different
> types.
> * limits_bits.cpp (__rw_flt_denorm_min, __rw_flt_infinity,
> __rw_flt_qNaN, __rw_flt_sNaN, __rw_dbl_denorm_min, __rw_dbl_infinity,
> __rw_dbl_qNaN, __rw_dbl_sNaN, __rw_ldbl_denorm_min, __rw_ldbl_infinity,
> __rw_ldbl_qNaN, __rw_ldbl_sNaN): Defined as statically (i.e., at load
> time as opposed to dynamically, at runtime) initialized unions, backed
> by the appropriate byte patterns, with "C" language linkage to permit
> the defintions to have a different type than the declarations.
> (__rw_flt_denorm_min_bits, __rw_flt_infinity_bits, __rw_flt_qNaN_bits,
> __rw_flt_sNaN_bits, __rw_dbl_denorm_min_bits, __rw_dbl_infinity_bits,
> __rw_dbl_qNaN_bits, __rw_dbl_sNaN_bits, __rw_ldbl_denorm_min_bits,
> __rw_ldbl_infinity_bits, __rw_ldbl_qNaN_bits, __rw_ldbl_sNaN_bits):
> Removed.
>
> Modified:
> incubator/stdcxx/trunk/include/limits
> incubator/stdcxx/trunk/src/limits_bits.cpp
>
> Modified: incubator/stdcxx/trunk/include/limits
> URL:
> http://svn.apache.org/viewvc/incubator/stdcxx/trunk/include/limits?view=diff&rev=564059&r1=564058&r2=564059
> ==
> --- incubator/stdcxx/trunk/include/limits (original)
> +++ incubator/stdcxx/trunk/include/limits Wed Aug 8 17:47:54 2007
> @@ -23,7 +23,7 @@
> * implied. See the License for the specific language governing
> * permissions and limitations under the License.
> *
> - * Copyright 1994-2006 Rogue Wave Software.
> + * Copyright 1994-2007 Rogue Wave Software, Inc.
> *
> **/
>
> @@ -86,7 +86,9 @@
> #endif // _RWSTD_IS_IEC559
>
>
> -_RWSTD_NAMESPACE (__rw) {
> +_RWSTD_NAMESPACE (__rw) {
> +
> +extern "C" {
>
> _RWSTD_EXPORT extern const float __rw_flt_infinity;
> _RWSTD_EXPORT extern const double __rw_dbl_infinity;
> @@ -108,6 +110,8 @@
> _RWSTD_EXPORT extern const long double __rw_ldbl_denorm_min;
>
> #endif // _RWSTD_NO_LONG_DOUBLE
> +
> +} // extern "C"
>
> } // namespace __rw
>
>
> Modified: incubator/stdcxx/trunk/src/limits_bits.cpp
> URL:
> http://svn.apache.org/viewvc/incubator/stdcxx/trunk/src/limits_bits.cpp?view=diff&rev=564059&r1=564058&r2=564059
> ==
> --- incubator/stdcxx/trunk/src/limits_bits.cpp (original)
> +++ incubator/stdcxx/trunk/src/limits_bits.cpp Wed Aug 8 17:47:54 2007
> @@ -22,7 +22,7 @@
> * implied. See the License for the specific language governing
> * permissions and limitations under the License.
> *
> - * Copyright 1994-2006 Rogue Wave Software.
> + * Copyright 1994-2007 Rogue Wave Software, Inc.
> *
> **/
>
> @@ -30,6 +30,11 @@
>
> #include // for INFINITY, NAN
> #include// for atof()
> +
> +// must not #include to avoid colliding with symbols
> +// declared there with a different type than what they are
> +// defined with here
> +// #include
>
> #include
>
> @@ -42,126 +47,106 @@
> #error one of _RWSTD
Re: duplicate rows on results page
Greetings Martin I haven't had time to investigate this issue, but I suspect it may be fallout from the changes that were made to separate the processing logic within the static_export.pl script. The reordered logic takes longer to retrieve the index data from the database, and it's possible that the index data is updated during the retrieval process, resulting in the observed misbehavior. Table locking probably isn't option, as it likely would result in a stall for the rest of the automated test system. --Andrew Black Martin Sebor wrote: > Andrew, I suspect recent changes to the static_export.pl script > are causing duplicate rows for some builds. For example, we have > two rows for a 15S build with VisualAge C++ 6.0 on AIX 5.2. There > are a number of other duplicates as well, including a few results > for Intel C++ 9.1 that appear in triplicate, and one for EDG eccp > is there four times. > > Thanks > Martin
Re: Windows build results in the pink
Greetings Martin I am currently occupied with another high-priority project, and hope to finish it in the next couple days. I'll look into these problems once the other project has been dealt with. --Andrew Black Martin Sebor wrote: > A similar problem exists in Solaris 10/AMD64 build results. There, > examples and locales look like they are being reported correctly > but tests are not. > > Martim > > Martin Sebor wrote: >> Our latest Windows results are still having problems. I suspect it's >> the fallout of the exec changes last week and the parsing script not >> having been (fully) updated to adjust. Andrew, this is rather urgent >> for us. Can you please look into it and let us know when we can >> expect a fix? >> >> Thanks >> Martin >> >
Re: what's up with Windows builds?
Sources reloaded. I would have gotten to it a tad sooner if I weren't distracted with another project. --Andrew Black Martin Sebor wrote: > Andrew, now that the problem is fixed can you please re-submit > the latest sources for testing? > > Thanks > Martin > > Farid Zaripov wrote: >>> -Original Message- >>> From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Monday, August >>> 06, 2007 5:51 PM >>> To: stdcxx-dev@incubator.apache.org >>> Subject: what's up with Windows builds? >>> >>> ...they're all in DATA status and the logs are missing tables for >>> examples and tests (locales are there). The only clue I see is the >>> error below. Farid, any idea what's going on? >>> >>> Martin >>> >>> Performing Pre-Build Event... >>> Performing Custom Build Step >>> 'exec.exe" --compat -x "--compat' is not recognized as an internal or >>> external command, operable program or batch file. >>> Total run 338; 338 succeeded, 0 failed, 0 failed because of timeout, >>> 0 exited with non-zero code, 0 has not compiled >> >> Fixed: http://svn.apache.org/viewvc?view=rev&rev=563513 >> >> Farid. >
Re: [PING] Re: dead links on result page
Greetings Martin
The messages in the log indicate that the attachments in question didn't
exist in the nightly testing database when the page was generated on
Sat. A cause for this condition would be if the build was still in
progress (state W/'WAIT') when the export was performed. This should be
a fairly simple matter to resolve.
--Andrew Black
Martin Sebor wrote:
> Hi Andrew,
>
> There still are dead links. For example, the Intel C++ 9.1 build
> below (the only one of its kind in DATA status):
>
> http://people.apache.org/~sebor/stdcxx/results/linux_redhat_el-4.4-em64t-icc-64b-9.1-15S-562601-log.gz.txt
>
>
> Here's what's in the log files between Sat and this morning:
>
> $ (cd ~/.stdcxx-cache/ && grep
> "linux_redhat_el-4.4-em64t-icc-64b-9.1-15S" export-{Sat,Sun,Mon}.log)
> export-Sat.log:Updating linux_redhat_el-4.4-em64t-icc-64b-9.1-15S from
> 33899015 to 33900097
> export-Sat.log:No attachment for
> linux_redhat_el-4.4-em64t-icc-64b-9.1-15S-562601-log.gz.txt
> export-Sat.log:No attachment for
> linux_redhat_el-4.4-em64t-icc-64b-9.1-15S-562601-cfg-h.gz.txt
> export-Sat.log:No attachment for
> linux_redhat_el-4.4-em64t-icc-64b-9.1-15S-562601-cfg-l.gz.txt
>
> Does that mean anything to you?
>
> Martin
>
> Andrew Black wrote:
>> Greetings Martin.
>>
>> I've been adding debugging output to the script to help diagnose the
>> issue, but I'm not much closer to determining the cause. I'll be adding
>> a little more for tomorrow's run. Is the error output from the export
>> script being directed into the log file? I am assuming it is, but I
>> find myself wondering if it might not be.
>>
>> --Andrew Black
>>
>> Martin Sebor wrote:
>>> Andrew, any progress on identifying the problem?
>>>
>>> Here's a small sampling of dead links on today's page:
>>> http://people.apache.org/~sebor/stdcxx/results/aix-5.2-ppc-visualage-32b-6.0.0-11d-560283-log.gz.txt
>>>
>>>
>>> http://people.apache.org/~sebor/stdcxx/results/aix-5.3-ppc-vacpp-32b-7.0.0.0-15a-560283-log.gz.txt
>>>
>>>
>>> http://people.apache.org/~sebor/stdcxx/results/aix-5.3-ppc-vacpp-32b-8.0-8a-560283-log.gz.txt
>>>
>>>
>>> http://people.apache.org/~sebor/stdcxx/results/aix-5.3-ppc-vacpp-32b-9.0-11s-560283-log.gz.txt
>>>
>>>
>>> http://people.apache.org/~sebor/stdcxx/results/aix-5.3-ppc-vacpp-32b-9.0-15s-560283-log.gz.txt
>>>
>>>
>>>
>>> Martin
>>>
>>> Martin Sebor wrote:
>>>> The problem with the dead links on the results page seems to be back,
>>>> at least for some builds:
>>>>
>>>> http://people.apache.org/~sebor/stdcxx/results/solaris-10-sparc-sunpro-32b-5.9-8d-559650-log.gz.txt
>>>>
>>>>
>>>> http://people.apache.org/~sebor/stdcxx/results/solaris-10-sparc-sunpro-32b-5.9-8s-559650-log.gz.txt
>>>>
>>>>
>>>>
>>>> Andrew, can you please look into it at your earliest convenience?
>>>>
>>>> Thanks
>>>> Martin
>
Re: svn commit: r562224 - in /incubator/stdcxx/trunk/util: display.cpp display.h exec.cpp runall.cpp target.h util.cpp util.h
Greetings Martin. Something in this patch appears to cause the exec utility to hang on Windows. I haven't had much time to dig into the cause, but I thought I'd give everyone a heads up. Farid, if you have a chance, could you look into this? --Andrew Black [EMAIL PROTECTED] wrote: > Author: sebor > Date: Thu Aug 2 12:04:26 2007 > New Revision: 562224 > > URL: http://svn.apache.org/viewvc?view=rev&rev=562224 > Log: > 2007-07-26 Martin Sebor <[EMAIL PROTECTED]> > > * display.h (print_footer): Added an argument for the total number > of programs processed by the utility. > * display.cpp (print_target_verbose): Print stdin, stdout, and stderr > redirectiopn. > (print_status_verbose): Justified output. > (print_footer_plain): Printed the total number of programs processed > by the utility and avoided printing assertion totals unless they're > valid. > (print_footer_verbose): Added an argument. > * target.h (target_opts): Added infname and outfname members. > * util.h (input_name): Declared. > * util.cpp (input_name): Defined to parallel output_name(). > * exec.cpp (open_input): Removed. > (exec_file): Used target_opts::infname and target_opts::outfname. > * runall.cpp (run_target): Called input_name() and output_name() > to set the names of files to redirect input and output from and > to, respectively. > Avoided printing out assertion totals when they're not valid. > > Modified: > incubator/stdcxx/trunk/util/display.cpp > incubator/stdcxx/trunk/util/display.h > incubator/stdcxx/trunk/util/exec.cpp > incubator/stdcxx/trunk/util/runall.cpp > incubator/stdcxx/trunk/util/target.h > incubator/stdcxx/trunk/util/util.cpp > incubator/stdcxx/trunk/util/util.h > [Change snipped]
Re: bulletproofing exec output
Greetings Martin I suppose I should elaborate on the third option I put forward, in a more general manner. One of the long-term plans for the exec utility, as I understand it, was to allow for alternate output modes, such as an 'interactive' mode, which would include such sugar as colored output and run timeout countdown and the verbose output mode. What I picture is a structure where an arbitrary set of output mode files can be dropped into the bin directory and compiled into the exec utility. It ideally would be possible for the makefiles to automatically determine which files are output mode files, and each output mode module would add itself to an internal list of mode modules as part of the runtime initialization. A certain number of modules would ship with stdcxx (including the default and verbose modes, along with the 'interactive' mode after it's written), and end users would be able to write other modules of their own devising, if they wished. With this structure, we would be able to write a module of our own, designed for the nightly testing infrastructure, add it to the testing source tree overlay, and specify that the exec utility should use the new module, rather than the default output. --Andrew Black Martin Sebor wrote: > Andrew Black wrote: > [snipped descriptive summary] > ... >> Looking at the output (as it stands now), I believe the parsers could be >> more robust if they ignored all lines that started with whitespace or >> where the first word was in all caps. Alternately, they could start >> processing after the first line in all caps, and stop processing before >> the second line in all caps. I suppose a third option would be to alter >> the exec utility so it could produce the output desired, rather than >> doing a post-processing step. Thoughts? > > IMO, since exec already has all the data the post-processing stage > works so hard to compute it might as well write it out in a format > that's easy to parse by the script you're talking about. I.e., the > summary would be it. The other script that I was referring to is > the cross build view generation script that actually needs the > individual examples, locales, and tests, and doesn't care (yet) > about the summary. > > So if take this approach we need to "standardize" both the output > format for the individual programs as well as the summary. The > summary format currently looks like this: > [snipped sample output and initial problem]
Re: many builds in DATA status
Greetings Martin I observed the Windows issues earlier today when I glanced at the results, but I didn't spot the Solaris failures when I was making that pass. The reason for the GCC builds on windows are processed correctly is because they use the UNIX infrastructure, rather than the Windows infrastructure. The cause of the failure on Solaris appears to be a lack of functionality in the /usr/bin/awk, specifically the lack of a toupper() builtin. Our options on this platform appear to be a choice between using /usr/bin/nawk (aka /usr/xpg4/bin/awk), and rewriting the parser to avoid the use of the toupper() (and tolower()) builtins. A third option I see (altering the exec utility) I'll go into more detail elsewhere (specifically in the bulletproofing thread). I'm less certain about the cause of the failure on windows, but I suspect it to be basically the same as the cause of failure on Solaris - that of the start/stop parsing tags not being picked up. --Andrew Black Martin Sebor wrote: > There are large number of builds in DATA status in recent build > results: essentially, all Solaris and Windows builds (with gcc > on Windows being the notable exception). I suspect they might > have been caused by our recent changes to the run/publish script. > > Andrew, can you please confirm and if so look into it ASAP? > > Thanks > Martin
Re: [PING] Re: dead links on result page
Greetings Martin. I've been adding debugging output to the script to help diagnose the issue, but I'm not much closer to determining the cause. I'll be adding a little more for tomorrow's run. Is the error output from the export script being directed into the log file? I am assuming it is, but I find myself wondering if it might not be. --Andrew Black Martin Sebor wrote: > Andrew, any progress on identifying the problem? > > Here's a small sampling of dead links on today's page: > http://people.apache.org/~sebor/stdcxx/results/aix-5.2-ppc-visualage-32b-6.0.0-11d-560283-log.gz.txt > > http://people.apache.org/~sebor/stdcxx/results/aix-5.3-ppc-vacpp-32b-7.0.0.0-15a-560283-log.gz.txt > > http://people.apache.org/~sebor/stdcxx/results/aix-5.3-ppc-vacpp-32b-8.0-8a-560283-log.gz.txt > > http://people.apache.org/~sebor/stdcxx/results/aix-5.3-ppc-vacpp-32b-9.0-11s-560283-log.gz.txt > > http://people.apache.org/~sebor/stdcxx/results/aix-5.3-ppc-vacpp-32b-9.0-15s-560283-log.gz.txt > > > Martin > > Martin Sebor wrote: >> The problem with the dead links on the results page seems to be back, >> at least for some builds: >> >> http://people.apache.org/~sebor/stdcxx/results/solaris-10-sparc-sunpro-32b-5.9-8d-559650-log.gz.txt >> >> http://people.apache.org/~sebor/stdcxx/results/solaris-10-sparc-sunpro-32b-5.9-8s-559650-log.gz.txt >> >> >> Andrew, can you please look into it at your earliest convenience? >> >> Thanks >> Martin >
Re: bulletproofing exec output
Greetings Martin It might be of use to note how the existing parsers currently work when considering how the output could be improved for the purposes of parsing. On the windows side, the output from running of each family of executables (locales, tests, examples) is routed into it's own file. We then read the file line by line, looking for the starting row header and the (old) footer to determine when to start and stop reading. On the unix side, the output from making the 'runall' target is teed into a file, which is then post-processed. During that processing, the file is read line by line, with the section controlled by the make enter marker, the processing start controlled by the starting row header, and the processing stop controlled by the make leave marker. Looking at the output (as it stands now), I believe the parsers could be more robust if they ignored all lines that started with whitespace or where the first word was in all caps. Alternately, they could start processing after the first line in all caps, and stop processing before the second line in all caps. I suppose a third option would be to alter the exec utility so it could produce the output desired, rather than doing a post-processing step. Thoughts? --Andrew Black Martin Sebor wrote: > I did some work on the exec utility recently. One of the enhancements > I added was a summary section at the end of the output. It seems that > this had the unexpected consequence to the scripts that interpret the > output of the utility, namely that the new summary is taken as > additional tests, examples, or locales and included in the generated > reports. > > It's clear that the scripts aren't robust enough to deal with these > types of changes. I'd like to find a way to make them more robust so > that we can safely enhance the exec utility's output in the future > without causing this sort of adverse fallout. To make this possible > I think we need to enhance the output of exec to help the scripts > disambiguate ordinary output (such as the "PROGRAM SUMMARY" label > I added) from the output relevant to the scripts (i.e., the examples, > tests, and locales). > > What should this output format look like? Would adding the number > of each program in front its name be sufficient? I.e., replacing > > NAME STATUS WARN ASSERTS FAILED PERCNT ... > sanity_test.sh 00 46 0 100% > af_ZA.ISO-8859-1.sh00 16 0 100% > ar_AE.ISO-8859-6.sh00 16 0 100% > ar_BH.ISO-8859-6.sh00 16 0 100% > > with > > ## NAME STATUS WARN ASSERTS FAILED PERCNT ... >1. sanity_test.sh 00 46 0 100% >2. af_ZA.ISO-8859-1.sh00 16 0 100% >3. ar_AE.ISO-8859-6.sh00 16 0 100% >4. ar_BH.ISO-8859-6.sh00 16 0 100% > > That way scripts written to process this type of output would look > for lines matching the RE pattern "^ *[1-9][0-9]*\. [^ ][^ ]* *" > to reliably distinguish find programs (examples, locales, tests) > in the log files from other kinds of output. The big assumption > here is that there would be no other lines matching that RE in > the logs, or at least not in the immediate vicinity of the output > from exec. > > I would also like to make an additional enhancement to help scripts > to extract the relevant exec output from the rest of the contents > of the log and differentiate between examples, locales, and tests. > I'm thinking replacing the label "NAME" with "EXAMPLE NAME", "LOCALE > NAME", and "TEST NAME" and ending the output with something like > "END EXAMPLES" etc. should do it. > > Any other/better ideas? > > Martin
Re: invalid BUILDMODE in cygwin 15s build
Greetings Farid. The cause is (mostly) a scheduling issue. In particular, the request specifies the use of windows threads, but the glue scripts used for unix builds don't know about windows threads. I'll resolve this problem today, as it's fairly simple to fix. --Andrew Black Farid Zaripov wrote: > I see in > http://people.apache.org/~sebor/stdcxx/results/win_xp-2-x86-gcc-32b-3.4. > 4-15s-win32-559300-log.gz.txt > that build was started with BUILDMODE=,archive,debug,narrow but should > started with > BUILDMODE=pthreads,archive,debug,narrow > > Farid.
Re: Intel C++ errors on Windows
Greetings Martin I believe the failures are environment caused. For the Intel 10 builds on Windows 2003 AMD64, the Intel 10 compiler isn't installed (Though the 9.1 compiler appears to be). For the Intel 9 builds on Windows 2000 and Windows 2003, the cause is the use of an incorrect setenv. --Andrew Black Martin Sebor wrote: > Andrew, Farid, > > Our Intel C++ builds (both 9.1 and 10) on Windows are failing with > various configuration errors. Have you guys seen them yet and if so, > do you have any comments on what's going on? > > Here's one from this build: > http://people.apache.org/~sebor/stdcxx/results/win_2000-4-x86-icl-32b-9.1-11s-558871-log.gz.txt > > > Performing Custom Build Step > The system cannot find the path specified. > Configuring for icc-9.1 - 11s Debug Static > checking if compiler is sane... Configure: Fatal error: Compiler failed > sanity check > You may see log here: > file://D:/bman5/builds/33883718/source-buildspace/build/icc-9.1/11s/include/config.log > > Project : error PRJ0019: A tool returned an error code from "Performing > Custom Build Step" > > The config.log message indicates the compiler driver isn't installed: > Compiling with command "icl /c /EHsc /GS /D_CRT_SECURE_NO_DEPRECATE /GR > /MTd /Zi /Gm > /I"D:\bman5\builds\33883718\source-buildspace\build\icc-9.1\11s\include\tests" > /I"D:\bman5\builds\33883718\source-buildspace\include" > /Fo"D:\bman5\builds\33883718\source-buildspace\build\icc-9.1\11s\include\tests\\" > /Fd"D:\bman5\builds\33883718\source-buildspace\build\icc-9.1\11s\include\tests\sanity.pdb" > "D:\bman5\builds\33883718\source-buildspace\build\icc-9.1\11s\include\tests\sanity.cpp"" > > 'icl' is not recognized as an internal or external command, > operable program or batch file. > > > Another but different one here: > http://people.apache.org/~sebor/stdcxx/results/win_2003-1-amd64-icl-32b-10.0-12d-win32-558871-log.gz.txt > > ### Creating solution > Solution generation script > Checking arguments... > Building directory tree created > Checking consistence... > conversion utility not found > ### Building solution / Creating HTML log > 'build\build_icc-10.0.bat' is not recognized as an internal or external > command, > > Thanks > Martin
[jira] Created: (STDCXX-501) [aCC 3/HPUX/PARISC] Compile using -AA rather than -Aa
[aCC 3/HPUX/PARISC] Compile using -AA rather than -Aa - Key: STDCXX-501 URL: https://issues.apache.org/jira/browse/STDCXX-501 Project: C++ Standard Library Issue Type: Bug Components: Build Environment: aCC 3/HPUX/PARISC Reporter: Andrew Black (See http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200707.mbox/[EMAIL PROTECTED] for background) At this time, stdcxx is compiled using the -Aa switch for aCC 3. Most 3rd-party libraries, such as those provided by database vendors, are built using the binary incompatible -AA switch. To make stdcxx more usable with other libraries, the infrastructure should be altered to build with -AA for this compiler family. This issue doesn't affect aCC 5 and 6, as builds with those versions of the compiler already use -AA. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (STDCXX-489) [Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect
Greetings Martin I don't think the infrastructure is set up to fail anywhere if the desired word width can't be built. I don't recall seeing any sort of record in the makefile.in to indicate whether the build is narrow or wide, any checks in the configuration tests to see if the build type is that desired, or any logic in the compiler config files to test the invoke before generating the build directory. --Andrew Black Martin Sebor wrote: > Andrew Black (JIRA) wrote: >> [ >> https://issues.apache.org/jira/browse/STDCXX-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> ] >> >> Andrew Black resolved STDCXX-489. >> - >> >> Resolution: Invalid >> >> Greetings Mark. >> >> I'm closing this issue as 'Invalid', as the cause of the problem is >> your environment. >> >> Unlike most other compilers, the Intel compiler doesn't have a command >> line switch to control whether the generated executables are 32 or 64 >> bit. Rather, there are two separate executables, one 32 bit, and one >> 64 bit. (The only other compilers I can think of with this behavior >> are Visual Studio and the Intel Compiler for Windows.) >> >> To produce a 32 bit executable with the Intel compiler, you will need >> to use the correct iccvars.sh to set up your environment. > > Hmm. The manual mentions the -m32 and -m64 options but they're only > supported on Mac OS and not on Linux or Windows. Weird. But if the > compiler really doesn't provide any options to control the word > width on Linux we shouldn't just silently ignore a request to > generate code that we can't generate with the compiler. We should > fail with an error. I thought we did that for other compilers but > I could be wrong (clearly we don't with Intel C++). > > Martin > >> >> This quirk of the Intel compiler has caused problems for me also. If >> you have an Intel Premier account, >> https://premier.intel.com/premier/IssueDetail.aspx?IssueID=420157 was >> a support request I filed asking for assistance on this subject. >> >> --Andrew Black >> >>> [Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect >>> - >>> >>> Key: STDCXX-489 >>> URL: https://issues.apache.org/jira/browse/STDCXX-489 >>> Project: C++ Standard Library >>> Issue Type: Bug >>> Components: Configuration >>>Affects Versions: 4.2 >>> Environment: Intel C++ 10 on Linux >>>Reporter: Mark Brown >>> >>> Configuring stdcxx for 32-bits using >>> BUILDMODE=pthreads,archive,optimized,narrow on x86_64 I see the >>> system architecture is "LP64 little endian" instead of "ILP32 little >>> endian." It looks like the "narrow" in BUILDMODE has no effect, kind >>> of like "wide" had no effect in bug STDCXX-470. >>> $ nice make BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s >>> BUILDMODE=pthreads,archive,optimized,narrow CONFIG=icc.config >>> creating BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s >>> generating /home/mbrown/stdcxx-icc-10.0-12s/makefile.in from >>> /home/mbrown/stdcxx/etc/config/icc.config >>> make[1]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s' >>> make[2]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include' >>> make config >>> make[3]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include' >>> configuring stdcxx 4.2.0 for icc-10.0 on linux-2.6.18-1.2798.fc6-x86_64 >>> checking if the compiler is sane ok (invoked with icc) >>> checking if the linker is sane ok (invoked with icc) >>> checking system architecture LP64 little endian >> >
[jira] Commented: (STDCXX-489) [Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect
[ https://issues.apache.org/jira/browse/STDCXX-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513708 ] Andrew Black commented on STDCXX-489: - Greetings Mark. Based on the Intel incident, the 32-bit version of iccvars.sh should be located in /opt/intel/cc/10.0.025/bin . My understanding is that both the 32 and 64 bit version should have been installed if you ran a default install (the incident was with the 9.1 compiler, but the 10.0 compiler seems to be the same, as best I can tell). If the 32 bit version isn't present, it sounds like what you'd need to do would be to run a custom install of the 32 bit compiler. --Andrew Black > [Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect > - > > Key: STDCXX-489 > URL: https://issues.apache.org/jira/browse/STDCXX-489 > Project: C++ Standard Library > Issue Type: Bug > Components: Configuration >Affects Versions: 4.2 > Environment: Intel C++ 10 on Linux >Reporter: Mark Brown > > Configuring stdcxx for 32-bits using > BUILDMODE=pthreads,archive,optimized,narrow on x86_64 I see the system > architecture is "LP64 little endian" instead of "ILP32 little endian." It > looks like the "narrow" in BUILDMODE has no effect, kind of like "wide" had > no effect in bug STDCXX-470. > $ nice make BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s > BUILDMODE=pthreads,archive,optimized,narrow CONFIG=icc.config > creating BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s > generating /home/mbrown/stdcxx-icc-10.0-12s/makefile.in from > /home/mbrown/stdcxx/etc/config/icc.config > make[1]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s' > make[2]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include' > make config > make[3]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include' > configuring stdcxx 4.2.0 for icc-10.0 on linux-2.6.18-1.2798.fc6-x86_64 > checking if the compiler is sane ok (invoked with icc) > checking if the linker is sane ok (invoked with icc) > checking system architecture LP64 little endian -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-489) [Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect
[ https://issues.apache.org/jira/browse/STDCXX-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black resolved STDCXX-489. - Resolution: Invalid Greetings Mark. I'm closing this issue as 'Invalid', as the cause of the problem is your environment. Unlike most other compilers, the Intel compiler doesn't have a command line switch to control whether the generated executables are 32 or 64 bit. Rather, there are two separate executables, one 32 bit, and one 64 bit. (The only other compilers I can think of with this behavior are Visual Studio and the Intel Compiler for Windows.) To produce a 32 bit executable with the Intel compiler, you will need to use the correct iccvars.sh to set up your environment. This quirk of the Intel compiler has caused problems for me also. If you have an Intel Premier account, https://premier.intel.com/premier/IssueDetail.aspx?IssueID=420157 was a support request I filed asking for assistance on this subject. --Andrew Black > [Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect > - > > Key: STDCXX-489 > URL: https://issues.apache.org/jira/browse/STDCXX-489 > Project: C++ Standard Library > Issue Type: Bug > Components: Configuration >Affects Versions: 4.2 > Environment: Intel C++ 10 on Linux >Reporter: Mark Brown > > Configuring stdcxx for 32-bits using > BUILDMODE=pthreads,archive,optimized,narrow on x86_64 I see the system > architecture is "LP64 little endian" instead of "ILP32 little endian." It > looks like the "narrow" in BUILDMODE has no effect, kind of like "wide" had > no effect in bug STDCXX-470. > $ nice make BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s > BUILDMODE=pthreads,archive,optimized,narrow CONFIG=icc.config > creating BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s > generating /home/mbrown/stdcxx-icc-10.0-12s/makefile.in from > /home/mbrown/stdcxx/etc/config/icc.config > make[1]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s' > make[2]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include' > make config > make[3]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include' > configuring stdcxx 4.2.0 for icc-10.0 on linux-2.6.18-1.2798.fc6-x86_64 > checking if the compiler is sane ok (invoked with icc) > checking if the linker is sane ok (invoked with icc) > checking system architecture LP64 little endian -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-116) [Mac OS X 10.2.8] Examples fail to build due to LD error
[ https://issues.apache.org/jira/browse/STDCXX-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Black closed STDCXX-116. --- Resolution: Won't Fix Testing with Darwin 8.10.1 (Mac OS X 10.4.10) and GCC 4.2.0 fails to reproduce this issue. Given that this issue was reported with an antiquated version of the operating system and compiler in question, I am closing this issue as 'Won't Fix'. > [Mac OS X 10.2.8] Examples fail to build due to LD error > > > Key: STDCXX-116 > URL: https://issues.apache.org/jira/browse/STDCXX-116 > Project: C++ Standard Library > Issue Type: Bug > Components: Build > Environment: Mac OS X 10.2.8/Darwin 6.8 with GCC 3.1 >Reporter: Andrew Black >Assignee: Andrew Black > > When attempting to build the examples as part of the make sequence, I recieve > the following messages > gcc -c -I/Volumes/Orion/Work/stdcxx/include/ansi -D_RWSTD_USE_CONFIG > -I/Users/blackaw/Documents/Work/stdcxx//include > -I/Volumes/Orion/Work/stdcxx/include > -I/Volumes/Orion/Work/stdcxx/examples/include -pedantic -nostdinc++ -W > -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long > -Wcast-align /Volumes/Orion/Work/stdcxx/examples/manual/accum.cpp > gcc accum.o -o accum -L/Users/blackaw/Documents/Work/stdcxx//lib -lstd > -lsupc++ -lm > ld: archive: /Users/blackaw/Documents/Work/stdcxx//lib/libstd.a has no table > of contents, add one with ranlib(1) (can't load from it) > make[2]: *** [accum] Error 1 > make[1]: [examples] Error 2 (ignored) > The obvious solution is to call ranlib as part of the make process for the > library, but this would involve altering the make proccess for the config > tests, library and test library, along with requiring conditional logic to > protect other platforms/compilers from this step that would likely cause > problems. > Looking at the man page for ranlib on my linux box here, it appears that a > better solution could be to define ARFLAGS for gcc as being '-s', though I > could potentially see problems emerging were this to be an unconditional > definition. > I will try this solution tonight. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-488) [Mac OS X/Darwin] RPATH not defined in makefile.in
[Mac OS X/Darwin] RPATH not defined in makefile.in -- Key: STDCXX-488 URL: https://issues.apache.org/jira/browse/STDCXX-488 Project: C++ Standard Library Issue Type: Bug Components: Build Environment: All Mac OS X and Darwin platforms, dynamic builds Reporter: Andrew Black Assignee: Andrew Black Priority: Minor When configuring a build on Mac OS X and Darwin, the generated makefile.in doesn't define a value for the RPATH makefile variable. As a result, the path to the library directory isn't embedded into the build. In turn, this leads to failures running the generated executables in dynamic builds. A placeholder workaround is to define DYLD_LIBRARY_PATH. The correct resolution is to determine the correct value for the RPATH variable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r555106 - /incubator/stdcxx/trunk/etc/config/src/LIMITS.cpp
Greetings Martin I'm not certain, but I suspect this change has lead to a breakage with aCC 3.73 and aCC 3.76. In particular, I see the following failure while building the library (remarks trimmed out) > aCC -c -I$(TOPDIR)/include/ansi -I/usr/include -I$(TOPDIR)/include > -I$(BUILDDIR)/include -Aa +nostl +W2193 +W2261 +W2340 +W2401 +W2487 +W4263 > +W4264 +W4297 +O2 +DD64 +w +W392 +W655 +W684 +W818 +W819 +W849 +Z > $(TOPDIR)/src/time_put.cpp > "$(TOPDIR)/src/time_put.cpp", line 2811: error #2167: argument of type > "unsigned long" is incompatible with parameter of type "const wchar_t *" > bufsize, > ^ The failure is a fairly new (less than a week old), and I believe this to be the most likely culprit. --Andrew Black [EMAIL PROTECTED] wrote: > Author: sebor > Date: Tue Jul 10 15:51:19 2007 > New Revision: 555106 > > URL: http://svn.apache.org/viewvc?view=rev&rev=555106 > Log: > 2007-07-10 Martin Sebor <[EMAIL PROTECTED]> > > STDCXX-482 > * LIMITS.cpp (compute_limits): Used the first argument to pass in > a pointer to a value for the function to use in integer arithmetic > involving (signed) overflow which with some aggressive optimizers > such as Sun Studio 12 aka Sun C++ 5.9 leads to undefined behavior. > (main): Introduced MKLIMITS() macro for convenience. > > Modified: > incubator/stdcxx/trunk/etc/config/src/LIMITS.cpp
Usage of -AA vs -Aa with acc
Greetings Martin, all. I've been looking at the acc.config file, and I'm curious as to the reason we're using the -AA switch with aCC 5 and 6 (HPUX on IA64), but using the -Aa switch for aCC 3 (HPUX on PARISC). The reason I'm curious is because my understanding is that most libraries are built using -AA, such as those provided by many database vendors. In addition, libraries built with -Aa are binary incompatible with those built with -AA. (As background for those unfamiliar with the compiler, the -AA and -Aa switches enable recent ANSI C++ features like Koenig lookup, but differ in the include paths and versions of libCsup used.) --Andrew Black
[jira] Created: (STDCXX-482) [Sun C++ 5.9] LIMITS configuration test enters infinite loop in optimized builds
[Sun C++ 5.9] LIMITS configuration test enters infinite loop in optimized builds Key: STDCXX-482 URL: https://issues.apache.org/jira/browse/STDCXX-482 Project: C++ Standard Library Issue Type: Bug Components: Configuration Affects Versions: 4.2 Environment: Sun C++ 5.9 (Sun Studio 12) Reporter: Andrew Black Priority: Critical (See also report by Michael van der Westhuizen in http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200707.mbox/[EMAIL PROTECTED] ) Nightly testing indicates that release builds with trunk and the Sun Studio 12 compiler lead to an infinite loop while running the LIMITS (numeric limits) configuration test. As a result, it is necessary to deschedule these requests from testing to avoid clogging the nightly testing system until it has been investigated/resolved. --Andrew Black -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Windows build failures reported as DATA
Greetings Martin. I've done a little digging, and the problem appears to originate in the glue scripts used for nightly testing. In particular, the post-run parser for windows incorrectly interprets a failure to build the library as a hard (state C) failure, rather than a library (state F) failure. I will be checking in a fix shortly. --Andrew Black Martin Sebor wrote: > Most of our Windows buils failed due to a change I committed over > the weekend (http://svn.apache.org/viewvc?view=rev&revision=554281). > I'm working on fixing the regression but the breakage highlighted > another problem that I'm hoping you might be able to quickly fix, > Andrew. Even though the builds failed due to a compilation error > in the library they are reported in the status of DATA instead > of LIB. > > Thanks > Martin
Re: Intel C++ build issues on Windows
Greetings Martin According to the IT department, we have version 9.1.037 installed on one build server on each platform. Intel builds on windows are generally broken, due to a poorly coordinated installation of the 10.0.026 compiler. I will be working to resolve these issues on Monday. --Andrew Black Martin Sebor wrote: > Farid Zaripov wrote: >>> -Original Message- >>> From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, June >>> 29, 2007 9:53 PM >>> To: stdcxx-dev@incubator.apache.org >>> Subject: Re: Intel C++ build issues on Windows >>> > [...] >>> Farid, what is the exact version of Intel C++ and MSVC that you're >>> using on Windows? Our logs indicate we are at 9.1.028 for icl and >>> Visual Studio 2005. Andrew, do you know if we're have a service pack >>> installed for Visual Studio and if so, what version it is? >>> Ditto for the OS. >> >> Intel Compiler: >> - >> Intel(R) C++ Compiler for 32-bit applications, Version 9.1Build >> 20060323Z > > The latest 9.1 patch is 9.1.038 dated 2007/05/10. We appear > to be at 9.1.028, which is quite a bit out of date (dated > 2006/07/06). Yours is even older and corresponds to 9.1.022. > > I think we all need to upgrade to the latest patch and see > if the issue persists. > > Martin
Re: [VOTE] ready to graduate
+1 Martin Sebor wrote: > Our mentors as well as a number of IPMC members recently expressed > confidence in stdcxx being ready to graduate out of the incubator > (see the thread starting with msg14476 below). > > In order to propose graduation to the Incubator PMC we all need to > formally agree that we are ready. This is a vote to ascertain this > agreement. > > [ ] Check here (or use +1) to indicate you agree that stdcxx is > ready to graduate. > > [ ] Check here (or use -1) to indicate that stdcxx is not ready > to graduate at this point. If you check this please provide > comments explaining what you feel needs to change in order > for it to become ready. > > Martin > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg14476.html
[jira] Commented: (STDCXX-109) [Mac OS X 10.2.8] Unable to build rwstderr.cat (no gencat utility)
[ https://issues.apache.org/jira/browse/STDCXX-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510418 ] Andrew Black commented on STDCXX-109: - I am uncertain if this problem actually is a must fix for 4.2.0. The OS and compiler in question are old, and we are at least able to get the library to build on newer versions of the operating system (though other problems have been observed). Combined with other problems with the OS/compiler in question, I'm not certain it's worth trying to resolve the issue - for this OS and compiler. This issue points out a slightly larger problem though - Should we require there to be a version of gencat on unix systems, or should we try to provide some sort of a workaround for systems which lack the utility? If we chose the former route, this issue can be closed as 'Won't Fix'. If the later, a decision needs to be made on whether this accommodation is something that needs to be done for 4.2.0. --Andrew Black > [Mac OS X 10.2.8] Unable to build rwstderr.cat (no gencat utility) > -- > > Key: STDCXX-109 > URL: https://issues.apache.org/jira/browse/STDCXX-109 > Project: C++ Standard Library > Issue Type: Bug > Components: Build > Environment: Mac OS X 10.2.8/Darwin 6.8 with GCC 3.1 > Reporter: Andrew Black >Assignee: Andrew Black > Fix For: 4.2 > > > When the make process gets to the point where it tries to build the > rwstderr.cat file, the make process fails with > gencat rwstderr.cat /Volumes/Orion/Work/stdcxx/src/rwstderr.msg > /bin/sh: gencat: command not found > make[2]: *** [rwstderr.cat] Error 127 > make[1]: *** [lib] Error 2 > make: *** [libstd] Error 2 > The most obvious cause is that there is no gencat utility installed on the > system in the $PATH hierarchy. I have not searched for the gencat utility > outside of the $PATH hierarchy at this point in time, though it would make > sense to do so. As this utility is referenced as a part of the makefile > rules, it would be difficult at best to control logic through the > characterization tests. > A possible way to detect if there is an accessable copy of gencat would be to > use the which command, redirecting the output to /dev/null, and using the > return code to detect the location. > Another possible tactic would be to make the failed execution of gencat a non > fatal problem (which likely would result in other problems if it failed in > other circumstances), then to touch the output file when done so that a file > is present (if empty) to be used in building the library. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: status of STDCXX-116
Greetings Martin My instinct is to say that the problem is that of an obsolete OS and compiler. However, as I noted in http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200706.mbox/[EMAIL PROTECTED] I was unable to run the generated executables when I built with a more modern OS and compiler. As the system used to perform the build is at home, at this moment I am unable to check if the errors observed are the same or different. My suspicion is that they are different, but I'm not certain. --Andrew Black Martin Sebor wrote: > Andrew, any update on this issue? > > https://issues.apache.org/jira/browse/STDCXX-116 > > Thanks > Martin
