From owner-freebsd-current@freebsd.org Wed Jul 25 17:09:26 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 E9EA6104F7E4 for ; Wed, 25 Jul 2018 17:09:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-14.consmr.mail.bf2.yahoo.com (sonic309-14.consmr.mail.bf2.yahoo.com [74.6.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8944C8580F for ; Wed, 25 Jul 2018 17:09:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 0FhAYMcVM1lXXDL.56Q_JYeAcgFhYLTvgMyG8kCkKG4Fxj0XXVjaI4PzYA8XfCp lvakjVJk.umz77q.33b1WnIdbTbypaoepsDjEIwwW0ALGD0d8Ag7SBVkm5VwDvSJQOJgdD0gue_K 0FEmruM0kd3fucOZrO9VdAkzoSzk4pDGnerMBsPAdL3zuvloBtfSSoqJu965B4xVXuEWe.uTIGJP JDCSMFs5RjXzxkytwotuE._vXs4TaocBrLYCLO6KH24OEwrbfT3ThkLA31Ns.pqW4TijBepF8oPm WKV0IHNmjXaPZBg_M4aQrdNxMzU7pmflRM7rTtZQBhq5lUfBTnfGHzUnGDGOgutDQRRipt5YRIRw 4f8hHCzT_A0N_9Ca5tDMGSSSdIpWVrTzPyDfWJOQZ5xY97s0ak1_yo.RHe_Gad29SU4w1qZOCtXw t1WpJwYrKVUkWX7YlQH6nXKF8fGm0ll1PeeYnNSr_qKB6X8efBXtLs4AIDFhbOzJXiX9DVPENx9j .tj8dBnbvhtUwfRn0qvHwfuNo1cUVS..JB3TcQANyN8otWBESuCIezp1ObL5zms1R5tGxEJ9liUX v_XkA2FnNiDlxeHEt8HKnMOtZhvigQJz8JFgPuz.pdY5vYRpJvDUFZFG4XpKtJrVPfafYHCyo6au uHHDIwxPKA1c6LHWl7sYM.y.jmZtgM1mIQ7.kbNf3NgHvy72HcWrUpBjOkhxMVuN213MIyksUsPt DH_LsSgVvo2KvjGokZbHGJ7Mb3HYF7Nnk7GkBpKL8dcmbgtplC3H7Aamc6vn6nsR1Ui6IoI1b4iL _cdHc29spHYS6XUzE9c6wZ3NImjOKS1YxfWQMw7elngRAa6KueV2vNYGukH.RcHzJ9Hktb2jcxSb U.Ev_16CG26h.fPO.R0LgGx43CwFp_fLaaCCsr2IW3wfROR2aPsziq4BE.RifUA17kOVaaPaj6.r IdCcGwfHmqHffX0wePKECVpcVlz8aBSkDYq_lTTqs85wX1jO8M_vT61H8KL4U7vdhWdVj4Q4AWdg nSjQ- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Wed, 25 Jul 2018 17:09:18 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 71bbae85b95da5146ebb7afc44545263; Wed, 25 Jul 2018 17:09:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) 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') From: Mark Millard In-Reply-To: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> Date: Wed, 25 Jul 2018 10:09:14 -0700 Cc: Konstantin Belousov , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <788B1EE7-EFC9-4AD4-9FD1-9876D0121189@yahoo.com> References: <95fdbf29-6c11-77a6-27a3-2d0dc30f1668@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3445.9.1) 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:09:26 -0000 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: >>=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 *' 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 >>>=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 = '' > 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 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)