https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155
--- Comment #14 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> --- Hi Dominique, Thanks for doing that. It was to have been my final step in the process. I will commit the patch and then will go back to diagnose why an unchanged tree dump yields different assembler. Cheers Paul On 3 February 2018 at 12:44, dominiq at lps dot ens.fr <gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155 > > --- Comment #13 from Dominique d'Humieres <dominiq at lps dot ens.fr> --- >> There is an important caveat to this fix, which has me very worried: >> On top of removal of uncalled code making the bug disappear, I cannot >> see any difference in the tree dump between the working testcase and >> the failing version. > > Confirmed. However looking to the assembly for the first test, I see > > ... > movq $4, (%rcx) #, MEM[(struct array_t[0:] > *)_21][_23].child.dtype.elem_len > ... > movb $1, (%rcx) #, MEM[(struct array_t[0:] > *)_21][_23].child.dtype.rank > ... > movb $1, (%rax) #, MEM[(struct array_t[0:] > *)_21][_23].child.dtype.type > ... > > for the working case that are not present without the patch. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
