Re: [Xen-devel] clang compilation

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.08.13 at 10:17, Tim Deegan <tim@xxxxxxx> wrote:
> At 08:17 +0100 on 16 Aug (1376641071), Patrick Welche wrote:
>> On Thu, Aug 15, 2013 at 10:15:31PM +0100, Tim Deegan wrote:
>> > > > I've tested with every GCC I can lay my hands on (and clang 3.0),
>> > > > building x86 and ARM.
>> 
>> Joerg has a "clang fix" for warnings for xen/arch/x86/time.c, essentially
>> mul to mull or mulq - did you see such warnings when testing with clang?
>> 
>> 
> http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/sysutils/xenkernel42/patches/ 
> patch-xen_arch_x86_time.c
> 
> We already have one of those changes upstream:
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=59a28b5f045331641cbf 
> 0c1fc8d5d67afe328939
> 
> Jan, can that be backported as far as 4.2 as a build fix?

Sure, even more so that this is not just a build fix - the generated
code would end up being wrong if the input "delta" was put in
memory instead of a register.

> I'm not sure why I didn't trip over the mul in mul_frac() too, but
> we can probably take that if you'd like to send a patch.

And that should relax the constraint of multiplier to "rm" at once.

> The other chunk in that file is against 32-bit code, which is gone in
> 4.3 and 4.4.  I guess we might take that as a fix directly against 4.2.
> Jan, what do you think?

I'd add this as part of the backport of 59a28b5f, as logically the 64-bit
change ought to be extended to 32-bit.

Yet with all of this I wonder what kind of broken assembler they're
using - deferring the operand size from register operands should
work consistently for all instructions or none, i.e. needing explicit
suffixes on mul but not any of the other .

Jan


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