Re: Confirm the semantic of GCC extension "Conditionals with Omitted Operands"

["Gong, Sishuai" <sishuai@purdue.edu>]

Hello,

Thanks for the clarification! I apologize for missing your first replies. For some reason, they didn’t come to my mailbox until yours.

Thanks,
Sishuai

> On Jul 23, 2020, at 3:39 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> 
> On Thu, 23 Jul 2020 at 20:24, Gong, Sishuai via Gcc-help
> <gcc-help@gcc.gnu.org> wrote:
>> 
>> Hi,
>> 
>> I’d like to follow-up on my previous email.
>> 
>> What exactly is the semantic of the GCC extension “Conditionals with Omitted Operands”? Does it guarantee that the read operations of the first operand are only made once (which is not what happens in our experiments)? If not, is there a way to guarantee that the reads of the first operand are only made once to avoid concurrency problems (e.g., a double read that sees different results because of a write made by a concurrent thread)?
> 
> Did you read the previous replies?
> 
> To make a variable safe for concurrent access by multiple t threads
> you need to use atomic operations, and there is no atomic version of
> the ?: operator.
> 
> So you will need to do something like:
> 
> unsigned int hello(int *const *a)
> {
>    int b;
>    __atomic_load(a, &, __ATOMIC_SEQ_CST);
>    unsigned int c = b;
>    return c & 0xFE ?: 0x123;
> }
> 
> In other words, if the GCC extension doesn't provide the guarantees
> you need, do something different.