By discarding (and warning about) all but the first definition.
compilable/test17352.d tests that the compiler accepts 2 distinct but
equivalent templated function instantiations (with an alias to a
different local of the same type and name) ending up with a common
mangled name.
See https://issues.dlang.org/show_bug.cgi?id=17352.
These out contracts can still access the return value via __result.
LDC always passes the return value by reference to the out contract -
as long as there is a result (non-void). As the return type may still
need to be inferred in the first semantic pass, reserve a parameter
there and remove it later in semantic3() in case it is void (or finalize
its type).
Fixes compilable/test17502.
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.
* 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`
Apparently needed for x86_64 in general and NetBSD (possibly other BSD
flavours too) based on `clang::ToolChain::IsUnwindTablesDefault()`.
Resolves issue #2048.
The previous check wouldn't check intermediate aggregates for static-ness,
that was one problem. The other was the assertion that the outer function
can be reached as long as there are no static functions inbetween, which
isn't always the case, as issue #1864 clearly shows, which is resolved by
this.
Compatible with DMD, but restricted to Windows and functions only.
`export` functions with bodies get the dllexport attribute and will be
exported if the containing object is pulled in when linking.
Body-less `export` functions get the dllimport attribute and will be
accessed via an import table indirection, set up at runtime by the OS.
This is a temporary solution, the proper fix is a pending DMD PR, after
which LDC will need to be adapted.
