parser: Remove useless NULL check
parser: Refactor common code for type checks when ignoring function results
tests: Fix threadcall test to build on win32 (9f3efc61 regression)
pdflib.bi: Add missing #inclib "gdi32"
Refuse override if function result CONST bits differ
Refuse override if one is a CONST member but the other isn't
tests: Fix tests/image-expr.bas to compile on 64bit (298b2ee1 regression)

CU_ASSERT( p ) doesn't work because it's passing a 64bit pointer to a
32bit LONG which FB currently doesn't allow because it's a smaller integer
data type.
tests: Disable test that would cause SIGFPE on x86-64 (division overflow)
tests: Add missing MOD folding tests
Prevent ICE on signed integer division overflow (SIGFPE) in const folding

Calculating -2147483648 \ -1 = 2147483648 (doesn't fit into 32bit signed
integer) on x86 throws SIGFPE. Same for -9223372036854775808 \ -1 =
9223372036854775808 (doesn't fit into 64bit signed integer) on x86-64.
I'd have expected these divisions to overflow and return 0, but
apparently, that's not happening, on x86/x86-64 at least.

Related to that, -9223372036854775808 \ -1 returns an "incorrect" result
on x86 currently because the LongInt arithmetic doesn't handle this
special case, though (at least) it doesn't throw SIGFPE.

I'm seeing the exact same issues with gcc aswell. (it should be noted that
the C standard doesn't [yet] define the exact behaviour of these divisions)

This commit specifically addresses the issue where fbc itself would crash
due to SIGFPE by doing such divisions during constant folding. This isn't
desirable, and now it shows a warning and produces the value 0, because
that's the result these divisions "should" produce. It's also what I get
from gcc's constant folding.

Working around the x86 instructions' behaviour on a larger scale (i.e. by
emitting extra checks for each division, so it will be "safe" at runtime)
seems wrong, because
  a) it'd add a massive overhead to lot of code (that's also a point
     brought up during discussions about such issues around gcc or
     the C standard)
  b) x86 is what it is, who are we to change that.

Furthermore, this is very similar to the division by zero issue, which we
don't check for at runtime either, but do detect during constant folding.

Reported-by: St_W on IRC
ast: Add astRemoveNoConvCAST() helper
ast: Add astSkipNoConvCAST() helper
Allow byref function pointer call results to be ignored
ast: Make astDumpTree() show FIELD's symbol
ast: Refactor astIsClassOnTree() into astHasSideFx()
Treat PTRCHK/BOUNDCHK as not having side-effects

This makes astHasSideFx() return FALSE for the RTL function CALLs in
PTRCHK/BOUNDCHK (-exx) nodes. Previously, the CALLs included in the
PTRCHK/BOUNDCHK nodes would be seen as side-effect.

An alternative solution may be to not store the CALLs to the RTL functions
in the PTRCHK/BOUNDCHK nodes in the first place, but instead build them
during emitting (in astLoadPTRCHK/BOUNDCHK). That would require storing
the lbound/ubound expressions and line number information in the
PTRCHK/BOUNDCHK nodes though.

In most places in the compiler this would only cause side-effect removal,
which just resulted in less optimal code generation but wasn't a problem
visible to the user.

However, there is 1 place where this makes a visible difference: The
fb.image expression parsing/checking in parser-quirk-gfx.bas,
hCheckFbImageExpr().

For the GET graphics statement, if a udt.array(i) target image expression
is given, it has to clone the array access, because it's passed twice to
fb_GfxGet(): once as target buffer, once for manual bound checking.

This cloning isn't done if the expression contains side-effects though,
because that wouldn't be safe. Instead, an error is shown.

In this one case the use of -exx would cause BOUNDCHK to be added which
caused code to stop compiling because it suddenly seemed to contain
side-effects.

This also prevented the FB test suite from compiling under -exx since the
addition of the fb.image expression parsing tests in 298b2ee16a.
examples: Rename jpeglib example

Compiling jpeg.bas to a library/DLL/.so would produce some libjpeg.* files
confusingly similar to jpeglib's libjpeg.* binaries.

Furthermore, fbc prevents DLLs from linking against themselves, thus it's
impossible to compile a jpeg.bas to a DLL while using libjpeg. fbc always
removes the -ljpeg from the ld command line, thus there will always be
undefined references.
examples: Adjust jpeglib example to work with both fb and fblite dialects
parser-quirk-gfx: Add hUdt2Ptr() helper
parser-quirk-gfx: Rename hTurnNIDXARRAYIntoArrayAccess()