[llvm-bugs] [Bug 40033] New: Unittest Sema/./SemaTests.exe/PreferredTypeTest.BinaryExpr failing when host and target have differing sizes for types
via llvm-bugs
llvm-bugs at lists.llvm.org
Fri Dec 14 15:12:06 PST 2018
https://bugs.llvm.org/show_bug.cgi?id=40033
Bug ID: 40033
Summary: Unittest
Sema/./SemaTests.exe/PreferredTypeTest.BinaryExpr
failing when host and target have differing sizes for
types
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: douglas_yung at playstation.sony.com
CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org
The unittest PreferredTypeTest.BinaryExpr was added upstream in r349053, and
then subsequently updated in r349086 to fix problems on LLP64 platforms.
We see a failure in the following test in our internal builds:
Code = R"cpp(
void test(int *ptr) {
ptr + ^10;
ptr += ^10;
ptr -= ^10;
})cpp";
// Expect the normalized ptrdiff_t type, which is typically long or long
long.
const char *PtrDiff = sizeof(void *) == sizeof(long) ? "long" : "long long";
EXPECT_THAT(collectPreferredTypes(Code), Each(PtrDiff));
The problem is that we use Visual Studio 2015 to build the clang and the
unittest, while test when run on Windows uses the newly built clang (which has
a target of the PS4). The problem is that the calculation of PtrDiff gives a
different answer depending on what your platform is in this case and causes the
test to fail.
On 64bit Windows, we have the following:
sizeof(void *) = 8
sizeof(long) = 4
While on the PS4 target, we have the following:
sizeof(void *) = 8
sizeof(long) = 8
This causes a problem because when Visual Studio compiles the unittest, since
it is targeting Windows, the comparison evaluates to false, and PtrDiff is set
to "long long". But when the test is actually run and it takes into
consideration the target platform type sizes, it returns only "long" which
causes the test to fail.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20181214/131eb5b2/attachment-0001.html>
More information about the llvm-bugs
mailing list