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/25/18 10:09 AM, Mark Millard wrote:
> 
> 
> On 2018-Jul-25, at 8:39 AM, John Baldwin <jhb at freebsd.org> wrote:
> 
>> 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.
> 
> I did misread the headers. FreeBSD has the likes of:
> 
> #if defined(__CLANG_ATOMICS)
> . . .
> #define	atomic_fetch_add_explicit(object, operand, order)		\
> 	__c11_atomic_fetch_add(object, operand, order)
> . . .
> #elif defined(__GNUC_ATOMICS)
> . . .
> #define	atomic_fetch_add_explicit(object, operand, order)		\
> 	__atomic_fetch_add(&(object)->__val, operand, order)
> . . .
> #endif
> . . .
> #define	atomic_fetch_add(object, operand)				\
> 	atomic_fetch_add_explicit(object, operand, memory_order_seq_cst)
> 
> so __atomic_fetch_add would occur.
> 
> But so far I do not see the problem with -r335782 reverted. I last built
> -r336693 last night via devel/amd64-gcc (via xtoolchain).
> 
> From what I can tell FreeBSD defines:
> 
> #if !defined(__CLANG_ATOMICS)
> #define	_Atomic(T)			struct { volatile T __val; }
> #endif

This looks wrong for modern GCC supporting C11 atomics.  What is happening is
that this is probably overriding the compiler's builtin _Atomic and then the
compiler's stdatomic.h which doesn't look for __val but expects 'object' to
be a plain int is then failing to compile.  Just including sys/cdefs.h in
my test program doesn't trigger the failure though.

-- 
John Baldwin