Non-determinism exposed by microsoft-abi-virtual-inheritance.cpp test

[pcc]

Bugzilla Link	36159
Resolution	FIXED
Resolved on	Mar 07, 2018 15:16
Version	unspecified
OS	Linux
CC	@dwblaikie,@nico,@rnk

Extended Description

$ clang -cc1 -internal-isystem .../lib/clang/7.0.0/include -nostdsysteminc .../clang/test/CodeGenCXX/microsoft-abi-virtual-inheritance.cpp -fno-rtti -std=c++11 -Wno-inaccessible-base -triple=i386-pc-win32 -emit-llvm -o - > /tmp/1 $ clang -cc1 -internal-isystem .../lib/clang/7.0.0/include -nostdsysteminc .../clang/test/CodeGenCXX/microsoft-abi-virtual-inheritance.cpp -fno-rtti -std=c++11 -Wno-inaccessible-base -triple=i386-pc-win32 -emit-llvm -o - | diff -u /tmp/1 -

shows a diff most of the time, e.g.

--- /tmp/1 2018-01-30 17:18:22.750623402 -0800 +++ - 2018-01-30 17:28:37.603706299 -0800 @@ -618,10 +618,10 @@ %vbptr16 = getelementptr inbounds i8, i8 %35, i32 0 %36 = bitcast i8 %vbptr16 to i32* %vbtable17 = load i32, i32** %36, align 4

• %37 = getelementptr inbounds i32, i32* %vbtable17, i32 1
• %37 = getelementptr inbounds i32, i32 %vbtable17, i32 2 %vbase_offs18 = load i32, i32 %37, align 4 %38 = add nsw i32 0, %vbase_offs18
• %vtordisp.value19 = sub i32 %38, 8
• %vtordisp.value19 = sub i32 %38, 16 %39 = getelementptr inbounds i8, i8 %32, i32 %38 %40 = getelementptr i8, i8 %39, i32 -4 %vtordisp.ptr20 = bitcast i8 %40 to i32 @@ -630,10 +630,10 @@ %vbptr21 = getelementptr inbounds i8, i8 %41, i32 0 %42 = bitcast i8 %vbptr21 to i32* %vbtable22 = load i32, i32** %42, align 4
• %43 = getelementptr inbounds i32, i32* %vbtable22, i32 2
• %43 = getelementptr inbounds i32, i32 %vbtable22, i32 1 %vbase_offs23 = load i32, i32 %43, align 4 %44 = add nsw i32 0, %vbase_offs23
• %vtordisp.value24 = sub i32 %44, 16
• %vtordisp.value24 = sub i32 %44, 8 %45 = getelementptr inbounds i8, i8 %32, i32 %44 %46 = getelementptr i8, i8 %45, i32 -4 %vtordisp.ptr25 = bitcast i8 %46 to i32

[nico]

r326960

[nico]

https://reviews.llvm.org/D44223

[nico]

For the vtordisp lines:

This walks VBaseMap in iteration order: http://llvm-cs.pcc.me.uk/tools/clang/lib/CodeGen/MicrosoftCXXABI.cpp#1199

for (VBOffsets::const_iterator I = VBaseMap.begin(), E = VBaseMap.end(); I != E; ++I) { ... }

VBaseMap has type ASTRecordLayout::VBaseOffsetsMapTy which is a llvm::DenseMap<const CXXRecordDecl *, VBaseInfo> -- so even if DenseMap promises sorted iteration order, it'd be sorted by pointer value.

The vbtableNs are probably from the same loop actually: The loop calls GetVirtualBaseClassOffset() which calls GetVBaseOffsetFromVBPtr() which creates the vbtableN vars.

The loop initializes some in-memory structures (it's in initializeHiddenVirtualInheritanceMembers()), and the nondeterminism only means that we do this in a different order. So we should fix it, but it's not a flaky miscompile.