[jira] Created: (STDCXX-677) IBM XLC++ 9.0/AIX 5.3] tr1/cstdint limit macros incompatible with system provided C headers
IBM XLC++ 9.0/AIX 5.3] tr1/cstdint limit macros incompatible with system provided C headers --- Key: STDCXX-677 URL: https://issues.apache.org/jira/browse/STDCXX-677 Project: C++ Standard Library Issue Type: Bug Components: TR1.8 - C Compatibility Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Travis Vitek Fix For: 4.2.1 The following testcase fails to compile because both the C library stdint.h and our tr1/cstdint headers define defines the C99 limit macros. It looks like we need to avoid defining the macros if a previous definition already exists. Is that a sufficient solution? What if our defintion is different for some reason? $ cat u.cpp && gmake u #include #include xlCcore -c -I/amd/devco/vitek/stdcxx/trunk/include/ansi -D_RWSTDDEBUG -I/amd/devco/vitek/stdcxx/trunk/include -I/build/vitek/11s/include -I/amd/devco/vitek/stdcxx/trunk/tests/include -g -qtemplateregistry=u.ti u.cpp "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 56.11: 1540-0848 (S) The macro name "INT8_MAX" is already defined with a different definition. "/usr/include/stdint.h", line 142.9: 1540-0425 (I) "INT8_MAX" is defined on line 142 of "/usr/include/stdint.h". "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 57.11: 1540-0848 (S) The macro name "UINT8_MAX" is already defined with a different definition. "/usr/include/stdint.h", line 149.9: 1540-0425 (I) "UINT8_MAX" is defined on line 149 of "/usr/include/stdint.h". "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 116.11: 1540-0848 (S) The macro name "INT16_MAX" is already defined with a different definition. "/usr/include/stdint.h", line 143.9: 1540-0425 (I) "INT16_MAX" is defined on line 143 of "/usr/include/stdint.h". "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 117.11: 1540-0848 (S) The macro name "UINT16_MAX" is already defined with a different definition. "/usr/include/stdint.h", line 150.9: 1540-0425 (I) "UINT16_MAX" is defined on line 150 of "/usr/include/stdint.h". "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 171.13: 1540-0848 (S) The macro name "INT32_MAX" is already defined with a different definition. "/usr/include/stdint.h", line 144.9: 1540-0425 (I) "INT32_MAX" is defined on line 144 of "/usr/include/stdint.h". "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 172.13: 1540-0848 (S) The macro name "UINT32_MAX" is already defined with a different definition. "/usr/include/stdint.h", line 151.9: 1540-0425 (I) "UINT32_MAX" is defined on line 151 of "/usr/include/stdint.h". "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 225.13: 1540-0848 (S) The macro name "INT64_MAX" is already defined with a different definition. "/usr/include/stdint.h", line 146.9: 1540-0425 (I) "INT64_MAX" is defined on line 146 of "/usr/include/stdint.h". "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 226.13: 1540-0848 (S) The macro name "UINT64_MAX" is already defined with a different definition. "/usr/include/stdint.h", line 153.9: 1540-0425 (I) "UINT64_MAX" is defined on line 153 of "/usr/include/stdint.h". "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 323.9: 1540-0848 (S) The macro name "PTRDIFF_MIN" is already defined with a different definition. "/usr/include/stdint.h", line 222.9: 1540-0425 (I) "PTRDIFF_MIN" is defined on line 222 of "/usr/include/stdint.h". "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 324.9: 1540-0848 (S) The macro name "PTRDIFF_MAX" is already defined with a different definition. "/usr/include/stdint.h", line 223.9: 1540-0425 (I) "PTRDIFF_MAX" is defined on line 223 of "/usr/include/stdint.h". "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 326.9: 1540-0848 (S) The macro name "SIZE_MAX" is already defined with a different definition. "/usr/include/stdint.h", line 246.9: 1540-0425 (I) "SIZE_MAX" is defined on line 246 of "/usr/include/stdint.h". "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 328.9: 1540-0848 (S) The macro name "WCHAR_MIN" is already defined with a different definition. "/usr/include/stdint.h", line 236.9: 1540-0425 (I) "WCHAR_MIN" is defined on line 236 of "/usr/include/stdint.h". "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 329.9: 1540-0848 (S) The macro name "WCHAR_MAX" is already defined with a different definition. "/usr/include/stdint.h", line 234.9: 1540-0425 (I) "WCHAR_MAX" is defined on line 234 of "/usr/include/stdint.h". "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 331.9: 1540-0848 (S) The macro name "WINT_MIN" is already defined with a different definition. "/usr/include/stdint.h", line 239.9: 1540-0425 (I) "WINT_MIN" is defined on line 239 of "/usr/include/stdint.h". "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 332.9: 1540-0848 (S) T
[jira] Updated: (STDCXX-677) [IBM XLC++ 9.0/AIX 5.3] tr1/cstdint limit macros incompatible with system provided C headers
[ https://issues.apache.org/jira/browse/STDCXX-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-677: Summary: [IBM XLC++ 9.0/AIX 5.3] tr1/cstdint limit macros incompatible with system provided C headers (was: IBM XLC++ 9.0/AIX 5.3] tr1/cstdint limit macros incompatible with system provided C headers) > [IBM XLC++ 9.0/AIX 5.3] tr1/cstdint limit macros incompatible with system > provided C headers > > > Key: STDCXX-677 > URL: https://issues.apache.org/jira/browse/STDCXX-677 > Project: C++ Standard Library > Issue Type: Bug > Components: TR1.8 - C Compatibility >Affects Versions: 4.2.0 >Reporter: Travis Vitek >Assignee: Travis Vitek > Fix For: 4.2.1 > > > The following testcase fails to compile because both the C library stdint.h > and our tr1/cstdint headers define defines the C99 limit macros. It looks > like we need to avoid defining the macros if a previous definition already > exists. Is that a sufficient solution? What if our defintion is different for > some reason? > $ cat u.cpp && gmake u > #include > #include > xlCcore -c -I/amd/devco/vitek/stdcxx/trunk/include/ansi -D_RWSTDDEBUG > -I/amd/devco/vitek/stdcxx/trunk/include -I/build/vitek/11s/include > -I/amd/devco/vitek/stdcxx/trunk/tests/include -g -qtemplateregistry=u.ti > u.cpp > "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 56.11: 1540-0848 > (S) The macro name "INT8_MAX" is already defined with a different definition. > "/usr/include/stdint.h", line 142.9: 1540-0425 (I) "INT8_MAX" is defined on > line 142 of "/usr/include/stdint.h". > "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 57.11: 1540-0848 > (S) The macro name "UINT8_MAX" is already defined with a different definition. > "/usr/include/stdint.h", line 149.9: 1540-0425 (I) "UINT8_MAX" is defined on > line 149 of "/usr/include/stdint.h". > "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 116.11: 1540-0848 > (S) The macro name "INT16_MAX" is already defined with a different definition. > "/usr/include/stdint.h", line 143.9: 1540-0425 (I) "INT16_MAX" is defined on > line 143 of "/usr/include/stdint.h". > "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 117.11: 1540-0848 > (S) The macro name "UINT16_MAX" is already defined with a different > definition. > "/usr/include/stdint.h", line 150.9: 1540-0425 (I) "UINT16_MAX" is defined on > line 150 of "/usr/include/stdint.h". > "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 171.13: 1540-0848 > (S) The macro name "INT32_MAX" is already defined with a different definition. > "/usr/include/stdint.h", line 144.9: 1540-0425 (I) "INT32_MAX" is defined on > line 144 of "/usr/include/stdint.h". > "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 172.13: 1540-0848 > (S) The macro name "UINT32_MAX" is already defined with a different > definition. > "/usr/include/stdint.h", line 151.9: 1540-0425 (I) "UINT32_MAX" is defined on > line 151 of "/usr/include/stdint.h". > "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 225.13: 1540-0848 > (S) The macro name "INT64_MAX" is already defined with a different definition. > "/usr/include/stdint.h", line 146.9: 1540-0425 (I) "INT64_MAX" is defined on > line 146 of "/usr/include/stdint.h". > "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 226.13: 1540-0848 > (S) The macro name "UINT64_MAX" is already defined with a different > definition. > "/usr/include/stdint.h", line 153.9: 1540-0425 (I) "UINT64_MAX" is defined on > line 153 of "/usr/include/stdint.h". > "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 323.9: 1540-0848 > (S) The macro name "PTRDIFF_MIN" is already defined with a different > definition. > "/usr/include/stdint.h", line 222.9: 1540-0425 (I) "PTRDIFF_MIN" is defined > on line 222 of "/usr/include/stdint.h". > "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 324.9: 1540-0848 > (S) The macro name "PTRDIFF_MAX" is already defined with a different > definition. > "/usr/include/stdint.h", line 223.9: 1540-0425 (I) "PTRDIFF_MAX" is defined > on line 223 of "/usr/include/stdint.h". > "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 326.9: 1540-0848 > (S) The macro name "SIZE_MAX" is already defined with a different definition. > "/usr/include/stdint.h", line 246.9: 1540-0425 (I) "SIZE_MAX" is defined on > line 246 of "/usr/include/stdint.h". > "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 328.9: 1540-0848 > (S) The macro name "WCHAR_MIN" is already defined with a different definition. > "/usr/include/stdint.h", line 236.9: 1540-0425 (I) "WCHAR_MIN" is defined on > line 236 of "/usr/include/stdint.h". > "/amd/devco/vitek/stdcxx/trunk/include/tr1/cstdint", line 3
[jira] Updated: (STDCXX-343) [LWG #541] std::auto_ptr specialization missing
[
https://issues.apache.org/jira/browse/STDCXX-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Vitek updated STDCXX-343:
Fix Version/s: (was: 4.2.1)
4.3
Reassigning to 4.3. We shouldn't fix this before then.
> [LWG #541] std::auto_ptr specialization missing
> -
>
> Key: STDCXX-343
> URL: https://issues.apache.org/jira/browse/STDCXX-343
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: 20. General Utilities
>Affects Versions: 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Assignee: Travis Vitek
> Fix For: 4.3
>
>
> The resolution of issue 541 adds an explicit specialization for
> std::auto_ptr with the following definition:
> template<> class auto_ptr
> {
> public:
> typedef void element_type;
> };
> See http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541
> This needs to be implemented (since otherwise the specialization has
> undefined behavior -- see STDCXX-172).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (STDCXX-343) [LWG #541] std::auto_ptr specialization missing
[
https://issues.apache.org/jira/browse/STDCXX-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548882
]
vitek edited comment on STDCXX-343 at 12/5/07 3:47 PM:
--
Rescheduled for 4.3. We shouldn't fix this before then.
was (Author: vitek):
Reassigning to 4.3. We shouldn't fix this before then.
> [LWG #541] std::auto_ptr specialization missing
> -
>
> Key: STDCXX-343
> URL: https://issues.apache.org/jira/browse/STDCXX-343
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: 20. General Utilities
>Affects Versions: 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Assignee: Travis Vitek
> Fix For: 4.3
>
>
> The resolution of issue 541 adds an explicit specialization for
> std::auto_ptr with the following definition:
> template<> class auto_ptr
> {
> public:
> typedef void element_type;
> };
> See http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541
> This needs to be implemented (since otherwise the specialization has
> undefined behavior -- see STDCXX-172).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-343) [LWG #541] std::auto_ptr specialization missing
[
https://issues.apache.org/jira/browse/STDCXX-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548880
]
Travis Vitek commented on STDCXX-343:
-
This is a source incompatible change. Technically this should be rescheduled
for 5.0. Discussion on this particular bug can be found here
http://www.nabble.com/forum/ViewPost.jtp?post=13986319&framed=y
> [LWG #541] std::auto_ptr specialization missing
> -
>
> Key: STDCXX-343
> URL: https://issues.apache.org/jira/browse/STDCXX-343
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: 20. General Utilities
>Affects Versions: 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
>
> The resolution of issue 541 adds an explicit specialization for
> std::auto_ptr with the following definition:
> template<> class auto_ptr
> {
> public:
> typedef void element_type;
> };
> See http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541
> This needs to be implemented (since otherwise the specialization has
> undefined behavior -- see STDCXX-172).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-223) [Windows] std::time_put %c time format specifier not implemented
[
https://issues.apache.org/jira/browse/STDCXX-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Vitek closed STDCXX-223.
---
> [Windows] std::time_put %c time format specifier not implemented
>
>
> Key: STDCXX-223
> URL: https://issues.apache.org/jira/browse/STDCXX-223
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: Windows
>Reporter: Martin Sebor
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
>
> Moved from the Rogue Wave bug tracking database:
> Created By: sebor @ Apr 29, 2003 01:34:21 PM
> Original Message
> Subject: puzzle
> Date: Tue, 22 Apr 2003 12:31:46 -0600
> From: "L. Nicoara" <[EMAIL PROTECTED]>
> To: Martin Sebor <[EMAIL PROTECTED]>
> This program prints A - Windows, VC7 (also 15d). Is there anything
> obviously wrong with it?
> Liviu
> #include
> #include
> #include
> #include
> int main ()
> {
> const char* fmt = "%c";
> tm t = tm ();
> t.tm_sec = 0;
> t.tm_min = 0;
> t.tm_hour = 0;
> t.tm_mday = 13;
> t.tm_mon = 8;
> t.tm_year = 67;
> t.tm_wday = 3;
> t.tm_isdst = 0;
> typedef std::ostreambuf_iterator iter_t;
> std::locale loc ("C");
> std::ostringstream os;
> iter_t os_iter(os.rdbuf ());
> const std::time_put& fac =
> std::use_facet >(loc);
> fac.put(os_iter,os,os.fill(), &t, fmt, fmt + std::strlen (fmt));
> std::cout << "Date-time : " << os.str().c_str () << std::endl;
> return 0;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-676) [MSVC] 22.locale.time.put test fails
[ https://issues.apache.org/jira/browse/STDCXX-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-676: Attachment: stdcxx-223.patch New patch includes discussed changes. 2007-12-05 Travis Vitek <[EMAIL PROTECTED]> STDCXX-676 * tests/locale/22.locale.time.put.cpp [_MSC_VER] (rw_strftime): Avoid passing unsupported format specifiers to strftime(). > [MSVC] 22.locale.time.put test fails > > > Key: STDCXX-676 > URL: https://issues.apache.org/jira/browse/STDCXX-676 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 >Reporter: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-223.patch > > > In my manual runs I have noticed that the test fails because the MSCRT > strftime doesn't support %T, %e, or %G and asserts internally. This doesn't > appear to happen on all configurations because these tests are running to > completion on some of the nightly builds. > I think the rw_strftime() that is inside the test could be expanded to avoid > the assert inside the CRT so that the test would pass on all windows > configurations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-676) [MSVC] 22.locale.time.put test fails
[ https://issues.apache.org/jira/browse/STDCXX-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-676: Attachment: (was: stdcxx-223.patch) > [MSVC] 22.locale.time.put test fails > > > Key: STDCXX-676 > URL: https://issues.apache.org/jira/browse/STDCXX-676 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 >Reporter: Travis Vitek > Fix For: 4.2.1 > > > In my manual runs I have noticed that the test fails because the MSCRT > strftime doesn't support %T, %e, or %G and asserts internally. This doesn't > appear to happen on all configurations because these tests are running to > completion on some of the nightly builds. > I think the rw_strftime() that is inside the test could be expanded to avoid > the assert inside the CRT so that the test would pass on all windows > configurations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-443) [IBM XLC++] should avoid using -qinline or -Q in C++ code
[ https://issues.apache.org/jira/browse/STDCXX-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548755 ] Travis Vitek commented on STDCXX-443: - I've done 12d builds [one with -O and the other with -O -Q]. The library is smaller and executables are _usually_ smaller with just -O [as expected because of less inlining]. Do we want to run some sort of performance benchmark to decide what we should do, or do we just want to follow the documentation? -O -O -Q File Name 1826061 1841108 libstd12d.so.4.2.0 31994 32286 search 39317 39281 set_diff 38813 38835 set_intr 39945 39909 set_sym_diff 39983 39947 set_union 60225 60459 setex 30370 30439 sieve 24177 24147 slice 27590 27856 slice_array 50960 52112 sort 77747 78013 spell 63653 63970 stack 24598 24620 stdexcept 84276 85530 stocks 33127 45083 stream_iterator 26953 27219 string 41160 41400 stringbuf 40945 41211 strstream 42568 42564 strstreambuf 32063 32360 swap > [IBM XLC++] should avoid using -qinline or -Q in C++ code > - > > Key: STDCXX-443 > URL: https://issues.apache.org/jira/browse/STDCXX-443 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.3 > Environment: IBM VisualAge C++ 6.0, 7.0, and XLC++ 8.0 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > > Quoting from the XLC++ 8.0 Compiler Reference, page 249 (-Q option): > To maximize inlining: > * for C programs, specify optimization (-O) and also specify the appropriate > -Q options for the C language. > * for C++ programs, specify optimization (-O) but do not specify the -Q > option. > We should review whether our use of -Q in optimized builds is called for. -- 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_12548746
]
Travis Vitek commented on STDCXX-673:
-
I believe that the proposed patch is sufficient, but I'm curious why we need
the logic at all. We could just write the following
printf ("#define _RWSTD_INT%d_T %s signed %s\n" \
"#define _RWSTD_UINT%d_T %s unsigned %s\n", \
width, width < 10 ? " " : "", type, \
width, width < 10 ? " " : "", type); \
That way the type is always declared as signed. Leaving the type as `char' in
any case seems like a bad idea. The actual underlying type is ambiguous from a
readers perspective, and can change if the user compiles their code with with
`-qchars='. It is quite possible that doing such a thing after
configuration time would cause other failures, but it is possible that it would
work also.
> [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
>
>
> 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] Assigned: (STDCXX-666) [MSVC 8-x64] 21.string.cons.cpp test fails in optimized builds due to bad codegeneration by the compiler
[
https://issues.apache.org/jira/browse/STDCXX-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-666:
Assignee: Farid Zaripov
> [MSVC 8-x64] 21.string.cons.cpp test fails in optimized builds due to bad
> codegeneration by the compiler
>
>
> Key: STDCXX-666
> URL: https://issues.apache.org/jira/browse/STDCXX-666
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2.0
> Environment: MSVC 8.0-x64, builds 8{d|s}, 12{d|s}
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2.1
>
>
> The 21.string.cons.cpp test fails with 16 assertions on 64-bit MSVC in
> optimized builds.
> The reason is the bad codegeneration in __rw_new_capacity() inlined in
> std::basic_string ctors. Because of this bug the __rw_new_capacity(0, const
> std::basic_string<> *) returns value greater that size_max() and ctor throws
> exception.
> The temporary workaround might be definition of the __rw_new_capacity() as
> __declspec (noinline).
> --
> 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 inline
> _RWSTD_STRING_SIZE_TYPE
> +#else// _WIN64 && _MSC_VER && !__INTEL_COMPILER
> +template __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>*)
> {
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-663) [MSVC] MSVC declares non-standard prototype of the wcstok()
[ https://issues.apache.org/jira/browse/STDCXX-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-663. > [MSVC] MSVC declares non-standard prototype of the wcstok() > --- > > Key: STDCXX-663 > URL: https://issues.apache.org/jira/browse/STDCXX-663 > Project: C++ Standard Library > Issue Type: Bug > Components: External > Environment: MSVC, ICC/Windows >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > Attachments: wcstok.patch > > > The MSVC declares non-standard prototype of the wcstok(): > wchar.h: > --- > _CRTIMP wchar_t * __cdecl wcstok(wchar_t *, const wchar_t *); > --- > Since configuration script doesn't check the correct prototype and checks > only for name, the config.h file contains _RWSTD_NO_WCSTOK macro undefined. > The MSVC 8 and higher declares wcstok_s() which is identical to standard > wcstok(): > wchar.h: > --- > _CRTIMP_ALTERNATIVE __checkReturn wchar_t * __cdecl wcstok_s(__inout_z_opt > wchar_t * _Str, __in_z const wchar_t * _Delim, __deref_inout_z_opt wchar_t ** > _Context); > --- > I think we need to #define _RWSTD_NO_WCSTOK macro in > include/rw/_config_msvcrt.h and add inline wcstok() invoking wcstok_s() in > include /ansi/cwchar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-663) [MSVC] MSVC declares non-standard prototype of the wcstok()
[ https://issues.apache.org/jira/browse/STDCXX-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-663. -- Resolution: Fixed Fixed thus: http://svn.apache.org/viewvc?view=rev&revision=597411 Merged in thunk thus: http://svn.apache.org/viewvc?view=rev&revision=597412 > [MSVC] MSVC declares non-standard prototype of the wcstok() > --- > > Key: STDCXX-663 > URL: https://issues.apache.org/jira/browse/STDCXX-663 > Project: C++ Standard Library > Issue Type: Bug > Components: External > Environment: MSVC, ICC/Windows >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > Attachments: wcstok.patch > > > The MSVC declares non-standard prototype of the wcstok(): > wchar.h: > --- > _CRTIMP wchar_t * __cdecl wcstok(wchar_t *, const wchar_t *); > --- > Since configuration script doesn't check the correct prototype and checks > only for name, the config.h file contains _RWSTD_NO_WCSTOK macro undefined. > The MSVC 8 and higher declares wcstok_s() which is identical to standard > wcstok(): > wchar.h: > --- > _CRTIMP_ALTERNATIVE __checkReturn wchar_t * __cdecl wcstok_s(__inout_z_opt > wchar_t * _Str, __in_z const wchar_t * _Delim, __deref_inout_z_opt wchar_t ** > _Context); > --- > I think we need to #define _RWSTD_NO_WCSTOK macro in > include/rw/_config_msvcrt.h and add inline wcstok() invoking wcstok_s() in > include /ansi/cwchar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
