RE: 21.string.cons.cpp test fails on 64-bit MSVC (8.0 and 9.0)
Farid Zaripov-2 wrote: > >> -Original Message- >> From: Martin Sebor [mailto:[EMAIL PROTECTED] >> Sent: Monday, November 19, 2007 8:11 PM >> To: stdcxx-dev@incubator.apache.org >> Subject: Re: 21.string.cons.cpp test fails on 64-bit MSVC >> (8.0 and 9.0) >> >> > Yes, I've tried it and after applying this patch the problem was >> > resolved (actually invoking __rw_new_capacity(0) was optimized to >> > "return _RWSTD_MINIMUM_STRING_CAPACITY;"). >> >> Great. Now if you could figure out a way to optimize the >> integer expression to avoid all the divisions... :) > > How about this one? > > > https://issues.apache.org/jira/secure/attachment/12369790/new_capacity.p > atch > > Farid. > > Sorry it's taken me so long to get back to this thread. I spent some time today looking at the patch and added my comments to the issue: https://issues.apache.org/jira/browse/STDCXX-226#action_12550775 Martin -- View this message in context: http://www.nabble.com/21.string.cons.cpp-test-fails-on-64-bit-MSVC-%288.0-and-9.0%29-tp13728936p14289932.html Sent from the stdcxx-dev mailing list archive at Nabble.com.
Re: [PATCH] MSVC has non-standard prototype of the wcstok()
Farid Zaripov-2 wrote:
>
> The all MSVC has the non-standard prototype of the wcstok():
>
> wchar_t* wcstok(wchar_t*, const wchar_t*);
>
>
> The prototype from C standard:
> wchar_t* wcstok(wchar_t*, const wchar_t*, wchar_t**);
>
>
> Since the configure script performs checking only names and doesn't
> checking the correct prototype, the _RWSTD_NO_WCSTOK macro is
> not defined in config.h. As a result the 21.cwchar.cpp test asserts on
> "wcstok() not declared".
>
>
But there is a mechanism to check for signatures too, isn't there?
Could we use it to detect this or are you saying even this is not
enough?
Martin
>
> However the MSVC 8 and later has the wcstok_s() function with the
> prototype similar to the standard wcstok():
>
> wchar_t* wcstok_s(wchar_t* _Str, const wchar_t* _Delim, wchar_t **
> _Context);
>
>
> I've propose the following changes:
>
> ChangeLog:
> * rw/_config_msvcrt.h: #define _RWSTD_NO_WCSTOK and
> _RWSTD_NO_WCSTOK_IN_LIBC
> macros since the MSVC has the non-standard prototype of the wcstok().
> * ansi/cwchar [_MSC_VER >= 1400]: Define inline wcstok() function
> using wcstok_s().
> #undefine _RWSTD_NO_WCSTOK and _RWSTD_NO_WCSTOK_IN_LIBC macros.
>
>
> Index: include/ansi/cwchar
> ===
> --- include/ansi/cwchar (revision 596338)
> +++ include/ansi/cwchar (working copy)
> @@ -1074,6 +1074,22 @@
> using ::wcstok;
>
> # undef _RWSTD_NO_WCSTOK
> +#elif defined (_MSC_VER) && 1400 <= _MSC_VER
> +
> +} // namespace std
> +
> +/* extern "C++" */ inline wchar_t*
> +wcstok (wchar_t* __s1, const wchar_t* __s2, wchar_t** __ptr)
> +{
> +return wcstok_s (__s1, __s2, __ptr);
> +}
> +
> +namespace std {
> +
> +using ::wcstok;
> +
> +# undef _RWSTD_NO_WCSTOK
> +# undef _RWSTD_NO_WCSTOK_IN_LIBC
> #endif // _RWSTD_NO_WCSTOK[_IN_LIBC]
>
> #ifndef _RWSTD_NO_WCSTOL
> Index: include/rw/_config-msvcrt.h
> ===
> --- include/rw/_config-msvcrt.h (revision 596338)
> +++ include/rw/_config-msvcrt.h (working copy)
> @@ -54,6 +54,15 @@
> # define _RWSTD_NO_DEPRECATED_C_HEADERS
> #endif // _RWSTD_NO_DEPRECATED_C_HEADERS
>
> +#ifndef _RWSTD_NO_WCSTOK
> +// MSVC CRT has incorrect prototype of the wcstok()
> +# define _RWSTD_NO_WCSTOK
> +#endif // _RWSTD_NO_WCSTOK
> +
> +#ifndef _RWSTD_NO_WCSTOK_IN_LIBC
> +# define _RWSTD_NO_WCSTOK_IN_LIBC
> +#endif // _RWSTD_NO_WCSTOK_IN_LIBC
> +
> // operator new and delete is not reliably replaceable across
> // shared library boundaries, which includes the shared library
> // version of the language support library
>
> Farid.
>
>
--
View this message in context:
http://www.nabble.com/-PATCH--MSVC-has-non-standard-prototype-of-the-wcstok%28%29-tp13857994p14289929.html
Sent from the stdcxx-dev mailing list archive at Nabble.com.
_RWSTD_VER value on trunk (was: Re: svn commit: r597396 - /incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp)
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? Martin Sebor wrote: > > [EMAIL PROTECTED] wrote: >> Author: faridz >> Date: Thu Nov 22 04:40:33 2007 >> New Revision: 597396 >> >> URL: http://svn.apache.org/viewvc?rev=597396&view=rev >> Log: >> 2007-11-22 Farid Zaripov <[EMAIL PROTECTED]> >> >> * 26.valarray.cassign.cpp (run_test): Corrected condition in >> preprocessor directive. > > Good catch, thanks! > > We should probably bump up _RWSTD_VER on trunk. To what, though? > > It might also be a good idea to always set the macro so that it can't > match that of any branch. Any ideas how to do that? > > Martin > >> >> Modified: >> >> incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp >> >> Modified: >> incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp >> URL: >> http://svn.apache.org/viewvc/incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp?rev=597396&r1=597395&r2=597396&view=diff >> == >> --- >> incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp >> (original) >> +++ >> incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp >> Thu Nov 22 04:40:33 2007 >> @@ -805,7 +805,7 @@ >> TEST (int); >> TEST (double); >> >> -#if 0x0402 <= _RWSTD_VER >> +#if 0x0402 >= _RWSTD_VER >> >> // test fails to compile with stdcxx 4.2.0 and prior due to >> // STDCXX-512: http://issues.apache.org/jira/browse/STDCXX-512 >> >> >> > > > -- View this message in context: http://www.nabble.com/Re%3A-svn-commit%3A-r597396incubator-stdcxx-branches-4.2.x-tests-numerics-26.valarray.cassign.cpp-tp13905517p14289920.html Sent from the stdcxx-dev mailing list archive at Nabble.com.
[PING] Re: planning 4.2.1, 4.3, and beyond
Any thoughts on this? Martin Sebor wrote: > > I'd like to discuss our plans and schedule for the next few releases, > starting with 4.2.1 and 4.3, work on both of which might very well take > place in parallel. > > In the post below, I suggested the end of December for the maintenance > 4.2.1 release: > http://www.nabble.com/timeframe-for-4.2.1--tf4749764.html#a13581657 > I suspect this is overly optimistic, in part because I think we should > first transition out of the incubator before we put out another release, > and also because we still have over 100 bugs scheduled for this update. > What should be included in 4.2.1? Besides issues already scheduled for > 4.2.1 I think we should try to finish the Purify project (Travis) and > set up Purify for nightly (or some other periodic type of) testing. > As far as platform support goes, my suggested breakdown (Primary, > Secondary etc.) is here: > http://www.nabble.com/Re%3A--RFC--stdcxx-release-process-p13598352.html > With this as background I'm beginning to think that February might be > a more reasonable time frame for 4.2.1. But before we solidify any of > this we first need to finalize the Release and Version Policy. I'd > like to start the vote on the document this week, so if there are > any comments of questions on the latest draft, or any concerns or > comments on this proposed approach, please send them in ASAP. > > At the same time, I'd really like us to start making progress on some > of the (formerly TR1) C++ 0x features (STDCXX-27). They are currently > scheduled for 5.0 but I don't see any reason why at least some of them > couldn't be included in 4.3. One of the first things that should be > implemented, IMO, is type_traits, so we can get some experience with > the new implementation and start taking advantage of the little > critters in new code (such as the unordered associative containers, > STDCXX-32). Another big ticket item that we should start working on > is Concepts (STDCXX-672). As long as we maintain compatibility there > should be no reason not to phase in support for Concepts in chunks > rather than waiting until everything is done. Of course, features > that require incompatible changes will need to be deferred until > 5.0. It would be good to start thinking about which ones those > might be and which ones can be targeted for 4.3. > > Thoughts? > > Martin > > -- View this message in context: http://www.nabble.com/planning-4.2.1%2C-4.3%2C-and-beyond-tp13943332p14289891.html Sent from the stdcxx-dev mailing list archive at Nabble.com.
Re: mailing list for Jira issues?
Okay, I updated INFRA-1422 and requested a new mailing list: [EMAIL PROTECTED] https://issues.apache.org/jira/browse/INFRA-1422#action_12550847 Once it's set up, well redirect Jira traffic to it. 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? > > https://issues.apache.org/jira/browse/STDCXX-546 > > > -- View this message in context: http://www.nabble.com/mailing-list-for-Jira-issues--tp14248354p14289778.html Sent from the stdcxx-dev mailing list archive at Nabble.com.
[jira] Assigned: (STDCXX-647) [MSVC] 0.printf.cpp test fails
[
https://issues.apache.org/jira/browse/STDCXX-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor reassigned STDCXX-647:
---
Assignee: Farid Zaripov
> [MSVC] 0.printf.cpp test fails
> --
>
> Key: STDCXX-647
> URL: https://issues.apache.org/jira/browse/STDCXX-647
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2.0
> Environment: MSVC, ICC/Windows
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
>Priority: Minor
> Fix For: 4.2.1
>
>
> The 0.printf.cpp test fails with 36 assertions due to STDCXX-646:
>
> # Assertion failed on line 2076: rw_sprintf("[%{$NULL-word}]", ...) == "[]",
> got "[word]"
> # Assertion failed on line 2092: rw_sprintf("[%{$NULL=word}]", ...) == "[]",
> got "[word]"
> # Assertion failed on line 2103: rw_sprintf("[%{$UNSET:?word}]", ...) ==
> "[%{$UNSET:?word}]", got "[word]"
> # Assertion failed on line 2107: rw_sprintf("[%{$NULL?word}]", ...) == "[]",
> got "[%{$NULL?word}]"
> # Assertion failed on line 2108: rw_sprintf("[%{$UNSET?word}]", ...) ==
> "[%{$UNSET?word}]", got "[word]"
> # Assertion failed on line 2113: rw_sprintf("[%{$UNSET:+word}]", ...) ==
> "[]", got "[word]"
> # Assertion failed on line 2117: rw_sprintf("[%{$NULL+word}]", ...) ==
> "[word]", got "[]"
> # Assertion failed on line 2118: rw_sprintf("[%{$UNSET+word}]", ...) == "[]",
> got "[word]"
> # Assertion failed on line 2128: rw_sprintf("[%{$*:-WORD}]", ...) ==
> "[WORD]", got "[word]"
> # Assertion failed on line 2131: rw_sprintf("[%{$*-WORD}]", ...) == "[]", got
> "[WORD]"
> # Assertion failed on line 2132: rw_sprintf("[%{$*-WORD}]", ...) == "[WORD]",
> got "[word]"
> # Assertion failed on line 2137: rw_sprintf("[%{$*:=WORD}]", ...) ==
> "[WORD]", got "[word]"
> # Assertion failed on line 2138: rw_sprintf("[%{$*}]", ...) == "[WORD]", got
> "[word]"
> # Assertion failed on line 2145: rw_sprintf("[%{$*=WORD}]", ...) == "[]", got
> "[WORD]"
> # Assertion failed on line 2146: rw_sprintf("[%{$*=WORD}]", ...) == "[WORD]",
> got "[word]"
> # Assertion failed on line 2147: rw_sprintf("[%{$*}]", ...) == "[WORD]", got
> "[word]"
> # Assertion failed on line 2155: rw_sprintf("[%{$*:?WORD}]", ...) ==
> "[%{$*:?WORD}]", got "[word]"
> # Assertion failed on line 2158: rw_sprintf("[%{$*?WORD}]", ...) == "[]", got
> "[%{$*?WORD}]"
> # Assertion failed on line 2159: rw_sprintf("[%{$*?WORD}]", ...) ==
> "[%{$*?WORD}]", got "[word]"
> # Assertion failed on line 2163: rw_sprintf("[%{$*:+WORD}]", ...) == "[]",
> got "[WORD]"
> # Assertion failed on line 2166: rw_sprintf("[%{$*+WORD}]", ...) == "[WORD]",
> got "[]"
> # Assertion failed on line 2167: rw_sprintf("[%{$*+WORD}]", ...) == "[]", got
> "[WORD]"
> # Assertion failed on line 2173: rw_sprintf("[%{$*:-*}]", ...) == "[WORD]",
> got "[word]"
> # Assertion failed on line 2176: rw_sprintf("[%{$*-*}]", ...) == "[]", got
> "[WORD]"
> # Assertion failed on line 2177: rw_sprintf("[%{$*-*}]", ...) == "[WORD]",
> got "[word]"
> # Assertion failed on line 2182: rw_sprintf("[%{$*:=*}]", ...) == "[WORD]",
> got "[word]"
> # Assertion failed on line 2183: rw_sprintf("[%{$*}]", ...) == "[WORD]", got
> "[word]"
> # Assertion failed on line 2190: rw_sprintf("[%{$*=*}]", ...) == "[]", got
> "[WORD]"
> # Assertion failed on line 2191: rw_sprintf("[%{$*=*}]", ...) == "[WORD]",
> got "[word]"
> # Assertion failed on line 2192: rw_sprintf("[%{$*}]", ...) == "[WORD]", got
> "[word]"
> # Assertion failed on line 2200: rw_sprintf("[%{$*:?*}]", ...) ==
> "[%{$*:?*}]", got "[word]"
> # Assertion failed on line 2203: rw_sprintf("[%{$*?*}]", ...) == "[]", got
> "[%{$*?*}]"
> # Assertion failed on line 2204: rw_sprintf("[%{$*?*}]", ...) == "[%{$*?*}]",
> got "[word]"
> # Assertion failed on line 2208: rw_sprintf("[%{$*:+*}]", ...) == "[]", got
> "[WORD]"
> # Assertion failed on line 2211: rw_sprintf("[%{$*+*}]", ...) == "[WORD]",
> got "[]"
> # Assertion failed on line 2212: rw_sprintf("[%{$*+*}]", ...) == "[]", got
> "[WORD]"
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-650) 22.locale.codecvt.out test fails to compile
[ https://issues.apache.org/jira/browse/STDCXX-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor closed STDCXX-650. --- Fix verified in nightly builds. Merged to 4.2.1 in http://svn.apache.org/viewvc?view=rev&revision=603470 Closing... > 22.locale.codecvt.out test fails to compile > --- > > Key: STDCXX-650 > URL: https://issues.apache.org/jira/browse/STDCXX-650 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 >Reporter: Travis Vitek >Assignee: Martin Sebor > Fix For: 4.2.1 > > > There is actually nothing wrong with the test itself. The problem is the name > of the test. The makefile has rules for .out files, and when trying to build > the executable 22.locale.codecvt.out, it thinks you are talking about a .out > file, not an executable, so it does nothing. Renaming the source file to > 22.locale.codecvt.outx.cpp avoids the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-673) [IBM XLC++ 9.0/AIX 5.3] 0.printf fails with assertions
[
https://issues.apache.org/jira/browse/STDCXX-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550785
]
Travis Vitek commented on STDCXX-673:
-
It looks like the best solution for now is to always make these types signed. I
found that some platforms define type int8_t to be `char' which can be made
unsigned with a compiler flag. This may be an issue for us to consider if we
make public typedefs based on these macros. Here are the results on the
platforms I had available for testing.
--- AIX/VisualAge C++ 9.0 ---
$ xlC -qchars=unsigned x.cpp && ./a.out
int8_t is signed (signed char)
--- HP-UX/aCC 3.73 --
$ aCC +uc x.cpp && ./a.out
int8_t is unsigned (char)
--- Linux/GCC ---
$ g++ -funsigned-char x.cpp && ./a.out
int8_t is signed (signed char)
--- Solaris/SunPro 5.9 --
$ CC -xchar=unsigned x.cpp && ./a.out
int8_t is unsigned (char)
--- Irix/MipsPro 7.41 ---
$ CC x.cpp && ./a.out
int8_t is signed (signed char)
--- Compaq/Compaq C++ ---
$ cxx -unsigned x.cpp && ./a.out
int8_t is signed (signed char)
> [IBM XLC++ 9.0/AIX 5.3] 0.printf fails with assertions
> --
>
> Key: STDCXX-673
> URL: https://issues.apache.org/jira/browse/STDCXX-673
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Test Driver
>Affects Versions: 4.2.0
>Reporter: Travis Vitek
>Assignee: Travis Vitek
>Priority: Minor
> Fix For: 4.2.1
>
> Attachments: stdcxx-673.patch
>
>
> extension: "%{N}" buffer size
> /amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
> rw_vasnprintf(8d0, 8d8, "foo", va_list) error: errno
> = 12: Not enough space
> /amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
> rw_vasnprintf(8d0, 8d8, "foo", va_list) error: errno
> = 12: Not enough space
> /amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
> rw_vasnprintf(8d0, 8d8, "foo", va_list) error: errno
> = 12: Not enough space
> /amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
> rw_vasnprintf(8d0, 8d8, "foo", va_list) error: errno
> = 12: Not enough space
> /amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
> rw_vasnprintf(8d0, 8d8, "bar", va_list) error: errno
> = 12: Not enough space
> /amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
> rw_vasnprintf(8d0, 8d8, "bar", va_list) error: errno
> = 12: Not enough space
> /amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
> rw_vasnprintf(8d0, 8d8, "bar", va_list) error: errno
> = 12: Not enough space
> /amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
> rw_vasnprintf(8d0, 8d8, "bar", va_list) error: errno
> = 12: Not enough space
> extension: "[EMAIL PROTECTED]" nested format directive
> malformed directives
> Failed 8 out of 1572 assertions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-673) [IBM XLC++ 9.0/AIX 5.3] 0.printf fails with assertions
[
https://issues.apache.org/jira/browse/STDCXX-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Vitek updated STDCXX-673:
Attachment: stdcxx-673.patch
2007-12-11 Travis Vitek <[EMAIL PROTECTED]>
STDCXX-673
* etc/config/src/LIMITS.cpp (main): Always use signed
types for definition of _RWSTD_INT[8,16,32,64]_T macros.
> [IBM XLC++ 9.0/AIX 5.3] 0.printf fails with assertions
> --
>
> Key: STDCXX-673
> URL: https://issues.apache.org/jira/browse/STDCXX-673
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Test Driver
>Affects Versions: 4.2.0
>Reporter: Travis Vitek
>Assignee: Travis Vitek
>Priority: Minor
> Fix For: 4.2.1
>
> Attachments: stdcxx-673.patch
>
>
> extension: "%{N}" buffer size
> /amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
> rw_vasnprintf(8d0, 8d8, "foo", va_list) error: errno
> = 12: Not enough space
> /amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
> rw_vasnprintf(8d0, 8d8, "foo", va_list) error: errno
> = 12: Not enough space
> /amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
> rw_vasnprintf(8d0, 8d8, "foo", va_list) error: errno
> = 12: Not enough space
> /amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
> rw_vasnprintf(8d0, 8d8, "foo", va_list) error: errno
> = 12: Not enough space
> /amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
> rw_vasnprintf(8d0, 8d8, "bar", va_list) error: errno
> = 12: Not enough space
> /amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
> rw_vasnprintf(8d0, 8d8, "bar", va_list) error: errno
> = 12: Not enough space
> /amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
> rw_vasnprintf(8d0, 8d8, "bar", va_list) error: errno
> = 12: Not enough space
> /amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
> rw_vasnprintf(8d0, 8d8, "bar", va_list) error: errno
> = 12: Not enough space
> extension: "[EMAIL PROTECTED]" nested format directive
> malformed directives
> Failed 8 out of 1572 assertions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-226: Attachment: benchmark-stdcxx-226.c Attached simple benchmark program to compare the runtime performance of the three approaches discussed in the issue. Compiled with any C compiler, run as follows: $ time ./a.out [ 0 | 1 | 2 ] N 0 for the original algorithm 1 for the algorithm implemented in the attached patch 2 for the reciprocal multiplication approach N the number of iterations (unsigned long) > __rw::__rw_new_capacity() uses floating point math > -- > > Key: STDCXX-226 > URL: https://issues.apache.org/jira/browse/STDCXX-226 > Project: C++ Standard Library > Issue Type: Improvement > Components: 23. Containers >Affects Versions: 4.1.2, 4.1.3, 4.2.0 > Environment: all >Reporter: Martin Sebor >Assignee: Farid Zaripov > Fix For: 4.2.1 > > Attachments: benchmark-stdcxx-226.c, new_capacity.patch > > > Moved from the Rogue Wave bug tracking database: > Created By: sebor @ May 09, 2002 11:15:41 AM > The template __rw_new_capacity() uses floating point arithmetic which may be > less efficient than integer arithmetic on some architectures. Need to change > to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550775 ] Martin Sebor commented on STDCXX-226: - We still need to benchmark this before making any changes... Currently, we get the new capacity by multiplying the current value by an approximation of the Golden Ratio (http://en.wikipedia.org/wiki/Golden_ratio), or 1.618: z = x * 1.618 I suspect that the closest we'll be able to come to this value using integer operations without incurring a significant performance penalty is by multiplying the current value by 16 and dividing the result by 10. We can avoid the expensive division by 10 by approximating the operations using reciprocal multiplication as described below. I.e., like so: z = x << 4; z = ((z >> 1) + z) >> 1; z = ((z >> 4) + z); z = ((z >> 8) + z); z = ((z >> 16) + z) >> 3; http://www.cs.uiowa.edu/~jones/bcd/divide.html I put together a simple benchmark to compare the performance of the original algorithm to that of the new one. I also included the approach I describe here because it seems to produce results that are closer to the original. The benchmark shows that eliminating the FP operations yields a dramatic improvement (an order of magnitude or more) on all architectures (x86, IA64, PA-RISC, PowerPC, or SPARC) regardless of which of the two approaches we go with. The algorithm in your patch performs slightly better than the alternative here (between 10% and up to twice as fast, depending on the hardware architecture) but yields results that are considerably less accurate than the alternative (I haven't measured by how much). So unless you think the performance gain is more important, I think we should go with the alternative I presented here. > __rw::__rw_new_capacity() uses floating point math > -- > > Key: STDCXX-226 > URL: https://issues.apache.org/jira/browse/STDCXX-226 > Project: C++ Standard Library > Issue Type: Improvement > Components: 23. Containers >Affects Versions: 4.1.2, 4.1.3, 4.2.0 > Environment: all >Reporter: Martin Sebor >Assignee: Farid Zaripov > Fix For: 4.2.1 > > Attachments: new_capacity.patch > > > Moved from the Rogue Wave bug tracking database: > Created By: sebor @ May 09, 2002 11:15:41 AM > The template __rw_new_capacity() uses floating point arithmetic which may be > less efficient than integer arithmetic on some architectures. Need to change > to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-226: - Severity: Inefficiency Patch Info: [Patch Available] Affects Version/s: 4.2.0 Fix Version/s: 4.2.1 > __rw::__rw_new_capacity() uses floating point math > -- > > Key: STDCXX-226 > URL: https://issues.apache.org/jira/browse/STDCXX-226 > Project: C++ Standard Library > Issue Type: Improvement > Components: 23. Containers >Affects Versions: 4.1.2, 4.1.3, 4.2.0 > Environment: all >Reporter: Martin Sebor >Assignee: Farid Zaripov > Fix For: 4.2.1 > > Attachments: new_capacity.patch > > > Moved from the Rogue Wave bug tracking database: > Created By: sebor @ May 09, 2002 11:15:41 AM > The template __rw_new_capacity() uses floating point arithmetic which may be > less efficient than integer arithmetic on some architectures. Need to change > to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
