If a target file name is given (`-of`) and a library is created then
`-singleObj` is implied. This results in behaviour not compatible
with dmd. This commit checks for this situation and does not set
`-singleObj`. This fixes issue #978.
Adds a new command line option -mabi= and uses the value to compute
the ABI to use. Adds the ABI to linker and assembler invocation, too.
Allows consistent invocation of the whole tool chain.
LP64 defines a C environment with 64bit pointers and char/short/int/long
are 8/16/32/64bit. char/short/int/long have defined sizes in D. We need
to look only at the pointer size.
There are now 64bit environments with 32bit pointers. Examples are
x32 in Intel and N32 on MIPS64. For these environments D_LP64 should
not defined but the global.param.is64bit is still true. The definition
of size_t is also affected. If only 32bit are addressable then size_t
should also be a 32bit type. (This is not required by C standard but
common practize.)
The net result is that not only the definition of D_LP64 must be changed
but also DtoSize_t().
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.
