From bugzilla-daemon at cs.uiuc.edu Mon Feb 1 01:56:31 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 01:56:31 -0600
Subject: [LLVMbugs] [Bug 6193] New: crash in instcombine in
MatchSelectFromAndOr
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6193
Summary: crash in instcombine in MatchSelectFromAndOr
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: sharparrow1 at yahoo.com
CC: llvmbugs at cs.uiuc.edu
Blocks: 5511
Testcase:
define i32 @x(i32 %aMaskWidth, i8 %aStride) nounwind {
entry:
%conv41 = sext i8 %aStride to i32
%neg = xor i32 %conv41, -1
%and42 = and i32 %aMaskWidth, %neg
%and47 = and i32 130, %conv41
%or = or i32 %and42, %and47
ret i32 %or
}
Currently crashes with opt -instcombine. I think there's an issue involving
r94339 ("change the canonical form of 'cond ? -1 : 0' to be 'sext cond' instead
of a select").
--
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 Feb 1 04:51:50 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 04:51:50 -0600
Subject: [LLVMbugs] [Bug 6194] New: inlining of MRV function does not remove
bitcast-/shift-/ zext-/trunc-operations on x64
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6194
Summary: inlining of MRV function does not remove bitcast-/shift-
/zext-/trunc-operations on x64
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: karrenberg at cs.uni-saarland.de
CC: llvmbugs at cs.uiuc.edu
For the code below, llvm-gcc generates non-optimal code for accessing and
returning structs on x64.
In order to conform to ABI requirements, a struct parameter which holds 3
floats is split into two parameters: a double and a float.
Accessing the first two struct-values results in a series of bitcast-, zext-,
lshr-, and trunc-operations (test1).
It should be possible to reduce this to bitcast(i64)-shift-bitcast(float).
More importantly however, if code that returns a struct is inlined into a
function that defines that same struct, the corresponding series of operations
as above are entirely redundant (float ->
bitcast/zext/shl/zext/lshr/trunc/bitcast -> float) but do not get optimized
away (test3):
define void @test2(float %aX, float %aY, float %aZ, %struct.float3* nocapture
%res) nounwind noinline {
entry:
%tmp27 = bitcast float %aY to i32 ; [#uses=1]
%tmp28 = zext i32 %tmp27 to i96 ; [#uses=1]
%tmp29 = shl i96 %tmp28, 32 ; [#uses=1]
%tmp21 = zext i96 %tmp29 to i128 ; [#uses=1]
%0 = getelementptr inbounds %struct.float3* %res, i64 0, i32 0 ;
[#uses=1]
store float %aX, float* %0, align 4
%1 = getelementptr inbounds %struct.float3* %res, i64 0, i32 1 ;
[#uses=1]
%tmp10 = lshr i128 %tmp21, 32 ; [#uses=1]
%tmp11 = trunc i128 %tmp10 to i32 ; [#uses=1]
%tmp12 = bitcast i32 %tmp11 to float ; [#uses=1]
store float %tmp12, float* %1, align 4
%2 = getelementptr inbounds %struct.float3* %res, i64 0, i32 2 ;
[#uses=1]
store float %aZ, float* %2, align 4
ret void
}
--
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 Feb 1 06:22:22 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 06:22:22 -0600
Subject: [LLVMbugs] [Bug 6192] [mips] wrong instruction selection for
multiplication
In-Reply-To:
Message-ID: <201002011222.o11CMMbZ019501@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6192
Bruno Cardoso Lopes changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bruno.cardoso at gmail.com
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #2 from Bruno Cardoso Lopes 2010-02-01 06:22:21 ---
Hi,
Your proposed patch is not the way to go (the instruction selection is going
over ISD::MUL). I fixed it in r94977:
http://llvm.org/viewvc/llvm-project?view=rev&revision=94977
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 Mon Feb 1 08:40:23 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 08:40:23 -0600
Subject: [LLVMbugs] [Bug 6195] New: instcombine crash: " replaceAllUses of
value with new value of different type!"
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6195
Summary: instcombine crash: "replaceAllUses of value with new
value of different type!"
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=4160)
--> (http://llvm.org/bugs/attachment.cgi?id=4160)
testcase .ll
$ opt -instcombine -disable-output simd-4.ll
opt: llvm/lib/VMCore/Value.cpp:317: void
llvm::Value::replaceAllUsesWith(llvm::Value*): Assertion `New->getType() ==
getType() && "replaceAllUses of value with new value of different type!"'
failed.
...
--
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 Feb 1 08:57:19 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 08:57:19 -0600
Subject: [LLVMbugs] [Bug 6196] New: llc crash: "cast() argument of
incompatible type!"
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6196
Summary: llc crash: "cast() argument of incompatible type!"
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
$ llc gcc37433.ll
llc: llvm/include/llvm/Support/Casting.h:199: typename llvm::cast_retty::ret_type llvm::cast(const Y&) [with X = llvm::Function, Y =
llvm::GlobalValue*]: Assertion `isa(Val) && "cast() argument of
incompatible type!"' failed.
...
6 llc 0x0000000000993474 llvm::iplist
>::splice(llvm::ilist_iterator, llvm::iplist >&, llvm::ilist_iterator) +
0
7 llc 0x0000000000ea342f
llvm::X86TargetLowering::IsEligibleForTailCallOptimization(llvm::SDValue,
llvm::CallingConv::ID, bool, llvm::SmallVectorImpl
const&, llvm::SmallVectorImpl const&, llvm::SelectionDAG&)
const + 621
8 llc 0x0000000000e9fee3
llvm::X86TargetLowering::LowerCall(llvm::SDValue, llvm::SDValue,
llvm::CallingConv::ID, bool, bool&, llvm::SmallVectorImpl
const&, llvm::SmallVectorImpl const&, llvm::DebugLoc,
llvm::SelectionDAG&, llvm::SmallVectorImpl&) + 309
9 llc 0x0000000001174328
llvm::TargetLowering::LowerCallTo(llvm::SDValue, llvm::Type const*, bool, bool,
bool, bool, unsigned int, llvm::CallingConv::ID, bool, bool, llvm::SDValue,
std::vector >&, llvm::SelectionDAG&,
llvm::DebugLoc, unsigned int) + 2538
...
Here's the testcase:
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-unknown-linux-gnu"
%"char[]" = type [1 x i8]
@.str = external constant %"char[]", align 1 ; <%"char[]"*> [#uses=1]
define i32 @regex_subst() nounwind {
entry:
%0 = tail call i32 bitcast (%"char[]"* @.str to i32 (i32)*)(i32 0) nounwind ;
[#uses=1]
ret i32 %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 Mon Feb 1 09:36:53 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 09:36:53 -0600
Subject: [LLVMbugs] [Bug 6197] New: infinite recursion in ipsccp due to
block addresses
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6197
Summary: infinite recursion in ipsccp due to block addresses
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=4161)
--> (http://llvm.org/bugs/attachment.cgi?id=4161)
testcase .ll
$ opt -ipsccp pr32919.1.ll -disable-output
Segmentation fault (core dumped)
--
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 Feb 1 10:57:10 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 10:57:10 -0600
Subject: [LLVMbugs] [Bug 6198] New: instcombine crash: "Cannot getTypeInfo()
on a type that is unsized!"
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6198
Summary: instcombine crash: "Cannot getTypeInfo() on a type that
is unsized!"
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
The type in question is a function type.
$ opt -instcombine -disable-output 20080721-1.ll
opt: llvm/lib/Target/TargetData.cpp:498: unsigned char
llvm::TargetData::getAlignment(const llvm::Type*, bool) const: Assertion
`Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"' failed.
...
6 opt 0x0000000000a658d8 llvm::TargetData::getAlignment(llvm::Type
const*, bool) const + 140
7 opt 0x0000000000a65b58
llvm::TargetData::getPrefTypeAlignment(llvm::Type const*) const + 40
8 opt 0x0000000000940cf7 llvm::isSafeToLoadUnconditionally(llvm::Value*,
llvm::Instruction*, unsigned int, llvm::TargetData const*) + 340
Testcase:
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-unknown-linux-gnu"
module asm "\09.ident\09\22GCC: (GNU) 4.5.0 20100129 (experimental) LLVM:
88902:94980M\22"
define i32 @test(i32 %b) nounwind readonly {
entry:
%0 = icmp eq i32 %b, 0 ; [#uses=1]
%p_1 = select i1 %0, i8* bitcast (void ()* @bar to i8*), i8* bitcast (void
()* @foo to i8*) ; [#uses=1]
%q_6 = bitcast i8* %p_1 to i8** ; [#uses=1]
%D.2728_7 = load i8** %q_6, align 8 ; [#uses=1]
%1 = icmp eq i8* %D.2728_7, null ; [#uses=1]
%D.2731_2 = select i1 %1, i32 1, i32 0 ; [#uses=1]
ret i32 %D.2731_2
}
declare void @foo()
declare void @bar()
--
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 Feb 1 11:43:08 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 11:43:08 -0600
Subject: [LLVMbugs] [Bug 6198] instcombine crash: "Cannot getTypeInfo() on a
type that is unsized!"
In-Reply-To:
Message-ID: <201002011743.o11Hh87p031675@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6198
Bob Wilson changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Bob Wilson 2010-02-01 11:43:08 ---
Fixed in svn r94984.
For some reason, I can't repro the crash. I ran an assertion-enabled opt but
it seems to run OK. Since the cause of the problem seems fairly obvious, I
just fixed it.
--
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 Feb 1 13:35:43 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 13:35:43 -0600
Subject: [LLVMbugs] [Bug 6197] infinite recursion in ipsccp due to block
addresses
In-Reply-To:
Message-ID: <201002011935.o11JZh3F004212@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6197
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Component|new bugs |Core LLVM classes
Product|new-bugs |libraries
Resolution| |FIXED
Version|unspecified |2.6
--- Comment #2 from Chris Lattner 2010-02-01 13:35:42 ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100201/095402.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 Feb 1 14:05:10 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 14:05:10 -0600
Subject: [LLVMbugs] [Bug 6195] instcombine crash: " replaceAllUses of value
with new value of different type!"
In-Reply-To:
Message-ID: <201002012005.o11K5A6S005555@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6195
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Component|new bugs |Core LLVM classes
Product|new-bugs |libraries
Resolution| |FIXED
Version|unspecified |2.5
--- Comment #2 from Chris Lattner 2010-02-01 14:05:10 ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100201/095406.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 Feb 1 16:11:39 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 16:11:39 -0600
Subject: [LLVMbugs] [Bug 6201] New: add i64 version of alloca
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6201
Summary: add i64 version of alloca
Product: new-bugs
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Keywords: code-cleanup, code-quality
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: vhernandez at apple.com
CC: llvmbugs at cs.uiuc.edu
Currently the alloca instruction's number of elements operand is limited to
i32.
= alloca [, i32 ][, align ] ; yields
{type*}:result
Add a version of alloca that supports 164 number of elements.
[This was originally tracked in Bug 715, but that one has been closed because
other enhancement requests from that bug have been 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 Feb 1 16:12:24 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 16:12:24 -0600
Subject: [LLVMbugs] [Bug 715] remove mallocinst instruction,
add i64 version of alloca.
In-Reply-To:
Message-ID: <201002012212.o11MCOEN011244@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=715
Victor Hernandez changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #10 from Victor Hernandez 2010-02-01 16:12:23 ---
I have filed http://llvm.org/bugs/show_bug.cgi?id=6201 to cover the i64 alloca.
Closing this bug.
--
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 Feb 1 16:40:19 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 16:40:19 -0600
Subject: [LLVMbugs] [Bug 6196] llc crash: "cast() argument of
incompatible type!"
In-Reply-To:
Message-ID: <201002012240.o11MeJj9012262@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6196
Evan Cheng changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Evan Cheng 2010-02-01 16:40:19 ---
Fixed: 95017.
--
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 Feb 1 16:49:02 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 16:49:02 -0600
Subject: [LLVMbugs] [Bug 6157] opt -O1 segfault
In-Reply-To:
Message-ID: <201002012249.o11Mn2CT012634@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6157
Dale Johannesen changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #17 from Dale Johannesen 2010-02-01 16:49:01 ---
Right. It is simpler than I said, SelectionDAGBuilder was just not handling
dbg.value. Now it is ignored, like dbg.declare. Fixed here.
http://llvm.org/viewvc/llvm-project?rev=94996&view=rev
http://llvm.org/viewvc/llvm-project?rev=95021&view=rev
--
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 Feb 1 17:36:49 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 17:36:49 -0600
Subject: [LLVMbugs] [Bug 4515] certain enum constants have wrong type inside
an enum definition
In-Reply-To:
Message-ID: <201002012336.o11Nangu014701@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=4515
Douglas Gregor changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dgregor at apple.com
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Douglas Gregor 2010-02-01 17:36:48 ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100201/027012.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 Feb 1 18:46:14 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 18:46:14 -0600
Subject: [LLVMbugs] [Bug 6182] Cascaded and non-specific errors for ommitted
semicolon after a class {}
In-Reply-To:
Message-ID: <201002020046.o120kEN9017548@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6182
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #1 from Chris Lattner 2010-02-01 18:46:13 ---
Tracking related issues in PR6180
*** This bug has been marked as a duplicate of bug 6180 ***
--
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 Feb 1 19:26:23 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 19:26:23 -0600
Subject: [LLVMbugs] [Bug 6202] New: [mips] wrong transfer of double float
value from FP register to GP register
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6202
Summary: [mips] wrong transfer of double float value from FP
register to GP register
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: Linux
Status: ASSIGNED
Keywords: miscompilation
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: bruno.cardoso at gmail.com
ReportedBy: zhou_shuchang at sina.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=4162)
--> (http://llvm.org/bugs/attachment.cgi?id=4162)
test floating point sqrt
#include
#include
int main(int argc,char** argv)
{
float f=argc;
printf("%f\n",sqrt(f));
}
with ./a.out, we get 0.0 instead of 1.0.
In assembly
sqrt.d $f2, $f2
mov.s $f12, $f2
~~~~~~~~~~~~~~~ sqrt.d keep the result in $f2-$f3 pair, but only $f2 is
transferred.
swc1 $f12, 60($fp)
--
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 Feb 1 19:27:09 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 19:27:09 -0600
Subject: [LLVMbugs] [Bug 6180] Weird error for ommitted semicolon
In-Reply-To:
Message-ID: <201002020127.o121R981019104@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6180
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #6 from Chris Lattner 2010-02-01 19:27:09 ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100201/027017.html
For this testcase:
template
class a{}
class temp{};
a b;
class b
{
}
we now produce:
t.cc:5:10: error: expected ';' after class
class a{}
^
;
t.cc:13:2: error: expected ';' after class
}
^
;
We used to produce:
t.cc:7:1: error: cannot combine with previous 'class' declaration specifier
class temp{};
^
t.cc:9:3: error: template argument for template type parameter must be a type
a b;
^~~~
t.cc:4:16: note: template parameter is declared here
template
^
t.cc:18:1: error: expected unqualified-id
^
GCC 4.2 produces:
t.cc:7: error: multiple types in one declaration
t.cc:9: error: non-template type ???a??? used as a template
t.cc:9: error: invalid type in declaration before ???;??? token
t.cc:13: error: expected unqualified-id at end of input
--
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 Feb 1 19:45:02 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 19:45:02 -0600
Subject: [LLVMbugs] [Bug 6203] New: [mips] cannot copy register from FGR32
to AFGR64 class
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6203
Summary: [mips] cannot copy register from FGR32 to AFGR64 class
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: Linux
Status: ASSIGNED
Keywords: compile-fail
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: bruno.cardoso at gmail.com
ReportedBy: zhou_shuchang at sina.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=4163)
--> (http://llvm.org/bugs/attachment.cgi?id=4163)
cannot copy register from FGR32 to AFGR64 class
#include
int main()
{
register unsigned char rC0, rC1;
rC0 = 0;
rC1 = 255;
rC0 += (float) rC1;
if(rC0 == 255)
printf("passed\n");
else
printf("failed\n");
return 0;
}
we have assertion failure
clang: /home/zsc/tmpd/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:291: void
llvm::InstrEmitter::AddRegisterOperand(llvm::MachineInstr*, llvm::SDValue,
unsigned int, const llvm::TargetInstrDesc*, llvm::DenseMap, llvm::DenseMapInfo >&): Assertion `Emitted && "Unable to issue a copy instruction!\n"'
failed.
0. Program arguments: /usr/local/bin/clang -cc1 -triple
mipsel-unknown-linux-gnu -S -disable-free -main-file-name 16.c -pic-level 2
-mdisable-fp-elim -v -g -resource-dir /usr/local/lib/clang/1.1 -fmessage-length
87 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o 16.s -x c
16.c
By GDB, bool MipsInstrInfo::copyRegToReg returns false
(gdb) p SrcRC->Name
$8 = 0x9575a01 "FGR32"
(gdb) p DestRC->Name
$9 = 0x95759ee "AFGR64"
(gdb) f
#0 llvm::MipsInstrInfo::copyRegToReg (this=0x9cf7548, MBB=..., I=...,
DestReg=1039, SrcReg=1036, DestRC=0x9c5aec0, SrcRC=0x9c5afe0) at
/home/zsc/tmpd/llvm/lib/Target/Mips/MipsInstrInfo.cpp:169
--
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 Feb 1 20:14:21 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 20:14:21 -0600
Subject: [LLVMbugs] [Bug 5597] Cannot mangle template arguments that are
declarations
In-Reply-To:
Message-ID: <201002020214.o122ELNJ020920@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5597
Anders Carlsson changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |andersca at mac.com
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #6 from Anders Carlsson 2010-02-01 20:14:20 ---
Both attached test cases compile fine now, closing.
--
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 Feb 1 20:34:18 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 1 Feb 2010 20:34:18 -0600
Subject: [LLVMbugs] [Bug 6204] New: crash legalizing vector select
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6204
Summary: crash legalizing vector select
Product: libraries
Version: trunk
Platform: PC
OS/Version: All
Status: NEW
Keywords: compile-fail
Severity: normal
Priority: P2
Component: Common Code Generator Code
AssignedTo: unassignedbugs at nondot.org
ReportedBy: clattner at apple.com
CC: llvmbugs at cs.uiuc.edu
This testcase on x86:
define <4 x i32> @test(<4 x i32> %a, <4 x i32> %b, <4 x i1> %c) {
%d = select <4 x i1> %c, <4 x i32> %a, <4 x i32> %b
ret <4 x i32> %d
}
Crashes with:
$ llc t.ll
SplitVectorOperand Op #0: 0x2025950: v4i32 = select 0x20258cc, 0x202508c,
0x2025194 [ORD=1]
Do not know how to split this operator's operand!
UNREACHABLE executed at LegalizeVectorTypes.cpp:967!
--
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 Feb 2 02:46:53 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 2 Feb 2010 02:46:53 -0600
Subject: [LLVMbugs] [Bug 6208] New: ; after struct definition
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6208
Summary: ; after struct definition
Product: clang
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Semantic Analyzer
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: rdivacky at freebsd.org
CC: clattner at apple.com, llvmbugs at cs.uiuc.edu
pes delta$ cat 000.c
enum lapic_clock {
LAPIC_CLOCK_NONE,
};
struct lvt {
} static lapics[0xfe + 1];
pes delta$ gcc -fsyntax-only 000.c && echo yes
yes
pes delta$ clang -fsyntax-only 000.c
000.c:5:2: error: expected ';' after struct
} static lapics[0xfe + 1];
^
;
000.c:5:10: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
} static lapics[0xfe + 1];
~~~~~~ ^
2 diagnostics generated.
pes delta$
--
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 Feb 2 04:16:50 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 2 Feb 2010 04:16:50 -0600
Subject: [LLVMbugs] [Bug 6204] crash legalizing vector select
In-Reply-To:
Message-ID: <201002021016.o12AGoiX021720@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6204
Duncan Sands changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |baldrick at free.fr
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #3 from Duncan Sands 2010-02-02 04:16:49 ---
Codegen does not support vectors with an i1 element type, or any other
funky element type for that matter. In fact even in the IR these are
not supported properly: some places think that <8 x i1> is one byte long
(eg: you can bitcast it to an i8), while others think it is eight bytes
long. The whole thing is a mess and needs a command decision from Chris
as to what such vectors really look and quack like. There is already a
bunch of discussion in PR1784, so marking this as a duplicate of that.
*** This bug has been marked as a duplicate of bug 1784 ***
--
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 Feb 2 05:01:39 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 2 Feb 2010 05:01:39 -0600
Subject: [LLVMbugs] [Bug 6209] New: Keep Results Into SIMD Registers
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6209
Summary: Keep Results Into SIMD Registers
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: All
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
An article by Gustavo Oliveira:
http://www.gamasutra.com/view/feature/4248/designing_fast_crossplatform_simd_.php?page=3
See the part: 2. Keep Results Into SIMD Registers
It suggests to don't write code like this (note the deltalength, that's a
float):
Vec4& x2 = m_x[i2];
Vec4 delta = x2-x1;
float deltalength = Sqrt(Dot(delta,delta));
float diff = (deltalength-restlength)/deltalength;
x1 += delta*half*diff;
x2 -= delta*half*diff;
He says that's expensive since the compiler needs to generate code that will
move data from and to the SIMD and FPU registers. He suggests to write it like
this, assuming the "Dot" function above replicates the result into the SIMD
4-quad words and the "w" component zeroed-out. Now the expensive casting
operations are no longer necessary:
Vec4& x2 = m_x[i2];
Vec4 delta = x2-x1;
Vec4 deltalength = Sqrt(Dot(delta,delta));
Vec4 diff = (deltalength-restlength)/deltalength;
x1 += delta*half*diff;
x2 -= delta*half*diff;
Maybe LLVM can sometimes perform a similar optimization (I think it's not
already done by LLVM, but I can be wrong).
--------------------
Below there's another interesting section:
3. Re-Arrange Data to Be Friendly to SIMD operations
But this looks like an optimization harder to do for a C compiler.
--
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 Feb 2 05:04:55 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 2 Feb 2010 05:04:55 -0600
Subject: [LLVMbugs] [Bug 6210] New: -O3, -Os, -Oe: optimize for running time,
binary size, or energy
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6210
Summary: -O3, -Os, -Oe: optimize for running time, binary size,
or energy
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Keywords: 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
Current CPUs like Core duo or i7 are quite redundant, they can perform the same
operations in various ways. Such ways use different amounts of electricity.
Even stripped down CPUs like Atom have some redundancy.
In very big data centres, like Google ones, the limiting factor is often the
amount of electricity used by the very large number of computers present.
Mobile phones, ebook readers, and similar gadgets often have powerful 32 bit
CPUs with many MB of RAM, but for them it's important to maximize the number of
hours they can run with a battery charge.
So in theory it can be added a "-Oe" compilation argument to LLVM that tells
the compiler to compile the code trying to minimize the amount of electricity
the running program will use on the specified CPU.
For example in -Oe mode the compiler can do the opposite of what I've written
in bug 6209, and use the FP stack to store a single float value, saving the
power needed to store an move around 128 bits in a SSE register.
--
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 Feb 2 07:53:21 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 2 Feb 2010 07:53:21 -0600
Subject: [LLVMbugs] [Bug 6212] New: Clang misses optimisation on if vs else
if
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6212
Summary: Clang misses optimisation on if vs else if
Product: libraries
Version: trunk
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Scalar Optimizations
AssignedTo: unassignedbugs at nondot.org
ReportedBy: arplynn at gmail.com
CC: llvmbugs at cs.uiuc.edu
int test1(int mainType, int subType)
{
if(mainType == 7)
{
subType = 4;
}
else if(mainType == 9)
{
subType = 6;
}
else if(mainType == 11)
{
subType = 9;
}
return subType;
}
int test2(int mainType, int subType)
{
if(mainType == 7)
{
subType = 4;
}
if(mainType == 9)
{
subType = 6;
}
if(mainType == 11)
{
subType = 9;
}
return subType;
}
Clang generates more efficient code in the second case than the first, because
the first is transformed into a switch which then gets expanded to longer code
by the code generator.
--
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 Feb 2 09:40:01 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 2 Feb 2010 09:40:01 -0600
Subject: [LLVMbugs] [Bug 6213] New: llvm-config --cflags differ when
compiled using cmake/ configure
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6213
Summary: llvm-config --cflags differ when compiled using
cmake/configure
Product: tools
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: llvm-config
AssignedTo: unassignedbugs at nondot.org
ReportedBy: xerxes at zafena.se
CC: llvmbugs at cs.uiuc.edu
svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
mkdir llvm-configure
mkdir llvm-cmake
configure:
cd llvm-configure
../llvm/configure
make
xerxes at xerxes-J464X:~/llvmtest/llvm-configure/Debug/bin$ ./llvm-config --cflags
-I/home/xerxes/llvmtest/llvm-configure/../llvm/include
-I/home/xerxes/llvmtest/llvm-configure/include -D_DEBUG -D_GNU_SOURCE
-D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -g -fPIC
CMAKE:
cd llvm-cmake
cmake ../llvm
make
xerxes at xerxes-J464X:~/llvmtest/llvm-cmake/bin$ ./llvm-config --cflags
-I/home/xerxes/llvmtest/llvm/include -I/home/xerxes/llvmtest/llvm-cmake/include
-D_GNU_SOURCE -fPIC -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -Wall -W
-Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long
as can be seen cmake generated llvm-config reports totally different cflags
than the configure generated dito.
some of the options really break a lot of external projects like the -pedantic
--
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 Feb 2 11:32:55 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 2 Feb 2010 11:32:55 -0600
Subject: [LLVMbugs] [Bug 6208] ; after struct definition
In-Reply-To:
Message-ID: <201002021732.o12HWtXL008636@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6208
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Chris Lattner 2010-02-02 11:32:55 ---
Fixed:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100201/027041.html
C is a horrible horrible language :)
--
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 Feb 2 12:10:03 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 2 Feb 2010 12:10:03 -0600
Subject: [LLVMbugs] [Bug 6210] -O3, -Os, -Oe: optimize for running time,
binary size, or energy
In-Reply-To:
Message-ID: <201002021810.o12IA3gO010224@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6210
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Chris Lattner 2010-02-02 12:10:03 ---
Almost all computer literature shows that the best way to save power (on
mainstream cpus that don't have super crazy power features) is to execute code
faster so that the chip can enter a low power state sooner. Faster = lower
power.
--
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 Feb 2 16:00:36 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 2 Feb 2010 16:00:36 -0600
Subject: [LLVMbugs] [Bug 6115] What does 'Cannot yet select: intrinsic
%llvm.x86.sse41.dpps' mean?
In-Reply-To:
Message-ID: <201002022200.o12M0a8v020657@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6115
Eric Christopher changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |WORKSFORME
--- Comment #7 from Eric Christopher 2010-02-02 16:00:35 ---
FWIW llc is the easiest way to turn a .ll to a .s file.
--
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 Feb 2 16:14:50 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 2 Feb 2010 16:14:50 -0600
Subject: [LLVMbugs] [Bug 6214] New: scalar absolute value of single
precision floating point values
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6214
Summary: scalar absolute value of single precision floating point
values
Product: libraries
Version: 2.6
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Backend: X86
AssignedTo: unassignedbugs at nondot.org
ReportedBy: llvm at henning-thielemann.de
CC: llvmbugs at cs.uiuc.edu
I noticed that LLVM uses SSE registers also for scalar floating point
operations.
Thus when I want to compute the absolute value,
it would be certainly most efficient to implement it using 'andss' or 'andsd'
with an appropriate mask to clear the sign bit.
(Similarly LLVM's X86 backend implements negation using 'xorss'.)
However, when I cast a single precision floating point value to a 32 bit
integer and clear the sign bit in this representation,
then the X86 code generator moves the floating point value to a general purpose
register, clears the sign bit there and moves the floating point value back to
an XMM register for subsequent operations.
The only way to stay in XMM registers is to cast the whole vector to a 32 bit
integer vector and apply an 128 bit mask that clears bit 31.
This would be certainly inefficient, if the floating point number was in an FPU
register before. (But so far I have never seen LLVM using FPU registers. I have
only seen XMM usage and calls to math lib for sin, cos, exp.)
--
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 Feb 2 16:27:18 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 2 Feb 2010 16:27:18 -0600
Subject: [LLVMbugs] [Bug 6215] New: Target dependent selection of intrinsics
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6215
Summary: Target dependent selection of intrinsics
Product: libraries
Version: 2.6
Platform: PC
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: Backend: X86
AssignedTo: unassignedbugs at nondot.org
ReportedBy: llvm at henning-thielemann.de
CC: llvmbugs at cs.uiuc.edu
Using the LLVM interface for Haskell I generate, compile and run llvm code at
runtime of a Haskell program. I want to make use of special SSE commands like
'haddps', 'minps', 'dpps' if the corresponding SSE intruction set is available
on the machine the program runs on. I have found that X86Subtarget has methods
hasSSE3 and friends that would solve the problem. However, they do not seem to
be available in the C interface.
Thus my feature request is to add according functions to the C interface to
LLVM or to extend documentation by a paragraph on how to access hasSSE checks
with the current C interface. Maybe I have to write such C wrappers myself?
--
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 Feb 2 16:41:22 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 2 Feb 2010 16:41:22 -0600
Subject: [LLVMbugs] [Bug 6215] Target dependent selection of intrinsics
In-Reply-To:
Message-ID: <201002022241.o12MfMcG022622@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6215
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Chris Lattner 2010-02-02 16:41:21 ---
You can already detect what CPU you're on by using the CPUID instruction
directly. The intrinsics for these SSE instructions you want are already
exposed by llvm.x86.foo 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 Tue Feb 2 18:47:58 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 2 Feb 2010 18:47:58 -0600
Subject: [LLVMbugs] [Bug 6216] New: Parse failure with struct definition in
__builtin_offset
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6216
Summary: Parse failure with struct definition in __builtin_offset
Product: clang
Version: trunk
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: parser
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: dgregor at apple.com
CC: llvmbugs at cs.uiuc.edu
blackthorn:clang dgregor$ cat t.c
int f() { return __builtin_offsetof(struct { char c; int i; }, i); }
blackthorn:clang dgregor$ gcc -fsyntax-only t.c
blackthorn:clang dgregor$ clang -fsyntax-only t.c
t.c:1:62: error: expected ';' after struct
int f() { return __builtin_offsetof(struct { char c; int i; }, i); }
^
;
t.c:1:62: error: expected ','
int f() { return __builtin_offsetof(struct { char c; int i; }, i); }
^
,
t.c:1:62: error: expected expression
t.c:1:65: error: expected expression
int f() { return __builtin_offsetof(struct { char c; int i; }, i); }
^
4 diagnostics generated.
--
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 Feb 2 19:45:47 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 2 Feb 2010 19:45:47 -0600
Subject: [LLVMbugs] [Bug 6216] Parse failure with struct definition in
__builtin_offset
In-Reply-To:
Message-ID: <201002030145.o131jl49031354@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6216
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Chris Lattner 2010-02-02 19:45:46 ---
Fixed:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100201/027065.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 Feb 2 20:28:31 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 2 Feb 2010 20:28:31 -0600
Subject: [LLVMbugs] [Bug 6218] New: Broken debug info for almost every c++
app
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6218
Summary: Broken debug info for almost every c++ app
Product: clang
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: asl at math.spbu.ru
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=4167)
--> (http://llvm.org/bugs/attachment.cgi?id=4167)
Bitcode
Consider the attached .bc produced by clang++ -g, the generated assembler is
invalid:
$llc main.bc && gcc -g main.s
main.s: Assembler messages:
main.s:35733: Fatal error: duplicate .debug_line sections
and indeed:
$ grep -n debug_line main.s
12: .section .debug_line,"", at progbits
31370: .section .debug_line,"", 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 Wed Feb 3 07:13:46 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 3 Feb 2010 07:13:46 -0600
Subject: [LLVMbugs] [Bug 6219] New: Tablegen lexer misreading cmp${cc}pd ?
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6219
Summary: Tablegen lexer misreading cmp${cc}pd ?
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
Recently tblgen started throwing (and catching) an exception internally during
the LLVM build. It doesn't like this snippet from X86InstrSSE.td:
def CMPPDrmi : PDIi8<0xC2, MRMSrcMem,
(outs VR128:$dst), (ins VR128:$src1, f128mem:$src,
SSECC:$cc),
"cmp${cc}pd\t{$src, $dst|$dst, $src}",
[(set VR128:$dst, (int_x86_sse2_cmp_pd VR128:$src1,
The exception is thrown in getOperandNamed with the message:
Instruction 'CMPPDrmi' does not have an operand named '$ccpd'!
It looks like ${cc}pd is being wrongly parsed as ccpd.
--
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 Feb 3 10:17:10 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 3 Feb 2010 10:17:10 -0600
Subject: [LLVMbugs] [Bug 6221] New: ExecutionEngine::create is ambiguous as
of 94686
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6221
Summary: ExecutionEngine::create is ambiguous as of 94686
Product: libraries
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Generic Execution Engine Support
AssignedTo: unassignedbugs at nondot.org
ReportedBy: ddneff at hotmail.com
CC: llvmbugs at cs.uiuc.edu
ExecutionEngine has two create functions:
static ExecutionEngine* create(Module *M);
static ExecutionEngine *create(Module *M,
bool ForceInterpreter = false,
std::string *ErrorStr = 0,
CodeGenOpt::Level OptLevel =
CodeGenOpt::Default,
bool GVsWithCode = true);
Notice that the second version has the same first parameter type as the first,
and all of the following arguments have default parameters. GCC4.3 (probably
others) won't let you call the first version because its ambiguous, so it might
as well be removed.
--
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 Feb 3 11:48:08 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 3 Feb 2010 11:48:08 -0600
Subject: [LLVMbugs] [Bug 6222] New: Assert "getTerminator returned null" for
a verified function
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6222
Summary: Assert "getTerminator returned null" for a verified
function
Product: new-bugs
Version: trunk
Platform: Macintosh
URL: http://xlr.sf.net
OS/Version: MacOS X
Status: NEW
Keywords: crash-on-invalid, regression
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: christophe at taodyne.com
CC: llvmbugs at cs.uiuc.edu
This is exposed by test 02.Data/rects.xl in the test suite of the XL compiler.
We generate functions by exploring a tree of possibilities. In some cases, we
will drop code that we generated. This may result in a basic block that is not
properly terminated. This passes "verifyFunction" but then asserts in
JIT::getPointerToFunction.
The stack trace for the assert is:
#0 llvm::SuccIterator::SuccIterator
(this=0x7fff5fbfd4a0, T=0x0) at CFG.h:99
#1 0x0000000100682e0f in llvm::succ_begin (BB=0x1022bbb80) at CFG.h:204
#2 0x0000000100696379 in llvm::GraphTraits::child_begin
(N=0x1022bbb80) at CFG.h:231
#3 0x000000010083bc4d in llvm::DFSPass >
(DT=@0x1022263c0, V=0x1022bbb80, N=0) at DominatorInternals.h:65
#4 0x000000010083bfb3 in llvm::Calculate
(DT=@0x1022263c0, F=@0x1022bbaa0) at DominatorInternals.h:253
#5 0x000000010083c6a1 in
llvm::DominatorTreeBase::recalculate
(this=0x1022263c0, F=@0x1022bbaa0) at Dominators.h:671
#6 0x000000010083319b in llvm::DominatorTree::runOnFunction (this=0x102226390,
F=@0x1022bbaa0) at Dominators.cpp:58
#7 0x00000001008932f2 in llvm::FPPassManager::runOnFunction (this=0x102224bd0,
F=@0x1022bbaa0) at PassManager.cpp:1348
#8 0x0000000100894f65 in llvm::FunctionPassManagerImpl::run (this=0x102224660,
F=@0x1022bbaa0) at PassManager.cpp:1300
#9 0x0000000100895114 in llvm::FunctionPassManager::run (this=0x102223ca0,
F=@0x1022bbaa0) at PassManager.cpp:1230
#10 0x00000001005039d3 in llvm::JIT::runJITOnFunctionUnlocked
(this=0x102224560, F=0x1022ccef0, locked=@0x7fff5fbfdb00) at JIT.cpp:642
#11 0x0000000100503c72 in llvm::JIT::getPointerToFunction (this=0x102224560,
F=0x1022ccef0) at JIT.cpp:680
#12 0x000000010003e5ea in XL::CompiledUnit::Finalize (this=0x7fff5fbfdbe0) at
compiler.cpp:599
The basic block being looked at contains the following:
p debugv(BB)
allocas:
%result = alloca %tree* ; <%tree**> [#uses=3]
store %tree* %0, %tree** %result
%loc1 = alloca %tree* ; <%tree**> [#uses=1]
%loc2 = alloca %tree* ; <%tree**> [#uses=4]
%computed = alloca i1 ; [#uses=4]
store i1 false, i1* %computed
%loc3 = alloca %tree* ; <%tree**> [#uses=1]
%loc4 = alloca %tree* ; <%tree**> [#uses=1]
%treek = load %tree** @xlcst7 ; <%tree*> [#uses=2]
store %tree* %treek, %tree** %loc2
%loc6 = alloca %tree* ; <%tree**> [#uses=2]
%computed7 = alloca i1 ; [#uses=3]
store i1 false, i1* %computed7
%loc12 = alloca %tree* ; <%tree**> [#uses=2]
%computed15 = alloca i1 ; [#uses=3]
store i1 false, i1* %computed15
%loc17 = alloca %tree* ; <%tree**> [#uses=6]
store %tree* %1, %tree** %loc17
%loc22 = alloca %tree* ; <%tree**> [#uses=9]
%computed23 = alloca i1 ; [#uses=7]
store i1 false, i1* %computed23
%loc29 = alloca %tree* ; <%tree**> [#uses=2]
%computed30 = alloca i1 ; [#uses=3]
store i1 false, i1* %computed30
%loc31 = alloca %tree* ; <%tree**> [#uses=4]
%computed34 = alloca i1 ; [#uses=9]
store i1 false, i1* %computed34
%loc36 = alloca %tree* ; <%tree**> [#uses=20]
store %tree* %2, %tree** %loc36
%loc44 = alloca %tree* ; <%tree**> [#uses=2]
%computed45 = alloca i1 ; [#uses=3]
store i1 false, i1* %computed45
%treek49 = load %tree** @xlcst9 ; <%tree*> [#uses=2]
store %tree* %treek49, %tree** %loc22
%loc55 = alloca %tree* ; <%tree**> [#uses=2]
%computed56 = alloca i1 ; [#uses=3]
store i1 false, i1* %computed56
%loc68 = alloca %tree* ; <%tree**> [#uses=2]
%computed69 = alloca i1 ; [#uses=3]
store i1 false, i1* %computed69
%treek87 = load %tree** @xlcst14 ; <%tree*> [#uses=2]
store %tree* %treek87, %tree** %loc6
The function doesn't really look like it uses that basic block anymore:
define internal %tree* @xl_eval15(%tree*, %tree*) {
allocas:
%treek = load %tree** @xlcst17 ; <%tree*> [#uses=1]
%treek71 = load %tree** @xlcst20 ; <%tree*> [#uses=0]
%glob = load %tree** @xlint16 ; <%tree*> [#uses=1]
%2 = tail call %tree* @xl_eval4(%tree* %treek, %tree* %1, %tree* %glob) ;
<%tree*> [#uses=1]
%3 = tail call %tree* @xl_evaluate(%tree* %2) ; <%tree*> [#uses=0]
%glob80 = load %tree** @xlcst19 ; <%tree*> [#uses=1]
%4 = tail call %tree* (%tree*, i32, ...)* @xl_new_closure(%tree* %glob80, i32
1, %tree* %1) ; <%tree*> [#uses=1]
%glob83 = load %tree** @xlcst20 ; <%tree*> [#uses=1]
%glob85 = load %tree** @xlint22 ; <%tree*> [#uses=1]
%5 = tail call %tree* @xl_eval3(%tree* %glob83, %tree* %4, %tree* %glob85) ;
<%tree*> [#uses=1]
%6 = tail call %tree* @xl_evaluate(%tree* %5) ; <%tree*> [#uses=1]
%7 = tail call %tree* @xl_evaluate(%tree* %6) ; <%tree*> [#uses=1]
ret %tree* %7
}
Before optimizations, it looked like:
define internal %tree* @xl_eval15(%tree*, %tree*) {
allocas:
%result = alloca %tree* ; <%tree**> [#uses=4]
store %tree* %0, %tree** %result
%loc1 = alloca %tree* ; <%tree**> [#uses=5]
%loc2 = alloca %tree* ; <%tree**> [#uses=4]
%computed = alloca i1 ; [#uses=4]
store i1 false, i1* %computed
%loc3 = alloca %tree* ; <%tree**> [#uses=1]
%treek = load %tree** @xlcst17 ; <%tree*> [#uses=2]
store %tree* %treek, %tree** %loc2
%loc5 = alloca %tree* ; <%tree**> [#uses=8]
%computed6 = alloca i1 ; [#uses=7]
store i1 false, i1* %computed6
%loc11 = alloca %tree* ; <%tree**> [#uses=5]
%computed12 = alloca i1 ; [#uses=4]
store i1 false, i1* %computed12
%loc19 = alloca %tree* ; <%tree**> [#uses=1]
%computed20 = alloca i1 ; [#uses=2]
store i1 false, i1* %computed20
%loc21 = alloca %tree* ; <%tree**> [#uses=2]
%computed24 = alloca i1 ; [#uses=5]
store i1 false, i1* %computed24
%loc26 = alloca %tree* ; <%tree**> [#uses=10]
store %tree* %1, %tree** %loc26
%loc32 = alloca %tree* ; <%tree**> [#uses=1]
%computed33 = alloca i1 ; [#uses=2]
store i1 false, i1* %computed33
%treek38 = load %tree** @xlcst19 ; <%tree*> [#uses=2]
store %tree* %treek38, %tree** %loc11
%loc44 = alloca %tree* ; <%tree**> [#uses=1]
%computed45 = alloca i1 ; [#uses=2]
store i1 false, i1* %computed45
%loc57 = alloca %tree* ; <%tree**> [#uses=1]
%computed58 = alloca i1 ; [#uses=2]
store i1 false, i1* %computed58
%treek71 = load %tree** @xlcst20 ; <%tree*> [#uses=2]
store %tree* %treek71, %tree** %loc5
%loc76 = alloca %tree* ; <%tree**> [#uses=2]
%2 = load %tree** @xlcst19 ; <%tree*> [#uses=1]
store %tree* %2, %tree** %loc76
%loc81 = alloca %tree* ; <%tree**> [#uses=3]
%3 = load %tree** @xlcst19 ; <%tree*> [#uses=1]
store %tree* %3, %tree** %loc81
%computed89 = alloca i1 ; [#uses=3]
store i1 false, i1* %computed89
%computed92 = alloca i1 ; [#uses=2]
store i1 false, i1* %computed92
br label %entry
entry: ; preds = %allocas
%loc = load %tree** %result ; <%tree*> [#uses=1]
store %tree* %loc, %tree** %loc1
%lazy = load i1* %computed ; [#uses=1]
br i1 %lazy, label %skip, label %work
exit: ; preds = %skip7
%retval = load %tree** %result ; <%tree*> [#uses=1]
ret %tree* %retval
skip: ; preds = %empty, %subexpr,
%entry
%loc4 = load %tree** %loc2 ; <%tree*> [#uses=1]
%4 = call %tree* @xl_evaluate(%tree* %loc4) ; <%tree*> [#uses=1]
store %tree* %4, %tree** %loc2
store i1 true, i1* %computed
%lazy9 = load i1* %computed6 ; [#uses=1]
br i1 %lazy9, label %skip7, label %work8
work: ; preds = %entry
br label %subexpr
subexpr: ; preds = %work
store %tree* %1, %tree** %loc3
%intk = load %tree** @xlint16 ; <%tree*> [#uses=0]
%glob = load %tree** @xlint16 ; <%tree*> [#uses=1]
%5 = call %tree* @xl_eval4(%tree* %treek, %tree* %1, %tree* %glob) ; <%tree*>
[#uses=1]
store %tree* %5, %tree** %loc2
store i1 true, i1* %computed
br label %skip
empty: ; No predecessors!
br label %skip
skip7: ; preds = %empty86,
%subexpr78, %skip
%loc87 = load %tree** %loc5 ; <%tree*> [#uses=1]
%6 = call %tree* @xl_evaluate(%tree* %loc87) ; <%tree*> [#uses=1]
store %tree* %6, %tree** %loc5
store i1 true, i1* %computed6
%loc88 = load %tree** %loc5 ; <%tree*> [#uses=1]
store %tree* %loc88, %tree** %loc1
store i1 true, i1* %computed89
%loc90 = load %tree** %loc1 ; <%tree*> [#uses=1]
%7 = call %tree* @xl_evaluate(%tree* %loc90) ; <%tree*> [#uses=1]
store %tree* %7, %tree** %loc1
store i1 true, i1* %computed89
%loc91 = load %tree** %loc1 ; <%tree*> [#uses=1]
store %tree* %loc91, %tree** %result
store i1 true, i1* %computed92
br label %exit
work8: ; preds = %skip
br label %subexpr78
subexpr10: ; No predecessors!
%lazy15 = load i1* %computed12 ; [#uses=1]
br i1 %lazy15, label %skip13, label %work14
skip13: ; preds = %fail53, %isGood62,
%isGood37, %subexpr10
%loc67 = load %tree** %loc11 ; <%tree*> [#uses=1]
%tagPtr = getelementptr %tree* %loc67, i32 0, i32 0 ; [#uses=1]
%tag = load i64* %tagPtr ; [#uses=1]
%tagAndMask = and i64 %tag, 7 ; [#uses=1]
%isRightTag = icmp eq i64 %tagAndMask, 0 ; [#uses=1]
br i1 %isRightTag, label %isRightKind, label %fail66
work14: ; preds = %subexpr10
br label %subexpr16
subexpr16: ; preds = %work14
%glob17 = load %tree** @integer ; <%tree*> [#uses=0]
%glob18 = load %tree** @integer ; <%tree*> [#uses=1]
store %tree* %glob18, %tree** %loc19
store i1 true, i1* %computed20
store %tree* %1, %tree** %loc21
%lazy25 = load i1* %computed24 ; [#uses=1]
br i1 %lazy25, label %skip22, label %work23
skip22: ; preds = %work23, %subexpr16
%loc28 = load %tree** %loc26 ; <%tree*> [#uses=1]
%glob29 = load %tree** @integer ; <%tree*> [#uses=1]
%8 = call i1 @xl_type_check(%tree* %loc28, %tree* %glob29) ; [#uses=1]
br i1 %8, label %isGood, label %fail
work23: ; preds = %subexpr16
%loc27 = load %tree** %loc26 ; <%tree*> [#uses=1]
%9 = call %tree* @xl_evaluate(%tree* %loc27) ; <%tree*> [#uses=1]
store %tree* %9, %tree** %loc26
store i1 true, i1* %computed24
br label %skip22
fail: ; preds = %isGood, %skip22
br label %subexpr41
isGood: ; preds = %skip22
%glob30 = load %tree** @integer ; <%tree*> [#uses=0]
%glob31 = load %tree** @integer ; <%tree*> [#uses=1]
store %tree* %glob31, %tree** %loc32
store i1 true, i1* %computed33
%intk34 = load %tree** @xlint18 ; <%tree*> [#uses=0]
%glob35 = load %tree** @xlint18 ; <%tree*> [#uses=1]
%glob36 = load %tree** @integer ; <%tree*> [#uses=1]
%10 = call i1 @xl_type_check(%tree* %glob35, %tree* %glob36) ; [#uses=1]
br i1 %10, label %isGood37, label %fail
isGood37: ; preds = %isGood
%loc39 = load %tree** %loc26 ; <%tree*> [#uses=1]
%glob40 = load %tree** @xlint18 ; <%tree*> [#uses=1]
%11 = call %tree* @xl_BinarySubInt(%tree* %treek38, %tree* %loc39, %tree*
%glob40) ; <%tree*> [#uses=1]
store %tree* %11, %tree** %loc11
store i1 true, i1* %computed12
br label %skip13
subexpr41: ; preds = %fail
%glob42 = load %tree** @real ; <%tree*> [#uses=0]
%glob43 = load %tree** @real ; <%tree*> [#uses=1]
store %tree* %glob43, %tree** %loc44
store i1 true, i1* %computed45
%loc46 = load %tree** %loc26 ; <%tree*> [#uses=1]
store %tree* %loc46, %tree** %loc21
%lazy49 = load i1* %computed24 ; [#uses=1]
br i1 %lazy49, label %skip47, label %work48
skip47: ; preds = %work48, %subexpr41
%loc51 = load %tree** %loc26 ; <%tree*> [#uses=1]
%glob52 = load %tree** @real ; <%tree*> [#uses=1]
%12 = call i1 @xl_type_check(%tree* %loc51, %tree* %glob52) ; [#uses=1]
br i1 %12, label %isGood54, label %fail53
work48: ; preds = %subexpr41
%loc50 = load %tree** %loc26 ; <%tree*> [#uses=1]
%13 = call %tree* @xl_evaluate(%tree* %loc50) ; <%tree*> [#uses=1]
store %tree* %13, %tree** %loc26
store i1 true, i1* %computed24
br label %skip47
fail53: ; preds = %isGood54, %skip47
br label %skip13
isGood54: ; preds = %skip47
%glob55 = load %tree** @real ; <%tree*> [#uses=0]
%glob56 = load %tree** @real ; <%tree*> [#uses=1]
store %tree* %glob56, %tree** %loc57
store i1 true, i1* %computed58
%glob59 = load %tree** @xlint18 ; <%tree*> [#uses=0]
%glob60 = load %tree** @xlint18 ; <%tree*> [#uses=1]
%glob61 = load %tree** @real ; <%tree*> [#uses=1]
%14 = call i1 @xl_type_check(%tree* %glob60, %tree* %glob61) ; [#uses=1]
br i1 %14, label %isGood62, label %fail53
isGood62: ; preds = %isGood54
%glob63 = load %tree** @xlcst19 ; <%tree*> [#uses=1]
%loc64 = load %tree** %loc26 ; <%tree*> [#uses=1]
%glob65 = load %tree** @xlint18 ; <%tree*> [#uses=1]
%15 = call %tree* @xl_BinarySubReal(%tree* %glob63, %tree* %loc64, %tree*
%glob65) ; <%tree*> [#uses=1]
store %tree* %15, %tree** %loc11
store i1 true, i1* %computed12
br label %skip13
fail66: ; preds = %isRightKind,
%skip13
%glob72 = load %tree** @xlcst20 ; <%tree*> [#uses=1]
%16 = call %tree* @xl_type_error(%tree* %glob72) ; <%tree*> [#uses=1]
store %tree* %16, %tree** %loc5
store i1 true, i1* %computed6
unreachable
isRightKind: ; preds = %skip13
%loc68 = load %tree** %loc11 ; <%tree*> [#uses=1]
%17 = bitcast %tree* %loc68 to %integer* ; <%integer*> [#uses=1]
%18 = getelementptr %integer* %17, i32 0, i32 4 ; [#uses=1]
%treeValue = load i64* %18 ; [#uses=1]
%isGood69 = icmp eq i64 %treeValue, 0 ; [#uses=1]
br i1 %isGood69, label %isGood70, label %fail66
isGood70: ; preds = %isRightKind
%19 = call %tree* @xl_type_error(%tree* %treek71) ; <%tree*> [#uses=1]
store %tree* %19, %tree** %loc5
store i1 true, i1* %computed6
unreachable
subexpr73: ; No predecessors!
%glob74 = load %tree** @xlcst19 ; <%tree*> [#uses=0]
%glob75 = load %tree** @xlcst19 ; <%tree*> [#uses=1]
%20 = call %tree* (%tree*, i32, ...)* @xl_new_closure(%tree* %glob75, i32 1,
%tree* %1) ; <%tree*> [#uses=1]
store %tree* %20, %tree** %loc76
%glob77 = load %tree** @xlcst20 ; <%tree*> [#uses=1]
%21 = call %tree* @xl_type_error(%tree* %glob77) ; <%tree*> [#uses=1]
store %tree* %21, %tree** %loc5
store i1 true, i1* %computed6
unreachable
subexpr78: ; preds = %work8
%glob79 = load %tree** @xlcst19 ; <%tree*> [#uses=0]
%glob80 = load %tree** @xlcst19 ; <%tree*> [#uses=1]
%22 = call %tree* (%tree*, i32, ...)* @xl_new_closure(%tree* %glob80, i32 1,
%tree* %1) ; <%tree*> [#uses=1]
store %tree* %22, %tree** %loc81
%intk82 = load %tree** @xlint22 ; <%tree*> [#uses=0]
%glob83 = load %tree** @xlcst20 ; <%tree*> [#uses=1]
%loc84 = load %tree** %loc81 ; <%tree*> [#uses=1]
%glob85 = load %tree** @xlint22 ; <%tree*> [#uses=1]
%23 = call %tree* @xl_eval3(%tree* %glob83, %tree* %loc84, %tree* %glob85) ;
<%tree*> [#uses=1]
store %tree* %23, %tree** %loc5
store i1 true, i1* %computed6
br label %skip7
empty86: ; No predecessors!
br label %skip7
}
I will fix my side (making sure there is a terminator), but I think that
verifyFunction should have caught it. Also, I am pretty sure that the same
input used to work, although due to numerous incompatible changes in the LLVM
source-code, I have not been able to do a full regression analysis.
--
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 Feb 3 13:18:33 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 3 Feb 2010 13:18:33 -0600
Subject: [LLVMbugs] [Bug 6221] ExecutionEngine::create is ambiguous as of
94686
In-Reply-To:
Message-ID: <201002031918.o13JIXtW025477@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6221
Jeffrey Yasskin changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Jeffrey Yasskin 2010-02-03 13:18:32 ---
Oops. Should be fixed in r95236. Thanks for the report.
--
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 Feb 3 13:48:54 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 3 Feb 2010 13:48:54 -0600
Subject: [LLVMbugs] [Bug 4409] LLVM needs a tool for pattern matching LLVM IR
In-Reply-To:
Message-ID: <201002031948.o13JmsJM026856@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=4409
Daniel Dunbar changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Daniel Dunbar 2010-02-03 13:48:54 ---
FileCheck has basically solved 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 Wed Feb 3 15:59:30 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 3 Feb 2010 15:59:30 -0600
Subject: [LLVMbugs] [Bug 6223] New: ARM thumb target fails to JIT tPUSH
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6223
Summary: ARM thumb target fails to JIT tPUSH
Product: libraries
Version: trunk
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Backend: ARM
AssignedTo: unassignedbugs at nondot.org
ReportedBy: xerxes at zafena.se
CC: llvmbugs at cs.uiuc.edu
Running LLVM built on Ubuntu Lucid thumb-unknown-linux-gnueabi host.
xerxes at babbage-lucid:/wd/llvm-configure/test/ExecutionEngine/Output$ lli
-mtriple=thumb -debug hello.ll.tmp.bc
...
JITTing function 'main'
JIT: Starting CodeGen of Function main
JIT: Emitting BB0 at [0x40294010]
JIT: 0x40294010: tPUSH pred:14, pred:%reg0, %reg0, %R7, %LR,
%SP, %SP
Unhandled instruction encoding format!
UNREACHABLE executed at /wd/llvm/lib/Target/ARM/ARMCodeEmitter.cpp:313
Stack dump:
0. Program arguments: lli hello.ll.tmp.bc
1. Running pass 'ARM Machine Code Emitter' on function '@main'
Aborted (core dumped)
xerxes at babbage-lucid:/wd/llvm-configure/test/ExecutionEngine/Output$ lli
-version
Low Level Virtual Machine (http://llvm.org/):
llvm version 2.7svn
Optimized build with assertions.
Built Feb 3 2010 (10:13:03).
Host: thumb-unknown-linux-gnueabi
Host CPU: (unknown)
Registered Targets:
arm - ARM
thumb - Thumb
--
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 Feb 3 16:20:49 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 3 Feb 2010 16:20:49 -0600
Subject: [LLVMbugs] [Bug 6224] New: The x86 Disassembler (edis) is built
even if x86 target is not selected -> build fails
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6224
Summary: The x86 Disassembler (edis) is built even if x86 target
is not selected -> build fails
Product: tools
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: llvmc
AssignedTo: unassignedbugs at nondot.org
ReportedBy: zapster at zapster.cc
CC: llvmbugs at cs.uiuc.edu
The x86 disassembler is built if x86 target is not enabled. Edis should be
disabled if the x86 target is not selected.
build steps:
$ ../llvm/configure --disable-optimized --enable-targets=pic16 ; make -j2
...
llvm[3]: Linking Debug executable llvmc
/home/zapster/test/llvm/tools/edis/EDDisassembler.cpp:56: error:
???instInfoX86??? was not declared in this scope
/home/zapster/test/llvm/tools/edis/EDDisassembler.cpp:57: error:
???instInfoX86??? was not declared in this scope
/home/zapster/test/llvm/tools/edis/EDDisassembler.cpp:59: error: too many
initializers for ???InfoMap???
/home/zapster/test/llvm/tools/edis/EDDisassembler.cpp:59: error: too many
initializers for ???InfoMap???
/home/zapster/test/llvm/tools/edis/EDDisassembler.cpp: In static member
function ???static void EDDisassembler::initialize()???:
/home/zapster/test/llvm/tools/edis/EDDisassembler.cpp:114: error:
???LLVMInitializeX86TargetInfo??? was not declared in this scope
/home/zapster/test/llvm/tools/edis/EDDisassembler.cpp:114: error:
???LLVMInitializeX86Target??? was not declared in this scope
/home/zapster/test/llvm/tools/edis/EDDisassembler.cpp:114: error:
???LLVMInitializeX86AsmPrinter??? was not declared in this scope
/home/zapster/test/llvm/tools/edis/EDDisassembler.cpp:114: error:
???LLVMInitializeX86AsmParser??? was not declared in this scope
/home/zapster/test/llvm/tools/edis/EDDisassembler.cpp:114: error:
???LLVMInitializeX86Disassembler??? was not declared in this scope
make[2]: *** [/home/zapster/test/build/tools/edis/Debug/EDDisassembler.o] Error
1
make[2]: Leaving directory `/home/zapster/test/build/tools/edis'
make[1]: *** [edis/.makeall] Error 2
...
--
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 Feb 3 17:51:55 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 3 Feb 2010 17:51:55 -0600
Subject: [LLVMbugs] [Bug 6225] New: stack corruption with tail recursive
calls
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6225
Summary: stack corruption with tail recursive calls
Product: new-bugs
Version: 2.6
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: amanous at softlab.ntua.gr
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=4170)
--> (http://llvm.org/bugs/attachment.cgi?id=4170)
llvm program producing the bug
I have been using LLVM for quite some time now, for production of native
binaries for a compiler I am developing. The compiler works with continuations,
so I rely heavily on tail recursion (all my calls are "fastcc tail", the stack
never grows).
Lately I encountered a strange behavior. A binary produced by my compiler
finished computation and THEN segfaulted. The first thing that came to mind was
corruption of the return address, and after debugging with gdb it proved I was
correct.
After a lot of investigation of my entire compiler I traced the problem to the
llvm conversion. During a branching call, the llvm corrupted the return address
to the operating system, e.g. the contents of the location pointed by the stack
pointer when the program starts.
Attached is the smallest piece of code I could create that reproduces the bug.
I compile with :
llvm-as -f test.ll
llc -tailcallopt -asm-verbose -march x86 -f test.bc
gcc -g -Wall -m32 -c test.s
gcc -g -m32 -o test test.o
the binary "test" segfaults.
The interesting code fragment is:
----------------
define fastcc void @l186(%tupl_p %r1) noreturn nounwind {
entry:
...
br i1 %cond, label %true, label %false
true:
tail call fastcc void @l297(i32 %r10, i32 %r9, i32 %r8, i32 %r7, i32 %r6, i32
%r5, i32 %r3, i32 %r2) noreturn nounwind
ret void
false:
tail call fastcc void @l298(i32 %r10, i32 %r9, i32 %r4) noreturn nounwind
ret void
}
----------------
Which gets translated to:
----------------
l186:
.LBB1_0:
subl $24, %esp
pushl %ebp
pushl %ebx
pushl %edi
pushl %esi
subl $36, %esp
....
.LBB1_1: # %true
...
movl %ecx, 76(%esp)
...
----------------
The "movl %ecx, 76(%esp)" instruction overwrites the return address of the
program irreversibly. When the computation finishes, it will jump to this
address, causing a segmentation fault.
I tried the same program with the trunk version (a few days ago) and I get the
same assembly translation (and segfault of course).
--
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 Feb 3 21:14:23 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 3 Feb 2010 21:14:23 -0600
Subject: [LLVMbugs] [Bug 6227] New: can't build LLVM in debug mode on Ubuntu
9.10 on x86
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6227
Summary: can't build LLVM in debug mode on Ubuntu 9.10 on x86
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
Argh, the message below is pretty verbose... ring bells for anyone?
In release mode the compiler builds fine and works fine.
llvm[2]: Building Debug Bytecode Archive libprofile_rt.bca (internalize)
/home/regehr/z/tmp/llvm-r95278/Debug/bin/llvm-ld
-L/home/regehr/z/tmp/llvm-gcc-r95275-install/lib
-internalize-public-api-file=/home/regehr/z/tmp/llvm-r95278/runtime/libprofile/exported_symbols.lst
-o
/home/regehr/z/tmp/llvm-r95278/runtime/libprofile/Debug/profile_rt.internalize
/home/regehr/z/tmp/llvm-r95278/runtime/libprofile/Debug/BasicBlockTracing.bc
/home/regehr/z/tmp/llvm-r95278/runtime/libprofile/Debug/CommonProfiling.bc
/home/regehr/z/tmp/llvm-r95278/runtime/libprofile/Debug/EdgeProfiling.bc
/home/regehr/z/tmp/llvm-r95278/runtime/libprofile/Debug/OptimalEdgeProfiling.bc
LinkModules ValueMap:
Fr: 0x8ed1338 i32* null
To: 0x8ed1338 i32* null
Fr: 0x8ed4d14 @ArrayCursor = internal global i32* null ;
[#uses=1]
To: 0x8ed6514 @ArrayCursor = internal global i32* null ;
[#uses=5]
Fr: 0x8ed6294 @ArrayStart = internal global i32* null ;
[#uses=1]
To: 0x8ed2d8c @ArrayStart = internal global i32* null ;
[#uses=4]
Fr: 0x8ed62dc @ArrayEnd = internal global i32* null ;
[#uses=1]
To: 0x8ed2df4 @ArrayEnd = internal global i32* null ;
[#uses=1]
Fr: 0x8ed6340
declare void @write_profiling_data(i32, i32*, i32)
To: 0x8ed2e50
declare void @write_profiling_data(i32, i32*, i32)
Fr: 0x8ed6390
declare internal void @BBTraceAtExitHandler() nounwind
To: 0x8edb8a0
define internal void @BBTraceAtExitHandler() nounwind {
entry:
%0 = load i32** @ArrayCursor, align 4, !dbg !6 ; [#uses=1]
%1 = ptrtoint i32* %0 to i32, !dbg !6 ; [#uses=1]
%2 = load i32** @ArrayStart, align 4, !dbg !6 ; [#uses=2]
%3 = ptrtoint i32* %2 to i32, !dbg !6 ; [#uses=1]
%4 = sub nsw i32 %1, %3, !dbg !6 ; [#uses=1]
%5 = ashr i32 %4, 2 ; [#uses=1]
tail call void @write_profiling_data(i32 6, i32* %2, i32 %5) nounwind, !dbg
!6
%6 = load i32** @ArrayStart, align 4, !dbg !14 ; [#uses=2]
store i32* %6, i32** @ArrayCursor, align 4, !dbg !14
%7 = bitcast i32* %6 to i8*, !dbg !15 ; [#uses=1]
tail call void @free(i8* %7) nounwind, !dbg !15
ret void, !dbg !16
}
Fr: 0x8ed63e0
declare i32 @save_arguments(i32, i8**)
To: 0x8ed2938
declare i32 @save_arguments(i32, i8**)
Fr: 0x8ed6448
declare void @free(i8* nocapture) nounwind
To: 0x8edb820
declare void @free(i8* nocapture) nounwind
Fr: 0x8ed6498
declare void @llvm_trace_basic_block(i32) nounwind
To: 0x8edb720
define void @llvm_trace_basic_block(i32 %BBNum) nounwind {
entry:
%0 = load i32** @ArrayCursor, align 4, !dbg !6 ; [#uses=2]
store i32 %BBNum, i32* %0, align 4, !dbg !6
%1 = getelementptr inbounds i32* %0, i32 1, !dbg !6 ; [#uses=3]
store i32* %1, i32** @ArrayCursor, align 4, !dbg !6
%2 = load i32** @ArrayEnd, align 4, !dbg !11 ; [#uses=1]
%3 = icmp eq i32* %1, %2, !dbg !11 ; [#uses=1]
br i1 %3, label %bb, label %return, !dbg !11
bb: ; preds = %entry
%4 = ptrtoint i32* %1 to i32, !dbg !12 ; [#uses=1]
%5 = load i32** @ArrayStart, align 4, !dbg !12 ; [#uses=2]
%6 = ptrtoint i32* %5 to i32, !dbg !12 ; [#uses=1]
%7 = sub nsw i32 %4, %6, !dbg !12 ; [#uses=1]
%8 = ashr i32 %7, 2 ; [#uses=1]
tail call void @write_profiling_data(i32 6, i32* %5, i32 %8) nounwind, !dbg
!12
%9 = load i32** @ArrayStart, align 4, !dbg !18 ; [#uses=1]
store i32* %9, i32** @ArrayCursor, align 4, !dbg !18
ret void, !dbg !19
return: ; preds = %entry
ret void, !dbg !19
}
Fr: 0x8ed6578
declare i32 @llvm_start_basic_block_tracing(i32, i8**, i32* nocapture, i32)
nounwind
To: 0x8ed4e20
define i32 @llvm_start_basic_block_tracing(i32 %argc, i8** %argv, i32*
nocapture %arrayStart, i32 %numElements) nounwind {
entry:
tail call void @llvm.dbg.value(metadata !6, i64 0, metadata !7), !dbg !18
%0 = tail call i32 @save_arguments(i32 %argc, i8** %argv) nounwind, !dbg !19
; [#uses=1]
tail call void @llvm.dbg.value(metadata , i64 0, metadata !20), !dbg
!19
tail call void @llvm.dbg.value(metadata , i64 0, metadata !21), !dbg
!22
%1 = tail call noalias i8* @malloc(i32 131072) nounwind, !dbg !23 ;
[#uses=2]
%2 = bitcast i8* %1 to i32*, !dbg !23 ; [#uses=2]
store i32* %2, i32** @ArrayStart, align 4, !dbg !23
%3 = getelementptr inbounds i8* %1, i32 131072 ; [#uses=1]
%4 = bitcast i8* %3 to i32* ; [#uses=1]
store i32* %4, i32** @ArrayEnd, align 4, !dbg !24
store i32* %2, i32** @ArrayCursor, align 4, !dbg !25
%5 = tail call i32 @atexit(void ()* @BBTraceAtExitHandler) nounwind, !dbg !26
; [#uses=0]
ret i32 %0, !dbg !27
}
Fr: 0x8ed66d0
declare noalias i8* @malloc(i32) nounwind
To: 0x8ed2368
declare noalias i8* @malloc(i32) nounwind
Fr: 0x8ed6740
declare i32 @atexit(void ()*) nounwind
To: 0x8ed3010
declare i32 @atexit(void ()*) nounwind
Fr: 0x8ed67b0
declare void @llvm.dbg.value(metadata, i64, metadata) nounwind readnone
To: 0x8ed2850
declare void @llvm.dbg.value(metadata, i64, metadata) nounwind readnone
Fr: 0x8ed76b8 !{i32 131072}
To: 0x8ed76b8 !{i32 131072}
Fr: 0x8eda3b8 !{i32 459008, metadata !-1, metadata !"BufferSize", metadata
!-1, i32 52, metadata !-1} ; [ DW_TAG_auto_variable ]
To: 0x8eda3b8 !{i32 459008, metadata !-1, metadata !"BufferSize", metadata
!-1, i32 52, metadata !-1} ; [ DW_TAG_auto_variable ]
Fr: 0x8edb5f0 i32 %argc
To: 0x8eda078 i32 %argc
Fr: 0x8edb618 i8** %argv
To: 0x8eda0a0 i8** %argv
Fr: 0x8edb640 i32* %arrayStart
To: 0x8eda0c8 i32* %arrayStart
Fr: 0x8edb668 i32 %numElements
To: 0x8eda0f0 i32 %numElements
Couldn't remap value: 0x8edb6c0 metadata
Couldn't remap value!
UNREACHABLE executed at LinkModules.cpp:419!
0 llvm-ld 0x0865bcae
1 llvm-ld 0x0865bb23
2 0x4001d400 __kernel_sigreturn + 0
3 libc.so.6 0x401cb932 abort + 386
4 llvm-ld 0x0863c938 llvm::FoldingSetNodeID::AddPointer(void const*) + 0
5 llvm-ld 0x08345de2
6 llvm-ld 0x08348ba4
7 llvm-ld 0x08348d6c
8 llvm-ld 0x08349dd6 llvm::Linker::LinkModules(llvm::Module*, llvm::Module*,
std::string*) + 1844
9 llvm-ld 0x08344174 llvm::Linker::LinkInModule(llvm::Module*, std::string*)
+ 46
10 llvm-ld 0x08343f39 llvm::Linker::LinkInFile(llvm::sys::Path const&, bool&)
+ 1355
11 llvm-ld 0x08343423
llvm::Linker::LinkInItems(std::vector,
std::allocator > > const&,
std::vector, std::allocator > >&) + 295
12 llvm-ld 0x083167af main + 1142
13 libc.so.6 0x401b4b56 __libc_start_main + 230
14 llvm-ld 0x0830f061
Stack dump:
0. Program arguments: /home/regehr/z/tmp/llvm-r95278/Debug/bin/llvm-ld
-L/home/regehr/z/tmp/llvm-gcc-r95275-install/lib
-internalize-public-api-file=/home/regehr/z/tmp/llvm-r95278/runtime/libprofile/exported_symbols.lst
-o
/home/regehr/z/tmp/llvm-r95278/runtime/libprofile/Debug/profile_rt.internalize
/home/regehr/z/tmp/llvm-r95278/runtime/libprofile/Debug/BasicBlockTracing.bc
/home/regehr/z/tmp/llvm-r95278/runtime/libprofile/Debug/CommonProfiling.bc
/home/regehr/z/tmp/llvm-r95278/runtime/libprofile/Debug/EdgeProfiling.bc
/home/regehr/z/tmp/llvm-r95278/runtime/libprofile/Debug/OptimalEdgeProfiling.bc
make[2]: *** [/home/regehr/z/tmp/llvm-r95278/Debug/lib/libprofile_rt.bca]
Aborted
make[2]: Leaving directory `/home/regehr/z/tmp/llvm-r95278/runtime/libprofile'
make[1]: *** [libprofile/.makeall] Error 2
make[1]: Leaving directory `/home/regehr/z/tmp/llvm-r95278/runtime'
make: *** [all] Error 1
--
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 Feb 4 00:07:50 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 4 Feb 2010 00:07:50 -0600
Subject: [LLVMbugs] [Bug 6228] New: ASCII NUL bytes in output of `llvm-ar t`
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6228
Summary: ASCII NUL bytes in output of `llvm-ar t`
Product: new-bugs
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: abbeyj at gmail.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=4171)
--> (http://llvm.org/bugs/attachment.cgi?id=4171)
Remove NUL padding bytes when reading archive
Running `llvm-ar t` on certain archives will produce ASCII NUL bytes in the
output. These are normally invisible but they don't belong there and are
causing test/Archive/toc_MacOSX.ll to fail on Windows. When diff sees two
"binary" files that have different line endings it reports them as different
and the test fails.
The MacOSX.a archive has the names NUL padded up to (I believe) 8 byte
boundaries. These NULs need to be trimmed off on reading.
STR:
$ llvm-ar t test/Archive/MacOSX.a | od -c
Expected output:
0000000 _ _ . S Y M D E F S O R T E D
0000020 \r \n e v e n l e n \r \n o d d l e
0000040 n \r \n v e r y _ l o n g _ b y t
0000060 e c o d e _ f i l e _ n a m e .
0000100 b c \r \n I s N A N . o \r \n
0000115
(possibly with different platform-appropriate line endings)
Actual output:
0000000 _ _ . S Y M D E F S O R T E D
0000020 \0 \0 \0 \0 \r \n e v e n l e n \0 \0 \0
0000040 \0 \0 \r \n o d d l e n \0 \0 \0 \0 \0 \0
0000060 \r \n v e r y _ l o n g _ b y t e
0000100 c o d e _ f i l e _ n a m e . b
0000120 c \0 \0 \0 \0 \0 \r \n I s N A N . o \0
0000140 \0 \0 \0 \0 \r \n
0000146
Attached patch removes the extra NUL bytes from the output and changes
test/Archive/MacOSX.toc from a binary to a text file (removes
svn:mime-type=application/octet-stream and adds svn:eol-style=native). I can't
figure out how to get SVN to include the new contents of the file in the patch
so I'm attaching it separately.
--
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 Feb 4 00:20:09 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 4 Feb 2010 00:20:09 -0600
Subject: [LLVMbugs] [Bug 6228] ASCII NUL bytes in output of `llvm-ar t`
In-Reply-To:
Message-ID: <201002040620.o146K9hM020166@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6228
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Chris Lattner 2010-02-04 00:20:08 ---
Thanks, applied:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100201/095633.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 Thu Feb 4 00:24:34 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 4 Feb 2010 00:24:34 -0600
Subject: [LLVMbugs] [Bug 6222] Assert "getTerminator returned null" for a
verified function
In-Reply-To:
Message-ID: <201002040624.o146OYvF020394@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6222
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #3 from Chris Lattner 2010-02-04 00:24:33 ---
It sounds like you're using the API wrong. Using the jit in non-lazy mode will
cause it to compile functions and those functions need to be self consistent.
--
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 Feb 4 01:32:28 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 4 Feb 2010 01:32:28 -0600
Subject: [LLVMbugs] [Bug 6214] scalar absolute value of single precision
floating point values
In-Reply-To:
Message-ID: <201002040732.o147WSB8023201@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6214
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |LATER
--- Comment #2 from Chris Lattner 2010-02-04 01:32:28 ---
I moved the microoptzn into the SSE ideas file:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100201/095640.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 Thu Feb 4 01:34:08 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 4 Feb 2010 01:34:08 -0600
Subject: [LLVMbugs] [Bug 6229] New: Irrelevant/ incorrect preprocessor
defines present under -std=c89
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6229
Summary: Irrelevant/incorrect preprocessor defines present under
-std=c89
Product: new-bugs
Version: trunk
Platform: Macintosh
OS/Version: MacOS X
Status: NEW
Severity: minor
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: llvm.org at elliottcable.com
CC: llvmbugs at cs.uiuc.edu
I???m not sure if this is intended or not, but it seems weird: when compiling
source with `clang -std=c89`, things like `LLONG_MIN` and `ULLONG_MAX`, that
apply to features not available under `-std=c89`, are still defined. This lead
to the situation in my code, where my `#if` passed (because `LLONG_MIN` and
such are defined), but the code was un-compile-able under `-std=c89`, because
it depended on the availability of `long long` when `LLONG_MIN` was defined.
--
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 Feb 4 10:10:25 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 4 Feb 2010 10:10:25 -0600
Subject: [LLVMbugs] [Bug 6218] Broken debug info for almost every c++ app
In-Reply-To:
Message-ID: <201002041610.o14GAPeD026838@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6218
Anton Korobeynikov changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Anton Korobeynikov 2010-02-04 10:10:24 ---
This turned out to be a binutils bug.
--
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 Feb 4 11:36:14 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 4 Feb 2010 11:36:14 -0600
Subject: [LLVMbugs] [Bug 6230] New: Instruction combiner pass broken for
Vectors over 32 elements
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6230
Summary: Instruction combiner pass broken for Vectors over 32
elements
Product: libraries
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Transformation Utilities
AssignedTo: unassignedbugs at nondot.org
ReportedBy: ddneff at hotmail.com
CC: llvmbugs at cs.uiuc.edu
The instruction combiner is not creating demanded element bit masks correctly
when indexing into large vectors. It is shifting 1 left by the index, and when
the index is larger than an integer, the mask is not correct.
===========================
InstCombineVectorOps.cpp contains these two lines inside of
InstCombiner::visitExtractElementInst:
APInt DemandedMask(VectorWidth, 1 << IndexVal);
if (Value *V = SimplifyDemandedVectorElts(EI.getOperand(0),
DemandedMask, UndefElts)) {
...
Shifting 1 left by IndexVal will overflow a 32 bit integer whenever IndexVal is
greater than 31. I believe the correct code should use the APInt to set the
mask along the lines of:
APInt DemandMask(VectorWidth, 0);
DemandMask.set(IndexVal);
if (Value *V = SimplifyDemandedVectorElts(EI.getOperand(0),
DemandedMask, UndefElts)) {
===============================
A similar problem exists in file InstCombineSimplifyDemanded.cpp in
InstCombiner::SimplifyDemandedVectorElts:
if (DemandedElts == ((1ULL << VWidth) -1))
return 0;
This at least works until 64 element vectors, but I believe it should be
something like:
if (DemandedElts == APInt(VWidth, 0).set())
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 Thu Feb 4 12:47:41 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 4 Feb 2010 12:47:41 -0600
Subject: [LLVMbugs] [Bug 6086] assertion failure in LiveIntervals
In-Reply-To:
Message-ID: <201002041847.o14IlfK6001971@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6086
Jakob Stoklund Olesen changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Jakob Stoklund Olesen 2010-02-04 12:47:40 ---
Fixed in r95319
--
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 Feb 4 21:00:16 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 4 Feb 2010 21:00:16 -0600
Subject: [LLVMbugs] [Bug 6235] New: Alpha Backend fails to compile with
internal compiler error .
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6235
Summary: Alpha Backend fails to compile with internal compiler
error.
Product: libraries
Version: 2.6
Platform: DEC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Backend: Alpha
AssignedTo: alenhar2 at uiuc.edu
ReportedBy: mattst88 at gmail.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=4175)
--> (http://llvm.org/bugs/attachment.cgi?id=4175)
LLVM-gcc frontend compile failure log
--
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 Feb 5 02:34:44 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 5 Feb 2010 02:34:44 -0600
Subject: [LLVMbugs] [Bug 6240] New: clang++ miscompiles MemCpyOptimizer.o in
Release mode
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6240
Summary: clang++ miscompiles MemCpyOptimizer.o in Release mode
Product: clang
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: daniel at zuster.org
CC: clattner at apple.com, llvmbugs at cs.uiuc.edu,
dgregor at apple.com
When clang++ is used to build a Release clang++, MemCpyOptimizer appears to be
miscompiled (based on test failures). If MemCpyOptimizer is compiled at O0 with
clang++, then test/Transforms/MemCpyOpt/align.ll passes.
This is most likely an IRgen error where we are relying somehow on undefined
behavior.
--
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 Feb 5 03:31:38 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 5 Feb 2010 03:31:38 -0600
Subject: [LLVMbugs] [Bug 6243] New: C2440 "reinterpret_cast": cant convert
enum to unsigned int
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6243
Summary: C2440 "reinterpret_cast": cant convert enum to unsigned
int
Product: libraries
Version: trunk
Platform: PC
OS/Version: Windows XP
Status: NEW
Keywords: compile-fail
Severity: normal
Priority: P2
Component: Support Libraries
AssignedTo: unassignedbugs at nondot.org
ReportedBy: etherzhhb at gmail.com
CC: llvmbugs at cs.uiuc.edu
hi all,
i am write to report the "bits_storage" of commandline library not work on msvc
and cygwin.
i am writing the code like this:
enum PrintStyle { AnalOnly, PostOder, HierNode, NameOnly };
cl::bits
printStyle("print-region-style", cl::Hidden,
cl::desc("print style of printing out regions"),
cl::values(
clEnumValN(AnalOnly, "analyze-only", "only print region on
analyze"),
clEnumValN(PostOder, "postoder", "print RegionNodes in post
order"),
clEnumValN(HierNode, "hier-node", "print RegionNodes
with hierachical iterator"),
clEnumValN(NameOnly, "name-only", "only print the region
name"),
clEnumValEnd));
and some place have the code like
printStyle.isSet(NameOnly)
then it get a compile error when i compile it with msvc:
error C2440: ???reinterpret_cast???: cant convert ???const llvm::PrintStyle???
to ???unsigned int???
F:\cygwin\home\ether\polyllvm\pofl\include\llvm\Support\CommandLine.h 1171
and it also cant compile under cygwin:
llvm[0]: Compiling RegionPrinter.cpp for Debug build
/home/ether/polyllvm/pofl/include/llvm/Support/CommandLine.h: In static member
function ???static unsigned int llvm::cl::bits_storage::Bit(const T&) [with T = llvm::PrintStyle, DataType =
llvm::PrintStyle]???:
/home/ether/polyllvm/pofl/include/llvm/Support/CommandLine.h:1187:
instantiated from ???bool llvm::cl::bits_storage::isSet(const
T&) [with T = llvm::PrintStyle, DataType = llvm::PrintStyle]???
/home/ether/polyllvm/pofl/lib/Analysis/Region/RegionPrinter.cpp:83:
instantiated from here
/home/ether/polyllvm/pofl/include/llvm/Support/CommandLine.h:1171: error:
invalid cast from type ???llvm::PrintStyle??? to type ???unsigned int???
make: ***
[/home/ether/polyllvm/build/lib/Analysis/Region/Debug/RegionPrinter.o] Error 1
my gcc version is:
gcc version 4.3.4 20090804 (release) 1 (GCC)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
and if i use (unsigned) instead of reinterpret_cast, it work.
--best regards
ether
--
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 Feb 5 10:37:59 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 5 Feb 2010 10:37:59 -0600
Subject: [LLVMbugs] [Bug 6185] llvm-gcc assumes no alignment for bitfield
loads
In-Reply-To:
Message-ID: <201002051637.o15GbxRI025469@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6185
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #5 from Chris Lattner 2010-02-05 10:37:58 ---
This is the same as Bug 5995. llvm-gcc is lowering accesses to be align 1 when
llvm-types lowers the structure to an llvm packed struct. Whether or not it
turns into an llvm packed struct should have nothing to do with the alignment
of the load. This is terrible code and needs to be ripped out.
*** This bug has been marked as a duplicate of bug 5995 ***
--
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 Feb 5 13:46:18 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 5 Feb 2010 13:46:18 -0600
Subject: [LLVMbugs] [Bug 6246] New: Semi-automatic vectorization when
performing scalar operations on vector elements
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6246
Summary: Semi-automatic vectorization when performing scalar
operations on vector elements
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: llvm at henning-thielemann.de
CC: llvmbugs at cs.uiuc.edu
In my automatically generated code it often happens that scalar operations are
applied to vector elements that could have been written as vector operations as
well. E.g. (due to modularization issues) I generate code like
define <4 x float> @_vadd(<4 x float>, <4 x float>) {
%a0 = extractelement <4 x float> %0, i32 0
%b0 = extractelement <4 x float> %1, i32 0
%c0 = fadd float %a0, %b0
%a1 = extractelement <4 x float> %0, i32 1
%b1 = extractelement <4 x float> %1, i32 1
%c1 = fadd float %a1, %b1
%a2 = extractelement <4 x float> %0, i32 2
%b2 = extractelement <4 x float> %1, i32 2
%c2 = fadd float %a2, %b2
%a3 = extractelement <4 x float> %0, i32 3
%b3 = extractelement <4 x float> %1, i32 3
%c3 = fadd float %a3, %b3
%d0 = insertelement <4 x float> undef, float %c0, i32 0
%d1 = insertelement <4 x float> %d0, float %c1, i32 1
%d2 = insertelement <4 x float> %d1, float %c2, i32 2
%d3 = insertelement <4 x float> %d2, float %c3, i32 3
ret <4 x float> %d3
}
I think it would be both correct and more efficient to swap 'fadd's and
'extractelements' by an optimization pass which would yield:
define <4 x float> @_vadd(<4 x float>, <4 x float>) nounwind readnone {
%c = fadd <4 x float> %0, %1
%c0 = extractelement <4 x float> %c, i32 0
%c1 = extractelement <4 x float> %c, i32 1
%c2 = extractelement <4 x float> %c, i32 2
%c3 = extractelement <4 x float> %c, i32 3
%d0 = insertelement <4 x float> undef, float %c0, i32 0
%d1 = insertelement <4 x float> %d0, float %c1, i32 1
%d2 = insertelement <4 x float> %d1, float %c2, i32 2
%d3 = insertelement <4 x float> %d2, float %c3, i32 3
ret <4 x float> %d3
}
That the remaining extractelements and insertelements are the identity
transform is already correctly detected both by the optimizer and the (X86)
code generator. The optimizer transforms the last piece of code to something
like:
define <4 x float> @_vadd(<4 x float>, <4 x float>) nounwind readnone {
%c = fadd <4 x float> %0, %1
ret <4 x float> %c
}
--
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 Feb 6 06:46:53 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 6 Feb 2010 06:46:53 -0600
Subject: [LLVMbugs] [Bug 6251] New: Compiled with -O2 program crashes inside
libstdc++
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6251
Summary: Compiled with -O2 program crashes inside libstdc++
Product: clang
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: sorokin at rain.ifmo.ru
CC: llvmbugs at cs.uiuc.edu
Blocks: 6023
The following program (see attachment) crashes when it is compiled with -O2.
ivan at ivan-desktop:~/d/llvm-build/Debug/bin$ ./clang++ -ggdb 13.cpp
ivan at ivan-desktop:~/d/llvm-build/Debug/bin$ ./a.out
ivan at ivan-desktop:~/d/llvm-build/Debug/bin$ ./clang++ -O2 -ggdb 13.cpp
ivan at ivan-desktop:~/d/llvm-build/Debug/bin$ gdb a.out
(gdb) run
Starting program: /home/ivan/d/llvm-build/Debug/bin/a.out
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff733f719 in free () from /lib/libc.so.6
(gdb) backtrace
#0 0x00007ffff733f719 in free () from /lib/libc.so.6
#1 0x00007ffff7b3656f in std::ios_base::~ios_base() () from
/usr/lib/libstdc++.so.6
#2 0x0000000000400eef in main () at 13.cpp:30
If I remove inheritance from fake_base or
If I remove fake_member member or
If I compile without -O2
the program doesn't crash.
Ubuntu 9.10 x86-64.
This bug occur when using boost::format.
I continue my experiments to make more precise bug report.
--
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 Feb 6 07:12:36 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 6 Feb 2010 07:12:36 -0600
Subject: [LLVMbugs] [Bug 6252] New: FP ASM crash with local register
allocator
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6252
Summary: FP ASM crash with local register allocator
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
$ llc -regalloc=local fpcrash.ll
llc: llvm/lib/Target/X86/X86FloatingPoint.cpp:1051:
void::FPS::handleSpecialFP(llvm::ilist_iterator&):
Assertion `(StackTop == 1 || StackTop == 2) && "Stack should have one or two
element on it to return!"' failed.
Testcase (reduced from GCC's 990413-2.c):
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-unknown-linux-gnu"
define void @f() nounwind {
entry:
%tmp = call x86_fp80 asm sideeffect "fpatan\0A\09",
"={st},0,{st(1)},~{fpsr},~{flags},~{st(1)}"(x86_fp80 undef, x86_fp80 undef)
nounwind ; [#uses=0]
ret void
}
--
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 Feb 6 11:08:24 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 6 Feb 2010 11:08:24 -0600
Subject: [LLVMbugs] [Bug 6253] New: SimpleRegisterCoalescer fails to update
live-in information
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6253
Summary: SimpleRegisterCoalescer fails to update live-in
information
Product: libraries
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Keywords: code-cleanup
Severity: normal
Priority: P2
Component: Common Code Generator Code
AssignedTo: unassignedbugs at nondot.org
ReportedBy: mwb.cde at googlemail.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=4185)
--> (http://llvm.org/bugs/attachment.cgi?id=4185)
Make SimpleRegisterCoalescer print live-in information
The register coalescer doesn't update variable live-in information
when replacing virtual registers with physical registers. This means
that live-in information after running SimpleRegisterCoalescer is not
complete and can't be relied on.
The effect is that register allocators used with
SimpleRegisterCoalescer have to recalculate live-in information from
the set of live intervals. This increases compile-time unnecessarily,
since all physical registers have to be considered and not just those
which were changed by the register coalescer. This is already done
by RegAllocLinearScan as a side-effect of setting live-in values for
virtual registers, so this is not a problem if the standard
allocator is used.
Test case:
- Apply the attached patch to make SimpleRegisterCoalescer print the
block live-in variables at the start and end of the register
coalescer pass.
- Run
llc -debug -regalloc=linearscan -march=x86
on
test/CodeGen/Generic/2003-05-27/usefsubasbool.l
The coalescer replaces source reg1024 with xmm0 in instruction 36
(UCOMISDRRrr %reg1024, %reg1026, eflags) of block BB#1
(shortcirc_next.1), but xmm0 is defined in block BB#0 (entry) and xmm0
is not marked live into BB#1.
--
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 Feb 7 00:40:48 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 7 Feb 2010 00:40:48 -0600
Subject: [LLVMbugs] [Bug 6255] New: llvm_unreachable assert in llc
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6255
Summary: llvm_unreachable assert in llc
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: viridia at gmail.com
CC: llvmbugs at cs.uiuc.edu
I've been getting an error in llc lately:
FIXME: Don't support this constant cast expr
UNREACHABLE executed at
/home/talin/Projects/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:898!
This started happening about two weeks ago for me (I update to the trunk
revision on a fairly regular basis.)
Attached is an input file which can reproduce the error with the following
command:
llc StringReaderTest.opt.bc
Note that this input file was produced by opt, which did not report any
complaints.
--
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 Feb 7 09:07:12 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 7 Feb 2010 09:07:12 -0600
Subject: [LLVMbugs] [Bug 6258] New: Invalid module generated
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6258
Summary: Invalid module generated
Product: clang
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: asl at math.spbu.ru
CC: llvmbugs at cs.uiuc.edu
Blocks: 5881
Consider the attached sources
I have:
$ ./clang qdesigner_propertycommand.ii
Attributes after last parameter!
void (i1)* @_ZN5QFont12setUnderlineEb
Attributes after last parameter!
void (i1)* @_ZN5QFont12setStrikeOutEb
Attributes after last parameter!
void (i1)* @_ZN5QFont10setKerningEb
Broken module found, compilation aborted!
both original & reduces sources are provided.
--
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 Feb 7 11:37:31 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 7 Feb 2010 11:37:31 -0600
Subject: [LLVMbugs] [Bug 6258] Invalid module generated
In-Reply-To:
Message-ID: <201002071737.o17HbVSX009623@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6258
Anders Carlsson changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |andersca at mac.com
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Anders Carlsson 2010-02-07 11:37:30 ---
Committed revision 95524.
--
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 Feb 7 12:00:18 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 7 Feb 2010 12:00:18 -0600
Subject: [LLVMbugs] [Bug 6259] New: Assertion in Sema
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6259
Summary: Assertion in Sema
Product: clang
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Semantic Analyzer
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: asl at math.spbu.ru
CC: llvmbugs at cs.uiuc.edu
Blocks: 5881
Consider the preprocessed sources attached. I am seeing:
$ ./clang++ qdbusmetatype.ii
clang:
/home/asl/proj/llvm/src/tools/clang/lib/Sema/../../include/clang/AST/DeclCXX.h:300:
clang::CXXRecordDecl::DefinitionData& clang::CXXRecordDecl::data(): Assertion
`DefinitionData && "queried property of class with no definition"' failed.
Both original and reduces sources attached. Reduced one looks pretty bigus, but
triggers the same assertion though.
--
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 Feb 7 13:45:12 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 7 Feb 2010 13:45:12 -0600
Subject: [LLVMbugs] [Bug 6260] New: llc crash - assertion " Ran out of
registers during register allocation!"
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6260
Summary: llc crash - assertion "Ran out of registers during
register allocation!"
Product: new-bugs
Version: trunk
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: ddunkle at arxan.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=4200)
--> (http://llvm.org/bugs/attachment.cgi?id=4200)
simplified bugpoint "bc" file
We are using this version of llc:
Low Level Virtual Machine (http://llvm.org/):
llvm version 2.7svn
Optimized build with assertions.
Built Feb 4 2010 (14:30:07).
Host: i386-apple-darwin9
Host CPU: penryn
We use llc in this fashion:
llc -O0 bugpoint-reduced-simplified.bc
If the -O0 is removed, or -O3 is specified, or if -regalloc=local is specified
the assertion goes away and llc completes. So it seems specific to -O0.
It is necessary for us to use -O0 for product purposes.
I will attach the simplified bugpoint output.
--
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 Feb 8 10:15:49 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 10:15:49 -0600
Subject: [LLVMbugs] [Bug 3255] Investigate deterministic variations due to
"unintended" changes .
In-Reply-To:
Message-ID: <201002081615.o18GFnsm025418@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3255
Daniel Dunbar changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |LATER
--- Comment #18 from Daniel Dunbar 2010-02-08 10:15:49 ---
Closing this out, when I start performance testing Clang I have ways to
quantify these problems.
--
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 Feb 8 11:59:31 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 11:59:31 -0600
Subject: [LLVMbugs] [Bug 3327] ia64 target problems with ELF sections
In-Reply-To:
Message-ID: <201002081759.o18HxVA8030770@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3327
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--- Comment #1 from Chris Lattner 2010-02-08 11:59:31 ---
The IA64 backend got removed.
--
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 Feb 8 12:34:21 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 12:34:21 -0600
Subject: [LLVMbugs] [Bug 6252] FP ASM crash with local register allocator
In-Reply-To:
Message-ID: <201002081834.o18IYLep032615@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6252
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #1 from Chris Lattner 2010-02-08 12:34:20 ---
We don't have solid support for those constraints.
*** This bug has been marked as a duplicate of bug 879 ***
--
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 Feb 8 13:28:21 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 13:28:21 -0600
Subject: [LLVMbugs] [Bug 6259] Assertion in Sema while generating
diagnostics on invalid input
In-Reply-To:
Message-ID: <201002081928.o18JSLkp002653@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6259
John McCall changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rjmccall at apple.com
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #5 from John McCall 2010-02-08 13:28:20 ---
Crash-on-invalid is fixed in r95554. Confirmed that unreduced test case fixed
by resolution of related bug. Our work here is done.
--
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 Feb 8 15:47:10 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 15:47:10 -0600
Subject: [LLVMbugs] [Bug 5585] Global variables that are references and have
constant initializers should be marked constant
In-Reply-To:
Message-ID: <201002082147.o18LlAV6009596@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5585
John McCall changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rjmccall at apple.com
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from John McCall 2010-02-08 15:47:09 ---
Fixed in r95577.
--
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 Feb 8 16:06:10 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 16:06:10 -0600
Subject: [LLVMbugs] [Bug 6255] llvm_unreachable assert in llc
In-Reply-To:
Message-ID: <201002082206.o18M6ARa010554@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6255
Dan Gohman changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Dan Gohman 2010-02-08 16:06:10 ---
The new sizeof folding code was producing constant expressions of kinds that
the asm printer wasn't prepared to handle. This is fixed in r95583.
--
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 Feb 8 17:10:15 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 17:10:15 -0600
Subject: [LLVMbugs] [Bug 5308] LLVM IRgen should not defer static data with
non-constant initializations (in C++)
In-Reply-To:
Message-ID: <201002082310.o18NAFJ9013871@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5308
John McCall changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rjmccall at apple.com
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from John McCall 2010-02-08 17:10:14 ---
Fixed at some point.
--
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 Feb 8 17:56:18 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 17:56:18 -0600
Subject: [LLVMbugs] [Bug 6230] Instruction combiner pass broken for Vectors
over 32 elements
In-Reply-To:
Message-ID: <201002082356.o18NuIPv015894@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6230
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Chris Lattner 2010-02-08 17:56:18 ---
Thanks, fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100208/095820.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 Feb 8 18:06:00 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 18:06:00 -0600
Subject: [LLVMbugs] [Bug 6243] C2440 "reinterpret_cast": cant convert enum
to unsigned int
In-Reply-To:
Message-ID: <201002090006.o19060Ke016443@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6243
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Chris Lattner 2010-02-08 18:06:00 ---
Fixed in r95622, 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 Mon Feb 8 18:07:23 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 18:07:23 -0600
Subject: [LLVMbugs] [Bug 6229] Irrelevant/incorrect preprocessor defines
present under -std=c89
In-Reply-To:
Message-ID: <201002090007.o1907NaH016506@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6229
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Chris Lattner 2010-02-08 18:07:22 ---
We support long long in c89 mode as an extension:
$ clang t.c -std=c89 -c
$ clang t.c -std=c89 -c -pedantic
t.c:2:6: warning: 'long long' is an extension when C99 mode is not enabled
[-Wlong-long]
long long x;
^
--
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 Feb 8 18:11:39 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 18:11:39 -0600
Subject: [LLVMbugs] [Bug 6212] Clang misses optimisation on if vs else if
In-Reply-To:
Message-ID: <201002090011.o190Bd8h016721@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6212
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |LATER
--- Comment #1 from Chris Lattner 2010-02-08 18:11:38 ---
Thanks, moved this microoptimization to the README file here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100208/095824.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 Feb 8 19:07:52 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 19:07:52 -0600
Subject: [LLVMbugs] [Bug 6209] Keep Results Into SIMD Registers
In-Reply-To:
Message-ID: <201002090107.o1917q07019213@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6209
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |REMIND
--- Comment #2 from Chris Lattner 2010-02-08 19:07:51 ---
Closing until we get a testcase, please reopen when/if you get one.
--
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 Feb 8 19:30:34 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 19:30:34 -0600
Subject: [LLVMbugs] [Bug 6193] crash in instcombine in MatchSelectFromAndOr
In-Reply-To:
Message-ID: <201002090130.o191UYYC020437@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6193
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Chris Lattner 2010-02-08 19:30:34 ---
Fixed here, thanks!
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100208/095840.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100208/095841.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 Feb 8 19:40:05 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 19:40:05 -0600
Subject: [LLVMbugs] [Bug 6167] Segmentation fault due to type mismatch for
build_struct_gep in OCaml bindings
In-Reply-To:
Message-ID: <201002090140.o191e5ql021397@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6167
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Chris Lattner 2010-02-08 19:40:05 ---
Applied, thanks:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100208/095842.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 Feb 8 23:34:17 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 23:34:17 -0600
Subject: [LLVMbugs] [Bug 6227] linker metadata issue
In-Reply-To:
Message-ID: <201002090534.o195YHuT001821@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6227
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #4 from Chris Lattner 2010-02-08 23:34:17 ---
assuming that victors patch fixed this, please reopen if not.
--
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 Feb 8 23:50:43 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 23:50:43 -0600
Subject: [LLVMbugs] [Bug 2515] execution of scanf functions broken in lli
In-Reply-To:
Message-ID: <201002090550.o195oh0f002672@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=2515
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Chris Lattner 2010-02-08 23:50:43 ---
ByteswapSCANFResults is gone.
--
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 Feb 8 23:52:02 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 23:52:02 -0600
Subject: [LLVMbugs] [Bug 2649] x86-64 execution crash.
In-Reply-To:
Message-ID: <201002090552.o195q2Gi002767@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=2649
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #5 from Chris Lattner 2010-02-08 23:52:02 ---
This is probably 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 Feb 8 23:52:55 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 23:52:55 -0600
Subject: [LLVMbugs] [Bug 2786] incorrect branch code produced by code
generator, under certain circumstances
In-Reply-To:
Message-ID: <201002090552.o195qtXO002838@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=2786
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #15 from Chris Lattner 2010-02-08 23:52:54 ---
Undefined behavior is undefined.
--
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 Feb 8 23:55:39 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 23:55:39 -0600
Subject: [LLVMbugs] [Bug 3462] missing 128bit intrinsic on x86-64
In-Reply-To:
Message-ID: <201002090555.o195tdw2003055@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3462
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |LATER
--- Comment #2 from Chris Lattner 2010-02-08 23:55:39 ---
Moved out to the X86 unimplemented file here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100208/095849.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 Feb 8 23:56:17 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 23:56:17 -0600
Subject: [LLVMbugs] [Bug 3508] /SingleSource/UnitTests/Vector/divides cbe
failure
In-Reply-To:
Message-ID: <201002090556.o195uHU6003104@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3508
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--- Comment #2 from Chris Lattner 2010-02-08 23:56:17 ---
I don't think anyone cares enough to fix this anymore and CBE isn't considered
release critical.
--
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 Feb 8 23:57:53 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 23:57:53 -0600
Subject: [LLVMbugs] [Bug 4279] Tail calls not used when possible without
-tailcallopt
In-Reply-To:
Message-ID: <201002090557.o195vrjR003187@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=4279
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Chris Lattner 2010-02-08 23:57:53 ---
Evan implemented 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 Mon Feb 8 23:59:41 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 8 Feb 2010 23:59:41 -0600
Subject: [LLVMbugs] [Bug 4410] incorrect expansion for uint_to_fp
In-Reply-To:
Message-ID: <201002090559.o195xfiv003285@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=4410
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |LATER
--- Comment #2 from Chris Lattner 2010-02-08 23:59:40 ---
LLVM's codegen only supports the default rounding mode currently. To expand on
this, we'd want to extend the IR. I'm not aware of anyone interested in this
though.
--
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 Feb 9 00:00:59 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 9 Feb 2010 00:00:59 -0600
Subject: [LLVMbugs] [Bug 4598] clang: ICE on invalid C: pure virtual method
called
In-Reply-To:
Message-ID: <201002090600.o1960xlY003373@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=4598
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #2 from Chris Lattner 2010-02-09 00:00:58 ---
Works on ToT.
*** This bug has been marked as a duplicate of bug 3444 ***
--
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 Feb 9 00:03:36 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 9 Feb 2010 00:03:36 -0600
Subject: [LLVMbugs] [Bug 4629] quest test case generator finds possible bugs
in clang and llvmc on x86-64
In-Reply-To:
Message-ID: <201002090603.o1963aWO003599@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=4629
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #6 from Chris Lattner 2010-02-09 00:03:35 ---
I spot checked a few of these and they seemed to work with ToT.
--
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 Feb 9 00:04:49 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 9 Feb 2010 00:04:49 -0600
Subject: [LLVMbugs] [Bug 4706] Bitcode reader fails after rev# 78258
In-Reply-To:
Message-ID: <201002090604.o1964nb8003679@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=4706
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #10 from Chris Lattner 2010-02-09 00:04:48 ---
This has probably been fixed. If not, 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 Tue Feb 9 00:05:42 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 9 Feb 2010 00:05:42 -0600
Subject: [LLVMbugs] [Bug 4883] x86 doesn't turn on tail recursion
elimination by default
In-Reply-To:
Message-ID: <201002090605.o1965gd8003755@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=4883
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Chris Lattner 2010-02-09 00:05:42 ---
Evan implemented tail call support that handles 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 Tue Feb 9 00:10:18 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 9 Feb 2010 00:10:18 -0600
Subject: [LLVMbugs] [Bug 5052] JIT crash using sequence 'load --> bswap -->
bitcast --> fptoui'
In-Reply-To:
Message-ID: <201002090610.o196AIQD004070@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5052
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #7 from Chris Lattner 2010-02-09 00:10:17 ---
sounds like a build problem.
--
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 Feb 9 00:13:38 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 9 Feb 2010 00:13:38 -0600
Subject: [LLVMbugs] [Bug 5268] clang: undefined behavior in message-length
test: uninitialized variables, and out-of-bounds read
In-Reply-To:
Message-ID: <201002090613.o196Dcqt004279@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5268
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Chris Lattner 2010-02-09 00:13:37 ---
this valgrind's clean on mainline.
--
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 Feb 9 00:41:18 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 9 Feb 2010 00:41:18 -0600
Subject: [LLVMbugs] [Bug 5624] test/CodeGen/Generic has target specific tests
In-Reply-To:
Message-ID: <201002090641.o196fIih005793@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5624
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Chris Lattner 2010-02-09 00:41:17 ---
Fixed in a series of patches leading up to r95656.
--
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 Feb 9 01:46:51 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 9 Feb 2010 01:46:51 -0600
Subject: [LLVMbugs] [Bug 5107] Division by zero in
SimpleRegisterCoalescing:: isWinToJoinCrossClass()
In-Reply-To:
Message-ID: <201002090746.o197kpfn009069@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5107
Evan Cheng changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #2 from Evan Cheng 2010-02-09 01:46:50 ---
No test case. Closing.
--
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 Feb 9 02:29:19 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 9 Feb 2010 02:29:19 -0600
Subject: [LLVMbugs] [Bug 6103] Simple Register Coalescing assert failure:
invalid register-register move instruction
In-Reply-To:
Message-ID: <201002090829.o198TJUv011006@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6103
Duncan Sands changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
--- Comment #2 from Duncan Sands 2010-02-09 02:29:18 ---
It no longer crashes 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 Tue Feb 9 02:29:36 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 9 Feb 2010 02:29:36 -0600
Subject: [LLVMbugs] [Bug 6240] clang++ is generally alignment argument to
memset, but not setting the appropriate alignement on alloca
In-Reply-To:
Message-ID: <201002090829.o198Ta2b011045@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6240
Daniel Dunbar changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |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 Tue Feb 9 10:05:59 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 9 Feb 2010 10:05:59 -0600
Subject: [LLVMbugs] [Bug 5052] JIT crash using sequence 'load --> bswap -->
bitcast --> fptoui'
In-Reply-To:
Message-ID: <201002091605.o19G5x4K014992@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5052
Jack changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
--- Comment #8 from Jack 2010-02-09 10:05:59 ---
It's windows-specific problem in JIT coz it didn't have some primitive
functions ( like '__fixunssfdi' ) in Windows version. In revison 95656 I still
not able to run attached code via 'lli'. Please, use Boot Camp to test it on
Windows.
--
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 Feb 9 11:34:54 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 9 Feb 2010 11:34:54 -0600
Subject: [LLVMbugs] [Bug 6253] SimpleRegisterCoalescer fails to update
live-in information
In-Reply-To:
Message-ID: <201002091734.o19HYsGM019310@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=6253
Jakob Stoklund Olesen changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Jakob Stoklund Olesen 2010-02-09 11:34:54 ---
Applied as r95668, 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 Feb 9 11:36:25 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 9 Feb 2010 11:36:25 -0600
Subject: [LLVMbugs] [Bug 6265] New: ARMCodeEmitter can't pass hello_world
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=6265
Summary: ARMCodeEmitter can't pass hello_world
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: sliao at google.com
CC: llvmbugs at cs.uiuc.edu
Based on LLVM's version 3 days ago: 95512:
Abort happens at ARMCodeEmitter.cpp:554.
ARMCodeEmitter::emitPseudoInstruction(const MachineInstr &MI)
the Opcode (MI.getDesc().Opcode is 128 which is a invalid one.
I found that opcode (128) name is MOVi32imm, but in the emitPseudoInstruction,
this is treated as invalid opcode.
It seems the ARM code emitter in llvm is not completely implemented? below,
next to the faulting line is the comment "// FIXME: Add support for MOVimm32."
See below (excerpted from ARMCodeEmitter.cpp).
void ARMCodeEmitter::emitPseudoInstruction(const MachineInstr &MI) {
unsigned Opcode = MI.getDesc().Opcode;
switch (Opcode) {
default:
llvm_unreachable("ARMCodeEmitter::emitPseudoInstruction");
// FIXME: Add support for MOVimm32.
case TargetInstrInfo::INLINEASM: {
// We allow inline assembler nodes with empty bodies - they can
// implicitly define registers, which is ok for JIT.
if (MI.getOperand(0).getSymbolName()[0]) {
llvm_report_error("JIT does not support inline asm!");
}
break;
}
case TargetInstrInfo::DBG_LABEL:
Because even hello_world doesn't work, I try to drill down further. Note that
the hello_world.c is written as follows:
extern int printf(const char*, ...);
int main(int argc, char** argv) {
int (*a)(const char*, ...) = printf;
a("Hello World!\n");
return a;
}
If I don't refer to function pointer or any global variable in hello_world.c,
then it can pass code emitter.
So we may have to implement this MOVi32imm, or use another instruction for
function pointer or global variables.
--
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 Feb 9 12:11:17 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 9 Feb 2010 12:11:17 -0600
Subject: [LLVMbugs] [Bug 5626] Poor codegen for operations on vectors of
non-power-of-two lengths
In-Reply-To:
Message-ID: <201002091811.o19IBHEd020909@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=5626
Mon P Wang changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #9 from Mon P Wang