Is this still available or has it been fixed once 18480 was fixed?

Well it seems to be an issue with the mangling in gdb (maybe the new backreferencing mangling isn't supported yet?). I would guess that it's a similar issue on OSX with LLDB?

How to reproduce:

1) pick a random ICE
2) compile dmd with ENABLE_DEBUG=1
3) get the stacktrace


```
gdbbt ../generated/linux/release/64/dmd -dip1000 foo.d
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
DMD v2.079.0-285-g5bdf4078c DEBUG

Program received signal SIGSEGV, Segmentation fault.
0x0000555555806135 in _D3dmd6escape13escapeByValueFCQBc10expression10ExpressionPSQCfQCe15EscapeByResultsZv (er=0x7fffffffb730, e=0x0) at dmd/escape.d:1293
1293	    e.accept(v);
#0  0x0000555555806135 in _D3dmd6escape13escapeByValueFCQBc10expression10ExpressionPSQCfQCe15EscapeByResultsZv (er=0x7fffffffb730, e=0x0) at dmd/escape.d:1293
#1  0x00005555558052b9 in _D3dmd6escape14checkNewEscapeFPSQBe6dscope5ScopeCQBv10expression10ExpressionbZb (gag=false, e=0x0, sc=0x7ffff6971120) at dmd/escape.d:592
#2  0x000055555581f676 in ExpressionSemanticVisitor::visit(NewExp*) (this=0x7fffffffbc78, exp=0x7ffff7e9f2f0) at dmd/expressionsem.d:2363
#3  0x0000555555810d66 in NewExp::accept(Visitor*) (this=0x7ffff7e9f2f0, v=0x7fffffffbc78) at dmd/expression.d:4155
#4  0x000055555583461f in expressionSemantic(Expression*, Scope*) (e=0x7ffff7e9f2f0, sc=0x7ffff6971120) at dmd/expressionsem.d:9367
#5  0x00005555558c5042 in StatementSemanticVisitor::visit(ExpStatement*) (this=0x7fffffffbd48, s=0x7ffff7e9f360) at dmd/statementsem.d:177
#6  0x00005555558a771a in ExpStatement::accept(Visitor*) (this=0x7ffff7e9f360, v=0x7fffffffbd48) at dmd/statement.d:715
#7  0x00005555558c4f2b in statementSemantic(Statement*, Scope*) (s=0x7ffff7e9f360, sc=0x7ffff6971120) at dmd/statementsem.d:126
#8  0x00005555558c52f0 in StatementSemanticVisitor::visit(CompoundStatement*) (this=0x7fffffffc048, cs=0x7ffff7e9f380) at dmd/statementsem.d:235
#9  0x00005555558a7ece in CompoundStatement::accept(Visitor*) (this=0x7ffff7e9f380, v=0x7fffffffc048) at dmd/statement.d:908
#10 0x00005555558c4f2b in statementSemantic(Statement*, Scope*) (s=0x7ffff7e9f380, sc=0x7ffff6971120) at dmd/statementsem.d:126
#11 0x00005555558d9d38 in Semantic3Visitor::visit(FuncDeclaration*) (this=0x7fffffffc990, funcdecl=0x7ffff7e9efa0) at dmd/semantic3.d:581
#12 0x000055555583b80a in FuncDeclaration::accept(Visitor*) (this=0x7ffff7e9efa0, v=0x7fffffffc990) at dmd/func.d:2277
#13 0x00005555558d862d in semantic3(Dsymbol*, Scope*) (dsym=0x7ffff7e9efa0, sc=0x7ffff6970e30) at dmd/semantic3.d:82
#14 0x00005555558d8a24 in Semantic3Visitor::visit(Module*) (this=0x7fffffffca40, mod=0x7ffff7e9eb60) at dmd/semantic3.d:195
#15 0x00005555557cfbf2 in Module::accept(Visitor*) (this=0x7ffff7e9eb60, v=0x7fffffffca40) at dmd/dmodule.d:1322
#16 0x00005555558d862d in semantic3(Dsymbol*, Scope*) (dsym=0x7ffff7e9eb60, sc=0x0) at dmd/semantic3.d:82
#17 0x000055555587268b in dmd.mars.tryMain(ulong, const(char)**) (argv=0x7fffffffd628, argc=3) at dmd/mars.d:836
#18 0x000055555587380f in D main () at dmd/mars.d:1098
```

