Re: spaces in rw_xxx_expand()

[Martin Sebor]

PING? Should I open an issue for this or is it something you're
already working on or planning to?


Martin Sebor wrote:
> 
> In the shell, spaces that are otherwise treated as separators can
> be either escaped or quoted to have them interpreted as ordinary
> characters. The rw_xxx_expand() functions let me escape spaces but
> they don't seem to like quoting. For example, the shell expands
> the following three strings to the same result:
> 
>  "a{b\ c,d}"==> "ab c ad"
>  "a{b' 'c,d}"
>  "a{b" "c,d}"
> 
> but rw_brace_expand() fails on the last two. It should work the
> same as the shell.
> 
> In the change below I've enhanced the 0.braceexpand.cpp test to
> exercise a number of (passing) test cases including plan as well
> as escaped whitespace:
> 
> http://svn.apache.org/viewvc?rev=642790&view=rev
> 
> I think the same test cases should be added for quoted whitespace.
> 
> Martin
> 
> 

-- 
View this message in context: 
http://www.nabble.com/spaces-in-rw_xxx_expand%28%29-tp16385194p16431767.html
Sent from the stdcxx-dev mailing list archive at Nabble.com.

RE: svn commit: r643630 - /stdcxx/trunk/etc/config/src/float_defs.h

[Eric Lemings]

 
Doh!  Yeah, thought I had it tested out pretty good.  That's what
thinkin' gets me.

Save the following script and set SVN_EDITOR environment variable
to use it during check-ins:

-
#!/bin/sh

# Generate custom template for Subversion log messages.

[ $# -eq 1 ] || {
echo "Usage: $0 FILE"
exit 1
}

FILE=$1
TEXT=`cat ${FILE}`
TODAY=`date +%F`
# This will have to be tailored by the end user.  Can't think of a way
# to determine this automaticallly.
EMAIL="Eric Lemings <[EMAIL PROTECTED]>"

# Save original file and revert back to it later if necessary.
TMPFILE=`mktemp -t svn.XX`
if [ $? -ne 0 ]; then
  echo "$0: error: could not create temporary file"
  exit 1
fi

# Create a new template using GNU ChangeLog format.
cat <${TMPFILE}
${TODAY} ${EMAIL}

ISSUE-ID
* file1 (func1), file2: Summary of 1st change.
* file2: Summary of 2nd change.
${TEXT}
END

# Try to determine user's preferred editor.
[ -z ${EDITOR} ] && EDITOR=${SVN_EDITOR}
[ -z ${EDITOR} ] && EDITOR=${VISUAL}
[ -z ${EDITOR} ] && [ -f ${HOME}/.emacs ] && EDITOR=emacs
[ -z ${EDITOR} ] && EDITOR=vi

# Compare checksums to determine if file actually changed.
OLDCRC=`cksum ${TMPFILE}`
if ${EDITOR} ${TMPFILE}; then
  NEWCRC=`cksum ${TMPFILE}`
  if [ "${OLDCRC}" != "${NEWCRC}" ]; then
rm -f ${FILE}
mv ${TMPFILE} ${FILE}
  else
rm -f ${TMPFILE}
  fi
else
echo "$0: error: editor failed: \"${EDITOR}\""
exit 1
fi
-

Brad.

> -Original Message-
> From: Travis Vitek [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 01, 2008 4:48 PM
> To: dev@stdcxx.apache.org
> Subject: RE: svn commit: r643630 - 
> /stdcxx/trunk/etc/config/src/float_defs.h
> 
> 
> Brad,
> 
> I think your changelog template is great, but it might be a 
> good idea to
> fill it in. :) BTW, there are two spaces between the date and 
> your name,
> and then another two between your name and your e-mail address.
> 
> Travis
> 
> >-Original Message-
> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> >Sent: Tuesday, April 01, 2008 3:35 PM
> >To: [EMAIL PROTECTED]
> >Subject: svn commit: r643630 - 
> >/stdcxx/trunk/etc/config/src/float_defs.h
> >
> >Author: elemings
> >Date: Tue Apr  1 15:35:11 2008
> >New Revision: 643630
> >
> >URL: http://svn.apache.org/viewvc?rev=643630&view=rev
> >Log:
> >2008-04-01 Eric Lemings <[EMAIL PROTECTED]>
> >
> > STDCXX-###
> > * file (function), ...: Summary of change.
> >
> >
> >Modified:
> >stdcxx/trunk/etc/config/src/float_defs.h
> >
> 

Re: [jira] Commented: (STDCXX-708) [HP aCC 6.15/HP-UX/IPF] 18.numeric.special.float fails assertions

[Martin Sebor]

