reg 1.31 : variable used in GEP cause other constant to be threaded as if equal to 0

[ghost]

Note sure about the title however see https://godbolt.org/z/ePxshnvvc.

In the second case, the same pointer is displayed twice, unless you add the const storage class to RR.

[ghost]

Better test case:

void main()
{
    int[2][1] arr;
    assert(&(arr[0][0]) !is &(arr[0][1]));
    ubyte RR = 0;
    assert(&(arr[RR][0]) !is &(arr[RR][1])); // fails
}     

can that be caused by the switch to untyped pointers ?

[JohanEngelen]

Link to godbolt with AST and LLVM IR output: https://godbolt.org/z/aajE5nKK3

The ASTs are different:

// LDC 1.30
assert(&arr[cast(ulong)RR][0] !is &arr[cast(ulong)RR][1]);

// LDC 1.31
assert(&arr[cast(ulong)RR] + 0LU !is &arr[cast(ulong)RR] + 4LU);

The new offset addition + x (that replaced the [] array indexing) is apparently ignored by LDC in 1.31, as it is not translated into LLVM IR:

; LDC 1.30
%19 = getelementptr inbounds [2 x i32], [2 x i32]* %18, i32 0, i64 1

; LDC 1.31
%14 = getelementptr inbounds [2 x i32], [2 x i32]* %13, i64 0
%15 = bitcast [2 x i32]* %14 to i32*

[thewilsonator]

Does this issue still happen when opaque pointers are enabled?

[kinke]

We're hitting

ldc/gen/binops.cpp

Lines 27 to 28 in 0d4d711

	assert((offset % elemSize) == 0 &&
	"Expected offset by an integer amount of elements");

The problem is that the pointer is int[2]*, and we're not expecting constant byte offsets (here: 4) NOT maching the element size. The frontend here 'flattens' the int[2]* to the resulting int*, where we'd correctly apply the GEP offset of 1.

[JohanEngelen]

Yeah, the AST is invalid, but that's hard to fix now?