On 03/16/2016 03:39 PM, H.J. Lu wrote:
On Wed, Mar 16, 2016 at 10:02 AM, H.J. Lu <hjl.to...@gmail.com> wrote:
On Wed, Mar 16, 2016 at 9:58 AM, Jason Merrill <ja...@redhat.com> wrote:
On 03/16/2016 08:38 AM, H.J. Lu wrote:
FAIL: g++.dg/abi/pr60336-1.C scan-assembler jmp[\t
]+[^$]*?_Z3xxx9true_type
FAIL: g++.dg/abi/pr60336-5.C scan-assembler jmp[\t
]+[^$]*?_Z3xxx9true_type
FAIL: g++.dg/abi/pr60336-6.C scan-assembler jmp[\t
]+[^$]*?_Z3xxx9true_type
FAIL: g++.dg/abi/pr60336-7.C scan-assembler jmp[\t
]+[^$]*?_Z3xxx9true_type
FAIL: g++.dg/abi/pr60336-9.C scan-assembler jmp[\t
]+[^$]*?_Z3xxx9true_type
FAIL: g++.dg/abi/pr68355.C scan-assembler jmp[\t
]+[^$]*?_Z3xxx17integral_constantIbLb1EE
These pass for me on x86_64, but I do see calls with -m32.
They are expected since get_ref_base_and_extent needs to be
changed to set bitsize to 0 for empty types so that when
ref_maybe_used_by_call_p_1 calls get_ref_base_and_extent to
get 0 as the maximum size on empty type. Otherwise, find_tail_calls
won't perform tail call optimization for functions with empty type
parameters.
That isn't why the optimization isn't happening in pr68355 with -m32; the
.optimized dump has
xxx (D.2289); [tail call]
Rather, the failure seems to happen in load_register_parameter, at
/* Check for overlap with already clobbered argument area,
providing that this has non-zero size. */
if (is_sibcall
&& (size == 0
|| mem_overlaps_already_clobbered_arg_p
(XEXP (args[i].value, 0),
size)))
*sibcall_failure = 1;
The code seems to contradict the comment, and seems to have been broken by
r162402. Applying this additional patch fixes those tests.
I am running the full test now.
On x86-64, I got
export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.dg/ubsan/object-size-9.c:11:13:
runtime error: load of address 0x000000600ffa with insufficient space
for an object of type 'char'
0x000000600ffa: note: pointer points here
<memory cannot be printed>
PASS: gcc.dg/ubsan/object-size-9.c -O2 execution test
FAIL: gcc.dg/ubsan/object-size-9.c -O2 output pattern test
Output was:
That looks like a dejagnu glitch; the output you quote seems to match
the expected output from the test.
Jason