Eric Lemings (JIRA) wrote:
[ https://issues.apache.org/jira/browse/STDCXX-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584333#action_12584333 ] 


Eric Lemings commented on STDCXX-708:
-

Wasn't expecting Jira to automatically append that email to the comments in the 
issue.


I didn't know you could do that either. All you need to do is send your
response to [EMAIL PROTECTED] Nifty!

Martin


The cross-post on the dev list shows the proper formatting.

I changed the directive using the suggested directive from _config.h and 
testing it now on both HP-UX platforms.


[HP aCC 6.15/HP-UX/IPF] 18.numeric.special.float fails assertions
-

Key: STDCXX-708
URL: https://issues.apache.org/jira/browse/STDCXX-708
Project: C++ Standard Library
 Issue Type: Bug
 Components: Tests
   Affects Versions: trunk
Environment: {noformat}
$ uname -srm && aCC -V
HP-UX B.11.31 ia64
aCC: HP C/aC++ B3910B A.06.15 [May 16 2007]
{noformat}
   Reporter: Martin Sebor
   Assignee: Eric Lemings
Fix For: 4.2.1

  Original Estimate: 4h
 Time Spent: 6h
 Remaining Estimate: 0h

When compiled with HP aCC 6 on HP-UX running on IPF hardware the newly added 
test 
[18.numeric.special.float.cpp|http://svn.apache.org/viewvc/stdcxx/trunk/tests/support/18.numeric.special.float.cpp]
 fails a bunch of assertions.
One of them look like a configuration problem in the library (has_denorm) while 
others (min(), max(), and epsilon()) like problems in the test
{noformat}
$ nice gmake 18.numeric.special.float -r && ./18.numeric.special.float
aCC -c  -D_RWSTDDEBUG   -mt -I/amd/devco/sebor/stdcxx/include \
-I/build/sebor/stdcxx-aCC-6.15-15D/include 
-I/amd/devco/sebor/stdcxx/tests/include  \
-AA  -g +d  +DD64 +w +W392 +W655 +W684 +W818 +W819 +W849 +W2193 +W2236 +W2261 \
+W2340 +W2401 +W2487 +W4227 +W4229 +W4231 +W4235 +W4237 +W4249 +W4255 +W4272 \
+W4284 +W4285 +W4286   
/amd/devco/sebor/stdcxx/tests/support/18.numeric.special.float.cpp
"/amd/devco/sebor/stdcxx/include/limits", line 449: warning #4070-D: floating
  point underflow exception
  _RWSTD_STATIC_FUN (long double, (min), _RWSTD_LDBL_MIN) 
  ^

aCC 18.numeric.special.float.o -o 18.numeric.special.float \
-L/build/sebor/stdcxx-aCC-6.15-15D/rwtest -lrwtest15D -AA +nostl -Wl,+s   -mt 
+DD64 \
-L/build/sebor/stdcxx-aCC-6.15-15D/lib  \
-Wl,+b/build/sebor/stdcxx-aCC-6.15-15D/lib:/build/sebor/stdcxx-aCC-6.15-15D/rwtest
 \
-lstd15D  -lm 
rm 18.numeric.special.float.o

# INFO (S1) (10 lines):
# TEXT: 
# COMPILER: HP aCC, __HP_aCC = 61500, __EDG_VERSION__ = 308

# ENVIRONMENT: ia64 running hp-ux
# FILE: 18.numeric.special.float.cpp
# COMPILED: Jan 24 2008, 17:28:57
# COMMENT: floating specializations

# CLAUSE: numeric.special
# ASSERTION (S7) (4 lines):
# TEXT: numeric_limits::has_denorm == -1, got 1
# CLAUSE: numeric.special
# LINE: 1366
# ASSERTION (S7) (4 lines):
# TEXT: numeric_limits::has_denorm == -1, got 1
# CLAUSE: numeric.special
# LINE: 1366
# ASSERTION (S7) (4 lines):
# TEXT: numeric_limits::min() == 3.3621e-4932, got 3.3621e-4932
# CLAUSE: numeric.special
# LINE: 1253
# ASSERTION (S7) (4 lines):
# TEXT: numeric_limits::max() == 1.18973e+4932, got 1.18973e+4932
# CLAUSE: numeric.special
# LINE: 1254
# ASSERTION (S7) (4 lines):
# TEXT: numeric_limits::epsilon() == 1.92593e-34, got 1.0842e-19
# CLAUSE: numeric.special
# LINE: 1262
# ASSERTION (S7) (4 lines):
# TEXT: numeric_limits::has_denorm == -1, got 1
# CLAUSE: numeric.special
# LINE: 1366
# +---+--+--+--+
# | DIAGNOSTIC|  ACTIVE  |   TOTAL  | INACTIVE |
# +---+--+--+--+
# | (S1) INFO |1 |1 |   0% |
# | (S5) WARNING  |0 |3 | 100% |
# | (S7) ASSERTION|6 |  134 |  95% |
# +---+--+--+--+
{noformat}

Re: on branches and merging

[Martin Sebor]

Travis Vitek wrote:
 




Martin Sebor wrote:

It occurs to me that even if most work were done on the release
branch(es) the changes would still need to merged only in the
opposite direction: from each branch to trunk and/or to other
branches. I'm afraid I don't see how the merging problem can
be avoided. Do you?



I don't see the merge itself as the most serious problem. The trouble is
trying to figure out what changes can be merged out to 4.2.x from trunk.

I believe that we currently have some changes that aren't suitable for
4.2.x on trunk. When someone goes and tries to do the merge out, they
have to make sure they do the merge correctly and they have to be
careful to not merge changes that are incompatible with the target
branches compatibility requirements. That is what I'm worried about.


Same here.



If the merging was going from 4.2.x to trunk, then the compatibility
issue is moot.


Good point. The only problem here, and it's probably the one that
led to the current convention of making changes on trunk first,
before merging them to 4.2.x, is that we've had a good share of
changes that we thought were appropriate for 4.2.x that turned
out not to be.

The release process document tries to deal with this problem by
allowing changes on a release branch at first, until the RM has
decided it's time to start stabilizing the branch (Feature Freeze).
At that point the branch becomes RTC for everyone but the RM. In
practice what I expect this to mean is that development (including
bug fixing) will proceed on trunk (or other branches) with the RM
being responsible for doing the merges.

Since we haven't reached a "Feature Freeze" yet we should be able
to follow the process. The only two obstacles are: no test results
for 4.2.x, and our propensity to make incompatible changes. As I
said I'll take care of the first. I'm not sure how to handle the
second except by freezing the branch. Which will bring us a full
circle...

Martin

Re: on branches and merging

[Martin Sebor]

Eric Lemings wrote:
 


-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Tuesday, April 01, 2008 4:11 PM
To: dev@stdcxx.apache.org
Subject: on branches and merging (was: Re: failing regression tests)


...

It occurs to me that even if most work were done on the release
branch(es) the changes would still need to merged only in the
opposite direction: from each branch to trunk and/or to other
branches. I'm afraid I don't see how the merging problem can
be avoided. Do you?


Sure.  Don't branch until all issues scheduled for the release have
been resolved and you're ready to start testing release candidates.
That way, all main development occurs in only one place only: on
the trunk.


That doesn't work when there are several parallel development
efforts going on. In our case, they are: 4.2.x, 4.3, and 5.0.
As I just mentioned in my response to Travis we have changes
(or patches) for all three. We just haven't been committing
(or have been reverting) patches for the latter two because
they're not appropriate for 4.2.x. That's not workable.

There's no avoiding having development happen on multiple
branches at the same time. We need to figure out how to
make the process of merging changes between these branches
as easy as possible with the least chance of errors.

Martin

RE: svn commit: r643630 - /stdcxx/trunk/etc/config/src/float_defs.h

[Travis Vitek]

Brad,

I think your changelog template is great, but it might be a good idea to
fill it in. :) BTW, there are two spaces between the date and your name,
and then another two between your name and your e-mail address.

Travis

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
>Sent: Tuesday, April 01, 2008 3:35 PM
>To: [EMAIL PROTECTED]
>Subject: svn commit: r643630 - 
>/stdcxx/trunk/etc/config/src/float_defs.h
>
>Author: elemings
>Date: Tue Apr  1 15:35:11 2008
>New Revision: 643630
>
>URL: http://svn.apache.org/viewvc?rev=643630&view=rev
>Log:
>2008-04-01 Eric Lemings <[EMAIL PROTECTED]>
>
>   STDCXX-###
>   * file (function), ...: Summary of change.
>
>
>Modified:
>stdcxx/trunk/etc/config/src/float_defs.h
>

RE: on branches and merging (was: Re: failing regression tests)

[Travis Vitek]

 


>Martin Sebor wrote:
>
>It occurs to me that even if most work were done on the release
>branch(es) the changes would still need to merged only in the
>opposite direction: from each branch to trunk and/or to other
>branches. I'm afraid I don't see how the merging problem can
>be avoided. Do you?
>

I don't see the merge itself as the most serious problem. The trouble is
trying to figure out what changes can be merged out to 4.2.x from trunk.

I believe that we currently have some changes that aren't suitable for
4.2.x on trunk. When someone goes and tries to do the merge out, they
have to make sure they do the merge correctly and they have to be
careful to not merge changes that are incompatible with the target
branches compatibility requirements. That is what I'm worried about.

If the merging was going from 4.2.x to trunk, then the compatibility
issue is moot.

Travis

on branches and merging (was: Re: failing regression tests)

[Martin Sebor]

Travis Vitek wrote:
 


Martin Sebor wrote:

Travis Vitek wrote:
 



I'm thinking that all work for 4.2.1 should be done on the 
4.2.x branch, and future work should be done on trunk until

an appropriate branch has been created. That way we avoid
having to be careful about bulk merges from trunk to 4.2.1...
Everything that is on 4.2.x should be safe for trunk.

Unfortunately, I think that would mean that we would need to 
do nightly testing on the 4.2.x branch, possibly in addition

to trunk.

Right, that's a big problem. Another problem with this approach
is that it has the potential to destabilize the branch.


I don't mind it being unstable,


Stability is increasingly important as we approach a release.
Every major breakage (like the one we just had on trunk) sets
us back by days if not a week, sometimes up to 10 days when
the build servers are busy.


provided that we are actually testing
that branch. I don't think we are testing 4.2.x, so we don't even know
if it is stable or not. When we get close to release time, we should
probably be testing 4.2.x almost exclusively.


Scott tells me we have been testing 4.2.x in nightly builds for
some time. I just haven't gotten around to publishing the results
yet. I need to do it soon. I think I'll need Andrew's help to set
up the script(s).




The second problem can be mitigated by tagging the branch when
it's known to be stable. I don't think there's anything we can
do about the first problem except alleviate it by implementing
a more intelligent test harness. I'm not sure we have cycles
for that...


Are you saying that the test infrastrucure doesn't allow us to test
4.2.x at all? I can see how that would be a serious problem. How are we
expected to verify that the code that is on 4.2.x is good?


What I'm saying is that it might be a hard sell to get Rogue Wave
to run two (or more) sets of nightly builds for stdcxx, one for
trunk and one for each branch, unless it's much more lightweight
than it is now.




Is there some convention or process we could put in place that
would make the bulk merge issue less painful? I wake up in the
middle of the night thinking about how we're going to manage
it for 4.2.1. Maybe it won't be so bad, but it does seem like
it will be a lot work and could be pretty error prone.


Well, for a while there Farid was working directly on 4.2.x and merging
back to trunk. That solution would work. Another obvious option would be
to require users to merge their own changes out. We were doing this for
a hile, but I've noticed that this hasn't been happening lately.


It hasn't because we haven't been testing the branch (or
publishing the results). We could switch nightly builds to 4.2.x
but then we'll have the same problem on trunk and/or on any other
branch (such as 4.3 or 5.0, once they've been created). We already
have a number of patches and tests that we've been waiting to
commit because they're not appropriate for 4.2.x and we've been
treating trunk as a copy of 4.2.x. I think that's a mistake.
We should commit these patches otherwise they are at risk of
becoming out of sync with the files they patch. Then it'll be
a chore to apply them all.

I guess my point is that it doesn't matter if it's a branch or
trunk that gets tested, or where some/many of us do their work,
there's nothing we can do to get away from merging the changes
at some point. So it seems that we need to come up with
a solution to the merging problem, independently of what we
do about testing.

Martin

RE: [jira] Commented: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions

[Travis Vitek]

 

>Martin Sebor wrote:
>
>Travis Vitek wrote:
>>  
>> 
>>> Travis Vitek commented on STDCXX-742:
>>> -
>>>
>>> This is happening because we don't use the -qrtti=dynamiccast 
>>> option. We internally use a dynamic_cast to determine if the 
>>> facet is of the correct derived type, but if dynamic_cast 
>>> isn't supported we use a C style cast, and that returns bad results.
>>>
>>> This case is essentially the same as STDCXX-664. We didn't add 
>>> -qrtti=dynamiccast back then, and we just worked around the 
>>> issue in the test. It seems to me that we should have added 
>>> the flag. Would this be a binary compatible change?
>>>
>> 
>> What are the thoughts on this? There was some discussion
>> [http://tinyurl.com/3xfdma] of enabling -qrtti=dynamiccast for the
>> VisualAge C++ compiler, but it petered out. 
>
>Is there any way to turn on rtti using a pragma? That way we could
>enable it only for translation units that included  and we
>wouldn't be shoving the option down the throats of users who don't
>care about named locales.

No, there is no pragma for this. Even if there were we would need to do
some hacking to get it to work. We try determine if dynamic_cast<>()
exists and is functioning correctly at configuration time. If that
config test fails, we define _RWSTD_NO_DYNAMIC_CAST. So even if we
managed to enable rtti when  was included, we would need to
'fix' the _RWSTD_NO_DYNAMIC_CAST and _RWSTD_DYNAMIC_CAST macros. Ewww..

>
>Btw., does XLC++ itself correctly handle the test case mentioned
>in the thread, even without -qrtti? (It's possible to get some
>simple cases to work even w/o the option but not all of them).
>

I'm not absolutely sure what you're asking. It sounds like you are
asking if the Standard C++ Library implementation that ships with XLC++
has this same problem. The answer to that is no...

$ type t.cpp
#include 
#include 
#include 

template 
void test_has_facet (const char *loc_name, const char *cname)
{
const std::locale loc =
loc_name ? std::locale (loc_name) : std::locale ();

typedef std::messages_byname ByName;

const bool byname = loc_name
&& std::strcmp (loc_name, "C");

const bool facet_exists = std::has_facet(loc);

assert (byname == facet_exists);

try {
// verify that use facet throws an exception only
// for the default and "C" locales
std::use_facet(loc);

assert (byname);
}
catch (std::exception &ex) {
assert (!byname);
}
}

template 
void test_messages (charT, const char *cname)
{
// exercise has_facet and use_facet in the default locale
test_has_facet(0, cname);

// exercise has_facet and use_facet in locale("C")
test_has_facet("C", cname);
}

int main (int, char*[])
{
test_messages (char (), "char");

return 0;
}

  $ xlC t.cpp -o t && ./t
  $

If I run the same code under stdcxx, I get the following

  $ gmake t && ./t

  

  Assertion failed: byname == facet_exists, file t.cpp, line 18
  IOT/Abort trap (core dumped)
  $

Travis

RE: on branches and merging (was: Re: failing regression tests)

[Eric Lemings]

 

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Tuesday, April 01, 2008 4:11 PM
> To: dev@stdcxx.apache.org
> Subject: on branches and merging (was: Re: failing regression tests)
> 
...
> 
> It occurs to me that even if most work were done on the release
> branch(es) the changes would still need to merged only in the
> opposite direction: from each branch to trunk and/or to other
> branches. I'm afraid I don't see how the merging problem can
> be avoided. Do you?

Sure.  Don't branch until all issues scheduled for the release have
been resolved and you're ready to start testing release candidates.
That way, all main development occurs in only one place only: on
the trunk.

Brad.

on branches and merging (was: Re: failing regression tests)

[Martin Sebor]

Martin Sebor wrote:

Travis Vitek wrote:
 


Martin Sebor wrote:

[...]

I think we need to decide if trunk is supposed to be a copy of
4.2.x or if it's for development of future versions. If the
latter, there's no problem with keeping tests like it there
as long as they're passing or as long as there's an entry in
xfail.txt. We just need to remember not to merge them (and
fixes for them, if they're incompatible) out to 4.2.x.

So, which is it? Do we keep trunk as a development version of
4.2.x or do we make changes on it that are incompatible with
4.2.x?



I'm thinking that all work for 4.2.1 should be done on the 4.2.x branch,
and future work should be done on trunk until an appropriate branch has
been created. That way we avoid having to be careful about bulk merges
from trunk to 4.2.1... Everything that is on 4.2.x should be safe for
trunk.

Unfortunately, I think that would mean that we would need to do nightly
testing on the 4.2.x branch, possibly in addition to trunk.


Right, that's a big problem. Another problem with this approach
is that it has the potential to destabilize the branch.

The second problem can be mitigated by tagging the branch when
it's known to be stable. I don't think there's anything we can
do about the first problem except alleviate it by implementing
a more intelligent test harness. I'm not sure we have cycles
for that...


It occurs to me that even if most work were done on the release
branch(es) the changes would still need to merged only in the
opposite direction: from each branch to trunk and/or to other
branches. I'm afraid I don't see how the merging problem can
be avoided. Do you?



Is there some convention or process we could put in place that
would make the bulk merge issue less painful? I wake up in the
middle of the night thinking about how we're going to manage
it for 4.2.1. Maybe it won't be so bad, but it does seem like
it will be a lot work and could be pretty error prone.

Martin

RE: failing regression tests

[Travis Vitek]

 

>Martin Sebor wrote:
>
>Travis Vitek wrote:
>>  
>> 
>> 
>> I'm thinking that all work for 4.2.1 should be done on the 
>> 4.2.x branch, and future work should be done on trunk until
>> an appropriate branch has been created. That way we avoid
>> having to be careful about bulk merges from trunk to 4.2.1...
>> Everything that is on 4.2.x should be safe for trunk.
>> 
>> Unfortunately, I think that would mean that we would need to 
>> do nightly testing on the 4.2.x branch, possibly in addition
>> to trunk.
>
>Right, that's a big problem. Another problem with this approach
>is that it has the potential to destabilize the branch.

I don't mind it being unstable, provided that we are actually testing
that branch. I don't think we are testing 4.2.x, so we don't even know
if it is stable or not. When we get close to release time, we should
probably be testing 4.2.x almost exclusively.

>
>The second problem can be mitigated by tagging the branch when
>it's known to be stable. I don't think there's anything we can
>do about the first problem except alleviate it by implementing
>a more intelligent test harness. I'm not sure we have cycles
>for that...

Are you saying that the test infrastrucure doesn't allow us to test
4.2.x at all? I can see how that would be a serious problem. How are we
expected to verify that the code that is on 4.2.x is good?

>
>Is there some convention or process we could put in place that
>would make the bulk merge issue less painful? I wake up in the
>middle of the night thinking about how we're going to manage
>it for 4.2.1. Maybe it won't be so bad, but it does seem like
>it will be a lot work and could be pretty error prone.

Well, for a while there Farid was working directly on 4.2.x and merging
back to trunk. That solution would work. Another obvious option would be
to require users to merge their own changes out. We were doing this for
a hile, but I've noticed that this hasn't been happening lately.

>
>Martin
>

Re: failing regression tests

[Martin Sebor]

Travis Vitek wrote:
 


Martin Sebor wrote:

Farid Zaripov wrote:

Martin Sebor wrote:

The regression tests below are all failing with SIGABRT.
I check the issues and they have all been deferred, so what's 
missing is an entry for each of these tests in xfail.txt to 
mark them up on our build result pages.


 21.string.assign.stdcxx-629
 21.string.insert.stdcxx-630
 21.string.insert.stdcxx-632
 21.string.replace.stdcxx-170

Farid, I think these are all your issues. Can you please take 
care of updating xfail.txt when you have a chance?
  Done. It seems that the 21.string.insert.stdcxx-630 test 
is added by my mistake (the STDCXX-630 issue is about assign

string method and not about insert). So I deleted this test
from trunk.

I think we need to decide if trunk is supposed to be a copy of
4.2.x or if it's for development of future versions. If the
latter, there's no problem with keeping tests like it there
as long as they're passing or as long as there's an entry in
xfail.txt. We just need to remember not to merge them (and
fixes for them, if they're incompatible) out to 4.2.x.

So, which is it? Do we keep trunk as a development version of
4.2.x or do we make changes on it that are incompatible with
4.2.x?



I'm thinking that all work for 4.2.1 should be done on the 4.2.x branch,
and future work should be done on trunk until an appropriate branch has
been created. That way we avoid having to be careful about bulk merges
from trunk to 4.2.1... Everything that is on 4.2.x should be safe for
trunk.

Unfortunately, I think that would mean that we would need to do nightly
testing on the 4.2.x branch, possibly in addition to trunk.


Right, that's a big problem. Another problem with this approach
is that it has the potential to destabilize the branch.

The second problem can be mitigated by tagging the branch when
it's known to be stable. I don't think there's anything we can
do about the first problem except alleviate it by implementing
a more intelligent test harness. I'm not sure we have cycles
for that...

Is there some convention or process we could put in place that
would make the bulk merge issue less painful? I wake up in the
middle of the night thinking about how we're going to manage
it for 4.2.1. Maybe it won't be so bad, but it does seem like
it will be a lot work and could be pretty error prone.

Martin

Re: [jira] Commented: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions

[Martin Sebor]

Travis Vitek wrote:
 


Travis Vitek commented on STDCXX-742:
-

This is happening because we don't use the -qrtti=dynamiccast 
option. We internally use a dynamic_cast to determine if the 
facet is of the correct derived type, but if dynamic_cast 
isn't supported we use a C style cast, and that returns bad results.


This case is essentially the same as STDCXX-664. We didn't add 
-qrtti=dynamiccast back then, and we just worked around the 
issue in the test. It seems to me that we should have added 
the flag. Would this be a binary compatible change?




What are the thoughts on this? There was some discussion
[http://tinyurl.com/3xfdma] of enabling -qrtti=dynamiccast for the
VisualAge C++ compiler, but it petered out. 


Is there any way to turn on rtti using a pragma? That way we could
enable it only for translation units that included  and we
wouldn't be shoving the option down the throats of users who don't
care about named locales.

Btw., does XLC++ itself correctly handle the test case mentioned
in the thread, even without -qrtti? (It's possible to get some
simple cases to work even w/o the option but not all of them).

Martin

RE: failing regression tests

[Travis Vitek]

 

>Martin Sebor wrote:
>
>Farid Zaripov wrote:
>>>
>>>Martin Sebor wrote:
>>>
>>> The regression tests below are all failing with SIGABRT.
>>> I check the issues and they have all been deferred, so what's 
>>> missing is an entry for each of these tests in xfail.txt to 
>>> mark them up on our build result pages.
>>>
>>>  21.string.assign.stdcxx-629
>>>  21.string.insert.stdcxx-630
>>>  21.string.insert.stdcxx-632
>>>  21.string.replace.stdcxx-170
>>>
>>> Farid, I think these are all your issues. Can you please take 
>>> care of updating xfail.txt when you have a chance?
>> 
>>   Done. It seems that the 21.string.insert.stdcxx-630 test 
>> is added by my mistake (the STDCXX-630 issue is about assign
>> string method and not about insert). So I deleted this test
>> from trunk.
>
>I think we need to decide if trunk is supposed to be a copy of
>4.2.x or if it's for development of future versions. If the
>latter, there's no problem with keeping tests like it there
>as long as they're passing or as long as there's an entry in
>xfail.txt. We just need to remember not to merge them (and
>fixes for them, if they're incompatible) out to 4.2.x.
>
>So, which is it? Do we keep trunk as a development version of
>4.2.x or do we make changes on it that are incompatible with
>4.2.x?
>

I'm thinking that all work for 4.2.1 should be done on the 4.2.x branch,
and future work should be done on trunk until an appropriate branch has
been created. That way we avoid having to be careful about bulk merges
from trunk to 4.2.1... Everything that is on 4.2.x should be safe for
trunk.

Unfortunately, I think that would mean that we would need to do nightly
testing on the 4.2.x branch, possibly in addition to trunk.

>Martin
>

Re: nightly build errors 4/1/08

[Martin Sebor]

Scott Zhong wrote:

OS: Solaris 10   compiler: sunpro 5.7 / 5.8 failure:

Caused by incorrect administration of /var directory.  Appears to be
fixed currently.

*

OS: tru64-5.1-alpha  compiler: Compaq-6.5:

Compiler license server issue, sent a help ticket to the infrastructure.

*

OS: Solaris 10   compiler: eccp-3.9:

Incorrect flag pass to the compiler, not infrastructure related.


Thanks for the note!

There are two problems: one with the -shared option (STDCXX-800)
and another with the linker not being able to find libm. There's
no issue for the second problem yet. We need to create one and
see if we can get away with not linking libm on Solaris 9 where
(I think) it may not be necessary.

Martin

RE: [jira] Commented: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions

[Travis Vitek]

 

>Travis Vitek commented on STDCXX-742:
>-
>
>This is happening because we don't use the -qrtti=dynamiccast 
>option. We internally use a dynamic_cast to determine if the 
>facet is of the correct derived type, but if dynamic_cast 
>isn't supported we use a C style cast, and that returns bad results.
>
>This case is essentially the same as STDCXX-664. We didn't add 
>-qrtti=dynamiccast back then, and we just worked around the 
>issue in the test. It seems to me that we should have added 
>the flag. Would this be a binary compatible change?
>

What are the thoughts on this? There was some discussion
[http://tinyurl.com/3xfdma] of enabling -qrtti=dynamiccast for the
VisualAge C++ compiler, but it petered out. 

Travis

Re: failing regression tests

[Martin Sebor]

Farid Zaripov wrote:

-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 28, 2008 10:42 PM

To: dev@stdcxx.apache.org
Subject: failing regression tests

The regression tests below are all failing with SIGABRT.
I check the issues and they have all been deferred, so what's 
missing is an entry for each of these tests in xfail.txt to 
mark them up on our build result pages.


 21.string.assign.stdcxx-629
 21.string.insert.stdcxx-630
 21.string.insert.stdcxx-632
 21.string.replace.stdcxx-170

Farid, I think these are all your issues. Can you please take 
care of updating xfail.txt when you have a chance?


  Done. It seems that the 21.string.insert.stdcxx-630 test is added by
my mistake
(the STDCXX-630 issue is about assign string method and not about
insert). So
I deleted this test from trunk.


I think we need to decide if trunk is supposed to be a copy of
4.2.x or if it's for development of future versions. If the
latter, there's no problem with keeping tests like it there
as long as they're passing or as long as there's an entry in
xfail.txt. We just need to remember not to merge them (and
fixes for them, if they're incompatible) out to 4.2.x.

So, which is it? Do we keep trunk as a development version of
4.2.x or do we make changes on it that are incompatible with
4.2.x?

Martin

Re: svn commit: r642397 - in /stdcxx/trunk/tests/src: braceexp.cpp locale.cpp

[Martin Sebor]

Travis Vitek wrote:
 


Martin Sebor wrote:

PING?

The sign extension issue is still there. I don't want it to 
get forgotten.





It was not forgotten. I decided to re-add the inline functions to avoid
having to cast to unsigned char all over the place.

  http://svn.apache.org/viewvc?view=rev&revision=643214


Great, that fixes locale.cpp. Thanks for doing that. I was also
(or mainly) pointing out the same problems in braceexp.cpp. I
hesitate to commit a fix myself in case you're working on the
file but here's a patch that addresses the remaining problems:

Index: tests/src/braceexp.cpp
===
--- tests/src/braceexp.cpp  (revision 643552)
+++ tests/src/braceexp.cpp  (working copy)
@@ -35,6 +35,10 @@
 #include 


+// for convenience
+typedef unsigned char UChar;
+
+
 // search `beg' to `end' for a character that `fn'
 // returns non-zero.
 static const char*
@@ -46,7 +50,7 @@

 for (/**/; beg < end; ++beg) {

-const bool is_space = 0 != isspace (*beg);
+const bool is_space = 0 != isspace (UChar (*beg));

 if (!is_escaped && match_space == is_space) {
 return beg;
@@ -682,8 +686,10 @@
 char cend = beg [4];

 // only works if sequence characters are both lowercase or uppercase.
-const int both_are_lower = islower (cbeg) && islower (cend);
-const int both_are_upper = isupper (cbeg) && isupper (cend);
+const int both_are_lower =
+islower (UChar (cbeg)) && islower (UChar (cend));
+const int both_are_upper =
+isupper (UChar (cbeg)) && isupper (UChar (cend));

 if (! (both_are_lower || both_are_upper))
 return 0;

Martin



Travis


Martin Sebor wrote:

[EMAIL PROTECTED] wrote:

Author: vitek
Date: Fri Mar 28 14:28:41 2008
New Revision: 642397

URL: http://svn.apache.org/viewvc?rev=642397&view=rev
Log:

2008-03-28  Travis Vitek  <[EMAIL PROTECTED]>

STDCXX-714
	* tests/src/braceexp.cpp: Remove _rw_isspace(), 

_rw_isupper() and

_rw_islower(). Use appropriate C library calls instead.

STDCXX-716
* tests/src/locale.cpp: Remove _rw_isspace(), _rw_toupper() and
_rw_tolower(). Use appropriate C library calls instead.


Travis, the isxxx() functions take an int argument and that their
domain is the values between 0 and UCHAR_MAX plus EOF (and their
behavior is undefined otherwise -- IIRC, the Microsoft functions
abort in the undefined case). When passed a plain char, the
argument is subject to sign extension where the type signed and
values between CHAR_MIN and -1 are invalid. To make sure the
functions always behave correctly it's best to cast the argument
to unsigned char.

Martin




Modified:
stdcxx/trunk/tests/src/braceexp.cpp
stdcxx/trunk/tests/src/locale.cpp

Modified: stdcxx/trunk/tests/src/braceexp.cpp
URL:


http://svn.apache.org/viewvc/stdcxx/trunk/tests/src/braceexp.cp
p?rev=642397&r1=642396&r2=642397&view=diff
===
===

--- stdcxx/trunk/tests/src/braceexp.cpp (original)
+++ stdcxx/trunk/tests/src/braceexp.cpp Fri Mar 28 14:28:41 2008
@@ -3,55 +3,14 @@
 
 #include  // for malloc(), free()

 #include  // for memcpy()
+#include   // for isspace()
 #include  // for assert()
 
 #include 
 
-inline int _rw_is_lower (int ch)

-{
-switch (ch) {
-case 'a': case 'b': case 'c': case 'd': case 'e': case 'f':
-case 'g': case 'h': case 'i': case 'j': case 'k': case 'l':
-case 'm': case 'n': case 'o': case 'p': case 'q': case 'r':
-case 's': case 't': case 'u': case 'v': case 'w': case 'x':
-case 'y': case 'z':
-return 1;
-}
-
-return 0;
-}
-
-inline int _rw_is_upper (int ch)
-{
-switch (ch) {
-case 'A': case 'B': case 'C': case 'D': case 'E': case 'F':
-case 'G': case 'H': case 'I': case 'J': case 'K': case 'L':
-case 'M': case 'N': case 'O': case 'P': case 'Q': case 'R':
-case 'S': case 'T': case 'U': case 'V': case 'W': case 'X':
-case 'Y': case 'Z':
-return 1;
-}
-
-return 0;
-}
-
-inline int _rw_is_space (int ch)
-{
-switch (ch)
-{
-case '\n':
-case '\r':
-case '\t':
-case ' ':
-return 1;
-}
-
-return 0;
-}
-
 inline int _rw_is_not_space (int ch)
 {
-return !_rw_is_space (ch);
+return !isspace (ch);
 }
 
 // search `beg' to `end' for a character that `fn'

@@ -696,8 +655,8 @@
 char cend = beg [4];
 
 // only works if sequence characters are both lowercase or

uppercase.
-const int both_are_lower = _rw_is_lower (cbeg) && _rw_is_lower
(cend);
-const int both_are_upper = _rw_is_upper (cbeg) && _rw_is_upper
(cend);
+const int both_are_lower = islower (cbeg) && islower (cend);
+const int both_are_upper = isupper (cbeg) && isupper (cend);
 
 if (! (both_are_lower || both_are_upper))

 return 0;
@@ -1050,7 +1009,7 @@
 
 while (tok_beg)

 {
-const char* tok_en

RE: svn commit: r642397 - in /stdcxx/trunk/tests/src: braceexp.cpp locale.cpp

[Travis Vitek]

 

>Martin Sebor wrote:
>
>PING?
>
>The sign extension issue is still there. I don't want it to 
>get forgotten.
>
>

It was not forgotten. I decided to re-add the inline functions to avoid
having to cast to unsigned char all over the place.

  http://svn.apache.org/viewvc?view=rev&revision=643214

Travis

>Martin Sebor wrote:
>> 
>> [EMAIL PROTECTED] wrote:
>>> Author: vitek
>>> Date: Fri Mar 28 14:28:41 2008
>>> New Revision: 642397
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=642397&view=rev
>>> Log:
>>> 
>>> 2008-03-28  Travis Vitek  <[EMAIL PROTECTED]>
>>> 
>>> STDCXX-714
>>> * tests/src/braceexp.cpp: Remove _rw_isspace(), 
>_rw_isupper() and
>>> _rw_islower(). Use appropriate C library calls instead.
>>> 
>>> STDCXX-716
>>> * tests/src/locale.cpp: Remove _rw_isspace(), _rw_toupper() and
>>> _rw_tolower(). Use appropriate C library calls instead.
>> 
>> 
>> Travis, the isxxx() functions take an int argument and that their
>> domain is the values between 0 and UCHAR_MAX plus EOF (and their
>> behavior is undefined otherwise -- IIRC, the Microsoft functions
>> abort in the undefined case). When passed a plain char, the
>> argument is subject to sign extension where the type signed and
>> values between CHAR_MIN and -1 are invalid. To make sure the
>> functions always behave correctly it's best to cast the argument
>> to unsigned char.
>> 
>> Martin
>> 
>>> 
>>> 
>>> Modified:
>>> stdcxx/trunk/tests/src/braceexp.cpp
>>> stdcxx/trunk/tests/src/locale.cpp
>>> 
>>> Modified: stdcxx/trunk/tests/src/braceexp.cpp
>>> URL:
>>> 
>http://svn.apache.org/viewvc/stdcxx/trunk/tests/src/braceexp.cp
>p?rev=642397&r1=642396&r2=642397&view=diff
>>> 
>===
>===
>>> --- stdcxx/trunk/tests/src/braceexp.cpp (original)
>>> +++ stdcxx/trunk/tests/src/braceexp.cpp Fri Mar 28 14:28:41 2008
>>> @@ -3,55 +3,14 @@
>>>  
>>>  #include  // for malloc(), free()
>>>  #include  // for memcpy()
>>> +#include   // for isspace()
>>>  #include  // for assert()
>>>  
>>>  #include 
>>>  
>>> -inline int _rw_is_lower (int ch)
>>> -{
>>> -switch (ch) {
>>> -case 'a': case 'b': case 'c': case 'd': case 'e': case 'f':
>>> -case 'g': case 'h': case 'i': case 'j': case 'k': case 'l':
>>> -case 'm': case 'n': case 'o': case 'p': case 'q': case 'r':
>>> -case 's': case 't': case 'u': case 'v': case 'w': case 'x':
>>> -case 'y': case 'z':
>>> -return 1;
>>> -}
>>> -
>>> -return 0;
>>> -}
>>> -
>>> -inline int _rw_is_upper (int ch)
>>> -{
>>> -switch (ch) {
>>> -case 'A': case 'B': case 'C': case 'D': case 'E': case 'F':
>>> -case 'G': case 'H': case 'I': case 'J': case 'K': case 'L':
>>> -case 'M': case 'N': case 'O': case 'P': case 'Q': case 'R':
>>> -case 'S': case 'T': case 'U': case 'V': case 'W': case 'X':
>>> -case 'Y': case 'Z':
>>> -return 1;
>>> -}
>>> -
>>> -return 0;
>>> -}
>>> -
>>> -inline int _rw_is_space (int ch)
>>> -{
>>> -switch (ch)
>>> -{
>>> -case '\n':
>>> -case '\r':
>>> -case '\t':
>>> -case ' ':
>>> -return 1;
>>> -}
>>> -
>>> -return 0;
>>> -}
>>> -
>>>  inline int _rw_is_not_space (int ch)
>>>  {
>>> -return !_rw_is_space (ch);
>>> +return !isspace (ch);
>>>  }
>>>  
>>>  // search `beg' to `end' for a character that `fn'
>>> @@ -696,8 +655,8 @@
>>>  char cend = beg [4];
>>>  
>>>  // only works if sequence characters are both lowercase or
>>> uppercase.
>>> -const int both_are_lower = _rw_is_lower (cbeg) && _rw_is_lower
>>> (cend);
>>> -const int both_are_upper = _rw_is_upper (cbeg) && _rw_is_upper
>>> (cend);
>>> +const int both_are_lower = islower (cbeg) && islower (cend);
>>> +const int both_are_upper = isupper (cbeg) && isupper (cend);
>>>  
>>>  if (! (both_are_lower || both_are_upper))
>>>  return 0;
>>> @@ -1050,7 +1009,7 @@
>>>  
>>>  while (tok_beg)
>>>  {
>>> -const char* tok_end = _rw_find_match (tok_beg, end,
>>> _rw_is_space);
>>> +const char* tok_end = _rw_find_match (tok_beg, 
>end, isspace);
>>>  if (!tok_end)
>>>  tok_end = end;
>>>  
>>> 
>>> Modified: stdcxx/trunk/tests/src/locale.cpp
>>> URL:
>>> 
>http://svn.apache.org/viewvc/stdcxx/trunk/tests/src/locale.cpp?
>rev=642397&r1=642396&r2=642397&view=diff
>>> 
>===
>===
>>> --- stdcxx/trunk/tests/src/locale.cpp (original)
>>> +++ stdcxx/trunk/tests/src/locale.cpp Fri Mar 28 14:28:41 2008
>>> @@ -951,59 +951,6 @@
>>>  struct _rw_locale_entry* next;
>>>  };
>>>  
>>> -static int
>>> -_rw_toupper (int chr)
>>> -{
>>> -//if (chr < 'a' || 'z' < chr)
>>> -//return chr;
>>> -//return chr - 'a' + 'A';
>>> -switch (chr)
>>> -{
>>> -case 'a': case 'b': case 'c': case 'd': case 'e': case 'f':
>>> -case 'g': case 'h': case 'i': case 'j': case 'k': cas

RE: regression in 23.deque.iterators

[Farid Zaripov]

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Friday, March 28, 2008 10:54 PM
> To: dev@stdcxx.apache.org
> Subject: regression in 23.deque.iterators
> 
> The 23.deque.iterators test is failing with a SIGABRT.
> Reverting the most recent changes to deque made to fix
> STDCXX-635 lets the test pass. Farid, can you please look into it?
> http://svn.apache.org/viewvc?view=rev&revision=637539
> 

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

Farid.

RE: failing regression tests

[Farid Zaripov]

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Friday, March 28, 2008 10:42 PM
> To: dev@stdcxx.apache.org
> Subject: failing regression tests
> 
> The regression tests below are all failing with SIGABRT.
> I check the issues and they have all been deferred, so what's 
> missing is an entry for each of these tests in xfail.txt to 
> mark them up on our build result pages.
> 
>  21.string.assign.stdcxx-629
>  21.string.insert.stdcxx-630
>  21.string.insert.stdcxx-632
>  21.string.replace.stdcxx-170
> 
> Farid, I think these are all your issues. Can you please take 
> care of updating xfail.txt when you have a chance?

  Done. It seems that the 21.string.insert.stdcxx-630 test is added by
my mistake
(the STDCXX-630 issue is about assign string method and not about
insert). So
I deleted this test from trunk.

Farid.

Re: svn commit: r642397 - in /stdcxx/trunk/tests/src: braceexp.cpp locale.cpp

[Martin Sebor]

PING?

The sign extension issue is still there. I don't want it to get forgotten.


Martin Sebor wrote:
> 
> [EMAIL PROTECTED] wrote:
>> Author: vitek
>> Date: Fri Mar 28 14:28:41 2008
>> New Revision: 642397
>> 
>> URL: http://svn.apache.org/viewvc?rev=642397&view=rev
>> Log:
>> 
>> 2008-03-28  Travis Vitek  <[EMAIL PROTECTED]>
>> 
>>  STDCXX-714
>>  * tests/src/braceexp.cpp: Remove _rw_isspace(), _rw_isupper() and
>>  _rw_islower(). Use appropriate C library calls instead.
>> 
>>  STDCXX-716
>>  * tests/src/locale.cpp: Remove _rw_isspace(), _rw_toupper() and
>>  _rw_tolower(). Use appropriate C library calls instead.
> 
> 
> Travis, the isxxx() functions take an int argument and that their
> domain is the values between 0 and UCHAR_MAX plus EOF (and their
> behavior is undefined otherwise -- IIRC, the Microsoft functions
> abort in the undefined case). When passed a plain char, the
> argument is subject to sign extension where the type signed and
> values between CHAR_MIN and -1 are invalid. To make sure the
> functions always behave correctly it's best to cast the argument
> to unsigned char.
> 
> Martin
> 
>>  
>> 
>> Modified:
>> stdcxx/trunk/tests/src/braceexp.cpp
>> stdcxx/trunk/tests/src/locale.cpp
>> 
>> Modified: stdcxx/trunk/tests/src/braceexp.cpp
>> URL:
>> http://svn.apache.org/viewvc/stdcxx/trunk/tests/src/braceexp.cpp?rev=642397&r1=642396&r2=642397&view=diff
>> ==
>> --- stdcxx/trunk/tests/src/braceexp.cpp (original)
>> +++ stdcxx/trunk/tests/src/braceexp.cpp Fri Mar 28 14:28:41 2008
>> @@ -3,55 +3,14 @@
>>  
>>  #include  // for malloc(), free()
>>  #include  // for memcpy()
>> +#include   // for isspace()
>>  #include  // for assert()
>>  
>>  #include 
>>  
>> -inline int _rw_is_lower (int ch)
>> -{
>> -switch (ch) {
>> -case 'a': case 'b': case 'c': case 'd': case 'e': case 'f':
>> -case 'g': case 'h': case 'i': case 'j': case 'k': case 'l':
>> -case 'm': case 'n': case 'o': case 'p': case 'q': case 'r':
>> -case 's': case 't': case 'u': case 'v': case 'w': case 'x':
>> -case 'y': case 'z':
>> -return 1;
>> -}
>> -
>> -return 0;
>> -}
>> -
>> -inline int _rw_is_upper (int ch)
>> -{
>> -switch (ch) {
>> -case 'A': case 'B': case 'C': case 'D': case 'E': case 'F':
>> -case 'G': case 'H': case 'I': case 'J': case 'K': case 'L':
>> -case 'M': case 'N': case 'O': case 'P': case 'Q': case 'R':
>> -case 'S': case 'T': case 'U': case 'V': case 'W': case 'X':
>> -case 'Y': case 'Z':
>> -return 1;
>> -}
>> -
>> -return 0;
>> -}
>> -
>> -inline int _rw_is_space (int ch)
>> -{
>> -switch (ch)
>> -{
>> -case '\n':
>> -case '\r':
>> -case '\t':
>> -case ' ':
>> -return 1;
>> -}
>> -
>> -return 0;
>> -}
>> -
>>  inline int _rw_is_not_space (int ch)
>>  {
>> -return !_rw_is_space (ch);
>> +return !isspace (ch);
>>  }
>>  
>>  // search `beg' to `end' for a character that `fn'
>> @@ -696,8 +655,8 @@
>>  char cend = beg [4];
>>  
>>  // only works if sequence characters are both lowercase or
>> uppercase.
>> -const int both_are_lower = _rw_is_lower (cbeg) && _rw_is_lower
>> (cend);
>> -const int both_are_upper = _rw_is_upper (cbeg) && _rw_is_upper
>> (cend);
>> +const int both_are_lower = islower (cbeg) && islower (cend);
>> +const int both_are_upper = isupper (cbeg) && isupper (cend);
>>  
>>  if (! (both_are_lower || both_are_upper))
>>  return 0;
>> @@ -1050,7 +1009,7 @@
>>  
>>  while (tok_beg)
>>  {
>> -const char* tok_end = _rw_find_match (tok_beg, end,
>> _rw_is_space);
>> +const char* tok_end = _rw_find_match (tok_beg, end, isspace);
>>  if (!tok_end)
>>  tok_end = end;
>>  
>> 
>> Modified: stdcxx/trunk/tests/src/locale.cpp
>> URL:
>> http://svn.apache.org/viewvc/stdcxx/trunk/tests/src/locale.cpp?rev=642397&r1=642396&r2=642397&view=diff
>> ==
>> --- stdcxx/trunk/tests/src/locale.cpp (original)
>> +++ stdcxx/trunk/tests/src/locale.cpp Fri Mar 28 14:28:41 2008
>> @@ -951,59 +951,6 @@
>>  struct _rw_locale_entry* next;
>>  };
>>  
>> -static int
>> -_rw_toupper (int chr)
>> -{
>> -//if (chr < 'a' || 'z' < chr)
>> -//return chr;
>> -//return chr - 'a' + 'A';
>> -switch (chr)
>> -{
>> -case 'a': case 'b': case 'c': case 'd': case 'e': case 'f':
>> -case 'g': case 'h': case 'i': case 'j': case 'k': case 'l':
>> -case 'm': case 'n': case 'o': case 'p': case 'q': case 'r':
>> -case 's': case 't': case 'u': case 'v': case 'w': case 'x':
>> -case 'y': case 'z':
>> -return chr - 'a' + 'A';
>> -}
>> -
>> -return chr;
>> -}
>> -
>> -static int
>> -_rw_tolower (int chr)
>> -{
>> -//if (chr < 'A' || 'Z' < chr)
>> -//return chr;
>> -//return ch

Re: Building Tests

[Martin Sebor]

Eric Lemings wrote:
 


-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Friday, March 21, 2008 5:41 PM
To: dev@stdcxx.apache.org
Subject: Re: Building Tests

Eric Lemings wrote:
 
I haven't looked to confirm this but it looks like the Makefile(s)

ignore errors building the test programs but the build process still
stops (i.e. exits successfully).  I was wondering if the Makefile(s)
shouldn't also continue building the remaining test 

programs (i.e. set

MAKEFLAGS=-k before invoking the test Makefile).

I don't think the makefiles ignore build errors.


If you do a build on a platform where one of the test programs fails
to build, the make process will exit and will not build the remaining
test programs but the run target will still try to run these unbuilt
tests.


That's by design so the tests that fail to compile are reported
as such. Otherwise, if exec skipped them, build failures would
not show up in our nightly build results.




[...]


So, I think it makes sense that if the run target tries to run all
tests, then the target that builds the test programs should also
try to build as many test programs as possible.  Either that or
make the target that runs each test output dependent on the
respective test program so it only tries to run it if it is up to
date.


The latter could be done.

Martin

Re: svn commit: r643473 - /stdcxx/trunk/tests/support/18.numeric.special.float.cpp

[Martin Sebor]

Eric Lemings wrote:
 

[...]

STDCXX-708 

Each line should be indented by a single TAB. The issue URL
shouldn't be here.


Why not?


Because we don't put it there. There's a documented convention
that we follow (see below). It says nothing about any link. I
don't think we need the link but if you'd like to change the
convention feel free to write up a proposal.

http://stdcxx.apache.org/bugs.html#patch_format




* tests/support/18.numeric.special.float.cpp:

The names of the function you changed should be listed in
parentheses, like so:

* tests/support/18.numeric.special.float.cpp
(limits_values::has_denorm): ...


How do you specify partial function template specializations?


There's no such thing.

The point of the function names in the parentheses is to
help people find the changes that they might be interested
in without having to scan the whole diff. It's a judgment
call how accurately the name should identify the exact
specific function among a set of overloads or some such
ambiguities.



Most (probably all) of the GNU ChangeLog conventions were written for
C and don't translate to more advanced C++ features very well.  Not
to say that we couldn't tailor them; just need to have them in
writing somewhere.


If your changes are conditional (i.e., based on some preprocessor
macro), you should list the conditional in square brackets before
the list of the functions it applies to, e.g.,

* tests/support/18.numeric.special.float.cpp
[_AIX || __hpux] (limits_values::has_denorm): ...


I don't recall seeing this convention in the GNU docs anywhere.


It's described in the GNU coding standars:
http://www.gnu.org/prep/standards/html_node/Conditional-Changes.html#Conditional-Changes

Martin

RE: svn commit: r643473 - /stdcxx/trunk/tests/support/18.numeric.special.float.cpp

[Eric Lemings]

 

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 01, 2008 11:13 AM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r643473 - 
> /stdcxx/trunk/tests/support/18.numeric.special.float.cpp
> 
...
> 
> If you use Emacs, the add-change-log-entry command produces
> the correct format automatically.

I don't use Emacs.

> 
> You can see examples of correctly formatted entries in
> the ChangeLog file:
> http://svn.apache.org/repos/asf/stdcxx/trunk/ChangeLog
> for examples.
> 
> > Log:
> > Tue Apr  1 16:28:22 UTC 2008Eric Lemings 
> <[EMAIL PROTECTED]>
> 
> The date format is -MM-DD.
> 
> > 
> > STDCXX-708 
> 
> Each line should be indented by a single TAB. The issue URL
> shouldn't be here.

Why not?

> 
> > * tests/support/18.numeric.special.float.cpp:
> 
> The names of the function you changed should be listed in
> parentheses, like so:
> 
>   * tests/support/18.numeric.special.float.cpp
>   (limits_values::has_denorm): ...

How do you specify partial function template specializations?

Most (probably all) of the GNU ChangeLog conventions were written for
C and don't translate to more advanced C++ features very well.  Not
to say that we couldn't tailor them; just need to have them in
writing somewhere.

> If your changes are conditional (i.e., based on some preprocessor
> macro), you should list the conditional in square brackets before
> the list of the functions it applies to, e.g.,
> 
>   * tests/support/18.numeric.special.float.cpp
>   [_AIX || __hpux] (limits_values::has_denorm): ...

I don't recall seeing this convention in the GNU docs anywhere.

> 
> You can correct this Change Log entry via the svn propedit
> command, like so:
> 
> svn propedit svn:log --revprop -r643473 \
>  https://svn.apache.org/repos/asf/stdcxx

Fixed.

BTW, are these ChangeLogs parsed by any tools (other than Emacs)?

Also, I have another great idea.  Tweak the Subversion checkin command
so that it automatically provides a GNU ChangeLog template format as
the default change description.  That would save us a lot of time
putting change descriptions in the right format (and telling others to
do the same).  :)

Brad.

RE: [jira] Commented: (STDCXX-708) [HP aCC 6.15/HP-UX/IPF] 18.numeric.special.float fails assertions

[Eric Lemings]

 
Yeah, the LDBL_EPSILON macro is getting undefined and redefined in
the etc/config/src/float_defs.h header.

file stdcxx/trunk/etc/config/float_defs.h:
 30 #  if defined (__EDG__) && !defined (__INTEL_COMPILER)
 31  // define gcc 4 intrinsics otherwise not recognized
 32  // by the front end
...
 67 #if __GNUC__ < 4
 68
 69   // prevent the propriterary gcc __extension__ from
 70   // throwing the vanilla EDG demo for a loop
 71
 72 #  undef LDBL_EPSILON
 73 #  undef LDBL_MIN
 74 #  undef LDBL_MAX
 75
 76// redefine to prevent compilation errors
 77 #  define LDBL_EPSILON 1.0842021724855044e-19L
...

Does the block starting at line 30 really apply to all compilers using
an EDG front-end other than Intel C++?  Or only to GCC?  The comment
suggests that it applies only to GCC.

If so, either the directive at line 30 should be written as follows:

 30 #  if defined (__EDG__) && defined (__GNUC__) && !defined
(__INTEL_COMPILER)
 31  // define gcc 4 intrinsics otherwise not recognized
 32  // by the front end

Or the directive at line 67 should be written like this:

 67 #if defined (__GNUC__) && __GNUC__ < 4

Oui?

Brad.

> -Original Message-
> From: Martin Sebor (JIRA) [mailto:[EMAIL PROTECTED] 
> Sent: Monday, March 31, 2008 7:02 PM
> To: Eric Lemings
> Subject: [jira] Commented: (STDCXX-708) [HP aCC 
> 6.15/HP-UX/IPF] 18.numeric.special.float fails assertions
> 
> 
> [ 
> https://issues.apache.org/jira/browse/STDCXX-708?page=com.atla
> ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focus
> edCommentId=12583959#action_12583959 ] 
> 
> Martin Sebor commented on STDCXX-708:
> -
> 
> I wonder if the EDG-specific macros in 
> [float_defs.h|http://svn.apache.org/repos/asf/stdcxx/branches/
> 4.2.x/etc/config/src/float_defs.h] might have something to do 
> with it. Recall that HP aCC 6 is based on the EDG front end 
> and like other such compilers {{#defines}} the {{\_\_EDG__}} 
> macro. The preprocessor conditional needs to be adjusted 
> along the same lines as the one in 
> [_config.h|http://svn.apache.org/repos/asf/stdcxx/trunk/includ
> e/rw/_config.h]:
> 
> {noformat}
>190  // NOTE: the __EDG__ macro is #defined by most 
> EDG-based compilers
>191  
>192  #ifdefined (__EDG__)\
>193  && !defined (__DECCXX)  \
>194  && !defined (__HP_aCC)  \
>195  && !defined (__INTEL_COMPILER)  \
>196  && !defined (_SGI_COMPILER_VERSION)
> {noformat}
> 
> > [HP aCC 6.15/HP-UX/IPF] 18.numeric.special.float fails assertions
> > -
> >
> > Key: STDCXX-708
> > URL: 
> https://issues.apache.org/jira/browse/STDCXX-708
> > Project: C++ Standard Library
> >  Issue Type: Bug
> >  Components: Tests
> >Affects Versions: trunk
> > Environment: {noformat}
> > $ uname -srm && aCC -V
> > HP-UX B.11.31 ia64
> > aCC: HP C/aC++ B3910B A.06.15 [May 16 2007]
> > {noformat}
> >Reporter: Martin Sebor
> >Assignee: Eric Lemings
> > Fix For: 4.2.1
> >
> >   Original Estimate: 4h
> >  Time Spent: 6h
> >  Remaining Estimate: 0h
> >
> > When compiled with HP aCC 6 on HP-UX running on IPF 
> hardware the newly added test 
> [18.numeric.special.float.cpp|http://svn.apache.org/viewvc/std
> cxx/trunk/tests/support/18.numeric.special.float.cpp] fails a 
> bunch of assertions.
> > One of them look like a configuration problem in the 
> library (has_denorm) while others (min(), max(), and 
> epsilon()) like problems in the test
> > {noformat}
> > $ nice gmake 18.numeric.special.float -r && 
> ./18.numeric.special.float
> > aCC -c  -D_RWSTDDEBUG   -mt -I/amd/devco/sebor/stdcxx/include \
> > -I/build/sebor/stdcxx-aCC-6.15-15D/include 
> -I/amd/devco/sebor/stdcxx/tests/include  \
> > -AA  -g +d  +DD64 +w +W392 +W655 +W684 +W818 +W819 +W849 
> +W2193 +W2236 +W2261 \
> > +W2340 +W2401 +W2487 +W4227 +W4229 +W4231 +W4235 +W4237 
> +W4249 +W4255 +W4272 \
> > +W4284 +W4285 +W4286   
> /amd/devco/sebor/stdcxx/tests/support/18.numeric.special.float.cpp
> > "/amd/devco/sebor/stdcxx/include/limits", line 449: warning 
> #4070-D: floating
> >   point underflow exception
> >   _RWSTD_STATIC_FUN (long double, (min), _RWSTD_LDBL_MIN) 
> >   ^
> > aCC 18.numeric.special.float.o -o 18.numeric.special.float \
> > -L/build/sebor/stdcxx-aCC-6.15-15D/rwtest -lrwtest15D -AA 
> +nostl -Wl,+s   -mt +DD64 \
> > -L/build/sebor/stdcxx-aCC-6.15-15D/lib  \
> > 
> -Wl,+b/build/sebor/stdcxx-aCC-6.15-15D/lib:/build/sebor/stdcxx
> -aCC-6.15-15D/rwtest \
> > -lstd15D  -lm 
> > rm 18.numeric.special.float.o
> > # INFO (S1) (10 lines):
> > 

Re: svn commit: r643473 - /stdcxx/trunk/tests/support/18.numeric.special.float.cpp

[Martin Sebor]

[EMAIL PROTECTED] wrote:

Author: elemings
Date: Tue Apr  1 09:40:44 2008
New Revision: 643473

URL: http://svn.apache.org/viewvc?rev=643473&view=rev


Brad, a few notes on the format of your Change Log. Our
convention is to use the GNU/Emacs format for Change Logs
described in the Emacs manual:
http://www.gnu.org/software/emacs/manual/html_node/emacs/Change-Log.html#Change-Log

If you use Emacs, the add-change-log-entry command produces
the correct format automatically.

You can see examples of correctly formatted entries in
the ChangeLog file:
http://svn.apache.org/repos/asf/stdcxx/trunk/ChangeLog
for examples.


Log:
Tue Apr  1 16:28:22 UTC 2008Eric Lemings <[EMAIL PROTECTED]>


The date format is -MM-DD.



STDCXX-708 


Each line should be indented by a single TAB. The issue URL
shouldn't be here.


* tests/support/18.numeric.special.float.cpp:


The names of the function you changed should be listed in
parentheses, like so:

* tests/support/18.numeric.special.float.cpp
(limits_values::has_denorm): ...

If your changes are conditional (i.e., based on some preprocessor
macro), you should list the conditional in square brackets before
the list of the functions it applies to, e.g.,

* tests/support/18.numeric.special.float.cpp
[_AIX || __hpux] (limits_values::has_denorm): ...

You can correct this Change Log entry via the svn propedit
command, like so:

svn propedit svn:log --revprop -r643473 \
https://svn.apache.org/repos/asf/stdcxx

Thanks
Martin


Change expected values for
std::numeric_limits::has_denorm() to std::denorm_present on all
HP-UX platforms (inc. PA-RISC and IPF) per comments recorded in the issue.


Modified:
stdcxx/trunk/tests/support/18.numeric.special.float.cpp

Modified: stdcxx/trunk/tests/support/18.numeric.special.float.cpp
URL: 
http://svn.apache.org/viewvc/stdcxx/trunk/tests/support/18.numeric.special.float.cpp?rev=643473&r1=643472&r2=643473&view=diff
==
--- stdcxx/trunk/tests/support/18.numeric.special.float.cpp (original)
+++ stdcxx/trunk/tests/support/18.numeric.special.float.cpp Tue Apr  1 09:40:44 
2008
@@ -451,11 +451,9 @@
 
 static std::float_denorm_style has_denorm () {
 
-#if defined (_AIX)

-return std::denorm_present;
-#elif defined (__hpux)
-return std::denorm_indeterminate;
-#elif defined (__osf__)
+#if defined (_AIX) \
+|| defined (__hpux) \
+|| defined (__osf__)
 return std::denorm_present;
 #else
 return std::denorm_indeterminate;
@@ -720,11 +718,9 @@
 
 
 static std::float_denorm_style has_denorm () {

-#if defined (_AIX)
-return std::denorm_present;
-#elif defined (__hpux)
-return std::denorm_indeterminate;
-#elif defined (__osf__)
+#if defined (_AIX) \
+|| defined (__hpux) \
+|| defined (__osf__)
 return std::denorm_present;
 #else
 return std::denorm_indeterminate;
@@ -982,11 +978,9 @@
 
 
 static std::float_denorm_style has_denorm () {

-#if defined (_AIX)
-return std::denorm_present;
-#elif defined (__hpux)
-return std::denorm_indeterminate;
-#elif defined (__osf__)
+#if defined (_AIX) \
+|| defined (__hpux) \
+|| defined (__osf__)
 return std::denorm_present;
 #else
 return std::denorm_indeterminate;

Re: [aCC 6.05] too many warnings

[Andrew Black]

Martin Sebor wrote:
> Scott Zhong wrote:
>> In the debug build of aCC 6.05 for stdcxx trunk, there are too many
>> warnings that made the build log file to be larger than what the nightly
>> build infrastructure could handle.  This is causing debug builds to show
>> up as DATA in the results page.
> 
> Thanks for the heads up. Is there any way to get a partial log
> so we can tell which warnings are generating the most noise and
> silence them?

One method that comes to mind for trimming the log is to pipe the output
of the buildntest script to head, but the options required to limit the
output to some number of bytes appear to vary from platform to platform,
so you'd have to change the flags used to conform to the platform.  This
could be done in the nightly testing glue scripts.

--Andrew Black

RE: [aCC 6.05] too many warnings

[Scott Zhong]

No, not currently, it is within the function that saves the log that
throw an exception.   

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 01, 2008 10:06 AM
> To: dev@stdcxx.apache.org
> Subject: Re: [aCC 6.05] too many warnings
> 
> Scott Zhong wrote:
> > In the debug build of aCC 6.05 for stdcxx trunk, there are too many
> > warnings that made the build log file to be larger than what the
nightly
> > build infrastructure could handle.  This is causing debug builds to
show
> > up as DATA in the results page.
> 
> Thanks for the heads up. Is there any way to get a partial log
> so we can tell which warnings are generating the most noise and
> silence them?
> 
> Martin

Re: svn commit: r643448 - /stdcxx/trunk/etc/config/windows/run_locale_utils.wsf

[Andrew Black]

Martin Sebor wrote:
> [EMAIL PROTECTED] wrote:
>> Author: ablack
>> Date: Tue Apr  1 08:36:22 2008
>> New Revision: 643448
>>
>> URL: http://svn.apache.org/viewvc?rev=643448&view=rev
>> Log:
>> 2008-04-01  Andrew Black  <[EMAIL PROTECTED]>
>>
>> * etc/config/windows/run_locale_utils.wsf (run_locale_utils):
>> Replication of r643435 for Windows. (Update result footer format to
>> match format expected by exec utility. Footer search logic changed
>> in r643120.)
> 
> Does this by any chance fix the recent failures in locale tests?
> E.g., In these builds:
> 
> http://people.apache.org/~sebor/stdcxx/results/hpux-11.11-pa-acc-3.73-11S-643226-log.gz.txt
> 
> http://people.apache.org/~sebor/stdcxx/results/linux_redhat_el-3.8-em64t-gcc-3.2.3-11d-643226-log.gz.txt
> 

That's the intent (Well, r643435 is actually the change which fixes the
referenced builds, with r643448 fixing the windows builds which
exhibited the same problem.).  I checked the unix change locally before
checking it into subversion.

What happened is that r643120 altered the test parser to look for the
string '| INACTIVE |\n# +' when it was searching for the start of the
result header, but the test scripts were outputting '|INACTIVE|\n# +',
so a match wasn't found, producing the format messages.

--Andrew Black

> 
> Martin

nightly build errors 4/1/08

[Scott Zhong]

OS: Solaris 10   compiler: sunpro 5.7 / 5.8 failure:

Caused by incorrect administration of /var directory.  Appears to be
fixed currently.

*

OS: tru64-5.1-alpha  compiler: Compaq-6.5:

Compiler license server issue, sent a help ticket to the infrastructure.

*

OS: Solaris 10   compiler: eccp-3.9:

Incorrect flag pass to the compiler, not infrastructure related.

Re: svn commit: r643448 - /stdcxx/trunk/etc/config/windows/run_locale_utils.wsf

[Martin Sebor]

[EMAIL PROTECTED] wrote:

Author: ablack
Date: Tue Apr  1 08:36:22 2008
New Revision: 643448

URL: http://svn.apache.org/viewvc?rev=643448&view=rev
Log:
2008-04-01  Andrew Black  <[EMAIL PROTECTED]>

* etc/config/windows/run_locale_utils.wsf (run_locale_utils):
Replication of r643435 for Windows. (Update result footer format to
match format expected by exec utility. Footer search logic changed
in r643120.)


Does this by any chance fix the recent failures in locale tests?
E.g., In these builds:

http://people.apache.org/~sebor/stdcxx/results/hpux-11.11-pa-acc-3.73-11S-643226-log.gz.txt
http://people.apache.org/~sebor/stdcxx/results/linux_redhat_el-3.8-em64t-gcc-3.2.3-11d-643226-log.gz.txt

Martin




Modified:
stdcxx/trunk/etc/config/windows/run_locale_utils.wsf

Modified: stdcxx/trunk/etc/config/windows/run_locale_utils.wsf
URL: 
http://svn.apache.org/viewvc/stdcxx/trunk/etc/config/windows/run_locale_utils.wsf?rev=643448&r1=643447&r2=643448&view=diff
==
--- stdcxx/trunk/etc/config/windows/run_locale_utils.wsf (original)
+++ stdcxx/trunk/etc/config/windows/run_locale_utils.wsf Tue Apr  1 08:36:22 
2008
@@ -711,14 +711,15 @@
 {
 var pcnt = 100 * (assertions - failedassertions) / assertions;
 pcnt = Math.floor(pcnt + 0.5);
-outstrm.WriteLine("# 
+---++++");
-outstrm.WriteLine("# | DIAGNOSTIC| ACTIVE |  TOTAL 
|INACTIVE|");
-outstrm.WriteLine("# 
+---++++");
-outstrm.WriteLine("# | (S7) ASSERTION| " + 
FormatNumber(failedassertions, 6)
-+ " | " + FormatNumber(assertions, 6) + " | " + FormatNumber(pcnt, 5) + 
"% |");
-outstrm.WriteLine("# 
+---++++");
+outstrm.WriteLine("# 
+---+--+--+--+");
+outstrm.WriteLine("# | DIAGNOSTIC|  ACTIVE  |   TOTAL  | 
INACTIVE |");
+outstrm.WriteLine("# 
+---+--+--+--+");
+outstrm.WriteLine("# | (S7) ASSERTION| " + 
FormatNumber(failedassertions, 8)
++ " | " + FormatNumber(assertions, 8) + " | " + FormatNumber(pcnt, 7) + 
"% |");
+outstrm.WriteLine("# 
+---+--+--+--+");
 outstrm.WriteLine();
 }
+outstrm.WriteLine("## Warnings = 0");
 outstrm.WriteLine("## Assertions = " + assertions);
 outstrm.WriteLine("## FailedAssertions = " + failedassertions);
 outstrm.WriteLine();

Re: [aCC 6.05] too many warnings

[Martin Sebor]

Scott Zhong wrote:

In the debug build of aCC 6.05 for stdcxx trunk, there are too many
warnings that made the build log file to be larger than what the nightly
build infrastructure could handle.  This is causing debug builds to show
up as DATA in the results page.


Thanks for the heads up. Is there any way to get a partial log
so we can tell which warnings are generating the most noise and
silence them?

Martin

[aCC 6.05] too many warnings

[Scott Zhong]

In the debug build of aCC 6.05 for stdcxx trunk, there are too many
warnings that made the build log file to be larger than what the nightly
build infrastructure could handle.  This is causing debug builds to show
up as DATA in the results page.