On 01/28/2016 03:53 PM, Jason Merrill wrote:
On 01/28/2016 02:48 PM, Martin Sebor wrote:
The g++.dg/cpp1y/vla-initlist1.C test relies on undefined behavior
(reading an uninitialized array element) to verify that two VLAs
are allocated in memory starting at the same address. The test
has been seen to fail on powerpc64-*-linux-gnu and spu-*-elf.
The attached patch removes the undefined behavior while still
verifying the same thing. It passes on powerpc64le.
Jason, based on your comment in the bug I've removed the part
of the test that verifies that the no-op initializer-list ctor
for the user-defined VLA leaves the array elements uninitialized.
If that's something that should be tested let me know and I'll
add another test or test case for that.
Actually, yes, the testcase is testing for that as well. Is that the
part that breaks on PPC64LE?
Yes, that's the only thing the existing test exercises (i.e., that
the second element of the array is unchanged).
What seems to happen is that the call to __builtin_alloca_with_align
uses the stdu (store with update) instruction to store and bump down
the stack pointer (SP) at the same time (standard for powerpc63le)
to make room for the VLA. The subsequent code then reads the saved
value of the SP and uses it as the address of the VLA. Since the SP
is 64 bits wide, it clobbers the first two words of the VLA. The
test looks at the second element, expecting it to be unchanged, but
what it finds is the upper word of the saved SP. Since the saved SP
value doesn't get read I don't see anything wrong with this.
Other than that, I did notice one thing that doesn't look right.
There's an empty loop for the no-op initializer_list ctor to
initialize the rest of the array. I should open a bug for that.
But that's not a unique to the powerpc64 back end. The x86_64
code has the same empty loop.
Martin
