cs_hugeptr_arithmetic_normalization local setting
+ added the cs_hugeptr_comparison_normalization local setting and corresponding
directive {$HUGEPOINTERCOMPARISONNORMALIZATION} to set it
* the {HUGEPOINTERNORMALIZATION} changed to set both of the huge pointer
normalization settings, according to the specified compiler type ('BORLANDC',
'MICROSOFTC' or 'WATCOMC')
git-svn-id: trunk@28151 -
memory models. Enabled by the new directive {$hugecode on}. The directive is
ignored in the near code memory models. When enabled, it forces each procedure
to be in a separate segment and disables mixing near and far procedures (so
'near' and {$F-} are ignored in this mode). Note that {$hugecode on} does not
count as a different memory model, because you can freely link modules (units)
compiled with {$hugecode on} and {$hugecode off}.
git-svn-id: trunk@27615 -
on the stack, this can be enabled by -OoFORCENOSTACKFRAME. This reduces the required
entry/exit code and makes an extra register available to the compiler. However, since this is
based on an estimation of the required stack size, it might have two drawbacks:
either the stack frame is estimated to big, the program requires a bigger stack than needed
or it is estimated too small, then the compiler throws an internalerror during compilation. These
issues can be overcome as soon as the compiler supports recompiling subroutines if needed.
git-svn-id: trunk@27239 -
+ globtype.pas: add new modeswitch to modeswitch enum and name array
* ptype.pas & pdecobj.pas: check for new modeswitch instead of modeswitch class
* ppu.pas: increase ppu version as we've added a new modeswitch which requires correctly compiled units
* adjusted tests to enabled the modeswitch when necessary
+ added three new tests that check for correct functionality of modeswitch typehelpers
git-svn-id: trunk@26796 -
- all known issues with it are fixed
- the resulting warnings about uninitialized warnings are better than that ones from the old code
- with node dfa in place, stuff like dead store removal, strength reduction and ssa can be finished now
- drawback: with node dfa enabled, the compiler is 2-3% slower, there is still some room for improvement though
git-svn-id: trunk@26165 -
that may trigger JVM bytecode verification errors if they are used
before they are initialised (this includes passing them as a "var"
parameter) + test
* sorted -CT parameters alphabetically and alligned them
git-svn-id: trunk@25387 -
so that code written according to Delphi coding standards can be compiled
into JVM bytecode with routine names conforming to JVM coding standards
git-svn-id: trunk@25385 -
* This should be applicable to i8086 targets as well (but needs testing), by copying changes from i386/cgcpu.pas to i8086/cgcpu.pas and removing "$ifdef i386" lines in cgx86.pas.
git-svn-id: trunk@25224 -
JVM target, since Java bytecode itself has no support for properties and
hence exposing properties to external Java code can only be done through
getters/setters. Use the new parameters to do so:
-CTautogetterprefix=XXX
-CTautosetterprefix=YYY
The getter/setter will get the same visibility as the property. If a
getter/setter with the same naming convention was already specified for a
property and this getter/setter is declared in the same class as the
property, then the visibility of this existing getter/setter is
modified and no new routine is generated.
Newly generated getters/setters are virtual methods, because that is
the only way in Java bytecode to allow redefining these getters/setters
in child classes. However, that also means that using these switches can
change the behvaviour of code, since normally the used property definition
is only determined by the declared type of its associated class instance,
and not by the actual instance type. The compiler will therefore warn when
such an automatically generated getter/setter is overridden by another
automatically generated getter/setter in a child class.
git-svn-id: trunk@22959 -
they don't have explicit side-effects, and if -Oodeadvalues (part of -O4)
is active (because it can result in the removal of range check errors,
segmentation faults, etc)
git-svn-id: trunk@22254 -
like field reordering (possible problems cracker classes) or using ebp as normal register (broken
stack traces from dump_stack)
+ niln is also valid in a cse domain
* parameters passed by reference shall have a complexity >1
* load nodes from outer scopes shall have a complexity >1
* better cse debugging
+ more node types added to cse
* consider parameters passed by reference in cse
* take care of cse in parameters in simple cases
git-svn-id: trunk@22050 -
order to minimise memory losses due to alignment padding. Not yet enabled
by default at any optimization level, but can be (de)activated separately
via -Oo(no)orderfields
o added separate tdef.structalignment method that returns the alignment
of a type when it appears in a record/object/class (factors out
AIX-specific double alignment in structs)
o changed the handling of the offset of a delegate interface
implemented via a field, by taking the field offset on demand
rather than at declaration time (because the ordering optimization
causes the offsets of fields to be unknown until the entire
declaration has been parsed)
git-svn-id: trunk@21947 -
the drawback of this is that get_caller_frame and get_caller_addr might not work
anymore because they make the wrong assumption (i.e. not required by the abi)
that ebp contains always a valid (not necessarily the current) frame pointer
git-svn-id: trunk@21918 -
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 -
