[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

["pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #24 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #21)
> With my new testcase, compiled on an arm-none-eabi cross with 
> 
> cc1plus ../hwy-pr111231-cpp.cc -mfpu=neon-vfpv4 -mfloat-abi=hard
> -mfp16-format=ieee -marm -mlibarch=armv7-a+neon-vfpv4
> -march=armv7-a+neon-vfpv4 -O2 -fPIE -fvisibility=hidden
> -fvisibility-inlines-hidden -fmerge-all-constants -fmath-errno
> -fno-exceptions
> 
> The critical sequence, at the end of gimple optimization is:
> 
>   v = b;
>   MEM <unsigned char[16]> [(char * {ref-all})&D.33805] = MEM <unsigned
> char[16]> [(char * {ref-all})&v];
>   v ={v} {CLOBBER(eol)};
>   v = D.33805;
>   vect__239.652_700 = MEM <vector(8) short int> [(short int *)&v];
>   vect__240.653_702 = vect__239.652_700 << 8;
> 
> This generates the following (pseudo) rtl:
> 
> ; D.33805 = _179
>   113: r215:SI=r109:SI-0x10
>   114: {r0:SI..r3:SI} = [r215:SI (0 MEM <unsigned char[16]> [(char *
> {ref-all})_179]+0 S4 A64)]
>   112: r214:SI=r109:SI-0x60
>   115: [r214:SI (0 MEM <unsigned char[16]> [(char * {ref-all})&D.33805]+0 S4
> A64)] = {r0:SI..r3:SI}
> ; _179 = D.33805
>   117: r217:SI=r109:SI-0x60
>   118: {r0:SI..r3:SI} = [r217:SI (2 D.33805+0 S4 A64)]
>   116: r216:SI=r109:SI-0x10
> * 119: [r216:SI (2 MEM[(struct Vec128<short int, 8> *)_179]+0 S4 A64)] =
> {r0:SI..r3:SI}
> ; r218 = _179
> * 120: r218:V8HI=[r109:SI-0x10 (3 MEM <vector(8) short int> [(short int
> *)_179]+0 S16 A64)]
>   121: r178:V8HI=unspec[r218:V8HI,const_vector] 451
> 
> The two key instructions have been starred. 
> 
> Things proceed OK until sched2, at which point, when building the
> dependencies, we fail to create a link between i119 and i120.  I've tracked
> this as far as ptr_deref_may_alias_decl_p (), where the call to
> may_be_aliased () decides that D.33805 cannot be aliased and thus there's no
> dependency.  But it's not clear to me why we've tracked back to the copy
> before the load of interest, nor why, at this point, we're looking at tree
> addressability to decide whether or not there are memory dependencies here.

This making it sound like one of the -fstack-reuse= issues (see the linked bug
reports from PR 111843). Does -fstack-reuse=none help?