[jira] Commented: (STDCXX-231) std::getline from header is rather slow
[
https://issues.apache.org/jira/browse/STDCXX-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537089
]
Mark Brown commented on STDCXX-231:
---
I just benchmarked getline() from stdcxx 4.1.3 against the same function in gcc
4.1 (the program is below), and out of curiosity against the wc utility on
Linux. stdcxx is more than twice slower than gcc, and nearly ten times slower
than wc.The timings for a 32MB text file are:
$ ls -l input.txt && time LD_LIBRARY_PATH=../lib ./getline 1 input.txt && time
./a.out 1 input.txt && time wc -l input.txt && cat getline.cpp
-rw-rw-r-- 1 mbrown mbrown 32942720 Oct 23 11:30 input.txt
892370
real0m0.433s
user0m0.400s
sys 0m0.036s
892370
real0m0.149s
user0m0.124s
sys 0m0.024s
892370 input.txt
real0m0.053s
user0m0.048s
sys 0m0.004s
#include
#include
#include
#include
int main (int argc, char *argv[])
{
unsigned long loops;
const char* file;
loops = 1 < argc ? strtoul (argv [1], 0, 0) : 1;
file = 2 < argc ? argv [2] : __FILE__;
unsigned long line_count = 0;
std::string line;
for (unsigned long i = 0; i != loops; ++i) {
std::ifstream in (file);
if (!in.is_open ())
return 1;
while (std::getline (in, line))
++line_count;
}
printf ("%lu\n", line_count);
}
> std::getline from header is rather slow
>
>
> Key: STDCXX-231
> URL: https://issues.apache.org/jira/browse/STDCXX-231
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: 21. Strings
>Reporter: Martin Sebor
>
> Moved from the Rogue Wave bug tracking database:
> Created By: leroy @ Jan 25, 2001 03:20:01 PM
> Environment
> Compiler : SUNPRO 4.2
> OS : Solaris 2.5.1
> SCL : 1.3.0 (Summer-1999)
> Tools : 7.1.0 (Summer-1999) --> Use only for RWBench
> Command line option :
> for debug :
> CC -xildoff +w +p -g -o Test_dbg.exe test.cc -DRWDEBUG=1
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/11s
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/11s/include -I.
> -L/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/11s/lib -Bstatic
> -ltls11s -lstd11s -Bdynamic
> for release :
> CC -xildoff +w +p -fast -o Test_release.exe test.cc
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/8s
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/8s/include -I.
> -L/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/8s/lib -Bstatic
> -ltls8s -lstd8s -Bdynamic
> (Uploaded file: 997149-test.cc)
>
>
>
>
>
> Entered By: Web @ Thursday, January 25, 2001 2:41:42 AM
> Location of uploaded file:
> http://thoth.bco.roguewave.com/uploads/997149-test.cc
> View all uploaded files for this incident:
> http://webdev.roguewave.com/admin/tsvw/index.cfm?IncidentID=997149
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Entered By: Web @ Thursday, January 25, 2001 2:44:56 AM
> #web
> Please find my test case at the end of the note
> Environment
> Compiler : SUNPRO 4.2
> OS : Solaris 2.5.1
> SCL : 1.3.0 (Summer-1999)
> Tools : 7.1.0 (Summer-1999) --> Use only for RWBench
> Command line option :
> for debug :
> CC -xildoff +w +p -g -o Test_dbg.exe test.cc -DRWDEBUG=1
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/11s
> -I/opt/Rog
[jira] Created: (STDCXX-544) use gcc __builtin functions
use gcc __builtin functions --- Key: STDCXX-544 URL: https://issues.apache.org/jira/browse/STDCXX-544 Project: C++ Standard Library Issue Type: Improvement Components: Build Affects Versions: 4.1.3 Environment: gcc Reporter: Mark Brown Gcc provides many built-in equivalents of C library functions like memcpy or strlen for optimization purposes. stdcxx should take advantage of them when possible to deliver better performance. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-518) std::string copy constructor slow
[
https://issues.apache.org/jira/browse/STDCXX-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519279
]
Mark Brown commented on STDCXX-518:
---
I thought timings for multipled threads might be of interest. Unfortunately, I
have only 2 CPUs to test on.
$ time ./string-copy.gcc 1
real0m9.739s
user0m19.257s
sys 0m0.060s
$ time ./string-copy.stlport 1
real0m20.906s
user0m40.211s
sys 0m0.056s
$ time LD_LIBRARY_PATH=../lib ./string-copy 1
real0m17.585s
user0m34.698s
sys 0m0.076s
#include
#include
#include
#include
std::string strings [256];
const std::size_t num_strings = sizeof strings / sizeof *strings;
unsigned long n;
extern "C" void* test_copy_ctor (void*)
{
for (unsigned long i = 0; i != n; ++i) {
const std::size_t index = i % num_strings;
const std::string copy (strings [index]);
assert (copy.length () == index);
}
return 0;
}
int main (int argc, char *argv[])
{
n = argc < 2 ? 0 : std::strtoul (argv [1], 0, 10);
for (unsigned long i = 0; i != num_strings; ++i)
strings [i].assign (i, 'x');
pthread_t thread [2];
const std::size_t num_threads = sizeof thread / sizeof *thread;
for (std::size_t i = 0; i < num_threads; ++i)
pthread_create (thread + i, 0, test_copy_ctor, 0);
for (std::size_t i = 0; i < num_threads; ++i)
pthread_join (thread [i], 0);
}
> std::string copy constructor slow
> -
>
> Key: STDCXX-518
> URL: https://issues.apache.org/jira/browse/STDCXX-518
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: 21. Strings
>Affects Versions: 4.1.3
> Environment: gcc 4.1.2, x86_64
>Reporter: Mark Brown
>
> When thread safety is enabled in stdcxx the string copy constructor is more
> than ten times slower than when it's not, and twice as slow as the same copy
> constructor in gcc 4.1.2 on Linux (x86_64), but slightly faster than with
> STLport 5.1.3. The timings were done on Intel x86_64 at 2.4GHz:
> BUILDMODE=shared,optimized:
> $ time LD_LIBRARY_PATH=../lib ./string-copy 1
> real0m0.482s
> user0m0.480s
> sys 0m0.000s
> BUILDMODE=shared,optimized,pthread:
> $ time LD_LIBRARY_PATH=../lib ./string-copy 1
> real0m10.157s
> user0m10.041s
> sys 0m0.032s
> gcc 4.1.2 with -O2 -m64:
> $ time ./string-copy.gcc 1
> real0m4.280s
> user0m4.260s
> sys 0m0.020s
> gcc 4.1.2 with STLport 5.1.3 (-D_REENTRANT -O2 -m64 -lpthread):
> $ time ./string-copy.stlport 1
> real0m12.479s
> user0m12.473s
> sys 0m0.004s
> #include
> #include
> #include
> int main (int argc, char *argv[])
> {
> const unsigned long n = argc < 2 ? 0 : std::strtoul (argv [1], 0, 10);
> std::string strings [256];
> const std::size_t num_strings = sizeof strings / sizeof *strings;
> for (unsigned long i = 0; i != num_strings; ++i)
> strings [i].assign (i, 'x');
> for (unsigned long i = 0; i < n; ++i) {
> const std::size_t length = i % num_strings;
> const std::string str (strings [length]);
> assert (str.size () == length);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-518) std::string copy constructor slow
std::string copy constructor slow
-
Key: STDCXX-518
URL: https://issues.apache.org/jira/browse/STDCXX-518
Project: C++ Standard Library
Issue Type: Improvement
Components: 21. Strings
Affects Versions: 4.1.3
Environment: gcc 4.1.2, x86_64
Reporter: Mark Brown
When thread safety is enabled in stdcxx the string copy constructor is more
than ten times slower than when it's not, and twice as slow as the same copy
constructor in gcc 4.1.2 on Linux (x86_64), but slightly faster than with
STLport 5.1.3. The timings were done on Intel x86_64 at 2.4GHz:
BUILDMODE=shared,optimized:
$ time LD_LIBRARY_PATH=../lib ./string-copy 1
real0m0.482s
user0m0.480s
sys 0m0.000s
BUILDMODE=shared,optimized,pthread:
$ time LD_LIBRARY_PATH=../lib ./string-copy 1
real0m10.157s
user0m10.041s
sys 0m0.032s
gcc 4.1.2 with -O2 -m64:
$ time ./string-copy.gcc 1
real0m4.280s
user0m4.260s
sys 0m0.020s
gcc 4.1.2 with STLport 5.1.3 (-D_REENTRANT -O2 -m64 -lpthread):
$ time ./string-copy.stlport 1
real0m12.479s
user0m12.473s
sys 0m0.004s
#include
#include
#include
int main (int argc, char *argv[])
{
const unsigned long n = argc < 2 ? 0 : std::strtoul (argv [1], 0, 10);
std::string strings [256];
const std::size_t num_strings = sizeof strings / sizeof *strings;
for (unsigned long i = 0; i != num_strings; ++i)
strings [i].assign (i, 'x');
for (unsigned long i = 0; i < n; ++i) {
const std::size_t length = i % num_strings;
const std::string str (strings [length]);
assert (str.size () == length);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-493) std::string::append() slow
std::string::append() slow
--
Key: STDCXX-493
URL: https://issues.apache.org/jira/browse/STDCXX-493
Project: C++ Standard Library
Issue Type: Bug
Components: 21. Strings
Affects Versions: 4.1.3
Environment: gcc 4.1.2 on Linux/x86_64
Reporter: Mark Brown
This is a similar problem to STDCXX-492: all overloads of string::append() are
slower than the same overloads in gcc:
$ let n=0; while [ $n -lt 3 ]; do time LD_LIBRARY_PATH=../lib
./append-stdcxx-4.1.3 5 $n; let n=`expr $n + 1`; done
real0m11.221s
user0m9.941s
sys 0m1.104s
real0m13.065s
user0m11.661s
sys 0m1.236s
real0m7.837s
user0m6.660s
sys 0m1.160s
$ let n=0; while [ $n -lt 3 ]; do time ./append-gcc-4.1.2 5 $n; let
n=`expr $n + 1`; done
real0m4.865s
user0m4.172s
sys 0m0.692s
real0m7.617s
user0m6.920s
sys 0m0.696s
real0m5.787s
user0m5.068s
sys 0m0.720s
The program I used to do the comaprison is below:
#include
#include
#include
int main (int argc, char *argv[])
{
const int N = argc < 2 ? 1 : std::atoi (argv [1]);
const int op = argc < 3 ? 0 : std::atoi (argv [2]);
std::string str;
const std::string x ("X");
if (op == 0) {
for (int i = 0; i < N; ++i)
str.append (1, 'x');
} else if (op == 1) {
for (int i = 0; i < N; ++i)
str.append ("x");
} else {
for (int i = 0; i < N; ++i)
str.append (x);
}
assert (str.size () == std::size_t (N));
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-492) std::string::operator+=() slow
std::string::operator+=() slow
--
Key: STDCXX-492
URL: https://issues.apache.org/jira/browse/STDCXX-492
Project: C++ Standard Library
Issue Type: Bug
Components: 21. Strings
Affects Versions: 4.1.3
Environment: gcc 4.1.2 on Linux/x86_64
Reporter: Mark Brown
Comparing overloads of string::operator+=() in stdcxx with the same functions
in gcc 4.1.2, stdcxx is up to twice slower than gcc:
$ time ./op_plus_equal-stdcxx 1 0
real0m2.241s
user0m1.932s
sys 0m0.204s
$ time ./op_plus_equal-stdcxx 1 1
real0m2.540s
user0m2.344s
sys 0m0.196s
$ time ./op_plus_equal-stdcxx 1 2
real0m1.492s
user0m1.308s
sys 0m0.184s
$ time ./op_plus_equal-gcc 1 0
real0m0.883s
user0m0.728s
sys 0m0.156s
$ time ./op_plus_equal-gcc 1 1
real0m1.589s
user0m1.424s
sys 0m0.168s
$ time ./op_plus_equal-gcc 1 2
real0m1.131s
user0m0.976s
sys 0m0.156s
#include
#include
#include
int main (int argc, char *argv[])
{
const int N = argc < 2 ? 1 : std::atoi (argv [1]);
const int op = argc < 3 ? 0 : std::atoi (argv [2]);
std::string str;
const std::string x ("x");
if (op == 0) {
for (int i = 0; i < N; ++i)
str += 'x';
} else if (op == 1) {
for (int i = 0; i < N; ++i)
str += "x";
} else {
for (int i = 0; i < N; ++i)
str += x;
}
assert (str.size () == std::size_t (N));
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-491) string::push_back() slow
string::push_back() slow
Key: STDCXX-491
URL: https://issues.apache.org/jira/browse/STDCXX-491
Project: C++ Standard Library
Issue Type: Bug
Components: 21. Strings
Affects Versions: 4.1.3
Environment: gcc 4.1.2, Linux/x86_64
Reporter: Mark Brown
According to my timings string::push_back() in stdcxx 4.1.3 is more than twice
as slow than the same function in gcc 4.1.2 on Linux x86_64:
$ time ./push_back-stdcxx 1
real0m2.175s
user0m2.004s
sys 0m0.172s
$ time ./push_back-gcc 1
real0m0.924s
user0m0.760s
sys 0m0.164s
#include
#include
#include
int main (int argc, char *argv[])
{
const int N = argc < 2 ? 1 : std::atoi (argv [1]);
std::string str;
for (int i = 0; i < N; ++i)
str.push_back ('x');
assert (str.size () == std::size_t (N));
}
Comparing the generated assembly, the gcc push_back() is mostly inline but the
stdcxx push_back() is not:
stdcxx:
_Z8pushbackRSsc:
.LFB449:
movq(%rdi), %rax
movl%esi, %edx
movl$1, %ecx
movsbl %dl,%r8d
xorl%edx, %edx
movq-8(%rax), %rsi
jmp _ZNSs7replaceEmmmc
gcc:
_Z8pushbackRSsc:
.LFB904:
movq%rbp, -16(%rsp)
.LCFI0:
movq%r12, -8(%rsp)
.LCFI1:
movq%rdi, %rbp
movq%rbx, -24(%rsp)
.LCFI2:
subq$24, %rsp
.LCFI3:
movq(%rdi), %rax
movl%esi, %r12d
subq$24, %rax
movq(%rax), %rbx
addq$1, %rbx
cmpq8(%rax), %rbx
ja .L2
movl16(%rax), %eax
testl %eax, %eax
jg .L2
.L4:
movq(%rbp), %rdx
movq-24(%rdx), %rax
movb%r12b, (%rdx,%rax)
movq(%rbp), %rax
subq$24, %rax
movl$0, 16(%rax)
movq%rbx, (%rax)
movb$0, 24(%rax,%rbx)
movq(%rsp), %rbx
movq8(%rsp), %rbp
movq16(%rsp), %r12
addq$24, %rsp
ret
.p2align 4,,7
.L2:
movq%rbx, %rsi
movq%rbp, %rdi
call_ZNSs7reserveEm
jmp .L4
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-489) [Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect
[ https://issues.apache.org/jira/browse/STDCXX-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513707 ] Mark Brown commented on STDCXX-489: --- Hi Andrew, Can you suggest where to get the correct iccvars.sh script or how to change it? I only have one iccvars.sh in /opt/intel/cce/10.0.025/bin and I don't see any options that control which type of code the compiler generates. Is it possible that the compiler doesn't support 32-bit code on x86_64 and that I need to install another one? Thanks! --Mark > [Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect > - > > Key: STDCXX-489 > URL: https://issues.apache.org/jira/browse/STDCXX-489 > Project: C++ Standard Library > Issue Type: Bug > Components: Configuration >Affects Versions: 4.2 > Environment: Intel C++ 10 on Linux >Reporter: Mark Brown > > Configuring stdcxx for 32-bits using > BUILDMODE=pthreads,archive,optimized,narrow on x86_64 I see the system > architecture is "LP64 little endian" instead of "ILP32 little endian." It > looks like the "narrow" in BUILDMODE has no effect, kind of like "wide" had > no effect in bug STDCXX-470. > $ nice make BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s > BUILDMODE=pthreads,archive,optimized,narrow CONFIG=icc.config > creating BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s > generating /home/mbrown/stdcxx-icc-10.0-12s/makefile.in from > /home/mbrown/stdcxx/etc/config/icc.config > make[1]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s' > make[2]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include' > make config > make[3]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include' > configuring stdcxx 4.2.0 for icc-10.0 on linux-2.6.18-1.2798.fc6-x86_64 > checking if the compiler is sane ok (invoked with icc) > checking if the linker is sane ok (invoked with icc) > checking system architecture LP64 little endian -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-489) [Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect
[Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect - Key: STDCXX-489 URL: https://issues.apache.org/jira/browse/STDCXX-489 Project: C++ Standard Library Issue Type: Bug Components: Configuration Affects Versions: 4.2 Environment: Intel C++ 10 on Linux Reporter: Mark Brown Configuring stdcxx for 32-bits using BUILDMODE=pthreads,archive,optimized,narrow on x86_64 I see the system architecture is "LP64 little endian" instead of "ILP32 little endian." It looks like the "narrow" in BUILDMODE has no effect, kind of like "wide" had no effect in bug STDCXX-470. $ nice make BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s BUILDMODE=pthreads,archive,optimized,narrow CONFIG=icc.config creating BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s generating /home/mbrown/stdcxx-icc-10.0-12s/makefile.in from /home/mbrown/stdcxx/etc/config/icc.config make[1]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s' make[2]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include' make config make[3]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include' configuring stdcxx 4.2.0 for icc-10.0 on linux-2.6.18-1.2798.fc6-x86_64 checking if the compiler is sane ok (invoked with icc) checking if the linker is sane ok (invoked with icc) checking system architecture LP64 little endian -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-436) [Linux] MB_LEN_MAX incorrect
[Linux] MB_LEN_MAX incorrect
Key: STDCXX-436
URL: https://issues.apache.org/jira/browse/STDCXX-436
Project: C++ Standard Library
Issue Type: Bug
Components: 18. Language Support
Affects Versions: 4.2
Environment: gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
Reporter: Mark Brown
On my Linux system MB_LEN_MAX is normally defined to 16 but when I use the
macro in a program compiled with stdcxx the macro evaluates to 1. The test case
goes like this:
$ cat test.cpp && make CPPOPTS="-DGETCONF_MB_LEN_MAX=`getconf MB_LEN_MAX`" test
&& ./test
#include
#include
int main ()
{
assert (MB_LEN_MAX == GETCONF_MB_LEN_MAX);
}
gcc -c -I/home/mbrown/stdcxx/include/ansi -D_RWSTDDEBUG
-I/home/mbrown/stdcxx/include -I/home/mbrown/stdcxx-gcc-4.1.1-11s/include
-I/home/mbrown/stdcxx/examples/include -DGETCONF_MB_LEN_MAX=16 -pedantic
-nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings
-Wno-long-long -Wcast-align test.cpp
gcc u.o -o u -L/home/mbrown/stdcxx-gcc-4.1.1-11s/lib -lstd11s -lsupc++ -lm
test: test.cpp:6: int main(): Assertion `1 == 16' failed.
Aborted
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-435) [Linux] std::codecvt_byname("*.UTF-8").in() to_next greater than expected
[Linux] std::codecvt_byname("*.UTF-8").in() to_next greater than expected
-
Key: STDCXX-435
URL: https://issues.apache.org/jira/browse/STDCXX-435
Project: C++ Standard Library
Issue Type: Bug
Components: 22. Localization
Affects Versions: 4.1.3
Environment: gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
Reporter: Mark Brown
When compiled with gcc 4.1.1 on Linux the program below runs successfully to
completion as it should. When compiled with stdcxx the facet returns a to_next
value that is greater than the number of internal (wchar_t) characters actually
produced by the conversion and consequently the program aborts.
$ cat t.cpp && make t && ./t
#include
#include
#include
int main ()
{
const std::locale utf8 ("en_US.UTF-8");
typedef std::codecvt UTF8_Cvt;
const UTF8_Cvt &cvt = std::use_facet(utf8);
const char src[] = "abc";
wchar_t dst [2] = { L'\0' };
const char* from_next;
wchar_t* to_next;
std::mbstate_t state = std::mbstate_t ();
const std::codecvt_base::result res =
cvt.in (state,
src, src + 1, from_next,
dst, dst + 2, to_next);
assert (1 == from_next - src);
assert (1 == to_next - dst);
assert ('a' == dst [0]);
}
gcc -c -I/home/mbrown/stdcxx/include/ansi -D_RWSTDDEBUG
-I/home/mbrown/stdcxx/include -I/build/mbrown/stdcxx-gcc-4.1.1-11S/include
-I/home/mbrown/stdcxx/examples/include -pedantic -nostdinc++ -g -W -Wall
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
t.cpp
t.cpp: In function 'int main()':
t.cpp:21: warning: unused variable 'res'
gcc t.o -o t -L/build/mbrown/stdcxx-gcc-4.1.1-11S/lib -lstd11S -lsupc++ -lm
t: t.cpp:26: int main(): Assertion `1 == from_next - src' failed.
Aborted
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-426) infinite loop in exec utility
[ https://issues.apache.org/jira/browse/STDCXX-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Brown updated STDCXX-426: -- Attachment: strace.run-21.cwchar.log Attached partial strace output of running exec 21.cwchar. > infinite loop in exec utility > - > > Key: STDCXX-426 > URL: https://issues.apache.org/jira/browse/STDCXX-426 > Project: C++ Standard Library > Issue Type: Bug > Components: Test Driver >Affects Versions: 4.2 > Environment: gcc 3.4.6 on Red Hat Advanced Server 4, 12D (shared, > wide, optimized, thread-safe) build >Reporter: Mark Brown >Priority: Critical > Fix For: 4.2 > > Attachments: strace.run-21.cwchar.log > > > Copied from > http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200705.mbox/[EMAIL > PROTECTED] > Original Message > Subject: infinite loop in exec > Date: Wed, 23 May 2007 14:28:47 -0600 > From: Martin Sebor <[EMAIL PROTECTED]> > Reply-To: stdcxx-dev@incubator.apache.org > Organization: Rogue Wave Software > To: stdcxx-dev@incubator.apache.org > I'm running into an (almost?) infinite loop when running some > of our tests under the exec utility on Linux (in a 12D build > with gcc 3.4.6 on Red Hat Advanced Server 4, I haven't tried > other configurations). The initial output of strace for one > of the tests, 21.cwchar, is in the attached file. The test > by itself runs fine to completion and doesn't produce any > unusual output (no NULs). > Andrew, when you have a chance, can you take a look at it? > If that's not going to be soon let me know if I should open > an issue. > Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-426) infinite loop in exec utility
infinite loop in exec utility - Key: STDCXX-426 URL: https://issues.apache.org/jira/browse/STDCXX-426 Project: C++ Standard Library Issue Type: Bug Components: Test Driver Affects Versions: 4.2 Environment: gcc 3.4.6 on Red Hat Advanced Server 4, 12D (shared, wide, optimized, thread-safe) build Reporter: Mark Brown Priority: Critical Fix For: 4.2 Copied from http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200705.mbox/[EMAIL PROTECTED] Original Message Subject: infinite loop in exec Date: Wed, 23 May 2007 14:28:47 -0600 From: Martin Sebor <[EMAIL PROTECTED]> Reply-To: stdcxx-dev@incubator.apache.org Organization: Rogue Wave Software To: stdcxx-dev@incubator.apache.org I'm running into an (almost?) infinite loop when running some of our tests under the exec utility on Linux (in a 12D build with gcc 3.4.6 on Red Hat Advanced Server 4, I haven't tried other configurations). The initial output of strace for one of the tests, 21.cwchar, is in the attached file. The test by itself runs fine to completion and doesn't produce any unusual output (no NULs). Andrew, when you have a chance, can you take a look at it? If that's not going to be soon let me know if I should open an issue. Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-425) remove #include from example programs
remove #include from example programs -- Key: STDCXX-425 URL: https://issues.apache.org/jira/browse/STDCXX-425 Project: C++ Standard Library Issue Type: Improvement Components: Examples Affects Versions: 4.1.3 Reporter: Mark Brown I was trying to use the stdcxx example programs to benchmark compilation and link speeds against other libraries (g++, STLport) but the examples only compile with stdcxx because they each include an header. I tried removing the #include directive from several of the examples to see if they would still compile and they all did. It would be nice to remove the header and make the examples compile with other C++ standard libraries as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-412) money_get fails to parse currency in international format
[ https://issues.apache.org/jira/browse/STDCXX-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Brown updated STDCXX-412: -- Summary: money_get fails to parse currency in international format (was: num_get fails to parse currency in international format) Corrected the name of the facet (it's money_get, not num_get). Doh! > money_get fails to parse currency in international format > - > > Key: STDCXX-412 > URL: https://issues.apache.org/jira/browse/STDCXX-412 > Project: C++ Standard Library > Issue Type: Bug > Components: 22. Localization >Affects Versions: 4.1.3 > Environment: gcc 4.1.1 on Linux >Reporter: Mark Brown > > The example program money_get fails when extractinng monetary values in > international format such as "USD 1234" probably because of a bug in the > library. From > http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200705.mbox/[EMAIL > PROTECTED]: > -Original Message- > From: [EMAIL PROTECTED] > Sent: Sat, 12 May 2007 14:09:34 -0600 > To: stdcxx-dev@incubator.apache.org > Subject: Re: svn commit: r537492 - > /incubator/stdcxx/trunk/doc/stdlibref/money-get.html > Mark Brown wrote: > > Martin, > > > > Thanks for fixing it! I have a question about the new code: Could you show > > an example of an international monetary string that would be correctly > > parsed by the facet? I tried a few but none of them could be parsed. For > > instance, "USD 1234" gives this output: > > USD 1234 --> "" --> 0 > > The same happens with g++ and STLport so I suspect I must be doing > > something wrong. Removing the space between the currency symbol and the > > number didn't make a difference. > Hmm, I guess I should have tested the internationalized behavior before > I put it in. I think the code is correct as is and your input should be > correctly parsed by the facet (and produce 1234 on output). I'm not sure > what's going on. Stepping through the code it looks like the money_get > facet ends up retrieving the wrong specialization of moneypunct, i.e., > moneypunct when it needs moneypunct. What's > puzzling is that both libstdc++ and STLport behave the same. It seems > like too much of a coincidence for all three implementations to suffer > from the same bug. > In any event, thanks for bringing it to our attention! Can you open an > issue for this as well so we don't forget to investigate it in case I > don't get around to it soon? > Thanks > Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-413) 22.locale.money.get.cpp doesn't test international monetary formats
[ https://issues.apache.org/jira/browse/STDCXX-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Brown updated STDCXX-413: -- Component/s: Tests Description: The test 22.locale.money.get.cpp doesn't exercise international monetary formats. See: -Original Message- From: [EMAIL PROTECTED] Sent: Sat, 12 May 2007 15:42:16 -0600 To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r537492 - /incubator/stdcxx/trunk/doc/stdlibref/money-get.html Mark Brown wrote: >> -Original Message- >> From: [EMAIL PROTECTED] >> Sent: Sat, 12 May 2007 14:09:34 -0600 >> To: stdcxx-dev@incubator.apache.org >> Subject: Re: svn commit: r537492 - >> /incubator/stdcxx/trunk/doc/stdlibref/money-get.html >> >> Mark Brown wrote: >>> Martin, >>> >>> Thanks for fixing it! I have a question about the new code: Could you >>> show an example of an international monetary string that would be >>> correctly parsed by the facet? I tried a few but none of them could be >>> parsed. For instance, "USD 1234" gives this output: >>> USD 1234 --> "" --> 0 >>> The same happens with g++ and STLport so I suspect I must be doing >>> something wrong. Removing the space between the currency symbol and the >>> number didn't make a difference. >> Hmm, I guess I should have tested the internationalized behavior before >> I put it in. I think the code is correct as is and your input should be >> correctly parsed by the facet (and produce 1234 on output). I'm not sure >> what's going on. Stepping through the code it looks like the money_get >> facet ends up retrieving the wrong specialization of moneypunct, i.e., >> moneypunct when it needs moneypunct. What's >> puzzling is that both libstdc++ and STLport behave the same. It seems >> like too much of a coincidence for all three implementations to suffer >> from the same bug. >> >> In any event, thanks for bringing it to our attention! Can you open an >> issue for this as well so we don't forget to investigate it in case I >> don't get around to it soon? > > I can certainly do that. I should also mention that while investigating this > problem I found a test that's supposed to test this functionality: > 22.locale.money.get.cpp. The test fails 20 out of 1934 assertions but none of > them look like they have anything to do with parsing international monetary > values. It doesn't look like they are being tested at all... Yeah, I noticed it too. I'm in the process of enhancing the test to exercise the international formats as well. If you don't mind creating another issue for the test, just for tracking purposes, that would be swell! Martin Affects Version/s: 4.1.3 Summary: 22.locale.money.get.cpp doesn't test international monetary formats (was: 22.locale.money.get.cpp doesn') Finishing an accidentally submitted incomplete issue. > 22.locale.money.get.cpp doesn't test international monetary formats > --- > > Key: STDCXX-413 > URL: https://issues.apache.org/jira/browse/STDCXX-413 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.1.3 >Reporter: Mark Brown > > The test 22.locale.money.get.cpp doesn't exercise international monetary > formats. See: > -Original Message- > From: [EMAIL PROTECTED] > Sent: Sat, 12 May 2007 15:42:16 -0600 > To: stdcxx-dev@incubator.apache.org > Subject: Re: svn commit: r537492 - > /incubator/stdcxx/trunk/doc/stdlibref/money-get.html > Mark Brown wrote: > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> Sent: Sat, 12 May 2007 14:09:34 -0600 > >> To: stdcxx-dev@incubator.apache.org > >> Subject: Re: svn commit: r537492 - > >> /incubator/stdcxx/trunk/doc/stdlibref/money-get.html > >> > >> Mark Brown wrote: > >>> Martin, > >>> > >>> Thanks for fixing it! I have a question about the new code: Could you > >>> show an example of an international monetary string that would be > >>> correctly parsed by the facet? I tried a few but none of them could be > >>> parsed. For instance, "USD 1234" gives this output: > >>> USD 1234 --> "" --> 0 > >>> The same happens with g++ and STLport so I suspect I must be doing > >>> something wrong. Removing the space between the currency symbol and the > >>> number didn't make a difference. > >> Hmm, I guess I should have tested the internationalized behavior before > >> I put it in. I think the code is correct as is and your input should be > >> correctly parsed by the facet (and produce 1234 on output). I'm not sure > >> what's going on. Stepping through the code it looks like the money_get > >> facet ends up retrieving the wrong specialization of moneypunct, i.e., > >> moneypunct when it needs moneypunct. What's > >> puzzling is that both libstdc++ and STLport behave the same. It seems > >> like too much of a coincidence
[jira] Created: (STDCXX-412) num_get fails to parse currency in international format
num_get fails to parse currency in international format --- Key: STDCXX-412 URL: https://issues.apache.org/jira/browse/STDCXX-412 Project: C++ Standard Library Issue Type: Bug Components: 22. Localization Affects Versions: 4.1.3 Environment: gcc 4.1.1 on Linux Reporter: Mark Brown The example program money_get fails when extractinng monetary values in international format such as "USD 1234" probably because of a bug in the library. From http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200705.mbox/[EMAIL PROTECTED]: -Original Message- From: [EMAIL PROTECTED] Sent: Sat, 12 May 2007 14:09:34 -0600 To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r537492 - /incubator/stdcxx/trunk/doc/stdlibref/money-get.html Mark Brown wrote: > Martin, > > Thanks for fixing it! I have a question about the new code: Could you show an > example of an international monetary string that would be correctly parsed by > the facet? I tried a few but none of them could be parsed. For instance, "USD > 1234" gives this output: > USD 1234 --> "" --> 0 > The same happens with g++ and STLport so I suspect I must be doing something > wrong. Removing the space between the currency symbol and the number didn't > make a difference. Hmm, I guess I should have tested the internationalized behavior before I put it in. I think the code is correct as is and your input should be correctly parsed by the facet (and produce 1234 on output). I'm not sure what's going on. Stepping through the code it looks like the money_get facet ends up retrieving the wrong specialization of moneypunct, i.e., moneypunct when it needs moneypunct. What's puzzling is that both libstdc++ and STLport behave the same. It seems like too much of a coincidence for all three implementations to suffer from the same bug. In any event, thanks for bringing it to our attention! Can you open an issue for this as well so we don't forget to investigate it in case I don't get around to it soon? Thanks Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-413) 22.locale.money.get.cpp doesn'
22.locale.money.get.cpp doesn' -- Key: STDCXX-413 URL: https://issues.apache.org/jira/browse/STDCXX-413 Project: C++ Standard Library Issue Type: Bug Reporter: Mark Brown -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-411) documented money_get example output doesn't match real output
documented money_get example output doesn't match real output - Key: STDCXX-411 URL: https://issues.apache.org/jira/browse/STDCXX-411 Project: C++ Standard Library Issue Type: Bug Components: Documentation Affects Versions: 4.1.3 Reporter: Mark Brown -Original Message- From: [EMAIL PROTECTED] Sent: Fri, 11 May 2007 16:54:37 -0600 To: stdcxx-dev@incubator.apache.org Subject: Re: money_get example output Mark Brown wrote: > Hi all, > > Out of curiosity I tried compiling and running the example from the money_get > page with stdcxx on Linux but the output is different than the documentation > shows. So I tried it with g++ and the output is different still. Is the > documentation incorrect or is there a bug in the library? Can someone explain > what the correct output should be? > > $ ./money_get-stdcxx > $100.02 --> --> 0e-2175 > $ ./money_get-g++ > $100.02 --> --> 1.432e-3754 > > The example program is on this page: > http://incubator.apache.org/stdcxx/doc/stdlibref/money-get.html I think the problem is that the example code on the documentation page doesn't set the locale. The real example (i.e., the actual program) does: it sets it to the English US locale. The code is here: http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/examples/manual/moneyget.cpp The reason why stdcxx and libstdc++ produce different output in the default "C" locale is in all likelihood because the facet fails to store a value in the uninitialized variable and the example ends up writing out bogus bits. Can you please open a new Documentation issue for this? FWIW, copying the source code of each example program into the docs and keeping the two in sync is a maintenance headache. We should find a better way to do this. One possibility for dealing with this is to get rid of the code and replace it with a link to the .cpp file in Subversion. That alone probably isn't the most user-friendly solution. A variation on this approach that might be better is to run a script on the documentation sources after checking them out of Subversion on the Apache Web server and replace the links mentioned above with the up-to-date source code of each example extracted at the same time out of the repository. Can anyone think of any other ways to keep things in sync, or of any further improvements to the process? Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-410) money_base not documented
money_base not documented - Key: STDCXX-410 URL: https://issues.apache.org/jira/browse/STDCXX-410 Project: C++ Standard Library Issue Type: Bug Components: Documentation Affects Versions: 4.1.3 Reporter: Mark Brown The money_get Class reference pag: http://incubator.apache.org/stdcxx/doc/stdlibref/money-get.html is missing documentation for the money_base class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-364) [gcc/Linux] std::tm not declared in
[
https://issues.apache.org/jira/browse/STDCXX-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483014
]
Mark Brown commented on STDCXX-364:
---
I get the same error with gcc 3.4.4 on Cygwin.
> [gcc/Linux] std::tm not declared in
>
>
> Key: STDCXX-364
> URL: https://issues.apache.org/jira/browse/STDCXX-364
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 21. Strings
>Affects Versions: 4.1.3
> Environment: Linux, gcc 3.4.6 - 4.1.2
>Reporter: Scott (Yu) Zhong
>
> getting this error:
> /home/scottz/stdcxx/tests/strings/21.cwchar.cpp:568: error: reference to 'tm'
> is ambiguous
> /usr/include/../include/time.h:135: error: candidates are: struct tm
> /home/scottz/stdcxx/tests/strings/21.cwchar.cpp:550: error:
> struct Fallback::tm
> /home/scottz/stdcxx/tests/strings/21.cwchar.cpp:568: error: reference to 'tm'
> is ambiguous
> /usr/include/../include/time.h:135: error: candidates are: struct tm
> /home/scottz/stdcxx/tests/strings/21.cwchar.cpp:550: error:
> struct Fallback::tm
> /home/scottz/stdcxx/tests/strings/21.cwchar.cpp:568: error: 'tm' does not
> name a type
> /home/scottz/stdcxx/tests/strings/21.cwchar.cpp:577: error: 'test_tm' in
> namespace 'std::Nested' does not name a type
> -
> Martin Sebor [EMAIL PROTECTED]
> I was able to reproduce the same error with gcc 3.4.6.
> The purpose of the test is to verify the conformance of the header
> WRT namespace cleanliness (i.e., that symbols like struct tm are defined in
> namespace std and not also in the global scope). The test is designed to fail
> at runtime (via assertions) rather than at compile time but it looks like the
> implementation of the test (or maybe even its
> design) is broken. In any case, the fact that the test doesn't compile
> suggests there is a problem with the header.
> The compilation errors for the simple program below confirm this. Can you
> open an issue for this problem and reference this thread in the archive in
> the issue?
> $ cat t.cpp && nice make t
> #include
> int main ()
> {
> std::tm tmb = { 0 };
> }
> gcc -c -I/amd/devco/sebor/stdcxx/include/ansi -D_RWSTDDEBUG
> -I/amd/devco/sebor/stdcxx/include -I/build/sebor/stdcxx-gcc-3.4.6-11S/include
> -I/amd/devco/sebor/stdcxx/../rwtest
> -I/amd/devco/sebor/stdcxx/../rwtest/include
> -I/amd/devco/sebor/stdcxx/tests/include -pedantic -nostdinc++ -g -W -Wall
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long
> -Wcast-align t.cpp
> t.cpp: In function `int main()':
> t.cpp:5: error: `tm' is not a member of `std'
> t.cpp:5: error: expected `;' before "tmb"
> make: *** [t.o] Error 1
> Thanks
> Martin
> $ cat t.cpp && nice make t
> #include
> int main ()
> {
> std::tm tmb = { 0 };
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-351) [gcc 3.4.6] error on static const int expression as an array dimension in template code
[
https://issues.apache.org/jira/browse/STDCXX-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483012
]
Mark Brown commented on STDCXX-351:
---
The test compiles now so your change must have fixed it.
> [gcc 3.4.6] error on static const int expression as an array dimension in
> template code
> ---
>
> Key: STDCXX-351
> URL: https://issues.apache.org/jira/browse/STDCXX-351
> Project: C++ Standard Library
> Issue Type: Bug
> Components: External
> Environment: gcc 3.4.6
>Reporter: Martin Sebor
> Assigned To: Martin Sebor
> Fix For: 4.2
>
>
> The well-formed program below fails to compile with gcc 3.4.6 (gcc 4.1 does
> fine):
> $ cat t.cpp && gcc --version && gcc -pedantic t.cpp
> template struct S { static const int N = 1; };
> template
> void foo () {
> static const int N = S::N;
> static int a [S::N];
> static int b [N];
> }
> int main () { foo(); }
> gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> t.cpp: In function `void foo()':
> t.cpp:7: error: ISO C++ forbids variable-size array `b'
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-355) new container member functions cbegin() and cend()
new container member functions cbegin() and cend() -- Key: STDCXX-355 URL: https://issues.apache.org/jira/browse/STDCXX-355 Project: C++ Standard Library Issue Type: New Feature Components: 23. Containers Affects Versions: 4.1.2, 4.1.3 Reporter: Mark Brown This is a placeholder issue to implement the new container member functions cbegin(), cend(), crbegin() and crend() described in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1674.pdf. See also this post in the archive: http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200703.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-353) [Cygwin] localedef errors: UCS value of symbolic character out of range
[Cygwin] localedef errors: UCS value of symbolic character out of range --- Key: STDCXX-353 URL: https://issues.apache.org/jira/browse/STDCXX-353 Project: C++ Standard Library Issue Type: Bug Components: Locales Affects Versions: 4.1.3 Environment: Cygwin Reporter: Mark Brown On Cygwin, locale successfully builds all locales except zh_CN.GB18030 and zh_TW.EUC-TW: $ nice make -C../bin locales -k make: Entering directory `/home/mbrown/stdcxx-gcc-4.1.1-15s/bin' ./localedef -w -c -f /home/mbrown/stdcxx/etc/nls/charmaps/GB18030 -i /home/mbrown/stdcxx/etc/nls/src/zh_CN /home/mbrown/stdcxx-gcc-4.1.1-15s/nls/zh_CN.GB18030 Error 315: UCS value 66304 of symbolic character out of range. make: *** [zh_CN.GB18030] Error 4 ./localedef -w -c -f /home/mbrown/stdcxx/etc/nls/charmaps/EUC-TW -i /home/mbrown/stdcxx/etc/nls/src/zh_TW /home/mbrown/stdcxx-gcc-4.1.1-15s/nls/zh_TW.EUC-TW Error 315: UCS value 131083 of symbolic character out of range. make: *** [zh_TW.EUC-TW] Error 4 make: Target `locales' not remade because of errors. make: Leaving directory `/home/mbrown/stdcxx-gcc-4.1.1-15s/bin' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-352) [Cygwin] Windows popups in optimized builds
[ https://issues.apache.org/jira/browse/STDCXX-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479885 ] Mark Brown commented on STDCXX-352: --- Also reproduced by Farid Zaripov: http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200703.mbox/[EMAIL PROTECTED] > [Cygwin] Windows popups in optimized builds > --- > > Key: STDCXX-352 > URL: https://issues.apache.org/jira/browse/STDCXX-352 > Project: C++ Standard Library > Issue Type: Bug > Components: Build >Affects Versions: 4.1.3 > Environment: Cygwin, gcc >Reporter: Mark Brown > > Originally posted here: > http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200703.mbox/[EMAIL > PROTECTED] > > -Original Message- > > From: [EMAIL PROTECTED] > > Sent: Sat, 3 Mar 2007 11:33:26 -0800 > > To: stdcxx-dev@incubator.apache.org > > Subject: Re: Cygwin 12d build issues > > > > Thanks. I opened issue STDCXX-346 for the -fPIC warnings. I'll post > > a patch as soon as I'm done testing it. > > > > What about the LIBC_EXCEPTIONS.exe problem with the popup window? > The other test that pops up this window is EXTERN_INLINE.exe. It says: > EXTERN_INLINE.exe has stopped working. > A problem caused the program to stop working correctly. > Windows will close the program and notify you if a solution is > available. > > > > -- Mark > > > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> Sent: Fri, 02 Mar 2007 10:13:47 -0700 > >> To: stdcxx-dev@incubator.apache.org > >> Subject: Re: Cygwin 12d build issues > >> > >> Mark Brown wrote: > >>> Hi all, > >>> > >>> Just for kicks I'm trying to build a 12d version of the library on > >>> Cygwin. Things looks like they're going okay except for a couple of > >>> errors that open up a message box on the screen telling me that a test > >>> had a problem. The build stops at this point and waits for me to click > >>> on a button before moving on to the next test. I don't remember the > >>> first but the second one is for LIBC_EXCEPTIONS.exe. Is this normal? > >>> > >>> I also see lots of messages like these: > >>> > >>> make[2]: Entering directory `/home/mbrown/stdcxx-12d/lib' > >>> generating dependencies for $(TOPDIR)/src/atomic.s > >>> generating dependencies for $(TOPDIR)/src/wctype.cpp > >>> /home/mbrown/stdcxx/src/wctype.cpp:0: warning: -fPIC ignored for target > >>> (all code is position independent) > >>> > >>> I'm guessing Cygwin might need the same conditional as the one for AIX > >>> in gcc.config: > >>> > >>> # IBM AIX code is always position independent > >>> ifneq ($(OSNAME),AIX) > >>> PICFLAGS= -fPIC > >>> endif > >> > >> Looks like it. If you could open an issue for this too, > >> that would be great! A patch is also welcome :) > >> > >> Thanks > >> Martin > >> > >>> > >>> -- Mark -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-352) [Cygwin] Windows popups in optimized builds
[Cygwin] Windows popups in optimized builds --- Key: STDCXX-352 URL: https://issues.apache.org/jira/browse/STDCXX-352 Project: C++ Standard Library Issue Type: Bug Components: Build Affects Versions: 4.1.3 Environment: Cygwin, gcc Reporter: Mark Brown Originally posted here: http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200703.mbox/[EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] > Sent: Sat, 3 Mar 2007 11:33:26 -0800 > To: stdcxx-dev@incubator.apache.org > Subject: Re: Cygwin 12d build issues > > Thanks. I opened issue STDCXX-346 for the -fPIC warnings. I'll post > a patch as soon as I'm done testing it. > > What about the LIBC_EXCEPTIONS.exe problem with the popup window? The other test that pops up this window is EXTERN_INLINE.exe. It says: EXTERN_INLINE.exe has stopped working. A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available. > > -- Mark > > >> -Original Message- >> From: [EMAIL PROTECTED] >> Sent: Fri, 02 Mar 2007 10:13:47 -0700 >> To: stdcxx-dev@incubator.apache.org >> Subject: Re: Cygwin 12d build issues >> >> Mark Brown wrote: >>> Hi all, >>> >>> Just for kicks I'm trying to build a 12d version of the library on >>> Cygwin. Things looks like they're going okay except for a couple of >>> errors that open up a message box on the screen telling me that a test >>> had a problem. The build stops at this point and waits for me to click >>> on a button before moving on to the next test. I don't remember the >>> first but the second one is for LIBC_EXCEPTIONS.exe. Is this normal? >>> >>> I also see lots of messages like these: >>> >>> make[2]: Entering directory `/home/mbrown/stdcxx-12d/lib' >>> generating dependencies for $(TOPDIR)/src/atomic.s >>> generating dependencies for $(TOPDIR)/src/wctype.cpp >>> /home/mbrown/stdcxx/src/wctype.cpp:0: warning: -fPIC ignored for target >>> (all code is position independent) >>> >>> I'm guessing Cygwin might need the same conditional as the one for AIX >>> in gcc.config: >>> >>> # IBM AIX code is always position independent >>> ifneq ($(OSNAME),AIX) >>> PICFLAGS= -fPIC >>> endif >> >> Looks like it. If you could open an issue for this too, >> that would be great! A patch is also welcome :) >> >> Thanks >> Martin >> >>> >>> -- Mark -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-338) [Cygwin] linker errors due to multiple definition of `std::exception::what()'
[ https://issues.apache.org/jira/browse/STDCXX-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479884 ] Mark Brown commented on STDCXX-338: --- If it helps, I also get the same error with the latest trunk and gcc 4.1.1: gcc -c -I/home/mbrown/stdcxx/include/ansi -D_RWSTDDEBUG -mthreads -D_RWSTD_USE_CONFIG -I/home/mbrown/stdcxx/include -I/home/mbrown/stdcxx-gcc-4.1.1-15s/include -I/home/mbrown/stdcxx/examples/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align t.cpp gcc t.o -o t -mthreads -L/home/mbrown/stdcxx-gcc-4.1.1-15s/lib -lstd15s -lsupc++ -lcatgets -liconv -lm /usr/local/gcc-4.1.1/lib/gcc/i686-pc-cygwin/4.1.1/../../../libsupc++.a(eh_exception.o): In function `_ZNSt13bad_exceptionD2Ev': /home/mbrown/gcc-4.1.1/libstdc++-v3/libsupc++/eh_exception.cc:38: multiple definition of `std::exception::what() const' /home/mbrown/stdcxx-gcc-4.1.1-15s/lib/libstd15s.a(exception.o):/home/mbrown/stdcxx/src/exception.cpp:341: first defined here collect2: ld returned 1 exit status make: *** [t] Error 1 > [Cygwin] linker errors due to multiple definition of `std::exception::what()' > - > > Key: STDCXX-338 > URL: https://issues.apache.org/jira/browse/STDCXX-338 > Project: C++ Standard Library > Issue Type: Bug > Components: Configuration >Affects Versions: 4.1.3 > Environment: Cygwin >Reporter: Mark Brown > > When linking with stdcxx on Cygwin I get errors like: > /usr/lib/gcc/i686-pc-cygwin/3.4.4/libsupc++.a(eh_exception.o):(.text+0x80): > multiple definition of `std::exception::what() const' > The config.log file shows these errors for the EXCEPTION_WHAT test: > gcc -c -pedantic -nostdinc++ -g -Wall -W -Wcast-qual -Winline -Wshadow > -Wwrite-strings -Wno-long-long -Wcast-align -D_RWSTDDEBUG -D_RWSTD_USE_CONFIG > -I. /build > /sebor/stdcxx-4.1.3/etc/config/src/EXCEPTION_WHAT.cpp > In file included from > /home/mbrown/stdcxx-4.1.3/etc/config/src/EXCEPTION_WHAT.cpp:10: > /home/mbrown/stdcxx-4.1.3/etc/config/src/BAD_ALLOC_ASSIGNMENT.cpp:83: > warning: `class std::exception' has virtual functions but non-virtual > destructor > /home/mbrown/stdcxx-4.1.3/etc/config/src/BAD_ALLOC_ASSIGNMENT.cpp:333: > warning: unused parameter 'rhs' > /home/mbrown/stdcxx-4.1.3/etc/config/src/BAD_ALLOC_ASSIGNMENT.cpp:388: > warning: unused parameter 'rhs' > gcc EXCEPTION_WHAT.o -lm -lsupc++ -o EXCEPTION_WHAT > /usr/lib/gcc/i686-pc-cygwin/3.4.4/libsupc++.a(eh_exception.o):(.text+0x0): > multiple definition of `std::exception::~exception()' > EXCEPTION_WHAT.o:/home/mbrown/stdcxx-4.1.3/etc/config/src/BAD_ALLOC_ASSIGNMENT.cpp:(.text$_ZNSt9exceptionD2Ev[std::exception::~exception()]+0x0): > first defined here > collect2: ld returned 1 exit status -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-337) [Cygwin] unsats on _libiconv, _catgets
[ https://issues.apache.org/jira/browse/STDCXX-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477681 ] Mark Brown commented on STDCXX-337: --- I'm not sure how it happened but there's a typo in the patch I suggested above (my local copy is okay). The flag should have been -lcatgets, not -catgets. I'm sorry for the trouble. > [Cygwin] unsats on _libiconv, _catgets > -- > > Key: STDCXX-337 > URL: https://issues.apache.org/jira/browse/STDCXX-337 > Project: C++ Standard Library > Issue Type: Bug > Components: Build >Affects Versions: 4.1.3 > Environment: Cygwin >Reporter: Mark Brown > > I tried to build the library on Cygwin but I'm getting linker errors for the > localedef utility. I have the iconv library installed (in /usr/lib) but make > isn't linking with it. I also get linker errors for _catopen, _catgets, and > _catclose. I searched under /usr/lib to see what library defines these > symbols and it's libcatgets.a. Should the makefile be linking with it? > gcc localedef.o aliases.o charmap.o codecvt.o collate.o ctype.o def.o > diagnostic.o messages.o monetary.o numeric.o path.o time.o scanner.o -o > localedef -L/home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib -lstd11s -lsupc++ > -lm > /usr/lib/gcc/i686-pc-cygwin/3.4.4/libsupc++.a(eh_exception.o):(.text+0x80): > multiple definition of `std::exception::what() const' > /home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib/libstd11s.a(exception.o):/home/mbrown/stdcxx-4.1.3/src/exception.cpp:334: > first defined here > charmap.o: In function `_ZNSt4pairIKwSsEC1ERKS1_': > /home/mbrown/stdcxx-4.1.3/include/rw/_specialized.h:(.text+0x4c0): undefined > reference to `_libiconv_open' > charmap.o: In function `_ZNK7Charmap15convert_to_utf8EPKcjPcj': > /home/mbrown/stdcxx-4.1.3/util/charmap.cpp:346: undefined reference to > `_libiconv' > /home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib/libstd11s.a(messages.o): In > function `_ZN4__rw13__rw_cat_openERKSsRKSt6locale': > /home/mbrown/stdcxx-4.1.3/src/messages.cpp:205: undefined reference to > `_catopen' > /home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib/libstd11s.a(messages.o): In > function `_ZN4__rw16__rw_get_messageEiii': > /home/mbrown/stdcxx-4.1.3/src/messages.cpp:235: undefined reference to > `_catgets' > /home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib/libstd11s.a(messages.o): In > function `_ZN4__rw14__rw_cat_closeEi': > /home/mbrown/stdcxx-4.1.3/src/messages.cpp:277: undefined reference to > `_catclose' > collect2: ld returned 1 exit status > make[2]: *** [localedef] Error 1 > make[2]: Leaving directory `/home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/bin' > make[1]: *** [util] Error 2 > make[1]: Leaving directory `/home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s' > make: *** [libstd] Error 2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-346) [Cygwin] gcc -fPIC warnings
[Cygwin] gcc -fPIC warnings --- Key: STDCXX-346 URL: https://issues.apache.org/jira/browse/STDCXX-346 Project: C++ Standard Library Issue Type: Bug Components: Build Affects Versions: 4.1.3 Environment: gcc 3.4.4 on Cygwin Reporter: Mark Brown gcc shared library build on Cygwin spits out a warning message about the -fPIC flag on the command line for every .cpp file: make[2]: Entering directory `/home/mbrown/stdcxx-12d/lib' generating dependencies for $(TOPDIR)/src/atomic.s generating dependencies for $(TOPDIR)/src/wctype.cpp /home/mbrown/stdcxx/src/wctype.cpp:0: warning: -fPIC ignored for target (all code is position independent) Removing the -fPIC gets rid of the warnings so I'm guessing Cygwin might need the same conditional as the one for AIX in gcc.config: # IBM AIX code is always position independent ifneq ($(OSNAME),AIX) PICFLAGS= -fPIC endif Here's the archived post where this problem was first raised: http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200703.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-24) [Cygwin] collate.cpp needs wcsnxfrm
[ https://issues.apache.org/jira/browse/STDCXX-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477188 ] Mark Brown commented on STDCXX-24: -- I can compile the latest library on Cygwin without any errors from collate.cpp. > [Cygwin] collate.cpp needs wcsnxfrm > --- > > Key: STDCXX-24 > URL: https://issues.apache.org/jira/browse/STDCXX-24 > Project: C++ Standard Library > Issue Type: Bug > Components: 22. Localization >Affects Versions: 4.1.2 > Environment: Cygwin >Reporter: Lance Diduck > Fix For: 4.2 > > > Martin Sebor paraphrased: > Cygwin really doesn't define wcsnxfrm() (i.e., both > _RWSTD_NO_WCSXFRM and _RWSTD_NO_WCSXFRM_IN_LIBC are #defined) > we should probably implement our own transformation. > Looking at > collate.cpp, though, I don't see a check for _RWSTD_NO_WCSXFRM_IN_LIBC, > just for the former (which only determines whether function is declared; > the latter tells us if it's also not defined). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-340) localedef error on Cygwin
localedef error on Cygwin - Key: STDCXX-340 URL: https://issues.apache.org/jira/browse/STDCXX-340 Project: C++ Standard Library Issue Type: Bug Components: Utilities Affects Versions: 4.1.3 Environment: Cygwin Reporter: Mark Brown While trying to reproduce the problem noted in STDCXX-333 on Cygwin I encountered an error with the stdcxx localedef program: nls$ ../bin/localedef -c -f /home/mbrown/stdcxx/etc/nls/charmaps/UTF-8 -i /home/mbrown/stdcxx/etc/nls/src/en_US en_US.UTF-8 call to system LC_ALL=C /usr/bin/locale -a >/tmp/tdf4.0 2>/dev/null: No such file or directory Hangup -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-333) std::wfilebuf extracts more than 1 character from a 1 byte file
[
https://issues.apache.org/jira/browse/STDCXX-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474266
]
Mark Brown commented on STDCXX-333:
---
I tried to see if I could reproduce this problem on Cygwin. My version of
Cygwin doesn't have any locales so I tried to generate the en_US.UTF-8 locale
using the stdcxx localedef program. I got this error:
nls$ ../bin/localedef -c -f /home/mbrown/stdcxx/etc/nls/charmaps/UTF-8 -i
/home/mbrown/stdcxx/etc/nls/src/en_US en_US.UTF-8
call to system LC_ALL=C /usr/bin/locale -a >/tmp/tdf4.0 2>/dev/null: No such
file or directory
Hangup
> std::wfilebuf extracts more than 1 character from a 1 byte file
> ---
>
> Key: STDCXX-333
> URL: https://issues.apache.org/jira/browse/STDCXX-333
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.1.3
> Environment: gcc 3.2.3 on Linux
>Reporter: Mark Brown
>
> I get an an abort when I run the following program on Linux.
> #include
> #include
> #include
> int main ()
> {
> {
> std::filebuf fb;
> fb.open ("file", std::ios::out);
> fb.sputc ('a');
> }
> std::wfilebuf fb;
> fb.pubimbue (std::locale ("en_US.UTF-8"));
> fb.open ("file", std::ios::in);
> const int c[] = { fb.sbumpc (), fb.sgetc () };
> std::cout << c [0] << ' ' << c [1] << std::endl;
> assert (L'a' == c [0]);
> assert (std::wfilebuf::traits_type::eof () == c [1]);
> }
> test: test.cpp:21: int main(): Assertion `std::wfilebuf::traits_type::eof ()
> == c [1]' failed.
> Aborted
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-338) [Cygwin] linker errors due to multiple definition of `std::exception::what()'
[Cygwin] linker errors due to multiple definition of `std::exception::what()' - Key: STDCXX-338 URL: https://issues.apache.org/jira/browse/STDCXX-338 Project: C++ Standard Library Issue Type: Bug Components: Configuration Affects Versions: 4.1.3 Environment: Cygwin Reporter: Mark Brown When linking with stdcxx on Cygwin I get errors like: /usr/lib/gcc/i686-pc-cygwin/3.4.4/libsupc++.a(eh_exception.o):(.text+0x80): multiple definition of `std::exception::what() const' The config.log file shows these errors for the EXCEPTION_WHAT test: gcc -c -pedantic -nostdinc++ -g -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -D_RWSTDDEBUG -D_RWSTD_USE_CONFIG -I. /build /sebor/stdcxx-4.1.3/etc/config/src/EXCEPTION_WHAT.cpp In file included from /home/mbrown/stdcxx-4.1.3/etc/config/src/EXCEPTION_WHAT.cpp:10: /home/mbrown/stdcxx-4.1.3/etc/config/src/BAD_ALLOC_ASSIGNMENT.cpp:83: warning: `class std::exception' has virtual functions but non-virtual destructor /home/mbrown/stdcxx-4.1.3/etc/config/src/BAD_ALLOC_ASSIGNMENT.cpp:333: warning: unused parameter 'rhs' /home/mbrown/stdcxx-4.1.3/etc/config/src/BAD_ALLOC_ASSIGNMENT.cpp:388: warning: unused parameter 'rhs' gcc EXCEPTION_WHAT.o -lm -lsupc++ -o EXCEPTION_WHAT /usr/lib/gcc/i686-pc-cygwin/3.4.4/libsupc++.a(eh_exception.o):(.text+0x0): multiple definition of `std::exception::~exception()' EXCEPTION_WHAT.o:/home/mbrown/stdcxx-4.1.3/etc/config/src/BAD_ALLOC_ASSIGNMENT.cpp:(.text$_ZNSt9exceptionD2Ev[std::exception::~exception()]+0x0): first defined here collect2: ld returned 1 exit status -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-337) [Cygwin] unsats on _libiconv, _catgets
[ https://issues.apache.org/jira/browse/STDCXX-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472153 ] Mark Brown commented on STDCXX-337: --- Here's a simple patch that fixed the iconv and catgets linker errors for me: $ diff -u /home/mbrown/stdcxx-4.1.3/etc/config/gcc.config /home/mbrown/stdcxx-4.1.3/etc/config/gcc.config.save --- /home/mbrown/stdcxx-4.1.3/etc/config/gcc.config 2007-02-11 16:02:18.352101500 -0700 +++ /home/mbrown/stdcxx-4.1.3/etc/config/gcc.config.save2007-02-11 16:02:15.544101500 -0700 @@ -166,9 +166,6 @@ MULTI_CPPFLAGS_POSIX = -mthreads MULTI_LDFLAGS_POSIX = -mthreads - # link with libcatgets and libiconv - LDLIBS += -catgets -liconv - # set the assembler file suffix to .s AS_EXT = .s endif > [Cygwin] unsats on _libiconv, _catgets > -- > > Key: STDCXX-337 > URL: https://issues.apache.org/jira/browse/STDCXX-337 > Project: C++ Standard Library > Issue Type: Bug > Components: Build >Affects Versions: 4.1.3 > Environment: Cygwin >Reporter: Mark Brown > > I tried to build the library on Cygwin but I'm getting linker errors for the > localedef utility. I have the iconv library installed (in /usr/lib) but make > isn't linking with it. I also get linker errors for _catopen, _catgets, and > _catclose. I searched under /usr/lib to see what library defines these > symbols and it's libcatgets.a. Should the makefile be linking with it? > gcc localedef.o aliases.o charmap.o codecvt.o collate.o ctype.o def.o > diagnostic.o messages.o monetary.o numeric.o path.o time.o scanner.o -o > localedef -L/home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib -lstd11s -lsupc++ > -lm > /usr/lib/gcc/i686-pc-cygwin/3.4.4/libsupc++.a(eh_exception.o):(.text+0x80): > multiple definition of `std::exception::what() const' > /home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib/libstd11s.a(exception.o):/home/mbrown/stdcxx-4.1.3/src/exception.cpp:334: > first defined here > charmap.o: In function `_ZNSt4pairIKwSsEC1ERKS1_': > /home/mbrown/stdcxx-4.1.3/include/rw/_specialized.h:(.text+0x4c0): undefined > reference to `_libiconv_open' > charmap.o: In function `_ZNK7Charmap15convert_to_utf8EPKcjPcj': > /home/mbrown/stdcxx-4.1.3/util/charmap.cpp:346: undefined reference to > `_libiconv' > /home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib/libstd11s.a(messages.o): In > function `_ZN4__rw13__rw_cat_openERKSsRKSt6locale': > /home/mbrown/stdcxx-4.1.3/src/messages.cpp:205: undefined reference to > `_catopen' > /home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib/libstd11s.a(messages.o): In > function `_ZN4__rw16__rw_get_messageEiii': > /home/mbrown/stdcxx-4.1.3/src/messages.cpp:235: undefined reference to > `_catgets' > /home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib/libstd11s.a(messages.o): In > function `_ZN4__rw14__rw_cat_closeEi': > /home/mbrown/stdcxx-4.1.3/src/messages.cpp:277: undefined reference to > `_catclose' > collect2: ld returned 1 exit status > make[2]: *** [localedef] Error 1 > make[2]: Leaving directory `/home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/bin' > make[1]: *** [util] Error 2 > make[1]: Leaving directory `/home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s' > make: *** [libstd] Error 2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-337) link errors on Cygwin
link errors on Cygwin - Key: STDCXX-337 URL: https://issues.apache.org/jira/browse/STDCXX-337 Project: C++ Standard Library Issue Type: Bug Components: Build Affects Versions: 4.1.3 Environment: Cygwin Reporter: Mark Brown I tried to build the library on Cygwin but I'm getting linker errors for the localedef utility. I have the iconv library installed (in /usr/lib) but make isn't linking with it. I also get linker errors for _catopen, _catgets, and _catclose. I searched under /usr/lib to see what library defines these symbols and it's libcatgets.a. Should the makefile be linking with it? gcc localedef.o aliases.o charmap.o codecvt.o collate.o ctype.o def.o diagnostic.o messages.o monetary.o numeric.o path.o time.o scanner.o -o localedef -L/home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib -lstd11s -lsupc++ -lm /usr/lib/gcc/i686-pc-cygwin/3.4.4/libsupc++.a(eh_exception.o):(.text+0x80): multiple definition of `std::exception::what() const' /home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib/libstd11s.a(exception.o):/home/mbrown/stdcxx-4.1.3/src/exception.cpp:334: first defined here charmap.o: In function `_ZNSt4pairIKwSsEC1ERKS1_': /home/mbrown/stdcxx-4.1.3/include/rw/_specialized.h:(.text+0x4c0): undefined reference to `_libiconv_open' charmap.o: In function `_ZNK7Charmap15convert_to_utf8EPKcjPcj': /home/mbrown/stdcxx-4.1.3/util/charmap.cpp:346: undefined reference to `_libiconv' /home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib/libstd11s.a(messages.o): In function `_ZN4__rw13__rw_cat_openERKSsRKSt6locale': /home/mbrown/stdcxx-4.1.3/src/messages.cpp:205: undefined reference to `_catopen' /home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib/libstd11s.a(messages.o): In function `_ZN4__rw16__rw_get_messageEiii': /home/mbrown/stdcxx-4.1.3/src/messages.cpp:235: undefined reference to `_catgets' /home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib/libstd11s.a(messages.o): In function `_ZN4__rw14__rw_cat_closeEi': /home/mbrown/stdcxx-4.1.3/src/messages.cpp:277: undefined reference to `_catclose' collect2: ld returned 1 exit status make[2]: *** [localedef] Error 1 make[2]: Leaving directory `/home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/bin' make[1]: *** [util] Error 2 make[1]: Leaving directory `/home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s' make: *** [libstd] Error 2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-335) std::min() suboptimal
std::min() suboptimal
-
Key: STDCXX-335
URL: https://issues.apache.org/jira/browse/STDCXX-335
Project: C++ Standard Library
Issue Type: Bug
Components: 25. Algorithms
Affects Versions: 4.1.3
Environment: gcc 3.2.3, x86 Linux
Reporter: Mark Brown
I don't know if it's the compiler that's generating worse code for the stdcxx
version of min or if the function is not implemented as efficiently as it could
be but the disassembly for the two functions below shows that my_min() is one
instruction shorter than test_min():
#include
int test_min (int x, int y) { return std::min (x, y); }
int my_min (int x, int y) { return x < y ? x : y; }
_Z8test_minii:
pushl %ebp
movl%esp, %ebp
movl12(%ebp), %eax
cmpl%eax, 8(%ebp)
jg .L2
leal8(%ebp), %eax <<< extra load?
.L4:
movl(%eax), %eax
leave
ret
_Z6my_minii:
pushl %ebp
movl%esp, %ebp
movl12(%ebp), %eax
cmpl8(%ebp), %eax
jle .L6
movl8(%ebp), %eax
.L6:
leave
ret
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-333) std::wfilebuf extracts more than 1 character from a 1 byte file
std::wfilebuf extracts more than 1 character from a 1 byte file
---
Key: STDCXX-333
URL: https://issues.apache.org/jira/browse/STDCXX-333
Project: C++ Standard Library
Issue Type: Bug
Components: 27. Input/Output
Affects Versions: 4.1.3
Environment: gcc 3.2.3 on Linux
Reporter: Mark Brown
I get an an abort when I run the following program on Linux.
#include
#include
#include
int main ()
{
{
std::filebuf fb;
fb.open ("file", std::ios::out);
fb.sputc ('a');
}
std::wfilebuf fb;
fb.pubimbue (std::locale ("en_US.UTF-8"));
fb.open ("file", std::ios::in);
const int c[] = { fb.sbumpc (), fb.sgetc () };
std::cout << c [0] << ' ' << c [1] << std::endl;
assert (L'a' == c [0]);
assert (std::wfilebuf::traits_type::eof () == c [1]);
}
test: test.cpp:21: int main(): Assertion `std::wfilebuf::traits_type::eof () ==
c [1]' failed.
Aborted
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-332) ostringstream::tellp() returns -1 when the stream is empty
ostringstream::tellp() returns -1 when the stream is empty
--
Key: STDCXX-332
URL: https://issues.apache.org/jira/browse/STDCXX-332
Project: C++ Standard Library
Issue Type: Bug
Components: 27. Input/Output
Affects Versions: 4.1.3
Reporter: Mark Brown
When I call tellp() on an empty stringstream I get -1 instead of 0.
#include
#include
main()
{
std::ostringstream out;
std::ios::pos_type pos = out .tellp () ;
assert (pos == 0);
return 0;
}
test: test.cpp:9: int main(): Assertion `pos == 0' failed.
Aborted
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
