On Thu, Jun 18, 2015 at 12:24:29PM -0700, Andy Lutomirski wrote:
> Weird. Why does gcc think that an "=a" constraint on a 32-bit
> variable results in undefined high bits?
Probably precaution...
> I just compiled this:
>
> unsigned long long merge(unsigned int low, unsigned int high)
> {
> return (low) | ((unsigned long long)(high) << 32);
> }
>
> and I get this:
>
> merge:
> movq %rsi, %rax
> movl %edi, %edi
What guarantees you that the high 32-bits of %rdi, i.e. @low, are
cleared? Or is the caller required to do so? If so, I can't find that
passage in the ABI doc...
> salq $32, %rax
> orq %rdi, %rax
> ret
>
> Huh? Clang does the same thing.
>
> In fact, if I compile:
>
> extern unsigned int func(void);
>
> unsigned long long promote(void)
> {
> return func();
> }
>
> I get:
>
> promote:
> subq $8, %rsp
> call func
> addq $8, %rsp
> movl %eax, %eax
zero-extend the int?
> ret
>
> Now I'm extra confused. Do I just misunderstand the ABI, or are both
> clang and gcc missing an obvious optimization?
I don't see anything out of the ordinary but you'll tell me :)
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-x86_64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
