On Tue, 4 Dec 2018 at 05:15, Nick Desaulniers <ndesaulni...@google.com> wrote: > > > > +ifdef CONFIG_CC_IS_CLANG > > > > +# clang ppc port does not yet support -maltivec when -msoft-float is > > > > +# enabled. A future release of clang will resolve this > > > > +# https://bugs.llvm.org/show_bug.cgi?id=31177 > > > > +CFLAGS_REMOVE_altivec1.o += -msoft-float > > > > +CFLAGS_REMOVE_altivec2.o += -msoft-float > > > > +CFLAGS_REMOVE_altivec4.o += -msoft-float > > > > +CFLAGS_REMOVE_altivec8.o += -msoft-float > > > > +CFLAGS_REMOVE_altivec8.o += -msoft-float > > > > +CFLAGS_REMOVE_vpermxor1.o += -msoft-float > > > > +CFLAGS_REMOVE_vpermxor2.o += -msoft-float > > > > +CFLAGS_REMOVE_vpermxor4.o += -msoft-float > > > > +CFLAGS_REMOVE_vpermxor8.o += -msoft-float > > > > +endif > > > > > > Hi Joel, thanks for this patch! My same thoughts about > > > CONFIG_CC_IS_CLANG vs cc-option from > > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-November/180939.html > > > apply here as well. I don't feel strongly about either though. What > > > are your thoughts? > > > > I'm not sure that we can test for this one with cc-option. The result > > of having -maltivec with -msoft-float is a error about the internals > > of clang, which isn't something that kbuild is set up to test for. > > As in clang itself crashes, and cc-option/kbuild can't handle that gracefully?
The developer gets something like this: SplitVectorResult #0: t196: v16i8 = llvm.ppc.altivec.vcmpgtsb TargetConstant:i64<4823>, t146, t195 fatal error: error in backend: Do not know how to split the result of this operator! clang-8: error: clang frontend command failed with exit code 70 (use -v to see invocation) > > > > > When clang is fixed to allow this combination we will still build this > > code in the same way, so in that sense it fails "open". > >