[Bug tree-optimization/23476] [4.1 Regression] ICE in VRP, remove_range_assertions

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 06:24 --- Ignore the comment about fold, copy prop is doing its job. Also here is a testcase which can be repduced with a simple -O2 so this is definitely a regression now and not just a latent bug waiting to be ex

[Bug tree-optimization/23476] [4.1 Regression] ICE in VRP, remove_range_assertions

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 06:19 --- Honza and Diego, this is the VRP bug which Honza was talking about which he found working on his SSA based inliner. -- What|Removed |Added -

[Bug tree-optimization/23476] New: [4.1 Regression] ICE in VRP, remove_range_assertions

Testcase: int h(int); static inline int f(int t, const int i) { _Bool a = i < t; if (a) return h(t); return 9; } int g(int t) { return f(t, 0x7FFF); } Compile with -O2 -fno-tree-copy-prop, and you will get an ICE: t.c: In function ‘g’: t.c:12: internal compiler error: in remove_r

[Bug libgcj/23431] abstract method resolve error in gij

--- Additional Comments From snambi at gmail dot com 2005-08-19 06:17 --- some more analysis of the problem. looks like this bug has been introduced in gcj 4.0.1 it works correctly in gcj 3.3.3 and javac 1.4.2, ie it gives an error while compiling. please look below, to see the messages

[Bug libstdc++/23358] _Destroy doesn't optimize for scalar types

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 06:01 --- Confirmed. -- What|Removed |Added Severity|normal |minor

[Bug tree-optimization/23475] Frequences are not updated for empty loop removal

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 06:01 --- I should note I found this while looking into PR 23358. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23475

[Bug tree-optimization/23475] Frequences are not updated for empty loop removal

-- What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/sh

[Bug tree-optimization/23475] Frequences are not updated for empty loop removal

-- What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/sh

[Bug tree-optimization/23475] New: Frequences are not updated for empty loop removal

Testcase: int f(int t) { int i; if(t) for(i = 0 ;i<10;i++) ; else return 2; return 1; } in the tree dump: : if (t_3 != 0) goto ; else goto ; Invalid sum of incoming frequencies 1100, should be 1 # i_6 = PHI <0(0)>; :; i_8 = i_6 + 1; Invalid sum of incomi

[Bug c++/20624] [4.0 Regression] wrong "control reaches end of non-void function" warning

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-19 05:41 --- Subject: Bug 20624 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-19 05:41:14 Modified files: gcc: ChangeLog gimple-low.c gcc/t

[Bug c++/20624] [4.0 Regression] wrong "control reaches end of non-void function" warning

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 05:41 --- Fixed on the mainline, will apply to the 4.0 branch later today (after class around 12pm EDT). -- What|Removed |Added ---

[Bug target/22049] M68K Coldfire: ICE in reload_cse_simplify_operands

-- What|Removed |Added Known to work||4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22049

[Bug target/19421] [4.0/4.1 regression] ICE with soft-float on m68k

-- What|Removed |Added GCC target triplet|m68k-* |m68k-rtems http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421

[Bug target/23435] [4.1 Regression] Unrecognizable insn (in extract_insn, at recog.c)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 05:11 --- Confirmed, reduced testcase: struct statfs { int f_bsize; }; struct super_block { unsigned long s_blocksize; }; struct nfs_fsinfo { unsigned long long bsize; }; int statfs (struct nfs_fsinfo *); int nf

[Bug tree-optimization/23462] [4.1 Regression] 27_io/basic_filebuf/sgetn/char/[12]-i[no].cc execution tests fail

--- Additional Comments From phython at gcc dot gnu dot org 2005-08-19 04:41 --- ia64-linux as well. These tests seem to have been failing for a while on mmix. See pr19747. -- What|Removed |Added -

[Bug target/23435] [4.1 Regression] Unrecognizable insn (in extract_insn, at recog.c)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 04:21 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23435

[Bug middle-end/23458] ICE on m68k (-O3)

-- What|Removed |Added Known to work||4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23458

