constant is outside the range of type bounds of the left expression.
I.e. "if a>0" evaluates to true if a is declared with type 1..10,
as all legal values of a are greater than zero.
git-svn-id: trunk@7603 -
files with debuginfo but without any code could mess up the symbol
tables used/built by gdb, resulting in various problems when debugging.
The same workaround is used in gcc by Apple (mantis #9011)
git-svn-id: trunk@7597 -
It is done in the following way:
When unit is compiled, .rc file are compiled to .res and list of unit's resource files is stored in .ppu
Before final linking all program's .res files are collected into global .res file (.res files are easily concatenated).
Then this global .res files is compiled to single .or file, which is linked to executable.
As a result global resource index is created and the problem is fixed.
Old resource processing behavior still supported when tresinfo.rcbin is not set for target.
New resource processing is activated for windows and linux. Cross compiled windres can be used to compile .rc files on linux.
git-svn-id: trunk@7515 -
of parent procedures which are implicitly accessed from within
nested procedures for range checking purposes as non-regable in
the resulttype pass of the nested procedure (as opposed to in its
pass1/pass2, because by then the regvar assignment of the parent
procedure is already finished) (mantis #8975)
* related fix regarding checking whether the high parameter actually
exists (must check calling convention of the procedure to which the
high parameter belongs, which is not the same as checking that of
the current procedure in case of nested procedures)
git-svn-id: trunk@7512 -
* new set_current_module function that sets the current_module and
all related variables. Also closes scanner files if required, but
that might still need some optimization to prevent closing/opening
files too often
git-svn-id: trunk@7428 -
different from the native size, or when reading enums (because those
are handled via a temp internally -> regular var parameter checks
were not automatically performed)
git-svn-id: trunk@7398 -
* varsets ({$packset x}) are now supported on big endian targets
* gdb now displays sets properly on big endian systems
* cleanup of generic set code (in, include/exclude, helpers), all
based on "bitpacked array[] of 0..1" now
* there are no helpers available yet to convert sets from the old to
the new format, because the set format will change again slightly
in the near future (so that e.g. a set of 24..31 will be stored in
1 byte), and creating two classes of set conversion helpers would
confuse things (i.e., it's not recommended to use trunk currently for
programs which load sets stored to disk by big endian programs compiled
by previous FPC versions)
* cross-endian compiling has been tested and still works, but one case
is not supported: compiling a compiler for a different endianess
using a starting compiler from before the current revision (so first
cycle natively, and then use the newly created compiler to create a
cross-compiler)
git-svn-id: trunk@7395 -
