In D107695#3617159, @MatzeB wrote:

Hey, I don't know if this has anything to do with this change.

But I see the "llvm-clang-x86_64-sie-win" buildbot (https://lab.llvm.org/buildbot/#/builders/216) failing the reorder.py testcase randomly every 10-20 builds.

See https://lab.llvm.org/buildbot/#/builders/216 for the list of recent builds.

I didn't look deeply into the root cause here, but thought it would be good to ping here in case anyone has an idea to get the bot more stable.

I'm the owner of that buildbot, but unfortunately have not been able to get the failure to reproduce outside of the buildbot initiated build environment, so I haven't been able to really look into the issue. Any ideas how to possibly debug and/or fix the issue would be greatly appreciated as I've been a bit stuck on how to get it more stable!

I can confirm that the change seems to be working for me!

Your change is failing to build on the PS4 Windows bot, can you take a look and revert if it takes time to fix?

In D125263#3602731, @efriedma wrote:

We are seeing failures in our internal Windows build with an older version of the Visual C++ compiler that I bisected back to this commit. The errors are all similar to this:

I don't see any obvious reason for this to fail, or be affected by /permissive-. Can you attach and/or send me preprocessed source for the failing file?

Hi, I have create github issue #56173 with a preprocessed source that should show the error when built using an older version of Visual C++.

Hi @bcl5980, one of our internal tests started to hit an assertion failure while building which I bisected back to this change. I have filed the details as issue #56170, can you take a look?

In D125263#3602731, @efriedma wrote:

We are seeing failures in our internal Windows build with an older version of the Visual C++ compiler that I bisected back to this commit. The errors are all similar to this:

I don't see any obvious reason for this to fail, or be affected by /permissive-. Can you attach and/or send me preprocessed source for the failing file?

I've worked around the issue locally by disabling the call to /permissive-. I'll see what I can do to get a preprocessed source.

We are seeing failures in our internal Windows build with an older version of the Visual C++ compiler that I bisected back to this commit. The errors are all similar to this:

C:\src\upstream\llvm_clean_git\clang\include\clang/Basic/Sanitizers.def(41,1): error C2131: expression did not evaluate to a constant [C:\src\upstream\df6291a666d3-PS4-Release\tools\clang\lib\Basic\obj.clangBasic.vcxproj]
C:\src\upstream\llvm_clean_git\clang\include\clang/Basic/Sanitizers.def(41,1): message : failure was caused by call of undefined function or one not declared 'constexpr' [C:\src\upstream\df6291a666d3-PS4-Release\tools\clang\lib\Basic\obj.clangBasic.vcxproj]
C:\src\upstream\llvm_clean_git\clang\include\clang/Basic/Sanitizers.def(41,1): message : see usage of 'clang::SanitizerMask::bitPosToMask' [C:\src\upstream\df6291a666d3-PS4-Release\tools\clang\lib\Basic\obj.clangBasic.vcxproj]

@mboehme, one of our internal tests started to fail to compile after this change due to the compiler no longer accepting what I think should be a valid attribute declaration. I have filed issue #56077 for the problem, can you take a look?

I tried it on Windows building with both ninja and Visual Studio and both seem to work after your change. LGTM.

In D126308#3582337, @mizvekov wrote:

In D126308#3581240, @dyung wrote:

Can you take a look?

Hi @dyung , thanks for the report and sorry for the trouble!
Can you help me try to reproduce it?

Which version of Visual Studio, and what preset are you using?

Hi @mizvekov, this change seems to have broken the location of the hmaptool when using the Visual Studio builder on Windows. After your commit, 7 clang tests fail because hmaptool cannot be found at the expected location. For example, the test clang/test/Preprocessor/headermap-rel.c:

FAIL: Clang :: Preprocessor/headermap-rel.c (1 of 1)
******************** TEST 'Clang :: Preprocessor/headermap-rel.c' FAILED ********************
Script:
--
: 'RUN: at line 1';   rm -f D:\src\upstream\51608515faa7-PS4-Release\tools\clang\test\Preprocessor\Output\headermap-rel.c.tmp.hmap
: 'RUN: at line 2';   'C:/Program Files/Python310/python.exe' D:\src\upstream\51608515faa7-PS4-Release\Release\bin\hmaptool write D:\src\upstream\llvm_clean_git\clang\test\Preprocessor/Inputs/headermap-rel/foo.hmap.json D:\src\upstream\51608515faa7-PS4-Release\tools\clang\test\Preprocessor\Output\headermap-rel.c.tmp.hmap
: 'RUN: at line 3';   d:\src\upstream\51608515faa7-ps4-release\release\bin\clang.exe -cc1 -internal-isystem d:\src\upstream\51608515faa7-ps4-release\release\lib\clang\15.0.0\include -nostdsysteminc -E D:\src\upstream\llvm_clean_git\clang\test\Preprocessor\headermap-rel.c -o D:\src\upstream\51608515faa7-PS4-Release\tools\clang\test\Preprocessor\Output\headermap-rel.c.tmp.i -I D:\src\upstream\51608515faa7-PS4-Release\tools\clang\test\Preprocessor\Output\headermap-rel.c.tmp.hmap -F D:\src\upstream\llvm_clean_git\clang\test\Preprocessor/Inputs/headermap-rel
: 'RUN: at line 4';   d:\src\upstream\51608515faa7-ps4-release\release\bin\filecheck.exe D:\src\upstream\llvm_clean_git\clang\test\Preprocessor\headermap-rel.c -input-file D:\src\upstream\51608515faa7-PS4-Release\tools\clang\test\Preprocessor\Output\headermap-rel.c.tmp.i
--
Exit Code: 2

Hi, your recommit of your changes are causing a test failure on the PS4 bots because the newly added test target arm64 is not present, can you either fixup the test to not require that or add a REQUIRES line?

Just another data point, but we noticed the same issue of clang++ missing after install on our internal Windows builds, and I bisected it to this commit.

In D126651#3574290, @johannes wrote:

No idea why the conversion fails for the wide string.
First step is to reproduce the problem. I guess we should try in a Ubuntu VM.
Is there an easy way to see if other builders succeeded?

This seems to be causing 7 test failures on our internal linux buildbot:

• MemorySanitizer-X86_64 :: Linux/glob_altdirfunc.cpp
• MemorySanitizer-X86_64 :: stat64.cpp
• MemorySanitizer-lld-X86_64 :: Linux/glob_altdirfunc.cpp
• MemorySanitizer-lld-X86_64 :: stat64.cpp
• SanitizerCommon-asan-x86_64-Linux :: Posix/lstat64.cpp
• SanitizerCommon-msan-x86_64-Linux :: Posix/lstat64.cpp
• SanitizerCommon-tsan-x86_64-Linux :: Posix/lstat64.cpp

In D124561#3569218, @uabelho wrote:

Hello,

When I run tests (check-all) on this commit I get the follwoing two failures:

Failed Tests (2):
  lld :: MachO/eh-frame.s
  lld :: MachO/icf-safe.s

They crash with

Command Output (stderr):
--
ld64.lld: ../../lld/MachO/UnwindInfoSection.cpp:216: void lld::macho::UnwindInfoSection::addSymbol(const lld::macho::Defined *): Assertion `!p.first->second->unwindEntry' failed.
/repo/uabelho/main-github/llvm/build-all/tools/lld/test/MachO/Output/eh-frame.s.script: line 17: 123869 Aborted                 ld64.lld -arch x86_64 -platform_version macos 11.0 11.0 -syslibroot /repo/uabelho/main-github/lld/test/MachO/Inputs/MacOSX.sdk -fatal_warnings -arch arm64 -lSystem -lc++ /repo/uabelho/main-github/llvm/build-all/tools/lld/test/MachO/Output/eh-frame.s.tmp/eh-frame-arm64.o -o /repo/uabelho/main-github/llvm/build-all/tools/lld/test/MachO/Output/eh-frame.s.tmp/eh-frame-arm64

and

Command Output (stderr):
--
ld64.lld: ../../lld/MachO/ICF.cpp:451: auto lld::macho::foldIdenticalSections()::(anonymous class)::operator()(lld::macho::ConcatInputSection *) const: Assertion `isec->icfEqClass[0] == 0' failed.
ld64.lld: ../../lld/MachO/ICF.cpp:451: auto lld::macho::foldIdenticalSections()::(anonymous class)::operator()(lld::macho::ConcatInputSection *) const: Assertion `isec->icfEqClass[0] == 0' failed.
/repo/uabelho/main-github/llvm/build-all/tools/lld/test/MachO/Output/icf-safe.s.script: line 6: 45777 Aborted                 ld64.lld -arch x86_64 -platform_version macos 11.0 11.0 -syslibroot /repo/uabelho/main-github/lld/test/MachO/Inputs/MacOSX.sdk -fatal_warnings -arch arm64 -lSystem --icf=safe -dylib -o /repo/uabelho/main-github/llvm/build-all/tools/lld/test/MachO/Output/icf-safe.s.tmp/icf-safe.dylib /repo/uabelho/main-github/llvm/build-all/tools/lld/test/MachO/Output/icf-safe.s.tmp/icf-obj.o

Any idea what's happening?

In D123435#3569761, @thakis wrote:

This breaks tests everywhere: http://45.33.8.238/linux/78091/step_11.txt

The test you changed is failing on the PS4 Windows/Linux bots due to the arm64 triple not being available. Can you please fix the test?

Hi, the test you modified in your change seems to be failing on the PS4 linux build bot at https://lab.llvm.org/buildbot/#/builders/139/builds/22964.

In D120201#3547835, @abrachet wrote:

In D120201#3547834, @dyung wrote:

The test you added seems to be failing on the PS4 Windows bot. A quick glance seems to suggest that you aren't properly escaping the path separators somewhere. Can you take a look and revert if you need time to investigate?

https://lab.llvm.org/buildbot/#/builders/216/builds/5164

Should be fixed by https://github.com/llvm/llvm-project/commit/a0ef52cc102504c4282dec7001664ee020396681

The test you added seems to be failing on the PS4 Windows bot. A quick glance seems to suggest that you aren't properly escaping the path separators somewhere. Can you take a look and revert if you need time to investigate?

Hi @jkorous, 4 of the tests you added seem to be failing on the PS4 linux and Window buildbots, can you take a look, and revert if it might take a while to investigate?

@MTC @arichardson The test stats-file-option.ll that is now enabled after this commit seems to fail if X86 is not one of the built targets. Can the test be rewritten to now require that, or an appropriate REQUIRES line added?

In D123801#3499832, @dyung wrote:

@dmgreen, just a heads up that we are seeing an infinite loop in the compiler on an internal test which I have bisected to this change. I'm working on a repro at the moment and will post it when I can get it.

@dmgreen, just a heads up that we are seeing an infinite loop in the compiler on an internal test which I have bisected to this change. I'm working on a repro at the moment and will post it when I can get it.

Hi, the test you added, hwasan_symbolize.cpp seems to be causing a failure on the sanitizer buildbot (https://lab.llvm.org/buildbot/#/builders/37/builds/13022):

FAIL: HWAddressSanitizer-x86_64 :: TestCases/hwasan_symbolize.cpp (71 of 86)
******************** TEST 'HWAddressSanitizer-x86_64 :: TestCases/hwasan_symbolize.cpp' FAILED ********************
Script:
--
: 'RUN: at line 1';      /b/sanitizer-x86_64-linux/build/clang_build/./bin/clang   -m64  -gline-tables-only -fsanitize=hwaddress -fuse-ld=lld -fsanitize-hwaddress-experimental-aliasing -mllvm -hwasan-generate-tags-with-calls=1 -mllvm -hwasan-globals -mllvm -hwasan-use-short-granules -mllvm -hwasan-instrument-landing-pads=0 -mllvm -hwasan-instrument-personality-functions -Wl,--build-id -g /b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/hwasan/TestCases/hwasan_symbolize.cpp -o /b/sanitizer-x86_64-linux/build/clang_build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/hwasan_symbolize.cpp.tmp
: 'RUN: at line 2';   echo '[{"prefix": "'"$(realpath $(dirname /b/sanitizer-x86_64-linux/build/clang_build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/hwasan_symbolize.cpp.tmp)/../../../../../../)"'/", "link": "http://test.invalid/{file}:{line}"}]' > /b/sanitizer-x86_64-linux/build/clang_build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/hwasan_symbolize.cpp.tmp.linkify
: 'RUN: at line 3';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:symbolize=0 not  /b/sanitizer-x86_64-linux/build/clang_build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/hwasan_symbolize.cpp.tmp 2>&1 | hwasan_symbolize --html --symbols $(dirname /b/sanitizer-x86_64-linux/build/clang_build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/hwasan_symbolize.cpp.tmp) --index | FileCheck /b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/hwasan/TestCases/hwasan_symbolize.cpp
: 'RUN: at line 4';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:symbolize=0 not  /b/sanitizer-x86_64-linux/build/clang_build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/hwasan_symbolize.cpp.tmp 2>&1 | hwasan_symbolize --html --linkify /b/sanitizer-x86_64-linux/build/clang_build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/hwasan_symbolize.cpp.tmp.linkify --symbols $(dirname /b/sanitizer-x86_64-linux/build/clang_build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/hwasan_symbolize.cpp.tmp) --index | FileCheck --check-prefixes=CHECK,LINKIFY /b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/hwasan/TestCases/hwasan_symbolize.cpp
: 'RUN: at line 5';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:symbolize=0 not  /b/sanitizer-x86_64-linux/build/clang_build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/hwasan_symbolize.cpp.tmp 2>&1 | hwasan_symbolize --symbols $(dirname /b/sanitizer-x86_64-linux/build/clang_build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/hwasan_symbolize.cpp.tmp) --index | FileCheck /b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/hwasan/TestCases/hwasan_symbolize.cpp
--
Exit Code: 2
Command Output (stderr):
--
Traceback (most recent call last):
  File "/b/sanitizer-x86_64-linux/build/clang_build/./bin/hwasan_symbolize", line 19, in <module>
    import html
ImportError: No module named html
FileCheck error: '<stdin>' is empty.
FileCheck command line:  FileCheck /b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/hwasan/TestCases/hwasan_symbolize.cpp
--

And also our internal linux buildbot is reporting a failure after this commit:

/home/siadmin/jenkins/w/opensource/opensource_build/working_dir/compiler-rt/test/hwasan/TestCases/hwasan_symbolize.cpp:17:14: error: LINKIFY: expected string not found in input
 // LINKIFY: <a href="http://test.invalid/compiler-rt/test/hwasan/TestCases/hwasan_symbolize.cpp:[[@LINE-1]]">
             ^
<stdin>:1:1: note: scanning from here
==27214==ERROR: HWAddressSanitizer: tag-mismatch on address 0x680400000064 at pc 0x55d1c8f6e76b<br/>
^
<stdin>:1:1: note: with "@LINE-1" equal to "16"
==27214==ERROR: HWAddressSanitizer: tag-mismatch on address 0x680400000064 at pc 0x55d1c8f6e76b<br/>
^
<stdin>:6:68: note: possible intended match here
&nbsp;&nbsp;&nbsp;&nbsp;#1 main in /home/siadmin/jenkins/w/opensource/opensource_build/working_dir/compiler-rt/test/hwasan/TestCases/hwasan_symbolize.cpp:16:10<br/>
                                                                   ^

The PS4 linux buildbot which runs gcc is not building any longer after this change, @beanz can you take a look?

Hi @qcolombet, your change seems to be causing 2 test failures on the PS4 build bots, can you please take a look?

I think the problem here is that if zlib is not available, you won't get the clang command line you expect:

Hi @arsenm, the test you added is failing on our internal linux build bot that builds a release build without asserts with the following error:

Command Output (stderr):
--
/home/dyung/src/upstream/llvm_clean_git/llvm/test/CodeGen/AMDGPU/store-to-constant-error.ll:4:9: error: SDAG: expected string not found in input
; SDAG: LLVM ERROR: Cannot select: t{{[0-9]+}}: ch = store<(store (s32) into %ir.ptr.load, addrspace 4)>
        ^
<stdin>:1:1: note: scanning from here
LLVM ERROR: Cannot select: 0x55f05ad6f228: ch = store<(store (s32) into %ir.ptr.load, addrspace 4)> 0x55f05acd7d38, Constant:i32<1>, 0x55f05ad6f020, undef:i64
^

Can you take a look?

Hi, the test you added is failing on the PS4 Windows bot https://lab.llvm.org/buildbot/#/builders/216/builds/2647.

Hi, one of the tests you added. csky-toolchain.c seems to be failing on a Windows build bot, and from a quick look, it appears to be a path separator issue. Can you take a look?

This change is causing 9 test failures on a buildbot, can you please take a look and revert if you need time to investigate?

I've reverted this change in order to get the build bots green again.

This change is causing CMake failures on at least 2 different bots due to a missing dependency target "Bye". Can you take a look?

This seems to be breaking our internal Release Windows build with errors of the sort:

The tests you added are failing on a Windows buildbot, I'm guessing it is because you are explicitly setting the output to /dev/stdout which likely doesn't exist on Windows. Can you take a look?

@fhahn This change seems to be hitting an assertion failure in one of our internal tests. I have filed GHI#54223 with a repro. Can you take a look?

This change seems to be causing many bots to fail when running the clang :: Preprocessor/init.c test, can you take a look?

Thanks for fixing the problem with the original commit, but in the future, if you make follow-up commits, can you change the commit message to reflect what the commit contains? Having three different commits with the exact same commit message can be very confusing.

And the PS4 build bots:

If it helps, this is the cmake command I am using to build using gcc on linux:

CMake command: -G Ninja -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_VERSION_SUFFIX= -DLLVM_BUILD_RUNTIME=ON -DLLVM_TOOL_LLD_BUILD=OFF "-DLLVM_LIT_ARGS=--verbose -j80 --no-progress-bar --max-tests 10" -DCMAKE_BUILD_TYPE=Release -DLLVM_OPTIMIZED_TABLEGEN=ON -DLLVM_TARGETS_TO_BUILD=all -DLLVM_ENABLE_PROJECTS=clang;clang-tools-extra

Some of the stuff there probably isn't needed (it's taken from a general script that I make small changes to when trying to reproduce stuff), but is there for completeness.

In D120254#3342570, @svenvh wrote:

In D120254#3342551, @dyung wrote:

Hi, our internal release build bots are showing failures in two clang-tidy tests that I bisected back to your commit, clang-tidy/checkers/altera-id-dependent-backward-branch.cpp and clang-tidy/checkers/altera-single-work-item-barrier.cpp. After this change, both are exhibiting this error:

Error while processing /home/dyung/src/upstream/aa9c2d19d9b73589d72114d6e0a4fb4ce42b922b-linux/tools/clang/tools/extra/test/clang-tidy/checkers/Output/altera-single-work-item-barrier.cpp.tmp.cpp.
error: enum type memory_scope not found; include the base header with -finclude-default-header [clang-diagnostic-error]

Oddly, this only fails in a release configuration. Can you take a look?

I'll try to reproduce the failure locally, but until I've done so perhaps you could try whether the following fixes one of the tests? If so, then the other test will likely need a similar fix.

diff --git a/clang-tools-extra/test/clang-tidy/checkers/altera-id-dependent-backward-branch.cpp b/clang-tools-extra/test/clang-tidy/checkers/altera-id-dependent-backward-branch.cpp
index a6dbab7b72fc..9bc1bbf173cc 100644
--- a/clang-tools-extra/test/clang-tidy/checkers/altera-id-dependent-backward-branch.cpp
+++ b/clang-tools-extra/test/clang-tidy/checkers/altera-id-dependent-backward-branch.cpp
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy %s altera-id-dependent-backward-branch %t -- -header-filter=.* "--" -cl-std=CL1.2 -c --include opencl-c.h
+// RUN: %check_clang_tidy %s altera-id-dependent-backward-branch %t -- -header-filter=.* "--" -cl-std=CL1.2 -c --include opencl-c.h --include opencl-c-base.h
 
 typedef struct ExampleStruct {
   int IDDepField;

Hi, our internal release build bots are showing failures in two clang-tidy tests that I bisected back to your commit, clang-tidy/checkers/altera-id-dependent-backward-branch.cpp and clang-tidy/checkers/altera-single-work-item-barrier.cpp. After this change, both are exhibiting this error:

Error while processing /home/dyung/src/upstream/aa9c2d19d9b73589d72114d6e0a4fb4ce42b922b-linux/tools/clang/tools/extra/test/clang-tidy/checkers/Output/altera-single-work-item-barrier.cpp.tmp.cpp.
error: enum type memory_scope not found; include the base header with -finclude-default-header [clang-diagnostic-error]

Oddly, this only fails in a release configuration. Can you take a look?

Hi Snehasish, your change is likely causing 3 test failures on the PS4 linux buildbot, can you take a look?

In D119207#3330494, @shangwuyao wrote:

In D119207#3330385, @dyung wrote:

Hi, the test you added is failing on the PS4 Linux bot, can you take a look?

https://lab.llvm.org/buildbot/#/builders/139/builds/17199

Looks like the compiled SPIR-V is slightly different for different build settings, for llvm-clang-x86_64-sie-ubuntu-fast, it is compiled to

define hidden spir_kernel void @_Z6kernelPi(i32 addrspace(1)* noundef %output.coerce) #0 {

so it is missing that extra hidden keyword.
And for clang-ve-ninja, it is compiled to

define spir_kernel void @_Z6kernelPi(i32 addrspace(1)* noundef %0) #0 {

so the kernel argument identifier is slightly different (%0 vs %output.coerce).

I could fix that, I wonder why it didn't trigger the same issue (for the hidden keyword) with this test tho, it is basically the same.

And why does those build test run only after merging? For future reference, can I try to run those myself before submitting?

Hi, the test you added is failing on the PS4 Linux bot, can you take a look?

I've reverted this and the follow-up change to fix the build in 437d4e01fe4c057509dff30efd560049ad07bc99.

I'm not exactly sure why, but this change seems to be causing the Driver/cl-options.c test to fail on the PS4 Windows bot:

Update change based on @probinson 's feedback.

I was able to reproduce the issue with a small testcase that I have filed as issue 53695. Hope that helps.

This is a simple change that could make Windows testing of this test more reliable I think. Could I get a quick review?

Just a heads up that we potentially saw an issue with this commit on some of our internal tests. I've bisected it down to your commit, but I need to make sure it reproduces with an opensource compiler (without our private changes), and if so I will post a bug with the information.

In D114732#3294794, @devin.jeanpierre wrote:

Oops, sorry about that. What is the correct way to test/reproduce the change? Do I / can I submit builds to the buildbot manually for testing?

Also, should I be rolling back this change, or no? Not sure of the protocol here, this is my first change to Clang.

P.S. that breakage is disturbing -- I would not have expected this sort of failure on any platform, and I'm not sure if it reflects a bug on PS4. (It seems to be that structs are passed in registers, even if the member variables of that struct cannot be.)

Hi, your change is causing a test failure in the test attr-trivial-abi.cpp that you modified on the PS4 Windows box:

Your change seems to be causing some test failures on a buildbot, can you take a look?

Not sure why this wasn't closed automatically, but the changes were committed in https://reviews.llvm.org/rZORGc561bb939d9acad8dc9dce45692de7fa5e673101.

Ping

Hi Adrian, the test you updated in your commit is failing on the PS4 linux bot, can you take a look?

Remove compiler-rt as a dependency and build target.