[Bug target/21984] [4.1 regression] ICE in reload while compiling __mulxc3

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 04:09 --- *** Bug 21506 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug target/21506] [4.1 regression] [m68k-linux] ICE in verify_initial_elim_offsets during bootstrap

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 04:09 --- Yes it does, this is a dup of bug 21984. *** This bug has been marked as a duplicate of 21984 *** -- What|Removed |Added

[Bug target/21506] [4.1 regression] [m68k-linux] ICE in verify_initial_elim_offsets during bootstrap

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 04:07 --- Does this work now? I thought I saw that it does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21506

[Bug target/21506] [4.1 regression] [m68k-linux] ICE in verify_initial_elim_offsets during bootstrap

-- What|Removed |Added Target Milestone|--- |4.1.0 Version|4.0.1 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21506

[Bug target/23070] CALL_V4_CLEAR_FP_ARGS flag not properly set

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW

[Bug target/23070] CALL_V4_CLEAR_FP_ARGS flag not properly set

--- Additional Comments From amodra at bigpond dot net dot au 2005-08-19 03:21 --- Confirmed -- What|Removed |Added Status|UNCONFIRMED |NEW

[Bug target/23473] [4.1 Regression] ICE at config/arm/arm.c:3280

--- Additional Comments From kazu at gcc dot gnu dot org 2005-08-19 03:11 --- In fact, reverting Richard Earnshaw's patch 2005-08-15 Richard Earnshaw <[EMAIL PROTECTED]> PR target/23355 * arm.c (thumb_compute_save_reg_mask): Use similar logic to arm_compure_sa

[Bug target/23473] [4.1 Regression] ICE at config/arm/arm.c:3280

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 02:53 --- Seems like it was caused by: PR target/23355 * arm.c (thumb_compute_save_reg_mask): Use similar logic to arm_compure_save_reg0_reg12_mask to determine when the PIC register m

[Bug target/23473] ICE at config/arm/arm.c:3280

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 02:40 --- /* Something went wrong - thumb_compute_save_reg_mask() should have arranged for a suitable register to be pushed. */ gcc_unreachable (); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23473

[Bug c/22052] [4.0 Regression] redefinition of inline function succeeds

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 02:37 --- *** Bug 21975 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c/21975] [4.0 Regression] Segmentation fault while compiling ipw2100

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 02:37 --- *** This bug has been marked as a duplicate of 22052 *** -- What|Removed |Added

[Bug c/22052] [4.0 Regression] redefinition of inline function succeeds

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 02:36 --- *** Bug 23474 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c/23474] gcc segfaults when inlined function is redefined after use

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 02:36 --- *** This bug has been marked as a duplicate of 22052 *** -- What|Removed |Added

[Bug c/23474] New: gcc segfaults when inlined function is redefined after use

The following code causes Debian's gcc-4.0 to segfault: static inline __attribute__((always_inline)) void f(void) {} static inline void g(void) { f(); } static inline void f(void) {} void bug(void) { g(); } gcc -v: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v

[Bug target/23473] New: ICE at config/arm/arm.c:3280

Consider struct s { unsigned a : 1; }; int foo (struct s *p, int b, int c, int d) { p->a = 0; return b; } "./cc1 -quiet -O2 -mthumb -fPIC min.c" gives me min.c: In function 'foo': min.c:10: internal compiler error: in thumb_find_work_register, at config/arm/arm.c:3280 Please submit a full

[Bug c++/23472] __attribute__((constructor)) called twice with -funit-at-a-time

--- Additional Comments From matz at suse dot de 2005-08-19 01:36 --- Still a problem in the current hammer branch. CCing Honza. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23472

