* compinnr.inc include file converted to a unit
* inline number field size stored in ppu increased from byte to longint
* inlines in the parse tree (when written with the -vp option) now printed with
their enum name, instead of number
git-svn-id: trunk@36174 -
f(..) before using x directly as function result for f(..) (instead of a
temp) in case the function result of temp is passed via a hiddel
call-by-reference parameter. After all, if the result is returned by
value, then any changes to the function result inside the callee code
won't affect whatever we will assign the result to until the callee
has returned. However, this is not true in case of inlining: then
the replaced function result node will be substituted directly in the
inlined code -> also check for aliasing in that case.
o fixes test/toperator5.pp on x86-64
git-svn-id: trunk@34893 -
in ncnv
* handle the fact that we overwrite the open array resultdef of a parameters'
left node with the original resultdef (i.e., also for dynamic arrays) with
regards to LLVM type rules
o use the parameter's formal type (open array) instead of the value's type
(dynamic array) when loading/using its value, since that's the type the
value has been converted to
o this change is not really nice since it adds several independent checks in
different places, but I can't find a way to nicely unify the code to work
around this (nor one to get rid of that hack in the first place)
git-svn-id: trunk@34515 -
also the by-reference function result of a call node, now that this is
properly checked in the general case (these parameters/function results
are temp nodes in case of inlined calls)
git-svn-id: trunk@34446 -
and getters for the ttemp*node classes instead
o this will allow descendants to prevent certain flags from being added
or removed. E.g. for LLVM, certain temps must never be put in registers
because it cannot typecast a value in a register from a non-record/array
type to an array type without forcing it to memory (so if that is done
on an lvalue, the result will be written to the memory temp instead of
to the register)
git-svn-id: trunk@34358 -
parameters into temps in case it's required for correctness (so we
can easily "early exit" on failure from the latter) (still no
functional changes)
git-svn-id: trunk@34284 -
symbol is defined
o removed all places where AB_INDIRECT symbols were explicitly generated
o only generate AB_INDIRECT symbols for AT_DATA on systems_indirect_var_imports
o for some symbols an indirect symbol is always required (because they are
dereferenced by code in RTL units) -> use new AT_DATA_FORCEINDIRECT type
git-svn-id: trunk@34165 -
tasmdata.DefineAsmSymbol() and all routines that call it
o will be used to automatically generate AB_INDIRECT sybols when
necessary
git-svn-id: trunk@34164 -
pgenutil.pas:
+ new function maybe_add_pending_specialization() to add a pending specialization if it belongs to the current unit
* generate_specialization_phase2: don't set up the owner as this leads to problems when using overloaded generic routines and don't add it to the pending list if it's a procdef
ncal.pas, tcallnode:
* pass_typecheck: if we have a specialization then add it to the pending specializations once we know that we use it
git-svn-id: trunk@33843 -
the funcretnode field keeps a reference to this temp even after we
assign it to the call-by-reference return parameter if it is deleted
by changing it into a normal temp (after which it will be freed when
the result of the call node is used), because in that case getcopy
for the callnode must copy this reference after copying the
tempdeletenode in order to reset tempinfo^.hookoncopy (mantis #29891)
git-svn-id: trunk@33569 -
typecheckpass, because if it's for a nested routine on a platform
that uses ncgnstmm/ncgnstld, all parentfpstructs (which are
generated by the typecheckpass of the loadparentfpnode) must be
generated before pass_1 starts
git-svn-id: trunk@32559 -
* extend tcallnode with the ability to pass a tspecializationcontext so that tcallcandidates can do a final specialization
* the final procdef is registered at the end of tcallnode.pass_typecheck
git-svn-id: trunk@31763 -
routines to see through free type conversions (such as type conversions
inserted for absolute variables, like the 'result' variable)
git-svn-id: trunk@31490 -
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 -
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 -
parameter instead of immediately doing it in the constructor of the call
node, and then only create it if we actually need it.
It was previously created in the call node constructor because it needs to be
done before pass_1 (which is where it is actually used) due to pass_1 possibly
being performed in the context of inlining (and then a wrong self parameter
may be found, or none at all), and it was done unconditionally because at that
point we don't know yet whether or not a self parameter will be necessary (as
we haven't resolved the overloads/procdef yet).
The problem with this is that if we use the parentfpstruct way of handling
accesses to outer scope locals/parameters, we need to know all locals/
parameters that will be accessed from nested routines after typecheckpass,
otherwise we get crashes. The problem was that if a call to an RTL routine was
generated by the compiler in a routine nested inside a method during pass_1,
and this nested routine itself did not access self of the method (so self was
not added to its parentfpstruct during the typecheckpass), then the
unconditional reference to self when creating the call caused a compiler
crash (introduced in r30908)
git-svn-id: trunk@31197 -
type-safe way (for LLVM, and also internal consistency checking between
the VMT as generated in nobj.pas and ncgvmt.pas)
o also converted the VMT validity checking to the node level
git-svn-id: trunk@30950 -
tcallnode constructor, so that when it's needed later during pass 1,
its value doesn't depend on the context in which pass 1 is executed
(e.g. when inlining) (mantis #18121)
git-svn-id: trunk@30908 -
load a value from a nested context, or to pass a context to a nested
routine. In case a target uses both the stack and frame pointer, this
difference can matter.
git-svn-id: trunk@29937 -
platforms that normally must copy value parameters on the caller side,
because
o if we copy them on the caller side, then the behaviour will be different
compared to other platforms if the called routine is implemented in C
(since they are passed by reference, changes to the array contents will
be visible on other platforms, while they wouldn't be visible if the
copy is made on the caller side)
o if we don't copy them on the caller nor on the callee side, then behaviour
will be different compared to other platforms if the called routine is
implemented in Pascal and modifies the array (since then changes won't be
visible on the caller side, except on platforms that normally perform
the copy on the caller side)
git-svn-id: trunk@29873 -
be copied on the caller instead of callee side
o mark Darwin/Aarch64 as such a target (any AArch64 target will be like
that normally, as its ABI specifies this behaviour)
o don't mark by-reference value parameters on such targets as
vo_has_local_copy, since a) they don't have one (the copy is on the
caller side), and b) this ensures that all code handling such
parameters automatically knows that they are still by reference
after the init code has run
o when making the copies on the caller side, don't increase the
reference count for managed types except for variants, just like
is done when making the copies on the callee side. This is because
the reference count increasing code on the callee side only runs
for non-assembler functions, and we cannot know 100% certain on the
caller side whether the called function is assembler or not (e.g. in
case of externally declared functions)
o maybe over time we can reuse the Pascal code in
tcallparanode.copy_value_by_ref_para to replace the equivalent code
in hlcgobj and ncgutil also on the caller side for other targets
git-svn-id: trunk@29870 -
* when getting rid of temps. of inline parameters, take care if somewhere an alias of the variable might exist, resolves#24796 and #26534
git-svn-id: trunk@29616 -
inline function is getting assigned to one of its parameters, so that
typecasts etc. are dealt with correctly (mantis #26536)
git-svn-id: trunk@28834 -
o blocks are implemented as a variation of procedure variables
o declaration of a block variable: "test: procedure(c: char) is block;"
(C equivalent: (void)(^test)(char c) )
o the compiler automatically converts procedures/functions whose address
is passed to a block parameter or assigned to a block variable into
a "block". This consists of
1) generating a block descriptor (containing the size of the "block
literal" (see below) and the signature of the invocation function
encoded as an Objective-C selector)
2) generating a wrapper function around the original funcion (with C
calling convention), that has an extra first hidden parameter
(marked as vo_is_parentfp in the compiler) whose type is a pointer
to the describing "block literal"
3) generating the "block literal", which contains a pointer to an
external variable indicating whether this block captures context or
not, some flags (see compiler/blockutl.get_block_literal_flags for
info), a pointer to the wrapper function and a pointer to the
descriptor. In the future, it will also contain captured variables.
o right now, only global procedures/functions can be converted to blocks
(because they don't require state capturing). The next steps are (Object
Pascal) methods (not Objective-C methods, because Objective-C method
procvars don't exist) and finally nested functions
o on Mac OS X, the functionality will only work on Mac OS X 10.7 and later,
because we have to use the so-called "ABI.2010.3.16" to ensure that
our blocks aren't called as variadic functions by the runtime (which
came out after the Mac OS X 10.6 release)
o while the currently implemented functionality does not require any
library support at all, there's no use enabling it on other platforms
because unless it has been confirmed to work with a blocks runtime,
there's no point in using blocks (they're just somewhat bulky procvars
right now). Enabling it on other platforms (in combination with the
GNUStep Objective-C run time), should simply be a matter of adding
the right {$linklib xxx} statement to rtl/inc/blockrtl.pp file, adding
that file to Makefile.fpc for that platform and adding that platform
to the compiler/systems.systems_blocks_supported set
git-svn-id: branches/blocks@28232 -
so it doesn't truncate mangled names for the JVM target (it's
used there since r27149)
o adapted a number of WPO helpers to use tsymstr instead of
shortstring, but the WPO devirtualization functionality is
still limited to shortstrings internally
git-svn-id: trunk@27741 -
Currently it is implemented only for x86-CPUs supporting the FMA extension. While it would
be possible to implement it in software or simulate fma(<single>,<single>,<single>) using
double operations, it makes no sense in my opinion to do so.
git-svn-id: trunk@27564 -
cpu-specific descendants (unfortunately causes some duplication, but the
code is trivial and there is no easy way to avoid it)
* also moved the use of the field in ncal to cpu-specific files (with same
caveat)
git-svn-id: trunk@27438 -
o made all (non-abstract) tdef and tsym constructors virtual
o added c*def/c*sym classref types for every (non-abstract) t*def/t*sym
class
o added cpusym unit for every architecture that derives a tcpu*def/tcpu*sym
class from the base classes, and initialises the c*def/c*sym classes with
them. This is done so that the llvm target will be able to derive from
the tcpu*def/sym classes without umpteen ifdefs, and it also means that
the WPO can devirtualise everything because the c* variables are only
initialised with one class type
o replaced all t*def/t*sym constructor calls with c*def/c*sym constructor
calls
git-svn-id: trunk@27361 -
the availability of the body of a function declared as "inline" no
longer changes the CRC and hence no longer triggers recompilations
(mantis #24121)
git-svn-id: trunk@27192 -
* improved comments for inline argument handling
* replace arguments more aggressively with a copy of their original node tree when inlining
git-svn-id: trunk@26649 -
defcmp.pas:
+ add new function "def_is_related" which combines the "is_related" overloads of "tobjectdef", "trecorddef" and "tstringdef" (it returns "false" for other def types which is what "tdef.is_related" did)
* compare_defs_ext & compatible_childmethod_resultdef: change call from "x.is_related" to "def_is_related(x,...)"
symtype.pas, tdef:
- remove "is_related" method
symdef.pas:
- remove "is_related" in "tobjectdef", "trecorddef" and "tstringdef"
* tobjectdef.needs_inittable: for checking whether a Corba interface somehow inherits from a IInterface don't use "is_related" anymore (we want to avoid the dependency after all), but mimic the necessary functionality of "def_is_related"
htypechk.pas, nadd.pas, ncal.pas, ncnv.pas, ngtcon.pas, nld.pas, optvirt.pas, pdecobj.pas, pdecvar.pas, pexpr.pas, pgenutil.pas:
* change call from "x.is_related" to "def_is_related(x,...)"
symtable.pas
+ use unit defcmp
* change call from "x.is_related" to "def_is_related(x,...)"
jvm/njvmcnv.pas, jvm/njvmflw.pas:
* change call from "x.is_related" to "def_is_related(x,...)"
git-svn-id: trunk@25847 -
e.g. being a const parameter or immutable temp. values), managed types like dyn. arrays, new string types and interfaces can be kept in registers.
git-svn-id: trunk@24953 -
symconst.pas:
+ extend "thelpertype" by "ht_type" which tells the code in "pdecobj.parse_extended_type" that a type helper declaration has been parsed
node.pas:
+ add a constant which identifies all constant node types
ptype.pas:
+ read_named_type: add a parameter "hadtypetoken" to tell the code whether a "type" token had been parsed before
+ read_named_type: if an identifier "helper" is parsed we need to check whether "hadtypetoken" is true and the modeswitch "m_class" is set, but the "m_delphi" one is not; in that case we have a "type helper" declaration
pgenutil.pas, generate_specialization:
* adjust call to read_named_type
pdecl.pas, types_dec:
* adjust call to read_named_type
pdecobj.pas:
* parse_extended_type: extend for correct handling of primitive types (includes Delphi compatible handling as well) and reject types that are explicitly not allowed
* method_dec: require "static" for class methods in type helpers
* method_doc: allow constructors for type helpers as well
paramgr.pas, tparamanager:
* set_common_funcretloc_info: handle type helper constructors like record constructors
* handle_common_ret_in_param: the "self" value of a type helper constructor is also returned in a parameter
pexpr.pas:
+ add a function to postfixoperators which tries to find and apply a type helper for a given type
* postfixoperators: try to apply type helpers for ordinal constants
* postfixoperators: use the correct string type for string constants
* postfixoperators: try to apply type helpers for enum constants
* postfixoperators: try to apply type helpers for arrays
* postfixoperators: try to apply type helpers for Variant
* postfixoperators: try to apply type helpers for pointer types
* postfixoperators: try to apply type helpers for other types
* factor: check postfixoperators after _REALNUMBER, _CCHAR, _CWCHAR, _TRUE and _FALSE
* factor: also check postfixoperators if a _POINT follows a _NIL
symdef.pas, tdefawaresymtablestack.addhelpers:
* use "generate_objectpascal_helper_key" to generate the key
symtable.pas:
+ add function to generate the key value for the map of extended types using the extended def
* adjust "search_last_objectpascal_helper" and "search_objectpascal_helper" to handle primitive types as well
* use the new "generate_objectpascal_helper_key" function to generate the key
pparautl.pas:
* insert_self_and_vmt_para: don't insert the $vmt symbol for record or type helpers (ToDo: check whether class helpers really need the symbol as well)
* insert_self_and_vmt_para: pass "self" as var parameter for type helpers as well
psub.pas, generate_bodyentry_block:
* also allow type helpers for constructor methods
ncal.pas, tcallnode.gen_self_tree:
* also use a temp variable for type helper constructors
ncgcal.pas, tcgcallnode.secondcallparan:
* allow Pointers to be passed as address param if it is the Self value of a type helper extending a pointer type
* correctly handle the location in case of type helper constructors
+ add tests
git-svn-id: trunk@23580 -
they don't have explicit side-effects, and if -Oodeadvalues (part of -O4)
is active (because it can result in the removal of range check errors,
segmentation faults, etc)
git-svn-id: trunk@22254 -
like field reordering (possible problems cracker classes) or using ebp as normal register (broken
stack traces from dump_stack)
+ niln is also valid in a cse domain
* parameters passed by reference shall have a complexity >1
* load nodes from outer scopes shall have a complexity >1
* better cse debugging
+ more node types added to cse
* consider parameters passed by reference in cse
* take care of cse in parameters in simple cases
git-svn-id: trunk@22050 -
procdef, so that the unit containing it is marked as "used" (mantis #15966)
Even better would be if the unit containing the originally found procsym
were not also marked as used, but that would require a significant
rewrite (all symbols found using symboltable helpers are automatically
marked by those routines)
git-svn-id: trunk@21501 -
and also use this code to trash local variables in inlined routines
o fixes mantis #22088
o makes it possible to also implement it for the jvm target in the future
git-svn-id: trunk@21393 -
+ implement trashing of local variables if subroutine is inlined
* fix some errors releated to interproc. gotos and inlining
+ node_count function
* inline cannot be used with iochecking and safecall calling conventions
* track inherited usage
* don't inline if inherited is used
git-svn-id: trunk@21335 -
o support for the new codepage-aware ansistrings in the jvm branch
o empty ansistrings are now always represented by a nil pointer rather than
by an empty string, because an empty string also has a code page which
can confuse code (although this will make ansistrings harder to use
in Java code)
o more string helpers code shared between the general and jvm rtl
o support for indexbyte/word in the jvm rtl (warning: first parameter
is an open array rather than an untyped parameter there, so
indexchar(pcharvar^,10,0) will be equivalent to
indexchar[pcharvar^],10,0) there, which is different from what is
intended; changing it to an untyped parameter wouldn't help though)
o default() support is not yet complete
o calling fpcres is currently broken due to limitations in
sysutils.executeprocess() regarding handling unix quoting and
the compiler using the same command lines for scripts and directly
calling external programs
o compiling the Java compiler currently requires adding ALLOW_WARNINGS=1
to the make command line
git-svn-id: branches/jvmbackend@20887 -
copied before funcretnode because it may contain tempdeletenodes
that turn a temp to "delete on next use", with the use in the
funcretnode)
git-svn-id: branches/jvmbackend@20141 -
(= Android 4.0) java headers: java.*, javax.*, org.*, junit.*, android.*).
The RTL can also be used to target earlier versions of the Android
platform, but you manually have to take care of not using APIs that
weren't available yet. Adding separate units for separate platform
versions would only partly solve the problem, because some of the
classes used inside the system unit have also changed across
versions.
Use -Tandroid while compiling to select the Android OS as target
platform.
git-svn-id: branches/jvmbackend@19830 -
