Date: Wed, 25 Jul 2018 10:53:27 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Mark Millard <marklmi@yahoo.com> 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: <7c4e995d-ec64-030a-ed84-7a211166b993@FreeBSD.org> In-Reply-To: <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> References: <AED126D8-AFB9-4BF6-81AF-A3CE5F16D2AB@yahoo.com> <EDDB87CC-3CC6-4A71-AF6D-B193F26BB692@yahoo.com> <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7c4e995d-ec64-030a-ed84-7a211166b993>