From nobody Wed Jul 13 05:06:10 2022 X-Original-To: toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 16B7A1CFBB6A for ; Wed, 13 Jul 2022 05:06:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LjQZB5d3hz49lH for ; Wed, 13 Jul 2022 05:06:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4LjQZB4WjNz19hC for ; Wed, 13 Jul 2022 05:06:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 26D56A6D041874 for ; Wed, 13 Jul 2022 05:06:10 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 26D56AXA041873 for toolchain@FreeBSD.org; Wed, 13 Jul 2022 05:06:10 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 265181] Clang doesn't properly report the C++ error when float is used as an argument in bit-wise operators (only on armv6 some error is reported instead of reporting it on all architectures) Date: Wed, 13 Jul 2022 05:06:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1657688770; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rwUPI986b8UUr6EEhPgDfrbFb6IB3nhz6CjeogStnRI=; b=Vg9jxlO+KnNp9WdeY3GTQIKPE30rh4ktFIw4clmMc5efj5cJRoO3lY0btE37SGS0loRiMw 3VG6J/P30nXfHxEnLshQEoRY7jNr7W899w98SwFlRHMpd+eIgUSeLQ52Ssa3DIAnymdBqB AN3YEcmRhji6ZsfrvIScP2ZZxjGVoBngKr9bg6sT1gzyE0I/7p6rNikCBK8wz9372RS17h Y4DZs13mI7bsnfvTTl9RLbLbrmZMrA+htXU4NA5EldJ3Ztob3UEWU4HRCRG9LkqVBbAzEf Klb1wHJYCvXWqlg6VjXQjyZsvDlDCQXMW/nZMtD5Yf7jd7jdWS8KEtO+LF4dNQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657688770; a=rsa-sha256; cv=none; b=O+fpgo+fQRH2QWZ3Cc/F8K5UWKA6Om8RTuGs0u1LqFyk4J6p4VTk1t5hii2tmPS7OVoyHH zN7mZN1qbHzDd8sB8KS16nnSWTX5gpiN6tWUIyOEJHLmiIUeiEZx6KeDIdmAUsJ3KKcnrG HS2lMT57sRGK0NsKLKDWPOBNANcQqcktG8WGqDX4WQRIDzPtPOviyqsIVCzInzCW7aa3zo QbezoBRvacaoG/yerq7BS0mnXv34r37vPtye8uOWEO5gQISPbQg0pBxU4GvVt2Ys59EL0b Q0YhXz4dTJjC6KrraLJQFTRaP7HyPUU2NjiAwF+nKhe7MeJ2CKvmEsRPwfZd5A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265181 --- Comment #6 from Mark Millard --- (In reply to Yuri Victorovich from comment #4) clang is not what supplied bswap_32 : /usr/include/infiniband/byteswap.h provides: #define bswap_32 bswap32 (I switch to /usr/src/ style paths starting here.) /usr/13_0R-src/sys/sys/endian.h provides: #define bswap32(x) __bswap32(x) You are welcome to go explore the range architecture specific definitions in: (The space then tab sequence in the []'s below likely will not make it through the copy/paste sequence.) # grep -r "define[ ]*\<__bswap32\>" /usr/13_0R-src/sys/ | more /usr/13_0R-src/sys/arm64/include/endian.h:#define __bswap32(x) \ /usr/13_0R-src/sys/arm64/include/endian.h:#define __bswap32(x)=20=20= =20 __bswap32_var(x) /usr/13_0R-src/sys/arm/include/endian.h:#define __bswap32(x) \ /usr/13_0R-src/sys/arm/include/endian.h:#define __bswap32(x)=20=20=20 __bswap32_var(x) /usr/13_0R-src/sys/x86/include/endian.h:#define __bswap32(x)=20=20=20 __builtin_bswap32(x) /usr/13_0R-src/sys/riscv/include/endian.h:#define __bswap32(x) \ /usr/13_0R-src/sys/riscv/include/endian.h:#define __bswap32(x)=20=20= =20 __bswap32_var(x) /usr/13_0R-src/sys/mips/include/endian.h:#define __bswap32(x)=20=20= =20 ((__uint32_t)(__is_constant((x)) ? \ /usr/13_0R-src/sys/powerpc/include/endian.h:#define __bswap32(x)=20=20= =20 (__is_constant(x) ? __bswap32_const(x) : \ But even with just that much of a grep, note the x86 using: __builtin_bswap32(x) which is not going to have any binary operators involved at all. Such is not clang's problem for why that is different. I'll note that FreeBSD's arm/include/endian.h definitions are far from uniform for type handling: static __inline __uint32_t __bswap32_var(__uint32_t v) { __uint32_t t1; __asm __volatile("eor %1, %0, %0, ror #16\n" "bic %1, %1, #0x00ff0000\n" "mov %0, %0, ror #8\n" "eor %0, %0, %1, lsr #8\n" : "+r" (v), "=3Dr" (t1)); return (v); } . . . #ifdef __OPTIMIZE__ #define __bswap32_constant(x) \ ((((x) & 0xff000000U) >> 24) | \ (((x) & 0x00ff0000U) >> 8) | \ (((x) & 0x0000ff00U) << 8) | \ (((x) & 0x000000ffU) << 24)) . . . #define __bswap32(x) \ ((__uint32_t)(__builtin_constant_p(x) ? \ __bswap32_constant(x) : \ __bswap32_var(x))) #else #define __bswap16(x) __bswap16_var(x) #define __bswap32(x) __bswap32_var(x) #endif /* __OPTIMIZE__ */ __bswap32_var will not produce such binary operator related messages. But, for __OPTIMIZE__, __bswap32_constant usage will. So the __bswap32(x) usage will vary based on constant expressions vs. non-constant expressions. Again: Not clang++'s problem since it is not clang's set of definitions. clang++ is doing what it is told to by the language standard and code it was supplied. --=20 You are receiving this mail because: You are the assignee for the bug.=