date:20070911


[ 
https://issues.apache.org/jira/browse/STDCXX-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526440
 ] 

farid edited comment on STDCXX-520 at 9/11/07 5:14 AM:
---

The example doesn't fail (crash or something). It's just return 1 to indicate 
that used locales not available.

Added output of the error message thus: 
http://svn.apache.org/viewvc?rev=574560view=rev

Changed type back to improvement and scheduled for 4.2.1.


  was (Author: farid):
The example doesn't fail (crash or something). It's just return 1 to 
indicate that used locales not available.

Added output of the error message thus: 
http://svn.apache.org/viewvc?rev=574560view=rev

Changed type back to improvement and scheduled to 4.2.1.

  
 codecvt1.cpp example exits with exitcode=1
 --

 Key: STDCXX-520
 URL: https://issues.apache.org/jira/browse/STDCXX-520
 Project: C++ Standard Library
  Issue Type: Improvement
  Components: Examples
Affects Versions: 4.1.3
 Environment: All
Reporter: Farid Zaripov
Assignee: Farid Zaripov
Priority: Minor
 Fix For: 4.2.1


 codecvt1.cpp example exits with exitcode=1 because of no requested locales 
 are installed.
 The thread in mailing-list: 
 http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03703.html
 --
 codecvt1 should probably be disabled for now (until we figure
 out how to get it to work) and it should also be renamed to
 something more descriptive. Testing three hardwired encodings
 doesn't seem like a good idea for a simple example, so maybe
 we could split it up into codecvt-sjis.cpp, codecvt-eucjp,
 and codecvt-utf8.cpp.
 --

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-520) codecvt1.cpp example exits with exitcode=1


 [ 
https://issues.apache.org/jira/browse/STDCXX-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Farid Zaripov updated STDCXX-520:
-

Fix Version/s: (was: 4.2)
   4.2.1
   Issue Type: Improvement  (was: Bug)

The example doesn't fail (crash or something). It's just return 1 to indicate 
that used locales not available.

Added output of the error message thus: 
http://svn.apache.org/viewvc?rev=574560view=rev

Changed type back to improvement and scheduled to 4.2.1.


 codecvt1.cpp example exits with exitcode=1
 --

 Key: STDCXX-520
 URL: https://issues.apache.org/jira/browse/STDCXX-520
 Project: C++ Standard Library
  Issue Type: Improvement
  Components: Examples
Affects Versions: 4.1.3
 Environment: All
Reporter: Farid Zaripov
Assignee: Farid Zaripov
Priority: Minor
 Fix For: 4.2.1


 codecvt1.cpp example exits with exitcode=1 because of no requested locales 
 are installed.
 The thread in mailing-list: 
 http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03703.html
 --
 codecvt1 should probably be disabled for now (until we figure
 out how to get it to work) and it should also be renamed to
 something more descriptive. Testing three hardwired encodings
 doesn't seem like a good idea for a simple example, so maybe
 we could split it up into codecvt-sjis.cpp, codecvt-eucjp,
 and codecvt-utf8.cpp.
 --

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (STDCXX-517) No required options for generate.bat script

[
https://issues.apache.org/jira/browse/STDCXX-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Farid Zaripov resolved STDCXX-517.
--

Resolution: Fixed

Fixed thus: http://svn.apache.org/viewvc?rev=574613view=rev

No required options for generate.bat script
---

Key: STDCXX-517
URL: https://issues.apache.org/jira/browse/STDCXX-517
Project: C++ Standard Library
Issue Type: Improvement
Components: Configuration
Affects Versions: 4.1.3
Environment: All Windows platforms
Reporter: Eric Lemings
Assignee: Farid Zaripov
Fix For: 4.2

The generate.bat script currently requires two options: /BUILDDIR and
/CONFIG. Unless there's a valid reason NOT to do so, the generate.bat script
should preset or determine the following values for these options when the
user does not specify their own value. /BUILDDIR should default to the
source directory; that is, the same directory containing the generate.bat
script. For the /CONFIG option, the script should probe the build
environment for all possible/supported Windows compilers currently installed
and then sanity check each one that is found. If it finds no sane compilers,
the script should probably issue a warning and just exit. If only one
compiler is found, configure all distribution files to build with that
compiler. If more than one compiler is found, set the target compiler to the
first one found in predefined order of preference. (This order could be for
instance, MSVC 8, 7, ..., Intel C++ 10, 9, 8, etc, Cygwin GCC, Mingw,
Borland, etc.)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (STDCXX-517) No required options for generate.bat script

[
https://issues.apache.org/jira/browse/STDCXX-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Farid Zaripov closed STDCXX-517.

No required options for generate.bat script
---

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (STDCXX-516) Rename generate.bat as configure.bat.


 [ 
https://issues.apache.org/jira/browse/STDCXX-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Farid Zaripov resolved STDCXX-516.
--

Resolution: Fixed

Fixed thus: http://svn.apache.org/viewvc?rev=574618view=rev

 Rename generate.bat as configure.bat.
 -

 Key: STDCXX-516
 URL: https://issues.apache.org/jira/browse/STDCXX-516
 Project: C++ Standard Library
  Issue Type: Improvement
  Components: Configuration
Affects Versions: 4.1.3
 Environment: All Microsoft Windows platforms
Reporter: Eric Lemings
Assignee: Farid Zaripov
Priority: Minor
 Fix For: 4.2


 The generate.bat script does exactly the same thing that conventional 
 'configure' scripts do on Unix platforms: it configures the build environment 
 and generates the necessary build files.  Therefore, the filename 
 'configure.bat' would more easily identify the purpose of this file to users 
 accustomed to its Unix counterpart.  This filename will not interfere with a 
 'configure' script if such a script is added later on.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (STDCXX-516) Rename generate.bat as configure.bat.


 [ 
https://issues.apache.org/jira/browse/STDCXX-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Farid Zaripov closed STDCXX-516.



 Rename generate.bat as configure.bat.
 -

 Key: STDCXX-516
 URL: https://issues.apache.org/jira/browse/STDCXX-516
 Project: C++ Standard Library
  Issue Type: Improvement
  Components: Configuration
Affects Versions: 4.1.3
 Environment: All Microsoft Windows platforms
Reporter: Eric Lemings
Assignee: Farid Zaripov
Priority: Minor
 Fix For: 4.2


 The generate.bat script does exactly the same thing that conventional 
 'configure' scripts do on Unix platforms: it configures the build environment 
 and generates the necessary build files.  Therefore, the filename 
 'configure.bat' would more easily identify the purpose of this file to users 
 accustomed to its Unix counterpart.  This filename will not interfere with a 
 'configure' script if such a script is added later on.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: [jira] Closed: (STDCXX-517) No required options for generate.bat script

2007-09-11 Thread Eric Lemings

Typo in README file:

+specified a the suitable config file will be selected 

 -Original Message-
 From: Farid Zaripov (JIRA) [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, September 11, 2007 8:31 AM
 To: stdcxx-dev@incubator.apache.org
 Subject: [jira] Closed: (STDCXX-517) No required options for 
 generate.bat script

  [ 
 https://issues.apache.org/jira/browse/STDCXX-517?page=com.atla
 ssian.jira.plugin.system.issuetabpanels:all-tabpanel ]

 Farid Zaripov closed STDCXX-517.

  No required options for generate.bat script
  ---

  Key: STDCXX-517
  URL: 
 https://issues.apache.org/jira/browse/STDCXX-517
  Project: C++ Standard Library
   Issue Type: Improvement
   Components: Configuration
 Affects Versions: 4.1.3
  Environment: All Windows platforms
 Reporter: Eric Lemings
 Assignee: Farid Zaripov
  Fix For: 4.2

  The generate.bat script currently requires two options: 
 /BUILDDIR and /CONFIG.  Unless there's a valid reason NOT to 
 do so, the generate.bat script should preset or determine the 
 following values for these options when the user does not 
 specify their own value.  /BUILDDIR should default to the 
 source directory; that is, the same directory containing the 
 generate.bat script.  For the /CONFIG option, the script 
 should probe the build environment for all possible/supported 
 Windows compilers currently installed and then sanity check 
 each one that is found.  If it finds no sane compilers, the 
 script should probably issue a warning and just exit.  If 
 only one compiler is found, configure all distribution files 
 to build with that compiler.  If more than one compiler is 
 found, set the target compiler to the first one found in 
 predefined order of preference.  (This order could be for 
 instance, MSVC 8, 7, ..., Intel C++ 10, 9, 8, etc, Cygwin 
 GCC, Mingw, Borland, etc.)

 -- 
 This message is automatically generated by JIRA.
 -
 You can reply to this email to add a comment to the issue online.

RE: [jira] Closed: (STDCXX-517) No required options for generate.bat script

2007-09-11 Thread Farid Zaripov

 

 -Original Message-
 From: Eric Lemings [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, September 11, 2007 6:09 PM
 To: stdcxx-dev@incubator.apache.org
 Subject: RE: [jira] Closed: (STDCXX-517) No required options 
 for generate.bat script
 
 
 Typo in README file:
 
 +specified a the suitable config file will be selected

  Fixed: http://svn.apache.org/viewvc?rev=574626view=rev

Farid.

Re: [jira] Updated: (STDCXX-536) allow thread safety tests to time out without failing


Hi Travis,

Can you describe how this all works? I.e., what happens to a test
invoked without the --timeout option when it exceeds the default
295ms timeout? What happens to one that is invoked with the option?

From your comment below it sounds like the solution you implemented
is different from what I described in the issue, i.e., set an alarm
in response to this command line option and in handler for the alarm
set a flag that each thread would check at each iteration of its
loop to see if it should break.

https://issues.apache.org/jira/browse/STDCXX-536#action_12526315

Thanks
Martin

Travis Vitek (JIRA) wrote:

 [ 
https://issues.apache.org/jira/browse/STDCXX-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Travis Vitek updated STDCXX-536:


Attachment: stdcxx-536.patch

fixed patch to not use rw_note when timer expires because that function is not 
mt-safe.


allow thread safety tests to time out without failing
-

Key: STDCXX-536
URL: https://issues.apache.org/jira/browse/STDCXX-536
Project: C++ Standard Library
 Issue Type: Improvement
 Components: Tests
   Affects Versions: trunk
   Reporter: Martin Sebor
   Assignee: Travis Vitek
Fix For: 4.2

Attachments: stdcxx-536.patch


The newly added thread safety tests (and possibly some of the existing ones) 
tend to run for a long time, consuming a lot of CPU cycles, and sometimes even 
failing due to a timeout (currently 300 seconds in nightly builds). It would be 
useful to provide a mechanism such as a command line option whereby the tests' 
runtime could be limited without necessarily causing them to fail when the 
amount of time is exceeded. One way to do it would be for each test to set an 
alarm in response to this command line option and in handler for the alarm set 
a flag that each thread would check at each iteration of its loop to see if it 
should break.

[jira] Commented: (STDCXX-547) [Sun C++] 64-bit conversion warnings building the library


[ 
https://issues.apache.org/jira/browse/STDCXX-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526523
 ] 

Farid Zaripov commented on STDCXX-547:
--

The similar warnings got when building the library with MSVC 8.0 / x64 platform:

file.cpp
$(TOPDIR)\src\file.cpp(484) : warning C4244: 'argument' : conversion from 
'__int64' to 'long', possible loss of data
$(TOPDIR)\src\file.cpp(493) : warning C4244: 'argument' : conversion from 
'__int64' to 'long', possible loss of data
$(TOPDIR)\src\file.cpp(508) : warning C4244: 'argument' : conversion from 
'unsigned __int64' to 'unsigned int', possible loss of data
$(TOPDIR)\src\file.cpp(523) : warning C4244: 'argument' : conversion from 
'unsigned __int64' to 'unsigned int', possible loss of data

locale_core.cpp
$(TOPDIR)\src\locale_core.cpp(141) : warning C4267: 'argument' : conversion 
from 'size_t' to 'int', possible loss of data

num_put.cpp
$(TOPDIR)\src\num_put.cpp(745) : warning C4244: 'argument' : conversion from 
'__int64' to 'int', possible loss of data
$(TOPDIR)\src\num_put.cpp(772) : warning C4244: 'argument' : conversion from 
'__int64' to 'int', possible loss of data
$(TOPDIR)\src\num_put.cpp(802) : warning C4244: 'argument' : conversion from 
'__int64' to 'int', possible loss of data
$(TOPDIR)\src\num_put.cpp(830) : warning C4244: 'argument' : conversion from 
'__int64' to 'int', possible loss of data

ti_num_get.cpp
$(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '' : result of 32-bit 
shift implicitly converted to 64 bits (was 64-bit shift intended?)
$(TOPDIR)\include\loc/_punct.h(143) : see reference to function 
template instantiation '__rw::__rw_istreambuf_iterator 
__rw::__rw_match_namechar,std::istreambuf_iterator_CharT,_Traits(std::istreambuf_iterator_CharT,_Traits,std::istreambuf_iterator_CharT,_Traits,const
 char *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 ,int 
,std::ios_base *)' being compiled
with
[
_CharT=char,
_Traits=std::char_traitschar
]

ti_wnum_get.cpp
$(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '' : result of 32-bit 
shift implicitly converted to 64 bits (was 64-bit shift intended?)
$(TOPDIR)\include\loc/_punct.h(150) : see reference to function 
template instantiation '__rw::__rw_wistreambuf_iterator 
__rw::__rw_match_namewchar_t,std::istreambuf_iterator_CharT,_Traits(std::istreambuf_iterator_CharT,_Traits,std::istreambuf_iterator_CharT,_Traits,const
 wchar_t *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 
,int ,std::ios_base *)' being compiled
with
[
_CharT=wchar_t,
_Traits=std::char_traitswchar_t
]
$(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '' : result of 32-bit 
shift implicitly converted to 64 bits (was 64-bit shift intended?)
$(TOPDIR)\include\loc/_num_get.cc(218) : see reference to function 
template instantiation '_InputIter 
__rw::__rw_match_namechar,std::istreambuf_iterator_CharT,_Traits(_InputIter,_InputIter,const
 _CharT *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 
,int ,std::ios_base *)' being compiled
with
[
_InputIter=std::istreambuf_iteratorchar,std::char_traitschar,
_CharT=char,
_Traits=std::char_traitschar
]
$(TOPDIR)\include\loc/_num_get.cc(172) : while compiling class template 
member function 'std::istreambuf_iterator_CharT,_Traits 
std::num_get_CharT,_InputIter::do_get(std::istreambuf_iterator_CharT,_Traits,std::istreambuf_iterator_CharT,_Traits,std::ios_base
 ,__rw::__rw_iostate ,bool ) const'
with
[
_CharT=char,
_Traits=std::char_traitschar,
_InputIter=std::istreambuf_iteratorchar,std::char_traitschar
]
$(TOPDIR)\include\loc/_locale.h(346) : see reference to class template 
instantiation 'std::num_get_CharT,_InputIter' being compiled
with
[
_CharT=char,
_InputIter=std::istreambuf_iteratorchar,std::char_traitschar
]
$(TOPDIR)\include\loc/_locale.h(88) : see reference to function 
template instantiation 'const __rw::__rw_facet 
*__rw::__rw_get_facet_Facet(const std::locale ,const _Facet *)' being 
compiled
with
[
_Facet=std::numpunctwchar_t
]
$(TOPDIR)\include\loc/_num_get.cc(196) : see reference to function 
template instantiation 'const _Facet 
std::use_facetstd::numpunct_CharT(const std::locale )' being compiled
with
[
_Facet=std::numpunctwchar_t,
_CharT=wchar_t
]
$(TOPDIR)\include\loc/_num_get.cc(172) : while compiling class template 
member function 'std::istreambuf_iterator_CharT,_Traits 
std::num_get_CharT,_InputIter::do_get(std::istreambuf_iterator_CharT,_Traits,std::istreambuf_iterator_CharT,_Traits,std::ios_base

stdcxx atomics

2007-09-11 Thread Liviu Nicoara

I noticed that -- like other RW libs -- stdcxx does build the atomic ops 
sources even in ST builds although the logic in rw/_mutex.h picks up the 
vanilla implementation in 8-11 builds. Is this a mere slip?


--
Your fault - core dumped.

[jira] Updated: (STDCXX-436) [Linux] MB_LEN_MAX incorrect

2007-09-11 Thread Travis Vitek (JIRA)


 [ 
https://issues.apache.org/jira/browse/STDCXX-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Travis Vitek updated STDCXX-436:


Attachment: LIMITS.cpp.patch

Additional patch that appears to address the above mentioned issue.

 [Linux] MB_LEN_MAX incorrect
 

 Key: STDCXX-436
 URL: https://issues.apache.org/jira/browse/STDCXX-436
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 18. Language Support
Affects Versions: 4.1.3
 Environment: gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
Reporter: Mark Brown
Assignee: Travis Vitek
Priority: Critical
 Fix For: 4.2

 Attachments: 18.limits.stdcxx-436.cpp, LIMITS.cpp.patch, 
 stdcxx-436.patch


 On my Linux system MB_LEN_MAX is normally defined to 16 but when I use the 
 macro in a program compiled with stdcxx the macro evaluates to 1. The test 
 case goes like this:
 $ cat test.cpp  make CPPOPTS=-DGETCONF_MB_LEN_MAX=`getconf MB_LEN_MAX` 
 test  ./test
 #include assert.h
 #include limits.h
 int main ()
 {
 assert (MB_LEN_MAX == GETCONF_MB_LEN_MAX);
 }
 gcc -c -I/home/mbrown/stdcxx/include/ansi -D_RWSTDDEBUG
 -I/home/mbrown/stdcxx/include -I/home/mbrown/stdcxx-gcc-4.1.1-11s/include 
 -I/home/mbrown/stdcxx/examples/include -DGETCONF_MB_LEN_MAX=16 -pedantic 
 -nostdinc++ -g  -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings 
 -Wno-long-long -Wcast-align   test.cpp
 gcc u.o -o u  -L/home/mbrown/stdcxx-gcc-4.1.1-11s/lib  -lstd11s -lsupc++ -lm 
 test: test.cpp:6: int main(): Assertion `1 == 16' failed.
 Aborted

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-436) [Linux] MB_LEN_MAX incorrect

2007-09-11 Thread Travis Vitek (JIRA)


 [ 
https://issues.apache.org/jira/browse/STDCXX-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Travis Vitek updated STDCXX-436:


Attachment: 18.limits.stdcxx-436.cpp

The attached patch includes a regression test for this issue. Unfortunately 
this test fails on windows due to what appears to be a configuration test error.

The LIMITS.cpp configuration test has a block that attempts to detect 
MB_LEN_MAX, and chooses an appropriate default if it is not found. On some 
platforms, it appears that limits.h is included indirectly via stdio.h. Because 
the test does not include limits.h explicitly MB_LEN_MAX is not always defined, 
and the 'appropriate' default value of 8 is incorrect on windows [at least on 
my 32-bit XP configuration].


 [Linux] MB_LEN_MAX incorrect
 

 Key: STDCXX-436
 URL: https://issues.apache.org/jira/browse/STDCXX-436
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 18. Language Support
Affects Versions: 4.1.3
 Environment: gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
Reporter: Mark Brown
Assignee: Travis Vitek
Priority: Critical
 Fix For: 4.2

 Attachments: 18.limits.stdcxx-436.cpp, LIMITS.cpp.patch, 
 stdcxx-436.patch


 On my Linux system MB_LEN_MAX is normally defined to 16 but when I use the 
 macro in a program compiled with stdcxx the macro evaluates to 1. The test 
 case goes like this:
 $ cat test.cpp  make CPPOPTS=-DGETCONF_MB_LEN_MAX=`getconf MB_LEN_MAX` 
 test  ./test
 #include assert.h
 #include limits.h
 int main ()
 {
 assert (MB_LEN_MAX == GETCONF_MB_LEN_MAX);
 }
 gcc -c -I/home/mbrown/stdcxx/include/ansi -D_RWSTDDEBUG
 -I/home/mbrown/stdcxx/include -I/home/mbrown/stdcxx-gcc-4.1.1-11s/include 
 -I/home/mbrown/stdcxx/examples/include -DGETCONF_MB_LEN_MAX=16 -pedantic 
 -nostdinc++ -g  -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings 
 -Wno-long-long -Wcast-align   test.cpp
 gcc u.o -o u  -L/home/mbrown/stdcxx-gcc-4.1.1-11s/lib  -lstd11s -lsupc++ -lm 
 test: test.cpp:6: int main(): Assertion `1 == 16' failed.
 Aborted

-- 
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


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.

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.

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


Andrew Black wrote:

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: [jira] Updated: (STDCXX-536) allow thread safety tests to time out without failing

2007-09-11 Thread Travis Vitek


Ah, maybe there was some miscommunication in our phone conversation on
Friday. When we were talking about this, I mentioned adding a little bit
of code to main for the command line argument stuff, and a little code
to the thread_func to check the flag in each multithreaded test. You
responded that as much of the common stuff should be pushed into the
driver as possible and that the only thing that should be changed in the
tests is the polling of the 'timeout' flag.

That is essentially what I've done here.

Whatever timeout period you specify to --timeout-period=N will be the
number of seconds [remember rw_alarm uses seconds not milliseconds] that
will elapse before the _rw_timeout_expired flag will be set to a
non-zero value. After all of the command line arguments have been
processed, the driver calls _rw_runopts_timeout() which will setup the
alarm. After N seconds have elapsed the flag will be set and the polling
threads should see that and exit early.

After stepping back and thinking about how it probably should work, I've
got some thoughts. I think that the changes to the driver should be
eliminated. If the user wants this timeout stuff in their multithreading
test, then they have to add a hook in the command line arg processing
stuff in main [just like they do for the --nthreads arg]. There would be
one command line argument --timeout that will set the timeout period.
From there I see a choice. Either the test can be expected to explicitly
start/reset the alarm timer [via rw_timeout_start/stop() maybe], or it
could be done implicitly within the rw_thread_pool() function. Either
way, before the threads are started the _rw_timeout_expired flag would
need to be cleared and the alarm would need to be set. After all threads
had exited, the alarm would need to be cancelled.

This way each section of the test would use the provided timeout. The
timeout could still have a default value of 30 seconds if we wanted the
tests to use this without needing to supply additional command line
parameters to them from the build system.

Travis


Martin Sebor wrote:

Hi Travis,

Can you describe how this all works? I.e., what happens to a test
invoked without the --timeout option when it exceeds the default
295ms timeout? What happens to one that is invoked with the option?

 From your comment below it sounds like the solution you implemented
is different from what I described in the issue, i.e., set an alarm
in response to this command line option and in handler for the alarm
set a flag that each thread would check at each iteration of its
loop to see if it should break.

https://issues.apache.org/jira/browse/STDCXX-536#action_12526315

Thanks
Martin

[jira] Closed: (STDCXX-501) [HP aCC 3] compile using -AA rather than -Aa


 [ 
https://issues.apache.org/jira/browse/STDCXX-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Sebor closed STDCXX-501.
---

Resolution: Fixed

Nightly build results confirm this is working correctly.

 [HP aCC 3] 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: Configuration
Affects Versions: 4.1.2, 4.1.3
 Environment: aCC 3/HP-UX/PA-RISC
Reporter: Andrew Black
Assignee: Martin Sebor
Priority: Blocker
 Fix For: 4.2


 (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.

[jira] Updated: (STDCXX-504) Add Apache copyright notices


 [ 
https://issues.apache.org/jira/browse/STDCXX-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Sebor updated STDCXX-504:


Patch Info: [Patch Available]

 Add Apache copyright notices
 

 Key: STDCXX-504
 URL: https://issues.apache.org/jira/browse/STDCXX-504
 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

 Attachments: stdref-diff.txt, stdug-diff.txt




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

new Jira field: Patch Available


To make bug triage a little easier, I added a new field to stdcxx
issues called Patch Available. The field is a check box that should
be checked when a patch is attached to an issue. It would help if
non-committers who have submitted patches to Jira issues that are
ready for review please checked the box.

Thanks
Martin

[jira] Commented: (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:comment-tabpanel#action_12526578
 ] 

Martin Sebor commented on STDCXX-117:
-

Andrew, what's the status of this?

 [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] Commented: (STDCXX-493) std::string::append() slow


[ 
https://issues.apache.org/jira/browse/STDCXX-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526581
 ] 

Martin Sebor commented on STDCXX-493:
-

If you modified the patch in a substantive way you should add yourself to the 
ChangeLog.

 std::string::append() slow
 --

 Key: STDCXX-493
 URL: https://issues.apache.org/jira/browse/STDCXX-493
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 21. Strings
Affects Versions: 4.1.3
 Environment: gcc 4.1.2 on Linux/x86_64
Reporter: Mark Brown
Assignee: Travis Vitek
 Fix For: 4.2

 Attachments: stdcxx-493.patch


 This is a similar problem to STDCXX-492: all overloads of string::append() 
 are slower than the same overloads in gcc:
 $ let n=0; while [ $n -lt 3 ]; do time LD_LIBRARY_PATH=../lib 
 ./append-stdcxx-4.1.3 5 $n; let n=`expr $n + 1`; done
 real0m11.221s
 user0m9.941s
 sys 0m1.104s
 real0m13.065s
 user0m11.661s
 sys 0m1.236s
 real0m7.837s
 user0m6.660s
 sys 0m1.160s
 $ let n=0; while [ $n -lt 3 ]; do time ./append-gcc-4.1.2 5 $n; let 
 n=`expr $n + 1`; done
 real0m4.865s
 user0m4.172s
 sys 0m0.692s
 real0m7.617s
 user0m6.920s
 sys 0m0.696s
 real0m5.787s
 user0m5.068s
 sys 0m0.720s
 The program I used to do the comaprison is below:
 #include cassert
 #include cstdlib
 #include string
 int main (int argc, char *argv[])
 {
 const int N = argc  2 ? 1 : std::atoi (argv [1]);
 const int op = argc  3 ? 0 : std::atoi (argv [2]);
 std::string str;
 const std::string x (X);
 if (op == 0) {
 for (int i = 0; i  N; ++i)
 str.append (1, 'x');
 } else if (op == 1) {
 for (int i = 0; i  N; ++i)
 str.append (x);
 } else {
 for (int i = 0; i  N; ++i)
 str.append (x);
 }
 assert (str.size () == std::size_t (N));
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-493) std::string::append() slow

2007-09-11 Thread Travis Vitek (JIRA)


[ 
https://issues.apache.org/jira/browse/STDCXX-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526590
 ] 

Travis Vitek commented on STDCXX-493:
-

All I did was merge the patch with the current version of the affected file. 
This was necessary so that I could test the patch. If you want the original 
patch, it can be found via the link you posted above.

Since you've mentioned it, how would one go about _adding_ themselves to the 
ChangeLog? I've only seen entries with one author and it might be useful to 
know what the expected format is for the future.

 std::string::append() slow
 --

 Key: STDCXX-493
 URL: https://issues.apache.org/jira/browse/STDCXX-493
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 21. Strings
Affects Versions: 4.1.3
 Environment: gcc 4.1.2 on Linux/x86_64
Reporter: Mark Brown
Assignee: Travis Vitek
 Fix For: 4.2

 Attachments: stdcxx-493.patch


 This is a similar problem to STDCXX-492: all overloads of string::append() 
 are slower than the same overloads in gcc:
 $ let n=0; while [ $n -lt 3 ]; do time LD_LIBRARY_PATH=../lib 
 ./append-stdcxx-4.1.3 5 $n; let n=`expr $n + 1`; done
 real0m11.221s
 user0m9.941s
 sys 0m1.104s
 real0m13.065s
 user0m11.661s
 sys 0m1.236s
 real0m7.837s
 user0m6.660s
 sys 0m1.160s
 $ let n=0; while [ $n -lt 3 ]; do time ./append-gcc-4.1.2 5 $n; let 
 n=`expr $n + 1`; done
 real0m4.865s
 user0m4.172s
 sys 0m0.692s
 real0m7.617s
 user0m6.920s
 sys 0m0.696s
 real0m5.787s
 user0m5.068s
 sys 0m0.720s
 The program I used to do the comaprison is below:
 #include cassert
 #include cstdlib
 #include string
 int main (int argc, char *argv[])
 {
 const int N = argc  2 ? 1 : std::atoi (argv [1]);
 const int op = argc  3 ? 0 : std::atoi (argv [2]);
 std::string str;
 const std::string x (X);
 if (op == 0) {
 for (int i = 0; i  N; ++i)
 str.append (1, 'x');
 } else if (op == 1) {
 for (int i = 0; i  N; ++i)
 str.append (x);
 } else {
 for (int i = 0; i  N; ++i)
 str.append (x);
 }
 assert (str.size () == std::size_t (N));
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-493) std::string::append() slow


[ 
https://issues.apache.org/jira/browse/STDCXX-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526618
 ] 

Martin Sebor commented on STDCXX-493:
-

I meant you DON'T need to add yourself.

 std::string::append() slow
 --

 Key: STDCXX-493
 URL: https://issues.apache.org/jira/browse/STDCXX-493
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 21. Strings
Affects Versions: 4.1.3
 Environment: gcc 4.1.2 on Linux/x86_64
Reporter: Mark Brown
Assignee: Travis Vitek
 Fix For: 4.2

 Attachments: stdcxx-493.patch


 This is a similar problem to STDCXX-492: all overloads of string::append() 
 are slower than the same overloads in gcc:
 $ let n=0; while [ $n -lt 3 ]; do time LD_LIBRARY_PATH=../lib 
 ./append-stdcxx-4.1.3 5 $n; let n=`expr $n + 1`; done
 real0m11.221s
 user0m9.941s
 sys 0m1.104s
 real0m13.065s
 user0m11.661s
 sys 0m1.236s
 real0m7.837s
 user0m6.660s
 sys 0m1.160s
 $ let n=0; while [ $n -lt 3 ]; do time ./append-gcc-4.1.2 5 $n; let 
 n=`expr $n + 1`; done
 real0m4.865s
 user0m4.172s
 sys 0m0.692s
 real0m7.617s
 user0m6.920s
 sys 0m0.696s
 real0m5.787s
 user0m5.068s
 sys 0m0.720s
 The program I used to do the comaprison is below:
 #include cassert
 #include cstdlib
 #include string
 int main (int argc, char *argv[])
 {
 const int N = argc  2 ? 1 : std::atoi (argv [1]);
 const int op = argc  3 ? 0 : std::atoi (argv [2]);
 std::string str;
 const std::string x (X);
 if (op == 0) {
 for (int i = 0; i  N; ++i)
 str.append (1, 'x');
 } else if (op == 1) {
 for (int i = 0; i  N; ++i)
 str.append (x);
 } else {
 for (int i = 0; i  N; ++i)
 str.append (x);
 }
 assert (str.size () == std::size_t (N));
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: renaming branches/4.2.0 to branches/4.2


Just a heads up: I plan to make this change today. If anyone has
any concerns, please speak up now.

Martin

Martin Sebor wrote:

While reading the Release Branches section of the Subversion book
(http://tinyurl.com/8knxw) I realized that our 4.2.0 release branch
would have ideally been named 4.2 to accommodate the evolution of
the branch (i.e., bug fix, or micro releases such as 4.2.1, 4.2.2,
etc.) To make this possible I propose to rename branches/4.2.0 to
branches/4.2 sometime soon.

Are there any objections or concerns? If I don't hear any by, say
EOB Monday, I'll go ahead with the move Tuesday.

Martin

merge fix for STDCXX-501 to 4.2


I plan to merge the fix below to 4.2. The change implements
a long-awaited solution to a binary incompatibility problem
between stdcxx and code compiled with HP aCC with the -AA
option as described in STDCXX-501:

http://issues.apache.org/jira/browse/STDCXX-501
http://svn.apache.org/viewvc?view=revrevision=573411

The change has been successfully tested in our nightly builds
since last Friday.

Martin

Re: renaming branches/4.2.0 to branches/4.2

2007-09-11 Thread William A. Rowe, Jr.

Martin Sebor wrote:
 Just a heads up: I plan to make this change today. If anyone has
 any concerns, please speak up now.

The trouble of course is that you break local checkouts unless those
folks use 'svn switch' to flip the repository location.

One alternative is to leave 4.2.0 in place for now, and fix this at
the time you move the entire svn from it's incubation location over
to a TLP (top level project) subversion location, which breaks everyone
anyways.

Re: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat generate.bat


Andrew, since we discussed merging Farid's change out to 4.2,
I think it would be best to wait until the transient symlink
is in place.

Martin

Martin Sebor wrote:

Since this change affects a user interface to the library I think
we should provide a migration path for the transition to the new
interface. I suggest we keep generate.bat but make it a symbolic
link to configure.bat and deprecate it so that it can be removed
in 4.3.

Martin

[EMAIL PROTECTED] wrote:

Author: faridz
Date: Tue Sep 11 07:39:54 2007
New Revision: 574618

URL: http://svn.apache.org/viewvc?rev=574618view=rev
Log:
2007-09-11 Farid Zaripov [EMAIL PROTECTED]

STDCXX-516
* generate.bat: File renamed ...
* configure.bat: ... to this.
README: generate.bat text replaced by configure.bat.

Added:
incubator/stdcxx/trunk/configure.bat
  - copied unchanged from r574244, 
incubator/stdcxx/trunk/generate.bat

Removed:
incubator/stdcxx/trunk/generate.bat
Modified:
incubator/stdcxx/trunk/README

Modified: incubator/stdcxx/trunk/README
URL: 
http://svn.apache.org/viewvc/incubator/stdcxx/trunk/README?rev=574618r1=574617r2=574618view=diff 

== 


--- incubator/stdcxx/trunk/README (original)
+++ incubator/stdcxx/trunk/README Tue Sep 11 07:39:54 2007
@@ -495,15 +495,15 @@
 
   o   CD stdlib-X.Y.Z-MMDD\stdlib

   DIR /D  # this is ${TOPDIR}
- GNUmakefile  etc  examples  generate.bat include  src  tests
+ GNUmakefile  etc  examples  configure.bat  include  src  tests
 
  If your distribution  does not contain the test  suite and/or the

  examples, the output will look like so:
 
   DIR /D  # this is ${TOPDIR}

- GNUmakefile  etc  generate.bat include  src
+ GNUmakefile  etc  configure.bat  include  src
 
-  o   .\generate.bat [/BUILDDIR:builddir] [/CONFIG:config]

+  o   .\configure.bat  [/BUILDDIR:builddir] [/CONFIG:config]
 
  builddir is the pathname of the build directory where to create

 the solution  and  projects;  the  directory  will  be
@@ -532,7 +532,7 @@
 automatically.
 
   o  Example:

-generate.bat /BUILDDIR:C:\stdcxx /CONFIG:msvc-7.1
+configure.bat  /BUILDDIR:C:\stdcxx /CONFIG:msvc-7.1
 
  This command will create a build directory rooted at ${BUILDDIR},

  the solution file  ${BUILDDIR}\msvc-7.1\msvc-7.1.sln, the project

Re: [jira] Updated: (STDCXX-536) allow thread safety tests to time out without failing


Travis Vitek wrote:

Ah, maybe there was some miscommunication in our phone conversation on
Friday. When we were talking about this, I mentioned adding a little bit
of code to main for the command line argument stuff, and a little code
to the thread_func to check the flag in each multithreaded test. You
responded that as much of the common stuff should be pushed into the
driver as possible and that the only thing that should be changed in the
tests is the polling of the 'timeout' flag.

That is essentially what I've done here.


Okay, this makes sense. I thought the patch would set a default
timeout of 295ms for every test and once reached, force it to
exit with a zero exit status. That would not be good.



Whatever timeout period you specify to --timeout-period=N will be the
number of seconds [remember rw_alarm uses seconds not milliseconds] that
will elapse before the _rw_timeout_expired flag will be set to a
non-zero value. After all of the command line arguments have been
processed, the driver calls _rw_runopts_timeout() which will setup the
alarm. After N seconds have elapsed the flag will be set and the polling
threads should see that and exit early.


Right. But tests whose threads that don't check the flag will
continue running and, presumably, be killed by the infrastructure.



After stepping back and thinking about how it probably should work, I've
got some thoughts. I think that the changes to the driver should be
eliminated. If the user wants this timeout stuff in their multithreading
test, then they have to add a hook in the command line arg processing
stuff in main [just like they do for the --nthreads arg]. There would be
one command line argument --timeout that will set the timeout period.


How about implementing something more along the lines of what we
do with rw_opt_setlocales()? That way the whole command line option
handler along with the logic to set the alarm is in the driver,
and the tests that want to make use of it only need to add
rw_opt_settimeout to the rw_test() call in main()?


From there I see a choice. Either the test can be expected to explicitly
start/reset the alarm timer [via rw_timeout_start/stop() maybe], or it
could be done implicitly within the rw_thread_pool() function.


I don't follow this. Why would the test want to reset the alarm?
Or do you mean set it in response to the command line option?


Either
way, before the threads are started the _rw_timeout_expired flag would
need to be cleared and the alarm would need to be set. After all threads
had exited, the alarm would need to be cancelled.

This way each section of the test would use the provided timeout. The
timeout could still have a default value of 30 seconds if we wanted the
tests to use this without needing to supply additional command line
parameters to them from the build system.


I see where you're going with this. You want the test to be able
to timeout, shut down all running threads when it does, and then
if there's more work to be done (i.e., another group of threads
to create), to reset the alarm and restart the whole process.
Right?

I guess I hadn't thought of the fact that some of these tests
create multiple thread pools. Hmm. I don't think the test should
be allowed to reset its own timeout but I'm not sure I see a good
solution. It certainly shouldn't exit successfully without doing
the rest of the work. Should it fail? Or should it just continue
with the next pool and allow itself to be killed?

Martin



Travis



Martin Sebor wrote:

Hi Travis,

Can you describe how this all works? I.e., what happens to a test
invoked without the --timeout option when it exceeds the default
295ms timeout? What happens to one that is invoked with the option?

From your comment below it sounds like the solution you implemented
is different from what I described in the issue, i.e., set an alarm
in response to this command line option and in handler for the alarm
set a flag that each thread would check at each iteration of its
loop to see if it should break.

https://issues.apache.org/jira/browse/STDCXX-536#action_12526315

Thanks
Martin

Re: renaming branches/4.2.0 to branches/4.2


William A. Rowe, Jr. wrote:

Martin Sebor wrote:

Just a heads up: I plan to make this change today. If anyone has
any concerns, please speak up now.


The trouble of course is that you break local checkouts unless those
folks use 'svn switch' to flip the repository location.

One alternative is to leave 4.2.0 in place for now, and fix this at
the time you move the entire svn from it's incubation location over
to a TLP (top level project) subversion location, which breaks everyone
anyways.


Hmm. I admit I hadn't thought of the local checkout problem. Your
suggestion sounds most sensible. The only concern I have is that
we may not graduate before the release. (I guess I'd better hurry
up with the proposal!) Maybe we could do both: leave 4.2.0 in
place for now and also create 4.2 (or 4.2.x like APR would). Then,
during the transition, we would drop 4.2.0. Does that seem like
a good plan?

Martin

[jira] Resolved: (STDCXX-493) std::string::append() slow


 [ 
https://issues.apache.org/jira/browse/STDCXX-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Sebor resolved STDCXX-493.
-

Resolution: Fixed

Resolved by the committed patch. The before and after timings posted below 
indicate the patch makes the append(const_pointer) overload up to seven times 
faster than in 4.1.3.
http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03995.html

 std::string::append() slow
 --

 Key: STDCXX-493
 URL: https://issues.apache.org/jira/browse/STDCXX-493
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 21. Strings
Affects Versions: 4.1.3
 Environment: gcc 4.1.2 on Linux/x86_64
Reporter: Mark Brown
Assignee: Travis Vitek
 Fix For: 4.2

 Attachments: stdcxx-493.patch


 This is a similar problem to STDCXX-492: all overloads of string::append() 
 are slower than the same overloads in gcc:
 $ let n=0; while [ $n -lt 3 ]; do time LD_LIBRARY_PATH=../lib 
 ./append-stdcxx-4.1.3 5 $n; let n=`expr $n + 1`; done
 real0m11.221s
 user0m9.941s
 sys 0m1.104s
 real0m13.065s
 user0m11.661s
 sys 0m1.236s
 real0m7.837s
 user0m6.660s
 sys 0m1.160s
 $ let n=0; while [ $n -lt 3 ]; do time ./append-gcc-4.1.2 5 $n; let 
 n=`expr $n + 1`; done
 real0m4.865s
 user0m4.172s
 sys 0m0.692s
 real0m7.617s
 user0m6.920s
 sys 0m0.696s
 real0m5.787s
 user0m5.068s
 sys 0m0.720s
 The program I used to do the comaprison is below:
 #include cassert
 #include cstdlib
 #include string
 int main (int argc, char *argv[])
 {
 const int N = argc  2 ? 1 : std::atoi (argv [1]);
 const int op = argc  3 ? 0 : std::atoi (argv [2]);
 std::string str;
 const std::string x (X);
 if (op == 0) {
 for (int i = 0; i  N; ++i)
 str.append (1, 'x');
 } else if (op == 1) {
 for (int i = 0; i  N; ++i)
 str.append (x);
 } else {
 for (int i = 0; i  N; ++i)
 str.append (x);
 }
 assert (str.size () == std::size_t (N));
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: [jira] Updated: (STDCXX-536) allow thread safety tests to time out without failing

2007-09-11 Thread Travis Vitek

 

Martin Sebor wrote

Travis Vitek wrote:

 
 Whatever timeout period you specify to --timeout-period=N 
 will be the number of seconds that will elapse before the
 _rw_timeout_expired flag will be set to a non-zero value.
 [...]

Right. But tests whose threads that don't check the flag will
continue running and, presumably, be killed by the infrastructure.


Exactly.

 
 If the user wants this timeout stuff in their multithreading
 test, then they have to add a hook in the command line arg
 processing stuff in main [just like they do for the --nthreads
 arg]. [...]

How about implementing something more along the lines of what we
do with rw_opt_setlocales()?


Sorry, I gave a poor example. That is exactly what I mean.


 From there I see a choice. Either the test can be expected 
 to explicitly start/reset the alarm timer or it could be
 done implicitly within the rw_thread_pool() function.

I don't follow this. Why would the test want to reset the alarm?
Or do you mean set it in response to the command line option?


Many of the multithreaded tests have several 'sections'. They create a
pool of threads for each section.

Take, for example, the test 22.locale.globals.mt.cpp. It has two
sections. The first creates a pool of threads to call the function
test_has_facet, and the other calls test_use_facet. Imagine that the
first section would run for 30 seconds if given the time, and there was
a 5 second timeout enabled. When the test is run, the first section
would run for 5 seconds and the second section of the test would not run
at all. That is no good. Even worse is the fact that the test would exit
with a successful return code, so there would be no indication that the
second part of the test has been skipped. I think that is a bad thing.

 Either
 way, before the threads are started the _rw_timeout_expired 
flag would
 need to be cleared and the alarm would need to be set. After 
all threads
 had exited, the alarm would need to be cancelled.
 
 This way each section of the test would use the provided timeout. The
 timeout could still have a default value of 30 seconds if we 
wanted the
 tests to use this without needing to supply additional command line
 parameters to them from the build system.

I see where you're going with this. You want the test to be able
to timeout, shut down all running threads when it does, and then
if there's more work to be done (i.e., another group of threads
to create), to reset the alarm and restart the whole process.
Right?

Essentially. I don't mean restart the whole process in the literal
sense. I mean it would go on to the next section of the test so at least
that section would be exercised before the process exited.


I guess I hadn't thought of the fact that some of these tests
create multiple thread pools. Hmm. I don't think the test should
be allowed to reset its own timeout but I'm not sure I see a good
solution.

Yeah, ugh.

It certainly shouldn't exit successfully without doing
the rest of the work.

Agreed.

Should it fail?

Well, if we make the test fail aren't we essentially setting another
hard limit?

Or should it just continue with the next pool and allow
itself to be killed?


If we do that, then this timeout idea is done. 

If the goal is to get the tests to run to completion sometime before the
hard limit there are a few obvious changes we could make. In some cases
we might be able to just reduce the default number of iterations. In
other cases, we could combine 'sections' of the test. Some tests have a
section to test a char specialization, then a wchar_t specialization
section, and finally a combined section that tests both. We could
potentially remove the first two sections, or at least disable them by
default. Another option would be to continue testing these sections, but
separate them out into their own tests.

Travis

[jira] Created: (STDCXX-548) add an internal header for rw::rw_get_stdio_fmat()

add an internal header for __rw::__rw_get_stdio_fmat()
--

 Key: STDCXX-548
 URL: https://issues.apache.org/jira/browse/STDCXX-548
 Project: C++ Standard Library
  Issue Type: Improvement
  Components: Build
Affects Versions: 4.1.4, 4.1.3, 4.1.2
 Environment: All.
Reporter: Martin Sebor
Priority: Minor
 Fix For: 4.2.1


The __rw::__rw_get_stdio_fmat() function (and perhaps some others) defined in 
src/punct.cpp and declared as well as used in both num_get.cpp and num_put.cpp. 
Changing the function signature involves changing three places instead of two, 
which is error-prone. See http://svn.apache.org/viewvc?rev=574738view=rev and 
http://svn.apache.org/viewvc?rev=574422view=rev for an example where this 
caused breakage.

The function (and any other such examples) should be declared in a header to 
prevent such incidents.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: stdcxx atomics

2007-09-11 Thread Liviu Nicoara


Martin Sebor wrote:

Liviu Nicoara wrote:
I noticed that -- like other RW libs -- stdcxx does build the atomic 
ops sources even in ST builds although the logic in rw/_mutex.h picks 
up the vanilla implementation in 8-11 builds. Is this a mere slip?


Yeah, I guess it does. I've never thought about it. It would probably
make sense to avoid compiling them if they're not used. Can you open
an issue? (A patch would be welcome! ;-)


I might find me some time later in the week. :-) It struck me as odd as 
I do the same thing in Tools.


Liviu

--
Your fault - core dumped.

[jira] Created: (STDCXX-549) [Sun C++ 5.9/Linux/x86_64] configuration error on -xarch=generic64

[Sun C++ 5.9/Linux/x86_64] configuration error on -xarch=generic64
--

 Key: STDCXX-549
 URL: https://issues.apache.org/jira/browse/STDCXX-549
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Configuration
Affects Versions: trunk
 Environment: Sun C++ 5.9/Linux/x86_64
Reporter: Martin Sebor
Priority: Critical


Configuration in wide (64-bit) mode with Sun C++ 5.9 fails on Linux/x86_64:

gmake config
gmake[3]: Entering directory `$(BUILDDIR)/include'

configuring stdcxx 4.2.0 for CC-++ on linux-2.6.9-42.elsmp-x86_64

checking if the compiler is sane   no

int main () { return 0; }
CC -D_RWSTDDEBUG -I. -library=%none -g  -xarch=generic64 +w  -c a.cpp -o a.o
CC: illegal option usage -xarch=generic64
gmake[3]: *** [sane] Error 1
gmake[3]: Leaving directory `$(BUILDDIR)/include'
gmake[2]: *** [config.h] Error 2
gmake[2]: Leaving directory `$(BUILDDIR)/include'
gmake[1]: *** [config] Error 2
gmake[1]: Leaving directory `$(BUILDDIR)'
gmake: *** [config] Error 2
Command exited with non-zero status 2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (STDCXX-549) [Sun C++ 5.9/Linux/x86_64] configuration error on -xarch=generic64


 [ 
https://issues.apache.org/jira/browse/STDCXX-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Sebor reassigned STDCXX-549:
---

Assignee: Martin Sebor

 [Sun C++ 5.9/Linux/x86_64] configuration error on -xarch=generic64
 --

 Key: STDCXX-549
 URL: https://issues.apache.org/jira/browse/STDCXX-549
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Configuration
Affects Versions: trunk
 Environment: Sun C++ 5.9/Linux/x86_64
Reporter: Martin Sebor
Assignee: Martin Sebor
Priority: Critical

 Configuration in wide (64-bit) mode with Sun C++ 5.9 fails on Linux/x86_64:
 gmake config
 gmake[3]: Entering directory `$(BUILDDIR)/include'
 configuring stdcxx 4.2.0 for CC-++ on linux-2.6.9-42.elsmp-x86_64
 checking if the compiler is sane   no
 int main () { return 0; }
 CC -D_RWSTDDEBUG -I. -library=%none -g  -xarch=generic64 +w  -c a.cpp -o a.o
 CC: illegal option usage -xarch=generic64
 gmake[3]: *** [sane] Error 1
 gmake[3]: Leaving directory `$(BUILDDIR)/include'
 gmake[2]: *** [config.h] Error 2
 gmake[2]: Leaving directory `$(BUILDDIR)/include'
 gmake[1]: *** [config] Error 2
 gmake[1]: Leaving directory `$(BUILDDIR)'
 gmake: *** [config] Error 2
 Command exited with non-zero status 2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (STDCXX-549) [Sun C++ 5.9/Linux/x86_64] configuration error on -xarch=generic64


 [ 
https://issues.apache.org/jira/browse/STDCXX-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Sebor resolved STDCXX-549.
-

   Resolution: Fixed
Fix Version/s: trunk

Fixed by the referenced patch.

 [Sun C++ 5.9/Linux/x86_64] configuration error on -xarch=generic64
 --

 Key: STDCXX-549
 URL: https://issues.apache.org/jira/browse/STDCXX-549
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Configuration
Affects Versions: trunk
 Environment: Sun C++ 5.9/Linux/x86_64
Reporter: Martin Sebor
Assignee: Martin Sebor
Priority: Critical
 Fix For: trunk


 Configuration in wide (64-bit) mode with Sun C++ 5.9 fails on Linux/x86_64:
 gmake config
 gmake[3]: Entering directory `$(BUILDDIR)/include'
 configuring stdcxx 4.2.0 for CC-++ on linux-2.6.9-42.elsmp-x86_64
 checking if the compiler is sane   no
 int main () { return 0; }
 CC -D_RWSTDDEBUG -I. -library=%none -g  -xarch=generic64 +w  -c a.cpp -o a.o
 CC: illegal option usage -xarch=generic64
 gmake[3]: *** [sane] Error 1
 gmake[3]: Leaving directory `$(BUILDDIR)/include'
 gmake[2]: *** [config.h] Error 2
 gmake[2]: Leaving directory `$(BUILDDIR)/include'
 gmake[1]: *** [config] Error 2
 gmake[1]: Leaving directory `$(BUILDDIR)'
 gmake: *** [config] Error 2
 Command exited with non-zero status 2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: merge fix for STDCXX-501 to 4.2