[PATCH] D158279: clang: Make rewrite-includes-macros.cpp runnable on non-Win

2023-08-18 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea accepted this revision.
aganea added a comment.
This revision is now accepted and ready to land.

Sure. This was meant to catch an issue that only happened on Windows but it 
should work on all platforms.

LGTM.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158279/new/

https://reviews.llvm.org/D158279

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D147256: [DebugInfo] Fix file path separator when targeting windows.

2023-04-12 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added subscribers: thieta, saudi.
aganea added a comment.

+ @saudi @thieta


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147256/new/

https://reviews.llvm.org/D147256

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D146490: [Support] On Windows, ensure that UniqueID is really stable

2023-03-21 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

Fair enough. There are several choices forward: either we mark the issue as 
"Will Not Fix" or I can try only scoping this patch to only keep the handle for 
network drives/paths. Any other suggestions?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146490/new/

https://reviews.llvm.org/D146490

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D146490: [Support] On Windows, ensure that UniqueID is really stable

2023-03-20 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea updated this revision to Diff 506820.
Herald added a subscriber: ormris.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146490/new/

https://reviews.llvm.org/D146490

Files:
  clang-tools-extra/clangd/unittests/FSTests.cpp
  clang/include/clang/Basic/FileEntry.h
  clang/lib/Basic/FileEntry.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp
  clang/tools/libclang/Indexing.cpp
  clang/unittests/Basic/FileManagerTest.cpp
  llvm/include/llvm/Support/FileSystem.h
  llvm/include/llvm/Support/FileSystem/UniqueID.h
  llvm/include/llvm/Support/Windows/ScopedHandle.h
  llvm/include/llvm/Support/Windows/WindowsSupport.h
  llvm/lib/Support/VirtualFileSystem.cpp
  llvm/lib/Support/Windows/Path.inc
  llvm/unittests/Support/FSUniqueIDTest.cpp
  llvm/unittests/Support/Path.cpp
  llvm/unittests/Support/VirtualFileSystemTest.cpp
  llvm/utils/split-file/split-file.cpp

Index: llvm/utils/split-file/split-file.cpp
===
--- llvm/utils/split-file/split-file.cpp
+++ llvm/utils/split-file/split-file.cpp
@@ -162,14 +162,16 @@
 
   // Delete output if it is a file or an empty directory, so that we can create
   // a directory.
-  sys::fs::file_status status;
-  if (std::error_code ec = sys::fs::status(output, status))
-if (ec.value() != static_cast(std::errc::no_such_file_or_directory))
-  fatal(output, ec.message());
-  if (status.type() != sys::fs::file_type::file_not_found &&
-  status.type() != sys::fs::file_type::directory_file &&
-  status.type() != sys::fs::file_type::regular_file)
-fatal(output, "output cannot be a special file");
+  {
+sys::fs::file_status status;
+if (std::error_code ec = sys::fs::status(output, status))
+  if (ec.value() != static_cast(std::errc::no_such_file_or_directory))
+fatal(output, ec.message());
+if (status.type() != sys::fs::file_type::file_not_found &&
+status.type() != sys::fs::file_type::directory_file &&
+status.type() != sys::fs::file_type::regular_file)
+  fatal(output, "output cannot be a special file");
+  }
   if (std::error_code ec = sys::fs::remove(output, /*IgnoreNonExisting=*/true))
 if (ec.value() != static_cast(std::errc::directory_not_empty) &&
 ec.value() != static_cast(std::errc::file_exists))
Index: llvm/unittests/Support/VirtualFileSystemTest.cpp
===
--- llvm/unittests/Support/VirtualFileSystemTest.cpp
+++ llvm/unittests/Support/VirtualFileSystemTest.cpp
@@ -151,24 +151,23 @@
 return FilesAndDirs.find(std::string(P.str()));
   }
 
+  UniqueID makeUniqueID() { return UniqueID::inMemory(FSID, FileID++); }
+
   void addRegularFile(StringRef Path, sys::fs::perms Perms = sys::fs::all_all) {
-vfs::Status S(Path, UniqueID(FSID, FileID++),
-  std::chrono::system_clock::now(), 0, 0, 1024,
-  sys::fs::file_type::regular_file, Perms);
+vfs::Status S(Path, makeUniqueID(), std::chrono::system_clock::now(), 0, 0,
+  1024, sys::fs::file_type::regular_file, Perms);
 addEntry(Path, S);
   }
 
   void addDirectory(StringRef Path, sys::fs::perms Perms = sys::fs::all_all) {
-vfs::Status S(Path, UniqueID(FSID, FileID++),
-  std::chrono::system_clock::now(), 0, 0, 0,
-  sys::fs::file_type::directory_file, Perms);
+vfs::Status S(Path, makeUniqueID(), std::chrono::system_clock::now(), 0, 0,
+  0, sys::fs::file_type::directory_file, Perms);
 addEntry(Path, S);
   }
 
   void addSymlink(StringRef Path) {
-vfs::Status S(Path, UniqueID(FSID, FileID++),
-  std::chrono::system_clock::now(), 0, 0, 0,
-  sys::fs::file_type::symlink_file, sys::fs::all_all);
+vfs::Status S(Path, makeUniqueID(), std::chrono::system_clock::now(), 0, 0,
+  0, sys::fs::file_type::symlink_file, sys::fs::all_all);
 addEntry(Path, S);
   }
 
Index: llvm/unittests/Support/Path.cpp
===
--- llvm/unittests/Support/Path.cpp
+++ llvm/unittests/Support/Path.cpp
@@ -705,6 +705,7 @@
   ASSERT_NO_ERROR(fs::getUniqueID(Twine(TempPath2), D));
   ASSERT_NE(D, F1);
   ::close(FileDescriptor2);
+  D = fs::UniqueID();
 
   ASSERT_NO_ERROR(fs::remove(Twine(TempPath2)));
 
@@ -715,6 +716,7 @@
   ASSERT_NO_ERROR(fs::getUniqueID(Twine(TempPath2), D2));
   ASSERT_EQ(D2, F1);
 
+  D2 = fs::UniqueID();
   ::close(FileDescriptor);
 
   SmallString<128> Dir1;
@@ -729,6 +731,10 @@
  fs::createUniqueDirectory("dir2", Dir2));
   ASSERT_NO_ERROR(fs::getUniqueID(Dir2.c_str(), F2));
   ASSERT_NE(F1, F2);
+
+  F1 = fs::UniqueID();
+  F2 = fs::UniqueID();
+
   ASSERT_NO_ERROR(fs::remove(Dir1));
   ASSERT_NO_ERROR(fs::remove(Dir2));
   ASSERT_NO_ERROR(fs::remove(TempPath2));
@@ -887,6 +893,10 @@
   EXPECT_FALSE(fs::equivalent(A, B));

[PATCH] D146490: [Support] On Windows, ensure that UniqueID is really stable

2023-03-20 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea created this revision.
aganea added reviewers: mstorsjo, hans, kbobyrev, dexonsmith, zero9178.
Herald added subscribers: kadircet, arphaman, hiraditya.
Herald added a project: All.
aganea requested review of this revision.
Herald added projects: clang, LLVM, clang-tools-extra.
Herald added subscribers: cfe-commits, llvm-commits.

Before this patch, `UniqueID` was thought to store stable file IDs. However a 
recently reported issue  
shows that the file IDs are not always stable, at least on Windows. The 
documentation for the underlying Windows API 

 states: //(note the emphasis)//

> To determine whether two **open handles** represent the same file, combine 
> the identifier and the volume serial number for each file and compare them.

Currently, `UniqueID` does not keep the file handles open. The fact that file 
IDs were stable until now is only due to a NTFS implementation detail 
. In 
some cases, such as drives mounted on network locations, the underlying Windows 
drivers might or might not generate stable file IDs.

To fix the issue, we keep the file handles open during the lifetime of their 
corresponding `UniqueID` instances. Since handles will live longer now, this 
requires particular attention when performing some file actions, such as file 
deletions.

Should fix #61401  and 
#22079 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146490

Files:
  clang-tools-extra/clangd/unittests/FSTests.cpp
  clang/include/clang/Basic/FileEntry.h
  clang/lib/Basic/FileEntry.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp
  clang/tools/libclang/Indexing.cpp
  clang/unittests/Basic/FileManagerTest.cpp
  llvm/include/llvm/Support/FileSystem.h
  llvm/include/llvm/Support/FileSystem/UniqueID.h
  llvm/include/llvm/Support/Windows/ScopedHandle.h
  llvm/include/llvm/Support/Windows/WindowsSupport.h
  llvm/lib/Support/VirtualFileSystem.cpp
  llvm/lib/Support/Windows/Path.inc
  llvm/unittests/Support/FSUniqueIDTest.cpp
  llvm/unittests/Support/Path.cpp
  llvm/unittests/Support/VirtualFileSystemTest.cpp
  llvm/utils/split-file/split-file.cpp

Index: llvm/utils/split-file/split-file.cpp
===
--- llvm/utils/split-file/split-file.cpp
+++ llvm/utils/split-file/split-file.cpp
@@ -162,14 +162,16 @@
 
   // Delete output if it is a file or an empty directory, so that we can create
   // a directory.
-  sys::fs::file_status status;
-  if (std::error_code ec = sys::fs::status(output, status))
-if (ec.value() != static_cast(std::errc::no_such_file_or_directory))
-  fatal(output, ec.message());
-  if (status.type() != sys::fs::file_type::file_not_found &&
-  status.type() != sys::fs::file_type::directory_file &&
-  status.type() != sys::fs::file_type::regular_file)
-fatal(output, "output cannot be a special file");
+  {
+sys::fs::file_status status;
+if (std::error_code ec = sys::fs::status(output, status))
+  if (ec.value() != static_cast(std::errc::no_such_file_or_directory))
+fatal(output, ec.message());
+if (status.type() != sys::fs::file_type::file_not_found &&
+status.type() != sys::fs::file_type::directory_file &&
+status.type() != sys::fs::file_type::regular_file)
+  fatal(output, "output cannot be a special file");
+  }
   if (std::error_code ec = sys::fs::remove(output, /*IgnoreNonExisting=*/true))
 if (ec.value() != static_cast(std::errc::directory_not_empty) &&
 ec.value() != static_cast(std::errc::file_exists))
Index: llvm/unittests/Support/VirtualFileSystemTest.cpp
===
--- llvm/unittests/Support/VirtualFileSystemTest.cpp
+++ llvm/unittests/Support/VirtualFileSystemTest.cpp
@@ -151,24 +151,23 @@
 return FilesAndDirs.find(std::string(P.str()));
   }
 
+  UniqueID makeUniqueID() { return UniqueID::inMemory(FSID, FileID++); }
+
   void addRegularFile(StringRef Path, sys::fs::perms Perms = sys::fs::all_all) {
-vfs::Status S(Path, UniqueID(FSID, FileID++),
-  std::chrono::system_clock::now(), 0, 0, 1024,
-  sys::fs::file_type::regular_file, Perms);
+vfs::Status S(Path, makeUniqueID(), std::chrono::system_clock::now(), 0, 0,
+  1024, sys::fs::file_type::regular_file, Perms);
 addEntry(Path, S);
   }
 
   void addDirectory(StringRef Path, sys::fs::perms Perms = sys::fs::all_all) {
-vfs::Status S(Path, UniqueID(FSID, FileID++),
-  std::chrono::system_clock::now(), 0, 0, 0,
-  sys::fs::file_type::directory_file, Perms);
+vfs::Status S(Path,

[PATCH] D142224: [Support] Emulate SIGPIPE handling in raw_fd_ostream write for Windows

2023-02-24 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: llvm/lib/Support/Windows/Signals.inc:834
+  int RetCode = (int)EP->ExceptionRecord->ExceptionCode;
+  if (RetCode == (0xE000 | EX_IOERR))
+return;

erichkeane wrote:
> This patch seems to cause a self-build Werror regression.  The mask here is 
> large enough to cause the RHS of this to be unsigned, so the comparison hits 
> `-Wsign-compare`. See the example here https://godbolt.org/z/fa5q889jh
Please see rG1d0a5f11c04e6ac4dab578b81d02eabb83b31428


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D142224/new/

https://reviews.llvm.org/D142224

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D115103: Leak Sanitizer port to Windows

2023-02-20 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

@clemenswasser We hit this once in a while, when Microsoft update their 
libraries. But I'm surprised about the CC at the beginning. How can this issue 
be reproduced? Can you show a disassembly dump from the VS debugger, around the 
address of the function that fails?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115103/new/

https://reviews.llvm.org/D115103

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D115103: Leak Sanitizer port to Windows

2023-02-01 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

In D115103#4097460 , @clemenswasser 
wrote:

> Do you have a suggestion how I could fix this on MSVC

@clemenswasser The bug is there for years, I'm surprised it hasn't been fixed 
yet. MSVC doesn't support different types with bitfields. You should do:

  struct ChunkMetadata {
uint64_t allocated : 8;  // Must be first.
uint64_t tag : 2;
uint64_t requested_size : 54;
uint32_t stack_trace_id;
  };


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115103/new/

https://reviews.llvm.org/D115103

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D139167: [clang][Windows]Ignore Options '/d1nodatetime' and '/d1import_no_registry'

2022-12-03 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

In D139167#3967123 , @efriedma wrote:

> FYI, there's some discussion of /d1nodatetime floating around, even though it 
> isn't formally documented: it disables the definition of the `__DATE__`, 
> `__TIME__`, and `__TIMESTAMP__` macros.
>
> (No idea about d1import_no_registry, though.)

Those two options were introduced (I believe) along with the cl flag 
`/experimental:deterministic` (they actually alias to that flag, like -cc1 
flags do in Clang). `/d1import_no_registry` simply adds this attribute 
 
to all `#import` directives, to make them deterministic.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139167/new/

https://reviews.llvm.org/D139167

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D138746: [clang-format] Add .inc extension to git-clang-format

2022-12-03 Thread Alexandre Ganea via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rGae918c78b51a: [clang-format] Add .inc extension to 
git-clang-format (authored by aganea).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138746/new/

https://reviews.llvm.org/D138746

Files:
  clang/tools/clang-format/git-clang-format


Index: clang/tools/clang-format/git-clang-format
===
--- clang/tools/clang-format/git-clang-format
+++ clang/tools/clang-format/git-clang-format
@@ -88,7 +88,7 @@
   'c', 'h',  # C
   'm',  # ObjC
   'mm',  # ObjC++
-  'cc', 'cp', 'cpp', 'c++', 'cxx', 'hh', 'hpp', 'hxx',  # C++
+  'cc', 'cp', 'cpp', 'c++', 'cxx', 'hh', 'hpp', 'hxx', 'inc',  # C++
   'ccm', 'cppm', 'cxxm', 'c++m',  # C++ Modules
   'cu', 'cuh',  # CUDA
   # Other languages that clang-format supports


Index: clang/tools/clang-format/git-clang-format
===
--- clang/tools/clang-format/git-clang-format
+++ clang/tools/clang-format/git-clang-format
@@ -88,7 +88,7 @@
   'c', 'h',  # C
   'm',  # ObjC
   'mm',  # ObjC++
-  'cc', 'cp', 'cpp', 'c++', 'cxx', 'hh', 'hpp', 'hxx',  # C++
+  'cc', 'cp', 'cpp', 'c++', 'cxx', 'hh', 'hpp', 'hxx', 'inc',  # C++
   'ccm', 'cppm', 'cxxm', 'c++m',  # C++ Modules
   'cu', 'cuh',  # CUDA
   # Other languages that clang-format supports
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D138746: [clang-format] Add .inc extension to git-clang-format

2022-11-26 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea created this revision.
aganea added a reviewer: clang-format.
Herald added a project: All.
aganea requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The .inc extension isn't picked up for formatting when doing `git clang-format` 
on the LLVM repo. I'm not sure if we want this at large or more specific just 
for the LLVM codebase.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138746

Files:
  clang/tools/clang-format/git-clang-format


Index: clang/tools/clang-format/git-clang-format
===
--- clang/tools/clang-format/git-clang-format
+++ clang/tools/clang-format/git-clang-format
@@ -88,7 +88,7 @@
   'c', 'h',  # C
   'm',  # ObjC
   'mm',  # ObjC++
-  'cc', 'cp', 'cpp', 'c++', 'cxx', 'hh', 'hpp', 'hxx',  # C++
+  'cc', 'cp', 'cpp', 'c++', 'cxx', 'hh', 'hpp', 'hxx', 'inc',  # C++
   'ccm', 'cppm', 'cxxm', 'c++m',  # C++ Modules
   'cu', 'cuh',  # CUDA
   # Other languages that clang-format supports


Index: clang/tools/clang-format/git-clang-format
===
--- clang/tools/clang-format/git-clang-format
+++ clang/tools/clang-format/git-clang-format
@@ -88,7 +88,7 @@
   'c', 'h',  # C
   'm',  # ObjC
   'mm',  # ObjC++
-  'cc', 'cp', 'cpp', 'c++', 'cxx', 'hh', 'hpp', 'hxx',  # C++
+  'cc', 'cp', 'cpp', 'c++', 'cxx', 'hh', 'hpp', 'hxx', 'inc',  # C++
   'ccm', 'cppm', 'cxxm', 'c++m',  # C++ Modules
   'cu', 'cuh',  # CUDA
   # Other languages that clang-format supports
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D137101: [CodeView] Replace GHASH hasher by BLAKE3

2022-11-19 Thread Alexandre Ganea via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
aganea marked 2 inline comments as done.
Closed by commit rG49e483d3d62f: [CodeView] Replace GHASH hasher by BLAKE3 
(authored by aganea).
Herald added a reviewer: MaskRay.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D137101?vs=472098=476698#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137101/new/

https://reviews.llvm.org/D137101

Files:
  clang/docs/ReleaseNotes.rst
  lld/COFF/DebugTypes.cpp
  lld/docs/ReleaseNotes.rst
  llvm/include/llvm/DebugInfo/CodeView/TypeHashing.h
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
  llvm/lib/DebugInfo/CodeView/TypeHashing.cpp
  llvm/test/DebugInfo/COFF/global-type-hashes.ll
  llvm/test/DebugInfo/PDB/obj-globalhash.test

Index: llvm/test/DebugInfo/PDB/obj-globalhash.test
===
--- llvm/test/DebugInfo/PDB/obj-globalhash.test
+++ llvm/test/DebugInfo/PDB/obj-globalhash.test
@@ -14,41 +14,41 @@
 ; char**.  Both the local and global hashes should be the same, since the only
 ; back-references are for simple types which have fixed indices.
 CHECK-ONE:   obj-hashes-1
-CHECK-ONE:   TI: 0x1001, LocalHash: {{.*}}, GlobalHash: A7F8CF106F39A384
+CHECK-ONE:   TI: 0x1001, LocalHash: {{.*}}, GlobalHash: 912CE718D99C2F74
 CHECK-ONE:   obj-hashes-2
-CHECK-ONE:   TI: 0x1000, LocalHash: {{.*}}, GlobalHash: A7F8CF106F39A384
+CHECK-ONE:   TI: 0x1000, LocalHash: {{.*}}, GlobalHash: 912CE718D99C2F74
 
 ; int**.  Same as char**, both the local and global hashes should be the same.
 CHECK-TWO:   obj-hashes-1
-CHECK-TWO:   TI: 0x1000, LocalHash: {{.*}}, GlobalHash: 95D0616C5962F4B1
+CHECK-TWO:   TI: 0x1000, LocalHash: {{.*}}, GlobalHash: 20DAD105A7C67E1D
 CHECK-TWO:   obj-hashes-2
-CHECK-TWO:   TI: 0x1002, LocalHash: {{.*}}, GlobalHash: 95D0616C5962F4B1
+CHECK-TWO:   TI: 0x1002, LocalHash: {{.*}}, GlobalHash: 20DAD105A7C67E1D
 
 ; int***. Different local hashes, since the referent type (int**) is not at the
 ; same TypeIndex in both streams.  Same global hash, since they represent the
 ; same record.
 CHECK-THREE: obj-hashes-1
-CHECK-THREE: TI: 0x1002, LocalHash: {{.*}}, GlobalHash: 48D95F14F6176F4F
+CHECK-THREE: TI: 0x1002, LocalHash: {{.*}}, GlobalHash: 09CBAD68AF5C7998
 CHECK-THREE: obj-hashes-2
-CHECK-THREE: TI: 0x1001, LocalHash: {{.*}}, GlobalHash: 48D95F14F6176F4F
+CHECK-THREE: TI: 0x1001, LocalHash: {{.*}}, GlobalHash: 09CBAD68AF5C7998
 
 ; arg list (char**, int***).  Different local hashes, since the parameter types
 ; both occur at different TypeIndices in their respective input streams.  Same
 ; global hash, since the global hash of all referenced types is the same in
 ; both streams.
 CHECK-FOUR:  obj-hashes-1
-CHECK-FOUR:  TI: 0x1003, LocalHash: {{.*}}, GlobalHash: 99410CD14F5EE80D
+CHECK-FOUR:  TI: 0x1003, LocalHash: {{.*}}, GlobalHash: B6A17FFA392FDF6E
 CHECK-FOUR:  obj-hashes-2
-CHECK-FOUR:  TI: 0x1004, LocalHash: {{.*}}, GlobalHash: 99410CD14F5EE80D
+CHECK-FOUR:  TI: 0x1004, LocalHash: {{.*}}, GlobalHash: B6A17FFA392FDF6E
 
 ; double**.  This is only in stream 2, as a means to throw off the indexing.
 CHECK-FIVE:  obj-hashes-1
 CHECK-FIVE:  obj-hashes-2
-CHECK-FIVE:  TI: 0x1003, LocalHash: {{.*}}, GlobalHash: 20691EA9B88584CC
+CHECK-FIVE:  TI: 0x1003, LocalHash: {{.*}}, GlobalHash: 357B0B78DBFB83B4
 
 ; int** (char**, int***).  For the same logic as described in previous records,
 ; these two records have the same global hash but different local hashes.
 CHECK-SIX:   obj-hashes-1
-CHECK-SIX:   TI: 0x1004, LocalHash: {{.*}}, GlobalHash: 7ACF479173341AC1
+CHECK-SIX:   TI: 0x1004, LocalHash: {{.*}}, GlobalHash: 8356432DE786E196
 CHECK-SIX:   obj-hashes-2
-CHECK-SIX:   TI: 0x1005, LocalHash: {{.*}}, GlobalHash: 7ACF479173341AC1
+CHECK-SIX:   TI: 0x1005, LocalHash: {{.*}}, GlobalHash: 8356432DE786E196
Index: llvm/test/DebugInfo/COFF/global-type-hashes.ll
===
--- llvm/test/DebugInfo/COFF/global-type-hashes.ll
+++ llvm/test/DebugInfo/COFF/global-type-hashes.ll
@@ -21,129 +21,142 @@
 
 ; ModuleID = 'foo.cpp'
 source_filename = "foo.cpp"
-target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
+target datalayout = "e-m:x-p:32:32-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32-a:0:32-S32"
 target triple = "i686-pc-windows-msvc19.11.25547"
 
 %struct.Foo = type { i32, i32 }
 
-$"\01??0Foo@@QAE@HH@Z" = comdat any
+$"??0Foo@@QAE@HH@Z" = comdat any
 
-$"\01?method@Foo@@QAEHXZ" = comdat any
+$"?method@Foo@@QAEHXZ" = comdat any
 
-; Function Attrs: noinline norecurse nounwind optnone
-define i32 @main(i32 %argc, i8** %argv) #0 !dbg !8 {
+; Function Attrs: mustprogress noinline norecurse nounwind optnone
+define dso_local noundef i32 @main(i32 noundef %argc, ptr noundef %argv) #0 !dbg !8 {
 entry:
   %retval = alloca i32, align 4
-  %argv.addr

[PATCH] D136474: [CodeView][clang] Disable emitting command line into CodeView by default and add flag to enable

2022-10-27 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

In D136474#3888330 , @thakis wrote:

>> I read that, and I'm indicating that I don't agree. Chromium's requirements 
>> are driven by its particular usage of a cross-compiling distributed build 
>> system, which may not represent the average user's needs.
>
> Are you saying that it's a good thing if clang produces different output on 
> different hosts?

Objectively speaking, flags that change the terminal output, or more generally 
don't affect the output artifact, shouldn't be part of the reproducer. It was 
an oversight on my end when I initially implemented the feature. Back at 
Ubisoft we had the same goal as you do, ie. build for a given platform and end 
up with the same results, regardless of the host. But that was never completed 
after I left. My view is that we should first add the flag to allow disabling 
the reproducer, and then in subsequent patches try to remove irrelevant flags 
from the reproducer.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136474/new/

https://reviews.llvm.org/D136474

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126903: [clang] Add support for __builtin_memset_inline

2022-10-26 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

In D126903#3885114 , @gchatelet wrote:

> It should be fixed now @aganea . Can you check?

Works now, thanks again for the quick response. Should D136752 
 be cherry-picked into the 15.0 branch?

In D126903#3884748 , @thieta wrote:

> We have been building a two stage clang and our internal projects with this 
> version of rpmalloc and clang 15.x a while now and I haven't see the issue 
> you see @aganea. I don't think this patch is the problem as @efriedma 
> suggested, could be in rpmalloc but since I have used this successfully 
> already I am not sure about that either.

Is your internal build using the rpmalloc develop branch?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126903/new/

https://reviews.llvm.org/D126903

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126903: [clang] Add support for __builtin_memset_inline

2022-10-25 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

Hello @gchatelet! This patches introduces a regression in a two-stage build 
using rpmalloc on Windows. Bisection lead me here. Would you have a chance to 
take a look please? Thanks in advance.

To reproduce, I used the following script (rename to make_llvm.bat) F25053901: 
make_llvm.txt 

  C:\git\llvm-project>make_llvm.bat stage1
  ...
  C:\git\llvm-project>ninja clang lld -C stage1
  ...
  C:\git\llvm-project>make_llvm.bat stage2_rpmalloc
  ...
  C:\git\llvm-project>ninja lld -C stage2_rpmalloc

generates:

  [158/2714] Building C object 
lib\Support\CMakeFiles\LLVMSupport.dir\C_\git\rpmalloc\rpmalloc\rpmalloc.c.obj
  FAILED: 
lib/Support/CMakeFiles/LLVMSupport.dir/C_/git/rpmalloc/rpmalloc/rpmalloc.c.obj
  C:\git\llvm-project\stage1\bin\clang-cl.exe  /nologo -DENABLE_OVERRIDE 
-DENABLE_PRELOAD -DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS 
-D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS 
-D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -IC:\git\llvm-project\stage2_rpmalloc\lib\Support 
-IC:\git\llvm-project\llvm\lib\Support 
-IC:\git\llvm-project\stage2_rpmalloc\include 
-IC:\git\llvm-project\llvm\include /GS- /D_ITERATOR_DEBUG_LEVEL=0 -Xclang -O3 
-fstrict-aliasing -march=native -flto=thin -fwhole-program-vtables -fuse-ld=lld 
/Zc:inline /Zi -gcodeview-ghash /Zc:strictStrings /Oi /W4  -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers 
-Wimplicit-fallthrough -Wcovered-switch-default -Wstring-conversion 
-Wmisleading-indentation /Gw -flto=thin /MT /O2 /Ob2 /DNDEBUG /showIncludes 
/Folib\Support\CMakeFiles\LLVMSupport.dir\C_\git\rpmalloc\rpmalloc\rpmalloc.c.obj
 /Fdlib\Support\CMakeFiles\LLVMSupport.dir\LLVMSupport.pdb -c -- 
C:\git\rpmalloc\rpmalloc\rpmalloc.c
  Assertion failed: isa(Val) && "cast() argument of incompatible 
type!", file C:/git/llvm-project/llvm/include\llvm/Support/Casting.h, line 578
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.  Program arguments: C:\\git\\llvm-project\\stage1\\bin\\clang-cl.exe 
/nologo -DENABLE_OVERRIDE -DENABLE_PRELOAD -DGTEST_HAS_RTTI=0 -DUNICODE 
-D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS 
-D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 
-D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-IC:\\git\\llvm-project\\stage2_rpmalloc\\lib\\Support 
-IC:\\git\\llvm-project\\llvm\\lib\\Support 
-IC:\\git\\llvm-project\\stage2_rpmalloc\\include 
-IC:\\git\\llvm-project\\llvm\\include /GS- /D_ITERATOR_DEBUG_LEVEL=0 -Xclang 
-O3 -fstrict-aliasing -march=native -flto=thin -fwhole-program-vtables 
-fuse-ld=lld /Zc:inline /Zi -gcodeview-ghash /Zc:strictStrings /Oi /W4 -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers 
-Wimplicit-fallthrough -Wcovered-switch-default -Wstring-conversion 
-Wmisleading-indentation /Gw -flto=thin /MT /O2 /Ob2 /DNDEBUG /showIncludes 
/Folib\\Support\\CMakeFiles\\LLVMSupport.dir\\C_\\git\\rpmalloc\\rpmalloc\\rpmalloc.c.obj
 /Fdlib\\Support\\CMakeFiles\\LLVMSupport.dir\\LLVMSupport.pdb -c -- 
C:\\git\\rpmalloc\\rpmalloc\\rpmalloc.c
  1.   parser at end of file
  2.  Optimizer
   #0 0x7ff7f877ca86 HandleAbort 
C:\git\llvm-project\llvm\lib\Support\Windows\Signals.inc:418:0
   #1 0x7ff7fcdfc6bb raise 
C:\git\llvm-project\stage1\minkernel\crts\ucrt\src\appcrt\misc\signal.cpp:547:0
   #2 0x7ff7fcdf1ff4 abort 
C:\git\llvm-project\stage1\minkernel\crts\ucrt\src\appcrt\startup\abort.cpp:71:0
   #3 0x7ff7fcdf2672 common_assert_to_stderr 
C:\git\llvm-project\stage1\minkernel\crts\ucrt\src\appcrt\startup\assert.cpp:186:0
   #4 0x7ff7fcdf251a _wassert 
C:\git\llvm-project\stage1\minkernel\crts\ucrt\src\appcrt\startup\assert.cpp:443:0
   #5 0x7ff7f9b48e7b 
llvm::VNCoercion::analyzeLoadFromClobberingMemInst(class llvm::Type *, class 
llvm::Value *, class llvm::MemIntrinsic *, class llvm::DataLayout const &) 
C:\git\llvm-project\llvm\lib\Transforms\Utils\VNCoercion.cpp:381:0
   #6 0x7ff7f85a1ec4 llvm::GVNPass::AnalyzeLoadAvailability(class 
llvm::LoadInst *, class llvm::MemDepResult, class llvm::Value *, struct 
llvm::gvn::AvailableValue &) 
C:\git\llvm-project\llvm\lib\Transforms\Scalar\GVN.cpp:1211:0
   #7 0x7ff7f85a8a5c llvm::GVNPass::processLoad(class llvm::LoadInst *) 
C:\git\llvm-project\llvm\lib\Transforms\Scalar\GVN.cpp:2068:0
   #8 0x7ff7f85aa465 llvm::GVNPass::processInstruction(class 
llvm::Instruction *) 
C:\git\llvm-project\llvm\lib\Transforms\Scalar\GVN.cpp:2483:0
   #9 0x7ff7f85ab3ed llvm::GVNPass::processBlock(class llvm::BasicBlock *)

