Are you still having problem? I'd check myself, but don't have windows.

Are you still having problem? I'd check myself, but don't have windows.

Positive; just testes with r341740

Okay, I think this commit is the actual culprit:

commit b96a87a
Author: Rafael Espindola rafael.espindola@gmail.com
Date: Thu Nov 16 21:53:51 2017 +0000

Convert the last use of sys::fs::createUniqueFile in bugpoint.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318459 91177308-0d34-0410-b5e6-96231b3b80d8

The problem is that if(BitcodeFile.empty()), a TempFile will be created in a local scope, then get deleted before it's used out of scope further down.

btw, you can test this by using "-save-temps" and see if that solves the problem.

I don't think that r318459 is the problem. Before submitting this bug, I bisected it to r341740 (meaning it worked before that commit)

However Rafael's createUniqueFile refacturing indeed caused problems with bugpoint on Windows, but it has been fixed. See:

https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20171120/504298.html

With -save-temps:

$ bugpoint polly-timeout-grtestutils.ll -save-temps -verify -opt-command=C:\Users\meinersbur\build\llvm\release\bin\opt.exe -opt-args -polly-process-unprofitable
Read input file : 'polly-timeout-grtestutils.ll'
*** All input ok
Running selected passes on program to test for crash: C:\Users\meinersbur\build\llvm\release\bin\opt.exe: bugpoint-input-18caf6b.bc: error: Could not open input file: permission denied
Exited with error code '1'

*** Debugging optimizer crash!
Checking to see if these passes crash: -verify: C:\Users\meinersbur\build\llvm\release\bin\opt.exe: bugpoint-input-75e7dbd.bc: error: Could not open input file: permission denied
Exited with error code '1'

*** Found crashing pass: -verify
Emitted bitcode to 'bugpoint-passes.bc'

*** You can reproduce the problem with: opt bugpoint-passes.bc -verify
Checking for crash with changing conditionals to always jump to true: call1.i.noexc call1.i.noexc.split invoke.cont invoke.cont6 for.cond lpad lpad1 invoke.cont10 invoke.cont17 call.i.i.noexc... <33 total>: C:\Users\meinersbur\build\llvm\release\bin\opt.exe: bugpoint-input-6f44ec7.bc: error: Could not open input file: permission denied
verify failed!

Okay, that's a different bug, and I submitted a separate patch for it:

https://reviews.llvm.org/D51836

According to Microsoft docs,

https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-setfileinformationbyhandle

"... if the application is using FILE_DISPOSITION_INFO with the DeleteFile member set to TRUE, the file would need DELETE access requested in the call to the CreateFile function."

LLVM wraps these windows specific calls in lib/Support/Windows/Path.inc, but only passes DELETE in calls to remove or rename files. However, since TempFile sets FILE_DESPSITION_INFO.DeleteFile = true, subsequent CreateFile calls need to include DELETE access.

I don't have windows, so I can't test this, but here's a small patch that unilaterally adds DELETE to the underlying CreateFile calls that you can use to test if this is the actual problem.

diff --git a/lib/Support/Windows/Path.inc b/lib/Support/Windows/Path.inc
index 57557dbc3da..95c80eb4fc7 100644
--- a/lib/Support/Windows/Path.inc
+++ b/lib/Support/Windows/Path.inc
@@ -1070,7 +1070,7 @@ static std::error_code openNativeFileInternal(const Twine &Name,
SA.bInheritHandle = Inherit;

HANDLE H =

•  ::CreateFileW(PathUTF16.begin(), Access,
  

•  ::CreateFileW(PathUTF16.begin(), Access | DELETE,
                 FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, &SA,
                 Disp, Flags, NULL);
  

  if (H == INVALID_HANDLE_VALUE) {

This patch unfortunately did not fix the problem.

*** Bug llvm/llvm-bugzilla-archive#38467 has been marked as a duplicate of this bug. ***

mentioned in issue llvm/llvm-bugzilla-archive#38467