that don't use a fixed stack (mantis #28454)
o moved the code to finalise managed out parameters from ncgcal to ncal,
and add it to the init code of the call node (so it's evaluated before
any parameters are processed, ensuring that mantis #28390 stays fixed)
git-svn-id: trunk@31328 -
different 'ar' implementations under different platforms
* use the omflib reader instead of the ar reader in the msdos internal linker
git-svn-id: trunk@31322 -
moved to virtual methods, to allow for platform specific overrides (e.g. for
supporting section names, other than '.text', '.data' and '.bss', etc.)
git-svn-id: trunk@31321 -
o all external symbol definitions are now inserted in the llvmtype post pass
based on all declarations and types used in llvm instructions
o this means we don't have to use the workaround with the Pascal mangled
names anymore for all external names, as we now insert the external
references only once we know all type information
git-svn-id: trunk@31287 -
interface of a unit, or forward declared, and then the implementation turns
out to be external. We now properly generate a wrapper routine at the
Pascal level for the original declaration that calls through to the
external routine
git-svn-id: trunk@31285 -
linkage types for aliases (or its documentation hasn't been updated), and
external linkage is the default so it doesn't matter for earlier versions
git-svn-id: trunk@31284 -
unicodestring constants: specify the type of the pointer to the
string record (which is indirect) rather than that of the string
array (which will implicitly be the result of the getelementptr)
git-svn-id: trunk@31256 -
o the result is still not very clean due to the fact that this data
is almost completely unstructured due to variable-length strings
everywhere, which means that
a) we cannot just load recorddefs from the system or typeinfo unit
and use those as templates
b) we cannot easily reuse the recorddefs we create ourselves (except
if the strings have the same length -- this is the reason for all
of the names specified to begin_anonymous_record: to reuse defs
as much as possible rather than creating new ones all the time)
c) we have to add explicitly aligned subrecords everywhere to insert
explicit alignment on platforms that need it
git-svn-id: trunk@31255 -
implicitly taking the address of a complex expression in a typed constant
(you cannot put the contents of another memory location in a typed
constant)
git-svn-id: trunk@31252 -
bytes,becayse if we emit them at the end then we may interpret the first
padding byte as the final component of the queued expression
git-svn-id: trunk@31246 -
parameters:
1) since they are finalised on the caller side, if that same value
is passed as a value parameter as well and its reference count
was 1, then the value parameter will contain an invalid pointer
2) since finalisation involves a call, for optimal code generation
purposes they should also be evaluated first
(mantis #28279, #28390)
git-svn-id: trunk@31201 -
