https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91238
--- Comment #1 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
Further reduced, always triggers ICE, so it's not something that recently
started to happen.
---
alias T = const(char)*;
T name()
{
return "";
}
void collectDependencies(ref T)
{
}
void configurePackages(T[T] targets)
{
collectDependencies(targets[name]);
}
---
Associative array is lowered to a function call.
(const char * &) _aaGetRvalueX (targets, &targets.typeinfo, 8, &name ());
And the ICE triggers from that bounds checking wraps this in a SAVE_EXPR, and
does the condition:
SAVE_EXPR<...> != null ? SAVE_EXPR<...> : _d_arraybounds("ice91238.d", 11);
At some point during the traversal of add_expr() for the condition, it
encounters the ADDR_EXPR(CALL_EXPR(name)) in `&name ()` and inspects each
TREE_OPERAND, the first being an INTEGER_CST, triggering the check:
gcc_checking_assert (!(flags & OEP_ADDRESS_OF));
So, the front-end is guilty of taking the address of a non-lvalue, so the
codegen should better handle this.
