Skip to content

Conversation

dnadlinger
Copy link
Member

If anyone wanted to ever resurrect LDC1/Phobos (lphobos/README.txt had an »unmaintained« notice for more than three years now), this should be done in an external repository.

If anyone wanted to ever resurrect LDC1/Phobos (lphobos/README.txt had an »unmaintained« notice for more than three years now), this should be done in an external repository.
dnadlinger added a commit that referenced this pull request Aug 8, 2011
Removed Phobos 1 from LDC tree.
@dnadlinger dnadlinger merged commit e63044e into ldc-developers:master Aug 8, 2011
redstar added a commit that referenced this pull request Sep 27, 2014
Add implementation of popcnt.
redstar pushed a commit that referenced this pull request Sep 27, 2014
redstar pushed a commit that referenced this pull request Sep 27, 2014
regression test for Issue 10701
redstar pushed a commit that referenced this pull request Sep 27, 2014
missing executeArgs for benchmarks
@kinke kinke mentioned this pull request Mar 3, 2015
@dnadlinger dnadlinger deleted the remove-phobos1 branch May 8, 2016 14:10
timotheecour pushed a commit to timotheecour/ldc that referenced this pull request Dec 13, 2017
TemplateSpecializationType might be sugar for InjectedClassNameType too.
timotheecour pushed a commit to timotheecour/ldc that referenced this pull request Dec 13, 2017
A major source of headaches and probably the source ldc-developers#1 of mapping failures for sophisticated C++ libraries has been the restrictions of D template instantiation scope. Those restrictions are totally necessary and work great in D, and Clang adding "sugar" to its types made it possible to comply with them... most of the time.

One particular wall was hit while trying to map the MSVC standard library. For type_traits's conjunction<_Is_character<char>, _Is_character<char>>, the base class in Clang's AST is:

    TemplateSpecializationType 0xdfaed30 '_Conjunction<struct std::_Is_character<char>, struct std::_Is_character<char> >' sugar _Conjunction
        | -TemplateArgument type 'struct std::_Is_character<char>':'struct std::_Is_character<char>'
        | SubstTemplateTypeParmType 0xdda9f20 'struct std::_Is_character<char>' sugar
            | -TemplateTypeParmType 0xa7ce0f0 '_Traits' dependent contains_unexpanded_pack depth 0 index 0 pack
            | `-TemplateTypeParm 0xa7ce0c0 '_Traits'
            `-RecordType 0xa9079d0 'struct std::_Is_character<char>'
                `-ClassTemplateSpecialization 0xa907930 '_Is_character'
        | -TemplateArgument type 'struct std::_Is_character<char>' : 'struct std::_Is_character<char>'
        | SubstTemplateTypeParmType 0xdda9f20 'struct std::_Is_character<char>' sugar (...same as above....)
        `-RecordType 0xdfaed10 'struct std::_Conjunction<struct std::_Is_character<char>, struct std::_Is_character<char> >'
        `-ClassTemplateSpecialization 0xdfaec78 '_Conjunction'

This is one of those rare cases where Clang has lost pack information and no simple/good heuristic to guess when two or more arguments come from the same pack appears to be possible. Hence either Clang needs to be modified to preserve pack info, or a complicated check/heuristic is needed, or we've got to stop trying to stick to DMD's way.

The third option was chosen because there's actually no good reason to comply with those restrictions. Reflection doesn't get improved, and while instantiation from C++ modules, every referenced symbol is from C++ modules.

So from now on:
 - Every type gets desugared before being mapped in non-dependent contexts.
 - C++ modules now have access to the "C++ global namespace" during name lookups, through a special type of global import.

This allows to discard the C++ symbol collector and substitution complicated hack when mapping template arguments deduced by Sema.
kinke added a commit that referenced this pull request Sep 1, 2023
I guess the recent removal of module constructors in druntime has
brought these to light, for a little LDC ASan smoke test, which
newly complains with D v2.105, e.g.:

> Direct leak of 78624 byte(s) in 126 object(s) allocated from:
>     #0 0x55606978c40d in malloc /local/mnt/workspace/tmp/final/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
>     #1 0x5560698050b1 in _D2rt5minfo11ModuleGroup9sortCtorsMFNbAyaZv
kinke added a commit to kinke/ldc that referenced this pull request Sep 1, 2023
I guess the recent removal of module constructors in druntime has
brought these to light, for a little LDC ASan smoke test, which
newly complains with D v2.105, e.g.:

> Direct leak of 78624 byte(s) in 126 object(s) allocated from:
>     #0 0x55606978c40d in malloc /local/mnt/workspace/tmp/final/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
>     ldc-developers#1 0x5560698050b1 in _D2rt5minfo11ModuleGroup9sortCtorsMFNbAyaZv
the-horo added a commit to the-horo/ldc that referenced this pull request Aug 21, 2025
These tests seem to fail with a shared druntime, and work with a
static one. CI fails with a static druntime though.

A gdb backtrace with a shared druntime:
```
Reading symbols from ./a...
(No debugging symbols found in ./a)
(gdb) r
Starting program: /root/build/a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000005555550afc in D main ()
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0000007ff77432f0 in ?? () from /usr/lib/gcc/aarch64-unknown-linux-gnu/15/libgcc_s.so.1
(gdb) bt
\#0  0x0000007ff77432f0 in ?? () from /usr/lib/gcc/aarch64-unknown-linux-gnu/15/libgcc_s.so.1
\ldc-developers#1  0x0000007ff77563b8 in ?? () from /usr/lib/gcc/aarch64-unknown-linux-gnu/15/libgcc_s.so.1
\ldc-developers#2  0x0000007ff7757000 in _Unwind_Backtrace () from /usr/lib/gcc/aarch64-unknown-linux-gnu/15/libgcc_s.so.1
\ldc-developers#3  0x0000007ff78b2c6c in backtrace () from /usr/lib64/libc.so.6
\ldc-developers#4  0x0000007ff7aee058 in core.lifetime.emplace!(core.runtime.DefaultTraceInfo).emplace(core.runtime.DefaultTraceInfo) ()
   from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#5  0x0000007ff7aed1f0 in core.runtime.defaultTraceHandler(void*) () from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#6  0x0000007ff7b09614 in _d_createTrace () from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#7  0x0000007ff7b0a7a0 in _d_throw_exception () from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#8  0x0000007ff7acb418 in _d_assert_msg () from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#9  0x0000005555550d18 in etc.linux.memoryerror.registerMemoryAssertHandler!().registerMemoryAssertHandler()._d_handleSignalAssert(int, core.sys.posix.signal.siginfo_t*, void*) ()
