[llvm-dev] Wrong Users count for global string in clang/test/CodeGen/2009-02-13-zerosize-union-field.c

Nimrod Partush via llvm-dev llvm-dev at lists.llvm.org
Thu Nov 26 11:24:06 PST 2020


Hi,

I'm writing some code transformations using CLang. When I run my code
on clang/test/CodeGen/2009-02-13-zerosize-union-field.c
:

typedef unsigned int Foo __attribute__((aligned(32)));
typedef union{Foo:0;}a;
typedef union{int x; Foo:0;}b;
extern int printf(const char*, ...);
int main() {
  // CHECK: getelementptr inbounds ([5 x i8], [5 x i8]* @.str, i32 0, i32
0), i32 0
  printf("%ld\n", sizeof(a));
  // CHECK: getelementptr inbounds ([5 x i8], [5 x i8]* @.str, i32 0, i32
0), i32 1
  printf("%ld\n", __alignof__(a));
  // CHECK: getelementptr inbounds ([5 x i8], [5 x i8]* @.str, i32 0, i32
0), i32 4
  printf("%ld\n", sizeof(b));
  // CHECK: getelementptr inbounds ([5 x i8], [5 x i8]* @.str, i32 0, i32
0), i32 4
  printf("%ld\n", __alignof__(b));
}

I see that when I iterate the users() of the "%ld\n" string, only the last
user is reported. Here's my code for doing the iteration:

for (llvm::GlobalVariable &Glob : TheModule.globals())
  for (User *U : Glob.users())
    outs() << "User " << *U << "\n";

The 4 different calls are clearly visible in the .ll file:

  %call = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([5 x i8],
[5 x i8]* @"??_C at _04PEDNGLFL@?$CFld?6?$AA@", i64 0, i64 0), i64 4)
  %call1 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([5 x
i8], [5 x i8]* @"??_C at _04PEDNGLFL@?$CFld?6?$AA@", i64 0, i64 0), i64 1)
  %call2 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([5 x
i8], [5 x i8]* @"??_C at _04PEDNGLFL@?$CFld?6?$AA@", i64 0, i64 0), i64 4)
  %call3 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([5 x
i8], [5 x i8]* @"??_C at _04PEDNGLFL@?$CFld?6?$AA@", i64 0, i64 0), i64 4)

Any idea why this is happening?

Thanks

--Nimrod.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201126/34efc968/attachment.html>


More information about the llvm-dev mailing list