[Bug rtl-optimization/32293] [4.3 Regression] internal compiler error: in do_SUBST, at combine.c:502
--- Comment #9 from ubizjak at gmail dot com 2007-06-12 07:01 ---
Following patch should fix the ICE:
Index: combine.c
===
--- combine.c (revision 125636)
+++ combine.c (working copy)
@@ -5210,11 +5210,17 @@ simplify_if_then_else (rtx x)
if (true_code == EQ true_val == const0_rtx
exact_log2 (nzb = nonzero_bits (from, GET_MODE (from))) = 0)
- false_code = EQ, false_val = GEN_INT (nzb);
+ {
+ false_code = EQ;
+ false_val = GEN_INT (trunc_int_for_mode (nzb, GET_MODE (from)));
+ }
else if (true_code == EQ true_val == const0_rtx
(num_sign_bit_copies (from, GET_MODE (from))
== GET_MODE_BITSIZE (GET_MODE (from
- false_code = EQ, false_val = constm1_rtx;
+ {
+ false_code = EQ;
+ false_val = constm1_rtx;
+ }
/* Now simplify an arm if we know the value of the register in the
branch and it is used in the arm. Be careful due to the potential
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC||ubizjak at gmail dot com
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-06-12 07:01:32
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32293
[Bug fortran/32298] New: Intrinsic MINLOC / MAXLOC gives wrong results (gfortran build 20070522)
The following source code: !- PROGRAM ERR_MINLOC INTEGER, PARAMETER :: N = 7 DOUBLE PRECISION, DIMENSION (N), PARAMETER :: A = (/ 0.3D0, 0.455D0, 0.6D0, 0.7D0, 0.72D0, 0.76D0, 0.79D0 /) DOUBLE PRECISION :: B INTEGER :: I, J, K DO I = 1, N B = A(I) J = MINLOC (ABS (A - B), 1) K = MAXLOC (ABS (A - B), 1) PRINT *, I, J, K END DO STOP END PROGRAM ERR_MINLOC !-- gives the following result: (superflouos blanks are deleted): -- 1 2 7 2 2 7 3 3 7 4 4 2 5 5 2 6 6 2 7 7 2 -- The correct result is: -- 1 1 7 2 2 7 3 3 1 4 4 1 5 5 1 6 6 1 7 7 1 -- -- Summary: Intrinsic MINLOC / MAXLOC gives wrong results (gfortran build 20070522) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jens dot bischoff at freenet dot de GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32298
[Bug rtl-optimization/32293] [4.3 Regression] internal compiler error: in do_SUBST, at combine.c:502
--- Comment #10 from ubizjak at gmail dot com 2007-06-12 08:26 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00759.html -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||06/msg00759.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2007-06-12 07:01:32 |2007-06-12 08:26:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32293
[Bug ada/32299] New: 4.3-20070608 gnat bug detected in gimplify_addr_expr, at gimplify.c:3919
$ gcc -v -c gcc43.adb Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../SOURCES/gcc-4.3-20070608/configure --prefix=/usr --enable-languages=c,c++,ada Thread model: posix gcc version 4.3.0 20070608 (experimental) /usr/libexec/gcc/i686-pc-linux-gnu/4.3.0/gnat1 -quiet -dumpbase gcc43.adb -mtune=generic gcc43.adb -o /tmp/ccxo3ZQM.s +===GNAT BUG DETECTED==+ | 4.3.0 20070608 (experimental) (i686-pc-linux-gnu) GCC error: | | in gimplify_addr_expr, at gimplify.c:3919| | Error detected around gcc43.adb:28 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. gcc43.adb gcc43.ads -- file: gcc43.ads with Interfaces.C.Pointers, Interfaces.C.Strings; with System.Storage_Elements; package Gcc43 is package SSE renames System.Storage_Elements; package Conv is new Interfaces.C.Pointers (Index = SSE.Storage_Offset, Element = SSE.Storage_Element, Element_Array = SSE.Storage_Array, Default_Terminator = 16#00#); -- unused procedure Push_To_LLAPI (header_len : SSE.Storage_Offset; header_data : Conv.Pointer; data_len : SSE.Storage_Offset; data : Conv.Pointer); subtype Dummy_Contents is SSE.Storage_Array (1 .. 72); type J3_2_Llapi_T is record Dummy : Dummy_Contents; end record; end Gcc43; -- file: gcc43.adb with Interfaces.C.Pointers; with Ada.Exceptions; with System.Storage_Elements; with Unchecked_Conversion; with Text_IO; package body Gcc43 is use type SSE.Storage_Offset; procedure Push_To_LLAPI (header_len : SSE.Storage_Offset; header_data : Conv.Pointer; data_len : SSE.Storage_Offset; data : Conv.Pointer) is Header : SSE.Storage_Array (1 .. Header_Len); Buf : SSE.Storage_Array (1 .. 1 + Data_Len); Buf_Address : constant System.Address := Buf (1)'Address; Ext_Track : J3_2_Llapi_T; pragma Import (Ada, Ext_Track); for Ext_Track'Address use Buf_Address; begin if Header_Len = 0 then return; end if; begin Header := Conv.Value (Header_Data, Interfaces.C.ptrdiff_t (Header_Len)); Buf (1) := Header (1); Buf (2 .. Buf'Last) := Conv.Value (Data, Interfaces.C.ptrdiff_t (Data_Len)); exception when E : others = Text_IO.Put_Line (Push_To_LLAPI: exception on assigning Buf, Ada.Exceptions.Exception_Information (E)); end; end Push_To_LLAPI; end Gcc43; -- Summary: 4.3-20070608 gnat bug detected in gimplify_addr_expr, at gimplify.c:3919 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oliver dot kellogg at eads dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32299
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-12 10:05 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-12 10:05:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug rtl-optimization/32293] [4.3 Regression] internal compiler error: in do_SUBST, at combine.c:502
--- Comment #11 from uros at gcc dot gnu dot org 2007-06-12 10:31 --- Subject: Bug 32293 Author: uros Date: Tue Jun 12 10:31:04 2007 New Revision: 125643 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125643 Log: PR rtl-optimization/32293 * combine.c (simplify_if_then_else): Truncate return from nonzero_bits() to correct mode. testsuite/ChangeLog: PR rtl-optimization/32293 * gcc.dg/pr32293.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr32293.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32293
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #8 from rob1weld at aol dot com 2007-06-12 10:53 --- should be many more tests. It's OK. I followed the advice on page http://gcc.gnu.org/install/test.html - Section 0.1 How can you run the testsuite on selected tests?. make check-gcc RUNTESTFLAGS=dg-torture.exp I did that so I could check quickly and post here; so people would not be trying to fix what is NOT broken and know the correct place to look for the trouble. Just completed the whole test on everything - see here: http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00573.html Also please look at the end of the report. I made a mod to the test_summary to catch assembler errors - and it found some ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug testsuite/32063] contrib/test_summary script could output results more neatly
--- Comment #5 from rob1weld at aol dot com 2007-06-12 11:11 --- Here is another, this caught some errors! See end of: http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00573.html print grep -e undefined\\ reference\\ to /opt/gcc-4_3-build/gcc/testsuite/gcc/gcc.log | sort -u -k 2 | head -n 10 print ; system(grep -e undefined\\ reference\\ to /opt/gcc-4_3-build/gcc/testsuite/gcc/gcc.log | sort -u -k 2 | head -n 10); print ---; print ; Note: These additions go directly before these lines: print Compiler version: prefix version lang; print Platform: host; print configflags; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32063
[Bug libmudflap/31845] Need to adjust libmudflap timeout values in testsuite.
--- Comment #3 from rob1weld at aol dot com 2007-06-12 11:16 ---
FIX - Altered dg-timeout:
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.cth/pass37-frag-Origonal.c
/* { dg-output 100 100 100 100 100 100 100 100 100 100 } */
/* { dg-repetitions 20 } */
/* { dg-timeout 10 } */
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.cth/pass37-frag.c
/* { dg-output 100 100 100 100 100 100 100 100 100 100 } */
/* { dg-repetitions 20 } */
/* { dg-timeout 300 } */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31845
[Bug libmudflap/31681] [4.3 regression]: Many libmudflap faulures
--- Comment #5 from rob1weld at aol dot com 2007-06-12 11:21 --- [EMAIL PROTECTED] Fixed. Nope. Results for 4.3.0 20070611 (experimental) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00573.html A portion of this bug report is duplicated at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32276 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31681
[Bug fortran/32289] mips version of gfortran produces internal compiler error
--- Comment #4 from tbm at cyrius dot com 2007-06-12 11:22 --- This works with 4.3.0 20070604 on mips. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
[Bug target/32276] [4.3 Regression] New libmudflap failures
--- Comment #1 from rob1weld at aol dot com 2007-06-12 11:24 ---
These bug were first mentioned in report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31681
Confirmed for similar target:
Results for 4.3.0 20070611 (experimental) testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00573.html
--- My Notes ---
Screen output:
=== libmudflap tests ===
Schedule of variations:
unix
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /root/downloads/gcc-4_3-trunk/libmudflap/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.c/cfrags.exp ...
Running
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.c/externs.exp ...
Running
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.c++/c++frags.exp
...
FAIL: libmudflap.c++/pass41-frag.cxx execution test
FAIL: libmudflap.c++/pass41-frag.cxx (-static) execution test
FAIL: libmudflap.c++/pass41-frag.cxx ( -O) execution test
FAIL: libmudflap.c++/pass41-frag.cxx (-O2) execution test
FAIL: libmudflap.c++/pass41-frag.cxx (-O3) execution test
Running
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.c++/ctors.exp ...
Running
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.cth/cthfrags.exp
...
=== libmudflap Summary ===
# of expected passes1985
# of unexpected failures5
Log file i686-pc-linux-gnu/libmudflap/testsuite/libmudflap.log output:
mudflap violation 1 (check/read): time=1181641131.727908 ptr=0x401fd640 size=4
pc=0x40027c0d
location=`/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/include/ostream:546
(main)'
/opt/gcc-4_3-build/i686-pc-linux-gnu/./libmudflap/.libs/libmudflap.so.0(__mf_check+0x3d)
[0x40027c0d]
./pass41-frag.exe(main+0x2bb) [0x8048f7b]
/opt/gcc-4_3-build/i686-pc-linux-gnu/./libmudflap/.libs/libmudflap.so.0(__wrap_main+0x4f)
[0x4002745f]
number of nearby objects: 0
FAIL: libmudflap.c++/pass41-frag.cxx execution test
mudflap violation 1 (check/read): time=1181641140.406737 ptr=0x80fb280 size=4
pc=0x804b3d0
location=`/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/include/ostream:546
(main)'
[0x804b3d0]
[0x804851b]
[0x804b416]
number of nearby objects: 0
FAIL: libmudflap.c++/pass41-frag.cxx (-static) execution test
mudflap violation 1 (check/read): time=1181641147.350329 ptr=0x401fd640 size=4
pc=0x40027c0d
location=`/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/include/ostream:546
(main)'
/opt/gcc-4_3-build/i686-pc-linux-gnu/./libmudflap/.libs/libmudflap.so.0(__mf_check+0x3d)
[0x40027c0d]
./pass41-frag.exe(main+0x1b1) [0x8048e65]
/opt/gcc-4_3-build/i686-pc-linux-gnu/./libmudflap/.libs/libmudflap.so.0(__wrap_main+0x4f)
[0x4002745f]
number of nearby objects: 0
FAIL: libmudflap.c++/pass41-frag.cxx ( -O) execution test
mudflap violation 1 (check/read): time=1181641153.350016 ptr=0x401fd640 size=4
pc=0x40027c0d
location=`/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/include/ostream:546
(main)'
/opt/gcc-4_3-build/i686-pc-linux-gnu/./libmudflap/.libs/libmudflap.so.0(__mf_check+0x3d)
[0x40027c0d]
./pass41-frag.exe(main+0x2bb) [0x8048f7b]
/opt/gcc-4_3-build/i686-pc-linux-gnu/./libmudflap/.libs/libmudflap.so.0(__wrap_main+0x4f)
[0x4002745f]
number of nearby objects: 0
FAIL: libmudflap.c++/pass41-frag.cxx (-O2) execution test
mudflap violation 1 (check/read): time=1181641160.020512 ptr=0x401fd640 size=4
pc=0x40027c0d
location=`/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/include/ostream:546
(main)'
/opt/gcc-4_3-build/i686-pc-linux-gnu/./libmudflap/.libs/libmudflap.so.0(__mf_check+0x3d)
[0x40027c0d]
./pass41-frag.exe(main+0x2bb) [0x8049f7b]
/opt/gcc-4_3-build/i686-pc-linux-gnu/./libmudflap/.libs/libmudflap.so.0(__wrap_main+0x4f)
[0x4002745f]
number of nearby objects: 0
FAIL: libmudflap.c++/pass41-frag.cxx (-O3) execution test
All the log entries show number of nearby objects: 0. Does this mean that it
is
not the test itself that is failing but instead something other than the test -
IE:
GXX is compiling incorrect code or the libraries are incorrectly written.
# cat
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.c++/pass41-frag.cxx
#include string
#include iostream
int
main (int argc, char *argv[])
{
std::string myStr = Hello, World!;
std::cout myStr std::endl;
return 0;
}
/opt/gcc-4_3-build/./gcc/g++ -shared-libgcc -B/opt/gcc-4_3-build/./gcc
-nostdinc++ -L/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/src
-L/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/usr/test/i686-pc-linux-gnu/bin/ -B/usr/test/i686-pc-linux-gnu/lib/ -isystem
/usr/test/i686-pc-linux-gnu/include -isystem
/usr/test/i686-pc-linux-gnu/sys-include -ffloat-store
[Bug c++/32290] GCC crashes with OOM when compiling relatively simple source file (no endless loop)
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-12 11:29 --- mainline uses 10MB to compile reduced-problem.ii.nocrap. So this is actually a dup of PR29433. *** This bug has been marked as a duplicate of 29433 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32290
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-06-12 11:29 --- *** Bug 32290 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aribrei at arcor dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug rtl-optimization/32293] [4.3 Regression] internal compiler error: in do_SUBST, at combine.c:502
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-06-12 11:31 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32293
[Bug c++/32300] New: ICE with -O2 -fsee
cat bug.ii
struct vector {
int *start, *finish;
unsigned long size() { return finish - start; }
};
void f(vector v) {
for (unsigned i = 0; i v.size(); ++i);
}
g++ -O2 -fsee bug.ii
bug.ii: In function void f(vector):
bug.ii:7: internal compiler error: Segmentation fault
This started failing in the last couple of days.
I'm compiling on linux_x86_64.
--
Summary: ICE with -O2 -fsee
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug bootstrap/32287] gas version style changed causs warnings with configure
--- Comment #3 from rob1weld at aol dot com 2007-06-12 11:37 --- Even if they did change it back people may still have one of these versions since _all_ my versions of gas are less than a year old. Oneis the newest that apt-get will fetch (IE: the standard OS version), another is the newest snapshot, the last is the newest SVN compiled by me - so each is actually new, depending on how you look at it. My patch only grabs the numbers. If they change version numbering to 2.17.50.gamma.7.four then were screwed. I welcome anyone to write a better script. I'm just pointing out the bug. When things work (however badly) in one part of gcc and then fail (but only partially) in another spot (or work OK) then it can cause some weird errors that are hard to track down. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32287
[Bug fortran/32289] mips version of gfortran produces internal compiler error
--- Comment #5 from tbm at cyrius dot com 2007-06-12 11:43 --- I can reproduce this with current 4.1 from SVN, but not with 4.2 from SVN. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
[Bug tree-optimization/31657] Should combine bit tests in if stmts
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-12 12:06 --- Subject: Bug 31657 Author: rguenth Date: Tue Jun 12 12:06:19 2007 New Revision: 125644 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125644 Log: 2007-06-12 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/15353 PR tree-optimization/31657 * passes.c (init_optimization_passes): Add pass_tree_ifcombine. * timevar.def: Add TV_TREE_IFCOMBINE. * tree-pass.h (pass_tree_ifcombine): Declare. * tree-ssa-ifcombine.c: New file. * tree-ssa-phiopt.c (blocks_in_phiopt_order): Export. * tree-flow.h (blocks_in_phiopt_order): Declare. * Makefile.in (OBJS-common): Add tree-ssa-ifcombine.o. (tree-ssa-ifcombine.o): New dependencies. * gcc.c-torture/execute/20070424-1.c: New testcase. * gcc.dg/tree-ssa/ssa-ifcombine-1.c: Likewise. * gcc.dg/tree-ssa/ssa-ifcombine-2.c: Likewise. * gcc.dg/tree-ssa/ssa-ifcombine-3.c: Likewise. * gcc.dg/tree-ssa/ssa-ifcombine-4.c: Likewise. * gcc.dg/tree-ssa/ssa-ifcombine-5.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20070424-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-5.c trunk/gcc/tree-ssa-ifcombine.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/timevar.def trunk/gcc/tree-flow.h trunk/gcc/tree-pass.h trunk/gcc/tree-ssa-phiopt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31657
[Bug tree-optimization/15353] [tree-ssa] Merge two ifs if one subsumes the other.
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-06-12 12:06 --- Subject: Bug 15353 Author: rguenth Date: Tue Jun 12 12:06:19 2007 New Revision: 125644 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125644 Log: 2007-06-12 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/15353 PR tree-optimization/31657 * passes.c (init_optimization_passes): Add pass_tree_ifcombine. * timevar.def: Add TV_TREE_IFCOMBINE. * tree-pass.h (pass_tree_ifcombine): Declare. * tree-ssa-ifcombine.c: New file. * tree-ssa-phiopt.c (blocks_in_phiopt_order): Export. * tree-flow.h (blocks_in_phiopt_order): Declare. * Makefile.in (OBJS-common): Add tree-ssa-ifcombine.o. (tree-ssa-ifcombine.o): New dependencies. * gcc.c-torture/execute/20070424-1.c: New testcase. * gcc.dg/tree-ssa/ssa-ifcombine-1.c: Likewise. * gcc.dg/tree-ssa/ssa-ifcombine-2.c: Likewise. * gcc.dg/tree-ssa/ssa-ifcombine-3.c: Likewise. * gcc.dg/tree-ssa/ssa-ifcombine-4.c: Likewise. * gcc.dg/tree-ssa/ssa-ifcombine-5.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20070424-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-5.c trunk/gcc/tree-ssa-ifcombine.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/timevar.def trunk/gcc/tree-flow.h trunk/gcc/tree-pass.h trunk/gcc/tree-ssa-phiopt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15353
[Bug tree-optimization/15353] [tree-ssa] Merge two ifs if one subsumes the other.
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-06-12 12:08 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15353
[Bug tree-optimization/31657] Should combine bit tests in if stmts
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-12 12:08 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31657
[Bug tree-optimization/15357] [tree-ssa] combing if statements
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-12 12:10 --- The new if-combining pass can be told to make the transformation suggested in the description. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15357
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-12 12:36 --- Confirmed. A dataflow merge fallout probably: Program received signal SIGSEGV, Segmentation fault. 0x007c449c in df_insn_refs_verify (collection_rec=0x7fff1ab011c0, bb=0x2aec90911360, insn=0x2aec9074dfa0, abort_if_fail=1 '\001') at /space/rguenther/src/svn/trunk/gcc/df-scan.c:4148 4148 if (!DF_INSN_UID_DEFS (uid)) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||zadeck at naturalbridge dot ||com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-12 12:36:27 date|| Summary|ICE with -O2 -fsee |[4.3 Regression] ICE with - ||O2 -fsee Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug middle-end/32301] New: int __attribute__((vector_size(8))) doesn't use %mm0, produces ugly code
When the code below is compiled with -march=pentium4 -msse2 -O3
-fomit-frame-pointer, when N == 4 f() is correct:
f:
movdqa b, %xmm0
paddd a, %xmm0
movdqa %xmm0, c
ret
However for N == 2 gcc 4.2.0 doesn't use %mm0 any more (gcc 4.0.0 worked OK).
OK, for some reason gcc decides to synthesize the operation using scalar
instructions. But why the code for f() is so scary, not even close to that of
g()? My wild guess is that gcc copies vectors onto the stack because it thinks
the vectors may overlap. But is it really possible? If so, how can I say that
they never overlap? Perhaps this is a bug too, because they are declared as
different objects, should not overlap.
#define N 2
typedef signed int data_type;
typedef data_type __attribute__((vector_size(sizeof(data_type) * N))) vector;
extern vector a, b, c;
void
f()
{
c = a + b;
}
typedef data_type vector2[N];
extern vector2 a2, b2, c2;
void
g()
{
int i;
for (i = 0; i N; ++i)
c2[i] = a2[i] + b2[i];
}
For the code above gcc 4.2.0 produces:
f:
pushl %esi
pushl %ebx
subl$36, %esp
movla, %ebx
movla+4, %esi
movlb, %edx
movlb+4, %ecx
movl%edx, 24(%esp)
movl%ecx, 28(%esp)
movl24(%esp), %eax
movl%ebx, 16(%esp)
movl%esi, 20(%esp)
addl16(%esp), %eax
movl%eax, c
movl%edx, 8(%esp)
movl%ecx, 12(%esp)
movl12(%esp), %eax
movl%ebx, (%esp)
movl%esi, 4(%esp)
addl4(%esp), %eax
movl%eax, c+4
addl$36, %esp
popl%ebx
popl%esi
ret
g:
movla2, %eax
addlb2, %eax
movl%eax, c2
movla2+4, %eax
addlb2+4, %eax
movl%eax, c2+4
ret
--
Summary: int __attribute__((vector_size(8))) doesn't use %mm0,
produces ugly code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tomash dot brechko 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=32301
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-12 12:40 --- FYI (gdb) bt #0 0x007c449c in df_insn_refs_verify (collection_rec=0x70a74130, bb=0x2aaeba99e360, insn=0x2aaeba7dafa0, abort_if_fail=1 '\001') at /space/rguenther/src/svn/trunk/gcc/df-scan.c:4148 #1 0x007c4717 in df_bb_verify (bb=0x2aaeba99e360) at /space/rguenther/src/svn/trunk/gcc/df-scan.c:4195 #2 0x007c4bf4 in df_scan_verify () at /space/rguenther/src/svn/trunk/gcc/df-scan.c:4334 #3 0x007b1f56 in df_verify () at /space/rguenther/src/svn/trunk/gcc/df-core.c:1513 #4 0x007b0fa0 in df_analyze () at /space/rguenther/src/svn/trunk/gcc/df-core.c:1106 #5 0x00efa835 in init_dce (fast=1 '\001') at /space/rguenther/src/svn/trunk/gcc/dce.c:187 #6 0x00efbd0f in rest_of_handle_fast_dce () at /space/rguenther/src/svn/trunk/gcc/dce.c:719 #7 0x00efbda3 in run_fast_dce () at /space/rguenther/src/svn/trunk/gcc/dce.c:767 #8 0x00a3840e in rest_of_handle_see () at /space/rguenther/src/svn/trunk/gcc/see.c:3823 #9 0x009a4c69 in execute_one_pass (pass=0x1454340) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug target/32301] int __attribute__((vector_size(8))) doesn't use %mm0, produces ugly code
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-12 12:42 --- This is on purpose as if the compiler used the MMX registers it would need to emit emms but it does not do that yet. There are two other bugs about this issue already too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32301
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #3 from zadeck at naturalbridge dot com 2007-06-12 12:46 --- I am not surprised at this at all. Given that there are no regression tests that use -fsee and this pass is never on by default. I will look into this. However, the big picture is that we need to make a decision about optimizations like this. They should either be enabled either at some -O level or in regression tests or they should be removed from the compiler. They serve no purpose the way that they are now. -- zadeck at naturalbridge dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |zadeck at naturalbridge dot |dot org |com Status|NEW |ASSIGNED Last reconfirmed|2007-06-12 12:36:27 |2007-06-12 12:46:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug target/32280] _mm_srli_si128, heinous code for some shifts
--- Comment #6 from ubizjak at gmail dot com 2007-06-12 12:48 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32280
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-12 13:37 --- Yes, those should be at least excercised by the tortures. So, if enabling at -O3 regtests ok I'd vote for enabling it there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug c++/32288] Our C++ program (gcc 4.1.1 under Aix 5.3) crashes with a core dump
--- Comment #1 from alessandro dot mei at elsagdatamat dot com 2007-06-12 13:30 --- Created an attachment (id=13685) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13685action=view) compiler output and warnings; the preprocessed file (*.ii) that triggers the bug the complete command line that triggers the bug; /home/mag/sviluppo/bin/bkeuti /home/mag/sviluppo/config/bkeuti.xml /home/mag/sviluppo/config/processi.dtd /dev/null The stack content relative to the core file is the following: (gdb) where #0 0xd1514a98 in _ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base ( __x=incomplete type) at ../../../../gcc-4.1.1/libstdc++-v3/src/tree.cc:68 #1 0x10019fac in _ZNSt17_Rb_tree_iteratorISt4pairIKSsP6CTimerEEppEi ( this=incomplete type) at /usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/4.1.1/../../../../include/c++/4 .1.1/bits/stl_tree.h:190 #2 0x100200b0 in _ZN13bus_CProcesso17azioniDiBackGroudEv ( this=incomplete type) at bus_CProcesso.cpp:838 #3 0x10022750 in _ZN13bus_CProcesso3vaiEbi (this=incomplete type, bSync=false, intSec=1) at bus_CProcesso.cpp:458 #4 0x10022e18 in _ZN22bus_CProcessoExceptionC1Ev (this=incomplete type) at bus_CProcesso.hpp:88 #5 0x10005054 in main (argc=3, argv=0x2ff22934, envp=0x2ff22944) at bkeuti.cpp:655 #6 0x1214 in __start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32288
[Bug fortran/32302] New: gfortran - incorrect result with -O3
The output of this program is correct when using -g, but incorrect with -O3 - [dranta:~/junk] dir% cp dyna3dTest01.F Test01.F [dranta:~/junk] dir% gfortran -g -O3 -std=legacy -DSGI -DWKSTN -DUNIX -DVECLEN=32 -DDP -fcray-pointer -fno-automatic -o Test01 Test01.F Test01.F:47.19: common/aux32/a17(lnv),a28(lnv),dett(lnv), 1 Warning: Named COMMON block 'aux32' at (1) shall be of the same size Test01.F:53.19: common/aux33/ix1(lnv),ix2(lnv),ix3(lnv),ix4(lnv),ix5(lnv), 1 Warning: Named COMMON block 'aux33' at (1) shall be of the same size /usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib referenced from: /usr/local/gfortran/lib/gcc/powerpc-apple-darwin8.9.0/4.3.0/../../../libgfortran.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) [dranta:~/junk] dir% Test01 0.250 0.250 [dranta:~/junk] dir% gfortran -g -std=legacy -DSGI -DWKSTN -DUNIX -DVECLEN=32 -DDP -fcray-pointer -fno-automatic -o Test01 Test01.F Test01.F:47.19: common/aux32/a17(lnv),a28(lnv),dett(lnv), 1 Warning: Named COMMON block 'aux32' at (1) shall be of the same size Test01.F:53.19: common/aux33/ix1(lnv),ix2(lnv),ix3(lnv),ix4(lnv),ix5(lnv), 1 Warning: Named COMMON block 'aux33' at (1) shall be of the same size /usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib referenced from: /usr/local/gfortran/lib/gcc/powerpc-apple-darwin8.9.0/4.3.0/../../../libgfortran.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) [dranta:~/junk] dir% Test01 1.001.00 [dranta:~/junk] dir% cat Test01.F subroutine unpki(ixp,nwcon,nmel) parameter(lnv=VECLEN) #ifdef DP implicit double precision (a-h,o-z)dp #endif c c unpack connection data c common/aux32/kka(lnv),kkb(lnv),kkc(lnv), 1 kk1(lnv),kk2(lnv),kk3(lnv),dxy(lnv), 2 dyx(lnv),dyz(lnv),dzy(lnv),dzx(lnv), 3 dxz(lnv),vx17(lnv),vx28(lnv),vx35(lnv), 4 vx46(lnv),vy17(lnv),vy28(lnv), 5 vy35(lnv),vy46(lnv),vz17(lnv),vz28(lnv),vz35(lnv),vz46(lnv) common/aux33/ix1(lnv),ix2(lnv),ix3(lnv),ix4(lnv),ix5(lnv), 1 ix6(lnv),ix7(lnv),ix8(lnv),mxt(lnv) dimension ixp(nwcon,*) c return end subroutine prtal parameter(lnv=VECLEN) #ifdef DP implicit double precision (a-h,o-z)dp #endif common/aux8/ x1(lnv),x2(lnv),x3(lnv),x4(lnv), x5(lnv),x6(lnv),x7(lnv),x8(lnv), y1(lnv),y2(lnv),y3(lnv),y4(lnv), y5(lnv),y6(lnv),y7(lnv),y8(lnv), z1(lnv),z2(lnv),z3(lnv),z4(lnv), z5(lnv),z6(lnv),z7(lnv),z8(lnv) common/aux9/vlrho(lnv),det(lnv) common/aux10/ 1 px1(lnv),px2(lnv),px3(lnv),px4(lnv), px5(lnv),px6(lnv),px7(lnv),px8(lnv), 2 py1(lnv),py2(lnv),py3(lnv),py4(lnv), py5(lnv),py6(lnv),py7(lnv),py8(lnv), 3 pz1(lnv),pz2(lnv),pz3(lnv),pz4(lnv), pz5(lnv),pz6(lnv),pz7(lnv),pz8(lnv), 4 vx1(lnv),vx2(lnv),vx3(lnv),vx4(lnv), 5 vx5(lnv),vx6(lnv),vx7(lnv),vx8(lnv), 6 vy1(lnv),vy2(lnv),vy3(lnv),vy4(lnv), 7 vy5(lnv),vy6(lnv),vy7(lnv),vy8(lnv), 8 vz1(lnv),vz2(lnv),vz3(lnv),vz4(lnv), 9 vz5(lnv),vz6(lnv),vz7(lnv),vz8(lnv) common/aux32/a17(lnv),a28(lnv),dett(lnv), 1 aj1(lnv),aj2(lnv),aj3(lnv),aj4(lnv), 2 aj5(lnv),aj6(lnv),aj7(lnv),aj8(lnv), 3 aj9(lnv),x17(lnv),x28(lnv),x35(lnv), 4 x46(lnv),y17(lnv),y28(lnv),y35(lnv), 5 y46(lnv),z17(lnv),z28(lnv),z35(lnv),z46(lnv) common/aux33/ix1(lnv),ix2(lnv),ix3(lnv),ix4(lnv),ix5(lnv), 1 ix6(lnv),ix7(lnv),ix8(lnv),mxt(lnv),nmel common/aux36/lft,llt common/failu/sieu(lnv),failu(lnv) common/sand1/ihf,ibemf,ishlf,itshf dimension aj5968(lnv),aj6749(lnv),aj4857(lnv),aji1(lnv),aji2(lnv), 1 aji3(lnv),aji4(lnv),aji5(lnv), 1 aji6(lnv),aji7(lnv),aji8(lnv),aji9(lnv),aj12(lnv), 2 aj45(lnv),aj78(lnv),b17(lnv),b28(lnv),c17(lnv),c28(lnv) c equivalence (x17,aj5968),(x28,aj6749),(x35,aj4857),(x46,aji1), 1 (y17,aji2),(y28,aji3),(y35,aji4),(y46,aji5),(z17,aji6), 2 (z28,aji7),(z35,aji8),(z46,aji9),(aj1,aj12),(aj2,aj45), 3 (aj3,aj78),(px1,b17),(px2,b28),(px3,c17),(px4,c28) data o64th/0.0156250/ c c jacobian matrix c do 10 i=lft,llt x17(i)=x7(i)-x1(i) x28(i)=x8(i)-x2(i) x35(i)=x5(i)-x3(i) x46(i)=x6(i)-x4(i) y17(i)=y7(i)-y1(i) y28(i)=y8(i)-y2(i) y35(i)=y5(i)-y3(i) y46(i)=y6(i)-y4(i) z17(i)=z7(i)-z1(i) z28(i)=z8(i)-z2(i) z35(i)=z5(i)-z3(i) 10 z46(i)=z6(i)-z4(i) do 20 i=lft,llt aj1(i)=x17(i)+x28(i)-x35(i)-x46(i) aj2(i)=y17(i)+y28(i)-y35(i)-y46(i)
[Bug c++/32288] Our C++ program (gcc 4.1.1 under Aix 5.3) crashes with a core dump
--- Comment #2 from alessandro dot mei at elsagdatamat dot com 2007-06-12 13:42 --- (From update of attachment 13685) the complete command line that triggers the bug: /home/mag/sviluppo/bin/bkeuti /home/mag/sviluppo/config/bkeuti.xml /home/mag/sviluppo/config/processi.dtd /dev/null The stack content relative to the core file is the following: (gdb) where #0 0xd1514a98 in _ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base ( __x=incomplete type) at ../../../../gcc-4.1.1/libstdc++-v3/src/tree.cc:68 #1 0x10019fac in _ZNSt17_Rb_tree_iteratorISt4pairIKSsP6CTimerEEppEi ( this=incomplete type) at /usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/4.1.1/../../../../include/c++/4 .1.1/bits/stl_tree.h:190 #2 0x100200b0 in _ZN13bus_CProcesso17azioniDiBackGroudEv ( this=incomplete type) at bus_CProcesso.cpp:838 #3 0x10022750 in _ZN13bus_CProcesso3vaiEbi (this=incomplete type, bSync=false, intSec=1) at bus_CProcesso.cpp:458 #4 0x10022e18 in _ZN22bus_CProcessoExceptionC1Ev (this=incomplete type) at bus_CProcesso.hpp:88 #5 0x10005054 in main (argc=3, argv=0x2ff22934, envp=0x2ff22944) at bkeuti.cpp:655 #6 0x1214 in __start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32288
[Bug c++/32288] Our C++ program (gcc 4.1.1 under Aix 5.3) crashes with a core dump
--- Comment #3 from alessandro dot mei at elsagdatamat dot com 2007-06-12 13:48 --- the exact version of GCC; the system type; the options given when GCC was configured/built; gcc -v Using built-in specs. Target: powerpc-ibm-aix5.3.0.0 Configured with: ../gcc-4.1.1/configure --disable-nls Thread model: aix gcc version 4.1.1 -- alessandro dot mei at elsagdatamat dot com changed: What|Removed |Added CC||alessandro dot mei at ||elsagdatamat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32288
[Bug target/32288] Our C++ program (gcc 4.1.1 under Aix 5.3) crashes with a core dump
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c++ |target GCC target triplet||owerpc-ibm-aix5.3.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32288
[Bug tree-optimization/32303] New: [4.3 Regression] SPEC2006 447.dealII miscompiled at -O3
See PR30252 comment #30 for bug analysis and a patch. -- Summary: [4.3 Regression] SPEC2006 447.dealII miscompiled at -O3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code, alias Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32303
[Bug target/32288] Our C++ program (gcc 4.1.1 under Aix 5.3) crashes with a core dump
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-12 14:01 --- And why do you think GCC is at fault? It is hard to debug this huge sources really. Have you tried to pin point exactly where the issue. Do you have any uninitialized variables? Are you going over array bounds? Do you take an address of a local variable and keep it around even after it goes out of scope? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32288
[Bug tree-optimization/32303] [4.3 Regression] SPEC2006 447.dealII miscompiled at -O3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32303
[Bug fortran/32289] mips version of gfortran produces internal compiler error
--- Comment #6 from michael dot a dot richmond at nasa dot gov 2007-06-12 14:04 --- When you build gcc and gfortran on your mips box, do you specify your system type as mips-unknown-linux-gnu or as mips64-unknown-linux-gnu? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
[Bug c++/32304] New: ICE in set_mem_attributes_minus_bitpos
cat bug.ii
struct S {
S() {}
};
S f() {
static S s;
return s;
}
g++ -O bug.ii
bug2.ii: In function S f():
bug2.ii:6: internal compiler error: in set_mem_attributes_minus_bitpos, at
emit-rtl.c:1573
--
Summary: ICE in set_mem_attributes_minus_bitpos
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32304
[Bug fortran/32289] mips version of gfortran produces internal compiler error
--- Comment #7 from tbm at cyrius dot com 2007-06-12 14:12 --- mips-linux-gnu, as the Debian package does. Why? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
[Bug c++/32305] New: ICE in initialize_flags_in_bb with -O -fipa-pta
cat bug.ii
struct S1 {
S1() {}
};
struct S2 {
void f2() {
static S1 s1;
}
};
void f(S2 s2) {
s2.f2();
}
g++ -O -fipa-pta bug.ii
bug1.ii: In function void f(S2):
bug1.ii:9: internal compiler error: in initialize_flags_in_bb, at
tree-into-ssa.c:437
--
Summary: ICE in initialize_flags_in_bb with -O -fipa-pta
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32305
[Bug middle-end/32304] [4.3 Regression] ICE in set_mem_attributes_minus_bitpos
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-12 14:20 --- readonly is set on this decl which is wrong. I think I know what is wrong. ipa-reference.c sets TREE_READONLY on the decl when it really should not be (even though it is readonly now). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c++ |middle-end Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-06-12 14:20:18 date|| Summary|ICE in |[4.3 Regression] ICE in |set_mem_attributes_minus_bit|set_mem_attributes_minus_bit |pos |pos Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32304
[Bug middle-end/32304] [4.3 Regression] ICE in set_mem_attributes_minus_bitpos
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-12 14:22 --- *** Bug 31685 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32304
[Bug middle-end/31685] [4.3 regression] ICE in set_mem_attributes
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-12 14:22 --- I am going to mark this as a dup of bug 32304 (even though that is newer) because it has a short testcase and I added some anyalsis to the problem there. *** This bug has been marked as a duplicate of 32304 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31685
[Bug fortran/32289] mips version of gfortran produces internal compiler error
--- Comment #8 from michael dot a dot richmond at nasa dot gov 2007-06-12 14:33 --- (In reply to comment #7) mips-linux-gnu, as the Debian package does. Why? When I run the configure script on an SGI Indy under Debian 4.0, it sets the system type to mips64-unknown-linux-gnu, and sets the ABI to N32. When I run the configure script under Debian 3.1, it sets the system type to mips-unknown-linux-gnu, and sets the ABI to 32. Which ABI do you use? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
[Bug tree-optimization/32306] New: Bad Code generation ( Tree optimization )
For the following Code Snippet
void bar ()
{
b1 = foo(1);
b2 = foo(1);
b3 = foo(1);
b4 = foo(1);
b5 = foo(1);
b6 = foo(1);
b7 = foo(1);
b8 = foo(1);
b9 = foo(1);
b10 = foo(1);
b11 = foo(1);
b12 = foo(1);
array[0] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[1] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[2] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[3] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[4] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[5] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[6] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[7] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[8] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[9] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[10] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
return;
}
Where b ( from b1 to b12) are all declared static short b1, static short b2
etc.
and array is static short array[11].
This should generate code such as
if (b1 == 0) goto L1 else goto L2
L2:
if (b2 == 0) goto L1 else goto L3
L3:
if (b3 == 0) goto L1 else goto L4
L4:
if (b4 == 0) goto L1 else goto L5
L5:
if (b5 == 0) goto L1 else goto L6
L6:
if (b6 == 0) goto L1 else goto L7
L7:
if (b7 == 0) goto L1 else goto L8
L8:
if (b8 == 0) goto L1 else goto L9
L9:
if (b9 == 0) goto L1 else goto L10
L10:
if (b10 == 0) goto L1 else goto L11
L11:
if (b11 == 0) goto L1 else goto L12
L12:
if (b12 == 0) goto L1 else goto L13
L13:
array[i]=1 (for i from 0 to 10)
return
L1:
array[i]=0 (for i from 0 to 10)
return
This is exactly what 4.1 generates but 4.3 fails to combine the if sequences.
Version Details:
GNU C version 4.3.0 20070316 (experimental) (arm-none-eabi)
compiled by GNU C version 3.4.6 (Ubuntu 3.4.6-1ubuntu2).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
--
Summary: Bad Code generation ( Tree optimization )
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pranav dot bhandarkar at gmail dot com
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug tree-optimization/32306] Bad Code generation ( Tree optimization )
--- Comment #1 from pranav dot bhandarkar at gmail dot com 2007-06-12 14:48 --- Created an attachment (id=13686) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13686action=view) Tes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug tree-optimization/32306] Bad Code generation ( Tree optimization )
--- Comment #2 from pranav dot bhandarkar at gmail dot com 2007-06-12 14:50 --- Created an attachment (id=13687) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13687action=view) Code Generated by 4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug tree-optimization/32306] Bad Code generation ( Tree optimization )
--- Comment #3 from pranav dot bhandarkar at gmail dot com 2007-06-12 14:50 --- Created an attachment (id=13688) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13688action=view) Code Generated by 4.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug tree-optimization/32306] [4.2/4.3 Regression] Bad Code generation ( Tree optimization )
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-12 15:06 --- Try to narrow it down to sth shorter. (Looks like a jump-threading issue) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|arm-none-eabi | Keywords||missed-optimization Known to work||4.1.2 Last reconfirmed|-00-00 00:00:00 |2007-06-12 15:06:52 date|| Summary|Bad Code generation ( Tree |[4.2/4.3 Regression] Bad |optimization ) |Code generation ( Tree ||optimization ) Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug c++/32305] ICE in initialize_flags_in_bb with -O -fipa-pta
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-12 15:08 --- trunk-g/gcc ./cc1plus -O -fipa-pta t.ii S1::S1() S1::S1() S1::S1() void S2::f2() void f(S2) Analyzing compilation unit Performing interprocedural optimizations visibility early_local_cleanups inline static-var pure-const pta t.ii: In member function 'void S2::f2()': t.ii:10: error: stmt (0x2b369f6d8780) marked modified after optimization pass: _ZGVZN2S22f2EvE2s1.0_1 = (char *) _ZGVZN2S22f2EvE2s1; t.ii:10: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-06-12 15:08:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32305
[Bug fortran/32302] [4.2/4.3 Regression] Incorrect result with -O2
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-12 15:09 --- Until I know for sure, i am moving this back to the fortran component, it might be a front end issuse still. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|middle-end |fortran Summary|[4.2, 4.3 Regression] |[4.2/4.3 Regression] |Incorrect result with -O2 |Incorrect result with -O2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
[Bug middle-end/32302] [4.2, 4.3 Regression] Incorrect result with -O2
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-12 15:03 --- Works with 4.1.3 20070521. Fails with 4.2.1 20070604. Fails with 4.3.0 20070612. (On x86_64 Linux) Result is ok (1.0 1.0) for real(4), but not for real(8) (0.25 0.25). -O1 is also ok, but not -O2. I used gfortran -DVECLEN=1 -DDP -O2 (and also without -DDP and with -O1.) Presumably a middle-end problem. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |middle-end Ever Confirmed|0 |1 GCC host triplet|powerpc-apple-darwin8.9.0 | Keywords||wrong-code Known to fail||4.2.0 4.3.0 Known to work||4.1.3 Last reconfirmed|-00-00 00:00:00 |2007-06-12 15:03:55 date|| Summary|gfortran - incorrect result |[4.2, 4.3 Regression] |with -O3|Incorrect result with -O2 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-06-12 15:15 --- I see those as well, on x86_64-unknown-linux-gnu FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -O0 scan-tree-dump pow FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -O1 scan-tree-dump pow FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -O2 scan-tree-dump pow FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -O3 -fomit-frame-pointer scan-tree-d ump pow FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -O3 -g scan-tree-dump pow FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -Os scan-tree-dump pow ./gcc/cc1 --version GNU C version 4.3.0 20070612 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.0 20070612 (experimental), GMP version 4.2.1, MPFR version 2.2.0. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug c/32307] New: ICE building simple httpd log.c for -m5282x option
The full command line is below. It appears to be triggered by -m528x and is
indepdendent of selected optimization level.
m68k-rtems4.8-gcc --pipe -DHAVE_CONFIG_H -I..
-I../../cpukit/../../../uC5282/lib/include -DHAVE_MD5 -Wall -fasm -m528x -O2
-g -MT libshttpd_a-log.o -MD -MP -MF .deps/libshttpd_a-log.Tpo -c -o
libshttpd_a-log.o `test -f 'log.c' || echo
'../../../../../../current/c/src/../../cpukit/shttpd/'`log.c
../../../../../../current/c/src/../../cpukit/shttpd/log.c: In function
'log_access':
../../../../../../current/c/src/../../cpukit/shttpd/log.c:111: error: insn does
not satisfy its constraints:
(insn 74 158 159 10
../../../../../../current/c/src/../../cpukit/shttpd/log.c:90 (set (mem/c:SI
(plus:SI (reg/f:SI 14 %a6)
(reg:SI 1 %d1)) [57 D.6863+0 S4 A16])
(mem/s:SI (plus:SI (reg/v/f:SI 10 %a2 [orig:48 c ] [48])
(const_int 220 [0xdc])) [22 variable.loc.io.total+0 S4 A16]))
34 {*movsi_cf} (nil)
(nil))
../../../../../../current/c/src/../../cpukit/shttpd/log.c:111: internal
compiler error: in reload_cse_simplify_operands, at postreload.c:393
Please submit a full bug report,
--
Summary: ICE building simple httpd log.c for -m5282x option
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-rtems4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32307
[Bug c/32307] ICE building simple httpd log.c for -m5282x option
--- Comment #1 from joel at gcc dot gnu dot org 2007-06-12 15:17 --- Created an attachment (id=13689) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13689action=view) preprocessed code to generate problem The following should reproduce the error: m68k-rtems4.8-gcc -m528x -c log_preprocessed.c I believe this should occur on any m68k target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32307
[Bug target/32307] ICE building simple httpd log.c for -m5282x option
--- Comment #2 from joel at gcc dot gnu dot org 2007-06-12 15:21 --- Tested using RTEMS cross RPMs for RTEMS 4.6 (gcc 3.2.3) and RTEMS 4.7 (gcc 4.1.1). -- joel at gcc dot gnu dot org changed: What|Removed |Added Known to fail||3.2.3 4.1.1 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32307
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-12 15:31 --- This is not a bug. Here is the deal, the reporter compiled GCC with the new headers but is using the old library (which is known to be buggy). -- 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=32258
[Bug target/32307] ICE building simple httpd log.c for -m5282x option
--- Comment #3 from joel at gcc dot gnu dot org 2007-06-12 15:39 --- Created an attachment (id=13690) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13690action=view) alternate version of bug file which has if 0 around offensive code I hacked on the file that tripped the bug and now have this one which has if 0's around the offensive code. It appears to have offensive sections. + an inline conditional + two calls to my_snprintf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32307
[Bug target/32288] Our C++ program (gcc 4.1.1 under Aix 5.3) crashes with a core dump
--- Comment #5 from alessandro dot mei at elsagdatamat dot com 2007-06-12 15:41 --- (In reply to comment #4) And why do you think GCC is at fault? It is hard to debug this huge sources really. Have you tried to pin point exactly where the issue. Do you have any uninitialized variables? Are you going over array bounds? Do you take an address of a local variable and keep it around even after it goes out of scope? We have tried to pin point exactly where the crash occurs. It is hard to debug the source really, we agree, however there is nothing strange at that line and that code works fine on the test server. We are using GCC 4.1.1 downloaded from aixpdslib UCLA ftp website. We suspect that the GCC binary downloaded from this ftp site had been compiled on an AIX 5.3 version different from the one we are using in the production server. So we are now asking support if our suspect could explain the crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32288
[Bug middle-end/32176] [4.3 Regression] ICE tree-type mismatch: expected integer_cst, have plus_expr in int_cst_value, at tree.c:7720
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-06-12 15:44 --- (In reply to comment #1) While the assert is occurs in the middle end, I think it is very likely a tree-type mismatch in the front end. I think it is. It also fails for me on i686-darwin, with -O2 -fprefetch-loop-arrays -m64. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2007-06-01 07:49:47 |2007-06-12 15:44:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32176
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-06-12 15:47 --- I see it also with today's compiler on i686-darwin: $ gfortran test.f90 -O2 ./a.out a.bb ccc -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2007-05-29 15:32:38 |2007-06-12 15:47:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug c++/32308] New: template typename T int CTemp int ::sta; make the error
gcc -v :
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
g++ -o a a.cpp
a.cpp: In function ¡®void func(T) [with T = int]¡¯:
a.cpp:19: instantiated from ¡®int CTempint::sta¡¯
a.cpp:19: instantiated from ¡®void func(T) [with T = int]¡¯
a.cpp:24: instantiated from here
a.cpp:19: internal compiler error: in instantiate_decl, at cp/pt.c:11775
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.1/README.Bugs.
Preprocessed source stored into /tmp/ccXG3CFA.out file, please attach this to
your bugreport.
Source File:
#includeiostream
using namespace std;
template class T
class CTemp{
private:
T element;
public:
CTemp (T arg):element(arg){ }
static int sta;
};
template typename T int CTemp int ::sta;
template class T
void func (T arg){
CTemp T a (arg);
int i;
cout a.sta endl;
return;
}
int main(){
func (5);
return 0;
}
I'm sorry but I find anywhere to add an attachment
--
Summary: template typename T int CTemp int ::sta; make the
error
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cxcxcxcx at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32308
[Bug fortran/32298] MINLOC / MAXLOC: off-by one for PARAMETER arrays
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-12 16:05 ---
The result is ok, if one removes PARAMETER.
If one looks at the dump one find the following difference between arrays which
are parameters and those which are variables:
-S.3 = 0;
+S.3 = 1;
while (1)
{
- if (S.3 6) goto L.3;
+ if (S.3 7) goto L.3;
- if (ABS_EXPR A.2[S.3] - D.1367 limit.1 || pos.0 == 0)
+ if (ABS_EXPR a[S.3 + -1] - D.1367 limit.1 || pos.0 ==
0)
{
- limit.1 = ABS_EXPR A.2[S.3] - D.1367;
+limit.1 = ABS_EXPR a[S.3 + -1] - D.1367;
-pos.0 = S.3;
+pos.0 = S.3;
(This might also affect MAXVAL/MINVAL, though I did not manage to cook up an
example.)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2007-06-12 16:05:26
date||
Summary|Intrinsic MINLOC / MAXLOC |MINLOC / MAXLOC: off-by one
|gives wrong results |for PARAMETER arrays
|(gfortran build 20070522) |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32298
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #7 from dcb314 at hotmail dot com 2007-06-12 16:05 --- (In reply to comment #5) I am finally getting around to testing the patch (been busy with a release of our own toolchain last week). I can confirm that this bug still exists in gcc snapshot 20070608. Is it significant that the last couple of months of gcc 4.3 haven't been able to compile recent Linux kernels ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug c++/32308] template typename T int CTemp int ::sta; make the error
--- Comment #1 from cxcxcxcx at gmail dot com 2007-06-12 16:08 --- Created an attachment (id=13691) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13691action=view) The ii file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32308
[Bug fortran/32298] MINLOC / MAXLOC: off-by one for PARAMETER arrays
-- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org GCC target triplet|i386-pc-mingw32 | Known to fail||4.3.0 4.2.0 4.1.3 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32298
[Bug fortran/32289] mips version of gfortran produces internal compiler error
--- Comment #9 from tbm at cyrius dot com 2007-06-12 16:31 --- O32, just like Debian. Note that 4.0 also uses O32, although the kernel is 64-bit, so that might explain why it's configuring mips64 for you. I don't see the point of these questions though. After all, I confirmed your bug with gcc 4.1, and also that it's fixed in 4.2 and 4.3. So the remaining question is whether this will be fixed in 4.1 (which I doubt). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
[Bug target/32301] int __attribute__((vector_size(8))) doesn't use %mm0, produces ugly code
--- Comment #2 from tomash dot brechko at gmail dot com 2007-06-12 16:43 --- Sorry, I failed to find two other reports you reference, maybe I'm repeating someone's questions then. Okay, there are reasons not to use %mm0, but why %xmm0 is not used then? Something like f: movqb, %xmm0 movqa, %xmm1 paddd %xmm1, %xmm0 movq%xmm0, c ret And the other question is if copying of vector onto the stack is a misfeature, or there are reasons for doing that in synthesized vector operations, so this won't change. Thank you! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32301
[Bug tree-optimization/32309] New: Unnecessary conversion from short to unsigend short breaks vectorization
void Sub(short * __restrict src1row, short * __restrict src2row, int
num_in_row) {
for(int i=num_in_row; i--;) {
*src1row -= *src2row;
++src1row;
++src2row;
}
}
In the test case above, GCC inserts several explicit conversions soon after the
gimple transformation stage and gets,
D.2097 = *src1row;
D.2098 = (short unsigned int) D.2097;
D.2099 = *src2row;
D.2100 = (short unsigned int) D.2099;
D.2101 = D.2098 - D.2100;
D.2102 = (short int) D.2101;
These conversions breaks the vectorization and GCC reports,
/* i686-unknown-linux-gnu-gcc -O3 -ftree-vectorize -ftree-vectorizer-verbose=5
-march=nocona -fno-strict-aliasing -c test.cc */
..
test.cc:2: note: not vectorized: relevant stmt not supported: D.2430_11 =
(short unsigned int) D.2429_10
test.cc:1: note: vectorized 0 loops in function.
--
Summary: Unnecessary conversion from short to unsigend short
breaks vectorization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gangren at google dot com
GCC build triplet: i686-unknown-linux-gnu-gcc
GCC host triplet: i686-unknown-linux-gnu-gcc
GCC target triplet: i686-unknown-linux-gnu-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32309
[Bug tree-optimization/32309] Unnecessary conversion from short to unsigend short breaks vectorization
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-12 17:20 --- The conversions are not Unnecessary, they are necessary because short_var+short_var when that would overflow the range of short is still defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32309
[Bug fortran/32310] New: Intel-darwin specific ICE on CP2K code
I'm working towards reducing this, but it's coming slowly :( The code attached leads to an ICE with: $ gfortran -c -O0 qs_mo_types.f90 gfortran: Internal error: Illegal instruction (program f951) The backtrace for the ICE is: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xbf7fffec 0x000688fd in gfc_free_equiv_lists (l=Cannot access memory at address 0xbf70 0x44567150) at /tmp/gfortran-20070611/ibin/../gcc/gcc/fortran/symbol.c:2621 2621 gfc_free_equiv_lists (l-next); (gdb) where #0 0x000688fd in gfc_free_equiv_lists (l=0x44567150) at /tmp/gfortran-20070611/ibin/../gcc/gcc/fortran/symbol.c:2621 I wonder if this was introduced by Paul's patch recent for multiple equivalences. Paul, do you have any idea (I know you have no access to darwin, but I can debug for you if you so wish). I could not reproduce this on i386-linux (even with valgrind). -- Summary: Intel-darwin specific ICE on CP2K code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC build triplet: i386-apple-darwin8.8.1 GCC host triplet: i386-apple-darwin8.8.1 GCC target triplet: i386-apple-darwin8.8.1 OtherBugsDependingO 29975 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32310
[Bug tree-optimization/32309] Unnecessary conversion from short to unsigend short breaks vectorization
--- Comment #2 from gangren at google dot com 2007-06-12 17:28 --- (In reply to comment #1) The conversions are not Unnecessary, they are necessary because short_var+short_var when that would overflow the range of short is still defined. Do you mean that short_var + short_var is defined as (short)((unsigned short)short_var + (unsigned short)short_var)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32309
[Bug c/32311] New: fprintf prints only a part of a string if the string has \x00
when I do FILE *f = fopen(...); double k = 10; fprintf(file, k\x00%f, k); only the string k will be written to the file (And this is the problem, since I want the strings k and 10.0 to be separated by the symbol with the code 0). If I do fprintf(file, k\0x20%f, k); then the correct string k 10.0 will be written to the file. gcc -v: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4) -- Summary: fprintf prints only a part of a string if the string has \x00 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andrei dot kouznetsov at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32311
[Bug tree-optimization/32309] Unnecessary conversion from short to unsigend short breaks vectorization
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-12 17:36 --- Do you mean that short_var + short_var is defined as (short)((unsigned short)short_var + (unsigned short)short_var)? Kinda, because it is really defined by the C standard as: (short)((int)short_var + (int)short_var) And then GCC's middle-end optimizes it to: (short)((unsigned short)short_var + (unsigned short)short_var) *** This bug has been marked as a duplicate of 26128 *** -- 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=32309
[Bug tree-optimization/26128] Trivial operation not vectorized on char/short
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-12 17:36 --- *** Bug 32309 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gangren at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26128
[Bug c/32311] fprintf prints only a part of a string if the string has \x00
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-12 17:40 --- This is correct behavior because strings are really char arrays terminated by the null character (0 aka '\x00') so when you write k\x00%f, you really have a string that is only of length 1. -- 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=32311
[Bug tree-optimization/32309] Unnecessary conversion from short to unsigend short breaks vectorization
--- Comment #4 from dorit at il dot ibm dot com 2007-06-12 17:46 --- it's on my (long) todo list... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32309
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #177 from ian at gcc dot gnu dot org 2007-06-12 17:47 --- Subject: Bug 29286 Author: ian Date: Tue Jun 12 17:47:37 2007 New Revision: 125653 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125653 Log: ./: PR libstdc++/29286 * tree.def: Add CHANGE_DYNAMIC_TYPE_EXPR. * tree.h (CHANGE_DYNAMIC_TYPE_NEW_TYPE): Define. (CHANGE_DYNAMIC_TYPE_LOCATION): Define. (DECL_NO_TBAA_P): Define. (struct tree_decl_common): Add no_tbaa_flag field. * tree-ssa-structalias.c (struct variable_info): Add no_tbaa_pruning field. (new_var_info): Initialize no_tbaa_pruning field. (unify_nodes): Copy no_tbaa_pruning field. (find_func_aliases): Handle CHANGE_DYNAMIC_TYPE_EXPR. (dump_solution_for_var): Print no_tbaa_pruning flag. (set_uids_in_ptset): Add no_tbaa_pruning parameter. Change all callers. (compute_tbaa_pruning): New static function. (compute_points_to_sets): Remove CHANGE_DYNAMIC_TYPE_EXPR nodes. Call compute_tbaa_pruning. * tree-ssa-alias.c (may_alias_p): Test no_tbaa_flag for pointers. * gimplify.c (gimplify_expr): Handle CHANGE_DYNAMIC_TYPE_EXPR. * gimple-low.c (lower_stmt): Likewise. * tree-gimple.c (is_gimple_stmt): Likewise. * tree-ssa-operands.c (get_expr_operands): Likewise. * tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Likewise. * tree-inline.c (estimate_num_insns_1): Likewise. (copy_result_decl_to_var): Likewise. * expr.c (expand_expr_real_1): Likewise. * tree-pretty-print.c (dump_generic_node): Likewise. * tree-inline.c (copy_decl_to_var): Copy DECL_NO_TBAA_P flag. * omp-low.c (omp_copy_decl_2): Likewise. * print-tree.c (print_node): Print DECL_NO_TBAA_P flag. * doc/c-tree.texi (Expression trees): Document CHANGE_DYNAMIC_TYPE_EXPR. cp/: PR libstdc++/29286 * init.c (avoid_placement_new_aliasing): New static function. (build_new_1): Call it. testsuite/: PR libstdc++/29286 * g++.dg/init/new16.C: New test. * g++.dg/init/new17.C: New test. * g++.dg/init/new18.C: New test. * g++.dg/init/new19.C: New test. Added: trunk/gcc/testsuite/g++.dg/init/new16.C trunk/gcc/testsuite/g++.dg/init/new17.C trunk/gcc/testsuite/g++.dg/init/new18.C trunk/gcc/testsuite/g++.dg/init/new19.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/doc/c-tree.texi trunk/gcc/expr.c trunk/gcc/gimple-low.c trunk/gcc/gimplify.c trunk/gcc/omp-low.c trunk/gcc/print-tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-gimple.c trunk/gcc/tree-inline.c trunk/gcc/tree-pretty-print.c trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-dce.c trunk/gcc/tree-ssa-operands.c trunk/gcc/tree-ssa-structalias.c trunk/gcc/tree.def trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor
--- Comment #15 from rob1weld at aol dot com 2007-06-12 17:50 --- Correctly Rounded mathematical library http://lipforge.ens-lyon.fr/www/crlibm/index.html CRlibm, an efficient and proven correctly-rounded mathematical library CRlibm is a free mathematical library (libm) which provides: * implementations of the double-precision C99 standard elementary functions, * correctly rounded in the four IEEE-754 rounding modes, * with a comprehensive proof of both the algorithms used and their implementation, * sufficiently efficient in average time, worst-case time, and memory consumption to replace existing libms transparently, CRlibm is distributed under the GNU Lesser General Public License (LGPL). Included in the distribution is an extensive documentation with the proof of each function (currently more than 100 pages), as well as all the Maple scripts used to develop the functions. This makes this library an excellent tutorial on software elementary function development. Note than they provide proof for the library. I'll examine this link more closely. Nearly finished my patch testing - may be a few days. Some functions are _many_ times faster than MPFR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180
[Bug tree-optimization/32309] Unnecessary conversion from short to unsigend short breaks vectorization
--- Comment #5 from gangren at google dot com 2007-06-12 17:53 --- (In reply to comment #3) Do you mean that short_var + short_var is defined as (short)((unsigned short)short_var + (unsigned short)short_var)? Kinda, because it is really defined by the C standard as: (short)((int)short_var + (int)short_var) And then GCC's middle-end optimizes it to: (short)((unsigned short)short_var + (unsigned short)short_var) *** This bug has been marked as a duplicate of 26128 *** I'm aware of integral promotion. But not quite understand why we can optimize (short)((int)short_var + (int)short_var) to (short)((unsigned short)short_var + (unsigned short)short_var), but not to (short)((short)short_var + (short)short_var)? Is it because unsigned short has different overflow handling? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32309
Re: [Bug tree-optimization/32309] Unnecessary conversion from short to unsigend short breaks vectorization
On 12 Jun 2007 17:53:19 -, gangren at google dot com [EMAIL PROTECTED] wrote: I'm aware of integral promotion. But not quite understand why we can optimize (short)((int)short_var + (int)short_var) to (short)((unsigned short)short_var + (unsigned short)short_var), but not to (short)((short)short_var + (short)short_var)? Is it because unsigned short has different overflow handling? Yes, signed short has undefined overflow, while unsigned is defined as wrapping. --Pinski
[Bug tree-optimization/32309] Unnecessary conversion from short to unsigend short breaks vectorization
--- Comment #6 from pinskia at gmail dot com 2007-06-12 17:56 --- Subject: Re: Unnecessary conversion from short to unsigend short breaks vectorization On 12 Jun 2007 17:53:19 -, gangren at google dot com [EMAIL PROTECTED] wrote: I'm aware of integral promotion. But not quite understand why we can optimize (short)((int)short_var + (int)short_var) to (short)((unsigned short)short_var + (unsigned short)short_var), but not to (short)((short)short_var + (short)short_var)? Is it because unsigned short has different overflow handling? Yes, signed short has undefined overflow, while unsigned is defined as wrapping. --Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32309
[Bug tree-optimization/32309] Unnecessary conversion from short to unsigend short breaks vectorization
--- Comment #7 from gangren at google dot com 2007-06-12 18:10 --- (In reply to comment #6) Subject: Re: Unnecessary conversion from short to unsigend short breaks vectorization On 12 Jun 2007 17:53:19 -, gangren at google dot com [EMAIL PROTECTED] wrote: I'm aware of integral promotion. But not quite understand why we can optimize (short)((int)short_var + (int)short_var) to (short)((unsigned short)short_var + (unsigned short)short_var), but not to (short)((short)short_var + (short)short_var)? Is it because unsigned short has different overflow handling? Yes, signed short has undefined overflow, while unsigned is defined as wrapping. --Pinski Thanks. So even if the underlining architecture does not trigger an overflow on signed short (like AltiVec if I remember correctly), we still need to have such conversions? In addition, does undefined overflow include no overflow? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32309
[Bug fortran/32310] Intel-darwin specific ICE on CP2K code
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-06-12 18:10 --- Created an attachment (id=13692) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13692action=view) Testcase and module files that generate the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32310
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #178 from ian at airs dot com 2007-06-12 18:10 --- Fixed on mainline. No plans to backport the patch to previous releases. -- ian at airs dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to work|3.4.0 |3.4.0 4.3.0 Resolution||FIXED Target Milestone|4.2.1 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #5 from zadeck at naturalbridge dot com 2007-06-12 18:13 --- This bug should be assigned to Mircea Namolaru [EMAIL PROTECTED]. I have sent him mail asking that he get a proper bugzilla id. == The underlying problem is that see.c:2732 uses copy_rtx to make a copy of an insn and then hacks on it with validate_change (and it's close relatives). This is not the approved way to copy an insn. The copy_rtx function has two problems with df: 1) The copy has a basic_block, even though it is not in the insn stream, 2) The copy has the same insn_uid as the old insn. This is not legal and confuses df which keeps side info indexed by the insn_uid. There are several proper ways to make a copy of an insn: 1) call make_insn_raw (copy_rtx (PATTERN (ref))). 2) However, according to Ian Taylor, a middle end maintainer, the better thing to do would be to copy the pattern of the insn, not the insn itself and then hack on that. However, you then make a move insn and hack the modified copy so that it is right next to the move. What you should do insert the copy before the new move using one of the calls in emit_rtl such as add_insn_before. No one is supposed to hack the next and prev insn themselves. The rest of the pass appears to be df ready. Of course until it is tested it most likely does not work. And so adding some regression tests would be good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug middle-end/32304] [4.3 Regression] ICE in set_mem_attributes_minus_bitpos
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-12 18:16 --- The patch which fixes the problem: Index: ipa-reference.c === --- ipa-reference.c (revision 125637) +++ ipa-reference.c (working copy) @@ -269,6 +269,10 @@ if (DECL_EXTERNAL (t) || TREE_PUBLIC (t)) return false; + /* We cannot touch decl's whos types need constructing. */ + if (TYPE_NEEDS_CONSTRUCTING (TREE_TYPE (t))) +return false; + /* This is a variable we care about. Check if we have seen it before, and if not add it the set of variables we care about. */ if (!bitmap_bit_p (all_module_statics, DECL_UID (t))) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32304
[Bug tree-optimization/32309] Unnecessary conversion from short to unsigend short breaks vectorization
--- Comment #8 from ian at airs dot com 2007-06-12 18:25 --- Undefined signed overflow is a language issue, not a processor issue. When signed overflow is undefined, the compiler can and does make certain assumptions about the results of operations. For example, it assumes that a + 1 a is always true. In this case gcc is trying to optimize by doing the computation in short rather than int. But since the language requires that the computation be done in int, gcc has to make sure to get the same result. If the computation were done in short, and if later compilation passes could prove that the computation overflowed in short, then the result would be different than if the computation were done in int. -- ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32309
[Bug c++/32308] [4.1/4.2/4.3 Regression] template typename T int CTemp int ::sta; make the error
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-12 18:46 --- should read template int CTemp int ::sta; because t.C(13): error: CTempint is not a class template template class T int CTemp int ::sta; ^ -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Known to work||3.4.6 Last reconfirmed|-00-00 00:00:00 |2007-06-12 18:46:57 date|| Summary|template typename T int |[4.1/4.2/4.3 Regression] |CTemp int ::sta; make the |template typename T int |error |CTemp int ::sta; make the ||error Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32308
[Bug tree-optimization/32309] Unnecessary conversion from short to unsigend short breaks vectorization
--- Comment #9 from gangren at google dot com 2007-06-12 18:58 --- (In reply to comment #8) if later compilation passes could prove that the computation overflowed in short, then the result would be different than if the computation were done in int. The result could be different. But in some cases, such as this example, the result (variable) would be the same. In general, integral promotion might not be necessary when both destination and sources are short integers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32309
[Bug c++/32308] [4.1/4.2/4.3 Regression] template typename T int CTemp int ::sta; make the error
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-12 19:02 --- *** This bug has been marked as a duplicate of 24791 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32308
[Bug c++/24791] ICE on invalid instantiation of template's static member
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-12 19:02 --- *** Bug 32308 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||cxcxcxcx at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24791
[Bug rtl-optimization/31987] [4.3 Regression] ICE in remove_insn, at emit-rtl.c:3579 at -O3
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-12 19:13 --- Looks like the dataflow merge now exposes this to SPEC2000 FDO runs on x86_64 for wupwise and gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31987
[Bug middle-end/31579] [4.3 regression] ICE when compiling attached code
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-12 19:16 --- Subject: Bug 31579 Author: pinskia Date: Tue Jun 12 19:15:50 2007 New Revision: 125655 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125655 Log: 2007-06-12 Andrew Pinski [EMAIL PROTECTED] PR middle-end/31579 * expr.c (expand_expr_addr_expr_1): Call expand_expr for the offset with the modifier as EXPAND_INITIALIZER if the modifier is EXPAND_INITIALIZER. (expand_expr_real_1 case INTEGER_CST): Don't force to a register if we had an overflow. 2007-06-12 Andrew Pinski [EMAIL PROTECTED] PR middle-end/31579 * g++.dg/torture/pr31579.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr31579.C Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31579
[Bug middle-end/31579] [4.3 regression] ICE when compiling attached code
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-06-12 19:16 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31579
[Bug middle-end/30905] [4.3 Regression] Fails to cross-jump
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-12 19:17 --- Now in mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.2.0 Summary|[dataflow] Fails to cross- |[4.3 Regression] Fails to |jump|cross-jump Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
[Bug bootstrap/32312] New: [4.3.0 regression] bootstrap failure on sparc-sun-solaris2.10
I'm getting a new bootstrap failure on sparc-sun-solaris2.10 in stage1 building libgcc2.a: /tmp/kg/pat/build/./gcc/xgcc -B/tmp/kg/pat/build/./gcc/ -B/usr/local/sparc-sun-solaris2.10/bin/ -B/usr/local/sparc-sun-solaris2.10/lib/ -isystem /usr/local/sparc-sun-solaris2.10/include -isystem /usr/local/sparc-sun-solaris2.10/sys-include -O2 -g -O2 -O2 -g -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../egcc-SVN20070612/libgcc -I../../../egcc-SVN20070612/libgcc/. -I../../../egcc-SVN20070612/libgcc/../gcc -I../../../egcc-SVN20070612/libgcc/../include -o _absvdi2.o -MT _absvdi2.o -MD -MP -MF _absvdi2.dep -DL_absvdi2 -c ../../../egcc-SVN20070612/libgcc/../gcc/libgcc2.c \ ../../../egcc-SVN20070612/libgcc/../gcc/libgcc2.c: In function '__absvdi2': ../../../egcc-SVN20070612/libgcc/../gcc/libgcc2.c:280: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [_absvdi2.o] Error 1 -- Summary: [4.3.0 regression] bootstrap failure on sparc-sun- solaris2.10 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32312
[Bug bootstrap/32312] [4.3.0 regression] bootstrap failure on sparc-sun-solaris2.10
--- Comment #1 from ghazi at gcc dot gnu dot org 2007-06-12 20:37 ---
This worked as of June 9th, so it's recent.
The SEGV happens because df (used in the macro DF_REG_DEF_COUNT) is nil:
signal SEGV (no mapping at the fault address) in sparc_check_64 at line 7677 in
file sparc.c
7677 DF_REG_DEF_COUNT (REGNO (y)) == 1)
(dbx) where
=[1] sparc_check_64(x = 0xff168620, insn = 0xff123810), line 7677 in sparc.c
[2] output_v8plus_shift(operands = 0x1f07484, insn = 0xff123810, opcode =
0x1e8e364 srax), line 7741 in sparc.c
[3] output_363(operands = 0x1f07484, insn = 0xff123810), line 6499 in
sparc.md
[4] get_insn_template(code = 363, insn = 0xff123810), line 1584 in final.c
[5] final_scan_insn(insn = 0xff123810, file = 0x1f013c8, optimize = 2,
nopeepholes = 0, seen = 0xffbff22c), line 2460 in final.c
[6] final(first = 0xff123658, file = 0x1f013c8, optimize = 2), line 1569 in
final.c
[7] rest_of_handle_final(), line 3973 in final.c
[8] execute_one_pass(pass = 0x1ec37ec), line 1124 in passes.c
[9] execute_pass_list(pass = 0x1ec37ec), line 1177 in passes.c
[10] execute_pass_list(pass = 0x1ec3d94), line 1178 in passes.c
[11] execute_pass_list(pass = 0x1ec3d60), line 1178 in passes.c
[12] tree_rest_of_compilation(fndecl = 0xff154d20), line 406 in
tree-optimize.c
[13] c_expand_body(fndecl = 0xff154d20), line 4331 in c-common.c
[14] cgraph_expand_function(node = 0xff15fb30), line 1073 in cgraphunit.c
[15] cgraph_expand_all_functions(), line 1142 in cgraphunit.c
[16] cgraph_optimize(), line 1349 in cgraphunit.c
[17] c_write_global_declarations(), line 7911 in c-decl.c
[18] compile_file(), line 1064 in toplev.c
[19] do_compile(), line 2150 in toplev.c
[20] toplev_main(argc = 25U, argv = 0xffbff92c), line 2182 in toplev.c
[21] main(argc = 25, argv = 0xffbff92c), line 35 in main.c
(dbx) list
7677 DF_REG_DEF_COUNT (REGNO (y)) == 1)
7678 set_once = 1;
7679
7680 if (insn == 0)
7681 {
7682 if (set_once)
7683 insn = get_last_insn_anywhere ();
7684 else
7685 return 0;
7686 }
(dbx) print df
df = (nil)
(dbx)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32312
