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
: 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
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
ReportedBy: joerg dot richter at pdv-fs dot de
http
--- 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
works
--
joerg dot richter at pdv-fs dot de changed:
What|Removed
--- 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-patches nor
dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41373
--- 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
++
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=36363
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
--- 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
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
++
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 ...]
Can
--- 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/include/Makefile.in
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
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
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
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
--- 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
++
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
--- 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
: 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
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
--- 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/source
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
GCC host triplet: powerpc
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: powerpc-ibm-aix5.2.0.0
GCC target triplet: powerpc-ibm-aix5.2.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21264
: 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
--- 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-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 to test a modified patch
--- 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 C
--- 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 slower than
--- 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 short, we should make sure
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: powerpc-ibm-aix5.2.0.0
GCC target triplet
--- 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
--- 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: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 total runtime?
Doesn't
--- 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
: 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 anonther instance of this problem.
extern
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
45 matches
Mail list logo
