[Bug middle-end/108498] ppc64 big endian generates uninitialized reads with -fstore-merging
kungfujesus06 at gmail dot com
gcc-bugzilla@gcc.gnu.org
Mon Jan 23 17:42:36 GMT 2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498
--- Comment #11 from Adam Stylinski <kungfujesus06 at gmail dot com> ---
(In reply to Andrew Pinski from comment #9)
> The only thing is memcpy could be broken ...
>
> I can't find anything wrong with the generated code.
>
>
> 100007cc: 38 a0 00 44 li r5,68
> ...
> 100007d8: 3c 00 02 00 lis r0,512
> 100007dc: 60 00 ff 03 ori r0,r0,65283
> 100007e0: 78 00 07 c6 sldi r0,r0,32
> 100007e4: 64 00 00 01 oris r0,r0,1
> 100007e8: 60 00 02 03 ori r0,r0,515
> ...
> 100007fc: 38 81 00 74 addi r4,r1,116
> ...
> 1000080c: 7c 7f 1b 78 mr r31,r3
> ...
> 10000818: f8 01 00 74 std r0,116(r1)
> ...
> 1000082c: 4b ff fd 15 bl 10000540
> <0000003b.plt_call.memcpy@@GLIBC_2.3>
> ...
>
>
>
>
>
> On the main side:
> addi %r3,%r1,116
> ld %r9,-28688(%r13)
> std %r9,184(%r1)
> li %r9,0
> bl emit_test
> lwz %r4,124(%r1)
It's possible's a glibc bug and clang avoids it by simply not needing it but it
seems doubtful a small memcpy like this would have an issue that didn't show up
until now. It seems like if it did need a memcpy, GCC would invoke it's
builtin for a struct like like this rather than call into a library function.
Is there a compilation flag I can invoke to rule that out? Like some sort of
"only builtins"?
More information about the Gcc-bugs
mailing list