This test has %clang in the run line when it should have %clang_cc1. When built in release mode, %clang will discard labels for blocks, so it is unable to check for block labels.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I can't say that I know with any certainty, I'm too inexperienced. This failure was missed by me locally, the pre-merge bot, and by most of the buildbots other than the ones I mentioned above. I have no idea under what configuration of CMake options will clang not emit this particular case of a label for a BB.
You can check the CMake configurations of these bots.
https://github.com/llvm/llvm-zorg buildbot/osuosl/master/config/builders.py
I think it'd be good to know why. It may be a bug.
The problem is that this test is using %clang instead of %clang_cc1. Executing clang directly will pass -fdiscard-value-names when built with release mode; all blocks/values will be numbered, instead of explicitly named. It would be better to update the test to use %clang_cc1, to make it independent on flags passed depending on configuration of clang.
Ah I see, I was never able to find clear documentation on what exactly the -cc1 flag does other than the conceptual description. This should fix it right?
-cc1 options are implementation details and are unstable. Driver options need to be more stable and usually cannot be removed.
Ah I forgot that the driver option's default -f[no-]discard-value-names is dependent on -DLLVM_ENABLE_ASSERTIONS.
Can you also update the summary of this Diff and add a file-level comment to the test?
clang/test/Misc/loop-opt-setup.c | ||
---|---|---|
1 | Most tests use %clang_cc1 for relatively stable flag behavior so this comment is not needed. The comment should mention the purpose of this test and probably why -O1 is used. |
Most tests use %clang_cc1 for relatively stable flag behavior so this comment is not needed.
The comment should mention the purpose of this test and probably why -O1 is used.