LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 18165 - wrong code at -Os and above
Summary: wrong code at -Os and above
Status: RESOLVED FIXED
Alias: None
Product: libraries
Classification: Unclassified
Component: Scalar Optimizations (show other bugs)
Version: trunk
Hardware: PC All
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
: 17504 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-12-07 00:11 PST by Zhendong Su
Modified: 2014-07-08 18:36 PDT (History)
5 users (show)

See Also:
Fixed By Commit(s):


Attachments
Optimized version that reproduces the problem with llc (4.28 KB, text/plain)
2013-12-07 03:23 PST, Bill Wendling
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zhendong Su 2013-12-07 00:11:58 PST
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;
}
Comment 1 Bill Wendling 2013-12-07 03:23:15 PST
This looks like an LSR bug:

  $ llc -o t.s t.opt.ll -disable-lsr && clang t.s && ./a.out
  0
Comment 2 Bill Wendling 2013-12-07 03:23:54 PST
Created attachment 11685 [details]
Optimized version that reproduces the problem with llc
Comment 3 Andrew Trick 2013-12-09 11:40:12 PST
<rdar://problem/15616673> PR18165: LSR miscompile

Possibly related to PR17473?
Comment 4 Andrew Trick 2014-02-26 10:57:05 PST
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
Comment 5 Sanjay Patel 2014-07-08 18:36:41 PDT
*** Bug 17504 has been marked as a duplicate of this bug. ***