[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Ping#2: [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself
On 21/11/17 13:26, Jan Beulich wrote: >>>> On 06.11.17 at 16:04, <george.dunlap@xxxxxxxxxx> wrote: >> On 11/06/2017 11:59 AM, Jan Beulich wrote: >>>>>> On 16.10.17 at 14:42, wrote: >>>>>>> On 16.10.17 at 14:37, <andrew.cooper3@xxxxxxxxxx> wrote: >>>>> On 16/10/17 13:32, Jan Beulich wrote: >>>>>> Since the emulator acts on the live hardware registers, we need to >>>>>> prevent the compiler from using them e.g. for inlined memcpy() / >>>>>> memset() (as gcc7 does). We can't, however, set this from the command >>>>>> line, as otherwise the 64-bit build would face issues with functions >>>>>> returning floating point values and being declared in standard headers. >>>>>> >>>>>> As the pragma isn't available prior to gcc6, we need to invoke it >>>>>> conditionally. Luckily up to gcc6 we haven't seen generated code access >>>>>> SIMD registers beyond what our asm()s do. >>>>>> >>>>>> Reported-by: George Dunlap <george.dunlap@xxxxxxxxxx> >>>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> >>>>>> --- >>>>>> While this doesn't affect core functionality, I think it would still be >>>>>> nice for it to be allowed in for 4.10. >>>>> Agreed. >>>>> >>>>> Has this been tested with Clang? >>>> Sorry, no - still haven't got around to set up a suitable Clang >>>> locally. >>>> >>>>> It stands a good chance of being >>>>> compatible, but we may need an && !defined(__clang__) included. >>>> Should non-gcc silently ignore "#pragma GCC ..." it doesn't >>>> recognize, or not define __GNUC__ in the first place if it isn't >>>> sufficiently compatible? I.e. if anything I'd expect we need >>>> "#elif defined(__clang__)" to achieve the same for Clang by >>>> some different pragma (if such exists). >>> Not having received any reply so far, I'm wondering whether >>> being able to build the test harness with clang is more >>> important than for it to work correctly when built with gcc. I >>> can't predict when I would get around to set up a suitable >>> clang on my dev systems. >> I agree with the argument you make above. On the unlikely chance >> there's a problem Travis should catch it, and someone who actually has a >> clang setup can help sort it out. > I'm still lacking an ack, before it being sensible to check with Julien > whether this is still fine to go in at this late stage. Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |