On Fri, Mar 04, 2011 at 01:53:30PM +0000, Richard Sandiford wrote:
> A typo in dwarf2out.c:compare_loc_operands means that we fail to
> detect equivalent addresses in location lists. On this ARM testcase:
>
>
> https://bugs.launchpad.net/gcc-linaro/+bug/714921/+attachment/1837418/+files/gcc-oom.i
>
> the patch below reduces the number of lines of assembly from
> 39,230,550 to 1,266,183 when compiling with -O2 -g. (On my box,
> the original code triggers an OOM in the assembler, so I can't measure
> the difference in object sizes.)
>
> Normally I'd install this as obvious, but I'm not sure whether
> it qualifies for stage 4. I hope it does though. Not being able
> to build this file (due to the assembler OOM) is a regression from 4.4.
>
> Bootstrapped & regression-tested on x86_64-linux-gnu. OK for 4.6?
This is ok for 4.6 from RM POV, and as you say, it is obvious
and it didn't crash just because DW_OP_addr and DW_OP_const[48]u with dtprel
is created with new_loc_descr (..., ..., 0); and doesn't do anything with
the second operand, so valx2->v.val_addr will always be NULL and rtx_equal_p
then always returns false if valx1->v.val_addr is non-NULL.
> gcc/
> * dwarf2out.c (compare_loc_operands): Fix address handling.
>
> Index: gcc/dwarf2out.c
> ===================================================================
> --- gcc/dwarf2out.c 2011-03-04 13:08:38.000000000 +0000
> +++ gcc/dwarf2out.c 2011-03-04 13:15:28.000000000 +0000
> @@ -23178,7 +23178,7 @@ compare_loc_operands (dw_loc_descr_ref x
> && valx2->v.val_int == valy2->v.val_int;
> case DW_OP_addr:
> hash_addr:
> - return rtx_equal_p (valx1->v.val_addr, valx2->v.val_addr);
> + return rtx_equal_p (valx1->v.val_addr, valy1->v.val_addr);
> case DW_OP_GNU_implicit_pointer:
> return valx1->val_class == dw_val_class_die_ref
> && valx1->val_class == valy1->val_class
Jakub