\ldc-developers#10 <signal handler called>
\ldc-developers#11 0x0000005555550afc in D main ()
```

And with a static druntime:
```
Reading symbols from ./a...
(No debugging symbols found in ./a)
(gdb) r
Starting program: /tmp/a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000000555556a4bc in D main ()
(gdb) c
Continuing.
core.exception.AssertError@/usr/lib/ldc2/1.41/include/d/etc/linux/memoryerror.d(415): segmentation fault: null pointer read/write operation
----------------
??:? [0x555557fa2f]
??:? [0x555557f1ab]
??:? [0x5555581d17]
??:? [0x5555570893]
??:? [0x555556b2ab]
??:? [0x555556a6d7]
??:? [0x7ff7ffb797]
??:? [0x555556a4bb]
??:? [0x5555570567]
??:? [0x5555570413]
??:? [0x5555570277]
??:? [0x555556a5a3]
??:? [0x7ff7d02053]
??:? __libc_start_main [0x7ff7d02137]
??:? [0x555556a3af]

Program received signal SIGSEGV, Segmentation fault.
0x0000007ffffffdd0 in ?? ()
```

Signed-off-by: Andrei Horodniceanu <[email protected]>
the-horo added a commit to the-horo/ldc that referenced this pull request Aug 22, 2025
These tests seem to fail with a shared druntime (depending on arch as
well), and work with a static one. CI fails with a static druntime
though.

A gdb backtrace with a shared druntime:
```
Reading symbols from ./a...
(No debugging symbols found in ./a)
(gdb) r
Starting program: /root/build/a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000005555550afc in D main ()
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0000007ff77432f0 in ?? () from /usr/lib/gcc/aarch64-unknown-linux-gnu/15/libgcc_s.so.1
(gdb) bt
\#0  0x0000007ff77432f0 in ?? () from /usr/lib/gcc/aarch64-unknown-linux-gnu/15/libgcc_s.so.1
\ldc-developers#1  0x0000007ff77563b8 in ?? () from /usr/lib/gcc/aarch64-unknown-linux-gnu/15/libgcc_s.so.1
\ldc-developers#2  0x0000007ff7757000 in _Unwind_Backtrace () from /usr/lib/gcc/aarch64-unknown-linux-gnu/15/libgcc_s.so.1
\ldc-developers#3  0x0000007ff78b2c6c in backtrace () from /usr/lib64/libc.so.6
\ldc-developers#4  0x0000007ff7aee058 in core.lifetime.emplace!(core.runtime.DefaultTraceInfo).emplace(core.runtime.DefaultTraceInfo) ()
   from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#5  0x0000007ff7aed1f0 in core.runtime.defaultTraceHandler(void*) () from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#6  0x0000007ff7b09614 in _d_createTrace () from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#7  0x0000007ff7b0a7a0 in _d_throw_exception () from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#8  0x0000007ff7acb418 in _d_assert_msg () from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#9  0x0000005555550d18 in etc.linux.memoryerror.registerMemoryAssertHandler!().registerMemoryAssertHandler()._d_handleSignalAssert(int, core.sys.posix.signal.siginfo_t*, void*) ()
