[Bug target/54051] New: Invalid alignment specifier generated for vld3_lane_* and vld3_dup_* intrinsics.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54051
Bug #: 54051
Summary: Invalid alignment specifier generated for vld3_lane_*
and vld3_dup_* intrinsics.
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: ram...@gcc.gnu.org
ReportedBy: ram...@gcc.gnu.org
Target: arm-*-*eabi
Build: x86*
#include arm_neon.h
int32_t a __attribute__ ((aligned (64)));
int32x2x3_t test (void)
{
return vld3_dup_s32 (a);
}
int32x2x3_t test1 (void)
{
int32x2x3_t res ;
return vld3_lane_s32 (a, res, 1);
}
/tmp/ccdQ3KCr.s: Assembler messages:
/tmp/ccdQ3KCr.s:24: Error: can't use alignment with this instruction --
`vld3.32 {d16[],d17[],d18[]},[r3:64]'
/tmp/ccdQ3KCr.s:50: Error: can't use alignment with this instruction --
`vld3.32 {d16[1],d17[1],d18[1]},[r3:64]'
This can be traced to the use of the Alignment specifiers in the appropriate
patterns and that needs to be fixed up.
[Bug target/54051] [4.7/ 4.8 regression] Invalid alignment specifier generated for vld3_lane_* and vld3_dup_* intrinsics.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54051 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-07-20 Known to work||4.6.3 Summary|Invalid alignment specifier |[4.7/ 4.8 regression] |generated for vld3_lane_* |Invalid alignment specifier |and vld3_dup_* intrinsics. |generated for vld3_lane_* ||and vld3_dup_* intrinsics. Ever Confirmed|0 |1 Known to fail||4.7.0, 4.7.1 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-07-20 14:35:25 UTC --- I have a patch for this.
[Bug target/53735] thumb1 spill failure with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53735 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords|assemble-failure| Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-17 Ever Confirmed|0 |1 Known to fail||4.8.0 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-07-17 09:34:05 UTC --- It's really not an assemble failure. The problem is in the compiler and it looks prima-facie like ICE on valid code.
[Bug rtl-optimization/53352] Incorrect CSE optimization on RTL expressions with a paradoxical subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53352 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #11 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-07-13 16:24:34 UTC --- (In reply to comment #10) The test fails on Linux/x86 and Linux/x86-64. http://gcc.gnu.org/ml/gcc-testresults/2012-07/msg00958.html doesn't suggest this test fails anymore ? HJ, should this now be marked as FIXED ? ramana
[Bug target/53859] ICE when calculate insn latency for armv7e-m arch in O2 level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53859 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org Target Milestone|--- |4.8.0
[Bug target/53659] ARM: Using -mcpu=cortex-a9 option results in bad performance for Cortex-A9 processor in C-Ray phoronix benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53659 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-07-12 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1
[Bug rtl-optimization/49891] [4.7 regression] ICE in redirect_jump_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49891 --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-07-05 16:45:29 UTC --- Author: ramana Date: Thu Jul 5 16:45:18 2012 New Revision: 189294 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189294 Log: 2012-07-05 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR target/49891 PR target/51980 * gcc/testsuite/gcc.target/arm/neon/vtrnf32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vtrns32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vtrnu32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzipf32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzips32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzipu32.c: Update. 2012-07-05 Ramana Radhakrishnan ramana.radhakrish...@linaro.org Julian Brown jul...@codesourcery.com PR target/49891 PR target/51980 * config/arm/neon-gen.ml (return_by_ptr): Delete. (print_function): Handle empty strings. (return): Delete use of return_by_ptr. (mask_shape_for_shuffle): New function. (mask_elems): Likewise. (shuffle_fn): Likewise. (params): Simplify and remove use of return_by_ptr. (get_shuffle): New function. (print_variant): Update. * config/arm/neon.ml (rev_elems): New function. (permute_range): Likewise. (zip_range): Likewise. (uzip_range): Likewise. (trn_range): Likewise. (zip_elems): Likewise. (uzip_elems): Likewise. (trn_elems): Likewise. (features): New enumeration Use_shuffle. Delete ReturnPtr. (pf_su_8_16): New. (suf_32): New. (ops): Update entries for Vrev64, Vrev32, Vrev16, Vtr, Vzip, Vuzp. * config/arm/arm_neon.h: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm_neon.h trunk/gcc/config/arm/neon-gen.ml trunk/gcc/config/arm/neon.ml trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/neon/vtrnf32.c trunk/gcc/testsuite/gcc.target/arm/neon/vtrns32.c trunk/gcc/testsuite/gcc.target/arm/neon/vtrnu32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzipf32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzips32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzipu32.c
[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980 --- Comment #6 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-07-05 16:45:32 UTC --- Author: ramana Date: Thu Jul 5 16:45:18 2012 New Revision: 189294 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189294 Log: 2012-07-05 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR target/49891 PR target/51980 * gcc/testsuite/gcc.target/arm/neon/vtrnf32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vtrns32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vtrnu32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzipf32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzips32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzipu32.c: Update. 2012-07-05 Ramana Radhakrishnan ramana.radhakrish...@linaro.org Julian Brown jul...@codesourcery.com PR target/49891 PR target/51980 * config/arm/neon-gen.ml (return_by_ptr): Delete. (print_function): Handle empty strings. (return): Delete use of return_by_ptr. (mask_shape_for_shuffle): New function. (mask_elems): Likewise. (shuffle_fn): Likewise. (params): Simplify and remove use of return_by_ptr. (get_shuffle): New function. (print_variant): Update. * config/arm/neon.ml (rev_elems): New function. (permute_range): Likewise. (zip_range): Likewise. (uzip_range): Likewise. (trn_range): Likewise. (zip_elems): Likewise. (uzip_elems): Likewise. (trn_elems): Likewise. (features): New enumeration Use_shuffle. Delete ReturnPtr. (pf_su_8_16): New. (suf_32): New. (ops): Update entries for Vrev64, Vrev32, Vrev16, Vtr, Vzip, Vuzp. * config/arm/arm_neon.h: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm_neon.h trunk/gcc/config/arm/neon-gen.ml trunk/gcc/config/arm/neon.ml trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/neon/vtrnf32.c trunk/gcc/testsuite/gcc.target/arm/neon/vtrns32.c trunk/gcc/testsuite/gcc.target/arm/neon/vtrnu32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzipf32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzips32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzipu32.c
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 --- Comment #12 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-07-05 16:56:23 UTC --- Author: ramana Date: Thu Jul 5 16:56:15 2012 New Revision: 189295 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189295 Log: Correct bug number to PR target/48941 First part of the fix . Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/49891] [4.7 regression] ICE in redirect_jump_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49891 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-07-05 16:56:53 UTC --- (In reply to comment #3) Author: ramana Date: Thu Jul 5 16:45:18 2012 New Revision: 189294 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189294 Log: 2012-07-05 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR target/49891 This should have been PR target/48941 . PR target/51980 * gcc/testsuite/gcc.target/arm/neon/vtrnf32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vtrns32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vtrnu32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzipf32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzips32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzipu32.c: Update. 2012-07-05 Ramana Radhakrishnan ramana.radhakrish...@linaro.org Julian Brown jul...@codesourcery.com PR target/49891 PR target/51980 * config/arm/neon-gen.ml (return_by_ptr): Delete. (print_function): Handle empty strings. (return): Delete use of return_by_ptr. (mask_shape_for_shuffle): New function. (mask_elems): Likewise. (shuffle_fn): Likewise. (params): Simplify and remove use of return_by_ptr. (get_shuffle): New function. (print_variant): Update. * config/arm/neon.ml (rev_elems): New function. (permute_range): Likewise. (zip_range): Likewise. (uzip_range): Likewise. (trn_range): Likewise. (zip_elems): Likewise. (uzip_elems): Likewise. (trn_elems): Likewise. (features): New enumeration Use_shuffle. Delete ReturnPtr. (pf_su_8_16): New. (suf_32): New. (ops): Update entries for Vrev64, Vrev32, Vrev16, Vtr, Vzip, Vuzp. * config/arm/arm_neon.h: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm_neon.h trunk/gcc/config/arm/neon-gen.ml trunk/gcc/config/arm/neon.ml trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/neon/vtrnf32.c trunk/gcc/testsuite/gcc.target/arm/neon/vtrns32.c trunk/gcc/testsuite/gcc.target/arm/neon/vtrnu32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzipf32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzips32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzipu32.c
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-07-05 17:01:39 UTC --- (In reply to comment #12) fixed by http://gcc.gnu.org/viewcvs?root=gccview=revrev=189294
[Bug c++/51033] generic vector subscript and shuffle support was not added to C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033 --- Comment #28 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-06-27 14:19:25 UTC --- Author: ramana Date: Wed Jun 27 14:19:17 2012 New Revision: 189017 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189017 Log: 2012-06-27 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR C++/51033 * semantics.c (constexpr_call): Fix typo in comment. (cxx_eval_vec_perm_expr): New. (cxx_eval_constant_expression): Fold VEC_PERM_EXPRs. 2012-06-27 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR c++/51033. * g++.dg/torture/vshuf-16.inc: New test. * g++.dg/torture/vshuf-2.inc: New test. * g++.dg/torture/vshuf-4.inc: New test. * g++.dg/torture/vshuf-8.inc: New test. * g++.dg/torture/vshuf-main.inc: New test. * g++.dg/torture/vshuf-v16hi.C: New test. * g++.dg/torture/vshuf-v16qi.C: New test. * g++.dg/torture/vshuf-v2df.C: New test. * g++.dg/torture/vshuf-v2di.C: New test. * g++.dg/torture/vshuf-v2sf.C: New test. * g++.dg/torture/vshuf-v2si.C: New test. * g++.dg/torture/vshuf-v4df.C: New test. * g++.dg/torture/vshuf-v4di.C: New test. * g++.dg/torture/vshuf-v4sf.C: New test. * g++.dg/torture/vshuf-v4si.C: New test. * g++.dg/torture/vshuf-v8hi.C: New test. * g++.dg/torture/vshuf-v8qi.C: New test. * g++.dg/torture/vshuf-v8si.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/vshuf-16.inc trunk/gcc/testsuite/g++.dg/torture/vshuf-2.inc trunk/gcc/testsuite/g++.dg/torture/vshuf-4.inc trunk/gcc/testsuite/g++.dg/torture/vshuf-8.inc trunk/gcc/testsuite/g++.dg/torture/vshuf-main.inc trunk/gcc/testsuite/g++.dg/torture/vshuf-v16hi.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v16qi.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v2df.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v2di.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v2sf.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v2si.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v4df.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v4di.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v4sf.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v4si.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v8hi.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v8qi.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v8si.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug target/46883] GCC ICE with error: unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46883 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #8 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-06-22 10:40:23 UTC --- Marking as fixed as I can see it fixed with 4.6.0 release , 4.6 branch, 4.7 branch and trunk.
[Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-06-20
CC||jules at gcc dot gnu.org,
||ramana at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-06-20
10:16:28 UTC ---
The 54 duplicates are with a quick use of sed, awk and grep.
vld2Qf32.c vld2Qp16.c vld2Qp8.c vld2Qs16.c vld2Qs32.c vld2Qs8.c vld2Qu16.c
vld2Qu32.c vld2Qu8.c
vld3Qf32.c vld3Qp16.c vld3Qp8.c vld3Qs16.c vld3Qs32.c vld3Qs8.c vld3Qu16.c
vld3Qu32.c vld3Qu8.c vld4Qf32.c vld4Qp16.c vld4Qp8.c vld4Qs16.c vld4Qs32.c
vld4Qs8.c vld4Qu16.c vld4Qu32.c vld4Qu8.c vst2Qf32.c vst2Qp16.c vst2Qp8.c
vst2Qs16.c vst2Qs32.c vst2Qs8.c vst2Qu16.c vst2Qu32.c vst2Qu8.c vst3Qf32.c
vst3Qp16.c vst3Qp8.c vst3Qs16.c vst3Qs32.c vst3Qs8.c vst3Qu16.c vst3Qu32.c
vst3Qu8.c vst4Qf32.c vst4Qp16.c vst4Qp8.c vst4Qs16.c vst4Qs32.c vst4Qs8.c
vst4Qu16.c vst4Qu32.c vst4Qu8.c
However these really are not duplicates of scan-assembler directives. The
vld{3,4} instructions with 128 bit vector types should generate 2 vld{3,4}
instructions.
However there is a bug in the v{ld/st}2Q{type}.c tests where there should be
just one single vld2 instruction generated as these can deal with 4 registers.
Ramana
[Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664 --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-06-20 14:59:33 UTC --- (In reply to comment #2) Two scan-assembler directives with the same search string don't look for two instances of the same string, they just look for the same thing twice and pass if that string only occurs once. To look for two of them you'd need scan-assembler-times, with 2 as the expected number. Agreed - Aargh .That bit of my post appears to have disappeared. Ramana
[Bug c++/51033] generic vector subscript and shuffle support was not added to C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033 --- Comment #27 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-06-15 16:43:44 UTC --- Author: ramana Date: Fri Jun 15 16:43:36 2012 New Revision: 188671 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188671 Log: 2012-06-15 Marc Glisse marc.gli...@inria.fr PR c++/51033 * c-typeck.c (c_build_vec_perm_expr): Move to c-family/c-common.c. * c-tree.h (c_build_vec_perm_expr): Move to c-family/c-common.h. cp/ 2012-06-15 Marc Glisse marc.gli...@inria.fr PR c++/51033 * semantics.c (literal_type_p): Handle VECTOR_TYPE. (potential_constant_expression_1): Handle VEC_PERM_EXPR. * parser.c (cp_parser_postfix_expression): Handle RID_BUILTIN_SHUFFLE. c-family 2012-06-15 Marc Glisse marc.gli...@inria.fr PR c++/51033 * c-common.h (c_build_vec_perm_expr): Move decl here. * c-common.c (c_build_vec_perm_expr): Move definition here. 2012-06-15 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR c++/51033 * c-c++-common/torture/vshuf-16.inc: Move from gcc.c-torture/execute/. * c-c++-common/torture/vshuf-2.inc: Likewise. * c-c++-common/torture/vshuf-4.inc: Likewise. * c-c++-common/torture/vshuf-8.inc: Likewise. * c-c++-common/torture/vshuf-main.inc: Likewise. * c-c++-common/torture/vshuf-v16hi.c: Likewise. * c-c++-common/torture/vshuf-v16qi.c: Likewise. * c-c++-common/torture/vshuf-v2df.c: Likewise. * c-c++-common/torture/vshuf-v2di.c: Likewise. * c-c++-common/torture/vshuf-v2sf.c: Likewise. * c-c++-common/torture/vshuf-v2si.c: Likewise. * c-c++-common/torture/vshuf-v4df.c: Likewise. * c-c++-common/torture/vshuf-v4di.c: Likewise. * c-c++-common/torture/vshuf-v4hi.c: Likewise. * c-c++-common/torture/vshuf-v4sf.c: Likewise. * c-c++-common/torture/vshuf-v4si.c: Likewise. * c-c++-common/torture/vshuf-v8hi.c: Likewise. * c-c++-common/torture/vshuf-v8qi.c: Likewise. * c-c++-common/torture/vshuf-v8si.c: Likewise. Added: trunk/gcc/testsuite/c-c++-common/torture/vshuf-16.inc - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-16.inc trunk/gcc/testsuite/c-c++-common/torture/vshuf-2.inc - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-2.inc trunk/gcc/testsuite/c-c++-common/torture/vshuf-4.inc - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-4.inc trunk/gcc/testsuite/c-c++-common/torture/vshuf-8.inc - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-8.inc trunk/gcc/testsuite/c-c++-common/torture/vshuf-main.inc - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-main.inc trunk/gcc/testsuite/c-c++-common/torture/vshuf-v16hi.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v16hi.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v16qi.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v16qi.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v2df.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v2df.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v2di.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v2di.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v2sf.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v2sf.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v2si.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v2si.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v4df.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4df.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v4di.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4di.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v4hi.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4hi.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v4sf.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4sf.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v4si.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4si.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v8hi.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v8hi.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v8qi.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v8qi.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v8si.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v8si.c Removed: trunk/gcc/testsuite/gcc.c-torture/execute
[Bug c++/51033] generic vector subscript and shuffle support was not added to C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #26 from Ramana Radhakrishnan ramana at gcc dot gnu.org
2012-06-14 11:22:26 UTC ---
(In reply to comment #23)
(In reply to comment #21)
What does it mean exercise the backend a lot? Do you mean it takes a lot
of
time?
I think so.
I haven't looked at the tests, but I think it is not a problem to run
compile-only tests with both gcc and g++.
compile-time tests are not always sufficient.
The __builtin_shuffle tests are spread in:
gcc.dg{,/torture}
gcc.target/{i386,powerpc}
gcc.c-torture/{compile,execute}
I assume the tests in gcc.dg can move to c-c++-common. The target tests should
stay in target. Not sure about gcc.c-torture.
But one interesting thing to test is if the front-end passes the arguments as
constants and thus the backend can use specialized code instead of the slow
generic one. And this kind of test seems necessarily target-specific. Bah, I
guess I shouldn't ask for too much and moving the gcc.dg tests would be
enough.
Patch posted for comments here :
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00903.html
[Bug target/51509] Inefficient neon intrinsic code sequence
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51509 --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-06-15 00:51:26 UTC --- With -fno-split-wide-types I can end up getting identical output to what is expected in this case with FSF trunk. I suspect this might be another of those costs with lower-subreg issues. Ramana
[Bug c++/51033] generic vector subscript and shuffle support was not added to C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #25 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-06-13 15:14:16 UTC --- (In reply to comment #19) Created attachment 27217 [details] shuffle With this patch, g++ passes the few __builtin_shuffle tests I tried, and generates generic code for non-constant indexes and special code for constant indexes. I don't really know what to do about the testsuite. The tests exercise the backend a lot, and it probably doesn't make sense to run everything with both gcc and g++. But we still want to test that g++ accepts the syntax, and maybe even that it handles constants well. Content of the patch: - move c_build_vec_perm_expr to c-common and condition the maybe_const stuff to the dialect - adapt the C RID_BUILTIN_SHUFFLE parser code to the C++ FE (the 2 are different enough that it isn't easy to share) - remove the C_ONLY tag from __builtin_shuffle As usual, my limited knowledge of the compiler means I may have missed fundamental things. Are you planning on submitting the shuffle patch as well ?
[Bug rtl-optimization/53558] New: Register allocator doesn't tie return value register to output variable.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53558
Bug #: 53558
Summary: Register allocator doesn't tie return value register
to output variable.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ram...@gcc.gnu.org
Given the testcase below GCC generates extra moves to return value registers on
ARM v7-a linux-gnueabi . Disabling the smax insn pattern or the generic 3
operand condition move to doesn't really help
This also appears to be a problem on other architectures given the register
allocator fails to merge the copy of the result value in to the result .The
*arm_smax_insn pattern looks like the following. Debuggging the register
allocator showed that param 0,1, and 2 are in r1, r2 and r0 . However there is
probably an easier fit with r0, r2 and r0 given r0 and r2 die as well in this
instruction. I might be missing something here.
(define_insn *arm_smax_insn
[(set (match_operand:SI 0 s_register_operand =r,r)
(smax:SI (match_operand:SI 1 s_register_operand %0,?r)
(match_operand:SI 2 arm_rhs_operandrI,rI)))
(clobber (reg:CC CC_REGNUM))]
TARGET_ARM
@
cmp\\t%1, %2\;movlt\\t%0, %2
cmp\\t%1, %2\;movge\\t%0, %1\;movlt\\t%0, %2
[(set_attr conds clob)
(set_attr length 8,12)]
)
typedef unsigned int uint32_t;
typedef unsigned long long uint64_t;
typedef unsigned long uintptr_t;
typedef unsigned short uint16_t;
void f2(char *d, char const *s, int flags)
{
uint32_t tmp0, tmp1;
if (flags 1)
tmp0 = *s++;
if (flags 2)
{
uint16_t *ss = (void *)s;
tmp1 = *ss++;
s = (void *)ss;
}
if (flags 1)
*d++ = tmp0;
if (flags 2)
{
uint16_t *dd = (void *)d;
*dd++ = tmp1;
d = (void *)dd;
}
}
[Bug target/53334] [4.8 Regression] ICE in extract_insn, at recog.c:2131
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53334 --- Comment #6 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-05-22 09:07:03 UTC --- Author: ramana Date: Tue May 22 09:06:55 2012 New Revision: 187761 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187761 Log: Fix PR target/53334 2012-05-22 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR target/53334 * config/arm/arm-protos.h (arm_validize_comparison): Declare. * config/arm/arm.c (arm_validize_comparison): Define. * config/arm/arm.md (cbranchsi4): Cleanup expansion and use arm_validize_comparison. (cbranchdi4): Likewise. (cstoredi4): Likewise. (movsicc): Likewise. (movsfcc): Likewise. (movdfcc): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-protos.h trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md
[Bug target/53440] [arm] generic thunk code fails for method which uses '...'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53440 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-22 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 --- Comment #11 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-05-22 14:16:34 UTC --- There are still a few vmov's between Vector registers but I suspect that is because of the vcombine at the end for which RichardE might have something in flight. This is probably not true and needs some more investigation.
[Bug target/52989] Installation error on OS X (arm-eabi) cross-compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52989 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-05-16 09:41:33 UTC --- (In reply to comment #1) --with-multilib-list=interwork Maybe that is broken. I don't think we support --with-multilib-list yet for arm - ramana
[Bug target/53376] New: Unrecognizable compare insn generated by movsicc in arm backend.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53376
Bug #: 53376
Summary: Unrecognizable compare insn generated by movsicc in
arm backend.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ram...@gcc.gnu.org
Target: arm-linux-gnueabi
Build: x86*
extern int x;
static long long p;
static long long *h1 ;
static long long *h2 ;
void foo (void)
{
int i ;
for( i = 0 ; i x ; i++ )
{
if( (p 3) 5000)
p += 5000;
*h2 = *h1 ;
h2++;
}
}
Fails with an ICE
(insn 1166 1165 1167 155 (set (reg:CC 24 cc)
(compare:CC (reg:SI 2148 [ D.6766 ])
(const_int 5000 [0x1388]))) iirflt01/bmark.c:501 -1
(nil))
internal compiler error: in extract_insn, at
recog.c:2131
Compares with 5000 really aren't allowed and we appear to happily generate this
in this particular case - The patch below completely untested fixes this by
forcing invalid operations of the comparison into a register like what happens
in other parts of the compiler that use arm_gen_compare_reg -
For all cases other than DImode arm_gen_compare_reg expects to get only valid
operands to the arms of the compare. There are a number of places where these
checks already happen before the call to arm_gen_compare_reg and therefore it
seems pointless to check twice.
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index b1ad3bf..04be822 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -8144,6 +8144,9 @@
if (code == UNEQ || code == LTGT)
FAIL;
+if (!arm_add_operand (XEXP (operands[1], 1), SImode))
+ XEXP (operands[1], 1) = force_reg (SImode, XEXP (operands[1], 1));
+
ccreg = arm_gen_compare_reg (code, XEXP (operands[1], 0),
XEXP (operands[1], 1), NULL_RTX);
operands[1] = gen_rtx_fmt_ee (code, VOIDmode, ccreg, const0_rtx);
regards,
Ramana
[Bug target/53376] Unrecognizable compare insn generated by movsicc in arm backend.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53376
--- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-05-16
23:23:43 UTC ---
(In reply to comment #2)
(In reply to comment #0)
extern int x;
static long long p;
static long long *h1 ;
static long long *h2 ;
void foo (void)
{
int i ;
for( i = 0 ; i x ; i++ )
{
if( (p 3) 5000)
p += 5000;
*h2 = *h1 ;
h2++;
}
}
Fails with an ICE
(insn 1166 1165 1167 155 (set (reg:CC 24 cc)
(compare:CC (reg:SI 2148 [ D.6766 ])
(const_int 5000 [0x1388]))) iirflt01/bmark.c:501 -1
(nil))
internal compiler error: in extract_insn, at
recog.c:2131
Compares with 5000 really aren't allowed and we appear to happily generate
this
in this particular case - The patch below completely untested fixes this by
forcing invalid operations of the comparison into a register like what
happens
in other parts of the compiler that use arm_gen_compare_reg -
For all cases other than DImode arm_gen_compare_reg expects to get only
valid
operands to the arms of the compare. There are a number of places where
these
checks already happen before the call to arm_gen_compare_reg and therefore
it
seems pointless to check twice.
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index b1ad3bf..04be822 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -8144,6 +8144,9 @@
if (code == UNEQ || code == LTGT)
FAIL;
+if (!arm_add_operand (XEXP (operands[1], 1), SImode))
+ XEXP (operands[1], 1) = force_reg (SImode, XEXP (operands[1], 1));
+
ccreg = arm_gen_compare_reg (code, XEXP (operands[1], 0),
XEXP (operands[1], 1), NULL_RTX);
operands[1] = gen_rtx_fmt_ee (code, VOIDmode, ccreg, const0_rtx);
regards,
Ramana
FTR this isn't safe. There's no requirement for the comparison to be SImode;
it could be an FP mode or some other precision.
Agreed (as I said it was completely untested and something off the cuff) -
Reading the code more I realized that I am probably better off doing the
validation inside arm_gen_compare_reg for various modes.
Ramana
[Bug rtl-optimization/52804] IRA/RELOAD allocate wrong register on ARM for cortex-m0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52804 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.1 --- Comment #7 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-05-15 08:43:27 UTC --- Fixed then .
[Bug target/53241] Bad pre increment insn for ARM vfp store instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53241
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||ramana at gcc dot gnu.org
Resolution||FIXED
Target Milestone|--- |4.8.0
--- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-05-14
11:40:08 UTC ---
Fixed on trunk by
http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00325.html
t0o:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
add r0, r0, #16
mov r3, #0
.L3:
fldmiad r1!, {d17}
fldmiad r2!, {d16}
faddd d16, d17, d16
add r3, r3, #1
cmp r3, #10
fstmiad r0!, {d16}
bne .L3
bx lr
Ramana
[Bug rtl-optimization/52804] IRA/RELOAD allocate wrong register on ARM for cortex-m0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52804 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-14 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-05-14 11:42:53 UTC --- Fixed on trunk so far. Any plans of backporting this to 4.7 branch ? ramana
[Bug rtl-optimization/53278] [4.8 regression] internal compiler error: in df_uses_record, at df-scan.c:3179 when compiling libgcc2.c __mulvdi3 on armv5tel-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53278
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
Component|bootstrap |rtl-optimization
--- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-05-08
14:03:37 UTC ---
Here's a reduced testcase from newlib where I hit the same issue.
struct _reent
{
int _errno;
};
typedef unsigned int wchar_t;
unsigned long long
_wcstoull_r(struct _reent *rptr , const wchar_t *nptr , wchar_t **endptr , int
base)
{
register const wchar_t *s = nptr;
register unsigned long long acc;
register int c;
register unsigned long long cutoff;
register int neg = 0, any, cutlim;
if(base 0
|| base == 1
|| base 36) {
return(0ULL);
}
if ((base == 0 || base == 16)
c == L'0' (*s == L'x' || *s == L'X')) {
c = s[1];
}
if (base == 0)
base = c == L'0' ? 8 : 10;
cutoff = (unsigned long long)(9223372036854775807LL * 2ULL + 1ULL) / (unsigned
long long)base;
for (acc = 0, any = 0;; c = *s++) {
if (iswdigit(c))
break;
if (any 0 || acc cutoff || (acc == cutoff c cutlim))
any = -1;
else {
acc += c;
}
}
if (any 0) {
rptr-_errno = 34;
} else if (neg)
acc = -acc;
}
[Bug rtl-optimization/53278] [4.8 regression] internal compiler error: in df_uses_record, at df-scan.c:3179 when compiling libgcc2.c __mulvdi3 on armv5tel-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53278 --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-05-08 14:56:18 UTC --- The patch below appears to trigger the issue but there's a fundamental question as to why lower-subreg generates concatns when the documentation suggests that concat and concatn should only be used in declarations but not in the insn stream. http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00423.html
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ramana at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Attachment #24234|0 |1 is obsolete|| --- Comment #10 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-05-02 06:51:12 UTC --- Created attachment 27282 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27282 Rebased patch. This patch originally by Richard Sandiford fixed PR target/48941 but the problem was that lower-subreg was being a bit too aggressive with lowering subreg moves in this case causing unnecessary spills to the stack. As shown in my mail in the thread on lower-subreg.c the code generated is far better now with this patch in play . I've rebased to trunk, double checked that the generated files from the ml description match up and added a simple test that makes sure that the original testcase from the PR doesn't emit a vector store instruction ! That should be enough to catch all the cases that we worry about. There are still a few vmov's between Vector registers but I suspect that is because of the vcombine at the end for which RichardE might have something in flight. For the record, this patch is not directly applicable to earlier release branches as it depends on the new behaviour of lower-subreg.c which is why this bug is only targeted at 4.8.0
[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980
--- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-03-30
07:58:49 UTC ---
Your testcase is broken - it doesn't honour reinterpret_casts properly . This
is a better testcase.
#include arm_neon.h
uint32x4_t sqrlen4D_16u8( const uint8x16_t A, const uint8x16_t B )
{
const uint8x16_t absAB = vabdq_u8( A, B );
const uint16x8_t square_l = vmull_u8( vget_low_u8( absAB ), vget_low_u8( absAB
) );
const uint16x8_t square_h = vmull_u8( vget_high_u8( absAB ), vget_high_u8(
absAB ) );
const uint32x4x2_t rgrgrgrg_babababa = vuzpq_u32( vreinterpretq_u32_u16
(square_l), vreinterpretq_u32_u16 (square_h) );
const uint16x8_t rgrgrgrg = vreinterpretq_u16_u32 (rgrgrgrg_babababa.val[0]);
const uint16x8_t babababa = vreinterpretq_u16_u32 (rgrgrgrg_babababa.val[1]);
const uint32x4_t rpg_rpg_rpg_rpg = vpaddlq_u16( rgrgrgrg );
const uint32x4_t dp = vpadalq_u16( rpg_rpg_rpg_rpg, babababa );
return ( dp );
}
[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980
--- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-03-30
08:17:21 UTC ---
Experimenting with :
Applying the patch of PR48941 and the patch for lower-subreg here
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01886.html
I now see : We still have too many moves for my liking but the gratuituous
spilling is now gone.
.cpu cortex-a9
.eabi_attribute 27, 3
.fpu neon
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 34, 1
.eabi_attribute 18, 4
.file t2.c
.text
.align 2
.global sqrlen4D_16u8
.type sqrlen4D_16u8, %function
sqrlen4D_16u8:
@ args = 16, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vmovd16, r0, r1 @ v16qi
vmovd17, r2, r3
vldmia sp, {d18-d19}
vabd.u8 q10, q8, q9
vmull.u8q11, d20, d20
vmull.u8q10, d21, d21
vmovq8, q11 @ v4si -- unnecessary ?
vmovq9, q10 @ v4si -- unnecessary ?
vuzp.32 q8, q9
vpaddl.u16 q10, q8
vmovq11, q10 @ v4si -- unnecessary
vpadal.u16 q11, q9
vmovr0, r1, d22 @ v4si
vmovr2, r3, d23
bx lr
.size sqrlen4D_16u8, .-sqrlen4D_16u8
.ident GCC: (GNU) 4.8.0 20120330 (experimental)
.section.note.GNU-stack,,%progbits
This probably makes it a dup of PR48941 but it's starting to look more
promising now.
Eric, could you try the 2 patches and see what you get - This isn't something
to be gratuitously backported as we still have to see the effects elsewhere but
it would be worth seeing if this helps on your intrinsics testcases.
Ramana
[Bug middle-end/52800] New: eglibc build broken with internal compiler error in cfgloop .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52800
Bug #: 52800
Summary: eglibc build broken with internal compiler error in
cfgloop .
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ram...@gcc.gnu.org
Host: x86_64-linux-gnu
Target: arm-linux-gnueabi
Build: x86_64-linux-gnu
eglibc builds broken with trunk on arm-linux-gnueabi with an internal compiler
error in cfgloop.c - it has happened in about the last 3 days or so since my
last successful build was on 27th March.
$
/work/cross-build/fsf/arm-none-linux-gnueabi/tools-lowersubregchanges-patched/bin/arm-none-linux-gnueabi-gcc
-c -O2 ./besttry.c -mfloat-abi=soft -march=armv5te
./besttry.c: In function ‘_IO_new_file_write’:
./besttry.c:36:1: internal compiler error: in get_loop_body, at cfgloop.c:831
__extension__ typedef int __ssize_t;
extern __thread int __libc_errno __attribute__ ((tls_model (initial-exec)));
struct _IO_FILE {
int _fileno;
int _flags2;
};
typedef struct _IO_FILE _IO_FILE;
_IO_new_file_write (f,
data,
n)
_IO_FILE *f;
{
__ssize_t to_do = n;
while (to_do 0)
{
__ssize_t count =
(__builtin_expect (f-_flags2 2, 0) ?
({ unsigned int _sys_result = ({ register int _a1 asm (r0), _nr asm (r7);
int _a3tmp = (int) ((to_do));
int _a2tmp = (int) ((data));
register int _a2 asm (a2) = _a2tmp;
register int _a3 asm (a3) = _a3tmp; _nr = ((0 + 4));
asm volatile (swi 0x0 @ syscall SYS_ify(write) : =r
(_a1) : r (_nr) , r (_a1), r (_a2), r (_a3) : memory); _a1;
});
if (__builtin_expect (((unsigned int) (_sys_result)= 0xf001u), 0))
{ (__libc_errno = ((-(_sys_result;
_sys_result = (unsigned int) -1; }
(int) _sys_result; })
: __write (f-_fileno, data, to_do));
if (count 0)
{
break;
}
to_do -= count;
}
}
[Bug middle-end/52800] eglibc build broken with internal compiler error in cfgloop .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52800 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-03-30 23:34:41 UTC --- Richi - probably yours - svn+ssh://gcc.gnu.org/svn/gcc/trunk@185913 broken svn+ssh://gcc.gnu.org/svn/gcc/trunk@185910 good regards, Ramana
[Bug target/52412] another unnecessary register move on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52412 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-29 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.7.0 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-02-29 11:41:00 UTC --- Confirmed - looks like 4.6 gets this right. ramana
[Bug rtl-optimization/52396] Gcc failed to hoist loop invariant GOT load out of loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52396 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-29 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-02-29 11:43:31 UTC --- We manage to hoist this at O2 but not at Os in 4.7 while 4.6 appears to work fine.
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org, ||rearnsha at gcc dot gnu.org --- Comment #9 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-02-28 14:41:56 UTC --- I ran into this failure today when upgrading my copy of (e)glibc in my cross-environment. What's the best way of progressing this further ? Doesn't this mean that trunk is broken for building with anything later than glibc-2.15 ? Ramana
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785
--- Comment #14 from Ramana Radhakrishnan ramana at gcc dot gnu.org
2012-02-28 16:09:52 UTC ---
I can confirm that a build for arm-linux-gnueabi completes and do some
cross-testing on qemu if that's deemed to be enough.
Any other ideas for testing.
Ramana
Here's a suggestion for the comments in this patch.
diff --git a/libstdc++-v3/include/c_global/cstdio
b/libstdc++-v3/include/c_global/cstdio
index 049704d..76755ac 100644
--- a/libstdc++-v3/include/c_global/cstdio
+++ b/libstdc++-v3/include/c_global/cstdio
@@ -89,6 +89,17 @@
#undef vprintf
#undef vsprintf
+/* glibc 2.15 and later do not declare gets anymore for
+ ISO C11 mode and if __GNU_SOURCE is defined. See
+ http://gcc.gnu.org/PR51785 for more on this topic. If
+ this is being changed an equivalent change has to be made
+ in include/c_std/c_stdio. */
+#if __GLIBC_PREREQ (2,15)
+extern C {
+ extern char *gets (char *__s) __attribute__((deprecated));
+}
+#endif
+
namespace std
{
using ::FILE;
diff --git a/libstdc++-v3/include/c_std/cstdio
b/libstdc++-v3/include/c_std/cstdio
index 510f599..29142bb 100644
--- a/libstdc++-v3/include/c_std/cstdio
+++ b/libstdc++-v3/include/c_std/cstdio
@@ -88,6 +88,17 @@
#undef vprintf
#undef vsprintf
+/* glibc 2.15 and later do not declare gets anymore for
+ ISO C11 mode and if __GNU_SOURCE is defined. See
+ http://gcc.gnu.org/PR51785 for more on this topic. If
+ this hunk below is being changed please also investigate
+ the change for include/c_global/cstdio. */
+#if __GLIBC_PREREQ (2,15)
+extern C {
+ extern char *gets (char *__s) __attribute__((deprecated));
+}
+#endif
+
namespace std
{
using ::FILE;
[Bug target/46092] Improve constant handling of thumb2 instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46092 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||ramana at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 Severity|normal |enhancement --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-02-24 12:24:04 UTC --- Trunk generates this today. Thus fixed. Ramana tv: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. movwr3, #65520 cmpr0, r3 itthi subhir0, r0, #65280 subhir0, r0, #241 bxlr .sizetv, .-tv .identGCC: (GNU) 4.7.0 20120116 (experimental)
[Bug target/52258] __builtin_isgreaterequal is sometimes signaling on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52258
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-02-23
CC||ramana at gcc dot gnu.org
Known to work||4.7.0
Ever Confirmed|0 |1
Known to fail||4.6.3
--- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-02-23
02:22:28 UTC ---
Fails for anything earlier than trunk strangely enough while 4.6 goes wrong.
Trunk at O2 appears to generate :
main:
0:ed9f 7b13 vldrd7, [pc, #76]; 50 main+0x50
4:ee87 7b07 vdiv.f64d7, d7, d7
8:b510 push{r4, lr}
a:201f movsr0, #31
c:b082 subsp, #8
e:ed8d 7b00 vstrd7, [sp]
12:f7ff fffe bl0 feclearexcept
16:ed9d 7b00 vldrd7, [sp]
1a:eeb5 7b40 vcmp.f64d7, #0.0
1e:eef1 fa10 vmrsAPSR_nzcv, fpscr
22:da10 bge.n46 main+0x46
24:e9dd 0100 ldrdr0, r1, [sp]
28:f7ff fffe bl0 __isnan
2c:1c04 addsr4, r0, #0
2e:bf18 itne
30:2401 movner4, #1
32:2001 movsr0, #1
34:f7ff fffe bl0 fetestexcept
38:b110 cbzr0, 40 main+0x40
3a:4807 ldrr0, [pc, #28]; (58 main+0x58)
3c:f7ff fffe bl0 puts
40:4620 movr0, r4
42:b002 addsp, #8
44:bd10 pop{r4, pc}
46:2401 movsr4, #1
48:e7f3 b.n32 main+0x32
4a:bf00 nop
4c:f3af 8000 nop.w
...
[Bug target/52187] armeb-unknown-eabi not recognized as big-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52187 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-23 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-02-23 02:24:10 UTC --- I suppose confirmed :)
[Bug target/51835] ARM EABI violation when passing arguments to helper floating functions like __aeabi_d2iz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51835 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.6.3 |4.5.4 Known to fail||4.5.3 --- Comment #9 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-02-23 02:33:30 UTC --- Fixed I think now on all release branches where affected and trunk.
[Bug target/52060] Incorrect mask/and (ARM bic) instruction generated for shifted expression parameter, triggered by -O2 -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52060 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org Known to work||4.5.3 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-02-03 18:49:24 UTC --- According to comment #2 appears to work with 4.5.3 which means we need to look at this carefully.
[Bug target/50313] ARM: PIC code references a non-existant label
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50313 --- Comment #6 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-30 14:35:10 UTC --- Author: ramana Date: Mon Jan 30 14:35:05 2012 New Revision: 183727 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183727 Log: Fix PR target/50313 2012-01-30 Ramana Radhakrishnan ramana.radhakrish...@linaro.org Backport from mainline. 2012-01-20 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR target/50313 * config/arm/arm.c (arm_load_pic_register): Use gen_pic_load_addr_unified. Delete calls to gen_pic_load_addr_32bit , gen_pic_add_dot_plus_eight and gen_pic_add_dot_plus_four. (arm_pic_static_addr): Likewise. (arm_rtx_costs_1): Adjust cost for UNSPEC_PIC_UNIFIED. (arm_note_pic_base): Handle UNSPEC_PIC_UNIFIED. * config/arm/arm.md (UNSPEC_PIC_UNIFIED): Define. (pic_load_addr_unified): New. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/arm/arm.c branches/gcc-4_6-branch/gcc/config/arm/arm.md
[Bug target/50313] ARM: PIC code references a non-existant label
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50313 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.3 --- Comment #7 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-30 14:37:44 UTC --- Backported now to GCC 4.6 branch. Ramana
[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target|arm-linux-androideabi |arm-linux-androideabi, ||arm*-*-*eabi --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-27 15:25:29 UTC --- (In reply to comment #1) It looks like the neon builtins are not properly marked as pure/const, that certainly is a road-block for optimizations. The heavy use of UNSPECs is another. yes, one other problem is that a lot of the neon intrinsics don't expand into an equivalent RTL - you still need the unspecs for the polynomial types but in general a large number of the intrinsics that are in the form of unspecs could use the underlying vec_ expanders that are also present. Confirmed.
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 --- Comment #9 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-27 16:20:07 UTC --- (In reply to comment #8) Any chance of seeing the work on this restart ? I found this bug while looking for something that would help (I raised bug 51980 for the same kind of issue, still seen on trunk), but the patch attached to this bug does not solve the issue for code that is rich with zip/uzp/trn intrinsics. I took a look at this for sometime when I was reviewing the patch submitted on trunk. The problem in this case appears to go away with -fno-split-wide-types but that in general is not a good idea. IIRC when RichardS and I talked about it we did talk about maybe getting lower-subreg to pay some attention to it. Neon intrinsics have been improving ( I'd like to think) over time but they are still not perfect unfortunately. I don't have time to look at this in the near term myself. This is a major limitation of arm-gcc with respect to performance-critical Neon code in my opinion. As they say, patches are welcome :) Ramana
[Bug bootstrap/51985] [4.7 Regression] Bootstrap failure due to revision 183457
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51985 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #9 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-26 10:42:30 UTC --- (In reply to comment #5) Created attachment 26460 [details] gcc47-pr51985.patch Untested fix. The problem was I think that $(inst_sources) was included there twice, once in libc__98convenience_la_SOURCES = $(sources) $(inst_sources) (and for libc__98_la_SOURCES too), and once as part of $(host_sources_extra), which is included in $(sources). This occurred even on x86_64-linux, but wasn't fatal there, libstdc++.a was just much larger than it would have to be (contained additional lt*-*.o objects) and libstdc++.so.6, while it had the same list of exported symbols, was much larger too. bootstrap on arm-linux-gnueabi succeeded. Tests are still running. Ramana
[Bug target/48308] [4.6/4.7 Regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 --- Comment #20 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-25 08:52:43 UTC --- Author: ramana Date: Wed Jan 25 08:52:39 2012 New Revision: 183512 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183512 Log: 2012-01-25 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR rtl-optimization/48308 * combine.c (enum undo_kind): Add UNDO_LINKS. (struct undo): Add member l to other_contents and where. (do_SUBST_LINK): New. (SUBST_LINK): New. (try_combine): Handle LOG_LINKS for the dummy i1 case. (undo_all): Handle UNDO_LINKS. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c
[Bug lto/51642] Weak variable reference triggers ICE with -flto option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51642 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-23 11:46:42 UTC --- Richi : Is this a case of WONTFIX for 4.6 or is there a feasible backport ? Ramana
[Bug middle-end/45416] [4.5/4.6 Regression] Code size regression from 4.4 for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45416 --- Comment #16 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-23 17:59:56 UTC --- Author: ramana Date: Mon Jan 23 17:59:51 2012 New Revision: 183446 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183446 Log: 2012-01-23 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR middle-end/45416 * gcc.dg/pr45416.c: Skip if Thumb1. Handle ubfx. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr45416.c
[Bug target/51882] ICE: in extract_insn, at recog.c:2109 (unrecognizable insn) when building Mesa on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51882 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-21 12:29:02 UTC --- Created attachment 26403 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26403 reduced testcase Reduced testcase. Configured with : --target=arm-linux-gnueabi --with-cpu=cortex-a9 --with-fpu=neon --with-float=softfp - Command line options. : ./xgcc -B`pwd` -S -O2 -fPIC -mapcs -O2 -Wall-ffast-math -mtune=cortex-a9 besttry.c Ramana
[Bug target/51882] ICE: in extract_insn, at recog.c:2109 (unrecognizable insn) when building Mesa on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51882 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-21 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1
[Bug target/50313] ARM: PIC code references a non-existant label
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50313 --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-20 09:22:21 UTC --- Author: ramana Date: Fri Jan 20 09:22:14 2012 New Revision: 183328 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183328 Log: Fix PR target/50313 Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md
[Bug tree-optimization/51914] New: [4.7] All vect-intfloat-conversion tests fail for arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51914 Bug #: 51914 Summary: [4.7] All vect-intfloat-conversion tests fail for arm-linux-gnueabi Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ram...@gcc.gnu.org CC: i...@gcc.gnu.org Target: arm-* Build: x86* All the vect-intfloat-conversion tests fail for arm-linux-gnueabi with an ICE in vectorizable_store . FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c (internal compiler error) FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c (test for excess errors) FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c (internal compiler error) FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c (test for excess errors) FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c -flto (internal compiler error) FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c -flto (test for excess errors) FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c -flto scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c -flto (internal compiler error) FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c -flto (test for excess errors) FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c -flto scan-tree-dump-times vect vectorized 1 loops 1 #1 0x006320bc in vectorizable_store (stmt=0x405cd8a0, gsi=0x4, vec_stmt=0x2, slp_node=0x2) at ../../gcc-git-trunk/gcc/tree-vect-stmts.c:3892 3892 gcc_assert (useless_type_conversion_p (vectype, (gdb) bt #0 fancy_abort (file=0xa38948 ../../gcc-git-trunk/gcc/tree-vect-stmts.c, line=3893, function=0xa3870c vectorizable_store) at ../../gcc-git-trunk/gcc/diagnostic.c:898 #1 0x006320bc in vectorizable_store (stmt=0x405cd8a0, gsi=0x4, vec_stmt=0x2, slp_node=0x2) at ../../gcc-git-trunk/gcc/tree-vect-stmts.c:3892 #2 0x0063d6d0 in vect_transform_stmt (stmt=0x407f6900, gsi=0x4080a000, strided_store=0xbefff43f, slp_node=0x0, slp_node_instance=0x0) at ../../gcc-git-trunk/gcc/tree-vect-stmts.c:5474 #3 0x0064cd7c in vect_transform_loop (loop_vinfo=0x0) at ../../gcc-git-trunk/gcc/tree-vect-loop.c:5415 #4 0x0065b0ec in vectorize_loops () at ../../gcc-git-trunk/gcc/tree-vectorizer.c:214 #5 0x00400040 in execute_one_pass (pass=0xbc3400) at ../../gcc-git-trunk/gcc/passes.c:2081 #6 0x00400404 in execute_pass_list (pass=0xbc3400) at ../../gcc-git-trunk/gcc/passes.c:2136 #7 0x0040041c in execute_pass_list (pass=0xbc3504) at ../../gcc-git-trunk/gcc/passes.c:2137 #8 0x0040041c in execute_pass_list (pass=0xbc2db4) at ../../gcc-git-trunk/gcc/passes.c:2137 #9 0x00517838 in tree_rest_of_compilation (fndecl=0x407e3c80) at ../../gcc-git-trunk/gcc/tree-optimize.c:421 #10 0x001e9b78 in cgraph_expand_function (node=0x405ce540) at ../../gcc-git-trunk/gcc/cgraphunit.c:1818 #11 0x001ebb4c in cgraph_expand_all_functions () at ../../gcc-git-trunk/gcc/cgraphunit.c:1885 #12 cgraph_optimize () at ../../gcc-git-trunk/gcc/cgraphunit.c:2199 #13 0x001ec214 in cgraph_finalize_compilation_unit () at ../../gcc-git-trunk/gcc/cgraphunit.c:1327 #14 0x000daf08 in c_write_global_declarations () at ../../gcc-git-trunk/gcc/c-decl.c:10031 #15 0x004a8a58 in compile_file () at ../../gcc-git-trunk/gcc/toplev.c:573 #16 do_compile () at ../../gcc-git-trunk/gcc/toplev.c:1938 #17 toplev_main (argc=0, argv=0xd38a70) at ../../gcc-git-trunk/gcc/toplev.c:2014 #18 0x40429c3a in __libc_start_main () from /lib/arm-linux-gnueabi/libc.so.6 #19 0x000be8a2 in _start ()
[Bug tree-optimization/51914] [4.7] vect-intfloat-conversion4a/b tests fail for arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51914 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-20 09:50:52 UTC --- arch specific command line options used: -mcpu=cortex-a9 -mfpu=neon -mfloat-abi=softfp
[Bug target/51819] [4.7 Regression] Neon wrong code generation, Error: unsupported alignment for instruction -- `vst1.32 {d2[0]},[r0:64]'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51819 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/51819] [4.7 Regression] Neon wrong code generation, Error: unsupported alignment for instruction -- `vst1.32 {d2[0]},[r0:64]'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51819 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-20 13:24:53 UTC --- Author: ramana Date: Fri Jan 20 13:24:47 2012 New Revision: 183338 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183338 Log: Fix PR target/51819 Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug target/51819] [4.7 Regression] Neon wrong code generation, Error: unsupported alignment for instruction -- `vst1.32 {d2[0]},[r0:64]'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51819 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-20 13:26:14 UTC --- Fixed. .
[Bug target/51876] [4.7 regression] Recent extra neon related testsuite regressions on arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51876 --- Comment #6 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-19 15:40:58 UTC --- (In reply to comment #5) I did, but I'm waiting for testing results from Ramana. Testresults look good. Yeah , ok. Ramana
[Bug target/51835] ARM EABI violation when passing arguments to helper floating functions like __aeabi_d2iz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51835 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org Target Milestone|--- |4.6.3 Known to fail||4.6.0, 4.6.1, 4.6.2, 4.7.0 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-19 22:40:51 UTC --- This is only applicable to the 4.6 branch and trunk since support for the Cortex M4 wasn't added till 4.6. cheers Ramana
[Bug target/51876] [4.7 regression] Recent extra neon related testsuite regressions on arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51876 --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-17 13:48:12 UTC --- (In reply to comment #2) Created attachment 26349 [details] gcc47-pr51876.patch Untested fix (well, tested that the ICEs are gone on all these tests with a cross). vswp just seems to swap two vector registers, so it doesn't matter which one is the first and which is the second, and the pattern only has two operands, not 3. Ramana, could you please bootstrap/regtest it on some real hw? Doesn't matter which order you do the vswp it's just a swap of 2 vector registers. Looks obvious to me. Ramana
[Bug target/51178] FAIL: g++.dg/lookup/builtin5.C scan-assembler _ZSt5atanhd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51178 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Target|arm-none-eabi |arm-none-eabi, ||arm-linux-gnueabi Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-17 Ever Confirmed|0 |1
[Bug target/51876] New: [4.7 regression] Recent extra neon related testsuite regressions on arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51876 Bug #: 51876 Summary: [4.7 regression] Recent extra neon related testsuite regressions on arm-linux-gnueabi Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ram...@gcc.gnu.org A noticed a few of the neon tests are failing for arm-linux-gnueabi started failing recently. Skimming through some results on gcc-testresults I see that http://gcc.gnu.org/ml/gcc-testresults/2012-01/msg01284.html have these failures while this set of results http://gcc.gnu.org/ml/gcc-testresults/2012-01/msg00370.html that these tests were passing. Therefore this is a recent regression. FAIL: gcc.target/arm/neon/vcombinef32.c (internal compiler error) FAIL: gcc.target/arm/neon/vcombinef32.c (test for excess errors) FAIL: gcc.target/arm/neon/vcombinep16.c (internal compiler error) FAIL: gcc.target/arm/neon/vcombinep16.c (test for excess errors) FAIL: gcc.target/arm/neon/vcombinep8.c (internal compiler error) FAIL: gcc.target/arm/neon/vcombinep8.c (test for excess errors) FAIL: gcc.target/arm/neon/vcombines16.c (internal compiler error) FAIL: gcc.target/arm/neon/vcombines16.c (test for excess errors) FAIL: gcc.target/arm/neon/vcombines32.c (internal compiler error) FAIL: gcc.target/arm/neon/vcombines32.c (test for excess errors) FAIL: gcc.target/arm/neon/vcombines64.c (internal compiler error) FAIL: gcc.target/arm/neon/vcombines64.c (test for excess errors) FAIL: gcc.target/arm/neon/vcombines8.c (internal compiler error) FAIL: gcc.target/arm/neon/vcombines8.c (test for excess errors) FAIL: gcc.target/arm/neon/vcombineu16.c (internal compiler error) FAIL: gcc.target/arm/neon/vcombineu16.c (test for excess errors) FAIL: gcc.target/arm/neon/vcombineu32.c (internal compiler error) FAIL: gcc.target/arm/neon/vcombineu32.c (test for excess errors) FAIL: gcc.target/arm/neon/vcombineu64.c (internal compiler error) FAIL: gcc.target/arm/neon/vcombineu64.c (test for excess errors) FAIL: gcc.target/arm/neon/vcombineu8.c (internal compiler error) FAIL: gcc.target/arm/neon/vcombineu8.c (test for excess errors)
[Bug target/51876] [4.7 regression] Recent extra neon related testsuite regressions on arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51876 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-17 CC||rth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-17 00:06:11 UTC --- A git bisect shows this to be in the range of 183050 - 183052 , Richard : can you take a look ? Ramana
[Bug target/48308] [4.6/4.7 Regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 --- Comment #19 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-13 09:07:48 UTC --- (In reply to comment #14) Note, can't be reproduced on the trunk, the strcmp isn't DCEd there, but guess the problem is just latent there. Latent still in trunk with the testcase - you can try it with -fdbg-cnt=cprop:0 with the first reduced testcase and you should be able to see the same behaviour with trunk. The other testcase which is in PR50313 also fails with the same error on trunk (with -Os -fPIC -mcpu=arm9tdmi -marm ) The problem with reduced^2 testcase or reduced testcase appears to get fixed if we add LOG_LINKS to keep track of the dummy i1 in the form of a patch of the following nature. combine.c: try_combine attempts to create a dummy i1 instruction in case i1 is NULL and i2 looks like (parallel [(set (reg:CC X) (compare:CC OP (const_int 0))) (set Y OP)]) which is exactly how the intermediate instruction looks (parallel [ (set (reg:CC 24 cc) (compare:CC (reg:SI 0 r0) (const_int 0 [0]))) (set (reg:SI 168) (reg:SI 0 r0)) ]) i1 now becomes (set (reg:SI 168) (reg:SI 0 r0)) and i2 becomes (set (reg:CC 24 cc) (compare:CC (reg:SI 0 r168) (const_int 0 [0]))) but there are no LOG_LINKS to indicate that even when we've created the dummy i1 - i2 actually feeds into i1. After changing try_combine[1] to create a LOG_LINKS to indicate this relationship between i1 and i2 we no longer eliminate the wrong strcmp call and therefore this should IMHO be the handled in combine rather than faffing around in the backend. However this doesn't fix the testcase from PR50313 (gmime.i) which prima-facie appeared to exhibit the same behaviour as this particular testcase and that needs reopening and further investigation to be sure that the IR is valid when cfgcleanup decides to eliminate the PIC insn in. cheers Ramana diff --git a/gcc/combine.c b/gcc/combine.c index 4178870..f6b8769 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -2865,6 +2865,8 @@ try_combine (rtx i3, rtx i2, rtx i1, rtx i0, int *new_direct_jump_p, SUBST (PATTERN (i2), XVECEXP (PATTERN (i2), 0, 0)); SUBST (XEXP (SET_SRC (PATTERN (i2)), 0), SET_DEST (PATTERN (i1))); + LOG_LINKS (i2) = alloc_insn_link (i1, LOG_LINKS (i2)); + } } #endif
[Bug target/50313] ARM: PIC code references a non-existant label
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50313 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2012-01-13 Resolution|DUPLICATE | Ever Confirmed|0 |1 --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-13 12:03:14 UTC --- reopening this as the proposed fix for 48308 doesn't appear to fix the issue and the same problem in combine doesn't seem to happen in this case. Ramana
[Bug target/50313] ARM: PIC code references a non-existant label
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50313 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-13 12:06:33 UTC --- Created attachment 26314 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26314 smaller testcase Better reduced testcase. Fails on trunk with -Os -fPIC -mcpu=arm9tdmi or -Os -fPIC -mthumb -mcpu=cortex-a9
[Bug target/51709] armv7 target is not using unaligned access to packed fields sometimes (halfwords, loads?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51709 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-13 CC||ramana at gcc dot gnu.org Version|4.6.1 |4.7.0 Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-13 14:07:53 UTC --- Confirmed with GCC 4.7.0 on trunk . Reporting this for FSF GCC 4.6 is not correct as unaligned access will only be in 4.7.0 when it is released. If you have an issue with the CS tools report at the appropriate place and not here. cheers Ramana
[Bug target/51797] Arm backend missed the mls related optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51797 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||missed-optimization Last reconfirmed||2012-01-11 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 Severity|normal |enhancement
[Bug middle-end/51442] volatile bitfields broken on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51442 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.6.3 --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-11 12:12:07 UTC --- This should now be fixed by the commit as indicated below - Brendan - can you confirm this is the case ? Author: dj Date: Thu Dec 22 19:36:46 2011 New Revision: 182635 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182635 Log: 2011-12-22 Doug Kwan dougk...@google.com Backport from mainline 2011-03-23 Julian Brown jul...@codesourcery.com * expr.c (expand_expr_real_1): Only use BLKmode for volatile accesses which are not naturally aligned. 2011-11-20 Joey Ye joey...@arm.com * expr.c (expand_expr_real_1): Correctly handle strict volatile bitfield loads smaller than mode size. 2011-12-22 Doug Kwan dougk...@google.com Backport from mainline 2011-11-20 Joey Ye joey...@arm.com * gcc.dg/volatile-bitfields-1.c: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/volatile-bitfields-1.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/expr.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug target/51381] Internal compiler error for arm target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51381 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #12 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-11 12:13:50 UTC --- As per comment #11
[Bug tree-optimization/51799] [4.7 Regression] Compiler ICE in vect_is_simple_use_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51799 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-11 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1
[Bug target/51659] [4.7 regression] ICE in function output_move_double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51659 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.6.0 Keywords||ice-on-valid-code Last reconfirmed||2012-01-11 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 Summary|ICE in function |[4.7 regression] ICE in |output_move_double |function output_move_double Known to fail||4.7.0
[Bug target/51819] [4.7 Regression] Neon wrong code generation, Error: unsupported alignment for instruction -- `vst1.32 {d2[0]},[r0:64]'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51819 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-11 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-11 14:51:37 UTC --- Completely untested but I think this is the correct fix for this problem. diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index 4c310d4..31f03cc 100644 --- a/gcc/config/arm/arm.c +++ b/gcc/config/arm/arm.c @@ -17720,7 +17720,7 @@ arm_print_operand (FILE *stream, rtx x, int code) align_bits = 256; else if ((memsize == 8 || memsize == 16) (align % 16) == 0) align_bits = 128; - else if ((align % 8) == 0) + else if ((memsize = 8) (align % 8) == 0) align_bits = 64; else align_bits = 0;
[Bug target/48308] [4.6/4.7 Regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308
--- Comment #18 from Ramana Radhakrishnan ramana at gcc dot gnu.org
2012-01-11 18:15:05 UTC ---
(In reply to comment #14)
Note, can't be reproduced on the trunk, the strcmp isn't DCEd there, but guess
the problem is just latent there.
It looks like a target bug to me. Before RTL loop opts we have:
(insn 91 90 92 13 (set (reg:SI 167)
(unspec:SI [
(const:SI (unspec:SI [
(symbol_ref/v/f:SI (*.LC4) [flags 0x82]
var_decl 0x7f5ebb0a5500 *.LC4)
(const:SI (plus:SI (unspec:SI [
(const_int 4 [0x4])
] 21)
(const_int 8 [0x8])))
] 27))
] 3)) pr48308.i:228 170 {pic_load_addr_32bit}
(nil))
(insn 92 91 94 13 (set (reg:SI 167)
(unspec:SI [
(reg:SI 167)
(const_int 8 [0x8])
(const_int 4 [0x4])
] 4)) pr48308.i:228 173 {pic_add_dot_plus_eight}
(expr_list:REG_EQUAL (symbol_ref/v/f:SI (*.LC4) [flags 0x82] var_decl
0x7f5ebb0a5500 *.LC4)
(nil)))
and the pseudo 167 is then used to load one of the strcmp parameters.
Then (probably loop invariant motion) moves insn 91 before the loop, as it
looks to be loop invariant, but insn 92 is kept in the loop.
Next during RA, the register pressure is high and thus pseudo 167 is spilled,
so
before the loop there is a store. Then during the *.csa pass DCE is performed
and the strcmp is removed, which means insn 92 is removed as well, but the
store before the loop of course is kept. And there is no further DSE pass
that
would optimize that (now dead) store away.
So, IMHO arm_reorg needs to handle this case, find out what minipool entries
don't have the corresponding UNSPEC_PIC_BASE insn and handle them somehow
(either by emitting there a dummy 0 or similar, or trying to replace the insn
with UNSPEC_PIC_SYM with something else, ...).
That said, perhaps it would be nice to help the loop optimizers somehow figure
out that even the UNSPEC_PIC_BASE is loop invariant (wrap it into CONST?).
Found it I think- the problem is way before any of this . A transformation
in combine looks suspicious.
The first clue to all this was that the compiler was removing a call of strcmp
with .LC4 which is the constant string -noout . If you look at the testcase,
there is a use of noout afterwards which is to call :
if (!noout)
PEM_write_bio_Parameters(out,pkey);
However the condition
else if (strcmp(*args,-text) == 0)
text=1;
has a value of text set to 1.
However given text is not used later that is the only call
to strcmp that can be removed safely. However the strcmp of -text is retained
in the final code generated but the call to strcmp of -noout is the one
that's getting eliminated.
Here's the suspicious transformation after combine:
(insn 97 96 188 13 (set (reg:SI 168)
(reg:SI 0 r0)) ./t.i:41 624 {*arm_movsi_vfp}
(expr_list:REG_DEAD (reg:SI 0 r0)
(nil)))
(insn 188 97 189 13 (set (reg:CC 24 cc)
(compare:CC (reg:SI 168)
(const_int 0 [0]))) ./t.i:41 198 {*arm_cmpsi_insn}
(nil))
(insn 189 188 191 13 (set (reg/v:SI 136 [ badarg ])
(if_then_else:SI (eq (reg:CC 24 cc)
(const_int 0 [0]))
(reg:SI 168)
(const_int 0 [0]))) ./t.i:41 220 {*movsicc_insn}
(expr_list:REG_DEAD (reg:SI 168)
(nil)))
(insn 191 189 153 13 (set (reg/v:SI 135 [ noout ])
(if_then_else:SI (ne (reg:CC 24 cc)
(const_int 0 [0]))
(reg/v:SI 135 [ noout ])
(const_int 1 [0x1]))) ./t.i:41 220 {*movsicc_insn}
(expr_list:REG_DEAD (reg:CC 24 cc)
(nil)))
is transformed to :
(note 97 96 188 13 NOTE_INSN_DELETED)
(note 188 97 189 13 NOTE_INSN_DELETED)
(insn 189 188 191 13 (set (reg/v:SI 136 [ badarg ])
(const_int 0 [0])) ./t.i:41 624 {*arm_movsi_vfp}
(nil))
(insn 191 189 153 13 (parallel [
(set (reg/v:SI 135 [ noout ])
(if_then_else:SI (ne (reg:SI 168)
(const_int 0 [0]))
(reg/v:SI 135 [ noout ])
(const_int 1 [0x1])))
(clobber (reg:CC 24 cc))
]) ./t.i:41 273 {movcond}
(expr_list:REG_UNUSED (reg:CC 24 cc)
(expr_list:REG_DEAD (reg:SI 168)
(nil
Look at the use of reg:SI 168 in insn 191 rather than reg:SI r0 . That's where
it all goes pear shaped as we've now used reg:SI 168 which we've not defined
before. The other bits of info from .combine is as below.
Trying 97 - 188:
Successfully matched this instruction:
(parallel [
(set (reg:CC 24 cc)
(compare:CC (reg:SI 0 r0)
(const_int 0 [0])))
(set (reg:SI 168)
(reg:SI 0 r0
[Bug rtl-optimization/38644] [4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644 --- Comment #62 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-09 16:55:24 UTC --- Author: ramana Date: Mon Jan 9 16:55:16 2012 New Revision: 183019 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183019 Log: 2012-01-09 Ramana Radhakrishnan ramana.radhakrish...@linaro.org Backport from mainline 2011-11-04 Jiangning Liu jiangning@arm.com PR rtl-optimization/38644 * config/arm/arm.c (thumb1_expand_epilogue): Add memory barrier for epilogue having stack adjustment. 2012-01-09 Ramana Radhakrishnan ramana.radhakrish...@linaro.org Backport from mainline: 2011-11-04 Jiangning Liu jiangning@arm.com PR rtl-optimization/38644 * gcc.target/arm/stack-red-zone.c: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.target/arm/stack-red-zone.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/arm/arm.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug target/51509] Inefficient neon intrinsic code sequence
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51509 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Target|arm-linux-androideabi |arm-linux-androideabi, ||arm-linux-gnueabi Status|UNCONFIRMED |NEW Keywords||missed-optimization Last reconfirmed||2011-12-12 CC||ramana at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Blocks||47562 Ever Confirmed|0 |1
[Bug target/51381] Internal compiler error for arm target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51381
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Comment #11 from Ramana Radhakrishnan ramana at gcc dot gnu.org
2011-12-05 17:23:36 UTC ---
I don't think this is ICE on valid code. The compiler at the minute doesn't
generate unified syntax for VFP instructions - therefore expecting the
instructions of that form to work correctly is wrong.
I think the correct way of writing this is
void round_int(void)
{
__asm__ __volatile__(fconstd d1,%G0 : : Dv(0.5f) : d1);
}
And then it would work.
We really do need to transition to unified syntax for VFP instructions.
cheers
Ramana
[Bug c++/45012] Invalid ambiguity on partial class specialization matching
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45012 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #6 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-11-17 16:03:34 UTC --- It was fixed actually by this commit . Author: jason Date: Tue Sep 27 02:13:00 2011 New Revision: 179230 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179230 Log: PR c++/45102 * pt.c (tsubst_copy_and_build) [CONST_DECL]: Don't pull out constant value if we're still in a template. Added: trunk/gcc/testsuite/g++.dg/template/partial13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug target/43999] Gcc (lib1funcs.asm) doesn't build on ARM/Thumb2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43999 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||ramana at gcc dot gnu.org Known to work||4.6.0, 4.7.0 Known to fail||4.5.0 --- Comment #10 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-11-16 13:41:54 UTC --- (In reply to comment #8) Correct patch (http://patchwork.ozlabs.org/patch/72260/) was applied to mainline. Apply to 4.5 branch? Yes I don't see why this should not be backported into the 4.5 branch. It should be fixed 4.6 onwards. Ramana
[Bug target/45102] mm/page-writeback.c:820: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45102 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #7 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-11-16 15:17:21 UTC --- Appears to have been fixed on trunk but backports are probably needed.(In reply to comment #6) Author: jason Date: Tue Sep 27 02:13:00 2011 New Revision: 179230 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179230 Log: PR c++/45102 * pt.c (tsubst_copy_and_build) [CONST_DECL]: Don't pull out constant value if we're still in a template. Added: trunk/gcc/testsuite/g++.dg/template/partial13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog Jason, Was this a fix for PR45102 or PR45012 ? cheers Ramana
[Bug bootstrap/51068] [4.7 Regression] ARM bootstrap failure due to ICE in rtl_verify_flow_info_1 at cfgrtl.c:2001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51068 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-11-14 14:46:24 UTC --- Looks like a dup of PR51051 . Ramana
[Bug rtl-optimization/51051] [4.7 Regression]: build fails on cris-elf building libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51051 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #6 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-11-14 14:49:36 UTC --- *** Bug 51068 has been marked as a duplicate of this bug. ***
[Bug bootstrap/51068] [4.7 Regression] ARM bootstrap failure due to ICE in rtl_verify_flow_info_1 at cfgrtl.c:2001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51068 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-11-14 14:49:36 UTC --- A dup of PR51051 indeed - the ICE looks the same and comment #c3 in PR51051 suggests that it fixes the ICE for arm-linux-gnueabi as well. Ramana *** This bug has been marked as a duplicate of bug 51051 ***
[Bug target/51122] ICE in change_address_1, at emit-rtl.c:2001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51122 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-11-14 17:57:55 UTC --- Confirmed - Not sure if this is a dup or not of PR48256 but it smells similar. Ramana
[Bug target/51122] ICE in change_address_1, at emit-rtl.c:2001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51122 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-14 Ever Confirmed|0 |1
[Bug target/50968] ICE on armhf building gcc-snapshot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50968 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-11-03 19:11:53 UTC --- For the record and future reference, unwind-dw2.c should never be compiled in this configuration. The arm*eabi port uses the ARM format exception tables for exception handling rather than the generic DWARF exception handling tables. Ramana
[Bug target/48308] [4.6/4.7 Regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 --- Comment #13 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-11-02 11:40:44 UTC --- (In reply to comment #12) Please tell me this bug is fixed in gcc 4.6.2 release? If this is fixed in gcc4.6.2 release can I use the fix patch into gcc 4.6-linaro? Thanks Regards, Madhu This has not been fixed yet. That's evident from the status of the bug. Ramana
[Bug bootstrap/50878] [4.7 Regression] ARM bootstrap failure on insn-preds.c with error: dominator of 12 should be 6, not 5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50878 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-27 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-10-27 16:34:14 UTC --- Confirmed .
[Bug bootstrap/50878] [4.7 Regression] ARM bootstrap failure on insn-preds.c with error: dominator of 12 should be 6, not 5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50878 --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-10-27 16:38:53 UTC --- Created attachment 25635 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25635 testcase bzipped testcase.
[Bug bootstrap/50878] [4.7 Regression] ARM bootstrap failure on insn-preds.c with error: dominator of 12 should be 6, not 5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50878 --- Comment #6 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-10-27 16:56:38 UTC --- I see this with 180560 FYI. Ramana
[Bug middle-end/50886] [4.7 Regression] 445.gobmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50886 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org, ||vries at gcc dot gnu.org --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-10-27 17:38:30 UTC --- probably a dup of PR50878.
[Bug target/50809] driver-arm.c:55:11: error: anonymous type with no linkage used to declare variable 'anonymous struct vendors []' with linkage [-Werror]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50809 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-21 CC||ams at gcc dot gnu.org, ||ramana at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-10-21 08:44:05 UTC --- Andrew's been looking into it. Ramana
[Bug target/50106] [ARM] Wrong code with -march=armv5t -mthumb -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106 --- Comment #8 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-10-20 09:07:36 UTC --- Author: ramana Date: Thu Oct 20 09:07:30 2011 New Revision: 180240 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180240 Log: 2011-10-20 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR target/50106 * config/arm/arm.c (thumb_unexpanded_epilogue): Handle return reg size from 1-3. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug target/50106] [ARM] Wrong code with -march=armv5t -mthumb -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106 --- Comment #9 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-10-20 09:24:10 UTC --- Author: ramana Date: Thu Oct 20 09:24:06 2011 New Revision: 180241 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180241 Log: Backport from mainline fix for PR target/50106. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/arm/arm.c
[Bug target/50106] [ARM] Wrong code with -march=armv5t -mthumb -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.2 --- Comment #10 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-10-20 09:25:10 UTC --- Fixed now I think.
