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

[email protected]
Newsgroups gmane.os.freebsd.devel.ppc
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225629

--- Comment #24 from Mark Millard <[email protected]> ---
(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 the assignee for the bug.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.