https://bugs.llvm.org/show_bug.cgi?id=52361
Bug ID: 52361
Summary: wrong code at -O2 code on MacOSX with clang 13.0.0
Product: clang
Version: 13.0
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: khar...@mathworks.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Created attachment 25405
--> https://bugs.llvm.org/attachment.cgi?id=25405&action=edit
source code and run script to demonstate this problem.
See code below,
At -O2 optimization, it appears that clang boils away the "else" path in the
"bool test(const Name& name)" routine below - based only on a slight variation
in the anatomy of the structure (i.e. adding the "long t" field).
Initially, we discovered and reproduced this with Apple's Xcode 13. We then
obtained clang 13.0.0 directly from llvm.org and reproduced identical results.
The attached reproduction contains the source and script for three test
scenarios.
The first demonstrates expected behavior (no optimization).
The second demonstrates expected behavior with -O2 optimization.
The third demonstrates the unexpected behavior triggered by the addition of
"long t;" to the structure.
Thank you very much for looking into this!
REPRO CODE:
#include <stdio.h>
#include <stdint.h>
struct Name
{
char j[32];
#if EXPOSEBUG
long t;
#endif
};
bool test(const Name& name)
{
if (0 == ((uint64_t) &name & 2)) {
return 0;
} else {
return 1;
}
}
int main()
{
Name myname;
bool r = test(myname);
printf("NORMAL CASE :%s\n", r ? "!!!WRONG!!!" : "CORRECT");
const Name *px = (const Name *) 0x1e2;
r = test(*px);
printf("SPECIAL CASE:%s\n", r ? "CORRECT" : "!!!WRONG!!!");
return 0;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs