I hope I have untangled the checks for "native" Windows (Triple::Win32)
vs. Windows/MinGW/Cygwin (Triple::isOSWindows) correctly.
MinGW needs some default libraries as well, has to be fixed later.
In many parts the DMD frontend assumes a little endian CPU. In some
parts there are checks for endianess but they are incomplete and the
used definition is wrong. (Test for endianess will be removed in dmd
2.062.)
In this commit I add the required #if's and also add a CMake test for
endianess because there is no single compiler definition to check for.
Having two functions is not pretty, but shorter than messing
around with a custom context object, and much, MUCH better than
requiring a lot of changes to the rest of the code base.
This reverts commit c4adbedcc, which would have fixed the
problem at its roots, but caused strange template function
attribute inference failures in D-YAML, presumably due to
the different order of semantic3 execution on the templates.
Previously, it could happen that regular symbols referenced
only as part of a template instance (e.g. a lambda passed as
an alias parameter) were not even emitted in the wrong module,
but not at all because mustDefineSymbol would return false to
them when being analyzed during codegen of the wrong module.
This issue might affect incremental compilation with DMD as
well, and the fix should be discussed with the upstream devs.
GitHub: Fixes#249.
DMD has the obscure functionality to install functions starting with
_STI_ as global ctors and funtions starting with _STD_ as global
dtors. IMHO a pragma is a better way to specify the behaviour.
This commit adds pragma(LDC_global_crt_ctor) and
pragma(LDC_global_crt_dtor). If the pragma is specified on a function
or static method then an entry is made in the corresponding list. E.g.
in monitor_.d:
extern (C) {
#pragma(LDC_global_crt_ctor)
void _STI_monitor_staticctor()
{
// ...
}
}
This works on Linux without problems. On Windows with MS C Runtime
ctors work always but dtors are invoked only if linked against the
static C runtime. Dtors on Windows require at least LLVM 3.2.
The Param struct is very different between DMD and LDC. This is a start
to mark the differences. This also includes identifying unused switches
- like the debug? switches.
I removed the copyright notice. I don't think we are obliged to
display it for DMD; on the other hand, if we do, we might also
have to display the libconfig one (LGPL). Thus, this seemed like
the better choice.
The indentation is to align with the registered target output,
which we cannot control.
Adding pragma llvm_inline_ir.
Improved the error messages.
Append "ret void" when the return type is void
Improved the error message
in case when the string passed as llvm inline ir isn't valid llvm
assembly language.
LLVM 3.2 fix.
Add attribute AlwaysInline inside DtoInlineIRFunction.
Always generate a body for llvm_inline_ir
Also, always make llvm_inline_ir functions linkonce_odr. Because
the body is always generated when a module uses a llvm_inline_ir
function, the fact that the linker removes the function shouldn't
cause problems.
Such uncommented changes to the frontend are potentially a huge
source of confusion during merging new frontend versions
(especially if the piece of code gets changed again before the
next upstream release).
This fixes the std.format unit tests for assertion-enabled
LLVM builds.
What the actual solution for the problem should be depends
entirely on the outcome of the "Nested Unions?" discussion
on dmd-internals.
The previous solution was problematic because the change was language-
visble via the isUnsigned trait. Now, pointers are simply explicitly
checked for in the relevant places. (Note that there might be cases in
the diff where a direct isunsigned() call would have been appropriate –
I only checked for instances where the type clearly cannot be a pointer,
but chose to go the safe route in replicating existing behavior
otherwise).
Fixes DMD testcase 'traits'.
