Gerald Pfeifer <gerald_at_FreeBSD.org> wrote on
Date: Wed, 02 Jul 2025 22:52:19 UTC :
> 
> The branch main has been updated by gerald:
> 
> URL: 
> https://cgit.FreeBSD.org/ports/commit/?id=8e54722e2a4f50b3b494c6742d5ec96880dff472
> 
> commit 8e54722e2a4f50b3b494c6742d5ec96880dff472
> Author: Gerald Pfeifer <[email protected]>
> AuthorDate: 2025-07-02 20:10:00 +0000
> Commit: Gerald Pfeifer <[email protected]>
> CommitDate: 2025-07-02 22:52:07 +0000
> 
> lang/gcc14-devel: Drop files/patch-clang-vec_step
> 
> This patch never appeared in lang/gcc14, which was created for
> GCC 14.1 more than a year ago, nor do GCC 15 based ports carry it.

[It is unfortunately difficult to get detailed powerpc* family
port-package build-log information: https://pkg-status.freebsd.org
does not expose the powerpc* builder information. This limits
what I can know and report below. May be if I knew server names
I could just manually create URLs that would find things?]

I remind that the original problem was powerpc* family specific,
with altivec being enabled being sufficient to reach the problem.

Note: gcc had committed a work around specifically to the gcc13
branch, requiring llvm to be fixed long term. lang/gcc13-devel
and lang/13 have a mixed record for the powerpc* family members
as shown by freshports at this point. [I focus on gcc14+ below.]

But freshports shows no asuccessful powerpc* family builds of
lang/gcc1[45] at all, and only one very old example for
lang/gcc14-devel :

https://www.freshports.org/lang/gcc14-devel/
(just 14.0.0.s20231231 from 2024-02-25 and only for powerpc64le)

None for any powerpc* for the below:
https://www.freshports.org/lang/gcc15-devel/
https://www.freshports.org/lang/gcc14/
https://www.freshports.org/lang/gcc15/
https://www.freshports.org/lang/gcc16-devel/

My guess here is that something else is blocking the builds --but
if that was fixed, this problem could become visible again: I
see no evidence of an llvm fix of the basic problem.

Not that I can know for sure as things are, but looking in
contrib on a main [so: 15] system shows use of the keyword(?):

case tok::kw_vec_step:

# grep -r "\<vec_step\>" /usr/src/contrib/llvm-project/ | grep -v -e "\.cpp: 
*//" -e "\.h: *//"
/usr/src/contrib/llvm-project/llvm/lib/Target/AMDGPU/AMDGPULibFunc.cpp:{ 
"vec_step"                        , {1},   {E_ANY}},
/usr/src/contrib/llvm-project/clang/lib/AST/ItaniumMangle.cpp:                  
                   "cannot yet mangle vec_step expression");
/usr/src/contrib/llvm-project/clang/lib/Headers/opencl-c.h: * by 
vec_step(gentypem). The shuffle mask operand
/usr/src/contrib/llvm-project/clang/lib/Parse/ParseExpr.cpp:  case 
tok::kw_vec_step:   // unary-expression: OpenCL 'vec_step' expression
/usr/src/contrib/llvm-project/clang/lib/Parse/ParseExpr.cpp:         "Not a 
typeof/sizeof/alignof/vec_step expression!");
/usr/src/contrib/llvm-project/clang/lib/Parse/ParseExpr.cpp:         "Not a 
sizeof/alignof/vec_step expression!");
/usr/src/contrib/llvm-project/clang/include/clang/Basic/DiagnosticSemaKinds.td: 
 "'vec_step' requires built-in scalar or vector type, %0 invalid">;
/usr/src/contrib/llvm-project/clang/include/clang/Basic/TokenKinds.def:UNARY_EXPR_OR_TYPE_TRAIT(vec_step,
 VecStep, KEYOPENCLC | KEYOPENCLCXX | KEYALTIVEC | KEYZVECTOR)


(I still do not have powerpc system access and am unlikely to
ever have such again.)

> Approved by: salvadore (maintainer)
> ---
> lang/gcc14-devel/files/patch-clang-vec_step | 21 ---------------------
> 1 file changed, 21 deletions(-)
> 
> diff --git a/lang/gcc14-devel/files/patch-clang-vec_step 
> b/lang/gcc14-devel/files/patch-clang-vec_step
> deleted file mode 100644
> index 00607540eb2a..000000000000
> --- a/lang/gcc14-devel/files/patch-clang-vec_step
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239266 reports how
> -clang unfortunately poisons user namespace by default (without any
> -special options).
> -
> -Until that changes (or GCC changes) we need to avoid using vec_step
> -as a variable.
> -
> ---- UTC
> -Index: gcc/tree-vect-loop.cc
> -===================================================================
> ---- gcc/tree-vect-loop.cc (revision 273856)
> -+++ gcc/tree-vect-loop.cc (working copy)
> -@@ -55,6 +55,8 @@ along with GCC; see the file COPYING3. If not see
> - #include "vec-perm-indices.h"
> - #include "tree-eh.h"
> - 
> -+#define vec_step vec_step_
> -+
> - /* Loop Vectorization Pass.
> - 
> - This pass tries to vectorize loops.

===
Mark Millard
marklmi at yahoo.com


Reply via email to