• Cecil Ward (43/43) Apr 30 2023 ldc2 internal assert failure during compile:
• Johan (8/19) Apr 30 2023 This is a known issue:

Cecil Ward <cecil cecilward.com> writes:

ldc2 internal assert failure during compile:
LDC v1.31.0 targeting AMD64. (I ran this under the Matt Godbolt 
Compiler Explorer.)
command line flags:-O3 -release

ldc2: 
/home/runner/work/llvm-project/llvm-project/llvm/lib/IR/Instructions.cpp:3701:
llvm::SExtInst::SExtInst(llvm::Value *, llvm::Type *, const llvm::Twine &,
llvm::BasicBlock *): Assertion `castIsValid(getOpcode(), S, Ty) && "Illegal
SExt"' failed.
Stack dump without symbol names (ensure you have llvm-symbolizer 
in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to 
point to it):
/opt/compiler-explorer/ldc-latest-ci/ldc/bin/ldc2(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamEi+0x23)[0x557adb795ae3]
Compiler returned:

== D source code ==

import std.stdint;
import core.simd;

uint64_t hashi( const uint64_t * p, size_t len )
	{
	uint64_t s = 0;
	for ( size_t i = 0; i < len; i++ )
		{
		s ^= ( p[i] * 509 ) ^ ( p[i] >>> 9 );
		}
	return s;
	}

alias uint64_256_t = ulong4;
alias uint64x4_t = uint64_256_t;
alias uint64_32_t = uint64_256_t;

uint64_t hashv( const uint64_256_t * p, size_t len )
	{
	uint64_256_t s1 = [0, 0, 0, 0];
	for ( size_t i = 0; i < len; i++ )
		{
		const x = p[i];
		s1 ^= (x * 509) ^ (x >>> 9);
		}
	const nsz = (*p).sizeof * 8 / 64;
	const uint64_t[nsz] v = cast(uint64_t[nsz]) s1;
	uint64_t s = 0;
	for ( size_t i = 0; i < len; i++ )
		{
		s ^= v[i];
		}
	return s;
	}

Johan <j j.nl> writes:

On Sunday, 30 April 2023 at 16:25:53 UTC, Cecil Ward wrote:
 ldc2 internal assert failure during compile:

...
 alias uint64_256_t = ulong4;
 alias uint64x4_t = uint64_256_t;
 alias uint64_32_t = uint64_256_t;

 uint64_t hashv( const uint64_256_t * p, size_t len )
 	{
 	uint64_256_t s1 = [0, 0, 0, 0];
 	for ( size_t i = 0; i < len; i++ )
 		{
 		const x = p[i];
 		s1 ^= (x * 509) ^ (x >>> 9);

This is a known issue: 
https://github.com/ldc-developers/ldc/issues/3606

The workaround for now is to manually change the type of the 
shift operand to a vector:
`s1 ^= (x * 509) ^ (x >>> uint64_256_t(9));`

-Johan