[Bug c/43417] New: ICE : in final_scan_insn, at final.c:2604
I found a bug of ICE in gcc-4.4.3 on sh-elf.
gcc-4.3 and gcc-4.5 does not have this problem.
$ gcc -O2 mtest01-k-e.c
mtest01-k.c: In function emainf:
mtest01-k.c:88: error: could not split insn
(jump_insn 312 302 472 mtest01-k.c:64 (parallel [
(set (pc)
(if_then_else (leu (reg/v:DI 12 r12 [orig:310 maxbytes ] [310])
(const_int 1073741824 [0x4000]))
(label_ref:SI 516)
(pc)))
(clobber (reg:SI 10 r10))
(clobber (reg:SI 147 t))
]) 6 {cbranchdi4_i} (expr_list:REG_BR_PRED (const_int 49 [0x31])
(expr_list:REG_UNUSED (reg:SI 147 t)
(expr_list:REG_UNUSED (reg:SI 10 r10)
(expr_list:REG_BR_PROB (const_int 0 [0x0])
(nil))
mtest01-k.c:88: internal compiler error: in final_scan_insn, at final.c:2604
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions.
When I don't optimize it, it doesn't become the error.
$ gcc-4.4 -v
Using built-in specs.
Target: sh4-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.3-3'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--with-multilib-list=m4,m4-nofpu --with-cpu=sh4 --enable-checking=release
--build=sh4-linux-gnu --host=sh4-linux-gnu --target=sh4-linux-gnu
Thread model: posix
gcc version 4.4.3 (Debian 4.4.3-3)
--
Summary: ICE : in final_scan_insn, at final.c:2604
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iwamatsu at nigauri dot org
GCC build triplet: sh4-linux-gnu
GCC host triplet: sh4-linux-gnu
GCC target triplet: sh4-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43417
[Bug target/43399] [4.5 Regression] bootstrap failure in stage1
--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-18 07:16 --- BTW, if the PRE_MODIFY representation doesn't work well, I'd say just using a PARALLEL with what the insn really does and checking that in the match_parallel predicate probably wouldn't clash with anything else. If it would, you'd need to insert one UNSPEC somewhere. The comments say that currently the pattern looks like: (parallel [ (set (mem:BLK (pre_dec:BLK (reg:SI sp))) (unspec:BLK [(reg:SI r4)] UNSPEC_PUSH_MULT)) (use (reg:SI 11 fp)) (use (reg:SI 12 ip)) (use (reg:SI 14 lr)) (use (reg:SI 15 pc)) ]) with the REG_FRAME_RELATED_EXPR: (sequence [ (set (reg:SI sp) (plus:SI (reg:SI sp) (const_int -20))) (set (mem:SI (reg:SI sp)) (reg:SI r4)) (set (mem:SI (plus:SI (reg:SI sp) (const_int 4))) (reg:SI fp)) (set (mem:SI (plus:SI (reg:SI sp) (const_int 8))) (reg:SI ip)) (set (mem:SI (plus:SI (reg:SI sp) (const_int 12))) (reg:SI lr)) ]) So, would a parallel like: (parallel [ (set (mem:SI (plus:SI (reg:SI sp) (const_int -20))) (reg:SI r4)) (set (mem:SI (plus:SI (reg:SI sp) (const_int -16))) (reg:SI fp)) (set (mem:SI (plus:SI (reg:SI sp) (const_int -12))) (reg:SI ip)) (set (mem:SI (plus:SI (reg:SI sp) (const_int -8))) (reg:SI lr)) (set (mem:SI (plus:SI (reg:SI sp) (const_int -4))) (reg:SI pc)) (set (reg:SI sp) (plus:SI (reg:SI sp) (const_int -20))) ]) be unique? match_parallel would verify the form (that the first sp offset matches the negative stack adjustment, that it is multiple of reg size, that the last adjustment is -word size, that the offsets are consecutive etc. Alternatively surround the first set's RHS reg into UNSPEC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399
[Bug target/43417] ICE : in final_scan_insn, at final.c:2604
--- Comment #1 from iwamatsu at nigauri dot org 2010-03-18 07:18 --- Created an attachment (id=20138) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20138action=view) The source code that can reproduce a problem. this code generate by -E option. Sorry. There is the code to reappear, but cannot lower it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43417
[Bug rtl-optimization/43286] Missed related value optimization in cse.c
--- Comment #6 from steven at gcc dot gnu dot org 2010-03-18 08:27 --- Reopening... -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43286
[Bug rtl-optimization/43286] Missed related value optimization in cse.c
--- Comment #7 from steven at gcc dot gnu dot org 2010-03-18 08:29 --- ...to close as dup of bug 39871 *** This bug has been marked as a duplicate of 39871 *** -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43286
[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to poor register allocation
--- Comment #21 from steven at gcc dot gnu dot org 2010-03-18 08:29 --- *** Bug 43286 has been marked as a duplicate of this bug. *** -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||carrot at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871
[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to poor register allocation
--- Comment #22 from steven at gcc dot gnu dot org 2010-03-18 08:31 --- In the test case from bug 43286, should_replace_address does not perform the following replacement because the address cost is the same and the replacement is only done if new_rtx is more expensive than old_rtx. old_rtx (plus:SI (reg/v/f:SI 133 [ saveArea ]) (const_int 8 [0x8])) new_rtx (plus:SI (reg/v/f:SI 140 [ fp ]) (const_int -8 [0xfff8])) This is the same situation as described in comment #16. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871
[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1
--- Comment #8 from ramana at gcc dot gnu dot org 2010-03-18 09:25 --- (In reply to comment #7) BTW, if the PRE_MODIFY representation doesn't work well, I'd say just using a PARALLEL with what the insn really does and checking that in the match_parallel predicate probably wouldn't clash with anything else. If it would, you'd need to insert one UNSPEC somewhere. The PRE_MODIFY representation wouldn't work because you still have the assert in var-tracking.c under the check for PRE_MODIFY that this is a BLKmode. The problem is more the BLKmode on the address. The comments say that currently the pattern looks like: (parallel [ (set (mem:BLK (pre_dec:BLK (reg:SI sp))) (unspec:BLK [(reg:SI r4)] UNSPEC_PUSH_MULT)) (use (reg:SI 11 fp)) (use (reg:SI 12 ip)) (use (reg:SI 14 lr)) (use (reg:SI 15 pc)) ]) with the REG_FRAME_RELATED_EXPR: (sequence [ (set (reg:SI sp) (plus:SI (reg:SI sp) (const_int -20))) (set (mem:SI (reg:SI sp)) (reg:SI r4)) (set (mem:SI (plus:SI (reg:SI sp) (const_int 4))) (reg:SI fp)) (set (mem:SI (plus:SI (reg:SI sp) (const_int 8))) (reg:SI ip)) (set (mem:SI (plus:SI (reg:SI sp) (const_int 12))) (reg:SI lr)) ]) So, would a parallel like: (parallel [ (set (mem:SI (plus:SI (reg:SI sp) (const_int -20))) (reg:SI r4)) (set (mem:SI (plus:SI (reg:SI sp) (const_int -16))) (reg:SI fp)) (set (mem:SI (plus:SI (reg:SI sp) (const_int -12))) (reg:SI ip)) (set (mem:SI (plus:SI (reg:SI sp) (const_int -8))) (reg:SI lr)) (set (mem:SI (plus:SI (reg:SI sp) (const_int -4))) (reg:SI pc)) (set (reg:SI sp) (plus:SI (reg:SI sp) (const_int -20))) ]) be unique? match_parallel would verify the form (that the first sp offset matches the negative stack adjustment, that it is multiple of reg size, that the last adjustment is -word size, that the offsets are consecutive etc. Alternatively surround the first set's RHS reg into UNSPEC. Actually the comment is out of date and needs to be corrected. It need not be fp, sp, pc, and lr but any 4 integer registers that we choose to store using the push_multi scheme in the prologue. Let me go stare at the backend. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Component|target |bootstrap Priority|P1 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399
[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1
--- Comment #9 from ramana at gcc dot gnu dot org 2010-03-18 10:21 --- Created an attachment (id=20139) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20139action=view) patch Patch that makes the ICE disappear by converting these into mem:BLKmode (pre_modify (Pmode)). I will submit a variation of this in the ARM backend finally on gcc-patches@ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399
[Bug c++/43418] New: trunk rev157534. compile c++ with --enable-build-with-cxx fails in cp_parser_for_init_statement
during make: ./prev-gcc/g++ ... -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Icp .../gcc/cp/parser.c -o cp/parser.o error: converting false to pointer type for argument 2 of tree_node* cp_parser_expression_statement(cp_parser*, tree_node*) in gcc/cp/parser-c line 8355. cp_parser_expression_statement (parser, false); I guess there should be something else there in place of false, like 0? -- Summary: trunk rev157534. compile c++ with --enable-build-with- cxx fails in cp_parser_for_init_statement Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ailin dot nemui at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43418
[Bug c++/43418] trunk rev157534. compile c++ with --enable-build-with-cxx fails in cp_parser_for_init_statement
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-18 10:59 --- Can you try replacing it with NULL_TREE? If everything goes well on your end, we can commit the fix as obvious (I'm going to sanity check it for a normal build) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43418
[Bug tree-optimization/43415] [4.4/4.5 Regression] Consumes large amounts of memory and time in PRE at -O3
--- Comment #1 from amonakov at gcc dot gnu dot org 2010-03-18 11:30 --- Confirming. 4.5 trunk needs lots of memory in PRE. -- amonakov at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, amonakov at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||compile-time-hog, memory-hog Known to fail||4.4.3 4.5.0 Known to work||4.4.2 Last reconfirmed|-00-00 00:00:00 |2010-03-18 11:30:27 date|| Summary|[4.4 regression] gcc takes |[4.4/4.5 Regression] |unusually large amounts of |Consumes large amounts of |memory and time to compile |memory and time in PRE at - |nested for loop at -O3 |O3 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43415
[Bug c++/43418] trunk rev157534. compile c++ with --enable-build-with-cxx fails in cp_parser_for_init_statement
--- Comment #2 from ailin dot nemui at gmail dot com 2010-03-18 11:37 --- works fine :) thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43418
[Bug c++/43418] trunk rev157534. compile c++ with --enable-build-with-cxx fails in cp_parser_for_init_statement
--- Comment #3 from paolo at gcc dot gnu dot org 2010-03-18 11:46 --- Subject: Bug 43418 Author: paolo Date: Thu Mar 18 11:46:15 2010 New Revision: 157536 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157536 Log: 2010-03-18 Paolo Carlini paolo.carl...@oracle.com PR c++/43418 * parser.c (cp_parser_for_init_statement): Use NULL_TREE, not false, in the cp_parser_expression_statement call. Modified: trunk/gcc/cp/parser.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43418
[Bug c++/43418] trunk rev157534. compile c++ with --enable-build-with-cxx fails in cp_parser_for_init_statement
--- Comment #4 from paolo at gcc dot gnu dot org 2010-03-18 11:46 --- Subject: Bug 43418 Author: paolo Date: Thu Mar 18 11:46:33 2010 New Revision: 157537 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157537 Log: 2010-03-18 Paolo Carlini paolo.carl...@oracle.com PR c++/43418 * parser.c (cp_parser_for_init_statement): Use NULL_TREE, not false, in the cp_parser_expression_statement call. Modified: trunk/gcc/cp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43418
[Bug c++/43418] trunk rev157534. compile c++ with --enable-build-with-cxx fails in cp_parser_for_init_statement
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-18 11:47:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43418
[Bug c++/43418] trunk rev157534. compile c++ with --enable-build-with-cxx fails in cp_parser_for_init_statement
--- Comment #5 from paolo dot carlini at oracle dot com 2010-03-18 11:47 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43418
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
--- Comment #10 from matz at gcc dot gnu dot org 2010-03-18 12:21 --- Subject: Bug 43402 Author: matz Date: Thu Mar 18 12:20:50 2010 New Revision: 157538 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157538 Log: PR tree-optimization/43402 * tree-cfgcleanup.c (cleanup_control_expr_graph): Don't follow PHI chains of ssa names registered for update. testsuite/ * gcc.dg/pr43402.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr43402.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfgcleanup.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug target/43417] SH: 4.4 ICE in final_scan_insn, at final.c:2604
--- Comment #2 from kkojima at gcc dot gnu dot org 2010-03-18 12:39 --- Looks the same issue in http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00747.html though I can't reproduce the problem with my gcc-4.4.3 and 4.4 head compilers for the test case in #1. Could you try the patch in the above URL? -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Keywords||ice-on-valid-code Summary|ICE : in final_scan_insn, at|SH: 4.4 ICE in |final.c:2604|final_scan_insn, at ||final.c:2604 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43417
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
--- Comment #11 from matz at gcc dot gnu dot org 2010-03-18 12:46 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug debug/7580] incorrect/unfortunate DWARF-2 info for static const int class members
--- Comment #7 from dodji at gcc dot gnu dot org 2010-03-18 12:50 ---
Things have changed quite a bit in GCC 4.5 (trunk).
Now for the code:
class C
{
static const int foo;
};
int
main()
{
return 0;
}
GCC 4.5 will not generate any debug info for the class C at all, because it's
not used. The compiler does that to minimize the size of debug info.
Now if we write:
class C
{
static const int foo;
};
int
main()
{
C c;
return 0;
}
GCC generates debug info for C, and properly generates a DW_TAG_member for foo.
Note how we instantiate C in main, but don't reference C::foo in any way.
Here is a relevant DWARF portion of the assembly we get for this:
.uleb128 0x2# (DIE (0x2d) DW_TAG_class_type)
.ascii C\0# DW_AT_name
.byte 0x1 # DW_AT_byte_size
.byte 0x1 # DW_AT_decl_file (../../prtests/test.cc)
.byte 0x2 # DW_AT_decl_line
.long 0x49# DW_AT_sibling
.uleb128 0x3# (DIE (0x37) DW_TAG_member)
.ascii foo\0 # DW_AT_name
.byte 0x1 # DW_AT_decl_file (../../prtests/test.cc)
.byte 0x4 # DW_AT_decl_line
.long .LASF3 # DW_AT_MIPS_linkage_name: _ZN1C3fooE
.long 0x49# DW_AT_type
.byte 0x1 # DW_AT_external
.byte 0x1 # DW_AT_declaration
.byte 0x0 # end of children of DIE 0x2d
So I think we can close this bug now.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2003-06-09 15:32:16 |2010-03-18 12:50:30
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7580
[Bug debug/7580] incorrect/unfortunate DWARF-2 info for static const int class members
--- Comment #8 from dodji at gcc dot gnu dot org 2010-03-18 12:52 --- Bug no more present in GCC 4.5 -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7580
[Bug debug/37982] Extraneous DW_TAG_variable tag
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-11-01 11:03:52 |2010-03-18 12:52:49 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug debug/37982] Extraneous DW_TAG_variable tag
--- Comment #10 from dodji at gcc dot gnu dot org 2010-03-18 12:53 --- Bug no more present in 4.5 -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug rtl-optimization/43360] [4.3/4.4/4.5 Regression] wrong loop invariant hoisting
--- Comment #15 from hjl at gcc dot gnu dot org 2010-03-18 13:11 --- Subject: Bug 43360 Author: hjl Date: Thu Mar 18 13:10:49 2010 New Revision: 157539 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157539 Log: Remove the REG_EQUAL note if we don't know its invariant status. gcc/ 2010-03-18 Steven Bosscher ste...@gcc.gnu.org Eric Botcazou ebotca...@adacore.com PR rtl-optimization/43360 * loop-invariant.c (move_invariant_reg): Remove the REG_EQUAL note if we don't know its invariant status. gcc/testsuite/ 2010-03-18 H.J. Lu hongjiu...@intel.com PR rtl-optimization/43360 * gcc.dg/torture/pr43360.c: New. Added: trunk/gcc/testsuite/gcc.dg/torture/pr43360.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
[Bug rtl-optimization/43360] [4.3/4.4/4.5 Regression] wrong loop invariant hoisting
--- Comment #16 from hjl at gcc dot gnu dot org 2010-03-18 13:13 --- Subject: Bug 43360 Author: hjl Date: Thu Mar 18 13:13:42 2010 New Revision: 157540 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157540 Log: Remove the REG_EQUAL note if we don't know its invariant status. gcc/ 2010-03-18 H.J. Lu hongjiu...@intel.com Backport from mainline: 2010-03-18 Steven Bosscher ste...@gcc.gnu.org Eric Botcazou ebotca...@adacore.com PR rtl-optimization/43360 * loop-invariant.c (move_invariant_reg): Remove the REG_EQUAL note if we don't know its invariant status. gcc/testsuite/ 2010-03-18 H.J. Lu hongjiu...@intel.com Backport from mainline: 2010-03-18 H.J. Lu hongjiu...@intel.com PR rtl-optimization/43360 * gcc.dg/torture/pr43360.c: New. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr43360.c - copied unchanged from r157539, trunk/gcc/testsuite/gcc.dg/torture/pr43360.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/loop-invariant.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
[Bug rtl-optimization/43360] [4.3/4.4/4.5 Regression] wrong loop invariant hoisting
--- Comment #17 from hjl at gcc dot gnu dot org 2010-03-18 13:15 --- Subject: Bug 43360 Author: hjl Date: Thu Mar 18 13:15:21 2010 New Revision: 157541 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157541 Log: Remove the REG_EQUAL note if we don't know its invariant status. gcc/ 2010-03-18 H.J. Lu hongjiu...@intel.com Backport from mainline: 2010-03-18 Steven Bosscher ste...@gcc.gnu.org Eric Botcazou ebotca...@adacore.com PR rtl-optimization/43360 * loop-invariant.c (move_invariant_reg): Remove the REG_EQUAL note if we don't know its invariant status. gcc/testsuite/ 2010-03-18 H.J. Lu hongjiu...@intel.com Backport from mainline: 2010-03-18 H.J. Lu hongjiu...@intel.com PR rtl-optimization/43360 * gcc.dg/torture/pr43360.c: New. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr43360.c - copied unchanged from r157540, trunk/gcc/testsuite/gcc.dg/torture/pr43360.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/loop-invariant.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
[Bug rtl-optimization/43360] [4.3/4.4/4.5 Regression] wrong loop invariant hoisting
--- Comment #18 from hjl dot tools at gmail dot com 2010-03-18 13:16 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.3.4 4.4.3 4.5.0 |4.3.4 4.4.3 Known to work|4.2.1 |4.2.1 4.3.5 4.4.4 4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
[Bug rtl-optimization/43360] [4.3/4.4/4.5 Regression] wrong loop invariant hoisting
--- Comment #19 from steven at gcc dot gnu dot org 2010-03-18 13:20 --- For the record: bootstrapped+tested on amd64-linux and ia64-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
[Bug target/43399] [4.5 Regression] bootstrap failure in stage1
-- ramana at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ramana at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Component|bootstrap |target Priority|P3 |P1 Last reconfirmed|2010-03-17 22:43:30 |2010-03-18 13:36:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399
[Bug middle-end/43419] New: gcc replaces pow(x, 0.5) by sqrt(x), invalid when x is -0
gcc replaces pow(x, 0.5) by sqrt(x). This is invalid when x is -0. Indeed,
according to ISO C99 (N1256), F.9.4.4:
pow(±0, y) returns +0 for y 0 and not an odd integer.
So, pow(-0.0, 0.5) should return +0. But sqrt(-0.0) should return -0 according
to the IEEE 754 standard (and F.9.4.5 from ISO C99).
Testcase:
#include stdio.h
#include math.h
int main (void)
{
volatile double x = -0.0;
printf (sqrt(-0)= %g\n, sqrt (x));
printf (pow(-0,0.5) = %g\n, pow (x, 0.5));
return 0;
}
--
Summary: gcc replaces pow(x, 0.5) by sqrt(x), invalid when x is -
0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43419
[Bug bootstrap/43420] New: a small miscode in binutils/readelf.c
on line 6197 to 6205:
unsigned char buf[5];
unsigned int i, len;
unsigned long offset;
for (i = 0; i 9; i++)
{
GET_OP (buf[i]);
if ((buf[i] 0x80) == 0)
break;
}
An obviously small wrong definition on the size of buf, which will cause
cc1.exe to treat warnings as errors.
Change size [5] to [9], am I right?
--
Summary: a small miscode in binutils/readelf.c
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aflyhorse at foxmail dot com
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43420
[Bug middle-end/43419] gcc replaces pow(x, 0.5) by sqrt(x), invalid when x is -0
--- Comment #1 from vincent at vinc17 dot org 2010-03-18 14:33 --- If I understand correctly, the bug appears with: r119248 | rguenth | 2006-11-27 12:38:42 +0100 (Mon, 27 Nov 2006) | 10 lines 2006-11-27 Richard Guenther rguent...@suse.de PR middle-end/25620 * builtins.c (expand_builtin_pow): Optimize non integer valued constant exponents using sqrt or cbrt if possible. Always fall back to expanding via optabs. * gcc.target/i386/pow-1.c: New testcase. * gcc.dg/builtins-58.c: Likewise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43419
[Bug middle-end/43419] gcc replaces pow(x, 0.5) by sqrt(x), invalid when x is -0
--- Comment #2 from matz at gcc dot gnu dot org 2010-03-18 14:35 --- Mine. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-18 14:35:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43419
[Bug fortran/25620] Missed optimization with power
--- Comment #18 from vincent at vinc17 dot org 2010-03-18 14:37 --- The patch affected C, where the transformation of pow(x, 0.5) into sqrt(x) is incorrect. See PR 43419. -- vincent at vinc17 dot org changed: What|Removed |Added CC||vincent at vinc17 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25620
[Bug debug/42959] g++ does not emit DW_AT_default_value
--- Comment #5 from dodji at gcc dot gnu dot org 2010-03-18 14:38 --- (In reply to comment #4) As we discussed on IRC, it seems we'd need a way to express that we'd want the debugger to create a temporary, initialize it and later destroy it. DWARF can't express as of now. So we'll probably need some kind of extension. I am not sure exactly what extension yet though. I need to think about this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42959
[Bug middle-end/43419] gcc replaces pow(x, 0.5) by sqrt(x), invalid when x is -0
--- Comment #3 from dominiq at lps dot ens dot fr 2010-03-18 14:41 --- While you are looking at this part, you may have to check that a similar problem does not exist when converting x*sqrt(x) to pow(w,1.5) and so on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43419
[Bug middle-end/43419] gcc replaces pow(x, 0.5) by sqrt(x), invalid when x is -0
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-18 14:48 --- I checked, and these and similar transformations are always guarded by flag_unsafe_math_optimizations, so we should be fine, unless I missed a case of course. If you notice one, please create a bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43419
[Bug c/43374] ICE with __builtin_isinf() and _Decimal argument
--- Comment #3 from roman at binarylife dot net 2010-03-18 14:52 ---
This looks related.
$ cat test.c
_Decimal64 func() {
return 9e384dd + 9e384dd;
}
$ gcc -c test.c
test.c: In function 'func':
test.c:2:3: internal compiler error: in decimal_to_decnumber, at dfp.c:115
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43374
[Bug tree-optimization/43415] [4.4/4.5 Regression] Consumes large amounts of memory and time in PRE at -O3
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-18 15:29 --- I will have a look. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-03-18 11:30:27 |2010-03-18 15:29:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43415
[Bug middle-end/43419] gcc replaces pow(x, 0.5) by sqrt(x), invalid when x is -0
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-18 15:31 --- Looks like we need to guard this with HONOR_SIGNED_ZEROS. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43419
[Bug c/43421] New: strict-aliasing warning from innocent code
Compiling the code below (with -O2 -Wall -std=c99, gcc 4.4.3) gives the warning
apa.c: In function 'f':
cc1: warning: dereferencing pointer '({anonymous})' does break strict-aliasing
rules
apa.c:9: note: initialized from here
which is both unhelpful and dubious - is the code really doing anything wrong
here?
static int g(const void *p) {
int x;
__builtin_memcpy(x, p, sizeof x);
return x;
}
struct s { char d[5]; };
int f(struct s ss) {
int t = 0;
for (int i = 0; i 2; i++)
t += g(ss.d);
return t;
}
--
Summary: strict-aliasing warning from innocent code
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mattiase at acm dot org
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=43421
[Bug middle-end/43419] gcc replaces pow(x, 0.5) by sqrt(x), invalid when x is -0
--- Comment #6 from matz at gcc dot gnu dot org 2010-03-18 16:08 --- Subject: Bug 43419 Author: matz Date: Thu Mar 18 16:07:53 2010 New Revision: 157543 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157543 Log: PR middle-end/43419 * builtins.c (expand_builtin_pow): Don't transform pow(x, 0.5) into sqrt(x) if we need to preserve signed zeros. testsuite/ * gcc.dg/pr43419.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr43419.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43419
[Bug target/43305] [4.4/4.5 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()
--- Comment #6 from matz at gcc dot gnu dot org 2010-03-18 16:47 --- Mine. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-03-09 15:49:38 |2010-03-18 16:47:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43305
[Bug middle-end/43419] gcc replaces pow(x, 0.5) by sqrt(x), invalid when x is -0
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-18 16:47 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43419
[Bug bootstrap/43420] a small miscode in binutils/readelf.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-18 16:48 --- readelf is not part of the GCC project but the binutils project. Please report it to them (http://www.sourceware.org/bugzilla/ ). -- 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=43420
[Bug c/43211] [4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1430
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-18 16:53 --- That would indeed be my preferred approach. The alternative would be to add much if (x == error_mark_node) sillyness all over the middle-end, like the front-ends do. The middle-end should be able to rightfully expect to be fed only at least basically valid trees. This could possibly also be done in the gimplifier (just don't emit a statement if some operands smell bad). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43211
[Bug c/43211] [4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1430
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-18 16:55 --- A radical approach would be to not gimplify in case of errors Part of the problem there is that the C++ front-end (at least used to), produce errors while gimplifying (though that might be fixed). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43211
[Bug c/43211] [4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1430
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-18 16:57 --- See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24222 for all the bugs about emitting errors/warnings during gimplification; though as I said some of those might be fixed; I have not checked yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43211
[Bug c/43211] [4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1430
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-03-18 16:59 --- I will be looking into this, we should be able to not have a function_type with an error_mark_node as an argument but we should just have an error_mark_node instead. -- 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 GCC host triplet|x86_64-pc-linux-gnu | GCC target triplet|x86_64-pc-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43211
[Bug c/43211] [4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1430
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-18 17:05 ---
Actually this is a simple patch:
Index: c-decl.c
===
--- c-decl.c(revision 157518)
+++ c-decl.c(working copy)
@@ -6118,6 +6118,7 @@ grokparms (struct c_arg_info *arg_info,
TREE_VALUE (typelt) = error_mark_node;
TREE_TYPE (parm) = error_mark_node;
+ arg_types = NULL_TREE;
}
else if (VOID_TYPE_P (type))
{
Since if arg_types is returned and a NULL_TREE means a variable length
arguments, we get away with still diagnosing all the other issues (well close
to all overs).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43211
[Bug tree-optimization/43415] [4.4/4.5 Regression] Consumes large amounts of memory and time in PRE at -O3
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-18 17:24 --- I have a patch. It's just unfortunate ordering of phi-translation and missed caching. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43415
[Bug tree-optimization/42906] [4.5 Regression] Empty loop not removed
--- Comment #20 from changpeng dot fang at amd dot com 2010-03-18 17:24 --- (In reply to comment #19) Splitting critical edges for CDDCE will probably also solve this problem. Richard. Yes, splitting critical edges is an enhancement to CDDCE and can solve this problem. There are two approaches to do this (1) add pass_split_crit_edges before each pass_cd_dce or (2) encode split_crit_edges into cddce as an initialization. What do you think? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42906
[Bug c/43374] ICE with __builtin_isinf() and _Decimal argument
--- Comment #4 from janis at gcc dot gnu dot org 2010-03-18 17:27 ---
The tests also fail on powerpc64-linux, although the first one gets the same
error with and without optimization.
elm3c105% cat 43374-1.c
int func(_Decimal32 v) {
return __builtin_isinf(v);
}
elm3c105% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -c 43374-1.c
43374-1.c: In function func:
43374-1.c:2:25: internal compiler error: in prepare_float_lib_cmp, at
optabs.c:4391
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
elm3c105% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -c -O 43374-1.c
43374-1.c: In function func:
43374-1.c:1:5: internal compiler error: in prepare_float_lib_cmp, at
optabs.c:4391
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
elm3c105% cat 43374-2.c
_Decimal64 func() {
return 9e384dd + 9e384dd;
}
elm3c105% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -c 43374-2.c
43374-2.c:3:1: internal compiler error: in decimal_to_decnumber, at dfp.c:115
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
elm3c105% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -c -O 43374-2.c
43374-2.c:3:1: internal compiler error: in decimal_to_decnumber, at dfp.c:115
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
The failures are the same for -m32 and -m64.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
CC||bergner at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43374
[Bug tree-optimization/42906] [4.5 Regression] Empty loop not removed
--- Comment #21 from rguenther at suse dot de 2010-03-18 17:30 --- Subject: Re: [4.5 Regression] Empty loop not removed On Thu, 18 Mar 2010, changpeng dot fang at amd dot com wrote: --- Comment #20 from changpeng dot fang at amd dot com 2010-03-18 17:24 --- (In reply to comment #19) Splitting critical edges for CDDCE will probably also solve this problem. Richard. Yes, splitting critical edges is an enhancement to CDDCE and can solve this problem. There are two approaches to do this (1) add pass_split_crit_edges before each pass_cd_dce or (2) encode split_crit_edges into cddce as an initialization. What do you think? Thanks. Ideally we'd handle this with pass properties and the pass manager (but that requires larger changes). For now I'd do it like the crited pass before PRE, thus schedule a new pass before CDDCEs. I also think that we can consider not fixing this for 4.5 and do it properly for 4.6. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42906
[Bug target/43404] ARM: Internal compiler error when using 'foo' in naked function
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-03-18 17:37 --- Native functions aren't expected to work with a 'C' body. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43404
[Bug target/43404] ARM: Internal compiler error when using 'foo' in naked function
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-18 17:39 --- Then it should produce an error and not an internal compiler error. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43404
[Bug c/43422] New: reversed loop is not vectorized
gcc could not vectorize this simple reversed loop:
int a[100], b[100];
void foo(int n)
{
int i;
for(i=n-2; i=0; i--)
a[i+1] = a[i] + b[i];
}
chf...@pathscale:~/gcc$ gcc -O3 -ftree-vectorizer-verbose=2 -c foo.c
foo.c:6: note: not vectorized: complicated access pattern.
foo.c:3: note: vectorized 0 loops in function.
open64 can vectorize this loop:
chf...@pathscale:~/gcc$ opencc -O3 -LNO:simd_verbose=on -c foo.c
(foo.c:0) LOOP WAS VECTORIZED.
--
Summary: reversed loop is not vectorized
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: changpeng dot fang at amd dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43422
[Bug tree-optimization/43416] [4.4 regression] internal compiler error in C++ template instantiations at -O3
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-18 17:55 --- Works on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43416
[Bug tree-optimization/43416] [4.4 regression] internal compiler error in C++ template instantiations at -O3
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-18 17:56 --- Could be a dup of bug 42871 or PR 43074. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43416
[Bug rtl-optimization/42216] [4.5 Regression] changes in scheduling regress 464.h264ref 20%
--- Comment #28 from rguenth at gcc dot gnu dot org 2010-03-18 17:59 --- All fine again. Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42216
[Bug fortran/43043] [-fwhole-file] ICE segfault for select_type_4.f90
--- Comment #2 from pault at gcc dot gnu dot org 2010-03-18 18:00 ---
The following fixes the PR. I have not regtested yet but anticipate that all
will be well.
Index: ../trunk/gcc/fortran/trans-expr.c
===
--- ../trunk/gcc/fortran/trans-expr.c (revision 157419)
+++ ../trunk/gcc/fortran/trans-expr.c (working copy)
@@ -4454,6 +4454,8 @@
{
gfc_component *data;
data = gfc_find_component (cm-ts.u.derived, $data, true, true);
+ if (!data-backend_decl)
+ gfc_get_derived_type (cm-ts.u.derived);
val = gfc_conv_initializer (c-expr, cm-ts,
TREE_TYPE (data-backend_decl),
data-attr.dimension,
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43043
[Bug c/43423] New: gcc should vectorize this loop through iteration range splitting
chf...@pathscale:~/gcc$ cat foo.c
int a[100], b[100], c[100];
void foo(int n, int mid)
{
int i;
for(i=0; in; i++)
{
if (i mid)
a[i] = a[i] + b[i];
else
a[i] = a[i] + c[i];
}
}
chf...@pathscale:~/gcc$ gcc -O3 -ftree-vectorizer-verbose=7 -c foo.c
foo.c:6: note: not vectorized: control flow in loop.
foo.c:3: note: vectorized 0 loops in function.
This loop can be vectorized by icc.
For this case, I would expect to see two loops with iteration range
of [0, mid) and [mid, n). Then both loops can be vectorized.
I am not sure which pass in gcc should do this iteration range splitting.
--
Summary: gcc should vectorize this loop through iteration range
splitting
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: changpeng dot fang at amd dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43423
[Bug c++/43424] New: -O2 -floop-parallelize-all causes verify_stmts failure
I just tried to compile the package normaliz-2.2 with the C++ compiler version 4.5 snapshot 20100311 and it said vector_operations.cpp: In function 'std::vectorlong int v_make_prime(const std::vectorlong int, Integer)': vector_operations.cpp:300:17: error: statement marked for throw in middle of block # .MEM_36 = VDEF .MEM_81 D.34201_8 = v_gcd (v_2(D)); vector_operations.cpp:300:17: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flags -O2 -floop-parallelize-all required. -- Summary: -O2 -floop-parallelize-all causes verify_stmts failure Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43424
[Bug target/43383] __extendxftf2 not exported from 32-bit shared libgcc
--- Comment #4 from hjl at gcc dot gnu dot org 2010-03-18 18:12 --- Subject: Bug 43383 Author: hjl Date: Thu Mar 18 18:12:31 2010 New Revision: 157544 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157544 Log: Export __extendxftf2 to GCC_4.5.0 for 32bit libgcc. 2010-03-18 H.J. Lu hongjiu...@intel.com PR target/43383 * config/i386/libgcc-glibc.ver: Add __extendxftf2 to GCC_4.5.0 for 32bit. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/libgcc-glibc.ver -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43383
[Bug target/43383] __extendxftf2 not exported from 32-bit shared libgcc
--- Comment #5 from hjl dot tools at gmail dot com 2010-03-18 18:13 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43383
[Bug c/43423] gcc should vectorize this loop through iteration range splitting
--- Comment #1 from amonakov at gcc dot gnu dot org 2010-03-18 18:13 --- Graphite is able to split the loop, but then the vectorizer punts anyway: gcc -O3 -ftree-vectorizer-verbose=7 -fgraphite-identity -S t.c t.c:11: note: not vectorized: number of iterations cannot be computed. t.c:9: note: not vectorized: number of iterations cannot be computed. t.c:3: note: vectorized 0 loops in function. -- amonakov at gcc dot gnu dot org changed: What|Removed |Added CC||amonakov at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43423
[Bug c++/43424] -O2 -floop-parallelize-all causes verify_stmts failure
--- Comment #1 from dcb314 at hotmail dot com 2010-03-18 18:13 --- Created an attachment (id=20140) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20140action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43424
[Bug c/43425] New: enhance scalar expansion to vectorize this loop
chf...@pathscale:~/gcc$ cat foo.c
int a[100], b[100];
void foo(int n, int mid)
{
int i, t = 0;
for(i=0; in; i++)
{
a[i] = b[i] + t;
t = b[i];
}
}
chf...@pathscale:~/gcc$ gcc -O3 -ftree-vectorizer-verbose=7 -c foo.c
foo.c:6: note: not vectorized: unsupported use in stmt.
foo.c:3: note: vectorized 0 loops in function.
scalar expansion of t into array to carry the values accross iteration.
--
Summary: enhance scalar expansion to vectorize this loop
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: changpeng dot fang at amd dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43425
[Bug fortran/43044] [-fwhole-file] ICE segfault for global_references_1.f90 (invalid code)
--- Comment #1 from pault at gcc dot gnu dot org 2010-03-18 18:17 ---
This is fixed by the following, which is not yet regtested:
Index: ../trunk/gcc/fortran/resolve.c
===
--- ../trunk/gcc/fortran/resolve.c (revision 157419)
+++ ../trunk/gcc/fortran/resolve.c (working copy)
@@ -1841,6 +1841,7 @@
/* Non-assumed length character functions. */
if (sym-attr.function sym-ts.type == BT_CHARACTER
+ gsym-ns-proc_name-ts.u.cl
gsym-ns-proc_name-ts.u.cl-length != NULL)
{
gfc_charlen *cl = sym-ts.u.cl;
From the style, this does not look like it was my addition :-)
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43044
[Bug c/43426] New: dlsym: invalid version 5 (max 0)
Hello, I'm trying to build sqlite-3.6.22 on a sun4v server (T1 processor). I have tried bith gcc 4.4.1 and 4.4.3 in 32 and 64 bits modes. sqlite build process aborts with: ... gcc -DSQLITE_THREADSAFE=0 -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -mtune=niagara -mcpu=niagara -m64 -m64 -m64 -m64 -o .libs/sqlite3 shell.o -L/usr/lib/sparcv9 ./.libs/libsqlite3.so -lreadline -lcurses -Wl,--rpath -Wl,/usr/local/lib /usr/shared-apps/lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/bin/ld: ./.libs/libsqlite3.so: dlsym: invalid version 5 (max 0) ./.libs/libsqlite3.so: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [sqlite3] Error 1 libsqlite.a is usable. I have no idea about libsqlite3.so usability. Both compilers work fine on all others programs I have tried to build. If I replace libsqlite3.so by libsqlite3.a, link stage can be done without error: tchaikovski:[~/rpl/build/tools/sqlite-3.6.22] gcc -DSQLITE_THREADSAFE=0 -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -mtune=niagara -mcpu=niagara -m64 -m64 -m64 -m64 -o .libs/sqlite3 shell.o -L/usr/lib/sparcv9 ./.libs/libsqlite3.a -lreadline -lcurses -Wl,--rpath -Wl,/usr/local/lib tchaikovski:[~/rpl/build/tools/sqlite-3.6.22] Gcc options are: tchaikovski:[~/rpl/build/tools/sqlite-3.6.22] gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../gcc-4.4.3/configure --prefix=/usr/shared-apps --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-nls --enable-checking=release --with-mpfr=/usr/shared-apps/ --with-gnu-ld --enable-bootstrap Thread model: posix gcc version 4.4.3 (GCC) I have checked mpfr and gmp and I use binutils 2.20.1. On another sparc server (sun4u, dual UltraSPARC-III) running debian/squeeze with gcc-4.4 (gcc version 4.4.3 20100108), I cannot reproduce this bug. Regards, JKB -- Summary: dlsym: invalid version 5 (max 0) Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mt1 at systella dot fr GCC build triplet: sparc-sun-solaris2.10 GCC host triplet: sparc-sun-solaris2.10 GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43426
[Bug tree-optimization/43423] gcc should vectorize this loop through iteration range splitting
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-18 18:22 --- Well it could be vectorized even without range splitting. The issue is the sinking of the store to a[i]. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43423
[Bug middle-end/40106] [4.4/4.5 Regression] Weird interaction between optimize_insn_for_speed_p and -funsafe-math-optimizations
--- Comment #46 from dominiq at lps dot ens dot fr 2010-03-18 18:29 --- The answer to the question (b) in comment #35: (b) why !optimize_size has been replaced with optimize_insn_for_speed_p ()? seems to be this patch replace some of optimize_size tests by optimize_insn_for_speed_p predicate so we can make decisions on per-BB granuality. from http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00121.html (revision 138565 by hubicka, Sun Aug 3 12:04:49 2008 UTC). Why is there any need to expand pow(x,n) on per-BB granularity? is not !optimize_size enough for this case? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
[Bug tree-optimization/43425] enhance scalar expansion to vectorize this loop
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-18 18:31 --- Basically undoing predictive commoning (which we switched the order for 4.5 to fix a different issue). Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |tree-optimization Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-03-18 18:31:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43425
Re: [Bug tree-optimization/43423] gcc should vectorize this loop through iteration range splitting
Well it could be vectorized even without range splitting. The issue is the sinking of the store to a[i]. You mean that the problem is the if-conversion of the stores a[i] = ...
[Bug tree-optimization/43423] gcc should vectorize this loop through iteration range splitting
--- Comment #3 from sebpop at gmail dot com 2010-03-18 18:33 --- Subject: Re: gcc should vectorize this loop through iteration range splitting Well it could be vectorized even without range splitting. The issue is the sinking of the store to a[i]. You mean that the problem is the if-conversion of the stores a[i] = ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43423
[Bug c/43427] New: The loop is not interchanged and thus could not be vectorized.
chf...@pathscale:~/gcc$ cat foo.c
float a[100][100], b[100][100];
void foo(int n)
{
int i, j;
for(j=0; jn; j++)
for(i=0; i n; i++)
a[i][j] = a[i][j] + b[i][j];
}
chf...@pathscale:~/gcc$ gcc -O3 -ftree-vectorizer-verbose=2 -c foo.c
foo.c:6: note: not vectorized: can't create epilog loop 2.
foo.c:7: note: not vectorized: complicated access pattern.
foo.c:3: note: vectorized 0 loops in function.
Information from open64:
chf...@pathscale:~/gcc$ opencc -O3 -LNO:simd_verbose=on -c foo.c
(foo.c:0) LOOP WAS VECTORIZED.
(foo.c:0) LOOP WAS VECTORIZED.
chf...@pathscale:~/gcc$ opencc -O3 -LNO:simd_verbose=on:interchange=0 -c foo.c
(foo.c:0) Non-contiguous array a reference exists. Loop was not vectorized.
(foo.c:0) Non-contiguous array a reference exists. Loop was not vectorized.
Graphite may be able to do this basic loop interchange.
--
Summary: The loop is not interchanged and thus could not be
vectorized.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: changpeng dot fang at amd dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43427
[Bug tree-optimization/43423] gcc should vectorize this loop through iteration range splitting
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-18 18:38 ---
(In reply to comment #3)
Subject: Re: gcc should vectorize this loop
through iteration range splitting
You mean that the problem is the if-conversion of the stores
a[i] = ...
If we rewrite the code like:
int a[100], b[100], c[100];
void foo(int n, int mid)
{
int i;
for(i=0; in; i++)
{
int t;
int ai = a[i], bi = b[i], ci = c[i];
if (i mid)
t = ai + bi;
else
t = ai + ci;
a[i] = t;
}
}
--- CUT ---
This gets vectorized as we produce an if-cvt first.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||missed-optimization
Last reconfirmed|-00-00 00:00:00 |2010-03-18 18:38:42
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43423
[Bug tree-optimization/43427] The loop is not interchanged and thus could not be vectorized.
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-18 18:41 --- -ftree-loop-linear can do it also; though neither graphite or that is on by default. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-03-18 18:41:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43427
[Bug fortran/43043] [-fwhole-file] ICE segfault for select_type_4.f90
--- Comment #3 from burnus at gcc dot gnu dot org 2010-03-18 18:41 --- (In reply to comment #2) The following fixes the PR. I have not regtested yet but anticipate that all will be well. Looks good. Does is also fix PR 43039? Looking at Thomas' analysis and at the patch, it might well be the case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43043
[Bug tree-optimization/43423] gcc should vectorize this loop through iteration range splitting
--- Comment #5 from spop at gcc dot gnu dot org 2010-03-18 18:51 --- Yes, I think we should improve if-conversion to handle more complex cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43423
[Bug tree-optimization/43428] New: vectorizer should invoke loop distribution to partially vectorize this loop
chf...@pathscale:~/gcc$ cat foo.c
float a[100], b[100], c[100];
void foo(int n)
{
int i;
for(i=1; in; i++)
{
a[i] = a[i] + c[i];
b[i] = b[i-1] + a[i];
}
}
chf...@pathscale:~/gcc$ gcc -O3 -ftree-vectorizer-verbose=2
-ftree-loop-distribution -c foo.c
foo.c:6: note: not vectorized, possible dependence between data-refs
b[D.2730_7] and b[i_17]
foo.c:3: note: vectorized 0 loops in function.
Loop distribution itself may find not profitable to do such distribution.
However, partially vectorize this loop may obtain big profit. ICC can partially
vectorize it.
--
Summary: vectorizer should invoke loop distribution to partially
vectorize this loop
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: changpeng dot fang at amd dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43428
[Bug tree-optimization/43427] The loop is not interchanged and thus could not be vectorized.
--- Comment #2 from spop at gcc dot gnu dot org 2010-03-18 18:59 --- In the output of ./cc1 -O3 -floop-interchange -fdump-tree-graphite-all -ftree-vectorizer-verbose=7 we have: Loops at depths 0 and 1 will be interchanged. so we do the interchange, but then the vectorizer complains about: note: not vectorized: data ref analysis failed D.2729_41 = a[i_40][var.8_47]; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43427
[Bug tree-optimization/43427] The loop is not interchanged and thus could not be vectorized.
--- Comment #3 from spop at gcc dot gnu dot org 2010-03-18 19:01 --- ./cc1 -O3 -msse2 -ffast-math -ftree-vectorizer-verbose=2 pr43427.c -ftree-loop-linear pr43427.c:6: note: not vectorized: complicated access pattern. pr43427.c:7: note: LOOP VECTORIZED. pr43427.c:3: note: vectorized 1 loops in function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43427
[Bug fortran/43043] [-fwhole-file] ICE segfault for select_type_4.f90
--- Comment #4 from pault at gcc dot gnu dot org 2010-03-18 19:09 --- (In reply to comment #3) (In reply to comment #2) The following fixes the PR. I have not regtested yet but anticipate that all will be well. Looks good. Does is also fix PR 43039? Looking at Thomas' analysis and at the patch, it might well be the case. I suspect that it is similar but not identical. Will look after dinner :-) Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43043
[Bug middle-end/43251] [4.4 Regression] Erroneous code with -ftree-vectorize
--- Comment #13 from a dot kumar at alumni dot iitm dot ac dot in 2010-03-18 19:25 --- Hi! I was wondering if this bug is likely to be fixed in the next GCC release; is this likely to be the case? Thanks! Kumar -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
[Bug middle-end/42450] [4.5 Regression] another GCC 4.5 ICE on C++ templated code
--- Comment #17 from jamborm at gcc dot gnu dot org 2010-03-18 20:07 --- Subject: Bug 42450 Author: jamborm Date: Thu Mar 18 20:07:13 2010 New Revision: 157546 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157546 Log: 2010-03-18 Martin Jambor mjam...@suse.cz PR middle-end/42450 * cgraph.h (cgraph_redirect_edge_call_stmt_to_callee): Declare. * cgraphunit.c (cgraph_materialize_all_clones): Update calls in all non-clones. Moved call redirection... (cgraph_redirect_edge_call_stmt_to_callee): ...to this new function. (cgraph_materialize_all_clones): Dispose of all combined_args_to_skip bitmaps. (verify_cgraph_node): Do not check for edges pointing to wrong nodes in inline clones. * tree-inline.c (copy_bb): Call cgraph_redirect_edge_call_stmt_to_callee. * ipa.c (cgraph_remove_unreachable_nodes): Call cgraph_node_remove_callees even when there are used clones. * testsuite/g++.dg/torture/pr42450.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr42450.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.h trunk/gcc/cgraphunit.c trunk/gcc/ipa.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42450
[Bug fortran/43043] [-fwhole-file] ICE segfault for select_type_4.f90
--- Comment #5 from pault at gcc dot gnu dot org 2010-03-18 20:12 --- (In reply to comment #3) (In reply to comment #2) snip I suspect that it is similar but not identical. Will look after dinner :-) Paul This surmise is correct. As soon as the other two fixes have finished regtesting, I will try what I think is the fix for this one. I believe the derived type 'dt' at trans-expr.c:507 needs to be checked for its backend_decl. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43043
[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory
--- Comment #14 from jakub at gcc dot gnu dot org 2010-03-18 20:15 --- Subject: Bug 43058 Author: jakub Date: Thu Mar 18 20:15:05 2010 New Revision: 157547 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157547 Log: PR debug/43058 * var-tracking.c (non_suitable_const): New function. (add_uses): For DEBUG_INSNs with constants, don't record any value, instead just the constant value itself. (compute_bb_dataflow) case MO_VAL_LOC: If PAT_VAR_LOCATION_LOC is not VAR_LOC_UNKNOWN_P, set var to the constant. (emit_notes_in_bb): Likewise. (emit_note_insn_var_location): For onepart variables if cur_loc is a VOIDmode constant, use DECL_MODE. * gcc.dg/pr43058.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr43058.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
[Bug debug/42873] [4.5 Regression] deadlock in var tracking in recent builds
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-18 20:17 --- Subject: Bug 42873 Author: jakub Date: Thu Mar 18 20:16:48 2010 New Revision: 157548 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157548 Log: PR debug/42873 * var-tracking.c (canonicalize_vars_star): New. (dataflow_post_merge_adjust): Use it. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42873
[Bug bootstrap/43403] [4.5 Regression] ICE in stage1 compiling __bswapdi2
--- Comment #9 from jakub at gcc dot gnu dot org 2010-03-18 20:17 --- Subject: Bug 43403 Author: jakub Date: Thu Mar 18 20:17:32 2010 New Revision: 157549 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157549 Log: PR bootstrap/43403 * var-tracking.c (vt_init_cfa_base): Do nothing if cfa_base_rtx would be hard_frame_pointer_rtx or non-fixed register. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43403
[Bug target/43399] [4.5 Regression] bootstrap failure in stage1
--- Comment #10 from jakub at gcc dot gnu dot org 2010-03-18 20:19 --- Subject: Bug 43399 Author: jakub Date: Thu Mar 18 20:18:53 2010 New Revision: 157550 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157550 Log: PR bootstrap/43399 * var-tracking.c (adjust_mems) case POST_MODIFY: Allow BLKmode mem_mode. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399
[Bug c/43429] New: dlsym: invalid version 5 (max 0)
Hello, I'm trying to build sqlite-3.6.22 on a sun4v server (T1 processor). I have tried bith gcc 4.4.1 and 4.4.3 in 32 and 64 bits modes. sqlite build process aborts with: ... gcc -DSQLITE_THREADSAFE=0 -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -mtune=niagara -mcpu=niagara -m64 -m64 -m64 -m64 -o .libs/sqlite3 shell.o -L/usr/lib/sparcv9 ./.libs/libsqlite3.so -lreadline -lcurses -Wl,--rpath -Wl,/usr/local/lib /usr/shared-apps/lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/bin/ld: ./.libs/libsqlite3.so: dlsym: invalid version 5 (max 0) ./.libs/libsqlite3.so: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [sqlite3] Error 1 libsqlite.a is usable. I have no idea about libsqlite3.so usability. Both compilers work fine on all others programs I have tried to build. If I replace libsqlite3.so by libsqlite3.a, link stage can be done without error: tchaikovski:[~/rpl/build/tools/sqlite-3.6.22] gcc -DSQLITE_THREADSAFE=0 -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -mtune=niagara -mcpu=niagara -m64 -m64 -m64 -m64 -o .libs/sqlite3 shell.o -L/usr/lib/sparcv9 ./.libs/libsqlite3.a -lreadline -lcurses -Wl,--rpath -Wl,/usr/local/lib tchaikovski:[~/rpl/build/tools/sqlite-3.6.22] Gcc options are: tchaikovski:[~/rpl/build/tools/sqlite-3.6.22] gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../gcc-4.4.3/configure --prefix=/usr/shared-apps --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-nls --enable-checking=release --with-mpfr=/usr/shared-apps/ --with-gnu-ld --enable-bootstrap Thread model: posix gcc version 4.4.3 (GCC) I have checked mpfr and gmp and I use binutils 2.20.1. On another sparc server (sun4u, dual UltraSPARC-III) running debian/squeeze with gcc-4.4 (gcc version 4.4.3 20100108), I cannot reproduce this bug. Regards, JKB -- Summary: dlsym: invalid version 5 (max 0) Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mt1 at systella dot fr GCC build triplet: sparc-sun-solaris2.10 GCC host triplet: sparc-sun-solaris2.10 GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43429
[Bug tree-optimization/43424] -O2 -floop-parallelize-all causes verify_stmts failure
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-18 20:22 ---
Reduced testcase:
struct vector
{
long operator[](int __n) { return *(_M_start + __n); }
~vector();
long *_M_start;
};
long v_gcd();
void v_make_prime(vector v,long g, long j){
int i;
vector w;
g=v_gcd();
for (i = 0; i j; i++)
w[i]=v[i]/g;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-03-18 20:22:06
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43424
[Bug tree-optimization/43430] New: Missed vectorization: stmt not supported: cond_expr
This code from FFmpeg is not vectorized:
gcc-4.5 -c vsad_intra.c -O3 -ffast-math -ftree-vectorizer-verbose=7 -msse2
[...]
vsad_intra.c:15: note: not vectorized: relevant stmt not supported: iftmp.0_7 =
[cond_expr] iftmp.0_35 0 ? iftmp.0_77 : iftmp.0_35;
typedef short DCTELEM;
typedef unsigned char uint8_t;
typedef long int x86_reg;
typedef unsigned int uint32_t;
typedef unsigned long int uint64_t;
int
vsad16_c (void *c, uint8_t * s1, uint8_t * s2, int stride, int h)
{
int score = 0;
int x, y;
for (y = 1; y h; y++)
{
for (x = 0; x 16; x++)
{
score +=
((s1[x] - s2[x] - s1[x + stride] + s2[x + stride]) =
0 ? (s1[x] - s2[x] - s1[x + stride] +
s2[x + stride]) : (-(s1[x] - s2[x] - s1[x + stride] +
s2[x + stride])));
}
s1 += stride;
s2 += stride;
}
return score;
}
--
Summary: Missed vectorization: stmt not supported: cond_expr
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: spop at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43430
[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory
--- Comment #15 from jakub at gcc dot gnu dot org 2010-03-18 20:30 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
[Bug debug/42873] [4.5 Regression] deadlock in var tracking in recent builds
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-18 20:31 --- Fixed, thanks Alex. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42873
[Bug bootstrap/43403] [4.5 Regression] ICE in stage1 compiling __bswapdi2
--- Comment #10 from jakub at gcc dot gnu dot org 2010-03-18 20:31 --- Does it work now? -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43403
[Bug middle-end/20491] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042
--- Comment #37 from jakub at gcc dot gnu dot org 2010-03-18 20:35 --- The latter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20491
[Bug bootstrap/43403] [4.5 Regression] ICE in stage1 compiling __bswapdi2
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2010-03-18 20:36 --- Subject: Re: [4.5 Regression] ICE in stage1 compiling __bswapdi2 Does it work now? Full regression test isn't complete. Bootstrap was successful and no regressions were observed in gcc and acats tests. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43403
