When certain attributes are applied to the calling function, like "unsafe-fp-math", the inlined inlineIR function has to have the same attributes otherwise the calling function attribute will be reset to the safe merge of the two: "false". Because the same inlineIR function can be called in different functions using an alias definition, a new function (with possibly different attributes) has to be instantiated upon every call.
Related GH issue #1438
The first check is what DMD also does; the second one is to replace
the assertion by an ICE, since the bug can apparently be triggered
rather reliably.
See GitHub #1360.
This is required to resolve the type for AAPCS/AAPCS64.
Up to now it was not necessary because only char* was used.
AAPCS/AAPCS64 use a special extern(C++) struct __va_list.
Also adds the CMake infrastructure to compile and link the D source files.
The build is partially broken:
- A few files in Phobos and druntime do not build
- MSVC build is broken because of unresolved symbols involving reals
And for sret args too, except for MSVC targets.
At least on Win64, the sret align attributes lead to ICEs for std.bitmanip
and std.uni (release only), when computing the known alignment in the LLVM
inliner pass:
Assertion failed: I->getParent()->getParent() ==
Q.CxtI->getParent()->getParent() && "Got assumption for the wrong function!",
file C:\LDC\llvm\lib\Analysis\ValueTracking.cpp, line 711
Trying to get the alignment right by using the first non-default one
in the following order of descending priority:
VarDeclaration::alignment [variables only of course]
Type::alignment()
Type::alignsize()
This fixes `align(x) struct S { ... }`.
Starting with LLVM 3.7, linkage and COMDAT are 2 different concepts.
This means that LinkageODROnce does not put the object into a COMDAT.
On Windows this resulted in linker error messages.
This PR places all template functions, TypeInfo objects and other
objects into a COMDAT.
This is most visible on x86 (32-bit), where the stack
alignment is off otherwise.
This change is quite messy because many places assumed
that there was always exactly one LLVM parameter per
TypeFunction::parameters entry.
Now with *almost* working EH codegen. Does not compile Phobos yet
because we run into the "instruction does not dominate all uses"
issue when an r-value result of toElemDtor is used and we need to
run cleanups in between. Should easily be fixed by promoting those
values to allocas.
Most of the changes outside of ir/irfunction.{h, cpp} are just
because CreateCallOrInvoke moved locations. I took the
opportunity to also make use of the different arg count
overloads where possible.
Never generates any landing pads or invoke instructions right now
for simplicity. The code for emitting them will be added back in
the next step.
The "after..." blocks without any precedessors remain for now, as
we need a clean way to suppress any codegen for that block (but
not new blocks, which might resolve labels) before tackling that
one.
Builds druntime/Phobos on OS X x86_64 (albeit without EH, of course).
