On Mon, May 23, 2016 at 3:23 PM, Bin Cheng <bin.ch...@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 alignment transfer (in that case TMR_INDEX2 is likely non-NULL though). Thanks, Richard. > Thanks, > bin > > 2016-05-20 Bin Cheng <bin.ch...@arm.com> > > * tree-ssa-address.c (copy_ref_info): Check null TMR_STEP.
