Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct <anonymous> *' is incompatible with argument 1 of '__atomic_fetch_add')

On 7/24/18 11:39 PM, Mark Millard wrote:
> On 2018-Jul-24, at 10:32 PM, Mark Millard <marklmi at yahoo.com> wrote:
> 
>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText
>> (head -r336573 after the prior 6596's -r336565 ):
>>
>> --- all_subdir_lib/ofed ---
>> In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0,
>>                 from /workspace/src/contrib/ofed/librdmacm/acm.c:42:
>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init':
>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid initializer
>>  atomic_store(&lock->cnt, 0);
>>  ^
>> In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0:
>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_acquire':
>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type 'struct <anonymous> *' is incompatible with argument 1 of '__atomic_fetch_add'
>>  if (atomic_fetch_add(&lock->cnt, 1) > 0)
>>  ^~
>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_release':
>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type 'struct <anonymous> *' is incompatible with argument 1 of '__atomic_fetch_sub'
>>  if (atomic_fetch_sub(&lock->cnt, 1) > 1)
>>  ^~
>> . . .
>> --- all_subdir_lib/ofed ---
>> *** [acm.o] Error code 1
>>
>>
>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for
>> -r336700 ) still shows this type of error.
> 
> 
> [I should have a subject with "head -r336568 through -r336570 . . .".]
> 
> From what I can tell looking around having something like:
> 
> if (atomic_fetch_add(&lock->cnt, 1) > 0)
> 
> involve a __atomic_fetch_add indicates that:
> 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h
> 
> was in use instead of FreeBSD's stdatomic.h file.
> 
> If this is right, then the issue may be tied to head -r335782
> implicitly changing the order of the include file directory
> searching for builds via the devel/*-gcc .
> 
> (I reverted -r335782 in my environment some time ago and have
> not run into this problem in my context so far.)

C11 atomics should work fine with compiler-provided headers since they
are a part of the language (and the system stdatomic.h simply attempts
to mimic the compiler-provided header in case it is missing).

Simple standalone tests of _Atomic(int) with GCC don't trigger those
failures when using its stdatomic.h, so there is probably something else
going on with kernel includes being used while building the library,
etc.  The last time we had this issue with stdarg.h it was because a
header shared between the kernel and userland always used '<machine/stdarg.h>'
which is correct for the kernel but not for userland.

-- 
John Baldwin