Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4 |
|
#
2167881f |
| 21-Feb-2024 |
Fangrui Song <i@maskray.me> |
[ARM,MC] Support FDPIC relocations
Linux kernel fs/binfmt_elf_fdpic.c supports FDPIC for MMU-less systems. GCC/binutils/qemu support FDPIC ABI for ARM (https://github.com/mickael-guene/fdpic_doc). _
[ARM,MC] Support FDPIC relocations
Linux kernel fs/binfmt_elf_fdpic.c supports FDPIC for MMU-less systems. GCC/binutils/qemu support FDPIC ABI for ARM (https://github.com/mickael-guene/fdpic_doc). _ARM FDPIC Toolchain and ABI_ provides a summary.
This patch implements FDPIC relocations to the integrated assembler. There are 6 static relocations and 2 dynamic relocations, with R_ARM_FUNCDESC as both static and dynamic.
gas requires `--fdpic` to assemble data relocations like `.word f(FUNCDESC)`. This patch adds `MCTargetOptions::FDPIC` and reports an error if FDPIC is not set.
Pull Request: https://github.com/llvm/llvm-project/pull/82187
show more ...
|
Revision tags: llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5 |
|
#
423ad04c |
| 06-Nov-2023 |
Stefan Pintilie <stefanp@ca.ibm.com> |
[PowerPC] Add an alias for -mregnames so that full register names used in assembly. (#70255)
This option already exists on GCC and so it is being added to LLVM so
that we use the same option as the
[PowerPC] Add an alias for -mregnames so that full register names used in assembly. (#70255)
This option already exists on GCC and so it is being added to LLVM so
that we use the same option as them.
show more ...
|
Revision tags: llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init |
|
#
9b8ed1ee |
| 11-Jul-2023 |
Chen, Cheng2 <cheng2.chen@intel.com> |
[NFC]add initialization for EmitCompactUnwindNonCanonical in ctor
I found that the newly added member variables, "EmitCompactUnwindNonCanonical" were not initialized in the constructor, but other me
[NFC]add initialization for EmitCompactUnwindNonCanonical in ctor
I found that the newly added member variables, "EmitCompactUnwindNonCanonical" were not initialized in the constructor, but other member variables were initialized. The behavior seems to need to be consistent to improve code.
Reviewed By: oontvoo
Differential Revision: https://reviews.llvm.org/D154472
show more ...
|
Revision tags: llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6 |
|
#
d4bcb45d |
| 12-Jun-2022 |
Jez Ng <jezng@fb.com> |
[MC][re-land] Omit DWARF unwind info if compact unwind is present where eligible
This reverts commit d941d597837d9e1405086f008c9bd6a71e7263c9.
Differential Revision: https://reviews.llvm.org/D122258
|
#
d941d597 |
| 12-Jun-2022 |
Jez Ng <jezng@fb.com> |
Revert "[MC] Omit DWARF unwind info if compact unwind is present where eligible"
This reverts commit ef501bf85d8c869248e51371f0e74bcec0e7b229.
|
#
ef501bf8 |
| 12-Jun-2022 |
Jez Ng <jezng@fb.com> |
[MC] Omit DWARF unwind info if compact unwind is present where eligible
Previously, omitting unnecessary DWARF unwinds was only done in two cases: * For Darwin + aarch64, if no DWARF unwind info is
[MC] Omit DWARF unwind info if compact unwind is present where eligible
Previously, omitting unnecessary DWARF unwinds was only done in two cases: * For Darwin + aarch64, if no DWARF unwind info is needed for all the functions in a TU, then the `__eh_frame` section would be omitted entirely. If any one function needed DWARF unwind, then MC would emit DWARF unwind entries for all the functions in the TU. * For watchOS, MC would omit DWARF unwind on a per-function basis, as long as compact unwind was available for that function.
This diff makes it so that we omit DWARF unwind on a per-function basis for Darwin + aarch64 as well. In addition, we introduce the flag `--emit-dwarf-unwind=` which can toggle between `always`, `no-compact-unwind` (only emit DWARF when CU cannot be emitted for a given function), and the target platform `default`. `no-compact-unwind` is particularly useful for newer x86_64 platforms: we don't want to omit DWARF unwind for x86_64 in general due to possible backwards compat issues, but we should make it possible for people to opt into this behavior if they are only targeting newer platforms.
**Motivation:** I'm working on adding support for `__eh_frame` to LLD, but I'm concerned that we would suffer a perf hit. Processing compact unwind is already expensive, and that's a simpler format than EH frames. Given that MC currently produces one EH frame entry for every compact unwind entry, I don't think processing them will be cheap. I tried to do something clever on LLD's end to drop the unnecessary EH frames at parse time, but this made the code significantly more complex. So I'm looking at fixing this at the MC level instead.
**Addendum:** It turns out that there was a latent bug in the X86 backend when `OmitDwarfIfHaveCompactUnwind` is naively enabled, which is not too surprising given that this combination has not been heretofore used.
For functions that have unwind info that cannot be encoded with CU, MC would end up dropping both the compact unwind entry (OK; existing behavior) as well as the DWARF entries (not OK). This diff fixes things so that we emit the DWARF entry, as well as a CU entry with encoding `UNWIND_X86_MODE_DWARF` -- this basically tells the unwinder to look for the DWARF entry. I'm not 100% sure the `UNWIND_X86_MODE_DWARF` CU entry is necessary, this was the simplest fix. ld64 seems to be able to handle both the absence and presence of this CU entry. Ultimately ld64 (and LLD) will synthesize `UNWIND_X86_MODE_DWARF` if it is absent, so there is no impact to the final binary size.
Reviewed By: davide, lhames
Differential Revision: https://reviews.llvm.org/D122258
show more ...
|
Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3 |
|
#
e4479504 |
| 26-Apr-2022 |
Andrew Savonichev <andrew.savonichev@gmail.com> |
[NFC] Fix order of initialization in MCTargetOptions
This patch fixes a compiler warning after D121299:
field 'MCUseDwarfDirectory' will be initialized after field 'MCIncrementalLinkerCompatible'
|
#
0a27622a |
| 26-Apr-2022 |
Andrew Savonichev <andrew.savonichev@gmail.com> |
[NVPTX] Disable DWARF .file directory for PTX
Default behavior for .file directory was changed in D105856, but ptxas (CUDA 11.5 release) refuses to parse it:
$ llc -march=nvptx64 llvm/test/Debu
[NVPTX] Disable DWARF .file directory for PTX
Default behavior for .file directory was changed in D105856, but ptxas (CUDA 11.5 release) refuses to parse it:
$ llc -march=nvptx64 llvm/test/DebugInfo/NVPTX/debug-file-loc.ll $ ptxas debug-file-loc.s ptxas debug-file-loc.s, line 42; fatal : Parsing error near '"foo.h"': syntax error
Added a new field to MCAsmInfo to control default value of UseDwarfDirectory. This value is used if -dwarf-directory command line option is not specified.
Differential Revision: https://reviews.llvm.org/D121299
show more ...
|
Revision tags: llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2 |
|
#
9647a6f7 |
| 07-Jun-2021 |
Wouter van Oortmerssen <aardappel@gmail.com> |
[WebAssembly] Added initial type checker to MC Assembler
This to protect against non-sensical instruction sequences being assembled, which would either cause asserts/crashes further down, or a Wasm
[WebAssembly] Added initial type checker to MC Assembler
This to protect against non-sensical instruction sequences being assembled, which would either cause asserts/crashes further down, or a Wasm module being output that doesn't validate.
Unlike a validator, this type checker is able to give type-errors as part of the parsing process, which makes the assembler much friendlier to be used by humans writing manual input.
Because the MC system is single pass (instructions aren't even stored in MC format, they are directly output) the type checker has to be single pass as well, which means that from now on .globaltype and .functype decls must come before their use. An extra pass is added to Codegen to collect information for this purpose, since AsmPrinter is normally single pass / streaming as well, and would otherwise generate this information on the fly.
A `-no-type-check` flag was added to llvm-mc (and any other tools that take asm input) that surpresses type errors, as a quick escape hatch for tests that were not intended to be type correct.
This is a first version of the type checker that ignores control flow, i.e. it checks that types are correct along the linear path, but not the branch path. This will still catch most errors. Branch checking could be added in the future.
Differential Revision: https://reviews.llvm.org/D104945
show more ...
|
Revision tags: llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2 |
|
#
a8ec9de4 |
| 03-Jun-2020 |
Igor Kudrin <ikudrin@accesssoftek.com> |
[MC] Add --dwarf64 to generate DWARF64 debug info [1/7]
The patch adds an option `--dwarf64` to instruct a tool to generate debug information in the 64-bit DWARF format. There is no real implementat
[MC] Add --dwarf64 to generate DWARF64 debug info [1/7]
The patch adds an option `--dwarf64` to instruct a tool to generate debug information in the 64-bit DWARF format. There is no real implementation yet, only a few compatibility checks.
Differential Revision: https://reviews.llvm.org/D81143
show more ...
|
Revision tags: llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3 |
|
#
ee2c0f76 |
| 16-Feb-2020 |
Eric Astor <epastor@google.com> |
[ms] [llvm-ml] Add a draft MASM parser
Summary: Many directives are unavailable, and support for others may be limited.
This first draft has preliminary support for: - conditional directives (i
[ms] [llvm-ml] Add a draft MASM parser
Summary: Many directives are unavailable, and support for others may be limited.
This first draft has preliminary support for: - conditional directives (including errors), - data allocation (unsigned types up to 8 bytes, and ALIGN), - equates/variables (numeric and text), - and procedure directives (without parameters), as well as COMMENT, ECHO, INCLUDE, INCLUDELIB, PUBLIC, and EXTERN. Text variables (aka text macros) are expanded in-place wherever the identifier occurs.
We deliberately ignore all ml.exe processor directives.
Prominent features not yet supported: - structs - macros (both procedures and functions) - procedures (with specified parameters) - substitution & expansion operators
Conditional directives are complicated by the fact that "ifdef rax" is a valid way to check if a file is being assembled for a 64-bit x86 processor; we add support for "ifdef <register>" in general, which requires adding a tryParseRegister method to all MCTargetAsmParsers. (Some targets require backtracking in the non-register case.)
Reviewers: rnk, thakis
Reviewed By: thakis
Subscribers: kerbowa, merge_guards_bot, wuzish, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, mgorny, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, Jim, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72680
show more ...
|
Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init |
|
#
d2bb8c16 |
| 01-Jan-2020 |
Fangrui Song <maskray@google.com> |
[MC][TargetMachine] Delete MCTargetOptions::MCPIECopyRelocations
clang/lib/CodeGen/CodeGenModule performs the -mpie-copy-relocations check and sets dso_local on applicable global variables. We don't
[MC][TargetMachine] Delete MCTargetOptions::MCPIECopyRelocations
clang/lib/CodeGen/CodeGenModule performs the -mpie-copy-relocations check and sets dso_local on applicable global variables. We don't need to duplicate the work in TargetMachine shouldAssumeDSOLocal.
Verified that -mpie-copy-relocations can still emit PC relative relocations for external variable accesses.
clang -target x86_64 -fpie -mpie-copy-relocations -c => R_X86_64_PC32 clang -target aarch64 -fpie -mpie-copy-relocations -c => R_AARCH64_ADR_PREL_PG_HI21+R_AARCH64_LDST64_ABS_LO12_NC
show more ...
|
Revision tags: llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5 |
|
#
aedec3f6 |
| 11-Mar-2019 |
Evgeniy Stepanov <eugeni.stepanov@gmail.com> |
Remove ASan asm instrumentation.
Summary: It is incomplete and has no users AFAIK.
Reviewers: pcc, vitalybuka
Subscribers: srhines, kubamracek, mgorny, krytarowski, eraman, hiraditya, jdoerfert, #
Remove ASan asm instrumentation.
Summary: It is incomplete and has no users AFAIK.
Reviewers: pcc, vitalybuka
Subscribers: srhines, kubamracek, mgorny, krytarowski, eraman, hiraditya, jdoerfert, #sanitizers, llvm-commits, thakis
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D59154
llvm-svn: 355870
show more ...
|
Revision tags: llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3 |
|
#
6bda14b3 |
| 06-Jun-2017 |
Chandler Carruth <chandlerc@gmail.com> |
Sort the remaining #include lines in include/... and lib/....
I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line
Sort the remaining #include lines in include/... and lib/....
I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days.
I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch.
This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files.
Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again).
llvm-svn: 304787
show more ...
|
Revision tags: llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3 |
|
#
4b6ff6b8 |
| 10-Feb-2017 |
Eugene Zelenko <eugene.zelenko@gmail.com> |
[MC] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).
llvm-svn: 294685
|
Revision tags: llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3 |
|
#
b38cfced |
| 05-Dec-2016 |
Weiming Zhao <weimingz@codeaurora.org> |
Summary: Currently there is no way to disable deprecated warning from asm like this
clang -target arm deprecated-asm.s -c deprecated-asm.s:30:9: warning: use of SP or PC in the list is deprecated
Summary: Currently there is no way to disable deprecated warning from asm like this
clang -target arm deprecated-asm.s -c deprecated-asm.s:30:9: warning: use of SP or PC in the list is deprecated stmia r4!, {r12-r14}
We have to have an option what can disable it.
Patched by Yin Ma!
Reviewers: joey, echristo, weimingz
Subscribers: llvm-commits, aemerson
Differential Revision: https://reviews.llvm.org/D27219
llvm-svn: 288734
show more ...
|
Revision tags: llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
#
f29fa586 |
| 13-Oct-2016 |
Sriraman Tallam <tmsriram@google.com> |
New llc option pie-copy-relocations to optimize access to extern globals.
This option indicates copy relocations support is available from the linker when building as PIE and allows accesses to exte
New llc option pie-copy-relocations to optimize access to extern globals.
This option indicates copy relocations support is available from the linker when building as PIE and allows accesses to extern globals to avoid the GOT.
Differential Revision: https://reviews.llvm.org/D24849
llvm-svn: 284160
show more ...
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1 |
|
#
e67c1466 |
| 27-Jul-2016 |
Nirav Dave <niravd@google.com> |
Initialize PreserveAsmComments in MCTargetOptions
llvm-svn: 276905
|
Revision tags: llvmorg-3.8.1, llvmorg-3.8.1-rc1, llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1 |
|
#
03e2cc30 |
| 21-Dec-2015 |
David Majnemer <david.majnemer@gmail.com> |
[MC, COFF] Support link /incremental conditionally
Today, we always take into account the possibility that object files produced by MC may be consumed by an incremental linker. This results in us i
[MC, COFF] Support link /incremental conditionally
Today, we always take into account the possibility that object files produced by MC may be consumed by an incremental linker. This results in us initialing fields which vary with time (TimeDateStamp) which harms hermetic builds (e.g. verifying a self-host went well) and produces sub-optimal code because we cannot assume anything about the relative position of functions within a section (call sites can get redirected through incremental linker thunks).
Let's provide an MCTargetOption which controls this behavior so that we can disable this functionality if we know a-priori that the build will not rely on /incremental.
llvm-svn: 256203
show more ...
|
Revision tags: llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1, llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, studio-1.4, llvmorg-3.7.0-rc2 |
|
#
fe36f83b |
| 27-Jul-2015 |
Colin LeMahieu <colinl@codeaurora.org> |
[llvm-mc] Add --no-warn flag with -W alias to disable outputting warnings while assembling.
llvm-svn: 243338
|
Revision tags: llvmorg-3.7.0-rc1, llvmorg-3.6.2, llvmorg-3.6.2-rc1, llvmorg-3.6.1, llvmorg-3.6.1-rc1, llvmorg-3.5.2, llvmorg-3.5.2-rc1, llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3, llvmorg-3.6.0-rc2, llvmorg-3.6.0-rc1 |
|
#
6e30cd95 |
| 14-Jan-2015 |
Eric Christopher <echristo@gmail.com> |
Migrate ABIName to MCTargetOptions so that it can be shared between the TargetMachine level and the MC level.
llvm-svn: 225891
|
Revision tags: llvmorg-3.5.1, llvmorg-3.5.1-rc2, llvmorg-3.5.1-rc1, llvmorg-3.5.0, llvmorg-3.5.0-rc4 |
|
#
2981591f |
| 26-Aug-2014 |
Joerg Sonnenberger <joerg@bec.de> |
Convert MC command line option for fatal assembler warnings into a proper flag.
llvm-svn: 216471
|
Revision tags: llvmorg-3.5.0-rc3, llvmorg-3.5.0-rc2, llvmorg-3.5.0-rc1 |
|
#
4c5bff36 |
| 19-Jun-2014 |
Eric Christopher <echristo@gmail.com> |
Move -dwarf-version to an MC level command line option so it's used by all of the MC level tools and codegen. Fix up all uses in the compiler to use this and set it on the context accordingly.
llvm-
Move -dwarf-version to an MC level command line option so it's used by all of the MC level tools and codegen. Fix up all uses in the compiler to use this and set it on the context accordingly.
llvm-svn: 211257
show more ...
|
#
eb719728 |
| 20-May-2014 |
Eric Christopher <echristo@gmail.com> |
Move the verbose asm option to be part of the options struct and set appropriately.
llvm-svn: 209258
|