Date: Tue, 5 Dec 2017 20:46:31 -0800 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, FreeBSD Ports <freebsd-ports@freebsd.org> Cc: Gerald Pfeifer <gerald@FreeBSD.org> Subject: powerpc64 & system-clang vs. building the likes of lang/gcc7 (at least): vec_step name pollution causes compile failures, should gcc7 source code avoid the name? Message-ID: <D179C66E-5631-40F0-B035-A442640E573A@dsl-only.net>
next in thread | raw e-mail | index | archive | help
[I experiment with clang-based worlds and kernels
on powerpc64 and powerpc. But I'm not sure that
such is the only type of context is required to
see the below problem.]
Attempting to build lang/gcc7 on a system-clang based
powerpc64 (world and kernel) gets:
=
/wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3835:27: =
error: expected unqualified-id
tree new_vec, vec_init, vec_step, t;
^
=
/wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3835:26: =
error: expected ';' at end of declaration
tree new_vec, vec_init, vec_step, t;
^
;
Well, it turns out that vec_step has the following
potential naming conflicts, one for powerpc64 FreeBSD
specifics, and one for clang specifics (for support of
OpenCL). . .
For powerpc64:
/usr/src/contrib/gcc/config/rs6000/altivec.h:#define vec_step(x) =
__builtin_vec_step (* (__typeof__ (x) *) 0)
(I'm point the above out despite my clang-based context.)
For clang:
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp:/// vec_step =
and we are at the start of an expression or a parenthesized
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp:/// [OpenCL =
1.1 6.11.12] vec_step built-in function:
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp:/// =
vec_step ( expressions )
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp:/// =
vec_step ( type-name )
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp: "Not =
a typeof/sizeof/alignof/vec_step expression!");
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp: "Not =
a sizeof/alignof/vec_step expression!");
/usr/src/contrib/llvm/tools/clang/lib/Sema/SemaExpr.cpp: // [OpenCL 1.1 =
6.11.12] "The vec_step built-in function takes a built-in
/usr/src/contrib/llvm/tools/clang/lib/Sema/TreeTransform.h: /// \brief =
Build a new sizeof, alignof or vec_step expression with a
/usr/src/contrib/llvm/tools/clang/include/clang/AST/Expr.h:/// vec_step =
(OpenCL 1.1 6.11.12).
=
/usr/src/contrib/llvm/tools/clang/include/clang/ASTMatchers/ASTMatchers.h:=
/// \brief Matches sizeof (C99), alignof (C++11) and vec_step (OpenCL)
=
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.=
td: "invalid application of '%select{sizeof|alignof|vec_step}0' to a "
=
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.=
td: "invalid application of '%select{sizeof|alignof|vec_step}0' to a =
void "
=
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.=
td: "invalid application of =
'%select{sizeof|alignof|vec_step|__builtin_omp_required_simd_align}0' to =
a void type">;
=
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.=
td: "invalid application of =
'%select{sizeof|alignof|vec_step|__builtin_omp_required_simd_align}0' to =
an "
=
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.=
td: "invalid application of =
'%select{sizeof|alignof|vec_step|__builtin_omp_required_simd_align}0' to =
a "
=
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.=
td: "'vec_step' requires built-in scalar or vector type, %0 invalid">;
=
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/TokenKinds.def:KEYWO=
RD(vec_step , KEYOPENCL|KEYALTIVEC|KEYZVECTOR)
(The lists were extracted from a: grep -r "\<vec_step\>" /usr/src/*
Some material was omitted from the reported matches.)
Given the clang extension for having vec_step for OpenCL,
it might be best if lang/gcc7 was updated to avoid the
name (upstream as well). devel/llvm50 likely has the
same vec_step as system-clang. I'm not sure about
devel/llvm40 .
This might be true of some other lang/gcc*'s: I just
happen to build lang/gcc7 but not the others (generally).
Context details:
# uname -apKU
FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT r326192M powerpc =
powerpc64 1200054 1200054
# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 455204
Last Changed Rev: 455204
(Last before FLAVORS is enabled.)
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D179C66E-5631-40F0-B035-A442640E573A>