[Bug 199051] New: Sparse IR generation for initializers is generating STORE instructions with PSEUDO_VAL with value 0 but size greater than 64-bits

[bugzilla-daemon@xxxxxxxxxxxxxxxxxxx]

https://bugzilla.kernel.org/show_bug.cgi?id=199051

               URL: https://marc.info/?l=linux-sparse&m=152029047803362&w=
                    2
            Bug ID: 199051
           Summary: Sparse IR generation for initializers is generating
                    STORE instructions with PSEUDO_VAL with value 0 but
                    size greater than 64-bits
           Product: Tools
           Version: unspecified
    Kernel Version: N/A
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: high
          Priority: P1
         Component: Sparse
          Assignee: tools_sparse@xxxxxxxxxxxxxxxxxxxxxx
          Reporter: mobile@xxxxxxxxxxxxxxx
        Regression: No

Impacted Sparse versions: 0.5.1, 0.5.2-RC1

While testing the patch for giving value pseudos of type PSEUDO_VAL a size, a
problem was discovered with a previous patch that attempted to zero-initialize
declarations with incomplete initializers. This initial patch for this was
https://marc.info/?l=linux-sparse&m=149168635810900&w=2. 

The problem with this patch is two fold:
a) It generates STORE instructions that uses a value pseudo of type PSEUDO_VAL,
and value 0, but size can be greater than 64-bits. This violates the invariant
for a PSEUDO_VAL type which has a long value that can only be 64-bits in size.
b) Secondly as all value pseudos (type PSEUDO_VAL) of 0 value are considered
the same, the pseudo ends up getting referenced in unrelated instruction sizes. 

Example test program:

struct A {
        long x,y;
};
struct B {
        char buf[100];
        union {
                int j;
                long long k;
        } u;
};

extern int printf(const char *, ...);
void bar(int j) {
        printf("got %d\n", j);
}

void foo()
{
        struct A a = { 0 };
        struct B b = { { 0 } };

        a.y == 0 ? bar(1) : bar(0);
        b.u.j == 0 ? bar(1) : bar(0);
        b.u.k == 0 ? bar(1) : bar(0);
}

int main(void)
{
        foo();
        return 0;
}

A somewhat enhanced dump of IR for foo() shows this:

foo:
.L2:
        <entry-point>
        store.128   $0 -> 0[a]
          target pseudo usage {
          }
          src pseudo usage {
              store.128   $0 -> 0[a]
              store.64    $0 -> 0[a]
              load.64     %r4 <- 8[a]
          }
        store.64    $0 -> 0[a]
          target pseudo usage {
          }
          src pseudo usage {
             store.128   $0 -> 0[a]
             store.64    $0 -> 0[a]
             load.64     %r4 <- 8[a]
          }
        store.896   $0 -> 0[b]
          target pseudo usage {
          }
          src pseudo usage {
             store.896   $0 -> 0[b]
             store.8     $0 -> 0[b]
             load.32     %r7 <- 104[b]
             load.64     %r10 <- 104[b]
          }
        store.8     $0 -> 0[b]
          target pseudo usage {
          }
          src pseudo usage {
             store.896   $0 -> 0[b]
             store.8     $0 -> 0[b]
             load.32     %r7 <- 104[b]
             load.64     %r10 <- 104[b]
          }

truncated>


Since these STORE instructions were only required to fix an issue with
sparse-llvm and sparse-llvm cannot actually handle these instructions correctly
anyway, an immediate fix is to revert the aforesaid patch, and review the
approach to resolving this issue for a future patch.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html