Fixes Bug #19 - error: non-trivial conversion.
ARM EH fixes.
More ARM EH fixes.
Rename TARGET_ANDROID macro

GCC sometimes defines it's own TARGET_ANDROID macro which
evaluates to a runtime expression so we can't use it.
Rename our TARGET_ANDROID TARGET_ANDROID_D to avoid clashes
Merge pull request #36 from jpf91/fixAndroid

Rename TARGET_ANDROID macro
update to new vector API in GCC
Merge pull request #40 from lomereiter/new_gcc_vec_api

update to new vector API in GCC
Make it harder for gcc to make wrong optimisations.
Split out toCtype, toElem, toIR.
Remove from d-glue.cc, update Makefile.
Update patches for latest gcc snapshot
Use gcc's config system for predefined CPU versions

* Also fix definition of D_LP64
Merge pull request #46 from jpf91/versym

Use gcc's config system for predefined CPU versions
Remove STRUCTTHISREF and SARRAYVALUE macros.
Use gcc's config system for predefined OS versions
Functions in templates may still need a static chain

isnested==false for a template instance only means that the template
instance does not have nested parameters from the instantiation
scope (e.g. alias parameters). But it can still use variables from
it's declaration scope.
So we can only assume that a function in a template doesn't need
a static chain if we additionally check that the template's
parent is a module.
Nested structs may need static chains as well

The old code only checked for nested classes, but nested structs
may also need a static chain. Also a nested chain must propagate
through template instances.
Must handle 'degenerate closures'

Those are constructs that would need to be closures if they had escaped
local variables. As they don't escape local variables we can save the
frame pointer and don't need to make them a real closure. At the same
time we can never set a static chain for those functions as they can
be called from outside.
Implement getVThis for nested structs
Merge pull request #49 from jpf91/fixVThis

Implement getVThis for nested structs