\ldc-developers#10 <signal handler called>
\ldc-developers#11 0x0000005555550afc in D main ()
```

And with a static druntime:
```
Reading symbols from ./a...
(No debugging symbols found in ./a)
(gdb) r
Starting program: /tmp/a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000000555556a4bc in D main ()
(gdb) c
Continuing.
core.exception.AssertError@/usr/lib/ldc2/1.41/include/d/etc/linux/memoryerror.d(415): segmentation fault: null pointer read/write operation
----------------
??:? [0x555557fa2f]
??:? [0x555557f1ab]
??:? [0x5555581d17]
??:? [0x5555570893]
??:? [0x555556b2ab]
??:? [0x555556a6d7]
??:? [0x7ff7ffb797]
??:? [0x555556a4bb]
??:? [0x5555570567]
??:? [0x5555570413]
??:? [0x5555570277]
??:? [0x555556a5a3]
??:? [0x7ff7d02053]
??:? __libc_start_main [0x7ff7d02137]
??:? [0x555556a3af]

Program received signal SIGSEGV, Segmentation fault.
0x0000007ffffffdd0 in ?? ()
```

Signed-off-by: Andrei Horodniceanu <[email protected]>
the-horo added a commit to the-horo/ldc that referenced this pull request Aug 22, 2025
These tests seem to fail with a shared druntime (depending on arch as
well), and work with a static one. CI fails with a static druntime
though.

A gdb backtrace with a shared druntime:
```
Reading symbols from ./a...
(No debugging symbols found in ./a)
(gdb) r
Starting program: /root/build/a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000005555550afc in D main ()
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0000007ff77432f0 in ?? () from /usr/lib/gcc/aarch64-unknown-linux-gnu/15/libgcc_s.so.1
(gdb) bt
\#0  0x0000007ff77432f0 in ?? () from /usr/lib/gcc/aarch64-unknown-linux-gnu/15/libgcc_s.so.1
\ldc-developers#1  0x0000007ff77563b8 in ?? () from /usr/lib/gcc/aarch64-unknown-linux-gnu/15/libgcc_s.so.1
\ldc-developers#2  0x0000007ff7757000 in _Unwind_Backtrace () from /usr/lib/gcc/aarch64-unknown-linux-gnu/15/libgcc_s.so.1
\ldc-developers#3  0x0000007ff78b2c6c in backtrace () from /usr/lib64/libc.so.6
\ldc-developers#4  0x0000007ff7aee058 in core.lifetime.emplace!(core.runtime.DefaultTraceInfo).emplace(core.runtime.DefaultTraceInfo) ()
   from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#5  0x0000007ff7aed1f0 in core.runtime.defaultTraceHandler(void*) () from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#6  0x0000007ff7b09614 in _d_createTrace () from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#7  0x0000007ff7b0a7a0 in _d_throw_exception () from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#8  0x0000007ff7acb418 in _d_assert_msg () from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#9  0x0000005555550d18 in etc.linux.memoryerror.registerMemoryAssertHandler!().registerMemoryAssertHandler()._d_handleSignalAssert(int, core.sys.posix.signal.siginfo_t*, void*) ()
\ldc-developers#10 <signal handler called>
\ldc-developers#11 0x0000005555550afc in D main ()
```

And with a static druntime:
```
Reading symbols from ./a...
(No debugging symbols found in ./a)
(gdb) r
Starting program: /tmp/a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000000555556a4bc in D main ()
(gdb) c
Continuing.
core.exception.AssertError@/usr/lib/ldc2/1.41/include/d/etc/linux/memoryerror.d(415): segmentation fault: null pointer read/write operation
----------------
??:? [0x555557fa2f]
??:? [0x555557f1ab]
??:? [0x5555581d17]
??:? [0x5555570893]
??:? [0x555556b2ab]
??:? [0x555556a6d7]
??:? [0x7ff7ffb797]
??:? [0x555556a4bb]
??:? [0x5555570567]
??:? [0x5555570413]
??:? [0x5555570277]
??:? [0x555556a5a3]
??:? [0x7ff7d02053]
??:? __libc_start_main [0x7ff7d02137]
??:? [0x555556a3af]

