[Bug libgomp/45351] New: many unaligned accesses in libgomp tests
I'm not sure if all of these are within libgomp, definitely some are, maybe all. alphaev67-dec-osf5.1 === libgomp tests === Schedule of variations: unix Running target unix Using /home/jayk/share/dejagnu/baseboards/unix.exp as board description file for target. Using /home/jayk/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/jayk/src/gcc-4.5.1/libgomp/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/jayk/src/gcc-4.5.1/libgomp/testsuite/libgomp.c/c.exp ... Unaligned access pid=152418 a.15.1.exe va=0x14000a35e pc=0x3ff80ba63d4 ra=0x3ff80ba63 ... I removed all the pids and addresses and sort | uniq... Unaligned access a.15.1.exe Unaligned access a.16.1.exe Unaligned access a.18.1.exe Unaligned access a.19.1.exe Unaligned access a.2.1.exe Unaligned access a.21.1.exe Unaligned access a.22.7.exe Unaligned access a.22.8.exe Unaligned access a.26.1.exe Unaligned access a.28.1.exe Unaligned access a.28.2.exe Unaligned access a.28.3.exe Unaligned access a.28.4.exe Unaligned access a.29.1.exe Unaligned access a.31.4.exe Unaligned access a.31.5.exe Unaligned access a.36.1.exe Unaligned access a.39.1.exe Unaligned access a.4.1.exe Unaligned access a.5.1.exe Unaligned access a10.1.exe Unaligned access allocatable1.exe Unaligned access allocatable2.exe Unaligned access allocatable3.exe Unaligned access allocatable4.exe Unaligned access allocatable5.exe Unaligned access atomic-3.exe Unaligned access atomic-4.exe Unaligned access atomic-5.exe Unaligned access barrier-1.exe Unaligned access character1.exe Unaligned access character2.exe Unaligned access collapse-1.exe Unaligned access collapse-2.exe Unaligned access collapse-3.exe Unaligned access collapse1.exe Unaligned access collapse2.exe Unaligned access collapse3.exe Unaligned access collapse4.exe Unaligned access copyin-1.exe Unaligned access copyin-2.exe Unaligned access copyin-3.exe Unaligned access crayptr1.exe Unaligned access crayptr2.exe Unaligned access critical-1.exe Unaligned access critical-2.exe Unaligned access ctor-1.exe Unaligned access ctor-10.exe Unaligned access ctor-11.exe Unaligned access ctor-12.exe Unaligned access ctor-2.exe Unaligned access ctor-3.exe Unaligned access ctor-4.exe Unaligned access ctor-5.exe Unaligned access ctor-6.exe Unaligned access ctor-7.exe Unaligned access ctor-8.exe Unaligned access ctor-9.exe Unaligned access debug-1.exe Unaligned access do1.exe Unaligned access do2.exe Unaligned access for-1.exe Unaligned access for-2.exe Unaligned access for-3.exe Unaligned access for-4.exe Unaligned access for-5.exe Unaligned access for-6.exe Unaligned access for-7.exe Unaligned access for-8.exe Unaligned access icv-1.exe Unaligned access jacobi.exe Unaligned access lastprivate1.exe Unaligned access lastprivate2.exe Unaligned access lib-1.exe Unaligned access lib-2.exe Unaligned access lib1.exe Unaligned access lib2.exe Unaligned access lib3.exe Unaligned access lib4.exe Unaligned access lock-1.exe Unaligned access lock-2.exe Unaligned access loop-1.exe Unaligned access loop-10.exe Unaligned access loop-11.exe Unaligned access loop-12.exe Unaligned access loop-2.exe Unaligned access loop-3.exe Unaligned access loop-4.exe Unaligned access loop-5.exe Unaligned access loop-6.exe Unaligned access loop-7.exe Unaligned access loop-8.exe Unaligned access loop-9.exe Unaligned access master-1.exe Unaligned access nested-1.exe Unaligned access nested-2.exe Unaligned access nested-3.exe Unaligned access nested1.exe Unaligned access nestedfn-1.exe Unaligned access nestedfn-3.exe Unaligned access nestedfn-4.exe Unaligned access nestedfn-5.exe Unaligned access nestedfn-6.exe Unaligned access nestedfn1.exe Unaligned access nestedfn2.exe Unaligned access nestedfn3.exe Unaligned access nestedfn4.exe Unaligned access nqueens-1.exe Unaligned access omp-loop01.exe Unaligned access omp-loop02.exe Unaligned access omp-loop03.exe Unaligned access omp-nested-1.exe Unaligned access omp-parallel-for Unaligned access omp-parallel-if. Unaligned access omp-single-1.exe Unaligned access omp-single-2.exe Unaligned access omp-single-3.exe Unaligned access omp_hello.exe Unaligned access omp_matvec.exe Unaligned access omp_orphan.exe Unaligned access omp_parse1.exe Unaligned access omp_parse2.exe Unaligned access omp_parse3.exe Unaligned access omp_parse4.exe Unaligned access omp_reduction.ex Unaligned access omp_workshare1.e Unaligned access omp_workshare2.e Unaligned access omp_workshare4.e Unaligned access ordered-1.exe Unaligned access ordered-2.exe Unaligned access ordered-3.exe Unaligned access parallel-1.exe Unaligned access pr24455.exe Unaligned access pr25162.exe Unaligned access pr25219.exe Unaligned access pr26691.exe Unaligned access pr26943-1.exe Unaligned access pr26943-2.exe Unaligned access pr26943-3.exe Unaligned access pr26943-4.exe Unaligned access pr26943.exe Unaligned access pr27337.exe Unaligned access pr27395-1.exe Unaligned access pr27395-2.exe
[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)
--- Comment #8 from linuxl4 at sohu dot com 2010-08-20 06:50 --- Error: Dummy 'x' at (1) cannot have an initializer I think this is easy to understand, an additional short message about why it can't have an initializer will be better. It helps if you already state (a) the error message and (b) what you expect in the first description. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337
[Bug rtl-optimization/44691] [4.6 Regression] ICE: RTL check: expected code 'reg', have 'plus' in rhs_regno, at rtl.h:1050
--- Comment #6 from abel at gcc dot gnu dot org 2010-08-20 08:07 --- Subject: Bug 44691 Author: abel Date: Fri Aug 20 08:07:17 2010 New Revision: 163396 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163396 Log: PR rtl-optimization/44691 * gfortran.dg/pr44691.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr44691.f Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44691
[Bug fortran/45344] [4.5 Regression] Many Fortran test failures
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-20 08:41 --- Subject: Bug 45344 Author: jakub Date: Fri Aug 20 08:41:00 2010 New Revision: 163397 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163397 Log: PR fortran/45344 Backport from mainline 2010-05-14 Jakub Jelinek ja...@redhat.com * trans.c (trans_code): Set backend locus early. * trans-decl.c (gfc_get_fake_result_decl): Use source location of the function instead of current input_location. * gfortran.dg/gomp/pr44036-1.f90: Adjust. Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/trans-decl.c branches/gcc-4_5-branch/gcc/fortran/trans.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/gomp/pr44036-1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45344
[Bug fortran/45344] [4.5 Regression] Many Fortran test failures
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-20 08:43 --- 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=45344
[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing
--- Comment #7 from burnus at gcc dot gnu dot org 2010-08-20 08:43 --- Comparison of the recurrence version with calling the library every time (for the run-time library, I expect a similar result for MPFR/compile time version): http://gcc.gnu.org/ml/fortran/2010-08/msg00252.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36158
[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)
--- Comment #9 from burnus at gcc dot gnu dot org 2010-08-20 08:45 --- (In reply to comment #8) Error: Dummy 'x' at (1) cannot have an initializer I think this is easy to understand, an additional short message about why it can't have an initializer will be better. Do you have a suggestion? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337
[Bug bootstrap/45350] [4.6 Regression] Failed to bootstrap on Linux/ia64
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-20 08:55 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45350
[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)
--- Comment #10 from jv244 at cam dot ac dot uk 2010-08-20 08:57 --- (In reply to comment #9) (In reply to comment #8) Error: Dummy 'x' at (1) cannot have an initializer Do you have a suggestion? Error: Dummy argument 'x' at (1) cannot have the save attribute which is implied by initialization. ?? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337
[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated
--- Comment #14 from hubicka at gcc dot gnu dot org 2010-08-20 10:23 --- http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01544.html has patch for empty constructor removal in middle end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45307
[Bug rtl-optimization/45352] New: ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058
Command line: $ gcc -O1 -frerun-cse-after-loop -ftree-vectorize -fschedule-insns -fschedule-insns2 -fselective-scheduling2 -fsel-sched-pipelining -funroll-loops -fprefetch-loop-arrays testcase.c or $ gcc -O3 -fschedule-insns -fschedule-insns2 -fselective-scheduling2 -fsel-sched-pipelining -funroll-loops -fprefetch-loop-arrays testcase.c I came to this problem in several testcases, but the set of options could never be reduced more. Compiler output: $ gcc -O1 -frerun-cse-after-loop -ftree-vectorize -fschedule-insns -fschedule-insns2 -fselective-scheduling2 -fsel-sched-pipelining -funroll-loops -fprefetch-loop-arrays testcase.c testcase.c: In function 'main1': testcase.c:10:1: internal compiler error: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r163371 - crash -- Summary: ICE: in reset_sched_cycles_in_current_ebb, at sel- sched.c:7058 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz 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=45352
[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058
--- Comment #1 from zsojka at seznam dot cz 2010-08-20 11:15 --- Created an attachment (id=21528) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21528action=view) reduced testcase (from gcc.dg/vect/no-vfa-vect-43.c) The first loop is not needed to reproduce the problem, it just makes values initialized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45352
[Bug rtl-optimization/45353] New: ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in sel_bb_head, at sel-sched-ir.c:4329 with -fselective-scheduling and __builtin_unreachable()
Command line:
$ gcc -O -fschedule-insns -fselective-scheduling testcase.c
Compiler output:
$ gcc -O -fschedule-insns -fselective-scheduling testcase.ctestcase.c: In
function 'foo':
testcase.c:4:1: internal compiler error: RTL check: expected elt 3 type 'B',
have '0' (rtx barrier) in sel_bb_head, at sel-sched-ir.c:4329
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
- testcase.c
void foo ()
{
__builtin_unreachable ();
}
-
Current testcases from testsuite, such as gcc.dg/builtin-unreachable-3.c, ICE
as well with given flags.
Tested revisions:
r163371 - crash
--
Summary: ICE: RTL check: expected elt 3 type 'B', have '0' (rtx
barrier) in sel_bb_head, at sel-sched-ir.c:4329 with -
fselective-scheduling and __builtin_unreachable()
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
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=45353
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #34 from howarth at nitro dot med dot uc dot edu 2010-08-20 11:39 --- No breakage in current bootstrap. -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[Bug middle-end/43359] gas_dyn benchmark exhibits missed vectorization with graphite
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-08-20 11:45 --- Fixed at graphite branch merge r163105 through r163174. -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43359
[Bug tree-optimization/45354] New: ICE: verify_flow_info failed: fallthru edge crosses section boundary (bb 6) with gcc.dg/tree-prof/update-cunroll-2.c
Command line: $ gcc -O -fschedule-insns -fselective-scheduling -freorder-blocks-and-partition -fprofile-generate gcc.dg/tree-prof/update-cunroll-2.c $ rm *.gcda $ ./a.out $ gcc -O -fschedule-insns -fselective-scheduling -freorder-blocks-and-partition -fprofile-use gcc.dg/tree-prof/update-cunroll-2.c gcc.dg/tree-prof/update-cunroll-2.c: In function 't': gcc.dg/tree-prof/update-cunroll-2.c:12:1: error: fallthru edge crosses section boundary (bb 6) gcc.dg/tree-prof/update-cunroll-2.c:12:1: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I wasn't able to further reduce the testcase. Tested revisions: r163371 - crash -- Summary: ICE: verify_flow_info failed: fallthru edge crosses section boundary (bb 6) with gcc.dg/tree-prof/update- cunroll-2.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz 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=45354
[Bug debug/45171] Invalid DWARF...DIE 0x00006a1d has multiple AT_byte_size attributes.
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2010-08-20 12:02 --- Fixed with r162882. -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45171
[Bug debug/42487] FAIL: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan-assembler DW_AT_ranges
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-08-20 12:04 --- Fixed with r163326. -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42487
[Bug rtl-optimization/45353] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in sel_bb_head, at sel-sched-ir.c:4329 with -fselective-scheduling and __builtin_unreachable()
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-20 12:21 --- Created an attachment (id=21529) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21529action=view) gcc46-pr45353.patch Untested fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45353
[Bug tree-optimization/44997] [4.6 regression] tree-chrec introduces broken asm code
--- Comment #9 from jakub at gcc dot gnu dot org 2010-08-20 12:38 --- Invalid. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44997
[Bug middle-end/45355] New: [4.6 regression] FAIL: gcc.c-torture/compile/pr43164.c
On Linux/ia64, revision 163389 gave FAIL: gcc.c-torture/compile/pr43164.c -O2 (internal compiler error) FAIL: gcc.c-torture/compile/pr43164.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/pr43164.c -O2 -flto (internal compiler error) FAIL: gcc.c-torture/compile/pr43164.c -O2 -flto (test for excess errors) FAIL: gcc.c-torture/compile/pr43164.c -O2 -fwhopr (internal compiler error) FAIL: gcc.c-torture/compile/pr43164.c -O2 -fwhopr (test for excess errors) FAIL: gcc.c-torture/compile/pr43164.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/pr43164.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/pr43164.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/pr43164.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/pr43164.c -Os (internal compiler error) FAIL: gcc.c-torture/compile/pr43164.c -Os (test for excess errors) Revision 163371 is OK. -- Summary: [4.6 regression] FAIL: gcc.c-torture/compile/pr43164.c Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45355
[Bug middle-end/45355] [4.6 regression] FAIL: gcc.c-torture/compile/pr43164.c
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-20 13:52 --- We are running out of stack in recursive call: Program received signal SIGSEGV, Segmentation fault. 0x41bf3c90 in if_then_else_cond (x=0x23ef08d0, ptrue=0x6ef88070, pfalse=0x6ef88080) at ../../src-trunk/gcc/combine.c:8437 8437 enum machine_mode mode = GET_MODE (x); (gdb) bt #0 0x41bf3c90 in if_then_else_cond (x=0x23ef08d0, ptrue=0x6ef88070, pfalse=0x6ef88080) at ../../src-trunk/gcc/combine.c:8437 #1 0x41bf4190 in if_then_else_cond (x=0x23ef0900, ptrue=0x6ef88100, pfalse=0x6ef88110) at ../../src-trunk/gcc/combine.c:8472 #2 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, ptrue=0x6ef88190, pfalse=0x6ef881a0) at ../../src-trunk/gcc/combine.c:8472 #3 0x41bf4190 in if_then_else_cond (x=0x23ef0900, ptrue=0x6ef88220, pfalse=0x6ef88230) at ../../src-trunk/gcc/combine.c:8472 #4 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, ptrue=0x6ef882b0, pfalse=0x6ef882c0) at ../../src-trunk/gcc/combine.c:8472 #5 0x41bf4190 in if_then_else_cond (x=0x23ef0900, ptrue=0x6ef88340, pfalse=0x6ef88350) at ../../src-trunk/gcc/combine.c:8472 #6 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, ptrue=0x6ef883d0, pfalse=0x6ef883e0) at ../../src-trunk/gcc/combine.c:8472 #7 0x41bf4190 in if_then_else_cond (x=0x23ef0900, ptrue=0x6ef88460, pfalse=0x6ef88470) ---Type return to continue, or q return to quit--- at ../../src-trunk/gcc/combine.c:8472 #8 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, ptrue=0x6ef884f0, pfalse=0x6ef88500) at ../../src-trunk/gcc/combine.c:8472 #9 0x41bf4190 in if_then_else_cond (x=0x23ef0900, ptrue=0x6ef88580, pfalse=0x6ef88590) at ../../src-trunk/gcc/combine.c:8472 #10 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, ptrue=0x6ef88610, pfalse=0x6ef88620) at ../../src-trunk/gcc/combine.c:8472 #11 0x41bf4190 in if_then_else_cond (x=0x23ef0900, ptrue=0x6ef886a0, pfalse=0x6ef886b0) at ../../src-trunk/gcc/combine.c:8472 #12 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, ptrue=0x6ef88730, pfalse=0x6ef88740) at ../../src-trunk/gcc/combine.c:8472 #13 0x41bf4190 in if_then_else_cond (x=0x23ef0900, ptrue=0x6ef887c0, pfalse=0x6ef887d0) at ../../src-trunk/gcc/combine.c:8472 #14 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, ptrue=0x6ef88850, pfalse=0x6ef88860) at ../../src-trunk/gcc/combine.c:8472 #15 0x41bf4190 in if_then_else_cond (x=0x23ef0900, ---Type return to continue, or q return to quit--- ptrue=0x6ef888e0, pfalse=0x6ef888f0) at ../../src-trunk/gcc/combine.c:8472 #16 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, ptrue=0x6ef88970, pfalse=0x6ef88980) at ../../src-trunk/gcc/combine.c:8472 #17 0x41bf4190 in if_then_else_cond (x=0x23ef0900, ptrue=0x6ef88a00, pfalse=0x6ef88a10) at ../../src-trunk/gcc/combine.c:8472 #18 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, ptrue=0x6ef88a90, pfalse=0x6ef88aa0) at ../../src-trunk/gcc/combine.c:8472 #19 0x41bf4190 in if_then_else_cond (x=0x23ef0900, ptrue=0x6ef88b20, pfalse=0x6ef88b30) at ../../src-trunk/gcc/combine.c:8472 #20 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, ptrue=0x6ef88bb0, pfalse=0x6ef88bc0) at ../../src-trunk/gcc/combine.c:8472 #21 0x41bf4190 in if_then_else_cond (x=0x23ef0900, ptrue=0x6ef88c40, pfalse=0x6ef88c50) at ../../src-trunk/gcc/combine.c:8472 #22 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, ptrue=0x6ef88cd0, pfalse=0x6ef88ce0) at ../../src-trunk/gcc/combine.c:8472 ---Type return to continue, or q return to quit--- #23 0x41bf4190 in if_then_else_cond (x=0x23ef0900, ptrue=0x6ef88d60, pfalse=0x6ef88d70) at ../../src-trunk/gcc/combine.c:8472 #24 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, ptrue=0x6ef88df0, pfalse=0x6ef88e00) at ../../src-trunk/gcc/combine.c:8472 #25 0x41bf4190 in if_then_else_cond (x=0x23ef0900, ptrue=0x6ef88e80, pfalse=0x6ef88e90) at ../../src-trunk/gcc/combine.c:8472 #26 0x41bf4190 in if_then_else_cond (x=0x23ef08d0, ptrue=0x6ef88f10,
[Bug middle-end/45356] New: ICE: in main, at gcc.c:7175 with -fcompare-debug -save-temps and unusable PCH file
Commands needed: echo empty.h gcc empty.h -o testcase.h.gch echo '#include testcase.h' testcase.c gcc -fcompare-debug -save-temps testcase.c Output: testcase.c:1:22: error: one or more PCH files were found, but they were invalid testcase.c:1:22: error: use -Winvalid-pch for more information testcase.c:1:22: fatal error: testcase.h: No such file or directory compilation terminated. gcc: error: during -fcompare-debug recompilation gcc: internal compiler error: in main, at gcc.c:7175 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r163371 - crash -- Summary: ICE: in main, at gcc.c:7175 with -fcompare-debug -save- temps and unusable PCH file Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45356
[Bug bootstrap/45357] New: [4.6 regression] Revision 163403 Failed to bootstrap
On Linux/x86, revision 163403: http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00616.html gave: ../../src-trunk/gcc/lto/lto.c: In function 'lto_materialize_function': ../../src-trunk/gcc/lto/lto.c:161:3: error: implicit declaration of function 'has_analyzed_clone' [-Werror=implicit-function-declaration] ../../src-trunk/gcc/lto/lto.c: At top level: ../../src-trunk/gcc/lto/lto.c:124:1: error: 'has_analyzed_clone_p' defined but not used [-Werror=unused-function] cc1: all warnings being treated as errors -- Summary: [4.6 regression] Revision 163403 Failed to bootstrap Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45357
[Bug bootstrap/45357] [4.6 regression] Revision 163403 Failed to bootstrap
--- Comment #1 from hjl at gcc dot gnu dot org 2010-08-20 14:42 --- Subject: Bug 45357 Author: hjl Date: Fri Aug 20 14:42:28 2010 New Revision: 163405 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163405 Log: Replace has_analyzed_clone with has_analyzed_clone_p. 2010-08-20 H.J. Lu hongjiu...@intel.com PR bootstrap/45357 * lto.c (lto_materialize_function): Replace has_analyzed_clone with has_analyzed_clone_p. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45357
[Bug c/45358] New: =+ oddness
Hello,
there is a minor issue when =+ is used by accident instead of +=.
It is unfortunate there there is not even a warning, because this is a typo
that can cost lots and lots of time.
Furthermore it seems that =+ is was the old syntax in the old pre ANSI C.
=+ behaves like =
(mathematically it is of course the same, but the behavior is still wrong,
but there is also never a reason to write =+ instead of =)
#include stdio.h
int main(void) {
int a=1,b=1;
a += 2;
b =+ 2;
printf(a=%d b=%d\n,a,b);
return 0;
}
(no warning, not even with -Wall)
a=3 b=2
It would be nice if future version could at least throw a warning.
Regards
Christian Leber
--
Summary: =+ oddness
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christian at leber dot de
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45358
[Bug middle-end/44974] [4.6 Regression] Function with attribute noreturn omits a call to another function with noreturn
--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-20 15:13 --- Created an attachment (id=21530) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21530action=view) gcc46-pr44974.patch Untested fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44974
[Bug c/45358] =+ oddness
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-20 15:23 --- =+ in x =+ y; isn't one token, but two, it is the same as if you write x = + y ; And, unary + is standard C unary operator: The result of the unary + operator is the value of its (promoted) operand. The integer promotions are performed on the operand, and the result has the promoted type. So, I don't think there is anything that should be warned about, it is normal valid C. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45358
[Bug fortran/45305] Array-valued calles to elementals are not simplified
--- Comment #3 from dominiq at lps dot ens dot fr 2010-08-20 15:24 ---
With the patch in comment #2, some error messages are repeated several times:
for instance gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90 gives
/opt/gcc/work/gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90:8.26:
integer(1) :: a(2) = (/ Z'FF', Z'FF' /) ! { dg-error Arithmetic overflow }
1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1). This
check can be disabled with the option -fno-range-check
/opt/gcc/work/gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90:8.26:
integer(1) :: a(2) = (/ Z'FF', Z'FF' /) ! { dg-error Arithmetic overflow }
1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1). This
check can be disabled with the option -fno-range-check
/opt/gcc/work/gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90:8.33:
integer(1) :: a(2) = (/ Z'FF', Z'FF' /) ! { dg-error Arithmetic overflow }
1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1). This
check can be disabled with the option -fno-range-check
/opt/gcc/work/gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90:8.26:
integer(1) :: a(2) = (/ Z'FF', Z'FF' /) ! { dg-error Arithmetic overflow }
1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1). This
check can be disabled with the option -fno-range-check
instead of
/opt/gcc/work/gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90:8.26:
integer(1) :: a(2) = (/ Z'FF', Z'FF' /) ! { dg-error Arithmetic overflow }
1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1). This
check can be disabled with the option -fno-range-check
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45305
[Bug c/45358] =+ oddness
--- Comment #2 from schwab at linux-m68k dot org 2010-08-20 15:35 --- There is a lot of normal valid C we warn about... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45358
[Bug c/45358] =+ oddness
--- Comment #3 from redi at gcc dot gnu dot org 2010-08-20 15:36 --- Yes, if (b = 2) is valid and -Wparentheses warns about that. (In reply to comment #0) It would be nice if future version could at least throw a warning. Obviously it can't be anything *more* than a warning. N.B. at least in C++ there are valid reasons to use the + operator, such as turning an lvalue into an rvalue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45358
[Bug target/45359] New: poor -march=native choices for VIA C7 Esther processors
C7 is a x86 CPU from VIA based on Esther (C5J) core evolved from the Nehemiah+ (C5P) core found in the C3-2 line. /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 10 model name : VIA Esther processor 800MHz stepping: 9 cpu MHz : 399.008 cache size : 128 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx up pni est tm2 rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en bogomips: 798.02 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 32 bits virtual gcc -v -fverbose-asm -march=native -S test.c Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-gnu-unique-object --enable-lto --enable-plugin --disable-multilib --disable-libstdcxx-pch --with-system-zlib --with-ppl --with-cloog --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info Thread model: posix gcc version 4.5.1 (GCC) COLLECT_GCC_OPTIONS='-v' '-fverbose-asm' '-S' /usr/lib/gcc/i686-pc-linux-gnu/4.5.1/cc1 -quiet -v test.c -march=pentium-m -mtune=generic -quiet -dumpbase test.c -auxbase test -version -fverbose-asm -o test.s [snip] cat test.s # GNU C (GCC) version 4.5.1 (i686-pc-linux-gnu) # compiled by GNU C version 4.5.1, GMP version 5.0.1, MPFR version 3.0.0-p3, MPC version 0.8.2 # GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=62811 # options passed: test.c -march=pentium-m -mtune=generic -fverbose-asm # options enabled: -falign-loops -fargument-alias -fauto-inc-dec # -fbranch-count-reg -fcommon -fdelete-null-pointer-checks -fdwarf2-cfi-asm # -fearly-inlining -feliminate-unused-debug-types -ffunction-cse -fgcse-lm # -fident -finline-functions-called-once -fira-share-save-slots # -fira-share-spill-slots -fivopts -fkeep-static-consts # -fleading-underscore -fmath-errno -fmerge-debug-strings # -fmove-loop-invariants -fpcc-struct-return -fpeephole # -fsched-critical-path-heuristic -fsched-dep-count-heuristic # -fsched-group-heuristic -fsched-interblock -fsched-last-insn-heuristic # -fsched-rank-heuristic -fsched-spec -fsched-spec-insn-heuristic # -fsched-stalled-insns-dep -fshow-column -fsigned-zeros # -fsplit-ivs-in-unroller -ftrapping-math -ftree-cselim -ftree-forwprop # -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize # -ftree-parallelize-loops= -ftree-phiprop -ftree-pta -ftree-reassoc # -ftree-scev-cprop -ftree-slp-vectorize -ftree-vect-loop-version # -funit-at-a-time -fvect-cost-model -fverbose-asm # -fzero-initialized-in-bss -m32 -m80387 -m96bit-long-double # -maccumulate-outgoing-args -malign-stringops -mfancy-math-387 # -mfp-ret-in-387 -mfused-madd -mglibc -mieee-fp -mmmx -mno-red-zone # -mno-sse4 -mpush-args -msahf -msse -msse2 -mtls-direct-seg-refs -- Summary: poor -march=native choices for VIA C7 Esther processors Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: opod at nic-nac-project dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45359
[Bug c/45358] =+ oddness
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-20 16:02 --- I think we certainly don't want to warn for = +, or =/**/+, so if anything, there could be a warning for = token immediately followed by a token that makes a valid op= token (i.e. the same file, same line, column 1 above the = column). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45358
[Bug target/45336] pextr{b,w,d}, (worse than) redundant extensions
--- Comment #7 from hjl dot tools at gmail dot com 2010-08-20 16:54 ---
Created an attachment (id=21531)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21531action=view)
A patch
I talked to icc people. They think the return value should be
zero-extended to reflex what hardware does. However, we need to
optimize out sign_extend in:
(insn:TI 9 7 10 (set (reg:SI 0 ax [orig:68 D.6819 ] [68])
(zero_extend:SI (vec_select:QI (reg:V16QI 21 xmm0 [orig:64 x ] [64])
(parallel [
(const_int 4 [0x4])
]
/export/build/gnu/gcc/build-x86_64-linux/gcc/include/smmintrin.h:442 1681
{*sse4_1_pextrb}
(expr_list:REG_DEAD (reg:V16QI 21 xmm0 [orig:64 x ] [64])
(nil)))
(insn:TI 10 9 18 (set (reg:DI 0 ax [orig:67 D.6819 ] [67])
(sign_extend:DI (reg:SI 0 ax [orig:68 D.6819 ] [68]))) foo.c:3 126
{extendsidi2_rex64}
(nil))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45336
[Bug target/45360] New: arm: -mhard-float != -mfloat-abi=hard during linking
The GCC manual (ARM Options) states that -mhard-float is equivalent to -mfloat-abi=hard. However that does seem to be the case when it comes to linking: $ arm-elf-gcc -mfloat-abi=hard -print-file-name=libc.a /usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/fpu/libc.a $ arm-elf-gcc -mhard-float -print-file-name=libc.a /usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/libc.a $ arm-elf-gcc -mfloat-abi=hard -v -o hello hello.c ... COLLECT_GCC_OPTIONS='-mfloat-abi=hard' '-v' '-o' 'hello' /usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/bin/as.exe -mfloat-abi=hard -o /tmp/ccBX7XJa.o /tmp/ccm5rZK3.s COMPILER_PATH=/usr/lib/gcc/arm-elf/4.5.1/:/usr/lib/gcc/arm-elf/4.5.1/:/usr/lib/gcc/arm-elf/:/usr/lib/gcc/arm-elf/4.5.1/:/usr/lib/gcc/arm-elf/:/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/bin/ LIBRARY_PATH=/usr/lib/gcc/arm-elf/4.5.1/fpu/:/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/fpu/:/usr/lib/gcc/arm-elf/4.5.1/:/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/:/usr/arm-elf/sys-root/usr/lib/ COLLECT_GCC_OPTIONS='-mfloat-abi=hard' '-v' '-o' 'hello' /usr/lib/gcc/arm-elf/4.5.1/collect2.exe --sysroot=/usr/arm-elf/sys-root -X -o hello /usr/lib/gcc/arm-elf/4.5.1/fpu/crti.o /usr/lib/gcc/arm-elf/4.5.1/fpu/crtbegin.o /usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/fpu/crt0.o -L/usr/lib/gcc/arm-elf/4.5.1/fpu -L/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/fpu -L/usr/lib/gcc/arm-elf/4.5.1 -L/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib -L/usr/arm-elf/sys-root/usr/lib /tmp/cc4pxySH.o --start-group -lgcc -lc --end-group /usr/lib/gcc/arm-elf/4.5.1/fpu/crtend.o /usr/lib/gcc/arm-elf/4.5.1/fpu/crtn.o $ arm-elf-gcc -mhard-float -v -o hello hello.c ... COLLECT_GCC_OPTIONS='-mhard-float' '-v' '-o' 'hello' /usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/bin/as.exe -mfloat-abi=hard -o /tmp/ccQgFiBi.o /tmp/ccv7qPvG.s COMPILER_PATH=/usr/lib/gcc/arm-elf/4.5.1/:/usr/lib/gcc/arm-elf/4.5.1/:/usr/lib/gcc/arm-elf/:/usr/lib/gcc/arm-elf/4.5.1/:/usr/lib/gcc/arm-elf/:/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/bin/ LIBRARY_PATH=/usr/lib/gcc/arm-elf/4.5.1/:/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/:/usr/arm-elf/sys-root/usr/lib/ COLLECT_GCC_OPTIONS='-mhard-float' '-v' '-o' 'hello' /usr/lib/gcc/arm-elf/4.5.1/collect2.exe --sysroot=/usr/arm-elf/sys-root -X -o hello /usr/lib/gcc/arm-elf/4.5.1/crti.o /usr/lib/gcc/arm-elf/4.5.1/crtbegin.o /usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/crt0.o -L/usr/lib/gcc/arm-elf/4.5.1 -L/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib -L/usr/arm-elf/sys-root/usr/lib /tmp/ccQgFiBi.o --start-group -lgcc -lc --end-group /usr/lib/gcc/arm-elf/4.5.1/crtend.o /usr/lib/gcc/arm-elf/4.5.1/crtn.o Note that -mhard-float is translated to -mfloat-abi=hard when passed to the assembler but the fpu multilibs aren't added to LIBRARY_PATH, resulting in linking with the soft-float crt*.o and libraries. -- Summary: arm: -mhard-float != -mfloat-abi=hard during linking Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yselkowitz at users dot sourceforge dot net GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: arm-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45360
[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing
--- Comment #8 from burnus at gcc dot gnu dot org 2010-08-20 17:23 --- Created an attachment (id=21532) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21532action=view) Run-time implementation Possibly final patch, though not yet regtested. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Attachment #21526|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36158
[Bug middle-end/45361] New: gcc.target/i386/volatile-2.c failed
On Linux/x86-64. revision 163402 gave FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \\t]obj_5, -- Summary: gcc.target/i386/volatile-2.c failed Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45361
[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing
--- Comment #9 from burnus at gcc dot gnu dot org 2010-08-20 17:50 --- (In reply to comment #8) Created an attachment (id=21532) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21532action=view) [edit] Possibly final patch, though not yet regtested. Fails for: integer :: x(2) x = [1,2] print *, RESHAPE([x], [1,2]) end Probably due to trans-intrinsics.c change of copying the formal arg list - even though it looks OK in the debugger. I could not yet trace down where exactly it fails. GDB/valgrind show the line: Invalid read of size 4 at 0x57A7F9: gfc_conv_procedure_call (trans-expr.c:2755) by 0x58AF4E: conv_generic_with_optional_char_arg.constprop.32 (trans-intrinsic.c:3326) by 0x58BBDA: gfc_conv_intrinsic_function (trans-intrinsic.c:4917) but trans-expr.c:2755 is the line where gfc_conv_procedure_call is defined, which does not help me with debugging :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36158
[Bug testsuite/45361] gcc.target/i386/volatile-2.c failed
--- Comment #1 from ubizjak at gmail dot com 2010-08-20 17:57 --- This is testsuite problem, on x86_64 we have: movl$0, obj_5(%rip) movlobj_5(%rip), %eax vs. movl$0, obj_5 movlobj_5, %eax on x86_32. So, scan patterns should be updated to include (%rip) after the reference. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |testsuite Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-20 17:57:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45361
[Bug rtl-optimization/45353] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in sel_bb_head, at sel-sched-ir.c:4329 with -fselective-scheduling and __builtin_unreachable()
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-20 18:07 --- Subject: Bug 45353 Author: jakub Date: Fri Aug 20 18:07:12 2010 New Revision: 163412 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163412 Log: PR rtl-optimization/45353 * sel-sched-ir.c (sel_bb_head): Return NULL even if next_nonnote_insn after bb_note is a BARRIER. * gcc.dg/pr45353.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr45353.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45353
[Bug testsuite/45361] gcc.target/i386/volatile-2.c failed
--- Comment #2 from nathan at gcc dot gnu dot org 2010-08-20 18:12 --- Thanks Uros. Could you prepare a patch to match the x86_64 output -- given you have the hardware? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45361
[Bug rtl-optimization/45353] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in sel_bb_head, at sel-sched-ir.c:4329 with -fselective-scheduling and __builtin_unreachable()
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-20 18:35 --- 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=45353
[Bug middle-end/44974] [4.6 Regression] Function with attribute noreturn omits a call to another function with noreturn
--- Comment #6 from jakub at gcc dot gnu dot org 2010-08-20 18:49 --- Subject: Bug 44974 Author: jakub Date: Fri Aug 20 18:49:46 2010 New Revision: 163415 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163415 Log: PR middle-end/44974 * builtins.c (expand_builtin): Don't optimize away calls to DECL_LOOPING_CONST_OR_PURE_P builtins. * gcc.dg/pr44974.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr44974.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44974
[Bug preprocessor/45362] New: Dangling reference about saved cpp_macro for push/pop macro
The issue is that for the push/pop macro the old state of the macro (a cpp_macro reference) is stored. As this structure is handled by GC without a root, all get free'ed when garbage collection happens. This gc can lead to issues when such a saved node gets undefined and the node, which previously hold the cpp_macro reference, gets reused for a different macro. As the linked in the saved macro list isn't under control of gc and it doesn't have a gc root element, the stored reference gets invalid in such cases and can lead to segmentation faults due access to already free'ed memory. -- Summary: Dangling reference about saved cpp_macro for push/pop macro Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ktietz at gcc dot gnu dot org GCC target triplet: *-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug middle-end/44974] [4.6 Regression] Function with attribute noreturn omits a call to another function with noreturn
--- Comment #7 from jakub at gcc dot gnu dot org 2010-08-20 18:56 --- 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=44974
[Bug testsuite/45361] gcc.target/i386/volatile-2.c failed
--- Comment #3 from uros at gcc dot gnu dot org 2010-08-20 19:24 --- Subject: Bug 45361 Author: uros Date: Fri Aug 20 19:23:52 2010 New Revision: 163416 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163416 Log: PR testsuite/45361 * gcc.target/i386/volatile-2.c: Update scan strings to also include (%rip) for the memory reference on x86_64. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/volatile-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45361
[Bug c/45358] Diagnostic could be issued for old C style a =+ b and similar cases
-- steven at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-linux-gnu| GCC host triplet|x86_64-linux-gnu| GCC target triplet|x86_64-linux-gnu| Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2010-08-20 19:46:42 date|| Summary|=+ oddness |Diagnostic could be issued ||for old C style a =+ b and ||similar cases http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45358
[Bug testsuite/45361] gcc.target/i386/volatile-2.c failed
--- Comment #4 from ubizjak at gmail dot com 2010-08-20 20:49 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED GCC target triplet||x86_64-pc-linux-gnu Resolution||FIXED Target Milestone|--- |4.6.0 Version|4.5.3 |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45361
[Bug target/45336] pextr{b,w,d}, (worse than) redundant extensions
--- Comment #8 from jakub at gcc dot gnu dot org 2010-08-20 20:54 --- Subject: Bug 45336 Author: jakub Date: Fri Aug 20 20:54:25 2010 New Revision: 163420 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163420 Log: PR target/45336 * config/i386/sse.md (*sse4_1_pextrb): Add SWI48 mode iterator to cover zero extension into 64-bit register. (*sse2_pextrw): Likewise. (*sse4_1_pextrd_zext): New insn. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45336
[Bug target/45336] pextr{b,w,d}, (worse than) redundant extensions
--- Comment #9 from hjl at gcc dot gnu dot org 2010-08-20 20:58 --- Subject: Bug 45336 Author: hjl Date: Fri Aug 20 20:57:56 2010 New Revision: 163421 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163421 Log: Cast to unsigned short/char first for _mm_extract_epi16/_mm_extract_epi8. gcc/ 2010-08-20 H.J. Lu hongjiu...@intel.com PR target/45336 * config/i386/emmintrin.h (_mm_extract_epi16): Cast to unsigned short first. * config/i386/smmintrin.h (_mm_extract_epi8): Cast to unsigned char first. gcc/testsuite/ 2010-08-20 H.J. Lu hongjiu...@intel.com PR target/45336 * gcc.target/i386/pr45336-1.c: New. * gcc.target/i386/pr45336-2.c: Likewise. * gcc.target/i386/pr45336-3.c: Likewise. * gcc.target/i386/pr45336-4.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr45336-1.c trunk/gcc/testsuite/gcc.target/i386/pr45336-2.c trunk/gcc/testsuite/gcc.target/i386/pr45336-3.c trunk/gcc/testsuite/gcc.target/i386/pr45336-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/emmintrin.h trunk/gcc/config/i386/smmintrin.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45336
[Bug target/45363] New: libgcc fails to configure: cc1: internal compiler error: Illegal instruction: 4
This is the relevant part from sparc64-portbld-freebsd8.0/libgcc/config.log:
configure:3211: checking for suffix of object files
configure:3233: /usr/ports/lang/gcc45/work/build/./gcc/xgcc
-B/usr/ports/lang/gcc45/work/build/./gcc/
-B/usr/local/sparc64-portbld-freebsd8.0/bin/
-B/usr/local/sparc64-portbld-freebsd8.0/lib/ -isystem
/usr/local/sparc64-portbld-freebsd8.0/include -isystem
/usr/local/sparc64-portbld-freebsd8.0/sys-include-c -O2 -pipe -g
-I/usr/local/include -fno-strict-aliasing conftest.c 5
cc1: internal compiler error: Illegal instruction: 4
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
configure:3237: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME GNU C Runtime Library
| #define PACKAGE_TARNAME libgcc
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING GNU C Runtime Library 1.0
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL http://www.gnu.org/software/libgcc/;
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
--
Summary: libgcc fails to configure: cc1: internal compiler error:
Illegal instruction: 4
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gerald at pfeifer dot com
GCC host triplet: sparc64-portbld-freebsd8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45363
[Bug target/45363] libgcc fails to configure: cc1: internal compiler error: Illegal instruction: 4
--- Comment #1 from gerald at pfeifer dot com 2010-08-20 21:22 --- Created an attachment (id=21533) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21533action=view) Full sparc64-portbld-freebsd8.0/libgcc/config.log file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45363
[Bug target/45363] libgcc fails to configure: cc1: internal compiler error: Illegal instruction: 4
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-08-20 22:00 --- It looks like the cc1 compiler is miscompiled. Which stage of the bootstrap is this? Could you post a backtrace of cc1 from within gdb when it executes the illegal instruction? Is that a recent problem on the 4.5 branch? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING Version|4.5.3 |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45363
[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)
--- Comment #11 from burnus at gcc dot gnu dot org 2010-08-20 22:28 --- (In reply to comment #7) Untested patch: The patch is not sufficient as the following example shows for which no warning is printed: type t end type t type t2 integer :: j = 7 end type t2 contains subroutine x(a, b, c) type(t) ,intent(OUT) :: a = t() ! Wrong type(t2) ,intent(OUT) :: b = t2() ! Wrong type(t2) ,intent(OUT) :: c ! OK, default initializer end subroutine x end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337
[Bug tree-optimization/45260] [4.5/4.6 Regression] g++4.5: -prefetch-loop-arrays internal compiler error: in verify_expr, at tree-cfg.c:2541
--- Comment #5 from changpeng dot fang at amd dot com 2010-08-20 22:48 --- I have a fix: http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01625.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45260
[Bug middle-end/45230] gcc.c-torture/execute/strncmp-1.c ICEs with -fgraphite-identity
--- Comment #3 from spop at gcc dot gnu dot org 2010-08-20 23:50 --- Subject: Bug 45230 Author: spop Date: Fri Aug 20 23:49:58 2010 New Revision: 163432 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163432 Log: Add testcase for PR45230. 2010-08-20 Sebastian Pop sebastian@amd.com PR middle-end/45230 * gcc.dg/graphite/id-pr45230.c: New. Added: branches/graphite/gcc/testsuite/gcc.dg/graphite/id-pr45230.c Modified: branches/graphite/gcc/ChangeLog.graphite -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45230
[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9
--- Comment #50 from howarth at nitro dot med dot uc dot edu 2010-08-21 00:31 --- According to the darwin unwinder maintainers in the Snow Leopard libunwind sources... // The following functions are implemented to just call abort _Unwind_GetDataRelBase _Unwind_GetTextRelBase _Unwind_FindEnclosingFunction // The following functions are empty and do nothing __register_frame_info_bases __register_frame_info __register_frame_info_table_bases __register_frame_info_table __register_frame_table __deregister_frame_info __deregister_frame_info_bases -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug target/45336] pextr{b,w,d}, (worse than) redundant extensions
--- Comment #10 from tbptbp at gmail dot com 2010-08-21 00:49 ---
Subject: Re: pextr{b,w,d}, (worse than) redundant extensions
A quick check vs trunk tells me that not only pextr* are now sane but
about 2% movs*/movz* disappeared altogether (in that particular
binary).
Hat's off.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45336
[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9
--- Comment #51 from howarth at nitro dot med dot uc dot edu 2010-08-21 00:55 --- An additional clarification from the darwin unwinder developers on the status of the libunwind sources from Snow Leopard... Everything down in the darwin layer is supposed to be open source. It was a glitch that our libunwind did not get the right sign offs to make that happen in SnowLeopard. A fork was made in libunwind and incorporated into the open source lldb project. You can view those sources at: http://llvm.org/svn/llvmproject/lldb/trunk/source/Plugins/Process/Utility/libunwind/src/UnwindLevel1-gcc-ext.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug middle-end/45364] New: Apparent infinite loop while compiling wine's directx.c with -O1 -g
Building the attached code with gcc -m32 -O1 -g -c directx.i -o test.o takes forever. On a machine where gcc -m32 -O0 -g -c directx.i -o test.o finishes in 2.9 seconds and gcc -m32 -O2 -c directx.i -o test.o finishes in 15 seconds, I left gcc -m32 -O2 -g -c directx.i -o test.o running overnight and it still didn't finsh - either something is incredibly slow, or (more likely) it hits an infinite loop somewhere. -- Summary: Apparent infinite loop while compiling wine's directx.c with -O1 -g Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux 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=45364
[Bug middle-end/45364] Apparent infinite loop while compiling wine's directx.c with -O1 -g
--- Comment #1 from bero at arklinux dot org 2010-08-21 01:00 --- Created an attachment (id=21534) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21534action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45364
[Bug middle-end/45364] Compiling wine's directx.c with -O1 -g takes a very long time
--- Comment #2 from bero at arklinux dot org 2010-08-21 01:10 --- Assumed it was an infinite loop a bit too early -- it did finish after giving it some more time. There is a speed problem though. Updating summary and severity. -- bero at arklinux dot org changed: What|Removed |Added Severity|normal |enhancement Summary|Apparent infinite loop while|Compiling wine's directx.c |compiling wine's directx.c |with -O1 -g takes a very |with -O1 -g |long time http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45364
[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9
--- Comment #52 from howarth at nitro dot med dot uc dot edu 2010-08-21 02:24 --- Also the additional clarification that... The UnwindLevel1-gcc-ext.c source file in lldb is the same as in SnowLeopard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug target/45365] New: X86 FP add and multiply aren't commutative
According to table 4-7 in chapter 4, Vol 1 of IA32/Inte64 SDM, x86 FP add and multiply aren't commutative with Qnan/Snan inputs. But we have DEF_RTL_EXPR(PLUS, plus, ee, RTX_COMM_ARITH) DEF_RTL_EXPR(MULT, mult, ee, RTX_COMM_ARITH) That impacts x86 FP plus and mult patterns. Should we introduce a new target option to disable x86 commutative FP plus and mult? -- Summary: X86 FP add and multiply aren't commutative Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45365
[Bug target/45365] X86 FP add and multiply aren't commutative
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-21 03:54 ---
[...@gnu-6 intrin]$ cat mulpd.c
#include stdlib.h
#include string.h
#include stdint.h
#include emmintrin.h
__m128d a;
__m128d b;
uint64_t av[] = {0x0, 0xfff8ULL};
uint64_t bv[] = {0xffefULL, 0x7fff2d4db6efd985ULL};
uint64_t expa[] = {0x8000ULL, 0xfff8ULL};
uint64_t expb[] = {0x8000ULL, 0x7fff2d4db6efd985ULL};
void check_mulpd(__m128d const* op0, __m128d const* op1,
uint64_t *exp)
{
__m128d r = _mm_mul_pd (*op0, *op1);;
if (memcmp (r, exp, sizeof (r)))
abort ();
}
int main()
{
memcpy(a, av, sizeof(a));
memcpy(b, bv, sizeof(b));
check_mulpd(a, b, expa);
check_mulpd(b, a, expb);
return 0;
}
[...@gnu-6 intrin]$ make
gcc -g -o o0 mulpd.c
gcc -g -O2 -o o2 mulpd.c
./o2
./o0
make: *** [all] Aborted
[...@gnu-6 intrin]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45365
[Bug target/45365] X86 FP add and multiply aren't commutative
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-08-21 03:58 --- How are they are not commutative with respect of the NaNs? Is it only when both are operands are NaNs, it causes an issue? If I read your testcase correctly, x87 and SSE both don't do IEEE FP correctly with respect of NaNs. For multiply and add if either operand is a NaN, the result is also a NaN IIRC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45365
[Bug target/45365] X86 FP add and multiply aren't commutative
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-21 04:10 --- (In reply to comment #2) How are they are not commutative with respect of the NaNs? Is it only when both are operands are NaNs, it causes an issue? If I read your testcase correctly, x87 and SSE both don't do IEEE FP correctly with respect of NaNs. For multiply and add if either operand is a NaN, the result is also a NaN IIRC. The difference is QNaN and SNaN. They are both NaNs, but not the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45365
[Bug target/45365] X86 FP add and multiply aren't commutative
--- Comment #4 from hjl dot tools at gmail dot com 2010-08-21 04:14 --- (In reply to comment #2) How are they are not commutative with respect of the NaNs? Is it only when both are operands are NaNs, it causes an issue? Yes, only when both operands and NaNs with SSE FP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45365
[Bug bootstrap/44905] --enable-build-with-cxx bootstrap failure compiling gcc/cppdefault.c
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-08-21 04:20 --- Fixed with... Author: lcwu Date: Fri Jul 23 22:20:45 2010 New Revision: 162492 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162492 Log: Fix violations of self-assignment check in GCC source. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/dbxout.c trunk/gcc/omega.c trunk/gcc/tree-ssa-ccp.c -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44905
[Bug testsuite/45361] gcc.target/i386/volatile-2.c failed
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-08-21 05:11 --- The fix at r163416 caused... FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+, obj_0(\\(%rip\\))? FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+, obj_1(\\(%rip\\))? FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+, obj_2(\\(%rip\\))? FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+, obj_3(\\(%rip\\))? FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+, obj_4(\\(%rip\\))? FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+, obj_5(\\(%rip\\))? FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t]obj_5(\\(%rip\\))?, FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+, obj_6(\\(%rip\\))? FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+, obj_7(\\(%rip\\))? FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+, obj_8(\\(%rip\\))? on x86_64-apple-darwin10 at -m32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45361
[Bug middle-end/45364] Compiling wine's directx.c with -O1 -g takes a very long time
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-21 05:13 --- On Linux/Intel64, I got time /usr/gcc-4.5/bin/gcc -m32 -O2 pr45364.i -g -c /tmp /usr/gcc-4.5/bin/gcc -m32 -O2 pr45364.i -g -c 110.63s user 0.17s system 99% cpu 1:50.87 total [...@gnu-6 tmp]$ /usr/gcc-4.5/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/gcc-4.5/bin/gcc COLLECT_LTO_WRAPPER=/usr/gcc-4.5/libexec/gcc/x86_64-unknown-linux-gnu/4.5.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc-4.5/gcc/configure --enable-clocale=gnu --with-system-zlib --enable-checking=assert --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --prefix=/usr/gcc-4.5 --with-local-prefix=/usr/local --with-plugin-ld=ld.gold --enable-gold --with-fpmath=sse Thread model: posix gcc version 4.5.1 (GCC) [...@gnu-6 tmp]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45364
[Bug testsuite/45361] gcc.target/i386/volatile-2.c failed
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-08-21 05:15 --- Created an attachment (id=21535) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21535action=view) assembly file for gcc.target/i386/volatile-2.c at -m32 on x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45361
[Bug testsuite/45361] gcc.target/i386/volatile-2.c failed
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2010-08-21 05:16 --- Assembly created with... /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100820/gcc/testsuite/gcc.target/i386/volatile-2.c -O2 -S -m32 -o volatile-2.s using... Using built-in specs. COLLECT_GCC=gcc-4COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper Target: x86_64-apple-darwin10.5.0 Configured with: ../gcc-4.6-20100820/configure --prefix=/sw --prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --enable-build-with-cxx --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.6 --enable-lto --enable-checking=yes Thread model: posix gcc version 4.6.0 20100821 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45361
[Bug target/41323] Add new _mm_extract_epu16 intrinsic (resquest)
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-21 05:21 --- *** This bug has been marked as a duplicate of 45336 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41323
[Bug target/45336] pextr{b,w,d}, (worse than) redundant extensions
--- Comment #11 from hjl dot tools at gmail dot com 2010-08-21 05:21 --- *** Bug 41323 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||etjq78kl at free dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45336
