Skip site navigation (1)Skip section navigation (2)
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>