Program received signal SIGSEGV, Segmentation fault.
0x0000007ffffffdd0 in ?? ()
```

Signed-off-by: Andrei Horodniceanu <[email protected]>
the-horo added a commit to the-horo/ldc that referenced this pull request Aug 24, 2025
These tests seem to fail with a shared druntime (depending on arch as
well), and work with a static one. CI fails with a static druntime
though.

A gdb backtrace with a shared druntime:
```
Reading symbols from ./a...
(No debugging symbols found in ./a)
(gdb) r
Starting program: /root/build/a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000005555550afc in D main ()
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0000007ff77432f0 in ?? () from /usr/lib/gcc/aarch64-unknown-linux-gnu/15/libgcc_s.so.1
(gdb) bt
\#0  0x0000007ff77432f0 in ?? () from /usr/lib/gcc/aarch64-unknown-linux-gnu/15/libgcc_s.so.1
\ldc-developers#1  0x0000007ff77563b8 in ?? () from /usr/lib/gcc/aarch64-unknown-linux-gnu/15/libgcc_s.so.1
\ldc-developers#2  0x0000007ff7757000 in _Unwind_Backtrace () from /usr/lib/gcc/aarch64-unknown-linux-gnu/15/libgcc_s.so.1
\ldc-developers#3  0x0000007ff78b2c6c in backtrace () from /usr/lib64/libc.so.6
\ldc-developers#4  0x0000007ff7aee058 in core.lifetime.emplace!(core.runtime.DefaultTraceInfo).emplace(core.runtime.DefaultTraceInfo) ()
   from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#5  0x0000007ff7aed1f0 in core.runtime.defaultTraceHandler(void*) () from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#6  0x0000007ff7b09614 in _d_createTrace () from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#7  0x0000007ff7b0a7a0 in _d_throw_exception () from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#8  0x0000007ff7acb418 in _d_assert_msg () from /usr/lib/ldc2/1.41/lib64/libdruntime-ldc-shared.so.111
\ldc-developers#9  0x0000005555550d18 in etc.linux.memoryerror.registerMemoryAssertHandler!().registerMemoryAssertHandler()._d_handleSignalAssert(int, core.sys.posix.signal.siginfo_t*, void*) ()
\ldc-developers#10 <signal handler called>
\ldc-developers#11 0x0000005555550afc in D main ()
```

And with a static druntime:
```
Reading symbols from ./a...
(No debugging symbols found in ./a)
(gdb) r
Starting program: /tmp/a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000000555556a4bc in D main ()
(gdb) c
Continuing.
core.exception.AssertError@/usr/lib/ldc2/1.41/include/d/etc/linux/memoryerror.d(415): segmentation fault: null pointer read/write operation
----------------
??:? [0x555557fa2f]
??:? [0x555557f1ab]
??:? [0x5555581d17]
??:? [0x5555570893]
??:? [0x555556b2ab]
??:? [0x555556a6d7]
??:? [0x7ff7ffb797]
??:? [0x555556a4bb]
??:? [0x5555570567]
??:? [0x5555570413]
??:? [0x5555570277]
??:? [0x555556a5a3]
??:? [0x7ff7d02053]
??:? __libc_start_main [0x7ff7d02137]
??:? [0x555556a3af]

Program received signal SIGSEGV, Segmentation fault.
0x0000007ffffffdd0 in ?? ()
```

Signed-off-by: Andrei Horodniceanu <[email protected]>
kinke pushed a commit that referenced this pull request Sep 27, 2025
Limit the number of platforms that this is done on.  A inspection of
some libc implementations of fork has identified the main culprits,
don't need to apply this to any others.

MacOS testsuite also regressed as a result on calling this code, it's
not clear why, but the backtrace is:
```
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
  * frame #0: 0x00007ff81abe6ee3 libsystem_platform.dylib`_os_unfair_lock_recursive_abort + 23
    frame #1: 0x00007ff81abe12da libsystem_platform.dylib`_os_unfair_lock_lock_slow + 247
    frame #2: 0x00007ff81abccd44 libsystem_pthread.dylib`_pthread_atfork_prepare_handlers + 48
    frame #3: 0x00007ff825dc2705 libSystem.B.dylib`libSystem_atfork_prepare + 25
    frame #4: 0x00007ff81aac17e1 libsystem_c.dylib`fork + 24
    frame #5: 0x0000000101f730ee test_runner`core.internal.backtrace.dwarf.resolveAddressesWithAtos(Location[]) + 210
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant