[Bug c++/27114] New: inlining bug under optimization. (cast to reference)
The following code aligns and increments a pointer twice. I expect an offset of 8 with respect to the original address. Works as expected with an unoptimized build, but an an offset of 4 is reported when compiled with -O2. The problem seems to be the cast to (long&) before the arithmetic operations in the inline align() function. Removing the (in case of char*) unnecessary first cast will produce the correct output. --- begin code --- #include struct Test { char *p; }; inline void align(char* &p) { ((long &)p) += 3; ((long &)p) &= -4; } int main() { char buffer[8] = {0}; Test t = { buffer }; align(t.p); t.p += 4; align(t.p); t.p += 4; printf("%d\n", t.p - buffer); } --- end code --- --- begin output --- > g++ -v -Wall -O2 gcc-4-1-bug.cxx Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1.0/configure --prefix=/space/gcc-4.1.0 --enable-languages=c,c++ Thread model: posix gcc version 4.1.0 /space/gcc-4.1.0/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1plus -quiet -v -D_GNU_SOURCE gcc-4-1-bug.cxx -quiet -dumpbase gcc-4-1-bug.cxx -mtune=pentiumpro -auxbase gcc-4-1-bug -O2 -Wall -version -o /tmp/cc1idx2e.s ignoring nonexistent directory "/space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0 /space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/i686-pc-linux-gnu /space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/backward /usr/local/include /space/gcc-4.1.0/include /space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/include /usr/include End of search list. GNU C++ version 4.1.0 (i686-pc-linux-gnu) compiled by GNU C version 4.1.0. GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128169 Compiler executable checksum: 4ff5a0850335423f0b9670917725c57b as -V -Qy -o /tmp/ccK9mBVm.o /tmp/cc1idx2e.s GNU assembler version 2.16.91.0.2 (i586-suse-linux) using BFD version 2.16.91.0.2 20050720 (SuSE Linux) /space/gcc-4.1.0/libexec/gcc/i686-pc-linux-gnu/4.1.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/crtbegin.o -L. -L/usr/local/lib -L/space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0 -L/space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/../../.. /tmp/ccK9mBVm.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/crtend.o /usr/lib/crtn.o > ./a.out 4 --- end output --- -- Summary: inlining bug under optimization. (cast to reference) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot bonekaemper at rtsgroup dot net GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27114
[Bug pending/27092] Compiling a special asm-statment will fail if -O1 -fgcse is set.
--- Comment #2 from amodra at bigpond dot net dot au 2006-04-11 06:09 --- Current 4.0, 4.1, and mainline compile the testcase OK. -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27092
[Bug middle-end/24853] scheduling takes 40% or more time
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-04-11 06:06 --- Sorry, the patch doesn't seem to help at all. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
[Bug tree-optimization/27087] [4.1/4.2 regression] ICE in merge_alias_info
--- Comment #4 from law at redhat dot com 2006-04-11 05:56 --- Subject: Re: [4.1/4.2 regression] ICE in merge_alias_info On Sat, 2006-04-08 at 23:16 +, pinskia at gcc dot gnu dot org wrote: > > --- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-08 23:16 > --- > Confirmed, the ICE is during DOM. As I mentioned in the PR notes, the problem is tree-ssa-copy.c::may_propagate_copy allows copy propagations which are rejected by merge_alias_info. Specifically it allows copy propagating when the flow-sensitive alias information is not compatible. I'm not entirely sure the compatibility check in may_propagate_copy and merge_alias_info is correct. It seems to me that we want to verify that one is a subset of the other, not just that the two objects have intersecting flow sensitive information. Someone more familiar with this code should follow-up on that issue. My patch merely makes the two routines consistent in how they handle flow-sensitive alias information for copy propagations. Bootstrapped and regression tested on i686-pc-linux-gnu. --- Comment #5 from law at redhat dot com 2006-04-11 05:56 --- Created an attachment (id=11241) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11241&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27087
[Bug tree-optimization/27087] [4.1/4.2 regression] ICE in merge_alias_info
--- Comment #3 from law at redhat dot com 2006-04-11 05:41 --- The problem is that may_propagate_copy and merge_alias_info are inconsistent. ie, DOM properly calls may_propagate_copy to determine if a particular copy propagation is valid. may_propagate_copy returns true indicating the copy propagation is valid. However, when the copy propagation is performed and we reach merge_alias_info, merge_alias_info has an additional sanity check that causes it to fail. This really isn't a DOM problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27087
[Bug fortran/27112] Rejects to call a generic procedure by argument keywords.
--- Comment #2 from iguchi at coral dot t dot u-tokyo dot ac dot jp 2006-04-11 05:15 --- (In reply to comment #1) Intel does NOT agree with gfortran. I think such discussion is not fruitful. $ ifort --version ifort (IFORT) 9.0 20060222 Copyright (C) 1985-2006 Intel Corporation. All rights reserved. $ ifort test.f90 fortcom: Warning: test.f90, line 25: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [FOO2] use m2 --^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27112
[Bug target/18900] Don't use fp regs for mem moves without explicit use of fp
--- Comment #5 from =?ISO-8859-15?Q?=22Thomas_Bj=F6rkman_=28=C4S/EAB=29=22?= 2006-04-11 05:10 --- Subject: Re: Should be able to not use fp moves for functions that don't implicted use float points Hej ! How come the slogan on Bug target/18900 has changed from "ppc optimization non removable" to "Don't use fp regs for mem moves without explicit use of fp" ? When will it be corrected ? BR / Thomas Björkman -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18900
[Bug fortran/27112] Rejects to call a generic procedure by argument keywords.
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-04-11 05:02 --- Intel agrees with gfortran: fortcom: Error: foofoo.f90, line 25: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-spec. [FOO2] use m2 --^ fortcom: Error: foofoo.f90, line 24: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-spec. [FOO1] use m1 --^ compilation aborted for foofoo.f90 (code 1) Also Lahey checker agrees: Checking file SOURCE.F90. Checking program unit M1 at line 1. Checking program unit M2 at line 12. Checking program unit TEST at line 23. Line 25, file SOURCE.F90 use m2 | FATAL -- The arguments for procedures (FOO2) and (FOO1) allow references to the generic procedure to be ambiguous (see "Procedure Interfaces" in your Fortran 90 language reference). Encountered 1 error, 0 warnings in file SOURCE.F90. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27112
[Bug fortran/27113] New: TODO: Complex array constructors in tonto-2.2
Compiling tonto-2.2 reveals that structure components cannot be used in array constructors: subroutine complex_constructor type BASIS_TYPE character(len=512) :: label end type type(BASIS_TYPE), dimension(:), pointer :: var call read_library_data_((/var%label/)) end subroutine complex_constructor emits.. complex_constructor.f90: In function complex_constructor: complex_constructor.f90:1: fatal error: gfc_todo: Not Implemented: complex character array constructors compilation terminated. I am on to it Paul -- Summary: TODO: Complex array constructors in tonto-2.2 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: pault at gcc dot gnu dot org ReportedBy: pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27113
[Bug fortran/27112] New: Rejects to call a generic procedure by argument keywords.
In the following program, generic procedure "foo" can be distinguished between two procedure "foo1" and "foo2" by keywords of arguments. But gfortran cannot compile this source code and output the same message twice. I think it is wrong behavior. $ cat test.f90 module m1 implicit none interface foo module procedure foo1 end interface contains subroutine foo1(j) integer :: j end subroutine end module module m2 implicit none interface foo module procedure foo2 end interface contains subroutine foo2(i) integer :: i end subroutine end module program test use m1 use m2 implicit none call foo(j=3) end program $ gfortran --version GNU Fortran 95 (GCC) 4.2.0 20060129 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $ gfortran test.f90 In file test.f90:24 use m1 1 Error: Ambiguous interfaces 'foo1' and 'foo2' in generic interface 'foo' at (1) In file test.f90:24 use m1 1 Error: Ambiguous interfaces 'foo1' and 'foo2' in generic interface 'foo' at (1) -- Summary: Rejects to call a generic procedure by argument keywords. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: iguchi at coral dot t dot u-tokyo dot ac dot jp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27112
[Bug fortran/27096] Automatic charlen pointer array result produces and ICE
-- 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=27096
[Bug fortran/26257] internal compiler error: Segmentation fault, on function call with assumed shape array parameter
--- Comment #7 from pault at gcc dot gnu dot org 2006-04-11 04:42 --- Sorry, I forgot about closing out this one on 4.1. Fixed on trunk and 4.1. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26257
[Bug fortran/26257] internal compiler error: Segmentation fault, on function call with assumed shape array parameter
--- Comment #6 from pault at gcc dot gnu dot org 2006-04-11 04:40 --- Subject: Bug 26257 Author: pault Date: Tue Apr 11 04:40:33 2006 New Revision: 112848 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112848 Log: 2006-04-11 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26257 * trans-array.c (gfc_conv_expr_descriptor): Exclude calculation of the offset and data when se->data_not_needed is set. * trans.h: Include the data_not_need bit in gfc_se. * trans-intrinsic.c (gfc_conv_intrinsic_size): Set it for SIZE. 2006-04-11 Paul Thomas <[EMAIL PROTECTED]> * PR fortran/26257 gfortran.dg/auto_char_len_3.f90: New test Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/auto_char_len_3.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/fortran/trans.h branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26257
[Bug classpath/24481] SecureRandom.setSeed has no impact
--- Comment #6 from david at jpackage dot org 2006-04-11 04:34 --- I was saying something slightly different, since I did not test the program across multiple runs. I did test nextBytes() within the same program run, and this produced identical bytes with each successive call to nextBytes(). Checking the javadocs, I find: ``Note that this instance of SecureRandom has not been seeded... [but] [i]f a call is not made to setSeed, the first call to the nextBytes method will force the SecureRandom object to seed itself.'' Note that even though `new SecureRandom()' does not seed itself, any attempt to extract randomness will cause it to seed itself first before returning any bytes, so I believe the GNU implementation to be incorrect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481
[Bug target/25690] error: unrecognizable insn - failed to assign &a[1] if a is a struct
--- Comment #6 from peter dot jansen at aad dot gov dot au 2006-04-11 04:32 --- Its ok in gcc-3.4.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25690
[Bug classpath/24481] SecureRandom.setSeed has no impact
--- Comment #5 from csm at gnu dot org 2006-04-11 04:21 --- The original issue seems to be fixed; on gcj version `gcj (GCC) 4.2.0 20060410 (experimental)' I get this output from the `seed' testcase: > Byte difference in a seeded PRNG: 64 > Seed data: > 9c1185a5c5e9fc5461288977ee8f548b2258d3138bbc57e4cbe8b6a1d2c999ef6253e0a6e58196ae643db8559e6ba7c97214bd66197b97184d68e3b0654b David, are you saying that if you have a program like: > import java.security.SecureRandom; > > class sr > { > public static void main (String[] argv) throws Throwable > { > SecureRandom sr = new SecureRandom (); > byte[] b = new byte[64]; > sr.nextBytes (b); > for (int i = 0; i < b.length; i++) > { > System.out.print (b[i]); > System.out.print (' '); > } > System.out.println (); > } > } ...that you get the same output every time? If so, this is because our default SecureRandom isn't seeded when created. Ideally, we would try to use `/dev/random,' or some timing data to get a random seed. -- csm at gnu dot org changed: What|Removed |Added CC||david at jpackage dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481
[Bug c/26154] [4.2 Regression] OpenMP extensions to the C language is not documented
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-11 03:00 --- It should be something like what XLC does at: http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/topic/com.ibm.xlcpp8l.doc/compiler/ref/ruprpdir.htm#RUPRPDIR Which is actually much better than what is even in the current GCC docs which is nothing even at the toplevel of extensions that GCC supports. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-11 03:00:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26154
[Bug target/18900] Don't use fp regs for mem moves without explicit use of fp
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-11 02:49 --- Altivec can be done with -mno-altivec and it is not really a real pain because if you are going to use altivec registers in your program, you want to use them more rather than less. And for the functions you don't want explicit use of altivec, put them into a seperate file which does not compile with -maltivec (or compile that seperate file with -mno-altivec since some -mcpu=* enables altivec). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Don't use fp/vmx regs for |Don't use fp regs for mem |mem moves without explicit |moves without explicit use |use of fp/vmx |of fp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18900
[Bug target/25690] error: unrecognizable insn - failed to assign &a[1] if a is a struct
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-11 02:45 --- *** Bug 27110 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||peter dot jansen at aad dot ||gov dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25690
[Bug target/27110] gcc 4.1.0 mcore-unknown-elf-gcc internal compiler error in extract_insn, at recog.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-11 02:45 --- *** This bug has been marked as a duplicate of 25690 *** -- 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=27110
[Bug c/27110] gcc 4.1.0 mcore-unknown-elf-gcc internal compiler error in extract_insn, at recog.c
--- Comment #1 from peter dot jansen at aad dot gov dot au 2006-04-11 02:34 --- Created an attachment (id=11239) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11239&action=view) Here is the preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27110
[Bug c/27110] New: gcc 4.1.0 mcore-unknown-elf-gcc internal compiler error in extract_insn, at recog.c
when compiling newlib with mcore-unknown-elf-gcc (v4.1.0) I get an internal compiler error. Compiler configure line ../gcc-4.1.0/configure --target=mcore-unknown-elf --disable-libssp --enable-languages=c The command line that triggers the bug is mcore-unknown-elf-gcc -B/home/peter_jan/mcore/build-newlib/mcore-unknown-elf/big/newlib/ -isystem /home/peter_jan/mcore/build-newlib/mcore-unknown-elf/big/newlib/targ-include -isystem /home/peter_jan/mcore/newlib-1.14.0/newlib/libc/include -mbig-endian -DPACKAGE=\"newlib\" -DVERSION=\"1.14.0\" -I. -I../../../../../../newlib-1.14.0/newlib/libc/stdlib -O2 -fno-builtin -O2 -g -O2 -mbig-endian -c ../../../../../../newlib-1.14.0/newlib/libc/stdlib/dtoa.c --save-temps Here is the compiler output ../../../../../../newlib-1.14.0/newlib/libc/stdlib/dtoa.c: In function _dtoa_r: ../../../../../../newlib-1.14.0/newlib/libc/stdlib/dtoa.c:854: error: unrecognizable insn: (insn 167 166 168 18 ../../../../../../newlib-1.14.0/newlib/libc/stdlib/dtoa.c:287 (set (reg:SI 191) (const:SI (plus:SI (symbol_ref/f:SI ("*.LC3") [flags 0x2] ) (const_int 1 [0x1] -1 (nil) (nil)) ../../../../../../newlib-1.14.0/newlib/libc/stdlib/dtoa.c:854: internal compiler error: in extract_insn, at recog.c:2084 -- Summary: gcc 4.1.0 mcore-unknown-elf-gcc internal compiler error in extract_insn, at recog.c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peter dot jansen at aad dot gov dot au GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: mcore-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27110
[Bug target/18900] Don't use fp/vmx regs for mem moves without explicit use of fp/vmx
--- Comment #3 from amodra at bigpond dot net dot au 2006-04-11 02:10 --- The same issue applies to VMX (Altivec) registers. With lazy fp/vmx task switching, the first use of fp/vmx regs in a task can be expensive. -- amodra at bigpond dot net dot au changed: What|Removed |Added Summary|Should be able to not use fp|Don't use fp/vmx regs for |moves for functions that|mem moves without explicit |don't implicted use float |use of fp/vmx |point registers | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18900
[Bug tree-optimization/27109] Simplify "a - 10 > 150" into "a > 160" when range of a is known (in VRP or somewhere else)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27109
[Bug tree-optimization/27109] New: Simplify "a - 10 > 150" into "a > 160" when range of a is known (in VRP or somewhere else)
Kinda like PR 14490 but for the -fwrapv and unsigned cases: void bar (void); void foo (unsigned a) { if (a < 100) return; if (200 < a) return; if (a - 10 > 150) bar (); } -- Summary: Simplify "a - 10 > 150" into "a > 160" when range of a is known (in VRP or somewhere else) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27109
[Bug debug/21391] [3.4/4.0/4.1/4.2 Regression] referencing a type via a cast does not emit it for debug (feliminate-unused-debug-types)
--- Comment #6 from aldyh at gcc dot gnu dot org 2006-04-11 01:38 --- Patch that fixes the problem. http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00380.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21391
[Bug tree-optimization/27090] FRE does not look past previous type casts
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-11 01:33 --- So I talked to Daniel about this and he said a new Number value system or the tree combiner so basicially there is nothing can be done currently. Guess maybe it is time for you Richard to stop hacking on fowardprop and start hacking on a real tree combiner :) (I don't have time to do it any more). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||15459 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27090
[Bug tree-optimization/27090] FRE does not look past previous type casts
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-11 01:21 --- Just a note VN.2 should really have not been created (maybe there is no way around this because it is just equivalant to VN.0). This actually gets fixed by a real tree combiner since fold is able to "fix" up (int*)(unsigned*)intptr (or the C++ example). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27090
[Bug tree-optimization/27090] FRE does not look past previous type casts
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27090
[Bug c/27108] syntax error with same-name typedef and local variable using va_arg
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-11 01:06 --- This is not a bug as foo is now a variable decl and not a typedef one so "foo a;" would fail also. Now if this was C++ you could use ::foo to get the typedef version of foo but this is C and there is no way to access the other namespaces. In 4.1.0 and above the error message is now: t.c: In function 'pathological': t.c:12: error: expected specifier-qualifier-list before 'foo' -- 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=27108
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #27 from amodra at bigpond dot net dot au 2006-04-11 00:37 --- Sorry! My apologies for closing this bug without checking that the original problem had been fixed. I was focusing on the code generation problems. -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug c/27108] New: syntax error with same-name typedef and local variable using va_arg
When compiling this (after cpp): # 1 "test.c" # 1 "" # 1 "" # 1 "test.c" # 1 "/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/stdarg.h" 1 3 4 # 43 "/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/stdarg.h" 3 4 typedef __builtin_va_list __gnuc_va_list; # 105 "/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/stdarg.h" 3 4 typedef __gnuc_va_list va_list; # 2 "test.c" 2 typedef int foo; pathological(int a, ...) { int foo; va_list ap; __builtin_va_arg(ap,foo); } I get this error: test.c: In function `pathological': test.c:9: error: parse error before "foo" Removing the 'int foo' declaration in 'pathological' fixes the error. I'm not sure what to make of this; however, I would suspect that the variable named foo is preventing gcc from seeing the typedef named foo. -- Summary: syntax error with same-name typedef and local variable using va_arg Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jesuswaffle at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27108
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #26 from amodra at gcc dot gnu dot org 2006-04-11 00:36 --- Subject: Bug 26459 Author: amodra Date: Tue Apr 11 00:36:50 2006 New Revision: 112844 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112844 Log: PR target/26459 * config/rs6000/e500-double.h (SUB3TARGET_OVERRIDE_OPTIONS): Test rs6000_explicit_options.float_gprs. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/rs6000/e500-double.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #25 from amodra at gcc dot gnu dot org 2006-04-11 00:33 --- Subject: Bug 26459 Author: amodra Date: Tue Apr 11 00:33:29 2006 New Revision: 112843 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112843 Log: PR target/26459 * config/rs6000/e500-double.h (SUB3TARGET_OVERRIDE_OPTIONS): Test rs6000_explicit_options.float_gprs. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/e500-double.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug libfortran/27107] New: Make dependency on io/io.h broken
When revising libgfortran/io/io.h by itself, make does not recompile source files that include io.h causing erroneous builds. To get files recompiled that depend on io.h one must 'touch' the sourcefiles. -- Summary: Make dependency on io/io.h broken Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gno http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27107
[Bug bootstrap/27099] stage3 compare failure
--- Comment #4 from andy at trojanfoe dot servebeer dot com 2006-04-10 23:18 --- Thanks, I thought I had read that pretty well. Am I being stupid? Andy -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27099
[Bug tree-optimization/27105] ICE with -O3 -ftree-loop-linear
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-10 20:49 --- Yes, it is known that -ftree-loop-linear is buggy. There might already be a dup of this bug too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27105
[Bug tree-optimization/27105] ICE with -O3 -ftree-loop-linear
--- Comment #1 from micis at gmx dot de 2006-04-10 20:33 --- Created an attachment (id=11238) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11238&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27105
[Bug tree-optimization/27105] New: ICE with -O3 -ftree-loop-linear
I tried the last (gcc-4.2-20060408) snapshot. When I compile the preprocessed source t.ii the compiler segfaults. /usr/local/gcc42h/bin/g++42h -O3 -ftree-loop-linear -S t.ii g++42h -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.2-20060408/configure --prefix=/usr/local/gcc42h --program-suffix=42h --with-arch=opteron --enable-languages=c,c++ --enable-__cxa_atexit --disable-nls --enable-threads=posix --disable-multilib --enable-checking Thread model: posix gcc version 4.2.0 20060408 (experimental) using gdb I got this call stack: #0 is_gimple_min_invariant (t=0x0) at ../../gcc-4.2-20060408/gcc/tree-gimple.c:172 #1 0x005df0d8 in expr_invariant_in_loop_p (loop=0x1315790, expr=0x0) at ../../gcc-4.2-20060408/gcc/tree-ssa-loop-ivopts.c:1303 #2 0x005df15e in expr_invariant_in_loop_p (loop=0x1315790, expr=0x2a99c12690) at ../../gcc-4.2-20060408/gcc/tree-ssa-loop-ivopts.c:1321 #3 0x005df15e in expr_invariant_in_loop_p (loop=0x1315790, expr=0x2a99c12620) at ../../gcc-4.2-20060408/gcc/tree-ssa-loop-ivopts.c:1321 #4 0x005df15e in expr_invariant_in_loop_p (loop=0x1315790, expr=0x2a9ba1b300) at ../../gcc-4.2-20060408/gcc/tree-ssa-loop-ivopts.c:1321 #5 0x00989e65 in can_put_in_inner_loop (inner=0x1315790, stmt=0x2a9e90c780) at ../../gcc-4.2-20060408/gcc/lambda-code.c:2175 #6 0x0098b3d8 in can_convert_to_perfect_nest (loop=0x13156d0, loopivs=0x11eced0) at ../../gcc-4.2-20060408/gcc/lambda-code.c:2268 #7 0x0098b7d6 in perfect_nestify (loops=0xed7470, loop=0x13156d0, lbounds=0x12a8310, ubounds=0x12c5f20, steps=0x12b9760, loopivs=0x11eced0) at ../../gcc-4.2-20060408/gcc/lambda-code.c:2362 #8 0x0098d276 in gcc_loopnest_to_lambda_loopnest (currloops=0xed7470, loop_nest=0x13156d0, inductionvars=0x7fbfffe258, invariants=0x7fbfffe250, need_perfect_nest=1 '\001') at ../../gcc-4.2-20060408/gcc/lambda-code.c:1494 #9 0x00889277 in linear_transform_loops (loops=0xed7470) at ../../gcc-4.2-20060408/gcc/tree-loop-linear.c:322 #10 0x005b7345 in tree_linear_transform () at ../../gcc-4.2-20060408/gcc/tree-ssa-loop.c:228 #11 0x008843bb in execute_one_pass (pass=0xc5f660) at ../../gcc-4.2-20060408/gcc/passes.c:863 #12 0x0088452c in execute_pass_list (pass=0xc5f660) at ../../gcc-4.2-20060408/gcc/passes.c:910 #13 0x0088453e in execute_pass_list (pass=0xc5f480) at ../../gcc-4.2-20060408/gcc/passes.c:911 #14 0x0088453e in execute_pass_list (pass=0xc5eac0) at ../../gcc-4.2-20060408/gcc/passes.c:911 #15 0x0055c047 in tree_rest_of_compilation (fndecl=0x2a966e3000) at ../../gcc-4.2-20060408/gcc/tree-optimize.c:418 #16 0x004d2aa8 in expand_body (fn=0x2a966e3000) at ../../gcc-4.2-20060408/gcc/cp/semantics.c:3012 #17 0x008d34c6 in cgraph_expand_function (node=0x2a9b2596c0) at ../../gcc-4.2-20060408/gcc/cgraphunit.c:1102 #18 0x008d5bbe in cgraph_optimize () at ../../gcc-4.2-20060408/gcc/cgraphunit.c:1167 #19 0x0047f635 in cp_finish_file () at ../../gcc-4.2-20060408/gcc/cp/decl2.c:3147 #20 0x0053140a in c_common_parse_file (set_yydebug=Variable "set_yydebug" is not available. ) at ../../gcc-4.2-20060408/gcc/c-opts.c:1165 #21 0x00855ce8 in toplev_main (argc=Variable "argc" is not available. I tried to delta-debug but after removing the preprocessor comments I got: internal compiler error: verify_cgraph_node failed So I decided to attach the original preprocessed source. Michael Cieslinski -- Summary: ICE with -O3 -ftree-loop-linear Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: micis at gmx dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27105
[Bug target/25671] test_bit() compilation does not expand to "bt" instruction
--- Comment #3 from steven at gcc dot gnu dot org 2006-04-10 20:31 --- This is what the i386 machine description has to say about BT and friends: ;; %%% bts, btr, btc, bt. ;; In general these instructions are *slow* when applied to memory, ;; since they enforce atomic operation. When applied to registers, ;; it depends on the cpu implementation. They're never faster than ;; the corresponding and/ior/xor operations, so with 32-bit there's ;; no point. But in 64-bit, we can't hold the relevant immediates ;; within the instruction itself, so operating on bits in the high ;; 32-bits of a register becomes easier. ;; ;; These are slow on Nocona, but fast on Athlon64. We do require the use ;; of btrq and btcq for corner cases of post-reload expansion of absdf and ;; negdf respectively, so they can never be disabled entirely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25671
[Bug target/25671] test_bit() compilation does not expand to "bt" instruction
--- Comment #2 from steven at gcc dot gnu dot org 2006-04-10 20:18 --- The resulting code for -march=opteron: test_bit: .LFB2: leal63(%rsi), %edx testl %esi, %esi movl%esi, %eax cmovns %esi, %edx sarl$31, %eax shrl$26, %eax sarl$6, %edx leal(%rsi,%rax), %ecx movslq %edx,%rdx andl$63, %ecx subl%eax, %ecx movl$1, %eax sall%cl, %eax cltq testq %rax, (%rdi,%rdx,8) setne %al movzbl %al, %eax ret For -march=nocona the code is even uglier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25671
[Bug target/7625] gcc pessimized 64-bit % operator on hppa2.0
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-04-10 20:17 --- Subject: Re: gcc pessimized 64-bit % operator on hppa2.0 > Boooiinngg... > > Or, is anyone working on this? I'm not. Note that the HP code is using 64-bit registers and instructions in 32-bit mode for the call to $$rem2. I think doing this in GCC is going to be tricky as normal calls only save the the least significant 32-bits. Maybe we could somehow confine 64-bit register values to the call clobbered registers. Normally register pairs are used for 64-bit values. In 64-bit mode, we can probably easily benefit from using the new 64-bit millicode. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7625
[Bug target/26778] [4.0/4.1/4.2 regression] GCC4 moves the result of a conditional block through inadequate registers
--- Comment #4 from steven at gcc dot gnu dot org 2006-04-10 19:57 --- GCC 3.4 did better, said the reporter in comment #0. -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|GCC4 moves the result of a |[4.0/4.1/4.2 regression] |conditional block through |GCC4 moves the result of a |inadequate registers|conditional block through ||inadequate registers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
[Bug target/7625] gcc pessimized 64-bit % operator on hppa2.0
--- Comment #4 from steven at gcc dot gnu dot org 2006-04-10 19:49 --- Boooiinngg... Or, is anyone working on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7625
[Bug java/27104] static final variable not being tracked as being set correctly
--- Comment #3 from vnasardinov at gmail dot com 2006-04-10 19:15 --- Thanks. It would help to have the words "definite assignment" and/or "definitely unassigned" and/or http://java.sun.com/docs/books/jls/third_edition/html/defAssign.html somewhere in the summary or comments, so people can find it before filing duplicates. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27104
[Bug java/24835] gcj accepts invalid code with static final variables
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-10 19:04 --- *** Bug 27104 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||vnasardinov at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24835
[Bug java/27104] static final variable not being tracked as being set correctly
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-10 19:04 --- And I already filed this once before too :). Anyways this is a dup of bug 24835. *** This bug has been marked as a duplicate of 24835 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|libgcj |java Keywords||accepts-invalid Resolution||DUPLICATE Summary|definite assingment bug in |static final variable not |GCJ |being tracked as being set ||correctly http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27104
[Bug libgcj/27104] definite assingment bug in GCJ
--- Comment #1 from vnasardinov at gmail dot com 2006-04-10 19:02 --- Created an attachment (id=11237) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11237&action=view) the test case This comes from http://www.javapuzzlers.com/java-puzzlers.zip with minor modifications. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27104
[Bug libgcj/27104] New: definite assingment bug in GCJ
All of the compiler versions are the same as in bug 27101. Sun's compiler: | $ javac UnwelcomeGuest.java | UnwelcomeGuest.java:9: variable USER_ID might already have been assigned | USER_ID = GUEST_USER_ID; | ^ | 1 error The Eclipse compiler: | $ ecj UnwelcomeGuest.java | -- | 1. ERROR in UnwelcomeGuest.java | (at line 9) | USER_ID = GUEST_USER_ID; | ^^^ | The final field USER_ID may already have been assigned | -- | 1 problem (1 error) GCJ: | $ gcj -C UnwelcomeGuest.java | $ echo $? | 0 Will attach the test case momentarily. -- Summary: definite assingment bug in GCJ Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vnasardinov at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27104
[Bug tree-optimization/27103] [4.2 Regression] ICE: tree check: expected ssa_name, have symbol_memory_tag in is_old_name, at tree-into-ssa.c:466
--- Comment #3 from debian-gcc at lists dot debian dot org 2006-04-10 18:53 --- (In reply to comment #2) > This works with "4.2.0 20060409". Hmm. I get the ICE with 4.2.0 20060407. Will try a newer one... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27103
[Bug tree-optimization/27103] [4.2 Regression] ICE: tree check: expected ssa_name, have symbol_memory_tag in is_old_name, at tree-into-ssa.c:466
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-10 18:45 --- This works with "4.2.0 20060409". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27103
[Bug tree-optimization/27103] [4.2 Regression] ICE: tree check: expected ssa_name, have symbol_memory_tag in is_old_name, at tree-into-ssa.c:466
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ICE: tree check: expected |[4.2 Regression] ICE: tree |ssa_name, have |check: expected ssa_name, |symbol_memory_tag in|have symbol_memory_tag in |is_old_name, at tree-into- |is_old_name, at tree-into- |ssa.c:466 |ssa.c:466 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27103
[Bug tree-optimization/27103] ICE: tree check: expected ssa_name, have symbol_memory_tag in is_old_name, at tree-into-ssa.c:466
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-10 18:43 --- Related to PR 26490. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||26490 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27103
[Bug tree-optimization/27103] New: ICE: tree check: expected ssa_name, have symbol_memory_tag in is_old_name, at tree-into-ssa.c:466
[ forwarded from http://bugs.debian.org/361814 ] [EMAIL PROTECTED]:/tmp% cat test.c typedef struct { int size; } gnutls_datum; typedef struct gnutls_cert { gnutls_datum raw; } gnutls_cert; typedef struct { } gnutls_privkey; int _gnutls_log_level; void _gnutls_log(void); void _gnutls_write_datum24(char*, gnutls_datum); void _gnutls_gen_x509_crt (gnutls_cert *apr_cert_list, char *pdata) { if (_gnutls_log_level) _gnutls_log(); _gnutls_write_datum24(pdata, apr_cert_list->raw); pdata += apr_cert_list->raw.size; } [EMAIL PROTECTED]:/tmp% gcc -c -O test.c [EMAIL PROTECTED]:/tmp% gcc-4.1 -c -O2 test.c [EMAIL PROTECTED]:/tmp% gcc -c -O2 test.c test.c: In function '_gnutls_gen_x509_crt': test.c:10: internal compiler error: tree check: expected ssa_name, have symbol_memory_tag in verify_ssa, at tree-ssa.c:776 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Falk -- Summary: ICE: tree check: expected ssa_name, have symbol_memory_tag in is_old_name, at tree-into-ssa.c:466 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27103
[Bug java/27101] GCJ rejects valid code (for Sun's measure of "valid')
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-10 18:24 --- (In reply to comment #2) > Tom Fitzsimmons stopped complaining about my pipe-quoting technique > after I told him about "M-x delete-rectangle" a.k.a. "C-x r d". Takes > about 5 seconds in Emacs to fix this up. One, if you type really fast :) > Thanks for looking at this. Who uses emacs, I am serious, I don't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27101
[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.
--- Comment #13 from sje at cup dot hp dot com 2006-04-10 18:22 --- Putting the size of pad back seems OK on IA64 in both ILP32 and LP64 modes. In ILP32 mode I get: The DTP Size of p: 136 Size of pad: 200 Size of char *: 4 Size if int: 4 In LP64 mode, both on HP-UX and Linux, I get: The DTP Size of p: 168 Size of pad: 264 Size of char *: 8 Size if int: 4 So we have space without changing the size of pad and by putting pad back to the original size I do get programs to work but the alignment problem described in comment #11 is still there waiting to hit at any time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26890
[Bug tree-optimization/27090] FRE does loop past previous type casts
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-10 18:12 --- Well really more like: int f(int *a) { int t = *a; unsigned *b = (unsigned *)a; int *c = (int*)b; return *c + t; } Which should be the same as: int f(int *a) { return *a * 2; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27090
[Bug java/27101] GCJ rejects valid code (for Sun's measure of "valid')
--- Comment #2 from vnasardinov at gmail dot com 2006-04-10 18:12 --- Tom Fitzsimmons stopped complaining about my pipe-quoting technique after I told him about "M-x delete-rectangle" a.k.a. "C-x r d". Takes about 5 seconds in Emacs to fix this up. One, if you type really fast :) Thanks for looking at this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27101
[Bug bootstrap/26066] disable-threads causes undefined reference to pthread_kill and pthread_sigmask
--- Comment #2 from polite at itd dot nrl dot navy dot mil 2006-04-10 17:25 --- I tried the same thing with gcc 4.1.0 and I got the same result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26066
[Bug target/27076] During installation of gcc-3.4.0 compiler getting an error "make[1]: *** [getpwd.o] Error 1"
--- Comment #5 from sagar dot indalkar at ge dot com 2006-04-10 16:49 --- Hi, Thanks for quick response. I am not installing Fortran compiler, I am only installing the gcc compiler. After your mail I have tried running the make command. make command still giving the error. The error is as follows. gcc -c -DHAVE_CONFIG_H -g -I. -I../../gcc-4.0.3/libiberty/../include -W -Wall -Wtraditional -pedantic ../../gcc-4.0.3/libiberty/getpwd.c -o getpwd.o ../../gcc-4.0.3/libiberty/getpwd.c: In function `getpwd': ../../gcc-4.0.3/libiberty/getpwd.c:77: storage size of `dotstat' isn't known ../../gcc-4.0.3/libiberty/getpwd.c:77: storage size of `pwdstat' isn't known ../../gcc-4.0.3/libiberty/getpwd.c:81: warning: implicit declaration of function `getenv' ../../gcc-4.0.3/libiberty/getpwd.c:81: warning: assignment makes pointer from integer without a cast ../../gcc-4.0.3/libiberty/getpwd.c:83: warning: implicit declaration of function `stat' ../../gcc-4.0.3/libiberty/getpwd.c:89: warning: implicit declaration of function `getcwd' ../../gcc-4.0.3/libiberty/getpwd.c:92: warning: implicit declaration of function `free' ../../gcc-4.0.3/libiberty/getpwd.c:77: warning: unused variable `dotstat' ../../gcc-4.0.3/libiberty/getpwd.c:77: warning: unused variable `pwdstat' make[1]: *** [getpwd.o] Error 1 make[1]: Leaving directory `/var/build/gcc-4.0.3-build/libiberty' make: *** [all-libiberty] Error 2 Could you please let me know what is the problem because for gcc version 3.4.0 I was getting almost same error. Is there anyway to resolve the error? This problem is preventing my project work. Thanks in advance Regards, Sagar -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27076
[Bug fortran/27089] Module procedure with explicit result does not pass type to specification expression.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-10 16:41:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27089
[Bug target/27076] During installation of gcc-3.4.0 compiler getting an error "make[1]: *** [getpwd.o] Error 1"
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-10 16:40 --- That error should not effect compiling of GCC unless you need a fortran compiler and then you need to read: http://gcc.gnu.org/install/ AND: http://gcc.gnu.org/install/prerequisites.html People build all the time on x86-linux-gnu so we know building is not broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27076
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-04-10 16:35 --- *** Bug 27085 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug tree-optimization/27085] [4.2 regression] ICE in add_virtual_operand
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-10 16:35 --- It is a dup, Daniel asked me yesterday to close it as one but I did not get around to it til today. *** This bug has been marked as a duplicate of 26626 *** -- 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=27085
[Bug c++/27100] ICE with multiple friend declarations
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-10 16:34 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-10 16:34:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27100
[Bug java/27101] GCJ rejects valid code (for Sun's measure of "valid')
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-10 16:30 --- Please next time if you going to put the testcase inline don't put stuff in front of the testcase so it can be easy to access. Anyways confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|libgcj |java Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2006-04-10 16:30:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27101
[Bug c/11813] make -fexceptions default for c and objective-c
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-04-10 16:28 --- *** Bug 27098 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mlazar at kma dot zcu dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11813
[Bug c++/27098] throw cause terminate() instead of catch
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-10 16:28 --- *** This bug has been marked as a duplicate of 11813 *** -- 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=27098
[Bug c++/27094] [4.0/4.1/4.2 Regression] tree check: expected tree_list, have omp_return in build_call
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-10 16:22 --- Here is another testcase (which was reduced from the same source and gives a similar error message but does not have inheritance in it): template struct allocator { ~allocator() throw() { } }; struct list { allocator _M_impl; }; template struct stack { stack(const list& __c = list()); }; stack <1> a; -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|x86_64-linux-gnu| GCC host triplet|x86_64-linux-gnu| GCC target triplet|x86_64-linux-gnu| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27094
[Bug bootstrap/27099] stage3 compare failure
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-04-10 15:55 --- > config.status: creating libada-mk > config.status: creating auto-host.h > config.status: executing default commands > Bootstrapping the compiler > gmake[1]: Entering directory `/tmp/gcc-4.1.0/gcc' > gmake[1]: *** No rule to make target `bootstrap'. Stop. > gmake[1]: Leaving directory `/tmp/gcc-4.1.0/gcc' > gmake: *** [bootstrap] Error 2 http://gcc.gnu.org/install/configure.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27099
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #14 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-04-10 15:53 --- Subject: Re: IVs with the same evolution not eliminated > I wonder if it helps placing this between cunroll and ivopts... > > void foo(int n, int m, int stridex, int stridey, int stridex2, int stridey2, > double *x, double *y) > { > for (int k=0; k for (int j=0; j for (int i=0; i<2; ++i) > x[i + stridex*j + stridex2*k] = y[i + stridey*j + stridey2*k]; > } > > producing better IV selection than what we get now. ivopts do not care (they will recognize that the two array references have the same offsets). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #24 from edmar at freescale dot com 2006-04-10 15:42 --- I am sorry, but the patches on comments 17, 18, 21, and 22 are no good without the patch on comment 5, which seems, it was never commited into the repository... Can you double check this. Thanks. Edmar -- edmar at freescale dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-04-10 15:31 --- I wonder if it helps placing this between cunroll and ivopts... void foo(int n, int m, int stridex, int stridey, int stridex2, int stridey2, double *x, double *y) { for (int k=0; khttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto
--- Comment #14 from paul dot richard dot thomas at cea dot fr 2006-04-10 15:07 --- (In reply to comment #13) > PR23634 does not affect this PR. So only two bugs left. I checked by > commenting out the lines effecting compiling. I have submitted 2 PRs for tonto-2.2; PR25597 and PR27096. The first I have submitted a patch for and the patch for the second will be submitted tonight. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
[Bug c++/27102] [4.0/4.1/4.2 regression] ICE with invalid class name in function template
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-04-10 15:03 --- Btw, the ICE is a segfault on the 4.0 branch. On the 4.1 branch and mainline we get: bug.cc:2: internal compiler error: in is_ancestor, at cp/name-lookup.c: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
[Bug c++/27102] [4.0/4.1/4.2 regression] ICE with invalid class name in function template
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-04-10 15:01 --- Confirmed. We had a similar problem with template classes in PR18731. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Severity|critical|normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code, ||monitored Last reconfirmed|-00-00 00:00:00 |2006-04-10 15:01:31 date|| Summary|Semgmentation Fault on |[4.0/4.1/4.2 regression] ICE |Template|with invalid class name in ||function template Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
[Bug c++/27102] New: Semgmentation Fault on Template
gcc gives segmenation fault on the following code: template void T::foo() { } -- Summary: Semgmentation Fault on Template Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mmirzaza at cs dot uwaterloo dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
[Bug fortran/27096] Automatic charlen pointer array result produces and ICE
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-04-10 14:48 --- A patch (not regtested yet, nor tested on tonto) and testcase for this and PR25597: Index: gcc/fortran/trans-decl.c === --- gcc/fortran/trans-decl.c(révision 112529) +++ gcc/fortran/trans-decl.c(copie de travail) @@ -2536,6 +2536,12 @@ { tree result = TREE_VALUE (current_fake_result_decl); fnbody = gfc_trans_dummy_array_bias (proc_sym, result, fnbody); + + /* An automatic character length, pointer array result. */ + if (proc_sym->ts.type == BT_CHARACTER + && TREE_CODE (proc_sym->ts.cl->backend_decl) == VAR_DECL) + fnbody = gfc_trans_dummy_character (proc_sym, proc_sym->ts.cl, + fnbody); } else if (proc_sym->ts.type == BT_CHARACTER) { Index: gcc/fortran/trans-array.c === --- gcc/fortran/trans-array.c (révision 112529) +++ gcc/fortran/trans-array.c (copie de travail) @@ -4385,7 +4385,14 @@ /* Get the descriptor type. */ type = TREE_TYPE (sym->backend_decl); - gcc_assert (GFC_DESCRIPTOR_TYPE_P (type)); + if (!GFC_DESCRIPTOR_TYPE_P (type)) +{ + /* If the backend_decl is not a descriptor, we must have a pointer +to one. */ + descriptor = build_fold_indirect_ref (sym->backend_decl); + type = TREE_TYPE (descriptor); + gcc_assert (GFC_DESCRIPTOR_TYPE_P (type)); +} /* NULLIFY the data pointer. */ gfc_conv_descriptor_data_set (&fnblock, descriptor, null_pointer_node); ! { dg-do run } ! Tests the fixes for PR25597 and PR27096. ! ! This test combines the PR testcases. ! character(10), dimension (2) :: implicit_result character(10), dimension (2) :: explicit_result character(10), dimension (2) :: source source = "abcdefghij" explicit_result = join_1(source) if (any (explicit_result .ne. source)) call abort () implicit_result = reallocate_hnv (source, size(source, 1), LEN (source)) if (any (implicit_result .ne. source)) call abort () contains ! This function would cause an ICE in gfc_trans_deferred_array. function join_1(self) result(res) character(len=*), dimension(:) :: self character(len=len(self)), dimension(:), pointer :: res allocate (res(2)) res = self end function ! This function originally ICEd and latterly caused a runtime error. FUNCTION reallocate_hnv(p, n, LEN) CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: reallocate_hnv character(*), dimension(:) :: p ALLOCATE (reallocate_hnv(n)) reallocate_hnv = p END FUNCTION reallocate_hnv end Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27096
[Bug fortran/25597] ICE with allocate on the return value of a function, character array with a len of an argument
--- Comment #6 from paul dot richard dot thomas at cea dot fr 2006-04-10 14:35 --- (In reply to comment #5) > (In reply to comment #4) > > A little further reduced: > Actually that is a different bug. > Anyways the reduced testcase looks like: > FUNCTION reallocate_hnv(p,n,LEN) > CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: reallocate_hnv > ALLOCATE(reallocate_hnv(n)) > END FUNCTION reallocate_hnv This no longer ICEs but does bomn out in runtime, as described in PR27096 Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25597
[Bug fortran/27096] Automatic charlen pointer array result produces and ICE
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-04-10 14:19 --- The peculiar code turns out to be a result of the way in which I kludged my way past the ICE. In sorting the out, I found that there is a double fault: The implicit result version of the above character(10), dimension (2) :: inp inp = "abcdefghij" inp = join_1(inp) print *, inp contains function join_1(self) character(len=*), dimension(:) :: self character(len=len(self)), dimension(:), pointer :: join_1 allocate (join_1(2)) join_1 = self end function end compiles but hits the runtime error: Fortran runtime error: Attempt to allocate negative amount of memory. Possible integer overflow. I must check that this is not an existing PR. A double patch is on its way. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27096
[Bug c++/26660] [4.2 Regression] PCH vs -save-temps, ICE while GCing
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-04-10 13:58 --- Confirmed. One can also use the following for t1.cc: = #include "t.hh" void foo() {} = -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-10 13:58:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26660
[Bug libgcj/27101] New: GCJ rejects valid code (for Sun's measure of "valid')
This is probably a duplicate of something that has been filed before, but my cursory search failed to turn up any similar tickets. GCJ rejects code that both Sun and Eclipse compilers accept. Here's the test case: | $ cat Reluctant.java | public class Reluctant { | private Reluctant internalInstance = new Reluctant(); | | public Reluctant() throws Exception { | throw new Exception("I'm not coming out"); | } | | public static void main(String[] args) { | try { | Reluctant b = new Reluctant(); | System.out.println("Surprise!"); | } catch (Exception ex) { | System.out.println("I told you so"); | } | } | } The test comes from http://www.javapuzzlers.com/java-puzzlers.zip Here's what I'm using | $ gcj -v | Using built-in specs. | Reading specs from /usr/lib/gcc/x86_64-redhat-linux/4.1.0/libgcj.spec | rename spec lib to liborig | Target: x86_64-redhat-linux | Configured with: ../configure --prefix=/usr --mandir=/usr/share/man \ | --infodir=/usr/share/info --enable-shared --enable-threads=posix \ | --enable-checking=release --with-system-zlib --enable-__cxa_atexit \ | --disable-libunwind-exceptions --enable-libgcj-multifile \ | --enable-languages=c,c++,objc,obj-c++,java,fortran,ada \ | --enable-java-awt=gtk --disable-dssi \ | --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre \ | --with-cpu=generic --host=x86_64-redhat-linux | | Thread model: posix | gcc version 4.1.0 20060304 (Red Hat 4.1.0-3) Here's the compilation error the above code triggers: | $ gcj -C Reluctant.java | Reluctant.java: In class 'Reluctant': | Reluctant.java: In method 'finit$()': | Reluctant.java:2: error: Exception $-1òøjava.lang.Exceptionòù can't be thrown in initializer. | private Reluctant internalInstance = new Reluctant(); | ^ | 1 error Here's what the Eclipse compiler has to say: | $ ecj -v | Eclipse Java Compiler v_585_R31x, 3.1.2 release, Copyright IBM Corp 2000, 2006. All rights reserved. | $ ecj Reluctant.java | -- | 1. WARNING in Reluctant.java | (at line 2) | private Reluctant internalInstance = new Reluctant(); | | The field Reluctant.internalInstance is never read locally | -- | -- | 2. WARNING in Reluctant.java | (at line 10) | Reluctant b = new Reluctant(); | ^ | The local variable b is never read | -- | 2 problems (2 warnings) No errors. Same with Sun's javac: | $ javac -version 2>&1 | head -n1 | javac 1.5.0_06 | $ javac -Xlint Reluctant.java | $ echo $? | 0 -- Summary: GCJ rejects valid code (for Sun's measure of "valid') Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vnasardinov at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27101
[Bug c++/27100] New: ICE with multiple friend declarations
The compiler segfaults on the following valid code snippet when invoked with "g++ --param ggc-min-expand=0 --param ggc-min-heapsize=0": struct A { friend void foo() {} friend void foo(); }; The error message on mainline is: bug.cc:4: warning: 'void foo()' is already a friend of class 'A' bug.cc:4: internal compiler error: Segmentation fault Please submit a full bug report, [etc.] This happens since the two command line parameters were introduced (GCC 3.3). -- Summary: ICE with multiple friend declarations Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, monitored, GC Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27100
[Bug debug/27057] [4.0/4.1/4.2 Regression] ICE with -feliminate-dwarf2-dups and using namespace
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-10 13:21 --- Subject: Bug 27057 Author: jakub Date: Mon Apr 10 13:21:13 2006 New Revision: 112821 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112821 Log: PR debug/27057 * dwarf2out.c (is_symbol_die): Return true also for namespaces. * g++.dg/debug/dwarf2-2.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/debug/dwarf2-2.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/dwarf2out.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27057
[Bug debug/27057] [4.0/4.1/4.2 Regression] ICE with -feliminate-dwarf2-dups and using namespace
--- Comment #1 from jakub at gcc dot gnu dot org 2006-04-10 13:18 --- Subject: Bug 27057 Author: jakub Date: Mon Apr 10 13:18:19 2006 New Revision: 112820 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112820 Log: PR debug/27057 * dwarf2out.c (is_symbol_die): Return true also for namespaces. * g++.dg/debug/dwarf2-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27057
[Bug libfortran/24685] real(16) formatted input is broken for huge values
--- Comment #16 from jakub at gcc dot gnu dot org 2006-04-10 12:02 --- Subject: Bug 24685 Author: jakub Date: Mon Apr 10 12:02:55 2006 New Revision: 112819 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112819 Log: PR libgfortran/24685 * io/write.c (MIN_FIELD_WIDTH, STR, STR1): Define. (output_float): Increase buffer sizes for IEEE quad and IBM extended long double. (write_real): Output REAL(16) as 1PG43.34E4 rather than 1PG40.31E4. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug bootstrap/27099] stage3 compare failure
--- Comment #2 from andy at trojanfoe dot servebeer dot com 2006-04-10 12:01 --- If I configure without "--enable-bootstrap" I get this error quite early on during the build: config.status: creating libada-mk config.status: creating auto-host.h config.status: executing default commands Bootstrapping the compiler gmake[1]: Entering directory `/tmp/gcc-4.1.0/gcc' gmake[1]: *** No rule to make target `bootstrap'. Stop. gmake[1]: Leaving directory `/tmp/gcc-4.1.0/gcc' gmake: *** [bootstrap] Error 2 -- andy at trojanfoe dot servebeer dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27099
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-04-10 11:56 --- So it is indeed chicken and egg ;) load-PRE does not PRE the loads if the loop is not in do-while form, and we won't hoist the loop header copies until the loads are PREd. As to comment #13, if we are able to "clean" the two innermost loops of a nest that is already a good improvement. Though from all the experiments it looks like it is advisable to write do-while loops with hoisted loop header copies manually rather than for loops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
[Bug tree-optimization/27085] [4.2 regression] ICE in add_virtual_operand
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-04-10 11:54 --- Probably related to PR 26626. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27085
[Bug target/27076] During installation of gcc-3.4.0 compiler getting an error "make[1]: *** [getpwd.o] Error 1"
--- Comment #3 from sagar dot indalkar at ge dot com 2006-04-10 11:46 --- Hi, As per suggestion given, I have downloaded the gcc compiler version 4.0.3 and uploaded to the box. When started configuring the using the command given below. ../gcc-4.0.3/configure --prefix=/usr/bin/gcc-4.0.3 I was getting error as follows. configure:2271: gcc -c -g conftest.c 1>&5 configure:2261:17: gmp.h: No such file or directory configure: In function `main': configure:2265: `choke' undeclared (first use in this function) configure:2265: (Each undeclared identifier is reported only once configure:2265: for each function it appears in.) configure:2265: parse error before "me" configure: failed program was: #line 2260 "configure" #include "confdefs.h" #include "gmp.h" int main() { #if __GNU_MP_VERSION < 3 choke me #endif ; return 0; } For more details I have attached config.log file. Thanks in advance Regards, Sagar -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27076
[Bug target/27076] During installation of gcc-3.4.0 compiler getting an error "make[1]: *** [getpwd.o] Error 1"
--- Comment #2 from sagar dot indalkar at ge dot com 2006-04-10 11:45 --- Created an attachment (id=11236) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11236&action=view) Config log of gcc-4.0.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27076
[Bug c++/27094] [4.0/4.1/4.2 Regression] tree check: expected tree_list, have omp_return in build_call
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-04-10 11:34 --- Confirmed. Reduced testcase (compile with "g++ --param ggc-min-expand=0 --param ggc-min-heapsize=0"): = struct A { ~A(); }; struct B : A { B(); }; template struct C { C(const B& = B()); }; C<0> c; = The regression appeared in GCC 4.0.2. On mainline the error message reads: PR27094.cc: In constructor 'C< >::C(const B&) [with int = 0]': PR27094.cc:16: internal compiler error: tree check: expected tree_list, have omp_return in build_call, at cp/call.c:329 Please submit a full bug report, [etc.] On the 4.0 and 4.1 branch we have: PR27094.cc: In constructor 'C< >::C(const B&) [with int = 0]': PR27094.cc:16: internal compiler error: tree check: expected tree_list, have dl_expr in build_call, at cp/call.c:330 Please submit a full bug report, [etc.] -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||monitored Known to fail||4.0.2 4.1.0 4.1.1 4.2.0 Known to work||3.4.6 4.0.0 4.0.1 Last reconfirmed|-00-00 00:00:00 |2006-04-10 11:34:47 date|| Summary|[4.2 Regression] tree check:|[4.0/4.1/4.2 Regression] |expected tree_list, have|tree check: expected |omp_return in build_call|tree_list, have omp_return ||in build_call Target Milestone|4.2.0 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27094
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
--- Comment #18 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-04-10 10:24 --- Subject: Re: loop header should also be pulled out of the inner loop too > > > actually, thinking about it again, it should suffice to teach > > > invariant_without_guard_p about invariant memory loads, and this should > > > just > > > work. > > > > It basically does, the only other problem is that we are not able to > > determine > > that the outer loop is not infinite. > > It that because we don't recognize the condition of the loop header? the problem is that we use # of iterations analysis, and it tries to fully instantiate the scalar evolutions, which is impossible for *je. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #12 from sebastian dot pop at cri dot ensmp dot fr 2006-04-10 09:14 --- Created an attachment (id=11235) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11235&action=view) proposed fix This patch fixes the problem, but probably it is a more general optimization fix than the one described in the PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug middle-end/27095] [4.1/4.2 Regression] O2 produces duplicate code
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-10 09:00 --- We go via expand_builtin_memset which expands strlen at len_rtx = expand_normal (len); but then, expand via setmem fails, so we bail out else if (!set_storage_via_setmem(dest_mem, len_rtx, val_rtx, dest_align)) return 0; and end up doing regular return expand_call (exp, target, ignore); which then expands strlen again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27095
[Bug bootstrap/27099] stage3 compare failure
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-04-10 08:50 --- > I have configured gcc-4.1.0 with the following command: > > configure --enable-threads --enable-languages=c,c++ --enable-bootstrap > --with-gnu-as --with-gnu-ld Do not use --enable-bootstrap, it has not been tested with 4.1; just do as usual: configure --enable-languages=c,c++ --with-gnu-as --with-gnu-ld gmake bootstrap -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|GCC 4.1.0 won't build under |stage3 compare failure |Solaris 9 - fails stage3| |compare | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27099
[Bug bootstrap/27099] New: GCC 4.1.0 won't build under Solaris 9 - fails stage3 compare
I have configured gcc-4.1.0 with the following command: configure --enable-threads --enable-languages=c,c++ --enable-bootstrap --with-gnu-as --with-gnu-ld The system has GNU binutils 2.16 installed and when running "gmake bootstrap" it compiles all 3 stage but fails during the compare stage with: ... bgcc_s.so.1 && ln -s libgcc_s.so.1 sparcv9/libgcc_s.so gmake[4]: Leaving directory `/tmp/gcc-4.1.0/host-sparc-sun-solaris2.9/stage3-gcc' echo timestamp > stmp-multilib gmake[3]: Leaving directory `/tmp/gcc-4.1.0/host-sparc-sun-solaris2.9/stage3-gcc' gmake[2]: Leaving directory `/tmp/gcc-4.1.0' gmake compare gmake[2]: Entering directory `/tmp/gcc-4.1.0' gmake[3]: Entering directory `/tmp/gcc-4.1.0' gmake[3]: Leaving directory `/tmp/gcc-4.1.0' /bin/sh: stage3-gcc: does not exist gmake[2]: *** [compare] Error 1 gmake[2]: Leaving directory `/tmp/gcc-4.1.0' gmake[1]: *** [stage3-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-4.1.0' gmake: *** [bootstrap] Error 2 -- Summary: GCC 4.1.0 won't build under Solaris 9 - fails stage3 compare Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andy at trojanfoe dot servebeer dot com GCC build triplet: solaris2.9 GCC host triplet: sparc GCC target triplet: sun http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27099
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
--- Comment #17 from rguenther at suse dot de 2006-04-10 08:10 --- Subject: Re: loop header should also be pulled out of the inner loop too On Mon, 9 Apr 2006, rakdver at gcc dot gnu dot org wrote: > (In reply to comment #14) > > (In reply to comment #11) > > > I updated the patch for current mainline, but it still has issues for some > > > common uses of loops: > > > > > > void foo(int *ie, int *je, double *x) > > > { > > > int i, j; > > > for (j=0; j<*je; ++j) > > > for (i=0; i<*ie; ++i) > > > x[i+j] = 0.0; > > > } > > > > > > After loop header copying we have > > > > > > if (*je > 0) > > > for (j=0; j<*je; ++j) > > > if (*ie > 0) > > > for (i=0; i<*ie; ++i) > > > x[i+j ] = 0.0; > > > > > > note how in this form we see the condition *ie > 0 not invariant wrt the > > > outer loop (because it does a memory load), but if we would run load-PRE > > > between loop header copying and guard hoisting we would get > > > > actually, thinking about it again, it should suffice to teach > > invariant_without_guard_p about invariant memory loads, and this should just > > work. > > It basically does, the only other problem is that we are not able to determine > that the outer loop is not infinite. It that because we don't recognize the condition of the loop header? Otherwise we know that *je > 0 and the loop runs from 0 to *je (in fact, I have loop determine the number of iterations of the loop to be *je). Of course this is with load-PRE moving the load before the loop-header and thus SCEV being presented with D.xxx = *je; if (D.xxx > 0) for (j=0; jhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
[Bug target/26765] ICE in in extract_insn with __thread and optimization
--- Comment #4 from raj dot khem at gmail dot com 2006-04-10 07:38 --- I am unable to compile glibc 2.3.6 with GCC 4.1 on all mips-linux architecture because of this ICE. -- raj dot khem at gmail dot com changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26765
asr.c:3444: internal compiler error: Segmentation fault: 11
===> asr (all) cc -O -pipe -funroll-loops -march=pentium3 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/IBsec/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -I/usr/obj/usr/src/sys/IBsec -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/asr/../../dev/asr/asr.c /usr/src/sys/modules/asr/../../dev/asr/asr.c: In function `ASR_queue_i': /usr/src/sys/modules/asr/../../dev/asr/asr.c:3444: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. *** Error code 1 Stop in /usr/src/sys/modules/asr. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/IBsec. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. root: uname -a FreeBSD ws3-plovdiv.digsys.bg 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Wed Mar 22 20:44:32 EET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IBsec i386 root: gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.4 [FreeBSD] 20050518 root: Best regards, Valentin ChernoZemsky __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com