From owner-freebsd-current@freebsd.org Wed Jul 25 17:53:30 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 3D7B71050C59 for ; Wed, 25 Jul 2018 17:53:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (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 B355C873DE; Wed, 25 Jul 2018 17:53:29 +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 7679710AFD2; Wed, 25 Jul 2018 13:53:28 -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 References: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> Cc: Konstantin Belousov , FreeBSD Current From: John Baldwin Message-ID: <7c4e995d-ec64-030a-ed84-7a211166b993@FreeBSD.org> Date: Wed, 25 Jul 2018 10:53:27 -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: <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> 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 13:53:28 -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 17:53:30 -0000 On 7/25/18 10:09 AM, Mark Millard wrote: > > > On 2018-Jul-25, at 8:39 AM, John Baldwin wrote: > >> 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. > > 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