I.e., llvm/CodeGen/CommandFlags.h which in turn includes
llvm/MC/MCTargetOptionsCommandFlags.h.
This gets rid of a few duplicates on our side and includes about 35
(depending on LLVM version) new command-line options. LLVM provides a
helper function to set up the TargetOptions according to (most of) these
options.
Newer LLVM versions may add new options and we'll automatically inherit
them, including setting up the TargetOptions accordingly.
I did my best (TM) to remove a few unused/undesirable options and hide all
remaining new ones except for `-fp-contract`. The lists will need to be
tweaked from time to time.
For switches to be appended after the user switches (or right before the
first `-run` switch).
The sections inherit it (as well as `switches`) from the `default` section
if it isn't overridden explicitly.
Fixes issue #2186.
* Disable debug info for now Until I get it working.
* Don't recurse into uninstansiated templates
* Remove device only modules from objfiles.
* Remove typeid generation for dcompute.
* Dont generate typeinfo member functions
* Whitelist `__dcompute_reflect`
* Fix LLVM 5.0 compilation.
* Fix adding linker option metadata to LLVM module.
See https://reviews.llvm.org/D31349
* Version the SPIRV cache dir on travis.
When creating LLVM's TargetMachine, llvm::SubtargetFeatures::getFeatureBits()
is called 3 times, and the help is printed 3 times (or even 6 times when
specifying both `-mcpu=help -mattr=help`).
So use some new code making sure the help is printed only once and return
0 early without trying to compile anything (and so erroring if no source
files have been specified etc.).
Fixes issue #2073.
Simplify LDMD quite a bit by translating the few different command-line
options directly in-place. This puts some more stress onto LDC's
command-line parsing, especially due to multiple occurrences of a single
Boolean option (e.g., '-o-') or mixtures of `-m64` and `-m32` etc. for
dmd-testsuite.
Also add new command-line option `-verrors-spec` showing gagged errors
(DMD's equivalent is `-verrors=<spec|limit>`) and sync the usage text with
DMD. LDMD now also recognizes `-h` (and `/?` on Windows).
The part needing most attention was ddmd.root.ctfloat, ddmd.target (incl.
gen/target.cpp) and ddmd.builtin. The front-end is now prepared for
elaborate compile-time floating-point types to allow for proper cross-
compilation.
This version still uses the host's `real` type for compile-time reals,
except for MSVC hosts, which still use 64-bit doubles (when compiled with
DMD host compiler too).
Some other changes:
* semantic*() of Statements extracted from statement.d to statementsem.d
* mangle() -> mangleToBuffer()
* Identifier::string -> toChars()
* Token::float80value => floatvalue
* Dsymbol::isAggregateMember() => isMember()
* BoolExp is no more
* ddmd.root.ctfloat: LDC-specific CTFE builtins
Fix issue #1941 by expanding response files *before* temptatively parsing
an explicit `-conf` and/or target triple for the config file lookup.
After injecting the switches from the config file right after argv[0],
expand again to catch any response files specified in the config file
switches.
I've previously missed this part when moving to the DMD output filenames.
LDC used to enforce the target object file extension for all produced
objects.
So in `compilable/ldc_output_filenames.sh`, we tried to produce the object
file `myObj.myExt.` instead of `myObj.myExt`. The tests passed on Windows,
but failed at least on Linux.
Make sure the overall order corresponds to the user's command-line order
of object and source files. The only exception being singleObj builds,
for which the single object file for all source files is always the first
entry in the object files list (which is forwarded to the linker in that
order). This is done so that we can easily get hold of the name when
emitting the single object file later in the `ldc::CodeGenerator` dtor.
It should also clearly define the linking order (affecting comdat
selections etc.) for special singleObj builds.
Also reuse some more code (wrt. output filenames) from DMD's main().
DMD does too, and the front-end's FileName class expects backslashes in
some places.
Due to the import and lib directories in the ldc2.conf file being
specified with forward slashes, most paths produced by LDC used both
slashes, e.g., `C:/LDC/ldc/runtime/druntime/src\object.d`, which looks
unprofessional, is problematic for the front-end and leads to differences
wrt. DMD when outputting module dependencies etc.
