Re: [PATCH GCC]A latent alignment bug in tree-ssa-address.c

["Bin.Cheng" <amker dot cheng at gmail dot com>]

On Mon, May 23, 2016 at 3:16 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Mon, May 23, 2016 at 3:23 PM, Bin Cheng <Bin.Cheng@arm.com> wrote:
>> Hi,
>> When working on PR69710, I ran into this latent bug in which alignment information is wrongly updated for pointer variables.  It results in memory exceptions on x86_64 after patch for PR69710.  Scenario is that copy_ref_info tries to update base's alignment in TARGET_MEM_REF[base + index << step].  But case with NULL TMR_STEP (which implies the step is 1) is not handled here.  This patch fixes the bug by simply checking NULL TMR_STEP.  The conditions about TMR_STEP could be relaxed if TMR_INDEX is an induction variable which has aligned initial value and step.  But that needs non-trivial code refactoring since copy_ref_info is uses by different parts of compiler.
>>
>> Bootstrap and test on x86_64.  Is it OK?
>
> I think it is ok but having !TMR_STEP when TMR_INDEX is non-NULL is
> IMHO bad and we should enforce
> that this doesn't happen in TMR verification in
> tree-cfg.c:verify_types_in_gimple_reference.  I also notice
> that if TMR_INDEX is NULL then TMR_STEP being NULL shouldn't block
Yeah, patch updated slightly to handle this case.

Thanks,
bin
> alignment transfer (in that case
> TMR_INDEX2 is likely non-NULL though).
>
> Thanks,
> Richard.
>
>> Thanks,
>> bin
>>
>> 2016-05-20 Bin Cheng  <bin.cheng@arm.com>
>>
>>         * tree-ssa-address.c (copy_ref_info): Check null TMR_STEP.

Attachment: check-null-TMR_STEP-for-align-update-20160522.txt
Description: Text document