digitalmars.D.bugs - [Issue 19290] New: immutable associative array corruption with -m64
- d-bugmail puremagic.com (43/43) Oct 07 2018 https://issues.dlang.org/show_bug.cgi?id=19290
https://issues.dlang.org/show_bug.cgi?id=19290 Issue ID: 19290 Summary: immutable associative array corruption with -m64 and MinGW Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: critical Priority: P1 Component: dmd Assignee: nobody puremagic.com Reporter: b2.temp gmx.com It seems that a kind of corruption happens in dparse when it's compiled with -m64, lld linker and MinGW. To reproduce save this code in a bat and run it from a console: ``` git clone https://github.com/dlang-community/libdparse.git git clone https://github.com/dlang-community/stdx-allocator.git cd libdparse git checkout v0.9.9 cd .. dmd main.d ^ libdparse\src\std\experimental\lexer.d ^ libdparse\src\dparse\ast.d ^ libdparse\src\dparse\lexer.d ^ libdparse\src\dparse\parser.d ^ libdparse\src\dparse\rollback_allocator.d ^ libdparse\src\dparse\stack_buffer.d ^ stdx-allocator\source\stdx\allocator\package.d ^ stdx-allocator\source\stdx\allocator\mallocator.d ^ stdx-allocator\source\stdx\allocator\gc_allocator.d ^ -Ilibdparse\src -Istdx-allocator\source -m64 -debug main.exe ``` Which gives a range error that didn't happen when using -m32, here : https://github.com/dlang-community/libdparse/blob/95444a966923a24098c31464e09a7096208da155/src/dparse/ast.d#L88 This really shouldn't happen since each possible entry is setup in a static module constructor just above. The problem doesn't happen if the involved assoc array is not immutable, which will be used as workaround for now. (test case wont be affected) --
Oct 07 2018