Re: Ping: [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

[Julien Grall <julien.grall@linaro.org>]

Hi,

On 11/06/2017 03:04 PM, George Dunlap 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@citrix.com> 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@citrix.com>
>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>> ---
>>>>> 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 am not entirely sure whether this count for a ack or not?

I was waiting an Acked-by/Reviewed-by before consider the Release-Acked-by.

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel