* [PATCH][ARM] pr50193: ICE on a | (b << negative-constant)
@ 2011-09-01 11:24 Andrew Stubbs
2011-09-01 13:21 ` Joseph S. Myers
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Stubbs @ 2011-09-01 11:24 UTC (permalink / raw)
To: gcc-patches; +Cc: patches
[-- Attachment #1: Type: text/plain, Size: 469 bytes --]
This patch should fix the bug in pr50193.
The problem is that the arith_shiftsi pattern accepted any arbitrary
constant as the shift amount (via the shift_amount_operand predicate)
where in fact the constant must be in the range 0..32.
This patch fixes the problem by merely checking that the constant is
positive. I've confirmed that values larger than the mode-size are not a
problem because the compiler optimizes those away earlier, even at -O0.
OK?
Andrew
[-- Attachment #2: pr50193.patch --]
[-- Type: text/x-patch, Size: 946 bytes --]
2011-09-01 Andrew Stubbs <ams@codesourcery.com>
gcc/
* config/arm/predicates.md (shift_amount_operand): Ensure shift
amount is positive.
gcc/testsuite/
* gcc.dg/pr50193-1.c: New file.
--- a/gcc/config/arm/predicates.md
+++ b/gcc/config/arm/predicates.md
@@ -132,7 +132,8 @@
(define_predicate "shift_amount_operand"
(ior (and (match_test "TARGET_ARM")
(match_operand 0 "s_register_operand"))
- (match_operand 0 "const_int_operand")))
+ (and (match_operand 0 "const_int_operand")
+ (match_test "INTVAL (op) > 0"))))
(define_predicate "arm_add_operand"
(ior (match_operand 0 "arm_rhs_operand")
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr50193-1.c
@@ -0,0 +1,10 @@
+/* PR 50193: ARM: ICE on a | (b << negative-constant) */
+/* Ensure that the compiler doesn't ICE. */
+
+/* { dg-options "-O2" } */
+
+int
+foo(int a, int b)
+{
+ return a | (b << -3); /* { dg-warning "left shift count is negative" } */
+}
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH][ARM] pr50193: ICE on a | (b << negative-constant) 2011-09-01 11:24 [PATCH][ARM] pr50193: ICE on a | (b << negative-constant) Andrew Stubbs @ 2011-09-01 13:21 ` Joseph S. Myers 2011-09-01 15:26 ` Andrew Stubbs 0 siblings, 1 reply; 9+ messages in thread From: Joseph S. Myers @ 2011-09-01 13:21 UTC (permalink / raw) To: Andrew Stubbs; +Cc: gcc-patches, patches On Thu, 1 Sep 2011, Andrew Stubbs wrote: > This patch fixes the problem by merely checking that the constant is positive. > I've confirmed that values larger than the mode-size are not a problem because > the compiler optimizes those away earlier, even at -O0. Do you mean that you have observed for some testcases that they get optimized away - or do you have reasons (if so, please state them) to believe that any possible path through the compiler that would result in a larger constant here (possibly as a result of constant propagation and other optimizations) will always result in it being optimized away as well? If it's just observation it would be better to put the complete check in here. Quite of few of the Csmith-generated bug reports from John Regehr have involved constants appearing in unexpected places as a result of transformations in the compiler. It would probably be a good idea for someone to try using Csmith to find ARM compiler bugs (both ICEs and wrong-code); pretty much all the bugs reported have been testing on x86 and x86_64, so it's likely there are quite a few bugs in the ARM back end that could be found that way. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH][ARM] pr50193: ICE on a | (b << negative-constant) 2011-09-01 13:21 ` Joseph S. Myers @ 2011-09-01 15:26 ` Andrew Stubbs 2011-09-01 15:29 ` Andrew Stubbs 0 siblings, 1 reply; 9+ messages in thread From: Andrew Stubbs @ 2011-09-01 15:26 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc-patches, patches On 01/09/11 14:21, Joseph S. Myers wrote: > On Thu, 1 Sep 2011, Andrew Stubbs wrote: > >> This patch fixes the problem by merely checking that the constant is positive. >> I've confirmed that values larger than the mode-size are not a problem because >> the compiler optimizes those away earlier, even at -O0. > > Do you mean that you have observed for some testcases that they get > optimized away - or do you have reasons (if so, please state them) to > believe that any possible path through the compiler that would result in a > larger constant here (possibly as a result of constant propagation and > other optimizations) will always result in it being optimized away as > well? If it's just observation it would be better to put the complete > check in here. OK, fair enough, redundant or not, here's a patch with belt and braces. OK now? > Quite of few of the Csmith-generated bug reports from John Regehr have > involved constants appearing in unexpected places as a result of > transformations in the compiler. It would probably be a good idea for > someone to try using Csmith to find ARM compiler bugs (both ICEs and > wrong-code); pretty much all the bugs reported have been testing on x86 > and x86_64, so it's likely there are quite a few bugs in the ARM back end > that could be found that way. Interesting, I've suggested it within Linaro. Thanks Andrew ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH][ARM] pr50193: ICE on a | (b << negative-constant) 2011-09-01 15:26 ` Andrew Stubbs @ 2011-09-01 15:29 ` Andrew Stubbs 2011-09-01 15:52 ` Jakub Jelinek 0 siblings, 1 reply; 9+ messages in thread From: Andrew Stubbs @ 2011-09-01 15:29 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc-patches, patches [-- Attachment #1: Type: text/plain, Size: 166 bytes --] On 01/09/11 16:26, Andrew Stubbs wrote: > OK, fair enough, redundant or not, here's a patch with belt and braces. > > OK now? And again, with the patch .... Andrew [-- Attachment #2: pr50193.patch --] [-- Type: text/x-patch, Size: 1014 bytes --] 2011-09-01 Andrew Stubbs <ams@codesourcery.com> gcc/ * config/arm/predicates.md (shift_amount_operand): Ensure shift amount is in the range 1..mode_size-1. gcc/testsuite/ * gcc.dg/pr50193-1.c: New file. --- a/gcc/config/arm/predicates.md +++ b/gcc/config/arm/predicates.md @@ -132,7 +132,9 @@ (define_predicate "shift_amount_operand" (ior (and (match_test "TARGET_ARM") (match_operand 0 "s_register_operand")) - (match_operand 0 "const_int_operand"))) + (and (match_operand 0 "const_int_operand") + (match_test "INTVAL (op) > 0 + && INTVAL (op) <= GET_MODE_PRECISION (mode)")))) (define_predicate "arm_add_operand" (ior (match_operand 0 "arm_rhs_operand") --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr50193-1.c @@ -0,0 +1,10 @@ +/* PR 50193: ARM: ICE on a | (b << negative-constant) */ +/* Ensure that the compiler doesn't ICE. */ + +/* { dg-options "-O2" } */ + +int +foo(int a, int b) +{ + return a | (b << -3); /* { dg-warning "left shift count is negative" } */ +} ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH][ARM] pr50193: ICE on a | (b << negative-constant) 2011-09-01 15:29 ` Andrew Stubbs @ 2011-09-01 15:52 ` Jakub Jelinek 2011-09-01 16:21 ` Andrew Stubbs 2011-09-07 15:37 ` Richard Earnshaw 0 siblings, 2 replies; 9+ messages in thread From: Jakub Jelinek @ 2011-09-01 15:52 UTC (permalink / raw) To: Andrew Stubbs; +Cc: Joseph S. Myers, gcc-patches, patches On Thu, Sep 01, 2011 at 04:29:25PM +0100, Andrew Stubbs wrote: > On 01/09/11 16:26, Andrew Stubbs wrote: > >OK, fair enough, redundant or not, here's a patch with belt and braces. > > > >OK now? > > And again, with the patch .... > > Andrew > 2011-09-01 Andrew Stubbs <ams@codesourcery.com> > > gcc/ > * config/arm/predicates.md (shift_amount_operand): Ensure shift > amount is in the range 1..mode_size-1. > > gcc/testsuite/ > * gcc.dg/pr50193-1.c: New file. > > --- a/gcc/config/arm/predicates.md > +++ b/gcc/config/arm/predicates.md > @@ -132,7 +132,9 @@ > (define_predicate "shift_amount_operand" > (ior (and (match_test "TARGET_ARM") > (match_operand 0 "s_register_operand")) > - (match_operand 0 "const_int_operand"))) > + (and (match_operand 0 "const_int_operand") > + (match_test "INTVAL (op) > 0 > + && INTVAL (op) <= GET_MODE_PRECISION (mode)")))) IN_RANGE (INTVAL (op), 0, GET_MODE_PRECISION (mode) - 1) ? 1) shift by 0 is well defined (though not sure if arm backend supports it) 2) shift by mode precision is undefined 3) isn't mode here the mode of the shift operand rather than of the shift itself (perhaps on arm in all patterns they are the same - a brief look at arm.amd suggest they are and they are SImode in all cases, so perhaps just IN_RANGE (INTVAL (op), 0, 31) ?) Jakub ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH][ARM] pr50193: ICE on a | (b << negative-constant) 2011-09-01 15:52 ` Jakub Jelinek @ 2011-09-01 16:21 ` Andrew Stubbs 2011-09-05 17:07 ` Andrew Stubbs 2011-09-07 15:37 ` Richard Earnshaw 1 sibling, 1 reply; 9+ messages in thread From: Andrew Stubbs @ 2011-09-01 16:21 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Joseph S. Myers, gcc-patches, patches On 01/09/11 16:51, Jakub Jelinek wrote: > IN_RANGE (INTVAL (op), 0, GET_MODE_PRECISION (mode) - 1) ? Ok, I can make that change. > 1) shift by 0 is well defined (though not sure if arm backend > supports it) Yeah, I suppose I could allow 0, but I don't know why it would be helpful? I mean, it's not like there's an operation that is only available with a no-op shift (I suppose you could say that all the ARM opcodes are like that, but neither the md file nor the official canonical assembler notation represents it that way). Conversely, assuming it's even possible for a zero shift to get this far, I imagined it would be possible for combine to use the arith_shiftsi pattern and therefore prevent it from combining the and/or/add/whatever into something else more worthwhile, so I chose to insist on greater than zero. > 2) shift by mode precision is undefined The LSL and ROR require the shift amount to be 1..31 while the LSR and ASR require 1..32. Anecdotally speaking, gcc optimizes away (and warns about) shifts greater than 31, so I chose mode-1. > 3) isn't mode here the mode of the shift operand rather than of the shift > itself (perhaps on arm in all patterns they are the same - > a brief look at arm.amd suggest they are and they are SImode in all > cases, so perhaps just IN_RANGE (INTVAL (op), 0, 31) ?) Well, I didn't want to hard-code the number, but yes, that would be equivalent at present, I think. I wasn't sure how to find the mode of shift operand in the predicate though, so I've assumed they're always the same size. How would one find the proper mode in a predicate? Andrew ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH][ARM] pr50193: ICE on a | (b << negative-constant) 2011-09-01 16:21 ` Andrew Stubbs @ 2011-09-05 17:07 ` Andrew Stubbs 2011-09-07 15:05 ` Ramana Radhakrishnan 0 siblings, 1 reply; 9+ messages in thread From: Andrew Stubbs @ 2011-09-05 17:07 UTC (permalink / raw) Cc: Jakub Jelinek, Joseph S. Myers, gcc-patches, patches [-- Attachment #1: Type: text/plain, Size: 1221 bytes --] On 01/09/11 17:21, Andrew Stubbs wrote: > I wasn't sure how to find the mode of shift operand in the predicate > though, so I've assumed they're always the same size. How would one find > the proper mode in a predicate? OK, no reply, so I'm just going to assume we're dealing with 32-bit registers. Additionally, Richard Sandiford has pointed out that changing the predicate such that it is more restrictive than the constraints is a problem because reload apparently ignores the predicates under certain circumstances. Setting aside that that seems broken and wrong (what's the point in a predicate if you're just going to ignore it), this patch also creates a new constraint "Pm" that limits the range to match the predicate. Speaking of which, I've limited the constants to the range 1..31 (inclusive) because a) allowing zero seems like it would be counter-productive - it would be better to keep a zero shift as a separate operation that can be optimized away (probably not an issue, but there it is); and b) allowing zero would produce non-canonical assembler (which is not a problem now, but is still best avoided). I have a bootstrap test running now. Assuming that succeeds, is this ok? Andrew [-- Attachment #2: pr50193.patch --] [-- Type: text/x-patch, Size: 6684 bytes --] 2011-09-05 Andrew Stubbs <ams@codesourcery.com> gcc/ * config/arm/arm.md (*not_shiftsi, *not_shiftsi_compare0, *not_shiftsi_compare0_scratch, *cmpsi_shiftsi, *cmpsi_shiftsi_swp, *arith_shiftsi, *arith_shiftsi_compare0, *arith_shiftsi_compare0_scratch, *sub_shiftsi, *sub_shiftsi_compare0, *sub_shiftsi_compare0_scratch): Change 'M' constraint to 'Pm'. * config/arm/constraints.md (Pm): New constraint. * config/arm/predicates.md (shift_amount_operand): Ensure that all constants satisfy the Pm constraint. gcc/testsuite/ * testsuite/gcc.dg/pr50193-1.c: New file. --- a/gcc/config/arm/arm.md +++ b/gcc/config/arm/arm.md @@ -3669,7 +3669,7 @@ [(set (match_operand:SI 0 "s_register_operand" "=r,r") (not:SI (match_operator:SI 3 "shift_operator" [(match_operand:SI 1 "s_register_operand" "r,r") - (match_operand:SI 2 "shift_amount_operand" "M,rM")])))] + (match_operand:SI 2 "shift_amount_operand" "Pm,rPm")])))] "TARGET_32BIT" "mvn%?\\t%0, %1%S3" [(set_attr "predicable" "yes") @@ -3683,7 +3683,7 @@ (compare:CC_NOOV (not:SI (match_operator:SI 3 "shift_operator" [(match_operand:SI 1 "s_register_operand" "r,r") - (match_operand:SI 2 "shift_amount_operand" "M,rM")])) + (match_operand:SI 2 "shift_amount_operand" "Pm,rPm")])) (const_int 0))) (set (match_operand:SI 0 "s_register_operand" "=r,r") (not:SI (match_op_dup 3 [(match_dup 1) (match_dup 2)])))] @@ -3700,7 +3700,7 @@ (compare:CC_NOOV (not:SI (match_operator:SI 3 "shift_operator" [(match_operand:SI 1 "s_register_operand" "r,r") - (match_operand:SI 2 "shift_amount_operand" "M,rM")])) + (match_operand:SI 2 "shift_amount_operand" "Pm,rPm")])) (const_int 0))) (clobber (match_scratch:SI 0 "=r,r"))] "TARGET_32BIT" @@ -7247,7 +7247,7 @@ (compare:CC (match_operand:SI 0 "s_register_operand" "r,r") (match_operator:SI 3 "shift_operator" [(match_operand:SI 1 "s_register_operand" "r,r") - (match_operand:SI 2 "shift_amount_operand" "M,rM")])))] + (match_operand:SI 2 "shift_amount_operand" "Pm,rPm")])))] "TARGET_32BIT" "cmp%?\\t%0, %1%S3" [(set_attr "conds" "set") @@ -7259,7 +7259,7 @@ [(set (reg:CC_SWP CC_REGNUM) (compare:CC_SWP (match_operator:SI 3 "shift_operator" [(match_operand:SI 1 "s_register_operand" "r,r") - (match_operand:SI 2 "shift_amount_operand" "M,rM")]) + (match_operand:SI 2 "shift_amount_operand" "Pm,rPm")]) (match_operand:SI 0 "s_register_operand" "r,r")))] "TARGET_32BIT" "cmp%?\\t%0, %1%S3" @@ -8649,7 +8649,7 @@ (match_operator:SI 1 "shiftable_operator" [(match_operator:SI 3 "shift_operator" [(match_operand:SI 4 "s_register_operand" "r,r,r,r") - (match_operand:SI 5 "shift_amount_operand" "M,M,M,r")]) + (match_operand:SI 5 "shift_amount_operand" "Pm,Pm,Pm,r")]) (match_operand:SI 2 "s_register_operand" "rk,rk,r,rk")]))] "TARGET_32BIT" "%i1%?\\t%0, %2, %4%S3" @@ -8700,7 +8700,7 @@ (match_operator:SI 1 "shiftable_operator" [(match_operator:SI 3 "shift_operator" [(match_operand:SI 4 "s_register_operand" "r,r") - (match_operand:SI 5 "shift_amount_operand" "M,r")]) + (match_operand:SI 5 "shift_amount_operand" "Pm,r")]) (match_operand:SI 2 "s_register_operand" "r,r")]) (const_int 0))) (set (match_operand:SI 0 "s_register_operand" "=r,r") @@ -8719,7 +8719,7 @@ (match_operator:SI 1 "shiftable_operator" [(match_operator:SI 3 "shift_operator" [(match_operand:SI 4 "s_register_operand" "r,r") - (match_operand:SI 5 "shift_amount_operand" "M,r")]) + (match_operand:SI 5 "shift_amount_operand" "Pm,r")]) (match_operand:SI 2 "s_register_operand" "r,r")]) (const_int 0))) (clobber (match_scratch:SI 0 "=r,r"))] @@ -8735,7 +8735,7 @@ (minus:SI (match_operand:SI 1 "s_register_operand" "r,r") (match_operator:SI 2 "shift_operator" [(match_operand:SI 3 "s_register_operand" "r,r") - (match_operand:SI 4 "shift_amount_operand" "M,r")])))] + (match_operand:SI 4 "shift_amount_operand" "Pm,r")])))] "TARGET_32BIT" "sub%?\\t%0, %1, %3%S2" [(set_attr "predicable" "yes") @@ -8749,7 +8749,7 @@ (minus:SI (match_operand:SI 1 "s_register_operand" "r,r") (match_operator:SI 2 "shift_operator" [(match_operand:SI 3 "s_register_operand" "r,r") - (match_operand:SI 4 "shift_amount_operand" "M,rM")])) + (match_operand:SI 4 "shift_amount_operand" "Pm,rPm")])) (const_int 0))) (set (match_operand:SI 0 "s_register_operand" "=r,r") (minus:SI (match_dup 1) @@ -8767,7 +8767,7 @@ (minus:SI (match_operand:SI 1 "s_register_operand" "r,r") (match_operator:SI 2 "shift_operator" [(match_operand:SI 3 "s_register_operand" "r,r") - (match_operand:SI 4 "shift_amount_operand" "M,rM")])) + (match_operand:SI 4 "shift_amount_operand" "Pm,rPm")])) (const_int 0))) (clobber (match_scratch:SI 0 "=r,r"))] "TARGET_32BIT" --- a/gcc/config/arm/constraints.md +++ b/gcc/config/arm/constraints.md @@ -31,7 +31,7 @@ ;; The following multi-letter normal constraints have been used: ;; in ARM/Thumb-2 state: Da, Db, Dc, Dn, Dl, DL, Dv, Dy, Di, Dz ;; in Thumb-1 state: Pa, Pb, Pc, Pd -;; in Thumb-2 state: Pj, PJ, Ps, Pt, Pu, Pv, Pw, Px, Py +;; in Thumb-2 state: Pj, PJ, Pm, Ps, Pt, Pu, Pv, Pw, Px, Py ;; The following memory constraints have been used: ;; in ARM/Thumb-2 state: Q, Ut, Uv, Uy, Un, Um, Us @@ -172,6 +172,12 @@ (and (match_code "const_int") (match_test "TARGET_THUMB1 && ival >= 0 && ival <= 7"))) +(define_constraint "Pm" + "@internal In ARM/Thumb2 state, a constant in the range 1 to 31" + (and (match_code "const_int") + (match_test "TARGET_32BIT + && IN_RANGE (ival, 1, 31)"))) + (define_constraint "Ps" "@internal In Thumb-2 state a constant in the range -255 to +255" (and (match_code "const_int") --- a/gcc/config/arm/predicates.md +++ b/gcc/config/arm/predicates.md @@ -132,7 +132,8 @@ (define_predicate "shift_amount_operand" (ior (and (match_test "TARGET_ARM") (match_operand 0 "s_register_operand")) - (match_operand 0 "const_int_operand"))) + (and (match_operand 0 "const_int_operand") + (match_test "satisfies_constraint_Pm (op)")))) (define_predicate "arm_add_operand" (ior (match_operand 0 "arm_rhs_operand") --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr50193-1.c @@ -0,0 +1,10 @@ +/* PR 50193: ARM: ICE on a | (b << negative-constant) */ +/* Ensure that the compiler doesn't ICE. */ + +/* { dg-options "-O2" } */ + +int +foo(int a, int b) +{ + return a | (b << -3); /* { dg-warning "left shift count is negative" } */ +} ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH][ARM] pr50193: ICE on a | (b << negative-constant) 2011-09-05 17:07 ` Andrew Stubbs @ 2011-09-07 15:05 ` Ramana Radhakrishnan 0 siblings, 0 replies; 9+ messages in thread From: Ramana Radhakrishnan @ 2011-09-07 15:05 UTC (permalink / raw) To: Andrew Stubbs; +Cc: Jakub Jelinek, Joseph S. Myers, gcc-patches, patches On 5 September 2011 18:07, Andrew Stubbs <ams@codesourcery.com> wrote: > On 01/09/11 17:21, Andrew Stubbs wrote: >> >> I wasn't sure how to find the mode of shift operand in the predicate >> though, so I've assumed they're always the same size. How would one find >> the proper mode in a predicate? > > OK, no reply, so I'm just going to assume we're dealing with 32-bit > registers. > > Additionally, Richard Sandiford has pointed out that changing the predicate > such that it is more restrictive than the constraints is a problem because > reload apparently ignores the predicates under certain circumstances. > Setting aside that that seems broken and wrong (what's the point in a > predicate if you're just going to ignore it), this patch also creates a new > constraint "Pm" that limits the range to match the predicate. > > Speaking of which, I've limited the constants to the range 1..31 (inclusive) > because a) allowing zero seems like it would be counter-productive - it > would be better to keep a zero shift as a separate operation that can be > optimized away (probably not an issue, but there it is); and b) allowing > zero would produce non-canonical assembler (which is not a problem now, but > is still best avoided). > > I have a bootstrap test running now. Assuming that succeeds, is this ok? This is a summary of what we discussed on IRC for others to also comment. This doesn't capture the case of mult by power_of_two in arith_shiftsi . So this testcase below int * foo (int *x , int y) { return x + (y << 24); } will fail . There are 2 options as we discussed on IRC . 1. as you suggested a check in shift_operator for the shift amount. 2. add an alternative for the M constraint but enable it using insn_enabled only if the mult_operator is valid. This sort of cries to be rewritten with iterators and then we can retain the mult case as a specific pattern only with the M constraint but that is a significant rewrite. > +;; in Thumb-2 state: Pj, PJ, Pm, Ps, Pt, Pu, Pv, Pw, Px, Py Minor nit - Pm is valid for both ARM / Thumb2 state and not just Thumb2 unlike the other constraints in the list above. Hope this helps. Ramana > > Andrew > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH][ARM] pr50193: ICE on a | (b << negative-constant) 2011-09-01 15:52 ` Jakub Jelinek 2011-09-01 16:21 ` Andrew Stubbs @ 2011-09-07 15:37 ` Richard Earnshaw 1 sibling, 0 replies; 9+ messages in thread From: Richard Earnshaw @ 2011-09-07 15:37 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Andrew Stubbs, Joseph S. Myers, gcc-patches, patches On 01/09/11 16:51, Jakub Jelinek wrote: > 1) shift by 0 is well defined (though not sure if arm backend > supports it) The canonical form of (<any_shift> (x) (const_int 0)) is just (x) So while it's well defined, it's also useless. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-09-07 15:12 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-09-01 11:24 [PATCH][ARM] pr50193: ICE on a | (b << negative-constant) Andrew Stubbs 2011-09-01 13:21 ` Joseph S. Myers 2011-09-01 15:26 ` Andrew Stubbs 2011-09-01 15:29 ` Andrew Stubbs 2011-09-01 15:52 ` Jakub Jelinek 2011-09-01 16:21 ` Andrew Stubbs 2011-09-05 17:07 ` Andrew Stubbs 2011-09-07 15:05 ` Ramana Radhakrishnan 2011-09-07 15:37 ` Richard Earnshaw
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).