m68k/aasmcpu.pas, taicpu.spilling_get_operation_type:
* add all Sxx instructions as "operand_write" instructions
m68k/n68kadd.pas, t68kaddnode.getresflags:
* use the correct operation in case of swapped nodes
m68k/cgcpu.pas, tcg68k.g_flags2reg:
- don't move a 0 to the register, because this will CLR it and thus the flags won't be valid anymore...
- NEG would have been the wrong operation (NOT would have been correct), but it isn't needed anyway...
* simplify the method by handling the address register case only when necessary
git-svn-id: trunk@23383 -
- removed a_jmp_cond, it's not virtual and not applicable to this CPU.
* a_loadfpu_reg_cgpara: use direct register moves for simple destinations.
* g_concatcopy: don't take address of source/destination for small amounts of data if possible, for single 32-bit moves this reduces number of generated instructions from 4 to 2.
* g_intf_wrapper: 'Self' is in R4 (a0), not R2. Fixes test/tinterface1.pp.
* mips/cpupara.pas: for functions with result returned in parameter, pass its address in a0 only if result is a record. ABI does not specify behavior for types except records/unions. At the same time, Pascal code relies on the fact that results like strings/interfaces does not change their locations, i.e. "function foo(<self>): IInterface" can be invoked as "procedure foo(<self>, out obj)". This fixes test/tdel1.pp and some Variant-related tests.
git-svn-id: trunk@23377 -
ARM status: roughly corresponds to i386 one, passes the test suite. Handles libraries, can link static libc code including basic PIC and TLS IE/LE stuff. Completely misses Thumb support. Also does not handle ABI-specific stuff, for this reason internally linked .so cannot be used for linking executables with ld. Little-endian only. Tested only on "versatilepb" QEMU virtual machine.
MIPS status: can link the compiler and at least some dynamic executables including fpmake. Some PIC support is present but almost untested. Specific header flags and sections are also not handled yet. Written to handle both endian, but tested for big-endian only ("malta" QEMU VM), including cross-linking from x86_64.
git-svn-id: trunk@23376 -
* For unresolved weak symbols, provide dynamic binding only if they are referenced via GOT or PLT (ld-compatible behavior).
* Made more TElfExeOutput properties/methods usable by descendant classes.
* x86_64/cpuelf.pas: some refactoring, handle DTPOFF relocations, prohibit TPOFF relocations in shared objects.
* i386/cpuelf.pas: set symref_from_text flags for copy relocations to work correctly.
git-svn-id: trunk@23375 -
use the correct flag for the copy loop: we jump back to the copy code as long as the value is positive aka BPL instead of BMI
This fixes around 30 tests (it fixes a quite bit more, but now some other tests seem to be broken...)
git-svn-id: trunk@23373 -
Only referencing data labels from code should change "GOT is needed" property. Writing data labels or referencing them from data should have no effect on it.
git-svn-id: trunk@23363 -
Note: the error messages for incorrect "misstyled" floating point numbers (e.g. "2e10foo") have changed because of this.
scanner.pas, tscannerfile.readtoken:
instead of tokenizing "2.", "2.e10", "2.e+10" and "2.e-10" as "_REALNUMBER" tokenize them as "_INTCONST _POINT", "_INTCONST _POINT _ID", "_INTCONST _POINT _ID _PLUS _INTCONST" "_INTCONST _POINT _ID _PLUS _INTCONST"; tokenizing of normal floating constants is not changed
pexpr.pas:
factor:
* extract the code for creating a new constant floating point from "factor" into a new function "real_const_node_from_pattern"
+ allow the parsing of postfixoperators for integer constants if a "." is encountered
+ postfixoperators: check for a "misstyled" floating point number if an ordinal const (not an enum and not a boolean) is encountered (the code is already partially prepared for type helper support)
+ Added tests
git-svn-id: trunk@23356 -
pdecvar.pas, read_record_fields:
* if the def of the field is a static array then use the array's element def (the final element def if it is a multi dimensional array) to check for whether this is the current record type
+ added tests
git-svn-id: trunk@23352 -
* adjust "is_generic" so that it will really work for true generics only
+ added an analogous method "is_specialization" for specializations
Both methods are not used yet, but this will change in the future...
git-svn-id: trunk@23348 -
pgenutil.pas, generate_specialization:
in case of "assigned(parsedtype)" an ">" could immediately follow (only one type parameter), so don't necessarily expect a type identifier
git-svn-id: trunk@23347 -
pgenutil.pas:
generate_specialization:
+ instead of giving an internal error if "symname" is empty and "tt" is "nil" we now do an error recovery by parsing the specialization parameters and returning an errordef (this happens if the "generic" type before the "<" is not found)
* handle "<>" specially by giving an approbiate error message (both when doing a recovery/parsing a generic and during normal specialization)
parse_generic_parameters:
* set the "block_type" to "bt_type" to be on the safe side
* don't continue with inspecting the def (especially hard typecasting) if the found def is not an "objectdef"
Added tests.
git-svn-id: trunk@23344 -
* If possible, use reference base instead of index, this yields shorter instructions.
* Added comment about offset limits for rip-relative addressing.
- Removed code related to taking threadvar address on win32, it is incorrect because Windows TLS is not directly accessible via segment registers (fs:0x2c points to array of pointers to TLS storages of each module, so at least double indirection is needed).
git-svn-id: trunk@23342 -
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 -
compiles again there (it's possible to take the address of arbitrary
threadvars on the jvm platform, but not of arbitrary other variables)
- disabled inclusion of generic thread manager and threadvar support
on the jvm target if the threading feature is enabled
git-svn-id: trunk@23322 -
