changes in the x86_64 version of ck_pr_store_64

[Andrew J. Schorr]

Hi,

This is probably a really stupid question. But just in case it isn't...

On x86_64, in commit f8b41af77c40751d0d89b6a394dd34d744f7f9d7, the definition
of ck_pr_store_64 changed as follows:

Previous version:

__attribute__((unused)) inline static void ck_pr_store_64(uint64_t *target, uint64_t v) { __asm__ __volatile__("movq" " %1, %0" : "=m" (*(uint64_t *)target) : "i" "q" (v) : "memory"); return; }

New version:

__attribute__((unused)) inline static void ck_pr_store_64(uint64_t *target, uint64_t v) { __asm__ __volatile__("movq" " %1, %0" : "=m" (*(uint64_t *)target) : "Z" "q" (v) : "memory"); return; }

In other words, the "i" constraint was replaced with "Z". In the gcc manual,
it appears to describe the "Z" constraint for x86 systems like so:

'Z'
32-bit unsigned integer constant, or a symbolic reference
known to fit that range (for immediate operands in
zero-extending x86-64 instructions).

Is this problematic since the actual argument here is a 64-bit unsigned
integer, not 32-bit? I'm guessing it does no harm, but just wanted to confirm.

Thanks,
Andy

[Samy Bahra]

> On Feb 18, 2015, at 10:42 AM, Andrew J. Schorr <asc...@telemetry-investments.com> wrote:
>
> Hi,
>

> This is probably a really stupid question. But just in case it isn't…

Never. The keen eye on commits is appreciated.

Correct. Compiler will fall back to the alternative constraint if 32-bit immediate is not possible.

>
> Thanks,
> Andy
>
> --
> You received this message because you are subscribed to the Google Groups "Concurrency Kit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to concurrencyki...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.