On Mon, Sep 22, 2014 at 10:58 AM, Richard Biener
<richard.guent...@gmail.com> wrote:
> On Thu, Sep 18, 2014 at 10:38 PM, Jeff Law <l...@redhat.com> wrote:
>> On 09/18/14 13:01, Bernd Schmidt wrote:
>>>
>>> This fixes an issue on ptx where we fail to output a declaration for a
>>> variable. The testcase is c-torture/compile/pr34856.c, and the cause of
>>> the problem is that the variable g is never inserted into the varpool,
>>> which is where a future patch will look for references to variables not
>>> defined in the current translation unit (ptx assembly requires
>>> declarations for these too).
>>>
>>> Bootstrapped and tested on x86_64-linux, ok?
>>>
>>>
>>> Bernd
>>>
>>> walk-more.diff
>>>
>>>
>>> commit 968a508fdd5c413147b9c26d37633bf7ab7a7e65
>>> Author: Bernd Schmidt<ber...@codesourcery.com>
>>> Date: Thu Sep 11 14:35:01 2014 +0200
>>>
>>> Fix handling of CONSTRUCTORs in gimple-walk.
>>>
>>> * gimple-walk.c (walk_stmt_load_store_addr_ops): Look past casts
>>> when
>>> dealing with CONSTRUCTORs.
>>
>> OK.
>
> Errr - certainly not.
>
> It seems to me that walk_stmt_load_store_addr_ops is called on
> bogus input. The function is supposed to be called on GIMPLE
> stmts and in GIMPLE stmts CONSTRUCTORs may _not_ have
> conversions in their elements.
>
> Please revert if you have applied already.
For the testcase I can indeed see
<bb 2>:
pin_3 = {(unsigned int) (long int) &g[16]};
but that's invalid GIMPLE, unfortunately not caught by out checker.
Please fix the root cause and add checking to verify_gimple_assign_single.
Thanks,
Richard.
>
> Thanks,
> Richard.
>
>> Jeff
>>
