pass_generate_code to pass_typecheck, so that it's also used by targets
that override pass_generate_code (fixes webtbs/tw16315b for LLVM)
git-svn-id: trunk@35021 -
o separate information for reading and writing, because e.g. in a
try-block, only the writes to local variables and parameters are
volatile (they have to be committed immediately in case the next
instruction causes an exception)
o for now, only references to absolute memory addresses are marked
as volatile
o the volatily information is (should be) properly maintained throughout
all code generators for all archictures with this patch
o no optimizers or other compiler infrastructure uses the volatility
information yet
o this functionality is not (yet) exposed at the language level, it
is only for internal code generator use right now
git-svn-id: trunk@34996 -
modified by applying user alignment settings (so it can be only done for
user-defined data, not not for internally generated data)
o set this option for user-defined data
git-svn-id: trunk@34633 -
instance methods that make use of the internal data builder
functionality so they automatically place all string data in the
same section if possible
git-svn-id: branches/hlcgllvm@30342 -
should be dead-strippable; may imply the creation of a separate section
(on platforms that dead-strip data based on sections), but does not
require it
* replaced all existing tcalo_new_section uses with
tcalo_make_dead_strippable, as that is their meaning/purpose
git-svn-id: branches/hlcgllvm@30335 -
get_final_asmlist() to the constructor, in preparation of supporting the
creation of internal builders for local data that will ignore some of the
irrelevant flags (at creation time)
git-svn-id: branches/hlcgllvm@30334 -
ttai_typedconstbuilder so that it can be overridden by other platforms
* override get_string_symofs() for LLVM and always return 0, as you can't
have labels in the middle of a declaration on that platform
git-svn-id: branches/hlcgllvm@28140 -
to free up space for more ait_* types in taitype (can't have
more than 32 because they have to fit in a small set)
o factored out writing of floating point numbers as an array of
byte in the external assemblers
git-svn-id: branches/hlcgllvm@28105 -
psub.pas: Use new fpc_compiler_has_fixup_jmps conditional.
mips/aasmcpu.pas: MIPS specific fixup_jmps function,
The insttruction distance calculation is not exact as
some pseudo-instruction can be expanded to a variable number of real instructions
real calculation would only be possible if we first
convert pseudo-instuctions to real instructions before calling fixup_jmps.
ncgutil.pas: Revert commit r21791
ncgcon.pas: Revert commit r21786
mips/cgcpu.pas: Partial revert of commit r21798, no need to always use A_J,
as fixup_jmps now handles out of range branches.
git-svn-id: trunk@21822 -
constants on Darwin, because its linker uses global symbols as delimiters
of subsections for dead code stripping. This was previously solved by
never making any ansistring constants smart linkable, which is now
solved
git-svn-id: trunk@21328 -
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 -
- add helper function getansistringcodepage which returns explicitly set codepage or 0 in other case
- add helper function getansistringdef which return a def with explicitly set codepage or cansistringtype in other case
- change tstoreddef.createnai constructor to allow set codepage in constructor
- don't convert string constants to rawbytestring. if string constant already has a codepage - preserve it or convert to ansistring codepage (delphi compatible)
- don't perform string conversion from ansistring to strings with explicitly set codepage (by directive or by compiler switch) and vice versa (delphi compatible)
+ test which covers most of the cases
git-svn-id: trunk@19510 -
- add TTagHashSet class descendant of THashSet with an ability to has also a LongWord value together with key
- change TAsmData.ConstPools[] to be an indexed property to properly initialize ConstPool class, remove pool initialization from all other units
- add ansistring constants to pool together with their encoding to distinct the same text constants with different codepage
+ test
git-svn-id: trunk@19261 -
o sets of enums are handled as JUEnumSet instances, others as JUBitSet
derivatives (both smallsets and varsets, to make interoperability with
Java easier)
o special handling of set constants: these have to be constructed at run
time. In case of constants in the code, create an internal constsym to
represent them. These and regular constsyms are then aliased by an
another internal staticvarsym that is used to initialise them in the
unit initialisation code.
o until they are constructed at run time, set constants are encoded as
constant Java strings (with the characters containing the set bits)
o hlcgobj conversion of tcginnode.pass_generate_code() for the genjumps
part (that's the only part of the generic code that's used by the JVM
target)
o as far as explicit typecasting support is concerned, currently the
following ones are supported (both from/to setdefs): ordinal types,
enums, any other set types (whose size is the same on native targets)
o enum setdefs also emit signatures
o overloading routines for different ordinal set types, or for different
enum set types, is not supported on the JVM target
git-svn-id: branches/jvmbackend@18662 -
only JVM constructs that are already implemented, but also ones that
will be supported in the future but that aren't implemented yet (to
make it easier to already adapt code to the future changes)
git-svn-id: branches/jvmbackend@18498 -
