You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Farid Zaripov <Fa...@epam.com> on 2007/11/13 17:02:08 UTC

21.string.cons.cpp test fails on 64-bit MSVC (8.0 and 9.0)

  The 21.string.cons.cpp test fails with 16 assertions on 64-bit MSVC
(8.0 and 9.0).

 
http://people.apache.org/~sebor/stdcxx/results/win_xp_1-em64t-msvc-8.0.h
tml
 
http://people.apache.org/~sebor/stdcxx/results/win_2003_1-em64t-msvc-8.0
.html
 
http://people.apache.org/~sebor/stdcxx/results/win_vista_0-em64t-msvc-8.
0.html

  The reason is the bad code generation of the compiler. JIRA is not
available
at the moment, so I'll create the issue later. Unfortunately I cannot
make
the simple testcase to reproduce the problem. The problem detected only
in
optimized builds (8{s|d}, 12{s|d}). As the temporary workaround might be
definition of the __rw::__rw_new_capacity as __declspec (noinline).

  Also maybe this problem would be accidentally fixed thus resolving the
issue named something like "floating point operation in
__rw_new_capacity"
(I've seen this issue before).

------------------------------
Index: include/string
===================================================================
--- include/string	(revision 593511)
+++ include/string	(working copy)
@@ -1528,8 +1528,13 @@
 // more specialized version for basic_string<>; may be further
specialized
 // in user code for example on a user-defined allocator
 
+#if !defined (_WIN64) || !defined (_MSC_VER) || defined
(__INTEL_COMPILER)
 template <class _CharT, class _Traits, class _Allocator>
 inline _RWSTD_STRING_SIZE_TYPE
+#else    // _WIN64 && _MSC_VER && !__INTEL_COMPILER
+template <class _CharT, class _Traits, class _Allocator>
+__declspec (noinline) _RWSTD_STRING_SIZE_TYPE
+#endif   // !_WIN64 || !_MSC_VER || __INTEL_COMPILER
 __rw_new_capacity (_RWSTD_STRING_SIZE_TYPE __size,
                    const _STD::basic_string<_CharT, _Traits,
_Allocator>*)
 {
------------------------------
  
Farid.

RE: 21.string.cons.cpp test fails on 64-bit MSVC (8.0 and 9.0)

Posted by Martin Sebor <se...@roguewave.com>.

Farid Zaripov-2 wrote:
> 
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>> 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: 21.string.cons.cpp test fails on 64-bit MSVC (8.0 and 9.0)

Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com] 
> 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.

Re: 21.string.cons.cpp test fails on 64-bit MSVC (8.0 and 9.0)

Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>> Sent: Monday, November 19, 2007 7:37 AM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: 21.string.cons.cpp test fails on 64-bit MSVC 
>> (8.0 and 9.0)
>>
>>
>> I'm not sure outlining the function is the most efficient way 
>> to handle it.
>> Have you tried Travis's integer patch for STDCXX-226? (My 
>> comment about the efficiency of the new formula notwithstanding.)
> 
>   It was my patch :)

Sorry for the mis-attribution! :)

> 
>   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... :)

Martin


RE: 21.string.cons.cpp test fails on 64-bit MSVC (8.0 and 9.0)

Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com] 
> Sent: Monday, November 19, 2007 7:37 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: 21.string.cons.cpp test fails on 64-bit MSVC 
> (8.0 and 9.0)
> 
> 
> I'm not sure outlining the function is the most efficient way 
> to handle it.
> Have you tried Travis's integer patch for STDCXX-226? (My 
> comment about the efficiency of the new formula notwithstanding.)

  It was my patch :)

  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;").

Farid.

Re: 21.string.cons.cpp test fails on 64-bit MSVC (8.0 and 9.0)

Posted by Martin Sebor <se...@roguewave.com>.
I'm not sure outlining the function is the most efficient way to handle it.
Have you tried Travis's integer patch for STDCXX-226? (My comment
about the efficiency of the new formula notwithstanding.)

Martin


Farid Zaripov-2 wrote:
> 
>   The 21.string.cons.cpp test fails with 16 assertions on 64-bit MSVC
> (8.0 and 9.0).
> 
>  
> http://people.apache.org/~sebor/stdcxx/results/win_xp_1-em64t-msvc-8.0.h
> tml
>  
> http://people.apache.org/~sebor/stdcxx/results/win_2003_1-em64t-msvc-8.0
> .html
>  
> http://people.apache.org/~sebor/stdcxx/results/win_vista_0-em64t-msvc-8.
> 0.html
> 
>   The reason is the bad code generation of the compiler. JIRA is not
> available
> at the moment, so I'll create the issue later. Unfortunately I cannot
> make
> the simple testcase to reproduce the problem. The problem detected only
> in
> optimized builds (8{s|d}, 12{s|d}). As the temporary workaround might be
> definition of the __rw::__rw_new_capacity as __declspec (noinline).
> 
>   Also maybe this problem would be accidentally fixed thus resolving the
> issue named something like "floating point operation in
> __rw_new_capacity"
> (I've seen this issue before).
> 
> ------------------------------
> Index: include/string
> ===================================================================
> --- include/string	(revision 593511)
> +++ include/string	(working copy)
> @@ -1528,8 +1528,13 @@
>  // more specialized version for basic_string<>; may be further
> specialized
>  // in user code for example on a user-defined allocator
>  
> +#if !defined (_WIN64) || !defined (_MSC_VER) || defined
> (__INTEL_COMPILER)
>  template <class _CharT, class _Traits, class _Allocator>
>  inline _RWSTD_STRING_SIZE_TYPE
> +#else    // _WIN64 && _MSC_VER && !__INTEL_COMPILER
> +template <class _CharT, class _Traits, class _Allocator>
> +__declspec (noinline) _RWSTD_STRING_SIZE_TYPE
> +#endif   // !_WIN64 || !_MSC_VER || __INTEL_COMPILER
>  __rw_new_capacity (_RWSTD_STRING_SIZE_TYPE __size,
>                     const _STD::basic_string<_CharT, _Traits,
> _Allocator>*)
>  {
> ------------------------------
>   
> Farid.
> 
> 

-- 
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-tf4798813.html#a13828136
Sent from the stdcxx-dev mailing list archive at Nabble.com.