Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla
: normal
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43970
--- Comment #2 from joerg dot richter at pdv-fs dot de 2010-04-29 12:54
---
But throw can be part of ?: operator:
$ cat t.cc
int func( bool b )
{
return b ? 0 : throw 5;
}
$ g++ -c t.cc
--
joerg dot richter at pdv-fs dot de changed:
What|Removed
--
Summary: conditional operator can't convert 0 to pointer
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #5 from joerg dot richter at pdv-fs dot de 2009-09-18 13:47
---
I found Doug Gregors workaround for this pair problem:
http://gcc.gnu.org/ml/libstdc++/2008-10/msg00080.html
I wonder why it was reverted 9 days later? I couldn't find any discussion on
gcc-patche
: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41373
--- Comment #8 from joerg dot richter at pdv-fs dot de 2009-07-15 15:13
---
If you mean that i.e. libgomp.so.1.0.0 and libssp.so.0.0.0 have the same bug.
Than yes. They reference libgcc_s.so.1 without setting RPATH to '$ORIGIN'.
So this issue isn't libstdc++ spec
--- Comment #6 from joerg dot richter at pdv-fs dot de 2009-07-15 13:15
---
I stumpled across the same problem recently.
Executable references both libstdc++.so and libgcc_s.so.
libstdc++.so references libgcc_s.so.
Both executable dependencies will be correctly resolved (due to RPATH
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36372
--- Comment #2 from joerg dot richter at pdv-fs dot de 2008-05-29 12:21
---
Seems I've used gcc on a machine with a newer libc than it was built on.
Sorry for the noise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36368
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36368
gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36363
l
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35398
--- Comment #12 from joerg dot richter at pdv-fs dot de 2007-07-05 11:17
---
Of course, you are right. :)
Just want to confirm, that all "s,g,g," and "s,^,," and "b" seem to work fine
with AIX-sed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
--- Comment #9 from joerg dot richter at pdv-fs dot de 2007-07-05 11:00
---
I think the last g in 's,g,g,g' is the important one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
--- Comment #4 from joerg dot richter at pdv-fs dot de 2007-07-04 19:48
---
Any chance that this gets fixed with 4.2.1? This is the only thing on AIX that
prevents an unpatched bootstrap.
Or perhaps its only missing documentation that GNU sed must be used.
--
http://gcc.gnu.org
--- Comment #3 from joerg dot richter at pdv-fs dot de 2007-06-07 10:03
---
Well,
$ which sed
/usr/bin/sed
$ /usr/bin/sed -e ''
sed: 0602-429 No editing script was provided.
Usage: sed [-n] Script [File ...]
sed [-n] [-e Script] ... [-f Script_file] ... [File ...]
--- Comment #1 from joerg dot richter at pdv-fs dot de 2007-05-30 08:47
---
AIX/sed doesn't allow sed -e ''.
Can't currently attach patches. Here is it inline:
--- libstdc++-v3/include/Makefile.in.old2007-05-30 10:03:19.0
+0200
+++ libstdc++-v3
unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
GCC build triplet: powerpc-ibm-aix5.2.0.0
GCC host triplet: powerpc-ibm-aix5.2.0.0
GCC target triplet: powerpc-ibm-aix5.2.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
ent: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31695
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28093
pile error
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28025
--- Comment #4 from joerg dot richter at pdv-fs dot de 2006-05-31 07:21
---
I can't see the problem with 4.1.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21264
--- Comment #4 from joerg dot richter at pdv-fs dot de 2006-05-30 09:43
---
Before I file a new bug, here is another testcase:
struct Block
{
public:
Block();
~Block();
};
bool func( bool bar )
{
Block block;
bool foo = false;
if( !foo || bar )
do { return true
--- Comment #2 from joerg dot richter at pdv-fs dot de 2006-05-29 08:31
---
I think this is a GCC problem, because this is the header installed by GCC.
Removing the header works, because then /usr/include/assert.h is used. And this
system header works as expected.
--
http
ormal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
GCC host triplet: powerpc-ibm-aix5.2.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27791
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25156
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-06-06
12:33 ---
Whoever has the same problem: -fno-working-directory solves it
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21815
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-05-30
11:41 ---
Well, but I want all generated objects to be the same between our developers.
This makes an extremly good cache hit rate with ccache. We arranged with it
that we don't have the current/s
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21815
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-ibm-aix5.2.0.0
GC
symbol warnings for complex template class
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs
27;t work together
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19753
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-28
07:54 ---
(In reply to comment #26)
> Excellent. Can you please check whether on AIX this is ok ("de_DE" is just
> an example, any actually installed named locale should do):
> [code]
> In
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-27
15:05 ---
With patch draft_19642_3 and count=100
$ time t > /dev/null
real 0,64
user 0,60
sys0,01
$ time t cout > /dev/null
real 1,14
user 1,12
sys0,00
Now its only 2 times slowe
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-27
12:54 ---
I think this runtimes of the different setlocale() calls might be interesting:
(This is for 100 calls)
category locale time
LC_ALL00.70s
LC_NUMERIC00.29s
LC_ALL &q
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-27
12:39 ---
A quick test shows, that std::setlocale(LC_ALL, NULL) returns "C C C C C C".
But std::setlocale(LC_NUMERIC, NULL) returns "C"
I think it is enough to test LC_NUMERIC.
I'll try
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-27
08:08 ---
std::cout.imbue( std::locale( "C" ) );
nor
std::cout.imbue( std::locale::classic() );
nor
export LANG=C
does change anything
Joerg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-26
16:00 ---
If it helps you, here the first lines of prof. But in practice some backtraces
help me a lot more than a a [g]prof output. Its very fast in finding big
bottlenecks, like setlocale in this PR.
count
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-26
15:41 ---
> ;) No, I mean *relative* percentages: setlocal in your profile is on top,
higher
> than __convert_from_v and everything else. I'm asking: is consuming 1%, 10%,
or
> 99% of the
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-26
15:18 ---
Ok, lets say I took 100 backtraces and got 99 times this one. I hope this is
enough percentage.
_GLIBCXX_USE_C99 is defined
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-26
15:00 ---
I took some backtraces during a longer run of the program and most of the time
it looked like this: (I removed some templates to make it readable)
__issetuid
load_locale
setlocale
int std
tus: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-ibm-aix5.2.0.0
GCC host triplet
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18976
--- Additional Comments From joerg dot richter at pdv-fs dot de 2004-11-03 08:20
---
In a recent discussion on comp.lang.c++.moderated was this example to give
bar "C++" linkage and foo "C" linkage. But g++ gives them both "C" linkage. It
might be ano
portedBy: joerg dot richter at pdv-fs dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17947
46 matches
Mail list logo
