+ CPUARM_HAS_BX is defined if the CPU supports the BX* instruction
+ CPUARM_HAS_REV is defined if the CPU supports the REV instruction. Note that you still have to check for compiler versions > 2.6.0 since the assembler reader of 2.6.0 does not understand that instruction.
+ CPUARM_HAS_IDIV is defined if the CPU supports the sdiv, udiv instructions. Use of this fixes a bug where previously these instruction were only used for armv7-m, while cortex3m cpus also support it.
+ CPUARM_HAS_LDREX is defined if the CPU supports the ldrex/strex instructions. Use of this fixes a bug with armv7(-a) cpus where this path has not been used.
+ SYSTEM_HAS_KUSER_CMPXCHG is defined if the system (mainly OS) support the kuser_cmpxchg functions. Use of this fixes a bug where ARMHF systems did not use it for synchronization (although ARMHF is armv7+ only, i.e. the LDREX path is used anyway)
git-svn-id: trunk@22081 -
default value (mantis #22343)
* give an error when specifying an invalid default value (e.g. a
floating point number for a longint parameter)
git-svn-id: trunk@22021 -
* check "A op B" and "B op A" again for operators that can be commutative (all binary ones except shl, shr, div, mod, **, / and -)
* also check for Nil for classrefdefs if left side is a pointer (allows "TClass var" <>/= Nil again, after the above changes)
* don't allow overloads for "implicit pointer type <>/= pointer" and the other way around (this fixes non compiling Objective Pascal test tobjc21.pp and also the new toperator87.pp test)
* some formating corrections
+ added test for "TObject <> Pointer"
+ added test for "TClass <>/= Nil"
git-svn-id: trunk@21983 -
The changes are built up in a way that all operators on two given types are not allowed if a default implementation for that operator exists. This implies that there is a possibility to have a overload work for (in this order) type A and B, but not for B and A. This is for example the case for Set + Enum (which seems to have a default implementation) where Enum + Set is allowed. The added tests try to detect as many default implementations as feasible, but can't cover everything...
git-svn-id: trunk@21975 -
hierarchies from other units that were compiled without debug information
in case not all classes from the hierarchy are explicitly used
(mantis #22495, #21503, #21259)
git-svn-id: trunk@21972 -
overflow (don't know what the y-coordinate is at that point, because the
window may be wider than the artificial screenwidth) (mantis #20880)
git-svn-id: trunk@21925 -
symtable.pas, searchsym_in_class:
* if we found a helper method that has overload defined we should not forget the symbol as there can be a case that no method with that name is defined in the extended class hierarchy
symtable.pas, searchsym_in_record:
* analogous to the above
+ added test given in the issue
+ added analogous test for record helpers
git-svn-id: trunk@21764 -
This fixes 64bit shifts on arm with a constant shift value of 0.
The old code would have emitted something like this
mov r0, r0, lsl #32
as 32 is an invalid shift value (and would be wrong anyway) the
assembler declined to assemble the produced source.
The new code will just not emit any code for a shift value of 0.
tests/test/tint642.pp now tests shl/shr 0 on 64 bit values.
tests/webtbs/tw22326.pp is also added as an additional test.
git-svn-id: trunk@21746 -
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 -
fist(t)pq instructions (mantis #22331)
* also internalerror in case the internal fpu stack position counter
becomes larger than 7, so we don't have to wait for the entire
byte to overflow before we detect a problem
git-svn-id: trunk@21734 -
* ptype.pas, read_named_type, array_dec:
allow border checks if both range elements are orddefs; for normal arrays
using e.g. "0..15" this will allow to declare the correct amount of
elements in the initialization while for generic arrays (e.g. "0..SizeOf(T)")
this will mean that only one element can be declared, which was already the
case before this change (maybe in such cases a constant initialization should
be forbidden in the future...)
+ added test
git-svn-id: trunk@21690 -
ptype.pas:
* read_named_type:
allow specializations for pointers in Delphi modes
* single_type:
correctly handle forwarddefs; as we can only specialize generics if
they are completely defined (srsym<>nil) we don't need to return a
forward def, but instead return the specialized def itself
+ added tests to "test" instead of "webtbs" as no explicit tests were given
in the report
git-svn-id: trunk@21689 -
ptype.pas:
* read_named_type:
after reading the type we're pointing to we need to make sure that
we didn't get a generic dummy symbol; this can happen when parsing
a pointer declaration as the type in a constant or variable
declaration
* resolve_forward_types:
when resolving forward types we need to make sure that we weren't
given a generic dummy to which no non-generic definition was
given (possible in Delphi mode); for non-Delphi modes we can not
rely on the generic dummy flag as the typedef of the symbol will
the generic def
+ added test from the bug reports as well as three additional ones to
make sure that nothing breaks regarding to forward pointer
declarations
git-svn-id: trunk@21687 -
* pgenutil.pas: factor out the reading of generic specialization parameters (parse_generic_specialization_types) and the generation of a generic type name (generate_generic_name)
* pdecsub.pas, parse_proc_head:
* also allow an interface alias declaration if an identifier is followed by a "<" (which starts a specialization)
+ add a procedure "consume_generic_interface" which parses such a specialization (by using "parse_generic_specialization_types") - this is needed, because "consume_generic_type_parameter" can (and should not!) handle "ISomeIntf<Integer, T>" or (somewhen in the future) "ISomeIntf<TSomeOtherGeneric<T>>" - and finds the correct symbol for the interface (by utilizing the "generate_generic_name" function)
* generate the correct mapping entry (for the generic it's only needed for checking (if any), but for a specialization it's essential that we reference the correct specialization)
+ add tests which were included with the issue and also two additional ones
Note: In non-Delphi modes an interface alias can be done like in Delphi mode; "specialization" is not necessary and furthermore not even allowed!
git-svn-id: trunk@21656 -
* pscanner.pas: change SizeInt to ASizeInt for tokenreadsizeint and tokenwritesizeint and change necessary other locations for record- and replaytokenbuffers
+ Added a test in the hope that some test-platforms do cross platform (e.g. win32 => win64) compilation.
git-svn-id: trunk@21651 -
* pparautl.pas, insert_funcret_para:
assume that the result in a generic function/method can not be passed in a param
* pparautl.pas, insert_funcret_local:
don't call ret_in_param, but create the symbol as we need a valid funcretsym
* pstatmnt.pas, assembler_block:
don't modify the framepointer for a generic method/function
* rautils.pas, TOperand.SetupResult:
don't assume that we can't use the result for a generic function/method
git-svn-id: trunk@21608 -
+ pgenutil.pas:
add a procedure which adds a type symbol to a non-Delphi-mode generic class or record which has the same name as the unit global dummy symbol for that generic. I don't know why I had that idea earlier as this will simplify some of the conditions in the parser again (I haven't changed these yet, but I hope to do that at least when I start working on generic functions).
* pgenutil.pas, generate_specialization:
correctly handle "specialize TSomeGeneric<T>" as method parameter in a generic with the newly added rename symbol
* pdecobj.pas, object_dec & ptype.pas, record_dec:
call the procedure to add the rename symbol (the procedure checks whether the mode is correct)
* ppu.pas:
increase PPU version so that we don't use non-Delphi mode units with generics, but without the rename symbol
+ added tests:
the one in webtbs are for classes/objects and those in test are for records
git-svn-id: trunk@21603 -
* pdecsub.pas, parse_proc_dec & pdecobj.pas, constructor_head:
correctly set the return type of the constructor of a class helper to the extended def
* psub.pas, generate_bodyentry_block:
call the NEWINSTANCE of the extended class for constructors of class helpers
git-svn-id: trunk@21582 -
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 -
