Farid Zaripov wrote:
-Original Message-
From: Liviu Nicoara [mailto:[EMAIL PROTECTED]
[...]
I was wondering if you
believe it would be possible to have the Windows
infrastructure (of which I know next to nothing) generate a
pdb file in the lib directory
Done: http
An issue has been discovered in our automated builds where the stdcxx
debug info is not accessible when we build the downstream products on
top of stdcxx. I was wondering if you believe it would be possible to
have the Windows infrastructure (of which I know next to nothing)
generate a pdb file
Martin Sebor wrote:
Liviu Nicoara wrote:
+1.
Thanks!
Just for the record, what particular platform (compiler/OS) and
configuration did you test the tarball on?
Slack 10.1, gcc 4.2.0, 11s. I've got:
PROGRAM SUMMARY:
Programs:187
Non-zero exit status: 0
Sign
+1.
Martin Sebor wrote:
I just created the next stdcxx 4.2.0 release candidate tag,
stdcxx-4.2.0-rc-7, that incorporates changes addressing issues
pointed out in the original vote thread.
http://svn.apache.org/repos/asf/incubator/stdcxx/tags/4.2.0-rc-7/
The tarball containing the release candid
Martin Sebor wrote:
[...]
It occurs to me that we might be able to preempt a potentially
contentious discussion by replacing the stdcxx Acknowledgment
page with one describing the pre-stdcxx history of the project
where we could retain any or all the names from the current
acknowledgment page wit
Martin Sebor wrote:
Liviu Nicoara wrote:
I noticed that -- like other RW libs -- stdcxx does build the atomic
ops sources even in ST builds although the logic in rw/_mutex.h picks
up the vanilla implementation in 8-11 builds. Is this a mere slip?
Yeah, I guess it does. I've never th
I noticed that -- like other RW libs -- stdcxx does build the atomic ops
sources even in ST builds although the logic in rw/_mutex.h picks up the
vanilla implementation in 8-11 builds. Is this a mere slip?
--
Your fault - core dumped.
I am attaching a tentative patch for review, in relation with STDCXX-541
(https://issues.apache.org/jira/browse/STDCXX-541). Testing showed it
solves the test case failure and adds no extra failures in the stdcxx
strings test suite. This solves quite a few of related failures in
strings in down
: ../gcc-4.2.0/configure --prefix=/opt/compilers/gcc-4.2.0
--enable-threads --enable-shared --enable-languages=c,c++
Thread model: posix
gcc version 4.2.0
Reporter: Liviu Nicoara
The following program asserts:
$ cat t.cpp
#include
#include
int
main ()
{
assert (std
Martin Sebor wrote:
Liviu Nicoara wrote:
Martin Sebor wrote:
Which list? Is there any project that you liked in particular?
http://directory.apache.org the most.
FWIW, I like the Web interface to the Standard C++ Library
documentation for IBM XLC/C++ 9.0, especially the expandable
Martin Sebor wrote:
Hey everyone,
Marc Betz has been working on the improvements to the stdcxx
documentation outlined in STDCXX-391. Most of them are pretty
straightforward and can, IMO, be implemented without much
debate (although feedback is always appreciated :) but there
is one that I think
+1.
Martin Sebor wrote:
Our mentors as well as a number of IPMC members recently expressed
confidence in stdcxx being ready to graduate out of the incubator
(see the thread starting with msg14476 below).
In order to propose graduation to the Incubator PMC we all need to
formally agree that we a
On May 29, 2007, at 3:58 PM, Martin Sebor wrote:
Liviu Nicoara wrote:
Liviu Nicoara wrote:
Liviu Nicoara wrote:
On May 21, 2007, at 7:17 PM, Martin Sebor wrote:
There is a problem in locale (as usual, sigh :( A couple of our
thread safety tests have been crashing: 22_mt and 22_time_put_mt
Liviu Nicoara wrote:
Liviu Nicoara wrote:
On May 21, 2007, at 7:17 PM, Martin Sebor wrote:
Liviu Nicoara wrote:
I agree it would be a spectacular demonstration of the usefulness of
the tool but -- based on my knowledge of the stdcxx code -- I
strongly doubt I can demonstrate an MT bug in it
Liviu Nicoara wrote:
On May 21, 2007, at 7:17 PM, Martin Sebor wrote:
Liviu Nicoara wrote:
I agree it would be a spectacular demonstration of the usefulness of
the tool but -- based on my knowledge of the stdcxx code -- I
strongly doubt I can demonstrate an MT bug in it. Do you know of an
Sorry for the delay. Here's my vote:
On May 21, 2007, at 5:17 PM, Martin Sebor wrote:
I think the discussion has wound down so let's have a vote and
decide whether stdcxx committers should follow the Commit-Then
Review (CTR) or Review-Then-Commit (RTC) policy on stdcxx/trunk
by default.
[x] A
On May 21, 2007, at 7:17 PM, Martin Sebor wrote:
Liviu Nicoara wrote:
I agree it would be a spectacular demonstration of the usefulness
of the tool but -- based on my knowledge of the stdcxx code -- I
strongly doubt I can demonstrate an MT bug in it. Do you know of
an unresolved MT bug in
On May 20, 2007, at 11:57 PM, Martin Sebor wrote:
Eric Lemings wrote:
Questions for STDCXX users and maintainers regarding Intel Thread
Checker (ITC):
1. Would STDCXX benefit from ITC support?
I don't know :) Does it reveal any problems in our code? Is it worth
the effort? From what I've he
Martin Sebor wrote:
William A. Rowe, Jr. wrote:
[...]
So I would like to propose that we all follow a relaxed form of
the Review-Then-Commit policy, where "simple" or "obviously safe"
changes be allowed to go in under the Commit-Then-Review process.
I don't think it's necessary to precisely defi
Eric Lemings wrote:
Questions for STDCXX users and maintainers regarding Intel Thread
Checker (ITC):
1. Would STDCXX benefit from ITC support?
2. Should ITC support be added to STDCXX?
For more info,
http://www3.intel.com/cd/software/products/asmo-na/eng/threading/219785.
htm
Allow m
Eric Lemings wrote:
Questions for STDCXX users and maintainers regarding Intel Thread
Checker (ITC):
1. Would STDCXX benefit from ITC support?
Stdcxx uses its own synchronization mechanisms, outside the POSIX
threads API. Thus, it is possible that an executable linked with stdcxx
and inst
[
https://issues.apache.org/jira/browse/STDCXX-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496380
]
Liviu Nicoara commented on STDCXX-402:
--
Pretty sure. The key in reproducing it seems to be non-zero bytes
[
https://issues.apache.org/jira/browse/STDCXX-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496339
]
Liviu Nicoara commented on STDCXX-402:
--
AFAICT, the for loop at line 936 in strtoul.cpp starts by skipping the
[
https://issues.apache.org/jira/browse/STDCXX-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496315
]
Liviu Nicoara commented on STDCXX-402:
--
I guess this one is going to become a priority of sorts. A quick look
Martin Sebor wrote:
Our recent status report raised a question from one of the reviewers
about our commit policy, specifically about the following comment on
it on our project page:
Except where noted, all stdcxx committers follow the Review Then
Commit policy.
[...]
So I would like to propo
library.
Reporter: Liviu Nicoara
The following test case:
$ cat t.cpp
#include
#include
#include
int
main ()
{
long long n = 0;
{
std::stringstream s (std::string ("214748364"));
s >> n;
std::cout << n << "\n";
FWIW, option 3 makes more sense to me.
It could be enhanced though in the light of Martin's reply to Mark: some
tests do not cleanly apply to a section. In which case option 3 can be
enhanced to place such tests in the regress dir w/o a section number.
Liviu
Andrew Black wrote:
If we constra
Here it is. I have grouped the options which required change together. I
could not test the change with 8.1 and 9.0 compilers but I will do that
as soon as our sysadmins resolve my account issues.
On a side note: I could not detect any changes brought in by the -Xc
option which I believe to be
Liviu Nicoara wrote:
Martin Sebor wrote:
Liviu Nicoara wrote:
The diff conditional got truncated in the copy & paste:
[...]
So does this mean Intel renamed crtxn.o to crtend.o between
9.0 and 9.1?
Intel tells me (in issue 355260) they have an undocumented
compiler option -cxxlib-nostd
Martin Sebor wrote:
Liviu Nicoara wrote:
The diff conditional got truncated in the copy & paste:
[...]
So does this mean Intel renamed crtxn.o to crtend.o between
9.0 and 9.1?
Intel tells me (in issue 355260) they have an undocumented
compiler option -cxxlib-nostd that will apparently le
The diff conditional got truncated in the copy & paste:
Liviu Nicoara wrote:
[...]
+ifeq ($(shell [ $(CXX_MAJOR) -ge 9 -o $(CXX_MAJOR) -eq 9 -a $(CXX_MINOR) -ge 1 ]
Here it is again:
2007-02-15 lnicoara <[EMAIL PROTECTED]>
* etc/config/icc.config
Added cond
2007-02-15 lnicoara <[EMAIL PROTECTED]>
* etc/config/icc.config:
Added conditional to handle name differences
for crt object between Intel C++ 9.0 and 9.1.
Liviu
Index: etc/config/icc.config
===
--- et
Hi Farid,
That is part of an optimization (which gives constant complexity) which
I left as it is now at Martin's indication.
Liviu
Farid Zaripov wrote:
If the _RWSTD_NO_LIST_NODE_BUFFER macro is not defined, then
list::splice() method do not conform the stadnard requirements (linear
compl
Hi Koh,
The header files you listed are coming from the Essential Tools library,
OEM'd to a number of vendors. The Essential Tools library is not open
source at the time.
We do have ports of our libraries, Essential Tools included, for RHAS
and our sales people would be very interested to he
Martin Sebor wrote:
> Farid Zaripov wrote:
>> I can't understand what does the line "test -z "`echo $it | grep .cm`"
>> ;" in function below?
>>
>> check_locale_m()
>
> My guess is that whoever wrote it (cough, Liviu, cough) meant
> a literal period [...]
I can only assume that in some incarnat
The problem - as I saw it in the locale_name_fmat comp test Jeremy was
running - seems to be a buffer overrun in LOCALE_NAME_FMAT.cpp at line
189 (trunk) because the 'def_locale' buffer may not have enough space to
hold the name of a locale, e.g. the one Jeremy got:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC
Hi,
The following test case fails with the latest dev stdcxx (*):
tmp$ cat t.cpp
#include
#include
#include
int main ()
{
std::strstreambuf sb;
std::ostream os (&sb);
os << " ";
std::streampos pos =
sb.pubseekoff (0, std::ios::end, std::ios::out);
assert (pos =
AFAIK, dynatype is not expected to be compiled by all compilers because
of the tricky template code it contains.
Liviu
Craig Chariton wrote:
>
>
> While rebuilding the solution on Windows XP Pro with MSVC 7.1, I
> received
> the following errors on dynatype.cpp:
>
>
>
> -- Rebuild All
--enable-languages=c,c++ --enable-shared --enable-__cxa_atexit
Thread model: posix
gcc version 4.0.2
and it still doesn't fail for me.
Liviu
Liviu Nicoara wrote:
> Anton,
>
> I am going to try it on one of our SUSE 9 boxes and I will let you know
> how it goes for me.
>
> Tha
Thanks,
> Anton Pevtsov
>
>
> -Original Message-
> From: Liviu Nicoara [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 03, 2006 19:53
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: basic_string::insert (iterator p, InputIterator first,
> InputIterator last) on Linux,
d got bcabcdef
Gcc was built by myself on a Slackware 10.1 box from GNU sources (not RH
or anything).
Please let me know if I am missing anything.
- Liviu
Liviu Nicoara wrote:
> Hi Anton,
>
> What kind of a build was this? Is the testing infrastructure needed to
> exhibit the pr
Hi Anton,
What kind of a build was this? Is the testing infrastructure needed to
exhibit the problem or you just used it for convenience in printing the
results?
- Liviu
Anton Pevtsov wrote:
> The basic_string::insert (iterator p, InputIterator first, InputIterator
> last) doesn't work correctly
Yep, with SunPro it is getting a shorter one but it shows too t_cancel
and thr_exit_common (in 4.1.4 though).
Martin Sebor wrote:
> Liviu Nicoara wrote:
>> I got it. I will test against dev and file a bug report only if that
>> fails too.
>
> It does with gcc but I haven
I got it. I will test against dev and file a bug report only if that
fails too.
Thanks,
Liviu
Martin Sebor wrote:
> Liviu Nicoara wrote:
>> Liviu Nicoara wrote:
>>
>>> The following test case fails intermittently with SIGSEGV:
>>> ...
>>> I
Liviu Nicoara wrote:
> The following test case fails intermittently with SIGSEGV:
> ...
> I will file a JIRA incident soon.
Will 4.1.4 be revisited and the bug addressed if dev does not show the
problem? What is the policy in this case?
Thanks,
Liviu
The following test case fails intermittently with SIGSEGV:
$ uname -a
SunOS doc 5.10 Generic_118822-19 sun4u sparc SUNW,Ultra-Enterprise
$ gcc --version
gcc (GCC) 3.4.4
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO war
Martin Sebor wrote:
>> Liviu Nicoara wrote:
>> A cursory look at toplevel GNUMakefile shows that CXXOPTS, CPPOPTS and
>> LDOPTS values are not saved in makefile.in. The easiest fix would be to
>> append their values to the corresponding ~FLAGS variables. I have not
>>
Martin Sebor wrote:
> Liviu Nicoara wrote:
>> Martin Sebor wrote:
> Did you quote the whole thing:
>
> gmake CXXOPTS="-F " LDOPTS="-F " ...
A cursory look at toplevel GNUMakefile shows that CXXOPTS, CPPOPTS and
LDOPTS values are not saved in makefile.
Martin Sebor wrote:
> Liviu Nicoara wrote:
>> Martin Sebor wrote:
>>
>>> Liviu Nicoara wrote:
>>>
>> The options are discarded and the build fails with the compiler looking
>> for the config file in /etc/... . I would like to have the ability to
&g
Martin Sebor wrote:
> Liviu Nicoara wrote:
>> I tried to make a build with VACPP 8.0 on a SUSE box. The setting of "-F
>> " (compiler config location) via compiler/linker options as
>> explained in the README:
>>
>> "To change prepr
I tried to make a build with VACPP 8.0 on a SUSE box. The setting of "-F
" (compiler config location) via compiler/linker options as
explained in the README:
"To change preprocessor, compiler, or linker options you can
either set the make variables CPPOPTS, CXXOPTS, and LDOPTS on th
Two tests in this post which are the result of restructuring previous tests:
- 23.vector.modifiers.cpp:
- test insert and erase complexity (part of former vector.cpp)
- test insert, insert range and insert "at-end" (whole former
vector_modifiers.cpp)
- test push_back (whole former vector
What Martin means by configuring the library is the first leg of
"make"-ing the library, where the GNU makefiles direct the execution of
the config tests and the creation the config.h header. You could see
for yourself how this goes by building the library on a UNIX w/o RCB
(i.e. using GNU makefil
That is the config header generated by the configuration process which
contains all the configuration macros defined prior to executing the
current config test.
Liviu
Nicole Willson wrote:
> The "config.h" file included in the COLLAPSE_STATIC_LOCALS.cpp comes from
> the compiler, correct?
>
> Ni
I meant using a custom separator (instead of space) in the list of
functions you test in libc_decl.sh.
Liviu
Martin Sebor wrote:
>> Liviu Nicoara wrote:
>> Perhaps a custom separator would be more beneficial in the long run?
>
> I'm not sure what you mean?
>
>>&g
Perhaps a custom separator would be more beneficial in the long run?
Liviu
Martin Sebor wrote:
> Liviu Nicoara wrote:
>
>>It seems I rushed to a wrong conclusion - I haven't noticed the
>>definitions for _RWSTD_INSTANTIATE_type's macros. Scratch the diff since
>
Could it be that the _RWSTD_INSTANTIATE_type macros are defined to 1
when instantiation is needed but not to 0 otherwise?
Liviu
Liviu Nicoara wrote:
> It seems I rushed to a wrong conclusion - I haven't noticed the
> definitions for _RWSTD_INSTANTIATE_type's macros. Scratch the
luded from /build/nicoara/stdcxx/include/ios:29,
from /build/nicoara/stdcxx/src/strstream.cpp:38:
/build/nicoara/stdcxx/include/rw/_basic_ios.h:339:42: operator '!' has
no right operand
/build/nicoara/stdcxx/include/rw/_basic_ios.h:346:45: operator '!' has
no right o
Revision 380238 seems to be broken at least on Linux. I believe the
intention in rw/_defs.h conditionals was to test for the definition of
the macros in the diff below since stdcxx does not define config macros
to values (0/1) as a matter of policy.
I changed all instances where the conditional te
I have converted the former vector.cpp to 23.vector.cons.cpp. I kept in
it the types and signatures tests along with the actual ctors tests.
Liviu
/***
*
* 23.vector.cons.cpp - test exercising [lib.vector.cons]
*
* $Id$
*
Martin,
I think there are more places sprtoing the extra newlines than the ones
you have in your diff. Aren't rw_info formatting strings supposed to not
have trailing newlines too?
Liviu
Martin Sebor wrote:
> Liviu Nicoara wrote:
>
>>I am sorry, I spaced on it. I am going to t
conclusions.
Liviu
Martin Sebor wrote:
> Liviu Nicoara wrote:
>
>>Has anyone tried to build on it?
>
>
> Doesn't seem like it. How is it different from Darwin that would
> affect us (i.e., compiler or the XCode environment, etc.)?
>
> Martin
>
Martin Sebor wrote:
> Liviu Nicoara wrote:
>>If you use implicit inclusion you need to collect the template
>>instantiations via the prelink step (-qmkshrobj).
> That's what we do on AIX, but it gives errors in Linux archive builds.
> I have a feeling that it's no
Martin,
If you use implicit inclusion you need to collect the template
instantiations via the prelink step (-qmkshrobj). I see in that in your
later post, config.h has RWSTD_NO_IMPLICIT_INCLUSION is defined but down
here you build your example with -qtemopinc.
Liviu
Martin Sebor wrote:
> Martin
Martin Sebor wrote:
> Nicole Willson wrote:
The equivalent (modulo anonymous struct) passes as well:
struct foo {
int flag;
};
static foo f = { 1 };
int flags = f.flag;
Liviu
>
>
> Moving this struct out of the function (i.e., to namespace scope)
> fixes it in this t
What's the compile line?
Nicole Willson wrote:
> NO! It's MY test case. :) I actually streamlined it a little more. Ok, here
> it is:
>
> //Test case for ICE on SuSE 9sp2 with xlC 8.0
> #include
>
> template class codecvt_byname
> {
> public:
> explicit codecvt_byname (){}
> };
>
> templ
I am sorry, I spaced on it. I am going to tend to it as soon as I can.
Liviu
Martin Sebor wrote:
> Martin Sebor wrote:
>
>>Liviu Nicoara wrote:
>>
>>
>>>I have attached my attempt at converting new.cpp "self" test to the new
>>>driver.
>
Has anyone tried to build on it?
Thanks,
Liviu
--disable-checking --with-gnu-ld
--verbose --target=i486-slackware-linux --host=i486-slackware-linux
Thread model: posix
gcc version 3.3.4
Reporter: Liviu Nicoara
Priority: Trivial
The following test case:
$ cat > t.cpp << EOF
include
int main ()
{
rw_assert
--enable-__cxa_atexit --disable-checking --with-gnu-ld
--verbose --target=i486-slackware-linux --host=i486-slackware-linux
Thread model: posix
gcc version 3.3.4
Reporter: Liviu Nicoara
Priority: Minor
(Need monospace font to see properly)
The following test case:
$ cat > t.cpp <
-__cxa_atexit --disable-checking --with-gnu-ld
--verbose --target=i486-slackware-linux --host=i486-slackware-linux
Thread model: posix
gcc version 3.3.4
Reporter: Liviu Nicoara
Priority: Minor
(Need monospace font to see properly)
The following test case:
$ cat > t.cpp << EOF
I have attached the converted test in subject line.
The explanatory pieces of text accompanying the assertions are in
certain [few] cases kind of silly.
Liviu
/***
*
* 23.deque.iterators.cpp - test exercising lib.deque.iter
Sure thing.
Martin Sebor wrote:
> Liviu Nicoara wrote:
>
>>The following test case:
>>
>>$ cat > t.cpp << EOF
>>
>>#include
>>
>>int run_test (int, char**)
>>{
>>for (int i = 0; i < 100; ++i)
>>rw_a
The following test case:
$ cat > t.cpp << EOF
#include
int run_test (int, char**)
{
for (int i = 0; i < 100; ++i)
rw_assert (1, 0, 0, " ");
return 0;
}
int main ()
{
return rw_test (0, 0, __FILE__, "", 0, run_test, 0);
}
EOF
yields the following output:
$ ./t
# INFO
The following test case:
$ cat > t.cpp << EOF
#include
int run_test (int, char**)
{
rw_assert (0, 0, 0, "");
return 0;
}
int main ()
{
return rw_test (0, 0, __FILE__, "", 0, run_test, 0);
}
EOF
yields:
$ ./t
# INFO (S1) (8 lines):
# TEXT:
# COMPILER: gcc 3.3.4, __VERSION__ = "3.
The following test case:
$ cat > t.cpp << EOF
include
int main ()
{
rw_assert (0, 0, 0, "");
return 0;
}
EOF
yields the following error message:
$ ./t
/build/nicoara/stdcxx/tests/src/driver.cpp:1164: rw_assert(): test
driver already initialized
Aborted
The message does not seem to
Martin,
I am currently attempting to convert deque.iterators to the new driver.
The test, in the current form uses plain asserts. I can only speculate
that a large number of assertions being exercised and the inefficiency
of the former driver's assertion mechanism was the reason for that. Is
that
-threads --enable-languages=c,c++
Thread model: posix
gcc version 4.0.2
Reporter: Liviu Nicoara
Copy and paste at prompt:
$ cat t.xpp
#include
#include
struct A { char tmp [32]; };
int main ()
{
A a [32];
std::deque lhs (a, a + 0);
std::deque rhs (a, a + 1);
lhs.swap (rhs
Martin Sebor wrote:
> Liviu Nicoara wrote:
>>Take two with corrections to add z modifier to size_t arguments.
>
> I'm afraid that's still slightly incorrect and, in fact, has undefined
> semantics according to 7.19.6.1, p9 of C99. size_t is an unsigned type,
> a
Take two with corrections to add z modifier to size_t arguments.
Liviu Nicoara wrote:
> I have attached a second version of the test. Please let me know if this
> addresses the points you raised.
>
> Thanks,
> Liviu
>
> Liviu Nicoara wrote:
>
>>Martin Sebor wrote
I have attached a second version of the test. Please let me know if this
addresses the points you raised.
Thanks,
Liviu
Liviu Nicoara wrote:
> Martin Sebor wrote:
>
>>Liviu Nicoara wrote:
>>
>>
>>>I have attached my tentative porting of lib.deque.modifiers tes
I have attached my attempt at converting new.cpp "self" test to the new
driver.
Liviu
/***
*
* 0.new.cpp - test exercising replacement operator new and delete
*
* $Id$
*
**
Martin Sebor wrote:
> Liviu Nicoara wrote:
>
>>I have attached my tentative porting of lib.deque.modifiers test to the
>>new driver. Martin, I would appreciate suggestions for improving the
>>sections which use ToString class (one of those uses split formatting).
>
I am working on it. Sorry for not answering promptly, it won't happen again.
Liviu
Martin Sebor wrote:
> Liviu -- please let me know either way; if you don't have it I'll port
> it myself.
>
> Thanks
> Martin
>
>
> Martin Sebor wrote:
>
>>Livi
+1
Tested on RH AS 4 Itanium, EM64T, and SUSE (x86) (all with gcc).
Martin Sebor wrote:
> Justin Erenkrantz wrote:
> [...]
>
>>>Since several of them are involved and would require us to recertify
>>>the library on all the platforms where it has passed my goal is to get
>>>them fixed in 4.1.4. D
I have attached my tentative porting of lib.deque.modifiers test to the
new driver. Martin, I would appreciate suggestions for improving the
sections which use ToString class (one of those uses split formatting).
Thanks,
Liviu
/
Attached is my attempt at converting the lib.string.cons test. It
contains the additional new_test.h/new.cpp and
string_test.h/string_test.cpp for support.
Liviu
21.string.cons.tgz
Description: application/compressed-tar
Do you mind if I take route #1?
Martin Sebor wrote:
> Liviu Nicoara wrote:
>
>>Martin,
>>
>>There are quite a few tests affected by the name changes in the
>>replacement op new/delete in driver:
>
>
> We need to minimize breakage in the Rogue Wave test s
Martin,
There are quite a few tests affected by the name changes in the
replacement op new/delete in driver:
/build/nicoara/hal/tests/stdlib/containers/deque_modifiers.cpp
/build/nicoara/hal/tests/stdlib/containers/leak.cpp
/build/nicoara/hal/tests/stdlib/containers/vector.cpp
/build/nicoara/hal/
Martin,
AFAICT, rw_sprintf is not yet implemented in the driver. Any plans to
implement it in the near future?
Liviu
Martin,
I am working on the strings.cons test now and I am fiddling with the
replacement op new/delete support in the driver.
So, the naming convention calls for _rw_ for all functions in the driver
(including those with internal linkage) and rw_ for all types defined in
the driver?
Thanks,
Livi
/Output
Versions: 4.1.2
Environment: $ icl -help 2>&1 | head -n 3
Intel(R) C++ Compiler for 32-bit applications, Version 8.1Build 20050201Z
Package ID: w_cc_pc_8.1.025
Copyright (C) 1985-2005 Intel Corporation. All rights reserved.
Windows 2000 Professional SP2
Reporter
I attached a tar.gz archive containing the test mentioned in the subject
line (modified to use the new driver). The test comes from former
c_strings.cpp test.
Liviu
string.tgz
Description: application/compressed-tar
I attached a tar.gz archive containing the two tests mentioned in the
subject line. The tests come from splitting the former append.cpp test
and exercise lib.string.+= and lib.string.append.
Liviu
string.tgz
Description: application/compressed-tar
/A
Reporter: Liviu Nicoara
Priority: Minor
Complete the test for rw_printf family of print functions to include tests for
all format specifiers, modifiers, etc.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators
Martin,
As we discussed it yesterday the gcc builds are broken on dev because of
a glitch introduced in [I believe] revision 366948.
AFAICT the else branch of the new SunOS conditional in rw/_mbstate.h
does not preserve the former logic.
The following is a tentative patch; could you please tak
+1
Martin Sebor wrote:
> I created a tarball of the stdcxx 4.1.3 branch (minus the docs/
> subdirectory):
> http://svn.apache.org/repos/asf/incubator/stdcxx/branches/4.1.3/
>
> and placed in my home directory:
> http://people.apache.org/~sebor/stdcxx/stdcxx-incubating-4.1.3.tar.gz
>
> The MD5 su
A minor issue: -Wextra in gcc.config added for CXX_MAJOR != 2 breaks gcc
builds. AFAICT, it's a valid option starting with 3.4.x.
Liviu
2006-01-09 Liviu Nicoara <[EMAIL PROTECTED]>
* etc/config/gcc.config: altered conditional
to add -Wextra for gcc > 3.4
Ind
warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Liviu
Liviu Nicoara wrote:
> Martin,
>
> I believe this is the patch we want. After we talked I realized that the
> order-only dependency actually is in effect and what we were seeing it
> was the correc
its age).
Addressing:
http://issues.apache.org/jira/browse/STDCXX-85
ChangeLog entry:
2005-12-30 Liviu Nicoara <[EMAIL PROTECTED]>
* GNUMakefile: removed useless rules: all, builddir, added
rule lib, added variable INCDIR
* etc/config/makefile.rules: added orde
1 - 100 of 116 matches
Mail list logo
