clang generates endless loop

[llvmbot]

Bugzilla Link	9614
Resolution	FIXED
Resolved on	Mar 07, 2013 16:17
Version	trunk
OS	Linux
Blocks	llvm/llvm-bugzilla-archive#11199
Attachments	glibc wchar.h
Reporter	LLVM Bugzilla Contributor
CC	@ahatanak,@andersk,@shining,@echristo,@efriedma-quic,@foutrelis,@ismail

Extended Description

Clang generates llvm intermediate code with an endless loop, when -O is used.
Here is source .c code:

$ cat test.c
#include <wchar.h>
int main ()
{
return btowc ('\0');
}

And after compilation we have:

(gdb) disas main
Dump of assembler code for function main:
0x00000000004004f0 <+0>: jmp 0x4004f0

End of assembler dump.

Here is LLVM IR:

$ clang -S -emit-llvm test.c; cat test.s
; ModuleID = 'test.c'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-pc-linux-gnu"

define i32 @​main() nounwind {
%1 = alloca i32, align 4
store i32 0, i32* %1
%2 = call i32 @​btowc(i32 0) nounwind
ret i32 %2
}

declare i32 @​btowc(i32) nounwind

$ clang -O -S -emit-llvm test.c; cat test.s
; ModuleID = 'test.c'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-pc-linux-gnu"

define i32 @​main() nounwind readnone {
br label %tailrecurse.i

tailrecurse.i: ; preds = %tailrecurse.i, %0
br label %tailrecurse.i
}

I've attached wchar.h just in case.

[efriedma-quic]

Testcase boils down to something like the following:

typedef __typeof(+L'a') wint_t;
extern wint_t __btowc_alias (int __c) __asm ("btowc");
__attribute((nothrow)) inline wint_t btowc (int __c) {
return __btowc_alias (__c);
}
int f(int x) { return btowc(x); }

clang resolves the call to __btowc_alias into a call to btowc, so clang essentially sees through the trick to try and make the inline version call the out-of-line version. The function then ends up looking like it's tail-recursive, i.e. an infinite loop.

[shining]

I've found another test case with realpath.

extern char *__realpath_alias (__const char *__restrict __name, char
*__restrict __resolved) asm ("" "realpath");

extern char *
realpath (__const char *__restrict __name, char *__restrict __resolved)
{
return __realpath_alias (__name, __resolved);
}

char *f(const char *path, char *buf)
{
return realpath(path, buf);
}

[efriedma-quic]

*** Bug llvm/llvm-bugzilla-archive#10179 has been marked as a duplicate of this bug. ***

[efriedma-quic]

*** Bug llvm/llvm-bugzilla-archive#10207 has been marked as a duplicate of this bug. ***

[llvmbot]

I get an infinite loop for btowc() with -O2 but not -O1 as described in bug #​10207.

This bug appears to have quite far reaching consequences. Not only does it make the configure scripts of such software as gnu tar, coreutils, diffutils, findutils, gettext, and grep hang. It might be the reason gnu sed, and awk hang during their tests as well (at least they hang when compiled with -O2 but not with -O1).

[d0k]

*** Bug llvm/llvm-bugzilla-archive#10981 has been marked as a duplicate of this bug. ***

[llvmbot]

*** Bug llvm/llvm-bugzilla-archive#10160 has been marked as a duplicate of this bug. ***

[llvmbot]

Another testcase with getcwd, boils down to (after preprocessing, removing impossible code paths, etc)

typedef typeof(sizeof(int)) size_t;
extern char *__getcwd_alias (char *__buf, size_t __size) asm ("" "getcwd");
extern char *getcwd (char *__buf, size_t __size)
{
return __getcwd_alias (__buf, __size);
}
char *test(char *buf, int len)
{
return getcwd((char *)buf, len);
}

This bug clang build a hanging vim on Linux unless optimizations are explicitly disabled.

[llvmbot]

Another testcase with getcwd, boils down to (after preprocessing, removing
impossible code paths, etc)

typedef typeof(sizeof(int)) size_t;
extern char *__getcwd_alias (char *__buf, size_t __size) asm ("" "getcwd");
extern char *getcwd (char *__buf, size_t __size)
{
return __getcwd_alias (__buf, __size);
}
char *test(char *buf, int len)
{
return getcwd((char *)buf, len);
}

This bug clang build a hanging vim on Linux unless optimizations are explicitly
disabled.

s/clang/causes clang to/

[llvmbot]

Dragonegg turns this into

define i32 @​btowc(i32 %__c) nounwind uwtable inlinehint {
entry:
%0 = tail call i32 @"\01btowc"(i32 %__c) nounwind
ret i32 %0
}

declare i32 @"\01btowc"(i32)