[Bug c++/23472] __attribute__((constructor)) called twice with -funit-at-a-time

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 01:15 --- This is a hammer branch specific bug (the branch which is used to produce SuSE's gcc). This bug does not effect any FSF branch any more as PR 16717 is already fixed and unit-at-a-time was added for 3.4.

[Bug c++/23472] New: __attribute__((constructor)) called twice with -funit-at-a-time

The constructor in the code for bug 16717 (below) gets called twice when compiled by 3.3.4 with - funit-at-a-time, but only once when called without -funit-at-a-time. This sounds like the opposite of bug 16717, which was marked as a 3.4 regression, and supposedly not a problem in 3.3.4. #inc

[Bug rtl-optimization/23453] [4.0/4.1 regression] miscompilation of PARI/GP on x86 with gcse after reload

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-08-19 01:03 --- Single-file testcase, compile with "-march=i486 -O2 -fomit-frame-pointer -fno-strict-aliasing -fgcse-after-reload": bar () { exit (0); } baz (x) { return x; } foo () { abort (); } ker0 (

[Bug tree-optimization/23471] New: a*a (for signed ints with -fno-wrapv) is always postive

Hmm, this is both a VRP bug and a folding bug. Even though a is VARYING, we know the that a*a will always be postive (this with -fno-wrapv which is default for C, C++ and fortran). void link_error(void); void f(int a) { int b = a; b*=a; if (b < 0) link_error(); } --- There should be n

[Bug tree-optimization/23452] Optimizing CONJG_EXPR (a) * a

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 23:33 --- Confirmed, there are two ways of fixing this, one in fold which folds CONJ_EXPR*a, the other way is to do it later on via somthing like like a combiner or even in complex exand. -- What|Re

[Bug libgcj/23466] Double.toString(0.0010) ---> "0.001" ISO "0.0010"

--- Additional Comments From robilad at kaffe dot org 2005-08-18 22:41 --- that looks like a bug in Sun's implementation, as the Double.toString() API specs demand that Double.toString returns only as many digits as necessary to uniquely identify the floating point number. Adding one o

[Bug middle-end/23470] New: a*a (for floats) is not considered always postive

While looking into PR 23452, I noticed this: double pow(double, double); int f(double a, double b) { if (((a*a) + (b*b))<0) link_error(); } There should be no reference to link_error as a*a is always postive. Note really __builtin_pow (a, 2.0e+0) is what is folded to first. --

[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program

-- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319

[Bug other/23469] Behaviour of built-in __signbitf(x) differs with optimization

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 21:41 --- This is not a bug as signbit just have to return a non zero value if it has the value passed has its sign bit set. So defining it this way: inline int mysignbit(float x) { union { float f; unsigned int i

[Bug rtl-optimization/23453] [4.0/4.1 regression] miscompilation of PARI/GP on x86

-- What|Removed |Added Status|WAITING |NEW Component|target |rtl-optimization Ever Confirmed|

[Bug other/23469] Behaviour of built-in __signbitf(x) differs with optimization

--- Additional Comments From ddneilson at gmail dot com 2005-08-18 20:49 --- Created an attachment (id=9541) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9541&action=view) Output from running the program with -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23469

[Bug other/23469] Behaviour of built-in __signbitf(x) differs with optimization

--- Additional Comments From ddneilson at gmail dot com 2005-08-18 20:49 --- Created an attachment (id=9540) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9540&action=view) Output from running the program without optimizations -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=234

[Bug other/23469] Behaviour of built-in __signbitf(x) differs with optimization

-- What|Removed |Added Attachment #9537|Ouput from compile with: g++|Output from compile with: description|-Wall -v -save-temps|g++ -Wall -v -save-temps

[Bug other/23469] Behaviour of built-in __signbitf(x) differs with optimization

--- Additional Comments From ddneilson at gmail dot com 2005-08-18 20:47 --- Created an attachment (id=9539) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9539&action=view) Output from compile with: g++ -Wall -v -O1 -save-temps signbit.cpp -- http://gcc.gnu.org/bugzilla/show_b

[Bug other/23469] Behaviour of built-in __signbitf(x) differs with optimization

--- Additional Comments From ddneilson at gmail dot com 2005-08-18 20:46 --- Created an attachment (id=9538) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9538&action=view) .ii file generated by compiling with: g++ -Wall -v -O1 -save-temps signbit.cpp -- http://gcc.gnu.org/bug

[Bug other/23469] Behaviour of built-in __signbitf(x) differs with optimization

--- Additional Comments From ddneilson at gmail dot com 2005-08-18 20:45 --- Created an attachment (id=9537) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9537&action=view) Ouput from compile with: g++ -Wall -v -save-temps signbit.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cg

[Bug other/23469] Behaviour of built-in __signbitf(x) differs with optimization

