Huh, Clang::Rmodule-build.m failed for no obvious reason and is green again
for the next build:
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/14221
Has anyone noticed this test in the past?
Cheers,
Jonas
A few pages of waterfall have shown no signs of R tests randomly
failing... This is weird.
I'd let it be, for now. Both Galina and Denis are copied. If it
happens again, they can investigate, as it doesn't seem related to
your commit in any way.
cheers,
--renato
[Copying also Reid]
http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/builds/9307 was
red,
http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/builds/9308 will
probably be green again (has already passed check 1 which failed before)
The failing tests (which are different) both show:
remark: building module '...' as '...'
which triggers a CHECK-NOT and "error: 'remark' diagnostics seen but not
expected:"
Thanks,
Jonas
We put up a new internal Windows bot on Monday, and it has been suffering
a lot of transient failures in Modules and PCH. On the other hand,
llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast has not been seeing these
(so far as I've noticed) so I wonder if there's some environmental thing
going on. I had been going on the assumption that there was an internal
problematic patch, but if folks upstream are also seeing flakiness in these
tests then maybe something else is at the root of it.
Our new bot is using 32 threads; are these tests unusually susceptible
to problems with parallel execution?
FTR the list of tests I've seen with this behavior:
Modules/fmodules-validate-once-per-build-session.c 3
Modules/no-stale-modtime.m 13
Modules/Rmodule-build.m 3
Modules/validate-system-headers.m 3
PCH/headersearch.cpp 3
PCH/verify_pch.m 6
--paulr
I agree, the PCH and Modules tests are a never-ending source of flakiness on Windows. I’m constantly disabling them by adding “REQUIRES: shell” or “REQUIRES: can-remove-opened-file”, and it’s a total hack.
I’d love it if we could diagnose what’s really going on here.