[llvm-bugs] [Bug 45035] New: Enabling UseAA in the arm backend generates wrong instruction order for pattern initialization

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=45035

            Bug ID: 45035
           Summary: Enabling UseAA in the arm backend generates wrong
                    instruction order for pattern initialization
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: yabinc at google.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

https://reviews.llvm.org/D69796 enables UseAA in the arm backend.
When compiling for arm target on Android with -ftrivial-auto-var-init=pattern,
we found a case that clang generates wrong instruction order to initialize a
local variable, putting a pattern initialization instruction after
initialization instructions in the inlined constructor. Thus it makes a wrongly
initialized member value for the local variable.

An example is shown in https://godbolt.org/z/3EHgBy.

C++ code:
struct af {
  long long s;
  long long ag;
  bool t;
  bool ah;
  bool u;
  af() : s(0), ag(0), t(false), ah(false), u(false) {}
};
z v, w;
ad x;
void aj(h<void(af &)> &ak) {
  for (; v != w;) {
    af a;
    ak(a);
  }
}

In the for loop, a.t should be initialized to false in the constructor. But
it isn't the case when compiled with below flags:
-c  -mthumb -Os    -O2 -g   -ftrivial-auto-var-init=pattern   -march=armv8-a
-mfloat-abi=softfp -mfpu=neon-fp-armv8  -target armv7a-linux-androideabi10000 
-Wall -Werror -std=gnu++17

In the disassembly:
        mov.w   r5, #-1
        ...
        strd    r5, r5, [sp, #8]    <== pattern initialization
        strd    r5, r5, [sp]        <== pattern initialization
        mov     r1, r9
        vst1.64 {d8, d9}, [r0], r10  <== constructor
        str.w   r11, [r0]            <== constructor
        mov     r0, r8
        strd    r5, r5, [sp, #16]    <== pattern initialization 
        bl      h<void (af&)>::operator()(af&)


So the last pattern initialization instruction makes a.t = 0xff.

The problem goes away if we revert https://reviews.llvm.org/D69796.
It is reproduced with latest llvm, with git hash
e4a9225f5d10f35cf9cf3664bb93620880228782.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200226/41328c84/attachment-0001.html>