[patch] Fix ICE on CONSTRUCTOR containing absolute addresses

[Richard Biener]

On Mon, Jul 17, 2017 at 10:51 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> Apart from the MEM construction where I simply trust you this looks
>> ok.  Mind adding MEM_REF support for this case as well?
>
> Do you mean MEM_REF <INTEGER_CST, INTEGER_CST>?  Is that possible?

Yes.

>> Btw, why's simply output_constant_def (TREE_OPERAND (target, 0), 1);
>> not correct?
>
> If you do that, you get a symbol in the constant pool whose value (address) is
> arbitrary; here what we want is a fixed value.  That being said, given that
> the contents of the contant pool is hashed, there is very likely not much
> difference in the end, although that would be conceptually incorrect.
>
>> Isn't this about &*0x1?
>
> Yes, it's not the address of a constant, it's the address of an object whose
> base address is absolute, so &(abs_address)->field[index].  This kind of thing
> is not folded by build_fold_addr_expr.

So this isn't about global

 void *x[] = { &((struct Y *)0x12)->foo }

but for a local one where supposedly variable indexing is valid (don't
we gimplify
that)?

And

+    case INDIRECT_REF:
+      /* This deals with absolute addresses.  */
+      offset += tree_to_shwi (TREE_OPERAND (target, 0));
+      x = gen_rtx_MEM (QImode,
+                      gen_rtx_SYMBOL_REF (Pmode, "origin of addresses"));

simply translates 0x12 to &*<origin> + 0x12 (where origin == 0 somehow?).

I suppose returing directly here and sth like

    value->base = gen_rtx_SYMBOL_REF (Pmode, "origin of addresses");
    value->offset = offset + tree_to_shwi (...);
    return;

would be clearer.  Or even

    value->base = tree-to-rtx (TREE_OPERAND (target, 0));
    value->offset = offset;

?


> --
> Eric Botcazou