Maurice Lombardi wrote:
There is a weird bug related to the optimisation in gcc. ev is filled through a macro which calls an asm routine when in 32 bits mode. It is then enqueued by an other macro which calls the same asm routine. Following the process with a debugger at the assembly level, I see that the instructions are reordered by gcc so that the enqueing is made before the filling is complete (the filling is correctly done, but afterwards). Declaring ev volatile is a hack that in principle says to gcc that ev can be modified in a way uncontrolled by gcc, so do not try to reorder the readings/writings on it. For me this solve both your problems on xkeys and demogrx. This is probably not the "right" way to do it, this volatile attribute has been imagined to solve problems when the memory is changed by an external process, not by something which seems to be on the control of gcc. I need to investigate further, and I have no practice of this stuff ...
I have little time ATM, so sorry for the late reply. At first glance, the "right" way to do it should be to declare the "asm" statement "volatile", but this seems already the case for all "asm" statements in GRX. Which asm routine is it here actually?
Frank