[compiler-rt] r276256 - Attempt to fix clang-cmake-mips after r268977.

[Daniel Sanders via llvm-commits]

> -----Original Message-----
> From: cbieneman at apple.com [mailto:cbieneman at apple.com] On Behalf Of
> Chris Bieneman
> Sent: 25 July 2016 22:30
> To: Daniel Sanders
> Cc: llvm-commits at lists.llvm.org; Vasileios Kalintiris
> Subject: Re: [compiler-rt] r276256 - Attempt to fix clang-cmake-mips after
> r268977.
> 
> 
> > On Jul 24, 2016, at 7:01 AM, Daniel Sanders <Daniel.Sanders at imgtec.com>
> wrote:
> >
> >>>> What I think is happening is that the 'include(builtin-config-ix)' in
> lib/builtins/CMakeLists.txt includes the
> >>>> 'set(TEST_COMPILE_ONLY On)' from cmake/builtin-config-ix.cmake
> which later causes
> >>>> CAN_TARGET_mips64 to be set according to the compiler behaviour
> rather than the compiler+linker
> >>>> behaviour. I can compile mips64 objects successfully on this machine
> but I can't link them.
> >>>
> >>> This isn't what's happening but because 'set(TEST_COMPILE_ONLY On)'
> executes slightly after the CAN_TARGET_mips64 check.
> >>>
> >>> It seems the truth of the matter is that r275780 on Monday fixed gcc
> builds by changing -mabi=n64 to -mabi=64. This didn't
> >>> take effect until Wednesday because buildbot is configured to skip the
> cmake command if build.ninja exists. On Wednesday,
> >>> we repaired the disk which eventually caused buildbot to wipe the build
> area and run the cmake command, introducing the
> >>> failures. At this point, I couldn't find anything obvious in the blamelists
> for Wednesday so I looked into it and found the
> >>> unconditional 'set(TEST_COMPILE_ONLY On)' which led me to r276256.
> >>>
> >>> To summarize, I think the unconditional 'set(TEST_COMPILE_ONLY On)'
> is probably a bug that would have a similar effect to our buildbot failure but it
> wasn't the cause of it. Sorry for the noise.
> >>
> >> This is actually intentional. It shouldn't impact the non-darwin build
> because the tests on the non-Apple branch are under
> if(COMPILER_RT_BUILTINS_STANDALONE_BUILD). In the Apple build, this
> >> allows the builtins build to include architectures that aren't included in the
> sanitizer build.
> >>
> >> -Chris
> >
> > Ah ok. Do you expect to define CAN_TARGET_${arch} both before and
> after the 'set(TEST_COMPILE_ONLY On)' or just on one side of it? If the
> answer is both then I'll need to re-work this workaround since the checks
> after the 'set(TEST_COMPILE_ONLY On)' will currently re-use the cached
> CAN_TARGET_${arch} from before it and this won't account for the updated
> TEST_COMPILE_ONLY.
> 
> Actually, looking through this more closely (now that I'm not on vacation). On
> the Darwin side CAN_TARGET_${arch} isn't used at all, we use
> CAN_TARGET_${os}_${arch} because the architecture alone isn't enough.
> That said, we do still set the CAN_TARGET_${os}_${arch} values after
> TEST_COMPILE_ONLY is set.

It sounds like my workaround is ok for this bit...

> It is expected that anything that passes the check before
> TEST_COMPILE_ONLY is set will also pass later, but there are cases where
> architectures will pass only after TEST_COMPILE_ONLY is On. In particular
> some of the embedded architectures are supported in the builtins build, but
> not the sanitizer builds.
> 
> -Chris

... but not for this bit. I've dug into llvm-lit and added a way to XFAIL the
problem tests for this buildbot. Once https://reviews.llvm.org/D22802 is
committed, I should be able to revert my workaround without breaking the
mips buildbots.