From bugzilla-daemon at cs.uiuc.edu Thu Oct 1 12:34:57 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 1 Oct 2009 12:34:57 -0500
Subject: [LLVMbugs] [Bug 5114] New: LLVMContext memory leaks!
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5114
Summary: LLVMContext memory leaks!
Product: libraries
Version: 2.6
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: critical
Priority: P2
Component: Core LLVM classes
AssignedTo: unassignedbugs at nondot.org
ReportedBy: DevOmem at web.de
CC: llvmbugs at cs.uiuc.edu
The program that will allocate and destroy LLVMContext many many times, will
crash due to memory leaks.
This program should in ideal case for days or weeks but usually becomes
unusable after some 1000 LLVMContext allocations and deletions.
This is really big problem that for now seems to have no solution!
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Thu Oct 1 17:11:56 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 1 Oct 2009 17:11:56 -0500
Subject: [LLVMbugs] [Bug 5116] New: x86-64 JIT omits stubs in some cases
they're needed
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5116
Summary: x86-64 JIT omits stubs in some cases they're needed
Product: libraries
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Backend: X86
AssignedTo: unassignedbugs at nondot.org
ReportedBy: jyasskin at google.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=3598)
--> (http://llvm.org/bugs/attachment.cgi?id=3598)
JITTest.cpp addition to provoke the bug
The attached unit test generates the following assembly:
0x00007ffff7f45010 : sub $0x8,%rsp
0x00007ffff7f45014 : mov $0x7,%edi
0x00007ffff7f45019 : callq 0x800000427cd8
0x00007ffff7f4501e : add $0x8,%rsp
0x00007ffff7f45022 : retq
where the intended target function is actually at address 0x427cd8. This
appears to be happening because the actual 64-bit offset gets truncated to 32
bits when it's stored into the callq instruction. This will only happen on
x86-64 systems when JIT code is allocated into memory far away from the
pre-compiled code segment. If lazy compilation is enabled, or the function is
looked up via dlsym instead of addGlobalMapping, the error doesn't happen.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Thu Oct 1 18:57:02 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 1 Oct 2009 18:57:02 -0500
Subject: [LLVMbugs] [Bug 5117] New: Simplification of multiple array
initializations
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5117
Summary: Simplification of multiple array initializations
Product: new-bugs
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Keywords: code-quality, new-feature
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: bearophile at mailas.com
CC: llvmbugs at cs.uiuc.edu
Unlike C, the D language always initializes all variables and dynamic arrays,
so sometimes it wastes some time in useless initializations, especially for
arrays.
The back-end of the D LDC compiler is LLVM, so I'd like LLVM to recognize
*basic* cases of multiple initialization and simplify them away.
Doing it in general may be not easy, but for remove the D wasted
initializations just a basic recognition is enough (also changing LDC itself
too a little).
SO for this C code:
#include "stdlib.h"
#define N 10000
int foo(int n) {
int i;
int *arr = calloc(N, sizeof(int));
for (i = 0; i < N; i++)
arr[i] = 0;
for (i = 0; i < N; i++)
arr[i] = 10;
for (i = 0; i < N; i++)
arr[i] = i;
return arr[n];
}
I'd like LLVM to produce something like this (note it uses a malloc and keeps
only the third loop, while the C code uses a calloc. The SimplifyLibCalls pass
may perform such simplification calloc->malloc):
define i32 @foo(i32 %n) nounwind {
bb1.thread:
%0 = malloc [10000 x i32] ; <[10000 x i32]*> [#uses=2]
br label %bb1
bb1: ; preds = %bb1, %bb1.thread
%i.0.reg2mem.0 = phi i32 [ 0, %bb1.thread ], [ %indvar.next, %bb1 ] ;
[#uses=3]
%1 = getelementptr [10000 x i32]* %0, i32 0, i32 %i.0.reg2mem.0 ;
[#uses=1]
store i32 %i.0.reg2mem.0, i32* %1, align 4
%indvar.next = add i32 %i.0.reg2mem.0, 1 ; [#uses=2]
%exitcond = icmp eq i32 %indvar.next, 10000 ; [#uses=1]
br i1 %exitcond, label %bb2, label %bb1
bb2: ; preds = %bb1
%2 = getelementptr [10000 x i32]* %0, i32 0, i32 %n ; [#uses=1]
%3 = load i32* %2, align 4 ; [#uses=1]
ret i32 %3
}
---------------------------------------------------------
Just for reference this is a similar example of D code:
int foo(int n) {
auto arr = new int[10_000];
for (int i; i < arr.length; i++)
arr[i] = 0;
arr[] = 10; // sets all arr to 10
foreach (i, ref el; arr)
el = i;
return arr[n];
}
This is how the LDC head compiler currently compiles it:
foo:
pushl %ebx
pushl %edi
pushl %esi
subl $16, %esp
movl $10000, 4(%esp)
movl $_D11TypeInfo_Ai6__initZ, (%esp)
xorl %esi, %esi
movl %eax, %edi
call _d_newarrayT
movl %eax, %ebx
.align 16
.LBB1_1:
movl $0, (%ebx,%esi,4)
incl %esi
cmpl $10000, %esi
jne .LBB1_1
movl %ebx, (%esp)
movl $10, 8(%esp)
movl $10000, 4(%esp)
call _d_array_init_i32
xorl %eax, %eax
.align 16
.LBB1_3:
movl %eax, (%ebx,%eax,4)
incl %eax
cmpl $10000, %eax
jne .LBB1_3
movl (%ebx,%edi,4), %eax
addl $16, %esp
popl %esi
popl %edi
popl %ebx
ret
Note the call to _d_array_init_i32 to perform:
the arr[] = 10;
This is where LDC itself may need to be improved (splitting that call in two
parts, allocation and initialization, giving LLVM a better chance to remove the
initialization where it's redundant).
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Thu Oct 1 19:27:08 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 1 Oct 2009 19:27:08 -0500
Subject: [LLVMbugs] [Bug 5037] arm_neon.h float32_t is not compatible with
float
In-Reply-To:
Message-ID: <200910020027.n920R87e001699@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5037
Bob Wilson changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #6 from Bob Wilson 2009-10-01 19:27:07 ---
This should be fixed now. svn revisions 83226, 83227, and 83228.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Fri Oct 2 04:48:30 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 2 Oct 2009 04:48:30 -0500
Subject: [LLVMbugs] [Bug 5119] New: Autoconf test for "cdecl" fails on OS X
compiling Ruby 1.9/ trunk
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5119
Summary: Autoconf test for "cdecl" fails on OS X compiling Ruby
1.9/trunk
Product: Build scripts
Version: trunk
Platform: Macintosh
OS/Version: MacOS X
Status: NEW
Severity: normal
Priority: P2
Component: autoconf
AssignedTo: unassignedbugs at nondot.org
ReportedBy: roberto at freebsd.org
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=3602)
--> (http://llvm.org/bugs/attachment.cgi?id=3602)
config.log from clang
The configure for Ruby script tries to find what needs to be used for "cdecl"
function attributes. It seems that either the test is flawed or clang has a
different behaviour.
configure is run with
CC=clang CFLAGS="-Os -m64" LDFLAGS="-m64"
Configure test is the following:
-----
AC_DEFUN([RUBY_FUNC_ATTRIBUTE], [dnl
m4_ifval([$2], dnl
[AS_VAR_PUSHDEF([attrib],[$2])], dnl
[AS_VAR_PUSHDEF([attrib],[FUNC_]AS_TR_CPP($1))] dnl
)dnl
m4_ifval([$3], dnl
[AS_VAR_PUSHDEF([rbcv],[$3])], dnl
[AS_VAR_PUSHDEF([rbcv],[rb_cv_func_][$1])]dnl
)dnl
m4_ifval([$4], [rbcv_cond=[$4]; test "$rbcv_cond" || unset rbcv_cond])
AC_CACHE_CHECK(for [$1] function attribute, rbcv,
[rbcv=x
if test "${ac_c_werror_flag+set}"; then
rb_c_werror_flag="$ac_c_werror_flag"
else
unset rb_c_werror_flag
fi
ac_c_werror_flag=yes
for mac in "__attribute__ (($1)) x" "x __attribute__ (($1))" "__declspec($1) x"
x; do
m4_ifval([$4],mac="$mac"${rbcv_cond+" /* only if $rbcv_cond */"})
AC_TRY_COMPILE(
m4_ifval([$4],${rbcv_cond+[@%:@if ]$rbcv_cond})
[@%:@define ]attrib[(x) $mac]
m4_ifval([$4],${rbcv_cond+[@%:@else]}
${rbcv_cond+[@%:@define ]attrib[(x) x]}
${rbcv_cond+[@%:@endif]})
attrib[(void conftest_attribute_check(void));], [],
[rbcv="$mac"; break])
done
if test "${rb_c_werror_flag+set}"; then
ac_c_werror_flag="$rb_c_werror_flag"
else
unset ac_c_werror_flag
fi
])
if test "$rbcv" != x; then
RUBY_DEFINE_IF([${rbcv_cond}], attrib[(x)], $rbcv)
fi
AS_VAR_POPDEF([attrib])
AS_VAR_POPDEF([rbcv])
])
RUBY_FUNC_ATTRIBUTE(noreturn, NORETURN)
RUBY_FUNC_ATTRIBUTE(deprecated, DEPRECATED)
RUBY_FUNC_ATTRIBUTE(noinline, NOINLINE)
if_i386=${universal_binary+[defined __i386__]}
RUBY_FUNC_ATTRIBUTE(stdcall, [], [], ${if_i386})
RUBY_FUNC_ATTRIBUTE(cdecl, [], [], ${if_i386})
RUBY_FUNC_ATTRIBUTE(fastcall, [], [], ${if_i386})
-----
The failing one is
RUBY_FUNC_ATTRIBUTE(cdecl, [], [], ${if_i386})
because the config.h ends up with
#define FUNC_CDECL(x) __declspec(cdecl) x
gcc 4.2 manage to get this correctly (see config.log.gcc)
Attached are config.log (clang) and config.log.gcc.
Clang is trunk at r82982.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sat Oct 3 02:14:16 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 3 Oct 2009 02:14:16 -0500
Subject: [LLVMbugs] [Bug 5126] New: JIT should use non-stub address outside
of calls
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5126
Summary: JIT should use non-stub address outside of calls
Product: libraries
Version: trunk
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Target-Independent JIT
AssignedTo: unassignedbugs at nondot.org
ReportedBy: jyasskin at google.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=3604)
--> (http://llvm.org/bugs/attachment.cgi?id=3604)
Test provoking the bug
The JIT uses stubs for a couple purposes: retargeting dlsym-found external
functions, lazily compiling internal functions, and on x86-64 calling functions
defined more than 32 bits away from the call site. For at least far calls, that
stub should only be used for calls, and not for other uses of the address.
The attached patch demonstrates that external functions when lazy compilation
is turned on copy the stub's address into a return value, and when PR5116 is
fixed a similar test will show that simple far calls use the stub's address
too.
Unladen Swallow ran into this because we're trying to use "%1 = load fptr; cmp
%1, @global" to guard inlined calls to @global, but %1 can't possibly match a
stub.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sat Oct 3 05:35:41 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 3 Oct 2009 05:35:41 -0500
Subject: [LLVMbugs] [Bug 5127] New: Non-type template arguments not parsed
correctly in default arguments
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5127
Summary: Non-type template arguments not parsed correctly in
default arguments
Product: clang
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: parser
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: sebastian.redl at getdesigned.at
CC: llvmbugs at cs.uiuc.edu
A poster on comp.std.c++ brought up a bug in GCC where the compiler doesn't
compile this code:
template struct A {};
struct B {
B(A arg = A()) {}
};
When I tried it out in Clang, I found that it won't compile it either. This is
really peculiar, since I really don't think anything is wrong with this. It
does compile if there is only one template parameter, but the comma is
apparently taken to end the argument.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sat Oct 3 06:50:38 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 3 Oct 2009 06:50:38 -0500
Subject: [LLVMbugs] [Bug 5128] New: miscompiles led.c:led_create_state from
the FreeBSD kernel
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5128
Summary: miscompiles led.c:led_create_state from the FreeBSD
kernel
Product: new-bugs
Version: trunk
Platform: PC
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: pawel.worach at gmail.com
CC: llvmbugs at cs.uiuc.edu, rdivacky at freebsd.org
Blocks: 3696
Created an attachment (id=3605)
--> (http://llvm.org/bugs/attachment.cgi?id=3605)
led.i
This is a somewhat vague report just to get this bug going, Roman will fill in
the details.
In the led_create_state() function in led.c the call sc->func() fails, it end
up with a page fault panic where it looks like func points to led_list which is
accessed in the LIST_HEAD_INSERT macro.
Now I the code is changed to insert a printf between there like this it works:
LIST_INSERT_HEAD(&led_list, sc, list);
printf("hello\n");
sc->func(sc->private, state != 0);
Attached you can find the preprocessed led.c, the original asm output as
led-broken.s and the "fixed" asm output where the printf was inserted.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sat Oct 3 17:02:36 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 3 Oct 2009 17:02:36 -0500
Subject: [LLVMbugs] [Bug 5129] New: Ttrigonometric benchmark
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5129
Summary: Ttrigonometric benchmark
Product: new-bugs
Version: 2.5
Platform: PC
OS/Version: Windows XP
Status: NEW
Keywords: code-quality
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: bearophile at mailas.com
CC: llvmbugs at cs.uiuc.edu
This is a simple trigonometric benchmark in C, shows some ways LLVM may improve
its generated code:
#include "math.h"
#include "stdio.h"
void test(double nloops) {
double rsin = 0.0;
double rcos = 0.0;
double rtan = 0.0;
double rlog = 0.0;
double i = 0.0;
while (i < nloops) {
rsin = sin(i);
rcos = cos(i);
rtan = tan(i);
//rtan = rsin / rcos;
rlog = log10(i);
i++;
}
printf(" i: %f\n", i);
printf(" sin: %f\n", rsin);
printf(" cos: %f\n", rcos);
printf(" tan: %f\n", rtan);
printf(" log10: %f\n", rlog);
}
int main() {
double n = 20*1000*1000;
test(n);
return 0;
}
Main loop of the C code compile with LLVM-GCC 2.5 on Windows:
llvm-gcc -Wall -O3 -s -fomit-frame-pointer -msse3 -march=native -ffast-math
bench.c -o bench_llvm
...>elaps bench_llvm.exe
i: 20000000.000000
sin: -0.956130
cos: -0.292941
tan: 3.263897
log10: 7.301030
0.00user 0.03system 0:15.18elapsed 0%CPU (0avgtext+0avgdata 8768maxresident)k
0inputs+0outputs (625major+0minor)pagefaults 0swaps
Note the calls to _log10m, _sin, _cos, _tan, and the amount of code after the
call to _sin:
LBB1_2: # bb
movsd 72(%esp), %xmm0
movsd %xmm0, (%esp)
call _log10
fstpt 56(%esp)
movsd 72(%esp), %xmm0
movsd %xmm0, (%esp)
call _tan
fstpt 40(%esp)
movsd 72(%esp), %xmm0
movsd %xmm0, (%esp)
call _cos
fstpt 24(%esp)
movsd 72(%esp), %xmm0
movsd %xmm0, (%esp)
call _sin
fstpl 80(%esp)
fldt 24(%esp)
fstpl 88(%esp)
fldt 40(%esp)
fstpl 96(%esp)
fldt 56(%esp)
fstpl 104(%esp)
movsd 72(%esp), %xmm0
addsd LCPI1_0, %xmm0
movsd %xmm0, 72(%esp)
ucomisd 120(%esp), %xmm0
movsd 104(%esp), %xmm0
movsd %xmm0, 56(%esp)
movsd 96(%esp), %xmm0
movsd %xmm0, 40(%esp)
movsd 88(%esp), %xmm0
movsd %xmm0, 24(%esp)
movsd 80(%esp), %xmm0
movsd %xmm0, 16(%esp)
##FP_REG_KILL
jb LBB1_2 # bb
---------------------------
Main loop C GCC:
gcc version 4.3.3-dw2-tdm-1 (GCC)
gcc -Wall -O3 -s -fomit-frame-pointer -msse3 -march=native -ffast-math bench.c
-o bench_gcc
GCC:
...>elaps bench_gcc.exe
i: 20000000.000000
sin: -0.956130
cos: -0.292941
tan: 3.263897
log10: 7.301030
0.01user 0.00system 0:04.09elapsed 0%CPU (0avgtext+0avgdata 8800maxresident)k
0inputs+0outputs (628major+0minor)pagefaults 0swaps
Note the use of fsincos, fptan, fldlg2, fyl2x and the tight code after fyl2x:
L10:
fstp %st(3)
fstp %st(0)
L6:
fld %st(0)
fsincos
fld %st(2)
fptan
fxch %st(1)
fstpl 48(%esp)
fldlg2
fld %st(4)
fyl2x
fstpl 56(%esp)
faddp %st, %st(3)
fxch %st(3)
fcomi %st(2), %st
ja L10
---------------------------
LLVM-GCC on Windows without SSE:
llvm-gcc -Wall -O3 -s -fomit-frame-pointer -S -ffast-math bench.c -o
bench_llvm.s
...>elaps bench_llvm
i: 20000000.000000
sin: -0.956130
cos: -0.292941
tan: 3.263897
log10: 7.301030
0.00user 0.01system 0:10.62elapsed 0%CPU (0avgtext+0avgdata 8672maxresident)k
0inputs+0outputs (560major+0minor)pagefaults 0swaps
It's faster.
Note the lack of calls to _sin, _cos and _tan, the usage of fsin, fcos,
the call to _log10 and the short code after fsin.
LBB1_2: # bb
fldl 52(%esp)
fstpl (%esp)
call _log10
fstpl 36(%esp)
fldl 52(%esp)
fstpl (%esp)
call _tan
fstpl 28(%esp)
fld1
fldl 52(%esp)
faddp %st(1)
fstl 44(%esp)
fldl 64(%esp)
fxch %st(1)
fucomi %st(1), %st(0)
fstp %st(1)
fldl 52(%esp)
fcos
fstpl 20(%esp)
fldl 52(%esp)
fsin
fstpl 12(%esp)
fstpl 52(%esp)
##FP_REG_KILL
jb LBB1_2 # bb
---------------------------
Main loop C GCC with division instead of tan:
gcc -Wall -O3 -s -fomit-frame-pointer -msse3 -march=native -ffast-math bench.c
-o bench_gcc
...>elaps bench_gcc
i: 20000000.000000
sin: -0.956130
cos: -0.292941
tan: 3.263897
log10: 7.301030
0.00user 0.00system 0:02.61elapsed 0%CPU (0avgtext+0avgdata 8544maxresident)k
0inputs+0outputs (553major+0minor)pagefaults 0swaps
This is how (with -ffast-math) the code may be compiled. fptan is replaced by
a (unsafe) division.
L10:
fstp %st(2)
fstp %st(0)
L6:
fld %st(0)
fsincos
fld %st(1)
fdiv %st(1), %st
fstpl 48(%esp)
fldlg2
fld %st(3)
fyl2x
fstpl 56(%esp)
fxch %st(2)
fadds LC2
fcomi %st(3), %st
jb L10
---------------------------
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sat Oct 3 18:48:09 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 3 Oct 2009 18:48:09 -0500
Subject: [LLVMbugs] [Bug 4047] permit configure --enable-targets=host,
cpp for example
In-Reply-To:
Message-ID: <200910032348.n93Nm9cv027540@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=4047
Jeffrey Yasskin changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #4 from Jeffrey Yasskin 2009-10-03 18:48:08 ---
Committed in r82634.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sun Oct 4 07:30:14 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 4 Oct 2009 07:30:14 -0500
Subject: [LLVMbugs] [Bug 5130] New: missed check for NULL and wrong value in
structure
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5130
Summary: missed check for NULL and wrong value in structure
Product: clang
Version: unspecified
Platform: PC
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: rdivacky at freebsd.org
CC: llvmbugs at cs.uiuc.edu
we see miscompilation of FreeBSD kernel with TOT llvm/clang
the attached test case is basically this code:
static struct taskqueue *
_taskqueue_create(const char *name, int mflags,
taskqueue_enqueue_fn enqueue, void *context,
int mtxflags, const char *mtxname)
{
struct taskqueue *queue;
queue = malloc(sizeof(struct taskqueue), M_TASKQUEUE, mflags | M_ZERO);
(1) if (!queue)
return NULL;
STAILQ_INIT(&queue->tq_queue);
queue->tq_name = name;
queue->tq_enqueue = enqueue;
queue->tq_context = context;
queue->tq_spin = (mtxflags & MTX_SPIN) != 0;
(2) queue->tq_flags |= TQ_FLAGS_ACTIVE;
mtx_init(&queue->tq_mutex, mtxname, NULL, mtxflags);
return queue;
}
there are two miscompilations on amd64 (and I think on i386 too). (the
generated asm attached)
1) there is a check for queue being NULL at (1) which is ommited in the
generated asm
2) the code at (2) is
return queue;
}
there are two miscompilations on amd64 (and I think on i386 too). (the
generated asm attached)
1) there is a check for queue being NULL at (1) which is ommited in the
generated asm
2) the code at (2) is
queue->tq_spin = (mtxflags & 0x00000001) != 0;
gcc generates this code:
orl $1, 96(%rbx)
while clang/llvm generates
movl $-1, 96(%r13)
these bugs are quite recent as I recall compiling a running FreeBSD kernel as
of roughly 2 weeks ago.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sun Oct 4 08:54:29 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 4 Oct 2009 08:54:29 -0500
Subject: [LLVMbugs] [Bug 5131] New: Initializer elements accepted by gcc are
rejected by clang
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5131
Summary: Initializer elements accepted by gcc are rejected by
clang
Product: clang
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Semantic Analyzer
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: bagnara at cs.unipr.it
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=3610)
--> (http://llvm.org/bugs/attachment.cgi?id=3610)
Complete testcase.
Clang rejects this code, which is taken from the GCC manual:
static const int array[] = { &&foo - &&foo,
&&bar - &&foo,
&&hack - &&foo };
The error given is:
cgoto.c:8:30: error: initializer element is not a compile-time constant
static const int array[] = { &&foo - &&foo,
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sun Oct 4 13:58:26 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 4 Oct 2009 13:58:26 -0500
Subject: [LLVMbugs] [Bug 5132] New: apparent clang wrong code at -O0
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5132
Summary: apparent clang wrong code at -O0
Product: new-bugs
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: regehr at cs.utah.edu
CC: llvmbugs at cs.uiuc.edu
I think 1 is the right answer.
regehr at john-home:~/volatile/tmp202$ clang small.c -o small
regehr at john-home:~/volatile/tmp202$ ./small
checksum = 0
regehr at john-home:~/volatile/tmp202$ clang small.c -o small -O
regehr at john-home:~/volatile/tmp202$ ./small
checksum = 1
regehr at john-home:~/volatile/tmp202$ clang -v
clang version 1.1 (http://llvm.org/svn/llvm-project/cfe/trunk 83272)
Target: i386-pc-linux-gnu
Thread model: posix
regehr at john-home:~/volatile/tmp202$ cat small.c
#include
#include
uint8_t g_14 = 250;
volatile uint64_t g_91;
uint8_t g_151;
int32_t func_16 (int8_t p_19, int64_t p_20);
int32_t func_16 (int8_t p_19, int64_t p_20)
{
return p_20;
}
int32_t func_35 (int64_t p_38);
int32_t func_35 (int64_t p_38)
{
if (func_16 (g_14, 1 <= g_14))
for (g_91 = 1; 1; )
return 1;
return 1;
}
int main (void)
{
func_35 (1);
printf ("checksum = %lld\n", g_91);
return 0;
}
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sun Oct 4 16:40:05 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 4 Oct 2009 16:40:05 -0500
Subject: [LLVMbugs] [Bug 5133] New: SingleSource/Benchmarks/Misc/oourafft. c
fails to build on FreeBSD
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5133
Summary: SingleSource/Benchmarks/Misc/oourafft.c fails to build
on FreeBSD
Product: Test Suite
Version: trunk
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Nightly Tester
AssignedTo: unassignedbugs at nondot.org
ReportedBy: pawel.worach at gmail.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=3612)
--> (http://llvm.org/bugs/attachment.cgi?id=3612)
oourafft.c.diff
FreeBSD does not have nor memalign, it does however have
posix_memalign.
Attached is a quick patch to make the test at least compile and run. Not sure
about the correctness regarding alignment if the test depends on alignment.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sun Oct 4 21:48:20 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 4 Oct 2009 21:48:20 -0500
Subject: [LLVMbugs] [Bug 5130] missed check for NULL and wrong value in
structure
In-Reply-To:
Message-ID: <200910050248.n952mK9H006823@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5130
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #7 from Chris Lattner 2009-10-04 21:48:19 ---
Fixed:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090928/088297.html
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 5 01:16:53 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 5 Oct 2009 01:16:53 -0500
Subject: [LLVMbugs] [Bug 5133] SingleSource/Benchmarks/Misc/oourafft. c
fails to build on FreeBSD
In-Reply-To:
Message-ID: <200910050616.n956Gr3o032674@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5133
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Chris Lattner 2009-10-05 01:16:52 ---
Looks good to me, applied in r83298!
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 5 03:31:57 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 5 Oct 2009 03:31:57 -0500
Subject: [LLVMbugs] [Bug 5130] missed check for NULL and wrong value in
structure
In-Reply-To:
Message-ID: <200910050831.n958VvCt030193@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5130
Roman Divacky changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #9 from Roman Divacky 2009-10-05 03:31:57 ---
the second issue, the
movl $-1, 96(%rbx)
instead of
orl $1, 96(%rbx)
is still there in the testcase
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 5 16:01:25 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 5 Oct 2009 16:01:25 -0500
Subject: [LLVMbugs] [Bug 5130] missed check for NULL and wrong value in
structure
In-Reply-To:
Message-ID: <200910052101.n95L1PqC029771@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5130
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #11 from Chris Lattner 2009-10-05 16:01:24 ---
Ok, we're tracking -fno-builtin stuff in other bugs, this issue (malloc
compare) is fixed.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 5 16:44:24 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 5 Oct 2009 16:44:24 -0500
Subject: [LLVMbugs] [Bug 5128] miscompiles led.c:led_create_state from the
FreeBSD kernel
In-Reply-To:
Message-ID: <200910052144.n95LiOKj003471@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5128
Pawel Worach changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #4 from Pawel Worach 2009-10-05 16:44:24 ---
The 5130 band aid also fixed this problem.
*** This bug has been marked as a duplicate of bug 5130 ***
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 5 17:41:07 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 5 Oct 2009 17:41:07 -0500
Subject: [LLVMbugs] [Bug 5135] New: int/double conversion problems in
profile info
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5135
Summary: int/double conversion problems in profile info
Product: new-bugs
Version: trunk
Platform: PC
OS/Version: NetBSD
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: eocallaghan at auroraux.org
CC: llvmbugs at cs.uiuc.edu
Good day,
When building on NetBSD/SPARC64 I noticed two worrying warnings:
[ 23%] Building CXX object
lib/Analysis/CMakeFiles/LLVMAnalysis.dir/ProfileInfoLoaderPass.cpp.o
/home/edward/llvm/lib/Analysis/ProfileInfoLoaderPass.cpp: In member function
'virtual void::LoaderPass::readEdgeOrRemember(std::pair, std::pair&, unsigned int&, unsigned int&)':
/home/edward/llvm/lib/Analysis/ProfileInfoLoaderPass.cpp:94: warning:
converting to 'unsigned int' from 'double'
[ 24%] Building CXX object
lib/Analysis/CMakeFiles/LLVMAnalysis.dir/ProfileVerifierPass.cpp.o
/home/edward/llvm/lib/Analysis/ProfileVerifierPass.cpp: In member function
'void::ProfileVerifierPass::recurseBasicBlock(const
llvm::BasicBlock*)':
/home/edward/llvm/lib/Analysis/ProfileVerifierPass.cpp:232: warning: converting
to 'int' from 'double'
Looking at lib/Analysis/ProfileInfoLoaderPass.cpp at the function:
void LoaderPass::readEdgeOrRemember(Edge edge, Edge &tocalc,
unsigned &uncalc, unsigned &count) {
double w;
if ((w = getEdgeWeight(edge)) == MissingValue) {
tocalc = edge;
uncalc++;
} else {
count+=w; <----- w is a double, count is a unsigned int.
}
}
Could ddunbar or andreas please look at this code.
Thanks for your time,
Edward.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 5 19:37:40 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 5 Oct 2009 19:37:40 -0500
Subject: [LLVMbugs] [Bug 5116] x86-64 JIT omits stubs in some cases they're
needed
In-Reply-To:
Message-ID: <200910060037.n960be1S026154@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5116
Jeffrey Yasskin changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Jeffrey Yasskin 2009-10-05 19:37:39 ---
I've applied the fix in r83353.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 5 23:33:59 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 5 Oct 2009 23:33:59 -0500
Subject: [LLVMbugs] [Bug 5136] New: LLVM CMake build system fails on Solaris.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5136
Summary: LLVM CMake build system fails on Solaris.
Product: new-bugs
Version: trunk
Platform: PC
OS/Version: SunOS
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: eocallaghan at auroraux.org
CC: llvmbugs at cs.uiuc.edu
The CMake build system can't seem to find mallinfo from malloc.h even though
its defined in /usr/include/malloc.h however the autohell version can? I can't
seem to work out why. Any tips?
See in:
llvm/cmake/config-ix.cmake
The line:
check_symbol_exists(mallinfo malloc.h HAVE_MALLINFO)
Revision: 83318.
Cheers,
Edward.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 5 23:59:07 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 5 Oct 2009 23:59:07 -0500
Subject: [LLVMbugs] [Bug 5136] LLVM CMake build system fails on Solaris.
In-Reply-To:
Message-ID: <200910060459.n964x7J9026764@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5136
Edward O'Callaghan changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #1 from Edward O'Callaghan 2009-10-05 23:59:07 ---
*** This bug has been marked as a duplicate of bug 4758 ***
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Wed Oct 7 05:46:44 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 7 Oct 2009 05:46:44 -0500
Subject: [LLVMbugs] [Bug 5145] New: Some atomic max/umax/min/ umin
intrinsics are not supported on X86 platform
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5145
Summary: Some atomic max/umax/min/umin intrinsics are not
supported on X86 platform
Product: new-bugs
Version: trunk
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: eugeny.grishul at gmail.com
CC: llvmbugs at cs.uiuc.edu
I tried max/min atomic operations on x86 platform( win7 64-bit, intel q9450,
32-bit llvm tools) and following are not work:
@llvm.atomic.load.max.i8.p0i8
@llvm.atomic.load.max.i16.p0i16
@llvm.atomic.load.max.i64.p0i64
@llvm.atomic.load.umax.i8.p0i8
@llvm.atomic.load.umax.i16.p0i16
@llvm.atomic.load.umax.i64.p0i64
@llvm.atomic.load.min.i8.p0i8
@llvm.atomic.load.min.i16.p0i16
@llvm.atomic.load.min.i64.p0i64
@llvm.atomic.load.umin.i8.p0i8
@llvm.atomic.load.umin.i16.p0i16
@llvm.atomic.load.umin.i64.p0i64
For @llvm.atomic.load.max.i8.p0i8 JIT prints something like this:
LLVM ERROR: Cannot yet select: 0x4fdd438: i8,ch = AtomicLoadUMax 0x500bb40,
0x4fedf60, 0x4fdb4d0
Are these intrisics supported on X86 architecture? If not, can you mention in
docs which intrinsic support which platform (I find that
add,sub,xor,or,and,nand,swap works with 8/16/32/64 bit widths, however docs
said that "Not all targets support all bit widths however." for them and
max/min intrinsics ).
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Wed Oct 7 07:42:10 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 7 Oct 2009 07:42:10 -0500
Subject: [LLVMbugs] [Bug 5146] New: Low perf compared to gcc for benchmark
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5146
Summary: Low perf compared to gcc for benchmark
Product: libraries
Version: 2.6
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Scalar Optimizations
AssignedTo: unassignedbugs at nondot.org
ReportedBy: alenhar2 at uiuc.edu
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=3618)
--> (http://llvm.org/bugs/attachment.cgi?id=3618)
bearophile.c
Filed on behalf of bearophile:
See beginning of C file for bearophile's 2.5 timings. I get with llvm 2.6 and
gcc 4.3.4 at his compile options with -fno-math-errno
-funsafe-math-optimizations: 2.7 sec and 2.1 sec respectively (Intel Q6600), so
what ever is the problem hasn't gone completely away in 2.6.
Some potential items from a quick glance through the asm:
tfo_apply has more mmx adds than the gcc one
atan2 (maybe others) are tail calls in gcc but not llvm
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Wed Oct 7 11:05:51 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 7 Oct 2009 11:05:51 -0500
Subject: [LLVMbugs] [Bug 5148] New: bug report
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5148
Summary: bug report
Product: clang
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: hui.chen at arm.com
CC: llvmbugs at cs.uiuc.edu
version (as a result of clang -v):
clang version 1.0 (http://llvm.org/svn/llvm-project/cfe/trunk 80670)
Target: i386-pc-linux-gnu
Thread model: posix
I wrote the simple code (attached) just to test the support of vector
extension.
The excutable generated by clang crashed because of segmentation fault.
The same code compiled by gcc produced the expected result.
I also "gdb"ed the excutable. I find that the clang compiler failed to produce
the right code for the following lines:
ptrV4x = (v4si *) x;
ptrV4y = (v4si *) y;
ptrV4z = (v4si *) z;
cheers
Hui
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Wed Oct 7 12:56:31 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 7 Oct 2009 12:56:31 -0500
Subject: [LLVMbugs] [Bug 5149] New: MIPS code generator crash when compiling
GCC's _muldi3.o
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5149
Summary: MIPS code generator crash when compiling GCC's _muldi3.o
Product: libraries
Version: 2.6
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: Common Code Generator Code
AssignedTo: unassignedbugs at nondot.org
ReportedBy: nbd at openwrt.org
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=3623)
--> (http://llvm.org/bugs/attachment.cgi?id=3623)
Simplified test case
I hit the following failed assertion while trying to build a llvm-gcc mips
cross compiler (llvm, llvm-gcc from the 2.6 release branch, r83451):
Assertion failed: (unsigned(ObjectIdx+NumFixedObjects) < Objects.size() &&
"Invalid Object Idx!"), function setObjectOffset, file
/Users/nbd/llvm/build_dir/host/llvm-2.6_r83451/include/llvm/CodeGen/MachineFrameInfo.h,
line 281.
0 llc 0x0000000100bc6f92 std::vector
>::_M_insert_aux(__gnu_cxx::__normal_iterator > >,
llvm::sys::Path const&) + 8402
1 llc 0x0000000100bc7656 std::vector
>::_M_insert_aux(__gnu_cxx::__normal_iterator > >,
llvm::sys::Path const&) + 10134
2 libSystem.B.dylib 0x00007fff8332c14a _sigtramp + 26
3 libSystem.B.dylib 0x00007fff832d0caa tiny_malloc_from_free_list + 1196
4 libSystem.B.dylib 0x00007fff833a8104 __pthread_markcancel + 0
5 llc 0x000000010025dce2
llvm::MachineFrameInfo::setObjectOffset(int, long long) + 98
6 llc 0x0000000100931d2d llvm::DenseMap, llvm::DenseMapInfo,
llvm::DenseMapInfo >
>::FindAndConstruct(llvm::VNInfo* const&) + 13213
7 llc 0x00000001008f7cdb llvm::sys::Path
llvm::WriteGraph(llvm::MachineFunction const*
const&, std::string const&, bool, std::string const&) + 2363
8 llc 0x0000000100b49faa llvm::FunctionPass::~FunctionPass() +
42906
9 llc 0x0000000100b4a614 llvm::FunctionPass::~FunctionPass() +
44548
10 llc 0x0000000100b4a952 llvm::FunctionPass::~FunctionPass() +
45378
11 llc 0x00000001000203b2 llvm::sys::SmartMutex::release()
+ 24418
12 llc 0x000000010001e828 llvm::sys::SmartMutex::release()
+ 17368
13 llc 0x0000000000000005 llvm::sys::SmartMutex::release()
+ 4294859701
Stack dump:
0. Program arguments: /Users/nbd/llvm/staging_dir/host/bin/llc -o
bugpoint-test-program.bc.llc.s -f bugpoint-test-program.bc
1. Running pass 'Prolog/Epilog Insertion & Frame Finalization' on function
'@__muldi3'
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Wed Oct 7 17:14:19 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 7 Oct 2009 17:14:19 -0500
Subject: [LLVMbugs] [Bug 5150] New: instcombine quadratic in GEP+Phi chain
length
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5150
Summary: instcombine quadratic in GEP+Phi chain length
Product: libraries
Version: trunk
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Scalar Optimizations
AssignedTo: unassignedbugs at nondot.org
ReportedBy: jyasskin at google.com
CC: llvmbugs at cs.uiuc.edu, nlewycky at google.com
Created an attachment (id=3624)
--> (http://llvm.org/bugs/attachment.cgi?id=3624)
Script to generate quadratic assembly
The attached script, when passed an integer argument N, generates an LLVM
assembly file containing a chain of O(N) Phi instructions separated by GEPs:
$ ./instcombine_test.py 3
declare void @use(i32*)
define i32* @foo(i32* %stack) {
%C0 = getelementptr i32* %stack, i32 0
br i1 undef, label %l1a, label %l1b
l1a:
%A1 = getelementptr i32* %C0, i64 1
br label %l1c
l1b:
%B1 = getelementptr i32* %C0, i64 1
br label %l1c
l1c:
%C1 = phi i32* [%A1, %l1a], [%B1, %l1b]
call void @use(i32* %C1)
br i1 undef, label %l2a, label %l2b
l2a:
%A2 = getelementptr i32* %C1, i64 1
br label %l2c
l2b:
%B2 = getelementptr i32* %C1, i64 1
br label %l2c
l2c:
%C2 = phi i32* [%A2, %l2a], [%B2, %l2b]
call void @use(i32* %C2)
ret i32* %C2
}
It's significant here that the phi node inputs are equivalent. The instcombine
pass is quadratic when trying to optimize the chain:
$ for n in 100 200 300 400 500 600; do ./instcombine_test.py
$n|$LLVM/llvm-as|time $LLVM/opt -instcombine >/dev/null;done
0.18 real 0.13 user 0.00 sys
0.51 real 0.44 user 0.00 sys
1.05 real 0.95 user 0.01 sys
1.81 real 1.66 user 0.01 sys
2.70 real 2.53 user 0.01 sys
3.82 real 3.61 user 0.02 sys
Thanks to Nick for helping me find the important chain.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Wed Oct 7 21:37:00 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 7 Oct 2009 21:37:00 -0500
Subject: [LLVMbugs] [Bug 5151] New: Error while generating ARM code with
llvm-gcc
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5151
Summary: Error while generating ARM code with llvm-gcc
Product: libraries
Version: 2.6
Platform: PC
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: Common Code Generator Code
AssignedTo: unassignedbugs at nondot.org
ReportedBy: nbd at openwrt.org
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=3625)
--> (http://llvm.org/bugs/attachment.cgi?id=3625)
Simplified test case
While trying to compile the kernel with an arm llvm-gcc cross toolchain, I get
this error triggered by net/sched/cls_basic.c of linux 2.6.28.10:
Assertion failed: ((!EarlyClobberRegs.test(Reg) ||
MI->isRegTiedToDefOperand(i)) && "Using an early clobbered register!"),
function forward, file RegisterScavenging.cpp, line 221.
0 llc 0x0000000100bc7ef2 std::vector
>::_M_insert_aux(__gnu_cxx::__normal_iterator > >,
llvm::sys::Path const&) + 8402
1 llc 0x0000000100bc85b6 std::vector
>::_M_insert_aux(__gnu_cxx::__normal_iterator > >,
llvm::sys::Path const&) + 10134
2 libSystem.B.dylib 0x00007fff8332c14a _sigtramp + 26
3 libSystem.B.dylib 0x00000001010627f2 _sigtramp + 2111006402
4 libSystem.B.dylib 0x00007fff833a8104 __pthread_markcancel + 0
5 llc 0x000000010095f78f
llvm::RegisterCoalescer::getAnalysisUsage(llvm::AnalysisUsage&) const + 6943
6 llc 0x00000001009303d8 llvm::DenseMap, llvm::DenseMapInfo,
llvm::DenseMapInfo >
>::FindAndConstruct(llvm::VNInfo* const&) + 3192
7 llc 0x0000000100932ccb llvm::DenseMap, llvm::DenseMapInfo,
llvm::DenseMapInfo >
>::FindAndConstruct(llvm::VNInfo* const&) + 13675
8 llc 0x00000001008f8abb llvm::sys::Path
llvm::WriteGraph(llvm::MachineFunction const*
const&, std::string const&, bool, std::string const&) + 2363
9 llc 0x0000000100b4af0a llvm::FunctionPass::~FunctionPass() +
42906
10 llc 0x0000000100b4b574 llvm::FunctionPass::~FunctionPass() +
44548
11 llc 0x0000000100b4b8b2 llvm::FunctionPass::~FunctionPass() +
45378
12 llc 0x0000000100020dc2 llvm::sys::SmartMutex::release()
+ 24418
13 llc 0x000000010001f238 llvm::sys::SmartMutex::release()
+ 17368
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Thu Oct 8 00:08:58 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 8 Oct 2009 00:08:58 -0500
Subject: [LLVMbugs] [Bug 5152] New: llvm-ld removes the reference to global
variable from debug info metadata.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5152
Summary: llvm-ld removes the reference to global variable from
debug info metadata.
Product: tools
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: llvm-ld
AssignedTo: unassignedbugs at nondot.org
ReportedBy: sanjiv.gupta at microchip.com
CC: dpatel at apple.com, llvmbugs at cs.uiuc.edu,
sanjiv.gupta at microchip.com
Created an attachment (id=3626)
--> (http://llvm.org/bugs/attachment.cgi?id=3626)
When llvm-ld processes this bitcode file, it corrupts reference to global
variable from metadata.
Clang generates metadata for global variable which has reference to the global
variable. When bitcode generated by clang is passed to llvm-ld with
-disable-opt option, the reference to global variable in metadata is set to
null.
!0 = metadata !{i32 458804, i32 0, metadata !1, metadata !"i", metadata !"i",
metadata !"", metadata !1, i32 1, metadata !2, i1 false, i1 true, null};
[DW_TAG_variable ]
The last field in metadata is null.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Thu Oct 8 12:55:43 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 8 Oct 2009 12:55:43 -0500
Subject: [LLVMbugs] [Bug 5112] llc from LLVM 2.6 release branch segfaults on
Linux
In-Reply-To:
Message-ID: <200910081755.n98HthWf009203@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5112
Jeffrey Yasskin changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #8 from Jeffrey Yasskin 2009-10-08 12:55:42 ---
r83391 was broken. Really fixed in r83417. Not merged to 2.6.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Thu Oct 8 14:22:45 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 8 Oct 2009 14:22:45 -0500
Subject: [LLVMbugs] [Bug 5155] New: Values should support placement new
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5155
Summary: Values should support placement new
Product: libraries
Version: trunk
Platform: PC
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Core LLVM classes
AssignedTo: unassignedbugs at nondot.org
ReportedBy: jyasskin at google.com
CC: llvmbugs at cs.uiuc.edu
I'm trying to write a test that the ExecutionEngine handles a GlobalVariable
being destroyed and a new one being created at the same address. The normal way
to do this would be to allocate a char[sizeof(GlobalVariable)] and use
placement new to put the GlobalVariable there. This doesn't work for subclasses
of User since it hangs extra data off the start of the object.
It would be nice if placement new (or CreateAt(void*,...) as appropriate) were
defined so we could write this kind of test.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Thu Oct 8 17:28:23 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 8 Oct 2009 17:28:23 -0500
Subject: [LLVMbugs] [Bug 5156] New: clang crashes on incorrect code
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5156
Summary: clang crashes on incorrect code
Product: clang
Version: unspecified
Platform: Macintosh
OS/Version: Mac System 9.x
Status: NEW
Severity: normal
Priority: P2
Component: parser
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: fjahanian at apple.com
CC: llvmbugs at cs.uiuc.edu
Forgot to put expected-note in the comment and clang horribly got confused and
crashed.
test is CXX/Temp/temp.spec/temp.expl.spec/p4.cpp and I just show the diff of my
mistake.
Index: p4.cpp
===================================================================
--- p4.cpp (revision 83583)
+++ p4.cpp (working copy)
@@ -13,7 +13,7 @@
void g() { }
struct Inner {
- T value; // expected-note {{member is declared here}}
+ T value; expected-note {{member is declared here}}
};
static T value;
p4.cpp:16:15: error: unknown type name 'expected'
T value; expected-note {{member is declared here}}
^
p4.cpp:16:23: error: expected member name or ';' after declaration specifiers
T value; expected-note {{member is declared here}}
~~~~~~~~^
p4.cpp:19:12: error: redefinition of 'value' as different kind of symbol
static T value;
^
p4.cpp:16:7: note: previous definition is here
T value; expected-note {{member is declared here}}
^
p4.cpp:22:19: error: declaration of 'T' shadows template parameter
template
^
p4.cpp:7:19: note: template parameter is declared here
template
^
p4.cpp:22:31: error: declaration of 'U' shadows template parameter
template
^
p4.cpp:7:31: note: template parameter is declared here
template
^
p4.cpp:38:6: error: implicit instantiation of undefined template 'struct
X'
void X::f() { }
^
p4.cpp:8:8: note: template is declared here
struct X { // expected-note{{here}}
^
p4.cpp:38:26: error: no function template matches function template
specialization 'f'
void X::f() { }
^
p4.cpp:41:8: error: incomplete type 'struct X' named in
nested name specifier
struct X::Inner {
^~~~~~~~~~~~~~~~~~~~
p4.cpp:8:8: note: forward declaration of 'struct X'
struct X { // expected-note{{here}}
^
p4.cpp:47:11: error: incomplete type 'struct X' named
in nested name specifier
IntHolder X::value = 17;
^~~~~~~~~~~~~~~~~~~~
p4.cpp:8:8: note: forward declaration of 'struct X'
struct X { // expected-note{{here}}
^
p4.cpp:47:31: error: duplicate member 'value'
IntHolder X::value = 17;
^
p4.cpp:23:12: note: previous declaration is here
T X::value; // expected-error{{no matching constructor}}
^
p4.cpp:47:31: error: 'value' can only be initialized if it is a static const
integral data member
IntHolder X::value = 17;
^
p4.cpp:59:1: error: incomplete type 'struct X' named in
nested name specifier
X::X() { } // expected-error{{instantiated member}}
^~~~~~~~~~~~~~~~~~~~
p4.cpp:8:8: note: forward declaration of 'struct X'
struct X { // expected-note{{here}}
^
0 clang-cc 0x0000000101106907 PrintStackTrace(void*) + 38
1 clang-cc 0x0000000101106e95 SignalHandler(int) + 336
2 libSystem.B.dylib 0x00007fff852642fa _sigtramp + 26
3 libSystem.B.dylib 0x0000000000000001 _sigtramp + 2061090081
4 clang-cc 0x00000001003ba251
clang::LocInfoType::classof(clang::Type const*) + 21
5 clang-cc 0x00000001003ba861 bool
llvm::isa_impl(clang::Type const&) + 21
6 clang-cc 0x00000001003ba87b
llvm::isa_impl_wrap::doit(clang::Type const&) + 21
7 clang-cc 0x00000001003ba895 bool
llvm::isa_impl_cl::isa(clang::Type const&) +
21
8 clang-cc 0x00000001003ba8af bool
llvm::isa_impl_cl::isa(clang::Type*) + 21
9 clang-cc 0x00000001003ba8cc bool llvm::isa_impl_cl::isa(clang::Type* const&) + 24
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Fri Oct 9 00:34:01 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 9 Oct 2009 00:34:01 -0500
Subject: [LLVMbugs] [Bug 5155] Values should support placement new
In-Reply-To:
Message-ID: <200910090534.n995Y1oO018532@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5155
Jeffrey Yasskin changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--- Comment #4 from Jeffrey Yasskin 2009-10-09 00:34:00 ---
Ok.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Fri Oct 9 01:13:55 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 9 Oct 2009 01:13:55 -0500
Subject: [LLVMbugs] [Bug 5157] New: ScalarEvolution should canonicalize
nosw/nousw
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5157
Summary: ScalarEvolution should canonicalize nosw/nousw
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: edwintorok at gmail.com
CC: llvmbugs at cs.uiuc.edu
ScalarEvolution only sets the nooverflow flags when creating a SCEV for a PHI
node.
For example if a loop has both an induction variable, and a pointer being
incremented by 1 each loop, then:
induction variable will be <0,+,1> (SubClassData 2),
the pointer will be Base + <0,+,1> (SubClassData 0).
If I extract the offset from the pointer it'll be different from the induction
variable (SubClassData 2!=0), although they are in fact equal.
I think SCEV should canonicalize the subclassdata, and set it for pointers too.
For now I workaround this by recreating the addrec from its operands before
using it (that way subclassdata is always 0).
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Fri Oct 9 01:24:03 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 9 Oct 2009 01:24:03 -0500
Subject: [LLVMbugs] [Bug 5157] ScalarEvolution should canonicalize nosw/nousw
In-Reply-To:
Message-ID: <200910090624.n996O3ha020206@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5157
T??r??k Edwin changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from T??r??k Edwin 2009-10-09 01:24:03 ---
Nevermind, the mismatch was due to an i32/i64 mismatch in their type
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Fri Oct 9 03:59:29 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 9 Oct 2009 03:59:29 -0500
Subject: [LLVMbugs] [Bug 5158] New: ConstructEnumTypeDIE crash with NULL Name
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5158
Summary: ConstructEnumTypeDIE crash with NULL Name
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: baldrick at free.fr
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=3629)
--> (http://llvm.org/bugs/attachment.cgi?id=3629)
testcase .ll
This breaks the llvm-gcc Ada build.
$ llc debug.bc
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct NULL not valid
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Fri Oct 9 06:27:10 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 9 Oct 2009 06:27:10 -0500
Subject: [LLVMbugs] [Bug 5159] New: sroa and other passes does a rotten job
on vector code from the gcc plugin
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5159
Summary: sroa and other passes does a rotten job on vector code
from the gcc plugin
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: baldrick at free.fr
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=3630)
--> (http://llvm.org/bugs/attachment.cgi?id=3630)
testcase .ll
The basic problem with the testcase is that GCC works throughout with
<2 x double>, building up and manipulating parts of <8 x double> using
these. It looks like sroa decides to turn the <2 x double> into giant
integers, and the final result is not happy. It would have been better
to split the <2 x double> into two parts.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Fri Oct 9 11:45:36 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 9 Oct 2009 11:45:36 -0500
Subject: [LLVMbugs] [Bug 5148] bug report
In-Reply-To:
Message-ID: <200910091645.n99GjaXl025655@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5148
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #3 from Chris Lattner 2009-10-09 11:45:35 ---
This code is invalid: the array of integers on the stack is not sufficiently
aligned, so your pointer cast is invalid. Try this:
int __attribute__ ((aligned)) x[4], y[4], z[4];
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Fri Oct 9 12:52:28 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 9 Oct 2009 12:52:28 -0500
Subject: [LLVMbugs] [Bug 5158] ConstructEnumTypeDIE crash with NULL Name
In-Reply-To:
Message-ID: <200910091752.n99HqS1n028112@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5158
devang.patel changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from devang.patel 2009-10-09 12:52:27 ---
Fixed in r83655.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Fri Oct 9 13:19:16 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 9 Oct 2009 13:19:16 -0500
Subject: [LLVMbugs] [Bug 5026] Don't know how to fold this instruction!
In-Reply-To:
Message-ID: <200910091819.n99IJGut029070@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5026
Dan Gohman changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #5 from Dan Gohman 2009-10-09 13:19:16 ---
This is fixed by r83656.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Fri Oct 9 15:24:45 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 9 Oct 2009 15:24:45 -0500
Subject: [LLVMbugs] [Bug 2973] very poor choice by the inliner (code size +
perf)
In-Reply-To:
Message-ID: <200910092024.n99KOjmP001540@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=2973
Dale Johannesen changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dalej at apple.com
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Dale Johannesen 2009-10-09 15:24:44 ---
Hmm, I'm not seeing this; currently clause_NumberSort and
pcheck_ClauseNumberMergeSort are both fully inlined and deleted. I've
implemented a check that should detect this case in 83602 (it fires 28 times in
SPASS, but not in this call stack.) I think we can close this.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Fri Oct 9 15:36:54 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 9 Oct 2009 15:36:54 -0500
Subject: [LLVMbugs] [Bug 5132] codegen miscompile
In-Reply-To:
Message-ID: <200910092036.n99KaslF002039@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5132
Dan Gohman changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Dan Gohman 2009-10-09 15:36:54 ---
That sign-extend is fine; that's part of a clever optimization which is valid
here. The problem is the bogus testb $-1, %al. This is fixed in r83670.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Fri Oct 9 15:52:05 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 9 Oct 2009 15:52:05 -0500
Subject: [LLVMbugs] [Bug 5152] llvm-ld removes the reference to global
variable from debug info metadata.
In-Reply-To:
Message-ID: <200910092052.n99Kq59S002709@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5152
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #2 from Chris Lattner 2009-10-09 15:52:04 ---
This is working as designed.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Fri Oct 9 19:30:35 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 9 Oct 2009 19:30:35 -0500
Subject: [LLVMbugs] [Bug 2595] aggressive-remat triggers bugs
In-Reply-To:
Message-ID: <200910100030.n9A0UZGZ010845@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=2595
Dan Gohman changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #5 from Dan Gohman 2009-10-09 19:30:34 ---
The useful parts of aggressive-remat are now folded into the default
rematerialization support.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Fri Oct 9 20:29:13 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 9 Oct 2009 20:29:13 -0500
Subject: [LLVMbugs] [Bug 5160] New: ValueHandle is easy to confuse with
active CallbackVHs
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5160
Summary: ValueHandle is easy to confuse with active CallbackVHs
Product: libraries
Version: trunk
Platform: PC
OS/Version: All
Status: ASSIGNED
Severity: normal
Priority: P2
Component: Core LLVM classes
AssignedTo: jyasskin at google.com
ReportedBy: jyasskin at google.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=3634)
--> (http://llvm.org/bugs/attachment.cgi?id=3634)
Some tests for the brokenness
When CallbackVHs modify ValueHandles that refer to the same Value, this can
crash the program or cause AssertingVHs to fail when they actually no longer
refer to the Value. I'll be working on a fix.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sat Oct 10 04:06:51 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 10 Oct 2009 04:06:51 -0500
Subject: [LLVMbugs] [Bug 217] LLVM needs a generic update SSA mechanism
In-Reply-To:
Message-ID: <200910100906.n9A96p8X009717@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=217
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Summary|LLVM needs a generic |LLVM needs a generic update
|dominator update mechanism |SSA mechanism
--- Comment #9 from Chris Lattner 2009-10-10 04:06:46 ---
Implemented here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091005/088600.html
Jump threading switched to use it here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091005/088601.html
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sat Oct 10 14:41:35 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 10 Oct 2009 14:41:35 -0500
Subject: [LLVMbugs] [Bug 5161] New: make llvm-test fails to run
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5161
Summary: make llvm-test fails to run
Product: new-bugs
Version: trunk
Platform: Macintosh
OS/Version: MacOS X
Status: NEW
Keywords: build-problem
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: rayfix at gmail.com
CC: llvmbugs at cs.uiuc.edu
ddunbar asked me to file a bug on this issue.
When I run make llvm-test using a cmake makefile style build I get the
following error.
make llvm-test
Running LLVM regression tests
lit.py: lit.cfg:60: fatal: No site specific configuration available!
make[3]: *** [test/CMakeFiles/llvm-test] Error 2
make[2]: *** [test/CMakeFiles/llvm-test.dir/all] Error 2
make[1]: *** [test/CMakeFiles/llvm-test.dir/rule] Error 2
make: *** [llvm-test] Error 2
vsoc-unix-build-540$
(Had some success removing LLVM_SRC_ROOT/test/Unit/lit.cfg)
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sat Oct 10 15:19:23 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 10 Oct 2009 15:19:23 -0500
Subject: [LLVMbugs] [Bug 5162] New:
ExecutionEngine->DisableLazyCompilation() causes crashes on Function
deletion
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5162
Summary: ExecutionEngine->DisableLazyCompilation() causes crashes
on Function deletion
Product: new-bugs
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: ian at mckellar.org
CC: nicholas at mxc.ca, llvmbugs at cs.uiuc.edu
When the execution engine has lazy compilation disabled (so that all dependent
functions are compiled up front) there's a handle to a dependent function
that's held too long. The attached sample code will trigger the assertion, but
the failure goes away if you comment out the call to DisableLazyCompilation().
I'm hitting this because unladen-swallow sets DisableLazyCompilation but it
doesn't look like many other projects do.
I will likely be almost completely offline until mid November so I'm sorry that
I won't be able to respond to comments till then.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sat Oct 10 16:54:10 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 10 Oct 2009 16:54:10 -0500
Subject: [LLVMbugs] [Bug 5163] New: error: token is not a valid binary
operator in a preprocessor subexpression
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5163
Summary: error: token is not a valid binary operator in a
preprocessor subexpression
Product: clang
Version: unspecified
Platform: PC
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: parser
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: rdivacky at freebsd.org
CC: llvmbugs at cs.uiuc.edu
clang cant grok the attached test case:
pes /tmp$ clang -c gstreamer.c
gstreamer.c:15:34: error: token is not a valid binary operator in a
preprocessor subexpression
#if MPEG2_RELEASE < MPEG2_VERSION(0,5,0)
~~~~~~~~~~~~~^
1 diagnostic generated.
pes /tmp$ gcc -c gstreamer.c
pes /tmp$
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sat Oct 10 16:57:08 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 10 Oct 2009 16:57:08 -0500
Subject: [LLVMbugs] [Bug 5163] error: token is not a valid binary operator
in a preprocessor subexpression
In-Reply-To:
Message-ID: <200910102157.n9ALv8Oq001858@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5163
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #2 from Chris Lattner 2009-10-10 16:57:08 ---
*** This bug has been marked as a duplicate of bug 4438 ***
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sat Oct 10 17:18:17 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 10 Oct 2009 17:18:17 -0500
Subject: [LLVMbugs] [Bug 4779] msp430 backend ICE: "#operands for dag node
doesn't match . td file!"
In-Reply-To:
Message-ID: <200910102218.n9AMIH6H002611@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=4779
Anton Korobeynikov changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |asl at math.spbu.ru
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Anton Korobeynikov 2009-10-10 17:18:17 ---
Fixed in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091005/088622.html
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sat Oct 10 17:50:41 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 10 Oct 2009 17:50:41 -0500
Subject: [LLVMbugs] [Bug 5165] New: npoly benchmark
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5165
Summary: npoly benchmark
Product: new-bugs
Version: 2.5
Platform: PC
OS/Version: Windows XP
Status: NEW
Keywords: code-quality
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: bearophile at mailas.com
CC: llvmbugs at cs.uiuc.edu
This is a small benchmark written in C. nicholas on #llvm has said "feel free
to file it in bugzilla for further analysis".
I think this is the origin of this benchmark:
http://openmap.bbn.com/~kanderso/performance/postscript/in-poly.ps
I have cleaned up a little the C code:
// C code, npoly.c
#include "stdio.h"
// return true if (x,y) point is inside the given polygon
int pnpoly(int npol, const double *xp, const double *yp, double x, double y) {
int i, j, c = 0;
for (i = 0, j = npol-1; i < npol; j = i++)
if ((((yp[i] <= y) && (y < yp[j])) ||
((yp[j] <= y) && (y < yp[i]))) &&
(x < (xp[j] - xp[i]) * (y - yp[i]) / (yp[j] - yp[i]) + xp[i]))
c = !c;
return c;
}
int main() {
int npol = 20;
double xp[20] = {0.0,1.0,1.0,0.0,0.0,1.0,-0.5,-1.0,-1.0,-2.0,
-2.5,-2.0,-1.5,-.5,1.0,1.0,0.0,-0.5,-1.0,-.5};
double yp[20] = {0.0,0.0,1.0,1.0,2.0,3.0,2.0,3.0,0.0,-.5,
-1.0,-1.5,-2.0,-2.0,-1.5,-1.0,-.5,-1.0,-1.0,-.5};
int i;
int count = 0;
for (i = 0; i < 1000000; i++) {
if (pnpoly(npol, xp, yp, 0.5, 0.5)) count++;
if (pnpoly(npol, xp, yp, 0.5, 1.5)) count++;
if (pnpoly(npol, xp, yp, -0.5, 1.5)) count++;
if (pnpoly(npol, xp, yp, 0.75, 2.25)) count++;
if (pnpoly(npol, xp, yp, 0.0, 2.01)) count++;
if (pnpoly(npol, xp, yp, -0.5, 2.5)) count++;
if (pnpoly(npol, xp, yp, -1.0, -0.5)) count++;
if (pnpoly(npol, xp, yp, -1.5, 0.5)) count++;
if (pnpoly(npol, xp, yp, -2.25, -1.0)) count++;
if (pnpoly(npol, xp, yp, 0.5, -0.25)) count++;
if (pnpoly(npol, xp, yp, 0.5, -1.25)) count++;
if (pnpoly(npol, xp, yp, -0.5, -2.5)) count++;
}
printf("count %d \n", count);
return 0;
}
Code compiled with (with gcc and llvm-gcc):
llvm-gcc -Wall -O3 -s -fomit-frame-pointer -msse3 -march=native -ffast-math
Using -ftree-vectorizer-verbose=5
Says GCC: note: vectorized 0 loops in function.
Timings, best of 3, seconds:
GCC: 0.87
LLVM-GCC: 1.24
(Feel free to increase the loop count if you have a faster PC.)
Compilers:
LLVM 2.5, V.4.2.1 (Based on Apple Inc. build 5636) (LLVM build)
gcc version 4.3.3-dw2-tdm-1 (GCC)
Windows Vista 32 bit on Celeron 2.13 MHz.
I have compiled the code with the daily build of LDC too (a D version) that
uses the latest LLVM 2.6, with similar results.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sat Oct 10 18:16:26 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 10 Oct 2009 18:16:26 -0500
Subject: [LLVMbugs] [Bug 217] LLVM needs a generic update SSA mechanism
In-Reply-To:
Message-ID: <200910102316.n9ANGQxh004669@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=217
Owen Anderson changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #10 from Owen Anderson 2009-10-10 18:16:25 ---
Chris, I don't think that solves _all_ of what this bug asks for. We're still
lacking a generc dominato r update function.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sat Oct 10 18:17:30 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 10 Oct 2009 18:17:30 -0500
Subject: [LLVMbugs] [Bug 217] LLVM needs a generic update SSA mechanism
In-Reply-To:
Message-ID: <200910102317.n9ANHUJK004723@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=217
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #11 from Chris Lattner 2009-10-10 18:17:30 ---
As originator of the bug, I know what it was about. :) Updating domtree
wasn't the point, that was seen as a way to get to SSA updates.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sun Oct 11 14:16:29 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 11 Oct 2009 14:16:29 -0500
Subject: [LLVMbugs] [Bug 4770] msp430 backend: Assertion `MO.getOffset() ==
0 && " No offsets allowed!"' failed.
In-Reply-To:
Message-ID: <200910111916.n9BJGTcd016191@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=4770
Anton Korobeynikov changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Anton Korobeynikov 2009-10-11 14:16:29 ---
Fixed in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091005/088662.html
the testcase is here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091005/088663.html
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sun Oct 11 16:28:42 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 11 Oct 2009 16:28:42 -0500
Subject: [LLVMbugs] [Bug 5166] New: verifier misses incorrect declaration of
intrinsics ( sometimes)
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5166
Summary: verifier misses incorrect declaration of intrinsics
(sometimes)
Product: libraries
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Core LLVM classes
AssignedTo: unassignedbugs at nondot.org
ReportedBy: nicholas at mxc.ca
CC: llvmbugs at cs.uiuc.edu
This file passes the verifier:
define void @foo() {
call i8* @llvm.returnaddress(i32 0)
ret void
}
declare void @llvm.returnaddress()
but if you flip it around to put the declaration of @llvm.returnaddress first
then it will notice that.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sun Oct 11 18:21:09 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 11 Oct 2009 18:21:09 -0500
Subject: [LLVMbugs] [Bug 5150] instcombine quadratic in GEP+Phi chain length
In-Reply-To:
Message-ID: <200910112321.n9BNL9Td024567@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5150
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Chris Lattner 2009-10-11 18:21:08 ---
This should be greatly improved here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091005/088694.html
If this doesn't fix it, please reopen.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sun Oct 11 20:06:28 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 11 Oct 2009 20:06:28 -0500
Subject: [LLVMbugs] [Bug 5167] New: Failing tests on Solaris.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5167
Summary: Failing tests on Solaris.
Product: new-bugs
Version: trunk
Platform: PC
OS/Version: SunOS
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: eocallaghan at auroraux.org
CC: llvmbugs at cs.uiuc.edu
FAIL:
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/2003-11-13-ConstExprCastCall.ll
Failed with signal(SIGPIPE) at line 1
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/2003-11-13-ConstExprCastCall.ll
-instcombine -S | /usr/bin/ggrep call | notcast
grep: RE error 43: Too many \(.
FAIL:
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/2004-11-27-SetCCForCastLargerAndConstant.ll
Failed with signal(SIGPIPE) at line 1
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/2004-11-27-SetCCForCastLargerAndConstant.ll
-instcombine -S | notcast .*int
grep: RE error 43: Too many \(.
FAIL:
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/2006-04-28-ShiftShiftLongLong.ll
Failed with signal(SIGPIPE) at line 2
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/2006-04-28-ShiftShiftLongLong.ll
-instcombine -S | notcast
grep: RE error 43: Too many \(.
FAIL:
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/2008-01-21-MismatchedCastAndCompare.ll
for PR1940
Failed with signal(SIGPIPE) at line 1
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/2008-01-21-MismatchedCastAndCompare.ll
-instcombine -S | notcast
grep: RE error 43: Too many \(.
FAIL:
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/2008-01-21-MulTrunc.ll
Failed with signal(SIGPIPE) at line 1
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/2008-01-21-MulTrunc.ll
-instcombine -S | notcast
grep: RE error 43: Too many \(.
FAIL:
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/IntPtrCast.ll
Failed with signal(SIGPIPE) at line 1
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/IntPtrCast.ll
-instcombine -S | notcast
grep: RE error 43: Too many \(.
FAIL:
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/apint-cast.ll
Failed with signal(SIGPIPE) at line 1
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/apint-cast.ll
-instcombine -S | notcast
grep: RE error 43: Too many \(.
FAIL:
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/apint-zext1.ll
Failed with signal(SIGPIPE) at line 1
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/apint-zext1.ll
-instcombine -S | notcast {} {%c1.*}
grep: RE error 43: Too many \(.
FAIL:
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/apint-zext2.ll
Failed with signal(SIGPIPE) at line 1
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/apint-zext2.ll
-instcombine -S | notcast {} {%c1.*}
grep: RE error 43: Too many \(.
FAIL:
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/binop-cast.ll
Failed with signal(SIGPIPE) at line 1
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/binop-cast.ll
-instcombine -S | notcast
grep: RE error 43: Too many \(.
FAIL: /export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/call.ll
Failed with signal(SIGPIPE) at line 1
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/call.ll
-instcombine 2> /dev/null -S | /usr/bin/ggrep call | notcast
child killed: write on pipe with no readers
FAIL:
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/cast-mul-select.ll
Failed with signal(SIGPIPE) at line 1
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/cast-mul-select.ll
-instcombine -S | notcast
grep: RE error 43: Too many \(.
FAIL:
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/cast-set.ll
Failed with signal(SIGPIPE) at line 1
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/cast-set.ll
-instcombine -S | notcast
grep: RE error 43: Too many \(.
The following tests now fail on Solaris ( 83817 ) :
FAIL: /export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/cast.ll
Failed with signal(SIGPIPE) at line 1
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/cast.ll
-instcombine -S | /usr/bin/ggrep %c | notcast
grep: RE error 43: Too many \(.
FAIL: /export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/cast2.ll
for PR1263
Failed with signal(SIGPIPE) at line 1
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/cast2.ll
-instcombine -S | notcast
grep: RE error 43: Too many \(.
FAIL: /export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/fpcast.ll
Failed with unknown error (or has stderr output) at line 1
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/fpcast.ll
-instcombine -S | notcast
grep: RE error 43: Too many \(.
FAIL: /export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/zext.ll
for PR3599
Failed with signal(SIGPIPE) at line 1
while running: opt <
/export/home2/edward/lab/llvm/llvm/test/Transforms/InstCombine/zext.ll
-instcombine -S | notcast {} {%c1.*}
grep: RE error 43: Too many \(.
Regards,
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sun Oct 11 23:01:55 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 11 Oct 2009 23:01:55 -0500
Subject: [LLVMbugs] [Bug 4758] cmake out of tree build.
In-Reply-To:
Message-ID: <200910120401.n9C41tWo000697@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=4758
Edward O'Callaghan changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #9 from Edward O'Callaghan 2009-10-11 23:01:54 ---
Fixed, Committed in revision 83819.
Cheers,
Edward.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 12 02:29:51 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 12 Oct 2009 02:29:51 -0500
Subject: [LLVMbugs] [Bug 5167] Failing InstCombine tests on Solaris.
In-Reply-To:
Message-ID: <200910120729.n9C7ToIH008353@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5167
Edward O'Callaghan changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #5 from Edward O'Callaghan 2009-10-12 02:29:50 ---
Fix Committed, revision 83828.
Cheers,
Edward.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 12 02:33:17 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 12 Oct 2009 02:33:17 -0500
Subject: [LLVMbugs] [Bug 5168] New: clang x86-64 abi does not set %rax when
returning struct
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5168
Summary: clang x86-64 abi does not set %rax when returning struct
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: xuzhongxing at gmail.com
CC: llvmbugs at cs.uiuc.edu
x86-64 abi page 22 says "On return %rax will contain the address that has been
passed in by the caller in %rdi". But clang -O2 mode does not set %rax.
$ cat returnbig.c
struct s {
int a[10];
};
struct s f(void) {
struct s x;
return x;
}
$ clang-cc -S -O2 returnbig.c
$ cat returnbig.s
.file "returnbig.c"
.text
.align 16
.globl f
.type f, at function
f:
movq $0, 24(%rdi)
movq $0, 16(%rdi)
movq $0, 8(%rdi)
movq $0, (%rdi)
movq $0, 32(%rdi)
ret
.size f, .-f
.section .note.GNU-stack,"", at progbits
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 12 03:11:00 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 12 Oct 2009 03:11:00 -0500
Subject: [LLVMbugs] [Bug 5168] clang x86-64 abi does not set %rax when
returning struct
In-Reply-To:
Message-ID: <200910120811.n9C8B0ea023004@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5168
Anton Korobeynikov changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |asl at math.spbu.ru
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #1 from Anton Korobeynikov 2009-10-12 03:10:58 ---
*** This bug has been marked as a duplicate of bug 783 ***
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 12 11:40:06 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 12 Oct 2009 11:40:06 -0500
Subject: [LLVMbugs] [Bug 5168] clang x86-64 abi does not set %rax when
returning struct
In-Reply-To:
Message-ID: <200910121640.n9CGe60m014017@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5168
Dan Gohman changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gohman at apple.com
Resolution|DUPLICATE |FIXED
--- Comment #2 from Dan Gohman 2009-10-12 11:40:06 ---
This is fixed here:
http://llvm.org/viewvc/llvm-project?rev=83853&view=rev
In my opinion, the front-end should still fix PR783, but for now the back-end
is
setting RAX itself.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 12 12:42:06 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 12 Oct 2009 12:42:06 -0500
Subject: [LLVMbugs] [Bug 5169] New: stack alignment?
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5169
Summary: stack alignment?
Product: libraries
Version: trunk
Platform: PC
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: Backend: X86
AssignedTo: unassignedbugs at nondot.org
ReportedBy: rdivacky at freebsd.org
CC: llvmbugs at cs.uiuc.edu
witten ~# cat argc.c
#include
int
main()
{
char *arr[] = {"a", "b", "c", "d"};
char *a = *arr+1;
int argc;
char **argv;
char **env;
__asm__("and $0xfffffff0,%esp");
argv = &a;
argc = *(long *)(void *)(argv - 1);
printf("I: %i\n", argc);
}
witten ~# gcc argc.c &&./a.out
I: 0
witten ~# clang argc.c && ./a.out
I: 672454409
Segmentation fault (core dumped)
when I comment out the __asm__("and $0xfffffff0,%esp"); the segfault is gone
but the printed value I is still wrong...
I dont know if this is llvm only specific or clang plays a role here.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 12 12:46:52 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 12 Oct 2009 12:46:52 -0500
Subject: [LLVMbugs] [Bug 5160] ValueHandle is easy to confuse with active
CallbackVHs
In-Reply-To:
Message-ID: <200910121746.n9CHkqfi016443@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5160
Jeffrey Yasskin changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #2 from Jeffrey Yasskin 2009-10-12 12:46:52 ---
Committed as r83861.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 12 13:08:41 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 12 Oct 2009 13:08:41 -0500
Subject: [LLVMbugs] [Bug 5169] stack alignment?
In-Reply-To:
Message-ID: <200910121808.n9CI8ftf017321@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5169
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #2 from Chris Lattner 2009-10-12 13:08:41 ---
This is invalid in two ways:
1) it is taking the address of "a" and incrementing it to get to another
variable on the stack. Stack layout is undefined.
2) inline asm isn't allowed to modify the stack pointer.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 12 14:28:17 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 12 Oct 2009 14:28:17 -0500
Subject: [LLVMbugs] [Bug 5170] New: Fix build of
MultiSource/Benchmarks/MiBench/ office-ispell on FreeBSD
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5170
Summary: Fix build of MultiSource/Benchmarks/MiBench/office-
ispell on FreeBSD
Product: Test Suite
Version: trunk
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Nightly Tester
AssignedTo: unassignedbugs at nondot.org
ReportedBy: pawel.worach at gmail.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=3644)
--> (http://llvm.org/bugs/attachment.cgi?id=3644)
ispell-term.c.diff
FreeBSD does not use sgtty but termios like linnex.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Mon Oct 12 15:54:38 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 12 Oct 2009 15:54:38 -0500
Subject: [LLVMbugs] [Bug 5171] New: SingleSource/UnitTests/Vector/SSE dies
with SEGV
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5171
Summary: SingleSource/UnitTests/Vector/SSE dies with SEGV
Product: Test Suite
Version: trunk
Platform: PC
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: Nightly Tester
AssignedTo: unassignedbugs at nondot.org
ReportedBy: pawel.worach at gmail.com
CC: llvmbugs at cs.uiuc.edu
# gdb Output/sse.expandfft.native
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) run
Starting program:
/usr/src-local/llvm-rel/pre1/llvm-2.6/projects/llvm-test/SingleSource/UnitTests/Vector/SSE/Output/sse.expandfft.native
Program received signal SIGSEGV, Segmentation fault.
0x0000000000400f56 in main ()
at
/usr/src-local/llvm-rel/pre1/llvm-2.6/projects/llvm-test/SingleSource/UnitTests/Vector/SSE/sse.expandfft.c:35
35 x[i] = z0;
(gdb) list
30 for(icase=0;icase<2;icase++){
31 if(first){
32 for(i=0;i<2*N;i+=2){
33 z0 = ggl(&seed); /* real part of array */
34 z1 = ggl(&seed); /* imaginary part of array */
35 x[i] = z0;
36 z[i] = z0; /* copy of initial real data */
37 x[i+1] = z1;
38 z[i+1] = z1; /* copy of initial imag. data */
39 }
(gdb) p z0
$1 = 0.00259052776
(gdb) p x
Variable "x" is not available.
(gdb) p x[0]
Variable "x" is not available.
(gdb) p i
No symbol "i" in current context.
(gdb) info loc
first = Variable "first" is not available.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 00:20:52 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 00:20:52 -0500
Subject: [LLVMbugs] [Bug 5173] New: [Diagnosis RFE] - Clang should have a
diagnosis for unused parameters in inline asm statement .
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5173
Summary: [Diagnosis RFE] - Clang should have a diagnosis for
unused parameters in inline asm statement.
Product: clang
Version: trunk
Platform: PC
OS/Version: Solaris
Status: NEW
Severity: enhancement
Priority: P2
Component: Semantic Analyzer
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: eocallaghan at auroraux.org
CC: llvmbugs at cs.uiuc.edu
G'Day,
As of trunk 83939.
Clang should have a diagnosis for unused parameters in inline asm statement.
Versions:
-bash-3.2$ /opt/SUNWspro/bin/cc -V
cc: Sun C 5.9 SunOS_i386 Patch 124868-08 2008/11/25
-bash-3.2$ /opt/gcc4/bin/gcc --version
gcc (GCC) 4.2.4
-bash-3.2$ /opt/clang/bin/clang --version
clang version 1.1 (trunk 83939)
Outputs:
-bash-3.2$ /opt/clang/bin/clang t.c
-bash-3.2$ /opt/gcc4/bin/gcc t.c
-bash-3.2$ /opt/SUNWspro/bin/cc t.c
"t.c", line 6: warning: parameter in inline asm statement unused: %1
Test Case:
-bash-3.2$ cat t.c
int main() {
int a,b;
asm ( "nop;"
:"=%c" (a)
: "r" (b)
);
return 0;
}
Cheers,
Edward.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 00:37:26 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 00:37:26 -0500
Subject: [LLVMbugs] [Bug 5170] Fix build of MultiSource/Benchmarks/MiBench/
office-ispell on FreeBSD
In-Reply-To:
Message-ID: <200910130537.n9D5bQGq003775@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5170
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Chris Lattner 2009-10-13 00:37:26 ---
Applied in r83944, thanks!
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 01:07:30 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 01:07:30 -0500
Subject: [LLVMbugs] [Bug 5174] New: ImmutableMap is slow
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5174
Summary: ImmutableMap is slow
Product: libraries
Version: trunk
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Support Libraries
AssignedTo: unassignedbugs at nondot.org
ReportedBy: resistor at mac.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=3647)
--> (http://llvm.org/bugs/attachment.cgi?id=3647)
ImmutableMapGVN.diff
ImmutableMap-based GVN is significantly slower than DenseMap-based GVN, even
though the lookup behavior is much better. Shark shows GVN spending 34% of its
time in GetCanonicalTree(), called from Factory::Add() in InsertDomMap(). Is
there any way we could make this faster?
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 02:14:47 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 02:14:47 -0500
Subject: [LLVMbugs] [Bug 5131] Initializer elements accepted by gcc are
rejected by clang
In-Reply-To:
Message-ID: <200910130714.n9D7ElY4007554@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5131
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Chris Lattner 2009-10-13 02:14:46 ---
Implemented here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091012/022248.html
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 02:58:12 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 02:58:12 -0500
Subject: [LLVMbugs] [Bug 5175] New: llvm-gcc cannot export symbols with
__declspec(dllexport)
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5175
Summary: llvm-gcc cannot export symbols with
__declspec(dllexport)
Product: libraries
Version: trunk
Platform: PC
OS/Version: Windows XP
Status: NEW
Keywords: compile-fail
Severity: normal
Priority: P2
Component: Linker
AssignedTo: unassignedbugs at nondot.org
ReportedBy: pijnacker at dse.nl
CC: llvmbugs at cs.uiuc.edu
Compiling the following function into a shared library on mingw/windows
__declspec(dllexport) someFunction()
{
printf("Hi\n");
}
gives the following error:
$ llvm-gcc -shared -o libfunction.dll function.c
Cannot export _someFunction: symbol not found
collect2: ld returned 1 exit status
Anton said about this:
Right, this is a bug introduced recently - we need to emit linker directive
with unmangled, but decorated name...
--
Ronald
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 10:58:51 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 10:58:51 -0500
Subject: [LLVMbugs] [Bug 5176] New: small testcase shows much badness (EH,
constant folding)
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5176
Summary: small testcase shows much badness (EH, constant folding)
Product: tools
Version: 2.2
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: llvm-g++
AssignedTo: unassignedbugs at nondot.org
ReportedBy: clattner at apple.com
CC: llvmbugs at cs.uiuc.edu
Consider this testcase:
struct A
{
bool foo(int*) const;
} a;
struct B {};
struct B1 : B
{
bool (A::*pmf)(int*) const;
const A* pa;
B1() : pmf(&A::foo), pa(&a) {}
bool operator()() const { return (pa->*pmf)(new int); }
};
struct B2 : B
{
B1 b1;
B2(const B1& _b1) : b1(_b1) {}
bool operator()() const { return b1(); }
};
template struct C
{
void bar(B2 b2) { while (b2()) ; }
C() { bar(B2(B1())); }
};
void baz(int i){
switch(i) {
case 0: new C<0>;
case 1: new C<1>;
case 2: new C<2>;
}
}
When compiled with:
$ llvm-gcc t.cc -S -o - -emit-llvm -O3
There are two problems. First, we get a bunch of horrible unfolded constant
expressions like this:
inttoptr (i64 trunc (i256 lshr (i256 or (i256 and (i256 and (i256 shl (i256
zext (i64 ptrtoint (i8 (%struct.A*, i32*)* @_ZNK1A3fooEPi to i64) to i256),
i256 64), i256 -6277101735386680763495507056286727952638980837032266301441),
i256 6277101735386680763835789423207666416102355444464034512895), i256 shl
(i256 zext (i64 ptrtoint (%struct.A* @a to i64) to i256), i256 192)), i256 64)
to i64) to i8 (%struct.A*, i32*)*)
Quite impressive, but not very useful.
The second problem is EH related, we get 3 copies of the exact same landing
pad:
pad: ; preds = %.noexc,
%_ZNK2B2clEv.exit.i.i
%eh_ptr = tail call i8* @llvm.eh.exception() ; [#uses=2]
%eh_select14 = tail call i64 (i8*, i8*, ...)* @llvm.eh.selector.i64(i8*
%eh_ptr, i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*), i8* null) ;
[#uses=0]
tail call void @_ZdlPv(i8* %0) nounwind
br label %Unwind
lpad15: ; preds = %.noexc41,
%_ZNK2B2clEv.exit.i.i40
%eh_ptr16 = tail call i8* @llvm.eh.exception() ; [#uses=2]
%eh_select18 = tail call i64 (i8*, i8*, ...)* @llvm.eh.selector.i64(i8*
%eh_ptr16, i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*), i8* null) ;
[#uses=0]
tail call void @_ZdlPv(i8* %8) nounwind
br label %Unwind
lpad19: ; preds = %.noexc33,
%_ZNK2B2clEv.exit.i.i32
%eh_ptr20 = tail call i8* @llvm.eh.exception() ; [#uses=2]
%eh_select22 = tail call i64 (i8*, i8*, ...)* @llvm.eh.selector.i64(i8*
%eh_ptr20, i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*), i8* null) ;
[#uses=0]
tail call void @_ZdlPv(i8* %16) nounwind
br label %Unwind
-Chris
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 11:14:21 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 11:14:21 -0500
Subject: [LLVMbugs] [Bug 5179] New: crash in clang++codegen (X86_64ABIInfo::
classifyArgumentType)
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5179
Summary: crash in clang++codegen
(X86_64ABIInfo::classifyArgumentType)
Product: clang
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: clattner at apple.com
CC: llvmbugs at cs.uiuc.edu, daniel at zuster.org
This crashes in X86_64ABIInfo::classifyArgumentType:
Assertion failed: ((Lo != NoClass || Hi == NoClass) && "Invalid null
classification."), function classifyArgumentType, file TargetABIInfo.cpp, line
977.
struct A
{
bool foo(int*) const;
} a;
struct B {};
struct B1 : B {
const A* pa;
B1() {}
};
struct B2 : B {
B1 b1;
B2(const B1& _b1) : b1(_b1) {}
};
void bar(B2 b2);
void baz(const B1 &b2)
{
bar(b2);
}
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 12:47:07 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 12:47:07 -0500
Subject: [LLVMbugs] [Bug 5174] ImmutableMap is slow
In-Reply-To:
Message-ID: <200910131747.n9DHl7Lv012450@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5174
Ted Kremenek changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Ted Kremenek 2009-10-13 12:47:05 ---
I suspect that this is probably a case of using the wrong data structure for a
given problem.
If all you are doing is using ImmutableMap just like you would use DenseMap, it
is never going to come as close to the performance as DenseMap. It uses a
balanced-AVL tree, and allocates new tree nodes whenever you do an insert and
removal in order to really leave the original map untouched. Algorithmically,
DenseMap is just going to leave it in the dust if all you care about are doing
lookups and insert/deletions to a single map. Where ImmutableMap is useful for
cases where you need (many) multiple copies (or versions) of the same map
around at the same time. DenseMap would not be a good data structure for such
scenarios.
ImmutableMap also has the invariant that no matter what *order* you
insert/remove values from the map, you will still get the same physical map.
The ImmutableMap object is just a smart pointer to an AVL tree node (the root),
and operator== is implemented using a simple pointer comparison of the two root
nodes. This is really value for the static analyzer, as it frequently does
comparisons between maps. This comes at a cost, however, as such
canonicalization of the maps takes work (via a FoldingSet).
Is there a reason you need to use ImmutableMap for GVN?
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 13:39:06 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 13:39:06 -0500
Subject: [LLVMbugs] [Bug 5174] ImmutableMap is slow
In-Reply-To:
Message-ID: <200910131839.n9DId6EH014736@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5174
Ted Kremenek changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 14:11:41 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 14:11:41 -0500
Subject: [LLVMbugs] [Bug 5182] New: llvm-g++ creates file for which llvm-dis
says " Invalid METADATA_ATTACHMENT reader"
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5182
Summary: llvm-g++ creates file for which llvm-dis says "Invalid
METADATA_ATTACHMENT reader"
Product: new-bugs
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: timo.lindfors at iki.fi
CC: llvmbugs at cs.uiuc.edu
Steps to reproduce:
1) git clone
git://triplane-class.git.sourceforge.net/gitroot/triplane-class/triplane-class
2) cd triplane-class
3) llvm-g++ -emit-llvm -o src/triplane.o -Wall -Isrc -O2 -g `sdl-config
--cflags` -DHAVE_SDL_MIXER
"-DTRIPLANE_DATA=\"/usr/local/share/games/triplane-classic\"" -c
src/triplane.cpp
4) llvm-dis src/triplane.o
Expected results:
4) llvm-dis disassembles the bitcode file and creates triplane.ll
Actual results:
4) llvm-dis does not create triplane.ll and prints the following error:
llvm-dis: Invalid METADATA_ATTACHMENT reader!
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 15:12:20 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 15:12:20 -0500
Subject: [LLVMbugs] [Bug 5183] New: call to func optimized out at -O2
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5183
Summary: call to func optimized out at -O2
Product: clang
Version: unspecified
Platform: PC
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: rdivacky at freebsd.org
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=3653)
--> (http://llvm.org/bugs/attachment.cgi?id=3653)
test case
the attached testcase is basically:
func_ptr *p;
for (p = __CTOR_END__ - 1; *p != (func_ptr) -1; p--)
(*p) ();
which clang -O2 compiles to:
__do_global_ctors_aux:
pushl %ebp
movl %esp, %ebp
xorb %al, %al
.align 16
.LBB1_2:
notb %al
testb $1, %al
movb $0, %al
jne .LBB1_2
popl %ebp
ret
note that there is no call to the function... gcc generates the call
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 15:28:39 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 15:28:39 -0500
Subject: [LLVMbugs] [Bug 5183] call to func optimized out at -O2
In-Reply-To:
Message-ID: <200910132028.n9DKSd8f019158@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5183
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Chris Lattner 2009-10-13 15:28:38 ---
This is correct behavior, the __CTOR_END__ global must be marked with
attribute(used)
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 16:46:16 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 16:46:16 -0500
Subject: [LLVMbugs] [Bug 1129] Debugging support for JIT code
In-Reply-To:
Message-ID: <200910132146.n9DLkGti022627@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=1129
Nuno Lopes changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nunoplopes at sapo.pt
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #4 from Nuno Lopes 2009-10-13 16:46:15 ---
I believe this is done by now. There's now support for both gdb and oprofile.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 16:54:59 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 16:54:59 -0500
Subject: [LLVMbugs] [Bug 4406] BrainF example fails with assertion failure
In-Reply-To:
Message-ID: <200910132154.n9DLsxAp023005@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=4406
Jeffrey Yasskin changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |DUPLICATE
--- Comment #8 from Jeffrey Yasskin 2009-10-13 16:54:58 ---
The fix for PR5162 fixes this too.
*** This bug has been marked as a duplicate of bug 5162 ***
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 17:02:08 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 17:02:08 -0500
Subject: [LLVMbugs] [Bug 5182] llvm-g++ creates file for which llvm-dis says
" Invalid METADATA_ATTACHMENT reader"
In-Reply-To:
Message-ID: <200910132202.n9DM28kL023303@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5182
Timo Juhani Lindfors changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Timo Juhani Lindfors 2009-10-13 17:02:07 ---
Thanks! I upgraded llvm to r84032 and do not see the bug anymore.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 18:39:48 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 18:39:48 -0500
Subject: [LLVMbugs] [Bug 5162] ExecutionEngine->DisableLazyCompilation()
causes crashes on Function deletion
In-Reply-To:
Message-ID: <200910132339.n9DNdmBs027112@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5162
Jeffrey Yasskin changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jyasskin at google.com
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #6 from Jeffrey Yasskin 2009-10-13 18:39:47 ---
Committed for Nick as r84032.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Tue Oct 13 21:00:51 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 13 Oct 2009 21:00:51 -0500
Subject: [LLVMbugs] [Bug 5184] New: Lazy compilation is not thread-safe
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5184
Summary: Lazy compilation is not thread-safe
Product: libraries
Version: trunk
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Target-Independent JIT
AssignedTo: unassignedbugs at nondot.org
ReportedBy: jyasskin at google.com
CC: llvmbugs at cs.uiuc.edu
Lazy compilation is implemented roughly as:
call @compilationCallback
define @compilationCallback() {
...
store %new_function_address (%return_address-4)
}
which turns the "call @compilationCallback" into a "call @real_function".
Unfortunately, while that store into the return address is running, another
thread could be executing the call. At least on the x86, there are no
guarantees about what can happen in this case. (Data reads and writes are
defined, but not instruction execution.) It's entirely possible that the store
won't be seen as atomic and will result in a wild jump.
I see three ways to fix this:
1) Instead of codegening a direct call instruction, generate something like:
%target = atomic load @callsite_target_address
call %target
and then at the end of compilation atomically store the real function back to
@callsite_target_address. This causes every callsite to be an indirect call,
which is likely to slow things down a lot, so there should be some way to mark
the functions where it's used. On platforms that don't even have atomic
pointer writes, this could be implemented by acquiring a lock around every
lazily-compilable call.
2) Assert that lazy compilation is only used in a single-threaded program. This
allows us to delete the JIT lock.
3) Delete lazy compilation. (which would simplify the JIT a fair amount)
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Wed Oct 14 01:27:36 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 14 Oct 2009 01:27:36 -0500
Subject: [LLVMbugs] [Bug 5185] New: C99 [*] VLA notation should be
disallowed in function definitions
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5185
Summary: C99 [*] VLA notation should be disallowed in function
definitions
Product: clang
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Semantic Analyzer
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: holm at liacs.nl
CC: llvmbugs at cs.uiuc.edu
The notation [*] is by the C99 standard only allowed in function prototypes.
GCC reports incorrect use of [*] like: "vla.c:22: error: ???[*]??? not allowed
in other than function prototype scope"
Clang (at least the one installed in OS X 10.6 devtools) happily accepts this
even in the argument lists of a function definition.
---------------
See C99 standard document section 6.7.5.3 paragraph 12:
"If the function declarator is not part of a definition of that function,
parameters may have incomplete type and may use the [*] notation in their
sequences of declarator specifiers to specify variable length array types."
---------------
I suggest reporting violations of this as something in the style of: "error:
VLA length not bound in definition" and not the "error: [*] not allowed" as GCC
does. The GCC report is not very suggestive about what you can do to fix the
error.
Example and simple test case:
void foo(int a[*]); // OK, this is a function prototype
// NOT valid C99, VLA 'a' must have its length bound to
// another parameter or constant when used in a function
// definition
void foo(int a[*])
{
}
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Wed Oct 14 05:13:30 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 14 Oct 2009 05:13:30 -0500
Subject: [LLVMbugs] [Bug 5186] New: hello.cpp && lli: Addr && "Code
generation didn' t add function to GlobalAddress table!"
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5186
Summary: hello.cpp && lli: Addr && "Code generation didn't add
function to GlobalAddress table!"
Product: new-bugs
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: timo.lindfors at iki.fi
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=3655)
--> (http://llvm.org/bugs/attachment.cgi?id=3655)
bitcode that causes the assertion
Steps to reproduce:
1) cat > testcase.cpp <
int main()
{
std::cout << "hello world\n";
return 0;
}
EOF
2) llvm-g++ hello.cpp -emit-llvm -c -o hello.bc
3) lli hello.bc
Expected results:
3) the program prints "hello world"
Actual results:
3) lli prints
lli: JIT.cpp:673: virtual void*
llvm::JIT::getPointerToFunction(llvm::Function*): Assertion `Addr && "Code
generation didn't add function to GlobalAddress table!"' failed.
0 lli 0x087c5d98
Stack dump:
0. Program arguments: lli hello.bc
Aborted (core dumped)
More info:
1) "clang hello.cpp -emit-llvm -c -o hello2.bc hello.bc" and "lli hello2.bc"
prints "hello world"
2) Version information:
llvm-gcc r83879
llvm r84032
clang r83964
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Wed Oct 14 12:21:13 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 14 Oct 2009 12:21:13 -0500
Subject: [LLVMbugs] [Bug 5189] New: trichotomy of scalars not optimized
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=5189
Summary: trichotomy of scalars not optimized
Product: libraries
Version: 2.6
Platform: Macintosh
OS/Version: Mac System 9.x
Status: NEW
Severity: normal
Priority: P2
Component: Scalar Optimizations
AssignedTo: unassignedbugs at nondot.org
ReportedBy: ggreif at gmail.com
CC: llvmbugs at cs.uiuc.edu
look at this code:
//////////////////////////////
extern int compare(int X, int Y);
int compare(int X, int Y) {
return !(X < Y) && !(X > Y);
}
int main(int argc, char **argv) {
return compare(argc, 42);
}
//////////////////////////////
llvm-gcc compiles it to equality comparison:
define i32 @main(i32 %argc, i8** nocapture %argv) nounwind readnone {
entry:
%0 = icmp eq i32 %argc, 42 ; [#uses=1]
%1 = zext i1 %0 to i32 ; [#uses=1]
ret i32 %1
}
But no such luck with pretty recent clang:
MacBook-de-Patricia:bin ggreif$ ./clang -x c -S -o - -emit-llvm - -O2
extern int compare(int X, int Y);
int compare(int X, int Y) {
return !(X < Y) && !(X > Y);
}
int main(int argc, char **argv) {
return compare(argc, 42);
}
; ModuleID = '-'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128"
target triple = "i386-apple-darwin9.0"
define i32 @compare(i32 %X, i32 %Y) nounwind readnone {
%1 = icmp slt i32 %X, %Y ; [#uses=1]
br i1 %1, label %4, label %2
;