From owner-freebsd-current@freebsd.org Wed Jul 25 15:40:03 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5326A104DFAA for ; Wed, 25 Jul 2018 15:40:03 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EC10C82AC7; Wed, 25 Jul 2018 15:40:02 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 65AB910AFD2; Wed, 25 Jul 2018 11:39:55 -0400 (EDT) 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 *' is incompatible with argument 1 of '__atomic_fetch_add') To: Mark Millard , Konstantin Belousov , FreeBSD Current References: From: John Baldwin Message-ID: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> Date: Wed, 25 Jul 2018 08:39:53 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 25 Jul 2018 11:39:55 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 15:40:03 -0000 On 7/24/18 11:39 PM, Mark Millard wrote: > On 2018-Jul-24, at 10:32 PM, Mark Millard 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 *' 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 *' 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 '' which is correct for the kernel but not for userland. -- John Baldwin