On 23.02.2026 11:04, Edwin Török wrote: > clang would duplicate the loop body and end up with a double definition > of the symbol: > ``` > /tmp/test_x86_emulator-0f3576.s:27823: Error: symbol `vmovsh_to_mem' is > already defined > /tmp/test_x86_emulator-0f3576.s:27825: Error: symbol `.Lvmovsh_to_mem_end' is > already defined > ``` > > This is a valid transformation, that even GCC might do, see > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile-1 which > says that `%=` should be used instead. However the C code here also > needs to know the name of the label, so I don't immediately see how to > solve that. > > For now mark the loop variable `volatile` to prevent the optimization as a > workaround. > (another way to fix this could be to move the loop body into a function, > but a compiler might inline it, or specialize it, leading to the same problem)
Hmm, moving decl and asm() out of the loop wouldn't really work. One option would be to extend the long-pending [1] to also cover test_x86_emulator.c. Another might be to make the upper loop bound not a literal 2, but one loaded from memory, suitably arranged for the compiler to not be able to const-propagate the value. But I wonder how many other transformations the compiler could do, causing the same issue elsewhere. Maybe we need to overhaul how this instruction instantiation works. (I further wonder how many such issues are lurking in the many patches I have out for review, plus the yet further ones I didn't post yet to not pointlessly increase the pile.) > --- a/tools/tests/x86_emulator/test_x86_emulator.c > +++ b/tools/tests/x86_emulator/test_x86_emulator.c > @@ -5248,7 +5248,7 @@ int main(int argc, char **argv) > memset(res + 3, ~0, 8); > regs.eax = (unsigned long)res; > regs.ecx = ~0; > - for ( i = 0; i < 2; ++i ) > + for (volatile int i = 0; i < 2; ++i ) Even if we went with this as a workaround, style should please not be screwed up. Also, whichever the workaround, I think a comment wants leaving. And then I don't think it is a good idea to introduce a shadowing induction variable. Jan [1] https://lists.xen.org/archives/html/xen-devel/2023-04/msg00283.html
