[llvm-bugs] [Bug 44276] New: [PowerPC] vec_splats cannot be used to initialize variables with static storage duration

[via llvm-bugs]

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

            Bug ID: 44276
           Summary: [PowerPC] vec_splats cannot be used to initialize
                    variables with static storage duration
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Headers
          Assignee: unassignedclangbugs at nondot.org
          Reporter: colin.samples at gmail.com
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    nemanja.i.ibm at gmail.com, richard-llvm at metafoo.co.uk

Compiling the following C code:

    #include <altivec.h>
    static vector int a = vec_splats(1);
    int main() { return 0; }

results in:

    test2.c:2:23: error: initializer element is not a compile-time constant
    static vector int a = vec_splats(1);

This compiles on GCC and when compiled as C++ (although not in a C++ constexpr
context).

The definition of vec_splats from altivec.h is:

    static __inline__ vector int __ATTRS_o_ai vec_splats(int __a) {
      return (vector int)(__a);
    }

By manually inlining it, the program compiles:

    #include <altivec.h>
    static vector int a = (vector int)(1);
    int main() { return 0; }

vec_promote is similar in that it GCC allows it to be used to initialize a
variable with static storage duration; however, the present implementation in
LLVM does not allow static initialization even when manually inlined.

I guess the issue here is use of functions rather than macros, but using macros
would run into the same issue as bug #44241; is there some better way to do
this?

-- 
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/20191211/81a7a043/attachment.html>