Date: Wed, 25 Jul 2018 10:09:14 -0700 From: Mark Millard <marklmi@yahoo.com> To: John Baldwin <jhb@freebsd.org> Cc: Konstantin Belousov <kib@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: 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') Message-ID: <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> In-Reply-To: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> References: <AED126D8-AFB9-4BF6-81AF-A3CE5F16D2AB@yahoo.com> <EDDB87CC-3CC6-4A71-AF6D-B193F26BB692@yahoo.com> <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText >>> (head -r336573 after the prior 6596's -r336565 ): >>>=20 >>> --- 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 >>>=20 >>>=20 >>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( = for >>> -r336700 ) still shows this type of error. >>=20 >>=20 >> [I should have a subject with "head -r336568 through -r336570 . . = .".] >>=20 >> =46rom what I can tell looking around having something like: >>=20 >> if (atomic_fetch_add(&lock->cnt, 1) > 0) >>=20 >> involve a __atomic_fetch_add indicates that: >>=20 >> = /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h >>=20 >> was in use instead of FreeBSD's stdatomic.h file. >>=20 >> 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 . >>=20 >> (I reverted -r335782 in my environment some time ago and have >> not run into this problem in my context so far.) >=20 > 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). >=20 > 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). =46rom 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.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?788B1EE7-EFC9-4AD4-9FD1-9876D0121189>