[Bug c++/17969] New: template inline functions not getting optimized
System: Linux columbia 2.4.21-4.EL #1 Fri Oct 3 18:13:58 EDT 2003 i686 i686 i386
GNU/Linux
Architecture: i686
$ gcc -v
Reading specs from /home/pkpras/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.2/specs
Configured with: ./configure --prefix=/home/pkpras/usr/local
Thread model: posix
gcc version 3.4.2
Below I am just showing the contents of two C++ files. I will be attaching *.i*
files later.
$ cat s1.cpp
#include functional
template typename Op
inline bool ff(Op op, int x)
{
return op(x);
}
int f(int x)
{
if (ff(std::bind2nd(std::equal_toint(), 10), x))
return 0;
else
return 1;
}
$ cat s2.cpp
int f(int x)
{
if (x == 10)
return 0;
else
return 1;
}
The command line used for compiling the two files are as follows:
$ gcc -S -O3 s1.cpp
$ gcc -S -O3 s2.cpp
The file s1.s has more code than s2.s. Below is the diff:
$ diff s1.s s2.s
1c1
.file s1.cpp
---
.file s2.cpp
8,9c8
.LFB86:
.L3:
---
.LFB2:
11a11
xorl%eax, %eax
14,23c14,15
subl$16, %esp
.LCFI2:
movl$10, -4(%ebp)
movl-8(%ebp), %eax
movl-4(%ebp), %ecx
movl8(%ebp), %edx
movl%eax, -16(%ebp)
movl%ecx, -12(%ebp)
cmpl-12(%ebp), %edx
leave
---
cmpl$10, 8(%ebp)
popl%ebp
25d16
movzbl %al, %eax
27c18
.LFE86:
---
.LFE2:
It seems that bind2nd is not getting optimized adequately.
--
Summary: template inline functions not getting optimized
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pkprasoon at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17969
[Bug c++/17969] template inline functions not getting optimized
--- Additional Comments From pkprasoon at gmail dot com 2004-10-13 06:14 --- Created an attachment (id=7333) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7333action=view) file corresponding to s1.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17969
[Bug c++/17969] template inline functions not getting optimized
--- Additional Comments From pkprasoon at gmail dot com 2004-10-13 06:15 --- Created an attachment (id=7334) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7334action=view) file correspoding to s2.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17969
[Bug target/14678] m68hc11-elf-gcc ICE
--- Additional Comments From namsh at kldp dot org 2004-10-13 06:48 --- It seems this bug was fixed. Today, I made the m6811-elf-gcc from CVS. $ m6811-elf-gcc --version m6811-elf-gcc (GCC) 3.4.3 20041013 (prerelease) ... No more ICE. I didn't use m6811-elf-gcc recently. The previous version I had is 3.4.1 20040607. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14678
[Bug bootstrap/6728] compilation of gcc 3.1 fails - msgfmt
--- Additional Comments From d dot yu dot bolkhovityanov at inp dot nsk dot su 2004-10-13 06:53 --- I've encountered the very same problem when trying to compile gcc-3.4 on RedHat-7.3. The key to the problem is more obvious in Joseph's report than it was in my case: /usr/openwin/bin/msgfmt -- OPENWIN!!! My system has xview-clients RPM installed, which, among other things, contains msgfmt binary, which is INCOMPATIBLE with regular msgfmt from gettext package. The solution for a builder is to either exclude /usr/openwin/bin from the $PATH, or to add it to the *end* of $PATH. As for GCC compilation system -- it can be worth testing in configure which kind of msgfmt is available, or to find where the good one is located. Should the bug be reopened? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6728
[Bug c++/17944] ICE Segmentation fault
--- Additional Comments From micis at gmx dot de 2004-10-13 07:15 --- I can't reproduce the original ICE (internal compiler error: in cp_tree_equal). The segfault occurs still with the (incomplete) set of source files in my attachment. There is no difference between an unpatched and a patched version of the compiler. Has anybody reproduced this segfault? Michael Cieslinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17944
[Bug tree-optimization/17724] [4.0 Regression] wrong dominator (eh/fold all builtins) related
--- Additional Comments From micis at gmx dot de 2004-10-13 07:22 --- The ICE is not related to this patch. Michael Cieslinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17724
[Bug debug/17406] [4.0 regression] ICE dwarf2out_frame_debug_expr, at dwarf2out.c:1692
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-13 07:27 --- Sorry for the delay. My bootstrap kept breaking, and the full cycle appears to take about 48 hours to complete. I can preliminarily say that this patch does indeed appear to fix this problem, but I have not yet completed regression testing. I will report back when it is done (sometime before the next ice age). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17406
[Bug preprocessor/17970] New: Preprocessor seems not to create newlines for all # linenumber debug stmts in nested macros
This report applies (at least) to these:
g++ (GCC) 3.3.5 (Debian 1:3.3.5-1)
g++-3.4 (GCC) 3.4.2 (Debian 3.4.2-2)
code fragment (from expanded code, censored to protect the innocent):
#line 54
CQ_DEBUG(5, xxx: *v (@
#line 54
v.get() ));
#line 54
The contents of CQ_DEBUG are not interesting, and it's valid (fairly small)
macro. However, the output of preprocessing is strange:
# 54 XXX.cpp
do { if (cq_debug_enabled(5, debug_module_name, debug_file_name, 54)) {
ostringstream temp;
temp xxx: *v (@ v.get() ); temp '\0';
cq_debug_output(5, debug_module_name, cq_debug_clean_file_name(debug_file_name),
54, temp.str().c_str()); }
} while(0);# 54 XXX.cpp
I hope this cut-n-paste did not screw it up, but basically there's missing
newline from the transformed #line precompiler output (# 54 ..).
Strange thing is, this happens only when doing preprocessing-only (g++ -E). If I
run whole g++ -c foo.cpp -o foo.o, things work beautifully.
Note that this works correctly if I change the macro to one line:
#line 54
CQ_DEBUG(5, xxx: *v (@ v.get() ));
#line 54
Because #lines within macros are bit questionable to start with, I'm not quite
sure if this is a bug, but because it works with normal 'g++', I should say it
should work with 'g++ -E' too..?
I did not have the time (work, work).. to actually test with latest snapshot,
sorry (and apparently Debian's latest is 2 months old so I didn't bother).
--
Summary: Preprocessor seems not to create newlines for all #
linenumber debug stmts in nested macros
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fingon at iki dot fi
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: linux-x86-debian-unstable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17970
[Bug preprocessor/17944] [3.4/4.0 regression] ICE with pragma once
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-13 09:16 --- Here's a reduced testcase which consists of three files: PR17944.c: #include include/bug1.h #include include/bug2.h include/bug1.h: #pragma once #include bug1.h include/bug2.h: #include bug1.h Compiling this with gcc -c PR17944.c I get a segfault since gcc 3.4.0. With gcc 2.95.3 - 3.3.5 I just get a warning: In file included from PR17944.c:1: include/bug1.h:1:9: warning: #pragma once is obsolete -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c++ |preprocessor Ever Confirmed||1 GCC build triplet|powerpc-unknown-linux-gnu | GCC host triplet|powerpc-unknown-linux-gnu | GCC target triplet|powerpc-unknown-linux-gnu | Keywords||ice-on-valid-code Known to fail||3.4.0 3.4.2 4.0.0 Known to work||3.3.5 Last reconfirmed|-00-00 00:00:00 |2004-10-13 09:16:09 date|| Summary|ICE Segmentation fault |[3.4/4.0 regression] ICE ||with pragma once Target Milestone|--- |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17944
[Bug c++/17971] New: [3.4/4.0 regression] Invalid default parameter not diagnosed.
Since PR 16929 got a little confusing, I'm opening a new PR for the
following problem:
Since gcc 3.4.0 we accept the following invalid code snippet. The invalid
default parameter a is not even diagnosed at instantiation time.
(This is different from PT 17011 - also a spin-off from PR16929 -
which is just a QoI issue.)
===
templatetypename struct A {};
templatetypename T struct B
{
AT a;
void foo(AT = a);
};
template struct Bint;
===
With 3.3.5 and before we got a decent error message:
bug.cc:7: error: invalid use of member `BT::a'
--
Summary: [3.4/4.0 regression] Invalid default parameter not
diagnosed.
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,mark at codesourcery dot
com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17971
[Bug c++/16929] [3.4/4.0 Regression] ICE on taking address of member in default parameter to member function
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-13 09:43 --- Well, the QoI issue was not the only thing left in this PR. The testcase in comment #8 shows an accepts-invalid bug that is not just an QoI issue. However, since this PR really is a little confusing now, I opened a new PR for that issue, namely PR17971. -- What|Removed |Added Keywords|accepts-invalid | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16929
[Bug c/17968] assigning variable of type size_t to a variable of type int - warning needs to be flagged.
--- Additional Comments From jsm at polyomino dot org dot uk 2004-10-13 10:15 --- Subject: Re: New: assigning size_t to int - warning needs to be flagged . On Wed, 13 Oct 2004, kaykaylance at yahoo dot com wrote: When compiling this code fragment, I am essentially assigning a size_t value to an int (implicitly ). So it would be nice if the compiler flags a warning there, indicating there is possible loss of data or an overflow error or a similar appropriate warning message. This looks like much the same warning request as bug 2707; see also bug 9072. There was a volunteer working on this http://gcc.gnu.org/ml/gcc/2004-06/msg01377.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17968
[Bug c++/14950] [3.4 Regression] [non unit-at-a-time] always_inline does not mix with templates and -O0
--- Additional Comments From veksler at il dot ibm dot com 2004-10-13 11:23 --- I can still reproduce on 3.4.2 with the original test case, using g++ -g -c t.cpp. There is a proposal in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14950#c5 to stop support for always_inline + no-unit-at-a-time. But it is only a proposal - no conscious decision was taken or documented. -- What|Removed |Added Status|RESOLVED|REOPENED Known to fail|3.4.0 |3.4.2 Known to work|4.0 3.3.3 |4.0.0 3.3.3 Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14950
[Bug bootstrap/6728] Add a configure test for msgfmt (it could be openwin's, not gettext's)
--- Additional Comments From giovannibajo at libero dot it 2004-10-13 11:24 --- Makes sense. Let's keep this open. -- What|Removed |Added Severity|normal |enhancement Status|RESOLVED|REOPENED Keywords||build Known to fail||3.1 3.4.2 Resolution|FIXED | Summary|compilation of gcc 3.1 fails|Add a configure test for |- msgfmt|msgfmt (it could be ||openwin's, not gettext's) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6728
[Bug tree-optimization/17724] [4.0 Regression] wrong dominator (eh/fold all builtins) related
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-13 11:27 --- Subject: Bug 17724 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-13 11:27:02 Modified files: gcc: ChangeLog tree-cfg.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/opt: pr17724-1.C pr17724-2.C pr17724-3.C pr17724-4.C pr17724-5.C pr17724-6.C Log message: PR tree-optimization/17724 * tree-cfg.c (tree_purge_dead_eh_edges): Free dominance info. * g++.dg/opt/pr17724-1.C: New test. * g++.dg/opt/pr17724-2.C: New test. * g++.dg/opt/pr17724-3.C: New test. * g++.dg/opt/pr17724-4.C: New test. * g++.dg/opt/pr17724-5.C: New test. * g++.dg/opt/pr17724-6.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.5856r2=2.5857 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gccr1=2.74r2=2.75 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4440r2=1.4441 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr17724-1.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr17724-2.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr17724-3.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr17724-4.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr17724-5.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr17724-6.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17724
[Bug preprocessor/17944] [3.4/4.0 regression] ICE with pragma once
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 11:31 --- *** This bug has been marked as a duplicate of 15167 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17944
[Bug preprocessor/15167] [3.4/4.0 Regression] Internal compiler error with #pragma once
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 11:31 --- *** Bug 17944 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||micis at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15167
[Bug c++/14950] [3.4 Regression] [non unit-at-a-time] always_inline does not mix with templates and -O0
-- What|Removed |Added Severity|normal |minor Target Milestone|3.4.1 |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14950
[Bug c++/17969] template inline functions not getting optimized
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 11:38 --- Fixed on the mainline: xori r3,r3,10 subfic r0,r3,0 adde r3,r0,r3 xori r3,r3,1 blr -- What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Keywords||missed-optimization Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17969
[Bug preprocessor/17970] Preprocessor seems not to create newlines for all # linenumber debug stmts in nested macros
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 11:43 --- Not a bug at all, preprocessor directives in a macro invocation is undefined. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17970
[Bug c/2707] gcc does not warn on truncate
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 11:44 --- *** Bug 17968 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||kaykaylance at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2707
[Bug target/14678] m68hc11-elf-gcc ICE
--- Additional Comments From giovannibajo at libero dot it 2004-10-13 11:56 --- Closing as fixed in 3.4.3, then. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14678
[Bug tree-optimization/17966] a quadratic behavior in thread_jumps
--- Additional Comments From giovannibajo at libero dot it 2004-10-13 11:58 --- Is this a regression? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
[Bug target/14595] make profiledbootstrap fails on MinGW/MSYS *after* applying PR14291 patch
--- Additional Comments From giovannibajo at libero dot it 2004-10-13 12:00 --- Stephan, can you check if this is still actual? Also, can you check what the error means? Is stage1/xgcc.exe really executable or not? -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14595
[Bug bootstrap/14614] Double target prefixed gcjh
--- Additional Comments From giovannibajo at libero dot it 2004-10-13 12:03 --- Confirmed. Eric, do you happen to know when this bug first appeared? Did you build other older compilers which did not have this problem? Tom, are you going to submit this patch then? -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||3.4.0 4.0.0 Last reconfirmed|-00-00 00:00:00 |2004-10-13 12:03:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14614
[Bug tree-optimization/17966] a quadratic behavior in thread_jumps
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-13 12:11 --- In this particular testcase, going through BBs in backwards does help by cutting down the running time by about half, but I wonder if we can create an identical testcase except that the order of BBs are reversed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
[Bug tree-optimization/17966] a quadratic behavior in thread_jumps
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 12:17 --- No this is not a regression (unless someone can find a testcase which says it is and I cannot find a testcase). See PR 17967 for a testcase which is a regression but thread_jumps has nothing to do it though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
[Bug tree-optimization/17966] a quadratic behavior in thread_jumps
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 12:19 --- I also cannot think of a testcase where we have the reverse BB but it could happen. Really we should processoring by post-dom order which gives us the correct way to do this transformation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
[Bug c++/17971] [3.4/4.0 regression] Invalid default parameter not diagnosed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 12:22 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-10-13 12:22:03 date|| Target Milestone|--- |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17971
[Bug tree-optimization/17724] [4.0 Regression] wrong dominator (eh/fold all builtins) related
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 12:22 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17724
[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)
-- What|Removed |Added Summary|[4.0 Regression] Expand is |[4.0 Regression] Expand is |considered slower? (or is it|considered slower? |because gimplifier |(remove_useless_stmts is |considered part of expand) |considered part of expand) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967
[Bug tree-optimization/17966] a quadratic behavior in thread_jumps
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-13 12:35 ---
Andrew, I did it in the hard way. :-)
void
foo (int a)
{
int b;
goto b1;
b4: return;
b3: if (a) { b = a; return; } else goto b4;
b2: if (a) { b = a; return; } else goto b3;
b1: if (a) { b = a; return; } else goto b2;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
[Bug c++/12625] bitfields which have sizes that are powers of 8 missed by -Wparentheses
-- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12625
[Bug c++/17972] New: const/pure functions result in bad asm
Snippet of shell session demonstrates how compiler generates bad asm (compare
to result of compilation without -DBUG). Toolchain built using latest
crosstool scripts.
Sample code attached below.
[EMAIL PROTECTED]:~/tools.k42/powerpc/partDeb/os$ powerpc64-linux-g++-c -o
workqueue.o wq.C -O1 -DBUG
[EMAIL PROTECTED]:~/tools.k42/powerpc/partDeb/os$ powerpc64-linux-objdump -d
workqueue.o
workqueue.o: file format elf64-powerpc
Disassembly of section .text:
._Z10queue_workP16workqueue_structP11work_struct:
0: 7c 08 02 a6 mflrr0
4: f8 01 00 10 std r0,16(r1)
8: f8 21 ff 91 stdur1,-112(r1)
c: 7d a9 6b 78 mr r9,r13
10: e9 29 00 00 ld r9,0(r9)
14: 88 09 00 03 lbz r0,3(r9)
18: 2f a0 00 00 cmpdi cr7,r0,0
1c: 40 be 00 10 bne+cr7,2c
._Z10queue_workP16workqueue_structP11work_struct+0x2c
20: 48 00 00 01 bl 20
._Z10queue_workP16workqueue_structP11work_struct+0x20
24: 60 00 00 00 nop
28: 48 00 00 00 b 28
._Z10queue_workP16workqueue_structP11work_struct+0x28
2c: 48 00 00 00 b 2c
._Z10queue_workP16workqueue_structP11work_struct+0x2c
30: 00 00 00 00 .long 0x0
34: 00 09 00 01 .long 0x90001
38: 80 00 00 00 lwz r0,0(0)
[EMAIL PROTECTED]:~/tools.k42/powerpc/partDeb/os$ powerpc64-linux-g++ -v
Reading specs from
/opt/crosstool/powerpc64-linux/gcc-3.4.2-glibc-2.3.3/lib/gcc/powerpc64-linux/3.4.2/specs
Configured with:
/home/mostrows/tools/crosstool-0.28-rc37/build/powerpc64-linux/gcc-3.4.2-glibc-2.3.3/gcc-3.4.2/configure
--target=powerpc64-linux --host=powerpc64-host_unknown-linux-gnu
--prefix=/opt/crosstool/powerpc64-linux/gcc-3.4.2-glibc-2.3.3 --disable-multilib
--with-sysroot=/opt/crosstool/powerpc64-linux/gcc-3.4.2-glibc-2.3.3/powerpc64-linux/sys-root
--with-local-prefix=/opt/crosstool/powerpc64-linux/gcc-3.4.2-glibc-2.3.3/powerpc64-linux/sys-root
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long
Thread model: posix
gcc version 3.4.2
struct LinuxVPInfo_s {
unsigned long physProc;
};
typedef struct LinuxVPInfo_s LinuxVPInfo;
extern LinuxVPInfo linuxVPInfo;
struct cpu_workqueue_struct {
int x;
};
struct workqueue_struct {
struct cpu_workqueue_struct cpu_wq[32];
};
struct work_struct {
unsigned long pending;
void (*func)(void *);
void *data;
void *wq_data;
};
extern void __k42_spin_lock_irqsave(struct cpu_workqueue_struct* c,
unsigned long *x);
struct thread_info {
int preempt_count;
};
extern int test_and_set_bit(int x, unsigned long *y);
#ifdef BUG
static inline struct thread_info *current_thread_info(void)
__attribute__((const));
static int smp_processor_id(void) __attribute__((pure));
#else
static int smp_processor_id(void);
static inline struct thread_info *current_thread_info(void);
#endif
static __inline__ int smp_processor_id(void) {
return linuxVPInfo.physProc;
}
static inline struct thread_info *current_thread_info(void)
{
struct thread_info **ti;
__asm__(mr %0,13 : =r(ti));
return *ti;
}
#define cti current_thread_info
extern void lkBreakpoint(int line, const char* file, const char* fn);
extern void __k42disable_preempt();
extern void __k42enable_preempt();
int queue_work(struct workqueue_struct *wq, struct work_struct *work)
{
unsigned long flags;
int ret = 0;
int cpu = ({ do {
do {
if (((cti()-preempt_count) (((1UL (8))-1) 0))==0) {
__k42disable_preempt();
(cti()-preempt_count)++;
} else
(cti()-preempt_count)++;
} while (0);
__asm__ __volatile__(: : :memory);
} while (0);
smp_processor_id();
});
struct cpu_workqueue_struct *cwq = wq-cpu_wq + cpu;
if (!test_and_set_bit(0, work-pending)) {
do {
if ((!work-wq_data)) {
lkBreakpoint(103,workqueue.C,(__func__));
}
} while (0);
work-wq_data = cwq;
__k42_spin_lock_irqsave(cwq, flags);
ret = 1;
}
do {
do {
__asm__ __volatile__(: : :memory);
do {
if (((cti()-preempt_count) (((1UL (8))-1) 0))==1) {
(cti()-preempt_count)--;
__k42enable_preempt();
} else
(cti()-preempt_count)--;
} while (0);
} while (0);
} while (0);
return ret;
}
--
Summary: const/pure functions result in bad asm
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mostrows at watson dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
[Bug c++/17971] [3.4/4.0 regression] Invalid default parameter not diagnosed.
--- Additional Comments From bangerth at dealii dot org 2004-10-13 12:50 ---
I'm not sure this is a bug: the standard quite unmistakably says that
default arguments aren't evaluated unless used. Now, if I try to
use the default argument in your testcase, like so
--
templatetypename struct A {};
templatetypename T struct B
{
AT a;
void foo(AT = a);
};
void bar ()
{
Bint().foo();
}
--
then I do get a sensible error:
g/x /home/bangerth/bin/gcc-4.0-pre/bin/c++ -c x.cc
x.cc:5: error: invalid use of non-static data member `Bint::a'
x.cc:12: error: from this location
Can you say why the compiler should diagnose this earlier rather than
later, given what the standard says?
For reference:
14.7.2/9 says
An explicit instantiation does not constitute a use of a default
argument, so default argument instantiation is not done. [Example:
char* p = 0;
templateclass T T g(T = p);
template int gint(int); // OK even though p isn't an int.
--end example]
and there are more places like this.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17971
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- Additional Comments From giovannibajo at libero dot it 2004-10-13 12:51 --- Daniel, since you have access to the system, would you kindly attempt preparing a fixinclude patch yourself? I guess it's easier for you to verify. If this is impossible for you, please at least attacch a copy of the buggy if.h to this report. Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
-- What|Removed |Added CC||giovannibajo at libero dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
[Bug middle-end/17973] New: tree dumps are cluttered and mixed with RTL dumps
Reported here: http://gcc.gnu.org/ml/gcc/2004-09/msg00764.html Currently, the dump list looks like: t.c.t00.expandt.c.t12.eh t.c.t22.lreg t.c.t32.redphi2 t.c.t45.lim t.c.t01.cgrapht.c.t13.cfg t.c.t23.forwprop1t.c.t32.sched2 t.c.t51.ivopts t.c.t01.sibling t.c.t13.loop2t.c.t23.greg t.c.t33.dce3 t.c.t52.loopdone t.c.t02.original t.c.t14.oplower t.c.t24.phiopt1 t.c.t33.stack t.c.t53.dom3 t.c.t03.generic t.c.t14.web t.c.t24.postreload t.c.t34.dse1 t.c.t54.redphi4 t.c.t03.jump t.c.t15.cse2 t.c.t25.alias2 t.c.t34.vartrack t.c.t55.cddce t.c.t04.cse t.c.t16.life t.c.t26.flow2t.c.t35.alias3 t.c.t56.dse2 t.c.t05.gcse t.c.t16.ssa t.c.t26.tailrt.c.t35.mach t.c.t57.forwprop3 t.c.t06.loop t.c.t17.alias1 t.c.t27.ch t.c.t36.forwprop2 t.c.t58.phiopt3 t.c.t06.vcg t.c.t17.combine t.c.t27.peephole2t.c.t37.phiopt2 t.c.t59.tailc t.c.t07.bypasst.c.t18.ce2 t.c.t28.ce3 t.c.t38.ccp t.c.t60.optimized t.c.t08.cfg t.c.t18.copyrename1 t.c.t28.profile t.c.t39.redphi3 t.c.t61.nrv t.c.t08.gimplet.c.t19.dce1 t.c.t29.rnregt.c.t40.fab t.c.t62.vars t.c.t09.bpt.c.t19.regmove t.c.t29.sra t.c.t41.crited t.c.t09.useless t.c.t20.dom1 t.c.t30.bbro t.c.t42.pre t.c.t11.ce1 t.c.t21.redphi1 t.c.t30.copyrename2 t.c.t43.loop t.c.t11.lower t.c.t22.dce2 t.c.t31.dom2 t.c.t44.loopinit RTL and tree dumps should be separated. RTL dumps used to be t.c.NN.pass. We can have .rNN.pass if we want now, but surely not .tNN.pass like tree dumps. -- Summary: tree dumps are cluttered and mixed with RTL dumps Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: giovannibajo at libero dot it CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17973
[Bug middle-end/17973] [4.0 Regression] tree dumps are cluttered and mixed with RTL dumps
--- Additional Comments From giovannibajo at libero dot it 2004-10-13 13:25 --- Paolo, this happened since your patch to unify RTL and tree dump infrastructure. Would you kindly have a look at this as quickly as possible? Many developers complained about the current state of affairs. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-10-13 13:25:42 date|| Summary|tree dumps are cluttered and|[4.0 Regression] tree dumps |mixed with RTL dumps|are cluttered and mixed with ||RTL dumps Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17973
[Bug tree-optimization/17966] a quadratic behavior in thread_jumps
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 13:26 --- I can get this down to (with a compiler at -O0): tree CFG cleanup : 6.30 ( 6%) usr 0.02 ( 1%) sys 13.51 (10%) wall I will submit a patch once I test it more on some other sources. But I will attach it here if I don't get around to it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
[Bug middle-end/17965] ice in expand_call
--- Additional Comments From bangerth at dealii dot org 2004-10-13 13:29 --- I still can't reproduce with a snapshot from an hour ago. This is my command line: /home/bangerth/bin/gcc-4.0-pre/bin/c++ -mtune=k8 -c x.cc -O2 W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17965
[Bug tree-optimization/17966] a quadratic behavior in thread_jumps
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-13 13:29 --- I should note that I used -O2 when I came up with 44% in the initial description of this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
[Bug middle-end/10138] -Wuninitialized could catch uninitialized arrays
-- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138
[Bug middle-end/17973] [4.0 Regression] tree dumps are cluttered and mixed with RTL dumps
--- Additional Comments From bonzini at gcc dot gnu dot org 2004-10-13 13:39 --- It only happens with -fdump-tree-all-all, which currently segfaults for me independently of this bug. Anyway thanks for reminding me. Will attach a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17973
[Bug c++/14140] Unwanted call to derived constructor after implicit conversion
-- What|Removed |Added Status|REOPENED|NEW Known to fail|3.3.3 3.2.3 3.4.0 4.0 |3.3.3 3.2.3 3.4.0 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14140
[Bug middle-end/192] String literals don't obey -fdata-sections
-- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
[Bug middle-end/15486] [3.3/3.4/4.0 regression] -fdata-sections moves common vars to .bss
-- What|Removed |Added Status|REOPENED|NEW Known to fail|3.3.4 3.4.1 4.0 |3.3.4 3.4.1 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15486
[Bug tree-optimization/17955] Perform associative optimization when it is safe
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 13:43 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2004-10-13 13:43:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17955
[Bug c++/14667] [4.0 Regression] ICE in cp_parser_parse_and_diagnose_invalid_type_name
-- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14667
[Bug bootstrap/14614] Double target prefixed gcjh
--- Additional Comments From ericw at evcohs dot com 2004-10-13 13:45 --- Subject: Re: Double target prefixed gcjh On 13 Oct 2004 at 12:03, giovannibajo at libero dot it wrote: --- Additional Comments From giovannibajo at libero dot it 2004-10-13 12:03 --- Confirmed. Eric, do you happen to know when this bug first appeared? Did you build other older compilers which did not have this problem? Unfortunately no, I do not know when this bug first appeared. Only in the last week did I first try to build java for the avr target, and to my knowledge it's the first time anybody has tried it. You can see some messages about this on the java list. And, no, I did not build it with older compilers. I can't speak for the original reporter of this bug though. Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14614
[Bug target/14454] [3.3/3.4/4.0 Regression] virtual function with vararg won't compile
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-13 14:04 --- Subject: Bug 14454 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-13 14:04:33 Modified files: gcc: ChangeLog gcc/config/sparc: sparc.c sparc.md gcc/testsuite : ChangeLog gcc/testsuite/g++.dg/inherit: thunk1.C Log message: PR target/14454 * config/sparc/sparc.c (TARGET_ASM_CAN_OUTPUT_MI_THUNK): Set to sparc_can_output_mi_thunk. (sparc_output_mi_thunk): Simplify handling of delta offset. Add handling of vcall offset. (sparc_can_output_mi_thunk): New predicate. * doc/tm.texi (TARGET_ASM_OUTPUT_MI_THUNK): Document VCALL_OFFSET. (TARGET_ASM_OUTPUT_MI_VCALL_THUNK): Delete. (TARGET_ASM_CAN_OUTPUT_MI_THUNK): New target hook. * config/sparc/sparc.c (emit_and_preserve): Preserve stack alignment. * config/sparc/sparc.md (movdi): Remove redundant test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.5860r2=2.5861 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.c.diff?cvsroot=gccr1=1.338r2=1.339 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.md.diff?cvsroot=gccr1=1.217r2=1.218 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4441r2=1.4442 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/thunk1.C.diff?cvsroot=gccr1=1.5r2=1.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14454
[Bug target/14454] [3.3/3.4/4.0 Regression] virtual function with vararg won't compile
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-13 14:16 --- Subject: Bug 14454 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-10-13 14:16:36 Modified files: gcc: ChangeLog gcc/config/sparc: sparc.c sparc.md gcc/doc: tm.texi gcc/testsuite : ChangeLog gcc/testsuite/g++.dg/inherit: thunk1.C Log message: PR target/14454 * config/sparc/sparc.c (TARGET_ASM_CAN_OUTPUT_MI_THUNK): Set to sparc_can_output_mi_thunk. (sparc_output_mi_thunk): Simplify handling of delta offset. Add handling of vcall offset. (sparc_can_output_mi_thunk): New predicate. * doc/tm.texi (TARGET_ASM_OUTPUT_MI_THUNK): Document VCALL_OFFSET. (TARGET_ASM_OUTPUT_MI_VCALL_THUNK): Delete. (TARGET_ASM_CAN_OUTPUT_MI_THUNK): New target hook. * config/sparc/sparc.md (movdi): Remove redundant test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.654r2=2.2326.2.655 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.271.4.21r2=1.271.4.22 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.md.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.196.2.5r2=1.196.2.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/tm.texi.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.281.2.18r2=1.281.2.19 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.285r2=1.3389.2.286 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/thunk1.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.5r2=1.5.40.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14454
[Bug c++/14140] [3.3/3.4/4.0 Regression] Unwanted call to derived constructor after implicit conversion
--- Additional Comments From giovannibajo at libero dot it 2004-10-13 14:21
---
Slightly cleaned-up testcase:
--
extern C int printf(const char* fmt, ...);
extern C void abort(void);
struct A {
A() {}
A(const A) { printf(A cctor\n); }
};
struct B : public A {
B() {}
B(const B) { printf(B cctor\n); abort(); }
};
struct Wrapper
{
B* b;
Wrapper(B* b_) : b(b_) {}
B operator*() const {return *b;}
operator B() const {return **this;}
};
void func(A a) {} // Takes the parameter by value
int main()
{
B b;
Wrapper b_wrap(b);
printf(\nCalling 'func(b)':\n);
func(b);
printf(\nCalling 'func(*b_wrap)':\n);
func(*b_wrap);
printf(\nCalling 'func(b_wrap)':\n);
func(b_wrap);
return 0;
}
--
In short, this should not abort, and does not with ICC, Comeau, or MSVC. This
is a regression since 2.95 appeared with 3.0.
--
What|Removed |Added
Severity|normal |critical
Known to fail|3.3.3 3.2.3 3.4.0 4.0.0 |3.0.4 3.3.3 3.2.3 3.4.0
||4.0.0
Known to work||2.95.3
Summary|Unwanted call to derived|[3.3/3.4/4.0 Regression]
|constructor after implicit |Unwanted call to derived
|conversion |constructor after implicit
||conversion
Target Milestone|--- |3.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14140
[Bug tree-optimization/17966] a quadratic behavior in thread_jumps
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-13 14:24 --- Andrew, Regarding your patch, if we have exactly one basic block immediately preceding EXIT_BLOCK_PTR, and that block happens to be a forwarder block, your algorithm terminates without doing any further work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
[Bug c++/14140] [3.3/3.4/4.0 Regression] Unwanted call to derived constructor after implicit conversion
--- Additional Comments From giovannibajo at libero dot it 2004-10-13 14:25 --- The original thread (with some C++ standard reference) is here: http://tinyurl.com/5smcv -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14140
[Bug target/14454] [3.3/3.4/4.0 Regression] virtual function with vararg won't compile
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-13 14:28 --- Gaby, I don't intend to put the fix on the 3.3 branch at this point. However the bug is rated as a critical regression there too, so you might want to overrule me. -- What|Removed |Added CC||gdr at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14454
[Bug target/14454] [3.3/3.4/4.0 Regression] virtual function with vararg won't compile
--- Additional Comments From giovannibajo at libero dot it 2004-10-13 14:36 --- Notice that the original bugreport is against 3.3.2 though, which means that the user really hit this problem on the 3.3 branch. And moving to 3.4 is non- trivial for much C++ code due to the new parser. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14454
[Bug bootstrap/14614] Double target prefixed gcjh
--- Additional Comments From ralf_corsepius at rtems dot org 2004-10-13 14:41 --- (In reply to comment #7) Eric, do you happen to know when this bug first appeared? I noticed it for the first time shortly before submitting this PR (Opened: 2004-03-17; cf. above;). I don't recall the corresponding gcc-release off hand but notes in my build-scripts indicate this bug to have appeared before gcc-3.4.0. As gcj doesn't build for most of my usual targets (embedded *rtems cross-toolchiains) due to lack of the infrastructure it requires, I have disabled building gcj since then and can't tell if this issue has re-appeared or if had been persistent since then. I can't speak for the original reporter of this bug though. I am the original reporter ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14614
[Bug target/14454] [3.3 Regression] virtual function with vararg won't compile
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 14:42 --- I would disagree with Giovanni's statement about moving to 3.4 being hard, yes it is a pain but it would be the correct thing to do for most code anyways but I will leave this up to GDR to decide to let this patch go in or not. -- What|Removed |Added Known to fail|3.4.1 4.0.0 |3.4.1 3.4.2 Known to work|2.95.3 |2.95.3 4.0.0 3.4.3 Summary|[3.3/3.4/4.0 Regression]|[3.3 Regression] virtual |virtual function with vararg|function with vararg won't |won't compile |compile Target Milestone|3.4.3 |3.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14454
[Bug tree-optimization/17966] a quadratic behavior in thread_jumps
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 14:44 --- Woops I have a fix for that and plus I also fixed an ICE I saw. I will attach a new patch soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
[Bug target/14454] [3.3 Regression] virtual function with vararg won't compile
-- What|Removed |Added Target Milestone|3.3.5 |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14454
[Bug c++/10200] Weird clash with same names in different scopes
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-10-13 14:50 --- It's parser bug. Not working on it anymore. -- What|Removed |Added AssignedTo|lerdsuwa at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200
[Bug rtl-optimization/17972] const/pure functions result in bad asm
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 14:51 --- What do you think is wrong, attach the difference. Also const/pure functions can changed so that they are only called once. And since they are pure (or is it const) is known not to access memory, the barrier: __asm__ __volatile__(: : :memory); does not make a difference. -- What|Removed |Added Component|c++ |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug c++/14140] [3.3/3.4/4.0 Regression] Unwanted call to derived constructor after implicit conversion
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 14:59 --- Then this is a dup of bug 14035. *** This bug has been marked as a duplicate of 14035 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14140
[Bug c++/14035] Compiler generates spurious temporary
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 14:59 --- *** Bug 14140 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||christian dot engstrom at ||glindra dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14035
[Bug c++/14035] [3.3/3.4/4.0 Regression] Compiler generates spurious temporary
-- What|Removed |Added Known to fail||3.4.0 4.0.0 Known to work||2.95.3 Summary|Compiler generates spurious |[3.3/3.4/4.0 Regression] |temporary |Compiler generates spurious ||temporary Target Milestone|--- |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14035
[Bug c++/13830] Invalid covariant type for identical type, friend related
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-10-13 15:17 --- Working on friend injection issues. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lerdsuwa at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13830
[Bug c++/15453] Friend declaration treated as a declaration in scope.
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-10-13 15:21 --- Working on friend injection issues. -- What|Removed |Added CC|lerdsuwa at gcc dot gnu dot | |org | AssignedTo|unassigned at gcc dot gnu |lerdsuwa at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Known to fail|2.95.3 3.0.4 3.2.3 3.3.3|2.95.3 3.0.4 3.2.3 3.3.3 |3.4.0 4.0 |3.4.0 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15453
[Bug tree-optimization/17966] a quadratic behavior in thread_jumps
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-13 15:38 --- Andrew, Your algorithm would still present a quadratic behavior in the following situation. bb0- a block with COND_EXPR only | \ | \ | bb1 - a block with COND_EXPR only | | \ | | \ | | bb2 - empty | | / | | / | bb3 - empty | / bb4- a block with RETURN_EXPR only First, note that the whole thing should collapse down to a single basic block as there is no interesting statement. Let's assume that the orientation of edges in the above diagram matches the order of edges present in each edge vector. That is, bb4's predecessor edge vector looks like (bb0-bb4, bb3-bb4). Here is the call sequence. thread_jumps () thread_jump (bb4, ...) no jump threading occurs thread_jump (bb0) no jump threading occurs thread_jump (ENTRY_BLOCK_PTR) base case thread_jump (bb3) no jump threading occurs (as bb3 is a forwarder block) thread_jump (bb1) bb1, bb2, and bb3 collapse down to one basic block thread_jump (bb0) base case (already visited) Here is the end result. bb0 | \ | \ | bb1 | / | / bb4 Note that we removed only one if statement. If we have n deeply nested if statements, we need n iterations of thread_jumps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
[Bug target/17717] SH4 internal compiler error: in emit_move_insn
-- What|Removed |Added Attachment #7232|preprocessed source for |preprocessed source for description|first inteernal error case |first internal error case http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17717
[Bug ada/17312] internal gnat bug. compilation abandoned.
--- Additional Comments From pluto at pld-linux dot org 2004-10-13 16:15 --- (In reply to comment #1) Does this work with i686-pc-linux-gnu as the target if so this is an optimization problem in the sense -march=pentium3 causes the wrong code. Also does this happen on the mainline. Currently I have installed gcc-3.4.3-20041008 (pentium3 target with -O2) and I can't rebuild any gcc34 snaphot (386 target with -O0) :/ # segv gcc -c -O0 -march=i386 -pipe -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-error -DHAVE_CONFIG_H-I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include ../../gcc/c-parse.c -o c-parse.o In file included from c-parse.y:48: ../../gcc/output.h:107: internal compiler error: Segmentation fault make[2]: *** [c-parse.o] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17312
[Bug rtl-optimization/17942] segv on valid-code
--- Additional Comments From pluto at pld-linux dot org 2004-10-13 16:50 --- Now I'm sure. It's kernel related bug. With 2.6.9rc2+20041007_0305 everything works fine. After update to 2.6.9rc4 lots of things stop working. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17942
[Bug middle-end/17503] quadratic behaviour in invalid_mode_change_p
-- What|Removed |Added Target Milestone|4.0.0 |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17503
[Bug c/16834] [3.3/3.4 Regression] huge compilation time increase from 3.2.3 to 3.3.2
--- Additional Comments From rth at gcc dot gnu dot org 2004-10-13 16:59 --- Patch committed for 3.4.3. I did try the patch against 3.3 branch, but it doesn't do much good. In that case there are other reload related bits that are snarfing up time: % cumulative self self total time seconds secondscalls s/call s/call name 36.00227.89 227.89 102804 0.00 0.01 find_equiv_reg 26.39394.97 167.08 703271664 0.00 0.00 single_set_2 23.97546.71 151.74 1749021956 0.00 0.00 true_regnum 3.01565.7819.07 162045491 0.00 0.00 subreg_regno_offset I'm not planning to look into this further. *** This bug has been marked as a duplicate of 17503 *** -- What|Removed |Added Status|ASSIGNED|RESOLVED Component|rtl-optimization|c Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16834
[Bug middle-end/17503] quadratic behaviour in invalid_mode_change_p
--- Additional Comments From rth at gcc dot gnu dot org 2004-10-13 16:59 --- *** Bug 16834 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||jozef dot kruger at philips ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17503
[Bug rtl-optimization/17942] segv on valid-code
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 17:01 --- Not a gcc bug. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17942
[Bug tree-optimization/17966] a quadratic behavior in thread_jumps
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 17:02 --- Oh, you are right, maybe doing the forwarding before and try doing it after will fix that and we will no longer have to do while (thread_jumps()) either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
[Bug java/15578] gcj doesn't support -extdirs
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-13 17:04 --- Subject: Bug 15578 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-13 17:03:58 Modified files: gcc: ChangeLog gcc.c Log message: PR java/15578: * gcc.c (option_map): Added --extdirs and --encoding. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.5861r2=2.5862 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcc.c.diff?cvsroot=gccr1=1.435r2=1.436 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15578
[Bug java/15578] gcj doesn't support -extdirs
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-13 17:05 --- Subject: Bug 15578 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-13 17:04:58 Modified files: gcc/java : ChangeLog lang.opt jvspec.c Log message: PR java/15578: * lang.opt (--extdirs): Document. * jvspec.c (lang_specific_driver): Recognize -encoding and -extdirs. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gccr1=1.1482r2=1.1483 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/lang.opt.diff?cvsroot=gccr1=1.10r2=1.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/jvspec.c.diff?cvsroot=gccr1=1.66r2=1.67 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15578
[Bug java/15578] gcj doesn't support -extdirs
--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-13 17:05 --- Fix checked in. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15578
[Bug java/1374] gcj -C (options) diverges from javac
-- Bug 1374 depends on bug 15578, which changed state. Bug 15578 Summary: gcj doesn't support -extdirs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15578 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1374
[Bug java/17574] [meta-bug] gcj and libgcj 4.0 tracking PR
-- Bug 17574 depends on bug 15578, which changed state. Bug 15578 Summary: gcj doesn't support -extdirs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15578 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17574
[Bug debug/13974] [4.0 regression] bad line marker in debug info
--- Additional Comments From mec dot gnu at mindspring dot com 2004-10-13 17:15 --- Subject: Re: [4.0 regression] bad line marker in debug info All right! It works in my gdb test bed, and does not cause any other regressions. There are still a few gdb test suite regressions from gcc 3.4.2 to gcc HEAD. I will analyze them and file fresh PR's for them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13974
[Bug c++/17661] [4.0 Regression] ICE in create_tmp_var
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-13 17:18 --- Subject: Bug 17661 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-13 17:18:16 Modified files: gcc/cp : ChangeLog semantics.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/expr: for2.C Log message: 2004-10-13 Andrew Pinski [EMAIL PROTECTED] PR c++/17661 * testsuite/g++.dg/expr/for2.C: New test. 2004-10-13 Andrew Pinski [EMAIL PROTECTED] PR c++/17661 * semantics.c (finish_for_expr): Convert expression to void so that we don't create temporaries for a?b:c. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4431r2=1.4432 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gccr1=1.446r2=1.447 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4442r2=1.4443 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/expr/for2.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17661
[Bug c++/17661] [4.0 Regression] ICE in create_tmp_var
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 17:18 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17661
[Bug web/17974] New: Debugging-Options.html: '-dletters' list format looks broken
example: http://gcc.gnu.org/onlinedocs/gcc-3.4.2/gcc/Debugging-Options.html#Debugging-Options A Annotate the assembler output with miscellaneous debugging information. b Dump after computing branch probabilities, to file.12.bp. B ... IMO, the text should start in the *same* line. Note, the .ps file looks fine! Browser: Mozilla -- Summary: Debugging-Options.html: '-dletters' list format looks broken Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: berndtrog at yahoo dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17974
[Bug debug/13841] [3.4/4.0? regression] missing debug info for _Complex function arguments
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED GCC target triplet|SPLIT_COMPLEX_ARGS == 1 |SPLIT_COMPLEX_ARGS == 1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13841
[Bug other/17974] Debugging-Options.html: '-dletters' list format looks broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 17:22 --- Why do you think it should be on the same line? Also this would be a texi2html bug, rather than anyother problem. -- What|Removed |Added Component|web |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17974
[Bug other/17974] Debugging-Options.html: '-dletters' list format looks broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 17:23 --- Also 2.95.3's manual has the same issue: http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC9 So this is not a bug. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17974
[Bug bootstrap/17975] New: make bootstrap fails because libiberty-components are not compiled
Since the introduction of version 3.4.0 I'm unable to build gcc. I've build it many times before, but with 3.40, 3.4.1, 3.4.2 it is always the same, under all possible variations regarding build directory etc.: [EMAIL PROTECTED]:~/GCC/Install_3.4.2 make bootstrap Configuring in libiberty configure: creating cache ./config.cache checking whether to enable maintainer-specific portions of Makefiles... no checking for makeinfo... makeinfo checking for perl... perl checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for x86_64-unknown-linux-gnu-ar... ar checking for x86_64-unknown-linux-gnu-ranlib... ranlib checking for x86_64-unknown-linux-gnu-gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking whether gcc and cc understand -c and -o together... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking whether byte ordering is bigendian... no checking for a BSD-compatible install... /usr/bin/install -c Appending /home/csoliver/GCC/gcc-3.4.2/libiberty/../config/mh-x86pic to xhost-mkfrag checking for sys/file.h... yes checking for sys/param.h... yes checking for limits.h... yes checking for stdlib.h... yes checking for malloc.h... yes checking for string.h... yes checking for unistd.h... yes checking for strings.h... yes checking for sys/time.h... yes checking for time.h... yes checking for sys/resource.h... yes checking for sys/stat.h... yes checking for sys/mman.h... yes checking for fcntl.h... yes checking for alloca.h... yes checking for sys/pstat.h... no checking for sys/sysmp.h... no checking for sys/sysinfo.h... yes checking for machine/hal_sysinfo.h... no checking for sys/table.h... no checking for sys/sysctl.h... yes checking for sys/systemcfg.h... no checking for sys/wait.h that is POSIX.1 compatible... yes checking whether time.h and sys/time.h may both be included... yes checking whether errno must be declared... no checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... (cached) yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for memory.h... yes checking for strings.h... (cached) yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... (cached) yes checking for uintptr_t... yes checking for pid_t... yes checking for library containing strerror... none required checking for asprintf... yes checking for atexit... yes checking for basename... yes checking for bcmp... yes checking for bcopy... yes checking for bsearch... yes checking for bzero... yes checking for calloc... yes checking for clock... yes checking for ffs... yes checking for getcwd... yes checking for getpagesize... yes checking for index... yes checking for insque... yes checking for memchr... yes checking for memcmp... yes checking for memcpy... yes checking for memmove... yes checking for mempcpy... yes checking for memset... yes checking for mkstemps... no checking for putenv... yes checking for random... yes checking for rename... yes checking for rindex... yes checking for setenv... yes checking for snprintf... yes checking for sigsetmask... yes checking for stpcpy... yes checking for stpncpy... yes checking for strcasecmp... yes checking for strchr... yes checking for strdup... yes checking for strncasecmp... yes checking for strrchr... yes checking for strstr... yes checking for strtod... yes checking for strtol... yes checking for strtoul... yes checking for tmpnam... yes checking for vasprintf... yes checking for vfprintf... yes checking for vprintf... yes checking for vsnprintf... yes checking for vsprintf... yes checking for waitpid... yes checking whether alloca needs Cray hooks... no checking stack direction for C alloca... -1 checking for unistd.h... (cached) yes checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking for _doprnt... no checking for sys_errlist... yes checking for sys_nerr... yes checking for sys_siglist... yes checking for external symbol _system_configuration... no checking for getrusage... yes checking for on_exit... yes checking for psignal... yes checking for strerror... yes checking for strsignal... yes checking for sysconf... yes checking for times... yes checking for sbrk... yes checking for gettimeofday... yes checking for realpath... yes
[Bug bootstrap/17975] make bootstrap fails because libiberty-components are not compiled
--- Additional Comments From o dot kullmann at swansea dot ac dot uk 2004-10-13 17:52 --- sorry, didn't want to do anything here, but just updating the page seems to have created something ?!?! -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17975
[Bug c/17384] [3.4/4.0 Regression] ICE with mode attribute on structures
--- Additional Comments From rth at gcc dot gnu dot org 2004-10-13 18:13 --- Working on a fix for the ICE, but I'll warn you that this construct is erroneous. You don't get to choose the mode for a structure; that's determined by the layout routines. As for your hardware registers, no there's no way to do this with a structure. You'll need to explicitly read these registers with an integer type. You might look into the transparent union extension that would let you cast between integer and structure types. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17384
[Bug libstdc++/17937] Critical ~__pool troubles
--- Additional Comments From matz at suse dot de 2004-10-13 18:28 ---
Still doesn't fully work. The initial testcase now works, but aRts still
segfaults. This time I need this testcase:
-
#include string
std::string idl_filename;
extern std::string idl_filename;
int main()
{
idl_filename = bla;
return 0;
}
-
This has to be compiled with -pthread, then it segfaults for me. Note that
the extern line is important, including it's place (after the definition).
% g++ -g -pthread mcopidl.cc
% ./a.out
Segmentation fault
% valgrind -q --num-callers=42 --tool=memcheck ./a.out
==7097== Invalid read of size 4
==7097==at 0x1B94C2CB: __gnu_cxx::__pooltrue::_M_reclaim_block(char*,
unsigned) (in /usr/lib/libstdc++.so.6.0.3)
==7097==by 0x1B94CD13: __gnu_cxx::__mt_allocchar,
__gnu_cxx::__common_pool_policytrue ::deallocate(char*, unsigned)
(in /usr/lib/libstdc++.so.6.0.3)
==7097==by 0x1B9945A2: std::string::_Rep::_M_destroy(std::allocatorchar
const) (in /usr/lib/libstdc++.so.6.0.3)
==7097==by 0x1B995A1C: std::string::~string()
(in /usr/lib/libstdc++.so.6.0.3)
==7097==by 0x804866A: __tcf_1 (mcopidl.cc:3)
==7097==by 0x1BA697EF: exit (in /lib/tls/libc.so.6)
==7097==by 0x1BA54AE9: __libc_start_main (in /lib/tls/libc.so.6)
==7097==by 0x8048580: ??? (start.S:119)
==7097== Address 0x8AA04420 is not stack'd, malloc'd or (recently) free'd
Segmentation fault
Note that it works either without the extern line or that one before the
definition, or when compiling without -pthread (but KDE is compiled with
that).
It seems I can't reopen this bug report, so if someone else could ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17937
[Bug libstdc++/17937] Critical ~__pool troubles
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 18:33 --- I think that is a bug in the front-end: L2:; if (__priority == 65535) goto L4; else goto L6; L4:; if (__initialize_p == 0) goto L5; else goto L6; L5:; __comp_dtor (idl_filename); L6:; if (__priority == 65535) goto L8; else goto L10; L8:; if (__initialize_p == 0) goto L9; else goto L10; L9:; __comp_dtor (idl_filename); Please file it seperately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17937
[Bug libstdc++/17937] Critical ~__pool troubles
--- Additional Comments From matz at suse dot de 2004-10-13 18:37 --- Ah, the problem is, that for some reasons GCC emits _two_ dtor functions for 'idl_filename' (__tcf_2 and __tcf_1), but only if the extern decl comes after the definition. Okay, this is an error in itself, but it seems the other allocators deal with this breakage more graceful. OTOH it's a real double free, so it's not really something which has to be fixed in the allocator itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17937
[Bug c++/17976] New: Calls the dtor twice
extern C void abort();
struct A
{
static int i;
A(){}
~A(){i++;if(i1)abort();}
};
int A::i = 0;
A a;
extern A a;
int main()
{
return 0;
}
--
Summary: Calls the dtor twice
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17976
[Bug libstdc++/17937] Critical ~__pool troubles
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 18:39 --- I filed the c++ front-end bug under PR 17976 with a simple example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17937
[Bug c++/17977] New: C++ emits multiple dtor-calling functions for one definition
This came over from #17937. The testcase
---
#include string
std::string idl_filename;
extern std::string idl_filename;
int main()
{
idl_filename = bla;
return 0;
}
---
segfaults when compiled with g++ -pthread test.cc.
The reason is that there are two destroyer functions for idl_filename
registered (__tcf_2 and __tcf_1). This happens only if the extern
declaration comes after the definition.
--
Summary: C++ emits multiple dtor-calling functions for one
definition
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: x86-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17977
[Bug libstdc++/17937] Critical ~__pool troubles
--- Additional Comments From matz at suse dot de 2004-10-13 18:41 --- Oh, wire-crossing. I filed this now as PR17977. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17937
