From bugzilla-daemon at llvm.org Tue Jun 1 01:49:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 1 Jun 2010 01:49:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7274] New: Clang gives errors that gcc doesn't when
compiling output of slice2cpp
Message-ID:
int main()
{
std::cout << "hello clang\n";
}
Eric at AERIX ~
$ clang test.cpp
/cygdrive/c/Users/Eric/AppData/Local/Temp/cc-lHUHtT.o:fake:(.text+0x1f):
undefined reference to `___dso_handle'
/cygdrive/c/Users/Eric/AppData/Local/Temp/cc-lHUHtT.o:fake:(.text+0x32):
undefined reference to `___cxa_atexit'
collect2: ld returned 1 exit status
clang: error: linker (via gcc) command failed with exit code 1 (use -v to see
invocation)
If I take out the #include and the write to std::cout, it compiles and links
OK.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Tue Jun 1 12:48:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 1 Jun 2010 12:48:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7275] Clang @encode not implemented assertion fails
when compiling Obj-C method with C++ instance pointer argument
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from John McCall 2010-06-01 12:48:14 CDT ---
Several problems with @encoding C++ types were fixed post-release, and I can't
duplicate on ToT. Please verify there.
--
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 llvm.org Tue Jun 1 15:26:09 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 1 Jun 2010 15:26:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7277] New: Scheduler cannot issue multiple
instructions per cycle
Message-ID: [#uses=1]
@bar = common global i32* null, align 4 ; [#uses=1]
define arm_aapcscc void @aaa() nounwind {
entry:
%tmp = load i32** @foo ; [#uses=1]
%tmp1 = load i32** @bar ; [#uses=1]
call arm_aapcscc void @baz(i32* %tmp, i32* %tmp1)
ret void
}
declare arm_aapcscc void @baz(i32*, i32*)
llc -mcpu=cortex-a8 currently codegens this into (interesting part is shown):
movw r0, :lower16:foo
movt r0, :upper16:foo (*)
movw r1, :lower16:bar (*)
movt r1, :upper16:bar
The running time of the code is 3 cycles at minimum since only (*) instructions
can be issued in parallel.
ARM can issue 2 instructions per cycle, thus the optimal code here is:
movw r0, :lower16:foo
movw r1, :lower16:bar
movt r0, :upper16:foo
movt r1, :upper16:bar
Up to 2 cycles can be saved here. Note that the pipeline description is
properly written for Cortex A8/A9 (and there is an indication of 2 functional
units available), so, this is definitely a scheduler deficiency.
--
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 llvm.org Tue Jun 1 23:05:27 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 1 Jun 2010 23:05:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7279] New: GVN emits expensive BitCast
Message-ID: struct T {};
template struct A {
template struct B {
template static void f(T*) {
std::cout << i;
}
};
};
*** Clang output:
main.cpp:14:2: error: no matching function for call to 'f'
A::B::f((T<1>*)0);
^~~~~~~~~~~~~~~~~~
main.cpp:6:31: note: candidate template ignored: failed template argument
deduction
template static void f(T*) {
*** Comments:
- If class A or B is made non-template it compiles.
- The code compiles with llvm-gcc (ie gcc 4.2), gcc 4.4 and msvc
- I'm pretty sure the code is standard compilant, but don't have proof.
- The minimal code doesn't make much sense, but I created it by reducing a 2k+
line file to pinpoint the 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 llvm.org Wed Jun 2 10:57:50 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 2 Jun 2010 10:57:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7282] C++ nested template bug
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Chris Lattner 2010-06-02 10:57:49 CDT ---
This works on mainline, 2.7 is really old by now.
--
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 llvm.org Wed Jun 2 10:58:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 2 Jun 2010 10:58:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7284] New: interpreter zeroes non-integer return
values
Message-ID: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |rjmccall at apple.com
Resolution| |FIXED
--- Comment #1 from John McCall 2010-06-02 16:22:22 CDT ---
Fixed in r105345.
--
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 llvm.org Wed Jun 2 16:30:55 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 2 Jun 2010 16:30:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7286] New: Missing
-analyzer-check-objc-missing-dealloc also skips leaked ivars
Message-ID:
#include
using std::map;
using std::string;
class Closure;
template struct id { typedef T type; };
template
Closure* NewCallback(Class* object,
void (Class::*method)(Arg1, Arg2, Arg3, Arg4),
typename id::type,
typename id::type,
typename id::type,
typename id::type);
struct Foo {
void Method(map, map, map, map);
};
void Use() {
Foo f;
NewCallback(&f, &Foo::Method,
map(),
map(),
map(),
map());
}
$ clang++ -fsyntax-only test.cc
test.cc:22:3: error: no matching function for call to 'NewCallback'
NewCallback(&f, &Foo::Method,
^~~~~~~~~~~
test.cc:9:10: note: candidate function [with Class = Foo, Arg1 =
std::map, std::basic_string,
std::less >,
std::allocator const,
std::basic_string > > >, Arg2 = std::map,
int, std::less >,
std::allocator const, int> > >, Arg3 =
std::map, std::less, std::allocator > > >, Arg4 = std::map,
std::allocator > >] not viable: no known
conversion from 'map' to 'typename
id, int, less >,
allocator const, int> > > >::type' (aka
'std::map, int,
std::less >,
std::allocator const, int> > >') for 4th
argument
Closure* NewCallback(Class* object,
^
1 error generated.
$
That message would be nearly readable if not for the [with Class = Foo, Arg1 =
...] junk in the middle of the useful part. I suspect the template argument
assignments should get their own line between the error message and the source
code quote.
--
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 llvm.org Thu Jun 3 01:45:49 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 3 Jun 2010 01:45:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7290] New: Sometimes the 'aka' type is better than
the user's typedef.
Message-ID: struct identity { typedef T type; };
template
T max(T lhs, typename identity::type rhs);
void Use() {
max(3, "Oops");
}
$ ./clang++ -fsyntax-only test.cc
test.cc:6:3: error: no matching function for call to 'max'
max(3, "Oops");
^~~
test.cc:3:3: note: candidate function [with T = int] not viable: no known
conversion from 'char const [5]' to 'typename identity::type' (aka 'int')
for 2nd argument
T max(T lhs, typename identity::type rhs);
^
1 error generated.
$
We might guess this based on the 'aka' type being shorter, but that won't
always be right. I suspect it'll be useful to have an attribute to let the user
tell clang which type to present.
--
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 llvm.org Thu Jun 3 07:14:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 3 Jun 2010 07:14:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7262] SIGSEGV during compilation of protobuf
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |benny.kra at gmail.com
Resolution| |WORKSFORME
--- Comment #1 from Benjamin Kramer 2010-06-03 07:14:31 CDT ---
I can't reproduce with clang trunk. Please try to compile it with trunk and
reopen if it still crashes.
--
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 llvm.org Thu Jun 3 07:20:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 3 Jun 2010 07:20:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7291] New: crash on initializer containing an
assignment
Message-ID: parser at end of file
2. t.cc:7:6: LLVM IR generation of declaration 'Foo::Foo'
3. t.cc:7:6: Generating code for declaration 'Foo::Foo'
clang: error: clang frontend command failed due to signal 11 (use -v to see
invocation)
$ clang --version
clang version 2.0 (trunk 105388)
stack trace:
#0 0x0000000101b079c8 in llvm::PATypeHolder::get (this=0x10) at Type.h:507
#1 0x0000000101c0117b in llvm::PATypeHolder::operator-> (this=0x10) at
AbstractTypeUser.h:162
#2 0x0000000101f1cc61 in llvm::Value::getContext (this=0x0) at Value.cpp:377
#3 0x0000000101ed58a2 in llvm::StoreInst::StoreInst (this=0x10461c920,
val=0x0, addr=0x10461c798, isVolatile=false, InsertBefore=0x0) at
Instructions.cpp:1079
#4 0x00000001001bb5f7 in llvm::IRBuilder >::CreateStore (this=0x7fff5fbfc590,
Val=0x0, Ptr=0x10461c798, isVolatile=false) at IRBuilder.h:610
#5 0x00000001001700b8 in clang::CodeGen::CodeGenFunction::EmitStoreOfScalar
(this=0x7fff5fbfc4c0, Value=0x0, Addr=0x10461c798, Volatile=false, Ty={Value =
{Value = 4368446768}}) at CGExpr.cpp:671
#6 0x00000001001721d3 in
clang::CodeGen::CodeGenFunction::EmitStoreThroughLValue (this=0x7fff5fbfc4c0,
Src={V1 = {Value = 0}, V2 = {Value = 0}}, Dst={LVType =
clang::CodeGen::LValue::Simple, V = 0x10461c798, {VectorIdx = 0x7fff5fbfbe70,
VectorElts = 0x7fff5fbfbe70, BitFieldInfo = 0x7fff5fbfbe70, PropertyRefExpr =
0x7fff5fbfbe70, KVCRefExpr = 0x7fff5fbfbe70}, Quals = {Mask = 0, static
GCAttrMask = 24, static GCAttrShift = 3, static AddressSpaceMask = 4294967264,
static AddressSpaceShift = 5}, Ivar = false, ObjIsArray = false, NonGC = false,
GlobalObjCRef = false, BaseIvarExp = 0x0}, Ty={Value = {Value = 4368446768}})
at CGExpr.cpp:906
#7 0x0000000100151a3c in EmitMemberInitializer (CGF=@0x7fff5fbfc4c0,
ClassDecl=0x10461a110, MemberInit=0x10461ac40, Constructor=0x10461aa10,
Args=@0x7fff5fbfc260) at CGClass.cpp:471
#8 0x0000000100154610 in clang::CodeGen::CodeGenFunction::EmitCtorPrologue
(this=0x7fff5fbfc4c0, CD=0x10461aa10, CtorType=clang::Ctor_Base,
Args=@0x7fff5fbfc260) at CGClass.cpp:667
#9 0x0000000100154754 in clang::CodeGen::CodeGenFunction::EmitConstructorBody
(this=0x7fff5fbfc4c0, Args=@0x7fff5fbfc260) at CGClass.cpp:620
#10 0x000000010020bbdf in clang::CodeGen::CodeGenFunction::GenerateCode
(this=0x7fff5fbfc4c0, GD={Value = {Value = 4368476689}}, Fn=0x10461bce0) at
CodeGenFunction.cpp:306
#11 0x000000010014895b in clang::CodeGen::CodeGenModule::EmitCXXConstructor
(this=0x10483c400, D=0x10461aa10, Type=clang::Ctor_Base) at CGCXX.cpp:212
#12 0x0000000100216912 in clang::CodeGen::CodeGenModule::EmitGlobalDefinition
(this=0x10483c400, GD={Value = {Value = 4368476689}}) at CodeGenModule.cpp:743
#13 0x0000000100216ae9 in clang::CodeGen::CodeGenModule::EmitGlobal
(this=0x10483c400, GD={Value = {Value = 4368476689}}) at CodeGenModule.cpp:713
#14 0x00000001001481f4 in clang::CodeGen::CodeGenModule::EmitCXXConstructors
(this=0x10483c400, D=0x10461aa10) at CGCXX.cpp:196
#15 0x0000000100216e45 in clang::CodeGen::CodeGenModule::EmitTopLevelDecl
(this=0x10483c400, D=0x10461aa10) at CodeGenModule.cpp:1937
#16 0x000000010023476a in (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl (this=0x1046172b0, DG={D =
0x10461aa10}) at ModuleBuilder.cpp:65
#17 0x00000001000270f6 in (anonymous
namespace)::BackendConsumer::HandleTopLevelDecl (this=0x1046176d0, D={D =
0x10461aa10}) at CodeGenAction.cpp:147
--
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 llvm.org Thu Jun 3 09:36:21 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 3 Jun 2010 09:36:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7293] New: Missing #include in googletest
header file
Message-ID: in googletest header file
Product: new-bugs
Version: trunk
Platform: PC
OS/Version: other
Status: NEW
Severity: normal
Priority: P
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: reeuwijk at few.vu.nl
CC: llvmbugs at cs.uiuc.edu
The file utils/unittest/googletest/include/gtest/internal/gtest-port.h uses the
functions 'isatty()' and 'rmdir()'. The declarations for these functions are in
unistd.h (according to their man pages on a recent Ubuntu system). However,
gtest-port.h does not #include .
The missing #include causes compilation problems on Minix3.
--
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 llvm.org Thu Jun 3 09:46:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 3 Jun 2010 09:46:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7294] New: Please add Minix to the list of excluded
OS in tools/clang/tools/Makefile
Message-ID: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #4 from Jakob Stoklund Olesen 2010-06-03 09:01:49 CDT ---
The early clobber, fixed assignment constraint "=&a" is not handled correctly.
It might help to add "%eax" t the clobber list.
And yes, this looks like a dup of PR 4118.
*** This bug has been marked as a duplicate of bug 4118 ***
--
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 llvm.org Thu Jun 3 08:12:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 3 Jun 2010 08:12:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7292] New: Adding version ident to clang-compiled
object files
Message-ID: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |sharparrow1 at yahoo.com
Resolution| |FIXED
--- Comment #1 from Eli Friedman 2010-06-03 14:58:31 CDT ---
Fixed in r105404.
--
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 llvm.org Thu Jun 3 15:14:49 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 3 Jun 2010 15:14:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7296] New: Disable specific warnings during static
analysis
Message-ID: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |sharparrow1 at yahoo.com
Resolution| |FIXED
--- Comment #6 from Eli Friedman 2010-06-03 15:39:40 CDT ---
Fixed in r105408.
--
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 llvm.org Thu Jun 3 23:02:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 3 Jun 2010 23:02:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7297] New: Member access is not the same for b[0].x
and b->x
Message-ID: for instructions.
--
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 llvm.org Fri Jun 4 02:48:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 4 Jun 2010 02:48:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7300] New: Unused argument registers can not be
reused
Message-ID: = MOV16rr %R12W
%reg1026 = MOV16rr %R13W
%reg1025 = MOV16rr %R14W
%reg1024 = MOV16rr %R15W
%reg1028 = MOV16rm %reg0, ; mem:LD2[@b]
%reg1029 = ADD16rm %reg1028, %reg0, , %SRW;
mem:LD2[@a]
SUB16mr %reg0, , %reg1029, %SRW; mem:ST2[@r]
LD2[@r]
RET
# End machine code for function test.
# Machine code for function test:
Function Live Ins: %R15W in reg%1024, %R14W in reg%1025, %R13W in reg%1026,
%R12W in reg%1027
BB#0: derived from LLVM BB %entry
Live Ins: %R15W %R14W %R13W %R12W
%reg1028 = MOV16rm %reg0, ; mem:LD2[@b]
%reg1029 = ADD16rm %reg1028, %reg0, , %SRW;
mem:LD2[@a]
SUB16mr %reg0, , %reg1029, %SRW; mem:ST2[@r]
LD2[@r]
RET
# End machine code for function test.
Those MOV16rr instructions are all dead, so machine DCE removes them. That
leaves the livein registers dangling, never to be killed. LiveIntervalAnalysis
then decides that they are live through the block.
--
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 llvm.org Fri Jun 4 11:59:36 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 4 Jun 2010 11:59:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7303] New: Assert when comparing vectors on X86_64
Message-ID: [#uses=1]
@global_subject11_246957600 = internal global i64 0 ; [#uses=1]
define void @dependentGraph0() {
entry:
%0 = load i64* @global_subject2_246951760 ; [#uses=1]
%1 = load i64* @global_subject11_246957600 ; [#uses=1]
%tupleInsert = insertelement <2 x i64> undef, i64 %0, i32 0 ; <<3 x i64>>
[#uses=1]
%tupleInsert33 = insertelement <2 x i64> %tupleInsert, i64 %1, i32 1 ; <<3 x
i64>> [#uses=1]
%q_equal35 = icmp eq <2 x i64> %tupleInsert33, zeroinitializer ; <<3 x i1>>
[#uses=1]
call void @output_integer(i8* inttoptr (i64 246924032 to i8*), i64 0, i64 0,
<2 x i1> %q_equal35)
ret void
}
declare void @output_integer(i8*, i64, i64, <2 x i1>) nounwind
--
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 llvm.org Fri Jun 4 14:03:23 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 4 Jun 2010 14:03:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7304] New: Partial specialize uses wrong
specialization for callsite
Message-ID: /C/
$ clang -D_7ZIP_ST -O1 -c LzmaEnc.c
Instruction does not dominate all uses!
%tmp3425 = mul i32 %umax3424, -1 ; [#uses=1]
%tmp3426 = add i32 %tmp3425, -1 ; [#uses=1]
Broken module found, compilation aborted!
0 clang 0x0000000001519eb4
1 clang 0x0000000001519d78
2 libpthread.so.0 0x00007f4a771c6150
3 libc.so.6 0x00007f4a764e21a5 gsignal + 53
4 libc.so.6 0x00007f4a764e35d0 abort + 384
5 clang 0x00000000014ac96b
6 clang 0x00000000014ac64c
7 clang 0x0000000001481a75
8 clang 0x000000000148173f
9 clang 0x00000000014813ef
10 clang 0x000000000042908b
11 clang 0x0000000000427d4d
12 clang 0x00000000006ad02a
13 clang 0x0000000000443c48
14 clang 0x00000000004438b3
15 clang 0x000000000042e2ea
16 clang 0x00000000004092df
17 clang 0x0000000000411eb0 main + 342
18 libc.so.6 0x00007f4a764cebbd __libc_start_main + 253
19 clang 0x0000000000407ca9
Stack dump:
0. Program arguments: /home/nelchael/devel/llvm/Debug/bin/clang -cc1
-triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name LzmaEnc.c
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir
/home/nelchael/devel/llvm/Debug/lib/clang/2.0 -D_7ZIP_ST -O1 -ferror-limit 19
-fmessage-length 194 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-lVeStn.s -x c LzmaEnc.c
1. parser at end of file
2. Code generation
3. Running pass 'Module Verifier' on function '@GetOptimum'
clang: error: clang frontend command failed due to signal 6 (use -v to see
invocation)
--
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 llvm.org Fri Jun 4 18:17:52 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 4 Jun 2010 18:17:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5599] clang doesn't follow x86-64 ABI array
alignment rule
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #5 from Rafael ?vila de Esp?ndola 2010-06-04 18:17:51 CDT ---
Fixed in r105500.
--
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 llvm.org Fri Jun 4 19:33:27 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 4 Jun 2010 19:33:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7306] LzmaEnc.c fails to compile
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #4 from Dan Gohman 2010-06-04 19:33:26 CDT ---
Fixed in r105510.
--
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 llvm.org Fri Jun 4 19:36:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 4 Jun 2010 19:36:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7260] Bogus(?) floating-point overflow
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #7 from Dan Gohman 2010-06-04 19:36:10 CDT ---
Fixed in r105480. The generated code isn't as nice as it could be, but that's
a separate issue.
--
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 llvm.org Sat Jun 5 02:52:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 5 Jun 2010 02:52:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5382] ScheduleDAGRRList crash in Debug+Checks build
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #5 from Jakub Staszak 2010-06-05 02:52:04 CDT ---
Fixed in r104718.
--
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 llvm.org Sat Jun 5 09:19:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 5 Jun 2010 09:19:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7308] New: Clang doesn't consider conversion
function template friends.
Message-ID:
class A
{
public:
template
operator A() {
A u;
u.m_a = m_a;
return u;
}
template template
friend A::operator A();
private:
int m_a;
};
void f() {
A a = A();
}
There seems to be poor support for such friends. Comeau fails with an ICE
assertion failure and GCC doesn't like it either.
I believe this program is correct according to the Standard (however the
Standard says that you can define function template friends in the friend
declaration - this can't be true for member function templates. Sounds like the
text treats "member function template" and "member template" as being mutually
exclusive?).
If this is indeed not valid, it would seem to be a good thing to reject this
straight away when the template is parsed.
--
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 llvm.org Sat Jun 5 09:57:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 5 Jun 2010 09:57:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7304] Partial specialize uses wrong specialization
for callsite
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Kenneth Uildriks 2010-06-05 09:57:34 CDT ---
Patch by Takumi Nakamura!
--
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 llvm.org Sat Jun 5 10:00:55 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 5 Jun 2010 10:00:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7309] New: Objective-C: Retain-count analysis with
property assignment
Message-ID:
@interface MyClass : NSObject
// retain or assign doesn't change anything
@property(nonatomic, retain) id prop;
@end
int main(int argc, char **argv)
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
MyClass *obj = [[[MyClass alloc] init] autorelease];
// This line triggers a possible leak diagnosis
[obj setProp:[[NSObject alloc] init]];
// This line is strictly equivalent but doesn't trigger the leak diagnosis
obj.prop = [[NSObject alloc] init];
[pool drain];
return 0;
}
@implementation MyClass
@synthesize prop;
@end
--
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 llvm.org Mon Jun 7 10:58:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 7 Jun 2010 10:58:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7245] Should not require copy constructor when
binding rvalue to reference
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Jeffrey Yasskin 2010-06-07 10:58:24 CDT ---
Fixed by r105529.
--
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 llvm.org Mon Jun 7 10:59:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 7 Jun 2010 10:59:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7247] Global templates shouldn't make member
template functions ambiguous
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Jeffrey Yasskin 2010-06-07 10:59:56 CDT ---
Fixed by r105518.
--
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 llvm.org Mon Jun 7 11:46:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 7 Jun 2010 11:46:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7298] undefined references in building several SPEC
CPU2000 Fortran benchmarks
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Duncan Sands 2010-06-07 11:46:11 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100607/102268.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 llvm.org Mon Jun 7 12:00:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 7 Jun 2010 12:00:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7310] New: Wrong ABI on ARM for classes with non
trivial copy constructors
Message-ID: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Rafael ?vila de Esp?ndola 2010-06-07 21:43:02 CDT ---
Fixed in 105592.
--
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 llvm.org Tue Jun 8 00:11:52 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 8 Jun 2010 00:11:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7311] New: Invalid instcombine of vector to scalar
Message-ID: -> into i64 ->
Testcase attached.
--
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 llvm.org Tue Jun 8 02:43:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 8 Jun 2010 02:43:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7312] New: Fast regalloc crash: Instruction uses an
alias of an allocated register
Message-ID: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #6 from Duncan Sands 2010-06-08 06:21:52 CDT ---
The loads and stores cannot be hoisted because of the possibility that src ==
dst.
--
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 llvm.org Tue Jun 8 12:29:33 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 8 Jun 2010 12:29:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7316] New: use of memcpy intrinsic causes assertion
Message-ID: ::reference
llvm::ilist_iterator::operator*() const [with NodeTy =
llvm::Instruction]: Assertion `Traits::getNext(NodePtr) != 0 && "Dereferencing
end()!"' failed.
0 llc 0x0000000000ec915f
1 llc 0x0000000000ec994d
2 libpthread.so.0 0x00007ff5323f5190
3 libc.so.6 0x00007ff5316fa4b5 gsignal + 53
4 libc.so.6 0x00007ff5316fdf50 abort + 384
5 libc.so.6 0x00007ff5316f3481 __assert_fail + 241
6 llc 0x0000000000e2fe5d llvm::Instruction::eraseFromParent() +
125
7 llc 0x0000000000cac0e6
8 llc 0x0000000000c24803
9 llc 0x0000000000e60f45
llvm::FPPassManager::runOnFunction(llvm::Function&) + 581
10 llc 0x0000000000e61361
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 145
11 llc 0x0000000000e61571
llvm::FunctionPassManager::run(llvm::Function&) + 81
12 llc 0x00000000005399cf main + 5439
13 libc.so.6 0x00007ff5316e5abd __libc_start_main + 253
14 llc 0x0000000000537869
Stack dump:
0. Program arguments: /usr/bin/llc -mtriple=x86_64-Linux-unknown -f -o
imaginary/wheel-sieve1/build/Main_plus_prelude.s
imaginary/wheel-sieve1/build/Main_plus_prelude_opt.bc
1. Running pass 'Lower Garbage Collection Instructions' on function
'@fun_plusplus'
--------------------------------------------------
--
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 llvm.org Tue Jun 8 13:28:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 8 Jun 2010 13:28:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7204] ccc-analyzer does not support gcc -imacros
option
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |kremenek at apple.com
Resolution| |FIXED
--- Comment #1 from Ted Kremenek 2010-06-08 13:28:13 CDT ---
(In reply to comment #0)
> clang seems to support it, ccc-analyzer should support it lile -include (adding
> it in %CompileOptionMap ?)
Agreed. Fixed in r105624.
--
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 llvm.org Tue Jun 8 13:58:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 8 Jun 2010 13:58:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7318] New: opt assertion failure after doing a
simple loop unroll
Message-ID: [#uses=3]
%s.0.lcssa = phi i32 [ 0, %entry ], [ %4, %bb.1 ], [ %4, %bb ] ;
[#uses=1]
Instruction does not dominate all uses!
%s.0.lcssa = phi i32 [ 0, %entry ], [ %4, %bb.1 ], [ %4, %bb ] ;
[#uses=1]
ret i32 %s.0.lcssa
Broken module found, compilation aborted!
0 opt 0x0000000000c1685c
1 opt 0x0000000000c16720
2 libpthread.so.0 0x00007f60e23f2190
3 libc.so.6 0x00007f60e16f74b5 gsignal + 53
4 libc.so.6 0x00007f60e16faf50 abort + 384
5 opt 0x0000000000bb58b9
6 opt 0x0000000000bb55d0
7 opt 0x0000000000b8ac7f
llvm::FPPassManager::runOnFunction(llvm::Function&) + 405
8 opt 0x0000000000b8ae9c
llvm::FPPassManager::runOnModule(llvm::Module&) + 102
9 opt 0x0000000000b8b1cf
llvm::MPPassManager::runOnModule(llvm::Module&) + 459
10 opt 0x0000000000b8b70f llvm::PassManagerImpl::run(llvm::Module&)
+ 125
11 opt 0x0000000000b8bc1b llvm::PassManager::run(llvm::Module&) +
39
12 opt 0x00000000007b8eb5 main + 3597
13 libc.so.6 0x00007f60e16e2abd __libc_start_main + 253
14 opt 0x00000000007aa789
Stack dump:
0. Program arguments: opt -O3 -unroll-count=2 b.bc -o out.bc
1. Running pass 'Function Pass Manager' on module 'b.bc'.
2. Running pass 'Module Verifier' on function '@foo'
Aborted (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 llvm.org Tue Jun 8 14:50:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 8 Jun 2010 14:50:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6163] Warn when comparing two arrays
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #5 from Douglas Gregor 2010-06-08 14:50:53 CDT ---
(In reply to comment #4)
> Created an attachment (id=4965)
--> (http://llvm.org/bugs/attachment.cgi?id=4965) [details]
> array checks
>
> This time with diagnostics that don't break localization, fixed LE GE, more
> tests.
Much improved! I've committed a slightly-tweaked version here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100607/031066.html
I removed this particular change, which doesn't seem necessary or related:
if (!lType->isFloatingType()
- && !(lType->isBlockPointerType() && isRelational)) {
+ && !lType->isBlockPointerType()) {
Also, I excluded VarDecls of reference type from the array-comparison warning,
since the result of such a comparison won't always be constant.
--
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 llvm.org Tue Jun 8 15:39:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 8 Jun 2010 15:39:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7319] New: Clang rejects enum compare gcc doesn't
and prints insane candidate list
Message-ID:
typedef enum {
Enum1,
Enum2,
Enum3
} MyEnum;
template
bool operator>(const X &inX1, const X &inX2)
{
return inX2 < inX1;
}
int main (int argc, const char * argv[]) {
MyEnum e1, e2;
if (e1 > e2)
std::cout << "its larger!\n" << std::endl;
else
std::cout << "its smaller!\n" << std::endl;
std::cout << "Done!\n" << std::endl;
return 0;
}
---
GCC accepts this code but clang rejects it. Clang also does it in a
particularly horrible way, producing:
t.cc:19:8: error: use of overloaded operator '>' is ambiguous
if (e1 > e2)
~~ ^ ~~
t.cc:10:6: note: candidate function [with X = MyEnum]
bool operator>(const X &inX1, const X &inX2)
^
t.cc:19:8: note: built-in candidate operator>(MyEnum, MyEnum)
if (e1 > e2)
^
t.cc:19:8: note: built-in candidate operator>(int, int)
t.cc:19:8: note: built-in candidate operator>(double, int)
t.cc:19:8: note: built-in candidate operator>(unsigned int, int)
t.cc:19:8: note: built-in candidate operator>(unsigned long, int)
t.cc:19:8: note: built-in candidate operator>(long double, int)
t.cc:19:8: note: built-in candidate operator>(long long, int)
t.cc:19:8: note: built-in candidate operator>(float, int)
t.cc:19:8: note: built-in candidate operator>(unsigned long long, int)
t.cc:19:8: note: built-in candidate operator>(long, int)
t.cc:19:8: note: built-in candidate operator>(int, long)
t.cc:19:8: note: built-in candidate operator>(int, long long)
t.cc:19:8: note: built-in candidate operator>(int, unsigned int)
t.cc:19:8: note: built-in candidate operator>(int, unsigned long)
t.cc:19:8: note: built-in candidate operator>(int, unsigned long long)
t.cc:19:8: note: built-in candidate operator>(int, float)
t.cc:19:8: note: built-in candidate operator>(int, double)
t.cc:19:8: note: built-in candidate operator>(int, long double)
t.cc:19:8: note: built-in candidate operator>(unsigned long long, double)
t.cc:19:8: note: built-in candidate operator>(unsigned long long, long double)
t.cc:19:8: note: built-in candidate operator>(unsigned long long, float)
t.cc:19:8: note: built-in candidate operator>(unsigned long long, unsigned long
long)
t.cc:19:8: note: built-in candidate operator>(unsigned long long, unsigned
long)
t.cc:19:8: note: built-in candidate operator>(float, long)
t.cc:19:8: note: built-in candidate operator>(float, long long)
t.cc:19:8: note: built-in candidate operator>(float, unsigned int)
t.cc:19:8: note: built-in candidate operator>(float, unsigned long)
t.cc:19:8: note: built-in candidate operator>(float, unsigned long long)
t.cc:19:8: note: built-in candidate operator>(float, float)
t.cc:19:8: note: built-in candidate operator>(unsigned long long, unsigned int)
t.cc:19:8: note: built-in candidate operator>(float, double)
t.cc:19:8: note: built-in candidate operator>(long double, long double)
t.cc:19:8: note: built-in candidate operator>(long double, double)
t.cc:19:8: note: built-in candidate operator>(long double, float)
t.cc:19:8: note: built-in candidate operator>(long double, unsigned long long)
t.cc:19:8: note: built-in candidate operator>(long double, unsigned long)
t.cc:19:8: note: built-in candidate operator>(long double, unsigned int)
t.cc:19:8: note: built-in candidate operator>(long double, long long)
t.cc:19:8: note: built-in candidate operator>(long double, long)
t.cc:19:8: note: built-in candidate operator>(double, long double)
t.cc:19:8: note: built-in candidate operator>(double, double)
t.cc:19:8: note: built-in candidate operator>(double, float)
t.cc:19:8: note: built-in candidate operator>(double, unsigned long long)
t.cc:19:8: note: built-in candidate operator>(double, unsigned long)
t.cc:19:8: note: built-in candidate operator>(double, unsigned int)
t.cc:19:8: note: built-in candidate operator>(double, long long)
t.cc:19:8: note: built-in candidate operator>(double, long)
t.cc:19:8: note: built-in candidate operator>(float, long double)
t.cc:19:8: note: built-in candidate operator>(unsigned int, long)
t.cc:19:8: note: built-in candidate operator>(long long, long double)
t.cc:19:8: note: built-in candidate operator>(long long, double)
t.cc:19:8: note: built-in candidate operator>(long long, float)
t.cc:19:8: note: built-in candidate operator>(long long, unsigned long long)
t.cc:19:8: note: built-in candidate operator>(long long, unsigned long)
t.cc:19:8: note: built-in candidate operator>(long long, unsigned int)
t.cc:19:8: note: built-in candidate operator>(long long, long long)
t.cc:19:8: note: built-in candidate operator>(long long, long)
t.cc:19:8: note: built-in candidate operator>(long, long double)
t.cc:19:8: note: built-in candidate operator>(long, double)
t.cc:19:8: note: built-in candidate operator>(long, float)
t.cc:19:8: note: built-in candidate operator>(long, unsigned long long)
t.cc:19:8: note: built-in candidate operator>(long, unsigned long)
t.cc:19:8: note: built-in candidate operator>(long, unsigned int)
t.cc:19:8: note: built-in candidate operator>(long, long long)
t.cc:19:8: note: built-in candidate operator>(long, long)
t.cc:19:8: note: built-in candidate operator>(unsigned long long, long long)
t.cc:19:8: note: built-in candidate operator>(unsigned long long, long)
t.cc:19:8: note: built-in candidate operator>(unsigned long, long double)
t.cc:19:8: note: built-in candidate operator>(unsigned long, double)
t.cc:19:8: note: built-in candidate operator>(unsigned long, float)
t.cc:19:8: note: built-in candidate operator>(unsigned long, unsigned long
long)
t.cc:19:8: note: built-in candidate operator>(unsigned long, unsigned long)
t.cc:19:8: note: built-in candidate operator>(unsigned long, unsigned int)
t.cc:19:8: note: built-in candidate operator>(unsigned long, long long)
t.cc:19:8: note: built-in candidate operator>(unsigned long, long)
t.cc:19:8: note: built-in candidate operator>(unsigned int, long double)
t.cc:19:8: note: built-in candidate operator>(unsigned int, double)
t.cc:19:8: note: built-in candidate operator>(unsigned int, float)
t.cc:19:8: note: built-in candidate operator>(unsigned int, unsigned long long)
t.cc:19:8: note: built-in candidate operator>(unsigned int, unsigned long)
t.cc:19:8: note: built-in candidate operator>(unsigned int, unsigned int)
t.cc:19:8: note: built-in candidate operator>(unsigned int, long long)
1 error 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 llvm.org Tue Jun 8 16:04:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 8 Jun 2010 16:04:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7319] Clang rejects enum compare gcc doesn't and
prints insane candidate list
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Douglas Gregor 2010-06-08 16:03:59 CDT ---
The bug is fixed in Clang r105642. The insane candidate list is a known issue
that Jeffrey Yasskin is currently looking into.
--
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 llvm.org Tue Jun 8 16:24:29 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 8 Jun 2010 16:24:29 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7320] New: #pragma GCC dependency crashes FE
without the optional trailing text
Message-ID: const&) + 121
11 libstdc++.so.6 0x000000381489d0b1 std::string::_M_mutate(unsigned long,
unsigned long, unsigned long) + 113
12 clang 0x0000000000afd97d
13 clang 0x0000000000affaed
14 clang 0x0000000000affaed
15 clang 0x0000000000afb789
16 clang 0x0000000000aeea57
17 clang 0x0000000000adc776
18 clang 0x0000000000adcbec
19 clang 0x0000000000a87d34
20 clang 0x0000000000a9975e
21 clang 0x0000000000aa2d69
22 clang 0x0000000000aacca8
23 clang 0x0000000000aace14
24 clang 0x0000000000a9c3ed
25 clang 0x0000000000a9c6aa
26 clang 0x000000000069b61e
27 clang 0x000000000043bb74
28 clang 0x000000000043eb92
29 clang 0x000000000042d2d0
30 clang 0x0000000000432e04 main + 2724
31 libc.so.6 0x000000381041d994 __libc_start_main + 244
32 clang 0x000000000042b469
Stack dump:
0. Program arguments:
/x/eng/build_scratch2/nomura/clang-llvm_100608_0000/root/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -S -disable-free -main-file-name a.c
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir
/x/eng/build_scratch2/nomura/clang-llvm_100608_0000/root/lib/clang/2.0
-U__linux__ -U__linux -Ulinux -U__gnu_linux__ -D__FreeBSD__=7 -D__amd64__
-ferror-limit 19 -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-Dq82Or.s -x c a.c
1. a.c:1:2: current parser token 'pragma'
clang: error: clang frontend command failed due to signal 6 (use -v to see
invocation)
[cyclsvl02]$
--
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 llvm.org Tue Jun 8 16:45:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 8 Jun 2010 16:45:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7321] New: --foo=bar flags are passed to
subprocesses as "--foo= bar"
Message-ID: ' : destructor
could not be generated because a base class destructor is inaccessible
with
[
T=llvm::MachineInstr
]
D:\hq\stg\opencl\drivers\opencl\compiler\llvm\include\llvm/Support/AlignOf.h(38)
: see reference to class template instantiation 'll
vm::AlignmentCalcImpl' being compiled
with
[
T=llvm::MachineInstr
]
D:\hq\stg\opencl\drivers\opencl\compiler\llvm\include\llvm/CodeGen/MachineFunction.h(102)
: see reference to class template instanti
ation 'llvm::AlignOf' being compiled
with
[
T=llvm::MachineInstr
]
--
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 llvm.org Tue Jun 8 18:16:16 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 8 Jun 2010 18:16:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7323] New: Tablegen should not generate switch
statements if no case lables exist
Message-ID: [#uses=1]
%and2 = and i32 %y, 65535 ; [#uses=1]
%add = add nsw i32 %and2, %and ; [#uses=1]
ret i32 %add
}
Compiled with "llc -march=thumb -mattr=+thumb2":
and r0, r0, #255
bfc r1, #16, #16
adds r0, r1, r0
bx lr
Compiled with "llc -march=thumb -mattr=+v6":
uxtb r0, r0
uxth r1, r1
adds r0, r1, r0
bx lr
I'm pretty sure that uxtb/uxth are shorter, so I'm not sure why they aren't
being used.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Wed Jun 9 00:24:08 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 9 Jun 2010 00:24:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7325] New: Clang too permissive with use of member
function lacking a call
Message-ID: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Kees van Reeuwijk 2010-06-09 08:27:34 CDT ---
Retracted, since this bug report is no longer applicable.
--
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 llvm.org Wed Jun 9 08:47:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 9 Jun 2010 08:47:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7331] New: Syntax Error in exports.map
Message-ID: parser at end of file
2. assert17-min.cc:3:5: LLVM IR generation of declaration 'main'
3. assert17-min.cc:3:5: Generating code for declaration 'main'
4. assert17-min.cc:3:12: LLVM IR generation of compound statement ('{}')
clang: error: clang frontend command failed due to signal 6 (use -v to see
invocation)
$ clang --version
clang version 2.0 (trunk 105724)
Target: x86_64-unknown-freebsd8.0
Thread model: posix
--
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 llvm.org Wed Jun 9 11:37:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 9 Jun 2010 11:37:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7333] New: infinite loop when compiling SPEC
CPU2006's 465.tonto
Message-ID: ::LoopSimplify::ProcessLoop(llvm::Loop*, llvm::LPPassManager&)?:
compiler/llvm/lib/Transforms/Utils/LoopSimplify.cpp:134: warning: label
?ReprocessLoop? defined but not used
compiler/llvm/lib/Transforms/Utils/LoopSimplify.cpp: At global scope:
compiler/llvm/lib/Transforms/Utils/LoopSimplify.cpp:63: warning: ?NumNested?
defined but not used
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Wed Jun 9 14:19:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 9 Jun 2010 14:19:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7321] --foo=bar flags are passed to subprocesses as
"--foo= bar"
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Daniel Dunbar 2010-06-09 14:19:42 CDT ---
Fixed here:
http://llvm.org/viewvc/llvm-project?view=rev&revision=105744
--
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 llvm.org Wed Jun 9 14:27:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 9 Jun 2010 14:27:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7321] --foo=bar flags are passed to subprocesses as
"--foo= bar"
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #3 from Daniel Dunbar 2010-06-09 14:27:18 CDT ---
Actually, that's not quite right yet...
--
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 llvm.org Wed Jun 9 15:06:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 9 Jun 2010 15:06:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7313] Fast regalloc: Ran out of registers during
register allocation!
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Jakob Stoklund Olesen 2010-06-09 15:06:40 CDT ---
Fixed in r105749
--
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 llvm.org Wed Jun 9 16:41:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 9 Jun 2010 16:41:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7336] New: imprecise wording in -pedantic warning
Message-ID: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #4 from Daniel Dunbar 2010-06-09 17:45:26 CDT ---
Fixed here:
http://llvm.org/viewvc/llvm-project?view=rev&revision=105763
--
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 llvm.org Wed Jun 9 18:16:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 9 Jun 2010 18:16:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7337] New: -Wunused-parameter
Message-ID:
void foo(const std::string &s)
{
std::string _str = s;
bool b = bool(_str[0] == '_' || std::isalpha(_str[0]));
}
int main()
{
return 0;
}
produces this:
$ clang++ --analyze test.cpp
test.cpp:7:10: warning: Value stored to 'b' during its initialization is never
read
bool b = bool(_str[0] == '_' || std::isalpha(_str[0]));
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
clang:
/home/reif/clang/llvm/tools/clang/lib/Checker/../../include/clang/Checker/PathSensitive/CheckerVisitor.h:41:
void clang::CheckerVisitor::PreVisit(clang::CheckerContext&, const
clang::Stmt*) [with ImplClass = ::AdjustedReturnValueChecker]:
Assertion `false && "Unsupport statement."' failed.
0 clang 0x090e38e0
1 clang 0x090e3778
2 0x00b45400 __kernel_sigreturn + 0
3 libc.so.6 0x0013da82 abort + 386
4 libc.so.6 0x00133718 __assert_fail + 248
5 clang 0x085a15ef
6 clang 0x085a156d
7 clang 0x0854d79c
8 clang 0x0853b6f2
9 clang 0x085447c2
10 clang 0x0853dbb8
11 clang 0x085450ec
12 clang 0x0853db32
13 clang 0x0853d2f4
14 clang 0x085356e6
15 clang 0x0853653d
16 clang 0x08535bb3
17 clang 0x081662b8
18 clang 0x0816330b
19 clang 0x08163402
20 clang 0x08163488
21 clang 0x08163075
22 clang 0x08162ade
23 clang 0x082f38e7
24 clang 0x08098a2a
25 clang 0x08098693
26 clang 0x08084c14
27 clang 0x0804ec2f
28 clang 0x0805754b main + 365
29 libc.so.6 0x00126bd6 __libc_start_main + 230
30 clang 0x0804d5e1
Stack dump:
0. Program arguments: /usr/local/bin/clang -cc1 -triple i386-pc-linux-gnu
-analyze -disable-free -main-file-name test.cpp -analyzer-store=region
-analyzer-opt-analyze-nested-blocks -analyzer-check-dead-stores
-analyzer-check-objc-mem -analyzer-eagerly-assume
-analyzer-check-objc-methodsigs -analyzer-check-objc-unused-ivars
-analyzer-output plist -w -mrelocation-model static -mdisable-fp-elim
-mconstructor-aliases -target-cpu pentium4 -resource-dir
/usr/local/lib/clang/2.0 -ferror-limit 19 -fmessage-length 207 -fexceptions
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o test.plist -x
c++ test.cpp
1. parser at end of file
2. test.cpp:7:5: Error evaluating statement
3. test.cpp:7:5: Error evaluating statement
4. test.cpp:7:14: Error evaluating statement
clang: error: clang frontend command failed due to signal 6 (use -v to see
invocation)
--
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 llvm.org Thu Jun 10 02:21:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Jun 2010 02:21:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7341] New: Crashing on structure initialization
Message-ID: parser at end of file
2. Code generation
3. Running pass 'X86 DAG->DAG Instruction Selection' on function
'@_ZN4TestC2Ev'
#include
#include
namespace {
struct A { };
}
struct Test
{
Test();
std::deque > x;
};
Test::Test() {}
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Thu Jun 10 04:01:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Jun 2010 04:01:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7343] New: Friend declaration is ignored
Message-ID:
struct Functor {
};
class Class {
struct Inner {
int a_;
};
friend struct Functor;
};
template <>
struct Functor {
int operator() (Class::Inner const & key) const
{
return key.a_;
}
};
yields:
functor.cc:14:23: error: 'Inner' is a private member of 'Class'
struct Functor {
^
functor.cc:6:12: note: declared private here
struct Inner {
^
1 error 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 llvm.org Thu Jun 10 04:07:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Jun 2010 04:07:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7344] New: Clang assertion failure when casting
void* to unsigned long
Message-ID: parser at end of file
2. ../src/serialize-bin-bug.C:1:6: LLVM IR generation of declaration
'serialize_annotatable_id'
3. ../src/serialize-bin-bug.C:1:6: Generating code for declaration
'serialize_annotatable_id'
4. ../src/serialize-bin-bug.C:2:1: LLVM IR generation of compound
statement ('{}')
clang: error: clang frontend command failed due to signal 6 (use -v to see
invocation)
Reproducable: Always
Expected Result: No assertion.
--
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 llvm.org Thu Jun 10 13:33:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Jun 2010 13:33:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7345] New: clang.llvm.org cannot be navigated with
a small window
Message-ID: CChar;
template int CChar::x; // fails
template int C::x; // ok
and the error message isn't too helpful.
See attached for code to build with -fsyntax-only.
--
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 llvm.org Thu Jun 10 14:24:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Jun 2010 14:24:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7348] New: Compiling a file results in sig11
Message-ID: -generated-files.hmap -iquote -project-headers.hmap -include-pch
/var/folders/VF/VFzLnnQ9GHSra88EddQRXE+++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/_Prefix-amoyqdgxngwegvaqnzimlpkpvmmv/_Prefix.pch.pth
-I-own-target-headers.hmap -I-all-target-headers.hmap
-F/build/Debug -I/Debug/include -I.build/DerivedSources/x86_64
-I.build/DerivedSources -O0 -Wno-trigraphs -Wreturn-type -Wunused-variable
-Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -std=gnu99
-fmessage-length=0 -fobjc-gc-only -fdiagnostics-print-source-range-info
-fpascal-strings -fdiagnostics-show-option -o
/var/folders/VF/VFzLnnQ9GHSra88EddQRXE+++TI/-Tmp-/cc-F9hCmK.s -x objective-c
//anon_union_struct_objc_class_crash.m
1. parser at end of file
2. /anon_union_struct_objc_class_crash.m:17:1: LLVM IR generation of
declaration 'AClass'
--
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 llvm.org Thu Jun 10 16:49:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Jun 2010 16:49:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7351] New: Bad recovery from "redefinition of 'x'
with a different type"
Message-ID: :1:2: error: unrecognized instruction
add $1, 1(%esp)
^
asmtests.c:4:19: note: generated from here
asm volatile ("add $1, 1(%esp) \n");
^
:1:9: error: unknown token in expression
lea 1+(%eax), %ebx
^
asmtests.c:10:19: note: generated from here
asm volatile ("lea 1+(%eax), %ebx \n");
^
:1:2: error: unrecognized instruction
pavgusb %mm1, %mm0
^
asmtests.c:16:19: note: generated from here
asm volatile ("pavgusb %mm1, %mm0 \n");
^
:1:2: error: unrecognized instruction
jmp *1(%esp)
^
asmtests.c:22:19: note: generated from here
asm volatile ("jmp *1(%esp) \n");
^
:1:2: error: unrecognized instruction
prefetch (%eax)
^
asmtests.c:28:19: note: generated from here
asm volatile ("prefetch (%eax) \n");
^
5 errors generated.
These are all required to compile FFmpeg.
--
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 llvm.org Fri Jun 11 03:42:24 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Jun 2010 03:42:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7353] New: Undefined symbol '__ZNSbIcED1Ev' when
using extern templates and -fvisibility-hidden
Message-ID: class basic_string {
public:
~basic_string() {}
};
extern template class basic_string;
}
std::basic_string kEmptyString;
$ /Users/thakis/src/llvm/Release/bin/clang++ -fvisibility=hidden -c file.pp.mm
fatal error: error in backend: symbol '__ZNSbIcED1Ev' can not be undefined in a
subtraction expression
The message is written by llvm/lib/MC/MachObjectWriter.cpp
--
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 llvm.org Fri Jun 11 04:38:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Jun 2010 04:38:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7354] New: False positive due to lack of knowledge
about sizeof()
Message-ID: class A {
class D;
D d;
};
$ /Users/thakis/src/llvm/Release/bin/clang++ -v -c crash.mm
clang version 2.0 (trunk 105794)
Target: i386-apple-darwin9
Thread model: posix
"/Users/thakis/src/llvm/Release/bin/clang" -cc1 -triple i386-apple-darwin9.0.0
-emit-obj -mrelax-all -disable-free -main-file-name crash.mm -pic-level 1
-mdisable-fp-elim -masm-verbose -target-cpu yonah -v -resource-dir
/Users/thakis/src/llvm/Release/lib/clang/2.0 -ferror-limit 19 -fmessage-length
127 -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o crash.o -x
objective-c++ crash.mm
clang -cc1 version 2.0 based upon llvm 2.8svn hosted on i386-apple-darwin9
ignoring nonexistent directory "/usr/include/c++/4.2.1"
ignoring nonexistent directory "/usr/include/c++/4.2.1/i686-apple-darwin10/"
ignoring nonexistent directory "/usr/include/c++/4.2.1/backward"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.0.0
/usr/include/c++/4.0.0/i686-apple-darwin8
/usr/include/c++/4.0.0/backward
/usr/local/include
/Users/thakis/src/llvm/Release/lib/clang/2.0/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
Assertion failed: (DefinitionData && "queried property of class with no
definition"), function data, file
/Users/thakis/src/llvm/tools/clang/lib/Sema/../../include/clang/AST/DeclCXX.h,
line 364.
0 clang 0x015140b8 main + 22059384
1 clang 0x01514e16 main + 22062806
2 libSystem.B.dylib 0x938812bb _sigtramp + 43
3 libSystem.B.dylib 0xffffffff _sigtramp + 1819798895
4 libSystem.B.dylib 0x938f523a raise + 26
5 libSystem.B.dylib 0x93901679 abort + 73
6 libSystem.B.dylib 0x938f63db __assert_rtn + 101
7 clang 0x0036a9cd main + 3539597
8 clang 0x0036ab87 main + 3540039
9 clang 0x003a6d26 main + 3786214
10 clang 0x007a6014 main + 7977172
11 clang 0x007a8da9 main + 7988841
12 clang 0x007aa777 main + 7995447
13 clang 0x0079a530 main + 7929328
14 clang 0x007e792c main + 8245740
15 clang 0x007eb181 main + 8260161
16 clang 0x007eb514 main + 8261076
17 clang 0x007a15c5 main + 7958149
18 clang 0x007f7d8e main + 8312398
19 clang 0x007f8114 main + 8313300
20 clang 0x003018d0 main + 3109264
21 clang 0x000636a4 main + 364388
22 clang 0x00034597 main + 171607
23 clang 0x0003889e main + 188766
24 clang 0x00003ffc _mh_execute_header + 12284
25 clang 0x0000b3fe main + 3262
26 clang 0x00002536 _mh_execute_header + 5430
Stack dump:
0. Program arguments: /Users/thakis/src/llvm/Release/bin/clang -cc1 -triple
i386-apple-darwin9.0.0 -emit-obj -mrelax-all -disable-free -main-file-name
crash.mm -pic-level 1 -mdisable-fp-elim -masm-verbose -target-cpu yonah -v
-resource-dir /Users/thakis/src/llvm/Release/lib/clang/2.0 -ferror-limit 19
-fmessage-length 127 -fexceptions -fdiagnostics-show-option -fcolor-diagnostics
-o crash.o -x objective-c++ crash.mm
1. crash.mm:3:6: current parser token ';'
2. crash.mm:1:23: parsing struct/union/class body 'A'
clang: error: clang frontend command failed due to signal 6 (use -v to see
invocation)
--
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 llvm.org Fri Jun 11 06:45:24 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Jun 2010 06:45:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7356] New: Internal error in jump threading
Message-ID: (Preds[i]->getTerminator()) && "Cannot split an edge from
an IndirectBrInst"' failed.
0 clang 0x08f6a0d7
Stack dump:
0. Program arguments: /home/misty/gcc/bin/clang -cc1 -triple
i386-pc-linux-gnu -S -disable-free -main-file-name io.i -mrelocation-model
static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4
-resource-dir /home/misty/gcc/lib/clang/2.0 -O2 -ferror-limit 19
-fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics
-o /tmp/cc-ZH6ozG.s -x cpp-output io.i
1. parser at end of file
2. Per-module optimization passes
3. Running pass 'CallGraph Pass Manager' on module 'io.i'.
4. Running pass 'Jump Threading' on function '@___H__20___io'
clang: error: clang frontend command failed due to signal 6 (use -v to see
invocation)
--
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 llvm.org Fri Jun 11 11:14:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Jun 2010 11:14:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7357] New: simplify-libcalls produces declarations
without a calling convention
Message-ID:
#ifndef static_assert
#define static_assert(a) switch ((int)(a)) case 0: case ((int)(a)):
#endif /* static_assert */
int main() {
static_assert(sizeof(int) == sizeof(unsigned int));
return 0;
}
[greearb at grok2 ~]$ clang++ -Os clang_test2.cc
clang_test2.cc:10:4: warning: switch condition has boolean value
static_assert(sizeof(int) == sizeof(unsigned int));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
clang_test2.cc:5:26: note: instantiated from:
#define static_assert(a) switch ((int)(a)) case 0: case ((int)(a)):
^ ~~~~~~~~
1 warning generated.
[greearb at grok2 ~]$
// This is a work-around:
//#define static_assert(a) switch ((a) + 0) case 0: case ((a) + 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 llvm.org Fri Jun 11 15:07:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Jun 2010 15:07:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7324] thumb2 mode doesn't use uxtb/uxth where
expected
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #2 from Evan Cheng 2010-06-11 15:07:41 CDT ---
This should be considered as correct. Looks like these instructions are not
available on all Thumb2 variants so you either need to specify the attribute
t2xtpk or a cpu to get these.
--
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 llvm.org Fri Jun 11 15:18:57 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Jun 2010 15:18:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7324] thumb2 mode doesn't use uxtb/uxth where
expected
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
--- Comment #3 from Brian G. Lucas 2010-06-11 15:18:57 CDT ---
I respectfully disagree. There are CPUs, e.g. the cortex-m3, that implement
SXTB, SXTH, UXTB, UXTH but *not* SXTB16, UXTB16, SXTAB, UXTAB,SXTAH, UXTAH,
SXTAB16, UXTAB16. Currently, there is but one predicate, HasT2ExtractPack,
that enables *all* of them. So if there are T2 variants that don't have SXTB,
SXTH, UXTB, UXTH, then we need another predicate to enable them and turn it on
for the cortex-m3.
In fact the cortex-Mx series will eventually require several more predicates.
Right now the cortex-m3 support is just wrong.
--
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 llvm.org Fri Jun 11 19:18:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Jun 2010 19:18:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7361] New: Top-level macros are not being analyzed
Message-ID: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |rjmccall at apple.com
Resolution| |FIXED
--- Comment #2 from John McCall 2010-06-11 20:56:19 CDT ---
Fixed in r105871.
--
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 llvm.org Fri Jun 11 21:53:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Jun 2010 21:53:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5678] [extension] variable length arrays are not
permitted in C++ in GNU mode.
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #10 from Yuri 2010-06-11 21:53:36 CDT ---
No, its not completely solved, with r105825 I see the errors with non-POD
types:
--- testcase ---
struct C {
C() {
}
};
int cnt();
void f() {
const int num = cnt();
struct MyRec {
C cc;
} c[num];
}
--- output ---
ex.C:12:6: error: variable length array of non-POD element type 'struct MyRec'
} c[num];
^
1 error 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 llvm.org Sat Jun 12 09:34:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 12 Jun 2010 09:34:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7362] New: A function with computed goto is
compiled slowly and produces a large object file
Message-ID: parser at end of file"
Message-ID: parser at
end of file"
Product: clang
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
AssignedTo: kremenek at apple.com
ReportedBy: dimhen at gmail.com
CC: llvmbugs at cs.uiuc.edu
[root at wellesberg clang_errs]# clang --version
clang version 2.0 (trunk 105882)
Target: i386-pc-linux-gnu
Thread model: posix
[root at wellesberg clang_errs]# cat eof.c
#include
void foo()
{
}
[root at wellesberg clang_errs]# scan-build gcc -c eof.c
scan-build: 'clang' executable not found in
'/usr/src/llvm/tools/clang/tools/scan-build/bin'.
scan-build: Using 'clang' from path: /usr/src/llvm/Release/bin/clang
clang: RegionStore.cpp:1373:
clang::SVal::RegionStoreManager::RetrieveArray(const void*, const
clang::TypedRegion*): Assertion
`isa(R->getValueType(getContext()))' failed.
0 clang 0x08e067f8
Stack dump:
0. Program arguments: /usr/src/llvm/Release/bin/clang -cc1
-DIBOutlet=__attribute__((iboutlet)) -cc1 -triple i386-pc-linux-gnu
-fsyntax-only -disable-free -main-file-name eof.c -mrelocation-model static
-mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -resource-dir
/usr/src/llvm/Release/lib/clang/2.0 -ferror-limit 19 -fmessage-length 0
-fgnu-runtime -fdiagnostics-show-option -x c eof.c -analyze
-analyzer-display-progress -analyzer-eagerly-assume
-analyzer-opt-analyze-nested-blocks -analyzer-check-objc-mem
-analyzer-check-security-syntactic -analyzer-check-dead-stores
-analyzer-check-objc-unused-ivars -analyzer-check-objc-methodsigs
-analyzer-store=region -analyzer-constraints=range -analyzer-output=html -o
/tmp/scan-build-2010-06-12-1
1. parser at end of file
scan-build: 0 bugs found.
scan-build: The analyzer encountered problems on some source files.
scan-build: Preprocessed versions of these sources were deposited in
'/tmp/scan-build-2010-06-12-1/failures'.
scan-build: Please consider submitting a bug report using these files:
scan-build: http://clang.llvm.org/StaticAnalysisUsage.html#filingbugs
--
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 llvm.org Sat Jun 12 10:47:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 12 Jun 2010 10:47:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5678] [extension] variable length arrays are not
permitted in C++ in GNU mode.
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #11 from Chris Lattner 2010-06-12 10:47:41 CDT ---
We do not intend to support non-pod types.
--
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 llvm.org Sat Jun 12 11:02:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 12 Jun 2010 11:02:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7345] clang.llvm.org cannot be navigated with a
small window
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #2 from Chris Lattner 2010-06-12 11:02:45 CDT ---
Yeah, I think something more like lldb.llvm.org might be the right answer.
*** This bug has been marked as a duplicate of bug 4012 ***
--
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 llvm.org Sat Jun 12 11:23:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 12 Jun 2010 11:23:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7349] -P flag strips all whitespace from
preprocessed output
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #2 from Chris Lattner 2010-06-12 11:23:46 CDT ---
Gross, but fixed :)
*** This bug has been marked as a duplicate of bug 7360 ***
--
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 llvm.org Sat Jun 12 15:33:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 12 Jun 2010 15:33:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7364] New: #pragma pack(1) needs to be supported
Message-ID: [#uses=2]
%2 = alloca i32, align 4 ; [#uses=1]
%3 = alloca i8**, align 4 ; [#uses=1]
store i32 0, i32* %1
store i32 %argc, i32* %2
call void @llvm.dbg.declare(metadata !{i32* %2}, metadata !0), !dbg !6
store i8** %argv, i8*** %3
call void @llvm.dbg.declare(metadata !{i8*** %3}, metadata !7), !dbg !11
br label %4, !dbg !12
; :4 ; preds = %4, %0
br label %4, !dbg !12
; No predecessors!
%6 = load i32* %1, !dbg !14 ; [#uses=1]
ret i32 %6, !dbg !14
}
declare void @llvm.dbg.declare(metadata, metadata) nounwind readnone
!0 = metadata !{i32 459009, metadata !1, metadata !"argc", metadata !2, i32 1,
metadata !5} ; [ DW_TAG_arg_variable ]
!1 = metadata !{i32 458798, i32 0, metadata !2, metadata !"main", metadata
!"main", metadata !"main", metadata !2, i32 2, metadata !3, i1 false, i1 true,
i32 0, i32 0, null, i1 false} ; [ DW_TAG_subprogram ]
!2 = metadata !{i32 458769, i32 0, i32 12, metadata !"test.c", metadata
!"/home/lb/pers/src/misc", metadata !"clang 1.1", i1 true, i1 false, metadata
!"", i32 0} ; [ DW_TAG_compile_unit ]
!3 = metadata !{i32 458773, metadata !2, metadata !"", null, i32 0, i64 0, i64
0, i64 0, i32 0, null, metadata !4, i32 0, null} ; [ DW_TAG_subroutine_type ]
!4 = metadata !{metadata !5}
!5 = metadata !{i32 458788, metadata !2, metadata !"int", metadata !2, i32 0,
i64 32, i64 32, i64 0, i32 0, i32 5} ; [ DW_TAG_base_type ]
!6 = metadata !{i32 1, i32 14, metadata !1, null}
!7 = metadata !{i32 459009, metadata !1, metadata !"argv", metadata !2, i32 1,
metadata !8} ; [ DW_TAG_arg_variable ]
!8 = metadata !{i32 458767, metadata !2, metadata !"", null, i32 0, i64 32, i64
32, i64 0, i32 0, metadata !9} ; [ DW_TAG_pointer_type ]
!9 = metadata !{i32 458767, metadata !2, metadata !"", null, i32 0, i64 32, i64
32, i64 0, i32 0, metadata !10} ; [ DW_TAG_pointer_type ]
!10 = metadata !{i32 458788, metadata !2, metadata !"char", metadata !2, i32 0,
i64 8, i64 8, i64 0, i32 0, i32 6} ; [ DW_TAG_base_type ]
!11 = metadata !{i32 1, i32 27, metadata !1, null}
!12 = metadata !{i32 3, i32 2, metadata !13, null}
!13 = metadata !{i32 458763, metadata !1, i32 2, i32 1} ; [
DW_TAG_lexical_block ]
!14 = metadata !{i32 5, i32 1, metadata !1, null}
$ clang -S -g -O0 test.c && cat test.s
.file "test.c"
.section .debug_frame,"", at progbits
.Lsection_debug_frame:
.section .debug_info,"", at progbits
.Lsection_info:
.section .debug_abbrev,"", at progbits
.Lsection_abbrev:
.section .debug_aranges,"", at progbits
.Lsection_aranges:
.section .debug_macinfo,"", at progbits
.Lsection_macinfo:
.section .debug_line,"", at progbits
.Lsection_line:
.section .debug_loc,"", at progbits
.Lsection_loc:
.section .debug_pubnames,"", at progbits
.Lsection_pubnames:
.section .debug_pubtypes,"", at progbits
.Lsection_pubtypes:
.section .debug_str,"", at progbits
.Lsection_str:
.section .debug_ranges,"", at progbits
.Lsection_ranges:
.text
.Ltext_begin:
.data
.Ldata_begin:
.text
.globl main
.align 16, 0x90
.type main, at function
main:
pushl %ebp
.Llabel1:
movl %esp, %ebp
.Llabel2:
subl $12, %esp
.Llabel3:
movl 8(%ebp), %eax
movl 12(%ebp), %ecx
movl $0, -4(%ebp)
movl %eax, -8(%ebp)
movl %ecx, -12(%ebp)
.LBB1_1:
jmp .LBB1_1
.size main, .-main
.Ltext_end:
.data
.Ldata_end:
.text
.Lsection_end1:
.section .debug_frame,"", at progbits
.Ldebug_frame_common:
.set .Lset1dbg,.Ldebug_frame_common_end-.Ldebug_frame_common_begin
.long .Lset1dbg
.Ldebug_frame_common_begin:
.long 4294967295
.byte 1
.byte 0
.uleb128 1
.sleb128 -4
.byte 8
.byte 12
.uleb128 4
.uleb128 4
.byte 136
.uleb128 1
.align 4
.Ldebug_frame_common_end:
.section .debug_info,"", at progbits
.Linfo_begin1:
.long 83
.short 2
.set .Lset2dbg,.Labbrev_begin
.long .Lset2dbg
.byte 4
.uleb128 1
.set .Lset3dbg,.Lsection_line
.long .Lset3dbg
.ascii "clang 1.1"
.byte 0
.byte 12
.ascii "test.c"
.byte 0
.ascii "/home/lb/pers/src/misc"
.byte 0
.uleb128 2
.byte 5
.ascii "int"
.byte 0
.byte 4
.uleb128 3
.ascii "main"
.byte 0
.ascii "main"
.byte 0
.byte 1
.byte 2
.byte 1
.long 57
.byte 0
.byte 0
.byte 0
.byte 0
.byte 0
.Linfo_end1:
.section .debug_abbrev,"", at progbits
.Labbrev_begin:
.uleb128 1
.uleb128 17
.uleb128 1
.uleb128 16
.uleb128 6
.uleb128 37
.uleb128 8
.uleb128 19
.uleb128 11
.uleb128 3
.uleb128 8
.uleb128 27
.uleb128 8
.uleb128 0
.uleb128 0
.uleb128 2
.uleb128 36
.uleb128 0
.uleb128 62
.uleb128 11
.uleb128 3
.uleb128 8
.uleb128 11
.uleb128 11
.uleb128 0
.uleb128 0
.uleb128 3
.uleb128 46
.uleb128 0
.uleb128 3
.uleb128 8
.uleb128 8199
.uleb128 8
.uleb128 58
.uleb128 11
.uleb128 59
.uleb128 11
.uleb128 39
.uleb128 12
.uleb128 73
.uleb128 19
.uleb128 0
.uleb128 0
.uleb128 0
.Labbrev_end:
.section .debug_line,"", at progbits
.set .Lset4dbg,.Lline_end-.Lline_begin
.long .Lset4dbg
.Lline_begin:
.short 2
.set .Lset5dbg,.Lline_prolog_end-.Lline_prolog_begin
.long .Lset5dbg
.Lline_prolog_begin:
.byte 1
.byte 1
.byte 246
.byte 245
.byte 10
.byte 0
.byte 1
.byte 1
.byte 1
.byte 1
.byte 0
.byte 0
.byte 0
.byte 1
.asciz "/home/lb/pers/src/misc"
.byte 0
.asciz "test.c"
.uleb128 1
.uleb128 0
.uleb128 0
.byte 0
.Lline_prolog_end:
.byte 0
.byte 5
.byte 2
.long .Lsection_end1
.byte 0
.byte 1
.byte 1
.Lline_end:
.section .debug_pubnames,"", at progbits
.set .Lset6dbg,.Lpubnames_end1-.Lpubnames_begin1
.long .Lset6dbg
.Lpubnames_begin1:
.short 2
.set .Lset7dbg,.Linfo_begin1
.long .Lset7dbg
.set .Lset8dbg,.Linfo_end1-.Linfo_begin1
.long .Lset8dbg
.long 64
.asciz "main"
.long 0
.Lpubnames_end1:
.section .debug_pubtypes,"", at progbits
.set .Lset9dbg,.Lpubtypes_end1-.Lpubtypes_begin1
.long .Lset9dbg
.Lpubtypes_begin1:
.short 2
.set .Lset10dbg,.Linfo_begin1
.long .Lset10dbg
.set .Lset11dbg,.Linfo_end1-.Linfo_begin1
.long .Lset11dbg
.long 0
.Lpubtypes_end1:
.section .debug_loc,"", at progbits
.section .debug_aranges,"", at progbits
.section .debug_ranges,"", at progbits
.section .debug_macinfo,"", at progbits
.section .note.GNU-stack,"", at progbits
$ readelf --debug-dump a.out
Contents of the .debug_pubnames section:
Length: 23
Version: 2
Offset into .debug_info section: 0x0
Size of area in .debug_info section: 87
Offset Name
40 main
Contents of the .debug_info section:
Compilation Unit @ offset 0x0:
Length: 0x53 (32-bit)
Version: 2
Abbrev Offset: 0
Pointer Size: 4
<0>: Abbrev Number: 1 (DW_TAG_compile_unit)
< c> DW_AT_stmt_list : 0x0
<10> DW_AT_producer : clang 1.1
<1a> DW_AT_language : 12 (ANSI C99)
<1b> DW_AT_name : test.c
<22> DW_AT_comp_dir : /home/lb/pers/src/misc
<1><39>: Abbrev Number: 2 (DW_TAG_base_type)
<3a> DW_AT_encoding : 5 (signed)
<3b> DW_AT_name : int
<3f> DW_AT_byte_size : 4
<1><40>: Abbrev Number: 3 (DW_TAG_subprogram)
<41> DW_AT_name : main
<46> DW_AT_MIPS_linkage_name: main
<4b> DW_AT_decl_file : 1
<4c> DW_AT_decl_line : 2
<4d> DW_AT_prototyped : 1
<4e> DW_AT_type : <0x39>
Contents of the .debug_abbrev section:
Number TAG
1 DW_TAG_compile_unit [has children]
DW_AT_stmt_list DW_FORM_data4
DW_AT_producer DW_FORM_string
DW_AT_language DW_FORM_data1
DW_AT_name DW_FORM_string
DW_AT_comp_dir DW_FORM_string
2 DW_TAG_base_type [no children]
DW_AT_encoding DW_FORM_data1
DW_AT_name DW_FORM_string
DW_AT_byte_size DW_FORM_data1
3 DW_TAG_subprogram [no children]
DW_AT_name DW_FORM_string
DW_AT_MIPS_linkage_name DW_FORM_string
DW_AT_decl_file DW_FORM_data1
DW_AT_decl_line DW_FORM_data1
DW_AT_prototyped DW_FORM_flag
DW_AT_type DW_FORM_ref4
Raw dump of debug contents of section .debug_line:
Offset: 0x0
Length: 65
DWARF Version: 2
Prologue Length: 49
Minimum Instruction Length: 1
Initial value of 'is_stmt': 1
Line Base: -10
Line Range: 245
Opcode Base: 10
Opcodes:
Opcode 1 has 0 args
Opcode 2 has 1 args
Opcode 3 has 1 args
Opcode 4 has 1 args
Opcode 5 has 1 args
Opcode 6 has 0 args
Opcode 7 has 0 args
Opcode 8 has 0 args
Opcode 9 has 1 args
The Directory Table:
/home/lb/pers/src/misc
The File Name Table:
Entry Dir Time Size Name
1 1 0 0 test.c
Line Number Statements:
Extended opcode 2: set Address to 0x80483db
Extended opcode 1: End of Sequence
Offset: 0x45
Length: 68
DWARF Version: 2
Prologue Length: 39
Minimum Instruction Length: 1
Initial value of 'is_stmt': 1
Line Base: -5
Line Range: 14
Opcode Base: 13
Opcodes:
Opcode 1 has 0 args
Opcode 2 has 1 args
Opcode 3 has 1 args
Opcode 4 has 1 args
Opcode 5 has 1 args
Opcode 6 has 0 args
Opcode 7 has 0 args
Opcode 8 has 0 args
Opcode 9 has 1 args
Opcode 10 has 0 args
Opcode 11 has 0 args
Opcode 12 has 1 args
The Directory Table:
/tmp
The File Name Table:
Entry Dir Time Size Name
1 1 0 0 cc-g9lJBF.s
Line Number Statements:
Extended opcode 2: set Address to 0x80483c0
Advance Line by 32 to 33
Copy
Special opcode 21: advance Address by 1 to 0x80483c1 and Line by 2 to 35
Special opcode 35: advance Address by 2 to 0x80483c3 and Line by 2 to 37
Special opcode 49: advance Address by 3 to 0x80483c6 and Line by 2 to 39
Special opcode 48: advance Address by 3 to 0x80483c9 and Line by 1 to 40
Special opcode 48: advance Address by 3 to 0x80483cc and Line by 1 to 41
Special opcode 104: advance Address by 7 to 0x80483d3 and Line by 1 to 42
Special opcode 48: advance Address by 3 to 0x80483d6 and Line by 1 to 43
Special opcode 49: advance Address by 3 to 0x80483d9 and Line by 2 to 45
Advance PC by 2 to 0x80483db
Extended opcode 1: End of Sequence
Contents of the .debug_frame section:
00000000 00000010 ffffffff CIE
Version: 1
Augmentation: ""
Code alignment factor: 1
Data alignment factor: -4
Return address column: 8
DW_CFA_def_cfa: r4 (esp) ofs 4
DW_CFA_offset: r8 (eip) at cfa-4
DW_CFA_nop
DW_CFA_nop
Contents of the .debug_pubtypes section:
Length: 14
Version: 2
Offset into .debug_info section: 0x0
Size of area in .debug_info section: 87
Offset Name
--
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 llvm.org Sat Jun 12 19:34:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 12 Jun 2010 19:34:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7366] New: Anything that includes stdio.h fails
Message-ID:
void blah() {}
scan-build -k gcc -c foo.c
See attached gdb.out
--
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 llvm.org Sat Jun 12 22:26:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 12 Jun 2010 22:26:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7367] New: Opt crash on attached .bc file
Message-ID: [ORD=1214]
[ID=38]
0x9b9d070: ch = store 0x9ba55f8:1, 0x9ad22c0, 0x9ba5790,
0x9bb49b8 [ORD=1214] [ID=37]
0x9ba55f8: i32,ch = load 0x9b7320c, 0x9bb4ce8, 0x9bb49b8
[ORD=1198] [ID=31]
0x9b7320c: ch = EntryToken [ORD=1193] [ID=0]
0x9bb4ce8: i32 = add 0x9b9c768, 0x9b9cd40 [ORD=1196] [ID=28]
0x9b9c768: i32,ch = CopyFromReg 0x9b7320c, 0x9ad3008 [ORD=1195] [ID=21]
0x9b7320c: ch = EntryToken [ORD=1193] [ID=0]
0x9ad3008: i32 = Register %reg1024 [ORD=1195] [ID=4]
0x9b9cd40: i32 = Constant<5124> [ORD=1196] [ID=5]
0x9bb49b8: i32 = undef [ORD=1198] [ID=6]
0x9ad22c0: i32 = add 0x9ad2d60, 0x9bb5238 [ORD=1200] [ID=36]
0x9ad2d60: i32,ch = CopyFromReg 0x9b7320c, 0x9bb55f0 [ORD=1200] [ID=22]
0x9b7320c: ch = EntryToken [ORD=1193] [ID=0]
0x9bb55f0: i32 = Register %reg1126 [ORD=1200] [ID=7]
0x9bb5238: i32 = mul 0x9ba55f8, 0x9bb5458 [ORD=1199] [ID=34]
0x9ba55f8: i32,ch = load 0x9b7320c, 0x9bb4ce8,
0x9bb49b8 [ORD=1198] [ID=31]
0x9b7320c: ch = EntryToken [ORD=1193] [ID=0]
0x9bb4ce8: i32 = add 0x9b9c768, 0x9b9cd40 [ORD=1196] [ID=28]
0x9b9c768: i32,ch = CopyFromReg 0x9b7320c, 0x9ad3008 [ORD=1195]
[ID=21]
0x9b7320c: ch = EntryToken [ORD=1193] [ID=0]
0x9ad3008: i32 = Register %reg1024 [ORD=1195] [ID=4]
0x9b9cd40: i32 = Constant<5124> [ORD=1196] [ID=5]
0x9bb49b8: i32 = undef [ORD=1198] [ID=6]
0x9bb5458: i32 = and 0x9ad2f80, 0x9ad2ab8 [ORD=1194] [ID=25]
0x9ad2f80: i32,ch = CopyFromReg 0x9b7320c, 0x9b9d290 [ORD=1194]
[ID=20]
0x9b7320c: ch = EntryToken [ORD=1193] [ID=0]
0x9b9d290: i32 = Register %reg1130 [ORD=1194] [ID=2]
0x9ad2ab8: i32 = Constant<255> [ORD=1194] [ID=3]
0x9ba5790: i32 = add 0x9ba4f10, 0x9ad2b40 [ORD=1206] [ID=35]
0x9ba4f10: i32 = add 0x9b9ca10, 0x9ad2678 [ORD=1204] [ID=33]
0x9b9ca10: i32,ch = CopyFromReg 0x9b7320c, 0x9bb4f90 [ORD=1193] [ID=19]
0x9b7320c: ch = EntryToken [ORD=1193] [ID=0]
0x9bb4f90: i32 = Register %reg1104 [ORD=1193] [ID=1]
0x9ad2678: i32 = shl 0x9bb5458, 0x9b9c6e0 [ID=29]
0x9bb5458: i32 = and 0x9ad2f80, 0x9ad2ab8 [ORD=1194] [ID=25]
0x9ad2f80: i32,ch = CopyFromReg 0x9b7320c, 0x9b9d290 [ORD=1194]
[ID=20]
0x9b7320c: ch = EntryToken [ORD=1193] [ID=0]
0x9b9d290: i32 = Register %reg1130 [ORD=1194] [ID=2]
0x9ad2ab8: i32 = Constant<255> [ORD=1194] [ID=3]
0x9b9c6e0: i8 = Constant<3> [ID=17]
0x9ad2b40: i32 = Constant<-4> [ORD=1206] [ID=8]
0x9bb49b8: i32 = undef [ORD=1198] [ID=6]
0x9ba53d8: i8,ch = CopyFromReg 0x9b7320c, 0x9ba58a0 [ORD=1214] [ID=23]
0x9b7320c: ch = EntryToken [ORD=1193] [ID=0]
0x9ba58a0: i8 = Register %reg1127 [ORD=1214] [ID=9]
0x9ba4f10: i32 = add 0x9b9ca10, 0x9ad2678 [ORD=1204] [ID=33]
0x9b9ca10: i32,ch = CopyFromReg 0x9b7320c, 0x9bb4f90 [ORD=1193] [ID=19]
0x9b7320c: ch = EntryToken [ORD=1193] [ID=0]
0x9bb4f90: i32 = Register %reg1104 [ORD=1193] [ID=1]
0x9ad2678: i32 = shl 0x9bb5458, 0x9b9c6e0 [ID=29]
0x9bb5458: i32 = and 0x9ad2f80, 0x9ad2ab8 [ORD=1194] [ID=25]
0x9ad2f80: i32,ch = CopyFromReg 0x9b7320c, 0x9b9d290 [ORD=1194] [ID=20]
0x9b7320c: ch = EntryToken [ORD=1193] [ID=0]
0x9b9d290: i32 = Register %reg1130 [ORD=1194] [ID=2]
0x9ad2ab8: i32 = Constant<255> [ORD=1194] [ID=3]
0x9b9c6e0: i8 = Constant<3> [ID=17]
0x9bb49b8: i32 = undef [ORD=1198] [ID=6]
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Sun Jun 13 07:20:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Jun 2010 07:20:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7272] Bad interaction between byval, -tailcallelim,
-inline and -dse
In-Reply-To: changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Duncan Sands 2010-06-13 07:20:12 CDT ---
This was fixed here, but the bugreport was not closed:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100531/102046.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 llvm.org Sun Jun 13 08:17:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Jun 2010 08:17:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7369] New: Miscompilation with -O1 and above
Message-ID:
40105d: 48 8b 85 50 ff ff ff mov -0xb0(%rbp),%rax
401064: 48 89 c1 mov %rax,%rcx
401067: 48 8b 0c cd 08 1c 40 mov 0x401c08(,%rcx,8),%rcx
0x401c08:
(gdb) print *(void*(*)[6]) 0x401c08
$1 = {0x401071, 0x40108c, 0x40108c, 0x4010d2, 0x4010e6, 0x4010f8}
401071: 30 c0 xor %al,%al
401073: b9 68 1d 40 00 mov $0x401d68,%ecx
401078: 48 89 cf mov %rcx,%rdi
40107b: e8 40 f9 ff ff callq 4009c0
401080: b8 01 00 00 00 mov $0x1,%eax
401085: 89 c7 mov %eax,%edi
401087: e8 84 f9 ff ff callq 400a10
40108c: 8b 04 25 e8 30 60 00 mov 0x6030e8,%eax
401093: 83 c0 01 add $0x1,%eax
401096: 30 c9 xor %cl,%cl
401098: ba 30 1d 40 00 mov $0x401d30,%edx
40109d: 48 89 d7 mov %rdx,%rdi
4010a0: 89 c6 mov %eax,%esi
4010a2: 88 c8 mov %cl,%al
4010a4: e8 17 f9 ff ff callq 4009c0
4010a9: b8 00 00 00 00 mov $0x0,%eax
4010ae: 89 c7 mov %eax,%edi
4010b0: e8 bb fd ff ff callq 400e70
4010b5: 30 c9 xor %cl,%cl
4010b7: ba 50 1d 40 00 mov $0x401d50,%edx
4010bc: 48 89 d7 mov %rdx,%rdi
4010bf: 88 c8 mov %cl,%al
4010c1: e8 fa f8 ff ff callq 4009c0
4010c6: b8 01 00 00 00 mov $0x1,%eax
4010cb: 89 c7 mov %eax,%edi
4010cd: e8 3e f9 ff ff callq 400a10
4010d2: 48 8b 04 25 20 31 60 mov 0x603120,%rax
4010d9: 00
4010da: c7 80 78 06 00 00 2a movl $0x2a,0x678(%rax)
4010e1: 00 00 00
4010e4: eb 19 jmp 4010ff
4010e6: 48 b8 00 00 00 00 00 mov $0x0,%rax
4010ed: 00 00 00
4010f0: c7 00 2a 00 00 00 movl $0x2a,(%rax)
4010f6: eb 07 jmp 4010ff
4010f8: eb 05 jmp 4010ff
4010fa: e8 e1 f8 ff ff callq 4009e0
===============================================================================
All right.
With -O1, the code looks like this:
===============================================================================
400ee5: e8 5e fb ff ff callq 400a48 <_setjmp at plt>
400eea: ff c0 inc %eax
400eec: 83 f8 05 cmp $0x5,%eax
400eef: 77 78 ja 400f69
400ef1: ff 24 c5 08 1a 40 00 jmpq *0x401a08(,%rax,8)
(gdb) print *(void*(*)[6]) 0x401a08
$1 = {0x400ef8, 0x400f0c, 0x400f0c, 0x400f3b, 0x400f69, 0x400f4c}
400ef8: bf 15 1c 40 00 mov $0x401c15,%edi
400efd: e8 36 fb ff ff callq 400a38
400f02: bf 01 00 00 00 mov $0x1,%edi
400f07: e8 4c fb ff ff callq 400a58