summaryrefslogtreecommitdiffstats
path: root/clang/test/Driver
Commit message (Collapse)AuthorAgeFilesLines
...
* [Hexagon] Fix clang driver to parse -mcpu/-mvXX and -march properly.Sumanth Gundapaneni2019-11-141-0/+13
| | | | | | Before this patch if we pass "-mcpu=hexagonv65 -march=hexagon" in this order, the driver fails to figure out the correct cpu version. This patch fixed this issue.
* [AMDGPU][HIP] Change default DWARF version to 4Scott Linder2019-11-142-1/+10
| | | | | | | | | | | | | Summary: Tooling around DWARF 5 is still not mature enough for this to be a sane default, and the AMDGPU and HIP toolchains should agree on a single default. Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, aprantl, dstuttard, tpr, t-tye, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70191
* [WebAssembly] -fwasm-exceptions enables reference-typesHeejin Ahn2019-11-131-2/+8
| | | | | | | | | | | | | | | Summary: This adds `-mreference-types` and `-mno-reference-types` flags to clang and make `-fwasm-exceptions` enables reference types feature in clang and the backend. Reviewers: tlively Subscribers: dschuff, sbc100, jgravelle-google, sunfish, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69832
* Revert "[RISCV] Use compiler-rt if no GCC installation detected"Richard Smith2019-11-136-16/+16
| | | | | | | This change causes test failures for builds configured with -DCLANG_DEFAULT_RTLIB=compiler-rt. This reverts commit 3289352e6bb9d2949c678c625478024bf2a5fbfb.
* [RISCV] Use compiler-rt if no GCC installation detectedEdward Jones2019-11-136-16/+16
| | | | | | | | If a GCC installation is not detected, then this attempts to use compiler-rt and the compiler-rt crtbegin/crtend implementations as a fallback. Differential Revision: https://reviews.llvm.org/D68407
* Add 8548 CPU definition and attributesJustin Hibbits2019-11-121-0/+12
| | | | | | | | 8548 CPU is GCC's name for the e500v2, so accept this in clang. The e500v2 doesn't support lwsync, so define __NO_LWSYNC__ for this as well, as GCC does. Differential Revision: https://reviews.llvm.org/D67787
* Don't assume that the clang binary's resolved name includes the stringRichard Smith2019-11-121-1/+1
| | | | | | 'clang'. This is not true in practice in some content-addressed file systems.
* AArch64: add arm64_32 support to Clang.Tim Northover2019-11-122-0/+7
|
* Revert cdcf58e5af0 "[RISCV] enable LTO support, pass some options to linker."Hans Wennborg2019-11-111-18/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This started passing target-features on the linker line, not just for RISCV but for all targets, leading to error messages in Chromium Android build: '+soft-float-abi' is not a recognized feature for this target (ignoring feature) '+soft-float-abi' is not a recognized feature for this target (ignoring feature) See Phabricator review for details. Reverting until this can be fixed properly. > Summary: > 1. enable LTO need to pass target feature and abi to LTO code generation > RISCV backend need the target feature to decide which extension used in > code generation. > 2. move getTargetFeatures to CommonArgs.h and add ForLTOPlugin flag > 3. add general tools::getTargetABI in CommonArgs.h because different target uses different > way to get the target ABI. > > Patch by Kuan Hsu Chen (khchen) > > Reviewers: lenary, lewis-revill, asb, MaskRay > > Reviewed By: lenary > > Subscribers: hiraditya, dschuff, aheejin, fedor.sergeev, mehdi_amini, inglorion, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, cfe-commits > > Tags: #clang > > Differential Revision: https://reviews.llvm.org/D67409
* [Diagnostics] Try to improve warning message for -Wreturn-typeDávid Bolvanský2019-11-091-1/+1
| | | | | | | | | | | | | | Summary: I agree with https://easyaspi314.github.io/gcc-vs-clang.html?fbclid=IwAR1VA0qxiWVUusOQUv5z7JESS7ZpeJy-UqAI5mnJscofGLqXcqeErIUB2gU, current warning message is not very good. We should try to improve it.. Reviewers: rsmith, aaron.ballman, easyaspi314 Reviewed By: aaron.ballman Subscribers: arphaman, Quuxplusone, mehdi_amini, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69762
* Revert "Reland "[clang] Report sanitizer blacklist as a dependency in cc1""Jan Korous2019-11-081-7/+3
| | | | This reverts commit cae4a28864f4e8a55920e2b94e2cd43617902dec.
* Reland "[clang] Report sanitizer blacklist as a dependency in cc1"Jan Korous2019-11-081-3/+7
| | | | This reverts commit 3182027282c59c51d5080d83365917fccd695854.
* Reland "[clang] Report sanitizer blacklist as a dependency in cc1"Jan Korous2019-11-081-7/+3
| | | | This reverts commit 9b8413ac6e56e7a6e0ba884773d13bcf9414bd43.
* Revert "Revert "Revert "[clang] Report sanitizer blacklist as a dependency ↵Abel Kocsis2019-11-081-3/+7
| | | | | | in cc1""" This reverts commit 3182027282c59c51d5080d83365917fccd695854.
* Revert "Revert "[clang] Report sanitizer blacklist as a dependency in cc1""Abel Kocsis2019-11-081-7/+3
| | | | This reverts commit 6b45e1bc11e91ea7b57a6ab1c19461a86dba33f8.
* Revert "[clang] Report sanitizer blacklist as a dependency in cc1"Jeremy Morse2019-11-081-3/+7
| | | | | | | | | | This reverts commit 03b84e4f6d0e1c04f22d69cc445f36e1f713beb4. This breaks dfsan tests with a linking failure, in for example this build: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/24312 Reverting this patch locally makes those tests succeed.
* [clang] Report sanitizer blacklist as a dependency in cc1Jan Korous2019-11-071-7/+3
| | | | | | | | Previously these were reported from the driver which blocked clang-scan-deps from getting the full set of dependencies from cc1 commands. Also the default sanitizer blacklist that is added in driver was never reported as a dependency. I introduced -fsanitize-system-blacklist cc1 option to keep track of which blacklists were user-specified and which were added by driver and clang -MD now also reports system blacklists as dependencies. Differential Revision: https://reviews.llvm.org/D69290
* [clang] Add -fdebug-default-version for specifying the default DWARF versionDavid Blaikie2019-11-071-0/+44
| | | | | | | | | | This flag decouples specifying the DWARF version from enabling/disabling DWARF in general (or the gN level - gmlt/limited/standalone, etc) while still allowing existing -gdwarf-N flags to override this default. Patch by Caroline Tice! Differential Revision: https://reviews.llvm.org/D69822
* [RISCV] Fix up tests on Windows after new usage of sys::path::appendReid Kleckner2019-11-072-22/+22
|
* Add support for options -frounding-math, ftrapping-math, -ffp-model=, and ↵Melanie Blower2019-11-073-4/+148
| | | | | | | | | | | | -ffp-exception-behavior= Add options to control floating point behavior: trapping and exception behavior, rounding, and control of optimizations that affect floating point calculations. More details in UsersManual.rst. Reviewers: rjmccall Differential Revision: https://reviews.llvm.org/D62731
* [RISCV] Improve sysroot computation if no GCC install detectedEdward Jones2019-11-0710-0/+68
| | | | | | | | | | If a GCC installed is not detected, the driver would default to the root of the filesystem. This is not ideal when this doesn't match the install directory of the toolchain and can cause undesireable behavior such as picking up system libraries or the system linker when cross-compiling. Differential Revision: https://reviews.llvm.org/D68391
* [mips] Add `octeon+` to the list of CPUs accepted by the driverSimon Atanasyan2019-11-072-0/+16
|
* [CUDA][HIP] Disable emitting llvm.linker.options in device compilationYaxun (Sam) Liu2019-11-041-0/+14
| | | | | | | The linker options (e.g. pragma detect_mismatch) are intended for host compilation only, therefore disable it for device compilation. Differential Revision: https://reviews.llvm.org/D57829
* [X86] Add support for -mvzeroupper and -mno-vzeroupper to match gccCraig Topper2019-11-041-0/+5
| | | | | | | | | | | | | | | | | -mvzeroupper will force the vzeroupper insertion pass to run on CPUs that normally wouldn't. -mno-vzeroupper disables it on CPUs where it normally runs. To support this with the default feature handling in clang, we need a vzeroupper feature flag in X86.td. Since this flag has the opposite polarity of the fast-partial-ymm-or-zmm-write we used to use to disable the pass, we now need to add this new flag to every CPU except KNL/KNM and BTVER2 to keep identical behavior. Remove -fast-partial-ymm-or-zmm-write which is no longer used. Differential Revision: https://reviews.llvm.org/D69786
* [profile] Add a mode to continuously sync counter updates to a fileVedant Kumar2019-10-311-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for continuously syncing profile counter updates to a file. The motivation for this is that programs do not always exit cleanly. On iOS, for example, programs are usually killed via a signal from the OS. Running atexit() handlers after catching a signal is unreliable, so some method for progressively writing out profile data is necessary. The approach taken here is to mmap() the `__llvm_prf_cnts` section onto a raw profile. To do this, the linker must page-align the counter and data sections, and the runtime must ensure that counters are mapped to a page-aligned offset within a raw profile. Continuous mode is (for the moment) incompatible with the online merging mode. This limitation is lifted in https://reviews.llvm.org/D69586. Continuous mode is also (for the moment) incompatible with value profiling, as I'm not sure whether there is interest in this and the implementation may be tricky. As I have not been able to test extensively on non-Darwin platforms, only Darwin support is included for the moment. However, continuous mode may "just work" without modification on Linux and some UNIX-likes. AIUI the default value for the GNU linker's `--section-alignment` flag is set to the page size on many systems. This appears to be true for LLD as well, as its `no_nmagic` option is on by default. Continuous mode will not "just work" on Fuchsia or Windows, as it's not possible to mmap() a section on these platforms. There is a proposal to add a layer of indirection to the profile instrumentation to support these platforms. rdar://54210980 Differential Revision: https://reviews.llvm.org/D68351
* Make flang driver stuff work on macOSNico Weber2019-10-311-4/+0
| | | | | | | | | | | 6bf55804 added special-case code for TY_PP_Fortran to ToolChain::LookupTypeForExtension(), but Darwin::LookupTypeForExtension() overrode that method without calling the superclass implementation. Make it call the superclass implementation to fix things. Differential Revision: https://reviews.llvm.org/D69636
* [cfi] Add flag to always generate .debug_frameDavid Candler2019-10-311-0/+6
| | | | | | | | | This adds a flag to LLVM and clang to always generate a .debug_frame section, even if other debug information is not being generated. In situations where .eh_frame would normally be emitted, both .debug_frame and .eh_frame will be used. Differential Revision: https://reviews.llvm.org/D67216
* [clang][llvm] Obsolete Exynos M1 and M2Evandro Menezes2019-10-302-66/+0
|
* [clang][driver][flang] Mark test as unsupported on darwinPeter Waller2019-10-301-0/+4
| | | | | | | D63607 made mac builders unhappy by failing this test, and it isn't yet obvious why. Mark as unsupported as a temporary measure. Signed-off-by: Peter Waller <peter.waller@arm.com>
* Rename a flang test caseJeremy Morse2019-10-302-2/+2
| | | | | | On Windows and macOS, the filesystem is case insensitive, and these files interfere with each other. Reading through, the case of the file extension is part of the test. I've altered the rest of the name instead.
* [clang][driver] Add basic --driver-mode=flang support for fortranPeter Waller2019-10-309-19/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a new Flang mode. When in Flang mode, the driver will invoke flang for fortran inputs instead of falling back to the GCC toolchain as it would otherwise do. The behaviour of other driver modes are left unmodified to preserve backwards compatibility. It is intended that a soon to be implemented binary in the flang project will import libclangDriver and run the clang driver in the new flang mode. Please note that since the binary invoked by the driver is under development, there will no doubt be further tweaks necessary in future commits. * Initial support is added for basic driver phases * -E, -fsyntax-only, -emit-llvm -S, -emit-llvm, -S, (none specified) * -### tests are added for all of the above * This is more than is supported by f18 so far, which will emit errors for those options which are unimplemented. * A test is added that ensures that clang gives a reasonable error message if flang is not available in the path (without -###). * Test that the driver accepts multiple inputs in --driver-mode=flang. * Test that a combination of C and Fortran inputs run both clang and flang in --driver-mode=flang. * clang/test/Driver/fortran.f95 is fixed to use the correct fortran comment character. Differential revision: https://reviews.llvm.org/D63607
* [Driver] Enable ShadowCallStack, not SafeStack, by default on AArch64 FuchsiaLeonard Chan2019-10-281-4/+5
| | | | | | | | | | | Submitted for mcgrathr. On AArch64, Fuchsia fully supports both SafeStack and ShadowCallStack ABIs. The latter is now preferred and will be the default. It's possible to enable both simultaneously, but ShadowCallStack is believed to have most of the practical benefit of SafeStack with less cost. Differential Revision: https://reviews.llvm.org/D66712
* Add Windows Control Flow Guard checks (/guard:cf).Andrew Paverd2019-10-282-3/+9
| | | | | | | | | | | | | | | | | | | Summary: A new function pass (Transforms/CFGuard/CFGuard.cpp) inserts CFGuard checks on indirect function calls, using either the check mechanism (X86, ARM, AArch64) or or the dispatch mechanism (X86-64). The check mechanism requires a new calling convention for the supported targets. The dispatch mechanism adds the target as an operand bundle, which is processed by SelectionDAG. Another pass (CodeGen/CFGuardLongjmp.cpp) identifies and emits valid longjmp targets, as required by /guard:cf. This feature is enabled using the `cfguard` CC1 option. Reviewers: thakis, rnk, theraven, pcc Subscribers: ychen, hans, metalcanine, dmajor, tomrittervg, alex, mehdi_amini, mgorny, javed.absar, kristof.beyls, hiraditya, steven_wu, dexonsmith, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65761
* Reland "[Clang][Bundler] Error reporting improvements"Sergey Dmitriev2019-10-251-16/+16
| | | | | | | | - Changed FileHandler read/write methods to return llvm::Error - Using unified way of reporting errors - Removed trailing '.' from the error messages Differential Revision: https://reviews.llvm.org/D67031
* Revert "[Clang][Bundler] Error reporting improvements"Sergey Dmitriev2019-10-251-16/+16
| | | | This reverts commit dd501045cdea1c80b6788f0266d2a79f8b412eea.
* [Clang][Bundler] Error reporting improvementsSergey Dmitriev2019-10-251-16/+16
| | | | | | | | - Changed FileHandler read/write methods to return llvm::Error - Using unified way of reporting errors - Removed trailing '.' from the error messages Differential Revision: https://reviews.llvm.org/D67031
* [hip] Allow the declaration of functions with variadic arguments in HIP.Michael Liao2019-10-252-6/+6
| | | | | | | | | | | | | | | | | Summary: - As variadic parameters have the lowest rank in overload resolution, without real usage of `va_arg`, they are commonly used as the catch-all fallbacks in SFINAE. As the front-end still reports errors on calls to `va_arg`, the declaration of functions with variadic arguments should be allowed in general. Reviewers: jlebar, tra, yaxunl Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69389
* Add AIX toolchain and basic linker functionalitystevewan2019-10-2410-0/+177
| | | | | | | | | | | | | | | | Summary: This patch adds AIX toolchain infrastructure into driver, and enables AIX system linker invocation with some basic functionality support Reviewers: daltenty, hubert.reinterpretcast, jasonliu, Xiangling_L Reviewed By: jasonliu Subscribers: Xiangling_L, jasonliu, ormris, wuzish, nemanjai, mgorny, kbarton, jfb, jsji, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68340
* Don't add -fsplit-lto-unit for thin LTO builds with PS4 and Darwin toolchainsevgeny2019-10-241-0/+4
| | | | | These toolchains use legacy thin LTO API, which is not capable of unit splitting Differential revision: https://reviews.llvm.org/D69173
* [RISCV] Add support for -ffixed-xX flagsSimon Cook2019-10-221-0/+341
| | | | | | | | | | | This adds support for reserving GPRs such that the compiler will not choose a register for register allocation. The implementation follows the same design as for AArch64; each reserved register becomes a target feature and used for getting the reserved registers for a given MachineFunction. The backend checks that it does not need to write to any reserved register; if it does a relevant error is generated. Differential Revision: https://reviews.llvm.org/D67185
* Fix -fuse-init-array decision logic on NetBSDJoerg Sonnenberger2019-10-211-0/+15
| | | | | | | For NetBSD 9 and later, it is the default. On older versions, only ARM and AArch64 use it by default. llvm-svn: 375468
* [test] Merge Driver/as-w-warnings.c into as-no-warnings.cFangrui Song2019-10-212-9/+7
| | | | | | For -integrated-as RUN lines we can remove -target. llvm-svn: 375439
* [profile] Do not cache __llvm_profile_get_filename resultVedant Kumar2019-10-181-1/+1
| | | | | | | | | | | | | | | | | When the %m filename pattern is used, the filename is unique to each image, so the cached value is wrong. It struck me that the full filename isn't something that's recomputed often, so perhaps it doesn't need to be cached at all. David Li pointed out we can go further and just hide lprofCurFilename. This may regress workflows that depend on using the set-filename API to change filenames across all loaded DSOs, but this is expected to be very rare. rdar://55137071 Differential Revision: https://reviews.llvm.org/D69137 llvm-svn: 375301
* [ThinLTOCodeGenerator] Add support for index-based WPDEugene Leviant2019-10-181-3/+2
| | | | | | | | | This is clang part of the patch. It adds -flto-unit flag for thin LTO builds on Mac and PS4 Differential revision: https://reviews.llvm.org/D68950 llvm-svn: 375224
* [WebAssembly] -pthread implies -target-feature +sign-extThomas Lively2019-10-181-2/+8
| | | | | | | | | | | | | | | | | Summary: The sign extension proposal was motivated by a desire to not have separate sign-extending atomic operations, so it is meant to be enabled when threads are used. Reviewers: aheejin, dschuff Subscribers: sbc100, jgravelle-google, sunfish, jfb, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69075 llvm-svn: 375199
* [clang-offload-wrapper][NFC] Use captured name of the entry type in LIT testSergey Dmitriev2019-10-171-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D69140 llvm-svn: 375177
* Reland: Dead Virtual Function EliminationOliver Stannard2019-10-171-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove dead virtual functions from vtables with replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up correctly. Original commit message: Currently, it is hard for the compiler to remove unused C++ virtual functions, because they are all referenced from vtables, which are referenced by constructors. This means that if the constructor is called from any live code, then we keep every virtual function in the final link, even if there are no call sites which can use it. This patch allows unused virtual functions to be removed during LTO (and regular compilation in limited circumstances) by using type metadata to match virtual function call sites to the vtable slots they might load from. This information can then be used in the global dead code elimination pass instead of the references from vtables to virtual functions, to more accurately determine which functions are reachable. To make this transformation safe, I have changed clang's code-generation to always load virtual function pointers using the llvm.type.checked.load intrinsic, instead of regular load instructions. I originally tried writing this using clang's existing code-generation, which uses the llvm.type.test and llvm.assume intrinsics after doing a normal load. However, it is possible for optimisations to obscure the relationship between the GEP, load and llvm.type.test, causing GlobalDCE to fail to find virtual function call sites. The existing linkage and visibility types don't accurately describe the scope in which a virtual call could be made which uses a given vtable. This is wider than the visibility of the type itself, because a virtual function call could be made using a more-visible base class. I've added a new !vcall_visibility metadata type to represent this, described in TypeMetadata.rst. The internalization pass and libLTO have been updated to change this metadata when linking is performed. This doesn't currently work with ThinLTO, because it needs to see every call to llvm.type.checked.load in the linkage unit. It might be possible to extend this optimisation to be able to use the ThinLTO summary, as was done for devirtualization, but until then that combination is rejected in the clang driver. To test this, I've written a fuzzer which generates random C++ programs with complex class inheritance graphs, and virtual functions called through object and function pointers of different types. The programs are spread across multiple translation units and DSOs to test the different visibility restrictions. I've also tried doing bootstrap builds of LLVM to test this. This isn't ideal, because only classes in anonymous namespaces can be optimised with -fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not work correctly with -fvisibility=hidden. However, there are only 12 test failures when building with -fvisibility=hidden (and an unmodified compiler), and this change does not cause any new failures for either value of -fvisibility. On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size reduction of ~6%, over a baseline compiled with "-O2 -flto -fvisibility=hidden -fwhole-program-vtables". The best cases are reductions of ~14% in 450.soplex and 483.xalancbmk, and there are no code size increases. I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which show a geomean size reduction of ~3%, again with no size increases. I had hoped that this would have no effect on performance, which would allow it to awlays be enabled (when using -fwhole-program-vtables). However, the changes in clang to use the llvm.type.checked.load intrinsic are causing ~1% performance regression in the C++ parts of SPEC2006. It should be possible to recover some of this perf loss by teaching optimisations about the llvm.type.checked.load intrinsic, which would make it worth turning this on by default (though it's still dependent on -fwhole-program-vtables). Differential revision: https://reviews.llvm.org/D63932 llvm-svn: 375094
* Fix darwin-ld-lto test for some speical pathSteven Wu2019-10-161-2/+4
| | | | | | | | | Fix the test by not assuming the prefix path of the temp directory can be matched by a regex. rdar://problem/56259195 llvm-svn: 375027
* [Driver,ARM] Make -mfloat-abi=soft turn off MVE.Simon Tatham2019-10-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since `-mfloat-abi=soft` is taken to mean turning off all uses of the FP registers, it should turn off the MVE vector instructions as well as NEON and scalar FP. But it wasn't doing so. So the options `-march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft` would cause the underlying LLVM to //not// support MVE (because it knows the real target feature relationships and turned off MVE when the `fpregs` feature was removed), but the clang layer still thought it //was// supported, and would misleadingly define the feature macro `__ARM_FEATURE_MVE`. The ARM driver code already has a long list of feature names to turn off when `-mfloat-abi=soft` is selected. The fix is to add the missing entries `mve` and `mve.fp` to that list. Reviewers: dmgreen Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69025 llvm-svn: 375001
* [Clang][OpenMP Offload] Move offload registration code to the wrapperSergey Dmitriev2019-10-151-5/+31
| | | | | | | | | | The final list of OpenMP offload targets becomes known only at the link time and since offload registration code depends on the targets list it makes sense to delay offload registration code generation to the link time instead of adding it to the host part of every fat object. This patch moves offload registration code generation from clang to the offload wrapper tool. This is the last part of the OpenMP linker script elimination patch https://reviews.llvm.org/D64943 Differential Revision: https://reviews.llvm.org/D68746 llvm-svn: 374937
OpenPOWER on IntegriCloud