[jira] Commented: (STDCXX-665) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
[ https://issues.apache.org/jira/browse/STDCXX-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559330#action_12559330 ] Travis Vitek commented on STDCXX-665: - Question posted to IBM forums http://www-128.ibm.com/developerworks/forums/thread.jspa?messageID=14035619&; > [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions > > > Key: STDCXX-665 > URL: https://issues.apache.org/jira/browse/STDCXX-665 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 >Reporter: Travis Vitek >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-665.patch > > > Currently only single threaded builds show this problem > NAME STATUS WARN ASSERTS FAILED PERCNTUSER > SYSREAL > 22.locale.messages 00 26810660% 0.090 > 0.640 3.960 -- 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-665) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
[
https://issues.apache.org/jira/browse/STDCXX-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559237#action_12559237
]
vitek edited comment on STDCXX-665 at 1/15/08 3:34 PM:
--
Yeah, if I would have looked I would have seen __rw_setlocale. This does make
me feel a little better about option (4). This change would allow us to
successfully open a message catalog when the locale provided to
std::messages::open() was not the C/POSIX locale. Any proposal for what we
would do if this is not the case? Maybe just fail?
Here is a test that I believe would fail the second assert because AIX requires
LC_MESSAGES to be set to something other than "C".
const std::locale classic (std::locale::classic ());
const std::locale en_US ("en_US");
const std::messages& m = std::use_facet >(classic);
// this would work because we would call setlocale (LC_MESSAGES, "en_US")
// internally
std::messages_base::catalog c1 = m.open ("catalog", en_US);
assert (! (c1 < 0));
m.close (c1);
// this would not work because we would call setlocale (LC_MESSAGES, "C")
// internally, and the NLSPATH lookup is disabled
std::messages_base::catalog c2 = m.open ("catalog", classic);
assert (! (c2 < 0));
m.close (c2);
In that case, I feel like I should use all of 1, 2 and 4.
was (Author: vitek):
Yeah, if I would have looked I would have seen __rw_setlocale. While does
make me feel better about option (4). This change would allow us to
successfully open a message catalog when the locale provided to
std::messages::open() was not the C/POSIX locale. Any proposal for what we
would do for this case? Maybe just fail?
const std::locale classic (std::locale::classic ());
const std::locale en_US ("en_US");
const std::messages& m = std::use_facet >(classic);
// this would work because we would call setlocale (LC_MESSAGES, "en_US")
// internally
std::messages_base::catalog c1 = m.open ("catalog", en_US);
assert (0 < c1);
m.close (c1);
// this would not work because we would call setlocale (LC_MESSAGES, "C")
// internally, and the NLSPATH lookup is disabled
std::messages_base::catalog c2 = m.open ("catalog", classic);
assert (0 < c2);
m.close (c2);
In that case, I feel like I should use all of 1, 2 and 4.
> [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
>
>
> Key: STDCXX-665
> URL: https://issues.apache.org/jira/browse/STDCXX-665
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2.0
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: stdcxx-665.patch
>
>
> Currently only single threaded builds show this problem
> NAME STATUS WARN ASSERTS FAILED PERCNTUSER
> SYSREAL
> 22.locale.messages 00 26810660% 0.090
> 0.640 3.960
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-665) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
[
https://issues.apache.org/jira/browse/STDCXX-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559237#action_12559237
]
Travis Vitek commented on STDCXX-665:
-
Yeah, if I would have looked I would have seen __rw_setlocale. While does make
me feel better about option (4). This change would allow us to successfully
open a message catalog when the locale provided to std::messages::open() was
not the C/POSIX locale. Any proposal for what we would do for this case? Maybe
just fail?
const std::locale classic (std::locale::classic ());
const std::locale en_US ("en_US");
const std::messages& m = std::use_facet >(classic);
// this would work because we would call setlocale (LC_MESSAGES, "en_US")
// internally
std::messages_base::catalog c1 = m.open ("catalog", en_US);
assert (0 < c1);
m.close (c1);
// this would not work because we would call setlocale (LC_MESSAGES, "C")
// internally, and the NLSPATH lookup is disabled
std::messages_base::catalog c2 = m.open ("catalog", classic);
assert (0 < c2);
m.close (c2);
In that case, I feel like I should use all of 1, 2 and 4.
> [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
>
>
> Key: STDCXX-665
> URL: https://issues.apache.org/jira/browse/STDCXX-665
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2.0
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: stdcxx-665.patch
>
>
> Currently only single threaded builds show this problem
> NAME STATUS WARN ASSERTS FAILED PERCNTUSER
> SYSREAL
> 22.locale.messages 00 26810660% 0.090
> 0.640 3.960
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-231) std::getline from header is rather slow
[
https://issues.apache.org/jira/browse/STDCXX-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Vitek reassigned STDCXX-231:
---
Assignee: Travis Vitek
> std::getline from header is rather slow
>
>
> Key: STDCXX-231
> URL: https://issues.apache.org/jira/browse/STDCXX-231
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: 21. Strings
>Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
>Reporter: Martin Sebor
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
>
> Moved from the Rogue Wave bug tracking database:
> Created By: leroy @ Jan 25, 2001 03:20:01 PM
> Environment
> Compiler : SUNPRO 4.2
> OS : Solaris 2.5.1
> SCL : 1.3.0 (Summer-1999)
> Tools : 7.1.0 (Summer-1999) --> Use only for RWBench
> Command line option :
> for debug :
> CC -xildoff +w +p -g -o Test_dbg.exe test.cc -DRWDEBUG=1
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/11s
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/11s/include -I.
> -L/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/11s/lib -Bstatic
> -ltls11s -lstd11s -Bdynamic
> for release :
> CC -xildoff +w +p -fast -o Test_release.exe test.cc
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/8s
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/8s/include -I.
> -L/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/8s/lib -Bstatic
> -ltls8s -lstd8s -Bdynamic
> (Uploaded file: 997149-test.cc)
>
>
>
>
>
> Entered By: Web @ Thursday, January 25, 2001 2:41:42 AM
> Location of uploaded file:
> http://thoth.bco.roguewave.com/uploads/997149-test.cc
> View all uploaded files for this incident:
> http://webdev.roguewave.com/admin/tsvw/index.cfm?IncidentID=997149
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Entered By: Web @ Thursday, January 25, 2001 2:44:56 AM
> #web
> Please find my test case at the end of the note
> Environment
> Compiler : SUNPRO 4.2
> OS : Solaris 2.5.1
> SCL : 1.3.0 (Summer-1999)
> Tools : 7.1.0 (Summer-1999) --> Use only for RWBench
> Command line option :
> for debug :
> CC -xildoff +w +p -g -o Test_dbg.exe test.cc -DRWDEBUG=1
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/11s
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/11s/include -I.
> -L/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/11s/lib -Bstatic
> -ltls11s -lstd11s -Bdynamic
> for release :
> CC -xildoff +w +p -fast -o Test_release.exe test.cc
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/8s
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/8s/include -I.
> -L/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/8s/lib -Bstatic
> -ltls8s -lstd8s -Bdynamic
> #Code
> #include
> #include
> #include
> #include
>
>
> class std_string_getline : public RWBench
> {
> public:
>std_string_getline() {;}
>
>void doLoop(unsigned long n);
>void idleLoop(unsigned long n);
>void what(ostream& os) const { os << "Standard String Getline : " << endl;}
> };
>
> class classic_getline : public RWBench
> {
> public:
> classic_getline() {;}
>
> void doLoop(unsigned long n);
> void idleLoop(unsigned long n);
> void what(ostream& os) const { os << "Classic Getline : " << endl;}
> };
>
> in
[jira] Updated: (STDCXX-665) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
[ https://issues.apache.org/jira/browse/STDCXX-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-665: Attachment: stdcxx-665.patch Simplified patch a little. I now use the locale returned by find_named_locale() instead of trying to find one on my own. > [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions > > > Key: STDCXX-665 > URL: https://issues.apache.org/jira/browse/STDCXX-665 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 >Reporter: Travis Vitek >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-665.patch > > > Currently only single threaded builds show this problem > NAME STATUS WARN ASSERTS FAILED PERCNTUSER > SYSREAL > 22.locale.messages 00 26810660% 0.090 > 0.640 3.960 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-665) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
[ https://issues.apache.org/jira/browse/STDCXX-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-665: Attachment: (was: stdcxx-665.patch) > [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions > > > Key: STDCXX-665 > URL: https://issues.apache.org/jira/browse/STDCXX-665 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 >Reporter: Travis Vitek >Assignee: Travis Vitek > Fix For: 4.2.1 > > > Currently only single threaded builds show this problem > NAME STATUS WARN ASSERTS FAILED PERCNTUSER > SYSREAL > 22.locale.messages 00 26810660% 0.090 > 0.640 3.960 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-665) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
[ https://issues.apache.org/jira/browse/STDCXX-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-665: Attachment: stdcxx-665.patch A slightly modified version of the above testcase exposed the answer, but the behavior is still inconsistent with the AIX documentation for catopen(). The documentation says "The NLSPATH environment variable defines the directory search path. When this variable is used, the setlocale subroutine must be called before the catopen subroutine." I found that adding a call to setlocale(LC_ALL, "C") in there isn't enough, and it won't work. You have to set the locale to some non-classic locale. It doesn't really matter which one you use, but it is required that he locale be set to something other than "C". So now the question is what do I do about this? The options I see are... 1. add a note to the documentation mentioning the limitation. 2. work around the issue and call setlocale() in the test with some known locale on AIX. 3. add an expected failure for this test. 4. modify the messages::open() function to temporarily set the locale so that the call will have a chance of succeeding? I think option 4 is totally out. It would not be thread safe, and selecting an appropriate locale could be problematic. I don't really like option 3 all that much either, because there is no way to indicate that we expect two assertion failures, and we have no way to tag those specific failures. This could potentially hide regressions. So that leaves me with options 1 and 2, or some combination of them. I'm attaching a patch for review. It doesn't include any documentation changes. If it is determined that a documentation change is necessary, I'll update the patch for that. > [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions > > > Key: STDCXX-665 > URL: https://issues.apache.org/jira/browse/STDCXX-665 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 >Reporter: Travis Vitek >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-665.patch > > > Currently only single threaded builds show this problem > NAME STATUS WARN ASSERTS FAILED PERCNTUSER > SYSREAL > 22.locale.messages 00 26810660% 0.090 > 0.640 3.960 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-622) valarray operator requirements not consistent with standard
[ https://issues.apache.org/jira/browse/STDCXX-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek closed STDCXX-622. --- Resolution: Duplicate > valarray operator requirements not consistent with standard > --- > > Key: STDCXX-622 > URL: https://issues.apache.org/jira/browse/STDCXX-622 > Project: C++ Standard Library > Issue Type: Bug > Components: 26. Numerics >Affects Versions: 4.2.0 >Reporter: Travis Vitek >Assignee: Travis Vitek >Priority: Minor > Fix For: 4.2.1 > > > 26.3.2.6 p1 says > Each of these operators may only be instantiated for a type T to which the > indicated operator can be > applied. Each of these operators performs the indicated operation on each of > its elements and the corresponding > element of the argument array. [for operators *=, /=, %=, +=, -=, ^=, &=, |=, > <<= and >>=] > The current implementation of the valarray member operators violate these > requirements. Internally they use the transform algorithm with one of the > function adapters [i.e. multiplies, divides]. So valarray::operator+=() > will use T::operator+() and T::operator=() when it should be using > T::operator+=(). As a direct result of this, the 26.valarray.cassign test > fails to compile on all platforms. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-577) purify reports leaked memory in stocks example
[ https://issues.apache.org/jira/browse/STDCXX-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek resolved STDCXX-577. - Resolution: Fixed > purify reports leaked memory in stocks example > --- > > Key: STDCXX-577 > URL: https://issues.apache.org/jira/browse/STDCXX-577 > Project: C++ Standard Library > Issue Type: Improvement > Components: Examples >Affects Versions: 4.2.0 >Reporter: Travis Vitek >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-577.patch, stocks-valgrind.log, stocks.log > > > It is pretty obvious from looking at the source that memory is being leaked. > The destructor for StockXchange doesn't deallocate memory allocated in > StockXchange::add(), and the sl_pairs allocated in main are never deallocated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-577) purify reports leaked memory in stocks example
[ https://issues.apache.org/jira/browse/STDCXX-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558138#action_12558138 ] Travis Vitek commented on STDCXX-577: - Committed to trunk in http://svn.apache.org/viewvc?view=rev&revision=611307 Merged to 4.2.x in http://svn.apache.org/viewvc?view=rev&revision=611308 > purify reports leaked memory in stocks example > --- > > Key: STDCXX-577 > URL: https://issues.apache.org/jira/browse/STDCXX-577 > Project: C++ Standard Library > Issue Type: Improvement > Components: Examples >Affects Versions: 4.2.0 >Reporter: Travis Vitek >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-577.patch, stocks-valgrind.log, stocks.log > > > It is pretty obvious from looking at the source that memory is being leaked. > The destructor for StockXchange doesn't deallocate memory allocated in > StockXchange::add(), and the sl_pairs allocated in main are never deallocated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek closed STDCXX-605. --- Resolution: Fixed Verified in nightly testing. > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-605-out.patch, stdcxx-605-v1.patch, > stdcxx-605-v2.patch, stdcxx-605-v3.patch > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-693) std::valarray::sum does not work correctly for udt that has nonzero default value
[
https://issues.apache.org/jira/browse/STDCXX-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557927#action_12557927
]
Travis Vitek commented on STDCXX-693:
-
Yes, I like that solution also. I've already done this for most of
for STDCXX-622 [which, I just noticed, appears to be a duplicate of STDCXX-512].
> std::valarray::sum does not work correctly for udt that has nonzero default
> value
> -
>
> Key: STDCXX-693
> URL: https://issues.apache.org/jira/browse/STDCXX-693
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 26. Numerics
>Affects Versions: 4.2.0
>Reporter: Travis Vitek
>Priority: Minor
>
> #include
> #include
> struct S
> {
> // this ctor should not be required
> S ()
> : value (21)
> {
> }
> S (int v)
> : value (v)
> {
> }
> S (const S& rhs)
> : value (rhs.value)
> {
> }
> S& operator+= (const S& rhs)
> {
> value += rhs.value;
> return *this;
> }
> int value;
> };
> int main ()
> {
> const std::valarray b (S (10), 1); // 10 elements with value 1
> assert (b.sum ().value == 10);
> return 0;
> }
> The wording in the standard seems to imply that the returned value should be
> a copy of one of the elements, and that op+= should be called on all of the
> other elements. If this is the case, then this an additional issue that would
> be detectable in user code [the user can count how many times the op+= is
> invoked]. This issue may apply to the min() and max() methods as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-693) std::valarray::sum does not work correctly for udt that has nonzero default value
std::valarray::sum does not work correctly for udt that has nonzero default
value
-
Key: STDCXX-693
URL: https://issues.apache.org/jira/browse/STDCXX-693
Project: C++ Standard Library
Issue Type: Bug
Components: 26. Numerics
Affects Versions: 4.2.0
Reporter: Travis Vitek
Priority: Minor
#include
#include
struct S
{
// this ctor should not be required
S ()
: value (21)
{
}
S (int v)
: value (v)
{
}
S (const S& rhs)
: value (rhs.value)
{
}
S& operator+= (const S& rhs)
{
value += rhs.value;
return *this;
}
int value;
};
int main ()
{
const std::valarray b (S (10), 1); // 10 elements with value 1
assert (b.sum ().value == 10);
return 0;
}
The wording in the standard seems to imply that the returned value should be a
copy of one of the elements, and that op+= should be called on all of the other
elements. If this is the case, then this an additional issue that would be
detectable in user code [the user can count how many times the op+= is
invoked]. This issue may apply to the min() and max() methods as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-665) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
[
https://issues.apache.org/jira/browse/STDCXX-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557521#action_12557521
]
Travis Vitek commented on STDCXX-665:
-
It appears that there is some issue with catopen() on AIX. I believe the
following testcase can be used to demonstrate.
#include
#include
#include
#include
#include
#include
#define _RWSTD_BAD_CATD nl_catd (-1)
int main (int argc, char* argv [])
{
if (argc < 2) {
printf ("usage %s [locale]\n", argv [0]);
return 0;
}
if (argc > 1) {
const char* loc = setlocale (LC_ALL, argv [2]);
if (!loc) printf ("failed to set locale to %s\n", argv [2]);
}
const char* const nls = getenv ("NLSPATH");
printf ("NLSPATH is %s\n", nls ? nls : "not set");
const char* const lang = getenv ("LANG");
printf ("LANGis %s\n", lang ? lang : "not set");
const nl_catd cat = catopen (argv[1], NL_CAT_LOCALE);
if (_RWSTD_BAD_CATD == cat) {
printf ("failed\n");
return 1;
}
else {
printf ("success\n");
catclose (cat);
}
return 0;
}
Here are the results on AIX and Linux...
$ ./t.aix /nfs/homes/vitek/nls/msgs-aix.cat
NLSPATH is /nfs/homes/vitek/nls/%N
LANGis not set
success
$ ./t.aix nls/msgs-aix.cat
NLSPATH is /nfs/homes/vitek/nls/%N
LANGis not set
success
$ ./t.aix msgs-aix.cat
NLSPATH is /nfs/homes/vitek/nls/%N
LANGis not set
failed
$ ./t.lin /nfs/homes/vitek/nls/msgs-lin.cat
NLSPATH is /nfs/homes/vitek/nls/%N
LANGis not set
success
$ ./t.lin nls/msgs-lin.cat
NLSPATH is /nfs/homes/vitek/nls/%N
LANGis not set
success
$ ./t.lin msgs-lin.cat
NLSPATH is /nfs/homes/vitek/nls/%N
LANGis not set
success
The first run of each series uses an absolute path, the second a relative path,
and the last should be using the NLSPATH after replacing %N with the provided
filename. Unfortunately that last case doesn't work on AIX.
The documentation for catopen() on AIX claims that setlocale() must be called
first if you require that the NLSPATH environment variable be used for catalog
lookup. I've tried this using the above testcase, but it doesn't seem to have
any effect.
> [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
>
>
> Key: STDCXX-665
> URL: https://issues.apache.org/jira/browse/STDCXX-665
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2.0
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
>
> Currently only single threaded builds show this problem
> NAME STATUS WARN ASSERTS FAILED PERCNTUSER
> SYSREAL
> 22.locale.messages 00 26810660% 0.090
> 0.640 3.960
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-577) purify reports leaked memory in stocks example
[ https://issues.apache.org/jira/browse/STDCXX-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557496#action_12557496 ] Travis Vitek commented on STDCXX-577: - The leaks mentioned by the valgrind report are potential leaks in purify. The locale that is imbued on std::cout.rdbuf() owns a StockXchange facet that is allocated on the heap. If/When the locale is destroyed, the facet reference count would be decremented and the object would be deallocated [if appropriate]. My solution is to restore the streams locale before main returns. This prevents the facet from being in use at program termination. This fix is included in the above patch. > purify reports leaked memory in stocks example > --- > > Key: STDCXX-577 > URL: https://issues.apache.org/jira/browse/STDCXX-577 > Project: C++ Standard Library > Issue Type: Improvement > Components: Examples >Affects Versions: 4.2.0 >Reporter: Travis Vitek >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-577.patch, stocks-valgrind.log, stocks.log > > > It is pretty obvious from looking at the source that memory is being leaked. > The destructor for StockXchange doesn't deallocate memory allocated in > StockXchange::add(), and the sl_pairs allocated in main are never deallocated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-577) purify reports leaked memory in stocks example
[ https://issues.apache.org/jira/browse/STDCXX-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-577: Attachment: stdcxx-577.patch 2008-01-09 Travis Vitek <[EMAIL PROTECTED]> STDCXX-577 * examples/include/stocks.h: Removed StockXchange destructor implementation. * examples/tutorial/stocks.cpp: Add StockXchange destructor that properly deallocates memory. (main): Avoid allocation of facets when the locale that uses them is not available. Change Xchange to hold pair values to avoid having to deallocate those pairs explicitly. Cache the locale initially imbued on stream, then restore it to ensure that facets used by imbued locale is deallocated. > purify reports leaked memory in stocks example > --- > > Key: STDCXX-577 > URL: https://issues.apache.org/jira/browse/STDCXX-577 > Project: C++ Standard Library > Issue Type: Improvement > Components: Examples >Affects Versions: 4.2.0 >Reporter: Travis Vitek >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-577.patch, stocks-valgrind.log, stocks.log > > > It is pretty obvious from looking at the source that memory is being leaked. > The destructor for StockXchange doesn't deallocate memory allocated in > StockXchange::add(), and the sl_pairs allocated in main are never deallocated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-577) purify reports leaked memory in stocks example
[ https://issues.apache.org/jira/browse/STDCXX-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-577: Attachment: (was: stdcxx-577.patch) > purify reports leaked memory in stocks example > --- > > Key: STDCXX-577 > URL: https://issues.apache.org/jira/browse/STDCXX-577 > Project: C++ Standard Library > Issue Type: Improvement > Components: Examples >Affects Versions: 4.2.0 >Reporter: Travis Vitek >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stocks-valgrind.log, stocks.log > > > It is pretty obvious from looking at the source that memory is being leaked. > The destructor for StockXchange doesn't deallocate memory allocated in > StockXchange::add(), and the sl_pairs allocated in main are never deallocated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-518) std::string copy constructor slow
[
https://issues.apache.org/jira/browse/STDCXX-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Vitek closed STDCXX-518.
---
Resolution: Fixed
I did a quick test to verify. I built the library and test with 'gmake
CXXOPTS=_RWSTD_USE_STRING_ATOMIC_OPS', and then ran it. Here is the
comparison...
$ time ./string-copy.stdcxx 1
real0m4.279s
user0m4.271s
sys 0m0.003s
$ time ./string-copy.gcc 1
real0m4.392s
user0m4.378s
sys 0m0.008s
> std::string copy constructor slow
> -
>
> Key: STDCXX-518
> URL: https://issues.apache.org/jira/browse/STDCXX-518
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: 21. Strings
>Affects Versions: 4.1.3
> Environment: gcc 4.1.2, x86_64
>Reporter: Mark Brown
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
>
> When thread safety is enabled in stdcxx the string copy constructor is more
> than ten times slower than when it's not, and twice as slow as the same copy
> constructor in gcc 4.1.2 on Linux (x86_64), but slightly faster than with
> STLport 5.1.3. The timings were done on Intel x86_64 at 2.4GHz:
> BUILDMODE=shared,optimized:
> $ time LD_LIBRARY_PATH=../lib ./string-copy 1
> real0m0.482s
> user0m0.480s
> sys 0m0.000s
> BUILDMODE=shared,optimized,pthread:
> $ time LD_LIBRARY_PATH=../lib ./string-copy 1
> real0m10.157s
> user0m10.041s
> sys 0m0.032s
> gcc 4.1.2 with -O2 -m64:
> $ time ./string-copy.gcc 1
> real0m4.280s
> user0m4.260s
> sys 0m0.020s
> gcc 4.1.2 with STLport 5.1.3 (-D_REENTRANT -O2 -m64 -lpthread):
> $ time ./string-copy.stlport 1
> real0m12.479s
> user0m12.473s
> sys 0m0.004s
> #include
> #include
> #include
> int main (int argc, char *argv[])
> {
> const unsigned long n = argc < 2 ? 0 : std::strtoul (argv [1], 0, 10);
> std::string strings [256];
> const std::size_t num_strings = sizeof strings / sizeof *strings;
> for (unsigned long i = 0; i != num_strings; ++i)
> strings [i].assign (i, 'x');
> for (unsigned long i = 0; i < n; ++i) {
> const std::size_t length = i % num_strings;
> const std::string str (strings [length]);
> assert (str.size () == length);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-518) std::string copy constructor slow
[
https://issues.apache.org/jira/browse/STDCXX-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557049#action_12557049
]
Travis Vitek commented on STDCXX-518:
-
This is a known issue. At one time in the past we didn't have atomic operation
support for amd64 and emt64 platforms running Linux. As a result we used a
per-string mutex to protect per-string data. Since that time we added the
necessary atomic operation support. Unfortunately, due to binary compatibility
requirements, we cannot switch the implementation until the next major version.
Please see http://svn.apache.org/viewvc?view=rev&revision=585998.
> std::string copy constructor slow
> -
>
> Key: STDCXX-518
> URL: https://issues.apache.org/jira/browse/STDCXX-518
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: 21. Strings
>Affects Versions: 4.1.3
> Environment: gcc 4.1.2, x86_64
>Reporter: Mark Brown
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
>
> When thread safety is enabled in stdcxx the string copy constructor is more
> than ten times slower than when it's not, and twice as slow as the same copy
> constructor in gcc 4.1.2 on Linux (x86_64), but slightly faster than with
> STLport 5.1.3. The timings were done on Intel x86_64 at 2.4GHz:
> BUILDMODE=shared,optimized:
> $ time LD_LIBRARY_PATH=../lib ./string-copy 1
> real0m0.482s
> user0m0.480s
> sys 0m0.000s
> BUILDMODE=shared,optimized,pthread:
> $ time LD_LIBRARY_PATH=../lib ./string-copy 1
> real0m10.157s
> user0m10.041s
> sys 0m0.032s
> gcc 4.1.2 with -O2 -m64:
> $ time ./string-copy.gcc 1
> real0m4.280s
> user0m4.260s
> sys 0m0.020s
> gcc 4.1.2 with STLport 5.1.3 (-D_REENTRANT -O2 -m64 -lpthread):
> $ time ./string-copy.stlport 1
> real0m12.479s
> user0m12.473s
> sys 0m0.004s
> #include
> #include
> #include
> int main (int argc, char *argv[])
> {
> const unsigned long n = argc < 2 ? 0 : std::strtoul (argv [1], 0, 10);
> std::string strings [256];
> const std::size_t num_strings = sizeof strings / sizeof *strings;
> for (unsigned long i = 0; i != num_strings; ++i)
> strings [i].assign (i, 'x');
> for (unsigned long i = 0; i < n; ++i) {
> const std::size_t length = i % num_strings;
> const std::string str (strings [length]);
> assert (str.size () == length);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (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:all-tabpanel ] Travis Vitek closed STDCXX-443. --- Resolution: Fixed committed to trunk in http://svn.apache.org/viewvc?view=rev&revision=601922 merged to 4.2.x in http://svn.apache.org/viewvc?view=rev&revision=604045 > [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 > > Attachments: stdcxx-443.patch > > > 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.
stdcxx-dev@incubator.apache.org
[
https://issues.apache.org/jira/browse/STDCXX-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556768#action_12556768
]
Travis Vitek commented on STDCXX-612:
-
I'm a little on the fence as to whether item 1 above really is forward
compatible or not. There may be some compiler that we aren't testing that
requires it, and we would be breaking compatibility there.
I don't really have a problem with letting this issue sit until 4.3 or later.
I'm also open to never fixing the issue if someone can provide a reasonable
argument for why you would want it to not work. Of course that may require
someone to explain why the standards gurus decided to require this interesting
behavior in some places. That said, if we are intent on doing something with
this issue now, then I think the above is acceptable.
> many iterator types do not work with types that implement unary operator&
> -
>
> Key: STDCXX-612
> URL: https://issues.apache.org/jira/browse/STDCXX-612
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 24. Iterators
>Affects Versions: 4.2.0
>Reporter: Travis Vitek
>Assignee: Farid Zaripov
> Fix For: 4.2.1
>
> Attachments: operator_arrow.patch
>
>
> Code that uses the macro _RWSTD_OPERATOR_ARROW will be affected by this
> issue. Code that has '&*' is also very likely to be affected.
> #include
> #include
> #include
> #include
> #include
> struct S
> {
>void operator& () const {};
> };
> int main ()
> {
>// this is just a compile test, it is not intended to run
>std::reverse_iterator().operator->();
>std::set::iterator().operator->();
>std::deque::iterator().operator->();
>std::list::iterator().operator->();
>return 0;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556714#action_12556714 ] Travis Vitek commented on STDCXX-605: - Dandy. > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-605-out.patch, stdcxx-605-v1.patch, > stdcxx-605-v2.patch, stdcxx-605-v3.patch > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-240) #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line option
[ https://issues.apache.org/jira/browse/STDCXX-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek closed STDCXX-240. --- Resolution: Fixed Closing. > #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line > option > - > > Key: STDCXX-240 > URL: https://issues.apache.org/jira/browse/STDCXX-240 > Project: C++ Standard Library > Issue Type: Improvement > Components: Build >Affects Versions: 4.1.2, 4.1.3, 4.1.4 >Reporter: Martin Sebor >Assignee: Travis Vitek >Priority: Minor > Fix For: 4.2.1 > > Attachments: stdcxx-240-vacpp60.patch, stdcxx-240.patch > > > Moved from the Rogue Wave bug tracking database: > Class/File: stdcomp.h > Fix Priority: Can Fix > Long Description: > *** Dec 1 1999 6:03PM *** sebor *** > A request for enhancement. > Subject: define RWSTD_NO_EXCEPTIONS when __HPACC_NOEH is > Date: Wed, 01 Dec 1999 17:11:36 -0800 > From: Chichiang Wan <[EMAIL PROTECTED]> > Organization: California Language Labs > To: oemsupport <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], wanc_at_hp <[EMAIL PROTECTED]> > aCC has an option +noeh. When it is provided, __HPACC_NOEH will be > defined. It would be nice for users to need to only use +noeh. For > that, > RWSTD_NO_EXCEPTIONS needs to be defined conditionally. > = > $ cat test.C > #include > $ aCC +noeh -c test.C > Error 46: "/opt/aCC/include/memory", line 493 # Exception handling is > not > enabled (do not use the +noeh flag to aCC). > RWSTD_THROW_NO_MSG(tmp == 0, bad_alloc); > -- Chichiang > Modified By: sebor @ May 29, 2000 10:28:25 PM > We should do this AND test it -- not just on aCC but in general with all > compilers that support this feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-240) #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line option
[ https://issues.apache.org/jira/browse/STDCXX-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-240: Patch Info: [Patch Available] > #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line > option > - > > Key: STDCXX-240 > URL: https://issues.apache.org/jira/browse/STDCXX-240 > Project: C++ Standard Library > Issue Type: Improvement > Components: Build >Affects Versions: 4.1.2, 4.1.3, 4.1.4 >Reporter: Martin Sebor >Assignee: Travis Vitek >Priority: Minor > Fix For: 4.2.1 > > Attachments: stdcxx-240-vacpp60.patch, stdcxx-240.patch > > > Moved from the Rogue Wave bug tracking database: > Class/File: stdcomp.h > Fix Priority: Can Fix > Long Description: > *** Dec 1 1999 6:03PM *** sebor *** > A request for enhancement. > Subject: define RWSTD_NO_EXCEPTIONS when __HPACC_NOEH is > Date: Wed, 01 Dec 1999 17:11:36 -0800 > From: Chichiang Wan <[EMAIL PROTECTED]> > Organization: California Language Labs > To: oemsupport <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], wanc_at_hp <[EMAIL PROTECTED]> > aCC has an option +noeh. When it is provided, __HPACC_NOEH will be > defined. It would be nice for users to need to only use +noeh. For > that, > RWSTD_NO_EXCEPTIONS needs to be defined conditionally. > = > $ cat test.C > #include > $ aCC +noeh -c test.C > Error 46: "/opt/aCC/include/memory", line 493 # Exception handling is > not > enabled (do not use the +noeh flag to aCC). > RWSTD_THROW_NO_MSG(tmp == 0, bad_alloc); > -- Chichiang > Modified By: sebor @ May 29, 2000 10:28:25 PM > We should do this AND test it -- not just on aCC but in general with all > compilers that support this feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-536) allow thread safety tests to time out without failing
[ https://issues.apache.org/jira/browse/STDCXX-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555660#action_12555660 ] Travis Vitek commented on STDCXX-536: - The patch is not ready for submission. I think we need to pick up discussion on this issue again. > 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: 4.2.0 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-498) [Intel C++ 8.1/SuSE/AMD64] std::time_put thread safety problem
[ https://issues.apache.org/jira/browse/STDCXX-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek resolved STDCXX-498. - Resolution: Cannot Reproduce I haven't been able to reproduce this failure in manual builds, and I'm not seeing it in automated testing either. > [Intel C++ 8.1/SuSE/AMD64] std::time_put thread safety problem > -- > > Key: STDCXX-498 > URL: https://issues.apache.org/jira/browse/STDCXX-498 > Project: C++ Standard Library > Issue Type: Bug > Components: 22. Localization >Affects Versions: 4.1.3 > Environment: Intel C++ 8.1/SuSE/AMD64 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > > Moved from Rogue Wave Bugzilla: > http://bugzilla.cvo.roguewave.com/show_bug.cgi?id=1708 (note the name of the > test is now 22.locale.time.put.mt.cpp). > tests/stdlib/locale/time_put_mt seems to have a thread safety issue > where a local name is corrupted and causes the test to fail. > Stack Trace using icc8.1 on sunburst (amd64) > > (gdb) r -O/dev/tty > > Starting program: /build/sebor/icc-8.1-15S/tests/22_time_put_mt > > -O/dev/tty [Thread debugging using libthread_db enabled] [New Thread > > 182894218016 (LWP 27151)] ## --- > > ## TestTag = std::time_put thread safety > > ## CompilerId = Intel C++, __INTEL_COMPILER = 810, > > __INTEL_COMPILER_BUILD_DATE = 20050406, __EDG_VERSION__ = 303 with > Rogue > > Wave C++ Standard Library, _RWSTD_VER = 0x0401 > > ## MachineId = x86_64/LP64 running linux-elf 2.4.20 with glibc 2.3 > > ## Remark = > > > > /build/sebor/dev/stdlib/tests/src/test.cpp:916: executing "locale -a > > > /tmp/tmpfile-J00vyh" > > Detaching after fork from child process 27156. > > > > ## RunTag = using the following 4 locales: "aa_DJ.iso88591", > > "be_BY", "ca_ES", "da_DK" > > [New Thread 1084229984 (LWP 27158)] > > T0 [New Thread 1094719840 (LWP 27159)] > > T1 [New Thread 1105209696 (LWP 27160)] > > T2 [New Thread 1115699552 (LWP 27161)] > > T3 T2 T2 T0 T1 T2 T3 T1 T2 T0 T0 T1 T1 T2 T3 T3 T1 T0 T2 T3 T0 T3 T2 > > T2 > > T0 T2 T0 T1 > > T2 iterated 1 times, shared counter = 30913 (min: 1, max: 2458) > > [Thread 1105209696 (LWP 27160) exited] > > T1 T0 T3 T1 T3 /build/sebor/dev/stdlib/src/locale_body.cpp:516: > > __rw::__rw_locale::__rw_locale(const char *): Assertion '!strchr (name, > > '*')' failed. > > /build/sebor/icc-8.1-15S/tests/22_time_put_mt[0x420851] > > > > Program received signal SIGABRT, Aborted. > > [Switching to Thread 1115699552 (LWP 27161)] 0x003c2392e4dd in > > raise () from /lib64/tls/libc.so.6 > > (gdb) where > > #0 0x003c2392e4dd in raise () from /lib64/tls/libc.so.6 #1 > > 0x003c2392fc8e in abort () from /lib64/tls/libc.so.6 #2 > > 0x00420930 in __rw::__rw_assert_fail ( > > expr=0x4a6eb0 "!strchr (name, '*')", > > file=0x4a6e7c "/build/sebor/dev/stdlib/src/locale_body.cpp", > line=516, > > func=0x4a6e4c "__rw::__rw_locale::__rw_locale(const char *)") > > at /build/sebor/dev/stdlib/src/assert.cpp:111 > > #3 0x0042aaa8 in _ZN4__rw11__rw_localeC9EPKc (this=0x69d430, > > name=0x428014e0 "@\n\227*") > > at /build/sebor/dev/stdlib/src/locale_body.cpp:516 > > #4 0x0042aeed in __rw::__rw_locale::__rw_locale () at > > _locale.h:292 > > #5 0x0042cedd in __rw::__rw_locale::_C_manage (plocale=0x0, > > locname=0x428014e0 "@\n\227*") > > at /build/sebor/dev/stdlib/src/locale_body.cpp:1004 > > #6 0x0042f154 in __rw::__rw_locale::_C_get_body (one=0x0, > > other=0x0, > > locname=0x63e7ef "da_DK", cat=256, pfacet=0x0) > > at /build/sebor/dev/stdlib/src/locale_combine.cpp:589 > > #7 0x0042e3bd in _ZNSt6localeC9EPKc (this=0x42801da0, > > locname=0x63e7ef "da_DK") > > at /build/sebor/dev/stdlib/src/locale_combine.cpp:646 > > #8 0x0042e445 in std::locale::locale () > > #9 0x00403c8f in test_thread::_C_do_run (this=0x7fbfffeb50) > > at /build/sebor/dev/stdlib/tests/localization/22_time_put_mt.cpp:159 > > #10 0x0040420b in __rw_run_thread (__arg=0x7fbfffeb50) > > at threadclass.h:209 > > #11 0x003c2440613a in start_thread () from > /lib64/tls/libpthread.so.0 > > #12 0x003c239c52b3 in clone () from /lib64/tls/libc.so.6 > > #13 0x in ?? () -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-503) std::ctype not thread safe
[
https://issues.apache.org/jira/browse/STDCXX-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Vitek resolved STDCXX-503.
-
Resolution: Cannot Reproduce
I haven't been able to reproduce this failure in manual builds, and I'm not
seeing it in automated testing either.
> std::ctype not thread safe
> --
>
> Key: STDCXX-503
> URL: https://issues.apache.org/jira/browse/STDCXX-503
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization, Thread Safety
>Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
> Environment: Intel C++ 10.0 20070613 on Linux/EM64T
>Reporter: Martin Sebor
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: 22.locale.ctype.mt.html
>
>
> The 22.locale.ctype.mt thread safety tests aborts at runtime indicating that
> there is a thread safety issue in the locale implementation. Running the test
> through the Intel Thread Checker reveals possible causes of the problem.
> $ tcheck_cl --format html -o 22.locale.ctype.mt.html 22.locale.ctype.mt
> --nloops=1000
> Intel(R) Thread Checker 3.1 command line instrumentation driver (24400)
> Copyright (c) 2007 Intel Corporation. All rights reserved.
> Building project
> Running: /build/sebor/stdcxx-icc-10.0.025-15S/tests/22.locale.ctype.mt
> --nloops=1000
> # INFO (S1) (10 lines):
> # TEXT:
> # COMPILER: Intel C++, __INTEL_COMPILER = 1000, __INTEL_COMPILER_BUILD_DATE =
> 20070613, __EDG_VERSION__ = 308
> # ENVIRONMENT: x86_64/LP64 running linux-elf (Fedora Core release 6 (Zod))
> with glibc 2.5
> # FILE: 22.locale.ctype.mt.cpp
> # COMPILED: Jul 29 2007, 16:10:58
> # COMMENT: thread safety
>
> # CLAUSE: lib.locale.ctype
> # NOTE (S2) (5 lines):
> # TEXT: executing "locale -a > /tmp/tmpfile-wSljVr"
> # CLAUSE: lib.locale.ctype
> # FILE: process.cpp
> # LINE: 270
> # INFO (S1) (3 lines):
> # TEXT: testing std::ctype with 2 threads, 1000 iterations each, in 16
> locales { "aa_DJ" "aa_DJ.iso88591" "aa_DJ.utf8" "aa_ER" "[EMAIL PROTECTED]"
> "aa_ER.utf8" "[EMAIL PROTECTED]" "aa_ET" "aa_ET.utf8" "af_ZA"
> "af_ZA.iso88591" "af_ZA.utf8" "am_ET" "am_ET.utf8" "an_ES" "an_ES.iso885915" }
> # CLAUSE: lib.locale.ctype
> # INFO (S1) (3 lines):
> # TEXT: exercising std::ctype
> # CLAUSE: lib.locale.ctype
> # INFO (S1) (3 lines):
> # TEXT: exercising std::ctype
> # CLAUSE: lib.locale.ctype
> /home/sebor/stdcxx/tests/localization/22.locale.ctype.mt.cpp:156: void
> *thread_func(void *): Assertion 'wc == data->wwidened_ [cinx]' failed.
> /build/sebor/stdcxx-icc-10.0.025-15S/tests/./22.locale.ctype.mt[0xbd20c5]
> Application finished
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-360) [XLC++ 7.0] ICE compiling 2.smartptr.shared.cpp
[ https://issues.apache.org/jira/browse/STDCXX-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553779 ] Travis Vitek commented on STDCXX-360: - I've tried several different patch levels and I cannot reproduce this problem on VisualAge C++ 7.0.0.0 or later. I have been able to reproduce this with VisualAge C++ 6.0.0.12. > [XLC++ 7.0] ICE compiling 2.smartptr.shared.cpp > --- > > Key: STDCXX-360 > URL: https://issues.apache.org/jira/browse/STDCXX-360 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.1.3, 4.2.0 > Environment: IBM XL C/C++ Version: 07.00..0009 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: t.cpp.gz, t.cpp.gz.base64 > > > PMR 02337,K78,000 > The attached translation unit (gzipped and encoded in base-64) produced by > preprocessing tests/tr1.util/2.smartptr.shared.cpp) causes an internal > compiler error: > $ xlC -qversion && xlC -q64 -c -g t.cpp > IBM XL C/C++ Enterprise Edition V7.0 > Version: 07.00..0009 > /nfs/packages/mdx/aix/compilers/5.3.0/va70_20070227/root/usr/vacpp/bin/.orig/xlC: > 1501-230 Internal compiler error; please contact your Service Representative > xlCcore_r -c -I/amd/devco/sebor/stdcxx-4.1.3/include/ansi -D_RWSTDDEBUG > -D_RWSTD_USE_CONFIG -I/build/sebor/stdcxx-4.1.3-vacpp-7.0-15D/include > -I/amd/devco/sebor/stdcxx-4.1.3/include > -I/amd/devco/sebor/stdcxx-4.1.3/../rwtest > -I/amd/devco/sebor/stdcxx-4.1.3/../rwtest/include > -I/amd/devco/sebor/stdcxx-4.1.3/tests/include -g -q64 > -qtemplateregistry=2.smartptr.shared.ti > /amd/devco/sebor/stdcxx-4.1.3/tests/tr1.util/2.smartptr.shared.cpp > /nfs/packages/mdx/aix/compilers/5.3.0/va70_20070227/root/usr/vacpp/bin/.orig/xlCcore_r: > 1501-230 Internal compiler error; please contact your Service Representative -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (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 closed STDCXX-673.
---
Resolution: Fixed
The 8.cstdint test was failing 3 assertions because of this problem, one
failure for each of int8_t, int_least8_t and int_fast8_t. So the test should
not need to be enhanced.
> [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] Closed: (STDCXX-603) [IBM XLC++ 9.0] unsats on std::valarray::apply() in 26.valarray.members.stdcxx-313.cpp
[ https://issues.apache.org/jira/browse/STDCXX-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek closed STDCXX-603. --- Resolution: Fixed Verfied to compile and run in automated testing. > [IBM XLC++ 9.0] unsats on std::valarray::apply() in > 26.valarray.members.stdcxx-313.cpp > - > > Key: STDCXX-603 > URL: https://issues.apache.org/jira/browse/STDCXX-603 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 > Environment: IBM XLC++ 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-603.patch > > > The 26.valarray.members.stdcxx-313.cpp regression test fails to link with IBM > XLC++ 9.0 on AIX 5.3: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/tests/include -O -Q > -qtemplateregistry=26.valarray.members.stdcxx-313.ti > $(TOPDIR)/tests/regress/26.valarray.members.stdcxx-313.cpp > xlCcore_r 26.valarray.members.stdcxx-313.o -o 26.valarray.members.stdcxx-313 > -L$(BUILDDIR)/rwtest -lrwtest -I$(TOPDIR)/include/ansi-liconv -Wl,-bh:5 > -L$(BUILDDIR)/lib -Wl,-bsvr4,-R$(BUILDDIR)/lib:$(BUILDDIR)/rwtest -lstd > -lm -qtemplateregistry=26.valarray.members.stdcxx-313.ti > ld: 0711-317 ERROR: Undefined symbol: .std::valarray::apply(S(*)(S)) const > ld: 0711-317 ERROR: Undefined symbol: .std::valarray::apply(S(*)(const > S&)) const > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. > gmake: *** [26.valarray.members.stdcxx-313] Error 8 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-604) [IBM XLC++ 9.0] ICE on 23.bitset.cons.stdcxx-297
[ https://issues.apache.org/jira/browse/STDCXX-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek closed STDCXX-604. --- Resolution: Fixed Verified to compile and run in automated testing. > [IBM XLC++ 9.0] ICE on 23.bitset.cons.stdcxx-297 > > > Key: STDCXX-604 > URL: https://issues.apache.org/jira/browse/STDCXX-604 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 > Environment: IBM XLC++ 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-604.patch > > > The 23.bitset.cons.stdcxx-297.cpp regression test fails to compile with IBM > XLC++ 9.0 due to an internal compiler error: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/tests/include -O -Q > -qtemplateregistry=23.bitset.cons.stdcxx-297.ti > $(TOPDIR)/tests/regress/23.bitset.cons.stdcxx-297.cpp > /nfs/packages/mdx/aix/compilers/5.2.0/va90/root/usr/vacpp/bin/.orig/xlCcore_r: > 1501-230 (S) Internal compiler error; please contact your Service > Representative > gmake: *** [23.bitset.cons.stdcxx-297.o] Error 41 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-524) buffer overflow in test 22.locale.time.get.cpp (make_LC_TIME)
[ https://issues.apache.org/jira/browse/STDCXX-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek closed STDCXX-524. --- Resolution: Fixed Verified in automated testing > buffer overflow in test 22.locale.time.get.cpp (make_LC_TIME) > - > > Key: STDCXX-524 > URL: https://issues.apache.org/jira/browse/STDCXX-524 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.1.2, 4.1.3, 4.1.4 >Reporter: Travis Vitek >Assignee: Travis Vitek >Priority: Trivial > Fix For: 4.2.1 > > Attachments: stdcxx-524.patch > > > This test uses L_tmpnam to determine the length of a buffer used to store a > filename string. Unfortunately, L_tmpnam is intended for use with tmpnam(), > but the buffer is written to with std::sprintf(). When I run the test, the > allocated buffer is 46 bytes, and the sprintf() call writes 58 bytes [this > will vary based on user name and other variables]. Perhaps the buffer should > be made larger, or some other method should be used to fill the buffer. > Perhaps this would work. > #if !defined (_WIN32) && !defined (_WIN64) > # define _PATH_MAX PATH_MAX > #else > # define _PATH_MAX _MAX_PATH > #endif > char srcfname [_PATH_MAX]; // [L_tmpnam + 32]; > std::sprintf (srcfname, "%s" SLASH "LC_TIME.src", locale_root); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-240) #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line option
[ https://issues.apache.org/jira/browse/STDCXX-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-240: Attachment: stdcxx-240-vacpp60.patch committed to trunk http://svn.apache.org/viewvc?view=rev&revision=605368 merged to 4.2.x http://svn.apache.org/viewvc?view=rev&revision=605369 The previous patch doesn't work with VisualAge C++ prior to version 7. Here is a small tweak to get builds working on that configuration again. 2007-12-19 Travis Vitek <[EMAIL PROTECTED]> * include/rw/_config-xlc.h [__IBMCPP__]: Conditionally disable exception support if command line option is set and the compiler is version 7.0 or later. > #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line > option > - > > Key: STDCXX-240 > URL: https://issues.apache.org/jira/browse/STDCXX-240 > Project: C++ Standard Library > Issue Type: Improvement > Components: Build >Affects Versions: 4.1.2, 4.1.3, 4.1.4 >Reporter: Martin Sebor >Assignee: Travis Vitek >Priority: Minor > Fix For: 4.2.1 > > Attachments: stdcxx-240-vacpp60.patch, stdcxx-240.patch > > > Moved from the Rogue Wave bug tracking database: > Class/File: stdcomp.h > Fix Priority: Can Fix > Long Description: > *** Dec 1 1999 6:03PM *** sebor *** > A request for enhancement. > Subject: define RWSTD_NO_EXCEPTIONS when __HPACC_NOEH is > Date: Wed, 01 Dec 1999 17:11:36 -0800 > From: Chichiang Wan <[EMAIL PROTECTED]> > Organization: California Language Labs > To: oemsupport <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], wanc_at_hp <[EMAIL PROTECTED]> > aCC has an option +noeh. When it is provided, __HPACC_NOEH will be > defined. It would be nice for users to need to only use +noeh. For > that, > RWSTD_NO_EXCEPTIONS needs to be defined conditionally. > = > $ cat test.C > #include > $ aCC +noeh -c test.C > Error 46: "/opt/aCC/include/memory", line 493 # Exception handling is > not > enabled (do not use the +noeh flag to aCC). > RWSTD_THROW_NO_MSG(tmp == 0, bad_alloc); > -- Chichiang > Modified By: sebor @ May 29, 2000 10:28:25 PM > We should do this AND test it -- not just on aCC but in general with all > compilers that support this feature. -- 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-605) [IBM XLC++] errors compiling dynatype.cpp
[
https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553208
]
vitek edited comment on STDCXX-605 at 12/18/07 6:49 PM:
---
In the failure you mention, the conversion we want is to `const int&'. The
conversion operator that gets invoked is the non-const `operator T&' with 'T'
being 'const int'. That conversion operator calls the non-const retrieve(),
which keeps the const and looks in the static dynatype::map for a
value. We should be looking in dynatype::map, but the const is not being
stripped.
Consider the following...
struct S
{
private:
template int g (T*) { return 0; }
template int g (const T*) const { return 1; }
public:
template int f () { return g ((T*)0); }
};
int main ()
{
const int a = S().f();
const int b = S().f();
return (a << 1) | b;
}
I believe that the expected result is 0. When compiling the S().f(),
I see a few candidate functions for overload resolution. Given that the
overload resolution system treats member functions as if they were free
functions with a correctly cv-qualified implicit object parameter, the
candidates would seem to be
int S_g(S&, int*);
int S_g(S&, const int*);
from the first template, and
int S_g(const S&, const int*);
from the second. The actual type of the call is
??? S_g(S&, const int*);
So the best match is easily selected, and the result is a call to the non-const
'g' template, which leaves the const on the template type T instead of
stripping it like we want.
Continuing with the example, I see a few options. We could make both 'g'
overloads share the same constness. If we make them have the same constness,
then the overload resolution chooses the best match based on the explicit
parameter type, and then discards const as we want. The disadvantage of this is
that we would either have two const overloads of 'g' [which you didn't appear
to like], or we can have two non-const overloads and cast away const when
calling from a const member function. A third option would be to make both 'g'
overloads into non-member functions that takes const S* [essentially the same
as making both members const], but that would require some code rearranging.
Personally I thought that the two const retrieve() overloads was the simplest
and cleanest solution [stdcxx-605-v2.patch]. The most recent patch involves
changing fewer lines of code in the example, but it leaves a nasty static/const
cast [stdcxx-605-v1.patch].
was (Author: vitek):
In the failure you mention, the conversion we want is to `const int&'. The
conversion operator that gets invoked is the non-const `operator T&' with 'T'
being 'const int'. That conversion operator calls the non-const retrieve(),
which keeps the const and looks in the static dynatype::map for a
value. We should be looking in dynatype::map, but the const is not being
stripped.
Consider the following...
struct S
{
private:
template int g (T*) { return 0; }
template int g (const T*) const { return 1; }
public:
template int f () { return g ((T*)0); }
};
int main ()
{
const int a = S().f();
const int b = S().f();
return (a << 1) | b;
}
I believe that the expected result is 0. When compiling the S().f(),
I see a few candidate functions for overload resolution. Given that the
overload resolution system treats member functions as if they were free
functions with a correctly cv-qualified implicit object parameter, the
candidates would seem to be
int S_g(S&, int*);
int S_g(S&, const int*);
from the first template, and
int S_g(const S&, int*);
int S_g(const S&, const int*);
from the second. The actual type of the call is
??? S_g(S&, const int*);
So the best match is easily selected, and the result is a call to the non-const
'g' template, which leaves the const on the template type T instead of
stripping it like we want.
Continuing with the example, I see a few options. We could make both 'g'
overloads share the same constness. If we make them have the same constness,
then the overload resolution chooses the best match based on the explicit
parameter type, and then discards const as we want. The disadvantage of this is
that we would either have two const overloads of 'g' [which you didn't appear
to like], or we can have two non-const overloads and cast away const when
calling from a const member function. A third option would be to make both 'g'
overloads into non-member functions that takes const S* [essentially the same
as making both members const], but that would require some code rearranging.
Personally I thought that the two const retrieve() overloads was the simplest
and cleanest solution [stdcxx-605-v2.patch]. The most recent patch involves
changing fewer lines of code in the example, but it leaves a nasty static/const
cast [stdcxx-605-v1.pat
[jira] Updated: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-605: Attachment: stdcxx-605-out.patch The update output is now attached as a separate patch. > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-605-out.patch, stdcxx-605-v1.patch, > stdcxx-605-v2.patch > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[
https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Vitek updated STDCXX-605:
Attachment: stdcxx-605-v2.patch
stdcxx-605-v1.patch
In the failure you mention, the conversion we want is to `const int&'. The
conversion operator that gets invoked is the non-const `operator T&' with 'T'
being 'const int'. That conversion operator calls the non-const retrieve(),
which keeps the const and looks in the static dynatype::map for a
value. We should be looking in dynatype::map, but the const is not being
stripped.
Consider the following...
struct S
{
private:
template int g (T*) { return 0; }
template int g (const T*) const { return 1; }
public:
template int f () { return g ((T*)0); }
};
int main ()
{
const int a = S().f();
const int b = S().f();
return (a << 1) | b;
}
I believe that the expected result is 0. When compiling the S().f(),
I see a few candidate functions for overload resolution. Given that the
overload resolution system treats member functions as if they were free
functions with a correctly cv-qualified implicit object parameter, the
candidates would seem to be
int S_g(S&, int*);
int S_g(S&, const int*);
from the first template, and
int S_g(const S&, int*);
int S_g(const S&, const int*);
from the second. The actual type of the call is
??? S_g(S&, const int*);
So the best match is easily selected, and the result is a call to the non-const
'g' template, which leaves the const on the template type T instead of
stripping it like we want.
Continuing with the example, I see a few options. We could make both 'g'
overloads share the same constness. If we make them have the same constness,
then the overload resolution chooses the best match based on the explicit
parameter type, and then discards const as we want. The disadvantage of this is
that we would either have two const overloads of 'g' [which you didn't appear
to like], or we can have two non-const overloads and cast away const when
calling from a const member function. A third option would be to make both 'g'
overloads into non-member functions that takes const S* [essentially the same
as making both members const], but that would require some code rearranging.
Personally I thought that the two const retrieve() overloads was the simplest
and cleanest solution [stdcxx-605-v2.patch]. The most recent patch involves
changing fewer lines of code in the example, but it leaves a nasty static/const
cast [stdcxx-605-v1.patch].
> [IBM XLC++] errors compiling dynatype.cpp
> -
>
> Key: STDCXX-605
> URL: https://issues.apache.org/jira/browse/STDCXX-605
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Examples
>Affects Versions: 4.2.0
> Environment: XLC++ 6.0 through 9.0/AIX 5.3
>Reporter: Martin Sebor
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: stdcxx-605-v1.patch, stdcxx-605-v2.patch
>
>
> The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX
> with ethe following errors:
> xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include
> -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q
> -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "int".
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "double".
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "double".
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "const char *".
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "const char *".
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "char".
> gmake: *** [dynatype.o] Error 1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-605: Attachment: (was: stdcxx-605.patch) > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-675) [MSVC] implement autolinking feature
[ https://issues.apache.org/jira/browse/STDCXX-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552933 ] Travis Vitek commented on STDCXX-675: - If the new user takes advantage of the autolinking feature, they will have to modify their build system to get it to work with a previous version of the library. i.e. they will need to explicitly link the library file when they go back to 4.2.0. Will this ever be useful for any compiler other than MSVC and ICC/Windows? Is there a way that we can ensure the user links the right library on all platforms? This wouldn't avoid the need to explicitly link the library, but it would eliminate issues with linking the wrong library. > [MSVC] implement autolinking feature > > > Key: STDCXX-675 > URL: https://issues.apache.org/jira/browse/STDCXX-675 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: MSVC, ICC/Windows >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Trivial > Fix For: 4.2.1 > > Attachments: autolink.patch > > > At the moment the users of the library should explicitly specify the used > library name in linker command line. Here might be problems if the user's > project was compiled with config.h for some configuration (let's say 12d) but > linked with library for another configuration (i.e. libstd12s.lib). > The MSVC and ICC/Windows has the posibility to specify the library using > #pragma comment (lib, libname) directive. So #including any header from the > library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-614) [gcc 4.1/Linux] error on size_t in 27.stringbuf.xsputn.stdcxx-515.cpp
[ https://issues.apache.org/jira/browse/STDCXX-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek closed STDCXX-614. --- Resolution: Fixed Verified in automated testing. > [gcc 4.1/Linux] error on size_t in 27.stringbuf.xsputn.stdcxx-515.cpp > - > > Key: STDCXX-614 > URL: https://issues.apache.org/jira/browse/STDCXX-614 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 > Environment: gcc 4.1.1 on Red Hat Enterprise Linux Server release 5 > (Tikanga) >Reporter: Martin Sebor >Assignee: Travis Vitek >Priority: Minor > Fix For: 4.2.1 > > > The 27.stringbuf.xsputn.stdcxx-515.cpp fails to compile with gcc 4.1.1 on > Red Hat Enterprise Linux Server release 5 with the error below: > gcc -c -I$(TOPDIR)/include/ansi -D_RWSTDDEBUG-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/tests/include -pedantic -nostdinc++ -g > -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long > -Wcast-align $(TOPDIR)/tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp > $(TOPDIR)/tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp: In function 'int > main()': > $(TOPDIR)/tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp:33: error: > 'size_t' was not declared in this scope > $(TOPDIR)/tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp:33: error: > expected `;' before 'i' > $(TOPDIR)/tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp:33: error: 'i' was > not declared in this scope > gmake: *** [27.stringbuf.xsputn.stdcxx-515.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-664) [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
[
https://issues.apache.org/jira/browse/STDCXX-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Vitek closed STDCXX-664.
---
Resolution: Fixed
Test passing automated testing.
> [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
> ---
>
> Key: STDCXX-664
> URL: https://issues.apache.org/jira/browse/STDCXX-664
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2.0
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: stdcxx-664-1.patch, stdcxx-664-2.patch
>
>
> Appears to affect single-threaded bulids only.
> [EMAIL PROTECTED] tests]$ ./22.locale.globals.mt
> # INFO (S1) (10 lines):
> # TEXT:
> # COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
> # ENVIRONMENT: powerpc running aix-5.3
> # FILE: 22.locale.globals.mt.cpp
> # COMPILED: Nov 8 2007, 21:35:16
> # COMMENT: thread safety
>
> # CLAUSE: lib.locale.global.templates
> # NOTE (S2) (5 lines):
> # TEXT: executing "locale -a > /tmp/tmpfile-fK3jqa"
> # CLAUSE: lib.locale.global.templates
> # FILE: process.cpp
> # LINE: 270
> # INFO (S1) (3 lines):
> # TEXT: testing std::locale globals with 1 thread, 2 iterations each, in
> 16 locales { "C" "POSIX" "AR_DZ.UTF-8" "AR_BH" "AR_AA.UTF-8" "AR_BH.UTF-8"
> "AR_AE.UTF-8" "AR_DZ" "AR_EG.UTF-8" "AR_EG" "AR_AE" "AR_AA" "AR_JO"
> "AR_JO.UTF-8" "AR_KW" "AR_KW.UTF-8" }
> # CLAUSE: lib.locale.global.templates
> # INFO (S1) (3 lines):
> # TEXT: template bool std::has_facet (const locale&)
> # CLAUSE: lib.locale.global.templates
> # INFO (S1) (3 lines):
> # TEXT: template const T& std::use_facet (const locale&)
> # CLAUSE: lib.locale.global.templates
> # WARNING (S5) (3 lines):
> # TEXT: exceptions not thread safe, skipping that part of test
> # CLAUSE: lib.locale.global.templates
> /amd/devco/vitek/stdcxx-trunk/tests/localization/22.locale.globals.mt.cpp:311:
> use_facet_loop: Assertion 'threw || opt_facets [opt_inx_collate] < 0' failed.
> IOT/Abort trap (core dumped)
> [EMAIL PROTECTED] tests]$
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (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 closed STDCXX-676. --- Resolution: Fixed > [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 >Assignee: 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-240) #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line option
[ https://issues.apache.org/jira/browse/STDCXX-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-240: Attachment: stdcxx-240.patch 2007-12-18 Travis Vitek <[EMAIL PROTECTED]> STDCXX-240 * include/rw/_config-acc.h: Conditionally disable exception support if appropriate command line option is set. * include/rw/_config-deccxx.h: Ditto. * include/rw/_config-eccp.h: Ditto. * include/rw/_config-gcc.h: Ditto. * include/rw/_config-icc.h: Ditto. * include/rw/_config-mipspro.h: Ditto. * include/rw/_config-xlc.h: Ditto. I'm filing a new bug on the test suite to get it updated to work when _RWSTD_NO_EXCEPTIONS is defined. > #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line > option > - > > Key: STDCXX-240 > URL: https://issues.apache.org/jira/browse/STDCXX-240 > Project: C++ Standard Library > Issue Type: Improvement > Components: Build >Affects Versions: 4.1.2, 4.1.3, 4.1.4 >Reporter: Martin Sebor >Assignee: Travis Vitek >Priority: Minor > Fix For: 4.2.1 > > Attachments: stdcxx-240.patch > > > Moved from the Rogue Wave bug tracking database: > Class/File: stdcomp.h > Fix Priority: Can Fix > Long Description: > *** Dec 1 1999 6:03PM *** sebor *** > A request for enhancement. > Subject: define RWSTD_NO_EXCEPTIONS when __HPACC_NOEH is > Date: Wed, 01 Dec 1999 17:11:36 -0800 > From: Chichiang Wan <[EMAIL PROTECTED]> > Organization: California Language Labs > To: oemsupport <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], wanc_at_hp <[EMAIL PROTECTED]> > aCC has an option +noeh. When it is provided, __HPACC_NOEH will be > defined. It would be nice for users to need to only use +noeh. For > that, > RWSTD_NO_EXCEPTIONS needs to be defined conditionally. > = > $ cat test.C > #include > $ aCC +noeh -c test.C > Error 46: "/opt/aCC/include/memory", line 493 # Exception handling is > not > enabled (do not use the +noeh flag to aCC). > RWSTD_THROW_NO_MSG(tmp == 0, bad_alloc); > -- Chichiang > Modified By: sebor @ May 29, 2000 10:28:25 PM > We should do this AND test it -- not just on aCC but in general with all > compilers that support this feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-681) Test suite and example programs don't compile on platforms that don't support exceptions
Test suite and example programs don't compile on platforms that don't support exceptions Key: STDCXX-681 URL: https://issues.apache.org/jira/browse/STDCXX-681 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Reporter: Travis Vitek Priority: Minor Many of the test programs don't compile if _RWSTD_NO_EXCEPTIONS is defined. All of our primary and secondary platforms support exceptions by default, but this support can usually be disabled with a command line argument to the compiler. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-240) #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line option
[ https://issues.apache.org/jira/browse/STDCXX-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-240: Attachment: (was: stdcxx-240.patch) > #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line > option > - > > Key: STDCXX-240 > URL: https://issues.apache.org/jira/browse/STDCXX-240 > Project: C++ Standard Library > Issue Type: Improvement > Components: Build >Affects Versions: 4.1.2, 4.1.3, 4.1.4 >Reporter: Martin Sebor >Assignee: Travis Vitek >Priority: Minor > Fix For: 4.2.1 > > > Moved from the Rogue Wave bug tracking database: > Class/File: stdcomp.h > Fix Priority: Can Fix > Long Description: > *** Dec 1 1999 6:03PM *** sebor *** > A request for enhancement. > Subject: define RWSTD_NO_EXCEPTIONS when __HPACC_NOEH is > Date: Wed, 01 Dec 1999 17:11:36 -0800 > From: Chichiang Wan <[EMAIL PROTECTED]> > Organization: California Language Labs > To: oemsupport <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], wanc_at_hp <[EMAIL PROTECTED]> > aCC has an option +noeh. When it is provided, __HPACC_NOEH will be > defined. It would be nice for users to need to only use +noeh. For > that, > RWSTD_NO_EXCEPTIONS needs to be defined conditionally. > = > $ cat test.C > #include > $ aCC +noeh -c test.C > Error 46: "/opt/aCC/include/memory", line 493 # Exception handling is > not > enabled (do not use the +noeh flag to aCC). > RWSTD_THROW_NO_MSG(tmp == 0, bad_alloc); > -- Chichiang > Modified By: sebor @ May 29, 2000 10:28:25 PM > We should do this AND test it -- not just on aCC but in general with all > compilers that support this feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-240) #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line option
[ https://issues.apache.org/jira/browse/STDCXX-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552501 ] Travis Vitek commented on STDCXX-240: - Some of the compilers handle disabling of exceptions differently. With AIX, the keywords remain valid, and are expected in some contexts. The warnings shown above seem inconsistent as one message says the throw spec is missing, and then the next says the exception spec is being ignored. A simple testcase shows that this is the case. So I need to disable exception usage in the library, but I need to leave the exception specs for at least one platform. > #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line > option > - > > Key: STDCXX-240 > URL: https://issues.apache.org/jira/browse/STDCXX-240 > Project: C++ Standard Library > Issue Type: Improvement > Components: Build >Affects Versions: 4.1.2, 4.1.3, 4.1.4 >Reporter: Martin Sebor >Assignee: Travis Vitek >Priority: Minor > Fix For: 4.2.1 > > Attachments: stdcxx-240.patch > > > Moved from the Rogue Wave bug tracking database: > Class/File: stdcomp.h > Fix Priority: Can Fix > Long Description: > *** Dec 1 1999 6:03PM *** sebor *** > A request for enhancement. > Subject: define RWSTD_NO_EXCEPTIONS when __HPACC_NOEH is > Date: Wed, 01 Dec 1999 17:11:36 -0800 > From: Chichiang Wan <[EMAIL PROTECTED]> > Organization: California Language Labs > To: oemsupport <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], wanc_at_hp <[EMAIL PROTECTED]> > aCC has an option +noeh. When it is provided, __HPACC_NOEH will be > defined. It would be nice for users to need to only use +noeh. For > that, > RWSTD_NO_EXCEPTIONS needs to be defined conditionally. > = > $ cat test.C > #include > $ aCC +noeh -c test.C > Error 46: "/opt/aCC/include/memory", line 493 # Exception handling is > not > enabled (do not use the +noeh flag to aCC). > RWSTD_THROW_NO_MSG(tmp == 0, bad_alloc); > -- Chichiang > Modified By: sebor @ May 29, 2000 10:28:25 PM > We should do this AND test it -- not just on aCC but in general with all > compilers that support this feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-524) buffer overflow in test 22.locale.time.get.cpp(make_LC_TIME)
[ https://issues.apache.org/jira/browse/STDCXX-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-524: Patch Info: [Patch Available] > buffer overflow in test 22.locale.time.get.cpp(make_LC_TIME) > > > Key: STDCXX-524 > URL: https://issues.apache.org/jira/browse/STDCXX-524 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.1.2, 4.1.3, 4.1.4 >Reporter: Travis Vitek >Assignee: Travis Vitek >Priority: Trivial > Fix For: 4.2.1 > > Attachments: stdcxx-524.patch > > > This test uses L_tmpnam to determine the length of a buffer used to store a > filename string. Unfortunately, L_tmpnam is intended for use with tmpnam(), > but the buffer is written to with std::sprintf(). When I run the test, the > allocated buffer is 46 bytes, and the sprintf() call writes 58 bytes [this > will vary based on user name and other variables]. Perhaps the buffer should > be made larger, or some other method should be used to fill the buffer. > Perhaps this would work. > #if !defined (_WIN32) && !defined (_WIN64) > # define _PATH_MAX PATH_MAX > #else > # define _PATH_MAX _MAX_PATH > #endif > char srcfname [_PATH_MAX]; // [L_tmpnam + 32]; > std::sprintf (srcfname, "%s" SLASH "LC_TIME.src", locale_root); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-664) [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
[
https://issues.apache.org/jira/browse/STDCXX-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552491
]
Travis Vitek commented on STDCXX-664:
-
Well, there is currently no need to check opt_no_exceptions inside
test_has_facet() because has_facet() doesn't throw if a facet is not installed,
it just returns false. The test_has_facet() test doesn't check the return from
has_facet(), so it doesn't detect the error.
I'm thinking that this test should be checking the return from has_facet(). We
don't appear to have a single-threaded test that checks the result of
has_facet() matches expectations, and we should. One argument against doing so
here is that this is a multithreading test.
> [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
> ---
>
> Key: STDCXX-664
> URL: https://issues.apache.org/jira/browse/STDCXX-664
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2.0
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: stdcxx-664-1.patch, stdcxx-664-2.patch
>
>
> Appears to affect single-threaded bulids only.
> [EMAIL PROTECTED] tests]$ ./22.locale.globals.mt
> # INFO (S1) (10 lines):
> # TEXT:
> # COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
> # ENVIRONMENT: powerpc running aix-5.3
> # FILE: 22.locale.globals.mt.cpp
> # COMPILED: Nov 8 2007, 21:35:16
> # COMMENT: thread safety
>
> # CLAUSE: lib.locale.global.templates
> # NOTE (S2) (5 lines):
> # TEXT: executing "locale -a > /tmp/tmpfile-fK3jqa"
> # CLAUSE: lib.locale.global.templates
> # FILE: process.cpp
> # LINE: 270
> # INFO (S1) (3 lines):
> # TEXT: testing std::locale globals with 1 thread, 2 iterations each, in
> 16 locales { "C" "POSIX" "AR_DZ.UTF-8" "AR_BH" "AR_AA.UTF-8" "AR_BH.UTF-8"
> "AR_AE.UTF-8" "AR_DZ" "AR_EG.UTF-8" "AR_EG" "AR_AE" "AR_AA" "AR_JO"
> "AR_JO.UTF-8" "AR_KW" "AR_KW.UTF-8" }
> # CLAUSE: lib.locale.global.templates
> # INFO (S1) (3 lines):
> # TEXT: template bool std::has_facet (const locale&)
> # CLAUSE: lib.locale.global.templates
> # INFO (S1) (3 lines):
> # TEXT: template const T& std::use_facet (const locale&)
> # CLAUSE: lib.locale.global.templates
> # WARNING (S5) (3 lines):
> # TEXT: exceptions not thread safe, skipping that part of test
> # CLAUSE: lib.locale.global.templates
> /amd/devco/vitek/stdcxx-trunk/tests/localization/22.locale.globals.mt.cpp:311:
> use_facet_loop: Assertion 'threw || opt_facets [opt_inx_collate] < 0' failed.
> IOT/Abort trap (core dumped)
> [EMAIL PROTECTED] tests]$
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-664) [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
[
https://issues.apache.org/jira/browse/STDCXX-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Vitek updated STDCXX-664:
Patch Info: [Patch Available]
> [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
> ---
>
> Key: STDCXX-664
> URL: https://issues.apache.org/jira/browse/STDCXX-664
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2.0
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: stdcxx-664-1.patch, stdcxx-664-2.patch
>
>
> Appears to affect single-threaded bulids only.
> [EMAIL PROTECTED] tests]$ ./22.locale.globals.mt
> # INFO (S1) (10 lines):
> # TEXT:
> # COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
> # ENVIRONMENT: powerpc running aix-5.3
> # FILE: 22.locale.globals.mt.cpp
> # COMPILED: Nov 8 2007, 21:35:16
> # COMMENT: thread safety
>
> # CLAUSE: lib.locale.global.templates
> # NOTE (S2) (5 lines):
> # TEXT: executing "locale -a > /tmp/tmpfile-fK3jqa"
> # CLAUSE: lib.locale.global.templates
> # FILE: process.cpp
> # LINE: 270
> # INFO (S1) (3 lines):
> # TEXT: testing std::locale globals with 1 thread, 2 iterations each, in
> 16 locales { "C" "POSIX" "AR_DZ.UTF-8" "AR_BH" "AR_AA.UTF-8" "AR_BH.UTF-8"
> "AR_AE.UTF-8" "AR_DZ" "AR_EG.UTF-8" "AR_EG" "AR_AE" "AR_AA" "AR_JO"
> "AR_JO.UTF-8" "AR_KW" "AR_KW.UTF-8" }
> # CLAUSE: lib.locale.global.templates
> # INFO (S1) (3 lines):
> # TEXT: template bool std::has_facet (const locale&)
> # CLAUSE: lib.locale.global.templates
> # INFO (S1) (3 lines):
> # TEXT: template const T& std::use_facet (const locale&)
> # CLAUSE: lib.locale.global.templates
> # WARNING (S5) (3 lines):
> # TEXT: exceptions not thread safe, skipping that part of test
> # CLAUSE: lib.locale.global.templates
> /amd/devco/vitek/stdcxx-trunk/tests/localization/22.locale.globals.mt.cpp:311:
> use_facet_loop: Assertion 'threw || opt_facets [opt_inx_collate] < 0' failed.
> IOT/Abort trap (core dumped)
> [EMAIL PROTECTED] tests]$
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-680) use_facet and has_facet are unreliable unless dynamic_cast is available
use_facet and has_facet are unreliable unless dynamic_cast is available --- Key: STDCXX-680 URL: https://issues.apache.org/jira/browse/STDCXX-680 Project: C++ Standard Library Issue Type: Bug Components: 22. Localization Affects Versions: 4.2.0 Reporter: Travis Vitek The function that is called by has_facet<>() and use_facet<>() uses _RWSTD_DYNAMIC_CAST in an attempt to check that the returned locale facet is of the requested type. Unfortunately, if RTTI is not supported or enabled, that cast becomes unreliable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-605: Attachment: stdcxx-605.patch Updated patch again. I could get away with only one of the overloads being const. I went ahead and made both of them non-const and now call them from the non-const conversion operator. The const conversion operator does just what it always did, it casts away const and calls the other conversion operator. I think this resolves both of your issues, and reduces the footprint of the changes. According to the style guide, there isn't supposed to be a space between a template parameter list and an opening paren, so I have omitted them in the code that I have added. There is existing code in this example that has whitespace there, I have opted to leave the existing code as-is. > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-605.patch > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-605: Attachment: (was: stdcxx-605.patch) > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- 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-664) [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
[ https://issues.apache.org/jira/browse/STDCXX-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551612 ] vitek edited comment on STDCXX-664 at 12/13/07 1:50 PM: --- Darn. My 'fix' would fail that test. It would not allow the ctype<> facet to be returned when the ctype_byname<> facet is requested, but it would return a ctype_byname facet when the user wanted a derived facet type. Well, I don't really have a preference for adding or not adding the rtti option. If we do add it, the user can easily override it by setting CXXOPTS=-qrtti=none when they invoke make. In case anyone is interested, here are the library and binary sizes for 11s and 12d builds both with and without the rtti flag. The last column is the change in size as a percentage of the original [i.e. percent growth]. rtti nortti growth libstd11s.a 7668238 7558127 1.46% accumulate4676042 4610870 1.41% adj_diff 4703018 4637972 1.40% advance 4670361 4605133 1.42% alg1 5076890 5008162 1.37% alg2 4893849 4828789 1.35% alg3 4957347 4892395 1.33% alg4 4904490 4839376 1.35% alg5 4706968 4641246 1.42% alg6 4781295 4716161 1.38% alg7 5233717 5168485 1.26% auto_ptr 4592689 4527693 1.44% binary_search 4835486 4770284 1.37% binders 4684042 4618862 1.41% bitset4601831 4536763 1.43% calc 4728289 4663095 1.40% codecvt 4610735 4543893 1.47% codecvt1 4606640 4540990 1.45% collate 4608657 4542807 1.45% complex 4733931 4664899 1.48% complx4708134 4639364 1.48% concord 5426332 5360742 1.22% copyex4709732 4644618 1.40% count 4698872 4633690 1.41% ctype 4595625 4529997 1.45% deque 5017853 4952769 1.31% distance 4692233 4627125 1.41% rtti nortti growth libstd12d.20 1841390 1826109 0.84% accumulate 3211531838 0.87% adj_diff3535035111 0.68% advance 3166531403 0.83% alg16249762792 -0.47% alg26418060571 5.96% alg38021478731 1.88% alg45437854114 0.49% alg54362540537 7.62% alg64607146050 0.05% alg7 122826 121773 0.86% auto_ptr2580125537 1.03% binary_search 5571955725 -0.01% binders 3137131092 0.90% bitset 2341023424 -0.06% calc5140939504 30.14% codecvt 3624636228 0.05% codecvt13008330089 -0.02% collate 2723327241 -0.03% complex 8735687068 0.33% complx 6382363359 0.73% concord 8449884504 -0.01% copyex 3538235077 0.87% count 3120531162 0.14% ctype 2437624358 0.07% deque 5088550751 0.26% distance2977829775 0.01% I'm attaching two seperate patches. The first patch disables the failing portion of this test when _RWSTD_NO_DYNAMIC_CAST is defined. The second patch is optional and adds the appropriate command line argument to add the minimum necessary rtti support with the VisualAge compiler versions 6, 7, 8 and 9. 2007-12-13 Travis Vitek <[EMAIL PROTECTED]> STDCXX-664 * tests/localization/22.locale.globals.mt.cpp (run_test): Avoid testing that use_facet<>() throws when using byname facets when _RWSTD_NO_DYNAMIC_CAST is defined. 2007-12-13 Travis Vitek <[EMAIL PROTECTED]> STDCXX-664 * etc/config/vacpp.config: Add -qrtti=dynamiccast flag to enable dynamic_cast support. was (Author: vitek): Darn. My 'fix' would fail that test. It would not allow the ctype<> facet to be returned when the ctype_byname<> facet is requested, but it would return a ctype_byname facet when the user wanted a derived facet type. Well, I don't really have a preference for adding or not adding the rtti option. If we do add it, the user can easily override it by setting CXXOPTS=-qrtti=none when they invoke make. In case anyone is interested, here are the library and binary sizes for 11s and 12d builds both with and without the rtti flag. The last column is the change in size as a percentage of the original [i.e. percent growth]. rtti nortti growth libstd11s.a 7668238 7558127 1.46% accumulate4676042 4610
[jira] Commented: (STDCXX-524) buffer overflow in test 22.locale.time.get.cpp(make_LC_TIME)
[ https://issues.apache.org/jira/browse/STDCXX-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551618 ] Travis Vitek commented on STDCXX-524: - That was my original plan, but I decided against it. I mention this above, but it is worth repeating. I'm attempting to avoid memory in use at program exit. > buffer overflow in test 22.locale.time.get.cpp(make_LC_TIME) > > > Key: STDCXX-524 > URL: https://issues.apache.org/jira/browse/STDCXX-524 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.1.2, 4.1.3, 4.1.4 >Reporter: Travis Vitek >Assignee: Travis Vitek >Priority: Trivial > Fix For: 4.2.1 > > Attachments: stdcxx-524.patch > > > This test uses L_tmpnam to determine the length of a buffer used to store a > filename string. Unfortunately, L_tmpnam is intended for use with tmpnam(), > but the buffer is written to with std::sprintf(). When I run the test, the > allocated buffer is 46 bytes, and the sprintf() call writes 58 bytes [this > will vary based on user name and other variables]. Perhaps the buffer should > be made larger, or some other method should be used to fill the buffer. > Perhaps this would work. > #if !defined (_WIN32) && !defined (_WIN64) > # define _PATH_MAX PATH_MAX > #else > # define _PATH_MAX _MAX_PATH > #endif > char srcfname [_PATH_MAX]; // [L_tmpnam + 32]; > std::sprintf (srcfname, "%s" SLASH "LC_TIME.src", locale_root); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-664) [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
[
https://issues.apache.org/jira/browse/STDCXX-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Vitek updated STDCXX-664:
Attachment: stdcxx-664-2.patch
This is the correct patch.
> [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
> ---
>
> Key: STDCXX-664
> URL: https://issues.apache.org/jira/browse/STDCXX-664
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2.0
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: stdcxx-664-1.patch, stdcxx-664-2.patch
>
>
> Appears to affect single-threaded bulids only.
> [EMAIL PROTECTED] tests]$ ./22.locale.globals.mt
> # INFO (S1) (10 lines):
> # TEXT:
> # COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
> # ENVIRONMENT: powerpc running aix-5.3
> # FILE: 22.locale.globals.mt.cpp
> # COMPILED: Nov 8 2007, 21:35:16
> # COMMENT: thread safety
>
> # CLAUSE: lib.locale.global.templates
> # NOTE (S2) (5 lines):
> # TEXT: executing "locale -a > /tmp/tmpfile-fK3jqa"
> # CLAUSE: lib.locale.global.templates
> # FILE: process.cpp
> # LINE: 270
> # INFO (S1) (3 lines):
> # TEXT: testing std::locale globals with 1 thread, 2 iterations each, in
> 16 locales { "C" "POSIX" "AR_DZ.UTF-8" "AR_BH" "AR_AA.UTF-8" "AR_BH.UTF-8"
> "AR_AE.UTF-8" "AR_DZ" "AR_EG.UTF-8" "AR_EG" "AR_AE" "AR_AA" "AR_JO"
> "AR_JO.UTF-8" "AR_KW" "AR_KW.UTF-8" }
> # CLAUSE: lib.locale.global.templates
> # INFO (S1) (3 lines):
> # TEXT: template bool std::has_facet (const locale&)
> # CLAUSE: lib.locale.global.templates
> # INFO (S1) (3 lines):
> # TEXT: template const T& std::use_facet (const locale&)
> # CLAUSE: lib.locale.global.templates
> # WARNING (S5) (3 lines):
> # TEXT: exceptions not thread safe, skipping that part of test
> # CLAUSE: lib.locale.global.templates
> /amd/devco/vitek/stdcxx-trunk/tests/localization/22.locale.globals.mt.cpp:311:
> use_facet_loop: Assertion 'threw || opt_facets [opt_inx_collate] < 0' failed.
> IOT/Abort trap (core dumped)
> [EMAIL PROTECTED] tests]$
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-664) [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
[
https://issues.apache.org/jira/browse/STDCXX-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Vitek updated STDCXX-664:
Attachment: (was: stdcxx-664v2.patch)
> [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
> ---
>
> Key: STDCXX-664
> URL: https://issues.apache.org/jira/browse/STDCXX-664
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2.0
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: stdcxx-664-1.patch
>
>
> Appears to affect single-threaded bulids only.
> [EMAIL PROTECTED] tests]$ ./22.locale.globals.mt
> # INFO (S1) (10 lines):
> # TEXT:
> # COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
> # ENVIRONMENT: powerpc running aix-5.3
> # FILE: 22.locale.globals.mt.cpp
> # COMPILED: Nov 8 2007, 21:35:16
> # COMMENT: thread safety
>
> # CLAUSE: lib.locale.global.templates
> # NOTE (S2) (5 lines):
> # TEXT: executing "locale -a > /tmp/tmpfile-fK3jqa"
> # CLAUSE: lib.locale.global.templates
> # FILE: process.cpp
> # LINE: 270
> # INFO (S1) (3 lines):
> # TEXT: testing std::locale globals with 1 thread, 2 iterations each, in
> 16 locales { "C" "POSIX" "AR_DZ.UTF-8" "AR_BH" "AR_AA.UTF-8" "AR_BH.UTF-8"
> "AR_AE.UTF-8" "AR_DZ" "AR_EG.UTF-8" "AR_EG" "AR_AE" "AR_AA" "AR_JO"
> "AR_JO.UTF-8" "AR_KW" "AR_KW.UTF-8" }
> # CLAUSE: lib.locale.global.templates
> # INFO (S1) (3 lines):
> # TEXT: template bool std::has_facet (const locale&)
> # CLAUSE: lib.locale.global.templates
> # INFO (S1) (3 lines):
> # TEXT: template const T& std::use_facet (const locale&)
> # CLAUSE: lib.locale.global.templates
> # WARNING (S5) (3 lines):
> # TEXT: exceptions not thread safe, skipping that part of test
> # CLAUSE: lib.locale.global.templates
> /amd/devco/vitek/stdcxx-trunk/tests/localization/22.locale.globals.mt.cpp:311:
> use_facet_loop: Assertion 'threw || opt_facets [opt_inx_collate] < 0' failed.
> IOT/Abort trap (core dumped)
> [EMAIL PROTECTED] tests]$
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-664) [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
[ https://issues.apache.org/jira/browse/STDCXX-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-664: Attachment: stdcxx-664v2.patch stdcxx-664-1.patch Darn. My 'fix' would fail that test. It would not allow the ctype<> facet to be returned when the ctype_byname<> facet is requested, but it would return a ctype_byname facet when the user wanted a derived facet type. Well, I don't really have a preference for adding or not adding the rtti option. If we do add it, the user can easily override it by setting CXXOPTS=-qrtti=none when they invoke make. In case anyone is interested, here are the library and binary sizes for 11s and 12d builds both with and without the rtti flag. The last column is the change in size as a percentage of the original [i.e. percent growth]. rtti nortti growth libstd11s.a 7668238 7558127 1.46% accumulate4676042 4610870 1.41% adj_diff 4703018 4637972 1.40% advance 4670361 4605133 1.42% alg1 5076890 5008162 1.37% alg2 4893849 4828789 1.35% alg3 4957347 4892395 1.33% alg4 4904490 4839376 1.35% alg5 4706968 4641246 1.42% alg6 4781295 4716161 1.38% alg7 5233717 5168485 1.26% auto_ptr 4592689 4527693 1.44% binary_search 4835486 4770284 1.37% binders 4684042 4618862 1.41% bitset4601831 4536763 1.43% calc 4728289 4663095 1.40% codecvt 4610735 4543893 1.47% codecvt1 4606640 4540990 1.45% collate 4608657 4542807 1.45% complex 4733931 4664899 1.48% complx4708134 4639364 1.48% concord 5426332 5360742 1.22% copyex4709732 4644618 1.40% count 4698872 4633690 1.41% ctype 4595625 4529997 1.45% deque 5017853 4952769 1.31% distance 4692233 4627125 1.41% rtti nortti growth libstd12d.20 1841390 1826109 0.84% accumulate 3211531838 0.87% adj_diff3535035111 0.68% advance 3166531403 0.83% alg16249762792 -0.47% alg26418060571 5.96% alg38021478731 1.88% alg45437854114 0.49% alg54362540537 7.62% alg64607146050 0.05% alg7 122826 121773 0.86% auto_ptr2580125537 1.03% binary_search 5571955725 -0.01% binders 3137131092 0.90% bitset 2341023424 -0.06% calc5140939504 30.14% codecvt 3624636228 0.05% codecvt13008330089 -0.02% collate 2723327241 -0.03% complex 8735687068 0.33% complx 6382363359 0.73% concord 8449884504 -0.01% copyex 3538235077 0.87% count 3120531162 0.14% ctype 2437624358 0.07% deque 5088550751 0.26% distance2977829775 0.01% I'm attaching two seperate patches. The first patch disables the failing portion of this test when _RWSTD_NO_DYNAMIC_CAST is defined. The second patch is optional and adds the appropriate command line argument to add the minimum necessary rtti support with the VisualAge compiler versions 6, 7, 8 and 9. 2007/12/13 Travis Vitek <[EMAIL PROTECTED]> STDCXX-664 * tests/localization/22.locale.globals.mt.cpp (run_test): Avoid testing that use_facet<>() throws when using byname facets when _RWSTD_NO_DYNAMIC_CAST is defined. 2007/12/13 Travis Vitek <[EMAIL PROTECTED]> STDCXX-664 * etc/config/vacpp.config: Add -qrtti=dynamiccast flag to enable dynamic_cast support. > [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt > --- > > Key: STDCXX-664 > URL: https://issues.apache.org/jira/browse/STDCXX-664 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 >Reporter: Travis Vitek >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-664-1.patch > > > Appears to affect single-threaded bulids only. > [EMAIL PROTECTED] tests]$ ./22.locale.globals.mt > # INFO (S1) (10 lines): > # TEXT: > # COMPILER: IBM VisualAge C++, __IBMCPP__ = 900 > # ENVIRONMENT: powerpc running aix-5.3 > # FILE: 22.locale.globals.mt.cpp > # COMPILED: Nov 8 20
[jira] Commented: (STDCXX-664) [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
[
https://issues.apache.org/jira/browse/STDCXX-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551171
]
Travis Vitek commented on STDCXX-664:
-
The actual problem is that rtti isn't enabled by default on this compiler, so
the _RWSTD_DYNAMIC_CAST() function macro that is used in _locale.h boils down
to a flat C style pointer cast, which will always succeed, even if the types
are totally unrelated. The routine currently requires that the dynamic_cast
operator be defined and work correctly, and this is obviously not the case.
I see two options to fix this. The simple option is to enable RTTI
[-qrtti=dynamiccast or -qrtti=all]. The second option is to add
__rw_get_facet_by_id() overloads for each of the _byname facets. These
overloads would either avoid creating a _byname facet for the classic locale,
or would fail after creating/retrieving a non-byname facet.
> [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
> ---
>
> Key: STDCXX-664
> URL: https://issues.apache.org/jira/browse/STDCXX-664
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2.0
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
>
> Appears to affect single-threaded bulids only.
> [EMAIL PROTECTED] tests]$ ./22.locale.globals.mt
> # INFO (S1) (10 lines):
> # TEXT:
> # COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
> # ENVIRONMENT: powerpc running aix-5.3
> # FILE: 22.locale.globals.mt.cpp
> # COMPILED: Nov 8 2007, 21:35:16
> # COMMENT: thread safety
>
> # CLAUSE: lib.locale.global.templates
> # NOTE (S2) (5 lines):
> # TEXT: executing "locale -a > /tmp/tmpfile-fK3jqa"
> # CLAUSE: lib.locale.global.templates
> # FILE: process.cpp
> # LINE: 270
> # INFO (S1) (3 lines):
> # TEXT: testing std::locale globals with 1 thread, 2 iterations each, in
> 16 locales { "C" "POSIX" "AR_DZ.UTF-8" "AR_BH" "AR_AA.UTF-8" "AR_BH.UTF-8"
> "AR_AE.UTF-8" "AR_DZ" "AR_EG.UTF-8" "AR_EG" "AR_AE" "AR_AA" "AR_JO"
> "AR_JO.UTF-8" "AR_KW" "AR_KW.UTF-8" }
> # CLAUSE: lib.locale.global.templates
> # INFO (S1) (3 lines):
> # TEXT: template bool std::has_facet (const locale&)
> # CLAUSE: lib.locale.global.templates
> # INFO (S1) (3 lines):
> # TEXT: template const T& std::use_facet (const locale&)
> # CLAUSE: lib.locale.global.templates
> # WARNING (S5) (3 lines):
> # TEXT: exceptions not thread safe, skipping that part of test
> # CLAUSE: lib.locale.global.templates
> /amd/devco/vitek/stdcxx-trunk/tests/localization/22.locale.globals.mt.cpp:311:
> use_facet_loop: Assertion 'threw || opt_facets [opt_inx_collate] < 0' failed.
> IOT/Abort trap (core dumped)
> [EMAIL PROTECTED] tests]$
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-524) buffer overflow in test 22.locale.time.get.cpp(make_LC_TIME)
[ https://issues.apache.org/jira/browse/STDCXX-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-524: Attachment: stdcxx-524.patch 2007/12/12 Travis Vitek <[EMAIL PROTECTED]> STDCXX-524 * tests/localization/22.locale.codecvt.length.cpp (create_locale): Check return code from rw_snprintf(). * tests/localization/22.locale.codecvt.out.cpp (create_locale): Ditto. * tests/localization/22.locale.time.get.cpp (make_LC_TIME): Ditto. Use rw_snprintf() instead of sprintf(), use larger fixed buffer sizes. * tests/localization/22.locale.time.put.cpp (make_LC_TIME): Ditto. * src/locale.cpp (): Ditto. > buffer overflow in test 22.locale.time.get.cpp(make_LC_TIME) > > > Key: STDCXX-524 > URL: https://issues.apache.org/jira/browse/STDCXX-524 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.1.2, 4.1.3, 4.1.4 >Reporter: Travis Vitek >Assignee: Travis Vitek >Priority: Trivial > Fix For: 4.2.1 > > Attachments: stdcxx-524.patch > > > This test uses L_tmpnam to determine the length of a buffer used to store a > filename string. Unfortunately, L_tmpnam is intended for use with tmpnam(), > but the buffer is written to with std::sprintf(). When I run the test, the > allocated buffer is 46 bytes, and the sprintf() call writes 58 bytes [this > will vary based on user name and other variables]. Perhaps the buffer should > be made larger, or some other method should be used to fill the buffer. > Perhaps this would work. > #if !defined (_WIN32) && !defined (_WIN64) > # define _PATH_MAX PATH_MAX > #else > # define _PATH_MAX _MAX_PATH > #endif > char srcfname [_PATH_MAX]; // [L_tmpnam + 32]; > std::sprintf (srcfname, "%s" SLASH "LC_TIME.src", locale_root); -- 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:
Patch Info: [Patch Available]
> [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-524) buffer overflow in test 22.locale.time.get.cpp(make_LC_TIME)
[ https://issues.apache.org/jira/browse/STDCXX-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-524: Attachment: (was: stdcxx-524.patch) > buffer overflow in test 22.locale.time.get.cpp(make_LC_TIME) > > > Key: STDCXX-524 > URL: https://issues.apache.org/jira/browse/STDCXX-524 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.1.2, 4.1.3, 4.1.4 >Reporter: Travis Vitek >Assignee: Travis Vitek >Priority: Trivial > Fix For: 4.2.1 > > > This test uses L_tmpnam to determine the length of a buffer used to store a > filename string. Unfortunately, L_tmpnam is intended for use with tmpnam(), > but the buffer is written to with std::sprintf(). When I run the test, the > allocated buffer is 46 bytes, and the sprintf() call writes 58 bytes [this > will vary based on user name and other variables]. Perhaps the buffer should > be made larger, or some other method should be used to fill the buffer. > Perhaps this would work. > #if !defined (_WIN32) && !defined (_WIN64) > # define _PATH_MAX PATH_MAX > #else > # define _PATH_MAX _MAX_PATH > #endif > char srcfname [_PATH_MAX]; // [L_tmpnam + 32]; > std::sprintf (srcfname, "%s" SLASH "LC_TIME.src", locale_root); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-605: Attachment: stdcxx-605.patch Thank you Martin for pointing me in the right direction here. This fix is fairly simple and makes me happy. 2007-12-12 Travis Vitek <[EMAIL PROTECTED]> STDCXX-605 * examples/tutorial/dynatype.cpp: Add overloaded method to discard const to avoid looking for value in wrong map when non-const conversion operator is used with a const type T. (main): Display text and converted value in two seperate statements so we can guarantee that output is generated the same on all compilers. Add a return 0 for correctness. * examples/tutorial/out/dynatype.out: Update output file to match expected output format. > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-605.patch > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-605: Attachment: (was: stdcxx-605.patch) > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- 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] Commented: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550251 ] Travis Vitek commented on STDCXX-605: - 1. Yes, all of this is because of the compiler bug. As it turns out, a similar problem exists for some builds on VC7.1. 2. I think I can do it, but the only way I can come up with involves quite a bit of template metaprogramming and that adds a lot of complication to the example. Perhaps I'm persuing the wrong method? If not, I'd hope that we could come up with a simpler solution. I'd almost prefer to use named methods for doing the conversions. 3. Fine. 4. I'll file another bug on that issue. I've wasted enough time on this particular goose-chase already. > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-605.patch > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-664) [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
[
https://issues.apache.org/jira/browse/STDCXX-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550136
]
Travis Vitek commented on STDCXX-664:
-
The issue is that somehow the classic locale on AIX actually seems to have the
_byname facets installed. The following testcase demonstrates.
[EMAIL PROTECTED] tests]$ cat t.cpp
#include
#include
int main ()
{
#define TEST(Facet) \
try { \
std::use_facet(classic); \
fprintf (stderr, "found facet %s in locale %s\n", \
#Facet, classic.name ().c_str ()); \
} \
catch (...) { \
}
const std::locale classic (std::locale::classic ());
typedef std::ctype_byname ctype_byname;
TEST (ctype_byname);
typedef std::collate_byname collate_byname;
TEST (collate_byname);
typedef std::messages_byname messages_byname;
TEST (messages_byname);
typedef std::numpunct_byname numpunct_byname;
TEST (numpunct_byname);
typedef std::time_get_byname time_get_byname;
TEST (time_get_byname);
typedef std::time_put_byname time_put_byname;
TEST (time_put_byname);
return 0;
}
> [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
> ---
>
> Key: STDCXX-664
> URL: https://issues.apache.org/jira/browse/STDCXX-664
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2.0
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
>
> Appears to affect single-threaded bulids only.
> [EMAIL PROTECTED] tests]$ ./22.locale.globals.mt
> # INFO (S1) (10 lines):
> # TEXT:
> # COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
> # ENVIRONMENT: powerpc running aix-5.3
> # FILE: 22.locale.globals.mt.cpp
> # COMPILED: Nov 8 2007, 21:35:16
> # COMMENT: thread safety
>
> # CLAUSE: lib.locale.global.templates
> # NOTE (S2) (5 lines):
> # TEXT: executing "locale -a > /tmp/tmpfile-fK3jqa"
> # CLAUSE: lib.locale.global.templates
> # FILE: process.cpp
> # LINE: 270
> # INFO (S1) (3 lines):
> # TEXT: testing std::locale globals with 1 thread, 2 iterations each, in
> 16 locales { "C" "POSIX" "AR_DZ.UTF-8" "AR_BH" "AR_AA.UTF-8" "AR_BH.UTF-8"
> "AR_AE.UTF-8" "AR_DZ" "AR_EG.UTF-8" "AR_EG" "AR_AE" "AR_AA" "AR_JO"
> "AR_JO.UTF-8" "AR_KW" "AR_KW.UTF-8" }
> # CLAUSE: lib.locale.global.templates
> # INFO (S1) (3 lines):
> # TEXT: template bool std::has_facet (const locale&)
> # CLAUSE: lib.locale.global.templates
> # INFO (S1) (3 lines):
> # TEXT: template const T& std::use_facet (const locale&)
> # CLAUSE: lib.locale.global.templates
> # WARNING (S5) (3 lines):
> # TEXT: exceptions not thread safe, skipping that part of test
> # CLAUSE: lib.locale.global.templates
> /amd/devco/vitek/stdcxx-trunk/tests/localization/22.locale.globals.mt.cpp:311:
> use_facet_loop: Assertion 'threw || opt_facets [opt_inx_collate] < 0' failed.
> IOT/Abort trap (core dumped)
> [EMAIL PROTECTED] tests]$
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549606 ] Travis Vitek commented on STDCXX-605: - 1. The original code casted to values. We can't cast to values, unless you'd like to cast to a reference first, then cast the result to a value. Of course that is already happening behind the scenes, so I see no reason to be so explicit unless required. 2. I'm assuming that you'd rather see `static_cast(v1)' over `static_cast(v1)'. If that is the case, then yes, I'd like to cast to const references also. Unfortunately you can't because `const T' is a different type than `T' when it comes to templates. The non-const template conversion operator gets invoked, and the dynatype tries to look itself up in the map, which fails, and throws an exception. I could const_cast the dynatype, then cast that, but that is even more hideous that what I've got now... std::cout << "double (v2 = v1) = " << static_cast(const_cast(v2)) << std::endl; I started to write named helper methods (get<>, get_ref<>, get_cref<>) to retrieve the value after applying the cast, but that seemed wrong because the `dynatype' is supposed to look and feel just like an object of type T, and adding special functions to make it behave that way seems wrong. 3. Are you saying you want me to modify the output spew to match the code, like so... std::cout << "static_cast(v2 = v1) = " << static_cast(v2) << std::endl; 4. The output is slightly different between AIX and Linux. Linux/GCC appear to evaluate all of the arguments before calling the stream functions, and AIX/VisualAgeC++ seem to invoke the arguments as they are needed. This causes a diff in the output, which will probably be flagged as a failure. Should I fix this also? > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-605.patch > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- 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-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549576 ] vitek edited comment on STDCXX-605 at 12/7/07 2:23 PM: -- New and improved. Hopefully approved. 2007-12-06 Travis Vitek <[EMAIL PROTECTED]> STDCXX-605 * examples/tutorial/dynatype.cpp (main): Explicit cast to correct type to avoid issues on IBM VisualAge C++. Use static_cast for consistency with existing example code. was (Author: vitek): New and improved. Hopefully approved. 2007-12-06 Travis Vitek <[EMAIL PROTECTED]> STDCXX-605 * tutorial/dynatype.cpp (main): Explicit cast to correct type to avoid issues on IBM VisualAge C++. Use static_cast for consistency with other parts of the example. > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-605.patch > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-605: Attachment: stdcxx-605.patch New and improved. Hopefully approved. 2007-12-06 Travis Vitek <[EMAIL PROTECTED]> STDCXX-605 * tutorial/dynatype.cpp (main): Explicit cast to correct type to avoid issues on IBM VisualAge C++. Use static_cast for consistency with other parts of the example. > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-605.patch > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-605: Attachment: (was: stdcxx-605.patch) > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-240) #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line option
[ https://issues.apache.org/jira/browse/STDCXX-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549291 ] Travis Vitek commented on STDCXX-240: - The original snippet provided above shows someone trying to build their code without exception support, with a library was configured with exception support. If I attempt to do this [e.g., build the library as normal, then build the examples without exceptions], I get errors in the tests and examples where we use exception keywords try/throw/catch. I'm guessing I should go through and fix all of those issues and add those changes to the patch or I should open up a new bug for the problem. Considering the issue is pre-existing and is fairly large, it might be better to create a new bug for dealing with it. I don't believe we should need to define the other macros explicitly. The include order is such that we shouldn't have to. I do see that we define _LIBC_THROWS to `throw ()' regardless of any of the other exception macros. This is probably wrong. I believe the error above was caused by building the library with -qnoeh, and then attempting to build user code without it. Now that I think about it, that is a bad idea anyways. > #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line > option > - > > Key: STDCXX-240 > URL: https://issues.apache.org/jira/browse/STDCXX-240 > Project: C++ Standard Library > Issue Type: Improvement > Components: Build >Affects Versions: 4.1.2, 4.1.3, 4.1.4 >Reporter: Martin Sebor >Assignee: Travis Vitek >Priority: Minor > Fix For: 4.2.1 > > Attachments: stdcxx-240.patch > > > Moved from the Rogue Wave bug tracking database: > Class/File: stdcomp.h > Fix Priority: Can Fix > Long Description: > *** Dec 1 1999 6:03PM *** sebor *** > A request for enhancement. > Subject: define RWSTD_NO_EXCEPTIONS when __HPACC_NOEH is > Date: Wed, 01 Dec 1999 17:11:36 -0800 > From: Chichiang Wan <[EMAIL PROTECTED]> > Organization: California Language Labs > To: oemsupport <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], wanc_at_hp <[EMAIL PROTECTED]> > aCC has an option +noeh. When it is provided, __HPACC_NOEH will be > defined. It would be nice for users to need to only use +noeh. For > that, > RWSTD_NO_EXCEPTIONS needs to be defined conditionally. > = > $ cat test.C > #include > $ aCC +noeh -c test.C > Error 46: "/opt/aCC/include/memory", line 493 # Exception handling is > not > enabled (do not use the +noeh flag to aCC). > RWSTD_THROW_NO_MSG(tmp == 0, bad_alloc); > -- Chichiang > Modified By: sebor @ May 29, 2000 10:28:25 PM > We should do this AND test it -- not just on aCC but in general with all > compilers that support this feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-679) [XLC++ 9.0/AIX] failure to apply template conversion operator
[XLC++ 9.0/AIX] failure to apply template conversion operator
-
Key: STDCXX-679
URL: https://issues.apache.org/jira/browse/STDCXX-679
Project: C++ Standard Library
Issue Type: Bug
Components: External
Environment: XLC++/AIX
Reporter: Travis Vitek
$ cat t.cpp && xlC -c t.cpp
struct A
{
template
operator T& ();
};
int main ()
{
A a;
(int)a;
return 0;
}
"t.cpp", line 11.10: 1540-0216 (S) An expression of type "A" cannot be
converted to type "int".
$
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-678) [XLC++ 9.0/AIX] unsats on class template member function taking function with typedef'd parameters
[XLC++ 9.0/AIX] unsats on class template member function taking function with
typedef'd parameters
--
Key: STDCXX-678
URL: https://issues.apache.org/jira/browse/STDCXX-678
Project: C++ Standard Library
Issue Type: Bug
Components: External
Environment: XLC++/AIX
Reporter: Travis Vitek
$ cat t.cpp && xlC -qversion && xlC t.cpp
template
struct A
{
typedef T U;
void apply(void f(const U&)) const;
};
template
void A::apply(void f(const U&)) const { }
struct S { };
void bar (const S&) { };
int main ()
{
A().apply(bar);
return 0;
}
IBM XL C/C++ Enterprise Edition for AIX, V9.0
Version: 09.00..
ld: 0711-317 ERROR: Undefined symbol: .A::apply(void(*)(const S&)) const
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
$
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (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 reassigned STDCXX-676: --- Assignee: Travis Vitek > [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 >Assignee: 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-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:all-tabpanel ] Travis Vitek updated STDCXX-443: Attachment: stdcxx-443.patch Well, I don't really have a preference about leaving or removing this flag. It doesn't seem to have any harmful effects. The difference with the flag off is minimal, and it _appears_ that only a few additional functions are getting inlined with the option on. 2007-12-06 Travis Vitek <[EMAIL PROTECTED]> STDCXX-443 * etc/config/vacpp.config: Remove -Q compile flag for AIX optimized builds to be consistent with IBM documentation. > [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 > > Attachments: stdcxx-443.patch > > > 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] Updated: (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:all-tabpanel ] Travis Vitek updated STDCXX-443: Patch Info: [Patch Available] > [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 > > Attachments: stdcxx-443.patch > > > 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_12549228
]
Travis Vitek commented on STDCXX-673:
-
The first four failures seem to happen because madvise() on AIX always returns
0. The documentation for this function says...
The madvise subroutine has no functionality and is supported for
compatibility only.
Unfortunately, none of the other functions that we are using on other platforms
[mincore, mvalid, msync] seem to work either. They all return -1 all the time.
I see no way to query the validity of a memory address from the process on AIX.
Maybe someone else knows?
As for the type definition problem above, I'm starting to think that this may
be a source compatibility issue. I can think of a few cases where code that
might have compiled on one system would no longer compile without modification.
Am I wrong here?
> [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] 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] Commented: (STDCXX-676) [MSVC] 22.locale.time.put test fails
[ https://issues.apache.org/jira/browse/STDCXX-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548524 ] Travis Vitek commented on STDCXX-676: - Thanks for the feedback. It looks like I need to go back and revise my patch. I _believe_ that this issue will affect any configuration that uses the strftime defined in the MSCRT library. I don't know much about cygwin, but I believe that platform would be excluded. As for the supported format specifiers, I only listed the first few that I ran into problems with. The MSCRT strftime() only supports 'aAbBcdHIjmMpSUwWxyYzZ', I added code for 'CDeFgGhnrRtTuV'. I didn't add support for the modifiers `O' and `E' because the test doesn't actually rely on them, it hard-codes the expected values for these instead. Now that I've written this up, I suppose I could have done the same and used hardcoded values where appropriate. This would mean removing many of the tests, so it probably isn't a good idea. Also, I was trying to avoid using std::strcpy(). I feel weird about using the library that I'm testing in the implementation of the actual test. I could have opted to use the C functions from , but that would have meant modifying some unrelated code to improve consistency inside the test. > [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] 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_12548517
]
Travis Vitek commented on STDCXX-673:
-
The last four failures happen because the config test LIMITS.cpp defines
_RWSTD_INT8_T to `char', which happens to be an unsigned type. Here are the
failing test lines...
TEST ("%{I8d}", 128, 0, 0, "-128");
TEST ("%{I8d}", 255, 0, 0, "-1");
TEST ("%{I8d}", -1, 0, 0, "-1");
TEST ("%{I8d}", -128, 0, 0, "-128");
In _rw_fmtinteger(), the value to print is cast to an _RWSTD_INT8_T. In the
first case, 128 is cast to a [unsigned] char, which leaves the value 128.
I don't believe that this was the intent. I thought that all of the
_RWSTD_INT*_T types are intended to match the requirements of the C99 types
`int*_t'. According to 7.18.1.1 p1 of the C99 standard, `int8_t' denotes a
signed integer type with a width of exactly 8 bits. Given this, I think that
the LIMITS.cpp config test is incorrect and should always define types as
either signed or unsigned. The README indicates that it was the intent for the
types to always be explicitly signed or unsigned, but the implementation does
not match. I'm not sure why this is, but it appears that someone was careful to
write code to only add the `signed' qualifier if the type of `char' is actually
signed.
> [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] Updated: (STDCXX-603) [IBM XLC++ 9.0] unsats on std::valarray::apply() in 26.valarray.members.stdcxx-313.cpp
[ https://issues.apache.org/jira/browse/STDCXX-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-603: Attachment: stdcxx-603.patch This isn't the prettiest solution, but it does work. Instead of using the `value_type' typedef in the function type parameter declaration, we use the actual template type. We could change the rest of the header to be internally consistent, but that would be inconsistent with other class template member function definitions. 2007-12-04 Travis Vitek <[EMAIL PROTECTED]> STDCXX-603 * include/valarray (apply): Avoid use of typedef in function type to avoid linker error with VisualAge C++. > [IBM XLC++ 9.0] unsats on std::valarray::apply() in > 26.valarray.members.stdcxx-313.cpp > - > > Key: STDCXX-603 > URL: https://issues.apache.org/jira/browse/STDCXX-603 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 > Environment: IBM XLC++ 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-603.patch > > > The 26.valarray.members.stdcxx-313.cpp regression test fails to link with IBM > XLC++ 9.0 on AIX 5.3: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/tests/include -O -Q > -qtemplateregistry=26.valarray.members.stdcxx-313.ti > $(TOPDIR)/tests/regress/26.valarray.members.stdcxx-313.cpp > xlCcore_r 26.valarray.members.stdcxx-313.o -o 26.valarray.members.stdcxx-313 > -L$(BUILDDIR)/rwtest -lrwtest -I$(TOPDIR)/include/ansi-liconv -Wl,-bh:5 > -L$(BUILDDIR)/lib -Wl,-bsvr4,-R$(BUILDDIR)/lib:$(BUILDDIR)/rwtest -lstd > -lm -qtemplateregistry=26.valarray.members.stdcxx-313.ti > ld: 0711-317 ERROR: Undefined symbol: .std::valarray::apply(S(*)(S)) const > ld: 0711-317 ERROR: Undefined symbol: .std::valarray::apply(S(*)(const > S&)) const > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. > gmake: *** [26.valarray.members.stdcxx-313] Error 8 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-603) [IBM XLC++ 9.0] unsats on std::valarray::apply() in 26.valarray.members.stdcxx-313.cpp
[ https://issues.apache.org/jira/browse/STDCXX-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-603: Patch Info: [Patch Available] > [IBM XLC++ 9.0] unsats on std::valarray::apply() in > 26.valarray.members.stdcxx-313.cpp > - > > Key: STDCXX-603 > URL: https://issues.apache.org/jira/browse/STDCXX-603 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 > Environment: IBM XLC++ 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-603.patch > > > The 26.valarray.members.stdcxx-313.cpp regression test fails to link with IBM > XLC++ 9.0 on AIX 5.3: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/tests/include -O -Q > -qtemplateregistry=26.valarray.members.stdcxx-313.ti > $(TOPDIR)/tests/regress/26.valarray.members.stdcxx-313.cpp > xlCcore_r 26.valarray.members.stdcxx-313.o -o 26.valarray.members.stdcxx-313 > -L$(BUILDDIR)/rwtest -lrwtest -I$(TOPDIR)/include/ansi-liconv -Wl,-bh:5 > -L$(BUILDDIR)/lib -Wl,-bsvr4,-R$(BUILDDIR)/lib:$(BUILDDIR)/rwtest -lstd > -lm -qtemplateregistry=26.valarray.members.stdcxx-313.ti > ld: 0711-317 ERROR: Undefined symbol: .std::valarray::apply(S(*)(S)) const > ld: 0711-317 ERROR: Undefined symbol: .std::valarray::apply(S(*)(const > S&)) const > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. > gmake: *** [26.valarray.members.stdcxx-313] Error 8 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (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 resolved STDCXX-223.
-
Resolution: Cannot Reproduce
> [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 This patch augments the implementation of rw_strftime() to support several of the format specifiers that strftime() doesn't support. If I couldn't find an easy way to replicate the expected behavior, I just return a failure. Some of these cases could be fixed with enough time. 2007-12-04 Travis Vitek <[EMAIL PROTECTED]> STDCXX-676 * tests/locale/22.locale.time.put.cpp (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] Created: (STDCXX-676) [MSVC] 22.locale.time.put test fails
[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] Issue Comment Edited: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[
https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546445
]
vitek edited comment on STDCXX-605 at 12/4/07 10:04 AM:
---
This appears to be a compiler bug. Here is a simple testcase.
[EMAIL PROTECTED] vitek]$ cat t.cpp && xlC -c t.cpp
struct A
{
template
operator T& ();
};
int main ()
{
A a;
(int)a;
return 0;
}
"t.cpp", line 11.10: 1540-0216 (S) An expression of type "A" cannot be
converted to type "int".
[EMAIL PROTECTED] vitek]$
Making an explicit call to `a.operator int& ()' works, as does a cast to `int&'
before the cast to `int'. It appears that the compiler isn't seeing that it can
get an `int' by applying one of the conversion operators.
Possible workarounds are to explicitly call the conversion operator, do an
additional cast, or change the conversion operator to be an exact match. i.e.
`operator T () const'.
was (Author: vitek):
This appears to be a compiler bug. Here is a simple testcase.
[EMAIL PROTECTED] examples]$ cat t.cpp && xlCcore -g -q64 t.cpp
template
T& get ()
{
static T v = T();
return v;
}
struct A
{
template
operator const T& () const {
return get();
}
};
int main ()
{
A a;
(int)a;
return 0;
}
"t.cpp", line 20.10: 1540-0216 (S) An expression of type "A" cannot be
converted to type "int".
Making an explicit call to `a.operator const int& ()' works, as does a cast to
`const int&' before the cast to `int'. It appears that the compiler isn't
seeing that it can get an `int' by applying one of the conversion operators.
Possible workarounds are to explicitly call the conversion operator, do an
additional cast, or change the conversion operator to be an exact match. i.e.
`operator T () const'.
> [IBM XLC++] errors compiling dynatype.cpp
> -
>
> Key: STDCXX-605
> URL: https://issues.apache.org/jira/browse/STDCXX-605
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Examples
>Affects Versions: 4.2.0
> Environment: XLC++ 6.0 through 9.0/AIX 5.3
>Reporter: Martin Sebor
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: stdcxx-605.patch
>
>
> The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX
> with ethe following errors:
> xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include
> -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q
> -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "int".
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "double".
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "double".
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "const char *".
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "const char *".
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "char".
> gmake: *** [dynatype.o] Error 1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-604) [IBM XLC++ 9.0] ICE on 23.bitset.cons.stdcxx-297
[ https://issues.apache.org/jira/browse/STDCXX-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-604: Comment: was deleted > [IBM XLC++ 9.0] ICE on 23.bitset.cons.stdcxx-297 > > > Key: STDCXX-604 > URL: https://issues.apache.org/jira/browse/STDCXX-604 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 > Environment: IBM XLC++ 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-604.patch > > > The 23.bitset.cons.stdcxx-297.cpp regression test fails to compile with IBM > XLC++ 9.0 due to an internal compiler error: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/tests/include -O -Q > -qtemplateregistry=23.bitset.cons.stdcxx-297.ti > $(TOPDIR)/tests/regress/23.bitset.cons.stdcxx-297.cpp > /nfs/packages/mdx/aix/compilers/5.2.0/va90/root/usr/vacpp/bin/.orig/xlCcore_r: > 1501-230 (S) Internal compiler error; please contact your Service > Representative > gmake: *** [23.bitset.cons.stdcxx-297.o] Error 41 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-604) [IBM XLC++ 9.0] ICE on 23.bitset.cons.stdcxx-297
[ https://issues.apache.org/jira/browse/STDCXX-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548321 ] Travis Vitek commented on STDCXX-604: - Martin filed an issue with IBM [PMR30355 756 000] in July. The testcase is nearly identical. IBM support reports that the ICE was fixed in the Oct2007 update, which I do not have access to at the moment. > [IBM XLC++ 9.0] ICE on 23.bitset.cons.stdcxx-297 > > > Key: STDCXX-604 > URL: https://issues.apache.org/jira/browse/STDCXX-604 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 > Environment: IBM XLC++ 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-604.patch > > > The 23.bitset.cons.stdcxx-297.cpp regression test fails to compile with IBM > XLC++ 9.0 due to an internal compiler error: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/tests/include -O -Q > -qtemplateregistry=23.bitset.cons.stdcxx-297.ti > $(TOPDIR)/tests/regress/23.bitset.cons.stdcxx-297.cpp > /nfs/packages/mdx/aix/compilers/5.2.0/va90/root/usr/vacpp/bin/.orig/xlCcore_r: > 1501-230 (S) Internal compiler error; please contact your Service > Representative > gmake: *** [23.bitset.cons.stdcxx-297.o] Error 41 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-603) [IBM XLC++ 9.0] unsats on std::valarray::apply() in 26.valarray.members.stdcxx-313.cpp
[
https://issues.apache.org/jira/browse/STDCXX-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548082
]
Travis Vitek commented on STDCXX-603:
-
Here is a reduced test case. The issue can be resolved by writing apply()
inline in the class declaration or changing the declaration of `__fun' to `void
__fun(const T&)'. Apparently the VisualAge C++ compiler gets confused when
using a typedef in this context.
[EMAIL PROTECTED] tests]$ cat t.cpp && gmake t
template
struct valarray
{
typedef T U;
void apply (void __func (const U&)) const;
};
template
void valarray::apply (void __fun (const U&)) const { }
struct S { };
void foo (const S& s) { };
int main ()
{
valarray().apply (foo);
return 0;
}
xlCcore t.o -o t -L/build/vitek/11s/rwtest -lrwtest11s
-I/amd/devco/vitek/stdcxx/trunk/include/ansi -D_RWSTDDEBUG-liconv -Wl,-bh:5
-L/build/vitek/11s/lib -lstd11s -lm -qtemplateregistry=t.ti
ld: 0711-317 ERROR: Undefined symbol: .valarray::apply(void(*)(const S&))
const
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
gmake: *** [t] Error 8
> [IBM XLC++ 9.0] unsats on std::valarray::apply() in
> 26.valarray.members.stdcxx-313.cpp
> -
>
> Key: STDCXX-603
> URL: https://issues.apache.org/jira/browse/STDCXX-603
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2.0
> Environment: IBM XLC++ 9.0/AIX 5.3
>Reporter: Martin Sebor
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
>
> The 26.valarray.members.stdcxx-313.cpp regression test fails to link with IBM
> XLC++ 9.0 on AIX 5.3:
> xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include
> -I$(BUILDDIR)/include -I$(TOPDIR)/tests/include -O -Q
> -qtemplateregistry=26.valarray.members.stdcxx-313.ti
> $(TOPDIR)/tests/regress/26.valarray.members.stdcxx-313.cpp
> xlCcore_r 26.valarray.members.stdcxx-313.o -o 26.valarray.members.stdcxx-313
> -L$(BUILDDIR)/rwtest -lrwtest -I$(TOPDIR)/include/ansi-liconv -Wl,-bh:5
> -L$(BUILDDIR)/lib -Wl,-bsvr4,-R$(BUILDDIR)/lib:$(BUILDDIR)/rwtest -lstd
> -lm -qtemplateregistry=26.valarray.members.stdcxx-313.ti
> ld: 0711-317 ERROR: Undefined symbol: .std::valarray::apply(S(*)(S)) const
> ld: 0711-317 ERROR: Undefined symbol: .std::valarray::apply(S(*)(const
> S&)) const
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
> gmake: *** [26.valarray.members.stdcxx-313] Error 8
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-240) #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line option
[ https://issues.apache.org/jira/browse/STDCXX-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-240: Attachment: stdcxx-240.patch Well, the test suite doesn't build cleanly if _RWSTD_NO_EXCEPTIONS is defined. There are many undefined variable warnings, and many places that use keywords try/throw/catch without checking the macro first. I can't fully say that this is working completely because many of the tests don't compile when _RWSTD_NO_EXCEPTIONS is defined. I also get some warnings because of mismatches. On AIX, for example, I get these warnings. "/amd/devco/vitek/stdcxx/trunk/include/new", line 216.7: 1540-0419 (W) An exception-specification must be specified as "throw(std::bad_alloc)" to match the implicit declaration. "/amd/devco/vitek/stdcxx/trunk/include/new", line 216.7: 1540-1088 (W) The exception specification is being ignored. "/amd/devco/vitek/stdcxx/trunk/include/new", line 223.6: 1540-0419 (W) An exception-specification must be specified as "throw()" to match the implicit declaration. "/amd/devco/vitek/stdcxx/trunk/include/new", line 223.6: 1540-1088 (W) The exception specification is being ignored. "/amd/devco/vitek/stdcxx/trunk/include/new", line 240.7: 1540-0419 (W) An exception-specification must be specified as "throw(std::bad_alloc)" to match the implicit declaration. "/amd/devco/vitek/stdcxx/trunk/include/new", line 240.7: 1540-1088 (W) The exception specification is being ignored. "/amd/devco/vitek/stdcxx/trunk/include/new", line 250.6: 1540-0419 (W) An exception-specification must be specified as "throw()" to match the implicit declaration. "/amd/devco/vitek/stdcxx/trunk/include/new", line 250.6: 1540-1088 (W) The exception specification is being ignored. Not sure how to proceed with this. I'm attaching the patch that checks the above mentioned macros in the appropriate config headers. It does nothing else. > #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line > option > - > > Key: STDCXX-240 > URL: https://issues.apache.org/jira/browse/STDCXX-240 > Project: C++ Standard Library > Issue Type: Improvement > Components: Build >Affects Versions: 4.1.2, 4.1.3, 4.1.4 >Reporter: Martin Sebor >Assignee: Travis Vitek >Priority: Minor > Fix For: 4.2.1 > > Attachments: stdcxx-240.patch > > > Moved from the Rogue Wave bug tracking database: > Class/File: stdcomp.h > Fix Priority: Can Fix > Long Description: > *** Dec 1 1999 6:03PM *** sebor *** > A request for enhancement. > Subject: define RWSTD_NO_EXCEPTIONS when __HPACC_NOEH is > Date: Wed, 01 Dec 1999 17:11:36 -0800 > From: Chichiang Wan <[EMAIL PROTECTED]> > Organization: California Language Labs > To: oemsupport <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], wanc_at_hp <[EMAIL PROTECTED]> > aCC has an option +noeh. When it is provided, __HPACC_NOEH will be > defined. It would be nice for users to need to only use +noeh. For > that, > RWSTD_NO_EXCEPTIONS needs to be defined conditionally. > = > $ cat test.C > #include > $ aCC +noeh -c test.C > Error 46: "/opt/aCC/include/memory", line 493 # Exception handling is > not > enabled (do not use the +noeh flag to aCC). > RWSTD_THROW_NO_MSG(tmp == 0, bad_alloc); > -- Chichiang > Modified By: sebor @ May 29, 2000 10:28:25 PM > We should do this AND test it -- not just on aCC but in general with all > compilers that support this feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-204) std::filebuf::overflow(EOF) writes garbage in unbuffered mode
[
https://issues.apache.org/jira/browse/STDCXX-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Vitek updated STDCXX-204:
Comment: was deleted
> std::filebuf::overflow(EOF) writes garbage in unbuffered mode
> -
>
> Key: STDCXX-204
> URL: https://issues.apache.org/jira/browse/STDCXX-204
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.1.2, 4.1.3
> Environment: All.
>Reporter: Martin Sebor
>Assignee: Martin Sebor
> Fix For: 4.2.0
>
>
> The program below dumps core:
> $ cat t.cpp && nice gmake t && ./t
> #include
> #include
> struct MyBuf: std::filebuf {
> int_type oflow () {
> return overflow (traits_type::eof ());
> }
> };
> int main ()
> {
> MyBuf f;
> assert (0 != f.open ("test.file", std::ios::out | std::ios::trunc));
> assert (0 != f.pubsetbuf (0, 0));
> assert (MyBuf::traits_type::eof () != f.oflow ());
> assert (0 == f.pubseekoff (0, std::ios::end, std::ios::out));
> }
> aCC -c -I/amd/devco/sebor/dev/stdlib/include/ansi -I/usr/include
> -D_RWSTDDEBUG -mt -D_RWSTD_USE_CONFIG -I/amd/devco/sebor/dev/stdlib/include
> -I/build/sebor/aCC-3.63-15S/include -I/amd/devco/sebor/dev/stdlib/../rwtest
> -I/amd/devco/sebor/dev/stdlib/../rwtest/include
> -I/amd/devco/sebor/dev/stdlib/tests/include -Aa +nostl -g +d +DD64 +w
> +W392 +W655 +W684 +W818 +W819 +W849 t.cpp
> aCC t.o -o t -L/build/sebor/aCC-3.63-15S/rwtest -lrwtest15S -Aa +nostl -Wl,+s
> -Wl,+vnocompatwarnings -L/build/sebor/aCC-3.63-15S/lib -mt +DD64
> -L/build/sebor/aCC-3.63-15S/lib -lstd15S -lm
> Assertion failed: 0 == f.pubseekoff (0, std::ios::end, std::ios::out), file
> t.cpp, line 19
> ABORT instruction (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
