Commit Graph

638 Commits

Author SHA1 Message Date
Shao-Ce SUN 2aed07e96c [NFC][MC] remove unused argument `MCRegisterInfo` in `MCCodeEmitter`
Reviewed By: skan

Differential Revision: https://reviews.llvm.org/D119846
2022-02-16 13:10:09 +08:00
Shao-Ce SUN 9cc49c1951 Revert "[NFC][MC] remove unused argument `MCRegisterInfo` in `MCCodeEmitter`"
This reverts commit fe25c06cc5.
2022-02-16 11:57:49 +08:00
Shao-Ce SUN fe25c06cc5 [NFC][MC] remove unused argument `MCRegisterInfo` in `MCCodeEmitter`
For ten years, it seems that `MCRegisterInfo` is not used by any target.

Reviewed By: skan

Differential Revision: https://reviews.llvm.org/D119846
2022-02-16 11:47:17 +08:00
Jameson Nash 76cad51ba7 replace clang LLVM_ENABLE_PLUGINS -> CLANG_PLUGIN_SUPPORT in tests
Ensure CLANG_PLUGIN_SUPPORT is compatible with llvm_add_library.
Fixes an issue noted in D111100.

Differential Revision: https://reviews.llvm.org/D119199
2022-02-09 17:31:34 -05:00
Fangrui Song 6bc20eb134 [cc1as] Remove -Wa,--compress-debug-sections=zlib-gnu
It's obsoleted and unlikely used. See D117744.
2022-01-26 13:28:51 -08:00
Jan Svoboda 76cb4cd074 [clang] Fix serialized diagnostics edge-cases
The Clang frontend sometimes fails on the following assertion when launched with `-serialize-diagnostic-file <x>`:

```
Assertion failed: (BlockScope.empty() && CurAbbrevs.empty() && "Block imbalance"), function ~BitstreamWriter, file BitstreamWriter.h, line 125.
```

This was first noticed when passing an unknown command-line argument to `-cc1`.

It turns out the `DiagnosticConsumer::finish()` function should be called as soon as processing of all source files ends, but there are some code paths where that doesn't happen:

1. when command line parsing fails in `cc1_main()`,
2. when `!Act.PrepareToExecute(*this)` or `!createTarget()` evaluate to `true` in `CompilerInstance::ExecuteAction` and the function returns early.

This patch ensures `finish()` is called in all those code paths.

Reviewed By: Bigcheese

Differential Revision: https://reviews.llvm.org/D118150
2022-01-26 11:21:51 +01:00
Kazu Hirata 3cfe375ae4 Use StringRef::contains (NFC) 2021-12-24 22:05:34 -08:00
Dave Lee 5a892be237 [clang] Fix cmake error 2021-11-02 10:47:44 -07:00
Nico Weber 2d3953499c [cmake] Make LLVM_ENABLE_LLD=ON work better on macOS
LLVM_LINKER_IS_LLD is now set with LLVM_ENABLE_LLD=ON (or LLVM_USER_LINKER=lld)
even on APPLE, and we pass -Wl,-order_file when LLVM_LINKER_IS_LLD on APPLE
too.

To make this straightforward, change the linker detection logic to go through
the compiler driver on APPLE like on the other platforms.

No intended behavior change if LLVM_ENABLE_LLD isn't set.

Differential Revision: https://reviews.llvm.org/D113021
2021-11-02 13:35:21 -04:00
Arthur Eubanks e2024d72fa Revert "[NFC] Remove LinkAll*.h"
This reverts commit fe364e5dc7.

Causes breakages, e.g. https://lab.llvm.org/buildbot/#/builders/188/builds/5266
2021-11-02 09:08:09 -07:00
Arthur Eubanks fe364e5dc7 [NFC] Remove LinkAll*.h
These were added to prevent functions from being removed by WPO.

But that doesn't make sense, correct WPO will not remove functions we actually use.

I noticed these because compiling cc1_main.cpp was pulling in random LLVM pass headers.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D112971
2021-11-02 08:43:17 -07:00
Kazu Hirata 16ceb44e62 [clang] Use llvm::{count,count_if,find_if,all_of,none_of} (NFC) 2021-10-25 09:14:45 -07:00
Reid Kleckner 89b57061f7 Move TargetRegistry.(h|cpp) from Support to MC
This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

