The only thing I can think of that can happen, is that calculating the
effective triple will then change it and possibly the default CPU (it can
happen).
But since that code is a mess anyway, I don't think anyone can know beforehand.
I'm happy to trust the tests, and if passing, feel free to commit.
We can catch the rest of the errors via buildbots or broken builds.
cheers,
--renato
================
Comment at: lib/Driver/Tools.cpp:7401
@@ -7400,3 +7400,3 @@
case llvm::Triple::thumbeb: {
const llvm::Triple &Triple = getToolChain().getTriple();
switch (Triple.getSubArch()) {
----------------
dschuff wrote:
> jvoung wrote:
> > Should this just set Triple =
> > llvm::Triple(getToolChain().ComputeEffectiveClangTriple(Args)); here?
> >
> > In case other stuff in this case statement depends on the triple later.
> That causes -mfpu=neon to be added to the linux build as well as NaCl (that
> causes the linux-as.c test to fail, which uses cortex-a8 as the cpu but does
> not expect -mfpu=neon). IIUC it should be ok to have -mfpu=neon (for both
> linux and nacl) because we always default to .fpu neon in the asm file when
> targeting cortex-a8. But that seems to mean that the assembler doesn't even
> care (at least for linux and nacl) whether it gets -mfpu=neon or not. I don't
> really understand why it should care anyway.
Triple management in the Clang driver is composed of random non-abelian
transformations. Don't try to understand it. :)
http://reviews.llvm.org/D8902
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
