Fix 3C definedType test failure on Windows X86 and re-enable the test

[mgrang]

@mattmccutchen-cci

After checkedc#930 merged a number of 3C unit tests failed on Windows builds. These were temporarily disabled: checkedc#952 to unblock the builds. Need fix the underlying issues and enable these tests.

[mattmccutchen-cci]

Thanks. We'll find the right person to look into this on Monday.

[mattmccutchen-cci]

I'm keeping this issue open for us to fix the definedType test on Windows X86 after Microsoft fixes the problem that currently makes the tests difficult to run on Windows X86 (checkedc#963).

[mattmccutchen-cci]

Now that we're able to run the Windows X86 tests, I tracked down why the test was failing on X86 and not X64.

checkedc-clang/clang/test/3C/definedType.c

Lines 21 to 36 in 54d1bfd

	#define ulong unsigned long
	ulong * TOP;
	// CHECK_NOALL: ulong * TOP;
	// CHECK_ALL: _Array_ptr<ulong> TOP = ((void *)0);
	ulong channelColumns;
	void
	DescribeChannel(void)
	{
	ulong col;
	TOP = (ulong *)malloc((channelColumns+1) * sizeof(ulong));
	// CHECK_ALL: TOP = (_Array_ptr<unsigned long>)malloc<unsigned long>((channelColumns+1) * sizeof(ulong));
	// CHECK_NOALL: TOP = (ulong *)malloc<unsigned long>((channelColumns+1) * sizeof(ulong));
	TOP[col] = 0;
	}

The malloc is generating "Unsafe call to allocator function" on X86 but not X64, which causes TOP to remain wild and fail the CHECK_ALL. Here are the AST dumps of the right side of the multiplication:

X86:

ImplicitCastExpr 0xa33ca0 'unsigned long' <IntegralCast>
`-UnaryExprOrTypeTraitExpr 0xa33c88 'unsigned int' sizeof 'unsigned long'

X64:

UnaryExprOrTypeTraitExpr 0x21c475cece8 'unsigned long long' sizeof 'unsigned long'

So sizeof appears to return unsigned int on X86 and unsigned long long on X64, which is consistent with the definition of size_t in the system headers. Multiplication automatically casts the argument of the "smaller" type to the "larger" type, and unsigned int is considered smaller than unsigned long for this purpose even though both types are 32 bits. So on X86, the sizeof gets casted to unsigned long, while on X64, the (channelColumns+1) gets casted to unsigned long long and there is no cast on the sizeof.

The ImplicitCastExpr is preventing this code from detecting the sizeof:

checkedc-clang/clang/lib/3C/ConstraintResolver.cpp

Lines 121 to 128 in 54d1bfd

	static bool getSizeOfArg(Expr *Arg, QualType &ArgTy) {
	if (auto *SizeOf = dyn_cast<UnaryExprOrTypeTraitExpr>(Arg))
	if (SizeOf->getKind() == UETT_SizeOf) {
	ArgTy = SizeOf->getTypeOfArgument();
	return true;
	}
	return false;
	}

I guess getSizeOfArg should just do Arg = Arg->IgnoreParenImpCasts() like analyzeAllocExpr does here:

checkedc-clang/clang/lib/3C/ConstraintResolver.cpp

Line 157 in 54d1bfd

E = E->IgnoreParenImpCasts();

Next questions: Is there a reasonable way to test this that is independent of the OS and architecture? Are there any other obvious places in 3C that we should test for similar bugs while we're here?

[mattmccutchen-cci]

Is there a reasonable way to test this that is independent of the OS and architecture?

The only straightforward testing approach I can see needs an integer type larger than size_t to force conversion of the sizeof. If we use unsigned __int128 if available and otherwise uintmax_t, that will work with Clang in many environments (including our typical one: Linux x86_64 with the GCC system headers, I think?). We could consider having another variant of the test that forces -m32 to get a second shot at it, though that may fail if the user doesn't have the 32-bit system headers installed. Does the unsigned __int128 / uintmax_t approach sound good enough? @john-h-kastner or @kyleheadley?

[john-h-kastner]

I'm satisfied as long as we can test this behavior on current 64-bit linux and don't cause test failures on other configurations.