Bug 16295 – REG since 2.069: undefined symbol that should be defined prevents separate compilation

Status
RESOLVED
Resolution
WORKSFORME
Severity
regression
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
x86
OS
Mac OS X
Creation time
2016-07-19T03:40:43Z
Last change time
2020-02-13T09:48:53Z
Assigned to
No Owner
Creator
Timothee Cour

Comments

Comment #0 by timothee.cour2 — 2016-07-19T03:40:43Z
out_D=/tmp/ dmd=$dmd_069_X # dmd=$dmd_068_X # dmd=$ldc_X $dmd -c -of$out_D/main.o main.d && nm $out_D/main.o | grep ' U _D4main8__' For dmd v2.071.1 and dmd v2.069, we these undefined symbols; the ones starting with _D4main8_ should not be undefined: U _D15TypeInfo_Struct6__vtblZ U _D4main8__T1AThZ1A8__T1BThZ1B5emptyMFNaNbNdNiNfZi U _D4main8__T1AThZ1A8__T1BThZ1B5frontMFNaNbNiNfZPv U _D4main8__T1AThZ1A8__T1BThZ1B8popFrontMFNaNbNiNfZv U __d_arraybounds U __d_assert U __d_assert_msg U __d_unittest eg, _D4main8__T1AThZ1A8__T1BThZ1B5frontMFNaNbNiNfZPv corresponds to: pure nothrow @nogc @safe void* main.A!(ubyte).A.B!(ubyte).B.front() For ldc (based on DMD v2.071.1 and LLVM 3.8.0) and dmd dmd v2.068, we get the correct undefined symbols: U _D15TypeInfo_Struct6__vtblZ U __d_arraybounds U __d_assert U __d_assert_msg U __d_unittest ---- fun.d: ---- import main; void fun(A!(ubyte) a){ } main.d: ---- module main; import fun; struct A(T) { void test() { foreach (v; this) { } } auto range() { return B!T(); } int opApply(int delegate(T)) { auto r = range; foreach (v; r) { } return 0; } struct B(T) { auto front() { void* a; return a; } @property empty() { return 0; } void popFront() { } } } alias Au = A!(ubyte);
Comment #1 by timothee.cour2 — 2016-07-19T03:46:46Z
NOTE: this is very bad because it prevents separate compilation model. this removes the undefined symbols: $dmd -c -of$out_D/main.o main.d fund.d this has undefined symbols: $dmd -c -of$out_D/main.o main.d $dmd -c -of$out_D/fun.o fun.d _D4main8__T1AThZ1A8__T1BThZ1B5frontMFNaNbNiNfZPv is undefined in both main.o and fun.o
Comment #2 by bugzilla — 2016-07-27T07:18:34Z
Does it work if you compile with -allinst ?
Comment #3 by timothee.cour2 — 2016-07-27T08:03:14Z
(In reply to Walter Bright from comment #2) > Does it work if you compile with -allinst ? no, IIRC I had tried and that didn't work.
Comment #4 by bugzilla — 2020-02-13T09:48:53Z
(In reply to Timothee Cour from comment #0) > out_D=/tmp/ > > dmd=$dmd_069_X > # dmd=$dmd_068_X > # dmd=$ldc_X > > $dmd -c -of$out_D/main.o main.d && nm $out_D/main.o | grep ' U _D4main8__' > > For dmd v2.071.1 and dmd v2.069, we these undefined symbols; the ones > starting with _D4main8_ should not be undefined: > > U _D4main8__T1AThZ1A8__T1BThZ1B5emptyMFNaNbNdNiNfZi > U _D4main8__T1AThZ1A8__T1BThZ1B5frontMFNaNbNiNfZPv > U _D4main8__T1AThZ1A8__T1BThZ1B8popFrontMFNaNbNiNfZv I see those in fun.o: > nm fun.o 0000000000000000 t 0000000000000000 V __bzeroBytes U _D15TypeInfo_Struct6__vtblZ 0000000000000000 V _D25TypeInfo_S4main__T1AThZQf6__initZ 0000000000000000 V _D35TypeInfo_S4main__T1AThZQf__T1BThZQf6__initZ 0000000000000000 R _D3fun12__ModuleInfoZ 0000000000000000 W _D3funQeFS4main__T1AThZQfZv 0000000000000000 W _D4main__T1AThZQf4testMFNaNbNiNfZv 0000000000000000 W _D4main__T1AThZQf4testMFZ14__foreachbody1MFNaNbNiNfhZi 0000000000000000 W _D4main__T1AThZQf5rangeMFNaNbNiNfZSQBh__TQBfThZQBl__T1BThZQf 0000000000000000 W _D4main__T1AThZQf7opApplyMFNaNbNiNfDFhZiZi 0000000000000000 W _D4main__T1AThZQf__T1BThZQf5emptyMFNaNbNdNiNfZi 0000000000000000 W _D4main__T1AThZQf__T1BThZQf5frontMFNaNbNiNfZPv 0000000000000000 W _D4main__T1AThZQf__T1BThZQf8popFrontMFNaNbNiNfZv U _d_dso_registry U __start_minfo U __stop_minfo with the current master. I'm going to resolve it as WORKSFORME. If it shows up again, we can revisit it.