[jira] Resolved: (STDCXX-268) std::list constructors do not call destructors for created objects if exception was thrown
[
https://issues.apache.org/jira/browse/STDCXX-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov resolved STDCXX-268.
--
Resolution: Fixed
Fix Version/s: 4.2
Fixed thus: http://svn.apache.org/viewvc?view=revrev=507971
std::list constructors do not call destructors for created objects if
exception was thrown
--
Key: STDCXX-268
URL: https://issues.apache.org/jira/browse/STDCXX-268
Project: C++ Standard Library
Issue Type: Bug
Components: 23. Containers
Affects Versions: 4.1.3
Environment: All
Reporter: Farid Zaripov
Fix For: 4.2
std::list constructors do not satisfy basic exception safety requirement (no
memory leaks) since they do not call destructors for created objects if
exception was thrown.
See details here:
http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200608.mbox/[EMAIL
PROTECTED]
test.cpp:
---
#include list
#include cassert
static int throw_inx = -1;
class ListItem
{
public:
static int count_;
void test ()
{
if (throw_inx == count_)
throw count_;
++count_;
}
ListItem () { test (); }
ListItem (const ListItem) { test (); }
~ListItem () { --count_; }
};
int ListItem::count_ = 0;
int main(int argc, char* argv[])
{
typedef std::listListItem List;
ListItem items [20];
List lst (20);
bool thrown = false;
throw_inx = 10;
try {
ListItem::count_ = 0;
List test (20);
} catch (...) {
thrown = true;
}
assert (thrown);
assert (0 == ListItem::count_);
try {
thrown = false;
ListItem::count_ = 0;
List test (20, items [0]);
} catch (...) {
thrown = true;
}
assert (thrown);
assert (0 == ListItem::count_);
try {
thrown = false;
ListItem::count_ = 0;
List test (items, items + 20);
} catch (...) {
thrown = true;
}
assert (thrown);
assert (0 == ListItem::count_);
try {
thrown = false;
ListItem::count_ = 0;
List test (lst.begin (), lst.end ());
} catch (...) {
thrown = true;
}
assert (thrown);
assert (0 == ListItem::count_);
try {
thrown = false;
ListItem::count_ = 0;
List test (lst);
} catch (...) {
thrown = true;
}
assert (thrown);
assert (0 == ListItem::count_);
return 0;
}
the test output:
-
test: /usr/src/tests/test.cpp:45: int main(int, char**): Assertion `0 ==
ListItem::count_' failed.
Aborted.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [PATCH] crtxn.o (Intel C++ 9.0) - crtend.o (Intel C++ 9.1)
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 let us do away with all the special object files and libraries on the link like. I tried it in a manual test a few months ago and it seemed to work fine but I haven't changed icc.config to use it yet. Would you mind checking it out and if it really does work putting together a patch that enables it for 9.0 and beyond? Do you think there is value in preserving the former linking for pre-9.x compilers? Liviu
Re: [PATCH] crtxn.o (Intel C++ 9.0) - crtend.o (Intel C++ 9.1)
Liviu Nicoara wrote: 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 that will apparently let us do away with all the special object files and libraries on the link like. [...] Do you think there is value in preserving the former linking for pre-9.x compilers? Make that pre-8.1 compilers (as per the Intel incident). I'd keep it unless it's *really* hard to do just in case someone is using an old version of the compiler. Martin
Intel 8.x, 9.x -cxxlib-nostd change, was: Re: [PATCH] crtxn.o (Intel C++ 9.0) - crtend.o (Intel C++ 9.1)
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 misspelled and ignored by the compiler driver. OTOH -X is omitting the standard include paths. 2007-02-19 lnicoara [EMAIL PROTECTED] * etc/config/icc.config Changed build process for post-8.1 compilers to use the yet undocumented -cxxlib-nostd option. Liviu Index: etc/config/icc.config === --- etc/config/icc.config (revision 509218) +++ etc/config/icc.config (working copy) @@ -15,8 +15,11 @@ endif CCVER := $(shell $(CXX) -V foo.c 21 | sed -n s/.*Version *\([0-9.]*\).*/\1/p) +CXX_MAJOR := $(shell echo $(CCVER) | sed s/^\([1-9][0-9]*\).*/\1/) +CXX_MINOR := $(shell echo $(CCVER) | sed s/[1-9]*\.\([0-9]*\).*/\1/) + + CPPFLAGS= -I$(TOPDIR)/include/ansi -CXXFLAGS= -Xc -no_cpprt WARNFLAGS = -w1 PHWARNFLAGS = @@ -26,11 +29,22 @@ ICCDIR = `which $(CXX) | sed 's:bin/$(CXX):lib:'` -LD = $(CXX) -no_cpprt $(ICCDIR)/crtxi.o -LDFLAGS = LDSOFLAGS = -shared -LDLIBS = -Bstatic -lcxa -lunwind -Bdynamic $(ICCDIR)/crtxn.o +# -cxxlib-nostd, present in all compilers since 8.1, will be documented in 10.x +ifeq ($(shell [ $(CXX_MAJOR) -gt 8 -o $(CXX_MAJOR) -eq 8 -a $(CXX_MINOR) -ge 1 ]), 0) + LD= $(CXX) -no_cpprt $(ICCDIR)/crtxi.o + CXXFLAGS = -Xc -no_cpprt + LDFLAGS = + LDLIBS= -Bstatic -lcxa -lunwind -Bdynamic $(ICCDIR)/crtxn.o +else + LD= $(CXX) + CXXFLAGS = -cxxlib-nostd + LDFLAGS = -cxxlib-nostd + LDLIBS= -lcxaguard -lsupc++ +endif + + # The flag(s) to use to embed a library search path into generated executables. RPATH = -Wl,-R
[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 cassert
#include fstream
#include iostream
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.
Re: [jira] Commented: (STDCXX-333) std::wfilebuf extracts more than 1 character from a 1 byte file
Mark Brown (JIRA) wrote:
[ 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
This looks like an unrelated problem. Could you open a new issue for it?
Thanks
Martin
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 cassert
#include fstream
#include iostream
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
[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.
Re: [jira] Commented: (STDCXX-333) std::wfilebuf extracts more than 1 character from a 1 byte file
-Original Message-
From: [EMAIL PROTECTED]
Sent: Mon, 19 Feb 2007 13:35:19 -0700
To: stdcxx-dev@incubator.apache.org
Subject: Re: [jira] Commented: (STDCXX-333) std::wfilebuf extracts more
than 1 character from a 1 byte file
Mark Brown (JIRA) wrote:
[
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
This looks like an unrelated problem. Could you open a new issue for it?
Sure. Here it is: https://issues.apache.org/jira/browse/STDCXX-340.
Mark
Thanks
Martin
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 cassert
#include fstream
#include iostream
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
Re: [jira] Commented: (STDCXX-333) std::wfilebuf extracts more than 1 character from a 1 byte file
I decided to look into this as an exercise in stdcxx debugging and
managed to figure out how to get around the error and generate the
en_US.UTF-8 locale. The change I made to make it work is in the
attached patch file. Let me know if this is the correct format
for patches or if you prefer something else.
Incidentally, the original test program for stdcxx-333 runs fine
on Cygwin with the en_US.UTF-8 locale so the error must be unique
to Linux.
-- Mark
-Original Message-
From: [EMAIL PROTECTED]
Sent: Mon, 19 Feb 2007 12:51:24 -0800
To: stdcxx-dev@incubator.apache.org, stdcxx-dev@incubator.apache.org
Subject: Re: [jira] Commented: (STDCXX-333) std::wfilebuf extracts more
than 1 character from a 1 byte file
-Original Message-
From: [EMAIL PROTECTED]
Sent: Mon, 19 Feb 2007 13:35:19 -0700
To: stdcxx-dev@incubator.apache.org
Subject: Re: [jira] Commented: (STDCXX-333) std::wfilebuf extracts more
than 1 character from a 1 byte file
Mark Brown (JIRA) wrote:
[
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
This looks like an unrelated problem. Could you open a new issue for it?
Sure. Here it is: https://issues.apache.org/jira/browse/STDCXX-340.
Mark
Thanks
Martin
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 cassert
#include fstream
#include iostream
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
Re: [jira] Commented: (STDCXX-333) std::wfilebuf extracts more than 1 character from a 1 byte file
Mark Brown wrote:
I decided to look into this as an exercise in stdcxx debugging and
managed to figure out how to get around the error and generate the
en_US.UTF-8 locale.
Great! Thanks for the detective work!
The change I made to make it work is in the
attached patch file. Let me know if this is the correct format
for patches or if you prefer something else.
I don't see the patch. Did you forget to attach it? (Sometimes the
attachments end up getting stripped by ezmlm even though they
shouldn't). If it's small, you might want to paste it directly into
your mail. Otherwise you might need to post it somewhere (e.g., on
your web page or in the issue itself).
Incidentally, the original test program for stdcxx-333 runs fine
on Cygwin with the en_US.UTF-8 locale so the error must be unique
to Linux.
Hmm. Very odd.
Martin
-- Mark
-Original Message-
From: [EMAIL PROTECTED]
Sent: Mon, 19 Feb 2007 12:51:24 -0800
To: stdcxx-dev@incubator.apache.org, stdcxx-dev@incubator.apache.org
Subject: Re: [jira] Commented: (STDCXX-333) std::wfilebuf extracts more
than 1 character from a 1 byte file
-Original Message-
From: [EMAIL PROTECTED]
Sent: Mon, 19 Feb 2007 13:35:19 -0700
To: stdcxx-dev@incubator.apache.org
Subject: Re: [jira] Commented: (STDCXX-333) std::wfilebuf extracts more
than 1 character from a 1 byte file
Mark Brown (JIRA) wrote:
[
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
This looks like an unrelated problem. Could you open a new issue for it?
Sure. Here it is: https://issues.apache.org/jira/browse/STDCXX-340.
Mark
Thanks
Martin
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 cassert
#include fstream
#include iostream
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
Re: [jira] Commented: (STDCXX-333) std::wfilebuf extracts more than 1 character from a 1 byte file
Martin Sebor wrote:
Mark Brown wrote:
I decided to look into this as an exercise in stdcxx debugging and
managed to figure out how to get around the error and generate the
en_US.UTF-8 locale.
Great! Thanks for the detective work!
The change I made to make it work is in the
attached patch file. Let me know if this is the correct format
for patches or if you prefer something else.
I should have mentioned: when posting patches to the list please
start the subject line with the string [PATCH] to make it stand
out. It's also good to give the email a descriptive title, or
change it to one when following up on an unrelated topic (as in
this case :)
Read the section below for more on how to submit patches:
http://incubator.apache.org/stdcxx/bugs.html#patches
Martin
I don't see the patch. Did you forget to attach it? (Sometimes the
attachments end up getting stripped by ezmlm even though they
shouldn't). If it's small, you might want to paste it directly into
your mail. Otherwise you might need to post it somewhere (e.g., on
your web page or in the issue itself).
Incidentally, the original test program for stdcxx-333 runs fine
on Cygwin with the en_US.UTF-8 locale so the error must be unique
to Linux.
Hmm. Very odd.
Martin
-- Mark
-Original Message-
From: [EMAIL PROTECTED]
Sent: Mon, 19 Feb 2007 12:51:24 -0800
To: stdcxx-dev@incubator.apache.org, stdcxx-dev@incubator.apache.org
Subject: Re: [jira] Commented: (STDCXX-333) std::wfilebuf extracts more
than 1 character from a 1 byte file
-Original Message-
From: [EMAIL PROTECTED]
Sent: Mon, 19 Feb 2007 13:35:19 -0700
To: stdcxx-dev@incubator.apache.org
Subject: Re: [jira] Commented: (STDCXX-333) std::wfilebuf extracts more
than 1 character from a 1 byte file
Mark Brown (JIRA) wrote:
[
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
This looks like an unrelated problem. Could you open a new issue for
it?
Sure. Here it is: https://issues.apache.org/jira/browse/STDCXX-340.
Mark
Thanks
Martin
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 cassert
#include fstream
#include iostream
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
[jira] Commented: (STDCXX-335) std::min() suboptimal
[
https://issues.apache.org/jira/browse/STDCXX-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474290
]
Martin Sebor commented on STDCXX-335:
-
See also this Sun C++ compiler bug for some relevant detail:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6498247
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 algorithm
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), %eaxextra 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] Resolved: (STDCXX-340) [Cygwin] SIGHUP in localedef
[ https://issues.apache.org/jira/browse/STDCXX-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor resolved STDCXX-340. - Resolution: Fixed Fix Version/s: 4.2 Fixed. [Cygwin] SIGHUP in localedef 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 Priority: Critical Fix For: 4.2 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.