[PATCH] D136474: [CodeView][clang] Disable emitting command line into CodeView by default and add flag to enable

2022-10-25 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added subscribers: thieta, saudi.
aganea added a comment.

+@saudi @thieta


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136474/new/

https://reviews.llvm.org/D136474

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136474: [CodeView][clang] Add flag to disable emitting command line into CodeView

2022-10-21 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a subscriber: stefan_reinalter.
aganea added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:4354
+
+// Emit codeview command line if requested.
+if (Args.hasFlag(options::OPT_gcodeview_command_line,

aeubanks wrote:
> MaskRay wrote:
> > This needs a test in clang/test/Driver/
> > 
> > Use `addOptInFlag`
> `addOptIn/OutFlag` doesn't work here with the semantics I want
> 
> For -cc1, `-gcodeview-command-line` should control whether or not we use this 
> feature, defaulting to not performing this feature.
> But on the driver level, not specifying anything should pass 
> `-gcodeview-command-line` by default (assuming `EmitCodeView`).
> 
> But perhaps this is confusing and we should default to 
> `-gcodeview-command-line` everywhere?
Is there a reason for having divergent initial values? `true` below but 
`-gcodeview-command-line` being `false`? They should be the same. The other 
question is, MSVC emits LF_BUILDINFO by default (if /Z7 is on). Not sure if we 
should be compatible out-of-the-box or if we should favor good cache hits? I 
have no problem specifying the flag on the cmd-line if it isn't on by default.

+@stefan_reinalter 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136474/new/

https://reviews.llvm.org/D136474

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136474: [CodeView][clang] Add flag to disable emitting command line into CodeView

2022-10-21 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

Thanks for the patch @aeubanks and apologies for this oversight. I am wondering 
however if it wouldn’t make more sense to just strip this flag 
(-fmessage-length) from the emitted cmd-line? The goal is to provide a 
reproducer, this flag does not matter for that purpose.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136474/new/

https://reviews.llvm.org/D136474

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129152: [Clang][unittests] Silence trucation warning with MSVC

2022-07-05 Thread Alexandre Ganea via Phabricator via cfe-commits 
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0880b9d52620: [Clang][unittests] Silence trucation warning 
with MSVC 2022 (authored by aganea).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129152/new/

https://reviews.llvm.org/D129152

Files:
  clang/unittests/StaticAnalyzer/RangeSetTest.cpp


Index: clang/unittests/StaticAnalyzer/RangeSetTest.cpp
===
--- clang/unittests/StaticAnalyzer/RangeSetTest.cpp
+++ clang/unittests/StaticAnalyzer/RangeSetTest.cpp
@@ -88,6 +88,12 @@
   template 
   static constexpr T X555TruncZeroOf = TruncZeroOf; // 0x'5600
 
+// Silence 'warning C4309: 'initializing': truncation of constant value'
+//   in RangeSetCastToPromotionConversionTest.
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(push)
+#pragma warning(disable : 4309)
+#endif
   // Numbers for ranges with the same bits in the lowest byte.
   // 0x'AA2A
   static constexpr T FromA = ClearLowBytes + 42;
@@ -95,6 +101,10 @@
   // 0x'552A
   static constexpr T FromB = ClearLowBytes + 42;
   static constexpr T ToB = FromB + 2; // 0x'552C
+
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(pop)
+#endif
 };
 
 template 


Index: clang/unittests/StaticAnalyzer/RangeSetTest.cpp
===
--- clang/unittests/StaticAnalyzer/RangeSetTest.cpp
+++ clang/unittests/StaticAnalyzer/RangeSetTest.cpp
@@ -88,6 +88,12 @@
   template 
   static constexpr T X555TruncZeroOf = TruncZeroOf; // 0x'5600
 
+// Silence 'warning C4309: 'initializing': truncation of constant value'
+//   in RangeSetCastToPromotionConversionTest.
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(push)
+#pragma warning(disable : 4309)
+#endif
   // Numbers for ranges with the same bits in the lowest byte.
   // 0x'AA2A
   static constexpr T FromA = ClearLowBytes + 42;
@@ -95,6 +101,10 @@
   // 0x'552A
   static constexpr T FromB = ClearLowBytes + 42;
   static constexpr T ToB = FromB + 2; // 0x'552C
+
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(pop)
+#endif
 };
 
 template 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129152: [Clang][unittests] Silence trucation warning with MSVC

2022-07-05 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

Thanks all for reviewing!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129152/new/

https://reviews.llvm.org/D129152

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129152: [Clang][unittests] Silence trucation warning with MSVC

2022-07-05 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea updated this revision to Diff 442366.
aganea added a comment.

Use `#pragma`


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129152/new/

https://reviews.llvm.org/D129152

Files:
  clang/unittests/StaticAnalyzer/RangeSetTest.cpp


Index: clang/unittests/StaticAnalyzer/RangeSetTest.cpp
===
--- clang/unittests/StaticAnalyzer/RangeSetTest.cpp
+++ clang/unittests/StaticAnalyzer/RangeSetTest.cpp
@@ -88,6 +88,12 @@
   template 
   static constexpr T X555TruncZeroOf = TruncZeroOf; // 0x'5600
 
+// Silence 'warning C4309: 'initializing': truncation of constant value'
+//   in RangeSetCastToPromotionConversionTest.
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(push)
+#pragma warning(disable : 4309)
+#endif
   // Numbers for ranges with the same bits in the lowest byte.
   // 0x'AA2A
   static constexpr T FromA = ClearLowBytes + 42;
@@ -95,6 +101,10 @@
   // 0x'552A
   static constexpr T FromB = ClearLowBytes + 42;
   static constexpr T ToB = FromB + 2; // 0x'552C
+
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(pop)
+#endif
 };
 
 template 


Index: clang/unittests/StaticAnalyzer/RangeSetTest.cpp
===
--- clang/unittests/StaticAnalyzer/RangeSetTest.cpp
+++ clang/unittests/StaticAnalyzer/RangeSetTest.cpp
@@ -88,6 +88,12 @@
   template 
   static constexpr T X555TruncZeroOf = TruncZeroOf; // 0x'5600
 
+// Silence 'warning C4309: 'initializing': truncation of constant value'
+//   in RangeSetCastToPromotionConversionTest.
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(push)
+#pragma warning(disable : 4309)
+#endif
   // Numbers for ranges with the same bits in the lowest byte.
   // 0x'AA2A
   static constexpr T FromA = ClearLowBytes + 42;
@@ -95,6 +101,10 @@
   // 0x'552A
   static constexpr T FromB = ClearLowBytes + 42;
   static constexpr T ToB = FromB + 2; // 0x'552C
+
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(pop)
+#endif
 };
 
 template 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129152: [Clang][unittests] Silence trucation warning with MSVC

2022-07-05 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea created this revision.
aganea added reviewers: ASDenysPetrov, thieta, hans.
Herald added subscribers: steakhal, mgorny.
Herald added a project: All.
aganea requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

I'm seeing the following with MSVC 2022:

  C:\git\llvm-project\clang\unittests\StaticAnalyzer\RangeSetTest.cpp(97): 
warning C4309: 'initializing': truncation of constant value
  C:\git\llvm-project\clang\unittests\StaticAnalyzer\RangeSetTest.cpp(948): 
note: see reference to class template instantiation 
'`anonymous-namespace'::TestValues' being compiled
  C:\git\llvm-project\clang\unittests\StaticAnalyzer\RangeSetTest.cpp(942): 
note: while compiling class template member function 'void 
`anonymous-namespace'::RangeSetCastToPromotionConversionTest_Test_Test::TestBody(void)'

The issue here is that `RangeSetCastToPromotionConversionTest` tries to 
instantiate the template at L947, `using TV = TestValues;` which ends up 
trying to assign at L94, `static constexpr T ToA = FromA + 2;` which overflows 
with `T=char`. Ideally, we wouldn't need `FromA/ToA/FromB/ToB` for this test.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D129152

Files:
  clang/unittests/StaticAnalyzer/CMakeLists.txt


Index: clang/unittests/StaticAnalyzer/CMakeLists.txt
===
--- clang/unittests/StaticAnalyzer/CMakeLists.txt
+++ clang/unittests/StaticAnalyzer/CMakeLists.txt
@@ -20,6 +20,11 @@
   TestReturnValueUnderConstruction.cpp
   )
 
+if(MSVC)
+  # warning C4309: 'initializing': truncation of constant value
+  set_source_files_properties(RangeSetTest.cpp PROPERTIES COMPILE_FLAGS 
-wd4309)
+endif()
+
 clang_target_link_libraries(StaticAnalysisTests
   PRIVATE
   clangBasic


Index: clang/unittests/StaticAnalyzer/CMakeLists.txt
===
--- clang/unittests/StaticAnalyzer/CMakeLists.txt
+++ clang/unittests/StaticAnalyzer/CMakeLists.txt
@@ -20,6 +20,11 @@
   TestReturnValueUnderConstruction.cpp
   )
 
+if(MSVC)
+  # warning C4309: 'initializing': truncation of constant value
+  set_source_files_properties(RangeSetTest.cpp PROPERTIES COMPILE_FLAGS -wd4309)
+endif()
+
 clang_target_link_libraries(StaticAnalysisTests
   PRIVATE
   clangBasic
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86351: WIP: llvm-buildozer

2022-04-22 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: llvm/lib/Analysis/MemorySSA.cpp:89
 #ifdef EXPENSIVE_CHECKS
-bool llvm::VerifyMemorySSA = true;
+LLVM_THREAD_LOCAL bool llvm::VerifyMemorySSA = true;
 #else

arsenm wrote:
> Do command line flags like this really need to be thread local? Wouldn't ever 
> cl::opt need to be if this is?
This was only for the PoC.

Values pointed by `cl::opt`s -- that is either the internal `cl::opt` data or 
the static pointed by `cl::location` -- should be part of a context of some 
sort. LLD now has `CommonLinkerContext` plus a derived context per-driver. We 
probably need a "context" class along the same lines for the LLVM libs. Should 
it be part of `LLVMContextImpl`? Some options are read a bit earlier, before 
the `LLVMContext` is created.
The `cl::opt`s themselves can remain static.

Unless we assume `cl::opt`s are just for debugging, and move to tablegen any 
such globals that affect multi-threaded compilation?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86351/new/

https://reviews.llvm.org/D86351

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D119257: Revert "Re-land [LLD] Remove global state in lldCommon"

2022-02-08 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

@mehdi_amini  Just to unblock users, I've posted 
https://reviews.llvm.org/D119277 which fixes the issue originally raised by 
@krzysz00 
I'm also working on a more long term solution in 
https://reviews.llvm.org/D119049


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119257/new/

https://reviews.llvm.org/D119257

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D119257: Revert "Re-land [LLD] Remove global state in lldCommon"

2022-02-08 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

All things considered I think in the short term it is better to aim for small 
patches/fixes that can be transplanted to `release/14.x` if need be. I've 
posted D119277  for the issue you were seeing 
@krzysz00, but I am still planning on proper fix over the next week or so.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119257/new/

https://reviews.llvm.org/D119257

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D119257: Revert "Re-land [LLD] Remove global state in lldCommon"

2022-02-08 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

@krzysz00 I will revert and re-land with both fixes.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119257/new/

https://reviews.llvm.org/D119257

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118070: Make lld-link work in a non-MSVC shell

2022-02-02 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

In D118070#3289227 , @MaskRay wrote:

> I know that you  want a place to be accessed by both clang driver and 
> lld-link but I am a bit nervous about the clang-driver style MSVC library 
> sitting inside llvm/lib/Support/.
> Is there a better place? @compnerd @aganea

Does it make sense to add a new platform library? LLVMPlatformWindows? 
LLVMWindows? LLVMWindowsTools? LLVMWindowsABI?

> Makes lld-link work in a non-MSVC shell by autodetecting MSVC toolchain. Also 
> adds support for /winsysroot and a few other switches.

@pkasting Note, this patch makes the outcome non-deterministic when the 
auto-detection kicks in. We are stamping the command-line the .PDB file, see  
https://github.com/llvm/llvm-project/blob/main/lld/COFF/PDB.cpp#L1402 - and 
some live-code-patching tools rely on that to reproduce the link. It'd be nice 
if the detected paths are queued to `config->argv`, to ensure that we can emit 
a self-standing LLD cmd-line, a bit like what `clang -cc1` does.




Comment at: lld/COFF/Driver.h:122
   // Library search path. The first element is always "" (current directory).
-  std::vector searchPaths;
+  std::vector searchPaths;
 

You could also use `saver().save(...)` below and keep this member intact. That 
would save some memory allocations.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118070/new/

https://reviews.llvm.org/D118070

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118428: [clang-cl] Support the /JMC flag

2022-01-31 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:155
+- Add support for MSVC-compatible ``/JMC``/``/JMC-`` flag in clang-cl, and 
+  equivalent -cc1 flag ``-fjmc``. ``/JMC`` could only be used when ``/Zi`` or
+  ``/Z7`` is turned on. With this addition, clang-cl can be used in Visual

hans wrote:
> The cc1 flag is more of an implementation detail, so not sure it's worth 
> mentioning in the release notes. Or do we want "clang -fjmc" to work?
@ychen @hans An additional question is whether we want to use the same cc1 flag 
for an potential ELF port?



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:7458
+   /*Default=*/false)) {
+if (*EmitCodeView && *DebugInfoKind >= 
codegenoptions::DebugInfoConstructor)
+  CmdArgs.push_back("-fjmc");

hans wrote:
> Why that level specifically and not e.g. *DebugInfoKind > NoDebugInfo?
@hans MSVC does this check too, not sure why.
```
D:\git\llvm-project>cl main.cpp /c /JMC
Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30139 for ARM64
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line warning D9007 : '/JMC' requires '/Zi, /ZI or /Z7'; option 
ignored
main.cpp
```



Comment at: llvm/lib/CodeGen/JMCInstrumenter.cpp:111
+
+void createDefaultCheckFunction(Module , const char *CheckFunctionName,
+bool Is32Bit) {

hans wrote:
> What's the purpose of the default check function? Doesn't the CRT always 
> provide one? (And if it doesn't, will JMC work at all?)
@hans That's what MSVC does, to avoid a linker error if the CRT isn't linked in:
```
D:\git\llvm-project>cat main.cpp
int main() { }
D:\git\llvm-project>cl main.cpp /JMC /Z7 /c
Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30139 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

main.cpp

D:\git\llvm-project>dumpbin /disasm main.obj
Microsoft (R) COFF/PE Dumper Version 14.29.30139.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file main.obj

File Type: COFF OBJECT

main:
  : 48 83 EC 28sub rsp,28h
  0004: 48 8D 0D 00 00 00  lea rcx,[__BB04C4AD_main@cpp]
00
  000B: E8 00 00 00 00 call__CheckForDebuggerJustMyCode
  0010: 33 C0  xor eax,eax
  0012: 48 83 C4 28add rsp,28h
  0016: C3 ret

__JustMyCode_Default:
  : C2 00 00   ret 0

  Summary

  50 .chks64
 228 .debug$S
 3EC .debug$T
  70 .drectve
   1 .msvcjmc
   C .pdata
  1A .text$mn
   8 .xdata

D:\git\llvm-project>dumpbin /all main.obj | grep -B12 -A5 'COMDAT; sym= 
__JustMyCode_Default'
SECTION HEADER #5
.text$mn name
   0 physical address
   0 virtual address
   3 size of raw data
 438 file pointer to raw data (0438 to 043A)
   0 file pointer to relocation table
   0 file pointer to line numbers
   0 number of relocations
   0 number of line numbers
60501020 flags
 Code
 COMDAT; sym= __JustMyCode_Default
 16 byte align
 Execute Read

RAW DATA #5
  : C2 00 00 â–ˇ..
```



Comment at: llvm/lib/CodeGen/JMCInstrumenter.cpp:157
+  const char *CheckFunctionName = "__CheckForDebuggerJustMyCode";
+  bool Is32Bit = Triple(M.getTargetTriple()).getArch() == Triple::x86;
+

hans wrote:
> That's a very x86 specific check. What about other targets? (Also the calling 
> conventions are x86 specific..)
@ychen Worth nothing that /JMC works on ARM/ARM64 as well. Should we support 
that too, not sure that's what @hans is implying?
```
D:\git\llvm-project>cl main.cpp /c /JMC /Z7
Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30139 for ARM64
Copyright (C) Microsoft Corporation.  All rights reserved.

main.cpp

D:\git\llvm-project>dumpbin /disasm main.obj
Microsoft (R) COFF/PE Dumper Version 14.29.30139.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file main.obj

File Type: COFF OBJECT

