llvm-gcc: x86_64 passing of struct { char a, b, c; } generates invalid read

[llvmbot]

Bugzilla Link	3413
Resolution	WONTFIX
Resolved on	Jul 29, 2010 17:32
Version	unspecified
OS	All
Reporter	LLVM Bugzilla Contributor

Extended Description

llvm-gcc generates an out of bounds read when passing struct { char a, b, c; }.

--
ddunbar@ozzy:tmp$ echo 'struct { char a,b,c; } f0() {}' | llvm-gcc -m64 -S -emit-llvm -o - -x c -

target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
target triple = "x86_64-apple-darwin10.0"
%struct.anon = type { i8, i8, i8 }

define i32 @​f0() nounwind {
entry:
%retval = alloca %struct.anon ; <%struct.anon*> [#uses=1]
%"alloca point" = bitcast i32 0 to i32 ; [#uses=0]
br label %return

return: ; preds = %entry
%retval1 = bitcast %struct.anon* %retval to i32* ; <i32*> [#uses=1]
%retval2 = load i32* %retval1 ; [#uses=1]
ret i32 %retval2
}

The read is accessing an extra byte after the alloca.

[llvmbot]

My guess is that this is being generated by the ABI stuff.
I guess it should do an i24 load and extend that to i32 ;)

[llvmbot]

The easier fix would be to pad the allocation size of retval.

[llvmbot]

The easier fix would be to pad the allocation size of retval.

Do you mean: recognize that the alloca is for the value being
returned, and specially allocate a power-of-two number of bytes?

I guess that's possible, but I prefer the solution of loading an
i16 followed by an i8, and mulching them together into the desired
i32. This happens to be exactly what you get if you load an i24
and extend it to i32, which makes it trivial to implement. On the
other hand, maybe your solution results in better code (fewer loads)?

[llvmbot]

I meant specifically the Retval allocation, although now that I think about it rounding sizes up to multiple of 4 bytes might be reasonable in the general case....could lose if there are a lot of little objects though.
It seems like this should produce better code, yes. IMO an unused byte of stack space seems like a good investment here (especially since all the ABIs I know of round SP to 4 bytes anyway).
We probably need to do this for sizes 5, 6, 7 bytes also.

[lattner]

This is (now) fixed in clang, we have no plans to fix this in llvm-gcc.