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.

Thu, Jun 3, 1:38 PM · Restricted Project, Restricted Project

aganea added a comment to D80344: [Windows SEH]: HARDWARE EXCEPTION HANDLING (MSVC -EHa) - Part 1.

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.

Thu, Jun 3, 8:31 AM · Restricted Project, Restricted Project

Tue, Jun 1

aganea added a comment to D80344: [Windows SEH]: HARDWARE EXCEPTION HANDLING (MSVC -EHa) - Part 1.

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.      <eof> parser at end of file
2.      Optimizer
 #0 0x00000000043c2633 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /media/project2/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:13
 #1 0x00000000043c08f0 llvm::sys::RunSignalHandlers() /media/project2/llvm-project/llvm/lib/Support/Signals.cpp:77:18
 #2 0x00000000043c1d7d llvm::sys::CleanupOnSignal(unsigned long) /media/project2/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3
 #3 0x0000000004343206 (anonymous namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) /media/project2/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:75:5
 #4 0x0000000004343206 CrashRecoverySignalHandler(int) /media/project2/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:388:51
 #5 0x00007f58152c4a90 __restore_rt sigaction.c:0:0
 #6 0x0000000003c5c11f llvm::ilist_sentinel<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void> >::empty() const /media/project2/llvm-project/llvm/include/llvm/ADT/ilist_node.h:248:36
 #7 0x0000000003c5c11f llvm::simple_ilist<llvm::Instruction>::empty() const /media/project2/llvm-project/llvm/include/llvm/ADT/simple_ilist.h:131:55
 #8 0x0000000003c5c11f llvm::BasicBlock::empty() const /media/project2/llvm-project/llvm/include/llvm/IR/BasicBlock.h:307:66
 #9 0x0000000003c5c11f llvm::BasicBlock::removePredecessor(llvm::BasicBlock*, bool) /media/project2/llvm-project/llvm/lib/IR/BasicBlock.cpp:328:7