main:
  : A9BF7BFD  stp fp,lr,[sp,#-0x10]!
  0004: 910003FD  mov fp,sp
  0008: 9008  adrpx8,__BB04C4AD_main@cpp
  000C: 91000100  add x0,x8,__BB04C4AD_main@cpp
  0010: 9400  bl  __CheckForDebuggerJustMyCode
  0014: 5280  mov w0,#0
  0018: A8C17BFD  ldp fp,lr,[sp],#0x10
  001C: D65F03C0  ret

__JustMyCode_Default:
  : D65F03C0  ret

  Summary

  48 .chks64
 228 .debug$S
 3F0 .debug$T
  70 .drectve
   1 .msvcjmc
   8 .pdata
  24 .text$mn
```


Repository:
  rG LLVM

[PATCH] D118428: [clang-cl] Support the /JMC flag

2022-01-29 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a reviewer: mstorsjo.
aganea added a subscriber: belkiss.
aganea added a comment.

Cool! :) Seems good generally.
Sounds like an expensive flag for the runtime perf :-D But I guess it makes the 
debugging experience a bit nicer.




Comment at: clang/lib/Driver/ToolChains/Clang.cpp:7457
+   /*Default=*/false)) {
+if (EnabledZ7)
+  CmdArgs.push_back("-fjmc");

Can we do here `if (*EmitCodeView && *DebugInfoKind >= 
codegenoptions::DebugInfoConstructor)`? Is it worth introducing a new variable?



Comment at: clang/test/Driver/cl-options.c:782
+// JMCZ7: -fjmc
+
 void f() { }

Perhaps add a test `%clang_cl /JMC /JMC-`



Comment at: llvm/lib/CodeGen/JMCInstrumenter.cpp:131
+
+  // Add a linker options /alternatename to set the default implementation for
+  // the check function.

s/options/option/


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118428/new/

https://reviews.llvm.org/D118428

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116511: [clang-cl] Support the /HOTPATCH flag

2022-01-20 Thread Alexandre Ganea via Phabricator via cfe-commits 
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
aganea marked 3 inline comments as done.
Closed by commit rG5af2433e1794: [clang-cl] Support the /HOTPATCH flag 
(authored by aganea).

Changed prior to commit:
  https://reviews.llvm.org/D116511?vs=399168=401678#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116511/new/

https://reviews.llvm.org/D116511

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/MSVC.cpp
  clang/test/CodeGen/patchable-function-entry.c
  clang/test/CodeGenCXX/debug-info-hotpatch-arm.cpp
  clang/test/CodeGenCXX/debug-info-hotpatch.cpp
  clang/test/Driver/cl-options.c
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
  llvm/test/DebugInfo/COFF/ARMNT/arm-register-variables.ll
  llvm/test/MC/AArch64/coff-debug.ll

Index: llvm/test/MC/AArch64/coff-debug.ll
===
--- llvm/test/MC/AArch64/coff-debug.ll
+++ llvm/test/MC/AArch64/coff-debug.ll
@@ -77,7 +77,8 @@
 ; CHECK: Compile3Sym {
 ; CHECK:   Kind: S_COMPILE3 (0x113C)
 ; CHECK:   Language: C (0x0)
-; CHECK:   Flags [ (0x0)
+; CHECK:   Flags [ (0x4000
+; CHECK:HotPatch (0x4000)
 ; CHECK:   ]
 ; CHECK: }
 ; CHECK:   ]
Index: llvm/test/DebugInfo/COFF/ARMNT/arm-register-variables.ll
===
--- llvm/test/DebugInfo/COFF/ARMNT/arm-register-variables.ll
+++ llvm/test/DebugInfo/COFF/ARMNT/arm-register-variables.ll
@@ -24,7 +24,8 @@
 ;  OBJ:   Compile3Sym {
 ; OBJ-NEXT: Kind: S_COMPILE3 (0x113C)
 ; OBJ-NEXT: Language: C (0x0)
-; OBJ-NEXT: Flags [ (0x0)
+; OBJ-NEXT: Flags [ (0x4000)
+; OBJ-NEXT:   HotPatch (0x4000)
 ; OBJ-NEXT: ]
 ; OBJ-NEXT: Machine: ARMNT (0xF4)
 
Index: llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
+++ llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
@@ -846,6 +846,12 @@
   if (MMI->getModule()->getProfileSummary(/*IsCS*/ false) != nullptr) {
 Flags |= static_cast(CompileSym3Flags::PGO);
   }
+  using ArchType = llvm::Triple::ArchType;
+  ArchType Arch = Triple(MMI->getModule()->getTargetTriple()).getArch();
+  if (Asm->TM.Options.Hotpatch || Arch == ArchType::thumb ||
+  Arch == ArchType::aarch64) {
+Flags |= static_cast(CompileSym3Flags::HotPatch);
+  }
 
   OS.AddComment("Flags and language");
   OS.emitInt32(Flags);
Index: llvm/include/llvm/Target/TargetOptions.h
===
--- llvm/include/llvm/Target/TargetOptions.h
+++ llvm/include/llvm/Target/TargetOptions.h
@@ -140,9 +140,9 @@
   EnableMachineFunctionSplitter(false), SupportsDefaultOutlining(false),
   EmitAddrsig(false), EmitCallSiteInfo(false),
   SupportsDebugEntryValues(false), EnableDebugEntryValues(false),
-  ValueTrackingVariableLocations(false),
-  ForceDwarfFrameSection(false), XRayOmitFunctionIndex(false),
-  DebugStrictDwarf(false),
+  ValueTrackingVariableLocations(false), ForceDwarfFrameSection(false),
+  XRayOmitFunctionIndex(false), DebugStrictDwarf(false),
+  Hotpatch(false),
   FPDenormalMode(DenormalMode::IEEE, DenormalMode::IEEE) {}
 
 /// DisableFramePointerElim - This returns true if frame pointer elimination
@@ -342,6 +342,9 @@
 /// By default, it is set to false.
 unsigned DebugStrictDwarf : 1;
 
+/// Emit the hotpatch flag in CodeView debug.
+unsigned Hotpatch : 1;
+
 /// Name of the stack usage file (i.e., .su file) if user passes
 /// -fstack-usage. If empty, it can be implied that -fstack-usage is not
 /// passed on the command line.
Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -118,6 +118,9 @@
 // RUN: %clang_cl /Gw /Gw- -### -- %s 2>&1 | FileCheck -check-prefix=Gw_ %s
 // Gw_-NOT: -fdata-sections
 
+// RUN: %clang_cl /hotpatch -### -- %s 2>&1 | FileCheck -check-prefix=hotpatch %s
+// hotpatch: -fms-hotpatch
+
 // RUN: %clang_cl /Imyincludedir -### -- %s 2>&1 | FileCheck -check-prefix=SLASH_I %s
 // RUN: %clang_cl /I myincludedir -### -- %s 2>&1 | FileCheck -check-prefix=SLASH_I %s
 // SLASH_I: "-I" "myincludedir"
@@ -483,7 +486,6 @@
 // RUN: /GZ \
 // RUN: /H \
 // RUN: /homeparams \
-// RUN: /hotpatch \
 // RUN: /JMC \
 // RUN: /kernel \
 // RUN: /LN \
Index: clang/test/CodeGenCXX/debug-info-hotpatch.cpp

[PATCH] D80833: [CodeView] Add full repro to LF_BUILDINFO record

2022-01-19 Thread Alexandre Ganea via Phabricator via cfe-commits 
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGaba5b91b699c: Re-land [CodeView] Add full repro to 
LF_BUILDINFO record (authored by aganea).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80833/new/

https://reviews.llvm.org/D80833

Files:
  clang/cmake/caches/BaremetalARM.cmake
  clang/cmake/caches/CrossWinToARMLinux.cmake
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/test/CodeGen/debug-info-codeview-buildinfo.c
  lld/test/COFF/Inputs/pdb_lines_1_relative.yaml
  lld/test/COFF/Inputs/pdb_lines_2_relative.yaml
  lld/test/COFF/pdb-relative-source-lines.test
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
  llvm/test/DebugInfo/COFF/build-info.ll
  llvm/test/DebugInfo/COFF/global-type-hashes.ll
  llvm/test/DebugInfo/COFF/types-basic.ll
  llvm/test/DebugInfo/COFF/types-data-members.ll

Index: llvm/test/DebugInfo/COFF/types-data-members.ll
===
--- llvm/test/DebugInfo/COFF/types-data-members.ll
+++ llvm/test/DebugInfo/COFF/types-data-members.ll
@@ -727,14 +727,22 @@
 ; ASM: .asciz	"t.cpp" # StringData
 ; ASM: .byte	242
 ; ASM: .byte	241
-; ASM: # BuildInfo (0x1022)
+; ASM: # StringId (0x1022)
+; ASM: .short	0xa # Record length
+; ASM: .short	0x1605  # Record kind: LF_STRING_ID
+; ASM: .long	0x0 # Id
+; ASM: .byte0   # StringData
+; ASM: .byte	243
+; ASM: .byte	242
+; ASM: .byte	241
+; ASM: # BuildInfo (0x1023)
 ; ASM: .short	0x1a# Record length
 ; ASM: .short	0x1603  # Record kind: LF_BUILDINFO
 ; ASM: .short	0x5 # NumArgs
 ; ASM: .long	0x1020  # Argument: D:\src\llvm\build
 ; ASM: .long	0x0 # Argument
 ; ASM: .long	0x1021  # Argument: t.cpp
-; ASM: .long	0x0 # Argument
+; ASM: .long	0x1022  # Argument
 ; ASM: .long	0x0 # Argument
 ; ASM: .byte	242
 ; ASM: .byte	241
Index: llvm/test/DebugInfo/COFF/types-basic.ll
===
--- llvm/test/DebugInfo/COFF/types-basic.ll
+++ llvm/test/DebugInfo/COFF/types-basic.ll
@@ -511,14 +511,22 @@
 ; ASM: .asciz	"t.cpp" # StringData
 ; ASM: .byte	242
 ; ASM: .byte	241
-; ASM: # BuildInfo (0x1015)
+; ASM: # StringId (0x1015)
+; ASM: .short	0xa # Record length
+; ASM: .short	0x1605  # Record kind: LF_STRING_ID
+; ASM: .long	0x0 # Id
+; ASM: .byte0   # StringData
+; ASM: .byte	243
+; ASM: .byte	242
+; ASM: .byte	241
+; ASM: # BuildInfo (0x1016)
 ; ASM: .short	0x1a# Record length
 ; ASM: .short	0x1603  # Record kind: LF_BUILDINFO
 ; ASM: .short	0x5 # NumArgs
 ; ASM: .long	0x1013  # Argument: D:\src\llvm\build
 ; ASM: .long	0x0 # Argument
 ; ASM: .long	0x1014  # Argument: t.cpp
-; ASM: .long	0x0 # Argument
+; ASM: .long	0x1015  # Argument
 ; ASM: .long	0x0 # Argument
 ; ASM: .byte	242
 ; ASM: .byte	241
Index: llvm/test/DebugInfo/COFF/global-type-hashes.ll
===
--- llvm/test/DebugInfo/COFF/global-type-hashes.ll
+++ llvm/test/DebugInfo/COFF/global-type-hashes.ll
@@ -295,7 +295,8 @@
 ; YAML: - 4470750F2E319329
 ; YAML: - 0FB556FD1FAB66D7
 ; YAML: - 5970EFB4874D0F3F
-; YAML: - EDB1D74C120CF44A
+; YAML: - D8EF11198C33843F
+; YAML: - D81F744D7366282B
 ; ...
 
 
Index: llvm/test/DebugInfo/COFF/build-info.ll
===
--- llvm/test/DebugInfo/COFF/build-info.ll
+++ llvm/test/DebugInfo/COFF/build-info.ll
@@ -5,7 +5,7 @@
 ; CHECK-NEXT:  0x{{.*}}: `D:\src\scopes\clang`
 ; CHECK-NEXT:  : ``
 ; CHECK-NEXT:  0x{{.*}}: `D:\src\scopes\foo.cpp`
-; CHECK-NEXT:  : ``
+; CHECK-NEXT:  0x{{.*}}: ``
 ; CHECK-NEXT:  : ``
 
 ; CHECK: {{.*}} | S_BUILDINFO [size = 8] BuildId = `[[INFO_IDX]]`
Index: llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
+++ llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
@@ -68,6 +68,7 @@
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/Program.h"
 #include "llvm/Support/SMLoc.h"
 #include "llvm/Support/ScopedPrinter.h"
 #include "llvm/Target/TargetLoweringObjectFile.h"
@@ -889,6 +890,34 @@
   return TypeTable.writeLeafType(SIR);
 }
 
+static std::string flattenCommandLine(ArrayRef Args,
+

[PATCH] D116861: [UBSan] Fix incorrect alignment reported when global new returns an offset pointer

2022-01-13 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added subscribers: hans, rnk, aganea.
aganea added reviewers: hans, rnk.
aganea added a comment.

+@hans @rnk Since we discussed this in one of the past Windows/COFF calls.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116861/new/

https://reviews.llvm.org/D116861

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116511: [clang-cl] Support the /HOTPATCH flag

2022-01-12 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea marked 2 inline comments as done.
aganea added inline comments.



Comment at: clang/test/CodeGenCXX/debug-info-hotpatch-arm.cpp:13
+// RUN: llvm-pdbutil dump -symbols %t.obj | FileCheck %s 
--check-prefix=HOTPATCH
+// ERR-HOTPATCH: error: unsupported option '/hotpatch' for target
+// HOTPATCH: S_COMPILE3 [size = [[#]]]

hans wrote:
> Does MSVC error for ARM/ARM64 too, or does it just ignore the flag?
It prints a warning:
```
D:\git\llvm-project>cl /c main.cpp /hotpatch
Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30138 for ARM64
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line warning D9002 : ignoring unknown option '/hotpatch'
main.cpp
```
But in our case, the issue is that `PATCHABLE_OP` isn't supported on ARM 
backend, so it ends up asserting in 
`D:/git/llvm-project/release/lib/Target/AArch64/AArch64GenMCCodeEmitter.inc` in 
`AArch64MCCodeEmitter::getBinaryCodeForInstr`. There's perhaps a (better?) way 
for shortcutting the use of `/hotpatch` on ARM, instead of erroring-out like 
today.

Should we be more clear in the message, saying that hotpatching is supported 
but we don't the flag? Or just consume and ignore it?



Comment at: clang/test/CodeGenCXX/debug-info-hotpatch-arm.cpp:19
+///
+// RUN: %clang_cl --target=aarch64-pc-windows-msvc /c %s -o %t.obj
+// RUN: llvm-pdbutil dump -symbols %t.obj | FileCheck %s 
--check-prefix=NO-HOTPATCH

hans wrote:
> nit: We still need -- before %s with clang-cl (%s could be /Users/... and get 
> interpreted as a flag), and so it needs to come last. Same for the line in 
> debug-info-hotpatch.cpp.
Thanks will do!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116511/new/

https://reviews.llvm.org/D116511

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116511: [clang-cl] Support the /HOTPATCH flag

2022-01-11 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: clang/include/clang/Driver/Options.td:2493
   MarshallingInfoInt>;
+def fhotpatch : Flag<["-"], "fhotpatch">, Group, Flags<[CC1Option]>,
+  HelpText<"Ensure that all functions can be hotpatched at runtime">,

hans wrote:
> Is this flag also exposed as a driver flag, or is it cc1 only?
> 
> I wonder if we should go for a less generic name here, perhaps -fms-hotpatch? 
> For example, the flag above is also about hotpatching, but a different 
> mechanism.
Added `CoreOption`. Changed to `-fms-hotpatch`.



Comment at: clang/lib/CodeGen/BackendUtil.cpp:648
   Options.ObjectFilenameForDebug = CodeGenOpts.ObjectFilenameForDebug;
+  Options.Hotpatch = CodeGenOpts.HotPatch;
 

hans wrote:
> Since it's currently only supported on x86_64, we should probably diagnose 
> trying to use it for other target somewhere.
Actually the whole thing works on ARM/ARM64, it just that these targets don't 
need the PATCHABLE_OP thing (since they always generate 16-bit/32-bit 
instructions).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116511/new/

https://reviews.llvm.org/D116511

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116511: [clang-cl] Support the /HOTPATCH flag

2022-01-11 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea updated this revision to Diff 399168.
aganea marked 4 inline comments as done.
aganea edited the summary of this revision.
aganea added a comment.
Herald added a subscriber: kristof.beyls.

As suggested by @hans

Also added test coverage for ARM/ARM64.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116511/new/

https://reviews.llvm.org/D116511

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/MSVC.cpp
  clang/test/CodeGen/patchable-function-entry.c
  clang/test/CodeGenCXX/debug-info-hotpatch-arm.cpp
  clang/test/CodeGenCXX/debug-info-hotpatch.cpp
  clang/test/Driver/cl-options.c
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp

Index: llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
+++ llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
@@ -845,6 +845,12 @@
   if (MMI->getModule()->getProfileSummary(/*IsCS*/ false) != nullptr) {
 Flags |= static_cast(CompileSym3Flags::PGO);
   }
+  using ArchType = llvm::Triple::ArchType;
+  ArchType Arch = Triple(MMI->getModule()->getTargetTriple()).getArch();
+  if (Asm->TM.Options.Hotpatch || Arch == ArchType::thumb ||
+  Arch == ArchType::aarch64) {
+Flags |= static_cast(CompileSym3Flags::HotPatch);
+  }
 
   OS.AddComment("Flags and language");
   OS.emitInt32(Flags);
Index: llvm/include/llvm/Target/TargetOptions.h
===
--- llvm/include/llvm/Target/TargetOptions.h
+++ llvm/include/llvm/Target/TargetOptions.h
@@ -140,9 +140,9 @@
   EnableMachineFunctionSplitter(false), SupportsDefaultOutlining(false),
   EmitAddrsig(false), EmitCallSiteInfo(false),
   SupportsDebugEntryValues(false), EnableDebugEntryValues(false),
-  ValueTrackingVariableLocations(false),
-  ForceDwarfFrameSection(false), XRayOmitFunctionIndex(false),
-  DebugStrictDwarf(false),
+  ValueTrackingVariableLocations(false), ForceDwarfFrameSection(false),
+  XRayOmitFunctionIndex(false), DebugStrictDwarf(false),
+  Hotpatch(false),
   FPDenormalMode(DenormalMode::IEEE, DenormalMode::IEEE) {}
 
 /// DisableFramePointerElim - This returns true if frame pointer elimination
@@ -342,6 +342,9 @@
 /// By default, it is set to false.
 unsigned DebugStrictDwarf : 1;
 
+/// Emit the hotpatch flag in CodeView debug.
+unsigned Hotpatch : 1;
+
 /// Name of the stack usage file (i.e., .su file) if user passes
 /// -fstack-usage. If empty, it can be implied that -fstack-usage is not
 /// passed on the command line.
Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -118,6 +118,9 @@
 // RUN: %clang_cl /Gw /Gw- -### -- %s 2>&1 | FileCheck -check-prefix=Gw_ %s
 // Gw_-NOT: -fdata-sections
 
+// RUN: %clang_cl /hotpatch -### -- %s 2>&1 | FileCheck -check-prefix=hotpatch %s
+// hotpatch: -fms-hotpatch
+
 // RUN: %clang_cl /Imyincludedir -### -- %s 2>&1 | FileCheck -check-prefix=SLASH_I %s
 // RUN: %clang_cl /I myincludedir -### -- %s 2>&1 | FileCheck -check-prefix=SLASH_I %s
 // SLASH_I: "-I" "myincludedir"
@@ -483,7 +486,6 @@
 // RUN: /GZ \
 // RUN: /H \
 // RUN: /homeparams \
-// RUN: /hotpatch \
 // RUN: /JMC \
 // RUN: /kernel \
 // RUN: /LN \
Index: clang/test/CodeGenCXX/debug-info-hotpatch.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/debug-info-hotpatch.cpp
@@ -0,0 +1,19 @@
+// REQUIRES: x86-registered-target
+///
+// RUN: %clang_cl --target=x86_64-windows-msvc /c /hotpatch /Z7 -o %t.obj -- %s
+// RUN: llvm-pdbutil dump -symbols %t.obj | FileCheck %s --check-prefix=HOTPATCH
+// HOTPATCH: S_COMPILE3 [size = [[#]]]
+// HOTPATCH: flags = hot patchable
+///
+// RUN: %clang_cl --target=x86_64-windows-msvc /c /Z7 -o %t.obj -- %s
+// RUN: llvm-pdbutil dump -symbols %t.obj | FileCheck %s --check-prefix=NO-HOTPATCH
+// NO-HOTPATCH-NOT: flags = hot patchable
+///
+// RUN: %clang_cl --target=x86_64-windows-msvc /hotpatch -### %s 2>&1 | FileCheck %s --check-prefix=FUNCTIONPADMIN
+// FUNCTIONPADMIN: clang{{.*}}
+// FUNCTIONPADMIN: {{link.*"}}
+// FUNCTIONPADMIN: -functionpadmin
+
+int main() {
+  return 0;
+}
Index: clang/test/CodeGenCXX/debug-info-hotpatch-arm.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/debug-info-hotpatch-arm.cpp
@@ -0,0 +1,25 @@
+// REQUIRES: aarch64-registered-target || arm-registered-target
+///
+/// Binaries are always

[PATCH] D116266: [SPIR-V] Add linking of separate translation units using spirv-link

2022-01-11 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: clang/test/Driver/spirv-toolchain.cl:71
+// SPLINK: {{llvm-spirv.*"}} [[BC]] "-o" [[SPV2:".*o"]]
+// SPLINK: {{"spirv-link.*"}} [[SPV1]] [[SPV2]] "-o" "a.out"

svenvh wrote:
> aganea wrote:
> > Hello @Anastasia, this line fails on my machine. It works with `// SPLINK: 
> > spirv-link{{.*}} [[SPV1]] [[SPV2]] "-o" "a.out"
> > `
> > 
> > See output with the error:
> > ```
> > FAIL: Clang :: Driver/spirv-toolchain.cl (579 of 81682)
> >  TEST 'Clang :: Driver/spirv-toolchain.cl' FAILED 
> > 
> > Script:
> > --
> > : 'RUN: at line 2';   d:\git\llvm-project\release\bin\clang.exe -### 
> > --target=spirv64 -x cl -c 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
> > d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV64 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
> > : 'RUN: at line 3';   d:\git\llvm-project\release\bin\clang.exe -### 
> > --target=spirv64 D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 
> > 2>&1 | d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV64 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
> > : 'RUN: at line 4';   d:\git\llvm-project\release\bin\clang.exe -### 
> > --target=spirv64 -x ir -c 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
> > d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV64 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
> > : 'RUN: at line 5';   d:\git\llvm-project\release\bin\clang.exe -### 
> > --target=spirv64 -x clcpp -c 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
> > d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV64 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
> > : 'RUN: at line 6';   d:\git\llvm-project\release\bin\clang.exe -### 
> > --target=spirv64 -x c -c 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
> > d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV64 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
> > : 'RUN: at line 12';   d:\git\llvm-project\release\bin\clang.exe -### 
> > --target=spirv32 -x cl -c 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
> > d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV32 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
> > : 'RUN: at line 13';   d:\git\llvm-project\release\bin\clang.exe -### 
> > --target=spirv32 D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 
> > 2>&1 | d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV32 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
> > : 'RUN: at line 14';   d:\git\llvm-project\release\bin\clang.exe -### 
> > --target=spirv32 -x ir -c 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
> > d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV32 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
> > : 'RUN: at line 15';   d:\git\llvm-project\release\bin\clang.exe -### 
> > --target=spirv32 -x clcpp -c 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
> > d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV32 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
> > : 'RUN: at line 16';   d:\git\llvm-project\release\bin\clang.exe -### 
> > --target=spirv32 -x c -c 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
> > d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV32 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
> > : 'RUN: at line 24';   d:\git\llvm-project\release\bin\clang.exe -### 
> > --target=spirv64 -x cl -S 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
> > d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPT64 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
> > : 'RUN: at line 25';   d:\git\llvm-project\release\bin\clang.exe -### 
> > --target=spirv64 -x ir -S 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
> > d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPT64 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
> > : 'RUN: at line 26';   d:\git\llvm-project\release\bin\clang.exe -### 
> > --target=spirv64 -x clcpp -c 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
> > d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV64 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
> > : 'RUN: at line 27';   d:\git\llvm-project\release\bin\clang.exe -### 
> > --target=spirv64 -x c -S 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
> > d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPT64 
> > D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
> > : 'RUN: at line 33';   d:\git\llvm-project\release\bin\clang.exe -### 
> >

[PATCH] D116266: [SPIR-V] Add linking of separate translation units using spirv-link

2022-01-11 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: clang/test/Driver/spirv-toolchain.cl:71
+// SPLINK: {{llvm-spirv.*"}} [[BC]] "-o" [[SPV2:".*o"]]
+// SPLINK: {{"spirv-link.*"}} [[SPV1]] [[SPV2]] "-o" "a.out"

Hello @Anastasia, this line fails on my machine. It works with `// SPLINK: 
spirv-link{{.*}} [[SPV1]] [[SPV2]] "-o" "a.out"
`

See output with the error:
```
FAIL: Clang :: Driver/spirv-toolchain.cl (579 of 81682)
 TEST 'Clang :: Driver/spirv-toolchain.cl' FAILED 

Script:
--
: 'RUN: at line 2';   d:\git\llvm-project\release\bin\clang.exe -### 
--target=spirv64 -x cl -c 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV64 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
: 'RUN: at line 3';   d:\git\llvm-project\release\bin\clang.exe -### 
--target=spirv64 D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 
| d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV64 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
: 'RUN: at line 4';   d:\git\llvm-project\release\bin\clang.exe -### 
--target=spirv64 -x ir -c 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV64 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
: 'RUN: at line 5';   d:\git\llvm-project\release\bin\clang.exe -### 
--target=spirv64 -x clcpp -c 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV64 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
: 'RUN: at line 6';   d:\git\llvm-project\release\bin\clang.exe -### 
--target=spirv64 -x c -c 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV64 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
: 'RUN: at line 12';   d:\git\llvm-project\release\bin\clang.exe -### 
--target=spirv32 -x cl -c 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV32 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
: 'RUN: at line 13';   d:\git\llvm-project\release\bin\clang.exe -### 
--target=spirv32 D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 
| d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV32 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
: 'RUN: at line 14';   d:\git\llvm-project\release\bin\clang.exe -### 
--target=spirv32 -x ir -c 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV32 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
: 'RUN: at line 15';   d:\git\llvm-project\release\bin\clang.exe -### 
--target=spirv32 -x clcpp -c 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV32 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
: 'RUN: at line 16';   d:\git\llvm-project\release\bin\clang.exe -### 
--target=spirv32 -x c -c 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV32 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
: 'RUN: at line 24';   d:\git\llvm-project\release\bin\clang.exe -### 
--target=spirv64 -x cl -S 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPT64 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
: 'RUN: at line 25';   d:\git\llvm-project\release\bin\clang.exe -### 
--target=spirv64 -x ir -S 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPT64 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
: 'RUN: at line 26';   d:\git\llvm-project\release\bin\clang.exe -### 
--target=spirv64 -x clcpp -c 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPV64 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
: 'RUN: at line 27';   d:\git\llvm-project\release\bin\clang.exe -### 
--target=spirv64 -x c -S 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPT64 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
: 'RUN: at line 33';   d:\git\llvm-project\release\bin\clang.exe -### 
--target=spirv32 -x cl -S 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl 2>&1 | 
d:\git\llvm-project\release\bin\filecheck.exe --check-prefix=SPT32 
D:\git\llvm-project\clang\test\Driver\spirv-toolchain.cl
: 'RUN: at line 34';   d:\git\llvm-project\release\bin\clang.exe -### 
--target=spirv32 -x ir -S

[PATCH] D115103: Leak Sanitizer port to Windows

2022-01-06 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

It does work indeed. I am running under a "x64 Native Tools Command Prompt for 
VS 2019" prompt with MSVC 16.11.8.

  D:\git\llvm-project>mkdir release && cd release
  D:\git\llvm-project\release>cmake ../llvm -G Ninja 
-DLLVM_ENABLE_PROJECTS="clang;lld;llvm;compiler-rt" -DCMAKE_BUILD_TYPE=Release 
-DLLVM_ENABLE_PDB=ON -DLLVM_ENABLE_ASSERTIONS=ON
  ...
  D:\git\llvm-project\release>ninja check-asan
  ninja: Entering directory `release'
  [0/1] Running the AddressSanitizer tests
  -- Testing: 669 tests, 16 workers --
  Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
  
  Testing Time: 86.33s
Unsupported  : 229
Passed   : 426
Expectedly Failed:  14

However you might need some Unix tools that don't come out-of-the-box on 
Windows.
You could first install the scoop  package manager and then 
install any tool that you need:

  D:\git\llvm-project>powershell
  ...
  D:\git\llvm-project [main ↓9 +10 ~0 -0 !]> iwr -useb get.scoop.sh | iex
  ...
  D:\git\llvm-project [main ↓9 +10 ~0 -0 !]> scoop install coreutils grep make 
sed unxutils sysinternals

And then run `ninja check-asan` again.

If you install `sysinternals` with scoop above, you can run `procexp64` prior 
to `ninja check-asan`. That will give a much finer view on the running 
processes, as compared to the Task Manager. Let me know if I can help further.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115103/new/

https://reviews.llvm.org/D115103

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116370: [clang][dataflow] Add multi-variable constant propagation example.

2022-01-06 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: 
clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp:104
+  }
+}
+

