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 25951 - wrong code on x86_64-linux-gnu at -O1 and above in 32-bit mode
Summary: wrong code on x86_64-linux-gnu at -O1 and above in 32-bit mode
Status: RESOLVED FIXED
Alias: None
Product: new-bugs
Classification: Unclassified
Component: new bugs (show other bugs)
Version: trunk
Hardware: PC Linux
: P normal
Assignee: Matthias Braun
URL:
Keywords:
: 26009 26025 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-12-27 13:36 PST by Chengnian Sun
Modified: 2016-01-07 12:57 PST (History)
6 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chengnian Sun 2015-12-27 13:36:32 PST
The following code is miscompiled by clang-trunk at -O1 and above in 32-bit mode (not 64-bit mode) on x86_64-linux-gnu.


$: clang-trunk  -v
clang version 3.8.0 (trunk 256450)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.2.1
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.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.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.2.1
Found candidate GCC installation: /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.3
Found candidate GCC installation: /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.4
Found candidate GCC installation: /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$: 
$: clang-trunk small.c -m32 -O3 ; ./a.out
127
$: clang-trunk small.c -m32 -O2 ; ./a.out
127
$: clang-trunk small.c -m32 -Os ; ./a.out
127
$: clang-trunk small.c -m32 -O1 ; ./a.out
1
$: clang-trunk small.c -m32 -O0 ; ./a.out
1
$: clang-trunk small.c -m64 -O3 ; ./a.out
1
$: cat small.c
int printf(const char*, ...);
char a, b, d;
int c;
int main() {
  int e = b++;
  c++;
  d = a++ == e;
  if (c)
    printf("%d\n", (int)b);
  return 0;
}
Comment 1 Michael Kuperstein 2015-12-28 09:30:18 PST
This looks related to r255362.

When trying to generate a SAHF sequence, computeRegisterLiveness()/analyzePhysReg() believe AX is dead because AH is killed - while AL is in fact alive and contains b.

I think in analyzePhysReg() 
bool Covered = TRI->isSuperRegisterEq(MOReg, Reg);
should be:
bool Covered = TRI->isSuperRegisterEq(Reg, MOReg);
but that causes other tests to fail.
Comment 2 Matthias Braun 2016-01-04 17:35:00 PST
Thanks for the analysis Michael, I think this is indeed the problem and I got confused by the fact that isSuperRegister(A, B) means B is a super register of A (the reverse would be a lot more intuitive IMO).

Fixing this lets two of the test cases run into the FIXME in X86InstrInfo::copyPhysReg(). I'll commit a change soon and disable -verify-machineinstrs for those two tests for now.
Comment 3 Matthias Braun 2016-01-04 18:49:36 PST
Fixed in r256799 (and I added a lit test case based on this bug in r256801).
Comment 4 Zhendong Su 2016-01-06 18:43:36 PST
*** Bug 26025 has been marked as a duplicate of this bug. ***
Comment 5 Sanjay Patel 2016-01-07 12:57:17 PST
*** Bug 26009 has been marked as a duplicate of this bug. ***