labels of LOC_JUMP in the node's location. This generates some extra jumps
for short circuit boolean and/or-expressions if optimizations are off, but
with optimisations enabled the generated code is the same (except for JVM
because the jump threading optimisation isn't enabled there yet).
git-svn-id: trunk@31431 -
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 -
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 -
* create separate nodes for Objective-C in tloadvmtaddrnode.pass_1
instead of implicitly relying on the fact that the Objective-C
ISA field is at the same offset as the VMT of Object-Pascal
classes
o translate the resulting loads of ISA field into direct pointer
accesses, so that even on non-fragile ABI platforms we don't
go via an indirection (like clang/gcc)
git-svn-id: trunk@30947 -
case a record contains an internal typed constant of its own type
(which happened becuase such a typed constant is also fieldvarsym, solved
by checking for sp_static) (mantis #27880)
* fixed several other similar cases in the compiler where we are only
interested in instance fields, but processed all fieldvarsyms
git-svn-id: trunk@30614 -
first java bytecode of a method, because when using javac for code
completion (as done by NetBeans), it assumes that all variable debug info
associated with the first byte code is for parameters. Furthermore, this
code in javac contains a range error when a lot of extra "parameters" are
declared this way, so it used to crash in some cases.
git-svn-id: trunk@29301 -
be included at the start of the implementation of the system unit (before
the rest of except.inc)
* catch declarations in/loading from the system unit of the TExceptAddr type
* use this type instead of hardcoded size constants in the compiler
* in generic code that is active for all targets, puts its use in a virtual
method since it's only valid for targets using setjmp/longjmp-style
exception handling (and the record is not defined at all in the JVM RTL)
git-svn-id: branches/hlcgllvm@28376 -
This is useful if you want to change the calling convention of the copy.
o call insert_funcret_para() after creating a bare copy
* don't copy aliasnames of copied procdefs either (can at best result
in duplicate symbol errors)
git-svn-id: trunk@28227 -
o only create an accessor wrapping the inherited accessor at a
potentially lower visibility level if the overriding property
itself does not specify a different accessor to use
o simplified code
o tests
git-svn-id: trunk@27954 -
existing getter setter (at a different visibility level) with a different
name, since the new one will have a unique name and not override anything
else
git-svn-id: trunk@27953 -
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 -
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 high level code generator. All hlcg code, except for the jvm code
generator, updated to use the new method. I didn't update jvm (it still uses
the method from cgutils), because I'm not familiar with that platform, so I
might get the types wrong.
git-svn-id: trunk@27309 -
required for the LLVM support (LLVM parameter support is not yet
included)
* always return the function return loc from a_call*, again as required
for the LLVM support
git-svn-id: branches/hlcgllvm@26992 -
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 -
cgobj.pas, tcg:
* g_save_registers: add the amount of used address registers to size as well
* g_save_registers: save all used address registers
* g_restore_registers: restore all stored address registers
m68k/cpubase.pas:
* rename saved_standard_address_registers to saved_address_registers
all other platform's cpubase.{inc,pas} (except alpha, ia64 and vis which are not up to date):
* add a saved_address_registers variable with one entry of RS_INVALID
At least a "make fullcycle" did complete.
git-svn-id: trunk@25664 -
(we previously internally generated assigned(unicode/ansistring) nodes,
which now cause typecheck errors because there is no special assigned
handling anymore)
git-svn-id: trunk@25557 -
that may trigger JVM bytecode verification errors if they are used
before they are initialised (this includes passing them as a "var"
parameter) + test
* sorted -CT parameters alphabetically and alligned them
git-svn-id: trunk@25387 -
a property in a child class has a higher visibility than the getter/
setter), ensure that we call the inherited method and not the method
itself (causing a stack overflow due to infinite recursion)
git-svn-id: trunk@25223 -
have to wrap an existing (g|s)etter that was marked as "abstract" (don't
mark the helper also as abstract, sicnce it contains code)
git-svn-id: trunk@23545 -
its property in case the visibility of the property is higher than
that of the getter/setter (on the JVM target when automatically
generating getters/setters)
git-svn-id: trunk@23523 -
that the type of the parameters can be determined automatically
o added compilerproc declarations for all helpers called in the compiler
via their assembler name, so we can look up the corresponding procdef
git-svn-id: trunk@23325 -
JVM target, since Java bytecode itself has no support for properties and
hence exposing properties to external Java code can only be done through
getters/setters. Use the new parameters to do so:
-CTautogetterprefix=XXX
-CTautosetterprefix=YYY
The getter/setter will get the same visibility as the property. If a
getter/setter with the same naming convention was already specified for a
property and this getter/setter is declared in the same class as the
property, then the visibility of this existing getter/setter is
modified and no new routine is generated.
Newly generated getters/setters are virtual methods, because that is
the only way in Java bytecode to allow redefining these getters/setters
in child classes. However, that also means that using these switches can
change the behvaviour of code, since normally the used property definition
is only determined by the declared type of its associated class instance,
and not by the actual instance type. The compiler will therefore warn when
such an automatically generated getter/setter is overridden by another
automatically generated getter/setter in a child class.
git-svn-id: trunk@22959 -
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 -
used across multiple levels of inheritance such as on MIPS (and the code
has to be reusable for a_call_ref/reeg in the future anyway)
git-svn-id: trunk@21906 -
defines INTERNAL_BACKTRACE (which assumes get_frame to be internal rather
than a system unit procedure)
* changed fpc_assert() declaration for jvm to be the same as for other
targets, so the same code can be used to call it in ninl now that's
called from the first pass
git-svn-id: trunk@21903 -
result location (NR_FUNCTION_RESULT_REG is not valid on all platforms)
o this requires passing the forced function result type (if any) to this
method
o a generic, basic thlcg.a_call_name() is now available that sets the
function result location; can be called by descendants
* the availability under all circumstances of the correct function return
type enables g_call_system_proc() on the JVM platform to now determine
by itself how many stack slots are removed by the call -> do so, instead
of manually counting them (or forgetting to do so and messing up the
maximum evaluation stack height calculations)
git-svn-id: trunk@21862 -
with the enum instance corresponding to ordinal 0 in JVM constructors,
because a virtual method called by a parent constructor may already
have assigned a different value (see tests/test/jvm/tenum2.pp). This
will result in null pointer exceptions when using such fields without
first explicitly assigning a value to them though.
The old behaviour can be restored with the new -CTenumfieldinit command
line parameter
git-svn-id: trunk@21736 -
getintparaloc + adapted all call sites of getintparaloc. This
led to a number of additional, related changes:
o corrected the type information for some getintparaloc parameters
o don't allocate some intparalocs in cases they aren't used
o changed "const tvardata" parameter into "constref tvardata" for
fpc_variant_copy_overwrite to make pass-by-reference semantics
explicit
o moved a number of routines that now have to call find_system_type()
from cgobj to hlcgobj so that cgobj doesn't have to start depending
on the symtable unit
o added versions of the cpureg alloc/dealloc methods to hlcgobj that
call through to their cgobj counter parts, so we can call save/restore
the cpu registers before/after calling system helpers from hlcgobj
(not implemented in hlcgobj itself, because all basic register
allocator functionality is still part of cgobj/cgcpu)
git-svn-id: trunk@21696 -
RS_INVALID superregister (instead of sometimes RS_NO and sometimes
RS_INVALID)
* check for RS_INVALID in tcg.g_save_registers() and ignore such entries
git-svn-id: trunk@21622 -
methods that don't have to be implemented by targets using the high
level code generator, with dummy implementations that raise an internal
error (to remove warnings about instantiating classes with abstract
methods)
* let the JVM tcg descendent derive from this new thlbasecgcpu class
git-svn-id: trunk@21098 -
ansistrings are represented by nil
* fixed type conversion of constant empty ansistring/unicodestring to
pchar/pwidechar on the JVM target
git-svn-id: branches/jvmbackend@21055 -
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 -
class before its VMT has been built, because that's the process that looks
for inherited abstract methods that are overridden -> instead use a new
synthetic method kind (tsk_callthrough_nonabstract) that will call
through to another method (in this case a constructor) if the owning
class does not contain any abstract methods, and generates an
empty routine otherwise
git-svn-id: branches/jvmbackend@20589 -
constructors (simply do nothing), because creating an abstract class
is not possible in the JVM (and while the JVM only triggers an
exception when you actually execute code that tries to create an
abstract class, the Android platform checks this using the bytecode
verifier at class verification time and therefore stumbled over the
old code)
git-svn-id: branches/jvmbackend@20547 -
on Dalvik, because those values are obtained via an "and 255" operation
which again turns them into longint values as var as the Dalvik type
system is concerned
git-svn-id: branches/jvmbackend@20527 -
to correctly handle non-pasbool types (can't just "not" their value),
and for Dalvik (a "not pasbool" became "xori 1", which turned the value
from a boolean into an integer as far as the Dalvik type checker was
concerned)
git-svn-id: branches/jvmbackend@20525 -
after an 8/16 bit operation on Dalvik (even if the value cannot have
become too big), because otherwise its type checker complains
git-svn-id: branches/jvmbackend@20520 -
their upper bound is lower than 127/32767: not necessary, and in case
of booleans not even allowed for Dalvik (because the "and" operation
turns the boolean into an integer as far as Dalvik is concerned)
git-svn-id: branches/jvmbackend@19825 -
classes, interfaces, dynamic arrays, ...) as "array of JLObject",
but instead as an array of the actual pointed-to type. The reason
for the previous behaviour was mainly that the JVM threadvar
implementation internally stores all threadvars that are
such double pointer types into an "array of JLObject". Type casting
this array to e.g. an "array of array of byte" causes an exception
even if it only contains "array of byte" instances (since the outer
array type is different). This is now solved by first taking the
element of the array and then typecasting it to the destination
type (so dynarrbyte(arr[0]) instead of pdynarrbyte(arr)^[0]).
The reason for the new (more accurate) behaviour is because the
old one caused type errors in case a double pointer field was
internally created for the nestedfpstruct support (see added
test)
git-svn-id: branches/jvmbackend@19821 -
verifier when -Cpjvmdalvik is used (including debug information). Using
-Cpjvmdalvik changes the semantics at the language-level in one case:
boolean(bytevar) will no longer return a boolean that contains the same
value as bytevar did, but will map the value to 0/1 (that also means that
such expressions cannot be passed to var-parameters in case of
-Cpjvmdalvik). Code compiled with -Cpjvmdalvik will also work fine on
the regular JVM, but it may be somewhat slower (it won't necessarily
be slower on Dalvik, because the .class -> .dex transformation
applies many optimizations itself)
git-svn-id: branches/jvmbackend@19743 -
those are also supported by the Java language (intftype.class) and required
in equivalent Pascal expressions (such as JLClass(intftype))
git-svn-id: branches/jvmbackend@19742 -
implicit pointer types into the nestedfpstruct, so that the original
parameter is properly changed when updated from inside nested routines
git-svn-id: branches/jvmbackend@19645 -
+ -CTcompactintarrayinit command line option to change the code generation
for typed array of some kind of integer-type initialization so that it
takes up less space in the bytecode (because the bytecode for all
routines, including the class initialization code that contains the
typed constant init code, is limited 64kb, large array or multiple
array constants could fairly easily bump into that limit)
git-svn-id: branches/jvmbackend@19638 -
set the external name of the underlying class type to the internal name
instead of to an (invalid) empty string
git-svn-id: branches/jvmbackend@19555 -
are used to implement procvar types, and add a constructor to the procvar
types that accept an instance implementing this interface -> much easier
and more natural to use procvar types from Java code
git-svn-id: branches/jvmbackend@19216 -
var-parameters on the JVM target for changes to the value passed
as var-parameter during the function call (because they are handled
via copy-in/copy-out, this may indicate unexpected bahviour later on).
out-parameters are checked in the same way, except if the out-parameter
is a local variable because then reading it before the call may result
in a bytecode verification error (since the variable may not yet be
initialized)
git-svn-id: branches/jvmbackend@19153 -
on the JVM target, because the generated code was invalid and I can't think
of a generic way to solve it (see added comments in njvmcal.pas)
git-svn-id: branches/jvmbackend@19055 -
o don't try to create .class files for generic types
o still generate all JVM-specific wrappers for generic types even though they
won't be written out, because when specializing all the defid's have to
match exactly
o add synthetic routine implementations after generating the specializations,
so that the synthetic routines for those specializations are also generated
(we don't specialize generic versions of the synthetic generic routines
because it's not easy or even always possible to create valid generic
versions of synthetic routines)
o Note: these are Pascal-style generics, not Java-style generics. The generic
types nor their specializations are usable from Java code (specializations
may become usable in the future)
git-svn-id: branches/jvmbackend@19047 -
to and returning them from sub routines, in order to follow the JVM
specs to the letter (not checked by the JVM bytecode verifiers, but
checked by the Android DEX verifier)
* -> also zero-extend them again at the caller side after returning
from such a function
git-svn-id: branches/jvmbackend@18919 -
required based on the source/destination sizes (like in
a_load_reg_reg(), a_load_ref_reg() and a_load_ref_ref())
git-svn-id: branches/jvmbackend@18918 -
complex parameters passed to inlined routines on the JVM target, because
it is not possible to take the address of any kind of node on the JVM
target (temp-reference nodes work for any kind of LOC_(C)REFERENCE, but
are currently only implemented for the JVM platform)
git-svn-id: branches/jvmbackend@18905 -
