[changed]
- Redims with explicit type will now redim existing dynamic array fields, if one of the same name exists, instead of creating a new local array. This makes Redims with explicit type match the behaviour of typeless Redims and Redims for global arrays.
- Relaxed type checking for procedure pointers and virtual method overrides: Procedures with different signatures can now be treated equal if the signatures are compatible. For example: assignments between a function pointer returning an Integer and one returning a Long won't cause a "suspicious pointer assignment" warning on 32bit anymore.
- -asm intel is now the default for all targets/backends (i.e. the C backend no longer defaults to -asm att). This should make switching between backends less trouble-some, especially with regards to inline ASM.
- The temporary .asm/.c files generated by fbc no longer contain time/date strings. This avoids unnecessary noise (the time/date is essentially always different) when comparing .asm/.c files (e.g. to detect changes in fbc's code generation).

[added]
- __FB_ASM__ intrinsic #define on x86, defined to "intel" or "att" (corresponding to the -asm command line option -- useful for -gen gcc/llvm only)
- fbc -showincludes option (shows #include tree) for debugging of #includes
- Address-of followed by pointer-arithmetic on variables (expressions such as @x+N) will now be turned into offsetted variable accesses, resulting in better generated code
- The results of type-casted function calls can now be ignored, even if it's a non-trivial cast
- Covariant parameters and function results (feature request #289)
- Type aliases for forward-reference type aliases (e.g. "type A as A_ : type B as A" -- previously it was only allowed to alias the forward reference directly: "type A as A_ : type B as A_")
- #761: crt/mem.bi for mem*() functions, separated from crt/string.bi, to allow them to be used together with windows.bi without running into conflicts between crt/string.bi and win/shlwapi.bi
- crt/iconv.bi for using glibc's iconv on GNU/Linux
- crt/regex.bi for using glibc's regex support on GNU/Linux
- crt/pthread.bi for using glibc's pthread support on GNU/Linux
- allegro5 binding: Win32-specific #inclibs supporting the lib naming convention used by Allegro5's Win32 builds
- Bindings (new/updated, including 64bit support):
FastCGI 2.4.1-SNAP-0311112127
Windows API, based on MinGW-w64's headers; DDK not updated yet; for GdiPlus only the flat C API is updated, not the C++ part.
libpng 1.2.53, 1.4.16, 1.5.21, 1.6.16
X11, based on current X.org packages
SDL1: SDL 1.2.15, SDL_image 1.2.12, SDL_mixer 1.2.12, SDL_net 1.2.8, SDL_ttf 2.0.11, SDL_gfx 2.0.13
SDL2: SDL2 2.0.3, SDL2_image 2.0.0, SDL2_mixer 2.0.0, SDL2_net 2.0.0, SDL2_ttf 2.0.12, SDL2_gfx 1.0.1
GNU libiconv 1.14
fontconfig 2.11.1
Allegro 5.0.11
TRE 0.8.0 as tre/tre.bi and tre/regex.bi. For backwards-compatibility, the "plain" regex.bi still exists, but now just redirects to tre/regex.bi.
OpenGL, based on Mesa-3D 10.5.1 (GL/mesa/*) and MinGW-w64 3.3.0 (GL/windows/*). GL/gl.bi & co use the Windows OpenGL binding on Win32/Win64, and the Mesa binding elsewhere.
GLUT 3.7
GLFW 2.7.9 (GL/glfw.bi), 3.1.1 (GLFW/glfw3.bi)
freeglut 3.0.0
Cairo 1.14.2
FreeType 2.5.5
GLib 2.42.2
Pango 1.36.8
ATK 2.14.0
gdk-pixbuf 2.30.8
GTK+ 2.24.27, 3.14.10
GtkGLExt 1.2.0
- The FB makefile now supports "make bootstrap-dist" and "make bootstrap" commands. The former allows packaging the FB sources together with precompiled fbc sources, and the latter allows building FB using those precompiled fbc sources, which is useful on systems that don't have a working fbc yet.

[fixed]
- Potential bad code generation for dynamic array field copying
- C backend: Naked functions could end up in the .data section instead of .text
- Returning a dereferenced constant (such as field>) caused a compiler crash
- 1.00.0 regression: Bad code generation for dynamic array descriptor initialization (and potentially other cases)
- 1.00.0 regression: . member access was allowed on [] pointer indexing expressions even if the type was not an UDT, but a UDT ptr
- Some unsafe pointer assignments between ANY PTRs and non-ANY PTRs with different PTR indirection levels didn't trigger a "suspicious pointer assignment" warning (e.g. ANY PTR PTR = BYTE PTR)
- On 64bit, all number literals with '&' suffix (LONG type) triggered a "too big" warning, even if their value was not really too big.
- #765: insufficient precision on FLT_MAX / DBL_MAX constants in crt/limits.bi
- gfxlib could crash on exit, if Screen[Res] was used in a global/module constructor
- #768: View [Screen] did not clip the given viewport coordinates to the screen properly, if x1/y1 were negative
- 0.90.0 regression: Potential compiler crash with -fpu sse -fpmode fast if the program used sin/cos and contained certain global float constants (such as pi/2)
- 1.00.0 regression: Potential dead-lock in thread-safe runtime library when using file or console I/O functions from multiple threads
- binding: allegro5: Fixed compilation on win32/win64
- Compiler directory layout: The non-standalone (Linux-style) DOS build now uses include/freebas/ and lib/freebas/ if running on DOS, instead of when compiling for DOS. This allows cross-compiling from Linux (or others) to DOS to work again: If on Linux, fbc -target dos will now use the normal include/freebasic/ and lib/freebasic/ directories of the Linux compiler, instead of requiring the 8.3-compatible directories.
- Extern variables were allowed to have mismatching fixed-length string lengths in declaration and definition
- 0.90.0 regression: In -lang qb, using __offsetof() caused a compiler error
- -lang qb's __offsetof() won't truncate the offset to 16 bit anymore
- Unix rtlib: division-by-zero crash on console I/O commands such as Input, if the terminal size couldn't be queried
- Unix rtlib: memory leak in X11 keyboard input handling initialization
- rtlib/gfxlib2: memory leaks of internal thread-specific data (gfxlib's TLS data when using the thread-safe (mt) FB runtime, and all TLS data of the main thread when using the normal (non-mt) FB runtime)
- rtlib: When using Open Scrn, there could be a dangling pointer bug in the internal screen file handle