Hello! I commit a tiny fix here, please see: 
rGa5af260d3e8b00a3353e813b73f83391edbef493


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116370/new/

https://reviews.llvm.org/D116370

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116313: [MSVC] Silence -Wnon-virtual-dtor on DIA APIs

2022-01-03 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a subscriber: dblaikie.
aganea added a comment.

I was wondering, can we mandate `LLVM_ENABLE_WERROR=ON` for all bots at least? 
(or maybe enable it through cmake, if ever there's a setting to detect we're 
running as a bot)
Or just reverse the default setting on the main branch, ie. make 
`LLVM_ENABLE_WERROR=ON` by default and let users disable it locally. I think 
that would encourage users to care more about warnings? Release branches could 
have it disabled somehow, to accommodate for the changing compiler 
environments. Was this discussed before?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116313/new/

https://reviews.llvm.org/D116313

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116313: [MSVC] Silence -Wnon-virtual-dtor on DIA APIs

2022-01-03 Thread Alexandre Ganea via Phabricator via cfe-commits 
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe32936aef4a2: [MSVC] Silence -Wnon-virtual-dtor on DIA APIs 
(authored by aganea).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116313/new/

https://reviews.llvm.org/D116313

Files:
  clang/lib/Driver/ToolChains/MSVCSetupApi.h
  llvm/lib/DebugInfo/PDB/CMakeLists.txt


Index: llvm/lib/DebugInfo/PDB/CMakeLists.txt
===
--- llvm/lib/DebugInfo/PDB/CMakeLists.txt
+++ llvm/lib/DebugInfo/PDB/CMakeLists.txt
@@ -4,7 +4,7 @@
 endmacro()
 
 if(LLVM_ENABLE_DIA_SDK)
-  include_directories(${MSVC_DIA_SDK_DIR}/include)
+  include_directories(SYSTEM ${MSVC_DIA_SDK_DIR}/include)
   set(LIBPDB_LINK_FOLDERS "${MSVC_DIA_SDK_DIR}\\lib")
 
   if ("$ENV{VSCMD_ARG_TGT_ARCH}" STREQUAL "arm64")
Index: clang/lib/Driver/ToolChains/MSVCSetupApi.h
===
--- clang/lib/Driver/ToolChains/MSVCSetupApi.h
+++ clang/lib/Driver/ToolChains/MSVCSetupApi.h
@@ -28,6 +28,11 @@
 
 #pragma once
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wnon-virtual-dtor"
+#endif
+
 // Constants
 //
 #ifndef E_NOTFOUND
@@ -512,3 +517,7 @@
 #ifdef __cplusplus
 }
 #endif
+
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif


Index: llvm/lib/DebugInfo/PDB/CMakeLists.txt
===
--- llvm/lib/DebugInfo/PDB/CMakeLists.txt
+++ llvm/lib/DebugInfo/PDB/CMakeLists.txt
@@ -4,7 +4,7 @@
 endmacro()
 
 if(LLVM_ENABLE_DIA_SDK)
-  include_directories(${MSVC_DIA_SDK_DIR}/include)
+  include_directories(SYSTEM ${MSVC_DIA_SDK_DIR}/include)
   set(LIBPDB_LINK_FOLDERS "${MSVC_DIA_SDK_DIR}\\lib")
 
   if ("$ENV{VSCMD_ARG_TGT_ARCH}" STREQUAL "arm64")
Index: clang/lib/Driver/ToolChains/MSVCSetupApi.h
===
--- clang/lib/Driver/ToolChains/MSVCSetupApi.h
+++ clang/lib/Driver/ToolChains/MSVCSetupApi.h
@@ -28,6 +28,11 @@
 
 #pragma once
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wnon-virtual-dtor"
+#endif
+
 // Constants
 //
 #ifndef E_NOTFOUND
@@ -512,3 +517,7 @@
 #ifdef __cplusplus
 }
 #endif
+
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116313: [MSVC] Silence -Wnon-virtual-dtor on DIA APIs

2022-01-03 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116313/new/

https://reviews.llvm.org/D116313

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116313: [MSVC] Silence -Wnon-virtual-dtor on DIA APIs

2022-01-03 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: llvm/include/llvm/DebugInfo/PDB/DIA/DIASupport.h:34
+#endif
 #include 
+#ifdef __clang__

hans wrote:
> I thought this warning should be suppressed for system headers. Isn't that 
> working here?
Good point, because it wasn't included as a system header in the first place.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116313/new/

https://reviews.llvm.org/D116313

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116313: [MSVC] Silence -Wnon-virtual-dtor on DIA APIs

2022-01-03 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea updated this revision to Diff 397069.
aganea marked 2 inline comments as done.
aganea added a comment.
Herald added subscribers: hiraditya, mgorny.

As suggested by @hans


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116313/new/

https://reviews.llvm.org/D116313

Files:
  clang/lib/Driver/ToolChains/MSVCSetupApi.h
  llvm/lib/DebugInfo/PDB/CMakeLists.txt


Index: llvm/lib/DebugInfo/PDB/CMakeLists.txt
===
--- llvm/lib/DebugInfo/PDB/CMakeLists.txt
+++ llvm/lib/DebugInfo/PDB/CMakeLists.txt
@@ -4,7 +4,7 @@
 endmacro()
 
 if(LLVM_ENABLE_DIA_SDK)
-  include_directories(${MSVC_DIA_SDK_DIR}/include)
+  include_directories(SYSTEM ${MSVC_DIA_SDK_DIR}/include)
   set(LIBPDB_LINK_FOLDERS "${MSVC_DIA_SDK_DIR}\\lib")
 
   if ("$ENV{VSCMD_ARG_TGT_ARCH}" STREQUAL "arm64")
Index: clang/lib/Driver/ToolChains/MSVCSetupApi.h
===
--- clang/lib/Driver/ToolChains/MSVCSetupApi.h
+++ clang/lib/Driver/ToolChains/MSVCSetupApi.h
@@ -28,6 +28,11 @@
 
 #pragma once
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wnon-virtual-dtor"
+#endif
+
 // Constants
 //
 #ifndef E_NOTFOUND
@@ -512,3 +517,7 @@
 #ifdef __cplusplus
 }
 #endif
+
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif


Index: llvm/lib/DebugInfo/PDB/CMakeLists.txt
===
--- llvm/lib/DebugInfo/PDB/CMakeLists.txt
+++ llvm/lib/DebugInfo/PDB/CMakeLists.txt
@@ -4,7 +4,7 @@
 endmacro()
 
 if(LLVM_ENABLE_DIA_SDK)
-  include_directories(${MSVC_DIA_SDK_DIR}/include)
+  include_directories(SYSTEM ${MSVC_DIA_SDK_DIR}/include)
   set(LIBPDB_LINK_FOLDERS "${MSVC_DIA_SDK_DIR}\\lib")
 
   if ("$ENV{VSCMD_ARG_TGT_ARCH}" STREQUAL "arm64")
Index: clang/lib/Driver/ToolChains/MSVCSetupApi.h
===
--- clang/lib/Driver/ToolChains/MSVCSetupApi.h
+++ clang/lib/Driver/ToolChains/MSVCSetupApi.h
@@ -28,6 +28,11 @@
 
 #pragma once
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wnon-virtual-dtor"
+#endif
+
 // Constants
 //
 #ifndef E_NOTFOUND
@@ -512,3 +517,7 @@
 #ifdef __cplusplus
 }
 #endif
+
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116511: [clang-cl] Support the /HOTPATCH flag

2022-01-03 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea updated this revision to Diff 397063.
aganea added a subscriber: saudi.
aganea added a comment.

Fix tests.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116511/new/

https://reviews.llvm.org/D116511

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/patchable-function-entry.c
  clang/test/CodeGenCXX/debug-info-hotpatch.cpp
  clang/test/Driver/cl-options.c
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp

Index: llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
+++ llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
@@ -843,6 +843,8 @@
   if (MMI->getModule()->getProfileSummary(/*IsCS*/ false) != nullptr) {
 Flags |= static_cast(CompileSym3Flags::PGO);
   }
+  if (Asm->TM.Options.Hotpatch)
+Flags |= static_cast(CompileSym3Flags::HotPatch);
 
   OS.AddComment("Flags and language");
   OS.emitInt32(Flags);
Index: llvm/include/llvm/Target/TargetOptions.h
===
--- llvm/include/llvm/Target/TargetOptions.h
+++ llvm/include/llvm/Target/TargetOptions.h
@@ -140,9 +140,9 @@
   EnableMachineFunctionSplitter(false), SupportsDefaultOutlining(false),
   EmitAddrsig(false), EmitCallSiteInfo(false),
   SupportsDebugEntryValues(false), EnableDebugEntryValues(false),
-  ValueTrackingVariableLocations(false),
-  ForceDwarfFrameSection(false), XRayOmitFunctionIndex(false),
-  DebugStrictDwarf(false),
+  ValueTrackingVariableLocations(false), ForceDwarfFrameSection(false),
+  XRayOmitFunctionIndex(false), DebugStrictDwarf(false),
+  Hotpatch(false),
   FPDenormalMode(DenormalMode::IEEE, DenormalMode::IEEE) {}
 
 /// DisableFramePointerElim - This returns true if frame pointer elimination
@@ -342,6 +342,9 @@
 /// By default, it is set to false.
 unsigned DebugStrictDwarf : 1;
 
+/// Emit the hotpatch flag in CodeView debug.
+unsigned Hotpatch : 1;
+
 /// Name of the stack usage file (i.e., .su file) if user passes
 /// -fstack-usage. If empty, it can be implied that -fstack-usage is not
 /// passed on the command line.
Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -118,6 +118,9 @@
 // RUN: %clang_cl /Gw /Gw- -### -- %s 2>&1 | FileCheck -check-prefix=Gw_ %s
 // Gw_-NOT: -fdata-sections
 
+// RUN: %clang_cl /hotpatch -### -- %s 2>&1 | FileCheck -check-prefix=hotpatch %s
+// hotpatch: -fhotpatch
+
 // RUN: %clang_cl /Imyincludedir -### -- %s 2>&1 | FileCheck -check-prefix=SLASH_I %s
 // RUN: %clang_cl /I myincludedir -### -- %s 2>&1 | FileCheck -check-prefix=SLASH_I %s
 // SLASH_I: "-I" "myincludedir"
Index: clang/test/CodeGenCXX/debug-info-hotpatch.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/debug-info-hotpatch.cpp
@@ -0,0 +1,13 @@
+// REQUIRES: x86-registered-target
+// RUN: %clang_cl --target=x86_64-windows-msvc /c /hotpatch /Z7 %s -o %t.obj
+// RUN: llvm-pdbutil dump -symbols %t.obj | FileCheck %s
+// RUN: %clang_cl --target=x86_64-windows-msvc /c /Z7 %s -o %t.obj
+// RUN: llvm-pdbutil dump -symbols %t.obj | FileCheck %s --check-prefix=NOHOTPATCH
+
+int main() {
+  return 0;
+}
+
+// CHECK: S_COMPILE3 [size = [[#]]]
+// CHECK: flags = hot patchable
+// NOHOTPATCH-NOT: flags = hot patchable
Index: clang/test/CodeGen/patchable-function-entry.c
===
--- clang/test/CodeGen/patchable-function-entry.c
+++ clang/test/CodeGen/patchable-function-entry.c
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -triple aarch64 -emit-llvm %s -o - | FileCheck %s
 // RUN: %clang_cc1 -triple x86_64 -emit-llvm %s -fpatchable-function-entry=1 -o - | FileCheck --check-prefixes=CHECK,OPT %s
+// RUN: %clang_cc1 -triple x86_64 -emit-llvm %s -fhotpatch -o - | FileCheck --check-prefixes=HOTPATCH %s
 
 // CHECK: define{{.*}} void @f0() #0
 __attribute__((patchable_function_entry(0))) void f0() {}
@@ -34,3 +35,7 @@
 // CHECK: attributes #2 = { {{.*}} "patchable-function-entry"="0" "patchable-function-prefix"="4"
 // CHECK: attributes #3 = { {{.*}} "patchable-function-entry"="3" "patchable-function-prefix"="2"
 // OPT:   attributes #4 = { {{.*}} "patchable-function-entry"="1"
+// HOTPATCH: attributes #0 = { {{.*}} "patchable-function"="prologue-short-redirect"
+// HOTPATCH: attributes #1 = { {{.*}} "patchable-function"="prologue-short-redirect"
+// HOTPATCH: attributes #2 = { {{.*}} "patchable-function"="prologue-short-redirect"
+// HOTPATCH: attributes

[PATCH] D116511: [clang-cl] Support the /HOTPATCH flag

2022-01-02 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea created this revision.
aganea added reviewers: amccarth, craig.topper, hans, rnk, stefan_reinalter.
Herald added subscribers: ormris, dexonsmith, dang, pengfei, hiraditya.
aganea requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

This patch adds support for the /HOTPATCH flag: 
https://docs.microsoft.com/sv-se/cpp/build/reference/hotpatch-create-hotpatchable-image?view=msvc-170=vs-2019

The flag is translated to a new `-fhotpatch` cc1 flag, which in turn adds a 
`patchable-function` attribute for each function in the TU. This is then picked 
up by the `PatchableFunction` pass which would generate a 
`TargetOpcode::PATCHABLE_OP` of minsize = 2 (which means the target instruction 
must resolve to at least two bytes). Currently `TargetOpcode::PATCHABLE_OP` is 
only implemented for x86/x64.

Additionally we generate a 'hot patchable' flag in the CodeView debug stream, 
in the `S_COMPILE3` record. This flag is then picked up by LLD (or link.exe) 
and is used in conjunction with the linker `/FUNCTIONPADMIN` flag to generate 
extraneous space before each function, to accommodate for live patching. Please 
see: 
https://github.com/llvm/llvm-project/blob/d703b922961e0d02a5effdd4bfbb23ad50a3cc9f/lld/COFF/Writer.cpp#L1298

The end result is that one can finally use Live++ 
 or Recode  along 
with clang-cl.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D116511

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/patchable-function-entry.c
  clang/test/CodeGenCXX/debug-info-hotpatch.cpp
  clang/test/Driver/cl-options.c
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp

Index: llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
+++ llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
@@ -843,6 +843,8 @@
   if (MMI->getModule()->getProfileSummary(/*IsCS*/ false) != nullptr) {
 Flags |= static_cast(CompileSym3Flags::PGO);
   }
+  if (Asm->TM.Options.Hotpatch)
+Flags |= static_cast(CompileSym3Flags::HotPatch);
 
   OS.AddComment("Flags and language");
   OS.emitInt32(Flags);
Index: llvm/include/llvm/Target/TargetOptions.h
===
--- llvm/include/llvm/Target/TargetOptions.h
+++ llvm/include/llvm/Target/TargetOptions.h
@@ -140,9 +140,9 @@
   EnableMachineFunctionSplitter(false), SupportsDefaultOutlining(false),
   EmitAddrsig(false), EmitCallSiteInfo(false),
   SupportsDebugEntryValues(false), EnableDebugEntryValues(false),
-  ValueTrackingVariableLocations(false),
-  ForceDwarfFrameSection(false), XRayOmitFunctionIndex(false),
-  DebugStrictDwarf(false),
+  ValueTrackingVariableLocations(false), ForceDwarfFrameSection(false),
+  XRayOmitFunctionIndex(false), DebugStrictDwarf(false),
+  Hotpatch(false),
   FPDenormalMode(DenormalMode::IEEE, DenormalMode::IEEE) {}
 
 /// DisableFramePointerElim - This returns true if frame pointer elimination
@@ -342,6 +342,9 @@
 /// By default, it is set to false.
 unsigned DebugStrictDwarf : 1;
 
+/// Emit the hotpatch flag in CodeView debug.
+unsigned Hotpatch : 1;
+
 /// Name of the stack usage file (i.e., .su file) if user passes
 /// -fstack-usage. If empty, it can be implied that -fstack-usage is not
 /// passed on the command line.
Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -118,6 +118,9 @@
 // RUN: %clang_cl /Gw /Gw- -### -- %s 2>&1 | FileCheck -check-prefix=Gw_ %s
 // Gw_-NOT: -fdata-sections
 
+// RUN: %clang_cl /hotpatch -### -- %s 2>&1 | FileCheck -check-prefix=hotpatch %s
+// hotpatch: -fhotpatchable
+
 // RUN: %clang_cl /Imyincludedir -### -- %s 2>&1 | FileCheck -check-prefix=SLASH_I %s
 // RUN: %clang_cl /I myincludedir -### -- %s 2>&1 | FileCheck -check-prefix=SLASH_I %s
 // SLASH_I: "-I" "myincludedir"
Index: clang/test/CodeGenCXX/debug-info-hotpatch.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/debug-info-hotpatch.cpp
@@ -0,0 +1,13 @@
+// REQUIRES: x86-registered-target
+// RUN: %clang_cl --target=x86_64-windows-msvc /c /hotpatch /Z7 %s -o %t.obj
+// RUN: llvm-pdbutil dump -symbols %t.obj | FileCheck %s
+// RUN: %clang_cl --target=x86_64-windows-msvc /c /Z7 %s -o %t.obj
+// RUN: llvm-pdbutil dump -symbols %t.obj | FileCheck %s --check-prefix=NOHOTPATCH
+
+int main() {
+  return 0;
+}
+
+// CHECK: S_COMPILE3 [size = [[#]]]

[PATCH] D80833: [CodeView] Add full repro to LF_BUILDINFO record

2021-12-31 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

@dexonsmith The issue with `-grecord-command-line`/`-frecord-command-line` is 
that it isn't producing a self-standing command-line. For example:

  > clang-cl /c main.cpp /clang:-grecord-command-line /Z7

would record: `d:\\git\\llvm-project\\stage1\\bin\\clang-cl.exe 
--driver-mode=cl -c main.cpp /clang:-grecord-command-line /Z7 
-grecord-command-line`

Whereas our patch records the cc1 command, which is self-standing:

  > stage1\bin\clang-cl /c main.cpp /Z7 -no-canonical-prefixes 
-fdebug-compilation-dir=.
  > stage1\bin\llvm-pdbutil.exe dump -types .\main.obj | grep -A5 LF_BUILDINFO
  0x1008 | LF_BUILDINFO [size = 28]
   0x1003: `.`
   0x1006: `stage1\bin\clang-cl.exe`
   0x1004: `main.cpp`
   0x1005: ``
   0x1007: `"-cc1" "-fmessage-length=120" "-fdiagnostics-format" "msvc" 
"-ferror-limit" "19" "-fcolor-diagnostics" "-mllvm" "-x86-asm-syntax=intel" 
"-disable-free" "-emit-obj" "-x" "c++" "-target-cpu" "x86-64" "-tune-cpu" 
"generic" "-triple" "x86_64-pc-windows-msvc19.29.30138" "-resource-dir" 
"stage1\\lib\\clang\\14.0.0" "-isystem" "stage1\\lib\\clang\\14.0.0\\include" 
"-isystem" "C:\\Program Files (x86)\\Microsoft Visual 
Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.29.30133\\include" "-isystem" 
"C:\\Program Files (x86)\\Microsoft Visual 
Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.29.30133\\atlmfc\\include" 
"-isystem" 
"C:\\Scoop\\global\\apps\\winsdk\\10.0.22000.194\\sdk\\Include\\10.0.22000.0\\ucrt"
 "-isystem" 
"C:\\Scoop\\global\\apps\\winsdk\\10.0.22000.194\\sdk\\Include\\10.0.22000.0\\shared"
 "-isystem" 
"C:\\Scoop\\global\\apps\\winsdk\\10.0.22000.194\\sdk\\Include\\10.0.22000.0\\um"
 "-isystem" 
"C:\\Scoop\\global\\apps\\winsdk\\10.0.22000.194\\sdk\\Include\\10.0.22000.0\\winrt"
 "-std=c++14" "-fmath-errno" "-fms-compatibility" "-fdelayed-template-parsing" 
"-pic-level" "2" "-stack-protector" "2" "-fvisibility" "default" 
"-fdeprecated-macro" "-fms-compatibility-version=19.29.30138" 
"-ffp-contract=on" "-fno-experimental-relative-c++-abi-vtables" "-O0" 
"-fdebug-compilation-dir=." "-fcoverage-compilation-dir=D:\\git\\llvm-project" 
"-faddrsig" "-fms-volatile" "-fno-use-cxa-atexit" "-gcodeview" 
"-gno-column-info" "-mrelax-all" "-mincremental-linker-compatible" 
"--mrelax-relocations" "-relaxed-aliasing" "-funwind-tables=2" 
"-mconstructor-aliases" "--dependent-lib=libcmt" "--dependent-lib=oldnames" 
"-flto-visibility-public-std" "-clear-ast-before-backend" 
"-debug-info-kind=constructor" "-fdiagnostics-hotness-threshold=0" "-D" "_MT"`

