A function attribute use-soft-float with values true or false is used instead.
This commi only ensures that LDC compiles with LLVM 3.7. The possible semantic
change needs to be evaluated.
Linking several modules together seems to trigger assertions with
identified structs. In debug builds, the assertion
!(Pair.first != Ty && Pair.second == Ty) && "mapping to a source type"
is raised. In non-debug builds, you often get a D exception saying
"Enforcement failed".
Reason seems to be the use of the some type object in different
modules. E.g. module A imports from module B the struct S. Then both
modules refer to the same identifed llvm::StructType object. This
causes the errors.
The behaviour may be an LLVM bug. There is no test case for this
situation. This affects all supported LLVM versions. If the target
module is changed (e.g. use of llvmModule[0] instead of an empty
module) then the error occurs in other LLVM versions, too.
This commit uses the following workaround:
- target module is llvmModule[0] (instead of an empty module)
- each other module is first linked into an empty module and then
into the target module.
This is really ugly but avoids the error.
There is no new test case required because runnable/A16.d already
checks it.
Set versions ARM_SoftFP & D_HardFloat instead of ARM_SoftFloat &
D_SoftFloat for option -mfloat-abi=softfp (function calls use soft float
ABI but using hardware floating point instruction).
(cherry picked from commit 5a19080e04cc775fe94ea2ef74c850b26bb8a469)
Includes all tagged with v2.067.0-b2. Does not includes latest druntime changes from ldc (head) branch.
This is known to be broken. I only merged the frontend stuff but did not try to compile something...
The TargetLibraryInfo class is now a wrapper. The real implementation
is TargetLibraryInfoImpl.
The TargetMachine can be asked for the DataLayout (like in all other
supported versions except 3.6)
First merge of current development stream. Asm blocks are known to be broken.
DMD: 0c9f437bc24015707130ba42dc434d9cd58282fb
druntime: 86d49cfb3670904603df0cfdfe44c6fff565c0fc
Phobos: a8ca4f7964becac680af0eadbde05aa7d10fc338
Turns out that since the change to use DMD's symbol emission
logic a few releases back we didn't actually ever emit code
for the extra modules. Thus, all the effort for the extra
semantic passes went to waste.
If we want to implement DMD-style cross-module inlining, we
need to add the extra semantic3s back in, and then iterate
over all the non-root modules with a codegen visitor that
only emits symbols as available_externally.
We probably won't need the availableExternally members if
we start with a clean design in the new symbol emission
framework. Thus, remove everything in the meantime. This
will make some release builds a bit faster, and should not
negatively affect generated code.
A similar problem as in upstream issue 13025 has been
observerd for LDC on Arch Linux (GNU ld 2.24) as well. This
is essentially the same workaround as Martin came up with in
D-Programming-Language/druntime#889. Because the linker
defines the symbols anyway as part of the default linker
script, the weak linkage actually makes no difference.
This is necessary as the only point of having -defaultlib
and -debuglib is to enable the user to customize the defaults
set in the configuration, for example to avoid linking to
Phobos.
GitHub: Fixes#416.
GitHub: Fixes#601.
