This is apparently assumed by a std.conv unittest.
Using DtoAlignment() here instead of checking for an explicit
vd->alignment != STRUCTALIGN_DEFAULT is not only nice for consistency,
but also leads to a `struct S { align(16) int a; }` global being correctly
aligned on a 16-bytes boundary. The struct itself has no explicit
alignment, but alignsize() is 16; so the upstream code doesn't set any
explicit alignment for the global.
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.
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).
This fixes structs with members of structs with real fields. Did not
fail the test suite unless building with assertions before, but
crashed building real-world applications (and obviously led to wrong
struct layouts).
We already generated the memsets for zeroing the padding,
but because we relied on the native LLVM type allignment
where possible instead of generating explicit padding
values, LLVM did not always copy those bytes around (e.g.
when spilling/reloading registers).
Unfortunately, I could not manage to isolate a self-contained
test case. The bug is quite specific to the exact memory
allocation decisions made by the standard library, as it will
not occur if the elements appended by the finally block codegen
fit into the current capacity.
Debug information is based on static lexical blocks. Most calls to
EmitFuncEnd() are done if control flow reaches the end of the
function which is quite different.
This leads to serious problems for values we really should
not be loading from, such as 100k element static arrays.
It was hard to figure out exactly why we need to emit DWARF
info here, so the easiest solution is to just have a look
at assignments during the next big debug info push.
With a single byte (implicit and 0) as initializer, as each void
element occupies 1 byte.
This is required when building T.init for a struct T containing
a void[N] with N > 0 and building literals of T.
This is required for the GC to be able to call their dtors, if need
be (by appending a TypeInfo pointer after the actual struct in case
the struct has a dtor).
_d_newitemT() / _d_newitemiT() also perform the initialization, so
we don't need to take care of that in toir.cpp anymore.
Runtime function _d_delarray_t() expects the TypeInfo_Struct argument
to be null if the struct has no dtor.
This fixes runnable/hospital.d, which deletes a dynamic array of class
handles. But in this case, we only delete the memory allocated for the
handles and don't destruct the actual class instances!
For hospital.d, it doesn't matter as the class has no dtor.
But I doubt that's intended behavior...
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...
First merge of current development stream. Asm blocks are known to be broken.
DMD: 0c9f437bc24015707130ba42dc434d9cd58282fb
druntime: 86d49cfb3670904603df0cfdfe44c6fff565c0fc
Phobos: a8ca4f7964becac680af0eadbde05aa7d10fc338
