Incorrect initialization of global arrays that are 2^32 bytes or larger

[nlsandler]

C programs with partially initialized arrays that are larger than 2^32 bytes aren't compiled correctly:

• char arrays get initialized entirely to zero, even if they have a non-zero initializer in the original source code
• when initializing arrays of other types, LLVM emits a .space or .zero directive with a negative byte count, which is rejected by the assembler.

char bad_char[4294967296] = {1};
char ok_char[4294967295u] = {1};

int bad_int[1073741824] = {1};
int ok_int[1073741823] = {1};

Compiling this with clang -S -arch x86_64 bad_static_arrays.c produces:

	.section	__TEXT,__text,regular,pure_instructions
	.build_version macos, 10, 15	sdk_version 10, 15
	.globl	_bad_char               ## @bad_char
.zerofill __DATA,__common,_bad_char,4294967296,4
	.section	__DATA,__data
	.globl	_ok_char                ## @ok_char
	.p2align	4
_ok_char:
	.byte	1                       ## 0x1
	.space	4294967294

	.globl	_bad_int                ## @bad_int
	.p2align	4
_bad_int:
	.long	1                       ## 0x1
	.space	4294967292
	.space	-4294967296

	.globl	_ok_int                 ## @ok_int
	.p2align	4
_ok_int:
	.long	1                       ## 0x1
	.space	4294967288


.subsections_via_symbols

That's from compiling with Clang 11.0, but it looks like the issue exists in the most recent version too: https://godbolt.org/z/eobvhbf7s

[OfekShochat]

just a note, seems like this isnt a problem within clang but llvm codegen, https://godbolt.org/z/dEo36dW43 at least with bad_int, with bad_char it is initializing to zeros. I'll have to investigate deeper because I don't know the codebase yet, but this seems relevant. I don't know actually, you might want to ignore this comment, but that means somehow VectorType is doing something fishy, because all it does (understandably) is extending Type with methods to get the number of elements etc

[efriedma-quic]

See

llvm-project/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

Line 3065 in 53f738c

unsigned Size = DL.getTypeAllocSize(CS->getType());

[llvmbot]

@llvm/issue-subscribers-good-first-issue

[OfekShochat]

Hello! Thanks for pointing that out, i had to do something else (if you're wondering). Currently I don't have an environment to actually fix this, but if this isn't in a very high priority, can I fix this as I actually set up my machine?

[efriedma-quic]

Sure; this appears to be a longstanding issue, so no rush.

[OfekShochat]

Thanks!

[msebor]

See also #54766.

[OfekShochat]

interestingly, both master and 14.0.6 fail on my machine in the parsing part, and seems like godbolt does too https://godbolt.org/z/59oqh7na7 (this is c++, not c)

[OfekShochat]

Hello! Today I found both problems. Of course that I just didn't pay attention to where exactly I was pointed to.
Question now is, what should it do? Should it fail? In codegen (the bad_char one, that clang's codegen is the problem) it tries to reserve NumElements in a SmallVector which it can't really handle.. The alternative to failing is having a check there and not trying to reserve all the elements, but giving EmitArrayConstant an argument so it knows to emit the space but doesn't allocate anything.
Is any of my conclusions wrong (they might be, I still didn't go over EmitArrayConstant thoroughly)?

[shafik]

I think this is related to #57317