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"?