Differential Revision: https://reviews.llvm.org/D111454
2021-10-08 14:51:48 -07:00
Simon Pilgrim e463b69736 [Support] Change fatal_error_handler_t to take a const char* instead of std::string
https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html

Excessive use of the <string> header has a massive impact on compile time; its most commonly included via the ErrorHandling.h header, which has to be included in many key headers, impacting many source files that have no need for std::string.

As an initial step toward removing the <string> include from ErrorHandling.h, this patch proposes to update the fatal_error_handler_t handler to just take a raw const char* instead.

The next step will be to remove the report_fatal_error std::string variant, which will involve a lot of cleanup and better use of Twine/StringRef.

Differential Revision: https://reviews.llvm.org/D111049
2021-10-05 10:55:40 +01:00
Brain Swift fae57a6a97 [Clang] [Fix] Clang build fails when build directory contains space character
Clang build fails when build directory contains space character.

Error messages:

[ 95%] Linking CXX executable ../../../../bin/clang
clang: error: no such file or directory: 'Space/Net/llvm/Build/tools/clang/tools/driver/Info.plist'
make[2]: *** [bin/clang-14] Error 1
make[1]: *** [tools/clang/tools/driver/CMakeFiles/clang.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

The path name is actually:
  'Dev Space/Net/llvm/Build/tools/clang/tools/driver/Info.plist'

Bugzilla issue - https://bugs.llvm.org/show_bug.cgi?id=51884
Reporter and patch author - Brain Swift <bsp2bsp-llvm@yahoo.com>

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D109979
2021-09-20 18:19:08 +05:30
Peter Smith 5e71839f77 [MC] Add MCSubtargetInfo to MCAlignFragment
In preparation for passing the MCSubtargetInfo (STI) through to writeNops
so that it can use the STI in operation at the time, we need to record the
STI in operation when a MCAlignFragment may write nops as padding. The
STI is currently unused, a further patch will pass it through to
writeNops.

There are many places that can create an MCAlignFragment, in most cases
we can find out the STI in operation at the time. In a few places this
isn't possible as we are in initialisation or finalisation, or are
emitting constant pools. When possible I've tried to find the most
appropriate existing fragment to obtain the STI from, when none is
available use the per module STI.

For constant pools we don't actually need to use EmitCodeAlign as the
constant pools are data anyway so falling through into it via an
executable NOP is no better than falling through into data padding.

This is a prerequisite for D45962 which uses the STI to emit the
appropriate NOP for the STI. Which can differ per fragment.

Note that involves an interface change to InitSections. It is now
called initSections and requires a SubtargetInfo as a parameter.

Differential Revision: https://reviews.llvm.org/D45961
2021-09-07 15:46:19 +01:00
Jan Svoboda 555a817d1d [clang] NFC: Extract DiagnosticOptions parsing
The way we parse `DiagnosticOptions` is a bit involved.

`DiagnosticOptions` are parsed as part of the cc1-parsing function `CompilerInvocation::CreateFromArgs` which takes `DiagnosticsEngine` as an argument to be able to report errors in command-line arguments. But to create `DiagnosticsEngine`, `DiagnosticOptions` are needed. This is solved by exposing the `ParseDiagnosticArgs` to clients and making its `DiagnosticsEngine` argument optional, essentially breaking the dependency cycle.

The `ParseDiagnosticArgs` function takes `llvm::opt::ArgList &`, which each client needs to create from the command-line (typically represented as `std::vector<const char *>`). Creating this data structure in this context is somewhat particular. This code pattern is copy-pasted in some places across the upstream code base and also in downstream repos. To make things a bit more uniform, this patch extracts the code into a new reusable function: `CreateAndPopulateDiagOpts`.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D108918
2021-09-02 14:37:14 +02:00
Nico Weber 3d157cfcc4 [clang] Add a -canonical-prefixes option
In https://reviews.llvm.org/D47480 I complained that there's no positive
form of this flag, so let's add one :)

https://gcc.gnu.org/PR29931 also has a pending patch to add the positive
form to gcc (but there's admittedly not a lot of movement on that bug).

This doesn't change any defaults.

Differential Revision: https://reviews.llvm.org/D108818
2021-09-01 14:51:06 -04:00
Kadir Cetinkaya ce90b60bd0
[clang][Driver] Expose driver mode detection logic
Also use it in other places that performed it on their own.

Differential Revision: https://reviews.llvm.org/D106789
2021-07-27 14:49:53 +02:00
Fangrui Song f1e2d5851b [OptTable] Rename PrintHelp to printHelp
To be consistent with other member functions and match the coding standard.
2021-06-24 14:47:03 -07:00
Martin Storsjö e5c7c171e5 [clang] Rename StringRef _lower() method calls to _insensitive()
This is mostly a mechanical change, but a testcase that contains
parts of the StringRef class (clang/test/Analysis/llvm-conventions.cpp)
isn't touched.
2021-06-25 00:22:01 +03:00
Philipp Krones c2f819af73 [MC] Refactor MCObjectFileInfo initialization and allow targets to create MCObjectFileInfo
This makes it possible for targets to define their own MCObjectFileInfo.
This MCObjectFileInfo is then used to determine things like section alignment.

This is a follow up to D101462 and prepares for the RISCV backend defining the
text section alignment depending on the enabled extensions.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D101921
2021-05-23 14:15:23 -07:00
Philipp Krones 632ebc4ab4 [MC] Untangle MCContext and MCObjectFileInfo
This untangles the MCContext and the MCObjectFileInfo. There is a circular
dependency between MCContext and MCObjectFileInfo. Currently this dependency
also exists during construction: You can't contruct a MOFI without a MCContext
without constructing the MCContext with a dummy version of that MOFI first.
This removes this dependency during construction. In a perfect world,
MCObjectFileInfo wouldn't depend on MCContext at all, but only be stored in the
MCContext, like other MC information. This is future work.

This also shifts/adds more information to the MCContext making it more
available to the different targets. Namely:

- TargetTriple
- ObjectFileType
- SubtargetInfo

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D101462
2021-05-05 10:03:02 -07:00
Scott Linder cab19d84ce [NFC] Refactor ExecuteAssembler in cc1as_main.cpp
Introduce an extra scope (another static function) to replace calls to
`unique_ptr::reset` with implicit destructors via RAII.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D101542
2021-04-30 17:11:50 +00:00
Jim Radford 06d06f2f64 [CMake][llvm] avoid conflict w/ (and use when available) new builtin check_linker_flag
Match the API for the new check_linker_flag and use it directly when
available, leaving the old code as a fallback.

Differential Revision: https://reviews.llvm.org/D100901
2021-04-27 16:41:28 -07:00
Abhina Sreeskantharajan 05b4babc9d [SystemZ][z/OS] Set more text files as text
This patch corrects more instances of text files being opened as text.

Reviewed By: Jonathan.Crowther

Differential Revision: https://reviews.llvm.org/D100654
2021-04-19 09:31:46 -04:00
Jonathan Crowther e71994a239 [SystemZ][z/OS] Add IsText Argument to GetFile and GetFileOrSTDIN
Add the `IsText` argument to `GetFile` and `GetFileOrSTDIN` which will help z/OS distinguish between text and binary correctly. This is an extension to [this patch](https://reviews.llvm.org/D97785)

Reviewed By: abhina.sreeskantharajan, amccarth

Differential Revision: https://reviews.llvm.org/D100488
2021-04-16 10:08:36 -04:00
Abhina Sreeskantharajan 82b3e28e83 [SystemZ][z/OS][Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text
Problem:
On SystemZ we need to open text files in text mode. On Windows, files opened in text mode adds a CRLF '\r\n' which may not be desirable.

Solution:
This patch adds two new flags

  - OF_CRLF which indicates that CRLF translation is used.
  - OF_TextWithCRLF = OF_Text | OF_CRLF indicates that the file is text and uses CRLF translation.

Developers should now use either the OF_Text or OF_TextWithCRLF for text files and OF_None for binary files. If the developer doesn't want carriage returns on Windows, they should use OF_Text, if they do want carriage returns on Windows, they should use OF_TextWithCRLF.

So this is the behaviour per platform with my patch:

z/OS:
OF_None: open in binary mode
OF_Text : open in text mode
OF_TextWithCRLF: open in text mode

Windows:
OF_None: open file with no carriage return
OF_Text: open file with no carriage return
OF_TextWithCRLF: open file with carriage return

The Major change is in llvm/lib/Support/Windows/Path.inc to only set text mode if the OF_CRLF is set.
```
  if (Flags & OF_CRLF)
    CrtOpenFlags |= _O_TEXT;
```

These following files are the ones that still use OF_Text which I left unchanged. I modified all these except raw_ostream.cpp in recent patches so I know these were previously in Binary mode on Windows.
./llvm/lib/Support/raw_ostream.cpp
./llvm/lib/TableGen/Main.cpp
./llvm/tools/dsymutil/DwarfLinkerForBinary.cpp
./llvm/unittests/Support/Path.cpp
./clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
./clang/lib/Frontend/CompilerInstance.cpp
./clang/lib/Driver/Driver.cpp
./clang/lib/Driver/ToolChains/Clang.cpp

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D99426
2021-04-06 07:23:31 -04:00
Sean Perry 7e0cc45ced [SystemZ][z/OS] Save strings for CC_PRINT env vars
The contents of the string returned by getenv() is not guaranteed across calls to getenv(). The code to handle the CC_PRINT etc env vars calls getenv() and saves the results in just a char *. The string returned by getenv() needs to be copied and saved. Switching the type of the strings from char * to std::string will do this and manage the alloated memory.

Differential Revision: https://reviews.llvm.org/D98554
2021-03-26 16:38:36 -04:00
Vladimir Vereschaka 155c49e087 [Driver] Print process statistics report on CC_PRINT_PROC_STAT env variable.
Added supporting CC_PRINT_PROC_STAT and CC_PRINT_PROC_STAT_FILE
environment variables to trigger clang driver reporting the process
statistics into specified file (alternate for -fproc-stat-report
option).

Differential Revision: https://reviews.llvm.org/D97094
2021-02-26 16:16:00 -08:00
Petr Hosek 9e56a093ee [Driver] Create -ffile-compilation-dir alias
We introduce -ffile-compilation-dir shorthand to avoid having to set
-fdebug-compilation-dir and -fprofile-compilation-dir separately. This
is similar to -ffile-prefix-map.

Differential Revision: https://reviews.llvm.org/D97433
2021-02-25 21:20:10 -08:00
Shao-Ce Sun ad14ccc8c2 [clang][flang] Improve the consistency of the code-base
In clang:
Replace argc_ with Argc
Replace argv_ with Argv
Replace argv with Args
In flang:
Replace argc_ with argc
Replace argv_ with argv
Replace argv with args

Reviewed By: awarzynski, aganea

Differential Revision: https://reviews.llvm.org/D97138
2021-02-25 21:25:43 +08:00
Igor Kudrin 72eee60b24 [Driver] Support -gdwarf64 for assembly files
The option was added in D90507 for C/C++ source files. This patch adds
support for assembly files.

Differential Revision: https://reviews.llvm.org/D96783
2021-02-17 17:03:34 +07:00
Jan Svoboda 225ccf0c50 [clang][cli] Command line round-trip for HeaderSearch options
This patch implements generation of remaining header search arguments.
It's done manually in C++ as opposed to TableGen, because we need the flexibility and don't anticipate reuse.

This patch also tests the generation of header search options via a round-trip. This way, the code gets exercised whenever Clang is built and tested in asserts mode. All `check-clang` tests pass.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D94472
2021-02-04 10:18:34 +01:00
Duncan P. N. Exon Smith ad7aaa475e Frontend: Fix layering between create{,Default}OutputFile, NFC
Fix layering between `CompilerInstance::createDefaultOutputFile` and the
two versions of `createOutputFile`.

- Add missing configuration flags to `createDefaultOutputFile` so that
  GeneratePCHAction and GenerateModuleFromModuleMapAction can use it.
  They previously promised that temporary files were turned on; now
  `createDefaultOutputFile` handles that logic.
- Lift the logic handling `InFile` and `Extension` to
  `createDefaultOutputFile`, since it's only the callers of that
  function that are using it.
- Rename the deeper of the two `createOutputFile`s to
  `createOutputFileImpl` and make it private to `CompilerInstance` (to
  prove that no one else is using it).
- Sink the logic for adding to `CompilerInstance::OutputFiles` down to
  `createOutputFileImpl`, allowing two "optional" (but always used)
  `std::string*` out parameters to be removed.
- Instead of passing a `std::error_code` out parameter into
  `createOutputFileImpl`, have it return `Expected<>`.
- As a drive-by, inline `CompilerInstance::addOutputFile` into its only
  caller, `createOutputFileImpl`.

Clean layering makes it easier for a future commit to extract
`createOutputFileImpl` out of `CompilerInstance`.

Differential Revision: https://reviews.llvm.org/D93248
2021-01-26 15:56:19 -08:00
Ayke van Laethem 0057cc5a21
Revert "[Clang] Move assembler into a separate file"
This reverts commit 2325157c05.

Unfortunately this commit produces linker errors on some builds:
http://lab.llvm.org:8011/#/builders/57/builds/3704
http://lab.llvm.org:8011/#/builders/112/builds/3216
http://lab.llvm.org:8011/#/builders/121/builds/3900
2021-01-23 15:04:27 +01:00
Ayke van Laethem 2325157c05
[Clang] Move assembler into a separate file
This change adds an AssemblerInvocation class, similar to the
CompilerInvocation class. It can be used to invoke cc1as directly.

The project I'm working on wants to compile Clang and use it as a static
library. For that to work, there must be a way to invoke the assembler
programmatically, using the same arguments as you would otherwise pass
to cc1as.

Differential Revision: https://reviews.llvm.org/D63852
2021-01-23 14:34:23 +01:00
Ella Ma 1756d67934 [llvm][clang][mlir] Add checks for the return values from Target::createXXX to prevent protential null deref
All these potential null pointer dereferences are reported by my static analyzer for null smart pointer dereferences, which has a different implementation from `alpha.cplusplus.SmartPtr`.

The checked pointers in this patch are initialized by Target::createXXX functions. When the creator function pointer is not correctly set, a null pointer will be returned, or the creator function may originally return a null pointer.

Some of them may not make sense as they may be checked before entering the function, but I fixed them all in this patch. I submit this fix because 1) similar checks are found in some other places in the LLVM codebase for the same return value of the function; and, 2) some of the pointers are dereferenced before they are checked, which may definitely trigger a null pointer dereference if the return value is nullptr.

Reviewed By: tejohnson, MaskRay, jpienaar

Differential Revision: https://reviews.llvm.org/D91410
2020-11-21 21:04:12 -08:00
Fangrui Song bc847b3143 [cc1as] Close MCAsmParser before MCStreamer
This is a pre-existing problem exposed by D90511 (asan failurs with
clang/test/Driver/relax.s and a few other tests).
2020-11-02 15:56:57 -08:00
Fangrui Song 2484e9159c [Driver] Clean up -gz & --compress-debug-sections
* Make cc1 and cc1as --compress-debug-sections an alias for --compress-debug-sections=zlib
* Make -gz an alias for -gz=zlib

The new behavior is consistent with GCC when binutils>=2.26 is detected:
-gz is translated to --compress-debug-sections=zlib instead of --compress-debug-sections.
2020-10-19 23:06:33 -07:00
Alexandre Ganea f5314d15af [Support] On Unix, let the CrashRecoveryContext return the signal code
Before this patch, the CrashRecoveryContext was returning -2 upon a signal, like ExecuteAndWait does. This didn't match the behavior on Windows, where the the exception code was returned.

We now return the signal's code, which optionally allows for re-throwing the signal later. Doing so requires all custom handlers to be removed first, through llvm::sys::unregisterHandlers() which we made a public API.

This is part of https://reviews.llvm.org/D70378
2020-09-24 08:21:43 -04:00
Fangrui Song 7cf4603fae Reland D61689 Change -gz and -Wa,--compress-debug-sections to use gABI compression (SHF_COMPRESSED) with integrated assembler
This fixes an inconsistency: clang -c -gz -fno-integrated-as means SHF_COMPRESSED
while clang -c -gz -fintegrated-as means zlib-gnu.

---

Since July 15, 2015 (binutils-gdb commit
19a7fe52ae3d0971e67a134bcb1648899e21ae1c, included in 2.26), gas
--compress-debug-sections=zlib (gcc -gz) means zlib-gabi:
SHF_COMPRESSED. Before that GCC/binutils used zlib-gnu (.zdebug).

clang's -gz was introduced in rC306115 (Jun 2017) to indicate zlib-gnu. It
is 2020 now and it is not unreasonable to assume users of the new
feature to have new linkers (ld.bfd/gold >= 2.26, lld >= rLLD273661).

Change clang's default accordingly to improve standard conformance.
zlib-gnu becomes out of fashion and gets poorer toolchain support.
Its mangled names confuse tools and are more likely to cause problems.

Reviewed By: compnerd

Differential Revision: https://reviews.llvm.org/D61689
2020-08-03 15:12:01 -07:00
Michele Scandale 53880b8cb9 [CMake] Make `intrinsics_gen` dependency unconditional.
The `intrinsics_gen` target exists in the CMake exports since r309389
(see LLVMConfig.cmake.in), hence projects can depend on `intrinsics_gen`
even it they are built separately from LLVM.

Reviewed By: MaskRay, JDevlieghere

Differential Revision: https://reviews.llvm.org/D83454
2020-07-17 16:43:17 -07:00
John Brawn ce1fa201af [Driver] When forcing a crash print the bug report message
Commit a945037e8f moved the printing of the
"PLEASE submit a bug report" message to the crash handler, but that means we
don't print it when forcing a crash using FORCE_CLANG_DIAGNOSTICS_CRASH. Fix
this by adding a function to get the bug report message and printing it when
forcing a crash.

Differential Revision: https://reviews.llvm.org/D81672
2020-06-29 13:13:12 +01:00
Alexandre Ganea 89ea0b0520 [MC] Pass down argv0 & cc1 cmd-line to the back-end and store in MCTargetOptions
When targetting CodeView, the goal is to store argv0 & cc1 cmd-line in the emitted .OBJ, in order to allow a reproducer from the .OBJ alone.

This patch is to simplify https://reviews.llvm.org/D80833
2020-06-18 09:17:14 -04:00
Benjamin Kramer 52dcbcbfe0 Simplify string joins. NFCI. 2020-04-11 17:20:11 +02:00
Zakk Chen 64fe841856 Fix typo, targetFeature should be lowercase.
this fixing also enable llc -mattr=+cpuhelp

Reviewers: ziangwan, kongyi

Reviewed By: kongyi

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D76757
2020-03-26 19:40:04 -07:00
gbreynoo a945037e8f Tools emit the bug report URL on crash
When Clang crashes a useful message is output:

"PLEASE submit a bug report to https://bugs.llvm.org/ and include the
crash backtrace, preprocessed source, and associated run script."

A similar message is now output for all tools.

Differential Revision: https://reviews.llvm.org/D74324
2020-03-26 10:26:59 +00:00
Eli Friedman 896335bfb8 Don't export symbols from clang/opt/llc if plugins are disabled.
The only reason we export symbols from these tools is to support
plugins; if we don't have plugins, exporting symbols just bloats the
executable and makes LTO less effective.

See review of D75879 for the discussion that led to this patch.

Differential Revision: https://reviews.llvm.org/D76527
2020-03-23 12:17:09 -07:00
Alexandre Ganea 28ad9fc208 [Clang][Driver] In -fintegrated-cc1 mode, avoid crashing on exit after a compiler crash
After a crash catched by the CrashRecoveryContext, this patch prevents from accessing dangling pointers in TimerGroup structures before the clang tool exits. Previously, the default TimerGroup had internal linked lists which were still pointing to old Timer or TimerGroup instances, which lived in stack frames released by the CrashRecoveryContext.

Fixes PR45164.

Differential Revision: https://reviews.llvm.org/D76099
2020-03-13 08:15:35 -04:00