Fixes 8535 (#8591)

* Goodbye postInitProc

* Give preInitProc its own scope

Avoid any conflict between the variables introduced by preInitProc and
initProc since both are codegen'd in the same function body.

* Fix codegen for global var init in emulated TLS

Fixes #8535

* Add test for #8535

* Keep a bogus stack frame around

* Remove more dead code
This commit is contained in:
LemonBoy 2018-08-17 00:34:27 +02:00 • committed by Andreas Rumpf
commit ac0f5c83ca
4 changed files with 45 additions and 16 deletions

View file

@ -256,7 +256,15 @@ proc genSingleVar(p: BProc, a: PNode) =
# That's why we are doing the construction inside the preInitProc.
# genObjectInit relies on the C runtime's guarantees that
# global variables will be initialized to zero.
genObjectInit(p.module.preInitProc, cpsInit, v.typ, v.loc, true)
var loc = v.loc
# When the native TLS is unavailable, a global thread-local variable needs
# one more layer of indirection in order to access the TLS block.
# Only do this for complex types that may need a call to `objectInit`
if sfThread in v.flags and emulatedThreadVars(p.config) and
isComplexValueType(v.typ):
initLocExprSingleUse(p.module.preInitProc, vn, loc)
genObjectInit(p.module.preInitProc, cpsInit, v.typ, loc, true)
# Alternative construction using default constructor (which may zeromem):
# if sfImportc notin v.flags: constructLoc(p.module.preInitProc, v.loc)
if sfExportc in v.flags and p.module.g.generatedHeader != nil: