[Bug bootstrap/29825] New: ICE in
the fix for PR middle-end/28915 causes a bootstrap failure with 4.1 20061113 on i486 (using the Debian build); didn't yet check with a vanilla 4.1 branch or the fedora 4.1 branch. Matthias ./xgcc -B./ -B/usr/i486-linux-gnu/bin/ -isystem /usr/i486-linux-gnu/include -isystem /usr/i486-linux-gnu/sys-include -L/home/packages/gcc/4.1/gcc-4.1-4.1.1ds2/build/gcc/../ld -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 -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -fexceptions -fvisibility=hidden -DHIDE_EXPORTS -c ../../src/gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o ../../src/gcc/unwind-dw2.c: In function 'uw_install_context_1': ../../src/gcc/unwind-dw2.c:1357: error: unrecognizable insn: (insn:HI 157 44 158 4 (set (reg:SI 98) (unspec:SI [ (symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl 0x4042e6c0 dwarf_reg_size_table) ] 1)) -1 (nil) (nil)) ../../src/gcc/unwind-dw2.c:1357: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE in Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug bootstrap/29825] ICE in extract_insn, at recog.c:2084 (unrecognizable insn)
--- Comment #1 from debian-gcc at lists dot debian dot org 2006-11-14 08:18 --- reverting the fix for PR28915 fixes the bootstrap error 2006-11-12 Jason Merrill [EMAIL PROTECTED] Andrew Pinski [EMAIL PROTECTED] PR middle-end/28915 * gimplify.c (gimplify_init_constructor): Don't reduce TREE_CONSTANT vector ctors. * tree-cfg.c (verify_expr): Don't look into TREE_CONSTANT vector ctors. * expmed.c (make_tree): Handle CONST, SYMBOL_REF. * tree.c (build_vector): Handle non-_CST elements. -- debian-gcc at lists dot debian dot org changed: What|Removed |Added Summary|ICE in |ICE in extract_insn, at ||recog.c:2084 (unrecognizable ||insn) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug bootstrap/29825] ICE in extract_insn, at recog.c:2084 (unrecognizable insn)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-14 08:21 --- (In reply to comment #1) reverting the fix for PR28915 fixes the bootstrap error This patch should not have any affect on bootstrap as there are no vectors usage inside GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug ada/29802] wrong directory in makefile for ada and libada when building the src directory
--- Comment #2 from bonzini at gnu dot org 2006-11-14 08:26 --- it is supported, it is just buggy. Jean-Pierre, it seems like you have something like a patch. Can you expand your idea more? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29802
[Bug bootstrap/29825] ICE in extract_insn, at recog.c:2084 (unrecognizable insn)
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-14 08:26 --- building a plain 4.1 branch to prove it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug fortran/29711] error_print does not support %N$X
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-11-14 16:44 --- Created an attachment (id=12618) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12618action=view) Patch mentionned in previous comment -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29711
[Bug bootstrap/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-11-14 09:03 --- Yep, and the aforementioned patch is indeed the culprit. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Severity|normal |blocker Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-14 09:03:07 date|| Summary|ICE in extract_insn, at |[4.1 regression] ICE in |recog.c:2084 (unrecognizable|extract_insn, at |insn) |recog.c:2084 Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug fortran/29814] integer assignment in hexadecimal fails
--- Comment #3 from vahtras at kth dot se 2006-11-14 09:42 --- Subject: Re: integer assignment in hexadecimal fails On 14 nov 2006, at 02.23, jvdelisle at gcc dot gnu dot org wrote: Try -fno-range-check or use standard conforming methods. Thank you, this was a learning experience indeed. /Olav -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29814
[Bug rtl-optimization/29798] [4.3 Regression] -O2 gives wrong results
--- Comment #13 from bonzini at gnu dot org 2006-11-14 08:46 --- Subject: Bug 29798 Author: bonzini Date: Tue Nov 14 08:46:26 2006 New Revision: 118808 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118808 Log: 2006-11-14 Paolo Bonzini [EMAIL PROTECTED] PR rtl-optimization/29798 * fwprop.c (use_killed_between): Check that DEF_INSN dominates TARGET_INSN before any other check. (fwprop_init): Always calculate dominators. (fwprop_done): Always free them. 2006-11-14 Paolo Bonzini [EMAIL PROTECTED] PR rtl-optimization/29798 * gcc.c-torture/execute/pr29798.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr29798.c Modified: trunk/gcc/ChangeLog trunk/gcc/fwprop.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29798
[Bug rtl-optimization/29798] [4.3 Regression] -O2 gives wrong results
--- Comment #14 from bonzini at gnu dot org 2006-11-14 08:50 --- still have to commit the patch on dataflow branch, but mainline is ok now -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29798
[Bug c/29826] New: __attribute__ dllimport makes optimization crash on cygwin
the exact version of GCC is 4.1.1 the system type is i686-pc-cygwin the options given when GCC was configured/built: --prefix=/tmp/local/unixutil/gcc-4.1.1 --with-local-prefix=/usr/local/myCompanyName (myCompanyName is not the exact wording) (also, there is a symlink /tmp/local/unixutil/gcc - gcc-4.1.1) the complete command line that triggers the bug: /tmp/local/unixutil/gcc/bin/gcc -O -Wall -Wextra -c zim.c the compiler output (error messages, warnings, etc.): stdout: nothing stderr: zim.c: In function '': zim.c:16: error: unrecognizable insn: (insn 20 19 21 2 (set (reg:SI 66) (const:SI (plus:SI (mem:SI (symbol_ref:SI (#i.) var_decl 0x194500b0 ) [0 S4 A8]) (const_int 4 [0x4] -1 (nil) (nil)) zim.c:16: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. zim.o: not created the preprocessed file: see below additional remarks: 1) if -O is removed, all seems OK 2) if __attribute__((dllimport)) is removed, all seems OK 3) if -Wall or -Wextra is removed, no change (still crash) ---zim.i- # 1 zim.c # 1 built-in # 1 command line # 1 zim.c struct { const char *1; const char *2; }; extern __attribute__((dllimport)) struct []; int (); int () { int i; for (i = 0; i 2; i++) { ([i].2); }; return(0); }; - -- Summary: __attribute__ dllimport makes optimization crash on cygwin Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Denis dot Excoffier at airbus dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
[Bug bootstrap/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-14 09:46 --- So the problem is that loop.c creates a tree for: (plus:SI (reg:SI 3 bx) (const:SI (unspec:SI [ (symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl 0xb7ce10b0 dwarf_reg_size_table) ] 1))) From: 5106expand_mult_add (rtx x, rtx target, rtx mult, rtx add, enum machine_mode mode, 5107 int unsignedp) (gdb) p debug_rtx(x) (const_int 1 [0x1]) $6 = void (gdb) p debug_rtx(mult) (const_int 1 [0x1]) $7 = void (gdb) p debug_rtx(add) (plus:SI (reg:SI 3 bx) (const:SI (unspec:SI [ (symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl 0xb7ce10b0 dwarf_reg_size_table) ] 1))) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug bootstrap/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-14 09:06 --- Looking into it, a bit more. But as far as I can tell this is a latent bug in the x86 back-end. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build, ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug rtl-optimization/29798] [4.3 Regression] -O2 gives wrong results
--- Comment #15 from bonzini at gnu dot org 2006-11-14 09:06 --- Subject: Bug 29798 Author: bonzini Date: Tue Nov 14 09:06:42 2006 New Revision: 118809 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118809 Log: 2006-11-14 Paolo Bonzini [EMAIL PROTECTED] Merge from mainline: 2006-11-14 Paolo Bonzini [EMAIL PROTECTED] PR rtl-optimization/29798 * fwprop.c (use_killed_between): Check that DEF_INSN dominates TARGET_INSN before any other check. Modified: branches/dataflow-branch/gcc/ChangeLog.dataflow branches/dataflow-branch/gcc/fwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29798
[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-11-14 09:57 --- (In reply to comment #8) Hmm, isn't movl %eax, [EMAIL PROTECTED] a valid way to have an offset? gas accepts that as valid so I think GCC should accept this. I am now going to bed but I am also going to say this is a latent bug in the x86 back-end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug fortran/29820] ICE in fold_convert, at fold-const.c:2146
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-14 09:50 --- I'm confused that for type geodetic real :: h end type geodetic gfortran is using a record type but still goes the scalar assignment path. With gfc_trans_scalar_assign changed to read gcc_assert (!AGGREGATE_TYPE_P (TREE_TYPE (lse-expr)) || TREE_TYPE (lse-expr) == TREE_TYPE (rse-expr)); gfc_add_modify_expr (block, lse-expr, !AGGREGATE_TYPE_P (TREE_TYPE (lse-expr)) ? fold_convert (TREE_TYPE (lse-expr), rse-expr) : rse-expr); we can see that we don't have the required type-unification for geodetic: (gdb) call debug_tree (lse-expr) indirect_ref 0x2b0877c769c0 type record_type 0x2b0877d4ea50 geodetic SF size integer_cst 0x2b0877c6cba0 constant invariant 32 unit size integer_cst 0x2b0877c6c6c0 constant invariant 4 align 32 symtab 0 alias set -1 fields field_decl 0x2b0877d4ce40 h type real_type 0x2b0877c87210 real4 SF file t.f90 line 9 size integer_cst 0x2b0877c6cba0 32 unit size integer_cst 0x2b0877c6c6c0 4 align 32 offset_align 128 offset integer_cst 0x2b0877c6c6f0 constant invariant 0 bit offset integer_cst 0x2b0877c842d0 constant invariant 0 context record_type 0x2b0877d4ea50 geodetic reference_to_this reference_type 0x2b0877d4eb00 chain type_decl 0x2b0877c91680 D.1330 (gdb) call debug_tree (rse-expr) array_ref 0x2b0877d55180 type record_type 0x2b0877d4ec60 geodetic SF size integer_cst 0x2b0877c6cba0 constant invariant 32 unit size integer_cst 0x2b0877c6c6c0 constant invariant 4 align 32 symtab 0 alias set -1 fields field_decl 0x2b0877d4cf00 h type real_type 0x2b0877c87210 real4 SF file t.f90 line 9 size integer_cst 0x2b0877c6cba0 32 unit size integer_cst 0x2b0877c6c6c0 4 align 32 offset_align 128 offset integer_cst 0x2b0877c6c6f0 constant invariant 0 bit offset integer_cst 0x2b0877c842d0 constant invariant 0 context record_type 0x2b0877d4ec60 geodetic pointer_to_this pointer_type 0x2b0877d4edc0 chain type_decl 0x2b0877c91750 D.1335 (while this should be the same type, one is record_type 0x2b0877d4ec60 and the other is record_type 0x2b0877d4ea50, which is causing this bug) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29820
Re: [Bug middle-end/28915] [4.1 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
On Tue, 2006-11-14 at 09:29 +, jakub at gcc dot gnu dot org wrote: --- Comment #24 from jakub at gcc dot gnu dot org 2006-11-14 09:29 --- This change breaks bootstrap on x86_64-linux and i386-linux: This is now PR 29825 and it is an x86 back-end issue about not accepting the instruction which is valid as far as I can tell as the following asm instruction is valid: movl %eax, [EMAIL PROTECTED] -- Pinski
[Bug target/29815] internal compiler error, if float-comparison is done with option -mfloat-gprs=yes
--- Comment #3 from poellmann at nm dot hsd dot utc dot com 2006-11-14 10:10 --- The problem maintains with gcc 4.1.1. The error-message is slightly different: test.c: In function 'compare': test.c:5: error: unrecognizable insn: (insn 12 11 13 1 (set (reg:CCFP 123) (compare:CCFP (reg:SF 121) (reg:SF 122))) -1 (nil) (nil)) test.c:5: internal compiler error: in extract_insn, at recog.c:2084 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29815
[Bug bootstrap/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-14 09:40 --- This is a bug in loop.c ... which is why it works in 4.2.0 and above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug middle-end/28915] [4.1 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #24 from jakub at gcc dot gnu dot org 2006-11-14 09:29 --- This change breaks bootstrap on x86_64-linux and i386-linux: /usr/src/gcc-4.1/obj/./gcc/xgcc -B/usr/src/gcc-4.1/obj/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-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 -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -m32 -fexceptions -fvisibility=hidden -DHIDE_EXPORTS -c ../../gcc/unwind-dw2.c -o libgcc/32/unwind-dw2.o ../../gcc/unwind-dw2.c: In function 'uw_install_context_1': ../../gcc/unwind-dw2.c:1334: error: unrecognizable insn: (insn:HI 159 44 160 4 (set (reg:SI 102) (unspec:SI [ (symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl 0x2b051210 dwarf_reg_size_table) ] 1)) -1 (nil) (nil)) ../../gcc/unwind-dw2.c:1334: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. The problematic part is the make_tree addition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #12 from jakub at gcc dot gnu dot org 2006-11-14 11:43 --- While that can help in this case, I think letting make_tree/expand_expr combo create invalid RTL is very dangerous (and, at least from i386 backend POV, some of the PIC UNSPECs not surrounded by CONST are invalid, the backend guarantees that wherever it creates them it adds the CONST around). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug fortran/29711] error_print does not support %N$X
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-11-14 10:39 --- I'll take that one. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-11-04 13:28:03 |2006-11-14 10:39:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29711
[Bug c/29827] New: Assigning function with a char param emits a spurious warning
Assigning a function pointer with a char parameter to a pointer with an undefined list causes gcc to emit a warning. [EMAIL PROTECTED]:~/ntnative/loader$ cat x.c void foo(char); void (*f1)() = foo; void bar(int); void (*f2)() = bar; [EMAIL PROTECTED]:~/ntnative/loader$ gcc -c x.c x.c:2: warning: initialization from incompatible pointer type [EMAIL PROTECTED]:~/ntnative/loader$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19) -- Summary: Assigning function with a char param emits a spurious warning Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mike at codeweavers dot com GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29827
[Bug fortran/22282] %loc is not implemented in gfortran
--- Comment #8 from pault at gcc dot gnu dot org 2006-11-14 10:19 --- FX, In spite of this morning's posting to the list, I will not be submitting a patch for %LOC but rather for %REF. I got stuck in vms space. Is there any functional difference between %LOC and %REF, do you know? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22282
[Bug fortran/29828] New: Fortran 2003: MIN and MAX with character variables
See: 13.7.76 MIN (A1, A2 [, A3, ...]) For arguments of character type, the result is the value that would be selected by application of intrinsic relational operators; that is, the collating sequence for characters with the kind type parameter of the arguments is applied. If the selected argument is shorter than the longest argument, the 20 result is extended with blanks on the right to the length of the longest argument. Example. [...] MIN (A, YY) has the value A , and 22 MIN ((/Z, A/), (/YY, B /)) has the value (/YY, A /). Analogously for: 13.7.71 MAX (A1, A2 [, A3, ...]) -- Summary: Fortran 2003: MIN and MAX with character variables Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29828
[Bug fortran/22282] %loc is not implemented in gfortran
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-11-14 10:37 --- %VAL, %REF and %DESCR have similar use and functionality, but %LOC is very different. It should in fact be an alias for function LOC, but it simply adding it in intrinsic.c with make_alias is not sufficient: creating a symbol name begining with a % has to be added to the parser and the symbol-name-mangler. My (short) attempt to do so failed, but it's probably not very difficult if you understand the binary tree structure of symbol names. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22282
[Bug fortran/29642] Fortran 2003: VALUE Attribute (call by value not call by reference for actual arguments)
--- Comment #3 from patchapp at dberlin dot org 2006-11-14 10:00 --- Subject: Bug number PR29642 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-11/msg00923.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29642
[Bug middle-end/28915] [4.1 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #25 from pinskia at gmail dot com 2006-11-14 10:02 --- Subject: Re: [4.1 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973 On Tue, 2006-11-14 at 09:29 +, jakub at gcc dot gnu dot org wrote: --- Comment #24 from jakub at gcc dot gnu dot org 2006-11-14 09:29 --- This change breaks bootstrap on x86_64-linux and i386-linux: This is now PR 29825 and it is an x86 back-end issue about not accepting the instruction which is valid as far as I can tell as the following asm instruction is valid: movl %eax, [EMAIL PROTECTED] -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #10 from jakub at gcc dot gnu dot org 2006-11-14 10:45 --- The problem is in the make_tree change of PR28915. make_tree is called with (const (unspec (something) ) ), before make_tree would just create a dummy VAR_DECL with DECL_RTL set to this, but now calls make_tree recursively and thus returns a dummy VAR_DECL with DECL_RTL set to (unspec (something) ) - note that CONST is lost. It is then folded and expanded, but CONST is never added back and i386 backend relies on it (and I believe other backends have similar requirements). I don't know why exactly the make_tree change was done, but certainly it should be limited to RTLs inside CONST that the middle-end groks fully. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug fortran/23060] %VAL, %REF and %DESCR constructs not implemented
--- Comment #11 from pault at gcc dot gnu dot org 2006-11-14 10:16 --- A long overdue patch for this will be submitted in the next 24hours. 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 Last reconfirmed|2006-11-03 14:11:48 |2006-11-14 10:16:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23060
[Bug c++/29829] New: arm-linux-g++: Internal error: Killed (program cc1plus)
while working in a project in C++. I tried to use a forward declaration of a class. Class is unders some name space. There I got the error message like below. arm-linux-g++: Internal error: Killed (program cc1plus) Please submit a full bug report. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: arm-linux-g++: Internal error: Killed (program cc1plus) Product: gcc Version: unknown Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mneehar at yahoo dot co dot in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29829
[Bug ada/29802] wrong directory in makefile for ada and libada when building the src directory
--- Comment #3 from jpvial at nerim dot net 2006-11-14 11:10 --- Subject: Re: wrong directory in makefile for ada and libada when building the src directory bonzini at gnu dot org wrote: --- Comment #2 from bonzini at gnu dot org 2006-11-14 08:26 --- it is supported, it is just buggy. Jean-Pierre, it seems like you have something like a patch. Can you expand your idea more? I think that the bug is in the configure script, not in the compiler itself. My solution cannot be called a patch, just a dirty workaround: 1: ada compiler for each stage of the bootstrap procedure, when the Makefile halts on the error, /home/jp/src/bug42/gcc-4.2-20061107/prev-gcc/gnatbind -C -I- -I. -Iada -I../.././gcc/ada -o ada/b_gnatb.c ada/gnatbind.ali make[3]: /home/jp/src/bug42/gcc-4.2-20061107/prev-gcc/gnatbind : commande introuvable (this is the french for command not found or something similar) I change to the relevant directory my-own-tree/gcc-4.2-20061107/host-x86_64-unknown-linux-gnu/gcc I change the PATH to my-own-tree/gcc-4.2-20061107/host-x86_64-unknown-linux-gnu/prev-gcc:$PATH I launch make in the directory, and wait for make (which is actually a sub-make) to finish. then I go back to the main directory my-own-tree/gcc-4.2-20061107 I restore the normal PATH and restart the main make for the next bootstrap stage, if any. This process is repeated for each stage. 2 libada : much simpler, and cleaner The Makefile for libada has a line: GCC_DIR=../../$(HOST_SUBDIR)/gcc but HOST_SUBDIR is nowhere defined, so GCC_DIR take the wrong value ../..//gcc I add, before the offending line HOST_SUBDIR=host-x86_64-unknown-linux-gnu and libada is built without further difficulty By the way, after the first answer to my bug report, I tried building in another directory; I had different bugs (of similar nature) for the compiler, and exactly the same problem for libada; finally it did not work better. I did not investigate further for this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29802
[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-11-14 11:11 --- The reduced testcase only fails on i?86, bootstrap also fails on x86_64 with the same error. At least (symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl 0x2af3f74a6580 dwarf_reg_size_table) is not a valid PIC address (it's only one in 64bit mode). from loop.c we enter ix86_expand_move (via gen_movis) with an operand1 of (unspec:SI [ (symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl 0x2b38cd3da580 dwarf_reg_size_table) ] 1) which we don't handle. We reach there through loop.c:gen_add_mult called with #11 0x0091e99b in gen_add_mult (b=0x2b38cd2ee410, m=0x2b38cd2ee410, a=0x2b38cd49bdc0, reg=0x2b38cd49bd20) at /space//rguenther/src/svn/gcc-4_1-branch/gcc/loop.c:9223 9223 result = expand_mult_add (b, reg, m, a, GET_MODE (reg), 1); (gdb) call debug_rtx (b) (const_int 1 [0x1]) (gdb) call debug_rtx (m) (const_int 1 [0x1]) (gdb) call debug_rtx (a) (plus:SI (plus:SI (reg:SI 3 bx) (const_int -1 [0x])) (const:SI (unspec:SI [ (symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl 0x2b38cd3da580 dwarf_reg_size_table) ] 1))) (gdb) call debug_rtx (reg) (reg:SI 82) via expmed.c:expand_mult_add we go through expanding a tree (ugh) which looks then like (gdb) call debug_tree (result) plus_expr 0x2b38cd499410 type integer_type 0x2b38cd2f8580 unsigned int public unsigned SI size integer_cst 0x2b38cd2e9a50 constant invariant 32 unit size integer_cst 0x2b38cd2e9570 constant invariant 4 align 32 symtab 0 alias set -1 precision 32 min integer_cst 0x2b38cd2e9b40 0 max integer_cst 0x2b38cd2e9b10 4294967295 arg 0 var_decl 0x2b38cd49c210 D.1348 type integer_type 0x2b38cd2f8580 unsigned int used unsigned SI file t.i line 16 size integer_cst 0x2b38cd2e9a50 32 unit size integer_cst 0x2b38cd2e9570 4 align 32 (reg:SI 3 bx) arg 1 var_decl 0x2b38cd49c160 D.1347 type integer_type 0x2b38cd2f8580 unsigned int used unsigned SI file t.i line 16 size integer_cst 0x2b38cd2e9a50 32 unit size integer_cst 0x2b38cd2e9570 4 align 32 (unspec:SI [ (symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl 0x2b38cd3da580 dwarf_reg_size_table) ] 1) which is where we get the plain UNSPEC from. In loop.c:scan_loop we propagate the load into its use which is the start of the problems. We then call validate_replace_rtx with (gdb) call debug_rtx (from) (reg/f:SI 72) (gdb) call debug_rtx (to) (plus:SI (reg:SI 3 bx) (const:SI (unspec:SI [ (symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl 0x2b22d66b7580 dwarf_reg_size_table) ] 1))) (gdb) call debug_rtx (insn) (insn 32 31 34 (parallel [ (set (reg:SI 71) (plus:SI (reg:SI 66 [ ivtmp.32 ]) (reg/f:SI 72))) (clobber (reg:CC 17 flags)) ]) 208 {*addsi_1} (nil) (nil)) In loop.c we go through lengths of discovering REG_EQUAL notes supposedly to use them as src in those operations. And indeed Index: loop.c === *** loop.c (revision 118809) --- loop.c (working copy) *** scan_loop (struct loop *loop, int flags) *** 1313,1326 ! modified_between_p (SET_SRC (set), p, user) no_labels_between_p (p, user) validate_replace_rtx (SET_DEST (set), ! SET_SRC (set), user)) { /* Replace any usage in a REG_EQUAL note. Must copy the new source, so that we don't get rtx sharing between the SET_SOURCE and REG_NOTES of insn p. */ REG_NOTES (user) = replace_rtx (REG_NOTES (user), SET_DEST (set), ! copy_rtx (SET_SRC (set))); delete_insn (p); for (i = 0; i LOOP_REGNO_NREGS (regno, SET_DEST (set)); --- 1313,1326 ! modified_between_p (SET_SRC (set), p, user) no_labels_between_p (p, user) validate_replace_rtx (SET_DEST (set), ! src, user)) { /* Replace any usage in a REG_EQUAL note. Must copy the new source, so that we don't get rtx sharing between the SET_SOURCE and REG_NOTES of insn p. */ REG_NOTES (user) = replace_rtx (REG_NOTES (user), SET_DEST (set), ! copy_rtx (src)); delete_insn (p); for (i = 0; i LOOP_REGNO_NREGS (regno, SET_DEST (set)); seems to fix this particular testcase.
[Bug tree-optimization/29832] -ftree-loop-linear miscompiles scalarize.f90
--- Comment #1 from jakub at gcc dot gnu dot org 2006-11-14 14:27 --- lambda_loopnest_to_gcc_loopnest interchanges the loops and we get: L12:; lletmp.77_46 = 0; lletmp.77_38 = lletmp.77_46 + 5; lnivtmp.75_21 = lnivtmp.75_9 + 1; lnivtmp.75_12 = lnivtmp.75_9 + 1; if (lletmp.77_38 = lnivtmp.75_12) goto L99; else goto L86; L86:; # lnivtmp.75_9 = PHI lnivtmp.75_21(13), lletmp.76_162(11); # S.2_165 = PHI S.2_40(13), 0(11); L13:; lbvtmp.82_18 = 0; lbvtmp.82_145 = lnivtmp.78_8; lbvtmp.82_20 = lbvtmp.82_18 + lbvtmp.82_145; S.2_40 = lbvtmp.82_20 + 1; lletmp.79_154 = 0; # lnivtmp.78_8 = PHI lnivtmp.78_3(16), lletmp.79_154(14); # S.3_171 = PHI S.3_51(16), 1(14); L15:; lletmp.80_22 = 0; lletmp.80_56 = lletmp.80_22 + 3; D.1393_41 = S.2_40 * 6; lbvtmp.81_31 = 0; lbvtmp.81_26 = lnivtmp.78_8; lbvtmp.81_106 = lbvtmp.81_26 + lbvtmp.81_31; D.1394_43 = 5 - lbvtmp.81_106; D.1395_44 = D.1394_43 * 6; pretmp.59_117 = D.1395_44 + -7; pretmp.59_121 = D.1393_41 + -7; D.1343_45 = pretmp.59_117; lbvtmp.84_161 = 0; lbvtmp.84_105 = lnivtmp.75_9; lbvtmp.84_120 = lbvtmp.84_105 + lbvtmp.84_161; D.1397_47 = pretmp.59_117 + lbvtmp.84_120; D.1342_42 = pretmp.59_121; lbvtmp.83_157 = 0; lbvtmp.83_158 = lnivtmp.75_9; lbvtmp.83_159 = lbvtmp.83_157 + lbvtmp.83_158; D.1398_48 = pretmp.59_121 + lbvtmp.83_159; D.1399_49 = a[D.1398_48]; b[D.1397_47] = D.1399_49; lbvtmp.85_125 = 0; lbvtmp.85_74 = lnivtmp.75_9; lbvtmp.85_68 = lbvtmp.85_74 + lbvtmp.85_125; S.3_51 = lbvtmp.85_68 + 1; lnivtmp.78_3 = lnivtmp.78_8 + 1; lnivtmp.78_19 = lnivtmp.78_8 + 1; if (lletmp.80_56 = lnivtmp.78_19) goto L12; else goto L87; L87:; goto bb 15 (L15); These basic blocks are the only ones that ever mention lnivtmp.78 variable, it is set from a PHI node at L15, but used both in L15 (ok) and also in L13, which isn't dominated by L15 (L13 is where the loop is entered). The lnivtmp.78 use before definition is from the bumper statement which is considered ok by perfect_nest_p. If the bumper SSA_NAME was only used in the bumper statement and the PHI node, this wouldn't be a big issue, eventhough lambda_loopnest_to_gcc_loopnest would reference undefined variable, it would be quickly optimized away (as the bumper would be optimized out as unused) - ltrans creates new bumper vars, but unfortunately it is used. I think either perfect_nest_p should only allow bumper variables which are solely used in the bumper statement and PHI node and nowhere else (this would cure this case, either it wouldn't be considered valid for ltrans or perfect_nestify would need to try harder (e.g. by cloning the bumper statement within the inner loop's body, in the inner loop's body it would set a different temporary which would be used there and the original bumper var would be only used outside of inner loop and in the PHI)), or lambda_loopnest_to_gcc_loopnest needs to be tought to special case stmt_is_bumper_for_loop statements outside of the innermost loop. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29832
[Bug fortran/29657] Don't allow SAVE for functions
--- Comment #7 from burnus at gcc dot gnu dot org 2006-11-14 15:49 --- Fixed in trunk. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29657
[Bug ada/29802] wrong directory in makefile for ada and libada when building the src directory
--- Comment #4 from bonzini at gnu dot org 2006-11-14 12:23 --- Created an attachment (id=12616) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12616action=view) patch to fix the bug Please try this. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29802
[Bug c/29826] __attribute__ dllimport makes optimization crash on cygwin
--- Comment #1 from Denis dot Excoffier at airbus dot com 2006-11-14 11:39 --- To be connected to Bug 29825. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-11-14 11:48 --- While that can help in this case, I think letting make_tree/expand_expr combo create invalid RTL is very dangerous (and, at least from i386 backend POV, some of the PIC UNSPECs not surrounded by CONST are invalid, the backend guarantees that wherever it creates them it adds the CONST around). FWIW I agree. Branches are not the right place to try out this kind of things. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug c++/29830] Name lookup bug for inner template specialization
--- Comment #1 from pluto at agmk dot net 2006-11-14 12:53 --- this is a dup of PR29767 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29830
[Bug c++/29830] New: Name lookup bug for inner template specialization
Hi, I haven't found any related bug in the known bugs database. Also I posted this problem to several forums to be shore that this code doesn't violate the C++ standard. ~60% replies that this should work. Moreover two other compilers can compile without any problem: The simplified code: // #include stdio.h template typename T, int v class record_descriptor { public: void operator()() { printf(Global template\n); } }; templatetypename T, int v, templatetypename,int class RD = record_descriptor class TableRecord { public: TableRecord() { RDT, v d; d(); } }; templatetypename A class Attr { public: template typename T, int v class i_record_descriptor { }; template int v class i_record_descriptorA, v { public: void operator()() { printf(Inner spec template\n); } }; Attr() { TableRecordA, 1, i_record_descriptor tr; } }; int main() { Attrint attr; return 0; } // Message: gccbug.cpp: In constructor 'TableRecordT, v, RD::TableRecord() [with T = int, int v = 1, RD = Attrint::i_record_descriptor]': gccbug.cpp:32: instantiated from 'AttrA::Attr() [with A = int]' gccbug.cpp:37: instantiated from here gccbug.cpp:15: error: no match for call to '(Attrint::i_record_descriptorint, 1) ()' If i_class_descriptor template has an implementation: // #include stdio.h template typename T, int v class record_descriptor { public: void operator()() { printf(Global template\n); } }; templatetypename T, int v, templatetypename,int class RD = record_descriptor class TableRecord { public: TableRecord() { RDT, v d; d(); } }; templatetypename A class Attr { public: template typename T, int v class i_record_descriptor { public: void operator()() { printf(Inner template\n); } }; template int v class i_record_descriptorA, v { public: void operator()() { printf(Inner spec template\n); } }; Attr() { TableRecordA, 1, i_record_descriptor tr; } }; int main() { Attrint attr; return 0; } / ...compiles but the result after executing is Inner template instead of Inner spec template If the parameter 'A' is changed in the partial specialozation to a primitve type, ex: 'int' then compiles fine and the result is correct. The last version I tried was: g++ (GCC) 4.1.2 20060901 (prerelease) (Debian 4.1.1-13) I hope I give you all the necessary information! Regards, Zoltan Jasz Software developer, Ericsson Telecomunication Hungary Ltd. -- Summary: Name lookup bug for inner template specialization Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zjasz at yahoo dot com GCC build triplet: 4.1.1 20060525 (Red Hat 4.1.1-1) GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29830
[Bug fortran/29828] Fortran 2003: MIN and MAX with character variables
--- Comment #1 from pault at gcc dot gnu dot org 2006-11-14 14:17 --- Confirmed. Tobias, What criterion are you chosing for the missing F2003 features? The reason that I ask is that it is not clear to me when you stop; eg. should we have a PR for polymorphism or for sub-modules? Maybe it would be better to have a meta-bug for F2003 and point to a Wiki page in which we try to joggle up a priority order? Best regards Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-14 14:17:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29828
[Bug c++/29830] Name lookup bug for inner template specialization
--- Comment #2 from zjasz at yahoo dot com 2006-11-14 15:02 --- (In reply to comment #1) this is a dup of PR29767 Sorry for duplication, I haven't checked again after I posted to the gcc-help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29830
[Bug c/29833] gcc 4.1.2 on x86_64 Ubuntu Edgy generates incorrect prefetch instruction
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-11-14 15:54 --- What does adding '-v' to the compile command say? It seems Ubuntu is using a default -march that enables 3dnow (k8 or opteron maybe) - it should use x86_64 instead. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29833
[Bug preprocessor/29831] New: changed include order when symlinking prefix or moving binaries
Have built gcc with --prefix=/usr/local/gcc-4.1.1. When /usr/local/gcc-4.1.1 is moved and symlinked to /stranger/gcc-4.1.1, the include path order changes, so that fixed system headers are searched before local headers. In non-symlink case, where the searched include path is correct, I can see this output (with focus on the include path): $ /usr/local/gcc-4.1.1/bin/gcc -c -v xx.c Using built-in specs. Target: i686-pc-linux-gnu Configured with: /ftp/pub/source/gcc/gcc-4.1.1.orig/configure --prefix=/usr/local/gcc-4.1.1 --enable-languages=c Thread model: posix gcc version 4.1.1 /usr/local/gcc-4.1.1/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -quiet -v xx.c -quiet -dumpbase xx.c -mtune=pentiumpro -auxbase xx -version -o /tmp/ccL8OzjB.s ignoring nonexistent directory /usr/local/gcc-4.1.1/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/local/gcc-4.1.1/include /usr/local/gcc-4.1.1/lib/gcc/i686-pc-linux-gnu/4.1.1/include /usr/include End of search list. GNU C version 4.1.1 (i686-pc-linux-gnu) compiled by GNU C version 4.1.1 (Gentoo 4.1.1). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 36febb42c74478a1ecbe6b4467b0f6b8 as -V -Qy -o xx.o /tmp/ccL8OzjB.s GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1 When I move and symlink /usr/local/gcc-4.1.1 to /stranger/gcc-4.1.1, the include order changes: $ mkdir /stranger $ mv /usr/local/gcc-4.1.1 /stranger $ ln -s /stranger/gcc-4.1.1 /usr/local $ /usr/local/gcc-4.1.1/bin/gcc -c -v xx.c Using built-in specs. Target: i686-pc-linux-gnu Configured with: /ftp/pub/source/gcc/gcc-4.1.1.orig/configure --prefix=/usr/local/gcc-4.1.1 --enable-languages=c Thread model: posix gcc version 4.1.1 /stranger/gcc-4.1.1/bin/../libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -quiet -v -iprefix /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/ xx.c -quiet -dumpbase xx.c -mtune=pentiumpro -auxbase xx -version -o /tmp/cc0hiBMc.s ignoring nonexistent directory /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include ignoring duplicate directory /usr/local/gcc-4.1.1/lib/gcc/i686-pc-linux-gnu/4.1.1/include ignoring nonexistent directory /usr/local/gcc-4.1.1/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/include /usr/local/include /usr/local/gcc-4.1.1/include /usr/include End of search list. GNU C version 4.1.1 (i686-pc-linux-gnu) compiled by GNU C version 4.1.1 (Gentoo 4.1.1). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 36febb42c74478a1ecbe6b4467b0f6b8 as -V -Qy -o xx.o /tmp/cc0hiBMc.s GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1 The basic difference is that cc1 gets called as: /stranger/gcc-4.1.1/bin/../libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 with this additional argument: -iprefix /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/ Additionally, when _moving_ to /stranger/gcc-4.1.1, /stranger/gcc-4.1.1/include does not get searched any more, while fixed system headers continue being searched first: $ rm /usr/local/gcc-4.1.1 $ /stranger/gcc-4.1.1/bin/gcc -c -v xx.c Using built-in specs. Target: i686-pc-linux-gnu Configured with: /ftp/pub/source/gcc/gcc-4.1.1.orig/configure --prefix=/usr/local/gcc-4.1.1 --enable-languages=c Thread model: posix gcc version 4.1.1 /stranger/gcc-4.1.1/bin/../libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -quiet -v -iprefix /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/ xx.c -quiet -dumpbase xx.c -mtune=pentiumpro -auxbase xx -version -o /tmp/ccIr1Gz5.s ignoring nonexistent directory /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include ignoring nonexistent directory /usr/local/gcc-4.1.1/include ignoring nonexistent directory /usr/local/gcc-4.1.1/lib/gcc/i686-pc-linux-gnu/4.1.1/include ignoring nonexistent directory /usr/local/gcc-4.1.1/i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/include /usr/local/include /usr/include End of search list. GNU C version 4.1.1 (i686-pc-linux-gnu) compiled by GNU C version 4.1.1 (Gentoo 4.1.1). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 36febb42c74478a1ecbe6b4467b0f6b8 as -V -Qy -o xx.o /tmp/ccIr1Gz5.s GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1 This is not only on linux, but on most (all?) unices too. -- Summary: changed include order when symlinking prefix or moving binaries Product: gcc Version: 4.1.1
[Bug tree-optimization/29832] New: -ftree-loop-linear miscompiles scalarize.f90
gfortran.fortran-torture/execute/scalarize.f90 is miscompiled at least on x86_64-linux with -O2 -ftree-loop-linear (other miscompiled fortran tests with -ftree-loop-linear are forall_1.f90 and der_type.f90). The only linear transformed loop in scalarize.f90 is the b(:, 5:1:-1) = a one (i.e. int8 S.2; S.2 = 0; while (1) { if (S.2 4) goto L.6; else (void) 0; { int8 D.1343; int8 D.1342; int8 S.3; D.1342 = (NON_LVALUE_EXPR S.2 + 1) * 6 + -7; D.1343 = (5 - S.2) * 6 + -7; S.3 = 1; while (1) { if (S.3 6) goto L.5; else (void) 0; b[NON_LVALUE_EXPR S.3 + D.1343] = a[NON_LVALUE_EXPR S.3 + D.1342]; S.3 = S.3 + 1; } L.5:; } S.2 = S.2 + 1; } L.6:; ). When entering ltrans, this is not perfect nest, but perfect_nestify changes it. I believe that transformation is valid: We have before ltrans (with loop entry L13 and loop exit L85): L12:; if (S.2_40 4) goto L85; else goto L86; L86:; # S.2_165 = PHI S.2_40(13), 0(11); L13:; S.2_40 = S.2_165 + 1; D.1393_41 = S.2_40 * 6; D.1394_43 = 5 - S.2_165; D.1395_44 = D.1394_43 * 6; pretmp.59_117 = D.1395_44 + -7; pretmp.59_121 = D.1393_41 + -7; # S.3_171 = PHI S.3_51(16), 1(14); L15:; D.1343_45 = pretmp.59_117; D.1397_47 = pretmp.59_117 + S.3_171; D.1342_42 = pretmp.59_121; D.1398_48 = pretmp.59_121 + S.3_171; D.1399_49 = a[D.1398_48]; b[D.1397_47] = D.1399_49; S.3_51 = S.3_171 + 1; if (S.3_51 6) goto L12; else goto L87; L87:; goto bb 15 (L15); This isn't perfect nest due to the pretmp.59_* MODIFY_EXPRs and their temporaries, and perfect_nestify transforms this into: L12:; if (S.2_40 4) goto L99; else goto L86; L86:; # S.2_165 = PHI S.2_40(13), 0(11); L13:; S.2_40 = S.2_165 + 1; # S.3_171 = PHI S.3_51(16), 1(14); L15:; D.1393_41 = S.2_40 * 6; D.1394_43 = 5 - S.2_165; D.1395_44 = D.1394_43 * 6; pretmp.59_117 = D.1395_44 + -7; pretmp.59_121 = D.1393_41 + -7; D.1343_45 = pretmp.59_117; D.1397_47 = pretmp.59_117 + S.3_171; D.1342_42 = pretmp.59_121; D.1398_48 = pretmp.59_121 + S.3_171; D.1399_49 = a[D.1398_48]; b[D.1397_47] = D.1399_49; S.3_51 = S.3_171 + 1; if (S.3_51 6) goto L12; else goto L87; L87:; goto bb 15 (L15); ... L99:; goto bb 44 (L100); # perfectiv.73_65 = PHI 0(43), perfectiv.73_4(46); L100:; uboundvar.74_155 = 4 + -1; perfectiv.73_4 = perfectiv.73_65 + 1; if (uboundvar.74_155 = perfectiv.73_4) goto L101; else goto L85; L101:; goto bb 44 (L100); (this was dumped before perfect_nest call at the end of perfect_nestify). It looks just fine to me, all it did was move the pretmp.95_* and their temporaries setting back into the L15 loop and create a pointless empty loop which further optimizations surely remove. The problem is either in perfect_nest_p (i.e. question whether what perfect_nestify created is a valid perfect nest, but identical basic blocks could as well come just from earlier passes without perfect_nestify being ever called), or if lambda_loopnest_to_gcc_loopnest screw this up. The problematic statement is the: S.2_40 = S.2_165 + 1; which is stmt_is_bumper_for_loop for the outer loop, but isn't used solely as the bumper, but also in the inner loop: D.1393_41 = S.2_40 * 6; -- Summary: -ftree-loop-linear miscompiles scalarize.f90 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29832
[Bug c/29833] gcc 4.1.2 on x86_64 Ubuntu Edgy generates incorrect prefetch instruction
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-11-14 16:29 --- Please file a bug with Ubuntu instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29833
[Bug tree-optimization/29832] -ftree-loop-linear miscompiles scalarize.f90
--- Comment #2 from jakub at gcc dot gnu dot org 2006-11-14 14:28 --- Forgot to mention, the problem is reproduceable also on gcc-4_1-branch and gcc-4_2-branch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Keywords|wrong-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29832
[Bug c/29833] New: gcc 4.1.2 on x86_64 Ubuntu Edgy generates incorrect prefetch instruction
Actual version string from gcc: 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Using __builtin_prefetch with the default compiler flags (i.e, mtune=generic) generates a 3dnow prefetch instruction (prefetchw), which won't run on em64t cpus. Attaching test file. Compiling this with gcc -otest test.c produces a binary that faults on em64t. Compiling with 'gcc -o test -mno-3dnow test.c' generates a prefetcht0 instruction, which works. -- Summary: gcc 4.1.2 on x86_64 Ubuntu Edgy generates incorrect prefetch instruction Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thaytan at noraisin dot net GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29833
[Bug c++/14032] Specialization of inner template using outer template argument doesn't work
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-11-14 16:30 --- *** Bug 29830 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||zjasz at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-11-14 16:34 --- (In reply to comment #13) While that can help in this case, I think letting make_tree/expand_expr combo create invalid RTL is very dangerous (and, at least from i386 backend POV, some of the PIC UNSPECs not surrounded by CONST are invalid, the backend guarantees that wherever it creates them it adds the CONST around). Did you read what I wrote, I said it is not valid, the x86 back-end should really be accepting it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations
--- Comment #6 from Raimund dot Merkert at baesystems dot com 2006-11-14 15:52 --- It does not seem to warn about unused functions. I also tried the following test case where 4.0.0 (solaris) does not warn even about foo ( I guess because it's referenced in Y's constructor?) gcc -Wunused-function test.cpp #include cstdio static void foo() {} struct Y { Y() { foo(); } }; struct X { inline X (const Y) {} inline ~X () { ::std::printf(1\n); } }; int main() { X x(Y()); return 0; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25814
[Bug fortran/29657] Don't allow SAVE for functions
--- Comment #6 from burnus at gcc dot gnu dot org 2006-11-14 15:35 --- Subject: Bug 29657 Author: burnus Date: Tue Nov 14 15:35:36 2006 New Revision: 118812 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118812 Log: fortran/ 2006-11-14 Tobias Burnus [EMAIL PROTECTED] PR fortran/29657 * symbol.c (check_conflict): Add further conflicts. testsuite/ 2006-11-14 Tobias Burnus [EMAIL PROTECTED] PR fortran/29657 * gfortran.dg/conflicts.f90: Add. Added: trunk/gcc/testsuite/gfortran.dg/conflicts.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29657
[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations
--- Comment #5 from wolfgang dot roemer at gmx dot net 2006-11-14 15:35 --- [EMAIL PROTECTED] wrote: Usually the problem will get caught as soon as you try to invoke a method, but if it's something like a guard object, without methods, then it can be a problem. At least in this case there should be a warning if -Wunused-function is used, shouldn't it? -- wolfgang dot roemer at gmx dot net changed: What|Removed |Added CC||wolfgang dot roemer at gmx ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25814
[Bug tree-optimization/29832] -ftree-loop-linear miscompiles scalarize.f90
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Keywords||wrong-code Known to fail||4.1.2 4.2.0 4.3.0 Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29832
[Bug c/29833] gcc 4.1.2 on x86_64 Ubuntu Edgy generates incorrect prefetch instruction
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-11-14 15:56 --- For SUSE 4.1.2 I get prefetcht0 generated. So this is an Ubuntu bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29833
[Bug target/16634] arm-elf-gcc problems when generating code for __attribute__ ((interrupt (IRQ)))
--- Comment #5 from tla at thrane dot com 2006-11-14 16:28 --- (In reply to comment #4) What's the status of this patch? The bug is also present in arm-elf-gcc version 4.1.0 However, adding the -fno-omit-frame-pointer parameter, make the compiler emit the correct code in the mentioned code example. -- tla at thrane dot com changed: What|Removed |Added CC||tla at thrane dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16634
[Bug c/29833] gcc 4.1.2 on x86_64 Ubuntu Edgy generates incorrect prefetch instruction
--- Comment #4 from thaytan at noraisin dot net 2006-11-14 16:09 --- It's using -mtune=generic: Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) /usr/lib/gcc/x86_64-linux-gnu/4.1.2/cc1 -quiet -v test.c -quiet -dumpbase test.c -mtune=generic -auxbase test -version -fstack-protector -fstack-protector -o /tmp/cc5wy3wa.s ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu ignoring nonexistent directory /usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../x86_64-linux-gnu/include ignoring nonexistent directory /usr/include/x86_64-linux-gnu #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.1.2/include /usr/include End of search list. GNU C version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) (x86_64-linux-gnu) compiled by GNU C version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128174 Compiler executable checksum: 69b037dea6ceacffa2e97527b1ac3ca3 as -V -Qy -o /tmp/ccONENBd.o /tmp/cc5wy3wa.s GNU assembler version 2.17 (x86_64-linux-gnu) using BFD version 2.17 Debian GNU/Linux /usr/lib/gcc/x86_64-linux-gnu/4.1.2/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test /usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.1.2/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.1.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.1.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 /tmp/ccONENBd.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.1.2/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crtn.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29833
[Bug c++/29834] New: g++ thinks it is a declaration when it cannot be
More cases where g++ apparently doesn't take enough context into account when deciding that something can be (and thus is) a declaration. Compiled the following (legal) program using g++ -c --- struct Doh { Doh( int ) {} } ; int x = 0 ; int f() { Doh( x ), ++ x ; return Doh( x ), x ; } --- Got following errors: --- parseError.cc: In function 'int f()': parseError.cc:11: error: no matching function for call to 'Doh::Doh()' parseError.cc:3: note: candidates are: Doh::Doh(int) parseError.cc:2: note: Doh::Doh(const Doh) parseError.cc:11: error: expected unqualified-id before '++' token parseError.cc:12: error: cannot convert 'Doh' to 'int' in return --- Apparently, g++ is interpreting Doh( x ) as a declaration, although in neither case is a declaration legal. (++x is not a legal declarator, so the first line cannot be a declaration, and of course, a declaration cannot start with the keyword return.) (Note that in the actual code, Doh was boost::mutex::scoped_lock. And I fear that using boost::mutex::scoped_lock like this is becoming a widespread idiom.) -- Summary: g++ thinks it is a declaration when it cannot be Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: james dot kanze at gmail dot com GCC build triplet: sparc-sun-solaris2.8 GCC host triplet: sparc-sun-solaris2.8 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
[Bug fortran/29711] error_print does not support %N$X
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-11-14 16:44 --- What about: de.f90:4: use foo, only : bar 1 Fehler: Bei (1) referenziertes Symbol »bar« nicht im Modul »foo« gefunden My limited german knowledge seems to indicate that it's OK, but I'm not sure. Could you try the attached patch on a few cases (possibly including multiple loci and such arguments reorganizations)? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29711
[Bug c++/29830] Name lookup bug for inner template specialization
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-14 16:30 --- *** This bug has been marked as a duplicate of 14032 *** -- 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=29830
[Bug ada/29802] [4.2/4.3 Regression] wrong directory in makefile for ada and libada when srcdir=.
--- Comment #5 from Jean-pierre dot vial at wanadoo dot fr 2006-11-14 17:11 --- (In reply to comment #0) when building ada on linux (x86-64) building ada fails because the makefile looks for gnatbuild in mydir/gcc-4.2-20061107/prev-gcc instead of mydir/gcc-4.2-20061107/host-x86_64-unknown-linux-gnu/prev-gcc I could not find where precisely in the makefile the bug hides. for libada it is obvious: the make variable HOST_SUBDIR is used, but nowhere defined. If I define it, libada is built (In reply to comment #4) Created an attachment (id=12616) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12616action=view) [edit] patch to fix the bug Please try this. The patch for the compiler works the patch for libada does not, here is the error message: Makefile:55: ../../@HOST_SUBDIR@/gcc/libada-mk: Aucun fichier ou répertoire de ce type (french message for no such file or directory) I tried the patch with HOST_SUBDIR both in lowercase and uppercase, same result. -- Jean-pierre dot vial at wanadoo dot fr changed: What|Removed |Added CC||Jean-pierre dot vial at ||wanadoo dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29802
[Bug c/29833] gcc 4.1.2 on x86_64 Ubuntu Edgy generates incorrect prefetch instruction
--- Comment #1 from thaytan at noraisin dot net 2006-11-14 14:26 --- Created an attachment (id=12617) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12617action=view) simple test file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29833
[Bug c/29827] Assigning function with a char param emits a spurious warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-14 10:09 --- This is not a bug, the reason is because void foo(char); void (*f1)() = foo; For foo, the prototype is not using int but instead char (or short) and f1 is not reallying having a prototype (old KR rules). Comeau C rejects this code as invalid with about the same error message as our warning. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29827
[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-14 09:53 --- Hmm, isn't movl %eax, [EMAIL PROTECTED] a valid way to have an offset? Reduced testcase: struct _Unwind_Context { void *reg[18]; }; static unsigned char dwarf_reg_size_table[18]; uw_install_context_1 (void *current, struct _Unwind_Context *target) { long i; for (i = 0; i 17; ++i) { void *t = target-reg[i]; if (t) __builtin_memcpy (current, t, dwarf_reg_size_table[i]); } } -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |target GCC target triplet||i?86-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug c++/29829] arm-linux-g++: Internal error: Killed (program cc1plus)
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-14 12:42 --- You need to provide a preprocessed testcase, specify what gcc version you use and what flags to compile. arm-linux-g++: Internal error: Killed (program cc1plus) this means the kernel (or you) killed the compiler, it probably has gone out-of-memory. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29829
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #25 from fche at redhat dot com 2006-11-14 12:19 --- (In reply to comment #24) Might the problem be that I am compiling on an old glibc? That is possible. Try MUDFLAP_OPTIONS=-trace-calls -verbose-trace. If you have access to a modern glibc, you could compare traces from the two variants. Or that you didn't invoke ./make and didn't in fact run the resulting exe? I certainly ran it. env MUDFLAP_OPTIONS=-collect-stats ./make gives some interesting figures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug c++/29106] [4.0 Regression] sizeof(*var) in expression drops entire line of code out of compile
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-11-14 17:14 --- Subject: Bug 29106 Author: mmitchel Date: Tue Nov 14 17:13:57 2006 New Revision: 118818 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118818 Log: PR c++/29106 * g++.dg/init/self1.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/init/self1.C Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29106
[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-11-14 17:14 --- Created an attachment (id=12619) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12619action=view) patch This one passes a C bootstrap regtest on x86_64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug c++/29106] [4.0 Regression] sizeof(*var) in expression drops entire line of code out of compile
--- Comment #11 from mmitchel at gcc dot gnu dot org 2006-11-14 17:15 --- Subject: Bug 29106 Author: mmitchel Date: Tue Nov 14 17:15:08 2006 New Revision: 118819 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118819 Log: PR c++/29106 * g++.dg/init/self1.C: New test. Added: trunk/gcc/testsuite/g++.dg/init/self1.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29106
[Bug c++/27693] [4.0 Regression] strange interaction with const and sizeof and variable declarations in g++-4.0
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-11-14 17:15 --- Fixed in 4.1 by the patch for PR 29106. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1 Regression] strange|[4.0 Regression] strange |interaction with const and |interaction with const and |sizeof and variable |sizeof and variable |declarations in g++-4.0 |declarations in g++-4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27693
[Bug fortran/29711] error_print does not support %N$X
--- Comment #5 from burnus at gcc dot gnu dot org 2006-11-14 17:16 --- Fehler: Bei (1) referenziertes Symbol »bar« nicht im Modul »foo« gefunden My limited german knowledge seems to indicate that it's OK, but I'm not sure. Looks ok. Could you try the attached patch on a few cases (possibly including multiple loci and such arguments reorganizations)? I will try. It actually effects the following strings in the following languages (see gcc/po/): de.po-msgid Symbol '%s' referenced at %L not found in module '%s' de.po-msgid User operator '%s' referenced at %L not found in module '%s' de.po-msgid Intrinsic operator '%s' referenced at %L not found in module '%s' de.po-msgid The equivalence set for variable '%s' declared at %L violates alignment requirents tr.po-msgid Processing spec %c%s%c, which is '%s'\n tr.po:msgstr '%4$s' %1$c%2$s%3$c ozelligi isleniyor\n ^ This could be a challenge! tr.po-msgid %s: warning: using formals list from %s(%d) for function '%s'\n tr.po-msgid collect: tweaking %s in %s\n zh_TW.po-msgid Assumed size array '%s' in namelist '%s'at %C is not allowed. zh_TW.po-msgid Assumed shape array '%s' in namelist '%s' at %C is an extension. zh_TW.po-msgid Argument '%s' of pure function '%s' at %L must be INTENT(IN) (Reminder to self: test also %s does not support %%n$ operand number formats.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29711
[Bug debug/29792] DWARF: Not all inline concrete instances are being generated
--- Comment #10 from acme at mandriva dot com 2006-11-14 17:19 --- (In reply to comment #9) I'm quite aware of what GCC outputs here :) However, past the initial declarations, we don't output debug information about what the state of the IR is at random points in the compilation, only about what the final output looks like. Since there is no inlined code left, we don't end up saying there is an inlined subroutine. Even if we could change this, i'm not sure we'd want to. It doesn't seem incorrect at all to do what we do. Otherwise, you'd end up with inlined subroutine dies with no low pc/high pc associated with them, which seems nonsensical. OK, so I'll have to find another way of using the DWARF info to see if a inline routine, such as __task_rq_lock was used at all in the build or was just included in the DWARF info but not referenced anywhere, have to dig more into the available information... BTW, if, in these cases, DW_TAG_subroutine is not referenced, what is the purpose of it being included? Is there a reason my limited knowledge is not realising? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29792
[Bug middle-end/27881] [4.1 Regression] Memory exhausted with -finline-functions on testsuite file alias3.C
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-11-14 17:25 --- The following simpler test case is sufficient to show the same behavior: struct X{}; void f(X x) { f(x); f(x); } Also, it is indeed true that --param max-inline-recursive-depth-auto=3 makes this compile instantaneously, but a value of 4 makes it go for a long time. I understand expoentials, but 2^4 isn't that big a number, so I wonder if we're hitting something else super-linear in here -- perhaps something that still in later releases as well? I am going to downgrade this to P2, as normally -finline-functions is only used with -O3, and as the --param option provides a work-around. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27881
[Bug c++/27826] [4.0/4.1 Regression] ICE in copy_to_mode_reg
--- Comment #14 from mmitchel at gcc dot gnu dot org 2006-11-14 17:30 --- I cannot getting this to fail with current GCC 4.1.2 sources. Can others still reproduce this problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27826
[Bug c++/14032] Specialization of inner template using outer template argument doesn't work
--- Comment #11 from zjasz at yahoo dot com 2006-11-14 17:40 --- (In reply to comment #6) Work postponed to GCC 4.1. This bug is tricky to fix. What is the status of this bug? Will be resolved in the next release? For us is critical because a whole framework is built up on this.:,,,( Unfortunately we don't have any workaround! /jz -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug middle-end/27881] [4.1 Regression] Memory exhausted with -finline-functions on testsuite file alias3.C
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-11-14 17:42 --- It's true that the number of created calls is 2^N, but unfortunately the number of created temporaries grows super-exponential: --param max-inline-recursive-depth-auto grep 'struct X' t.C.t24.fixupcfg | wc -l 1 3 2 63 3 16383 (!) So it grows like n_i = (2*(n_{i-1}+1))**2 - 1 with n_1 = 3. For 4 we would have 1073741823, for 5 we get 4611686018427387904 number of temporaries ;) Honza's patch (comment #8) fixes this on the mainline, but I guess porting that back is not really an option. We might instead lower the default value of max-inline-recursive-depth[-auto], which is currently 8. From the above numbers a limit of 2 should be appropriate. Or we can make it count the number of functions inlined, not the depth, to avoid exponential behavior with multiple calls to self. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27881
[Bug c++/27826] [4.0/4.1 Regression] ICE in copy_to_mode_reg
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-11-14 17:44 --- Yes: gcc41-g/gcc ./cc1plus -quiet t.C -O3 t.C: In function 'int f()': t.C:6: internal compiler error: in copy_to_mode_reg, at explow.c:577 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|i686-pc-linux-gnu |i?86-*-* x86_64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27826
[Bug c++/14032] Specialization of inner template using outer template argument doesn't work
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-11-14 17:46 --- Raising severity, some more people in CC. This at least seems to be an often reported problem. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug rtl-optimization/29349] mode switching is inefficient both at compile time and at run time
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-11-14 17:50 --- fpchg should also be enabled in sh.md for TARGET_SH4_300 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29349
[Bug c++/14032] Specialization of inner template using outer template argument doesn't work
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-11-14 17:54 --- (In reply to comment #12) Raising severity, some more people in CC. This at least seems to be an often reported problem. It is not a regression as far as I can tell. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug fortran/29835] New: Error message of non-unknown edit descriptor needs improvement
gfortran writes: read(1,'(Q,A)',iostat=i) n,line(:n) 1 Warning: Unexpected element in format string at (1) And if there is a long comment it may even look like: XLINE 1 Warning: Unexpected element in format string at (1) Expected: read(1,'(Q,A)',iostat=i) n,line(:n) 1 Warning: Unexpected element in format string at (1) or even: Warning: Unexpected element 'Q' in format string at (1) (The run-time message is also slightly misaligned: read(1,'(Q,A)') n,line(:n) 1 -- Test program - integer, parameter :: MAXLINE = 255 character(MAXLINE) line open(1,file='whatever', access='sequential',form='formatted',action='read') do read(1,'(Q,A)',iostat=i) n,line(:n) if (i/=0) exit ! real work here enddo end -- Test program - Cf. http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d968667b1e3219ab * * * The Q edit descriptor is, e.g., described at http://www.helsinki.fi/atk/unix/dec_manuals/cf77au/olrm0242.htm It is documented but not supported in g77, seems to be a DEC extension and is supported by ifort and sunf95. I think, gfortran does not need to support it. -- Summary: Error message of non-unknown edit descriptor needs improvement Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29835
[Bug fortran/29835] Error message of non-unknown edit descriptor needs improvement
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-14 18:01:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29835
[Bug tree-optimization/27755] PRE confused by control flow
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-11-14 18:12 --- Subject: Bug 27755 Author: dberlin Date: Tue Nov 14 18:12:20 2006 New Revision: 118821 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118821 Log: 2006-11-14 Daniel Berlin [EMAIL PROTECTED] Fix PR tree-optimization/27755 * tree-ssa-pre.c: Update comments. (bb_bitmap_sets): Add pa_in and deferred member. (BB_DEFERRED): New macro. (maximal_set): New variable. (pre_stats): Add pa_insert member. (bitmap_set_and): Short circuit orig == dest. (bitmap_set_subtract_values): New function. (bitmap_set_contains_expr): Ditto. (translate_vuses_through_block): Add phiblock argument. (dependent_clean): New function. (compute_antic_aux): Update for maximal_set changes. (compute_partial_antic_aux): New function. (compute_antic): Handle partial anticipation. (do_partial_partial_insertion): New function. (insert_aux): Handle partial anticipation. (add_to_sets): Add to maximal set. (compute_avail): Ditto. (init_pre): Initialize maximal_set. (execute_pre): Do partial anticipation if -O3+. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-16.c Modified: trunk/ (props changed) trunk/gcc/ChangeLog trunk/gcc/tree-ssa-pre.c Propchange: trunk/ ('svk:merge' modified) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27755
[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #16 from jason at gcc dot gnu dot org 2006-11-14 18:21 --- (In reply to comment #15) patch Please apply this patch to 4.2 and the trunk. I've reverted my patch on the 4.1 branch, as it seems to be too risky there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug c++/14032] Specialization of inner template using outer template argument doesn't work
--- Comment #14 from bangerth at math dot tamu dot edu 2006-11-14 18:37 --- Subject: Re: Specialization of inner template using outer template argument doesn't work It is not a regression as far as I can tell. True. However it does produce wrong code. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug fortran/24783] Implicit none in module overwrite explicit in procedure
--- Comment #2 from patchapp at dberlin dot org 2006-11-14 18:41 --- Subject: Bug number pr24783 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-11/msg00966.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24783
[Bug ada/29802] [4.2/4.3 Regression] wrong directory in makefile for ada and libada when srcdir=.
--- Comment #6 from bonzini at gnu dot org 2006-11-14 18:56 --- Created an attachment (id=12620) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12620action=view) updated patch Right, you need this additional hunk (I didn't include the regenerated configure, you have to run autoconf within the libada directory). Thanks for the quick feedback. -- bonzini at gnu dot org changed: What|Removed |Added Attachment #12616|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29802
[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-11-14 19:45 --- Please apply this patch to 4.2 and the trunk. I've reverted my patch on the 4.1 branch, as it seems to be too risky there. Have you really done so? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug preprocessor/29836] New: Concatenation operator ## doesn't work with this: / ## /
To whom it may concern, I am trying to use the macro concatenation operator to make a conditional comment. I want a symbol that I can sprinkle throught my C code that will be replaced either be a C++ style // comment, or it will be replaced with nothing. This is useful for turning on and off debug messages and other debug code. The basic idea is to use the ## concatenation operator in a macro definition to paste two forward slash characters ('/') together to make a C++ style comment of the form //. I tried this on two other C compilers and it worked on them. One compiler is MinGW running on my PC which is gcc version 3.2.3 (mingw special 20030504-1). The other one is the latest Keil C compiler for the 8051 microcontroller. Both of these compiled the code as I expected them to. The problem is that the gcc compilers on our Sun system and on our HP Unix system give errors when I try to compile the same code. The HP Unix system has gcc version 3.4.3. The C code file (called t.c) is: #define DEBUG / ## /// disable debug code // #define DEBUG // / ## /// enable debug code int main ( void ) { int i ; DEBUG int j ; // DEBUG is either empty or // DEBUG j = i ; return ( 0 ) ; } The compiler error messages are: t.c:8:1: pasting / and / does not give a valid preprocessing token t.c:10:1: pasting / and / does not give a valid preprocessing token The output from the preprocessor (using the -E command line switch) is: int main ( void ) { int i ; / / int j ; / / j = i ; return ( 0 ) ; } I find it strange that the preprocessor puts a blank space between the two '/' characters. This looks like a bug to me. I don't think there should be a blank space between the characters. Sincerely, Michael Bishop [EMAIL PROTECTED] P.S. I know that there are many other ways to make conditional debug code, and I have tried several of them over the last 20 years. I am hoping that this method can be made to work in a portable way. -- Summary: Concatenation operator ## doesn't work with this: / ## / Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot bishop at gdcanada dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29836
[Bug c++/29704] [4.1 Regression] ICE: default non-type template argument of pointer-to-member type
--- Comment #3 from jens dot maurer at gmx dot net 2006-11-14 20:24 --- I agree with Wolfgang's interpretation of the standard, but can't see why it renders my original code invalid. 14.3.2/1 says that a constant expression that evaluates to a null member pointer value is allowed as a non-type template argument, with an explicit reference to 4.11, which explains how to obtain one (i.e. convert a null pointer constant, e.g. 0, to a pointer-to-member type). That's what my original example does. 14.3.2/5 then says The following conversions are performed on each expression used as a non-type template-argument. There are indeed no conversions performed for pointer-to-members, but the expression I supplied for the non-type template-argument was (void(C::*)(int))0, not just 0 (which would have required an implicit conversion, see 4.11). And no conversion is necessary to convert an expression of that type to the parameter's type, which is void(C::*)(int). (EDG appears to agree with me and accepts the code, FWIW.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29704
[Bug fortran/29820] ICE in fold_convert, at fold-const.c:2146
--- Comment #5 from pault at gcc dot gnu dot org 2006-11-14 21:08 --- The remark in #3 that the bug clears if the order of the procedures is reversed is a giveaway: Index: gcc/fortran/trans-types.c === *** gcc/fortran/trans-types.c (revision 118704) --- gcc/fortran/trans-types.c (working copy) *** gfc_get_derived_type (gfc_symbol * deriv *** 1592,1602 other_equal_dts: /* Add this backend_decl to all the other, equal derived types and their components in this and sibling namespaces. */ ! ! for (dt = derived-ns-derived_types; dt; dt = dt-next) ! copy_dt_decls_ifequal (derived, dt-derived); ! ! for (ns = derived-ns-sibling; ns; ns = ns-sibling) for (dt = ns-derived_types; dt; dt = dt-next) copy_dt_decls_ifequal (derived, dt-derived); --- 1592,1599 other_equal_dts: /* Add this backend_decl to all the other, equal derived types and their components in this and sibling namespaces. */ ! ns = derived-ns-parent ? derived-ns-parent-contained : derived-ns; ! for (; ns; ns = ns-sibling) for (dt = ns-derived_types; dt; dt = dt-next) copy_dt_decls_ifequal (derived, dt-derived); clears the problem by associated the derived types correctly. I had previously convinced myself that this scan across all the contained procedures was not necessary because it should by symmetric under the interchange of the namespaces. I need to understand why this is not so before submitting the patch. Richard, Could you explain in babytalk, please, what this does? gcc_assert (!AGGREGATE_TYPE_P (TREE_TYPE (lse-expr)) || TREE_TYPE (lse-expr) == TREE_TYPE (rse-expr)); gfc_add_modify_expr (block, lse-expr, !AGGREGATE_TYPE_P (TREE_TYPE (lse-expr)) ? fold_convert (TREE_TYPE (lse-expr), rse-expr) : rse-expr); Is it simply that the fold_convert is simply not doing anything here? ie. when lse and rse are not the same stuctures, having the fold_convert simply tosses the detection of the problem elsewhere? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29820
[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #18 from debian-gcc at lists dot debian dot org 2006-11-14 21:09 --- (In reply to comment #16) I've reverted my patch on the 4.1 branch, as it seems to be too risky there. afaics the patch is not yet reverted. Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
[Bug fortran/29821] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:666ans-types.c:666
--- Comment #4 from pault at gcc dot gnu dot org 2006-11-14 21:24 --- If the implicit none or the module ... end module is removed, the ICE goes away. Probably worth running using a non-optimized front-end under valgrind. or replacing a = sum (eps(i:i) * eps) by a = sum (eps * eps) a = sum (eps(1:1) * eps) a = sum (eps(i:i)) also remove the problem integer, parameter :: i = 1 and removing the assinment to i, does likewise. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29821
[Bug c++/29834] g++ thinks it is a declaration when it cannot be
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-14 21:33 --- I you use ( Doh ( x ) ), ++ x; it works. (EDG accepts the code unmodified) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
[Bug fortran/29821] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:666ans-types.c:666
--- Comment #5 from pault at gcc dot gnu dot org 2006-11-14 21:48 --- It gets better and better... module gfcbug45 implicit none contains subroutine foo integer :: i real:: a real, parameter :: eps(1) = (/ 1 /) i = 1 a = mysum (eps(i:i) * eps) end subroutine foo real function mysum (x) real :: x(:) mysum = sum(x) end function mysum end module gfcbug45 works just fine. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29821
Paypal to e-gold, StormPay to e-gold, Moneybookers - fees 5-10%
Exchange Service from Paypal to e-gold, from StormPay to e-gold, from Moneybookers to e-gold SERVICE FEES: PayPal to E-Gold: 5% - 10% StormPay to E-Gold: 5% - 10% Moneybookers to E-Gold: 4%-7% PayExchange.net www.PayExchange.net
[Bug preprocessor/29836] Concatenation operator ## doesn't work with this: / ## /
--- Comment #1 from neil at daikokuya dot co dot uk 2006-11-14 22:49 --- Subject: Re: New: Concatenation operator ## doesn't work with this: / ## / michael dot bishop at gdcanada dot com wrote:- I am trying to use the macro concatenation operator to make a conditional comment. I want a symbol that I can sprinkle throught my C code that will be replaced either be a C++ style // comment, or it will be replaced with nothing. There is no such thing as a conditional comment. Only Microsoft's preprocessor, broken in many ways, seems to support this (and those compilers that attempt to emulate MS). This has been discussed before; GCC will never support this. The compiler error messages are: t.c:8:1: pasting / and / does not give a valid preprocessing token t.c:10:1: pasting / and / does not give a valid preprocessing token This is correct. The output from the preprocessor (using the -E command line switch) is: int main ( void ) { int i ; / / int j ; / / j = i ; return ( 0 ) ; } I find it strange that the preprocessor puts a blank space between the two '/' characters. This looks like a bug to me. I don't think there should be a blank space between the characters. It's because the preprocessor is taking care to avoid creating something that looks like a comment, from two separate tokens. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29836
[Bug preprocessor/29836] Concatenation operator ## doesn't work with this: / ## /
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-14 22:51 --- Not a bug as explained by Neil. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29836
[Bug tree-optimization/29791] [4.3 Regression] ICE: tree check: expected ssa_name, have symbol_memory_tag in verify_ssa, at tree-ssa.c:776
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-14 22:55 --- Janis can you do a regression hunt on this bug? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29791
[Bug fortran/29837] New: INTERFACE overloading INTENT problem - valid code is rejected
Different INTENT parameters on the first argument of overloaded subroutines confuse the argument matching mechanism and a compiler error is generated for code that is correct. See attached testcase. The problem breaks my code and I see no workaround. I hope somebody can fix it before the release. -- Summary: INTERFACE overloading INTENT problem - valid code is rejected Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: enok at lysator dot liu dot se GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29837