Ada testsuite issues with c74004a, c940010, c94002f, and c94002g... (and more?)
I have to manually kill at least c74004a, c940010, c94002f, and c94002g... (and more?) Iis there something fishy going on again or would this more probably be related to my system? Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u: (auroralinux corona + rathann's and rzm's FC3 updates) binutils-2.16.91.0.2-4.sparc (from Fedora Core development) bison-1.875c-2.sparc dejagnu-1.4.4-2.noarch expect-5.42.1-1.sparc gcc-3.4.3-22.sparc.sparc gcc4-4.0.0-0.41.sparc.sparc glibc-2.3.5-0.fc3.1.sparcv9 glibc-2.3.5-0.fc3.1.sparc64 glibc-devel-2.3.5-0.fc3.1.sparc64 glibc-devel-2.3.5-0.fc3.1.sparc glibc-headers-2.3.5-0.fc3.1.sparc glibc-kernheaders-2.6-20sparc.sparc gmp-4.1.4-3sparc.sparc gmp-4.1.4-3sparc.sparc64 gmp-devel-4.1.4-3sparc.sparc gmp-devel-4.1.4-3sparc.sparc64 kernel-2.6.11-1.1305sp1.sparc64 package kernel-devel is not installed package kernel-smp is not installed libgcc-3.4.3-22.sparc.sparc libgcc-3.4.3-22.sparc.sparc64 libstdc++-3.4.3-22.sparc.sparc libstdc++-3.4.3-22.sparc.sparc64 libstdc++-devel-3.4.3-22.sparc.sparc64 libstdc++-devel-3.4.3-22.sparc.sparc make-3.80-5.sparc nptl-devel-2.3.5-0.fc3.1.sparcv9 tcl-8.4.7-2.sparc LAST_UPDATED: Fri Sep 2 06:51:30 UTC 2005 I do get a lot of failures like this: Execution terminated by abort of environment task -- Cheers, /ChJ
Problems with the m32c target and M16C6N cpu
I have built a cross-gcc (gcc Aug 19th, binutils Aug. 21st, newlib Aug.
27th) on cygwin for the m32c target. The small test program that I use is:
struct bit_def {
charb0:1;
charb1:1;
charb2:1;
charb3:1;
charb4:1;
charb5:1;
charb6:1;
charb7:1;
};
union byte_def{
struct bit_def bit;
charbyte;
};
#define pd5_addr (*(volatile union byte_def *) 0x03eb) /* Port P5
direction register */
#define p5_addr (*(volatile union byte_def *) 0x03e9) /* Port P5
register */
#define pd5 pd5_addr.byte
#define p5_0 p5_addr.bit.b0
int main ()
{
int i=0;
pd5 = 1; // set p5_0 output
while (1)
{
while (i++1000)
p5_0=1;
while (i++2000)
p5_0=0;
i=0;
}
return 0;
}
The purpose of the program is to just toggle the output of Port 5_0
between 0 and 1. Actually, after building an object file with gcc
-mcpu=m16c, objcopy -Osrec, and flashing, there happens just nothing on
my M16C6N testboard. And when I try the file with the kd30 debugger, it
just hangs up.
Does anyone have a clue on what I'm doing wrong?
So long
Frank
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: Language Changes in Bug-fix Releases?
Richard B. Kreckel [EMAIL PROTECTED] wrote: Since the creation of the GCC 4.0 branch back in February a number of minor C++ language changes seem to have slipped in. Let me mention just two examples: [...] Are you really, really sure such language tightening is appropiate for bug-fix releases? (Note that the examples above are not regressions since gcc-3.4.y accept both of them.) Notice that we consider up to gcc 2.95 to check for regression status. If the code was correctly rejected in any version of GCC up to 2.95, then it is a regression, even if gcc 3.4 was wrong. But even if that couple of snippets weren't regressions, there are very high chances that a small variations of them could be a regression -- in fact, if the bug was fixed, it *must* have been a regression! Somebody found it, reported it in Bugzilla, and it got fixed. I suggest you to do some Bugzilla archeology. We don't really fix anything in dot releases unless there is a regression bug open in Bugzilla. Also, we try and keep the patch to fix the bug as minimal as possible -- sometimes, there is also a more complete and invasive patch to properly fix the same regression which is committed to HEAD. We can't do more than this. If a patch to fix a regression accidentally also fixes a very similar testcase which is not a regression, then let it be. -- Giovanni Bajo
Re: Problems with the m32c target and M16C6N cpu
The most likely problem is that you're not providing a reset vector that points at your program, so the board doesn't know the starting location (neither kd30 nor the flash program honor the start address s-record). I should probably have the tools do that automatically. With the tools you have, create a reset.S file that looks like this: .section .resetvec,a .word _start .text and add that to your compile line. I just checked in a fix yesterday that lets you do this: typedef void (*ifunc)() __attribute__((mode(SI))); extern void start(); const ifunc __attribute__((section(.resetvec))) reset_vector = start; Anyway, you can also use objdump -f on the ELF executable to find out where it wants its start address, then flash the chip, then verify that the program was loaded there. Then you can double-click on $pc in the register window to force it to start in the right place.
GCC 4.0.1 bootstrap successfully built and installed
Output from running srcdir/config.guess i686-pc-linux-gnu The output of `gcc -v' Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0.1/configure Thread model: posix gcc version 4.0.1 The distribution name and version from /etc/issue Welcome to SuSE Linux 9.3 (i586) - Kernel \r (\l). The version of the Linux kernel, from `uname -a'. Linux mgc 2.6.11.4-20a-default #1 Wed Mar 23 21:52:37 UTC 2005 i686 athlon i386 GNU/Linux The version of glibc from `rpm -q glibc' glibc-2.3.4-23.4 Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Re: Ada testsuite issues with c74004a, c940010, c94002f, and c94002g... (and more?)
Ada is quite broken right now - see also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23646 Right, sorry about that. I was almost ready to commit the fix on friday, but got stuck because someone was doing a long cvs operation locking any other use, so I had to leave before being able to commit the change. I should be able to get to it on monday, assuming cvs is available then. Arno
Successful 4.0.1 build
Build on Win32 under MinGW 3.4.2 ../gcc-4.0.1/config.guess i686-pc-mingw32 gcc -v Using built-in specs. Target: i686-pc-mingw32 Configured with: ../gcc-4.0.1/configure : (reconfigured) ../gcc-4.0.1/configure --prefix=/mingw --disable-nls Thread model: win32 gcc version 4.0.1 languages c, c++
Re: Ada testsuite issues with c74004a, c940010, c94002f, and c94002g... (and more?)
Arnaud Charlet [EMAIL PROTECTED] writes: Ada is quite broken right now - see also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23646 Right, sorry about that. I was almost ready to commit the fix on friday, but got stuck because someone was doing a long cvs operation locking any other use, so I had to leave before being able to commit the change. Do you have a patch that you could send already for others to use? I should be able to get to it on monday, assuming cvs is available then. Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpYEAYnp10td.pgp Description: PGP signature
[Bug target/23706] [4.1 Regression] ICE in rtl_verify_flow_info_1
--- Additional Comments From kkojima at gcc dot gnu dot org 2005-09-03 07:07 --- There are no new failures on c/c++/objc tests with the patch but it makes 120 new failures on gfortran execution test. The patched compiler still fails for libjava/interpret.cc and Andrew's reduced testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23706
[Bug bootstrap/23711] New: [4.1 regression] [s390] bootstrap error in libjava (ICE in fixup_eh_region_note)
CVS HEAD 20050901, complete build log at http://buildd.debian.org/fetch.php?pkg=gcc-snapshotver=20050901-1arch=s390stamp=1125582332file=logas=raw if /bin/sh ./libtool --mode=compile /build/buildd/gcc-snapshot-20050901/build/./gcc/xgcc -shared-libgcc -B/build/buildd/gcc-snapshot-20050901/build/./gcc -nostdinc++ -L/build/buildd/gcc-snapshot-20050901/build/s390-linux-gnu/libstdc++-v3/src -L/build/buildd/gcc-snapshot-20050901/build/s390-linux-gnu/libstdc++-v3/src/.libs -B/usr/lib/gcc-snapshot/s390-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/s390-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/s390-linux-gnu/include -isystem /usr/lib/gcc-snapshot/s390-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../src/libjava -I./include -I./gcj -I../../../src/libjava -Iinclude -I../../../src/libjava/include -I../../../src/libjava/classpath/include -I../../../src/libjava/classpath/native/fdlibm -I../../../src/libjava/../boehm-gc/include -I../boehm-gc/include -I../../../src/libjava/libltdl -I../../../src/libjava/libltdl -I../../../src/libjava/.././libjava/../gcc -I../../../src/libjava/../zlib -I../../../src/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/usr/lib/gcc-snapshot\ -DLIBDIR=\/usr/lib/gcc-snapshot/lib\ -DJAVA_HOME=\/usr/lib/gcc-snapshot/jre\ -DBOOT_CLASS_PATH=\/usr/lib/gcc-snapshot/jre/lib/rt.jar\ -DJAVA_EXT_DIRS=\/usr/lib/gcc-snapshot/share/java/ext\ -DGCJ_ENDORSED_DIRS=\/usr/lib/gcc-snapshot/share/java/gcj-endorsed\ -DLIBGCJ_DEFAULT_DATABASE=\/usr/lib/gcc-snapshot/lib/gcj-4.1.0/classmap.db\ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\gcj-4.1.0/classmap.db\ -DTOOLEXECLIBDIR=\/usr/lib/gcc-snapshot/lib\ -g -O2 -D_GNU_SOURCE -MT jni.lo -MD -MP -MF $depbase.Tpo -c -o jni.lo ../../../src/libjava/jni.cc; \ then mv -f $depbase.Tpo $depbase.Plo; else rm -f $depbase.Tpo; exit 1; fi /build/buildd/gcc-snapshot-20050901/build/./gcc/xgcc -shared-libgcc -B/build/buildd/gcc-snapshot-20050901/build/./gcc -nostdinc++ -L/build/buildd/gcc-snapshot-20050901/build/s390-linux-gnu/libstdc++-v3/src -L/build/buildd/gcc-snapshot-20050901/build/s390-linux-gnu/libstdc++-v3/src/.libs -B/usr/lib/gcc-snapshot/s390-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/s390-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/s390-linux-gnu/include -isystem /usr/lib/gcc-snapshot/s390-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../src/libjava -I./include -I./gcj -I../../../src/libjava -Iinclude -I../../../src/libjava/include -I../../../src/libjava/classpath/include -I../../../src/libjava/classpath/native/fdlibm -I../../../src/libjava/../boehm-gc/include -I../boehm-gc/include -I../../../src/libjava/libltdl -I../../../src/libjava/libltdl -I../../../src/libjava/.././libjava/../gcc -I../../../src/libjava/../zlib -I../../../src/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/usr/lib/gcc-snapshot\ -DLIBDIR=\/usr/lib/gcc-snapshot/lib\ -DJAVA_HOME=\/usr/lib/gcc-snapshot/jre\ -DBOOT_CLASS_PATH=\/usr/lib/gcc-snapshot/jre/lib/rt.jar\ -DJAVA_EXT_DIRS=\/usr/lib/gcc-snapshot/share/java/ext\ -DGCJ_ENDORSED_DIRS=\/usr/lib/gcc-snapshot/share/java/gcj-endorsed\ -DLIBGCJ_DEFAULT_DATABASE=\/usr/lib/gcc-snapshot/lib/gcj-4.1.0/classmap.db\ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\gcj-4.1.0/classmap.db\ -DTOOLEXECLIBDIR=\/usr/lib/gcc-snapshot/lib\ -g -O2 -D_GNU_SOURCE -MT jni.lo -MD -MP -MF .deps/jni.Tpo -c ../../../src/libjava/jni.cc -fPIC -DPIC -o .libs/jni.o ../../../src/libjava/jni.cc: In function 'void _Jv_JNI_GetStringUTFRegion(JNIEnv*, java::lang::String*, jsize, jsize, char*)': ../../../src/libjava/jni.cc:1396: internal compiler error: in fixup_eh_region_note, at reload1.c:3808 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [jni.lo] Error 1 make[5]: Leaving directory `/build/buildd/gcc-snapshot-20050901/build/s390-linux-gnu/libjava' -- Summary: [4.1 regression] [s390] bootstrap error in libjava (ICE in fixup_eh_region_note) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: s390-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23711
[Bug bootstrap/23712] New: [4.1 regression] [powerpc] bootstrap error in libjava (ICE in fixup_eh_region_note)
CVS HEAD 20050901 fails to bootstrap on powerpc-linux if /bin/sh ./libtool --mode=compile /build/buildd/gcc-snapshot-20050901/build/./gcc/xgcc -shared-libgcc -B/build/buildd/gcc-snapshot-20050901/build/./gcc -nostdinc++ -L/build/buildd/gcc-snapshot-20050901/build/powerpc-linux-gnu/libstdc++-v3/src -L/build/buildd/gcc-snapshot-20050901/build/powerpc-linux-gnu/libstdc++-v3/src/.libs -B/usr/lib/gcc-snapshot/powerpc-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/powerpc-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/powerpc-linux-gnu/include -isystem /usr/lib/gcc-snapshot/powerpc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../src/libjava -I./include -I./gcj -I../../../src/libjava -Iinclude -I../../../src/libjava/include -I../../../src/libjava/classpath/include -I../../../src/libjava/classpath/native/fdlibm -I../../../src/libjava/../boehm-gc/include -I../boehm-gc/include -I../../../src/libjava/libltdl -I../../../src/libjava/libltdl -I../../../src/libjava/.././libjava/../gcc -I../../../src/libjava/../zlib -I../../../src/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/usr/lib/gcc-snapshot\ -DLIBDIR=\/usr/lib/gcc-snapshot/lib\ -DJAVA_HOME=\/usr/lib/gcc-snapshot/jre\ -DBOOT_CLASS_PATH=\/usr/lib/gcc-snapshot/jre/lib/rt.jar\ -DJAVA_EXT_DIRS=\/usr/lib/gcc-snapshot/share/java/ext\ -DGCJ_ENDORSED_DIRS=\/usr/lib/gcc-snapshot/share/java/gcj-endorsed\ -DLIBGCJ_DEFAULT_DATABASE=\/usr/lib/gcc-snapshot/lib/gcj-4.1.0/classmap.db\ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\gcj-4.1.0/classmap.db\ -DTOOLEXECLIBDIR=\/usr/lib/gcc-snapshot/lib\ -g -O2 -D_GNU_SOURCE -MT prims.lo -MD -MP -MF $depbase.Tpo -c -o prims.lo ../../../src/libjava/prims.cc; \ then mv -f $depbase.Tpo $depbase.Plo; else rm -f $depbase.Tpo; exit 1; fi mkdir .libs /build/buildd/gcc-snapshot-20050901/build/./gcc/xgcc -shared-libgcc -B/build/buildd/gcc-snapshot-20050901/build/./gcc -nostdinc++ -L/build/buildd/gcc-snapshot-20050901/build/powerpc-linux-gnu/libstdc++-v3/src -L/build/buildd/gcc-snapshot-20050901/build/powerpc-linux-gnu/libstdc++-v3/src/.libs -B/usr/lib/gcc-snapshot/powerpc-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/powerpc-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/powerpc-linux-gnu/include -isystem /usr/lib/gcc-snapshot/powerpc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../src/libjava -I./include -I./gcj -I../../../src/libjava -Iinclude -I../../../src/libjava/include -I../../../src/libjava/classpath/include -I../../../src/libjava/classpath/native/fdlibm -I../../../src/libjava/../boehm-gc/include -I../boehm-gc/include -I../../../src/libjava/libltdl -I../../../src/libjava/libltdl -I../../../src/libjava/.././libjava/../gcc -I../../../src/libjava/../zlib -I../../../src/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/usr/lib/gcc-snapshot\ -DLIBDIR=\/usr/lib/gcc-snapshot/lib\ -DJAVA_HOME=\/usr/lib/gcc-snapshot/jre\ -DBOOT_CLASS_PATH=\/usr/lib/gcc-snapshot/jre/lib/rt.jar\ -DJAVA_EXT_DIRS=\/usr/lib/gcc-snapshot/share/java/ext\ -DGCJ_ENDORSED_DIRS=\/usr/lib/gcc-snapshot/share/java/gcj-endorsed\ -DLIBGCJ_DEFAULT_DATABASE=\/usr/lib/gcc-snapshot/lib/gcj-4.1.0/classmap.db\ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\gcj-4.1.0/classmap.db\ -DTOOLEXECLIBDIR=\/usr/lib/gcc-snapshot/lib\ -g -O2 -D_GNU_SOURCE -MT prims.lo -MD -MP -MF .deps/prims.Tpo -c ../../../src/libjava/prims.cc -fPIC -DPIC -o .libs/prims.o ../../../src/libjava/prims.cc: In function 'void* _Jv_ResolvePoolEntry(java::lang::Class*, jint)': ../../../src/libjava/prims.cc:375: error: missing REG_EH_REGION note in the end of bb 2 ../../../src/libjava/prims.cc:375: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [prims.lo] Error 1 make[5]: Leaving directory `/build/buildd/gcc-snapshot-20050901/build/powerpc-linux-gnu/libjava' make[4]: *** [all-recursive] Error 1 -- Summary: [4.1 regression] [powerpc] bootstrap error in libjava (ICE in fixup_eh_region_note) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23712
[Bug libfortran/23272] [mingw32] inquire via filename fails
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-03 07:55 --- For info, here is a way to create a pseudo inode number for stat and fstat using mingw32 and a few Windows API calls: http://gnuwin32.sourceforge.net/compile.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23272
[Bug fortran/23713] New: HDF5 build fails -- internal compiler error
Build of hdf5-1.6.4 with Fortran moduled fails with an internal compiler error. See http://hdf.ncsa.uiuc.edu/HDF5/ ./configure --enable-fortran make . . make[3]: Entering directory `/home/swhite/hdf5-1.6.4/fortran/src' rm -f .libs/H5f90global.lo gfortran -I. -I. -c H5f90global.f90 -fPIC -DPIC -o H5f90global.o H5f90global.f90:0: internal compiler error: backend decl for module variable h5t_enum_f already exists Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: HDF5 build fails -- internal compiler error Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: swhite at aei dot mpg dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: gcc version 4.1.0 20050829 (experimental) GCC host triplet: i686-pc-linux-gnu GCC target triplet: ? ? ? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23713
[Bug libfortran/23262] [migwin32] rewind truncates file
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-03 08:46 --- Well, that was not so difficult: when we write 1234\n6789\n for example, the length of the write is 10. But the size of the resulting file is 12, since each newline character is translated into a two-byte \n\r sequence! Then, the first step of the rewind is to truncate the file to length 10. I don't know exactly how we should handle this :( -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-03 08:46:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23262
[Bug rtl-optimization/23714] New: [4.1 Regression] ICE in expand_assignment
cc1plus -O2 -fnon-call-exceptions fails with
internal compiler error: in expand_assignment, at expr.c:3929
for
void run (void) {
float stack[1];
float *sp = stack;
try
{
float value2 = ((float) *(--sp));
float value1 = ((float) *(--sp));
*(sp++) = (value1 - value2);
}
catch (int *ex)
{
}
}
which is a testcase for PR 23706 written by Andrew Pinski.
It passes on 3.4 and 4.0.
--
Summary: [4.1 Regression] ICE in expand_assignment
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
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=23714
[Bug target/23706] [4.1 Regression] ICE in rtl_verify_flow_info_1
--- Additional Comments From kkojima at gcc dot gnu dot org 2005-09-03 09:20 --- BTW, I've found that Andrew's testcase fails even on i686-linux with -O2 -fnon-call-exceptions: internal compiler error: in expand_assignment, at expr.c:3929 I've filed it as PR 23714. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23706
[Bug bootstrap/23715] New: [4.1 regression] [sparc] bootstrap error in libjava (ICE in fixup_eh_region_note)
libjava fails to build on sparc-linux (CVS 20050901 HEAD) Matthias /home/doko-local/gcc/snap/gcc-snapshot-20050901/build/./gcc/xgcc -shared-libgcc -B/home/doko-local/gcc/snap/gcc-snapshot-20050901/build/./gcc -nostdinc++ -L/home/doko-local/gcc/snap/gcc-snapshot-20050901/build/sparc-linux-gnu/libstdc++-v3/src -L/home/doko-local/gcc/snap/gcc-snapshot-20050901/build/sparc-linux-gnu/libstdc++-v3/src/.libs -B/usr/lib/gcc-snapshot/sparc-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/sparc-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/sparc-linux-gnu/include -isystem /usr/lib/gcc-snapshot/sparc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../src/libjava -I./include -I./gcj -I../../../src/libjava -Iinclude -I../../../src/libjava/include -I../../../src/libjava/classpath/include -I../../../src/libjava/classpath/native/fdlibm -I../../../src/libjava/../boehm-gc/include -I../boehm-gc/include -I../../../src/libjava/libltdl -I../../../src/libjava/libltdl -I../../../src/libjava/.././libjava/../gcc -I../../../src/libjava/../zlib -I../../../src/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/usr/lib/gcc-snapshot\ -DLIBDIR=\/usr/lib/gcc-snapshot/lib\ -DJAVA_HOME=\/usr/lib/gcc-snapshot/jre\ -DBOOT_CLASS_PATH=\/usr/lib/gcc-snapshot/jre/lib/rt.jar\ -DJAVA_EXT_DIRS=\/usr/lib/gcc-snapshot/share/java/ext\ -DGCJ_ENDORSED_DIRS=\/usr/lib/gcc-snapshot/share/java/gcj-endorsed\ -DLIBGCJ_DEFAULT_DATABASE=\/usr/lib/gcc-snapshot/lib/gcj-4.1.0/classmap.db\ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\gcj-4.1.0/classmap.db\ -DTOOLEXECLIBDIR=\/usr/lib/gcc-snapshot/lib\ -g -O2 -D_GNU_SOURCE -MT interpret.lo -MD -MP -MF .deps/interpret.Tpo -c ../../../src/libjava/interpret.cc -fPIC -DPIC -o .libs/interpret.o ../../../src/libjava/interpret.cc: In static member function 'static void _Jv_InterpMethod::run(void*, ffi_raw*, _Jv_InterpMethod*)': ../../../src/libjava/interpret.cc:3243: internal compiler error: in fixup_eh_region_note, at reload1.c:3808 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [interpret.lo] Error 1 make[5]: Leaving directory `/home/doko-local/gcc/snap/gcc-snapshot-20050901/build/sparc-linux-gnu/libjava' -- Summary: [4.1 regression] [sparc] bootstrap error in libjava (ICE in fixup_eh_region_note) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: sparc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23715
[Bug bootstrap/23715] [4.1 regression] bootstrap error in libjava (ICE in fixup_eh_region_note)
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-03 09:54 --- Worked on SPARC/Solaris on gax% cat ~/cvs/gcc/LAST_UPDATED Tue Aug 30 23:56:01 CDT 2005 Wed Aug 31 04:56:01 UTC 2005 -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Summary|[4.1 regression] [sparc]|[4.1 regression] bootstrap |bootstrap error in libjava |error in libjava (ICE in |(ICE in |fixup_eh_region_note) |fixup_eh_region_note) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23715
[Bug libfortran/23262] [migwin32] rewind truncates file
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-03 10:15 --- OK, it's worse than I thought. When you open a file with O_BINARY, it is opened using Unix conventions, and you need to add yourself the \r in the right places. Otherwise, you can use the Windows CRLF convention, but then lseek and ftruncate are *not* usable. Not at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23262
[Bug c++/22592] -fvisibility-inlines-hidden broken differently
--- Additional Comments From jh at suse dot cz 2005-09-03 10:51 --- Subject: Re: -fvisibility-inlines-hidden broken differently --- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-03 01:03 --- Frankly, I think -fvisibility-inlines-hidden is a bad idea. I don't feel that way about -fvisibility, but giving inline functions special linkage in this way is a very fragile concept, and awards something with minimal C++ semantics (inline) substantial observable semantics. The documentation for -fv-i-h is not clear about this case. All it really says is that any inlines emitted will be hidden. The compiler's meeting that requirement, trivially, because it's not emitting any inlines. Is that even correct that we don't emit any inline? (ie see bellow) I don't think that we should do anything different in *this* source file because -fv-i-h is present. The thing we actually want to know is how the file containing the vtable is going to be compiled, and we can't know that here. Therefore, it seems to me that the mistake in Michael's chain of events is: 4) the call is emitted such that it expects a local (hidden) definition of the function in the DSO (i.e. not over PLT but direct call) Nothing in the semantics of -fv-i-h says that all inline functions in the program will be in this DSO. If we were to try to believe that, other things (like extern template) would probably break too. Instead, the linker should have the responsibility of binding the relocation within the DSO at DSO link-time, if there happens to be a satisfying symbol at link time. Jan, I don't think your patch is correct, as I don't think anything about the optimization of this program should change based on -fv-i-h. Hmm, OK, there are two problems I see. One problem is that this testcase breaks. We can declare it invalid or one other possibility I run across is to teach locally_bound predicate in varasm to not believe that this hidden inline function is going to be linked locally. This is very similar to way -fvisibility works - ie function is hidden only if defined in current unit and would result in DSO to build and even link if the other DSO will export the inline function (that won't happen with -fv-i-h on the other DSO, right?) This is not quite trivial, becuase -fv-i-h is hanled in the frontend and backend already don't see whether the particular inline was actually declared hidden (where user should provide it in within same DSO) or whether the hidden implied this way, but I guess we can simply be conservative here and when flag is active, thread this way all comdats with inline flag and hidden visibility. But the more general problem however is that I think it is quite incorrect to call comdat linkonce function directly without actually outputting it into current compilation unit, at least from the definition of comdat flag: /* Used in a DECL to indicate that, even if it TREE_PUBLIC, it need not be put out unless it is needed in this translation unit. Entities like this are shared across translation units (like weak entities), but are guaranteed to be generated by any translation unit that needs them, and therefore need not be put out anywhere where they are not needed. DECL_COMDAT is just a hint to the back-end; it is up to front-ends which set this flag to ensure that there will never be any harm, other than bloat, in putting out something which is DECL_COMDAT. */ Making direct call the function probably makes function needed in this translation unit even tought it wasn't originally. This can happen with and without the patch in this special case (COMDAT functio being originally referenced by vtable not going to be output here). Is there something behind scenes making this safe? (like is the argument that the function will be provided by unit defining vtable anyway safe and if so, why is not frontend emitting it as extern inline in all other units saving object file sizes?) If not, we probably should prevent the folding... Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22592 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22592
[Bug bootstrap/23712] [4.1 regression] [powerpc] bootstrap error in libjava (ICE in fixup_eh_region_note)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-03 11:49 --- This has already been fixed, this is a dup of bug 23676. *** This bug has been marked as a duplicate of 23676 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23712
[Bug middle-end/23676] [4.1 Regression] ICE: missing REG_EH_REGION note in the end of bb
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-03 11:49 --- *** Bug 23712 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23676
[Bug target/23715] [4.1 regression] bootstrap error in libjava (ICE in fixup_eh_region_note)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-03 11:52 --- This is most likely a target problem. For the target maintainer see http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00053.html for more information. -- What|Removed |Added Component|bootstrap |target Keywords||build, ice-on-valid-code Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23715
[Bug middle-end/23714] [4.1 Regression] ICE in expand_assignment
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-03 12:02 --- I should mention this really undefined code, I did not mean it to be used for any good example at higher optimization than -O0. Anyways confirmed. This has been failing since at least 20050822. -- What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Component|rtl-optimization|middle-end Ever Confirmed||1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2005-09-03 12:02:26 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23714
[Bug target/23711] [4.1 regression] [s390] bootstrap error in libjava (ICE in fixup_eh_region_note)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-03 12:03 --- This is most likely a target problem. For the target maintainer see http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00053.html for more information. -- What|Removed |Added Component|bootstrap |target Keywords||build, ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23711
[Bug fortran/17917] gfortran ICE on equivalence
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-03 12:05 --- *** Bug 23713 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||swhite at aei dot mpg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17917
[Bug fortran/23713] HDF5 build fails -- internal compiler error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-03 12:05 --- *** This bug has been marked as a duplicate of 17917 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23713
[Bug objc++/23716] New: obj-c++.dg/comp-types-10.mm ICE with the GNU runtime
FAIL: obj-c++.dg/comp-types-10.mm (test for excess errors) Excess errors: /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/comp-types-10.mm:19: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in setup_one_parameter, at tree- inline.c:1116 The reason is: __objc_gnu_init (D.2186) Is that we have a function which takes a paramater which is not needed but have a type of error_mark_node for some reason. -- Summary: obj-c++.dg/comp-types-10.mm ICE with the GNU runtime Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: objc++ 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 GCC target triplet: x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23716
[Bug objc++/23716] obj-c++.dg/comp-types-10.mm ICE with the GNU runtime
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-03 12:42 --- Confirmed, based on http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00118.html . -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-03 12:42:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23716
[Bug ada/23717] New: [Ada] Wrong ICE diagnostic formatting
internal_error_function in ada/misc.c uses plain vfprintf for formatting the error message, which may contain gcc-specific formatting directives when called through tree_class_check_failed or tree_contains_struct_check_failed. -- Summary: [Ada] Wrong ICE diagnostic formatting Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23717
[Bug objc++/16816] obj-c++ parser error with multi-colon selectors
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-03 13:03 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00163.html. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||09/msg00163.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16816
[Bug ada/23717] [Ada] Wrong ICE diagnostic formatting
--- Additional Comments From joseph at codesourcery dot com 2005-09-03 13:33 --- Subject: Re: New: [Ada] Wrong ICE diagnostic formatting On Sat, 3 Sep 2005, schwab at suse dot de wrote: internal_error_function in ada/misc.c uses plain vfprintf for formatting the error message, which may contain gcc-specific formatting directives when called through tree_class_check_failed or tree_contains_struct_check_failed. Roger Sayle's patch for this: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01498.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23717
[Bug target/23715] [4.1 regression] bootstrap error in libjava (ICE in fixup_eh_region_note)
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-03 13:36 --- This is most likely a target problem. For the target maintainer see http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00053.html for more information. Thanks for the tip! -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-03 13:36:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23715
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-09-03 14:25 --- Hi, I now think that the true origin of this PR is related to the fact that for AVR we need *two* registers for holding the frame pointer: Recently, I have played around with modifying avr-gcc by choosing different registers for the frame pointer and the stack pointer. Namely I have experimented with the calling convention used by the IAR system (use two seperate stacks for the return addresses and data). It turned out that the stack pointer and frame pointer register number during my experiments that was used by gcc was not 28 but 29! Possibly one would have to re-investigate avr_hard_regno_mode_ok(REGNO, MODE) function in avr.c that implements the HARD_REGNO_MODE_OK target macro. IIUC, there have been a couple of problems in the past with similar results: clobbered frame pointer. Maybe the fact that this bug does not show up frequently has to do with that the constraints for the Y register implemented in avr_hard_regno_mode_ok are fairly restrictive right now, so that the register allocator and reload almost never are tempted to use it. Important information would be wether avr_hard_regno_mode_ok is evaluated dynamically for each function. In this case one could probably prevent clobbering of the frame pointer by denying any mode in regs 28 and 29 in case that a frame pointer is needed. This way one possibly could also lift the present restriction that only pointers (Pmode objects) may be held in the y register. So I think that we are right now having a hidden problem in avr-gcc that shows up only in very rare occasions. Most probably it's also present in the 3.4.4 series. Yours, Björn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug target/23671] [4.1 Regression] ICE in fixup_eh_region_note, at reload1.c:3808
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-03 14:33 --- Subject: Bug 23671 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-03 14:33:07 Modified files: gcc: ChangeLog gcc/config/pa : pa.c Log message: PR middle-end/23671 pa.c (emit_move_sequence): Use replace_equiv_address instead of gen_rtx_MEM. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9889r2=2.9890 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa.c.diff?cvsroot=gccr1=1.305r2=1.306 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23671
[Bug target/23671] [4.1 Regression] ICE in fixup_eh_region_note, at reload1.c:3808
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-03 17:35 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23671
[Bug objc/20574] [4.1 Regression] weird error message after a parse error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-03 17:56 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00174.html. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||09/msg00174.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20574
[Bug objc/19324] [3.4/4.0/4.1 Regression] weird message for interface way in implementation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-03 17:56 --- Patch posted here for 4.1: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00174.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19324
[Bug objc/23709] [4.1 Regression] error recovery is not smart enough
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-03 18:11 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00175.html. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||09/msg00175.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23709
[Bug c++/23699] [4.0/4.1 Regression] rejects static int as non constant after extern template
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-03 18:18 --- Subject: Bug 23699 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-03 18:18:48 Modified files: gcc/cp : ChangeLog decl2.c parser.c semantics.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/ext: static1.C Log message: PR c++/23699 * decl2.c (mark_used): Always instantiate static data members initialized by constant expressions. * pt.c (instantiate_decl): Instantiate the initializers for static data members initialized by constant expressions. PR c++/21687 * semantics.c (expand_or_defer_fn): Do not call ggc_collect when finishing processing for a template function in a local class. Revert: 2005-09-02 Mark Mitchell [EMAIL PROTECTED] * parser.c (cp_parser_class_specifier): Push/pop GC contexts around functions in local classes. PR c++/23699 * g++.dg/ext/static1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4867r2=1.4868 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gccr1=1.795r2=1.796 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gccr1=1.354r2=1.355 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gccr1=1.483r2=1.484 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5999r2=1.6000 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/static1.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23699
[Bug c++/21687] [4.0/4.1 Regression] ICE in GC with local class inside a template function
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-03 18:18 --- Subject: Bug 21687 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-03 18:18:48 Modified files: gcc/cp : ChangeLog decl2.c parser.c semantics.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/ext: static1.C Log message: PR c++/23699 * decl2.c (mark_used): Always instantiate static data members initialized by constant expressions. * pt.c (instantiate_decl): Instantiate the initializers for static data members initialized by constant expressions. PR c++/21687 * semantics.c (expand_or_defer_fn): Do not call ggc_collect when finishing processing for a template function in a local class. Revert: 2005-09-02 Mark Mitchell [EMAIL PROTECTED] * parser.c (cp_parser_class_specifier): Push/pop GC contexts around functions in local classes. PR c++/23699 * g++.dg/ext/static1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4867r2=1.4868 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gccr1=1.795r2=1.796 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gccr1=1.354r2=1.355 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gccr1=1.483r2=1.484 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5999r2=1.6000 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/static1.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21687
[Bug c++/23699] [4.0/4.1 Regression] rejects static int as non constant after extern template
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-03 18:27 --- Subject: Bug 23699 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-03 18:27:39 Modified files: gcc/cp : pt.c Log message: PR c++/23699 * decl2.c (mark_used): Always instantiate static data members initialized by constant expressions. * pt.c (instantiate_decl): Instantiate the initializers for static data members initialized by constant expressions. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.1027r2=1.1028 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23699
[Bug c++/23699] [4.0/4.1 Regression] rejects static int as non constant after extern template
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-03 18:29 --- Subject: Bug 23699 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-03 18:29:47 Modified files: gcc/testsuite : ChangeLog gcc/cp : ChangeLog decl2.c parser.c pt.c semantics.c Added files: gcc/testsuite/g++.dg/ext: static1.C Log message: PR c++/23699 * decl2.c (mark_used): Always instantiate static data members initialized by constant expressions. * pt.c (instantiate_decl): Instantiate the initializers for static data members initialized by constant expressions. PR c++/21687 * semantics.c (expand_or_defer_fn): Do not call ggc_collect when finishing processing for a template function in a local class. Revert: 2005-09-02 Mark Mitchell [EMAIL PROTECTED] * parser.c (cp_parser_class_specifier): Push/pop GC contexts around functions in local classes. PR c++/23699 * g++.dg/ext/static1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.369r2=1.5084.2.370 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/static1.C.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.4648.2.88r2=1.4648.2.89 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.770.2.4r2=1.770.2.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.319.2.15r2=1.319.2.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.978.2.20r2=1.978.2.21 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.463.2.6r2=1.463.2.7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23699
[Bug c++/21687] [4.0/4.1 Regression] ICE in GC with local class inside a template function
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-03 18:29 --- Subject: Bug 21687 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-03 18:29:47 Modified files: gcc/testsuite : ChangeLog gcc/cp : ChangeLog decl2.c parser.c pt.c semantics.c Added files: gcc/testsuite/g++.dg/ext: static1.C Log message: PR c++/23699 * decl2.c (mark_used): Always instantiate static data members initialized by constant expressions. * pt.c (instantiate_decl): Instantiate the initializers for static data members initialized by constant expressions. PR c++/21687 * semantics.c (expand_or_defer_fn): Do not call ggc_collect when finishing processing for a template function in a local class. Revert: 2005-09-02 Mark Mitchell [EMAIL PROTECTED] * parser.c (cp_parser_class_specifier): Push/pop GC contexts around functions in local classes. PR c++/23699 * g++.dg/ext/static1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.369r2=1.5084.2.370 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/static1.C.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.4648.2.88r2=1.4648.2.89 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.770.2.4r2=1.770.2.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.319.2.15r2=1.319.2.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.978.2.20r2=1.978.2.21 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.463.2.6r2=1.463.2.7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21687
[Bug c++/23699] [4.0/4.1 Regression] rejects static int as non constant after extern template
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-03 18:45 --- Fixed in 4.0.2. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23699
[Bug rtl-optimization/23454] [4.0 regression] ICE in invert_exp_1, at jump.c:1719
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-03 18:50 --- Subject: Bug 23454 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-03 18:49:52 Modified files: gcc: ChangeLog reorg.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/opt: pr23454.C Log message: PR rtl-optimization/23454 * reorg.c (relax_delay_slots): Only call invert_jump if any_condjump_p is true. * g++.dg/opt/pr23454.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9890r2=2.9891 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reorg.c.diff?cvsroot=gccr1=1.110r2=1.111 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6000r2=1.6001 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr23454.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23454
[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-03 18:52 --- Does anyone happen to have a smallish test-case for this one? Obviously, I can build one of the affected toolchains, but if someone has a cut-down test case handy, I'll take it. :-) -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667
[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-03 19:04 --- (In reply to comment #12) Does anyone happen to have a smallish test-case for this one? Obviously, I can build one of the affected toolchains, but if someone has a cut-down test case handy, I'll take it. :-) It effects all targets, just the slower the machine, the more likely the timeout. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667
[Bug fortran/23261] [meta-bug] [mingw32] gfortran testsuite bugs
-- Bug 23261 depends on bug 23264, which changed state. Bug 23264 Summary: [mingw32] direct access failure http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23264 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23261
[Bug libfortran/23264] [mingw32] direct access failure
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-03 19:08 --- Don't ask me why, but this is a duplicate of PR23262. Patch fixes both. *** This bug has been marked as a duplicate of 23262 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23264
[Bug libfortran/23262] [migwin32] rewind truncates file
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-03 19:09 --- *** Bug 23264 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23262
[Bug rtl-optimization/23454] [4.0 regression] ICE in invert_exp_1, at jump.c:1719
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-03 19:10 --- Subject: Bug 23454 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-03 19:09:59 Modified files: gcc: ChangeLog reorg.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/opt: pr23454.C Log message: PR rtl-optimization/23454 * reorg.c (relax_delay_slots): Only call invert_jump if any_condjump_p is true. * g++.dg/opt/pr23454.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.408r2=2.7592.2.409 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reorg.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.104r2=1.104.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.370r2=1.5084.2.371 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr23454.C.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23454
[Bug rtl-optimization/23454] [4.0 regression] ICE in invert_exp_1, at jump.c:1719
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-03 19:14 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23454
[Bug c++/19004] [3.4 Regression] ICE in uses_template_parms at cp/pt.c:4860
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-03 19:53 --- Subject: Bug 19004 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-09-03 19:53:01 Modified files: gcc/cp : ChangeLog pt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: nontype13.C Log message: Backport: 2005-08-26 Mark Mitchell [EMAIL PROTECTED] PR c++/19004 * pt.c (uses_template_parms): Handle IDENTIFIER_NODE. (type_dependent_expression_p): Allow BASELINKs whose associated functions are simply a FUNCTION_DECL. * g++.dg/template/nontype13.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3892.2.238r2=1.3892.2.239 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.816.2.59r2=1.816.2.60 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.431r2=1.3389.2.432 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/nontype13.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.10.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19004
[Bug tree-optimization/23326] [4.0 Regression] Wrong code from forwprop
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-03 19:55 --- Subject: Bug 23326 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-03 19:54:51 Modified files: gcc: ChangeLog tree-ssa-forwprop.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/tree-ssa: pr23326.C Log message: 2005-09-03 Richard Guenther [EMAIL PROTECTED] Andrew Pinski [EMAIL PROTECTED] Serge Belyshev [EMAIL PROTECTED] PR tree-optimization/23326 * tree-ssa-forwprop.c (substitute_single_use_vars): Only do transformation if valid. * g++.dg/tree-ssa/pr23326.C: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.409r2=2.7592.2.410 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-forwprop.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.11r2=2.11.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.372r2=1.5084.2.373 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr23326.C.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23326
[Bug tree-optimization/23326] [4.0 Regression] Wrong code from forwprop
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-03 19:55 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23326
[Bug libffi/23718] New: ffitarget.h include problem
Hi, On install, GCC copies ffitarget.h to LIBDIR/gcc/TARGET/VERSION/include/libffi/ffitarget.h However, ffi.h tries to #include ffitarget.h, and can't find it (no wonder). Correction: Either put ffitarget.h into LIBDIR/gcc/TARGET/VERSION/include, or change the line in ffi.h to #include libffi/ffitarget.h. This should be invariant of the platform; I just checked on x86_64. 4.0.1 should be affected as well. -- Summary: ffitarget.h include problem Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: libffi AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bernd dot paysan at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23718
[Bug bootstrap/22259] [4.1 Regression] spawnv cannot execute gcc/as
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-03 19:58 --- From what I have seen on the gcc ml, it looks like the opposition to a pex-win32.c patch (Mark) agrees on it, and Christopher said in http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00513.html he could do it. Adding him to the PR. Maybe the assignment should be changed, too. -- What|Removed |Added CC||cgf at alum dot bu dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22259
[Bug c++/19004] [3.4 Regression] ICE in uses_template_parms at cp/pt.c:4860
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-03 19:59 --- Fixed also on the 3.4 branch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19004
[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out
--- Additional Comments From mark at codesourcery dot com 2005-09-03 20:08 --- Subject: Re: [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-03 19:04 --- (In reply to comment #12) Does anyone happen to have a smallish test-case for this one? Obviously, I can build one of the affected toolchains, but if someone has a cut-down test case handy, I'll take it. :-) It effects all targets, just the slower the machine, the more likely the timeout. Yes, but that makes it no easier for me to test and debug the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667
[Bug tree-optimization/23509] [4.1 regression] ICE with ivopts
--- Additional Comments From mec at google dot com 2005-09-03 20:16 ---
Here is another test with confirmatory data.
Test case, reduced from some firefox code:
int punycode_decode(const char input[], unsigned char case_flags[])
{
int j;
for (j = 0; j 128; ++j) {
if (case_flags)
case_flags[j] = input[j] - 65 26;
if (input[j] 32)
return -1;
}
return 0;
}
With native i686-pc-linux-gnu, my results are:
gcc 4.0.1, command line gcc -S -O3 z1.i, no error
gcc 4.1-20050819 snapshot, command line gcc -S -O3 z1.i, ICE:
z1.i: In function 'punycode_decode':
z1.i:2: internal compiler error: in finalize_ssa_uses, at
tree-ssa-operands.c:580
gcc 4.1-20050902 snapshot, command line gcc -S -O3 z1.i, ICE:
z1.i: In function 'punycode_decode':
z1.i:2: internal compiler error: in finalize_ssa_uses, at
tree-ssa-operands.c:580
gcc 4.1-20050902 snapshot, command line gcc -S -O3 -fno-ivopts z1.i, no error
gcc 4.1-20050902 snapshot + zdenek patch, command line gcc -S -O3 z1.i, no
error
zdenek patch is the version from
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01647.html .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23509
[Bug c++/21440] [4.0/4.1 Regression] ICE with statement-as-expression
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21440
[Bug testsuite/23720] New: FAIL: gcc.dg/debug/dwarf2/dwarf-char[123].c scan-assembler 0x[68][ \t]# DW_AT_encoding
Executing on host: /home/dave/gnu/gcc-4.0/objdir/gcc/xgcc -B/home/dave/gnu/gcc-4 .0/objdir/gcc/ /home/dave/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/debug/dwarf2/dwar f-char3.c -O2 -gdwarf-2 -dA -fno-show-column -S -o dwarf-char3.s(timeout = 300) PASS: gcc.dg/debug/dwarf2/dwarf-char3.c (test for excess errors) FAIL: gcc.dg/debug/dwarf2/dwarf-char3.c scan-assembler 0x[68][ \t]# DW_AT_encodi ng Looks like a assembler comment character issue: $ less dwarf-char3.s ... .byte 0x6 ; DW_AT_encoding ... .uleb128 0x3e ; (DW_AT_encoding) -- Summary: FAIL: gcc.dg/debug/dwarf2/dwarf-char[123].c scan- assembler 0x[68][ \t]# DW_AT_encoding Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23720
[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out
--- Additional Comments From pcarlini at suse dot de 2005-09-03 23:06 --- (In reply to comment #14) Yes, but that makes it no easier for me to test and debug the problem. Hi, today I tried, quickly, but failed to find a simple testcase. Tomorrow, I'll try again, harder. Thanks for taking care of this issue: as far as I'm concerned, tr1/unordered* are completely broken (now that we sorted out the most important bugs and would be seriously usable for 4.0.2 :( And the issue seems serious in general, anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667
[Bug libgcj/16990] [meta-bug] TimeZone Issues in libgcj/classpath
--- Additional Comments From mark at gcc dot gnu dot org 2005-09-03 23:50 --- New TimeZone issue Bug #23566 Need to regenerate TimeZone data against tzdata2005k -- What|Removed |Added BugsThisDependsOn||23566 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16990
[Bug classpath/17003] java.util.TimeZone information outdated
--- Additional Comments From mark at gcc dot gnu dot org 2005-09-03 23:51 --- The TimeZones have been regenerated from tzcode2005l. 2005-08-25 Mark Wielaard [EMAIL PROTECTED] Reported by Bastiaan Huisman [EMAIL PROTECTED] * scripts/tzabbrevs: Change America/Buenos_Aires to America/Argentina/Buenos_Aires for AGT link. * timezones.pl (parseTime): Assume and return wall time. Reindent output. * java/util/TimeZone.java (timezones): Regenerate using tzdata2005l. Since a few days there is a new dataset tzcode2005k. There is a bug in our script that prevents us from regenerating against that one. This is tracked in bug #23566. -- What|Removed |Added Status|NEW |RESOLVED Component|libgcj |classpath Product|gcc |classpath Resolution||FIXED Target Milestone|--- |0.18 Version|4.0.0 |unspecified http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17003
[Bug libgcj/16990] [meta-bug] TimeZone Issues in libgcj/classpath
-- Bug 16990 depends on bug 17003, which changed state. Bug 17003 Summary: java.util.TimeZone information outdated http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17003 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16990
[Bug middle-end/21460] sjlj_emit_function_enter adds rtl to wrong block
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||09/msg00118.html Status|NEW |ASSIGNED Keywords||patch Known to fail|4.0.2 |4.0.2 4.1.0 Summary|Internal compiler error in |sjlj_emit_function_enter |calc_dfs_tree on valid code |adds rtl to wrong block Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21460
[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target
--- Additional Comments From ngmlinux at gmail dot com 2005-09-04 00:14 --- After patching the gcc-4.0.1 source in boehm-gc/include/private/gcconfig.h, I get the following errors when I go to make. I did not get this errors before editing gcconfig.h, however they appear to be unrelated: ===code In file included from ./gthr-default.h:1, from ../../gcc/gthr.h:114, from ../../gcc/unwind-dw2.c:42: ../../gcc/gthr-posix.h:43:21: error: pthread.h: No such file or directory ../../gcc/gthr-posix.h:44:20: error: unistd.h: No such file or directory In file included from ./gthr-default.h:1, from ../../gcc/gthr.h:114, from ../../gcc/unwind-dw2.c:42: ../../gcc/gthr-posix.h:46: error: syntax error before '__gthread_key_t' ../../gcc/gthr-posix.h:46: warning: type defaults to 'int' in declaration of '__gthread_key_t' ../../gcc/gthr-posix.h:46: warning: data definition has no type or storage class../../gcc/gthr-posix.h:47: error: syntax error before '__gthread_once_t' ../../gcc/gthr-posix.h:47: warning: type defaults to 'int' in declaration of '__gthread_once_t' ../../gcc/gthr-posix.h:47: warning: data definition has no type or storage class../../gcc/gthr-posix.h:48: error: syntax error before '__gthread_mutex_t' ../../gcc/gthr-posix.h:48: warning: type defaults to 'int' in declaration of '__gthread_mutex_t' ../../gcc/gthr-posix.h:48: warning: data definition has no type or storage class../../gcc/gthr-posix.h:49: error: syntax error before '__gthread_recursive_mutex_t' ../../gcc/gthr-posix.h:49: warning: type defaults to 'int' in declaration of '__gthread_recursive_mutex_t' ../../gcc/gthr-posix.h:49: warning: data definition has no type or storage class../../gcc/gthr-posix.h: In function '__gthread_active_p': ../../gcc/gthr-posix.h:110: error: 'pthread_cancel' undeclared (first use in this function) ../../gcc/gthr-posix.h:110: error: (Each undeclared identifier is reported only once ../../gcc/gthr-posix.h:110: error: for each function it appears in.) ../../gcc/gthr-posix.h: At top level: ../../gcc/gthr-posix.h:474: error: syntax error before '*' token ../../gcc/gthr-posix.h:474: error: syntax error before ')' token ../../gcc/gthr-posix.h:483: error: syntax error before '*' token ../../gcc/gthr-posix.h:483: error: syntax error before ')' token ../../gcc/gthr-posix.h:489: error: syntax error before 'key' ../../gcc/gthr-posix.h:490: warning: function declaration isn't a prototype ../../gcc/gthr-posix.h: In function '__gthread_key_delete': ../../gcc/gthr-posix.h:490: warning: old-style function definition ../../gcc/gthr-posix.h:491: warning: implicit declaration of function 'pthread_key_delete' ../../gcc/gthr-posix.h:491: error: 'key' undeclared (first use in this function)../../gcc/gthr-posix.h: At top level: ../../gcc/gthr-posix.h:495: error: syntax error before 'key' ../../gcc/gthr-posix.h:496: warning: function declaration isn't a prototype ../../gcc/gthr-posix.h: In function '__gthread_getspecific': ../../gcc/gthr-posix.h:496: warning: old-style function definition ../../gcc/gthr-posix.h:497: warning: implicit declaration of function 'pthread_getspecific' ../../gcc/gthr-posix.h:497: error: 'key' undeclared (first use in this function)../../gcc/gthr-posix.h:497: warning: return makes pointer from integer without a cast ../../gcc/gthr-posix.h: At top level: ../../gcc/gthr-posix.h:501: error: syntax error before 'key' ../../gcc/gthr-posix.h:502: warning: function declaration isn't a prototype ../../gcc/gthr-posix.h: In function '__gthread_setspecific': ../../gcc/gthr-posix.h:502: warning: old-style function definition ../../gcc/gthr-posix.h:503: warning: implicit declaration of function 'pthread_setspecific' ../../gcc/gthr-posix.h:503: error: 'key' undeclared (first use in this function)../../gcc/gthr-posix.h:503: error: 'ptr' undeclared (first use in this function)../../gcc/gthr-posix.h: At top level: ../../gcc/gthr-posix.h:507: error: syntax error before '*' token ../../gcc/gthr-posix.h:508: warning: function declaration isn't a prototype ../../gcc/gthr-posix.h: In function '__gthread_mutex_lock': ../../gcc/gthr-posix.h:508: warning: old-style function definition ../../gcc/gthr-posix.h:510: warning: implicit declaration of function 'pthread_mutex_lock' ../../gcc/gthr-posix.h:510: error: 'mutex' undeclared (first use in this function) ../../gcc/gthr-posix.h: At top level: ../../gcc/gthr-posix.h:516: error: syntax error before '*' token ../../gcc/gthr-posix.h:517: warning: function declaration isn't a prototype ../../gcc/gthr-posix.h: In function '__gthread_mutex_trylock': ../../gcc/gthr-posix.h:517: warning: old-style function definition ../../gcc/gthr-posix.h:519: warning: implicit declaration of function 'pthread_mutex_trylock' ../../gcc/gthr-posix.h:519: error: 'mutex' undeclared (first use in this function) ../../gcc/gthr-posix.h: At top level: ../../gcc/gthr-posix.h:525: error: syntax error before
[Bug target/23721] New: pt.c:9462: ICE: in change_address_1, at emit-rtl.c:1791
stage1/xgcc -Bstage1/ -B/opt/gnu64/gcc/gcc-4.1.0/hppa64-hp-hpux11.11/bin/ -c - g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototyp es -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissin g-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -Icp -I../../gcc/gc c -I../../gcc/gcc/cp -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/includ e -I/opt/gnu64/gcc/gcc-4.1.0/include ../../gcc/gcc/cp/pt.c -o cp/pt.o ../../gcc/gcc/cp/pt.c: In function 'type_unification_real': ../../gcc/gcc/cp/pt.c:9462: internal compiler error: in change_address_1, at emi t-rtl.c:1791 Please submit a full bug report, Breakpoint 1, fancy_abort ( file=0x400a2f40 ../../gcc/gcc/emit-rtl.c, line=1791, function=0x8001be38 change_address_1) at ../../gcc/gcc/diagnostic.c:590 590 internal_error (in %s, at %s:%d, function, trim_filename (file), line); (gdb) bt #0 fancy_abort (file=0x400a2f40 ../../gcc/gcc/emit-rtl.c, line=1791, function=0x8001be38 change_address_1) at ../../gcc/gcc/diagnostic.c:590 #1 0x404b3740 in change_address_1 (memref=0x83fffe0c9980, mode=DImode, addr=0x83fffdd78720, validate=1) at ../../gcc/gcc/emit-rtl.c:1791 #2 0x404b515c in replace_equiv_address (memref=0x83fffe0c9980, addr=0x83fffdd78720) at ../../gcc/gcc/emit-rtl.c:1972 #3 0x408ad134 in emit_move_sequence (operands=0x83fffeff1dd0, mode=DImode, scratch_reg=0x83fffe0c98a0) at ../../gcc/gcc/config/pa/pa.c:1762 (gdb) p debug_rtx (memref) (mem/u/c/i:DI (symbol_ref/u:DI (*L$C0155) [flags 0x2]) [26 S8 A64]) $1 = void (gdb) p debug_rtx (addr) (plus:DI (symbol_ref:DI (tree_contains_struct) [flags 0xc0] var_decl 83fffe993dc0 tree_contains_struct) (const_int 11210 [0x2bca])) This is a result of the last change to pa.c. -- Summary: pt.c:9462: ICE: in change_address_1, at emit-rtl.c:1791 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23721
[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target
--- Additional Comments From ngmlinux at gmail dot com 2005-09-04 02:35 --- Ok, tried the same fix on another test machine, this one running Mandriva 2005 LE x86_64 and the arm-linux-gcc-4.0.1 toolchain with the boehm-gc patch compiled fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662
[Bug c++/23667] [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out
--- Additional Comments From mark at codesourcery dot com 2005-09-04 03:08 --- Subject: Re: [4.0/4.1 Regression] tr1/6_containers/unordered/hashtable/23465.cc execution test times out pcarlini at suse dot de wrote: --- Additional Comments From pcarlini at suse dot de 2005-09-03 23:06 --- (In reply to comment #14) Yes, but that makes it no easier for me to test and debug the problem. Hi, today I tried, quickly, but failed to find a simple testcase. Tomorrow, I'll try again, harder. Thanks for taking care of this issue: as far as I'm concerned, tr1/unordered* are completely broken (now that we sorted out the most important bugs and would be seriously usable for 4.0.2 :( And the issue seems serious in general, anyway. Definitely! One way or the other, I'll get this fixed, but I appreciate your help. Please do make sure that you've got the patch I checked in today; it's possible that patch magically fixed the problem. (We can hope!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23667
[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target
--- Additional Comments From ngmlinux at gmail dot com 2005-09-04 03:25 --- Ok after recompiling the static HelloWorld.exe with the patched toolchain the following happens upon execution on the target: ===code== [EMAIL PROTECTED] test]$ ./HelloWorld.exe HelloWorld.exe: dl-runtime.c:72: fixup: Assertion `((reloc-r_info) 0xff) == 22' failed. Aborted = The following post although refering to a dated toolchain appears as though it may be relevant: http://www.mail-archive.com/linux-arm@lists.arm.linux.org.uk/msg03071.html Does this seem to be on the right track? I'm noticing that in general, very few bugs if any in the arm-linux port of gcc have been fixed since the gcc-2.x.x and gcc-3.x.x toolchain releases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662
[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target
--- Additional Comments From ngmlinux at gmail dot com 2005-09-04 03:52 --- Perhaps the above link does not apply, my host system doesn't contain a dl-machine.h anywhere on the file system nor did a glibc-current directory turn up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662
Re: [Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target
On Sep 3, 2005, at 11:25 PM, ngmlinux at gmail dot com wrote: --- Additional Comments From ngmlinux at gmail dot com 2005-09-04 03:25 --- Ok after recompiling the static HelloWorld.exe with the patched toolchain the following happens upon execution on the target: ===code == [EMAIL PROTECTED] test]$ ./HelloWorld.exe HelloWorld.exe: dl-runtime.c:72: fixup: Assertion `((reloc-r_info) 0xff) == 22' failed. Aborted === == This is a glibc bug in the dynamic loader. Try a newer glibc. -- Pinski
[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-04 04:07 --- Subject: Re: Binaries generated by arm-linux-gcj segfault on execution on arm target On Sep 3, 2005, at 11:25 PM, ngmlinux at gmail dot com wrote: --- Additional Comments From ngmlinux at gmail dot com 2005-09-04 03:25 --- Ok after recompiling the static HelloWorld.exe with the patched toolchain the following happens upon execution on the target: ===code == [EMAIL PROTECTED] test]$ ./HelloWorld.exe HelloWorld.exe: dl-runtime.c:72: fixup: Assertion `((reloc-r_info) 0xff) == 22' failed. Aborted === == This is a glibc bug in the dynamic loader. Try a newer glibc. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662
[Bug testsuite/23720] FAIL: gcc.dg/debug/dwarf2/dwarf-char[123].c scan-assembler 0x[68][ \t]# DW_AT_encoding
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-04 04:09 --- Fails every where as far as I can see. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org GCC build triplet|hppa-unknown-linux-gnu | GCC host triplet|hppa-unknown-linux-gnu | GCC target triplet|hppa-unknown-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23720
[Bug testsuite/23720] FAIL: gcc.dg/debug/dwarf2/dwarf-char[123].c scan-assembler 0x[68][ \t]# DW_AT_encoding
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-04 04:09 --- Confirmed, that is. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-04 04:09:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23720
[Bug c++/23705] [4.0/4.1 Regression] zone allocator broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-04 04:11 --- Fixed by: 2005-09-03 Mark Mitchell [EMAIL PROTECTED] PR c++/21687 * semantics.c (expand_or_defer_fn): Do not call ggc_collect when finishing processing for a template function in a local class. Revert: 2005-09-02 Mark Mitchell [EMAIL PROTECTED] * parser.c (cp_parser_class_specifier): Push/pop GC contexts around functions in local classes. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23705
[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target
--- Additional Comments From ngmlinux at gmail dot com 2005-09-04 04:20 --- This is a glibc bug in the dynamic loader. Try a newer glibc. Is this a glibc bug on the target or the host machine? I believe my host would have a very recent glibc, my target has an ancient glibc but I compiled my HelloWorld.java as a staticly linked application thus I wouldn't expect it to have any dependencies on the target. ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662
[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-04 04:22 --- (In reply to comment #18) Is this a glibc bug on the target or the host machine? I believe my host would have a very recent glibc, my target has an ancient glibc but I compiled my HelloWorld.java as a staticly linked application thus I wouldn't expect it to have any dependencies on the target. ? You are running your program on the target right? Then it is a bug on the target. The dynamic loader still is invoked because well libjava still invokes it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662
[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target
--- Additional Comments From ngmlinux at gmail dot com 2005-09-04 05:02 --- You are running your program on the target right? Then it is a bug on the target. The dynamic loader still is invoked because well libjava still invokes it. I believe you as I still have glibc-2.2.2 on my target (I should have this updated in a week or two). Kind of defeats the whole point of static linking if libraries are still needed on the target? I assume only c libraries are need on the target and not libjava, otherwise you minus well load a whole JVM and skip gcj all together. I'll provide an update on the issue once my c library has been updated (couple weeks). Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662
