[Bug bootstrap/25435] stage build no longer works
-- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25435
[Bug bootstrap/25453] [4.2 Regression] --disable-bootstrap is not documented
--- Comment #3 from bonzini at gnu dot org 2006-03-21 08:25 --- no, we should definitely document it. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-23 05:50:43 |2006-03-21 08:25:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25453
[Bug rtl-optimization/20070] If-conversion can't match equivalent code, and cross-jumping only works for literal matches
--- Comment #25 from bonzini at gnu dot org 2006-03-21 08:27 --- can we close this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20070
[Bug target/26776] A stack frame can't be recovered when using large auto variable area.
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-21 09:28 --- The 3.4 branch is closed, can you check 4.0.3 or 4.1.0 please? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26776
[Bug target/26775] a stack pointer is not recovered correctly when using alloca.
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-21 09:28 --- The 3.4 branch is closed, can you check 4.0.3 or 4.1.0 please? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26775
[Bug c/26774] Out of memory compiling 9-line Delta-reduced Linux kernel driver msp3400.c
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-21 09:37 ---
Confirmed. Though the unreduced testcase does not build for me. The testcase
in question is
struct i2c_driver {
struct module *owner;
int (*command)(struct i2c_client *client,unsigned int cmd, void *arg);
struct device_driver driver;
}
static int msp_command(struct i2c_client *client, unsigned int cmd, void *arg);
static struct i2c_driver driver = {
.command = msp_command,
},
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||error-recovery, ice-on-
||invalid-code
Last reconfirmed|-00-00 00:00:00 |2006-03-21 09:37:33
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26774
[Bug c/26774] [4.0/4.1/4.2 Regression] Out of memory compiling 9-line Delta-reduced Linux kernel driver msp3400.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-21 09:38 --- 3.4 is confused by earlier errors and bails out. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.3 4.1.0 Known to work||3.4.6 Summary|Out of memory compiling 9- |[4.0/4.1/4.2 Regression] Out |line Delta-reduced Linux|of memory compiling 9-line |kernel driver msp3400.c |Delta-reduced Linux kernel ||driver msp3400.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26774
[Bug c++/26755] [4.1 regression?] may fail to generate code for base destructor defined inline
--- Comment #2 from tbm at cyrius dot com 2006-03-21 12:09 --- > We need a testcase to reproduce this. We don't have a minimal test case yet but you can download the source of the package which shows this problem and see for yourself. Maybe you can come up with a smaller testcase. http://www.rekallrevealed.org/packages/ xbsql-0.11.tgz shos the problem, but you also need xbase-2.0.0.tgz in order to compile it. -- tbm at cyrius dot com changed: What|Removed |Added CC||tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26755
[Bug libstdc++/26777] sync_with_stdio(false) triggers bug with sgetc and pubseekoff
--- Comment #1 from sam at quux dot dropbear dot id dot au 2006-03-21 12:29 --- Created an attachment (id=11081) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11081&action=view) --save-temps output from compilation of example code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26777
[Bug tree-optimization/26781] [4.2 Regression] ICE in tree-ssa-pre.c at create_component_ref_by_piec
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-21 15:31 --- Mine, it is STRING_CST which is causing the ICE. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-21 15:31:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
[Bug tree-optimization/26781] [4.2 Regression] ICE in tree-ssa-pre.c at create_component_ref_by_piec
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-21 15:31 ---
Reduced testcase:
void zconfdump(void)
{
char *p, *p2;
for (p2 = p; p2; )
{
char __a0, __a1, __a2;
__a0 = ((__const char *) ("\"\\"))[0];
if (__a0)
return;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
[Bug libstdc++/25482] Specialize (overload) std::copy/find for streambuf iterators
--- Comment #2 from paolo at gcc dot gnu dot org 2006-03-21 12:25 --- Subject: Bug 25482 Author: paolo Date: Tue Mar 21 12:25:11 2006 New Revision: 112247 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112247 Log: 2006-03-21 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/25482 * include/bits/stl_algobase.h (__copy_aux(_CharT*, _CharT*, ostreambuf_iterator<_CharT>), __copy_aux(const _CharT*, const _CharT*, ostreambuf_iterator<_CharT>), __copy_aux(istreambuf_iterator<_CharT>, istreambuf_iterator<_CharT>, _CharT*), copy(istreambuf_iterator<_CharT>, istreambuf_iterator<_CharT>, ostreambuf_iterator<_CharT>)): Declare. * include/bits/stl_algo.h (find(istreambuf_iterator<_CharT>, istreambuf_iterator<_CharT>, _CharT)): Likewise. * include/bits/streambuf_iterator.h (copy(istreambuf_iterator<_CharT>, istreambuf_iterator<_CharT>, ostreambuf_iterator<_CharT>), __copy_aux(_CharT*, _CharT*, ostreambuf_iterator<_CharT>), __copy_aux(const _CharT*, const _CharT*, ostreambuf_iterator<_CharT>), __copy_aux(istreambuf_iterator<_CharT>, istreambuf_iterator<_CharT>, _CharT*), find(istreambuf_iterator<_CharT>, istreambuf_iterator<_CharT>, _CharT)): Define. (class istreambuf_iterator<>, class ostreambuf_iterator<>): Declare friends. * include/std/std_streambuf.h (class basic_streambuf<>): Likewise. * include/bits/cpp_type_traits.h (struct __is_char<>): Add. * testsuite/25_algorithms/copy/streambuf_iterators/char/1.cc: New. * testsuite/25_algorithms/copy/streambuf_iterators/char/2.cc: New. * testsuite/25_algorithms/copy/streambuf_iterators/char/3.cc: New. * testsuite/25_algorithms/copy/streambuf_iterators/char/4.cc: New. * testsuite/25_algorithms/copy/streambuf_iterators/wchar_t/1.cc: New. * testsuite/25_algorithms/copy/streambuf_iterators/wchar_t/2.cc: New. * testsuite/25_algorithms/copy/streambuf_iterators/wchar_t/3.cc: New. * testsuite/25_algorithms/copy/streambuf_iterators/wchar_t/4.cc: New. * testsuite/25_algorithms/find/istreambuf_iterators/char/1.cc: New. * testsuite/25_algorithms/find/istreambuf_iterators/char/2.cc: New. * testsuite/25_algorithms/find/istreambuf_iterators/wchar_t/1.cc: New. * testsuite/25_algorithms/find/istreambuf_iterators/wchar_t/2.cc: New. * testsuite/performance/25_algorithms/copy_streambuf_iterators.cc: New. * testsuite/performance/25_algorithms/find_istreambuf_iterators.cc: New. Added: trunk/libstdc++-v3/testsuite/25_algorithms/copy/streambuf_iterators/ trunk/libstdc++-v3/testsuite/25_algorithms/copy/streambuf_iterators/char/ trunk/libstdc++-v3/testsuite/25_algorithms/copy/streambuf_iterators/char/1.cc trunk/libstdc++-v3/testsuite/25_algorithms/copy/streambuf_iterators/char/2.cc trunk/libstdc++-v3/testsuite/25_algorithms/copy/streambuf_iterators/char/3.cc trunk/libstdc++-v3/testsuite/25_algorithms/copy/streambuf_iterators/char/4.cc trunk/libstdc++-v3/testsuite/25_algorithms/copy/streambuf_iterators/wchar_t/ trunk/libstdc++-v3/testsuite/25_algorithms/copy/streambuf_iterators/wchar_t/1.cc trunk/libstdc++-v3/testsuite/25_algorithms/copy/streambuf_iterators/wchar_t/2.cc trunk/libstdc++-v3/testsuite/25_algorithms/copy/streambuf_iterators/wchar_t/3.cc trunk/libstdc++-v3/testsuite/25_algorithms/copy/streambuf_iterators/wchar_t/4.cc trunk/libstdc++-v3/testsuite/25_algorithms/find/istreambuf_iterators/ trunk/libstdc++-v3/testsuite/25_algorithms/find/istreambuf_iterators/char/ trunk/libstdc++-v3/testsuite/25_algorithms/find/istreambuf_iterators/char/1.cc trunk/libstdc++-v3/testsuite/25_algorithms/find/istreambuf_iterators/char/2.cc trunk/libstdc++-v3/testsuite/25_algorithms/find/istreambuf_iterators/wchar_t/ trunk/libstdc++-v3/testsuite/25_algorithms/find/istreambuf_iterators/wchar_t/1.cc trunk/libstdc++-v3/testsuite/25_algorithms/find/istreambuf_iterators/wchar_t/2.cc trunk/libstdc++-v3/testsuite/performance/25_algorithms/copy_streambuf_iterators.cc trunk/libstdc++-v3/testsuite/performance/25_algorithms/find_istreambuf_iterators.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/cpp_type_traits.h trunk/libstdc++-v3/include/bits/stl_algo.h trunk/libstdc++-v3/include/bits/stl_algobase.h trunk/libstdc++-v3/include/bits/streambuf_iterator.h trunk/libstdc++-v3/include/std/std_streambuf.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25482
[Bug libstdc++/26777] New: sync_with_stdio(false) triggers bug with sgetc and pubseekoff
The following code demonstrates the bug.
#include
using namespace std;
int main() {
ios::sync_with_stdio(false);
streambuf *s=cin.rdbuf();
int c=s->sgetc();
s->pubseekoff(0,ios::cur,ios::in);
cout << s;
}
When the resulting executable is run with standard input coming
(for example) a pipe, the first 8191 bytes of input are not
replicated to standard out.
Expected behaviour is for pubseekoff to fail, but not to throw
away buffered data in the process.
If sync_with_stdio(false) is not called, the program behaves
as expected.
If sgetc() is not called on the streambuf, the program behaves
as expected.
If standard input is redirected from a file, then pubseekoff
does not fail, and the output is as expected.
Compiler output and a demonstration:
$ g++ -v --save-temps -o bug bug.cc
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/gcc-4.0.2-r3/work/gcc-4.0.2/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.0.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.0.2
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.0.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.0.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --enable-multilib
--disable-libmudflap --disable-libgcj --enable-languages=c,c++,f95
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu
Thread model: posix
gcc version 4.0.2 (Gentoo 4.0.2-r3, pie-8.7.8)
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.0.2/cc1plus -E -quiet -v -D_GNU_SOURCE
bug.cc -mtune=k8 -fpch-preprocess -o bug.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/include/g++-v4
/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/include/g++-v4/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/include/g++-v4/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/include
/usr/include
End of search list.
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.0.2/cc1plus -fpreprocessed bug.ii
-quiet -dumpbase bug.cc -mtune=k8 -auxbase bug -version -o bug.s
GNU C++ version 4.0.2 (Gentoo 4.0.2-r3, pie-8.7.8) (x86_64-pc-linux-gnu)
compiled by GNU C version 4.0.2 (Gentoo 4.0.2-r3, pie-8.7.8).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../x86_64-pc-linux-gnu/bin/as
-V -Qy -o bug.o bug.s
GNU assembler version 2.16.1 (x86_64-pc-linux-gnu) using BFD version 2.16.1
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.0.2/collect2 --eh-frame-hdr -m
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o bug
/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/crtbegin.o
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../.. -L/lib/../lib64
-L/usr/lib/../lib64 bug.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/crtend.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../lib64/crtn.o
$ dd if=/dev/urandom bs=16k count=1 of=test-in
1+0 records in
1+0 records out
$ dd if=test-in bs=1 skip=8191 of=test-trunc
8193+0 records in
8193+0 records out
$ cat test-in | ./bug > test-out
$ cmp test-out test-trunc
$ wc -c test-in test-out test-trunc
16384 test-in
8193 test-out
8193 test-trunc
32770 total
$
--
Summary: sync_with_stdio(false) triggers bug with sgetc and
pubseekoff
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sam at quux dot dropbear dot id dot au
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26777
[Bug middle-end/26778] New: GCC4 moves the result of a conditional block through inadequate registers
When compiling the following reduced code, both GCC 4.0.3 and 4.1.0 clutter the
assembly code with some strange moves through SSE registers.
typedef union {
long long l;
double d;
} db_number;
double test(double x[3]) {
double th = x[1] + x[2];
if (x[2] != th - x[1]) {
db_number thdb;
thdb.d = th;
thdb.l++;
th = thdb.d;
}
return x[0] + th;
}
"gcc-4.0 -S -O3 -march=pentium3" will generate:
fstpl -16(%ebp)
movlps -16(%ebp), %xmm0
je .L2
...
movlps -16(%ebp), %xmm1
movaps %xmm1, %xmm0
.L2:
movlps %xmm0, -16(%ebp)
fldl-16(%ebp)
GCC has decided that the content of "th" would be in %xmm0 (while "th" is a
double variable and the target is a SSE 1 processor!) instead of being in
-16(%ebp) where the rest of the code expects it to be. As a consequence, the
compiler has to misoptimize the code to cope with this. In comparison, below is
what GCC 3.4 generates. This seems saner and optimal to me.
fstp%st(1)
je .L2
...
fldl-16(%ebp)
.L2:
With GCC 3.4, either the value is left untouched at the top of the
floating-point stack, either it is loaded once if it was modified. In both
cases, it is directly available once the execution reaches .L2. No SSE register
is involded and there is no load/store/load sequence though a single stack
location.
This was tested with Debian packages for GCC 3.4, 4.0, and 4.1 :
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.3 (Debian 4.0.3-1)
--
Summary: GCC4 moves the result of a conditional block through
inadequate registers
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
GCC host triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
[Bug c++/26755] [4.1 regression?] may fail to generate code for base destructor defined inline
--- Comment #6 from tbm at cyrius dot com 2006-03-21 15:33 --- I think you're onto something here. Compiling xbsql with 4.1 against a libxbase compiled with 4.1 works, but it fails against libxbase compiled with 4.0. So this may be an 4.0 issue - but it still leaves us with a binary compatibility between 4.0 and 4.1. gcc version 3.3.6 (Debian 1:3.3.6-13) libxbase 00020834 W _ZN5xbNdxD0Ev 000207a8 W _ZN5xbNdxD1Ev 0002071c W _ZN5xbNdxD2Ev xbsql U _ZN5xbNdxD1Ev U _ZN5xbNdxD2Ev gcc version 4.0.3 (Debian 4.0.3-1) libxbase 000225e4 W _ZN5xbNdxD0Ev 00022844 W _ZN5xbNdxD1Ev xbsql 0001b768 W _ZN5xbNdxD1Ev 0001826c W _ZN5xbNdxD2Ev gcc version 4.1.0 (Debian 4.1.0-0) libxbase 00022aa4 W _ZN5xbNdxD0Ev 00022b34 W _ZN5xbNdxD1Ev 00022bc4 W _ZN5xbNdxD2Ev xbsql U _ZN5xbNdxD1Ev U _ZN5xbNdxD2Ev system type: powerpc-unknown-linux-gnu, but also seen on AMD64, i386 and mips (all Linux) options given when GCC was configured/built: gcc-3.3 -v Reading specs from /usr/lib/gcc-lib/powerpc-linux-gnu/3.3.6/specs Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr --mandir=/usr/share/man --infodir=/usr /share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib - -enable-nls --without-included-gettext --enable-clocale=gnu --enable-debug --disable-multilib powerpc-linux-gnu Thread model: posix gcc version 3.3.6 (Debian 1:3.3.6-13) gcc-4.0 -v Using built-in specs. Target: powerpc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-sh ared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --pro gram-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --disable-werror --enable-checking=release po werpc-linux-gnu Thread model: posix gcc version 4.0.3 (Debian 4.0.3-1) gcc-4.1 -v Using built-in specs. Target: powerpc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enab le-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt =gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr --disable-softf loat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --enable-checking=release powerpc-linux-g nu Thread model: posix gcc version 4.1.0 (Debian 4.1.0-0) complete command line that triggers the bug; 3.3: /bin/sh ../libtool --mode=link g++-3.3 -UNO_READLINE -I/usr/local/include -g -g -o xql xql.o -lxbase -lreadline -lncurses ./libxbsql.la g++-3.3 -UNO_READLINE -I/usr/local/include -g -g -o .libs/xql xql.o -lreadline -lncurses ./.libs/libxbsql.so /usr/ lib/libxbase.so [works] 4.1 with libxbase installed compiled with 4.1: /bin/sh ../libtool --mode=link g++-4.1 -UNO_READLINE -I/usr/local/include -g -g -o xql xql.o -lxbase -lreadline -lncurses ./libxbsql.la g++-4.1 -UNO_READLINE -I/usr/local/include -g -g -o .libs/xql xql.o -lreadline -lncurses ./.libs/libxbsql.so /usr /lib/libxbase.so [works] 4.1 with libxbase installed compiled with 4.0: /bin/sh ../libtool --mode=link g++-4.1 -UNO_READLINE -I/usr/local/include -g -g -o xql xql.o -lxbase -lreadline -lncurses ./libxbsql.la g++-4.1 -UNO_READLINE -I/usr/local/include -g -g -o .libs/xql xql.o -lreadline -lncurses ./.libs/libxbsql.so /usr /lib/libxbase.so ./.libs/libxbsql.so: undefined reference to `xbNdx::~xbNdx()' 4.1 with libxbase installed compiled with 3.3: /bin/sh ../libtool --mode=link g++-4.1 -UNO_READLINE -I/usr/local/include -g -g -o xql xql.o -lxbase -lreadline -lncurses ./libxbsql.la g++-4.1 -UNO_READLINE -I/usr/local/include -g -g -o .libs/xql xql.o -lreadline -lncurses ./.libs/libxbsql.so /usr /lib/libxbase.so /usr/bin/ld: warning: libstdc++.so.5, needed by /usr/lib/libxbase.so, may conflict with libstdc++.so.6 [warning, but compiles/links] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26755
[Bug fortran/26779] New: Internal module procedure may not have private type dummy arguments
This error is generated by the example, given at the end of Metcalf, Reid and Cohen; pointer.f90. The following reduced testcase, illustartes it: module test public sub type, private :: t ! type :: t integer :: i end type t contains subroutine sub (arg) integer arg type(t) :: root call init(root, arg) contains subroutine init(ir, i) integer i type(t) :: ir ir%i = i end subroutine init end subroutine sub end module test In file private.f90:11 call init(root, arg) 1 Error: 'ir' is of a PRIVATE type and cannot be a dummy argument of 'init', which is PUBLIC at (1) Being an internal procedure, init is NOT public by 2.2.3.3 of the F95 standard. It should have access to all the symbols of the host, therefore this error is wrong on both levels; ir cannot be private to it, nor is init public! Needless to say, a patch is on its way! Paul -- Summary: Internal module procedure may not have private type dummy arguments Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paul dot richard dot thomas at cea dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26779
[Bug libstdc++/25482] Specialize (overload) std::copy/find for streambuf iterators
--- Comment #3 from pcarlini at suse dot de 2006-03-21 12:26 --- Fixed for 4.2.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25482
[Bug target/26713] Stack frame allocation limited to 32k
--- Comment #3 from christoph dot stueckjuergen at siemens dot com 2006-03-21 12:02 --- We found out that our problem is not related to the toolchain but to the rlimit settings of the kernel. Sorry if the bug caused confusion! Please mark the bug as invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26713
[Bug c++/22063] link failure involving symbol visibility
--- Comment #5 from matz at suse dot de 2006-03-21 13:59 ---
There is no such thing as a hidden reference. A symbol can be hidden,
then it's not exported and all references from inside DSO are directly bound
to it. That's not the situation we have here. We have a global exported
symbol ('vtable of foo') in libfoo.so, which somehow is not found by
the reference from inside liblinkfoo.so. This might also be a linker error,
I don't know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22063
[Bug c++/26780] New: Build fails while making ../../../unxlngi6.pro/slo/cellsuno.obj on LFS6.1, kernel 2.6.14.3
Three times in a row I got this error while building OOo-2.0.2 from source according to instructions at http://www.linuxfromscratch.org/blfs/view/svn/xsoft/openoffice.html but adapted for OOo-2.0.2 There is a suggestion to do a full report at gcc.gnu.org so I comply. Output of gcc -v -save-temps all-your-options source-file: g++: warning: ignoring -pipe since -save-temps was specified Reading specifications from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ Threads model: posix gcc version 3.4.3 -- Summary: Build fails while making ../../../unxlngi6.pro/slo/cellsuno.obj on LFS6.1, kernel 2.6.14.3 Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gratbau at cantv dot net 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=26780
[Bug target/26778] GCC4 moves the result of a conditional block through inadequate registers
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-21 13:13 --- I believe this is fallout from some of the regstack changes. It does indeed look a bit silly. But using the *ps variants on an SSE1 target is ok - the xmm registers are just used as temporary storage. This one movlps -16(%ebp), %xmm1 movaps %xmm1, %xmm0 is a regalloc issue. Btw. -O1 -march=pentium3 is enough to see it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |target Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2006-03-21 13:13:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
[Bug rtl-optimization/20070] If-conversion can't match equivalent code, and cross-jumping only works for literal matches
--- Comment #26 from amylaar at gcc dot gnu dot org 2006-03-21 14:24 --- (In reply to comment #25) > can we close this? > No, we still have to actually re-enable the cross-jumping code, and we haven't even gotten to the review of the if-conversion part. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20070
[Bug c++/26755] [4.1 regression?] may fail to generate code for base destructor defined inline
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-21 14:28 --- http://gcc.gnu.org/bugs.html Please read the instructions there (in fact this should not have been pulled up stream until then). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26755
[Bug target/26713] Stack frame allocation limited to 32k
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-21 13:25 --- Closing as invalid as requested by the reporter. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26713
[Bug c++/26755] [4.1 regression?] may fail to generate code for base destructor defined inline
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-21 14:06 --- Reading this bug report, leads me to think there is a bug in 4.0.x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26755
[Bug c++/26755] [4.1 regression?] may fail to generate code for base destructor defined inline
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-21 14:07 --- And we cannot do without a testcase as looking at the source which you gave link to does not give any obvious answers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26755
[Bug c++/26780] Build fails while making ../../../unxlngi6.pro/slo/cellsuno.obj on LFS6.1, kernel 2.6.14.3
--- Comment #1 from gratbau at cantv dot net 2006-03-21 14:07 --- Created an attachment (id=11082) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11082&action=view) Screen output for build command -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26780
[Bug libstdc++/26777] sync_with_stdio(false) triggers bug with sgetc and pubseekoff
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-21 14:21 --- GNU C++ version 4.0.2 (Gentoo 4.0.2-r3, pie-8.7.8) (x86_64-pc-linux-gnu) compiled by GNU C version 4.0.2 (Gentoo 4.0.2-r3, pie-8.7.8). This really should have been reported to gentoo first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26777
[Bug c++/21581] (optimisation) Functions in anonymous namespaces should default to "hidden" visibility
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-09-30 05:14:50 |2006-03-21 14:31:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21581
[Bug c/26781] New: ICE in tree-ssa-pre.c at create_component_ref_by_piec
Looks like a mis-applied patch in create_component_ref_by_pieces. -- Summary: ICE in tree-ssa-pre.c at create_component_ref_by_piec Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets dot com GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
Re: [Bug tree-optimization/26781] [4.2 Regression] ICE in tree-ssa-pre.c at create_component_ref_by_piec
On Tue, 2006-03-21 at 15:02 +, malitzke at metronets dot com wrote: > > --- Comment #5 from malitzke at metronets dot com 2006-03-21 15:02 > --- > The two "if (tree_code(genop) == VALUE_HANDLE) at lines 2190 of tree-ssa-pre.c > look suspicious to me. > > They aren't suspicious at all.
[Bug tree-optimization/26781] ICE in tree-ssa-pre.c at create_component_ref_by_piec
--- Comment #3 from malitzke at metronets dot com 2006-03-21 14:51 --- Created an attachment (id=11084) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11084&action=view) ICE combined output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
[Bug c++/26782] New: reject [valid?] template specialization.
namespace A { namespace B {
template < typename T > void foo();
} }
struct S1;
struct S2;
namespace A { namespace B {
template <> void foo< S1 >(); // accepted
} }
template <> void A::B::foo< S2 >(); // rejected
$ g++ bug.cpp -c -Wall
error: specialization of ‘template void A::B::foo()’
in different namespace
error: from definition of ‘template void A::B::foo()’
this testcase works with g++ 3.3.6 and vs-2003.
--
Summary: reject [valid?] template specialization.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: *
GCC host triplet: *
GCC target triplet: *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26782
[Bug tree-optimization/26781] ICE in tree-ssa-pre.c at create_component_ref_by_piec
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-21 14:42 --- This is not a mis applied patch (as I created the patch). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
[Bug rtl-optimization/26780] Build fails while making ../../../unxlngi6.pro/slo/cellsuno.obj on LFS6.1, kernel 2.6.14.3
--- Comment #4 from gratbau at cantv dot net 2006-03-21 15:00 --- Subject: Re: Build fails while making ../../../unxlngi6.pro/slo/cellsuno.obj on LFS6.1, kernel 2.6.14.3 Thanks, it was most certainly that condition. Restricting the number of concurrent running programs solved the issue. Where could I find related information on different type of errors and their symptoms so as to identify the simple ones the way you did it? Thanks, Alonso pinskia at gcc dot gnu dot org wrote: >--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-21 14:09 >--- >g++: Internal error: Killed (program cc1plus) > > >This means it ran out of memory. > > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26780
[Bug libstdc++/26777] sync_with_stdio(false) triggers bug with sgetc and pubseekoff
--- Comment #3 from sam at quux dot dropbear dot id dot au 2006-03-21 14:59 --- Sorry - I should have confirmed it on at least one other platform before submitting. So I've done so now! Exactly the same behaviour occurs on a i386-redhat-linux host with gcc version 4.0.0 20050519 (Red Hat 4.0.0-8). Also confirmed on x86_64-pc-linux-gnu with an earlier version of gcc under Gentoo, gcc version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8). I'd like to try it against a clean install of the latest stable gcc and libc versions, but unfortunately right now I do not have the time to set this up, nor to run through the actual libstdc++ source and see if I can spot what is going on. That the same buggy behaviour is exhibited on two different linux platforms, and across a series of gcc versions from 3.4.4 to 4.0.2, does point towards it being an actual libstdc++ bug though I think. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26777
[Bug bootstrap/25435] stage build no longer works
--- Comment #5 from hjl at lucon dot org 2006-03-21 15:09 --- When I make a backend change, "make" at the top level still tries to rebuild all libraries, even though nothing in library will be recompiled. When Java is enabled, it may take a while just to check if libjava needs to be recompiled. Is there an option to say I only want to rebuild compiler, not libraries? -- hjl at lucon dot org changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2006-03-21 15:09:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25435
[Bug tree-optimization/26781] [4.2 Regression] ICE in tree-ssa-pre.c at create_component_ref_by_piec
--- Comment #5 from malitzke at metronets dot com 2006-03-21 15:02 --- The two "if (tree_code(genop) == VALUE_HANDLE) at lines 2190 of tree-ssa-pre.c look suspicious to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
[Bug rtl-optimization/26780] Build fails while making ../../../unxlngi6.pro/slo/cellsuno.obj on LFS6.1, kernel 2.6.14.3
--- Comment #3 from gratbau at cantv dot net 2006-03-21 14:14 --- Created an attachment (id=11083) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11083&action=view) Source file This is the file last mentioned in the output before the fail -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26780
[Bug c++/26780] Build fails while making ../../../unxlngi6.pro/slo/cellsuno.obj on LFS6.1, kernel 2.6.14.3
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-21 14:09 --- g++: Internal error: Killed (program cc1plus) This means it ran out of memory. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||memory-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26780
[Bug tree-optimization/26781] [4.2 Regression] ICE in tree-ssa-pre.c at create_component_ref_by_piec
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-03-21 15:14 --- Subject: Re: [4.2 Regression] ICE in tree-ssa-pre.c at create_component_ref_by_piec On Tue, 2006-03-21 at 15:02 +, malitzke at metronets dot com wrote: > > --- Comment #5 from malitzke at metronets dot com 2006-03-21 15:02 > --- > The two "if (tree_code(genop) == VALUE_HANDLE) at lines 2190 of tree-ssa-pre.c > look suspicious to me. > > They aren't suspicious at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
[Bug tree-optimization/26781] ICE in tree-ssa-pre.c at create_component_ref_by_piec
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-21 14:44 --- Do you have a testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
[Bug tree-optimization/26781] [4.2 Regression] ICE in tree-ssa-pre.c at create_component_ref_by_piec
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-21 14:56 --- Reducing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|i686-linux-gnu | GCC host triplet|i686-linux-gnu | GCC target triplet|i686-linux-gnu | Summary|ICE in tree-ssa-pre.c at|[4.2 Regression] ICE in |create_component_ref_by_piec|tree-ssa-pre.c at ||create_component_ref_by_piec Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
[Bug tree-optimization/13876] loop not fully optimized
--- Comment #7 from law at redhat dot com 2006-03-21 15:08 --- This is a loop optimization issue, not a jump threading bug. To really optimize this loop well we will likely need the kinds of analysis found in "Beyond Induction Variables", the classic paper describing loop flip-flops and other interesting loop variables that are not simple induction variables. Anyway, I'm removing this from the set of bugs related to jump threading. Jeff -- law at redhat dot com changed: What|Removed |Added CC|law at gcc dot gnu dot org | OtherBugsDependingO|19794 | nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13876
[Bug bootstrap/25435] stage build no longer works
--- Comment #6 from paolo dot bonzini at lu dot unisi dot ch 2006-03-21 15:53 --- Subject: Re: stage build no longer works hjl at lucon dot org wrote: > --- Comment #5 from hjl at lucon dot org 2006-03-21 15:09 --- > When I make a backend change, "make" at the top level still tries to rebuild > all libraries, even though nothing in library will be recompiled. When Java > is enabled, it may take a while just to check if libjava needs to be > recompiled. > Is there an option to say I only want to rebuild compiler, not libraries? > One particular stage: "make all-stageN" All stages: "make stageN-bubble" (usually N=3 of course) All this is now documented in gcc's manual. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25435
[Bug target/26778] GCC4 moves the result of a conditional block through inadequate registers
--- Comment #2 from guillaume dot melquiond at ens-lyon dot fr 2006-03-21 15:27 --- > But using the *ps variants on an SSE1 target is ok - the xmm > registers are just used as temporary storage. I can't really think of situations where it makes sense. If this a temporary storage, it means this is the result of some computations and it will be used in some other computations. In my example, the temporary "th" is the sum of two doubles x[1] and x[2], and it will later be added to the double x[0]. I don't really know the SSE instruction set, but I can't think of a situation where a *ps instruction will give a double result or take a double value. So, in order for an xmm register to act as a temporary, it means that the following pattern has to be used : 1. do a fp computation, the result is in a fp register 2. store this fp register on the stack 3. load this stack memory in the xmm register 4. do other things 5. store this xmm register on the stack 6. load this stack memory in an fp register 7. do a fp computation with this fp register Using a xmm register with double type on SSE1 requires steps 2,3 and 5,6. So it would make a lot more sense to me to skip steps 3 and 5. Step 6 should directly load the value stored at step 2, there is no point in going through a xmm register and doing an additional load+store. Sorry if I missed something. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
[Bug tree-optimization/18046] Missed jump threading optimization
--- Comment #9 from law at redhat dot com 2006-03-21 15:57 --- We've got zero chance of threading the jump in this case until the partially redundant load from "i" is removed. Daniel -- there's a pretty obvious redundant load from the global variable "i" in this testcase. I haven't investigated why PRE is missing this obvious redundancy. Jeff -- law at redhat dot com changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18046
[Bug c++/26782] reject [valid?] template specialization.
--- Comment #1 from pluto at agmk dot net 2006-03-21 15:58 --- hmm $14.7.3/2 explains it very well. sorry for the noise. -- pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26782
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-03-21 16:02 --- Any updates on this? It get's in the way of loop versioning conditionals which I now have to decompose manually into chained if's :/ -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
[Bug tree-optimization/18046] Missed jump threading optimization
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-21 16:05 --- (In reply to comment #9) > Daniel -- there's a pretty obvious redundant load from the global > variable "i" in this testcase. I haven't investigated why PRE > is missing this obvious redundancy. Because tree level load PRE does not handle global variables, there is another bug about this, PR 23455. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18046
[Bug target/26504] compute_frame_pointer_to_cfa_displacement error for avr target with --with-dwarf2
--- Comment #7 from yannick dot podgorski at kuantic dot com 2006-03-21 16:08 --- Hi, I have the same error. I use : - binutils-2.16.1, - gcc 4.1.0, - avr-libc 1.4.3 But it works with gcc 4.0.3. I use the doc : www.nongnu.org/avr-libc/user-manual/install_tools.html make[3]: Entering directory `/home/avrdev-4/gcc-4.1.0/obj-avr/gcc' /home/avrdev-4/gcc-4.1.0/obj-avr/./gcc/xgcc -B/home/avrdev-4/gcc-4.1.0/obj-avr/./gcc/ -B/home/avrdev-4//avr/bin/ -B/home/avrdev-4//avr/lib/ -isystem /home/avrdev-4//avr/include -isystem /home/avrdev-4//avr/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF -Dinhibit_libc -mcall-prologues -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -DL_fixunssfsi -c ../../gcc/libgcc2.c -o libgcc/./_fixunssfsi.o ../../gcc/libgcc2.c: In function '__fixunssfsi': ../../gcc/libgcc2.c:1499: internal compiler error: in compute_frame_pointer_to_cfa_displacement, at dwarf2out.c:10445 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [libgcc/./_fixunssfsi.o] Erreur 1 make[3]: Leaving directory `/home/avrdev-4/gcc-4.1.0/obj-avr/gcc' make[2]: *** [stmp-multilib] Erreur 2 make[2]: Leaving directory `/home/avrdev-4/gcc-4.1.0/obj-avr/gcc' make[1]: *** [all-gcc] Erreur 2 make[1]: Leaving directory `/home/avrdev-4/gcc-4.1.0/obj-avr' make: *** [all] Erreur 2 Thanks a lot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
[Bug c++/26783] New: friend functions defined in-class not added to enclosing namespace
namespace foo {
class obj {
friend void create() { }
};
}
int main()
{
foo::create();
}
test.cpp: In function 'int main()':
test.cpp:9: error: 'create' is not a member of 'foo'
--
Summary: friend functions defined in-class not added to enclosing
namespace
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: squell at alumina dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26783
[Bug tree-optimization/26781] [4.2 Regression] ICE in tree-ssa-pre.c at create_component_ref_by_piec
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-21 16:13 ---
And here is a testcase without a simplifing opportunity:
void zconfdump(__SIZE_TYPE__ i)
{
for (;;)
{
char __a0;
__a0 = ("\"\\")[i];
if (__a0)
return;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
[Bug c++/21581] (optimisation) Functions in anonymous namespaces should default to "hidden" visibility
--- Comment #11 from jason at gcc dot gnu dot org 2006-03-21 16:15 --- Subject: Bug 21581 Author: jason Date: Tue Mar 21 16:15:25 2006 New Revision: 112250 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112250 Log: PR c++/21581 * parser.c (cp_parser_declaration): Support attributes on anonymous namespaces. * name-lookup.c (push_namespace_with_attribs): Anonymous namespaces default to hidden visibility. Added: trunk/gcc/testsuite/g++.dg/ext/visibility/anon1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/cp/parser.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21581
[Bug c++/26783] friend functions defined in-class not added to enclosing namespace
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-21 16:15 --- Friend functions are not injected as declarations. See http://gcc.gnu.org/gcc-4.1/changes.html. This is invalid C++. Use -ffriend-injection to get back the old behavior. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26783
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
--- Comment #13 from dnovillo at gcc dot gnu dot org 2006-03-21 16:19 --- (In reply to comment #12) > Any updates on this? It get's in the way of loop versioning conditionals > which > I now have to decompose manually into chained if's :/ > Nope. I'm unlikely to work on this any time soon. Maybe in another couple of months. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dnovillo 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=15911
[Bug c++/26691] Wrong code for constructor with default value
--- Comment #3 from jakub at gcc dot gnu dot org 2006-03-21 16:21 --- Subject: Bug 26691 Author: jakub Date: Tue Mar 21 16:21:24 2006 New Revision: 112251 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112251 Log: PR c++/26691 * cp-gimplify.c (cxx_omp_clause_apply_fn): Handle default arguments. * testsuite/libgomp.c++/pr26691.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/pr26691.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26691
[Bug tree-optimization/26781] [4.2 Regression] ICE in tree-ssa-pre.c at create_component_ref_by_piec
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-21 16:26 --- I am testing the following patch: Index: tree-ssa-pre.c === --- tree-ssa-pre.c (revision 112250) +++ tree-ssa-pre.c (working copy) @@ -2246,6 +2246,7 @@ create_component_ref_by_pieces (basic_bl case PARM_DECL: case RESULT_DECL: case SSA_NAME: +case STRING_CST: return genop; default: gcc_unreachable (); It works for the two simplified testcase (and the orginal one) but I would like some comments from Daniel about this patch before submitting it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
[Bug bootstrap/25435] stage build no longer works
--- Comment #7 from hjl at lucon dot org 2006-03-21 16:27 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25435
[Bug bootstrap/25435] stage build no longer works
--- Comment #8 from hjl at lucon dot org 2006-03-21 16:27 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25435
[Bug c++/21764] visibility attributes on namespace scope
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-03-21 16:32 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764
[Bug c++/19238] cannot change visibility of static variable in function template
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-21 16:32 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19238
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-03-21 16:48 --- And I'm getting lost in decomposing such a conditional into BBs and COND_EXPRs and GOTOs and adding edges and whatnot. This sucks. Where's the helper routine that I'm not finding? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
[Bug c++/20665] poor diagnostic for missing semicolon at end of template struct declaration
--- Comment #4 from tbm at cyrius dot com 2006-03-21 16:48 --- (In reply to comment #1) > On the mainline I get: > t.cc:1: error: template declaration of 'enum' > t.cc:2: error: multiple types in one declaration > > There might be a dup of this bug somewhere. Bug #16189 is the same and has some information why it's so hard to improve the error message. Please mark them a dupes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20665
[Bug c++/20665] poor diagnostic for missing semicolon at end of template struct declaration
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-21 16:50 --- (In reply to comment #4) Ok. *** This bug has been marked as a duplicate of 16189 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20665
[Bug c++/16189] obfuscated error message for missing semicolon after declaration in C++
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-21 16:50 --- *** Bug 20665 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16189
[Bug fortran/26784] New: Fortran frontend ICEs on -fmudflap
Compiling any Fortran file with -fmudflap results in an ICE: f951: warning: command line option "-fno-builtin" is valid for C/C++/ObjC/ObjC++ but not for Fortran lall.f:0: internal compiler error: mudflap: this language is not supported Please submit a full bug report, [etc.] In addition the warning is bogus as "-fno-builtin" wasn't specified. This happens since 4.0.0. -- Summary: Fortran frontend ICEs on -fmudflap Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, monitored Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26784
[Bug tree-optimization/18046] Missed jump threading optimization
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-03-21 16:57 --- Subject: Re: Missed jump threading optimization On Tue, 2006-03-21 at 15:57 +, law at redhat dot com wrote: > > --- Comment #9 from law at redhat dot com 2006-03-21 15:57 --- > We've got zero chance of threading the jump in this case until the > partially redundant load from "i" is removed. > > Daniel -- there's a pretty obvious redundant load from the global > variable "i" in this testcase. I haven't investigated why PRE > is missing this obvious redundancy. It doesn't deal with loads from global variables because we need to place a value number on each "instance" that occurs in the program, but can't easily because they are all shared. I will get to it eventually. > > Jeff > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18046
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
--- Comment #15 from law at redhat dot com 2006-03-21 16:57 --- Subject: Re: VRP/DOM does not like TRUTH_AND_EXPR On Tue, 2006-03-21 at 16:19 +, dnovillo at gcc dot gnu dot org wrote: > > --- Comment #13 from dnovillo at gcc dot gnu dot org 2006-03-21 16:19 > --- > (In reply to comment #12) > > Any updates on this? It get's in the way of loop versioning conditionals > > which > > I now have to decompose manually into chained if's :/ > > > Nope. I'm unlikely to work on this any time soon. Maybe in another couple of > months. How hard would it be to register the asserts for these dependency change at the same time we register the initial assert. It seems there's only two cases we care about. If we're asserting an SSA_NAME has a nonzero (true) value and the SSA_NAME is defined by a TRUTH_AND_EXPR, then we know both operands of the TRUTH_AND_EXPR must also be true (note we would then recurse on the operands). Similarly if we're asserting an SSA_NAME is zero (false) and the SSA_NAME is defined by a TRUTH_OR_EXPR, then we know that both operands of the TRUTH_OR_EXPR must also be zero (false). Again recurse on the operands. I don't *think* it would be that hard. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
[Bug c++/21581] (optimisation) Functions in anonymous namespaces should default to "hidden" visibility
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-03-21 17:01 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21581
[Bug c++/26691] Wrong code for constructor with default value
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-21 17:02 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26691
[Bug c++/26785] New: "extra qualification" error gives line number of end of declaration
The line number mentioned in the "extra qualification" error is not
ideal. Instead of showing the line number on which the extra
qualification actually occurs it shows the last line of the
declaration.
(sid)6102:[EMAIL PROTECTED]: ~] cat > test.cpp
class foo {
foo::foo(int a,
int b,
int c);
};
int main() {
}
(sid)6103:[EMAIL PROTECTED]: ~] g++ test.cpp
test.cpp:4: error: extra qualification `foo::' on member `foo'
I'd like to see "test.cpp:2: ..." here.
Presumably it checks things like that after reading a complete
declaration. I would have thought it could track what the first line
of the declaration was though.
seen with:
gcc version 4.1.0 20060219 (prerelease) (Debian 4.1-0exp9)
gcc version 4.0.3 (Debian 4.0.3-1) [using -pedantic]
--
Summary: "extra qualification" error gives line number of end of
declaration
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26785
[Bug c++/26785] "extra qualification" error gives line number of end of declaration
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-21 17:05 --- This is the crazy parser getting the line number "wrong". -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26785
[Bug c++/26785] "extra qualification" error gives line number of end of declaration
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-21 17:06:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26785
[Bug c++/21581] (optimisation) Functions in anonymous namespaces should default to "hidden" visibility
--- Comment #13 from sabre at nondot dot org 2006-03-21 18:03 --- Pardon the potentially silly question here, but why 'hidden'? Why not TREE_PUBLIC(decl) = 0? It seems that members of anonymous namespaces should be completely internal, and not depend on platform support for hidden visibility. If I understand correctly, marking something hidden places more slightly more burden on the static linker than marking it internal, and not all platforms support hidden. Should I (re)open a new bug for to request TREE_PUBLIC(decl) = 0 behavior? -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21581
[Bug c++/21581] (optimisation) Functions in anonymous namespaces should default to "hidden" visibility
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-03-21 18:05 --- (In reply to comment #13) > Should I (re)open a new bug for to request TREE_PUBLIC(decl) = 0 behavior? PR 10591 is for that issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21581
[Bug c++/21581] (optimisation) Functions in anonymous namespaces should default to "hidden" visibility
--- Comment #15 from sabre at nondot dot org 2006-03-21 18:06 --- Great, thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21581
[Bug c++/10591] use ODR rules to make C++ objects not be TREE_PUBLIC
--- Comment #18 from jason at gcc dot gnu dot org 2006-03-21 18:22 --- I think the summary is misleading; the change requested is an optimization. The testcase breaks because PCH breaks anonymous namespace naming so that it gets the same name in all translation units. I assume that the same problem happens with other users of get_file_function_name. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10591
[Bug tree-optimization/26781] [4.2 Regression] ICE in tree-ssa-pre.c at create_component_ref_by_piec
--- Comment #11 from malitzke at metronets dot com 2006-03-21 18:26 ---
While I have your attention I would propose this more comprehensive patch:
--- tree-ssa-pre.org.c 2006-03-21 12:55:12.0 -0500
+++ tree-ssa-pre.c 2006-03-21 13:11:36.0 -0500
@@ -2192,11 +2192,10 @@
tree found = bitmap_find_leader (AVAIL_OUT (block), expr);
if (found)
return found;
+ else
+genop = VALUE_HANDLE_EXPR_SET (expr)->head->expr;
}
- if (TREE_CODE (genop) == VALUE_HANDLE)
-genop = VALUE_HANDLE_EXPR_SET (expr)->head->expr;
-
switch TREE_CODE (genop)
{
case ARRAY_REF:
@@ -2219,6 +2218,7 @@
op2, op3);
return folded;
}
+ break;
case COMPONENT_REF:
{
tree op0;
@@ -2246,6 +2246,7 @@
case PARM_DECL:
case RESULT_DECL:
case SSA_NAME:
+case STRING_CST:
return genop;
default:
gcc_unreachable ();
It contains Andy's plus one simplifying patch and a break for consistency. The
consistency one could be invalidated via side effects from bitmap_find_leader.
I am am presently rebootstrapping (cc, c++, fortran, objc, java) to verify to
the best of my ability.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
[Bug c++/26690] ICE in get_callee_fndecl, at tree.c:5806 with OpenMP
--- Comment #2 from jakub at gcc dot gnu dot org 2006-03-21 18:35 --- Subject: Bug 26690 Author: jakub Date: Tue Mar 21 18:35:20 2006 New Revision: 112253 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112253 Log: PR c++/26690 * tree.c (get_callee_fndecl): If CALL is error_mark_node, return it immediately. * g++.dg/gomp/pr26690-1.C: New test. * g++.dg/gomp/pr26690-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr26690-1.C trunk/gcc/testsuite/g++.dg/gomp/pr26690-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26690
[Bug tree-optimization/26781] [4.2 Regression] ICE in tree-ssa-pre.c at create_component_ref_by_piec
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-03-21 18:53 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
[Bug tree-optimization/26781] [4.2 Regression] ICE in tree-ssa-pre.c at create_component_ref_by_piec
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-03-21 18:58 --- Subject: Bug 26781 Author: pinskia Date: Tue Mar 21 18:58:50 2006 New Revision: 112254 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112254 Log: 2006-03-21 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/26781 * tree-ssa-pre.c (create_component_ref_by_pieces): Handle STRING_CST. 2006-03-21 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/26781 * gcc.c-torture/compile/pr26781-1.c: New test. * gcc.c-torture/compile/pr26781-2.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr26781-1.c trunk/gcc/testsuite/gcc.c-torture/compile/pr26781-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
[Bug c++/10591] use ODR rules to make C++ objects not be TREE_PUBLIC
--- Comment #19 from cpence at gmail dot com 2006-03-21 19:12 --- @#18: I disagree. This bug is the only thing preventing anonymous namespaces from working together with PCH. As such, it's a bug, insofar as it keeps a _very_ worthwhile feature (namely, precompiling massive C++ headers like Boost) from working. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10591
[Bug c++/10591] use ODR rules to make C++ objects not be TREE_PUBLIC
--- Comment #20 from jason at redhat dot com 2006-03-21 19:19 --- Subject: Re: use ODR rules to make C++ objects not be TREE_PUBLIC Sorry I wasn't clear; I agree that this is an important bug. I meant that fixing the unique anonymous namespace name in the presence of PCH is the right way to fix it. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10591
[Bug c++/26786] New: template class method defined out-of-line is not instantiated
A template class member function that is defined out-of-line with an
associated explicit template instantiation is not instantiated by g++ 4.0.x.
No warnings or error messages are given. Using earlier g++ versions, the
member function is instantiated and placed in the object file.
Confirmed function is instantiated with
g++ 3.3.0/linux, 3.4.4/cygwin
Confirmed function is not instantiated with
g++ 4.0.1/linux, 4.0.2/linux
Source:
// ATemplate.h
template
class ATemplate
{
T const n;
public:
ATemplate () : n (1) { }
T GetValue () const;
};
template class ATemplate;
// ATemplate.cpp
#include "ATemplate.h"
template
T ATemplate::GetValue () const
{
return n;
}
Compile:
% g++ -c ATemplate.cpp
Contents of object file:
-
g++ 3.4.4 (cygwin):
% g++ -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --prefix=/usr
--exec-prefix=/usr --sysconfdir=
/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --enable-langua
ges=c,ada,c++,d,f77,java,objc --enable-nls --without-included-gettext
--enable-version-specific-runtime-libs -
-without-x --enable-libgcj --disable-java-awt --with-system-zlib
--enable-interpreter --disable-libgcj-debug -
-enable-threads=posix --enable-java-gc=boehm --disable-win32-registry
--enable-sjlj-exceptions --enable-hash-s
ynchronization --enable-libstdcxx-debug : (reconfigured)
Thread model: posix
gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
% nm -C ATemplate.o
T ATemplate::ATemplate()
T ATemplate::ATemplate()
T ATemplate::GetValue() const
-
g++ 4.0.1 (Linux x86_64):
% g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/nrel/ty/build/devel/gcc/gcc-4.0.1/configure
--prefix=/usr2/OS-DEPENDENT/Linux_Generic_x86_64/gcc-4.0.1
Thread model: posix
gcc version 4.0.1
% nm -C ATemplate.o
W ATemplate::ATemplate()
W ATemplate::ATemplate()
U __gxx_personality_v0
--
Summary: template class method defined out-of-line is not
instantiated
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tom dot hilinski at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26786
[Bug fortran/26787] New: Assigning to function causes ice in gfortran
The following incorrect code causes: simple.f90: In function bar: simple.f90:4: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:355 Code: module simple implicit none contains integer function foo() foo = 10 end function foo subroutine bar() foo = 10 end subroutine bar end module simple This should cause an error, rather than an internal compiler error. -- Summary: Assigning to function causes ice in gfortran Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jjcogliati-r1 at yahoo dot com 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=26787
[Bug c++/26786] template class method defined out-of-line is not instantiated
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-21 20:51 --- *** This bug has been marked as a duplicate of 24511 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26786
[Bug c++/24511] [DR 470] explicit instantiation/extern template unsats on symbols defined later
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-21 20:51 --- *** Bug 26786 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tom dot hilinski at comcast ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24511
[Bug tree-optimization/23745] VRP does not get information from casts from a smaller precision
--- Comment #2 from law at redhat dot com 2006-03-21 21:02 --- Fixed with today's checkin to tree-vrp.c. -- law at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23745
[Bug fortran/26787] Assigning to function causes ice in gfortran
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-21 21:04 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2006-03-21 21:04:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26787
[Bug c++/26788] New: optimization of expression templates not as performant as g++ 4.0.2
Hi, I just installed gcc 4.1.0 to compile my template expression matrix arithmetric library (a la Blitz). I recently did benchmarks with g++ 3.4.4 and 4.0.2 an I was pretty much impressed that g++ 4.0.2 managed to optimize the expressions such that I obtained performance nearly twice as fast as with g++ 3.4.4, and even better the performance was the same as my hand coded pointer only implementation. I was rather happy with this result. It seems that the handling of pointer arrays that are stored in a struct that represents the expression has been significantly improved. Now, the downside. I tried 4.1.0 and I noticed that the performance dropped down too a level even worse than gcc 3.4.4. I wondered about the reason and scanned the optimization parameters. I found salias-max-implicit-fields with a default value of 5. I guessed that might be the reason and increased the value to 50. With this value I've got back the impressive performance of g++ 4.0.2. I wonder why the default value has been set so low that apparently it cripples the optimizer to a level of optimization consierably below what has been achieved with g++ 4.0.2 (where this option does not exist). Does this option negatively affects performance elsewhere? If not it seems to me that a default value that resembles the settings in gcc 4.0.2 would be more sensible. Kind regards, and thanks anyway for this great compiler suite. Axel -- Summary: optimization of expression templates not as performant as g++ 4.0.2 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: roebel at ircam dot fr 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=26788
[Bug middle-end/23442] Compiler fails to build - internal compiler error: in do_SUBST, at combine.c:462
--- Comment #2 from arnold-j at t-online dot de 2006-03-21 21:11 --- This happens with *all* versions of m68k-elf-gcc I tried to build (3.3.6, 3.4.5, 3.4.6, 4.0.2, 4.0.3). Host gcc: gcc version 4.0.3 20060212 (prerelease) (Debian 4.0.2-9) Example: m68k-elf-gcc 3.4.6, configured with: ../../gcc-3.4.6/configure --target=m68k-elf --prefix=/opt/m68k --enable-languages=c Result: /home/jens/build/gcc/gcc/xgcc -B/home/jens/build/gcc/gcc/ -B/opt/m68k/m68k-elf/bin/ -B/opt/m68k/m68k-elf/lib/ -isystem /opt/m68k/m68k-elf/include -isystem /opt/m68k/m68k-elf/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../../gcc-3.4.6/gcc -I../../../gcc-3.4.6/gcc/. -I../../../gcc-3.4.6/gcc/../include -m68000 -DL_fixdfdi -c ../../../gcc-3.4.6/gcc/libgcc2.c -o libgcc/m68000/_fixdfdi.o ../../../gcc-3.4.6/gcc/libgcc2.c: In function `__fixdfdi': ../../../gcc-3.4.6/gcc/libgcc2.c:1277: internal compiler error: in do_SUBST, at combine.c:447 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [libgcc/m68000/_fixdfdi.o] Fehler 1 make[2]: Leaving directory `/home/jens/build/gcc/gcc' make[1]: *** [stmp-multilib] Fehler 2 make[1]: Leaving directory `/home/jens/build/gcc/gcc' make: *** [all-gcc] Fehler 2 The line numbers vary with gcc versions, but it's always an ICE of xgcc in do_SUBST (combine.c), trying to compile _fixdfdi (libgcc2.c) -- arnold-j at t-online dot de changed: What|Removed |Added CC||arnold-j at t-online dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23442
[Bug libgomp/26384] FAIL: libgomp.c/appendix-a/a.18.1.c execution test
--- Comment #1 from sje at gcc dot gnu dot org 2006-03-21 21:12 --- Subject: Bug 26384 Author: sje Date: Tue Mar 21 21:12:00 2006 New Revision: 112257 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112257 Log: PR libgomp/26384 * config/pa/pa64-hpux.h (LIB_SPEC): Fix for -mt and -pthread options. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa64-hpux.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26384
[Bug c++/26788] optimization of expression templates not as performant as g++ 4.0.2
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-21 21:14 --- salias-max-implicit-fields did not exist in 4.0.x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26788
[Bug c++/26788] optimization of expression templates not as performant as g++ 4.0.2
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-21 21:27 --- And the reason why salias-max-implicit-fields is set so low is to keep the compile time in check since we get bug reports about that also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26788
[Bug c++/26788] optimization of expression templates not as performant as g++ 4.0.2
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-21 21:28 --- Also do you have a testcase that can be attached to the bug since the information here is not enough to figure out what is going wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26788
[Bug middle-end/23442] Compiler fails to build - internal compiler error: in do_SUBST, at combine.c:462
--- Comment #3 from arnold-j at t-online dot de 2006-03-21 21:30 --- Created an attachment (id=11085) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11085&action=view) The preprocessed source file causing the error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23442
[Bug rtl-optimization/25569] [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops
--- Comment #12 from rakdver at gcc dot gnu dot org 2006-03-21 21:35 --- (In reply to comment #11) > This is definitely a bug in loop-iv.c -- once biv_p (SET_DEST (single_set > (insn))) returns true, iv_analyze_result must succeed as well. While I still consider this desirable, it is somewhat difficult to achieve (it requires big changes to iv_analyze_... routines, and I am not even quite sure the gain would be worth the cost). Replacing the assert in analyze_iv_to_split_insn with return NULL should be safe, in the meantime. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25569
[Bug c++/26690] ICE in get_callee_fndecl, at tree.c:5806 with OpenMP
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-21 21:59 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26690
[Bug libgomp/26384] FAIL: libgomp.c/appendix-a/a.18.1.c execution test
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-21 21:59 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26384
