Date: Sat, 20 Jul 2019 21:28:41 +0000 From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 239266] lang/gcc8 fails to build with clang8: tree-vect-loop.c:4979:12: error: expected unqualified-id Message-ID: <bug-239266-25139-CLEGPbHirs@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-239266-25139@https.bugs.freebsd.org/bugzilla/> References: <bug-239266-25139@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239266 --- Comment #12 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Gerald Pfeifer from comment #11) vec_step is from OpenCL (which did not respect compiler-specific namespace rules for C/C++): QUOTE The vec_step built-in function takes a built-in scalar or vector data type argument and returns an integer value representing the number of elements in the scalar or vector. For all scalar types, vec_step returns 1. The vec_step built-in functions that take a 3- component vector return 4. vec_step may also take a pure type as an argument, e.g. vec_step(float2) END QUOTE That is from: The OpenCL Specification Version: 1.2 which is from 2012-Nov. But I've seen references to version OpenCL V1.1 also having it --so vec_step is even olderin its originating standard. If I remember right, the clang implementation goes back to 2011. Thus: it is the classic problem when something wrong is done and stays in place for years (relative to C/C++): how much code would be invalidated and have to change if clang changed vec_step's spelling to be in a compiler namespace (or did something else incompatible to change things)? And what of OpenCL compatbility? Are GCC folks willing to avoid identifier names that OpenCL reserves and are shown to be a problem, so that compilers can reserve them, such as for OpenCL built-ins like here? --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-239266-25139-CLEGPbHirs>