[Bug 225629] powerpc64 (POWER9) segfaults randomly (e.g., building lang/gcc5)

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sun Jul 22 18:54:07 UTC 2018


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225629

--- Comment #24 from Mark Millard <marklmi26-fbsd at yahoo.com> ---
(In reply to Gerald Pfeifer from comment #23)

The problem is with the name vec_step which has a special
use in system-clang that conflicts with gcc's tree-vect-loop.c
local use of the name: namespace pollution (via OpenCL support
requiring such and being enabled, apparently). Anything that avoids
the name conflict is a work around.

clang for "with altivec/OpenCL support included" defines the notations:
( 3 lines from llvm/tools/clang/lib/Parse/ParseExpr.cpp )

[OpenCL 1.1 6.11.12] vec_step built-in function:
vec_step ( expressions )
vec_step ( type-name )

and has error messages like (2 more lines from there):

Not a typeof/sizeof/alignof/vec_step expression!

Not a sizeof/alignof/vec_step expression!

(and examples via tools/clang/include/clang/Basic/DiagnosticSemaKinds.td )

invalid application of
'%select{sizeof|alignof|vec_step|__builtin_omp_required_simd_align}0' to an

'vec_step' requires built-in scalar or vector type, %0 invalid



As I understand, telling clang -mno-altivec avoids vec_step being
defined by clang (via lack of OpenCL support for such) and so avoids
needing to rename the local variable in gcc's tree-vect-loop.c .


As far as I can tell the gcc code should be valid but system-clang as
configured by default makes it not so. I disagree with the "bug"
aspect of "Work-around for bug in tree-vect-loop.c".

Presuming there is a reason to have OpenCL support enabled in system-
clang, I expect that the conditional:

  CFLAGS+=      -mno-altivec

is appropriate. Otherwise disabling OpenCL support in system-clang for
powerpc64 would avoid vec_step ending up as an unavailable name. (I do
not know if altivec can be enabled but still have OpenCL support disabled
via normal configuration controls for system-clang.)

-mno-altivec would not be limited to gcc6 as long as gcc happens to
use the name vec_step in its tree-vect-loop.c . I've not checked
gcc8 yet, nor have I checked gcc9-devel . gcc7 had the usage and
so suffered the issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the freebsd-ppc mailing list