[llvm-bugs] [Bug 44391] New: [Aarch64] Wshadow and vcopy intrinsic

[via llvm-bugs]

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

            Bug ID: 44391
           Summary: [Aarch64] Wshadow and vcopy intrinsic
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C
          Assignee: unassignedclangbugs at nondot.org
          Reporter: aleyzour at magicleap.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

Here the code:
/// vcopy.c 
#include <arm_neon.h>

float32x4_t insert00(float32x4_t v1, float32x4_t v2) {
   return vcopyq_laneq_f32(v1, 0, v2, 0);
}
////

$ clang --version
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin


$ clang --target=aarch64-linux-gnu vcopy.c -c -I
/usr/aarch64-linux-gnu/include/ -E

# 2 "vcopy.c" 2

float32x4_t insert00(float32x4_t v1, float32x4_t v2) {
   return __extension__ ({ float32x4_t __s0_70 = v1; float32x4_t __s2_70 = v2;
float32x4_t __ret_70; __ret_70 = __extension__ ({ float32_t __s0 =
__extension__ ({ float32x4_t __s0 = __s2_70; float32_t __ret; __ret =
(float32_t) __builtin_neon_vgetq_lane_f32((int8x16_t)__s0, 0); __ret; });
float32x4_t __s1 = __s0_70; float32x4_t __ret; __ret = (float32x4_t)
__builtin_neon_vsetq_lane_f32(__s0, (int8x16_t)__s1, 0); __ret; }); __ret_70;
});


Notice that code:
{ float32_t __s0 = __extension__ ({ float32x4_t __s0 = __s2_70; .....

Should report a shadowing issue, but does fails to do so:

$ clang --target=aarch64-linux-gnu vcopy.c -c -I
/usr/aarch64-linux-gnu/include/ -Werror -Wshadow

does not report any issue at all.
But this code here (as the result of the clang -E > t1.c and reedited for
clarity)

//// t1.c
#include <arm_neon.h>

float32x4_t insert00(float32x4_t v1, float32x4_t v2) {
   return __extension__ ({ float32x4_t __s0_70 = v1; float32x4_t __s2_70 = v2;
float32x4_t __ret_70; __ret_70 = __extension__ ({ float32_t __s0 =
__extension__ ({ float32x4_t __s0 = __s2_70; float32_t __ret; __ret =
(float32_t) __builtin_neon_vgetq_lane_f32((int8x16_t)__s0, 0); __ret; });
float32x4_t __s1 = __s0_70; float32x4_t __ret; __ret = (float32x4_t)
__builtin_neon_vsetq_lane_f32(__s0, (int8x16_t)__s1, 0); __ret; }); __ret_70;
});
}
////

$ clang --target=aarch64-linux-gnu t1.c -c -I /usr/aarch64-linux-gnu/include/
-Werror -Wshadow 
t1.c:4:176: error: declaration shadows a local variable [-Werror,-Wshadow]
  ...({ float32_t __s0 = __extension__ ({ float32x4_t __s0 = __s2_70;
float32...
                                                      ^
t1.c:4:140: note: previous declaration is here
  ...float32x4_t __ret_70; __ret_70 = __extension__ ({ float32_t __s0 =
__ext...
                                                                 ^
1 error generated.

[Note: though I use clang 6.0, this can be reproduced with trunk clang]

Now. multiple questions obviously come to mind:
1- By what magic does clang remove the error in the first compilation (the one
of vcopy.c), but fails in the second case. Are those shadow errors inconsistent
or just deliberately trapped for some pattern and silently ignored?

2- Why so many neon intrinsics not functions? Does the compiler fails at
inlining them?


The reason for filing this bug is that I believe ccache (heavily used in the
context of building chromium) reuses the preprocessed C/C++ code and reinjects
them into the compilation process. And it fails when vcopy is used in the code.

There is an obvious workaround though (but only for clang), so make it a low
priority.

-- 
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/20191227/ee83f307/attachment.html>