initial import

git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@1 3ad0048d-3df7-0310-abae-a5850022a9f2
  * 2.1.1



git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@5 3ad0048d-3df7-0310-abae-a5850022a9f2
  * post 2.0.0 fixes from cvs



git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@7 3ad0048d-3df7-0310-abae-a5850022a9f2


git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@9 3ad0048d-3df7-0310-abae-a5850022a9f2
  * test fixed


git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@10 3ad0048d-3df7-0310-abae-a5850022a9f2
  * array of const for currency, classes and interfaces fixed


git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@11 3ad0048d-3df7-0310-abae-a5850022a9f2
* format(%u",[<qword>]); fixed
* made test working

git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@13 3ad0048d-3df7-0310-abae-a5850022a9f2
 * Patch from maillist for read() on a file with only a few numerical digits
	in them and no crlf


git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@15 3ad0048d-3df7-0310-abae-a5850022a9f2
  * property svn:eol-style: native set


git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@16 3ad0048d-3df7-0310-abae-a5850022a9f2
  * eol style property in main branch fixed


git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@19 3ad0048d-3df7-0310-abae-a5850022a9f2
  * fixed (currently harmless) error in r21287 that specified that the full
    contents of a procvar had to be loaded in case of a procedure of object
    or nested procvar rather than only the code address (harmless, because
    this code is only active for low level targets currently and since
    r21330 the location's size was used because the source and destination
    types were the same)

git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@21352 3ad0048d-3df7-0310-abae-a5850022a9f2
  * abort if the specified destination file is a directory (mantis #22089)


git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@21355 3ad0048d-3df7-0310-abae-a5850022a9f2
  * CTFrameSetter.pas -> CTFramesetter.pas (fixes installation on
    case-sensitive file systems, mantis #22094)


git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@21356 3ad0048d-3df7-0310-abae-a5850022a9f2
 * more deprecations. Copies of stringtypes usually defined in unit dos, but
   that are no longer needed.


git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@21358 3ad0048d-3df7-0310-abae-a5850022a9f2
 * more removal of deprecated functions (deprecated before 2.4.0)
   old copies of routines in dos, and some shortstring shorthands for fsplit.


git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@21359 3ad0048d-3df7-0310-abae-a5850022a9f2
  * allow default() on Objective-C classes and protocols: the compiler already
    allows it, and they're plain pointer-based types -> nil is fine


git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@21360 3ad0048d-3df7-0310-abae-a5850022a9f2
Allow the usage of a generic's name without type arguments inside of nested classes inside the generic. This fixes Mantis #19499, but also Mantis #18688.

* symtable.pas:
    + add function "get_generic_in_hierarchy_by_name" which returns a def with the name of the symbol in the given object/record hierarchy (useful only in non-Delphi modes)
    + add function "return_specialization_of_generic" which returns the specialization def of a given class inside the given object/record hierarchy
* pexpr.pas, factor, factor_read_id: instead of checking whether the names of the found symbol and the current_structdef are equal, check whether the generic appears in hierarchy of current_structdef
* ptype.pas:
    * id_type: check whether the found symbol is a generic dummy and we are currently parsing a generic then return the correct def of the generic instead of the dummy one
    * single_type: when using the generic type without type parameters the def must resolve to the specialized def when specializing the class instead of the generic def which the dummy symbol points to
    * read_named_type, expr_type: like in "single_type" we need to resolve the use of the parameterless type name to the correct specialization def instead of the generic def
* pdecobj.pas, object_dec: also set the typesym of the current_structdef as otherwise some assumptions about generics with the above mentioned changes aren't valid anymore (like the def the typesym is unset again afterwards)
+ add tests for both bug reports (the one for 19499 is slightly modified so that it does not contain any errors)

git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@21361 3ad0048d-3df7-0310-abae-a5850022a9f2
+ Support assembling expressions ".long L2-L1" where label L1 belongs to the current objsection and L2 comes from any objsection. This is done using relative relocations and is compatible with GNU AS.
* Also fixed ogcoff.pas to handle these relative relocations correctly.

git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@21362 3ad0048d-3df7-0310-abae-a5850022a9f2
* patch by Nico Erfurth:
Reorder unaligned Load sequence on ARM

The old version produced code like that:

ldrb rDEST, [rBASE]
ldrb rTemp, [rBASE, #1]
orr  rDEST, rDEST, rTEMP lsl #8 (2 stall cycles)
ldrb rTemp, [rBASE, #2]
orr  rDEST, rDEST, rTEMP lsl #16 (2 stall cycles)
ldrb rTemp, [rBASE, #3]
orr  rDEST, rDEST, rTEMP lsl #24 (2 stall cycles)

This creates a lot of stall-cycles on ARM Implementations with load
delay slots like Marvel Kirkwood or Intel XScale. With the usual up to 2
stall-cycles this code requires a total of 13 cycles (7 instructions + 6 stall
cycles) in best case.

The new code uses a second temp register to avoid the stall cycles.

ldrb rDEST, [rBASE]
ldrb rTemp1, [rBASE, #1]
ldrb rTemp2, [rBASE, #2]
orr  rDEST, rDEST, rTEMP1 lsl #8
ldrb rTemp1, [rBASE, #3]
orr  rDEST, rDEST, rTEMP2 lsl #16
orr  rDEST, rDEST, rTEMP1 lsl #24 (1 stall cycle)

The rescheduling and second register bring the total cycles down to 8.
If a later rescheduling should happen for the last orr it even can go
down to 7.



git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@21363 3ad0048d-3df7-0310-abae-a5850022a9f2
 * Patch from Ludo Brands implementing TCustomBufdataset.lookup
   Mantis #22099


git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@21364 3ad0048d-3df7-0310-abae-a5850022a9f2