Triple-related failures on clang-i686-xp-msvc9

Hi,

A bunch of clang tests are failing on Windows with:

error: unable to create target: 'No available targets are compatible with this triple, see -version for the available targets.'

http://google1.osuosl.org:8011/builders/clang-i686-xp-msvc9

Could someone take a look, please?

The error was sneaked in while sabre was blinding the bots with the asm.c failure, so nastygrams were not sent.

/jakob

This is me. We can no longer -emit-llvm for a Clang target without having built the corresponding LLVM target, and apparently that buildbot disables all targets except X86.

I don't think this is an unreasonable restriction, but I don't know why the buildbot disables all the non-x86 targets. I'll just xfail those tests on win32 until ddunbar weighs in.

John.

The real problem is that Clang should not be required to build with ARM support in order for its tests to pass. For the tests that are target specific, they should not run at all if Clang has not been built to support that target.

Unless we can support this mode in the test suite now, I think this change should be reverted.

Thanks, John.

Is that behaviour default for Windows, or is it specific to that bot? Otherwise your xfail will just become an xpass somewhere else.

/jakob

I saw these test fail on my own machine when I had not configured my LLVM build to build ARM. Anyone doing 'configure --enable-targets=host-only' (where the host is not ARM) will see these tests fail.

You're right; I'll revert both of these changes.

John.

I saw these test fail on my own machine when I had not configured my LLVM build to build ARM. Anyone doing 'configure --enable-targets=host-only' (where the host is not ARM) will see these tests fail.

Ouch.

LLVM's dg.exp files sometimes contain stuff like:

if { [llvm_supports_target Blackfin] } {
  RunLLVMTests [lsort [glob -nocomplain $srcdir/$subdir/*.{ll,c,cpp}]]
}

Maybe clang could do something similar?

We possibly could support something like this, but there is value to supporting --emit-llvm even if the target backend isn't built. Currently all the Clang tests run on all platforms, which is nice for catching accidental breakage. When hacking on Clang, I personally don't build all the targets most of the time because it just slows me down.

LLVM is trying to move target-specific intrinsics from the shared headers to the target libs. So far it has only been done for Blackfin and MicroBlaze. The intrinsics are not yet hooked up to builtins in clang, and we would like to do that through the TargetIntrinsicInfo interface.

If some builtins are defined by the target, it is probably not feasible to support -emit-llvm without the target present.

/jakob

That makes plenty of sense. I'm fine about the --emit-llvm tests being dependent on what backend targets were built since that gives us a nice tradeoff in software modularity. Ultimately we have the buildbots to tell us when we break things even if we don't build all the targets during our own development.

I know why buildbot doesn't support no X86 architectures, its not the
problem of buildbot, its the confguration of cmakelists.txt in llvm
root directory.

A bunch of clang tests are failing on Windows with:

error: unable to create target: 'No available targets are compatible with this triple, see -version for the available targets.'

http://google1.osuosl.org:8011/builders/clang-i686-xp-msvc9

Could someone take a look, please?

The error was sneaked in while sabre was blinding the bots with the asm.c failure, so nastygrams were not sent.

This is me. We can no longer -emit-llvm for a Clang target without having built the corresponding LLVM target, and apparently that buildbot disables all targets except X86.

The buildbot only builds X86 because its a slow machine.

- Daniel

Okay. That seems like a good reason, and Ted is right anyway, we need to support clients who don't enable all targets.

I think we should probably continue (*) to require the x86-32/64 target in order to run the test suite: it's good to have a standard target, it guarantees that we're testing codegen at two different pointer widths, most codegen tests are written against it, and the vast majority of developers will be running on it anyway. So if we can agree on how to conditionalize tests based on targets, then I'll add the appropriate conditions to the (7 or so) tests that break on optional-targets builds, then reintroduce the target dependency from r97693.

John.

(*) There are currently several codegen tests which test assembly output. That's probably unfortunate, but it does mean that the test suite already depends on the existence of the x86 target.