`to!string` on `string[]` seems to cause a memory error in pinholeopt ```test.d module test; import std.conv; class Foo { static string staticString; static void test(string[] a){ staticString = to!string(a); } } void main() { Foo.test([""]); } ``` ``` valgrind dmd test.d ``` > ==1171031== Memcheck, a memory error detector > ==1171031== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==1171031== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info > ==1171031== Command: dmd test.d > ==1171031== > ==1171031== Conditional jump or move depends on uninitialised value(s) > ==1171031== at 0x4D2D65: pinholeopt(code*, block*) (in /usr/bin/dmd) > ==1171031== by 0x509930: codgen(Symbol*) (in /usr/bin/dmd) > ==1171031== by 0x550BAA: writefunc2(Symbol*) (in /usr/bin/dmd) > ==1171031== by 0x550487: writefunc(Symbol*) (in /usr/bin/dmd) > ==1171031== by 0x249186: FuncDeclaration_toObjFile(FuncDeclaration*, bool) > (in /usr/bin/dmd) > ==1171031== by 0x250360: toObjFile::ToObjFile::visit(TemplateInstance*) (in > /usr/bin/dmd) > ==1171031== by 0x2748F1: genObjFile(Module*, bool) (in /usr/bin/dmd) > ==1171031== by 0x273A49: _D3dmd4glue20generateCodeAndWriteFACQBi7dmodule6ModuleAPxaAxaQdbbbbbZv (in /usr/bin/dmd) > ==1171031== by 0x46D6E5: _D3dmd4mars7tryMainFmPPxaKSQz7globals5ParamZi (in > /usr/bin/dmd) > ==1171031== by 0x4748FD: _Dmain (in /usr/bin/dmd) > ==1171031== by 0x5A1587: _D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZv > (in /usr/bin/dmd) > ==1171031== by 0x5A1484: _d_run_main2 (in /usr/bin/dmd) > ==1171031== > ==1171031== > ==1171031== HEAP SUMMARY: > ==1171031== in use at exit: 132,007,920 bytes in 177,642 blocks > ==1171031== total heap usage: 230,785 allocs, 53,143 frees, 140,442,533 bytes allocated > ==1171031== > ==1171031== LEAK SUMMARY: > ==1171031== definitely lost: 1,941,960 bytes in 31,054 blocks > ==1171031== indirectly lost: 742,311 bytes in 23,006 blocks > ==1171031== possibly lost: 8,142,415 bytes in 8,665 blocks > ==1171031== still reachable: 121,181,234 bytes in 114,917 blocks > ==1171031== of which reachable via heuristic: > ==1171031== multipleinheritance: 17,824,704 bytes in 17 blocks > ==1171031== suppressed: 0 bytes in 0 blocks > ==1171031== Rerun with --leak-check=full to see details of leaked memory > ==1171031== > ==1171031== Use --track-origins=yes to see where uninitialised values come from > ==1171031== For lists of detected and suppressed errors, rerun with: -s > ==1171031== ERROR SUMMARY: 12 errors from 1 contexts (suppressed: 0 from 0)
I can find plenty of other repro, e.g ``` module runnable; import std.random : uniform; void main(string[] args) { uniform(2000, 5000); } ``` exposes the same memory error.
bt for dmd-debug: --- Conditional jump or move depends on uninitialised value(s) ==1183775== at 0x8EE36E: pinholeopt(code*, block*) (cod3.d:5761) ==1183775== by 0x8B987F: codgen(Symbol*) (cgcod.d:435) ==1183775== by 0x86CD0E: writefunc2(Symbol*) (out.d:1479) ==1183775== by 0x86C5E6: writefunc(Symbol*) (out.d:1137) ==1183775== by 0x80EB01: FuncDeclaration_toObjFile(FuncDeclaration*, bool) (glue.d:1185) ==1183775== by 0x826EA9: toObjFile::ToObjFile::visit(FuncDeclaration*) (toobj.d:315) ==1183775== by 0x733F45: FuncDeclaration::accept(Visitor*) (func.d:2882) ==1183775== by 0x828045: _D3dmd5toobj9toObjFileRCQw7dsymbol7DsymbolbZ9ToObjFile5visitMRCQCj9dtemplate16TemplateInstanceZ__T9__lambda2TQDiZQpMFQDqZv (toobj.d:838) ==1183775== by 0x6AECEF: _D3dmd7dsymbol14foreachDsymbolFPSQBf4root5array__T5ArrayTCQCeQCd7DsymbolZQxMDFQvZvZv (dsymbol.d:105) ==1183775== by 0x82801E: toObjFile::ToObjFile::visit(TemplateInstance*) (toobj.d:838) ==1183775== by 0x6DCA55: TemplateInstance::accept(Visitor*) (dtemplate.d:7504) ==1183775== by 0x826E10: toObjFile(Dsymbol*, bool) (toobj.d:1019) ---
the line indicated by the debuginfos does not give variables that are void-initialized. I suspect that the real problem comes from bootstraping. The backend would generate bad code for itself at this specific place.
(In reply to Basile-z from comment #3) > the line indicated by the debuginfos does not give variables that are > void-initialized. I suspect that the real problem comes from bootstraping. > The backend would generate bad code for itself at this specific place. What host compiler are you using? Also, can you reproduce this without Phobos imports?
host compiler : v2.098.0 I have not tried to reproduce without Phobos for now.
Created attachment 1852 [details] fix minimal reproducer uint fn(uint a) { return 1 / a; } compile: valgrind dmd -O -c test.d with "--track-origins=yes", valgrind also prints what function the uninitialized data comes from ==17569== Uninitialised value was created by a stack allocation ==17569== at 0x70AADF: cddiv(CodeBuilder&, elem*, unsigned int*) (cod2.d:1298) there was a void-initialized struct there, the patch fixes this by initializing the field that was checked at "cod3.d:5761" in the backtrace
@dkorpel created dlang/dmd pull request #14139 "Fix issue 23102 - pinholeopt, "Conditional jump or move depends on un…" fixing this issue: - Fix issue 23102 - pinholeopt, "Conditional jump or move depends on uninitialised value(s)" https://github.com/dlang/dmd/pull/14139
dlang/dmd pull request #14139 "Fix issue 23102 - pinholeopt, "Conditional jump or move depends on un…" was merged into stable: - 51e9e039b204bcd7221d41d37f1ad657bf05c8e7 by Dennis Korpel: Fix issue 23102 - pinholeopt, "Conditional jump or move depends on uninitialised value(s)" https://github.com/dlang/dmd/pull/14139
dlang/dmd pull request #14280 "merge stable" was merged into master: - c3bd914c2af2a4b66ee433e634370cf91c427f9c by Dennis Korpel: Fix issue 23102 - pinholeopt, "Conditional jump or move depends on uninitialised value(s)" https://github.com/dlang/dmd/pull/14280