(the LF_BUILDINFO record is replicated unchanged in the .PDB)

Microsoft does something similair:

  > cl /c /Z7 .\main.cpp
  Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30136 for x64
  Copyright (C) Microsoft Corporation.  All rights reserved.
  
  main.cpp
  > llvm-pdbutil.exe dump -types .\main.obj | grep -B4 -A5 LF_BUILDINFO
  0x1009 | LF_SUBSTR_LIST [size = 16]
   0x1007: `-c -Z7 -MT 
-IC:\Scoop\global\apps\vs_buildtools\16.11.5\VS\VC\Tools\MSVC\14.29.30133\ATLMFC\include
 
-IC:\Scoop\global\apps\vs_buildtools\16.11.5\VS\VC\Tools\MSVC\14.29.30133\include
 -IC:\Scoop\global\apps\winsdk\10.0.22000.194\sdk\include\10.0.22000.0\ucrt`
   0x1008: ` 
-IC:\Scoop\global\apps\winsdk\10.0.22000.194\sdk\include\10.0.22000.0\shared 
-IC:\Scoop\global\apps\winsdk\10.0.22000.194\sdk\include\10.0.22000.0\um 
-IC:\Scoop\global\apps\winsdk\10.0.22000.194\sdk\include\10.0.22000.0\winrt 
-IC:\Scoop\global\apps\winsdk\10`
  0x100A | LF_STRING_ID [size = 64] ID: 0x1009, String: 
.0.22000.194\sdk\include\10.0.22000.0\cppwinrt -TP -X
  0x100B | LF_BUILDINFO [size = 28]
   0x1003: `D:\git\llvm-project`
   0x1004: 
`C:\Scoop\global\apps\vs_buildtools\16.11.5\VS\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\cl.exe`
   0x1005: `.\main.cpp`
   0x1006: `D:\git\llvm-project\vc140.pdb`
   0x100A: `.0.22000.194\sdk\include\10.0.22000.0\cppwinrt -TP -X`

MSVC splits the command over multiple string records, I suppose to increase the 
chances of de-duplication in the .PDB, something that we could do later. But 
the essence is that the command is free-standing (note `-X` and the explicit 
includes) and can be run without any env.vars set, unlike `-dwarf-debug-flags` 
or `-record-command-line`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80833/new/

https://reviews.llvm.org/D80833

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D80833: [CodeView] Add full repro to LF_BUILDINFO record

2021-12-31 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea updated this revision to Diff 396804.
aganea added a comment.
This revision is now accepted and ready to land.
Herald added subscribers: abrachet, mgorny.

Rebase & simplify.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80833/new/

https://reviews.llvm.org/D80833

Files:
  clang/cmake/caches/BaremetalARM.cmake
  clang/cmake/caches/CrossWinToARMLinux.cmake
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/test/CodeGen/debug-info-codeview-buildinfo.c
  lld/test/COFF/Inputs/pdb_lines_1_relative.yaml
  lld/test/COFF/Inputs/pdb_lines_2_relative.yaml
  lld/test/COFF/pdb-relative-source-lines.test
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
  llvm/test/DebugInfo/COFF/build-info.ll
  llvm/test/DebugInfo/COFF/global-type-hashes.ll
  llvm/test/DebugInfo/COFF/types-basic.ll
  llvm/test/DebugInfo/COFF/types-data-members.ll

Index: llvm/test/DebugInfo/COFF/types-data-members.ll
===
--- llvm/test/DebugInfo/COFF/types-data-members.ll
+++ llvm/test/DebugInfo/COFF/types-data-members.ll
@@ -727,14 +727,22 @@
 ; ASM: .asciz	"t.cpp" # StringData
 ; ASM: .byte	242
 ; ASM: .byte	241
-; ASM: # BuildInfo (0x1022)
+; ASM: # StringId (0x1022)
+; ASM: .short	0xa # Record length
+; ASM: .short	0x1605  # Record kind: LF_STRING_ID
+; ASM: .long	0x0 # Id
+; ASM: .byte0   # StringData
+; ASM: .byte	243
+; ASM: .byte	242
+; ASM: .byte	241
+; ASM: # BuildInfo (0x1023)
 ; ASM: .short	0x1a# Record length
 ; ASM: .short	0x1603  # Record kind: LF_BUILDINFO
 ; ASM: .short	0x5 # NumArgs
 ; ASM: .long	0x1020  # Argument: D:\src\llvm\build
 ; ASM: .long	0x0 # Argument
 ; ASM: .long	0x1021  # Argument: t.cpp
-; ASM: .long	0x0 # Argument
+; ASM: .long	0x1022  # Argument
 ; ASM: .long	0x0 # Argument
 ; ASM: .byte	242
 ; ASM: .byte	241
Index: llvm/test/DebugInfo/COFF/types-basic.ll
===
--- llvm/test/DebugInfo/COFF/types-basic.ll
+++ llvm/test/DebugInfo/COFF/types-basic.ll
@@ -511,14 +511,22 @@
 ; ASM: .asciz	"t.cpp" # StringData
 ; ASM: .byte	242
 ; ASM: .byte	241
-; ASM: # BuildInfo (0x1015)
+; ASM: # StringId (0x1015)
+; ASM: .short	0xa # Record length
+; ASM: .short	0x1605  # Record kind: LF_STRING_ID
+; ASM: .long	0x0 # Id
+; ASM: .byte0   # StringData
+; ASM: .byte	243
+; ASM: .byte	242
+; ASM: .byte	241
+; ASM: # BuildInfo (0x1016)
 ; ASM: .short	0x1a# Record length
 ; ASM: .short	0x1603  # Record kind: LF_BUILDINFO
 ; ASM: .short	0x5 # NumArgs
 ; ASM: .long	0x1013  # Argument: D:\src\llvm\build
 ; ASM: .long	0x0 # Argument
 ; ASM: .long	0x1014  # Argument: t.cpp
-; ASM: .long	0x0 # Argument
+; ASM: .long	0x1015  # Argument
 ; ASM: .long	0x0 # Argument
 ; ASM: .byte	242
 ; ASM: .byte	241
Index: llvm/test/DebugInfo/COFF/global-type-hashes.ll
===
--- llvm/test/DebugInfo/COFF/global-type-hashes.ll
+++ llvm/test/DebugInfo/COFF/global-type-hashes.ll
@@ -295,7 +295,8 @@
 ; YAML: - 4470750F2E319329
 ; YAML: - 0FB556FD1FAB66D7
 ; YAML: - 5970EFB4874D0F3F
-; YAML: - EDB1D74C120CF44A
+; YAML: - D8EF11198C33843F
+; YAML: - D81F744D7366282B
 ; ...
 
 
Index: llvm/test/DebugInfo/COFF/build-info.ll
===
--- llvm/test/DebugInfo/COFF/build-info.ll
+++ llvm/test/DebugInfo/COFF/build-info.ll
@@ -5,7 +5,7 @@
 ; CHECK-NEXT:  0x{{.*}}: `D:\src\scopes\clang`
 ; CHECK-NEXT:  : ``
 ; CHECK-NEXT:  0x{{.*}}: `D:\src\scopes\foo.cpp`
-; CHECK-NEXT:  : ``
+; CHECK-NEXT:  0x{{.*}}: ``
 ; CHECK-NEXT:  : ``
 
 ; CHECK: {{.*}} | S_BUILDINFO [size = 8] BuildId = `[[INFO_IDX]]`
Index: llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
+++ llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
@@ -68,6 +68,7 @@
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/Program.h"
 #include "llvm/Support/SMLoc.h"
 #include "llvm/Support/ScopedPrinter.h"
 #include "llvm/Target/TargetLoweringObjectFile.h"
@@ -887,6 +888,34 @@
   return TypeTable.writeLeafType(SIR);
 }
 
+static std::string flattenCommandLine(ArrayRef Args,
+  StringRef MainFilename) {
+

[PATCH] D115456: Implement on-demand TLS initialization for Microsoft CXX ABI

2021-12-29 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: clang/lib/CodeGen/MicrosoftCXXABI.cpp:2470
+// Dynamic TLS initialization works by checking the state of a
+// guard varibale (__tls_guard) to see whether TLS initialization
+// for a thread has happend yet.

s/varibale/variable/



Comment at: clang/lib/CodeGen/MicrosoftCXXABI.cpp:2477
+
+  // Emit the variable just like any regular global variable
+

Missing period at the end of the sentence please.



Comment at: clang/test/CodeGenCXX/ms-thread_local.cpp:1
-// RUN: %clang_cc1 %s -std=c++1y -triple=i686-pc-win32 -emit-llvm -o - | 
FileCheck %s
-// RUN: %clang_cc1 %s  -std=c++1y -triple=i686-pc-win32 
-ftls-model=local-dynamic -emit-llvm -o - | FileCheck %s -check-prefix=CHECK-LD
+// RUN: %clang_cc1 %s -std=c++1y -triple=i686-pc-win32 
-fms-compatibility-version=1925 -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 %s -std=c++1y -triple=i686-pc-win32 
-fms-compatibility-version=1925 -ftls-model=local-dynamic -emit-llvm -o - | 
FileCheck %s -check-prefix=CHECK-LD

Also please check with `-fms-compatibility-version=1920` to ensure that the 
dynamic initialization isn't generated.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115456/new/

https://reviews.llvm.org/D115456

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116313: [MSVC] Silence -Wnon-virtual-dtor on DIA APIs

2021-12-27 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea created this revision.
aganea added reviewers: mstorsjo, amccarth, hans.
aganea requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

When building LLVM with Clang 13.0 on Windows, I see a bunch of 
`-Wnon-virtual-dtor` errors on DIA (Debug Interface Access) COM APIs.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D116313

Files:
  clang/lib/Driver/ToolChains/MSVC.cpp
  llvm/include/llvm/DebugInfo/PDB/DIA/DIASupport.h


Index: llvm/include/llvm/DebugInfo/PDB/DIA/DIASupport.h
===
--- llvm/include/llvm/DebugInfo/PDB/DIA/DIASupport.h
+++ llvm/include/llvm/DebugInfo/PDB/DIA/DIASupport.h
@@ -27,7 +27,14 @@
 
 // DIA headers must come after windows headers.
 #include 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wnon-virtual-dtor"
+#endif
 #include 
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
 #include 
 
 #endif // LLVM_DEBUGINFO_PDB_DIA_DIASUPPORT_H
Index: clang/lib/Driver/ToolChains/MSVC.cpp
===
--- clang/lib/Driver/ToolChains/MSVC.cpp
+++ clang/lib/Driver/ToolChains/MSVC.cpp
@@ -47,7 +47,14 @@
 // Make sure this comes before MSVCSetupApi.h
 #include 
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wnon-virtual-dtor"
+#endif
 #include "MSVCSetupApi.h"
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
 #include "llvm/Support/COM.h"
 _COM_SMARTPTR_TYPEDEF(ISetupConfiguration, __uuidof(ISetupConfiguration));
 _COM_SMARTPTR_TYPEDEF(ISetupConfiguration2, __uuidof(ISetupConfiguration2));


Index: llvm/include/llvm/DebugInfo/PDB/DIA/DIASupport.h
===
--- llvm/include/llvm/DebugInfo/PDB/DIA/DIASupport.h
+++ llvm/include/llvm/DebugInfo/PDB/DIA/DIASupport.h
@@ -27,7 +27,14 @@
 
 // DIA headers must come after windows headers.
 #include 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wnon-virtual-dtor"
+#endif
 #include 
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
 #include 
 
 #endif // LLVM_DEBUGINFO_PDB_DIA_DIASUPPORT_H
Index: clang/lib/Driver/ToolChains/MSVC.cpp
===
--- clang/lib/Driver/ToolChains/MSVC.cpp
+++ clang/lib/Driver/ToolChains/MSVC.cpp
@@ -47,7 +47,14 @@
 // Make sure this comes before MSVCSetupApi.h
 #include 
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wnon-virtual-dtor"
+#endif
 #include "MSVCSetupApi.h"
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
 #include "llvm/Support/COM.h"
 _COM_SMARTPTR_TYPEDEF(ISetupConfiguration, __uuidof(ISetupConfiguration));
 _COM_SMARTPTR_TYPEDEF(ISetupConfiguration2, __uuidof(ISetupConfiguration2));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43002: [CodeView] Emit S_OBJNAME record

2021-12-22 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

In D43002#3205190 , @MaskRay wrote:

> Some test nits:) I don't know CodeView :(

Fixed, thanks @MaskRay !


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D43002/new/

https://reviews.llvm.org/D43002

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116011: [Clang] Own the CommandLineArgs in CodeGenOptions

2021-12-21 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea marked an inline comment as done.
aganea added inline comments.



Comment at: clang/lib/Driver/Job.cpp:390-392
   Argv.push_back(nullptr);
+  Argv.pop_back(); // The terminating null element shall not be part of the
+   // slice (main() behavior).

aganea wrote:
> aheejin wrote:
> > If we push `nullptr` and then pop it right after that, why do we push it in 
> > the first place?
> Simply to guarantee that we will have a `nullptr` element after the end of 
> the container. `.pop_back()` only decrements the size, the `nullptr` value 
> will remain there.
Frankly a better fix would be to change the API of `ExecuteCC1Tool` to take an 
`ArrayRef` and not rely on internal behavior of `SmallVector`. Maybe we should 
do that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116011/new/

https://reviews.llvm.org/D116011

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116011: [Clang] Own the CommandLineArgs in CodeGenOptions

2021-12-21 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea marked an inline comment as done.
aganea added inline comments.



Comment at: clang/lib/Driver/Job.cpp:390-392
   Argv.push_back(nullptr);
+  Argv.pop_back(); // The terminating null element shall not be part of the
+   // slice (main() behavior).

aheejin wrote:
> If we push `nullptr` and then pop it right after that, why do we push it in 
> the first place?
Simply to guarantee that we will have a `nullptr` element after the end of the 
container. `.pop_back()` only decrements the size, the `nullptr` value will 
remain there.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116011/new/

https://reviews.llvm.org/D116011

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116011: [Clang] Own the CommandLineArgs in CodeGenOptions

2021-12-21 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: clang/lib/Driver/Job.cpp:391
   Argv.push_back(nullptr);
+  Argv.pop_back(); // The terminating null element shall not be part of the
+   // slice (main() behavior).

I changed this to match the behavior of the //main function//, ie. `argv[argc]` 
is guaranteed to be a null pointer. Please let me know if you disagree.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116011/new/

https://reviews.llvm.org/D116011

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116011: [Clang] Own the CommandLineArgs in CodeGenOptions

2021-12-21 Thread Alexandre Ganea via Phabricator via cfe-commits 
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd26520f6f787: [Clang] Own the CommandLineArgs in 
CodeGenOptions (authored by aganea).

Changed prior to commit:
  https://reviews.llvm.org/D116011?vs=395359=395749#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116011/new/

https://reviews.llvm.org/D116011

Files:
  clang/include/clang/Basic/CodeGenOptions.h
  clang/lib/Driver/Job.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  llvm/include/llvm/MC/MCTargetOptions.h


Index: llvm/include/llvm/MC/MCTargetOptions.h
===
--- llvm/include/llvm/MC/MCTargetOptions.h
+++ llvm/include/llvm/MC/MCTargetOptions.h
@@ -65,7 +65,7 @@
   std::string COFFOutputFilename;
 
   const char *Argv0 = nullptr;
-  ArrayRef CommandLineArgs;
+  ArrayRef CommandLineArgs;
 
   /// Additional paths to search for `.include` directives when using the
   /// integrated assembler.
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -4518,7 +4518,7 @@
 
   // Store the command-line for using in the CodeView backend.
   Res.getCodeGenOpts().Argv0 = Argv0;
-  Res.getCodeGenOpts().CommandLineArgs = CommandLineArgs;
+  append_range(Res.getCodeGenOpts().CommandLineArgs, CommandLineArgs);
 
   FixupInvocation(Res, Diags, Args, DashX);
 
Index: clang/lib/Driver/Job.cpp
===
--- clang/lib/Driver/Job.cpp
+++ clang/lib/Driver/Job.cpp
@@ -388,6 +388,8 @@
   Argv.push_back(getExecutable());
   Argv.append(getArguments().begin(), getArguments().end());
   Argv.push_back(nullptr);
+  Argv.pop_back(); // The terminating null element shall not be part of the
+   // slice (main() behavior).
 
   // This flag simply indicates that the program couldn't start, which isn't
   // applicable here.
Index: clang/include/clang/Basic/CodeGenOptions.h
===
--- clang/include/clang/Basic/CodeGenOptions.h
+++ clang/include/clang/Basic/CodeGenOptions.h
@@ -398,7 +398,7 @@
   /// Executable and command-line used to create a given CompilerInvocation.
   /// Most of the time this will be the full -cc1 command.
   const char *Argv0 = nullptr;
-  ArrayRef CommandLineArgs;
+  std::vector CommandLineArgs;
 
   /// The minimum hotness value a diagnostic needs in order to be included in
   /// optimization diagnostics.


Index: llvm/include/llvm/MC/MCTargetOptions.h
===
--- llvm/include/llvm/MC/MCTargetOptions.h
+++ llvm/include/llvm/MC/MCTargetOptions.h
@@ -65,7 +65,7 @@
   std::string COFFOutputFilename;
 
   const char *Argv0 = nullptr;
-  ArrayRef CommandLineArgs;
+  ArrayRef CommandLineArgs;
 
   /// Additional paths to search for `.include` directives when using the
   /// integrated assembler.
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -4518,7 +4518,7 @@
 
   // Store the command-line for using in the CodeView backend.
   Res.getCodeGenOpts().Argv0 = Argv0;
-  Res.getCodeGenOpts().CommandLineArgs = CommandLineArgs;
+  append_range(Res.getCodeGenOpts().CommandLineArgs, CommandLineArgs);
 
   FixupInvocation(Res, Diags, Args, DashX);
 
Index: clang/lib/Driver/Job.cpp
===
--- clang/lib/Driver/Job.cpp
+++ clang/lib/Driver/Job.cpp
@@ -388,6 +388,8 @@
   Argv.push_back(getExecutable());
   Argv.append(getArguments().begin(), getArguments().end());
   Argv.push_back(nullptr);
+  Argv.pop_back(); // The terminating null element shall not be part of the
+   // slice (main() behavior).
 
   // This flag simply indicates that the program couldn't start, which isn't
   // applicable here.
Index: clang/include/clang/Basic/CodeGenOptions.h
===
--- clang/include/clang/Basic/CodeGenOptions.h
+++ clang/include/clang/Basic/CodeGenOptions.h
@@ -398,7 +398,7 @@
   /// Executable and command-line used to create a given CompilerInvocation.
   /// Most of the time this will be the full -cc1 command.
   const char *Argv0 = nullptr;
-  ArrayRef CommandLineArgs;
+  std::vector CommandLineArgs;
 
   /// The minimum hotness value a diagnostic needs in order to be included in
   /// optimization diagnostics.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43002: [CodeView] Emit S_OBJNAME record

2021-12-21 Thread Alexandre Ganea via Phabricator via cfe-commits 
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf44e3fbadd15: [CodeView] Emit S_OBJNAME record (authored by 
aganea).

Changed prior to commit:
  https://reviews.llvm.org/D43002?vs=374884=395663#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D43002/new/

https://reviews.llvm.org/D43002

Files:
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Driver/Job.h
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CMakeLists.txt
  clang/test/CodeGenCXX/debug-info-objname.cpp
  llvm/include/llvm/MC/MCTargetOptions.h
  llvm/include/llvm/Support/Caching.h
  llvm/include/llvm/Support/ToolOutputFile.h
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.h
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/Support/Caching.cpp
  llvm/test/DebugInfo/COFF/globals.ll
  llvm/test/DebugInfo/COFF/multifunction.ll
  llvm/test/DebugInfo/COFF/pr28747.ll
  llvm/test/DebugInfo/COFF/simple.ll
  llvm/test/DebugInfo/COFF/vframe-fpo.ll
  llvm/test/MC/AArch64/coff-debug.ll
  llvm/test/MC/ARM/coff-debugging-secrel.ll
  llvm/test/MC/COFF/cv-compiler-info.ll
  llvm/tools/llc/llc.cpp
  llvm/tools/llvm-lto2/llvm-lto2.cpp

Index: llvm/tools/llvm-lto2/llvm-lto2.cpp
===
--- llvm/tools/llvm-lto2/llvm-lto2.cpp
+++ llvm/tools/llvm-lto2/llvm-lto2.cpp
@@ -378,7 +378,7 @@
 std::error_code EC;
 auto S = std::make_unique(Path, EC, sys::fs::OF_None);
 check(EC, Path);