--- Additional Comments From ddneilson at gmail dot com 2005-08-18 20:44 --- Created an attachment (id=9536) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9536&action=view) .ii file generated by compiling with: g++ -Wall -v -save-temps signbit.cpp -- http://gcc.gnu.org/bugzill

[Bug other/23469] Behaviour of built-in __signbitf(x) differs with optimization

--- Additional Comments From ddneilson at gmail dot com 2005-08-18 20:43 --- Created an attachment (id=9535) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9535&action=view) Source file of example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23469

[Bug other/23469] New: Behaviour of built-in __signbitf(x) differs with optimization

The return value of the builtin signbit(x) macro (called with a float argument) differs when compiling with optimizations or not When optimizations are off the return value is 0x8000 or 0 (signbit set and not-set, respectively). When optimizations are on (-O1) return value is 1 or 0 (signbit set

[Bug c++/20624] [4.0/4.1 Regression] wrong "control reaches end of non-void function" warning

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 20:10 --- Patch posted here: which fixes this issue but not the one in PR 20681 which is a semi front-end bug in that it should have not emitted the break to

[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program

--- Additional Comments From fche at redhat dot com 2005-08-18 20:05 --- still broken. -- What|Removed |Added Status|RESOLVED|REOPENED

[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program

--- Additional Comments From gideon dot amos at canfieldsci dot com 2005-08-18 19:57 --- I'm still getting a mudflap violation with the simpler test case, posted by Frank Ch. Eigler, I get this on a debian linux system (Linux version 2.6.8-1-686-smp) with at least two builds of gcc: $ g

[Bug c++/22034] [4.1 Regression] ICE on valid (local class), dwarf2

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 19:14 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED

[Bug fortran/23460] [3.4 Regression] g77 unable to locate fortran INCLUDE files when preprocessed

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 19:12 --- Confirmed, this is a regression from 3.3.3 where this works. Gfortran works as expected. -- What|Removed |Added -

[Bug rtl-optimization/23454] [4.0 regression] ICE in invert_exp_1, at jump.c:1719

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 18:10 --- Confirmed, a reduced testcase: void tree_insert(); int empty, nulls; char found; long long min_arg, max_arg; static inline int compare_longlong(const long long s, const long long t) { return ((s < t) ? -1

[Bug middle-end/23467] alignment of member doesn't always carry over to alignment of struct.

--- Additional Comments From amylaar at gcc dot gnu dot org 2005-08-18 17:54 --- Created an attachment (id=9534) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9534&action=view) proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23467

[Bug middle-end/23467] alignment of member doesn't always carry over to alignment of struct.

--- Additional Comments From amylaar at gcc dot gnu dot org 2005-08-18 17:51 --- Created an attachment (id=9533) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9533&action=view) testcase Although the size of s1 gets padded to 64 bits for sh-elf, its alignemnt is set back to 32 bits

[Bug middle-end/23467] New: alignment of member doesn't always carry over to alignment of struct.

For STRICT_ALIGNMENT targets, the alignment of the mode of a struct can override a larger alignment requirement from an aligned member. -- Summary: alignment of member doesn't always carry over to alignment of struct. Product: gcc Version: 4.1.

[Bug libstdc++/23465] Assignment fails on TR1 unordered containers

--- Additional Comments From chris at bubblescope dot net 2005-08-18 17:26 --- The following simple piece of code fails to compile. #include int main(void) { std::tr1::unordered_set i,j; i = j; } The error is in fact in , and as all the unordered containers inherit from here, the

[Bug libstdc++/23465] New: Assignment fails on TR1 unordered containers

-- Summary: Assignment fails on TR1 unordered containers Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org Rep

[Bug target/23464] [4.1 Regression] compat tests fail

-- What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=

[Bug target/23463] [4.1 Regression] va-arg-22.c execution fails

-- What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=

[Bug tree-optimization/23462] [4.1 Regression] 27_io/basic_filebuf/sgetn/char/[12]-i[no].cc execution tests fail

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 16:47 --- And on powerpc-darwin. -- What|Removed |Added Component|libstdc++

[Bug target/23436] [4.1 Regression] Insn does not satisfy its constraints (reload_cse_simplify_operands)

--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-08-18 16:33 --- Mine. -- What|Removed |Added CC||rearnsha at gc

[Bug target/23464] New: [4.1 Regression] compat tests fail

FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t024 c_c

[Bug target/23463] New: [4.1 Regression] va-arg-22.c execution fails

FAIL: gcc.c-torture/execute/va-arg-22.c execution, -O0 FAIL: gcc.c-torture/execute/va-arg-22.c execution, -O1 FAIL: gcc.c-torture/execute/va-arg-22.c execution, -O2 FAIL: gcc.c-torture/execute/va-arg-22.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/va-arg-22.c execution,

[Bug libstdc++/23462] New: [4.1 Regression] 27_io/basic_filebuf/sgetn/char/[12]-i[no].cc execution tests fail

FAIL: 27_io/basic_filebuf/sgetn/char/1-in.cc execution test FAIL: 27_io/basic_filebuf/sgetn/char/1-io.cc execution test FAIL: 27_io/basic_filebuf/sgetn/char/2-in.cc execution test FAIL: 27_io/basic_filebuf/sgetn/char/2-io.cc execution test appeared on mainline between 20050816 and 20050817 (both a

[Bug java/12756] Binary Compatibility: Searches are slow

--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-18 16:09 --- AIUI, Andrew's profiling of jonas showed the runtime linker to be down in the noise. So this is not very important. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12756

[Bug tree-optimization/22228] [4.1 regression] ICE with -ftree-vectorize in verify_ssa

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-18 16:08 --- Subject: Bug 8 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-18 16:07:55 Modified files: gcc: ChangeLog tree-ssa-loop.c tree-vect-t

[Bug tree-optimization/23119] gcc.dg/vect/vect-105.c scan-tree-dump-times vectorized 1 loops 1 fails

--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-08-18 16:02 --- An XFAIL is still a test failing because of a bug in GCC, and all XFAILs should have open PRs in Bugzilla. If the target intrinsically cannot support the feature being tested for (e.g. target-specific tests),

[Bug c++/23426] [4.0/4.1 Regression] partial fix too large array problem

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 15:59 --- *** Bug 23461 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c++/23461] ICE in tree_low_cst, allocating oversized array from stack

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 15:59 --- This is a dup of bug 23426. The C example of this was fixed already. See PR 23426 for the current status of this bug. *** This bug has been marked as a duplicate of 23426 *** -- What|Re

[Bug c++/23461] ICE in tree_low_cst, allocating oversized array from stack

--- Additional Comments From pete at void dot printf dot net 2005-08-18 15:42 --- It's possible that this might be related to bug 22551, but I'm not sure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23461

[Bug c++/23461] New: ICE in tree_low_cst, allocating oversized array from stack

The following is a minimal test case. Obviously, this is trying to do a dumb thing, but it shouldn't give ICE, and g++ asked me to report it. The error is "internal compiler error: in tree_low_cst, at tree.c:3843". int main() { int ptr[10]; return 0; }; The output of g++ -

[Bug fortran/23460] New: g77 unable to locate fortran INCLUDE files when preprocessed

First, as requested the output of gcc -v Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --

[Bug c++/23089] [4.0/4.1 Regression] internal compiler error: in int_mode_for_mode, at stor-layout.c:251 at -O1

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-08-18 15:25 --- Testing a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rei

[Bug c++/22034] [4.1 Regression] ICE on valid (local class), dwarf2

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-18 15:25 --- Subject: Bug 22034 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-18 15:25:07 Modified files: gcc: cgraphunit.c ChangeLog Log message:

[Bug tree-optimization/23094] store ccp misses an optimization

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 13:55 --- I don't know how this was changed to waiting. -- What|Removed |Added Status|WAIT

[Bug tree-optimization/23094] store ccp misses an optimization

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 13:51 --- This was not fixed by the patch for PR 21574. -- What|Removed |Added Status|NEW

[Bug tree-optimization/23455] load PRE is missing

--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-18 13:46 --- Sorry. outcnt aliases with outbuf, so the load of t2 cannot be removed. The GIMPLE code that is now emitted is something like: void bi_windup(unsigned char *outbuf, unsigned char bi_buf) {

[Bug tree-optimization/23455] load PRE is missing

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-18 13:46 --- Subject: Re: load PRE is missing On Thu, 2005-08-18 at 13:44 +, bonzini at gcc dot gnu dot org wrote: > --- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-18 > 13:44 --- > ou

[Bug tree-optimization/23455] load PRE is missing

--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-18 13:44 --- outcnt aliases with outbuf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23455

[Bug target/23453] [4.0/4.1 regression] miscompilation of PARI/GP on x86

--- Additional Comments From debian-gcc at lists dot debian dot org 2005-08-18 13:15 --- testcase at http://people.debian.org/~doko/tmp/tst.tar.bz2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453

[Bug tree-optimization/23455] load PRE is missing

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-18 13:09 --- Subject: Re: New: load PRE is missing On Thu, 2005-08-18 at 07:55 +, bonzini at gcc dot gnu dot org wrote: > Load PRE is scheduled for 4.2, I'm creating this bug because load PRE is > currently split b

[Bug middle-end/23458] ICE on m68k (-O3)

-- What|Removed |Added Component|c |middle-end Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show

[Bug c/23458] ICE on m68k (-O3)

--- Additional Comments From bas at debian dot org 2005-08-18 12:33 --- Created an attachment (id=9531) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9531&action=view) Test case compile this with "gcc -O3 -c test.i" to trigger the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi

[Bug rtl-optimization/23454] [4.0 regression] ICE in invert_exp_1, at jump.c:1719

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 12:32 --- Here is the backtrace: #0 fancy_abort (file=0x5e7648 "../../gcc/jump.c", line=1719, function=0x5e76ec "invert_exp_1") at ../ ../gcc/diagnostic.c:556 #1 0x003a72d4 in invert_exp_1 (insn=0x2b8923c) at ../..

[Bug c/23458] New: ICE on m68k (-O3)

gcc 4.0.1-4 ICE's when compiling freesci on m68k: m68k-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../src/include-Wall -g -O3 -c script.c ../../src/include/gfx_system.h:241: warning: 'gfx_rect_fullscreen' defined but not used ../../src/include/gfx_widgets.h:73: warning: 'gfxw_point_zero

[Bug target/23454] [4.0 regression] ICE in invert_exp_1, at jump.c:1719

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 12:17 --- This is most likely latent on the mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23454

[Bug target/23454] [4.0 regression] ICE in invert_exp_1, at jump.c:1719

-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|---

[Bug target/23453] [4.0/4.1 regression] miscompilation of PARI/GP on x86

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 12:05 --- We need at least a testcase which links. -- What|Removed |Added Status|UNCONFIRM

[Bug target/23451] [3.4/4.0/4.1 regression] Redundant reloading from stack frame

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 12:01 --- I think this is just a ra issue which have no hope of being fixed in a release branch. -- What|Removed |Added ---

[Bug c++/23457] [3.4/4.0/4.1 Regression] compiler crash on huge object size with virtual base

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 11:58 --- Confirmed, backtrace: #0 internal_error (msgid=0x83f0f38 "tree_low_cst") at ../../gcc/diagnostic.c:536 #1 0x08127c4f in fancy_abort (file=0x83f0f38 "tree_low_cst", line=3313, function=0x83f0f38 "tree_lo

[Bug target/23376] ICE on GCC 4.x with -O1 -funroll-loops -fvariable-expansion-in-unroller

--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-18 11:51 --- Mark, should this patch go into 4.0.2 too? -- What|Removed |Added CC|

[Bug middle-end/23410] [4.1 Regression] FAIL: gcc.c-torture/execute/950612-1.c execution, at -Os and -O3

--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr 2005-08-18 11:51 --- Reduced testcase is: unsigned long long f4 (unsigned long long diff) { return ((unsigned long long) ((signed long long) diff < 0 ? -diff : diff)); } main () { int i; for (i = 0; i <= 10; i

[Bug middle-end/8081] ICE with variably sized types and nested functions

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 11:50 --- *** Bug 23456 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug middle-end/23456] [4.0 regression] ICE in assign_stack_temp_for_typ (ObjC)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-18 11:50 --- This not really a regression. This is a dup of bug 8081 which has been a bug since 2.95.3. *** This bug has been marked as a duplicate of 8081 *** -- What|Removed |Added

  1   2   >