Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wrong code at -Os and above #18539

Closed
zhendongsu opened this issue Dec 7, 2013 · 5 comments
Closed

wrong code at -Os and above #18539

zhendongsu opened this issue Dec 7, 2013 · 5 comments
Labels
bugzilla Issues migrated from bugzilla

Comments

@zhendongsu
Copy link

Bugzilla Link 18165
Resolution FIXED
Resolved on Jul 08, 2014 18:36
Version trunk
OS All
CC @atrick,@hfinkel,@isanbard

Extended Description

The following code is miscompiled by the current clang trunk (as well as clang 3.3 and 3.2) on x86_64-linux-gnu at -Os and above in both 32-bit and 64-bit modes.

It is also miscompiled by clang 3.0 and 3.1 at -O3, making it a regression from 2.9.

It also seems to affect MacOS X.

$ clang-trunk -v
clang version 3.5 (trunk 196634)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.3
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
$
$ clang-trunk -O1 small.c; a.out
0
$ clang-trunk -Os small.c; a.out
-1
$ clang-3.3 -Os small.c; a.out
-1
$ clang-3.2 -Os small.c; a.out
-1
$ clang-3.1 -Os small.c; a.out
0
$ clang-3.1 -O3 small.c; a.out
-1
$ clang-3.0 -O3 small.c; a.out
-1
$ clang-2.9 -O3 small.c; a.out
0
$
$ gcc-trunk -Os small.c; a.out
0
$ icc -Os small.c; a.out
0
$


int printf (const char *, ...);

struct
{
int f0;
int f1;
int f2;
} a, e;

int b, c = 1, d, f, g, h;

static int
fn1 (unsigned char p)
{
lbl:
for (g = 0; g; g++)
{
if (c)
break;
p && (d |= 1);
}
for (e.f1 = 0; e.f1 < 21; e.f1 += 2)
{
h = 0;
if (a.f0)
goto lbl;
f |= a.f2 |= p++ || b--;
}
return 0;
}

int
main ()
{
fn1 (128);
printf ("%d\n", b);
return 0;
}

@isanbard
Copy link
Contributor

isanbard commented Dec 7, 2013

This looks like an LSR bug:

$ llc -o t.s t.opt.ll -disable-lsr && clang t.s && ./a.out
0

@isanbard
Copy link
Contributor

isanbard commented Dec 7, 2013

@atrick
Copy link
Contributor

atrick commented Dec 9, 2013

rdar://problem/15616673 #18539 : LSR miscompile

Possibly related to #17847 ?

@atrick
Copy link
Contributor

atrick commented Feb 26, 2014

mzolotukhin@apple.com says:

when LSR replaces uses of one IV with the other, it needs to adjust the corresponding offsets. Adjusting here means multiplication by the strides ratio (factor). In the test we had one IV of type i8, its offset was 128, and the factor for this IV and the base IV was 2. LSR got the adjusted offset of 128*2=256 which later was truncated to i8, resulting in incorrect comparison result.

Committed r202273
M lib/Transforms/Scalar/LoopStrengthReduce.cpp
A test/Transforms/LoopStrengthReduce/pr18165.ll

@rotateright
Copy link
Contributor

*** Bug #17878 has been marked as a duplicate of this bug. ***

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 9, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla
Projects
None yet
Development

No branches or pull requests

4 participants