o the intiialization code of a for-loop used to do that, but no longer
does so since their automatic transformation to a while-loop. Even
though the code did not read the value of the for-loop variable
in case the loop was not entered, the JVM's verifier is not
sophisticated enough to be able to detect that (it's protected by
a boolean set in the loop)
git-svn-id: trunk@34858 -
rtl/inc/systemh.inc & rtl/java/jsystemh_types.inc:
- TEntryInformation: remove WideInitTables
rtl/win/sysosh.inc:
+ TEntyrInformationOS: add WideInitTables
rtl/win/syswin.inc:
* adjust WStrInitTablesTable, so that it is now a pointer and can be used both with direct and indirect main entry
* InitWin32Widestrings: WStrInitTablesTable is now a pointer
rtl/win32/sysinit.inc:
* WideInitTables has moved to the OS specific part of the entry information
rtl/win32/system.pp:
* OsSetupEntryinformation: setup WStrInitTablesTable
git-svn-id: trunk@33571 -
constant: directly encode the character values in the constant, rather
than letting unicodestr_to_chararray handle the conversion (which
implies a codepage conversion)
git-svn-id: trunk@33158 -
o pass length of result array as maximum length instead of that of an empty
string
o the returned length of Utf8ToUnicode() includes a terminating #0 char,
subtract that again when creating a new unicode string with the
characters
git-svn-id: trunk@33157 -
rtl/inc/systemh.inc:
+ TEntryInformation: add Pointer fields ResourceStringTables, ResStrInitTables, WideInitTables (for targets with separate WideString type) and ResLocation (not used on Windows, but since most other targets don't have Windows' resource system it's not part of OS)
rtl/java/jsystemh_types.inc:
+ TEntryInformation: adjust for consistency reasons
rtl/win32/sysinit.inc:
* SysInitEntryInformation: initialize with pointers to the correct tables
git-svn-id: trunk@33027 -
rtl/inc/systemh.inc:
+ add field OS of type TEntryInformationOS if the target specifies HAS_ENTRYINFORMATION_OS
rtl/java/jsystemh_types.inc:
+ same adjustments as above for consistency reasons despite it being not used there anyway
git-svn-id: trunk@33024 -
sizeint" function that returns:
<0: invalid sequence detected after processing "-result" bytes
0: incomplete (may still be valid if MaxLookAhead is increased)
>0: sequence of result bytes forms a codepoint (+ combining diacritical
marks if that parameter was true)
git-svn-id: trunk@30047 -
original routine names are used as they appear in the Pascal code in the
Java byte code -> fixed external reference to fpc_do_exit after r26029
git-svn-id: branches/hlcgllvm@28170 -
Max Nazhalov) and use that code by default on the JVM target
* adapted JVM tests for the new str<->float code similar to how the
generic tests were adapted
git-svn-id: trunk@25954 -
the other fpc_(u)char_to_*str() routines (exception dates back to the
time calls to these routines were still inserted "manually" in the
compiler). Fixes the compilation of "shortstr:=widecharconstant" after
r23613 and simplifies other code calling this helper + test
git-svn-id: branches/cpstrrtl@25428 -
CP_ACP (defaultsystemcodepage), because if all input strings have the
same code page then the result should also have that code page if it's
assigned to a rawbytestring rather than getting defaultsystemcodepage
* do not consider empty strings to determine the code page of the result
in fpc_AnsiStr_Concat_multi(), because that will cause a different
result than when using a sequence of fpc_AnsiStr_Concat() calls (it
ignores empty strings to determine the result code page) and it's also
slower
* do not consider the run time code page of the destination string in
fpc_AnsiStr_Concat(_multi)() because Delphi does not do so either. This
was introduced in r19118, probably to hide another bug
+ test
git-svn-id: branches/cpstrrtl@25143 -
* changed all mappings from CP_ACP to DefaultSystemCodePage to calls to the
new TranslatePlaceholderCP() routine (which also handles CP_OEMCP)
* removed unnecessary CP_ACP adaptations in fpc_AnsiStr_Concat_multi()
for JVM target (now handled in the ansistring to unicodestring conversion
routine)
git-svn-id: branches/cpstrrtl@25091 -
use a single byte API for file system operations
+ FPCRTL_FILESYSTEM_TWO_BYTE_API define that is set for targets where we
use a single byte API for file system operations
o in principle, both can be set if both are supprted and implemented in
the RTL in order to minimise conversions depending on the scenario
git-svn-id: branches/cpstrrtl@24991 -
o resolved conflict in updated morphos sysutils unit
o moved code that had been added to the now deleted sysunix.inc to the
unix-specific block of the fpwidestring unit's init code
git-svn-id: branches/cpstrrtl@24913 -
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 -
and gave it the correct type (TRelocateThreadVarHandler)
* changed parameter type of InitThread also to TRelocateThreadVarHandler
git-svn-id: trunk@23130 -
RTL units. Comes with a FPCRTL_FILESYSTEM_UTF8 define that can be
activated for targets whose single byte filesystem interface enforces
UTF-8; included in inc/systemh.inc and unix/cwstring.pp until now
+ DefaultFileSystemCodePage variable that holds the code page used for
communicating with the OS single byte file system APIs, and for the
strings returned by those same APIs. Initialized with
o the result of GetACP in the system unit of Windows platforms, except for
WinCE which uses UTF-8 since its file system OS API calls already use
the UTF-16 versions
o CP_UTF8 on Unix platforms with FPCRTL_FILESYSTEM_UTF8 defined, and with
DefaultSystemCodePage on other Unix platforms
o DefaultSystemCodePage on Java/Android JVM targets
+ DefaultRTLFileSystemCodePage variable that holds the code page used to
encode strings returned by RTL routines that return filenames obtained
from OS API calls. By default the same as DefaultFileSystemCodePage on
all platforms. Separate from DefaultFileSystemCodePage for clarity on
platforms that may use either utf-16 or single byte OS API calls to
send/receive file names (such as most Windows platforms)
+ new scpFileSystemSingleByte enum that can be passed to
GetStandardCodePage() to get the default code page for OS single byte file
system APIs, with implementations for Unix and Windows
+ SetMultiByteFileSystemCodePage() procedure to override the value of
DefaultFileSystemCodePage
In principle, in the long run unchanged programs only using generic
ansistrings and unicodestrings should (mostly) behave the same as in
FPC 2.6.0 as far as RTL-level file system APIs are concerned if
they set DefaultFileSystemCodePage and DefaultRTLFileSystemCodePage
to DefaultSystemCodePage at the start of their execution
git-svn-id: branches/cpstrrtl@22466 -
+ 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 -
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 -
get_caller_frame, get_caller_addr and dump_stack
with default NIL value to systemh.inc.
+ Added new get_addr function.
system.inc: Use get_addr and get_frame to call
HandleErrorAddrFrame instead of HandleErrorFrame
in several error functions.
Modify dump_stack to use frame and addr parameters.
Provide a dummy get_addr function returning nil.
i386/i386.inc, x86_64./x86_64.inc: Provide real
implementation of get_addr function.
git-svn-id: trunk@21697 -
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 -
compiler/options.pas only defines FPC_HAS_INTERNAL_ABS_LONG for cpus
which support the intrinsic. No need to check again in the rtl.
git-svn-id: trunk@21677 -
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 -
* created separate version of fpc_AnsiStr_Concat_multi() after all
because it contains a punicodechar(unicodestring) typecast, which
can't be supported on the JVM target (and splitting it out in the
generic code seems like a bit overkill), and restored original
generic version of fpc_AnsiStr_Concat_multi() (slightly faster
than version partially adapted for jvm)
git-svn-id: branches/jvmbackend@20903 -
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 -