define i32 @​f(i32 %x) nounwind uwtable {
entry:
%0 = tail call i32 @"\01btowc"(i32 %x) nounwind
ret i32 %0
}

which results in f being codegened as

    jmp     btowc

[llvmbot]

Is this still a problem for clang? This is what I'm getting now:

$ cat test.c
#include <wchar.h>
int main () {
return btowc ('\0');
}

$ clang test.c -o - -S -emit-llvm -O
; ModuleID = 'test.c'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.7.2"

define i32 @​main() nounwind uwtable ssp {
entry:
%call = tail call i32 @​btowc(i32 0) nounwind
ret i32 %call
}

declare i32 @​btowc(i32)

$ cat > test.c
typedef __typeof(+L'a') wint_t;
extern wint_t __btowc_alias (int __c) __asm ("btowc");
__attribute((nothrow)) inline wint_t btowc (int __c) {
return __btowc_alias (__c);
}
int f(int x) { return btowc(x); }

$ clang test.c -o - -S -emit-llvm -O
; ModuleID = 'test.c'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.7.2"

define i32 @​f(i32 %x) nounwind uwtable ssp {
entry:
%call.i = tail call i32 @"\01btowc"(i32 %x) nounwind
ret i32 %call.i
}

declare i32 @"\01btowc"(i32)

$ cat > test.c
extern char *__realpath_alias (__const char *__restrict __name, char
*__restrict __resolved) asm ("" "realpath");

extern char *
realpath (__const char *__restrict __name, char *__restrict __resolved) {
return __realpath_alias (__name, __resolved);
}

char *f(const char *path, char *buf) {
return realpath(path, buf);
}

$ clang test.c -o - -S -emit-llvm -O
; ModuleID = 'test.c'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.7.2"

define i8* @​realpath(i8* noalias %__name, i8* noalias %__resolved) nounwind uwtable ssp {
entry:
%call = tail call i8* @"\01realpath"(i8* %__name, i8* %__resolved) nounwind
ret i8* %call
}

declare i8* @"\01realpath"(i8*, i8*)

define i8* @​f(i8* %path, i8* %buf) nounwind uwtable ssp {
entry:
%call.i = tail call i8* @"\01realpath"(i8* %path, i8* %buf) nounwind
ret i8* %call.i
}

$ cat > test.c
typedef typeof(sizeof(int)) size_t;
extern char *__getcwd_alias (char *__buf, size_t __size) asm ("" "getcwd");
extern char *getcwd (char *__buf, size_t __size) {
return __getcwd_alias (__buf, __size);
}
char *test(char *buf, int len) {
return getcwd((char *)buf, len);
}

$ clang test.c -o - -S -O -emit-llvm
; ModuleID = 'test.c'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.7.2"

define i8* @​getcwd(i8* %__buf, i64 %__size) nounwind uwtable ssp {
entry:
%call = tail call i8* @"\01getcwd"(i8* %__buf, i64 %__size) nounwind
ret i8* %call
}

declare i8* @"\01getcwd"(i8*, i64)

define i8* @​test(i8* %buf, i32 %len) nounwind uwtable ssp {
entry:
%conv = sext i32 %len to i64
%call.i = tail call i8* @"\01getcwd"(i8* %buf, i64 %conv) nounwind
ret i8* %call.i
}

[ismail]

Is this still a problem for clang? This is what I'm getting now:

Still reproducable on Linux with

[/kutu/stuff]> clang -v
SUSE Linux clang version 3.0 (branches/release_30 142341) (based on LLVM 3.0)
Target: x86_64-unknown-linux-gnu
Thread model: posix

And AFAIK it only affects Linux.

[llvmbot]

Is this still a problem for clang? This is what I'm getting now:

Still reproducable on Linux with

[/kutu/stuff]> clang -v
SUSE Linux clang version 3.0 (branches/release_30 142341) (based on LLVM 3.0)
Target: x86_64-unknown-linux-gnu
Thread model: posix

And AFAIK it only affects Linux.

Interesting. When I took your IR example from the fist comment and ran it through 'opt' it generated IR which looked just fine. And the result was a 'jmp btowc' command, like Duncan's.

Can you investigate further? I don't have easy access to a Linux box..

[ismail]

I can only reproduce the problem with my original testcase from bug 10160 , http://llvm.org/bugs/attachment.cgi?id=6754

[llvmbot]

Interesting. When I took your IR example from the fist comment and ran it
through 'opt' it generated IR which looked just fine. And the result was a 'jmp
btowc' command, like Duncan's.

Can you investigate further? I don't have easy access to a Linux box..

I just remembered that I do have access to a Linux box. All of the tests I ran give the result as "ret i8* undef" (or some variation on that) with `-O'. Almost certainly not what you're looking for.