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

            Bug ID: 48735
           Summary: Difference between GCC and Clang on a defined program:
                    GCC's VLA is Clang fixed-size automatic array
           Product: clang
           Version: 11.0
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected], [email protected],
                    [email protected], [email protected],
                    [email protected]

Consider the compilation unit:

int t[12];

#define ADDR_FIRST (&(t[0]))
#define ADDR_LAST  (&(t[11]))

int Y, Z;

void f(void) {
  // Define u the same size as t:                                               
  long u[ADDR_LAST - ADDR_FIRST + 1];
  Y = sizeof *(Z=1, &u);
}

Compiler Explorer link: https://gcc.godbolt.org/z/fa8frb

When u is an automatic variable, GCC 10.2 treats u, declared as above, as a
VLA, and therefore generates code for the function f that assigns Z:

f:
        movl    $1, Z(%rip)
        movl    $96, Y(%rip)
        ret

Meanwhile Clang 11.0.0 treats the expression “ADDR_LAST - ADDR_FIRST + 1” as a
constant expression, which I think it is entitled to per C17 6.6:10
(https://cigix.me/c17#6.6.p10 ), meaning that u is a fixed-size array and that
f should not assign Z:

f:                                      # @f
        movl    $96, Y(%rip)
        retq

Note that the two compilers's behaviors agree when u is a static-lifetime
variable. In that case GCC emits a somewhat misleading warning about u having
file scope (whereas it should be the lifetime of u that's the problem) and
variable size, and subsequently treats u as a fixed-size array. Changing the
recognition of constant expressions to be stricter for all array sizes would
make Clang reject a static-lifetime definition for u, which GCC accepts.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to