https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109326
--- Comment #3 from Steve Thompson <susurrus.of.qualia at gmail dot com> --- (In reply to Andrew Pinski from comment #1) > init_olock_op_element_struct asm output looks fine to me: > > movzwl .LC0(%rip), %eax > movq $0, (%rdi) > movq $0, 8(%rdi) > movl $0, 16(%rdi) > movw %ax, 20(%rdi) > > LC0 is: > .LC0: > .byte 6 > .byte 10 > > olock_fsm_event is fine too as it is just duplicating those basic blocks > (the calls). > > init_olock_op_struct looks fine really: > movq %fs:0, %rax > pxor %xmm0, %xmm0 > movups %xmm0, (%rdi) > addq $olock_tparams@tpoff, %rax > > In Intel asm syntax: > > mov rax, QWORD PTR fs:0 > pxor xmm0, xmm0 > movups XMMWORD PTR [rdi], xmm0 > add rax, OFFSET FLAT:olock_tparams@tpoff > > it is basically moving the TLS pointer to rax and then adding the offset for > the variable. > > I don't understand what exactly you are complaining about realy. OK, I wasn't sure about the TLS accesses; adding -r to objdump helped clear that up. However I don't understand why olock_reset_op() is so large. It's a trivial initializer for a descriptor with an array of olock_op_element structures appended. There's no way it should look like what I quoted. I'd be happy if I am experiencing a fever-dream over nothing due to ignorance, but I am not convinced that that is the case. If I am wrong I will be very disappointed.