#10 0x0000000004432005 markAliveBlocks(llvm::Function&, llvm::SmallPtrSetImpl<llvm::BasicBlock*>&, llvm::DomTreeUpdater*) /media/project2/llvm-project/llvm/lib/Transforms/Utils/Local.cpp:2290:15
#11 0x0000000004432005 llvm::removeUnreachableBlocks(llvm::Function&, llvm::DomTreeUpdater*, llvm::MemorySSAUpdater*) /media/project2/llvm-project/llvm/lib/Transforms/Utils/Local.cpp:2402:18
#12 0x00000000042e72c7 simplifyFunctionCFGImpl(llvm::Function&, llvm::TargetTransformInfo const&, llvm::DominatorTree*, llvm::SimplifyCFGOptions const&) /media/project2/llvm-project/llvm/lib/Transforms/Scalar/SimplifyCFGPass.cpp:0:22
#13 0x00000000042e72c7 simplifyFunctionCFG(llvm::Function&, llvm::TargetTransformInfo const&, llvm::DominatorTree*, llvm::SimplifyCFGOptions const&) /media/project2/llvm-project/llvm/lib/Transforms/Scalar/SimplifyCFGPass.cpp:275:18
#14 0x00000000042e70d1 llvm::SimplifyCFGPass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) /media/project2/llvm-project/llvm/lib/Transforms/Scalar/SimplifyCFGPass.cpp:321:7
#15 0x0000000002e605bd llvm::detail::PassModel<llvm::Function, llvm::SimplifyCFGPass, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) BPFTargetMachine.cpp:0:0
#16 0x0000000003d54659 llvm::SmallPtrSet<void*, 2u>::operator=(llvm::SmallPtrSet<void*, 2u>&&) /media/project2/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:488:13
#17 0x0000000003d54659 llvm::PreservedAnalyses::operator=(llvm::PreservedAnalyses&&) /media/project2/llvm-project/llvm/include/llvm/IR/PassManager.h:155:7
#18 0x0000000003d54659 llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) /media/project2/llvm-project/llvm/include/llvm/IR/PassManager.h:509:16
#19 0x0000000002aa318d llvm::detail::PassModel<llvm::Function, llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> >, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) AMDGPUTargetMachine.cpp:0:0
#20 0x0000000003d5769e llvm::SmallPtrSet<void*, 2u>::operator=(llvm::SmallPtrSet<void*, 2u>&&) /media/project2/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:488:13
#21 0x0000000003d5769e llvm::PreservedAnalyses::operator=(llvm::PreservedAnalyses&&) /media/project2/llvm-project/llvm/include/llvm/IR/PassManager.h:155:7
#22 0x0000000003d5769e llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /media/project2/llvm-project/llvm/lib/IR/PassManager.cpp:117:14
#23 0x0000000002aa2fed llvm::detail::PassModel<llvm::Module, llvm::ModuleToFunctionPassAdaptor, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) AMDGPUTargetMachine.cpp:0:0
#24 0x0000000003d538f6 llvm::SmallPtrSet<void*, 2u>::operator=(llvm::SmallPtrSet<void*, 2u>&&) /media/project2/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:488:13
#25 0x0000000003d538f6 llvm::PreservedAnalyses::operator=(llvm::PreservedAnalyses&&) /media/project2/llvm-project/llvm/include/llvm/IR/PassManager.h:155:7
#26 0x0000000003d538f6 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /media/project2/llvm-project/llvm/include/llvm/IR/PassManager.h:509:16
#27 0x00000000045ba45e llvm::SmallPtrSetImplBase::isSmall() const /media/project2/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:194:33
#28 0x00000000045ba45e llvm::SmallPtrSetImplBase::~SmallPtrSetImplBase() /media/project2/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:82:10
#29 0x00000000045ba45e llvm::PreservedAnalyses::~PreservedAnalyses() /media/project2/llvm-project/llvm/include/llvm/IR/PassManager.h:155:7
#30 0x00000000045ba45e (anonymous namespace)::EmitAssemblyHelper::EmitAssemblyWithNewPassManager(clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) /media/project2/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1494:5
#31 0x00000000045b4868 std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >::~unique_ptr() /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/unique_ptr.h:360:12
#32 0x00000000045b4868 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) /media/project2/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1660:5
#33 0x0000000004bf8006 std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >::~unique_ptr() /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/unique_ptr.h:360:6
#34 0x0000000004bf8006 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) /media/project2/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:334:7
#35 0x00000000058f8283 __gnu_cxx::__normal_iterator<std::unique_ptr<clang::TemplateInstantiationCallback, std::default_delete<clang::TemplateInstantiationCallback> >*, std::vector<std::unique_ptr<clang::TemplateInstantiationCallback, std::default_delete<clang::TemplateInstantiationCallback> >, std::allocator<std::unique_ptr<clang::TemplateInstantiationCallback, std::default_delete<clang::TemplateInstantiationCallback> > > > >::__normal_iterator(std::unique_ptr<clang::TemplateInstantiationCallback, std::default_delete<clang::TemplateInstantiationCallback> >* const&) /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/stl_iterator.h:979:20
#36 0x00000000058f8283 std::vector<std::unique_ptr<clang::TemplateInstantiationCallback, std::default_delete<clang::TemplateInstantiationCallback> >, std::allocator<std::unique_ptr<clang::TemplateInstantiationCallback, std::default_delete<clang::TemplateInstantiationCallback> > > >::begin() /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/stl_vector.h:812:16
#37 0x00000000058f8283 void clang::finalize<std::vector<std::unique_ptr<clang::TemplateInstantiationCallback, std::default_delete<clang::TemplateInstantiationCallback> >, std::allocator<std::unique_ptr<clang::TemplateInstantiationCallback, std::default_delete<clang::TemplateInstantiationCallback> > > > >(std::vector<std::unique_ptr<clang::TemplateInstantiationCallback, std::default_delete<clang::TemplateInstantiationCallback> >, std::allocator<std::unique_ptr<clang::TemplateInstantiationCallback, std::default_delete<clang::TemplateInstantiationCallback> > > >&, clang::Sema const&) /media/project2/llvm-project/clang/include/clang/Sema/TemplateInstCallback.h:54:16
#38 0x00000000058f8283 clang::ParseAST(clang::Sema&, bool, bool) /media/project2/llvm-project/clang/lib/Parse/ParseAST.cpp:178:3
#39 0x0000000004b59658 clang::FrontendAction::Execute() /media/project2/llvm-project/clang/lib/Frontend/FrontendAction.cpp:955:10
#40 0x0000000004ad1d66 llvm::Error::getPtr() const /media/project2/llvm-project/llvm/include/llvm/Support/Error.h:277:12
#41 0x0000000004ad1d66 llvm::Error::operator bool() /media/project2/llvm-project/llvm/include/llvm/Support/Error.h:236:16
#42 0x0000000004ad1d66 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /media/project2/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:965:23
#43 0x0000000004bf3330 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /media/project2/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:278:25
#44 0x00000000028477f1 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /media/project2/llvm-project/clang/tools/driver/cc1_main.cpp:246:15
#45 0x0000000002845c25 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) /media/project2/llvm-project/clang/tools/driver/driver.cpp:338:12
#46 0x00000000049c3782 clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, bool*) const::$_1::operator()() const /media/project2/llvm-project/clang/lib/Driver/Job.cpp:404:30
#47 0x00000000049c3782 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, bool*) const::$_1>(long) /media/project2/llvm-project/llvm/include/llvm/ADT/STLExtras.h:177:12
#48 0x0000000004342fd7 llvm::function_ref<void ()>::operator()() const /media/project2/llvm-project/llvm/include/llvm/ADT/STLExtras.h:0:12
#49 0x0000000004342fd7 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) /media/project2/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:424:3
#50 0x00000000049c3229 clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, bool*) const /media/project2/llvm-project/clang/lib/Driver/Job.cpp:404:7
#51 0x0000000004996ce5 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const /media/project2/llvm-project/clang/lib/Driver/Compilation.cpp:196:15
#52 0x0000000004997177 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) const /media/project2/llvm-project/clang/lib/Driver/Compilation.cpp:249:13
#53 0x00000000049aa87c llvm::SmallVectorBase<unsigned int>::empty() const /media/project2/llvm-project/llvm/include/llvm/ADT/SmallVector.h:73:47
#54 0x00000000049aa87c clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) /media/project2/llvm-project/clang/lib/Driver/Driver.cpp:1538:23
#55 0x000000000284566d main /media/project2/llvm-project/clang/tools/driver/driver.cpp:510:21
#56 0x00007f5814d60082 __libc_start_main (/lib64/libc.so.6+0x27082)
#57 0x0000000002842d1e _start (/media/project2/llvm-project/stage0/bin/clang-cl+0x2842d1e)
clang-cl: error: clang frontend command failed with exit code 139 (use -v to see invocation)
clang version 13.0.0 (https://github.com/llvm/llvm-project.git 797ad701522988e212495285dade8efac41a24d4)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: /media/project2/llvm-project/stage0/bin

I'll paste the reproducer as soon as c-reduce completes.

Tue, Jun 1, 12:44 PM · Restricted Project, Restricted Project

Fri, May 28

aganea committed rG2b9b9652ce27: [LLD][COFF] Reduce the maximum size of the GHASH table (authored by aganea).

[LLD][COFF] Reduce the maximum size of the GHASH table

Fri, May 28, 7:03 AM

aganea closed D103297: [LLD][COFF] Reduce the maximum size of the GHASH table.

Fri, May 28, 7:03 AM · Restricted Project

Thu, May 27

aganea added a comment to D102633: [clang-scan-deps] Improvements to thread usage.

@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.

Thu, May 27, 8:31 PM · Restricted Project, Restricted Project

aganea accepted D103287: Pass -gcodeview-ghash when using clang-cl and lld-link.

Great, LGTM! Thanks Reid!

Thu, May 27, 8:24 PM · Restricted Project

aganea requested review of D103297: [LLD][COFF] Reduce the maximum size of the GHASH table.

Thu, May 27, 6:56 PM · Restricted Project

aganea added inline comments to D103287: Pass -gcodeview-ghash when using clang-cl and lld-link.

Thu, May 27, 5:00 PM · Restricted Project

Tue, May 25

aganea committed rG20c9a44ac016: [benchmark] Silence 'suggest override' and 'missing override' warnings (authored by aganea).

[benchmark] Silence 'suggest override' and 'missing override' warnings

Tue, May 25, 3:47 PM

aganea committed rGdd2be15ff91a: [gcov] Silence warning: comparison of integers of different signs (authored by aganea).

[gcov] Silence warning: comparison of integers of different signs

Tue, May 25, 3:47 PM

Fri, May 21

aganea added a comment to D92515: Bump MSVC required version to 19.14.

In that case you'll need to pass -fmsc-version=... or -fms-compatibility-version=... in the -DCMAKE_CXX_FLAGS and -DCMAKE_C_FLAGS, and put the proper version that corresponds to your MSVC includes/libs. You don't really need to MSVC binaries.

Fri, May 21, 1:42 PM · Restricted Project

aganea added a comment to D92515: Bump MSVC required version to 19.14.

In D92515#2774555, @Temtaime wrote:

This change makes it impossible to build clang 12 with clang 11.

Host Clang must have at least -fms-compatibility-version=19.14, your version is 19.11.

Fri, May 21, 1:22 PM · Restricted Project

aganea updated subscribers of D101427: Linux support for mimalloc as a custom allocator.

I have been working on testing rpmalloc and mimalloc as custom allocators with clang on Linux. Neither of them works out of the box with dynamic linking due to a hang bug in glibc 2.31 (Ubuntu 20.04LTS) elf/rtld.c:_dl_start_final which I have not yet debugged fully.

+@maniccoder

Fri, May 21, 6:15 AM · Restricted Project

aganea updated subscribers of D102633: [clang-scan-deps] Improvements to thread usage.

In D102633#2769762, @arphaman wrote:

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

Fri, May 21, 6:08 AM · Restricted Project, Restricted Project

aganea added a comment to D102888: [PDB] Enable parallel ghash type merging by default.

@rnk as a next step, you would probably want to re-do D43881 so that -gcodeview-ghash is enabled by default when building LLVM?

Fri, May 21, 5:54 AM · Restricted Project

aganea added inline comments to D102736: Fix tmp files being left on Windows builds..

Fri, May 21, 5:50 AM · Restricted Project, Restricted Project

aganea accepted D96619: [LLD][COFF] PR49068: Include the IMAGE_REL_BASED_HIGHLOW relocation base type when the machine is 64 bits and the relocation type is ADDR32.

LGTM. Please address the system-windows comment below before landing.

Fri, May 21, 5:21 AM · Restricted Project

aganea added a comment to D96619: [LLD][COFF] PR49068: Include the IMAGE_REL_BASED_HIGHLOW relocation base type when the machine is 64 bits and the relocation type is ADDR32.

Agreed with @mstorsjo, let's go ahead with this patch and we'll treat PR32669 separately?

Fri, May 21, 5:20 AM · Restricted Project

aganea added a comment to D102888: [PDB] Enable parallel ghash type merging by default.

In D102888#2773139, @mstorsjo wrote:

Sorry, I have little to no clue about PDB things, so I can't really give any meningful comment on this - but the patch overall looks reasonable.

Sorry I should have been more specific: I was wondering if you had an opinion for -debug:ghash- vs. -debug:noghash.

Fri, May 21, 5:16 AM · Restricted Project

Thu, May 20

aganea accepted D102888: [PDB] Enable parallel ghash type merging by default.

LGTM. But perhaps @thakis and @mstorsjo might want to take a second look?

Thu, May 20, 5:34 PM · Restricted Project

aganea added a comment to D102888: [PDB] Enable parallel ghash type merging by default.

We can speed that up with a faster content hash (not SHA1).

Definitely. xxHash in the LLVM tree gives quite good results, see https://reviews.llvm.org/D55585#1354878 Probably integrating the latest version would improve the figures (also it supports hardware vector instructions). https://github.com/Cyan4973/xxHash

Thu, May 20, 5:04 PM · Restricted Project

aganea accepted D102885: [PDB] Check the type server guid when ghashing.

If you're making /DEBUG:GHASH the default, can we switch back to the "classic" merging?

Thu, May 20, 4:31 PM · Restricted Project

Tue, May 18

aganea added a comment to D102736: Fix tmp files being left on Windows builds..

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.

Tue, May 18, 5:28 PM · Restricted Project, Restricted Project

aganea added a comment to D102736: Fix tmp files being left on Windows builds..

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

Tue, May 18, 4:51 PM · Restricted Project, Restricted Project

aganea added a comment to D102713: [PDB] Improve error handling when writes fail.

We had similar OOM issues on the bots, as mentionned in the two bug reports. Regarding https://bugs.chromium.org/p/chromium/issues/detail?id=1179085, if you're using /DEBUG:GHASH the following patch might fix it? (but still generates > 4 GB .PDBs, which is probably a merging bug)

diff --git a/lld/COFF/DebugTypes.cpp b/lld/COFF/DebugTypes.cpp
index fedcb054540f..8bd8723f4bf2 100644
--- a/lld/COFF/DebugTypes.cpp
+++ b/lld/COFF/DebugTypes.cpp
@@ -1064,7 +1064,8 @@ void TypeMerger::mergeTypesWithGHash() {

Tue, May 18, 2:12 PM · Restricted Project

aganea accepted D102713: [PDB] Improve error handling when writes fail.

Strangely, a few weeks ago I had a similair issue while trying to link an executable with MSVC-built .OBJ files. My PDB with lld-link.exe would have been 7.7 GB, but when linking the same .OBJ files with link.exe the PDB is 2.7 GB. Since we moved off MSVC, I haven't investigated in detail why. The problem doesn't occur on the same target when using Clang. I'm curious, is that your case?

Tue, May 18, 12:56 PM · Restricted Project

May 13 2021

aganea added a comment to D102339: [clang] On Windows, ignore case and separators when discarding duplicate dependency file paths..

In D102339#2755867, @thakis wrote:

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

May 13 2021, 6:16 AM · Restricted Project

May 12 2021

aganea added inline comments to D102339: [clang] On Windows, ignore case and separators when discarding duplicate dependency file paths..

May 12 2021, 3:15 PM · Restricted Project

May 8 2021

aganea added a comment to D96619: [LLD][COFF] PR49068: Include the IMAGE_REL_BASED_HIGHLOW relocation base type when the machine is 64 bits and the relocation type is ADDR32.

@ayrivera : Would you mind please giving a bit more context about your usage, and why do you need this to work?

May 8 2021, 6:43 AM · Restricted Project

May 6 2021

aganea added a comment to D70830: [LLDB] Disable MSVC warning C4190.

Hello @mstorsjo! I've reverted the patch locally, I'm at this commit:

F:\aganea\llvm-project>git log
commit a3a8a1a15b524d91b5308db68e9d293b34cd88dd (HEAD -> main, origin/main)

Using:

F:\aganea\llvm-project>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29914 for x64

that is, Visual Studio 16.9.4 running a "x64 Native Tools Command Prompt for VS 2019".

May 6 2021, 1:56 PM · Restricted Project

Apr 28 2021

aganea added reviewers for D101427: Linux support for mimalloc as a custom allocator: MaskRay, theraven.

Apr 28 2021, 9:21 AM · Restricted Project

Apr 21 2021

aganea added inline comments to D100756: [llvm-rc] [4/4] Add a GNU windres-like frontend to llvm-rc.

Apr 21 2021, 9:42 AM · Restricted Project, Restricted Project

aganea added inline comments to D100756: [llvm-rc] [4/4] Add a GNU windres-like frontend to llvm-rc.

Apr 21 2021, 8:09 AM · Restricted Project, Restricted Project

Apr 20 2021

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

LGTM.

Apr 20 2021, 2:28 PM · Restricted Project, Restricted Project

aganea added inline comments to D100755: [llvm-rc] [3/4] Run clang to preprocess input files.

Apr 20 2021, 2:05 PM · Restricted Project, Restricted Project

aganea added a comment to D100755: [llvm-rc] [3/4] Run clang to preprocess input files.

In D100755#2701649, @mstorsjo wrote:

In D100755#2701608, @aganea wrote:

Thanks for adding this Martin!

I'd really like to see a simple test running from the Clang side as well! Like calling llvm-rc with a file that requires preprocessing:

That sounds like a good idea, as there's indeed a gap in testing at that spot right now.

What would be the most appropriate place under clang/test for it?

Maybe under clang\test\Preprocessor ?

Apr 20 2021, 8:40 AM · Restricted Project, Restricted Project

aganea added a comment to D100755: [llvm-rc] [3/4] Run clang to preprocess input files.

Thanks for adding this Martin!

Apr 20 2021, 7:17 AM · Restricted Project, Restricted Project

Apr 19 2021

aganea added a reverting change for rGbb26fa8c286b: [clang-scan-deps] Add support for clang-cl: rG199c39748292: Revert "[clang-scan-deps] Add support for clang-cl".

Apr 19 2021, 2:45 PM

aganea committed rG199c39748292: Revert "[clang-scan-deps] Add support for clang-cl" (authored by aganea).

Revert "[clang-scan-deps] Add support for clang-cl"

Apr 19 2021, 2:45 PM

aganea added a reverting change for D92191: [clang-scan-deps] Add support for clang-cl: rG199c39748292: Revert "[clang-scan-deps] Add support for clang-cl".

Apr 19 2021, 2:45 PM · Restricted Project

aganea added a comment to D92191: [clang-scan-deps] Add support for clang-cl.

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

Apr 19 2021, 1:54 PM · Restricted Project

aganea added a comment to D92191: [clang-scan-deps] Add support for clang-cl.

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

Apr 19 2021, 1:30 PM · Restricted Project

Apr 17 2021

aganea committed rGbb26fa8c286b: [clang-scan-deps] Add support for clang-cl (authored by saudi).

[clang-scan-deps] Add support for clang-cl

Apr 17 2021, 11:23 AM

aganea committed rG488a19d00cba: [clang-scan-deps] Support double-dashes in clang command lines (authored by saudi).

[clang-scan-deps] Support double-dashes in clang command lines

Apr 17 2021, 11:23 AM

aganea committed rG7b75a3a8ebf0: [Support] ThreadPool tests: silence warning unused variable 'It' (authored by aganea).

[Support] ThreadPool tests: silence warning unused variable 'It'

Apr 17 2021, 11:23 AM

aganea closed D92191: [clang-scan-deps] Add support for clang-cl.

Apr 17 2021, 11:23 AM · Restricted Project

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

Apr 17 2021, 11:23 AM · Restricted Project

Apr 8 2021

aganea accepted D99978: [lld] Fixed CodeView GuidAdapter::format to handle GUID bytes in the right order..

LGTM. Thank you!

Apr 8 2021, 5:44 PM · Restricted Project

aganea added a comment to D99978: [lld] Fixed CodeView GuidAdapter::format to handle GUID bytes in the right order..

Thanks for integrating the comments!

Apr 8 2021, 9:30 AM · Restricted Project

Apr 6 2021

aganea committed rG8fbc05acd553: [Windows] Add test coverage for line endings when rewriting includes (authored by aganea).

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

Apr 6 2021, 12:39 PM

aganea closed D99973: [Windows] Add test coverage for line endings when rewriting includes.

Apr 6 2021, 12:38 PM · Restricted Project

aganea added inline comments to D99973: [Windows] Add test coverage for line endings when rewriting includes.

Apr 6 2021, 12:32 PM · Restricted Project

aganea added inline comments to D99978: [lld] Fixed CodeView GuidAdapter::format to handle GUID bytes in the right order..

Apr 6 2021, 11:52 AM · Restricted Project

aganea requested review of D99973: [Windows] Add test coverage for line endings when rewriting includes.

Apr 6 2021, 10:23 AM · Restricted Project

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

It works now, thanks! :-)

Apr 6 2021, 7:45 AM · Restricted Project

Apr 2 2021

aganea added a comment to D99426: [SystemZ][z/OS][Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text.

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.

Apr 2 2021, 9:05 AM · Restricted Project, Restricted Project, Restricted Project, Restricted Project

Apr 1 2021

aganea added a comment to D99426: [SystemZ][z/OS][Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text.

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?

Apr 1 2021, 3:37 PM · Restricted Project, Restricted Project, Restricted Project, Restricted Project

Mar 30 2021

aganea added a comment to D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation.

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.

Mar 30 2021, 3:50 PM · Restricted Project, Restricted Project

Mar 29 2021

aganea added a comment to D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation.

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?

Mar 29 2021, 2:15 PM · Restricted Project, Restricted Project

Mar 26 2021

aganea added a comment to D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation.

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 :-)

Mar 26 2021, 11:57 AM · Restricted Project, Restricted Project

aganea added a comment to D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation.

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$

Mar 26 2021, 9:57 AM · Restricted Project, Restricted Project

aganea added a comment to D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation.

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?

Mar 26 2021, 9:49 AM · Restricted Project, Restricted Project

aganea added a comment to D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation.

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?

Mar 26 2021, 6:41 AM · Restricted Project, Restricted Project

Mar 25 2021

aganea added a comment to D96363: Mark output as text if it is really text.

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

Mar 25 2021, 7:06 AM · Restricted Project, Restricted Project

Mar 24 2021

aganea committed rGe030ce3ec790: [Tooling] Handle compilation databases containing commands with double dashes (authored by jnykiel).

[Tooling] Handle compilation databases containing commands with double dashes

Mar 24 2021, 1:02 PM

aganea closed D98824: [Tooling] Handle compilation databases containing commands with double dashes.

Mar 24 2021, 1:02 PM · Restricted Project

aganea closed D99212: [Support] Fix Windows 7 path handling.

Commited as rG64ab2b6825c5 (doh, I forgot the Differential Revision: part).

Mar 24 2021, 9:57 AM · Restricted Project

aganea committed rG64ab2b6825c5: [Support] Fix 'keeping' temporary files on Windows 7 (authored by aganea).

[Support] Fix 'keeping' temporary files on Windows 7

Mar 24 2021, 9:47 AM

aganea added a comment to D99212: [Support] Fix Windows 7 path handling.

In D99212#2647586, @jhenderson wrote:

In D99212#2647555, @aganea wrote:

In D99212#2646852, @jhenderson wrote:

Looks reasonable to me. I guess this means that on Windows 7 we might end up with temp files kicking around afterwards?

There's no behavior specific to Windows 7, only this workaround to ensure the code works on both systems (Win 7 & 10). Temp files will remain on disk only if we're writing to a network drive, and only if the target file isn't renamed.

Yep, got it (I realised there wasn't anything Windows 7 specific here before that point). Not all temp files will be renamed though. Is it worth some additional commenting somewhere to make this clear?

Mar 24 2021, 7:06 AM · Restricted Project

aganea updated the diff for D99212: [Support] Fix Windows 7 path handling.

Mar 24 2021, 7:05 AM · Restricted Project

aganea added a comment to D99212: [Support] Fix Windows 7 path handling.

In D99212#2646852, @jhenderson wrote:

Looks reasonable to me. I guess this means that on Windows 7 we might end up with temp files kicking around afterwards?

Mar 24 2021, 6:50 AM · Restricted Project

Mar 23 2021

aganea requested review of D99212: [Support] Fix Windows 7 path handling.

Mar 23 2021, 4:19 PM · Restricted Project

aganea added a comment to D99212: [Support] Fix Windows 7 path handling.

In D99212#2645957, @amccarth wrote:

I like the solution. Has anyone actually tried it on Windows 7? I ask because some of the observations noted in second hand descriptions of the problem didn't fully add up. I think we understand the root problem, but I'm not 100% certain.

Mar 23 2021, 4:03 PM · Restricted Project

aganea updated the diff for D99212: [Support] Fix Windows 7 path handling.

As suggested by @rdwampler

Mar 23 2021, 4:02 PM · Restricted Project

aganea updated the summary of D99212: [Support] Fix Windows 7 path handling.

Mar 23 2021, 1:30 PM · Restricted Project

aganea added a comment to D81803: [Support] PR42623: Avoid setting the delete-on-close bit if a TempFile doesn't reside on a local drive.

Please see D99212 for a fix for Windows 7.

Mar 23 2021, 1:25 PM · Restricted Project

aganea requested review of D99212: [Support] Fix Windows 7 path handling.

Mar 23 2021, 1:22 PM · Restricted Project

Mar 18 2021

aganea added a comment to D81803: [Support] PR42623: Avoid setting the delete-on-close bit if a TempFile doesn't reside on a local drive.

It would be nice to retain Windows 7 support for now, seeing the number of users affected by this issue.

Mar 18 2021, 7:02 PM · Restricted Project

Mar 17 2021

aganea added inline comments to D98824: [Tooling] Handle compilation databases containing commands with double dashes.

Mar 17 2021, 4:25 PM · Restricted Project

aganea added reviewers for D98824: [Tooling] Handle compilation databases containing commands with double dashes: sammccall, ilya-biryukov, kadircet.

Mar 17 2021, 4:21 PM · Restricted Project

Mar 8 2021

aganea added a comment to D96862: Allow passing /manifestdependency via #pragma comment(linker, ...).

@ColinFinck Would you mind adding test coverage for this? Either modify an existing test such as lld/test/COFF/directives.s or a add a new test.

Mar 8 2021, 5:46 AM · lld, Restricted Project

Feb 26 2021

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

LGTM, just a few minor things:

Feb 26 2021, 5:35 AM · Restricted Project

Feb 25 2021

aganea accepted D97138: [clang][flang] Improve the consistency of the code-base.

In D97138#2586988, @achieveartificialintelligence wrote:

Thanks @aganea. And I have a question that, should I use argc & argv or argC & argV in the flang part now ?

Feb 25 2021, 5:12 AM · Restricted Project

Feb 24 2021

aganea added inline comments to D97138: [clang][flang] Improve the consistency of the code-base.

Feb 24 2021, 2:01 PM · Restricted Project

aganea added a comment to D97094: [Driver] Print process statistics report on CC_PRINT_PROC_STAT env variable..

Thanks for the update @vvereschaka ! Just a few minor things and it should be good to go.
Also please use git diff -U99999 next time to add context to the patch.

Feb 24 2021, 1:47 PM · Restricted Project

Feb 22 2021

aganea added inline comments to D97094: [Driver] Print process statistics report on CC_PRINT_PROC_STAT env variable..

Feb 22 2021, 2:59 PM · Restricted Project

Feb 15 2021

aganea added a comment to D95534: clang-cl: Invent a /winsysroot concept.

In D95534#2550998, @thakis wrote:

In D95534#2534510, @smeenai wrote:

I saw this on LLVM Weekly, and I like it a lot :)

Now if only Windows could case-correct their SDKs so we didn't need VFS overlays and symlinks for the linker...

We use ciopfs for this, https://source.chromium.org/chromium/chromium/src/+/master:build/vs_toolchain.py;l=485?q=ciopfs That code has worked without changes for the last 2.5 years.

Feb 15 2021, 5:42 AM · Restricted Project

Feb 12 2021

aganea added a comment to D79043: [Driver] Skip validation of system sanitizer blacklists files if -fno-sanitizer-blacklist was specified.

In D79043#2560710, @vitalybuka wrote:

This patch is relatively recent. I'd like to revert this for D96203
Can we user just pointo to /dev/null if file is not needed?

Feb 12 2021, 12:33 PM · Restricted Project, Restricted Project

Feb 10 2021

aganea accepted D96420: [test][Dexter] Fix test failure if space in python path.

For the record this fixes the issue below on Windows:

******************** TEST 'debuginfo-tests :: dexter/feature_tests/commands/penalty/unreachable.cpp' FAILED ********************
Script:
--
: 'RUN: at line 8';   not C:/Program Files/Python39/python.exe F:/aganea/llvm-project/debuginfo-tests\dexter\dexter.py test --fail-lt 1.0 -w --builder clang-cl_vs2015 --debugger dbgeng --cflags "/Zi /Od" --ldflags "/Zi" -- F:\aganea\llvm-project\debuginfo-tests\dexter\feature_tests\commands\penalty\unreachable.cpp | f:\aganea\llvm-project\buildtest\bin\filecheck.exe F:\aganea\llvm-project\debuginfo-tests\dexter\feature_tests\commands\penalty\unreachable.cpp
--
Exit Code: 2

Feb 10 2021, 8:29 AM · Restricted Project

Feb 8 2021

aganea added a comment to D95534: clang-cl: Invent a /winsysroot concept.

In D95534#2534510, @smeenai wrote:

Now if only Windows could case-correct their SDKs so we didn't need VFS overlays and symlinks for the linker...

Feb 8 2021, 3:21 PM · Restricted Project

Feb 5 2021

aganea added inline comments to D96133: Allow building with scudo memory allocator on Windows.

Feb 5 2021, 10:47 AM · Restricted Project

aganea added inline comments to D96133: Allow building with scudo memory allocator on Windows.

Feb 5 2021, 9:09 AM · Restricted Project

aganea added a comment to D96120: [scudo] Port scudo sanitizer to Windows.

A few questions: Does this work on x86 targets? Are the scudo tests below being built with /MD or with /MT? Would this change compile/work on MinGW as well?

Feb 5 2021, 7:50 AM · Restricted Project, Restricted Project

aganea updated subscribers of D96120: [scudo] Port scudo sanitizer to Windows.

Feb 5 2021, 6:08 AM · Restricted Project, Restricted Project

Jan 22 2021

aganea accepted D95256: [RGT] Don't use EXPECT* macros in a test subprcess that exits by signalling..

LGTM, thanks Paul!

Jan 22 2021, 12:55 PM · Restricted Project

aganea (Alexandre Ganea)User

Projects

User Details

Recent ActivityView All

Today

Fri, Jun 4

Thu, Jun 3

Tue, Jun 1

Fri, May 28

Thu, May 27

Tue, May 25

Fri, May 21

Thu, May 20

Tue, May 18

May 13 2021

May 12 2021

May 8 2021

May 6 2021

Apr 28 2021

Apr 21 2021

Apr 20 2021

Apr 19 2021

Apr 17 2021

Apr 8 2021

Apr 6 2021

Apr 2 2021

Apr 1 2021

Mar 30 2021

Mar 29 2021

Mar 26 2021

Mar 25 2021

Mar 24 2021

Mar 23 2021

Mar 18 2021

Mar 17 2021

Mar 8 2021

Feb 26 2021

Feb 25 2021

Feb 24 2021

Feb 22 2021

Feb 15 2021

Feb 12 2021

Feb 10 2021

Feb 8 2021

Feb 5 2021

Jan 22 2021

aganea (Alexandre Ganea)
User

Recent Activity
View All