On Tue, Sep 02, 2014 at 09:47:15AM -0400, David Edelsohn wrote:
> Alan,
>
> Any feedback?
It is just papering over the real bug(s), of course, so I'd be
inclined to say this doesn't belong on trunk.
If you take a look at the assembly that is failing, you find gcc is
trying to output a location expression for a parameter of mp_compare.
After replacing the 335-.LANCHOR0 with 0:
objdump -sj.debug_loc
0180 000000f8 00000104
0190 000f7a00 03000000 00220300 00000022
01a0 9f
readelf -r
00000195 00000401 R_PPC_ADDR32 00000000 .bss + 0
readelf -wo
00000188 000000f8 00000104 (DW_OP_breg10 (r10): 0; DW_OP_addr: 0;
DW_OP_plus; DW_OP_addr: 0; DW_OP_plus; DW_OP_stack_value)
Putting this all together, and knowing that .LANCHOR0 == .bss+0, the
expresssion is really:
00000188 000000f8 00000104 (DW_OP_breg10 (r10): 0; DW_OP_addr: .LANCHOR0;
DW_OP_plus; DW_OP_addr: 335-.LANCHOR0; DW_OP_plus; DW_OP_stack_value)
ie. ((r10) + 0) + (.LANCHOR0) + (335-.LANCHOR0)
Clearly this could be simplified to (r10) + 335, so it might be that
var-tracking is being confused by section anchors. However, it is
more than just a missing simplification because the location
expression doesn't make any sense at all..
In fact if you look at the corresponding location expression for
-fno-section-anchors code you get something quite screwy too.
0000018f 00000108 00000114 (DW_OP_breg10 (r10): 0; DW_OP_addr: 144; DW_OP_plus;
DW_OP_stack_value
which is (r10) + &modulus.
If I have the interpretation of all the debug info correct, what this
is saying is that in the epilogue of upton_modmult, the value for the
"r2" parameter of mp_compare is found by adding the address of
"modulus" to the contents of r10. The correct answer is simply that
the "r2" parameter of mp_compare is in r10.
> On Tue, Sep 2, 2014 at 6:28 AM, Maciej W. Rozycki
> <ma...@codesourcery.com> wrote:
> > Hi,
> >
> > Similarly to ARM, where this issue was seen originally, and likely many
> > other targets, the Power ABI does not appear to have a relocation defined
> > to support taking a difference of two symbols in different sections each.
> > This is seen as a failure in gcc.c-torture/compile/pr60655-2.c:
--
Alan Modra
Australia Development Lab, IBM
