[Bug gcov-profile/97594] [11 Regression] new test case gcc.dg/tree-prof/pr97461.c execution failure

["linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97594

--- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---


(In reply to Martin Liška from comment #2)
> (In reply to Martin Liška from comment #1)
> > Mine, I see a strange error:
> > 
> > $ Program received signal SIGBUS, Bus error.
> > 0x00003fffb7ceddbc in __GI__IO_link_in () from /lib64/libc.so.6
> > Missing separate debuginfos, use: debuginfo-install
> > glibc-2.17-307.el7.1.ppc64le
> > (gdb) bt
> > #0  0x00003fffb7ceddbc in __GI__IO_link_in () from /lib64/libc.so.6
> > #1  0x00003fffb7cebe58 in _IO_new_file_init_internal () from /lib64/libc.so.6
> 
> All right, so the test-case overloads malloc and returns a memory that is a
> static buffer. For some reason, it leads to SEGBUS.
> Do Power people know what's causing that?

I was testing the patch for PR97705 and met this issue during regression
testing, happened to notice this PR and just realized this one is also a random
issue. (how lucky I am :-))

Checked the assembly insn causing the SEGBUS

   0x00007ffff7cc6940 <+240>:   beq     0x7ffff7cc6b30 <__GI__IO_link_in+736>
   0x00007ffff7cc6944 <+244>:   li      r9,1
   0x00007ffff7cc6948 <+248>:   clrldi  r10,r10,32
=> 0x00007ffff7cc694c <+252>:   lwarx   r8,0,r3
   0x00007ffff7cc6950 <+256>:   subf.   r8,r10,r8

r3             0x100207e6          268568550

As Power ISA pointed out, the EA for lwarx must be a multiple of 4. "If it is
not, either the system alignment error handler is invoked or the results are
boundedly undefined."

So the code of function __GI__IO_link_in has already assumed the address there
would have one reasonable alignment.

By checking the manual of malloc/calloc, it says:

   RETURN VALUE
     The malloc() and calloc() functions return a pointer to the 
     allocated memory, which is  suitably  aligned  for any built-in
     type.  On error, these functions return NULL.  NULL may also be
     returned by a successful call to malloc() with a size of zero,
     or by a successful call to calloc() with nmemb or size equal to
     zero.

I think the assumption there is reasonable, the addresses returned from
user-overloaded malloc/calloc should also take care of this alignment
requirement and adjust the return address respecting this.

The below small patch can get the case to pass.

$ diff ~/gcc/gcc-git/gcc/testsuite/gcc.dg/tree-prof/pr97461.c pr97461.c
20a21,26
> /* The malloc() and calloc() functions return a pointer to the allocated
>    memory, which is suitably aligned for any built-in type.  Use 16
>    bytes here as the basic alignment requirement for user-defined malloc
>    and calloc.  See PR97594 for the details.  */
> #define ROUND_UP_FOR_16B_ALIGNMENT(x) ((x + 15) & (-16))
>
23c29
<     memory_p += size;
---
>     memory_p += ROUND_UP_FOR_16B_ALIGNMENT (size);