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 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

and that struct is being used in &(object)->__val is what the
error reports are about. So that would be, for example,

&(&lock->cnt)->__val

This would appear to suggest that __val itself had a type meeting:

operand type struct <anonymous>

for T in _Atomic(T) .

(This is independent of just what the issue traces back to: just
the net result on ci.freebsd.org . No claim that you are right
or wrong here. I'll not be looking any more until this afternoon
or night.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)