[Bug tree-optimization/27742] [4.2 regression] ICE with -ftree-vectorizer-verbose
--- Comment #6 from micis at gmx dot de 2006-06-19 07:05 --- I tried to reduce the source, but delta wasn't very successful. After more than 2 days on a fast opteron machine delta deleted only about 30%. With the reduced source in gdb I get: Program received signal SIGSEGV, Segmentation fault. 0x003d1cd6f1e0 in strlen () from /lib64/tls/libc.so.6 (gdb) where #0 0x003d1cd6f1e0 in strlen () from /lib64/tls/libc.so.6 #1 0x003d1cd42c51 in vfprintf () from /lib64/tls/libc.so.6 #2 0x003d1cd3f599 in buffered_vfprintf () from /lib64/tls/libc.so.6 #3 0x003d1cd3f779 in vfprintf () from /lib64/tls/libc.so.6 #4 0x003d1cd48076 in fprintf () from /lib64/tls/libc.so.6 #5 0x005c3e13 in vect_print_dump_info (vl=Variable "vl" is not available. ) at ../../gcc-4.2-20060610/gcc/tree-vectorizer.c:1335 #6 0x005c4cfa in vectorize_loops (loops=0x128bc80) at ../../gcc-4.2-20060610/gcc/tree-vectorizer.c:2068 #7 0x005ba750 in tree_vectorize () at ../../gcc-4.2-20060610/gcc/tree-ssa-loop.c:193 #8 0x0089291b in execute_one_pass (pass=0xc738a0) at ../../gcc-4.2-20060610/gcc/passes.c:864 #9 0x00892a8c in execute_pass_list (pass=0xc738a0) at ../../gcc-4.2-20060610/gcc/passes.c:911 #10 0x00892a9e in execute_pass_list (pass=0xc73720) at ../../gcc-4.2-20060610/gcc/passes.c:912 #11 0x00892a9e in execute_pass_list (pass=0xc72d60) at ../../gcc-4.2-20060610/gcc/passes.c:912 #12 0x0055d447 in tree_rest_of_compilation (fndecl=0x2a9b00d900) at ../../gcc-4.2-20060610/gcc/tree-optimize.c:418 #13 0x004d3098 in expand_body (fn=0x2a9b00d900) at ../../gcc-4.2-20060610/gcc/cp/semantics.c:3063 #14 0x008e2716 in cgraph_expand_function (node=0x2a9b060f00) at ../../gcc-4.2-20060610/gcc/cgraphunit.c:1112 #15 0x008e4ec8 in cgraph_optimize () at ../../gcc-4.2-20060610/gcc/cgraphunit.c:1177 #16 0x0047f645 in cp_finish_file () at ../../gcc-4.2-20060610/gcc/cp/decl2.c:3111 #17 0x00531eba in c_common_parse_file (set_yydebug=Variable "set_yydebug" is not available. ) at ../../gcc-4.2-20060610/gcc/c-opts.c:1165 #18 0x008642c8 in toplev_main (argc=Variable "argc" is not available. ) at ../../gcc-4.2-20060610/gcc/toplev.c:999 #19 0x003d1cd1c4ca in __libc_start_main () from /lib64/tls/libc.so.6 #20 0x0040253a in _start () This is still with snapshot gcc-4.2-20060610. command line was: g++ -O1 -g -ftree-vectorize -ftree-vectorizer-verbose=5 -S G2.ii Michael Cieslinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27742
mpeg12.c:974: internal compiler error: in extract_insn, at recog.c:2083
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 cc -I../libvo -I../../libvo -I/usr/X11R6/include -fno-PIC -O -pipe - -funroll-loops -march=pentium3 -fno-force-addr -D_LARGEFILE_SOURCE - -D_FILE_OFFSET_BITS=64 -I/usr/local/include/freetype2 - -I/usr/local/include -I/usr/X11R6/include/gtk12 - -I/usr/local/include/glib12 -I/usr/local/include -I/usr/X11R6/include - -DHAVE_AV_CONFIG_H -I.. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE - -D_GNU_SOURCE -c -o mpeg12.o mpeg12.c mpeg12.c: In function `mpeg1_encode_block': mpeg12.c:974: error: unrecognizable insn: (insn 713 711 715 37 (plus:SI (plus:SI (mult:SI (reg/v:SI 72 [ component ]) (const_int 4 [0x4])) (reg/v/f:SI 58 [ s ])) (const_int 1868 [0x74c])) -1 (nil) (nil)) mpeg12.c:974: internal compiler error: in extract_insn, at recog.c:2083 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. gmake[1]: *** [mpeg12.o] Error 1 gmake[1]: Leaving directory `/usr/ports/multimedia/mplayer/work/MPlayer-1.0pre7try2/libavcodec' gmake: *** [libavcodec/libavcodec.a] Error 2 *** Error code 2 root: uname -a && gcc -v FreeBSD ws3-plovdiv.digsys.bg 6.1-STABLE FreeBSD 6.1-STABLE #0: Wed May 31 13:48:25 EEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IBsec i386 Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.4 [FreeBSD] 20050518 root: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFElkx8w5LcGfjCffQRAqGoAJ4u7M+4BDPrI/So1aRysPbldTqe7wCeM5IR 3PQeQfVzTMVBVIQmMf6teuI= =GmrS -END PGP SIGNATURE-
[Bug tree-optimization/27742] [4.2 regression] ICE with -ftree-vectorizer-verbose
--- Comment #7 from micis at gmx dot de 2006-06-19 07:06 --- Created an attachment (id=11693) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11693&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27742
[Bug libstdc++/28080] New: header dependencies
Hi,
could you clean up the header dependencies? E.g. a simple
#include
int main()
{
return 0;
}
produces 250kb preprocessed output. So the usage of STL slows down compilation
considerable.
Cheers,
André
--
Summary: header dependencies
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Woebbeking at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug middle-end/26900] Number of iterations not know for simple loop
--- Comment #11 from sebastian dot pop at cri dot ensmp dot fr 2006-06-19 07:50 --- Subject: Re: Number of iterations not know for simple loop I thought that this bug should have been fixed by now: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01749.html what is the status of that patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26900
[Bug fortran/20876] Subroutine call in FORALL block not PURE
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-06-19 08:11 --- Created an attachment (id=11694) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11694&action=view) Patch to fix PR The reason for the segfault is that the locus for the assign statement was never set. Will commit tonight under the obvious rule. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20876
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #7 from raffalli at univ-savoie dot fr 2006-06-19 08:44 --- Just for comparison: on my Intel dual core 3GHz, icc compiles in 15s within 200Mb with -O3 (including cpp) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug c++/28041] [gomp] ICE in g++.dg/gomp/atomic-[4,5,9].C
--- Comment #1 from uros at kss-loka dot si 2006-06-19 08:56 --- Works OK with gcc version 4.2.0 20060619 (experimental). -- uros at kss-loka dot si changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28041
[Bug fortran/20874] elemental function ought to be scalar
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-06-19 09:25 --- Created an attachment (id=11695) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11695&action=view) Patch to fix PR I will submit this tonight. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20874
[Bug middle-end/26900] Number of iterations not know for simple loop
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-06-19 09:25 --- Roger requested this do be done differently by canonicalizing comparisons in fold and using an improved operand_equal_p to do this. Patches for this are done, but need to wait for stage1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26900
[Bug libstdc++/28080] header dependencies
--- Comment #1 from pcarlini at suse dot de 2006-06-19 09:29 --- Ok, let's see what we can do... -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-19 09:29:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
The combined tree newlib stuff used with non-newlib targets
While trying to build a crosscompiler for 'sparc-solaris2.9': configured with: ../configure --build=i686-linux-gnu --host=i686-linux-gnu --target=sparc-solaris2.9 --with-gnu-as --with-gnu-ld --enable-shared --enable-threads --enable-languages=c,c++ the following thing happened : clip -- /data1/home/src/gcc-4.1.1/build/./gcc/xgcc -B/data1/home/src/gcc-4.1.1/build/./gcc/ -nostdinc -B/data1/home/src/gcc-4.1.1/build/sparc-solaris2.9/newlib/ -isystem /data1/home/src/gcc-4.1.1/build/sparc-solaris2.9/newlib/targ-include -isystem/data1/home/src/gcc-4.1.1/newlib/libc/include -B/usr/local/sparc-solaris2.9/bin/ -B/usr/local/sparc-solaris2.9/lib/ -isystem /usr/local/sparc-solaris2.9/include -isystem /usr/local/sparc-solaris2.9/sys-include -O2 -Os -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include \ -c ../../gcc/config/sparc/gmon-sol2.c -o gmon.o In file included from /data1/home/src/gcc-4.1.1/newlib/libc/include/sys/errno.h:11, from /data1/home/src/gcc-4.1.1/newlib/libc/include/errno.h:9, from ../../gcc/tsystem.h:96, from ../../gcc/config/sparc/gmon-sol2.c:36: /data1/home/src/gcc-4.1.1/newlib/libc/include/sys/reent.h:259: error: conflicting types for ‘__FILE’ /data1/home/src/gcc-4.1.1/build/./gcc/include/stdio_tag.h:30: error: previous declaration of ‘__FILE’ was here In file included from /data1/home/src/gcc-4.1.1/newlib/libc/include/unistd.h:4, from ../../gcc/tsystem.h:105, from ../../gcc/config/sparc/gmon-sol2.c:36: /data1/home/src/gcc-4.1.1/newlib/libc/include/sys/unistd.h:145: error: conflicting types for ‘swab’ /data1/home/src/gcc-4.1.1/build/./gcc/include/stdlib.h:153: error: previous declaration of ‘swab’ was here ../../gcc/config/sparc/gmon-sol2.c: In function ‘moncontrol’: ../../gcc/config/sparc/gmon-sol2.c:413: warning: implicit declaration of function ‘profil’ make[2]: *** [gmon.o] Error 1 make[2]: Leaving directory `/data1/home/src/gcc-4.1.1/build/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/data1/home/src/gcc-4.1.1/build' make: *** [all] Error 2 clip -- As can be seen the '--with-newlib' WAS NOT used in the GCC configure but the 'newlib' and 'libgloss' subdirs were symlinked to be seen in the main GCC source directory. Although being there, it shouldn't happen that they would in any way be used. So this sounds to be a bug... Removing the symlinks of course helped for a while, but then : --- clip -- make[3]: Leaving directory `/data1/home/src/gcc-4.1.1/build/gcc' echo timestamp > stmp-multilib make[2]: Leaving directory `/data1/home/src/gcc-4.1.1/build/gcc' Checking multilib configuration... multilib.out is unchanged Configuring in sparc-solaris2.9/newlib /bin/sh: /data1/home/src/gcc-4.1.1/newlib/configure: No such file or directory make[1]: *** [configure-target-newlib] Error 1 make[1]: Leaving directory `/data1/home/src/gcc-4.1.1/build' make: *** [all] Error 2 --- clip -- Those newlib things shouldn't have been used at all! Removing everything (from $build) and then starting from scratch seemed to be the only way (or the easy one) to workaround this bug.
[Bug java/27025] ICE on simple initializer
--- Comment #7 from aph at gcc dot gnu dot org 2006-06-19 11:13 --- Deferred 'til ecj. -- aph at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|aph at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27025
[Bug fortran/28081] New: Undue compile-time error for zero-sized substring
The following error should not happen: $ cat substr_3.f implicit none character(len=10) :: s, t integer :: i, j s = "abcdefghij" t(:10) = s(1:) s(16:15) = "foo" if (s /= t) call abort end $ gfortran substr_3.f In file substr_3.f:9 s(16:15) = "foo" 1 Error: Substring end index at (1) is out of bounds -- Summary: Undue compile-time error for zero-sized substring Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: fxcoudert at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28081
[Bug fortran/28081] Undue compile-time error for zero-sized substring
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-06-19 11:39
---
Here is a patch that fixes this problem (and gives a slightly better, IMHO,
error message):
Index: resolve.c
===
--- resolve.c (revision 114721)
+++ resolve.c (working copy)
@@ -2542,7 +2542,9 @@
return FAILURE;
}
- if (compare_bound_int (ref->u.ss.start, 1) == CMP_LT)
+ if (compare_bound_int (ref->u.ss.start, 1) == CMP_LT
+ && (compare_bound (ref->u.ss.end, ref->u.ss.start) == CMP_EQ
+ || compare_bound (ref->u.ss.end, ref->u.ss.start) == CMP_GT))
{
gfc_error ("Substring start index at %L is less than one",
&ref->u.ss.start->where);
@@ -2570,9 +2572,11 @@
}
if (ref->u.ss.length != NULL
- && compare_bound (ref->u.ss.end, ref->u.ss.length->length) == CMP_GT)
+ && compare_bound (ref->u.ss.end, ref->u.ss.length->length) == CMP_GT
+ && (compare_bound (ref->u.ss.end, ref->u.ss.start) == CMP_EQ
+ || compare_bound (ref->u.ss.end, ref->u.ss.start) == CMP_GT))
{
- gfc_error ("Substring end index at %L is out of bounds",
+ gfc_error ("Substring end index at %L exceeds the string length",
&ref->u.ss.start->where);
return FAILURE;
}
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Keywords||patch
Known to fail||4.2.0 4.1.2
Last reconfirmed|-00-00 00:00:00 |2006-06-19 11:39:33
date||
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28081
[Bug bootstrap/28082] New: internal compiler error: Segmentation fault
GCC Version: /tmp/gcc-4.1.1/host-hppa2.0w-hp-hpux11.00/gcc/xgcc -V xgcc: '-V' option must have argument $ /tmp/gcc-4.1.1/host-hppa2.0w-hp-hpux11.00/gcc/xgcc -v Using built-in specs. Target: hppa2.0w-hp-hpux11.00 Configured with: ./configure --prefix=/opt/OpenSource/gcc-4.1.1 Thread model: single gcc version 4.1.1 System type: HP-UX hpux006 B.11.00 U 9000/800 HP-UX HP9000/A500 Build options: -- --prefix=/opt/OpenSource/gcc-4.1.1 Line that triggerd the error: - /tmp/gcc-4.1.1/host-hppa2.0w-hp-hpux11.00/gcc/xgcc -save-temps -B/tmp/gcc-4.1.1/host-hppa2.0w-hp-hpux11.00/gcc/ -B/opt/OpenSource/gcc-4.1.1/hppa2.0w-hp-hpux11.00/bin/ -B/opt/OpenSource/gcc-4.1.1/hppa2.0w-hp-hpux11.00/lib/ -isystem /opt/OpenSource/gcc-4.1.1/hppa2.0w-hp-hpux11.00/include -isystem /opt/OpenSource/gcc-4.1.1/hppa2.0w-hp-hpux11.00/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I./../intl -I../.././gcc/../libcpp/include -DL_ffssi2 -c ../.././gcc/libgcc2.c -o libgcc/./_ffssi2.o Output: --- ./.././gcc/libgcc2.c: In function '__ffssi2': ../.././gcc/libgcc2.c:485: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: internal compiler error: Segmentation fault Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: info at pion dot xs4all dot nl GCC build triplet: hppa2.0w-hp-hpux11.00 GCC host triplet: hppa2.0w-hp-hpux11.00 GCC target triplet: hppa2.0w-hp-hpux11.00 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28082
[Bug bootstrap/28082] internal compiler error: Segmentation fault
--- Comment #1 from info at pion dot xs4all dot nl 2006-06-19 11:54 --- Created an attachment (id=11700) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11700&action=view) Tempory output of the compiler -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28082
[Bug libfortran/27895] problem with SPREAD and zero-sized arrays
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-06-19 12:03 --- CSHIFT has the same problem: $ cat zero_cshift.f90 real :: tempn(1) tempn = 2.0 print *, cshift(tempn(2:),shift=1) end $ gfortran zero_cshift.f90 && ./a.out Floating point exception I believe the following functions may not be safe: EOSHIFT, PACK, RESHAPE, TRANSPOSE, UNPACK (and of course, SPREAD and CSHIFT). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27895
[Bug other/28083] New: fixincludes generates headers not ending with newline
Some of the headers produces by fixincludes (e.g., asm/posix_types.h) do not end with a newline. I'm not sure if this is a bug in autogen, or improper use of autogen (the autogen-generated replacement text in fixincl.x ends, e.g., with #endif /* _POSIX_TYPES_H_WRAPPER */" again without newline), or a bug in the C code processing this replacement text. -- Summary: fixincludes generates headers not ending with newline Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peb at mppmu dot mpg dot de 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=28083
[Bug middle-end/28034] [4.2 Regression] section anchors break -fprofile-generate
--- Comment #2 from rsandifo at gcc dot gnu dot org 2006-06-19 12:57 --- In response to comment #1, "tmp" isn't really the problem. The problem is coverage_counter_alloc(), which initially create an array of 1000 counters, and only supplies the real type at the end of compilation: /* Generate and save a copy of this so it can be shared. */ /* We don't know the size yet; make it big enough that nobody will make any clever transformation on it. */ char buf[20]; tree gcov_type_node = get_gcov_type (); tree domain_tree = build_index_type (build_int_cst (NULL_TREE, 1000)); /* replaced later */ tree gcov_type_array_type = build_array_type (gcov_type_node, domain_tree); If the final array has fewer than 1000 counters (as in the reduced testcase), we get some silly padding, but correct code. If the array has more than 1000 counters (as in the original testcase), the offset calculation wraps. Like the -ftree-vectorize thing, this is a chicken-and-egg ordering problem. The fix is to avoid using section anchors for tree_ctr_tables[]. Richard -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-19 12:57:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28034
[Bug fortran/20867] statement function args not given implicit type early enough
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-06-19 13:00 --- Created an attachment (id=11702) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11702&action=view) Patch to fix this PR Will submit tonight. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20867
[Bug other/28083] fixincludes generates headers not ending with newline
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-19 13:14 --- Please provide a testcase (the unfixed asm/posix_types.h). Also you should check if using gcc 4.x fixes this, as the 3.x series are no longer maintained. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28083
[Bug libmudflap/28077] [4.1/4.2 regression] pass39-frag.c produces mudflap violation on alpha
--- Comment #2 from fche at redhat dot com 2006-06-19 14:01 --- It looks like only the statically linked multithreding test cases trigger the problem. Would you mind trying ot hand-build one of those executables, but adding -rdynamic to LDFLAGS, and run with -backtrace=99 in MUDFLAP_OPTIONS? That way, the backtraces should have more symbolic information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28077
[Bug target/28084] New: /usr/include/errno.h:28: error: previous declaration of 'int errno' with 'C++' linkage
/mnt/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/mnt/gnu/gcc/objdir/./gcc -nostd inc++ -L/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src -L/mnt/gnu/gc c/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -B/opt/gnu/gcc/gcc-4.2.0/h ppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/lib/ -i system /opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gc c/gcc-4.2.0/hppa2.0w-hp-hpux11.11/sys-include -I/mnt/gnu/gcc/objdir/hppa2.0w-hp- hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/mnt/gnu/gcc/objdir/hppa2 .0w-hp-hpux11.11/libstdc++-v3/include -I/mnt/gnu/gcc/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics- show-location=once -g -O2 -c c++locale.cc -fPIC -DPIC -o .libs/c++locale.o /usr/include/errno.h:28: error: previous declaration of 'int errno' with 'C++' linkage /usr/include/sys/errno.h:48: error: conflicts with new declaration with 'C' linkage make[4]: *** [c++locale.lo] Error 1 make[4]: Leaving directory `/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++- v3/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++- v3' make[2]: *** [all] Error 2 -bash-2.05b$ ./xgcc -B./ -v Reading specs from ./specs Target: hppa2.0w-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enable-shared --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.2.0 --with-gmp=/opt/gnu/gcc/gcc-4.2.0 --enable-debug=no --disable-nls --enable-threads=posix --enable-languages=c,c++,objc,fortran,java,ada,obj-c++ Thread model: posix gcc version 4.2.0 20060619 (experimental) -- Summary: /usr/include/errno.h:28: error: previous declaration of 'int errno' with 'C++' linkage Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28084
[Bug other/28083] fixincludes generates headers not ending with newline
--- Comment #2 from peb at mppmu dot mpg dot de 2006-06-19 14:24 --- Created an attachment (id=11703) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11703&action=view) The file asm/posix_typed.h as produced by fixincludes from gcc-3.4.6 I just checked that the same file created by gcc-4.2.0 does end with a newline (the replacement text in fixincl.x again ends without newline, thus the problem is hidden somewhere in the C code processing fixincl.x). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28083
[Bug middle-end/28034] [4.2 Regression] section anchors break -fprofile-generate
--- Comment #3 from rsandifo at gcc dot gnu dot org 2006-06-19 14:31 --- Created an attachment (id=11704) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11704&action=view) Candidate patch Janis, can you try this patch? It avoids the use of section anchors for coverage counters. I'm bootstrapping it on i686-pc-linux-gnu, but that's not really much of a test. Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28034
[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types
--- Comment #13 from dberlin at gcc dot gnu dot org 2006-06-19 14:34 --- Subject: Bug 27341 Author: dberlin Date: Mon Jun 19 14:33:46 2006 New Revision: 114771 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114771 Log: 2006-06-19 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/27341 * tree-cfg.c (gimplify_val): Call mark_new_vars_to_rename on the statement we get. * tree-complex.c (pass_lower_complex): Update SMT usage. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr27341-1.c trunk/gcc/testsuite/gcc.c-torture/compile/pr27341-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-complex.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27341
[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types
--- Comment #14 from dberlin at gcc dot gnu dot org 2006-06-19 14:34 --- Fixed -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27341
[Bug c++/28085] New: initialization of zero-sized array causes internal compiler error
Following is the sequence to reproduce this issue and full g++ -v output.
$ cat source.cpp
int tab[0]={};
main()
{
}
$ g++ source.cpp
source.cpp:2: internal compiler error: in tree_low_cst, at tree.c:3255
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
.
$ g++ -v
Lecture des spécification à partir de /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configuré avec: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --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
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
Modèle de thread: posix
version gcc 3.3.5 (Debian 1:3.3.5-13)
$
system is Debian Sarge 3.1 for x86
--
Summary: initialization of zero-sized array causes internal
compiler error
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bertrand dot marlier at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28085
[Bug middle-end/28045] [4.0/4.1/4.2 Regression] Bitfield, &&, and optimization => bad code generation
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-06-19 14:48 --- Subject: Bug 28045 Author: rguenth Date: Mon Jun 19 14:48:47 2006 New Revision: 114772 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114772 Log: 2006-06-19 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/28045 * fold-const.c (operand_equal_p): Check if the argument types have the same precision before stripping NOPs. * gcc.dg/torture/pr28045.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr28045.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28045
[Bug middle-end/28045] [4.0/4.1 Regression] Bitfield, &&, and optimization => bad code generation
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-06-19 14:49 --- Fixed on the mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] |Bitfield, &&, and |Bitfield, &&, and |optimization => bad code|optimization => bad code |generation |generation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28045
[Bug target/27861] [4.0/4.1/4.2 regression] ICE in expand_expr_real_1, at expr.c:6916
--- Comment #5 from sayle at gcc dot gnu dot org 2006-06-19 14:57 --- Subject: Bug 27861 Author: sayle Date: Mon Jun 19 14:57:17 2006 New Revision: 114773 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114773 Log: PR target/27861 * expmed.c (expand_shift): On SHIFT_COUNT_TRUNCATED targets, we may have stripped a SUBREG from the shift count, so we may need to convert_to_mode back to the type's mode before calling make_tree. Use new_amount instead of amount to avoid expanding a tree twice. * gcc.dg/pr27861-1.c: New test case. Added: trunk/gcc/testsuite/gcc.dg/pr27861-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27861
[Bug middle-end/26807] [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)
--- Comment #18 from sje at cup dot hp dot com 2006-06-19 15:53 --- My PA runs show no failures of the pr24626* tests anymore. I think this problem has been resolved and the defect can be closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
[Bug middle-end/28045] [4.0/4.1 Regression] Bitfield, &&, and optimization => bad code generation
--- Comment #8 from Jerry dot James at usu dot edu 2006-06-19 16:27 --- On behalf of the XEmacs team, I thank you for your amazingly speedy attention to this bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28045
Mainline build problem on FC4
OK, so I wasn't just wacko last week. Mainline fails to build on Fedora Core 4 (with all the latest updates, kernel 2111) when built with checking disabled. Diego verified this on a second FC4 box. The compile fails when building crtfastmath during stage2. It doesn't happen when checking is enabled, nor does it happen on FC5 under any circumstance I have found. /build/gcc/2006-06-19-nc/./gcc/xgcc -B/build/gcc/2006-06-19-nc/./gcc/ -B/install/gcc-nc/i686-pc-linux-gnu/bin/ -B/install/gcc-nc/i686-pc-linux-gnu/lib/ -isystem /install/gcc-nc/i686-pc-linux-gnu/include -isystem /install/gcc-nc/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -msse -c \ /src/gcc/2006-06-19/gcc/gcc/config/i386/crtfastmath.c \ -o crtfastmath.o /bin/sh /src/gcc/2006-06-19/gcc/gcc/../move-if-change tmp-macro_list macro_list *** glibc detected *** /build/gcc/2006-06-19-nc/./gcc/cc1: malloc(): memory corruption: 0x08591630 *** === Backtrace: = /lib/libc.so.6[0x5ee1a2] /lib/libc.so.6(malloc+0x74)[0x5ef587] /lib/libc.so.6[0x5af193] /lib/libc.so.6[0x5ad498] /lib/libc.so.6[0x5ace25] /lib/libc.so.6(__dcgettext+0x43)[0x5abed7] /lib/libc.so.6(strsignal+0x13c)[0x5f4a13] /build/gcc/2006-06-19-nc/./gcc/cc1[0x830e5b2] === Memory map: 0055d000-0055e000 r-xp 0055d000 00:00 0 [vdso] 0055e000-00578000 r-xp fd:00 5499650/lib/ld-2.3.6.so 00578000-00579000 r-xp 00019000 fd:00 5499650/lib/ld-2.3.6.so 00579000-0057a000 rwxp 0001a000 fd:00 5499650/lib/ld-2.3.6.so 0058a000-006ad000 r-xp fd:00 5499657/lib/libc-2.3.6.so 006ad000-006af000 r-xp 00122000 fd:00 5499657/lib/libc-2.3.6.so 006af000-006b1000 rwxp 00124000 fd:00 5499657/lib/libc-2.3.6.so 006b1000-006b3000 rwxp 006b1000 00:00 0 00a29000-00a33000 r-xp fd:00 16893261 /build/gcc/2006-06-19-nc/prev-gcc/libgcc_s.so.1 00a33000-00a34000 rwxp 9000 fd:00 16893261 /build/gcc/2006-06-19-nc/prev-gcc/libgcc_s.so.1 08048000-084cf000 r-xp fd:00 16926839 /build/gcc/2006-06-19-nc/gcc/cc1 084cf000-084d4000 rw-p 00486000 fd:00 16926839 /build/gcc/2006-06-19-nc/gcc/cc1 084d4000-085a rw-p 084d4000 00:00 0 [heap] b7b0-b7b21000 rw-p b7b0 00:00 0 b7b21000-b7c0 ---p b7b21000 00:00 0 b7c87000-b7dd8000 rw-p b7c87000 00:00 0 b7dd8000-b7fd8000 r--p fd:00 201117 /usr/lib/locale/locale-archive b7fd8000-b7fd9000 rw-p b7fd8000 00:00 0 b7ffe000-b800 rw-p b7ffe000 00:00 0 bffe8000-b000 rw-p bffe8000 00:00 0 [stack] xgcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [crtfastmath.o] Error 1 make[3]: *** Waiting for unfinished jobs echo timestamp > s-macro_list make[3]: *** Waiting for unfinished jobs rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gpl.pod gcc.pod make[3]: Leaving directory `/build/gcc/2006-06-19-nc/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/build/gcc/2006-06-19-nc' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/build/gcc/2006-06-19-nc' make: *** [all] Error 2 Has anyone else encountered this? I'm checking back to see when/if this suddenly appeared. It also happens with a much earlier version of the kernel. If I recall from my poking around earlier last week, bitmap.o get miscompiled in stage1, but take that with a grain of salt.. a lot of things were going on last week and I don't know if that is still true today. Andrew
[Bug middle-end/26807] [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)
--- Comment #19 from danglin at gcc dot gnu dot org 2006-06-19 16:35 --- Fixed by patch. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
[Bug c++/28085] initialization of zero-sized array causes internal compiler error
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-19 16:40 --- Fixed in 3.4.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28085
[Bug c/28073] Type-punned pointer passed as function parameter generates bad assembly sequence
--- Comment #2 from sorenj at us dot ibm dot com 2006-06-19 16:44 --- Changing just one line of the test program to the (AFAIK) legal C code. By casting through void *, we are addressing Andrew's concerns about violating the C rules. Foo *pFoo = *(Foo **) ((void *)&longPtr); /* // BAD! */ eliminates the type-punned warning, even at the highest possible warning level, and continues to generate code the results in a bad return value. This test case illustrates that this problem is actually worse than we originally thought, as now incorrect code is generated without any warning. $ gcc -Wstrict-aliasing=2 -Wall -O2 badcase.c $ ./a.out ; echo $? 76 $ gcc -Wstrict-aliasing=2 -Wall -O2 -fno-strict-aliasing badcase.c $ ./a.out ; echo $? 1 -- sorenj at us dot ibm dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28073
[Bug c/28073] Type-punned pointer passed as function parameter generates bad assembly sequence
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-19 16:54 --- (In reply to comment #2) > Changing just one line of the test program to the (AFAIK) legal C code. By > casting through void *, we are addressing Andrew's concerns about violating > the > C rules. > > Foo *pFoo = *(Foo **) ((void *)&longPtr); /* // BAD! */ No you are still accessing a long as a "Foo*", the intermediate types does not change a thing. The cast to "void*" is designed to get rid of the warning but does not get rid of the undefinedness of the code. *** This bug has been marked as a duplicate of 21920 *** -- 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=28073
[Bug c/21920] alias violating
--- Comment #103 from pinskia at gcc dot gnu dot org 2006-06-19 16:54 --- *** Bug 28073 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sorenj at us dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug libstdc++/28080] header dependencies
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-19 16:56 --- Specificly it was fixed by: 2005-11-24 Bruce Korb <[EMAIL PROTECTED]> * fixincl.c(write_replacement) "here strings" in AutoGen often/generally don't have a terminating newline. Check the last byte for '\n'. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug libstdc++/28080] header dependencies
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-19 16:57 --- Woops wrong bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug target/28084] /usr/include/errno.h:28: error: previous declaration of 'int errno' with 'C++' linkage
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-19
17:07 ---
Subject: Re: New: /usr/include/errno.h:28: error: previous declaration of
'int errno' with 'C++' linkage
> /usr/include/errno.h:28: error: previous declaration of 'int errno' with 'C++'
> linkage
> /usr/include/sys/errno.h:48: error: conflicts with new declaration with 'C'
> linkage
It appears to me that HP intentionally declares 'errno' with both
'C' and 'C++' linkage. This is what I see in sys/errno.h:
# ifdef __cplusplus
extern "C" {
# endif /* __cplusplus */
# if defined(_REENTRANT) && !defined(_PTHREADS_DRAFT4)
/* Get errno definition by including not */
# else /* ! _REENTRANT || _PTHREADS_DRAFT4 */
extern int errno;
# endif /* ! _REENTRANT || _PTHREADS_DRAFT4 */
# ifdef __cplusplus
}
# endif /* __cplusplus */
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28084
[Bug other/28083] fixincludes generates headers not ending with newline
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-19 17:22 --- Fixed by: 2005-11-24 Bruce Korb <[EMAIL PROTECTED]> * fixincl.c(write_replacement) "here strings" in AutoGen often/generally don't have a terminating newline. Check the last byte for '\n'. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28083
[Bug target/28084] [4.2 Regression] /usr/include/errno.h:28: error: previous declaration of 'int errno' with 'C++' linkage
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-19 17:25 --- See commment #6 in PR 27227 for more about this bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227#c6 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||build Last reconfirmed|-00-00 00:00:00 |2006-06-19 17:25:44 date|| Summary|/usr/include/errno.h:28:|[4.2 Regression] |error: previous declaration |/usr/include/errno.h:28: |of 'int errno' with 'C++' |error: previous declaration |linkage |of 'int errno' with 'C++' ||linkage Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28084
[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #15 from aph at gcc dot gnu dot org 2006-06-19 17:38 --- Subject: Bug 27908 Author: aph Date: Mon Jun 19 17:38:08 2006 New Revision: 114778 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114778 Log: 2006-06-19 Andrew Haley <[EMAIL PROTECTED]> PR java/1305 PR java/27908 * expr.c (java_modify_addr_for_volatile): New function. (expand_java_field_op): Handle volatile fields. * java-gimplify.c (java_gimplify_component_ref): Call java_modify_addr_for_volatile to give the field_ref the correct volatile type. (java_gimplify_modify_expr): Likewise. * java-tree.h (java_modify_addr_for_volatile): New decl. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/expr.c trunk/gcc/java/java-gimplify.c trunk/gcc/java/java-tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug java/1305] [JSR133] GCJ ignores volatile modifier
--- Comment #9 from aph at gcc dot gnu dot org 2006-06-19 17:38 --- Subject: Bug 1305 Author: aph Date: Mon Jun 19 17:38:08 2006 New Revision: 114778 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114778 Log: 2006-06-19 Andrew Haley <[EMAIL PROTECTED]> PR java/1305 PR java/27908 * expr.c (java_modify_addr_for_volatile): New function. (expand_java_field_op): Handle volatile fields. * java-gimplify.c (java_gimplify_component_ref): Call java_modify_addr_for_volatile to give the field_ref the correct volatile type. (java_gimplify_modify_expr): Likewise. * java-tree.h (java_modify_addr_for_volatile): New decl. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/expr.c trunk/gcc/java/java-gimplify.c trunk/gcc/java/java-tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1305
[Bug c/28086] New: symbols missing on ia64
When building kaffe 1.1.7 (http://www.kaffe.org/) with GCC 4.1 I get the following error message: ia64-linux-gnu-gcc -g -O2 -Wall -W -Wextra -g -O1 -fno-omit-frame-pointer -o .libs/kaffe-bin main.o version.o .libs/kaffe-binS.o -Wl,--export-dynamic ../../kaffe/kaffevm/.libs/libkaffevm.so -ldl -lm ../../replace/.libs/libreplace.a -lpthread -Wl,--rpath -Wl,/usr/lib/kaffe/jthreads/jre/lib/ia64 ../../kaffe/kaffevm/.libs/libkaffevm.so: undefined reference to `__sync_val_compare_and_swap_di' ../../kaffe/kaffevm/.libs/libkaffevm.so: undefined reference to `__sync_fetch_and_add_di' collect2: ld returned 1 exit status With GCC 4.0 kaffe builds fine on ia64. -- Summary: symbols missing on ia64 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: konqueror at gmx dot de GCC build triplet: ia64-linux-gnu GCC host triplet: ia64-linux-gnu GCC target triplet: ia64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28086
[Bug target/28086] [4.1/4.2 Regression] symbols missing on ia64
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target Keywords||link-failure Summary|symbols missing on ia64 |[4.1/4.2 Regression] symbols ||missing on ia64 Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28086
[Bug libstdc++/28080] header dependencies
--- Comment #4 from Woebbeking at web dot de 2006-06-19 17:58 --- Subject: Re: header dependencies On Monday 19 June 2006 11:29, pcarlini at suse dot de wrote: > --- Comment #1 from pcarlini at suse dot de 2006-06-19 09:29 > Ok, let's see what we can do... Wow, fast reply! I hope you're successful :-) Maybe you could look at STLPort 5.x, AFAIK it's "more" efficient in this case. It also has other nice features like: - STL containers vector, deque, list and slist pointer specialization to limit code bloats (see _STLP_USE_PTR_SPECIALIZATIONS on config file); - Expression template for string concatenation operations (available through the _STLP_USE_TEMPLATE_EXPRESSION config option); Cheers, André -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug libstdc++/28080] header dependencies
--- Comment #5 from pcarlini at suse dot de 2006-06-19 18:05 --- (In reply to comment #4) > Wow, fast reply! I hope you're successful :-) Maybe you could look at > STLPort 5.x, AFAIK it's "more" efficient in this case. It also has > other nice features like: Ok, thanks, but certainly we are not going to look inside the headers, plagiarism doesn't seem the way to go... -- pcarlini at suse dot de changed: What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug c++/28017] lack of guard variables for explicitly instantiated template static data
--- Comment #10 from hhinnant at apple dot com 2006-06-19 18:11 --- It turns out this still isn't quite right. Looks like we need: #define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) && (DECL_COMMON (decl) \ || DECL_ONE_ONLY (decl) \ || DECL_WEAK (decl) \ || (TARGET_WEAK_NOT_IN_ARCHIVE_TOC \ && DECL_LANG_SPECIFIC (decl) \ && (DECL_EXPLICIT_INSTANTIATION (decl) \ || DECL_TEMPLATE_SPECIALIZATION (decl) The former solution was dereferencing a null pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28017
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-06-19 18:21 --- Paul Thomas proposed a patch that fixes the F95 problem. We still need to write simplification routines to enable such code (which is valid F2003) to compile with gfortran. I don't have time for that right now. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert 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=25104
[Bug fortran/28005] gfortran: mathmul produces wrong result
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-19 18:44 --- I forgot to assign this to myself Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28005
Re: [Bug c/28073] Type-punned pointer passed as function parameter generates bad assembly sequence
sorenj at us dot ibm dot com wrote:
> --- Comment #2 from sorenj at us dot ibm dot com 2006-06-19 16:44 ---
> Changing just one line of the test program to the (AFAIK) legal C code. By
> casting through void *, we are addressing Andrew's concerns about violating
> the
> C rules.
No you aren't.
The only thing that matters is what the type of the dereferenced pointer
is, not the intermediate casts.
For example,
int *foo
float b;
float *c;
b = 5.0
foo = (int*)&b
c = (float *)foo
printf("%f\n", *c);
is legal.
>
> Foo *pFoo = *(Foo **) ((void *)&longPtr); /* // BAD! */
Still not legal.
>
> eliminates the type-punned warning, even at the highest possible warning
> level,
> and continues to generate code the results in a bad return value. This test
> case illustrates that this problem is actually worse than we originally
> thought, as now incorrect code is generated without any warning.
We can't issue warnings in every case because it is impossible to detect
every case.
We could probably issue a warning in this case.
[Bug c/28073] Type-punned pointer passed as function parameter generates bad assembly sequence
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-06-19 18:55 ---
Subject: Re: Type-punned pointer passed as function parameter
generates bad assembly sequence
sorenj at us dot ibm dot com wrote:
> --- Comment #2 from sorenj at us dot ibm dot com 2006-06-19 16:44 ---
> Changing just one line of the test program to the (AFAIK) legal C code. By
> casting through void *, we are addressing Andrew's concerns about violating
> the
> C rules.
No you aren't.
The only thing that matters is what the type of the dereferenced pointer
is, not the intermediate casts.
For example,
int *foo
float b;
float *c;
b = 5.0
foo = (int*)&b
c = (float *)foo
printf("%f\n", *c);
is legal.
>
> Foo *pFoo = *(Foo **) ((void *)&longPtr); /* // BAD! */
Still not legal.
>
> eliminates the type-punned warning, even at the highest possible warning
> level,
> and continues to generate code the results in a bad return value. This test
> case illustrates that this problem is actually worse than we originally
> thought, as now incorrect code is generated without any warning.
We can't issue warnings in every case because it is impossible to detect
every case.
We could probably issue a warning in this case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28073
[Bug libmudflap/28077] [4.1/4.2 regression] pass39-frag.c produces mudflap violation on alpha
--- Comment #3 from tbm at cyrius dot com 2006-06-19 19:34 --- Created an attachment (id=11705) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11705&action=view) more detailed log This is with the options you specified but it seems it doesn't contain so much more information. Did I do something wrong or is that what you were looking for? -- tbm at cyrius dot com changed: What|Removed |Added Attachment #11691|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28077
[Bug middle-end/26198] Unfolded comparison after cfg_cleanup
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-06-19 19:40 --- Note that the reason mentioned was fixed recently, but we still have (in .optimized): :; p = &D.2217->a2.x[0]; D.2237 = &D.2217->a2.x[2]; if (p < D.2237) goto ; else goto ; ... :; p = &D.2217->a3.x[0]; D.2243 = &D.2217->a3.x[2]; if (p < D.2243) goto ; else goto ; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26198
[Bug tree-optimization/27090] FRE does not look past previous type casts
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-06-19 20:10 --- Subject: Bug 27090 Author: rguenth Date: Mon Jun 19 20:10:02 2006 New Revision: 114786 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114786 Log: 2006-06-19 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/27090 * g++.dg/tree-ssa/pr27090.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr27090.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27090
[Bug target/28086] [4.1/4.2 Regression] symbols missing on ia64
--- Comment #1 from schwab at suse dot de 2006-06-19 20:14 --- These symbols were never supposed to be used directly, only via the __sync_val_compare_and_swap and __sync_fetch_and_add macros (which are now builtins). -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28086
[Bug c++/28088] New: Internal compiler error on boost mpl test/apply.cpp
% g++ -v Using built-in specs. Target: i386-pc-solaris2.10 Configured with: ../configure --cache-file=./config.cache --srcdir=/openpkg/RPM/TMP/gcc-4.1.1/obj/.. --prefix=/openpkg --exec-prefix=/openpkg --includedir=/openpkg/include/gcc --libexecdir=/openpkg/libexec/gcc --with-gxx-include-dir=/openpkg/include/g++ --with-local-prefix=/openpkg/lib/gcc --enable-languages=c,c++ --enable-threads=posix --disable-maintainer-mode --disable-shared --disable-nls --with-gnu-ld --with-ld=/openpkg/bin/ld --with-gnu-as --with-as=/openpkg/bin/as --disable-multilib Thread model: posix gcc version 4.1.1 (OpenPKG-CURRENT) % "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -fPIC -DBOOST_ALL_NO_LIB=1 -I".." -c -o "/home/cae/boost-regression/results/boost/bin.v2/libs/mpl/test/apply.test/gcc-4.1.1_sunos_i86pc/debug/debug-symbols-off/apply.o" "../libs/mpl/test/apply.cpp" ../boost/mpl/aux_/preprocessed/gcc/template_arity.hpp: In instantiation of 'boost::mpl::aux::template_arity': ../libs/mpl/test/apply.cpp:63: instantiated from here ../boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:98: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See attached apply.i.gz -- Summary: Internal compiler error on boost mpl test/apply.cpp Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc-bklyn at sneakemail dot com GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28088
[Bug c++/28088] Internal compiler error on boost mpl test/apply.cpp
--- Comment #1 from gcc-bklyn at sneakemail dot com 2006-06-19 21:05 --- Created an attachment (id=11707) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11707&action=view) PReprocessed source to boost/mpl/test/apply.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28088
[Bug c/28073] Type-punned pointer passed as function parameter generates bad assembly sequence
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-06-19 21:04 --- Created an attachment (id=11706) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11706&action=view) warn for bad casts hiding type-punning At suse we used the attached patch to teach packagers not "fix" strict aliasing warnings by introducing a (void *) cast inbetween. Sort of a compromise between too much false positives and catching all evil use. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28073
[Bug middle-end/28034] [4.2 Regression] section anchors break -fprofile-generate
--- Comment #4 from janis at gcc dot gnu dot org 2006-06-19 21:08 --- I tried the patch with a C-only bootstrap for biarch powerpc64-linux and ran the three CPU2000 tests that had failed with profile generate/use; with the patch they work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28034
[Bug c++/28088] Internal compiler error on boost mpl test/apply.cpp
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-19 22:10 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28088
[Bug fortran/20874] elemental function ought to be scalar
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-06-19 22:11
---
Regarding your patch:
+ /* An elemental function is required to return a scalar 12.7.1 */
+ if (sym->attr.elemental && sym->attr.function
+ && sym->as && sym->as->rank)
I'm not sure why the condition sym->as->rank is needed (and if you decide to
include it, I'd prefer the explicit (sym->as->rank > 0)); elsewhere in
resolve.c, I read:
if (gfc_elemental (proc))
{
if (sym->as != NULL)
{
gfc_error
("Argument '%s' of elemental procedure at %L must be scalar",
sym->name, &sym->declared_at);
continue;
}
which makes me think that simply having as != NULL is enough to know that it's
not a scalar.
One more thing: reading the lines after the code I pasted above reminds me that
we should check that an elemental function doesn't return a pointer. Could it
be along these lines?:
+ if (sym->attr.elemental && sym->attr.function
+ && sym->result->attr.pointer)
+...
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
Known to fail||4.2.0 4.1.2
Last reconfirmed|2005-12-31 20:03:28 |2006-06-19 22:11:19
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20874
[Bug libfortran/27784] [4.1 only] Comparison of strings with char(0)
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-06-19 22:16 --- This was fixed on mainline by: r114175 | tkoenig | 2006-05-28 22:25:15 +0200 (Sun, 28 May 2006) | 11 lines 2006-05-28 Thomas Koenig <[EMAIL PROTECTED]> * intrinsics/string_intrinsics.c (compare_string): Use memcmp instead of strncmp to avoid tripping over CHAR(0) in a string. 2006-05-28 Thomas Koenig <[EMAIL PROTECTED]> * gfortran.dg/string_null_compare_1.f: New test case. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch Known to fail||4.1.2 Known to work||4.2.0 Summary|Comparison of strings with |[4.1 only] Comparison of |char(0) |strings with char(0) Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27784
[Bug fortran/27715] [4.1 only] Extented ASCII characters lead to wrong "CASE" selection
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2006-06-19 22:27 --- (In reply to comment #15) > If you want to, please go ahead and commit the fixes for PR 27980, PR 27715 > and PR 27784 to 4.1. As I can't find sleep tonight, I'll be backporting those patches. I spent some time trying to apply patch for PR27980 to mainline, only to realize it was already in. If you include the PR number (just like in the ChangeLog) in the commit message, the commit message will end up automagically in bugzilla, which is very useful :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715
[Bug fortran/27980] [4.1 only] Wrong allocation for zero-sized function result
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-06-19 22:29 --- Was fixed on mainline by r114677 | tkoenig | 2006-06-15 12:30:09 +0200 (Thu, 15 Jun 2006) | 23 lines 2006-06-15 Thomas Koenig <[EMAIL PROTECTED]> * trans-array.h (gfc_trans_create_temp_array): Add bool argument. * trans-arrray.c (gfc_trans_create_temp_array): Add extra argument "function" to show if we are translating a function. If we are translating a function, perform checks whether the size along any argument is negative. In that case, allocate size 0. (gfc_trans_allocate_storage): Add function argument (as false) to gfc_trans_create_temp_array call. * trans-expr.c (gfc_conv_function_call): Add function argument (as true) to gfc_trans_create_temp_array call. * trans-stmt.c (gfc_conv_elemental_dependencies): Add function argument (as false) to gfc_trans_create_temp_array call. * trans-intrinsic.c: Likewise. 2006-06-15 Thomas Koenig <[EMAIL PROTECTED]> * gfortran.dg/allocate_zerosize_2.f90: New test case. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch Known to fail||4.1.2 Known to work||4.2.0 Summary|Wrong allocation for zero- |[4.1 only] Wrong allocation |sized function result |for zero-sized function ||result Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27980
[Bug java/28089] New: jc1 miscompilation with fields inherited from interfaces
Look at initfield.java or PR162.java from the test suite.
>From initfield:
interface iface
{
final value x = new value();
}
public class initfield implements iface
{
public static void main(String[] args)
{
System.out.println(x.field);
...
When compiled with a correct java compiler (not gcj)
to bytecode, this line is compiled as:
0: getstatic #18=
3: getstatic #24=
6: getfield #28=
9: invokevirtual #34=
Note at PC=3 how the qualifying class is 'initfield', not 'iface'.
If this class is the run through gcj (using the c++ abi) the resulting
program will crash.
I think the fix is for gcj to notice this situation and emit an
explicit class initialization call for the declaring class of the field.
This conforms to the overall c++ abi idea; for BC we already properly
handle this at runtime.
This is a blocker for ecj integration.
--
Summary: jc1 miscompilation with fields inherited from interfaces
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28089
[Bug fortran/27980] [4.1 only] Wrong allocation for zero-sized function result
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-06-19 22:45 --- The backport of that patch is not trivial, since the mainline patch depends on Erik E.'s allocatable function result patch, which was never included in 4.1. I don't think it's difficult to backport either, but since it's your patch, Thomas, I'll let you do it when you have more time. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27980
[Bug java/28090] New: incorrect implementation of expand_java_arraystore
According to the ArrayStore.java test case, bounds checks should
take precedence over array store checks. However, expand_java_arraystore
clearly does it in the wrong order:
if (TREE_CODE (rhs_type_node) == POINTER_TYPE)
{
tree check = build_java_arraystore_check (array, rhs_node);
java_add_stmt (check);
}
array = build_java_arrayaccess (array, rhs_type_node, index);
--
Summary: incorrect implementation of expand_java_arraystore
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28090
Re: Mainline build problem on FC4
On Mon, 2006-06-19 at 12:31 -0400, Andrew MacLeod wrote: > OK, so I wasn't just wacko last week. Mainline fails to build on Fedora > Core 4 (with all the latest updates, kernel 2111) when built with > checking disabled. Diego verified this on a second FC4 box. > I've narrowed this down to the patch in revision 114674. (114673 works fine, 114674 exhibits the problem) r114674 | rakdver | 2006-06-15 05:42:03 -0400 (Thu, 15 Jun 2006) | 10 lines * tree-ssa-loop-niter.c (implies_nonnegative_p): New function. (derive_constant_upper_bound): Derive more precise upper bound in common cases. Return type changed to double_int. (record_estimate): Reflect the changed return type of derive_constant_upper_bound. * double-int.c (double_int_zext, double_int_sext): Fix. * gcc.dg/tree-ssa/loop-18.c: New test. bitmap.o in stage 2 is miscompiled by the stage 1 compiler. If I replace bitmap.o with the bitmap.o produced by the stage 2 compiler from rev. 114673, everything proceeds and we get a failure in stage3. Thats as far as I've gotten today. Andrew PS. The only configure options are --enable-languages=c,c++ --disable-checking > The compile fails when building crtfastmath during stage2. > > It doesn't happen when checking is enabled, nor does it happen on FC5 > under any circumstance I have found. > > > /build/gcc/2006-06-19-nc/./gcc/xgcc -B/build/gcc/2006-06-19-nc/./gcc/ > -B/install/gcc-nc/i686-pc-linux-gnu/bin/ > -B/install/gcc-nc/i686-pc-linux-gnu/lib/ -isystem > /install/gcc-nc/i686-pc-linux-gnu/include -isystem > /install/gcc-nc/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC-W > -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT > -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -msse -c \ > /src/gcc/2006-06-19/gcc/gcc/config/i386/crtfastmath.c \ > -o crtfastmath.o > /bin/sh /src/gcc/2006-06-19/gcc/gcc/../move-if-change tmp-macro_list > macro_list > *** glibc detected *** /build/gcc/2006-06-19-nc/./gcc/cc1: malloc(): memory > corruption: 0x08591630 *** > === Backtrace: = > /lib/libc.so.6[0x5ee1a2] > /lib/libc.so.6(malloc+0x74)[0x5ef587] > /lib/libc.so.6[0x5af193] > /lib/libc.so.6[0x5ad498] > /lib/libc.so.6[0x5ace25] > /lib/libc.so.6(__dcgettext+0x43)[0x5abed7] > /lib/libc.so.6(strsignal+0x13c)[0x5f4a13] > /build/gcc/2006-06-19-nc/./gcc/cc1[0x830e5b2] > === Memory map: > 0055d000-0055e000 r-xp 0055d000 00:00 0 [vdso] > 0055e000-00578000 r-xp fd:00 5499650/lib/ld-2.3.6.so > 00578000-00579000 r-xp 00019000 fd:00 5499650/lib/ld-2.3.6.so > 00579000-0057a000 rwxp 0001a000 fd:00 5499650/lib/ld-2.3.6.so > 0058a000-006ad000 r-xp fd:00 5499657/lib/libc-2.3.6.so > 006ad000-006af000 r-xp 00122000 fd:00 5499657/lib/libc-2.3.6.so > 006af000-006b1000 rwxp 00124000 fd:00 5499657/lib/libc-2.3.6.so > 006b1000-006b3000 rwxp 006b1000 00:00 0 > 00a29000-00a33000 r-xp fd:00 16893261 > /build/gcc/2006-06-19-nc/prev-gcc/libgcc_s.so.1 > 00a33000-00a34000 rwxp 9000 fd:00 16893261 > /build/gcc/2006-06-19-nc/prev-gcc/libgcc_s.so.1 > 08048000-084cf000 r-xp fd:00 16926839 > /build/gcc/2006-06-19-nc/gcc/cc1 > 084cf000-084d4000 rw-p 00486000 fd:00 16926839 > /build/gcc/2006-06-19-nc/gcc/cc1 > 084d4000-085a rw-p 084d4000 00:00 0 [heap] > b7b0-b7b21000 rw-p b7b0 00:00 0 > b7b21000-b7c0 ---p b7b21000 00:00 0 > b7c87000-b7dd8000 rw-p b7c87000 00:00 0 > b7dd8000-b7fd8000 r--p fd:00 201117 > /usr/lib/locale/locale-archive > b7fd8000-b7fd9000 rw-p b7fd8000 00:00 0 > b7ffe000-b800 rw-p b7ffe000 00:00 0 > bffe8000-b000 rw-p bffe8000 00:00 0 [stack] > xgcc: Internal error: Segmentation fault (program cc1) > Please submit a full bug report. > See http://gcc.gnu.org/bugs.html> for instructions. > make[3]: *** [crtfastmath.o] Error 1 > make[3]: *** Waiting for unfinished jobs > echo timestamp > s-macro_list > make[3]: *** Waiting for unfinished jobs > rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gpl.pod gcc.pod > make[3]: Leaving directory `/build/gcc/2006-06-19-nc/gcc' > make[2]: *** [all-stage2-gcc] Error 2 > make[2]: Leaving directory `/build/gcc/2006-06-19-nc' > make[1]: *** [stage2-bubble] Error 2 > make[1]: Leaving directory `/build/gcc/2006-06-19-nc' > make: *** [all] Error 2 > > > > Has anyone else encountered this? I'm checking back to see when/if this > suddenly appeared. It also happens with a much earlier version of the > kernel. If I recall from my poking around earlier last week, bitmap.o > get miscompiled in stage1, but take that with a grain of salt.. a lot of > things were going on last week and I don't know if that is still true > today. > > Andrew >
[Bug c++/28088] Internal compiler error on boost mpl test/apply.cpp
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-19 23:37 ---
Reduced testcase, this might be already fixed in 4.1.2 but I have not tried:
template< typename T > struct type_wrapper{};
int arity_helper(...);
template< template< typename P1 > class F, typename T1>
int arity_helper(type_wrapper< F >);
template< typename F >
struct template_arity
{
static const int value = sizeof(arity_helper(type_wrapper() ));
};
template<
typename T, int t = template_arity::value
>
struct lambda;
typedef lambda< lambda > t;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known to fail||4.1.1
Known to work||4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28088
[Bug target/28084] [4.2 Regression] /usr/include/errno.h:28: error: previous declaration of 'int errno' with 'C++' linkage
--- Comment #3 from sje at cup dot hp dot com 2006-06-19 23:48 ---
There was nothing intentional about the different linkages, in unreleased HP-UX
sources, they fixed it to be in 'extern "C"' in both places. Here is a patch
to inclhack.def that I have tested. I haven't submitted it because I was
waiting for the MAINTAINERS change to happen.
fix = {
hackname = hpux11_extern_errno;
mach = "*-hp-hpux11.[0-2]*";
files = errno.h;
select= "^[ \t]*extern int errno;$";
c_fix = format;
c_fix_arg = "#ifdef __cplusplus\nextern \"C\" {\n#endif\n%0\n#ifdef
__cplusplus\n}\n#endif";
test_text = " extern int errno;\n";
};
--
sje at cup dot hp dot com changed:
What|Removed |Added
CC||sje at cup dot hp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28084
[Bug target/27082] segfault with virtual class and visibility ("hidden")
--- Comment #14 from roger at eyesopen dot com 2006-06-19 23:50 --- Unfortunately, I'm unable to reproduce this failure with a cross-compiler to alphaev68-unknown-linux-gnu. However, examination of the tracebacks attached to this PR and the relevant source code reveals there is a potential problem. It looks like alpha_expand_mov can call force_const_mem on RTL expressions that are CONSTANT_P but that potentially don't satify targetm.cannot_force_const_mem, such as CONST etc... This would lead to precisely the failures observed in the discussion. operands[1] gets overwritten by NULL_RTX, and we then call validize_mem on a NULL pointer! Kaboom! I think one aspect of the solution is the following patch: Index: alpha.c === *** alpha.c (revision 114721) --- alpha.c (working copy) *** alpha_expand_mov (enum machine_mode mode *** 2227,2232 --- 2227,2237 return true; } + /* Don't call force_const_mem on things that we can't force + into the constant pool. */ + if (alpha_cannot_force_const_mem (operands[1])) + return false; + /* Otherwise we've nothing left but to drop the thing to memory. */ operands[1] = force_const_mem (mode, operands[1]); if (reload_in_progress) However, it's not impossible that this will prevent the current failure only to pass the problematic operand on to somewhere else in the compiler. Could someone who can reproduce this failure, try the above patch and see if there's any downstream fallout? It would also be great to see what the problematic RTX looks like. I'm pretty sure its either a SYMBOL_REF, a LABEL_REF or a CONST. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27082
[Bug target/28084] [4.2 Regression] /usr/include/errno.h:28: error: previous declaration of 'int errno' with 'C++' linkage
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-20 00:07 --- Subject: Re: [4.2 Regression] /usr/include/errno.h:28: error: previous declaration of 'int errno' with 'C++' linkage > mach = "*-hp-hpux11.[0-2]*"; I believe that we also need the fix for hpux10. I see extern int errno; #include in the HP-UX 10.20 version of errno.h with no extern "C" wrapper. sys/errno.h has the wrapper. Otherwise, the change looks good to me. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28084
[Bug c/27149] English in warning not grammatical: "the address of x, will always evaluate"
--- Comment #2 from sayle at gcc dot gnu dot org 2006-06-20 00:22 --- Subject: Bug 27149 Author: sayle Date: Tue Jun 20 00:22:21 2006 New Revision: 114800 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114800 Log: PR c/27149 * c-common.c (c_common_truthvalue_conversion): Fix grammar in warning. Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27149
[Bug bootstrap/28082] internal compiler error: Segmentation fault
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-20 00:33 --- We have reports of this working. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28082
[Bug target/27861] [4.0/4.1 regression] ICE in expand_expr_real_1, at expr.c:6916
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-06-20 00:39 --- Fixed at least on the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work|3.4.6 |3.4.6 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-06-20 00:39:43 date|| Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE in |in expand_expr_real_1, at |expand_expr_real_1, at |expr.c:6916 |expr.c:6916 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27861
[Bug c/27184] [4.0/4.1/4.2 Regression] Wrong code with pointers to arrays and types and strict aliasing
--- Comment #6 from patchapp at dberlin dot org 2006-06-20 01:31 --- Subject: Bug number PR c/27184 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01507.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27184
[Bug fortran/28091] New: ICE compiling array variables with input size.
Compile this test case with -fno-automatic: MacOSX:~ ed$ /Users/ed/bin-4.1.1/bin/gfortran -fno-automatic ARRAY_BADNESS.FOR ARRAY_BADNESS.FOR: In function 'bad': ARRAY_BADNESS.FOR:8: internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3321 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. MacOSX:~ ed$ Here is the reduced testcase: = SUBROUTINE BAD ( NPRFL, HPRFL, XPRFL ) IMPLICIT NONE INTEGER NPRFL, I REAL HPRFL( NPRFL ), XPRFL( NPRFL ) DOUBLE PRECISION * DHPRFL( NPRFL ), DXPRFL( NPRFL ) C -- C CONVERT SINGLE PRECISION REAL C INPUT TO DOUBLE PRECISION C -- DO I = 1, NPRFL DXPRFL(I) = DBLE( XPRFL(I) ) DHPRFL(I) = DBLE( HPRFL(I) ) END DO RETURN END SUBROUTINE = -- Summary: ICE compiling array variables with input size. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: 3dw4rd at verizon dot net GCC build triplet: powerpc-apple-darwin7.9.0 GCC host triplet: powerpc-apple-darwin7.9.0 GCC target triplet: powerpc-apple-darwin7.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28091
[Bug middle-end/28075] [4.1/4.2 Regression] inliner introduces unnecessary type conversions
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-20 02:10 --- Subject: Bug 28075 Author: pinskia Date: Tue Jun 20 02:09:57 2006 New Revision: 114801 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114801 Log: 2006-06-19 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/28075 * tree-inline.c (setup_one_parameter): Strip useless type conversion before adding it to the IR. (declare_return_variable): Likewise. 2006-06-19 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/28075 * gcc.dg/tree-ssa/inline-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/inline-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28075
[Bug middle-end/28075] [4.1 Regression] inliner introduces unnecessary type conversions
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-06-20 02:11 --- Fixed on the mainline and will commit on the 4.1 after two weeks (unless I get some time during the summit to commit it, I will). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.1 Known to work||4.0.2 4.2.0 Summary|[4.1/4.2 Regression] inliner|[4.1 Regression] inliner |introduces unnecessary type |introduces unnecessary type |conversions |conversions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28075
[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-20 03:43 --- Subject: Re: [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops > could you please try to simplify the testcase, ideally to separate just the > single misscompiled loop? I again failed to find anything wrong using just a > crosscompiler. I've simplified the testcase. It appears that my_parityll fails for 0x0001ULL. However, the preceding value is needed to trigger the bug. Dave --- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-20 03:43 --- Created an attachment (id=11708) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11708&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
--- Comment #14 from danglin at gcc dot gnu dot org 2006-06-20 03:51 --- The original attachment still fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
[Bug fortran/23091] ICE in gfc_trans_auto_array_allocation
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23091
[Bug fortran/28091] ICE compiling array variables with input size.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-20 04:13 --- This was just fixed 8 days ago for both 4.1.2 and the mainline (4.2.0). *** This bug has been marked as a duplicate of 23091 *** -- 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=28091
[Bug fortran/23091] ICE in gfc_trans_auto_array_allocation
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-06-20 04:13 --- *** Bug 28091 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||3dw4rd at verizon dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23091
[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
--- Comment #15 from danglin at gcc dot gnu dot org 2006-06-20 04:14 --- The second attachment doesn't fail if -fno-inline-functions is added to the compile command, or if 0x0001ULL is changed to 0x00010001ULL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
[Bug c/27149] English in warning not grammatical: "the address of x, will always evaluate"
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-20 04:15 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27149
[Bug fortran/25050] CSHIFT not allowed in initialization expression
--- Comment #2 from pault at gcc dot gnu dot org 2006-06-20 04:31 --- Subject: Bug 25050 Author: pault Date: Tue Jun 20 04:30:48 2006 New Revision: 114802 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114802 Log: 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25049 PR fortran/25050 * check.c (non_init_transformational): New function. (find_substring_ref): New function to signal use of disallowed transformational intrinsic in an initialization expression. (gfc_check_all_any): Call previous if initialization expr. (gfc_check_count): The same. (gfc_check_cshift): The same. (gfc_check_dot_product): The same. (gfc_check_eoshift): The same. (gfc_check_minloc_maxloc): The same. (gfc_check_minval_maxval): The same. (gfc_check_gfc_check_product_sum): The same. (gfc_check_pack): The same. (gfc_check_spread): The same. (gfc_check_transpose): The same. (gfc_check_unpack): The same. PR fortran/18769 *intrinsic.c (add_functions): Add gfc_simplify_transfer. *intrinsic.h : Add prototype for gfc_simplify_transfer. *simplify.c (gfc_simplify_transfer) : New function to act as placeholder for eventual implementation. Emit error for now. PR fortran/16206 * expr.c (find_array_element): Eliminate condition on length of offset. Add bounds checking. Rearrange exit. Return try and put gfc_constructor result as an argument. (find_array_section): New function. (find_substring_ref): New function. (simplify_const_ref): Add calls to previous. (simplify_parameter_variable): Return on NULL expr. (gfc_simplify_expr): Only call gfc_expand_constructor for full arrays. PR fortran/20876 * match.c (gfc_match_forall): Add missing locus to gfc_code. 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28005 * m4/matmul.m4: aystride = 1 does not uniquely detect the presence of a temporary transpose; an array element in the first dimension produces the same signature. Detect this using the rank of a and add specific code. * generated/matmul_r4.c: Regenerate. * generated/matmul_r8.c: Regenerate. * generated/matmul_r10.c: Regenerate. * generated/matmul_r16.c: Regenerate. * generated/matmul_c4.c: Regenerate. * generated/matmul_c8.c: Regenerate. * generated/matmul_c10.c: Regenerate. * generated/matmul_c16.c: Regenerate. * generated/matmul_i4.c: Regenerate. * generated/matmul_i8.c: Regenerate. * generated/matmul_i16.c: Regenerate. 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR fortran/16206 * gfortran.dg/array_initializer_1.f90: New test. PR fortran/28005 * gfortran.dg/matmul_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_initializer_1.f90 trunk/gcc/testsuite/gfortran.dg/matmul_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/match.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/matmul_c10.c trunk/libgfortran/generated/matmul_c16.c trunk/libgfortran/generated/matmul_c4.c trunk/libgfortran/generated/matmul_c8.c trunk/libgfortran/generated/matmul_i16.c trunk/libgfortran/generated/matmul_i4.c trunk/libgfortran/generated/matmul_i8.c trunk/libgfortran/generated/matmul_r10.c trunk/libgfortran/generated/matmul_r16.c trunk/libgfortran/generated/matmul_r4.c trunk/libgfortran/generated/matmul_r8.c trunk/libgfortran/m4/matmul.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25050
[Bug fortran/20876] Subroutine call in FORALL block not PURE
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-20 04:31 --- Subject: Bug 20876 Author: pault Date: Tue Jun 20 04:30:48 2006 New Revision: 114802 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114802 Log: 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25049 PR fortran/25050 * check.c (non_init_transformational): New function. (find_substring_ref): New function to signal use of disallowed transformational intrinsic in an initialization expression. (gfc_check_all_any): Call previous if initialization expr. (gfc_check_count): The same. (gfc_check_cshift): The same. (gfc_check_dot_product): The same. (gfc_check_eoshift): The same. (gfc_check_minloc_maxloc): The same. (gfc_check_minval_maxval): The same. (gfc_check_gfc_check_product_sum): The same. (gfc_check_pack): The same. (gfc_check_spread): The same. (gfc_check_transpose): The same. (gfc_check_unpack): The same. PR fortran/18769 *intrinsic.c (add_functions): Add gfc_simplify_transfer. *intrinsic.h : Add prototype for gfc_simplify_transfer. *simplify.c (gfc_simplify_transfer) : New function to act as placeholder for eventual implementation. Emit error for now. PR fortran/16206 * expr.c (find_array_element): Eliminate condition on length of offset. Add bounds checking. Rearrange exit. Return try and put gfc_constructor result as an argument. (find_array_section): New function. (find_substring_ref): New function. (simplify_const_ref): Add calls to previous. (simplify_parameter_variable): Return on NULL expr. (gfc_simplify_expr): Only call gfc_expand_constructor for full arrays. PR fortran/20876 * match.c (gfc_match_forall): Add missing locus to gfc_code. 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28005 * m4/matmul.m4: aystride = 1 does not uniquely detect the presence of a temporary transpose; an array element in the first dimension produces the same signature. Detect this using the rank of a and add specific code. * generated/matmul_r4.c: Regenerate. * generated/matmul_r8.c: Regenerate. * generated/matmul_r10.c: Regenerate. * generated/matmul_r16.c: Regenerate. * generated/matmul_c4.c: Regenerate. * generated/matmul_c8.c: Regenerate. * generated/matmul_c10.c: Regenerate. * generated/matmul_c16.c: Regenerate. * generated/matmul_i4.c: Regenerate. * generated/matmul_i8.c: Regenerate. * generated/matmul_i16.c: Regenerate. 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR fortran/16206 * gfortran.dg/array_initializer_1.f90: New test. PR fortran/28005 * gfortran.dg/matmul_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_initializer_1.f90 trunk/gcc/testsuite/gfortran.dg/matmul_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/match.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/matmul_c10.c trunk/libgfortran/generated/matmul_c16.c trunk/libgfortran/generated/matmul_c4.c trunk/libgfortran/generated/matmul_c8.c trunk/libgfortran/generated/matmul_i16.c trunk/libgfortran/generated/matmul_i4.c trunk/libgfortran/generated/matmul_i8.c trunk/libgfortran/generated/matmul_r10.c trunk/libgfortran/generated/matmul_r16.c trunk/libgfortran/generated/matmul_r4.c trunk/libgfortran/generated/matmul_r8.c trunk/libgfortran/m4/matmul.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20876
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #10 from pault at gcc dot gnu dot org 2006-06-20 04:31 --- Subject: Bug 16206 Author: pault Date: Tue Jun 20 04:30:48 2006 New Revision: 114802 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114802 Log: 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25049 PR fortran/25050 * check.c (non_init_transformational): New function. (find_substring_ref): New function to signal use of disallowed transformational intrinsic in an initialization expression. (gfc_check_all_any): Call previous if initialization expr. (gfc_check_count): The same. (gfc_check_cshift): The same. (gfc_check_dot_product): The same. (gfc_check_eoshift): The same. (gfc_check_minloc_maxloc): The same. (gfc_check_minval_maxval): The same. (gfc_check_gfc_check_product_sum): The same. (gfc_check_pack): The same. (gfc_check_spread): The same. (gfc_check_transpose): The same. (gfc_check_unpack): The same. PR fortran/18769 *intrinsic.c (add_functions): Add gfc_simplify_transfer. *intrinsic.h : Add prototype for gfc_simplify_transfer. *simplify.c (gfc_simplify_transfer) : New function to act as placeholder for eventual implementation. Emit error for now. PR fortran/16206 * expr.c (find_array_element): Eliminate condition on length of offset. Add bounds checking. Rearrange exit. Return try and put gfc_constructor result as an argument. (find_array_section): New function. (find_substring_ref): New function. (simplify_const_ref): Add calls to previous. (simplify_parameter_variable): Return on NULL expr. (gfc_simplify_expr): Only call gfc_expand_constructor for full arrays. PR fortran/20876 * match.c (gfc_match_forall): Add missing locus to gfc_code. 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28005 * m4/matmul.m4: aystride = 1 does not uniquely detect the presence of a temporary transpose; an array element in the first dimension produces the same signature. Detect this using the rank of a and add specific code. * generated/matmul_r4.c: Regenerate. * generated/matmul_r8.c: Regenerate. * generated/matmul_r10.c: Regenerate. * generated/matmul_r16.c: Regenerate. * generated/matmul_c4.c: Regenerate. * generated/matmul_c8.c: Regenerate. * generated/matmul_c10.c: Regenerate. * generated/matmul_c16.c: Regenerate. * generated/matmul_i4.c: Regenerate. * generated/matmul_i8.c: Regenerate. * generated/matmul_i16.c: Regenerate. 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR fortran/16206 * gfortran.dg/array_initializer_1.f90: New test. PR fortran/28005 * gfortran.dg/matmul_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_initializer_1.f90 trunk/gcc/testsuite/gfortran.dg/matmul_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/match.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/matmul_c10.c trunk/libgfortran/generated/matmul_c16.c trunk/libgfortran/generated/matmul_c4.c trunk/libgfortran/generated/matmul_c8.c trunk/libgfortran/generated/matmul_i16.c trunk/libgfortran/generated/matmul_i4.c trunk/libgfortran/generated/matmul_i8.c trunk/libgfortran/generated/matmul_r10.c trunk/libgfortran/generated/matmul_r16.c trunk/libgfortran/generated/matmul_r4.c trunk/libgfortran/generated/matmul_r8.c trunk/libgfortran/m4/matmul.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug fortran/25049] TRANSPOSE not allowed in initialisation expression
--- Comment #2 from pault at gcc dot gnu dot org 2006-06-20 04:31 --- Subject: Bug 25049 Author: pault Date: Tue Jun 20 04:30:48 2006 New Revision: 114802 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114802 Log: 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25049 PR fortran/25050 * check.c (non_init_transformational): New function. (find_substring_ref): New function to signal use of disallowed transformational intrinsic in an initialization expression. (gfc_check_all_any): Call previous if initialization expr. (gfc_check_count): The same. (gfc_check_cshift): The same. (gfc_check_dot_product): The same. (gfc_check_eoshift): The same. (gfc_check_minloc_maxloc): The same. (gfc_check_minval_maxval): The same. (gfc_check_gfc_check_product_sum): The same. (gfc_check_pack): The same. (gfc_check_spread): The same. (gfc_check_transpose): The same. (gfc_check_unpack): The same. PR fortran/18769 *intrinsic.c (add_functions): Add gfc_simplify_transfer. *intrinsic.h : Add prototype for gfc_simplify_transfer. *simplify.c (gfc_simplify_transfer) : New function to act as placeholder for eventual implementation. Emit error for now. PR fortran/16206 * expr.c (find_array_element): Eliminate condition on length of offset. Add bounds checking. Rearrange exit. Return try and put gfc_constructor result as an argument. (find_array_section): New function. (find_substring_ref): New function. (simplify_const_ref): Add calls to previous. (simplify_parameter_variable): Return on NULL expr. (gfc_simplify_expr): Only call gfc_expand_constructor for full arrays. PR fortran/20876 * match.c (gfc_match_forall): Add missing locus to gfc_code. 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28005 * m4/matmul.m4: aystride = 1 does not uniquely detect the presence of a temporary transpose; an array element in the first dimension produces the same signature. Detect this using the rank of a and add specific code. * generated/matmul_r4.c: Regenerate. * generated/matmul_r8.c: Regenerate. * generated/matmul_r10.c: Regenerate. * generated/matmul_r16.c: Regenerate. * generated/matmul_c4.c: Regenerate. * generated/matmul_c8.c: Regenerate. * generated/matmul_c10.c: Regenerate. * generated/matmul_c16.c: Regenerate. * generated/matmul_i4.c: Regenerate. * generated/matmul_i8.c: Regenerate. * generated/matmul_i16.c: Regenerate. 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR fortran/16206 * gfortran.dg/array_initializer_1.f90: New test. PR fortran/28005 * gfortran.dg/matmul_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_initializer_1.f90 trunk/gcc/testsuite/gfortran.dg/matmul_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/match.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/matmul_c10.c trunk/libgfortran/generated/matmul_c16.c trunk/libgfortran/generated/matmul_c4.c trunk/libgfortran/generated/matmul_c8.c trunk/libgfortran/generated/matmul_i16.c trunk/libgfortran/generated/matmul_i4.c trunk/libgfortran/generated/matmul_i8.c trunk/libgfortran/generated/matmul_r10.c trunk/libgfortran/generated/matmul_r16.c trunk/libgfortran/generated/matmul_r4.c trunk/libgfortran/generated/matmul_r8.c trunk/libgfortran/m4/matmul.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25049
[Bug fortran/28005] gfortran: mathmul produces wrong result
--- Comment #5 from pault at gcc dot gnu dot org 2006-06-20 04:31 --- Subject: Bug 28005 Author: pault Date: Tue Jun 20 04:30:48 2006 New Revision: 114802 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114802 Log: 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25049 PR fortran/25050 * check.c (non_init_transformational): New function. (find_substring_ref): New function to signal use of disallowed transformational intrinsic in an initialization expression. (gfc_check_all_any): Call previous if initialization expr. (gfc_check_count): The same. (gfc_check_cshift): The same. (gfc_check_dot_product): The same. (gfc_check_eoshift): The same. (gfc_check_minloc_maxloc): The same. (gfc_check_minval_maxval): The same. (gfc_check_gfc_check_product_sum): The same. (gfc_check_pack): The same. (gfc_check_spread): The same. (gfc_check_transpose): The same. (gfc_check_unpack): The same. PR fortran/18769 *intrinsic.c (add_functions): Add gfc_simplify_transfer. *intrinsic.h : Add prototype for gfc_simplify_transfer. *simplify.c (gfc_simplify_transfer) : New function to act as placeholder for eventual implementation. Emit error for now. PR fortran/16206 * expr.c (find_array_element): Eliminate condition on length of offset. Add bounds checking. Rearrange exit. Return try and put gfc_constructor result as an argument. (find_array_section): New function. (find_substring_ref): New function. (simplify_const_ref): Add calls to previous. (simplify_parameter_variable): Return on NULL expr. (gfc_simplify_expr): Only call gfc_expand_constructor for full arrays. PR fortran/20876 * match.c (gfc_match_forall): Add missing locus to gfc_code. 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28005 * m4/matmul.m4: aystride = 1 does not uniquely detect the presence of a temporary transpose; an array element in the first dimension produces the same signature. Detect this using the rank of a and add specific code. * generated/matmul_r4.c: Regenerate. * generated/matmul_r8.c: Regenerate. * generated/matmul_r10.c: Regenerate. * generated/matmul_r16.c: Regenerate. * generated/matmul_c4.c: Regenerate. * generated/matmul_c8.c: Regenerate. * generated/matmul_c10.c: Regenerate. * generated/matmul_c16.c: Regenerate. * generated/matmul_i4.c: Regenerate. * generated/matmul_i8.c: Regenerate. * generated/matmul_i16.c: Regenerate. 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR fortran/16206 * gfortran.dg/array_initializer_1.f90: New test. PR fortran/28005 * gfortran.dg/matmul_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_initializer_1.f90 trunk/gcc/testsuite/gfortran.dg/matmul_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/match.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/matmul_c10.c trunk/libgfortran/generated/matmul_c16.c trunk/libgfortran/generated/matmul_c4.c trunk/libgfortran/generated/matmul_c8.c trunk/libgfortran/generated/matmul_i16.c trunk/libgfortran/generated/matmul_i4.c trunk/libgfortran/generated/matmul_i8.c trunk/libgfortran/generated/matmul_r10.c trunk/libgfortran/generated/matmul_r16.c trunk/libgfortran/generated/matmul_r4.c trunk/libgfortran/generated/matmul_r8.c trunk/libgfortran/m4/matmul.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28005
[Bug fortran/18769] ICE in gfc_conv_array_initializer with array initialization with transfer
--- Comment #8 from pault at gcc dot gnu dot org 2006-06-20 04:31 --- Subject: Bug 18769 Author: pault Date: Tue Jun 20 04:30:48 2006 New Revision: 114802 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114802 Log: 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25049 PR fortran/25050 * check.c (non_init_transformational): New function. (find_substring_ref): New function to signal use of disallowed transformational intrinsic in an initialization expression. (gfc_check_all_any): Call previous if initialization expr. (gfc_check_count): The same. (gfc_check_cshift): The same. (gfc_check_dot_product): The same. (gfc_check_eoshift): The same. (gfc_check_minloc_maxloc): The same. (gfc_check_minval_maxval): The same. (gfc_check_gfc_check_product_sum): The same. (gfc_check_pack): The same. (gfc_check_spread): The same. (gfc_check_transpose): The same. (gfc_check_unpack): The same. PR fortran/18769 *intrinsic.c (add_functions): Add gfc_simplify_transfer. *intrinsic.h : Add prototype for gfc_simplify_transfer. *simplify.c (gfc_simplify_transfer) : New function to act as placeholder for eventual implementation. Emit error for now. PR fortran/16206 * expr.c (find_array_element): Eliminate condition on length of offset. Add bounds checking. Rearrange exit. Return try and put gfc_constructor result as an argument. (find_array_section): New function. (find_substring_ref): New function. (simplify_const_ref): Add calls to previous. (simplify_parameter_variable): Return on NULL expr. (gfc_simplify_expr): Only call gfc_expand_constructor for full arrays. PR fortran/20876 * match.c (gfc_match_forall): Add missing locus to gfc_code. 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28005 * m4/matmul.m4: aystride = 1 does not uniquely detect the presence of a temporary transpose; an array element in the first dimension produces the same signature. Detect this using the rank of a and add specific code. * generated/matmul_r4.c: Regenerate. * generated/matmul_r8.c: Regenerate. * generated/matmul_r10.c: Regenerate. * generated/matmul_r16.c: Regenerate. * generated/matmul_c4.c: Regenerate. * generated/matmul_c8.c: Regenerate. * generated/matmul_c10.c: Regenerate. * generated/matmul_c16.c: Regenerate. * generated/matmul_i4.c: Regenerate. * generated/matmul_i8.c: Regenerate. * generated/matmul_i16.c: Regenerate. 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR fortran/16206 * gfortran.dg/array_initializer_1.f90: New test. PR fortran/28005 * gfortran.dg/matmul_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_initializer_1.f90 trunk/gcc/testsuite/gfortran.dg/matmul_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/match.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/matmul_c10.c trunk/libgfortran/generated/matmul_c16.c trunk/libgfortran/generated/matmul_c4.c trunk/libgfortran/generated/matmul_c8.c trunk/libgfortran/generated/matmul_i16.c trunk/libgfortran/generated/matmul_i4.c trunk/libgfortran/generated/matmul_i8.c trunk/libgfortran/generated/matmul_r10.c trunk/libgfortran/generated/matmul_r16.c trunk/libgfortran/generated/matmul_r4.c trunk/libgfortran/generated/matmul_r8.c trunk/libgfortran/m4/matmul.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18769
[Bug c/28092] New: ICE while building glibc
The problem occurs with 4.0.3. I haven't tested newer compilers, but 3.4.6 and 3.3.6 work. Problem can be avoided by reducing -O2 to -O0. $ m68k-linux-gcc -O2 -c iso-2022-cn-ext.i In file included from iso-2022-cn-ext.c:654: ../iconv/loop.c: In function 'to_iso2022cn_ext_loop': ../iconv/loop.c:311: warning: pointer targets in passing argument 2 of 'ucs4_to_gb2312' differ in signedness ../iconv/loop.c:311: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l1' differ in signedness ../iconv/loop.c:311: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l2' differ in signedness ../iconv/loop.c:311: warning: pointer targets in passing argument 2 of 'ucs4_to_gb2312' differ in signedness ../iconv/loop.c:311: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l1' differ in signedness ../iconv/loop.c: In function 'to_iso2022cn_ext_loop_single': ../iconv/loop.c:414: warning: pointer targets in passing argument 2 of 'ucs4_to_gb2312' differ in signedness ../iconv/loop.c:414: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l1' differ in signedness ../iconv/loop.c:414: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l2' differ in signedness ../iconv/loop.c:414: warning: pointer targets in passing argument 2 of 'ucs4_to_gb2312' differ in signedness ../iconv/loop.c:414: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l1' differ in signedness ../iconv/skeleton.c: In function 'gconv': ../iconv/skeleton.c:801: internal compiler error: output_operand: invalid expression as operand Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. $ m68k-linux-gcc -O1 -c iso-2022-cn-ext.i In file included from iso-2022-cn-ext.c:654: ../iconv/loop.c: In function 'to_iso2022cn_ext_loop': ../iconv/loop.c:311: warning: pointer targets in passing argument 2 of 'ucs4_to_gb2312' differ in signedness ../iconv/loop.c:311: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l1' differ in signedness ../iconv/loop.c:311: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l2' differ in signedness ../iconv/loop.c:311: warning: pointer targets in passing argument 2 of 'ucs4_to_gb2312' differ in signedness ../iconv/loop.c:311: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l1' differ in signedness ../iconv/loop.c: In function 'to_iso2022cn_ext_loop_single': ../iconv/loop.c:414: warning: pointer targets in passing argument 2 of 'ucs4_to_gb2312' differ in signedness ../iconv/loop.c:414: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l1' differ in signedness ../iconv/loop.c:414: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l2' differ in signedness ../iconv/loop.c:414: warning: pointer targets in passing argument 2 of 'ucs4_to_gb2312' differ in signedness ../iconv/loop.c:414: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l1' differ in signedness In file included from iso-2022-cn-ext.c:658: ../iconv/skeleton.c: In function 'gconv': ../iconv/skeleton.c:801: internal compiler error: output_operand: invalid expression as operand Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. $ m68k-linux-gcc -O0 -c iso-2022-cn-ext.i In file included from iso-2022-cn-ext.c:654: ../iconv/loop.c: In function 'to_iso2022cn_ext_loop': ../iconv/loop.c:311: warning: pointer targets in passing argument 2 of 'ucs4_to_gb2312' differ in signedness ../iconv/loop.c:311: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l1' differ in signedness ../iconv/loop.c:311: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l2' differ in signedness ../iconv/loop.c:311: warning: pointer targets in passing argument 2 of 'ucs4_to_gb2312' differ in signedness ../iconv/loop.c:311: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l1' differ in signedness ../iconv/loop.c: In function 'to_iso2022cn_ext_loop_single': ../iconv/loop.c:414: warning: pointer targets in passing argument 2 of 'ucs4_to_gb2312' differ in signedness ../iconv/loop.c:414: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l1' differ in signedness ../iconv/loop.c:414: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l2' differ in signedness ../iconv/loop.c:414: warning: pointer targets in passing argument 2 of 'ucs4_to_gb2312' differ in signedness ../iconv/loop.c:414: warning: pointer targets in passing argument 2 of 'ucs4_to_cns11643l1' differ in signedness $ m68k-linux-gcc -v Using built-in specs. Target: m68k-linux Configured with: ../gcc-core-4.0.3/configure --prefix=/Volumes/btc-0.11/gcc-4.0.3-binutils-2.17.50.0.2-glibc-2.3.6 --target=m68k-linux --with-sysroot=/Volumes/btc-0.11/gcc-4.0.3-binutils-2.17.50.0.2-glibc-2.3.6/m68k-linux/sysroot --enable-altivec --with-newlib --disable-m
[Bug c/28092] ICE while building glibc
--- Comment #1 from ft01 at webmastery dot com dot au 2006-06-20 05:12 --- Created an attachment (id=11709) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11709&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28092
[Bug target/28092] ICE while building glibc
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28092
