Date: Sun, 22 Jul 2018 18:54:03 +0000 From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 225629] powerpc64 (POWER9) segfaults randomly (e.g., building lang/gcc5) Message-ID: <bug-225629-25139-IJLbaArMA1@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-225629-25139@https.bugs.freebsd.org/bugzilla/> References: <bug-225629-25139@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225629 --- Comment #24 from Mark Millard <marklmi26-fbsd@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+=3D -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. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-225629-25139-IJLbaArMA1>