-return std::make_unique(std::move(S));
+return std::make_unique(std::move(S), Path);
   };
 
   auto AddBuffer = [&](size_t Task, std::unique_ptr MB) {
Index: llvm/tools/llc/llc.cpp
===
--- llvm/tools/llc/llc.cpp
+++ llvm/tools/llc/llc.cpp
@@ -605,6 +605,9 @@
   GetOutputStream(TheTarget->getName(), TheTriple.getOS(), argv[0]);
   if (!Out) return 1;
 
+  // Ensure the filename is passed down to CodeViewDebug.
+  Target->Options.ObjectFilenameForDebug = Out->outputFilename();
+
   std::unique_ptr DwoOut;
   if (!SplitDwarfOutputFile.empty()) {
 std::error_code EC;
Index: llvm/test/MC/COFF/cv-compiler-info.ll
===
--- llvm/test/MC/COFF/cv-compiler-info.ll
+++ llvm/test/MC/COFF/cv-compiler-info.ll
@@ -1,4 +1,6 @@
-; RUN: llc -mtriple i686-pc-windows-msvc < %s | FileCheck %s
+; RUN: llc -mtriple i686-pc-windows-msvc < %s | FileCheck %s --check-prefixes=CHECK,STDOUT
+; RUN: llc -mtriple i686-pc-windows-msvc < %s -o %t
+; RUN: FileCheck %s --input-file=%t --check-prefixes=CHECK,FILE
 ; ModuleID = 'D:\src\scopes\foo.cpp'
 source_filename = "D:\5Csrc\5Cscopes\5Cfoo.cpp"
 target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
@@ -20,19 +22,23 @@
 ; One .debug$S section should contain an S_COMPILE3 record that identifies the
 ; source language and the version of the compiler based on the DICompileUnit.
 ; CHECK: 	.section	.debug$S,"dr"
+; CHECK:.short  4353# Record kind: S_OBJNAME
+; CHECK-NEXT:   .long   0   # Signature
+; STDOUT-NEXT:  .byte   0   # Object name
+; FILE-NEXT:.asciz	"{{.*}}{{|/}}cv-compiler-info.ll.tmp" # Object name
 ; CHECK: 		.short	4412  # Record kind: S_COMPILE3
-; CHECK: 		.long	1   # Flags and language
-; CHECK: 		.short	7 # CPUType
-; CHECK: 		.short	4 # Frontend version
-; CHECK: 		.short	0
-; CHECK: 		.short	0
-; CHECK: 		.short	0
-; CHECK: 		.short	[[BACKEND_VERSION:[0-9]+]]  # Backend version
-; CHECK: 		.short	0
-; CHECK: 		.short	0
-; CHECK: 		.short	0
-; CHECK: 		.asciz	"clang version 4.0.0 "  # Null-terminated compiler version string
-; CHECK-NOT: .short	4412  # Record kind: S_COMPILE3
+; CHECK-NEXT:   .long	1   # Flags and language
+; CHECK-NEXT: 	.short	7 # CPUType
+; CHECK-NEXT: 	.short	4 # Frontend version
+; CHECK-NEXT: 	.short	0
+; CHECK-NEXT: 	.short	0
+; CHECK-NEXT: 	.short	0
+; CHECK-NEXT: 	.short	[[BACKEND_VERSION:[0-9]+]]  # Backend version
+; CHECK-NEXT: 	.short	0
+; CHECK-NEXT: 	.short	0
+; CHECK-NEXT: 	.short	0
+; CHECK-NEXT: 	.asciz	"clang version 4.0.0 "  # Null-terminated compiler version string
+; CHECK-NOT:.short	4412  # Record kind: S_COMPILE3
 !1 = !DIFile(filename: "D:\5Csrc\5Cscopes\5Cfoo.cpp", directory: "D:\5Csrc\5Cscopes\5Cclang")
 !2 = !{}
 !7 = !{i32 2, !"CodeView", i32 1}
Index: llvm/test/MC/ARM/coff-debugging-secrel.ll
===
--- llvm/test/MC/ARM/coff-debugging-secrel.ll
+++

[PATCH] D116011: [Clang] Own the CommandLineArgs in CodeGenOptions

2021-12-19 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea created this revision.
aganea added reviewers: hans, aheejin, jansvoboda11.
Herald added a subscriber: dexonsmith.
aganea requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

As reported in PR52704: https://github.com/llvm/llvm-project/issues/52704

Since the round-tripping generates function-local arguments, before this patch 
accessing `CodeGenOptions.CommandLineArgs` or `MCTargetOptions.CommandLineArgs` 
used to keep references on free'd data.

+@hans for the `CC1Command` change which otherwise blocks the usage 
`append_range`. This was unconsistent with how `CommandLineArgs` were passed 
around in other places (without the terminating `nullptr` element).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D116011

Files:
  clang/include/clang/Basic/CodeGenOptions.h
  clang/lib/Driver/Job.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  llvm/include/llvm/MC/MCTargetOptions.h


Index: llvm/include/llvm/MC/MCTargetOptions.h
===
--- llvm/include/llvm/MC/MCTargetOptions.h
+++ llvm/include/llvm/MC/MCTargetOptions.h
@@ -64,7 +64,7 @@
   std::string SplitDwarfFile;
 
   const char *Argv0 = nullptr;
-  ArrayRef CommandLineArgs;
+  ArrayRef CommandLineArgs;
 
   /// Additional paths to search for `.include` directives when using the
   /// integrated assembler.
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -4520,7 +4520,7 @@
 
   // Store the command-line for using in the CodeView backend.
   Res.getCodeGenOpts().Argv0 = Argv0;
-  Res.getCodeGenOpts().CommandLineArgs = CommandLineArgs;
+  append_range(Res.getCodeGenOpts().CommandLineArgs, CommandLineArgs);
 
   FixupInvocation(Res, Diags, Args, DashX);
 
Index: clang/lib/Driver/Job.cpp
===
--- clang/lib/Driver/Job.cpp
+++ clang/lib/Driver/Job.cpp
@@ -387,7 +387,6 @@
   SmallVector Argv;
   Argv.push_back(getExecutable());
   Argv.append(getArguments().begin(), getArguments().end());
-  Argv.push_back(nullptr);
 
   // This flag simply indicates that the program couldn't start, which isn't
   // applicable here.
Index: clang/include/clang/Basic/CodeGenOptions.h
===
--- clang/include/clang/Basic/CodeGenOptions.h
+++ clang/include/clang/Basic/CodeGenOptions.h
@@ -395,7 +395,7 @@
   /// Executable and command-line used to create a given CompilerInvocation.
   /// Most of the time this will be the full -cc1 command.
   const char *Argv0 = nullptr;
-  ArrayRef CommandLineArgs;
+  std::vector CommandLineArgs;
 
   /// The minimum hotness value a diagnostic needs in order to be included in
   /// optimization diagnostics.


Index: llvm/include/llvm/MC/MCTargetOptions.h
===
--- llvm/include/llvm/MC/MCTargetOptions.h
+++ llvm/include/llvm/MC/MCTargetOptions.h
@@ -64,7 +64,7 @@
   std::string SplitDwarfFile;
 
   const char *Argv0 = nullptr;
-  ArrayRef CommandLineArgs;
+  ArrayRef CommandLineArgs;
 
   /// Additional paths to search for `.include` directives when using the
   /// integrated assembler.
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -4520,7 +4520,7 @@
 
   // Store the command-line for using in the CodeView backend.
   Res.getCodeGenOpts().Argv0 = Argv0;
-  Res.getCodeGenOpts().CommandLineArgs = CommandLineArgs;
+  append_range(Res.getCodeGenOpts().CommandLineArgs, CommandLineArgs);
 
   FixupInvocation(Res, Diags, Args, DashX);
 
Index: clang/lib/Driver/Job.cpp
===
--- clang/lib/Driver/Job.cpp
+++ clang/lib/Driver/Job.cpp
@@ -387,7 +387,6 @@
   SmallVector Argv;
   Argv.push_back(getExecutable());
   Argv.append(getArguments().begin(), getArguments().end());
-  Argv.push_back(nullptr);
 
   // This flag simply indicates that the program couldn't start, which isn't
   // applicable here.
Index: clang/include/clang/Basic/CodeGenOptions.h
===
--- clang/include/clang/Basic/CodeGenOptions.h
+++ clang/include/clang/Basic/CodeGenOptions.h
@@ -395,7 +395,7 @@
   /// Executable and command-line used to create a given CompilerInvocation.
   /// Most of the time this will be the full -cc1 command.
   const char *Argv0 = nullptr;
-  ArrayRef CommandLineArgs;
+  std::vector CommandLineArgs;
 
   /// The minimum hotness value a diagnostic needs in order to be included in
   /// optimization diagnostics.
___
cfe-commits mailing list

[PATCH] D43002: [CodeView] Emit S_OBJNAME record

2021-12-06 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea removed a reviewer: deadalnix.
aganea added a comment.

Ping! Any further comments? Thanks in advance for your time.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D43002/new/

https://reviews.llvm.org/D43002

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D112498: [Lex] Remove timer from #pragma clang __debug crash handler

2021-10-25 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

That sounds right. You can test that scenario in a debugger, by putting a 
breakpoint before BuryPointer in clang/tools/driver/driver.cpp and verifying 
that the TimerGroup still has a pointer to the deleted stack frames, after the 
CrashRecoveryContext has successfully catches the abort().


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112498/new/

https://reviews.llvm.org/D112498

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D112498: [Lex] Remove timer from #pragma clang __debug crash handler

2021-10-25 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

This Timer is actually the test coverage for that commit. If we don’t want it 
here, I guess you could move it to the Support unit tests?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112498/new/

https://reviews.llvm.org/D112498

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D80833: [CodeView] Add full repro to LF_BUILDINFO record

2021-10-10 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a subscriber: dexonsmith.
aganea added a comment.

In D80833#3052551 , @dexonsmith wrote:

> In D80833#2069411 , @aganea wrote:
>
>> In D80833#2069246 , @amccarth wrote:
>>
>>> Does embedding full paths affect distributed builds or build 
>>> reproducibility?
>>
>> It does affect reproducibility for distributed builds, the contents of 
>> `LF_BUILDINFO` for a remotely-compiled .OBJ will be different in the final 
>> .PDB.
>
> I don't think the path to the compiler is the only concern regarding 
> reproducible builds. Including the full command-line means that artifacts 
> change when options that have no (other) effect on the output are added. 
> E.g., adding `-Wall` will create a different object file than `-Wmost`. I 
> worry this is the wrong direction for default clang behaviour.

In my sense, the fact that an option doesn't change the output is orthogonal to 
producing a deterministic output. I think most caching systems treat the 
compiler as a black box, by simply hashing the command-line and assuming the 
same .OBJ will be generated from that command-line. The build system could 
filter out options that are known to have effect on the output, to address your 
concern. But I feel this outside of the scope of this patch?

> Should this new instability be restricted to when users explicitly request it?

The goal of this patch (and D43002 ) is simply 
to be on-par with what MSVC generates by default. It seems a bit 
counter-intuitive to provide `-grecord-command-line` to clang-cl only to match 
the MSVC behavior, but if that's the general consensus, I'm fine as long as 
`LF_BUILDINFO` is supported in LLVM.

In D80833#3052741 , @dexonsmith wrote:

> If you do go with "off-by-default", the natural driver option to use would be 
> the existing `-grecord-command-line`. You could use the same plumbing through 
> `-cc1` that it does.

You mean using the `llvm.commandline` metadata? That's an interesting idea 
which should be explored.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80833/new/

https://reviews.llvm.org/D80833

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43002: [CodeView] Emit S_OBJNAME record

2021-09-24 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp:752
 
+static void unescapeSlashes(SmallVectorImpl ) {
+  auto Read = Str.begin();

rnk wrote:
> aganea wrote:
> > rnk wrote:
> > > This isn't unescaping them, it's just canonicalizing double slashes to 
> > > one slash, right? Would `llvm::sys::native` suffice?
> > `llvm::sys::path::native()` doesn't remove consecutive (back)slashes. I 
> > think @zturner's main intent was when debugging in Visual Studio with 
> > arguments from LIT tests, they sometimes contain double backslashes.
> I see. I think "unescape" shouldn't be in the name, this isn't about escape 
> characters, it's about cleaning up or canonicalizing the path.
I removed this function. Now using `sys::path::remove_dots` which removes the 
consecutive slashes.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D43002/new/

https://reviews.llvm.org/D43002

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43002: [CodeView] Emit S_OBJNAME record

2021-09-24 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea updated this revision to Diff 374884.
aganea marked 5 inline comments as done.
aganea edited reviewers, added: akhuang; removed: zturner, gratianlup.
aganea edited subscribers, added: zturner, gratianlup; removed: aganea.
aganea added a comment.
Herald added subscribers: dang, mgorny.

As suggested by @rnk


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D43002/new/

https://reviews.llvm.org/D43002

Files:
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Driver/Job.h
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CMakeLists.txt
  clang/test/CodeGenCXX/debug-info-objname.cpp
  llvm/include/llvm/LTO/LTO.h
  llvm/include/llvm/Support/ToolOutputFile.h
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.h
  llvm/lib/LTO/Caching.cpp
  llvm/lib/LTO/LTOBackend.cpp
  llvm/test/DebugInfo/COFF/globals.ll
  llvm/test/DebugInfo/COFF/multifunction.ll
  llvm/test/DebugInfo/COFF/pr28747.ll
  llvm/test/DebugInfo/COFF/simple.ll
  llvm/test/DebugInfo/COFF/vframe-fpo.ll
  llvm/test/MC/AArch64/coff-debug.ll
  llvm/test/MC/ARM/coff-debugging-secrel.ll
  llvm/test/MC/COFF/cv-compiler-info.ll
  llvm/tools/llc/llc.cpp
  llvm/tools/llvm-lto2/llvm-lto2.cpp

Index: llvm/tools/llvm-lto2/llvm-lto2.cpp
===
--- llvm/tools/llvm-lto2/llvm-lto2.cpp
+++ llvm/tools/llvm-lto2/llvm-lto2.cpp
@@ -369,7 +369,7 @@
 std::error_code EC;
 auto S = std::make_unique(Path, EC, sys::fs::OF_None);
 check(EC, Path);
-return std::make_unique(std::move(S));
+return std::make_unique(std::move(S), Path);
   };
 
   auto AddBuffer = [&](size_t Task, std::unique_ptr MB) {
Index: llvm/tools/llc/llc.cpp
===
--- llvm/tools/llc/llc.cpp
+++ llvm/tools/llc/llc.cpp
@@ -576,6 +576,9 @@
   GetOutputStream(TheTarget->getName(), TheTriple.getOS(), argv[0]);
   if (!Out) return 1;
 
+  // Ensure the filename is passed down to CodeViewDebug.
+  Target->Options.ObjectFilenameForDebug = Out->outputFilename();
+
   std::unique_ptr DwoOut;
   if (!SplitDwarfOutputFile.empty()) {
 std::error_code EC;
Index: llvm/test/MC/COFF/cv-compiler-info.ll
===
--- llvm/test/MC/COFF/cv-compiler-info.ll
+++ llvm/test/MC/COFF/cv-compiler-info.ll
@@ -1,4 +1,6 @@
-; RUN: llc -mtriple i686-pc-windows-msvc < %s | FileCheck %s
+; RUN: llc -mtriple i686-pc-windows-msvc < %s | FileCheck %s --check-prefixes=CHECK,STDOUT
+; RUN: llc -mtriple i686-pc-windows-msvc < %s -o %t
+; RUN: FileCheck %s --input-file=%t --check-prefixes=CHECK,FILE
 ; ModuleID = 'D:\src\scopes\foo.cpp'
 source_filename = "D:\5Csrc\5Cscopes\5Cfoo.cpp"
 target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
@@ -20,19 +22,23 @@
 ; One .debug$S section should contain an S_COMPILE3 record that identifies the
 ; source language and the version of the compiler based on the DICompileUnit.
 ; CHECK: 	.section	.debug$S,"dr"
+; CHECK:.short  4353# Record kind: S_OBJNAME
+; CHECK-NEXT:   .long   0   # Signature
+; STDOUT-NEXT:  .byte   0   # Object name
+; FILE-NEXT:.asciz	"{{.*}}{{|/}}cv-compiler-info.ll.tmp" # Object name
 ; CHECK: 		.short	4412  # Record kind: S_COMPILE3
-; CHECK: 		.long	1   # Flags and language
-; CHECK: 		.short	7 # CPUType
-; CHECK: 		.short	4 # Frontend version
-; CHECK: 		.short	0
-; CHECK: 		.short	0
-; CHECK: 		.short	0
-; CHECK: 		.short	[[BACKEND_VERSION:[0-9]+]]  # Backend version
-; CHECK: 		.short	0
-; CHECK: 		.short	0
-; CHECK: 		.short	0
-; CHECK: 		.asciz	"clang version 4.0.0 "  # Null-terminated compiler version string
-; CHECK-NOT: .short	4412  # Record kind: S_COMPILE3
+; CHECK-NEXT:   .long	1   # Flags and language
+; CHECK-NEXT: 	.short	7 # CPUType
+; CHECK-NEXT: 	.short	4 # Frontend version
+; CHECK-NEXT: 	.short	0
+; CHECK-NEXT: 	.short	0
+; CHECK-NEXT: 	.short	0
+; CHECK-NEXT: 	.short	[[BACKEND_VERSION:[0-9]+]]  # Backend version
+; CHECK-NEXT: 	.short	0
+; CHECK-NEXT: 	.short	0
+; CHECK-NEXT: 	.short	0
+; CHECK-NEXT: 	.asciz	"clang version 4.0.0 "  # Null-terminated compiler version string
+; CHECK-NOT:.short	4412  # Record kind: S_COMPILE3
 !1 = !DIFile(filename: "D:\5Csrc\5Cscopes\5Cfoo.cpp", directory: "D:\5Csrc\5Cscopes\5Cclang")
 !2 = !{}
 !7 = !{i32 2, !"CodeView", i32 1}
Index: llvm/test/MC/ARM/coff-debugging-secrel.ll
===
--- llvm/test/MC/ARM/coff-debugging-secrel.ll
+++ llvm/test/MC/ARM/coff-debugging-secrel.ll
@@ -42,10

[PATCH] D109977: LLVM Driver Multicall tool

2021-09-17 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

This is really a great change, thanks @beanz!




Comment at: llvm/tools/llvm-objcopy/llvm-objcopy.cpp:404
 
-int main(int argc, char **argv) {
+int llvm_objcopy_main(int argc, char **argv) {
   InitLLVM X(argc, argv);

Shouldn't we say:
```
int objcopy_main(int argc, char **argv) {
```
here and the other places + all supporting code, if we want `llvm objcopy` 
(without the dash) like @phosek suggests?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109977/new/

https://reviews.llvm.org/D109977

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103773: [clang-cl] Add /permissive and /permissive-

2021-06-15 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: clang/test/Driver/cl-permissive.c:15
+// PERMISSIVE-OVERWRITE-NOT: "-fdelayed-template-parsing"
+// RUN: %clang_cl /permissive- /Zc:twoPhase- -### -- %s 2>&1 | FileCheck 
-check-prefix=PERMISSIVE-MINUS-OVERWRITE %s
+// PERMISSIVE-MINUS-OVERWRITE-NOT: "-fno-operator-names"

Hello @zero9178 !
After this patch, the following fails:
`// RUN: %clang_cl /permissive- -- %s`
generates:
`error: error reading '/Zc:strictStrings'`
Because `/Zc:strictStrings` isn't correctly expanded to 
`-Werror=c++11-compat-deprecated-writable-strings` as it should, but it is 
passed as-is to cc1. You can put a breakpoint here: 
https://github.com/llvm/llvm-project/blob/fc018ebb608ee0c1239b405460e49f1835ab6175/clang/lib/Driver/ToolChains/Clang.cpp#L5374
 and observe before/after this line.
Would you possibly have a chance to take a look please?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103773/new/

https://reviews.llvm.org/D103773

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103664: [Windows SEH]: Fix -O2 crash for Windows -EHa

2021-06-04 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

Thanks for the quick fix! Would you mind fixing the two failing tests please?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103664/new/

https://reviews.llvm.org/D103664

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D80344: [Windows SEH]: HARDWARE EXCEPTION HANDLING (MSVC -EHa) - Part 1

2021-06-03 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

In D80344#2797317 , @tentzen wrote:

> @aganea , this patch should be zero-impact without explicit option 
> -fasync-exceptions.  Are you also seeing a crash without this option?

I'm using `/EHa` which I expect translates to `-fasync-exceptions`. Removing 
`/EHa` doesn't cause the crash.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80344/new/

https://reviews.llvm.org/D80344

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D80344: [Windows SEH]: HARDWARE EXCEPTION HANDLING (MSVC -EHa) - Part 1

2021-06-03 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

In D80344#2792355 , @tentzen wrote:

> Thank you for reporting this .  From the callstack it does not seem related 
> to this patch.

It was actually `git bisect` which pointed to me to this patch, it could be a 
side-effect of it.

> Could you share the repro case @__compile.rsp temp.i with me?

Will surely do, I don't have a simple repro yet.

I'm also seeing a 3rd issue, different from the ones reported above, but it 
might all be the same thing:

  clang-cl: /mnt/llvm-project/clang/lib/CodeGen/CGCleanup.cpp:1322: void 
EmitSehScope(clang::CodeGen::CodeGenFunction &, llvm::FunctionCallee &): 
Assertion `BB && InvokeDest' failed.
  PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash 
backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.  Program arguments: /mnt/llvm-project/stage0/bin/clang-cl 
@/mnt/llvm-project/__test/__compile.rsp temp.i
  1.  (edited).cpp:1025:1 : current parser token 
'static_assert'
  2.  (edited).cpp:56:1 : LLVM IR generation of 
declaration '(edited)'
  3.  (edited).cpp:91:18: Generating code for declaration '(edited)'
   #0 0x05903223 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(/mnt/llvm-project/stage0/bin/clang-cl+0x5903223)
   #1 0x05900f6e llvm::sys::RunSignalHandlers() 
(/mnt/llvm-project/stage0/bin/clang-cl+0x5900f6e)
   #2 0x059025cd llvm::sys::CleanupOnSignal(unsigned long) 
(/mnt/llvm-project/stage0/bin/clang-cl+0x59025cd)
   #3 0x05876bc3 (anonymous 
namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) 
CrashRecoveryContext.cpp:0:0
   #4 0x05876d2e CrashRecoverySignalHandler(int) 
CrashRecoveryContext.cpp:0:0
   #5 0x7f88cc4d73c0 __restore_rt 
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
   #6 0x7f88cbf8818b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4618b)
   #7 0x7f88cbf67859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x25859)
   #8 0x7f88cbf67729 (/lib/x86_64-linux-gnu/libc.so.6+0x25729)
   #9 0x7f88cbf78f36 (/lib/x86_64-linux-gnu/libc.so.6+0x36f36)
  #10 0x05c91e05 EmitSehScope(clang::CodeGen::CodeGenFunction&, 
llvm::FunctionCallee&) CGCleanup.cpp:0:0
  #11 0x05c8c918 
clang::CodeGen::EHScopeStack::pushCleanup(clang::CodeGen::CleanupKind, unsigned 
long) (/mnt/llvm-project/stage0/bin/clang-cl+0x5c8c918)
  #12 0x05bf80ef void 
clang::CodeGen::CodeGenFunction::pushFullExprCleanup(clang::CodeGen::CleanupKind, 
clang::CodeGen::Address, llvm::Value*) CGCall.cpp:0:0
  #13 0x05cb937c 
clang::CodeGen::CodeGenFunction::EmitMaterializeTemporaryExpr(clang::MaterializeTemporaryExpr
 const*) (/mnt/llvm-project/stage0/bin/clang-cl+0x5cb937c)
  #14 0x05cb76a3 
clang::CodeGen::CodeGenFunction::EmitLValue(clang::Expr const*) 
(/mnt/llvm-project/stage0/bin/clang-cl+0x5cb76a3)
  #15 0x05cbba94 
clang::CodeGen::CodeGenFunction::EmitReferenceBindingToExpr(clang::Expr const*) 
(/mnt/llvm-project/stage0/bin/clang-cl+0x5cbba94)
  #16 0x05bf0114 
clang::CodeGen::CodeGenFunction::EmitCallArg(clang::CodeGen::CallArgList&, 
clang::Expr const*, clang::QualType) 
(/mnt/llvm-project/stage0/bin/clang-cl+0x5bf0114)
  #17 0x05bef273 
clang::CodeGen::CodeGenFunction::EmitCallArgs(clang::CodeGen::CallArgList&, 
clang::CodeGen::CodeGenFunction::PrototypeWrapper, 
llvm::iterator_range >, 
clang::CodeGen::CodeGenFunction::AbstractCallee, unsigned int, 
clang::CodeGen::CodeGenFunction::EvaluationOrder) 
(/mnt/llvm-project/stage0/bin/clang-cl+0x5bef273)
  #18 0x05e1368d 
commonEmitCXXMemberOrOperatorCall(clang::CodeGen::CodeGenFunction&, 
clang::CXXMethodDecl const*, llvm::Value*, llvm::Value*, clang::QualType, 
clang::CallExpr const*, clang::CodeGen::CallArgList&, 
clang::CodeGen::CallArgList*) CGExprCXX.cpp:0:0
  #19 0x05e13383 
clang::CodeGen::CodeGenFunction::EmitCXXMemberOrOperatorCall(clang::CXXMethodDecl
 const*, clang::CodeGen::CGCallee const&, clang::CodeGen::ReturnValueSlot, 
llvm::Value*, llvm::Value*, clang::QualType, clang::CallExpr const*, 
clang::CodeGen::CallArgList*) (/mnt/llvm-project/stage0/bin/clang-cl+0x5e13383)
  #20 0x05e15afa 
clang::CodeGen::CodeGenFunction::EmitCXXMemberOrOperatorMemberCallExpr(clang::CallExpr
 const*, clang::CXXMethodDecl const*, clang::CodeGen::ReturnValueSlot, bool, 
clang::NestedNameSpecifier*, bool, clang::Expr const*) 
(/mnt/llvm-project/stage0/bin/clang-cl+0x5e15afa)
  #21 0x05e16330 
clang::CodeGen::CodeGenFunction::EmitCXXOperatorMemberCallExpr(clang::CXXOperatorCallExpr
 const*, clang::CXXMethodDecl const*, clang::CodeGen::ReturnValueSlot) 
(/mnt/llvm-project/stage0/bin/clang-cl+0x5e16330)
  #22 0x05cd51f7 
clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, 
clang::CodeGen::ReturnValueSlot) 
(/mnt/llvm-project/stage0/bin/clang-cl+0x5cd51f7)
  #23 0x05cc27e1

[PATCH] D80344: [Windows SEH]: HARDWARE EXCEPTION HANDLING (MSVC -EHa) - Part 1

2021-06-01 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

Hello, this patch introduces a regression in one of our codebases. The 
compilation of several TUs fails with the following callstack:

  PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash 
backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.  Program arguments: /media/project2/llvm-project/stage0/bin/clang-cl 
@__compile.rsp temp.i
  1.   parser at end of file
  2.  Optimizer
   #0 0x043c2633 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
/media/project2/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:13
   #1 0x043c08f0 llvm::sys::RunSignalHandlers() 
/media/project2/llvm-project/llvm/lib/Support/Signals.cpp:77:18
   #2 0x043c1d7d llvm::sys::CleanupOnSignal(unsigned long) 
/media/project2/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3
   #3 0x04343206 (anonymous 
namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) 
/media/project2/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:75:5
   #4 0x04343206 CrashRecoverySignalHandler(int) 
/media/project2/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:388:51
   #5 0x7f58152c4a90 __restore_rt sigaction.c:0:0
   #6 0x03c5c11f 
llvm::ilist_sentinel >::empty() const 
/media/project2/llvm-project/llvm/include/llvm/ADT/ilist_node.h:248:36
   #7 0x03c5c11f llvm::simple_ilist::empty() const 
/media/project2/llvm-project/llvm/include/llvm/ADT/simple_ilist.h:131:55
   #8 0x03c5c11f llvm::BasicBlock::empty() const 
/media/project2/llvm-project/llvm/include/llvm/IR/BasicBlock.h:307:66
   #9 0x03c5c11f llvm::BasicBlock::removePredecessor(llvm::BasicBlock*, 
bool) /media/project2/llvm-project/llvm/lib/IR/BasicBlock.cpp:328:7
  #10 0x04432005 markAliveBlocks(llvm::Function&, 
llvm::SmallPtrSetImpl&, llvm::DomTreeUpdater*) 
/media/project2/llvm-project/llvm/lib/Transforms/Utils/Local.cpp:2290:15
  #11 0x04432005 llvm::removeUnreachableBlocks(llvm::Function&, 
llvm::DomTreeUpdater*, llvm::MemorySSAUpdater*) 
/media/project2/llvm-project/llvm/lib/Transforms/Utils/Local.cpp:2402:18
  #12 0x042e72c7 simplifyFunctionCFGImpl(llvm::Function&, 
llvm::TargetTransformInfo const&, llvm::DominatorTree*, 
llvm::SimplifyCFGOptions const&) 
/media/project2/llvm-project/llvm/lib/Transforms/Scalar/SimplifyCFGPass.cpp:0:22
  #13 0x042e72c7 simplifyFunctionCFG(llvm::Function&, 
llvm::TargetTransformInfo const&, llvm::DominatorTree*, 
llvm::SimplifyCFGOptions const&) 
/media/project2/llvm-project/llvm/lib/Transforms/Scalar/SimplifyCFGPass.cpp:275:18
  #14 0x042e70d1 llvm::SimplifyCFGPass::run(llvm::Function&, 
llvm::AnalysisManager&) 
/media/project2/llvm-project/llvm/lib/Transforms/Scalar/SimplifyCFGPass.cpp:321:7
  #15 0x02e605bd llvm::detail::PassModel >::run(llvm::Function&, 
llvm::AnalysisManager&) BPFTargetMachine.cpp:0:0
  #16 0x03d54659 llvm::SmallPtrSet::operator=(llvm::SmallPtrSet&&) 
/media/project2/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:488:13
  #17 0x03d54659 
llvm::PreservedAnalyses::operator=(llvm::PreservedAnalyses&&) 
/media/project2/llvm-project/llvm/include/llvm/IR/PassManager.h:155:7
  #18 0x03d54659 llvm::PassManager >::run(llvm::Function&, 
llvm::AnalysisManager&) 
/media/project2/llvm-project/llvm/include/llvm/IR/PassManager.h:509:16
  #19 0x02aa318d llvm::detail::PassModel >, 
llvm::PreservedAnalyses, llvm::AnalysisManager 
>::run(llvm::Function&, llvm::AnalysisManager&) 
AMDGPUTargetMachine.cpp:0:0
  #20 0x03d5769e llvm::SmallPtrSet::operator=(llvm::SmallPtrSet&&) 
/media/project2/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:488:13
  #21 0x03d5769e 
llvm::PreservedAnalyses::operator=(llvm::PreservedAnalyses&&) 
/media/project2/llvm-project/llvm/include/llvm/IR/PassManager.h:155:7
  #22 0x03d5769e llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, 
llvm::AnalysisManager&) 
/media/project2/llvm-project/llvm/lib/IR/PassManager.cpp:117:14
  #23 0x02aa2fed llvm::detail::PassModel >::run(llvm::Module&, 
llvm::AnalysisManager&) AMDGPUTargetMachine.cpp:0:0
  #24 0x03d538f6 llvm::SmallPtrSet::operator=(llvm::SmallPtrSet&&) 
/media/project2/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:488:13
  #25 0x03d538f6 
llvm::PreservedAnalyses::operator=(llvm::PreservedAnalyses&&) 
/media/project2/llvm-project/llvm/include/llvm/IR/PassManager.h:155:7
  #26 0x03d538f6 llvm::PassManager >::run(llvm::Module&, 
llvm::AnalysisManager&) 
/media/project2/llvm-project/llvm/include/llvm/IR/PassManager.h:509:16
  #27 0x045ba45e llvm::SmallPtrSetImplBase::isSmall() const 
/media/project2/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:194:33
  #28 0x045ba45e llvm::SmallPtrSetImplBase::~SmallPtrSetImplBase() 
/media/project2/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:82:10
  #29 0x045ba45e

[PATCH] D102633: [clang-scan-deps] Improvements to thread usage

2021-05-27 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

@dexonsmith Yes, using the Clang Tooling API seems like a good option, however 
some logic could/would be needed from 
`clang/tools/clang-scan-deps/ClangScanDeps.cpp`. Using clang-scan-deps as-a-DLL 
seemed like the best option on the short term, since we're using its `main()` 
//almost// verbatim with only a few minor changes. We still need to solve a 
contention issue related to the Windows implementation of `sys::fs::status()`, 
but then once everything is sorted out we'll re-consider the usage of the DLL.

In the meanwhile, do you have any opinion on this patch and/or on 
https://reviews.llvm.org/D102633#2773578 ? Do you think there's value for users?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102633/new/

https://reviews.llvm.org/D102633

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102633: [clang-scan-deps] Improvements to thread usage

2021-05-21 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a subscriber: mehdi_amini.
aganea added a comment.

In D102633#2769762 , @arphaman wrote:

> It might be good for @aganea to take a look as well.

Thanks! I actually work with @saudi, I already took a look at the patch before 
uploading. However I'm stil torn about running one of the workers on the main 
thread. I fear that we could have random errors because of the stack size of 
the "main" thread that could be different from the stack size of the 
"satellite" threads. There's 99.99% chance that this won't happen, but I'd 
prefer that behavior to be explicit.

We could have:

  -j0 : use all hardware threads
  -j1: don't use multi-threading, run all the tasks on the main thread
  -jN: use the specified number of threads

The rationale is that we're using clang-scan-deps as-a-DLL in Fastbuild, to 
extract the dependencies. Since Fastbuild already has its own thread pool 
management, we call into clang-scan-deps with -j1 from different Fastbuild 
threads (but keeping the `DependencyScanningService` alive between calls). It 
would great if each call to clang-scan-deps wouldn't create a extra new thread.

Perhaps any of you would like to comment? +@mehdi_amini


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102633/new/

https://reviews.llvm.org/D102633

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102736: Fix tmp files being left on Windows builds.

2021-05-21 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: clang/include/clang/Frontend/CompilerInstance.h:170
 std::string TempFilename;
+Optional TempFile;
 

Can we always use `TempFile`? And remove `TempFilename` in that case?



Comment at: clang/lib/Frontend/CompilerInstance.cpp:728
+
+std::string ErrorMsg;
+if (OF.TempFile) {

I think the idea overall in LLVM is to defer the error rendering as late as 
possible. You could probably only keep an `Error` variable here, and render it 
below in the diagnostic with `toString(E)`.



Comment at: clang/lib/Frontend/CompilerInstance.cpp:733
+} else {
+  if (std::error_code EC =
+  llvm::sys::fs::rename(OF.TempFilename, NewOutFile))

Here you can probably use `ECError` or `errorCodeToError()` with what is said 
slightly above.



Comment at: clang/lib/Frontend/CompilerInstance.cpp:840
 int fd;
-std::error_code EC = llvm::sys::fs::createUniqueFile(
-TempPath, fd, TempPath,
-Binary ? llvm::sys::fs::OF_None : llvm::sys::fs::OF_Text);
+#if _WIN32
+// On Windows, use llvm::sys::fs::TempFile to write the output file so

Usually it is better to avoid platform-specific logic. Could we use `TempFile` 
all the time on all platforms?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102736/new/

https://reviews.llvm.org/D102736

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102736: Fix tmp files being left on Windows builds.

2021-05-18 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

In D102736#2767516 , @amccarth wrote:

> I seem to recall some thrashing on this topic a few months ago.  If I'm 
> remembering correctly, setting the disposition to delete temporary files on 
> Windows was causing problems with Rust builds because you can't always set 
> the delete disposition (e.g., for a file on a network drive).  I think it got 
> pulled out, and then put back in in a limited way.

It landed in rG64ab2b6825c5aeae6e4afa7ef0829b89a6828102 
 - it 
fixed the initial Rust issue. I can add a Windows 7 bot if you think it's worth 
it. But I'm happy to occasionally maintain the Win7 port for as long as it's 
needed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102736/new/

https://reviews.llvm.org/D102736

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102736: Fix tmp files being left on Windows builds.

2021-05-18 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

Do you think the existing crash tests can be modified to validate that .tmp 
files are deleted indeed?




Comment at: clang/lib/Frontend/CompilerInstance.cpp:829
+Binary ? llvm::sys::fs::OF_None : llvm::sys::fs::OF_Text;
+// Use OF_Delete on Windows so that file can be marked for deletion.
+#ifdef _WIN32

What do you think about having the comment inside the `#idef _WIN32` ?



Comment at: llvm/include/llvm/Support/FileSystem.h:994
+// closed. On non-Windows, this is a no-op.
+std::error_code UnmarkFileForDeletion(file_t Handle);
+

It is unclear to me what is the right formatting for function names here? Is it 
what clang-tidy suggests or lowercase first, like the other functions?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102736/new/

https://reviews.llvm.org/D102736

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102339: [clang] On Windows, ignore case and separators when discarding duplicate dependency file paths.

2021-05-13 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

In D102339#2755867 , @thakis wrote:

> We share obj files built on linux and on windows. So that's a goal for us.

Hello @thakis, I believe you don't use this codepath to generate the cache key, 
do you? I thought you had a custom python script to extract the dependencies?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102339/new/

https://reviews.llvm.org/D102339

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102339: [clang] On Windows, ignore case and separators when discarding duplicate dependency file paths.

2021-05-12 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: clang/lib/Frontend/DependencyFile.cpp:145
+  StringRef SearchPath;
+#ifdef _WIN32
+  // Make the search insensitive to case and separators.

amccarth wrote:
> rnk wrote:
> > I feel like this should somehow be a property of the input virtual 
> > filesystem: we should be able to ask the VFS to do the path 
> > canonicalization for us, or ask if the FS is case insensitive and do the 
> > lower-casing if so.
> Additional complication:
> 
> Windows NTFS partitions can have case-sensitivity enabled on a per-directory 
> basis, so there is no single answer for the filesystem or even the host OS.  
> Granted, this is not yet a commonly used feature.
> 
> I wonder about the (also rarely used) case of cross compiling for a Linux 
> target on a Windows build machine.
> Windows NTFS partitions can have case-sensitivity enabled on a per-directory 
> basis, so there is no single answer for the filesystem or even the host OS. 
> Granted, this is not yet a commonly used feature.
I think case-sensitiveness was added for WSL, I'm not sure that feature would 
be used outside of that context. This would otherwise require quering the 
filesystem for the case of each directory component.

> I wonder about the (also rarely used) case of cross compiling for a Linux 
> target on a Windows build machine.
It's not that rare :) We do cross-compile all of our platforms from Windows, 
most of them are POSIX/Linux variants. This could become a problem although if 
we decided to share the dependency list accross systems, for example if we 
shared the cache artefacts (.OBJ files) between Windows and Linux bots. In 
which case a path renormalization would be necessary. The easiest solution for 
that purpose could be a case-insensitive FS on Linux and always execute the 
code that @saudi added in this patch. But that's not the goal right now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102339/new/

https://reviews.llvm.org/D102339

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100756: [llvm-rc] [4/4] Add a GNU windres-like frontend to llvm-rc

2021-04-21 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:300
+
+std::string unescape(StringRef S) {
+  std::string Out;

mstorsjo wrote:
> aganea wrote:
> > I would also need this function in D43002 (see unescapeSlashes), do you 
> > think we can move it to `sys::path` or any other "support" lib?
> This does things differently than your function - this converts `\\\"` into 
> `\"` while your version leaves `\\"` if I read it correctly.
> 
> (I'm also considering a different, platform specific unescaping strategy - 
> that'd be closer to how GNU windres behaves, but makes for a more 
> inconsistent tool. Keeping the logic here makes it easier to tweak if needed.)
I think `unescapeSlashes` in D43002 was only a quick hack to allow copy-pasting 
a command-line file name from LIT outputs into the VS debugger options dialog. 
If the file name contains double quotes I would expect it to be converted as 
you do, but double quotes cannot happen in file names on Windows. In theory one 
could use the `S_OBJNAME` and `LF_BUILDINFO` records to repro a clang-cl build 
command on Linux, but that seems improbable? (since the feature is meant to be 
used on Windows)



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:567
+  if (InputArgs.hasArg(OPT_lang_id)) {
+if (InputArgs.getLastArgValue(OPT_lang_id).getAsInteger(16, Opts.LangId))
+  fatalError("Invalid language id: " +

mstorsjo wrote:
> aganea wrote:
> > There was a latent issue here - unrelated to the moving of code around - I 
> > don't know if you want to fix it now or after? That is, `s/16/0/`.
> Hmm, as far as I can see, both rc.exe and GNU windres interpret values as 
> hexadecimal - if I run e.g. `rc.exe -l 40 test.rc`, where `40` is ambiguous, 
> I get language id 64.
Ok, we only have stuff like `rc.exe /l 0x0409` in our build scripts, the 0x in 
front isn't consumed, I though it was mandatory.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100756/new/

https://reviews.llvm.org/D100756

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100756: [llvm-rc] [4/4] Add a GNU windres-like frontend to llvm-rc

2021-04-21 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:259
 
-} // anonymous namespace
+static bool consume_back_lower(StringRef , const char *str) {
+  if (!S.endswith_lower(str))

`s/str/Str/`



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:300
+
+std::string unescape(StringRef S) {
+  std::string Out;

I would also need this function in D43002 (see unescapeSlashes), do you think 
we can move it to `sys::path` or any other "support" lib?



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:567
+  if (InputArgs.hasArg(OPT_lang_id)) {
+if (InputArgs.getLastArgValue(OPT_lang_id).getAsInteger(16, Opts.LangId))
+  fatalError("Invalid language id: " +

There was a latent issue here - unrelated to the moving of code around - I 
don't know if you want to fix it now or after? That is, `s/16/0/`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100756/new/

https://reviews.llvm.org/D100756

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100755: [llvm-rc] [3/4] Run clang to preprocess input files

2021-04-20 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea accepted this revision.
aganea added a comment.

LGTM.




Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:94
+
+ErrorOr findClang(const char *Argv0) {
+  StringRef Parent = llvm::sys::path::parent_path(Argv0);

mstorsjo wrote:
> aganea wrote:
> > Since you're not using the `std::error_code` below in the call site, should 
> > this return `Expected<...>`? In that case, the variable `Path` shouldn't be 
> > needed?
> With `Expected<>` I'd need to craft an `Error` at the end if I don't have a 
> path to return, but do you mean `Optional<>`? I guess that'd work - but as 
> `findProgramByName()` returns `ErrorOr` I kept the same 
> signature.
> 
> Even if returning `Optional<>`, we need a local variable to receive the 
> `ErrorOr` from `findProgramByName()` and inspect it.
> 
> In the future (after a release or so) I'd intend for this to be a hard error, 
> so at that point, the returned error code actually would be printed.
I see, thanks for the explanation!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100755/new/

https://reviews.llvm.org/D100755

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100755: [llvm-rc] [3/4] Run clang to preprocess input files

2021-04-20 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:94
+
+ErrorOr findClang(const char *Argv0) {
+  StringRef Parent = llvm::sys::path::parent_path(Argv0);

Since you're not using the `std::error_code` below in the call site, should 
this return `Expected<...>`? In that case, the variable `Path` shouldn't be 
needed?



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:154
+  Args.push_back("-U");
+  break;
+}

thakis wrote:
> mstorsjo wrote:
> > thakis wrote:
> > > Here's our chromium wrapper: 
> > > https://source.chromium.org/chromium/chromium/src/+/master:build/toolchain/win/rc/rc.py
> > > 
> > > On Windows, /winsysroot support and possibly -imsvc support would be nice 
> > > too.
> > Those sound useful - but I think I'd prefer to defer adding support for 
> > more nonstandard preprocessing options to a later patch.
> > 
> > What do you think of a generic `--preprocessor-arg` like in the windres 
> > frontend, which might be useful for @aganea?
> We don't need a general `--preprocessor-arg` as long as common args work.
> 
> Oh, on that note: 
> https://source.chromium.org/chromium/chromium/src/+/master:build/toolchain/win/rc/rc.py
>  also has `/showIncludes` support which is necessary to make ninja re-build 
> .rc files if either
> 
> * an included .h file is changed (needs preprocessor output)
> * an included resource file (.ico or similar) is changed (needs llvm-rc 
> support)
> 
> Don't know if llvm-rc has support for the latter part. If it doesn't, that'd 
> be nice to add, and some test that checks that both parts work would be nice. 
> (Neither in this patch; just thinking about what we'd need to switch.)
> We don't need a general --preprocessor-arg as long as common args work.
+1 with Nico. Native arguments in `llvm-rc` would be better (later).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100755/new/

https://reviews.llvm.org/D100755

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D92191: [clang-scan-deps] Add support for clang-cl

2021-04-19 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

Thanks! We found the issue. I think I'll revert the patch, and will reland a 
fixed version.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92191/new/

https://reviews.llvm.org/D92191

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D92191: [clang-scan-deps] Add support for clang-cl

2021-04-19 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

@gulfem We're taking a look now. Could you please post a link to the full build 
log, including the cmake flags used?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92191/new/

https://reviews.llvm.org/D92191

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D92191: [clang-scan-deps] Add support for clang-cl

2021-04-17 Thread Alexandre Ganea via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbb26fa8c286b: [clang-scan-deps] Add support for clang-cl 
(authored by saudi, committed by aganea).

Changed prior to commit:
  https://reviews.llvm.org/D92191?vs=318553=338330#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92191/new/

https://reviews.llvm.org/D92191

Files:
  clang/test/ClangScanDeps/Inputs/has_include_if_elif.json
  clang/test/ClangScanDeps/Inputs/header_stat_before_open_cdb.json
  clang/test/ClangScanDeps/Inputs/headerwithdirname.json
  clang/test/ClangScanDeps/Inputs/headerwithdirnamefollowedbyinclude.json
  clang/test/ClangScanDeps/Inputs/modules_cdb_clangcl.json
  clang/test/ClangScanDeps/Inputs/no-werror.json
  clang/test/ClangScanDeps/Inputs/regular_cdb_clangcl.json
  clang/test/ClangScanDeps/Inputs/static-analyzer-cdb.json
  clang/test/ClangScanDeps/Inputs/strip_diag_serialize.json
  clang/test/ClangScanDeps/Inputs/target-filename-cdb.json
  clang/test/ClangScanDeps/Inputs/vfsoverlay_cdb.json
  clang/test/ClangScanDeps/error.cpp
  clang/test/ClangScanDeps/has_include_if_elif.cpp
  clang/test/ClangScanDeps/header_stat_before_open.m
  clang/test/ClangScanDeps/headerwithdirname.cpp
  clang/test/ClangScanDeps/headerwithdirnamefollowedbyinclude.cpp
  clang/test/ClangScanDeps/modules-full.cpp
  clang/test/ClangScanDeps/modules.cpp
  clang/test/ClangScanDeps/no-werror.cpp
  clang/test/ClangScanDeps/regular_cdb.cpp
  clang/test/ClangScanDeps/static-analyzer.c
  clang/test/ClangScanDeps/strip_diag_serialize.cpp
  clang/test/ClangScanDeps/target-filename.cpp
  clang/test/ClangScanDeps/vfsoverlay.cpp
  clang/tools/clang-scan-deps/ClangScanDeps.cpp

Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -12,6 +12,8 @@
 #include "clang/Tooling/DependencyScanning/DependencyScanningTool.h"
 #include "clang/Tooling/DependencyScanning/DependencyScanningWorker.h"
 #include "clang/Tooling/JSONCompilationDatabase.h"
+#include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/Twine.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileUtilities.h"
 #include "llvm/Support/InitLLVM.h"
@@ -49,7 +51,8 @@
   /// option and cache the results for reuse. \returns resource directory path
   /// associated with the given invocation command or empty string if the
   /// compiler path is NOT an absolute path.
-  StringRef findResourceDir(const tooling::CommandLineArguments ) {
+  StringRef findResourceDir(const tooling::CommandLineArguments ,
+bool ClangCLMode) {
 if (Args.size() < 1)
   return "";
 
@@ -65,8 +68,12 @@
 if (CachedResourceDir != Cache.end())
   return CachedResourceDir->second;
 
-std::vector PrintResourceDirArgs{ClangBinaryName,
-"-print-resource-dir"};
+std::vector PrintResourceDirArgs{ClangBinaryName};
+if (ClangCLMode)
+  PrintResourceDirArgs.push_back("/clang:-print-resource-dir");
+else
+  PrintResourceDirArgs.push_back("-print-resource-dir");
+
 llvm::SmallString<64> OutputFile, ErrorFile;
 llvm::sys::fs::createTemporaryFile("print-resource-dir-output",
"" /*no-suffix*/, OutputFile);
@@ -418,24 +425,52 @@
 bool HasMQ = false;
 bool HasMD = false;
 bool HasResourceDir = false;
+bool ClangCLMode = false;
 auto FlagsEnd = llvm::find(Args, "--");
 if (FlagsEnd != Args.begin()) {
+  ClangCLMode =
+  llvm::sys::path::stem(Args[0]).contains_lower("clang-cl") ||
+  llvm::is_contained(Args, "--driver-mode=cl");
+
   // Reverse scan, starting at the end or at the element before "--".
   auto R = llvm::make_reverse_iterator(FlagsEnd);
   for (auto I = R, E = Args.rend(); I != E; ++I) {
 StringRef Arg = *I;
-if (LastO.empty()) {
-  if (Arg == "-o" && I != R)
-LastO = I[-1]; // Next argument (reverse iterator)
-  else if (Arg.startswith("-o"))
-LastO = Arg.drop_front(2).str();
+if (ClangCLMode) {
+  if (LastO.empty()) {
+// With clang-cl, the output obj file can be specified with
+// "/opath", "/o path", "/Fopath", and the dash counterparts.
+// Also, clang-cl adds ".obj" extension if none is found.
+if ((Arg == "-o" || Arg == "/o") && I != R)
+  LastO = I[-1]; // Next argument (reverse iterator)
+else if (Arg.startswith("/Fo") || Arg.startswith("-Fo"))
+  LastO = Arg.drop_front(3).str();
+else if (Arg.startswith("/o") || Arg.startswith("-o"))
+  LastO = Arg.drop_front(2).str();
+

[PATCH] D95099: [clang-scan-deps] : Support -- in clang command lines.

2021-04-17 Thread Alexandre Ganea via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rG488a19d00cba: [clang-scan-deps] Support double-dashes in 
clang command lines (authored by saudi, committed by aganea).

Changed prior to commit:
  https://reviews.llvm.org/D95099?vs=318304=338329#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95099/new/

https://reviews.llvm.org/D95099

Files:
  clang/test/ClangScanDeps/Inputs/regular_cdb.json
  clang/tools/clang-scan-deps/ClangScanDeps.cpp


Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -418,14 +418,15 @@
 bool HasMQ = false;
 bool HasMD = false;
 bool HasResourceDir = false;
-// We need to find the last -o value.
-if (!Args.empty()) {
-  std::size_t Idx = Args.size() - 1;
-  for (auto It = Args.rbegin(); It != Args.rend(); ++It) {
-StringRef Arg = Args[Idx];
+auto FlagsEnd = llvm::find(Args, "--");
+if (FlagsEnd != Args.begin()) {
+  // Reverse scan, starting at the end or at the element before "--".
+  auto R = llvm::make_reverse_iterator(FlagsEnd);
+  for (auto I = R, E = Args.rend(); I != E; ++I) {
+StringRef Arg = *I;
 if (LastO.empty()) {
-  if (Arg == "-o" && It != Args.rbegin())
-LastO = Args[Idx + 1];
+  if (Arg == "-o" && I != R)
+LastO = I[-1]; // Next argument (reverse iterator)
   else if (Arg.startswith("-o"))
 LastO = Arg.drop_front(2).str();
 }
@@ -437,12 +438,11 @@
   HasMD = true;
 if (Arg == "-resource-dir")
   HasResourceDir = true;
---Idx;
   }
 }
 // If there's no -MT/-MQ Driver would add -MT with the value of the 
last
 // -o option.
-tooling::CommandLineArguments AdjustedArgs = Args;
+tooling::CommandLineArguments AdjustedArgs(Args.begin(), FlagsEnd);
 AdjustedArgs.push_back("-o");
 AdjustedArgs.push_back("/dev/null");
 if (!HasMT && !HasMQ) {
@@ -472,6 +472,7 @@
 AdjustedArgs.push_back(std::string(ResourceDir));
   }
 }
+AdjustedArgs.insert(AdjustedArgs.end(), FlagsEnd, Args.end());
 return AdjustedArgs;
   });
   AdjustingCompilations->appendArgumentsAdjuster(
Index: clang/test/ClangScanDeps/Inputs/regular_cdb.json
===
--- clang/test/ClangScanDeps/Inputs/regular_cdb.json
+++ clang/test/ClangScanDeps/Inputs/regular_cdb.json
@@ -11,7 +11,7 @@
 },
 {
   "directory": "DIR",
-  "command": "clang -E DIR/regular_cdb_input.cpp -IInputs -o adena.o",
+  "command": "clang -E -IInputs -o adena.o -- DIR/regular_cdb_input.cpp",
   "file": "DIR/regular_cdb_input.cpp"
 }
 ]


Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -418,14 +418,15 @@
 bool HasMQ = false;
 bool HasMD = false;
 bool HasResourceDir = false;
-// We need to find the last -o value.
-if (!Args.empty()) {
-  std::size_t Idx = Args.size() - 1;
-  for (auto It = Args.rbegin(); It != Args.rend(); ++It) {
-StringRef Arg = Args[Idx];
+auto FlagsEnd = llvm::find(Args, "--");
+if (FlagsEnd != Args.begin()) {
+  // Reverse scan, starting at the end or at the element before "--".
+  auto R = llvm::make_reverse_iterator(FlagsEnd);
+  for (auto I = R, E = Args.rend(); I != E; ++I) {
+StringRef Arg = *I;
 if (LastO.empty()) {
-  if (Arg == "-o" && It != Args.rbegin())
-LastO = Args[Idx + 1];
+  if (Arg == "-o" && I != R)
+LastO = I[-1]; // Next argument (reverse iterator)
   else if (Arg.startswith("-o"))
 LastO = Arg.drop_front(2).str();
 }
@@ -437,12 +438,11 @@
   HasMD = true;
 if (Arg == "-resource-dir")
   HasResourceDir = true;
---Idx;
   }
 }
 // If there's no -MT/-MQ Driver would add -MT with the value of the last
 // -o option.
-tooling::CommandLineArguments AdjustedArgs = Args;
+tooling::CommandLineArguments AdjustedArgs(Args.begin(), FlagsEnd);
 AdjustedArgs.push_back("-o");
 AdjustedArgs.push_back("/dev/null");
 if (!HasMT && !HasMQ) {
@@ -472,6 +472,7 @@
 AdjustedArgs.push_back(std::string(ResourceDir));
   }
 }
+AdjustedArgs.insert(AdjustedArgs.end(),

[PATCH] D99973: [Windows] Add test coverage for line endings when rewriting includes

2021-04-06 Thread Alexandre Ganea via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
aganea marked an inline comment as done.
Closed by commit rG8fbc05acd553: [Windows] Add test coverage for line endings 
when rewriting includes (authored by aganea).

Changed prior to commit:
  https://reviews.llvm.org/D99973?vs=335574=335630#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99973/new/

https://reviews.llvm.org/D99973

Files:
  clang/test/Frontend/rewrite-includes-macros.cpp


Index: clang/test/Frontend/rewrite-includes-macros.cpp
===
--- /dev/null
+++ clang/test/Frontend/rewrite-includes-macros.cpp
@@ -0,0 +1,14 @@
+// REQUIRES: system-windows
+// RUN: %clang_cl /E -Xclang -frewrite-includes %s | %clang_cl /c -Xclang 
-verify /Tp -
+// expected-no-diagnostics
+
+int foo();
+int bar();
+#define HELLO \
+  foo(); \
+  bar();
+
+int main() {
+  HELLO
+  return 0;
+}


Index: clang/test/Frontend/rewrite-includes-macros.cpp
===
--- /dev/null
+++ clang/test/Frontend/rewrite-includes-macros.cpp
@@ -0,0 +1,14 @@
+// REQUIRES: system-windows
+// RUN: %clang_cl /E -Xclang -frewrite-includes %s | %clang_cl /c -Xclang -verify /Tp -
+// expected-no-diagnostics
+
+int foo();
+int bar();
+#define HELLO \
+  foo(); \
+  bar();
+
+int main() {
+  HELLO
+  return 0;
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99973: [Windows] Add test coverage for line endings when rewriting includes

2021-04-06 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea marked an inline comment as done.
aganea added inline comments.



Comment at: clang/test/Frontend/rewrite-includes-macros.cpp:15
+}
\ No newline at end of file


mstorsjo wrote:
> I guess the missing newline at end of file isn't one of the aspects that 
> needs to be tested?
It is not indeed, I'll fix that, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99973/new/

https://reviews.llvm.org/D99973

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99973: [Windows] Add test coverage for line endings when rewriting includes

2021-04-06 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea created this revision.
aganea added reviewers: abhina.sreeskantharajan, rnk, amccarth, MaskRay, 
mstorsjo.
aganea requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Validate that we properly generating a single line ending on Windows when using 
`-frewrite-includes`. Otherwise we're breaking split-line macros. The test 
fails before D99837 .

See discussion in https://reviews.llvm.org/D96363#2650460 and D99426 



Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99973

Files:
  clang/test/Frontend/rewrite-includes-macros.cpp


Index: clang/test/Frontend/rewrite-includes-macros.cpp
===
--- /dev/null
+++ clang/test/Frontend/rewrite-includes-macros.cpp
@@ -0,0 +1,14 @@
+// REQUIRES: system-windows
+// RUN: %clang_cl /E -Xclang -frewrite-includes %s | %clang_cl /c -Xclang 
-verify /Tp -
+// expected-no-diagnostics
+
+int foo();
+int bar();
+#define HELLO \
+  foo(); \
+  bar();
+
+int main() {
+  HELLO
+  return 0;
+}
\ No newline at end of file


Index: clang/test/Frontend/rewrite-includes-macros.cpp
===
--- /dev/null
+++ clang/test/Frontend/rewrite-includes-macros.cpp
@@ -0,0 +1,14 @@
+// REQUIRES: system-windows
+// RUN: %clang_cl /E -Xclang -frewrite-includes %s | %clang_cl /c -Xclang -verify /Tp -
+// expected-no-diagnostics
+
+int foo();
+int bar();
+#define HELLO \
+  foo(); \
+  bar();
+
+int main() {
+  HELLO
+  return 0;
+}
\ No newline at end of file
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99837: [Windows] Turn off text mode correctly in Rewriter to stop CRLF translation

2021-04-06 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea accepted this revision.
aganea added a comment.
This revision is now accepted and ready to land.

It works now, thanks! :-)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99837/new/

https://reviews.llvm.org/D99837

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99426: [SystemZ][z/OS][Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

2021-04-02 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

In D99426#2666141 , 
@abhina.sreeskantharajan wrote:

> In D99426#2665361 , @aganea wrote:
>
>> I am still concerned by the fact that this patch doesn't fix the issue 
>> mentionned in https://reviews.llvm.org/D96363#2650460
>> Was the intention to fix that issue? Will the fix be done in a subsequent 
>> patch?
>
> I was fairly confident that if https://reviews.llvm.org/D96363 was the patch 
> that was causing the issue for you

That is the case! I've confirmed that `git checkout 
fdb640ea30d416368b76b68b106deda580c6aced~1 && ninja clang -C build` generates a 
`clang-cl.exe` that works with my above test case. `git revert 
fdb640ea30d416368b76b68b106deda580c6aced` locally over ToT fixes the issue.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99426/new/

https://reviews.llvm.org/D99426

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99426: [Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

2021-04-01 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

I am still concerned by the fact that this patch doesn't fix the issue 
mentionned in https://reviews.llvm.org/D96363#2650460
Was the intention to fix that issue? Will the fix be done in a subsequent patch?




Comment at: llvm/lib/Support/Windows/Path.inc:1087
+  if (Flags & OF_CRLF) {
+assert(Flags & OF_Text, "Flags set OF_CRLF without OF_Text");
 CrtOpenFlags |= _O_TEXT;

`s/,/ &&/`


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99426/new/

https://reviews.llvm.org/D99426

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation

2021-03-30 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

>> In D99363#2653476 , 
>> @abhina.sreeskantharajan wrote:
>>
>>> 
>
> This was only other file from https://reviews.llvm.org/D96363 that was using 
> OF_TextWithCRLF instead of OF_Text. Please let me know if this latest patch 
> https://reviews.llvm.org/file/data/2jljo4tfl5aiisvwpzg2/PHID-FILE-egbpcbhz3t7b7a2tcjka/D99426.diff
>  fixes your issue.

There's no difference after applying the above change, I still see the issue.

> I realized the change for DwarfLinkerForBinary.cpp was missing

Sorry if I misunderstand, but I don't think DwarfLinkerForBinary.cpp is used 
when targeting Windows binaries.

> If not, I will revert the remaining changes in my old commit to unblock you.

I am not blocked. If the fix comes later on in the following days/weeks, I'm 
fine with that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99363/new/

https://reviews.llvm.org/D99363

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation

2021-03-29 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

In D99363#2653476 , 
@abhina.sreeskantharajan wrote:

> There were a lot of similar patches so reverting all of them might be more 
> work than isolating the change that caused it and reverting that. It seems 
> that the patch you initially commented on did not contain the problematic 
> change since reverting the change doesn't fix your issue. I created the 
> following patch https://reviews.llvm.org/D99426 based on @rnk suggestion. I 
> created a new flag for OF_TextWithCRLF on Windows and made sure my most 
> recent text changes use the OF_Text flag while all other uses were changed to 
> OF_TextWithCRLF. This should solve any CRLF issues that were introduced 
> recently by my patches. If you have time, would you be able to test if that 
> patch fixes your issue?

I've applied https://reviews.llvm.org/D99426#2656738 over 
rGc4d5b956170dd85941c1c2787abaa2e01575234c 
 but I'm 
still seeing the issue in https://reviews.llvm.org/D96363#2650460.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99363/new/

https://reviews.llvm.org/D99363

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation

2021-03-26 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

In D99363#2653476 , 
@abhina.sreeskantharajan wrote:

> In D99363#2653201 , @aganea wrote:
>
>> I'm just wondering if D96363  and all 
>> attached subsequent patches shouldn't be reverted for now. This is a quite 
>> trivial case uncovered by tests. On re-land, I would then add a test 
>> validating the issue on Windows:
>>
>>   $ cat -A rewrite-includes-clang-cl.cpp
>>   // REQUIRES: system-windows^M$
>>   // RUN: %clang_cl /E -Xclang -frewrite-includes %s | %clang_cl /c /Tp -^M$
>>   ^M$
>>   int foo();^M$
>>   int bar();^M$
>>   #define HELLO \^M$
>> foo(); \^M$
>> bar();^M$
>>   ^M$
>>   int main() {^M$
>> HELLO^M$
>> return 0;^M$
>>   }^M$
>
> There were a lot of similar patches so reverting all of them might be more 
> work than isolating the change that caused it and reverting that. It seems 
> that the patch you initially commented on did not contain the problematic 
> change since reverting the change doesn't fix your issue.

Actually it is `git bisect` that pointed me to that patch :-)

> I created the following patch https://reviews.llvm.org/D99426 based on @rnk 
> suggestion. I created a new flag for OF_TextWithCRLF on Windows and made sure 
> my most recent text changes use the OF_Text flag while all other uses were 
> changed to OF_TextWithCRLF. This should solve any CRLF issues that were 
> introduced recently by my patches. If you have time, would you be able to 
> test if that patch fixes your issue?

Yes I will!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99363/new/

https://reviews.llvm.org/D99363

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation

2021-03-26 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

I'm just wondering if D96363  and all attached 
subsequent patches shouldn't be reverted for now. This is quite trivial case 
uncovered by tests. On re-land, I would then add a test validating the issue on 
Windows:

  $ cat -A rewrite-includes-clang-cl.cpp
  // REQUIRES: windows^M$
  // RUN: %clang_cl /E -Xclang -frewrite-includes %s | %clang_cl /c 
/clang:-verify /Tp -^M$
  // expected-no-diagnostics^M$
  ^M$
  int foo();^M$
  int bar();^M$
  #define HELLO \^M$
foo(); \^M$
bar();^M$
  ^M$
  int main() {^M$
HELLO^M$
return 0;^M$
  }^M$


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99363/new/

https://reviews.llvm.org/D99363

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation

2021-03-26 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

In D99363#2652907 , 
@abhina.sreeskantharajan wrote:

> In D99363#2652899 , @aganea wrote:
>
>> Sorry, but after this patch, I still see the issue mentioned in 
>> https://reviews.llvm.org/D96363#2650460
>> @abhina.sreeskantharajan are you able to confirm the issue on your end?
>
> I don't have a Windows machine to test on, but I assumed since the problem 
> was in rewrite then this patch should have fixed it. Would you be able to 
> confirm if reverting the change in clang/lib/Driver/Driver.cpp fixes the 
> problem for you?

I went back to the version on the left:
F16001158: image.png 
but that does not fix the problem.

Indeed, I've tested & the problem does not occur on Linux.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99363/new/

https://reviews.llvm.org/D99363

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation

2021-03-26 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

Sorry, but after this patch, I still see the issue mentioned in 
https://reviews.llvm.org/D96363#2650460
@abhina.sreeskantharajan are you be able to confirm the issue on your end?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99363/new/

https://reviews.llvm.org/D99363

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D96363: Mark output as text if it is really text

2021-03-25 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added a comment.

Hello! This patch breaks compilation when using `-frewrite-includes` on 
Windows. It adds an extra line with CRLF, which causes compilation failures 
with macros line-breaks:

  $ cat -A hello.cpp
  int foo();^M$
  int bar();^M$
  #define HELLO \^M$
foo(); \^M$
bar();^M$
  ^M$
  int main() {^M$
HELLO^M$
return 0;^M$
  }
  $ clang-cl /E -Xclang -frewrite-includes hello.cpp > test.cpp
  
  $ cat -A test.cpp
  # 1 ""^M^M$
  # 1 "hello.cpp"^M^M$
  int foo();^M^M$
  int bar();^M^M$
  #define HELLO \^M^M$
foo(); \^M^M$
bar();^M^M$
  ^M^M$
  int main() {^M^M$
HELLO^M^M$
return 0;^M^M$
  }^M^M$
  
  $ clang-cl /c test.cpp
  hello.cpp(8,3): error: C++ requires a type specifier for all declarations
foo(); \
^
  hello.cpp(10,3): error: C++ requires a type specifier for all declarations
bar();
^
  2 errors generated.
  
  $ clang-cl /c hello.cpp
  
  $ 

@abhina.sreeskantharajan would you have a chance to take a look please?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96363/new/

https://reviews.llvm.org/D96363

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98824: [Tooling] Handle compilation databases containing commands with double dashes

2021-03-24 Thread Alexandre Ganea via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe030ce3ec790: [Tooling] Handle compilation databases 
containing commands with double dashes (authored by jnykiel, committed by 
aganea).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98824/new/

https://reviews.llvm.org/D98824

Files:
  clang/lib/Tooling/ArgumentsAdjusters.cpp
  clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
  clang/lib/Tooling/Tooling.cpp
  clang/unittests/Tooling/CompilationDatabaseTest.cpp

Index: clang/unittests/Tooling/CompilationDatabaseTest.cpp
===
--- clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -725,14 +725,14 @@
 protected:
   // Look up the command from a relative path, and return it in string form.
   // The input file is not included in the returned command.
-  std::string getCommand(llvm::StringRef F) {
+  std::string getCommand(llvm::StringRef F, bool MakeNative = true) {
 auto Results =
 inferMissingCompileCommands(std::make_unique(Entries))
-->getCompileCommands(path(F));
+->getCompileCommands(MakeNative ? path(F) : F);
 if (Results.empty())
   return "none";
 // drop the input file argument, so tests don't have to deal with path().
-EXPECT_EQ(Results[0].CommandLine.back(), path(F))
+EXPECT_EQ(Results[0].CommandLine.back(), MakeNative ? path(F) : F)
 << "Last arg should be the file";
 Results[0].CommandLine.pop_back();
 return llvm::join(Results[0].CommandLine, " ");
@@ -812,6 +812,28 @@
   EXPECT_EQ(getCommand("dir/bar.cpp"), "clang -D dir/foo.cpp -Wall");
 }
 
+TEST_F(InterpolateTest, StripDoubleDash) {
+  add("dir/foo.cpp", "-o foo.o -std=c++14 -Wall -- dir/foo.cpp");
+  // input file and output option are removed
+  // -Wall flag isn't
+  // -std option gets re-added as the last argument before the input file
+  // -- is removed as it's not necessary - the new input file doesn't start with
+  // a dash
+  EXPECT_EQ(getCommand("dir/bar.cpp"), "clang -D dir/foo.cpp -Wall -std=c++14");
+}
+
+TEST_F(InterpolateTest, InsertDoubleDash) {
+  add("dir/foo.cpp", "-o foo.o -std=c++14 -Wall");
+  EXPECT_EQ(getCommand("-dir/bar.cpp", false),
+"clang -D dir/foo.cpp -Wall -std=c++14 --");
+}
+
+TEST_F(InterpolateTest, InsertDoubleDashForClangCL) {
+  add("dir/foo.cpp", "clang-cl", "/std:c++14 /W4");
+  EXPECT_EQ(getCommand("/dir/bar.cpp", false),
+"clang-cl -D dir/foo.cpp /W4 /std:c++14 --");
+}
+
 TEST_F(InterpolateTest, Case) {
   add("FOO/BAR/BAZ/SHOUT.cc");
   add("foo/bar/baz/quiet.cc");
@@ -831,7 +853,7 @@
   add("foo.cpp", "clang-cl", "/W4");
 
   // Language flags should be added with CL syntax.
-  EXPECT_EQ(getCommand("foo.h"), "clang-cl -D foo.cpp /W4 /TP");
+  EXPECT_EQ(getCommand("foo.h", false), "clang-cl -D foo.cpp /W4 /TP");
 }
 
 TEST_F(InterpolateTest, DriverModes) {
@@ -839,8 +861,10 @@
   add("bar.cpp", "clang", "--driver-mode=cl");
 
   // --driver-mode overrides should be respected.
-  EXPECT_EQ(getCommand("foo.h"), "clang-cl -D foo.cpp --driver-mode=gcc -x c++-header");
-  EXPECT_EQ(getCommand("bar.h"), "clang -D bar.cpp --driver-mode=cl /TP");
+  EXPECT_EQ(getCommand("foo.h"),
+"clang-cl -D foo.cpp --driver-mode=gcc -x c++-header");
+  EXPECT_EQ(getCommand("bar.h", false),
+"clang -D bar.cpp --driver-mode=cl /TP");
 }
 
 TEST(TransferCompileCommandTest, Smoke) {
Index: clang/lib/Tooling/Tooling.cpp
===
--- clang/lib/Tooling/Tooling.cpp
+++ clang/lib/Tooling/Tooling.cpp
@@ -440,8 +440,9 @@
   return;
 
   // If there's no override in place add our resource dir.
-  Args.push_back("-resource-dir=" +
- CompilerInvocation::GetResourcesPath(Argv0, MainAddr));
+  Args = getInsertArgumentAdjuster(
+  ("-resource-dir=" + CompilerInvocation::GetResourcesPath(Argv0, MainAddr))
+  .c_str())(Args, "");
 }
 
 int ClangTool::run(ToolAction *Action) {
Index: clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
===
--- clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
+++ clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
@@ -177,6 +177,10 @@
Opt.matches(OPT__SLASH_Fo
 continue;
 
+  // ...including when the inputs are passed after --.
+  if (Opt.matches(OPT__DASH_DASH))
+break;
+
   // Strip -x, but record the overridden language.
   if (const auto GivenType = tryParseTypeArg(*Arg)) {
 Type = *GivenType;
@@ -235,6 +239,8 @@
   llvm::Twine(ClangCLMode ? "/std:" : "-std=") +
   LangStandard::getLangStandardForKind(Std).getName()).str());
 }
+if (Filename.startswith("-") || (ClangCLMode && Filename.startswith("/")))
+

[PATCH] D98824: [Tooling] Handle compilation databases with clang-cl commands generated by CMake 3.19+

2021-03-17 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea added inline comments.



Comment at: clang/lib/Tooling/InterpolatingCompilationDatabase.cpp:181
+  // ...including when the inputs are passed after --
+  if (Opt.matches(OPT__DASH_DASH)) {
+continue;

You can leave out the braces on a one-line statement: 
https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98824/new/

https://reviews.llvm.org/D98824

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D97094: [Driver] Print process statistics report on CC_PRINT_PROC_STAT env variable.

2021-02-26 Thread Alexandre Ganea via Phabricator via cfe-commits 
aganea accepted this revision.
aganea added a comment.
This revision is now accepted and ready to land.

LGTM, just a few minor things:




Comment at: clang/docs/UsersManual.rst:798
+  Setting ``CC_PRINT_PROC_STAT`` to ``1`` enables the feature, the report goes 
to
+  the stdout in the human readable format.
+  Setting ``CC_PRINT_PROC_STAT_FILE`` to a fully qualified file path makes it 
report

"enables the feature, the report goes to ~~the~~ stdout in ~~the~~ human 
readable format."



Comment at: clang/docs/UsersManual.rst:800
+  Setting ``CC_PRINT_PROC_STAT_FILE`` to a fully qualified file path makes it 
report
+  the process statistics to the given file in the CSV format. Specifying a 
relative
+  path will likely lead to multiple files with the same name created in 
different

"~~the~~ process statistics to the given file in the CSV format"



Comment at: clang/docs/UsersManual.rst:804
+
+  These environment variables are handy when you need to request the statistics
+  report without changing your build scripts or alter the existing set of 
compiler

Would you be able to merge this paragraph with the following one please? It 
could be something like:

"These environment variables are handy when you need to request the statistics 
report without changing your build scripts or alter the existing set of 
compiler options. Note that `-fproc-stat-report` take precedence over 
`CC_PRINT_PROC_STAT` and `CC_PRINT_PROC_STAT_FILE`."


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97094/new/

https://reviews.llvm.org/D97094

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

  1   2   3   4   5   >