However, with ddemangle everything is properly demangle:

```
gdbbt ../generated/linux/release/64/dmd -dip1000 foo.d | ddemangle
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
DMD v2.079.0-285-g5bdf4078c DEBUG

Program received signal SIGSEGV, Segmentation fault.
0x0000555555806135 in void dmd.escape.escapeByValue(dmd.expression.Expression, dmd.escape.EscapeByResults*) (er=0x7fffffffb730, e=0x0) at dmd/escape.d:1293
1293	    e.accept(v);
#0  0x0000555555806135 in void dmd.escape.escapeByValue(dmd.expression.Expression, dmd.escape.EscapeByResults*) (er=0x7fffffffb730, e=0x0) at dmd/escape.d:1293
#1  0x00005555558052b9 in bool dmd.escape.checkNewEscape(dmd.dscope.Scope*, dmd.expression.Expression, bool) (gag=false, e=0x0, sc=0x7ffff6971120) at dmd/escape.d:592
#2  0x000055555581f676 in ExpressionSemanticVisitor::visit(NewExp*) (this=0x7fffffffbc78, exp=0x7ffff7e9f2f0) at dmd/expressionsem.d:2363
```

Oh and exploring a bit when I look at the ICE in https://issues.dlang.org/show_bug.cgi?id=18136, I get the following stack trace with only partial demangling:

```
core.exception.AssertError@dmd/statement.d(425): Assertion failure
----------------
??:? _d_assertp [0xdc37fbf5]
??:? dmd.statement.ErrorStatement dmd.statement.ErrorStatement.__ctor() [0xdc25ec05]
??:? _ZN16Semantic3Visitor5visitEP15FuncDeclaration [0xdc291e83]
??:? _ZN16ParseTimeVisitorI10ASTCodegenE5visitEP22FuncLiteralDeclaration [0xdc275ef1]
??:? _ZN22FuncLiteralDeclaration6acceptEP7Visitor [0xdc1f5739]
??:? _Z9semantic3P7DsymbolP5Scope [0xdc29062c]
??:? _ZN25ExpressionSemanticVisitor5visitEP7FuncExp [0xdc1d80be]
??:? _ZN7FuncExp6acceptEP7Visitor [0xdc1ca119]
??:? _Z18expressionSemanticP10ExpressionP5Scope [0xdc1ec61e]
??:? _ZN14ResolveVisitor5visitEP10TypeTypeof [0xdc26a43a]
...
??:? int dmd.dtemplate.functionResolve(dmd.declaration.Match*, dmd.dsymbol.Dsymbol, dmd.globals.Loc, dmd.dscope.Scope*, dmd.root.array.Array!(dmd.root.rootobject.RootObject).Array*, dmd.mtype.Type, dmd.root.array.Array!(dmd.expression.Expression).Array*, const(char)**).applyTemplate(dmd.dtemplate.TemplateDeclaration) [0xdc1af047]
??:? _Z15resolveFuncCallRK3LocP5ScopeP7DsymbolP5ArrayIP10RootObjectEP4TypePS6_IP10ExpressionEi [0xdc1f3ffe]
??:? _ZN25ExpressionSemanticVisitor5visitEP7CallExp [0xdc1dad73]
```

Regarding the original report, it is indeed a lack of backreference support.
This will be fixed once https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543278.html is accepted. In the meantime, nothing we can do.
Regarding Seb's backtrace, the non-demangled symbols are C++ symbols. That's another issue entirely (there's an open PR for it) so closing this as FIXED (since there's an upstream patch).