From bugzilla-daemon at cs.uiuc.edu Sun Mar 1 03:16:15 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 1 Mar 2009 03:16:15 -0600
Subject: [LLVMbugs] [Bug 3693] New: Assertion failed: (ATI !=
AbstractTypeMap.end() && " Abstract type not in AbstractTypeMap?"),
function MoveConstantToNewSlot, file Constants.cpp, line 1196.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3693
Summary: Assertion failed: (ATI != AbstractTypeMap.end() &&
"Abstract type not in AbstractTypeMap?"), function
MoveConstantToNewSlot, file Constants.cpp, line 1196.
Product: tools
Version: trunk
Platform: PC
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: llvm-ld
AssignedTo: unassignedbugs at nondot.org
ReportedBy: rdivacky at freebsd.org
CC: llvmbugs at cs.uiuc.edu
I am hitting this assert when trying to llvm-ld FreeBSD kernel. this is the
backtrace. I can upload tar of all the .bc files if needed. this is on i386
(gdb) bt
#0 0x288343db in kill () from /lib/libc.so.7
#1 0x2860d2d7 in raise () from /lib/libthr.so.3
#2 0x288321ec in abort () from /lib/libc.so.7
#3 0x28819106 in __assert () from /lib/libc.so.7
#4 0x084938c5 in llvm::ValueMap >, llvm::StructType, llvm::ConstantStruct,
true>::MoveConstantToNewSlot (this=0x28bfbce0, C=0x2d8506b4, I={_M_node =
0x2d3d0c70}) at Constants.cpp:1195
#5 0x08480aa9 in llvm::ConstantStruct::replaceUsesOfWithOnConstant
(this=0x2d8506b4, From=0x2af04e20, To=0x2bdfe400, U=0x2d85066c)
at Constants.cpp:2581
#6 0x08510e19 in llvm::Value::uncheckedReplaceAllUsesWith (this=0x2af04e20,
New=0x2bdfe400) at Value.cpp:306
#7 0x08496114 in llvm::ConvertConstantType::convert (OldC=0x2af04e20, NewTy=0x2d8eb7f0)
at Constants.cpp:1575
#8 0x084961f1 in llvm::ValueMap::refineAbstractType (this=0x28922880,
OldTy=0x2d7665b0,
NewTy=0x2d8eb7f0) at Constants.cpp:1223
#9 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d7665b0,
NewType=0x2d8eb7f0) at Type.cpp:1421
#10 0x0850bd38 in llvm::TypeMap::RefineAbstractType (this=0x28908460, Ty=0x2d7665b0,
OldType=0x2d7b1540,
NewType=0x2d8c0300) at Type.cpp:916
#11 0x084f9a6f in llvm::PointerType::refineAbstractType (this=0x2d7665b0,
OldType=0x2d7b1540, NewType=0x2d8c0300) at Type.cpp:1510
#12 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d7b1540,
NewType=0x2d8c0300) at Type.cpp:1421
#13 0x0850d59b in llvm::TypeMap::RefineAbstractType (this=0x28908d60, Ty=0x2d7b1540,
OldType=0x2d6df430,
NewType=0x2d89f070) at Type.cpp:916
#14 0x084f9baf in llvm::FunctionType::refineAbstractType (this=0x2d7b1540,
OldType=0x2d6df430, NewType=0x2d89f070) at Type.cpp:1457
#15 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d6df430,
NewType=0x2d89f070) at Type.cpp:1421
#16 0x0850bd38 in llvm::TypeMap::RefineAbstractType (this=0x28908460, Ty=0x2d6df430,
OldType=0x2d318880,
NewType=0x2d7a0940) at Type.cpp:916
#17 0x084f9a6f in llvm::PointerType::refineAbstractType (this=0x2d6df430,
OldType=0x2d318880, NewType=0x2d7a0940) at Type.cpp:1510
#18 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d318880,
NewType=0x2d7a0940) at Type.cpp:1421
#19 0x0850c56f in llvm::TypeMap::RefineAbstractType (this=0x28908be0, Ty=0x2d318880,
OldType=0x2d7e8ca0,
NewType=0x2d89f0d0) at Type.cpp:952
#20 0x084f9abf in llvm::StructType::refineAbstractType (this=0x2d318880,
OldType=0x2d7e8ca0, NewType=0x2d89f0d0) at Type.cpp:1497
#21 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d7e8ca0,
NewType=0x2d89f0d0) at Type.cpp:1421
#22 0x0850bd38 in llvm::TypeMap::RefineAbstractType (this=0x28908460, Ty=0x2d7e8ca0,
OldType=0x2d862a80,
NewType=0x2d863ec0) at Type.cpp:916
#23 0x084f9a6f in llvm::PointerType::refineAbstractType (this=0x2d7e8ca0,
OldType=0x2d862a80, NewType=0x2d863ec0) at Type.cpp:1510
#24 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d862a80,
NewType=0x2d863ec0) at Type.cpp:1421
#25 0x0850c56f in llvm::TypeMap::RefineAbstractType (this=0x28908be0, Ty=0x2d862a80,
OldType=0x2d884b80,
NewType=0x2d8eb790) at Type.cpp:952
#26 0x084f9abf in llvm::StructType::refineAbstractType (this=0x2d862a80,
OldType=0x2d884b80, NewType=0x2d8eb790) at Type.cpp:1497
#27 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d884b80,
NewType=0x2d8eb790) at Type.cpp:1421
#28 0x0850bd38 in llvm::TypeMap::RefineAbstractType (this=0x28908460, Ty=0x2d884b80,
OldType=0x2d850100,
NewType=0x2d850f00) at Type.cpp:916
#29 0x084f9a6f in llvm::PointerType::refineAbstractType (this=0x2d884b80,
OldType=0x2d850100, NewType=0x2d850f00) at Type.cpp:1510
#30 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d850100,
NewType=0x2d850f00) at Type.cpp:1421
#31 0x0850c56f in llvm::TypeMap::RefineAbstractType (this=0x28908be0, Ty=0x2d850100,
OldType=0x2d884970,
NewType=0x2d8eb730) at Type.cpp:952
---Type to continue, or q to quit---
#32 0x084f9abf in llvm::StructType::refineAbstractType (this=0x2d850100,
OldType=0x2d884970, NewType=0x2d8eb730) at Type.cpp:1497
#33 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d884970,
NewType=0x2d8eb730) at Type.cpp:1421
#34 0x0850bd38 in llvm::TypeMap::RefineAbstractType (this=0x28908460, Ty=0x2d884970,
OldType=0x2d84c220,
NewType=0x2d881ee0) at Type.cpp:916
#35 0x084f9a6f in llvm::PointerType::refineAbstractType (this=0x2d884970,
OldType=0x2d84c220, NewType=0x2d881ee0) at Type.cpp:1510
#36 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d84c220,
NewType=0x2d881ee0) at Type.cpp:1421
#37 0x0850d7ae in llvm::TypeMap::RefineAbstractType (this=0x28908d60, Ty=0x2d84c220,
OldType=0x2d7b3c40,
NewType=0x2d88faf0) at Type.cpp:952
#38 0x084f9baf in llvm::FunctionType::refineAbstractType (this=0x2d84c220,
OldType=0x2d7b3c40, NewType=0x2d88faf0) at Type.cpp:1457
#39 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d7b3c40,
NewType=0x2d88faf0) at Type.cpp:1421
#40 0x0850bf45 in llvm::TypeMap::RefineAbstractType (this=0x28908460, Ty=0x2d7b3c40,
OldType=0x2d894400,
NewType=0x2d894e00) at Type.cpp:952
#41 0x084f9a6f in llvm::PointerType::refineAbstractType (this=0x2d7b3c40,
OldType=0x2d894400, NewType=0x2d894e00) at Type.cpp:1510
#42 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d894400,
NewType=0x2d894e00) at Type.cpp:1421
#43 0x0850c56f in llvm::TypeMap::RefineAbstractType (this=0x28908be0, Ty=0x2d894400,
OldType=0x2d8b0380,
NewType=0x2d8f6dc0) at Type.cpp:952
#44 0x084f9abf in llvm::StructType::refineAbstractType (this=0x2d894400,
OldType=0x2d8b0380, NewType=0x2d8f6dc0) at Type.cpp:1497
#45 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d8b0380,
NewType=0x2d8f6dc0) at Type.cpp:1421
#46 0x0850c56f in llvm::TypeMap::RefineAbstractType (this=0x28908be0, Ty=0x2d8b0380,
OldType=0x2d7bd100,
NewType=0x2d89f460) at Type.cpp:952
#47 0x084f9abf in llvm::StructType::refineAbstractType (this=0x2d8b0380,
OldType=0x2d7bd100, NewType=0x2d89f460) at Type.cpp:1497
#48 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d7bd100,
NewType=0x2d89f460) at Type.cpp:1421
#49 0x0850bf45 in llvm::TypeMap::RefineAbstractType (this=0x28908460, Ty=0x2d7bd100,
OldType=0x2d7b3d30,
NewType=0x2d89f1c0) at Type.cpp:952
#50 0x084f9a6f in llvm::PointerType::refineAbstractType (this=0x2d7bd100,
OldType=0x2d7b3d30, NewType=0x2d89f1c0) at Type.cpp:1510
#51 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d7b3d30,
NewType=0x2d89f1c0) at Type.cpp:1421
#52 0x0850bf45 in llvm::TypeMap::RefineAbstractType (this=0x28908460, Ty=0x2d7b3d30,
OldType=0x2d863680,
NewType=0x2d863f80) at Type.cpp:952
#53 0x084f9a6f in llvm::PointerType::refineAbstractType (this=0x2d7b3d30,
OldType=0x2d863680, NewType=0x2d863f80) at Type.cpp:1510
#54 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d863680,
NewType=0x2d863f80) at Type.cpp:1421
#55 0x0850c56f in llvm::TypeMap::RefineAbstractType (this=0x28908be0, Ty=0x2d863680,
OldType=0x2d8b05c0,
NewType=0x2d8cb340) at Type.cpp:952
#56 0x084f9abf in llvm::StructType::refineAbstractType (this=0x2d863680,
OldType=0x2d8b05c0, NewType=0x2d8cb340) at Type.cpp:1497
#57 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d8b05c0,
NewType=0x2d8cb340) at Type.cpp:1421
#58 0x0850c362 in llvm::TypeMap::RefineAbstractType (this=0x28908be0, Ty=0x2d8b05c0,
OldType=0x2d861d80,
NewType=0x2d8c29c0) at Type.cpp:916
#59 0x084f9abf in llvm::StructType::refineAbstractType (this=0x2d8b05c0,
OldType=0x2d861d80, NewType=0x2d8c29c0) at Type.cpp:1497
#60 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d861d80,
NewType=0x2d8c29c0) at Type.cpp:1421
#61 0x0850c362 in llvm::TypeMap::RefineAbstractType (this=0x28908be0, Ty=0x2d861d80,
OldType=0x2d890220,
NewType=0x2d8eb9d0) at Type.cpp:916
#62 0x084f9abf in llvm::StructType::refineAbstractType (this=0x2d861d80,
OldType=0x2d890220, NewType=0x2d8eb9d0) at Type.cpp:1497
#63 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d890220,
NewType=0x2d8eb9d0) at Type.cpp:1421
#64 0x0850bd38 in llvm::TypeMap::RefineAbstractType (this=0x28908460, Ty=0x2d890220,
OldType=0x2d88fdc0,
NewType=0x2d8e6760) at Type.cpp:916
---Type to continue, or q to quit---
#65 0x084f9a6f in llvm::PointerType::refineAbstractType (this=0x2d890220,
OldType=0x2d88fdc0, NewType=0x2d8e6760) at Type.cpp:1510
#66 0x084f998a in llvm::DerivedType::refineAbstractTypeTo (this=0x2d88fdc0,
NewType=0x2d8e6760) at Type.cpp:1421
#67 0x08299ca6 in ResolveTypes (DestTy=0x2d88fdc0, SrcTy=0x2d8e6760) at
LinkModules.cpp:62
#68 0x0829c4e3 in LinkTypes (Dest=0x28908310, Src=0x2af0c040, Err=0xbfbfbd24)
at LinkModules.cpp:284
#69 0x0829cbca in llvm::Linker::LinkModules (Dest=0x28908310, Src=0x2af0c040,
ErrorMsg=0xbfbfbd24) at LinkModules.cpp:1258
#70 0x0829735d in llvm::Linker::LinkInModule (this=0xbfbfbd10, Src=0x2af0c040,
ErrorMsg=0xbfbfbd24) at Linker.h:247
#71 0x082967d4 in llvm::Linker::LinkInFile (this=0xbfbfbd10, File=@0xbfbfbc00,
is_native=@0xbfbfbbf2) at LinkItems.cpp:199
#72 0x08296ee8 in llvm::Linker::LinkInItems (this=0xbfbfbd10,
Items=@0xbfbfbcdc, NativeItems=@0xbfbfbd04) at LinkItems.cpp:45
#73 0x0826bf1d in main (argc=727, argv=0xbfbfbe58, envp=0xbfbfc9b8) at
llvm-ld.cpp:546
(gdb)
--
Configure bugmail: http://llvm.org/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 Mar 1 04:46:16 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 1 Mar 2009 04:46:16 -0600
Subject: [LLVMbugs] [Bug 3690] Assertion failed: (StackTop == 0 && " Stack
should be empty after a call!"), function handleSpecialFP,
file X86FloatingPoint.cpp, line 952.
In-Reply-To:
Message-ID: <200903011046.n21AkGhk016340@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3690
Anton Korobeynikov changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |asl at math.spbu.ru
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #4 from Anton Korobeynikov 2009-03-01 04:46:11 ---
As far as I can understand Chris' position: this is effectively "wontfix" until
will happen in some apple-produced code. There are bunch of examples in
bugzilla, when such sort of assertions happen for non-darwin targets (e.g.
win64, linux, now - freebsd).
The only solution - is to alter sources not to use inline FP math even if this
causes serious performance regression (for example, during libm compilation,
when inline fp math seems to be the only sane way to support atan, etc).
*** 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 Sun Mar 1 10:24:37 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 1 Mar 2009 10:24:37 -0600
Subject: [LLVMbugs] [Bug 3694] New: missing instcombine for GEP 0, X, Y,
Z of bitcast of Ty* to [ 0 x Ty]*
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3694
Summary: missing instcombine for GEP 0,X,Y,Z of bitcast of Ty* to
[0 x Ty]*
Product: new-bugs
Version: unspecified
Platform: Other
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
test/FrontendC/2007-03-27-VarLengthArray.c now compiles to
define i32 @e(i32 %m, i32 %n) nounwind {
entry:
%0 = alloca i32, i32 %n, align 4 ; [#uses=2]
%1 = bitcast i32* %0 to [0 x i32]* ; <[0 x i32]*>
[#uses=1]
call void @f(i32* %0) nounwind
%2 = getelementptr [0 x i32]* %1, i32 0, i32 %m ;
[#uses=1]
%3 = load i32* %2, align 4 ; [#uses=1]
ret i32 %3
}
The bitcast could be eliminated by stripping the
first index off the GEP.
--
Configure bugmail: http://llvm.org/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 Mar 1 11:13:08 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 1 Mar 2009 11:13:08 -0600
Subject: [LLVMbugs] [Bug 3509] InitListExpr's getLocStart() incorrect
In-Reply-To:
Message-ID: <200903011713.n21HD8Zc029091@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3509
Douglas Gregor changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Douglas Gregor 2009-03-01 11:13:08 ---
This is fixed here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090223/013272.html
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sun Mar 1 12:20:23 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 1 Mar 2009 12:20:23 -0600
Subject: [LLVMbugs] [Bug 3695] New: llvm-gcc -S different from llvm-gcc
-emit-llvm | llc
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3695
Summary: llvm-gcc -S different from llvm-gcc -emit-llvm | llc
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: nicholas at mxc.ca
CC: llvmbugs at cs.uiuc.edu
I'm not sure what's causing this discrepancy. I have a tiny function:
# cat x.c
int foo(double x)
{
return (int)x;
}
which produces large amounts of x87 stack gunk when built with llvm-gcc:
# llvm-gcc -O2 x.c -S -o -
[...]
foo:
pushl %ebp
movl %esp, %ebp
subl $6, %esp
fldl 8(%ebp)
fnstcw -6(%ebp)
movw -6(%ebp), %ax
movw $3199, -6(%ebp)
fldcw -6(%ebp)
movw %ax, -6(%ebp)
fistpl -4(%ebp)
fldcw -6(%ebp)
movl -4(%ebp), %eax
addl $6, %esp
popl %ebp
ret
wait, using x87 stack? I configured llvm-gcc --host=i686-pc-linux-gnu
--build=i686-pc-linux-gnu. Surely it could do better than that.
# llvm-gcc -O2 x.c -c -o - -emit-llvm | llc -o -
[...]
foo:
cvttsd2si 4(%esp), %eax
ret
Much better. Why didn't llvm-gcc do that? What target triple is llvm-gcc
emitting anyways?
# llvm-gcc -O2 x.c -S -o - -emit-llvm
; ModuleID = 'x.c'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"
define i32 @foo(double %x) nounwind readnone {
entry:
%0 = fptosi double %x to i32 ; [#uses=1]
ret i32 %0
}
i386-pc-linux-gnu?! If you say so. Is llc ignoring the target triple? Or is
llvm-gcc setting something in the codegen that turns SSE support off? Let's try
that:
# llvm-gcc -O2 x.c -c -o - -emit-llvm | llc -o - -mattr=-sse
[...]
foo:
subl $6, %esp
fldl 10(%esp)
fnstcw (%esp)
movw (%esp), %ax
movw $3199, (%esp)
fldcw (%esp)
movw %ax, (%esp)
fistpl 2(%esp)
fldcw (%esp)
movl 2(%esp), %eax
addl $6, %esp
ret
Note that it's *not the same*. The code directly emitted by llvm-gcc showed
push/mov pair in the prologue, while this skips straight to the subl. What on
Earth is going on?
--
Configure bugmail: http://llvm.org/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 Mar 1 12:50:21 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 1 Mar 2009 12:50:21 -0600
Subject: [LLVMbugs] [Bug 3696] New: The FreeBSD source tree does not fully
compile with Clang
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3696
Summary: The FreeBSD source tree does not fully compile with
Clang
Product: clang
Version: unspecified
Platform: PC
URL: http://wiki.freebsd.org/BuildingFreeBSDWithClang
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: ed at 80386.nl
CC: llvmbugs at cs.uiuc.edu
Depends on: 3603,3671,3678,3679,3681,3682,3686,3687,3688,3690,3691
I'm creating this bug report, so we can keep track of all the reports that need
to be resolved before we can fully compile FreeBSD with Clang.
--
Configure bugmail: http://llvm.org/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 Mar 1 13:04:33 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 1 Mar 2009 13:04:33 -0600
Subject: [LLVMbugs] [Bug 3695] llvm-gcc -S different from llvm-gcc
-emit-llvm | llc
In-Reply-To:
Message-ID: <200903011904.n21J4XEX000816@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3695
Anton Korobeynikov changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |asl at math.spbu.ru
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Anton Korobeynikov 2009-03-01 13:04:33 ---
That's correct behaviour:
1. llc's defaults are different from the llvm-gcc (for example - frame pointer
elimination is by default on in llc, but not in llvm-gcc)
2. llc automatically detects CPU features, llvm-gcc by default-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 Sun Mar 1 18:20:28 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 1 Mar 2009 18:20:28 -0600
Subject: [LLVMbugs] [Bug 3672] Syntax error not rejected with
-pedantic-errors
In-Reply-To:
Message-ID: <200903020020.n220KSNB010783@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3672
Douglas Gregor changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Douglas Gregor 2009-03-01 18:20:27 ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090223/013292.html
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 Sun Mar 1 20:09:30 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 1 Mar 2009 20:09:30 -0600
Subject: [LLVMbugs] [Bug 3697] New: [PATCH] Updated header includes for GCC
4.4
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3697
Summary: [PATCH] Updated header includes for GCC 4.4
Product: clang
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Basic
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: salimma at fedoraproject.org
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=2633)
--> (http://llvm.org/bugs/attachment.cgi?id=2633)
gcc-4.4 patch for clang
GCC 4.4's g++ is now even stricter about header inclusion than GCC 4.4, and
clang does not currently compile out of the box. The attached patch includes
the necessary headers (cstdio, stdint.h) to get clang to compile.
Note: this really affects *all* of clang, I'm guessing the "Basic" component.
Should there be a "general" component?
--
Configure bugmail: http://llvm.org/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 Mar 2 03:59:27 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 03:59:27 -0600
Subject: [LLVMbugs] [Bug 3698] New: Clang ignores leading dot in symbol name
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3698
Summary: Clang ignores leading dot in symbol name
Product: clang
Version: unspecified
Platform: PC
URL: http://svn.freebsd.org/viewvc/base/head/lib/libc/gmon/gm
on.c?view=markup
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: ed at 80386.nl
CC: llvmbugs at cs.uiuc.edu
Blocks: 3696
When compiling the attached code with GCC, nm will show the following:
U .foo
0000000000000000 T main
If we compile the same code with LLVM, we get:
U foo
0000000000000000 T main
This causes FreeBSD's libc to load correctly. If libc is compiled with LLVM,
except gmon.c, libc seems to work properly.
--
Configure bugmail: http://llvm.org/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 Mar 2 06:39:48 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 06:39:48 -0600
Subject: [LLVMbugs] [Bug 3694] missing instcombine for GEP 0, X, Y,
Z of bitcast of Ty* to [0 x Ty ]*
In-Reply-To:
Message-ID: <200903021239.n22CdmwZ014603@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3694
Duncan Sands changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Duncan Sands 2009-03-02 06:39:33 ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090302/074464.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 Mar 2 07:15:22 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 07:15:22 -0600
Subject: [LLVMbugs] [Bug 3699] New: Clang test prefers FreeBSD's
/usr/include/mmintrin. h over LLVM's
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3699
Summary: Clang test prefers FreeBSD's /usr/include/mmintrin.h
over LLVM's
Product: clang
Version: unspecified
Platform: PC
URL: http://google1.osuosl.org:8011/builders/clang-x86_64-
freebsd/builds/3/steps/test-clang/logs/failure%20log
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Basic
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: ed at 80386.nl
CC: llvmbugs at cs.uiuc.edu
On FreeBSD, /usr/include/mmintrin.h is GNU's version of the header file. This
causes mmintrin-test.c to fail to compile.
--
Configure bugmail: http://llvm.org/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 Mar 2 07:17:34 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 07:17:34 -0600
Subject: [LLVMbugs] [Bug 3700] New: Test string-init.c fails if `store' is
in the path name.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3700
Summary: Test string-init.c fails if `store' is in the path name.
Product: clang
Version: unspecified
Platform: PC
URL: http://google1.osuosl.org:8011/builders/clang-x86_64-
freebsd/builds/3/steps/test-clang/logs/failure%20log
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: Basic
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: ed at 80386.nl
CC: llvmbugs at cs.uiuc.edu
The FreeBSD buildbot uses /store/home/buildbot/llvm to store the source code.
The string-init.c test fails, because it greps for `store', which always
matches a pathname in the 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 Mar 2 11:29:38 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 11:29:38 -0600
Subject: [LLVMbugs] [Bug 3695] llc ignores target triple subtarget
In-Reply-To:
Message-ID: <200903021729.n22HTcgE024750@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3695
Dan Gohman changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gohman at apple.com
Status|VERIFIED |REOPENED
OS/Version|Linux |All
Platform|PC |All
Resolution|INVALID |
Summary|llvm-gcc -S different from |llc ignores target triple
|llvm-gcc -emit-llvm | llc |subtarget
--- Comment #3 from Dan Gohman 2009-03-02 11:29:29 ---
Nick's observation about the target-triple seems valid.
Normally, target triple information in a module should
override auto-detected information. It seems that llc
is ignoring the hardware subtarget aspect of the target
triple.
--
Configure bugmail: http://llvm.org/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 Mar 2 12:43:19 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 12:43:19 -0600
Subject: [LLVMbugs] [Bug 3701] New: optimization bug at -O2
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3701
Summary: optimization bug at -O2
Product: clang
Version: unspecified
Platform: PC
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: rdivacky at freebsd.org
CC: llvmbugs at cs.uiuc.edu
hi.. when compiling the attached test case I am getting attached asm output.
here's a snippet of it:
if (pq->curr == xfer) {
/* we are currently scheduled for callback */
USB_BUS_UNLOCK(xfer->xroot->bus);
return (1);
}
/* we are not pending */
USB_BUS_UNLOCK(xfer->xroot->bus);
return (0);
(in the actual test case this is run through ccc -E so it's expanded)
this is translated to this asm via "ccc -O2 -S -ffreestanding usb.c" (note that
the -O2 is important) to this (snippet):
(1) cmpq %rbx, 56(%rax)
#APP
movl %fs:0,%rax
#NO_APP
movq 104(%rbx), %rcx
movq 296(%rcx), %rcx
movl $4, %edx
#APP
(2) lock ; cmpxchgl %edx,736(%rcx) ; sete %al ; 1:
# atomic_cmpset_int
note that the result of the cmpq at (1) is never used. and this cmpq
corresponds to the "if (pq->curr == xfer)" above. thus 1 is always returned.
--
Configure bugmail: http://llvm.org/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 Mar 2 13:25:28 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 13:25:28 -0600
Subject: [LLVMbugs] [Bug 3695] llc ignores target triple subtarget
In-Reply-To:
Message-ID: <200903021925.n22JPS87030232@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3695
Dan Gohman changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |INVALID
--- Comment #5 from Dan Gohman 2009-03-02 13:25:26 ---
Ok, thanks for clarifying. So pentium4-pc-linux-gnu is invalid, for example.
--
Configure bugmail: http://llvm.org/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 Mar 2 13:36:37 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 13:36:37 -0600
Subject: [LLVMbugs] [Bug 3702] New: Assertion failed: (isFile() && "Not a
file SLocEntry!"), function getFile,
file /usr/src-local/llvm/tools/clang/lib/Basic/../../
include/clang/Basic/SourceManager.h, line 237.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3702
Summary: Assertion failed: (isFile() && "Not a file SLocEntry!"),
function getFile, file /usr/src-
local/llvm/tools/clang/lib/Basic/../../include/clang/Bas
ic/SourceManager.h, line 237.
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: pawel.worach at gmail.com
CC: llvmbugs at cs.uiuc.edu
# ccc -c SLocEntry.c
Assertion failed: (isFile() && "Not a file SLocEntry!"), function getFile, file
/usr/src-local/llvm/tools/clang/lib/Basic/../../include/clang/Basic/SourceManager.h,
line 237.
--
Configure bugmail: http://llvm.org/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 Mar 2 14:24:55 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 14:24:55 -0600
Subject: [LLVMbugs] [Bug 3700] Test string-init.c fails if `store' is in the
path name.
In-Reply-To:
Message-ID: <200903022024.n22KOtT4000497@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3700
Ed Schouten changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |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 Mon Mar 2 15:00:01 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 15:00:01 -0600
Subject: [LLVMbugs] [Bug 3702] Assertion failed: (isFile() && "Not a file
SLocEntry!"), function getFile,
file /usr/src-local/llvm/tools/clang/lib/Basic/../../
include/clang/Basic/SourceManager.h, line 237.
In-Reply-To:
Message-ID: <200903022100.n22L012J001830@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3702
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #4 from Chris Lattner 2009-03-02 15:00:00 ---
Fix here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090302/013323.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 Mar 2 16:17:44 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 16:17:44 -0600
Subject: [LLVMbugs] [Bug 3699] Clang's executable name resolution doesn't
work on FreeBSD
In-Reply-To:
Message-ID: <200903022217.n22MHiXQ005301@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3699
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #6 from Chris Lattner 2009-03-02 16:17:43 ---
Awesome, applied:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090302/074495.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 Mar 2 16:20:42 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 16:20:42 -0600
Subject: [LLVMbugs] [Bug 3697] [PATCH] Updated header includes for GCC 4.4
In-Reply-To:
Message-ID: <200903022220.n22MKgdI005464@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3697
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Chris Lattner 2009-03-02 16:20:42 ---
No need to apologize! your patch looks great, applied here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090302/013333.html
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 Mar 2 17:28:32 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 17:28:32 -0600
Subject: [LLVMbugs] [Bug 3581] -strip-debug does not remove all debug info.
In-Reply-To:
Message-ID: <200903022328.n22NSWME008596@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3581
Devang Patel changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Devang Patel 2009-03-02 17:28:32 ---
Fixed. rev. 65889
--
Configure bugmail: http://llvm.org/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 Mar 2 17:51:11 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 17:51:11 -0600
Subject: [LLVMbugs] [Bug 3703] New: Analysis not updated after running a
CallGraphSCCPass.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3703
Summary: Analysis not updated after running a CallGraphSCCPass.
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: jlerouge at apple.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=2643)
--> (http://llvm.org/bugs/attachment.cgi?id=2643)
Testcase to reproduce the problem.
The attached Hello.cpp file illustrates my problem. Replace the original
Hello.cpp on the LLVM tree with that one, build and then run (assuming you are
on Darwin):
$ ./Debug/bin/opt --debug-pass=Structure --load LLVMHello.dylib -mysccpass
-hello -f -o t2.bc t.bc
Pass Arguments: -myanalysis -basiccg -mysccpass -hello -preverify -domtree
-verify
Target Data Layout
ModulePass Manager
My Analysis
Basic CallGraph Construction
Call Graph SCC Pass Manager
My SCCPass
Hello World Pass
FunctionPass Manager
Preliminary module verification
Dominator Tree Construction
Module Verifier
Bitcode Writer
-- Done running MyAnalysis
-- Done running MySCCPass
-- Done running Hello
As you can see above, MyAnalysis is not re-run after MySCCPass, even though
MySCCPass is not marking the analysis as beeing preserved. I was expecting it
would be re-run so Hello can start with a valid analysis.
Thanks,
Julien
--
Configure bugmail: http://llvm.org/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 Mar 2 22:16:54 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 22:16:54 -0600
Subject: [LLVMbugs] [Bug 3704] New: llvm-ld release built can' t correctly
link bc which contains debug information
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3704
Summary: llvm-ld release built can't correctly link bc which
contains debug information
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: dodohack at gmail.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=2644)
--> (http://llvm.org/bugs/attachment.cgi?id=2644)
2 llvm IR
the debug built of llvm can link 2 bc with debug information correctly.
but the release built of llvm can't do it correctly.
llvm is built with gcc 4.2
and llvm is 2.5 prerelease version.
the attached file is 2 llvm IR which will cause these error message:
[hwalin at earth temp]$ /temp/llvm-2.5-obj/Release/bin/llvm-ld environ.bc util.bc
Value still in symbol table! Type = '{ } *' Name = 'c3'
Value still in symbol table! Type = 'i32 *' Name = 'a'
Value still in symbol table! Type = 'i32 *' Name = 'b'
Value still in symbol table! Type = 'i32 *' Name = 'c'
Value still in symbol table! Type = 'i32' Name = 'alloca point'
Value still in symbol table! Type = '{ } *' Name = 'argv'
Value still in symbol table! Type = 'i8 * * *' Name = 'argv_addr'
Value still in symbol table! Type = 'i32' Name = 'retval10'
Value still in symbol table! Type = '{ } *' Name = 'argc'
Value still in symbol table! Type = 'i32 *' Name = 'retval'
Value still in symbol table! Type = '{ } *' Name = 'a5'
Value still in symbol table! Type = '{ } *' Name = 'b4'
Value still in symbol table! Type = 'i32 *' Name = 'argc_addr'
llvm-ld: /temp/llvm-2.5/lib/VMCore/ValueSymbolTable.cpp:29:
llvm::ValueSymbolTable::~ValueSymbolTable(): Assertion `vmap.empty() && "Values
remain in symbol table!"' failed.
0 llvm-ld 0x0834c8a7
1 libc.so.6 0x00baff91 abort + 257
2 libc.so.6 0x00ba793e __assert_fail + 238
3 llvm-ld 0x082eeb6a
?????????
[hwalin at earth temp]$
--
Configure bugmail: http://llvm.org/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 Mar 2 22:55:30 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 22:55:30 -0600
Subject: [LLVMbugs] [Bug 3687] Assertion failed: ((i >= FTy->getNumParams()
|| FTy-> getParamType(i) == Params[i]->getType()) && " Calling a function
with a bad signature!"), function init, file Instructions.cpp, line 294.
In-Reply-To:
Message-ID: <200903030455.n234tUZO020073@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3687
Eli Friedman changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sharparrow1 at yahoo.com
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Eli Friedman 2009-03-02 22:55:30 ---
Fixed in r65925. A rather nasty 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 Mar 2 23:40:02 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Mar 2009 23:40:02 -0600
Subject: [LLVMbugs] [Bug 3705] New: x86 backend fails to generate code on
this bitcode file
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3705
Summary: x86 backend fails to generate code on this bitcode file
Product: tools
Version: 2.4
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: llc
AssignedTo: unassignedbugs at nondot.org
ReportedBy: haohui.mai at gmail.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=2645)
--> (http://llvm.org/bugs/attachment.cgi?id=2645)
Test case
The X86 backend reports ``Couldn't allocate output reg for constraint 'A'!'' on
the attached bitcode 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 Mar 3 00:41:44 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Mar 2009 00:41:44 -0600
Subject: [LLVMbugs] [Bug 3691] Support for complex modes missing
In-Reply-To:
Message-ID: <200903030641.n236fiIP015110@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3691
Eli Friedman changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Eli Friedman 2009-03-03 00:41:43 ---
Fixed in r65935.
--
Configure bugmail: http://llvm.org/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 Mar 3 03:49:59 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Mar 2009 03:49:59 -0600
Subject: [LLVMbugs] [Bug 3706] New: Assertion failed: (RegMap[RegOnTop] <
StackTop), function moveToTop, file X86FloatingPoint.cpp, line 129.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3706
Summary: Assertion failed: (RegMap[RegOnTop] < StackTop),
function moveToTop, file X86FloatingPoint.cpp, line 129.
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: pawel.worach at gmail.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=2646)
--> (http://llvm.org/bugs/attachment.cgi?id=2646)
Pre-processed source
After bug #3691 was fixed this is the next problem in libgcc.
ccc -c -O2 -pipe -march=nocona -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-DHAVE_GTHR_DEFAULT -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include
-I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config
-I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I.
-I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -fstack-protector
-fvisibility=hidden -DHIDE_EXPORTS -fPIC -DL_mulxc3 -o _mulxc3.o
/usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c
Assertion failed: (RegMap[RegOnTop] < StackTop), function moveToTop, file
X86FloatingPoint.cpp, line 129.
--
Configure bugmail: http://llvm.org/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 Mar 3 05:55:52 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Mar 2009 05:55:52 -0600
Subject: [LLVMbugs] [Bug 3687] Assertion failed: ((i >= FTy->getNumParams()
|| FTy-> getParamType(i) == Params[i]->getType()) && " Calling a function
with a bad signature!"), function init, file Instructions.cpp, line 294.
In-Reply-To:
Message-ID: <200903031155.n23BtqrB003797@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3687
Pawel Worach changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #3 from Pawel Worach 2009-03-03 05:55:46 ---
Hmm, with this fix the error now turned up in another place in the FreeBSD
source tree, sendmail's mail.local.
ccc -O2 -pipe -march=nocona
-I/usr/src/libexec/mail.local/../../contrib/sendmail/include -I.
-I/usr/obj/usr/src/tmp/usr/include -fstack-protector -c
/usr/src/libexec/mail.local/../../contrib/sendmail/mail.local/mail.local.c
In file included from
/usr/src/libexec/mail.local/../../contrib/sendmail/mail.local/mail.local.c:29:
/usr/obj/usr/src/tmp/usr/include/unistd.h:363:43: warning: 'format' attribute
argument not supported: __printf0__
void setproctitle(const char *_fmt, ...) __printf0like(1, 2);
^
/usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:354:21: note: instantiated from:
__attribute__((__format__ (__printf0__, fmtarg, firstvararg)))
^
Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) ==
Params[i]->getType()) && "Calling a function with a bad signature!"), function
init, file Instructions.cpp, line 294.
--
Configure bugmail: http://llvm.org/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 Mar 3 06:57:08 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Mar 2009 06:57:08 -0600
Subject: [LLVMbugs] [Bug 3707] New: Inefficient loop codegen
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3707
Summary: Inefficient loop codegen
Product: libraries
Version: trunk
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Backend: X86
AssignedTo: unassignedbugs at nondot.org
ReportedBy: jturner at minnow-lang.org
CC: llvmbugs at cs.uiuc.edu
Compiling this with the llvm-gcc toolchain (through opt and llc) :
include
int main() {
int loop = 1000000000;
int timeout;
timeoutloop:
timeout = 2000;
/* asm("nop;"); */
loopto:
if (--timeout == 0) goto timeoutloop;
if (--loop != 0) goto loopto;
printf("Timeout: %i\n", timeout);
return 0;
}
Yields this asm as output (I'm using OS X):
.text
.align 4,0x90
.globl _main
_main:
subl $12, %esp
movl $1999, %eax
xorl %ecx, %ecx
movl $1999, %edx
.align 4,0x90
LBB1_1: ## loopto
cmpl $1, %eax
leal -1(%eax), %eax
cmove %edx, %eax
incl %ecx
cmpl $999999999, %ecx
jne LBB1_1 ## loopto
LBB1_2: ## bb1
movl %eax, 4(%esp)
movl $LC, (%esp)
call _printf
xorl %eax, %eax
addl $12, %esp
ret
.section __TEXT,__cstring,cstring_literals
LC: ## LC
.asciz "Timeout: %i\n"
.subsections_via_symbols
Which runs in 1.7s on this machine.
Uncommenting the 'asm("nop")' in the C code above instead yields this output:
.text
.align 4,0x90
.globl _main
_main:
subl $12, %esp
movl $1000000000, %eax
.align 4,0x90
LBB1_1: ## loopto.thread
movl %eax, %ecx
## InlineAsm Start
nop;
## InlineAsm End
movl $4294967295, %edx
jmp LBB1_3 ## bb
LBB1_2: ## loopto
decl %eax
incl %edx
cmpl $1998, %edx
je LBB1_1 ## loopto.thread
LBB1_3: ## bb
cmpl $1, %eax
jne LBB1_2 ## loopto
LBB1_4: ## bb1
subl %ecx, %eax
addl $1999, %eax
movl %eax, 4(%esp)
movl $LC, (%esp)
call _printf
xorl %eax, %eax
addl $12, %esp
ret
.section __TEXT,__cstring,cstring_literals
LC: ## LC
.asciz "Timeout: %i\n"
.subsections_via_symbols
Which runs in 1.0s.
The trivialized loop runs slower than the non-trivialized one. Evan Chang
points out on the LLVM mailing list:
"The main issue is incl updates the EFLAGS condition code register. But
llvm x86 isn't taking advantage of that. This is a known issue,
hopefully someone will find the time to implement before 2.6.
The second issue is the leal -1 can be turned (back) into a decl.
Combine that with the optimization previously described, it can
eliminate the first cmpl."
Another possibility is the use of cmove in this case is slower than a jz to a
branch that resets %eax. Modifying the original asm source above:
.text
.align 4,0x90
.globl _main
_main:
subl $12, %esp
movl $1999, %eax
xorl %ecx, %ecx
movl $1999, %edx
jmp LBB1_1
.align 4,0x90
LBB1_3:
movl %edx, %eax
jmp LBB1_4
LBB1_1: ## loopto
cmpl $1, %eax
leal -1(%eax), %eax
jz LBB1_3
LBB1_4:
incl %ecx
cmpl $999999999, %ecx
jnz LBB1_1 ## loopto
jmp LBB1_2
LBB1_2: ## bb1
movl %eax, 4(%esp)
movl $LC, (%esp)
call _printf
xorl %eax, %eax
addl $12, %esp
ret
.section __TEXT,__cstring,cstring_literals
LC: ## LC
.asciz "Timeout: %i\n"
.subsections_via_symbols
Which also runs in 1.0s.
--
Configure bugmail: http://llvm.org/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 Mar 3 08:26:28 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Mar 2009 08:26:28 -0600
Subject: [LLVMbugs] [Bug 3708] New: Fortran support in the online demo
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3708
Summary: Fortran support in the online demo
Product: Website
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: General Website
AssignedTo: unassignedbugs at nondot.org
ReportedBy: baldrick at free.fr
CC: llvmbugs at cs.uiuc.edu
It would be neat to offer Fortran as a language choice
in the online demo. This might even be trivial to do!
--
Configure bugmail: http://llvm.org/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 Mar 3 10:02:14 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Mar 2009 10:02:14 -0600
Subject: [LLVMbugs] [Bug 3709] New: Clang miscompiles crtend.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3709
Summary: Clang miscompiles crtend.
Product: clang
Version: unspecified
Platform: PC
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: ed at 80386.nl
CC: llvmbugs at cs.uiuc.edu
Blocks: 3696
Created an attachment (id=2649)
--> (http://llvm.org/bugs/attachment.cgi?id=2649)
Reduced testcase
When compiling the attached code without any optimization on x86_64, Clang
generates the following:
0000000000000000 <__do_global_ctors_aux>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 48 83 ec 10 sub $0x10,%rsp
8: 48 8d 04 25 00 00 00 lea 0x0,%rax
f: 00
10: 48 b9 f8 ff ff ff ff mov $0xfffffffffffffff8,%rcx
17: ff ff ff
1a: 48 01 c8 add %rcx,%rax
1d: 48 89 45 f8 mov %rax,0xfffffffffffffff8(%rbp)
21: 48 8b 45 f8 mov 0xfffffffffffffff8(%rbp),%rax
25: 48 8b 00 mov (%rax),%rax
28: b9 ff ff ff ff mov $0xffffffff,%ecx
2d: 89 c9 mov %ecx,%ecx
2f: 48 39 c8 cmp %rcx,%rax
32: 74 20 je 54 <__do_global_ctors_aux+0x54>
34: 48 8b 45 f8 mov 0xfffffffffffffff8(%rbp),%rax
38: 48 8b 00 mov (%rax),%rax
3b: ff d0 callq *%eax
3d: 48 8b 45 f8 mov 0xfffffffffffffff8(%rbp),%rax
41: 48 b9 f8 ff ff ff ff mov $0xfffffffffffffff8,%rcx
48: ff ff ff
4b: 48 01 c8 add %rcx,%rax
4e: 48 89 45 f8 mov %rax,0xfffffffffffffff8(%rbp)
52: eb cd jmp 21 <__do_global_ctors_aux+0x21>
54: 48 83 c4 10 add $0x10,%rsp
58: 5d pop %rbp
59: c3 retq
If we turn on the optimizer, we get:
0000000000000000 <__do_global_ctors_aux>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 30 c0 xor %al,%al
6: 66 data16
7: 66 data16
8: 66 data16
9: 90 nop
a: 66 data16
b: 66 data16
c: 90 nop
d: 66 data16
e: 66 data16
f: 90 nop
10: f6 d0 not %al
12: a8 01 test $0x1,%al
14: b0 00 mov $0x0,%al
16: 75 f8 jne 10 <__do_global_ctors_aux+0x10>
18: 5d pop %rbp
19: c3 retq
GCC generates the following code when using -O:
0000000000000000 <__do_global_ctors_aux>:
0: 53 push %rbx
1: 48 8b 05 00 00 00 00 mov 0(%rip),%rax # 8
<__do_global_ctors_aux+0x8>
8: 48 83 f8 ff cmp $0xffffffffffffffff,%rax
c: 74 18 je 26 <__do_global_ctors_aux+0x26>
e: bb 00 00 00 00 mov $0x0,%ebx
13: ff d0 callq *%eax
15: 48 8b 83 00 00 00 00 mov 0x0(%rbx),%rax
1c: 48 83 eb 08 sub $0x8,%rbx
20: 48 83 f8 ff cmp $0xffffffffffffffff,%rax
24: 75 ed jne 13 <__do_global_ctors_aux+0x13>
26: 5b pop %rbx
27: c3 retq
--
Configure bugmail: http://llvm.org/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 Mar 3 11:16:39 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Mar 2009 11:16:39 -0600
Subject: [LLVMbugs] [Bug 3710] New: llvm-gcc fails to build: Assertion `Cost
== C && " Cost exceeds InlineCost precision"' failed
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3710
Summary: llvm-gcc fails to build: Assertion `Cost == C && "Cost
exceeds InlineCost precision"' failed
Product: Build scripts
Version: 2.5
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Makefiles
AssignedTo: unassignedbugs at nondot.org
ReportedBy: jeffhao at umich.edu
CC: llvmbugs at cs.uiuc.edu
I've installed llvm 2.5 and was trying to make the new llvm-gcc from source for
2.5. LLVM installed, llvm-gcc errors out with the message:
cc1: /x/jeffhao/llvm/llvm/include/llvm/Transforms/Utils/InlineCost.h:44:
llvm::InlineCost::InlineCost(int, int): Assertion `Cost == C && "Cost exceeds
InlineCost precision"' failed.
../../llvm-gcc4.2-2.5.source/gcc/libgcov.c:644: internal compiler error:
Aborted
This is using the new 2.5 releases of both llvm and llvm-gcc on a 64-bit Intel
Quad Core running Red Hat el5 with kernel version 2.6.
I used these 2 commands to generate the error:
../llvm-gcc4.2-2.5.source/configure --prefix=/x/jeffhao/llvm/llvm-gcc/install
--program-prefix=llvm- --enable-llvm=/x/jeffhao/llvm/llvm-objects
--enable-languages=c,c++ --enable-checking --disable-shared
make
Here's the end of the output captured after configuring and making llvm-gcc:
/x/jeffhao/llvm/llvm-gcc/objects/./gcc/xgcc
-B/x/jeffhao/llvm/llvm-gcc/objects/./gcc/
-B/x/jeffhao/llvm/llvm-gcc/install/x86_64-unknown-linux-gnu/bin/
-B/x/jeffhao/llvm/llvm-gcc/install/x86_64-unknown-linux-gnu/lib/ -isystem
/x/jeffhao/llvm/llvm-gcc/install/x86_64-unknown-linux-gnu/include -isystem
/x/jeffhao/llvm/llvm-gcc/install/x86_64-unknown-linux-gnu/sys-include -O2 -O2
-g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I.
-I../../llvm-gcc4.2-2.5.source/gcc -I../../llvm-gcc4.2-2.5.source/gcc/.
-I../../llvm-gcc4.2-2.5.source/gcc/../include
-I../../llvm-gcc4.2-2.5.source/gcc/../libcpp/include
-I../../llvm-gcc4.2-2.5.source/gcc/../libdecnumber -I../libdecnumber
-I/x/jeffhao/llvm/llvm-objects/include -I/x/jeffhao/llvm/llvm/include
-fexceptions -c ../../llvm-gcc4.2-2.5.source/gcc/unwind-dw2.c -o
libgcc/./unwind-dw2.o
cc1: /x/jeffhao/llvm/llvm/include/llvm/Transforms/Utils/InlineCost.h:44:
llvm::InlineCost::InlineCost(int, int): Assertion `Cost == C && "Cost exceeds
InlineCost precision"' failed.
../../llvm-gcc4.2-2.5.source/gcc/unwind-dw2.c:1527: internal compiler error:
Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[4]: *** [libgcc/./unwind-dw2.o] Error 1
make[4]: Leaving directory `/x/jeffhao/llvm/llvm-gcc/objects/gcc'
make[3]: *** [stmp-multilib] Error 2
make[3]: Leaving directory `/x/jeffhao/llvm/llvm-gcc/objects/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/x/jeffhao/llvm/llvm-gcc/objects'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/x/jeffhao/llvm/llvm-gcc/objects'
make: *** [all] 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 Tue Mar 3 11:56:46 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Mar 2009 11:56:46 -0600
Subject: [LLVMbugs] [Bug 3711] New: 8-byte vectors on ppc32 assert
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3711
Summary: 8-byte vectors on ppc32 assert
Product: new-bugs
Version: unspecified
Platform: Macintosh
OS/Version: MacOS X
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: dalej at apple.com
CC: llvmbugs at cs.uiuc.edu
llvm-gcc -O1 20050607-1.c
Assertion failed: (false && "Unknown type action!"), function
ExpandRes_BIT_CONVERT, file LegalizeTypesGeneric.cpp, line 44.
extern void abort (void);
typedef int V2SI __attribute__ ((vector_size (8)));
int
main (void)
{
#if (__INT_MAX__ == 2147483647) \
&& (__LONG_LONG_MAX__ == 9223372036854775807LL)
if (((int)(long long)(V2SI){ 2, 2 }) != 2)
abort ();
#endif
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 Tue Mar 3 13:39:07 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Mar 2009 13:39:07 -0600
Subject: [LLVMbugs] [Bug 3712] New: Clang doesn' t predefine __OPTIMIZE__
and __PIC__ etc correctly
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3712
Summary: Clang doesn't predefine __OPTIMIZE__ and __PIC__ etc
correctly
Product: clang
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: clattner at apple.com
CC: llvmbugs at cs.uiuc.edu
There __OPTIMIZE__ should be set when -Ox is specified, and __PIC__ should
follow the -fpic /-fPIC settings appropriately.
--
Configure bugmail: http://llvm.org/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 Mar 3 14:31:30 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Mar 2009 14:31:30 -0600
Subject: [LLVMbugs] [Bug 3705] x86 backend fails to generate code on this
bitcode file
In-Reply-To:
Message-ID: <200903032031.n23KVU6g029629@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3705
Haohui Mai changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Haohui Mai 2009-03-03 14:31:30 ---
I tested it with trunk today. It seems work. Sorry for bothering.
--
Configure bugmail: http://llvm.org/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 Mar 3 18:29:43 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Mar 2009 18:29:43 -0600
Subject: [LLVMbugs] [Bug 3715] New: llvm-gcc fails to build on Fedora Linux
x86_86
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3715
Summary: llvm-gcc fails to build on Fedora Linux x86_86
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Keywords: build-problem, portability
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: postmodern.mod3 at gmail.com
CC: llvmbugs at cs.uiuc.edu
While attempting to compile llvm-gcc on my x86_64 Fedora Linux machine I
noticed that it was trying to find /usr/include/gnu/stubs-32.h instead of using
the existing /usr/include/gnu/stubs-64.h header file.
# ../llvm-gcc4.2-2.5.source/configure --enable-llvm=`pwd`/../llvm-2.5
--program-prefix=llvm- --enable-languages=c,c++ --host=x86_64-redhat-linux
--build=x86_64-redhat-linux
# make
...
make GCC_FOR_TARGET="/usr/local/src/llvm-gcc4.2-2.5.build/./gcc/xgcc
-B/usr/local/src/llvm-gcc4.2-2.5.build/./gcc/
-B/usr/local/x86_64-redhat-linux/bin/ -B/usr/local/x86_64-redhat-linux/lib/
-isystem /usr/local/x86_64-redhat-linux/include -isystem
/usr/local/x86_64-redhat-linux/sys-include" \
AR_FOR_TARGET="ar" \
AR_CREATE_FOR_TARGET="ar rc" \
AR_EXTRACT_FOR_TARGET="ar x" \
AR_FLAGS_FOR_TARGET="" \
CC="gcc" CFLAGS="-g -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute
-fno-common " \
BUILD_PREFIX="" \
BUILD_PREFIX_1="" \
LANGUAGES="" \
LIBGCC2_CFLAGS="-O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-m32 " \
LIBGCC2_STATIC_CFLAGS="" \
MULTILIB_CFLAGS=" -m32" T=32/ 32/crtbegin.o 32/crtend.o
32/crtbeginS.o 32/crtendS.o 32/crtbeginT.o 32/crtfastmath.o
make[5]: Entering directory `/usr/local/src/llvm-gcc4.2-2.5.build/gcc'
/usr/local/src/llvm-gcc4.2-2.5.build/./gcc/xgcc
-B/usr/local/src/llvm-gcc4.2-2.5.build/./gcc/
-B/usr/local/x86_64-redhat-linux/bin/ -B/usr/local/x86_64-redhat-linux/lib/
-isystem /usr/local/x86_64-redhat-linux/include -isystem
/usr/local/x86_64-redhat-linux/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -I. -I32 -I../../llvm-gcc4.2-2.5.source/gcc
-I../../llvm-gcc4.2-2.5.source/gcc/32
-I../../llvm-gcc4.2-2.5.source/gcc/../include
-I../../llvm-gcc4.2-2.5.source/gcc/../libcpp/include
-I../../llvm-gcc4.2-2.5.source/gcc/../libdecnumber -I../libdecnumber
-I/usr/local/src/llvm-gcc4.2-2.5.build/../llvm-2.5/include
-I/usr/local/src/llvm-2.5/include -m32 -g0 -finhibit-size-directive
-fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss
-fno-toplevel-reorder -fno-omit-frame-pointer -fno-asynchronous-unwind-tables
\
-c ../../llvm-gcc4.2-2.5.source/gcc/crtstuff.c -DCRT_BEGIN \
-o 32/crtbegin.o
In file included from /usr/include/features.h:359,
from /usr/include/stdio.h:28,
from ../../llvm-gcc4.2-2.5.source/gcc/tsystem.h:90,
from ../../llvm-gcc4.2-2.5.source/gcc/crtstuff.c:68:
/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory
make[5]: *** [32/crtbegin.o] Error 1
make[5]: Leaving directory `/usr/local/src/llvm-gcc4.2-2.5.build/gcc'
make[4]: *** [extra32] Error 2
make[4]: Leaving directory `/usr/local/src/llvm-gcc4.2-2.5.build/gcc'
make[3]: *** [stmp-multilib] Error 2
make[3]: Leaving directory `/usr/local/src/llvm-gcc4.2-2.5.build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/usr/local/src/llvm-gcc4.2-2.5.build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/usr/local/src/llvm-gcc4.2-2.5.build'
make: *** [all] 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 Tue Mar 3 19:42:54 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Mar 2009 19:42:54 -0600
Subject: [LLVMbugs] [Bug 3701] codegen does not propagate clobbers onto
INLINEASM node for flags
In-Reply-To:
Message-ID: <200903040142.n241gsFZ010032@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3701
Evan Cheng changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #17 from Evan Cheng 2009-03-03 19:42:53 ---
Fixed.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090302/074602.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 Mar 3 20:25:03 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Mar 2009 20:25:03 -0600
Subject: [LLVMbugs] [Bug 3716] New: Implement warning on poorly packed
structures
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3716
Summary: Implement warning on poorly packed structures
Product: clang
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Semantic Analyzer
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: daniel at zuster.org
CC: llvmbugs at cs.uiuc.edu
It would be nice if clang had a warning for structures which could be packed
better to save space.
For example:
--
struct s0 {
int32 a;
int16 b;
int32 c;
int16 d;
};
--
could be repacked to take 12 bytes instead of 16.
--
Configure bugmail: http://llvm.org/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 Mar 4 00:24:39 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 00:24:39 -0600
Subject: [LLVMbugs] [Bug 3686] Assertion failed: (0 && " Do not know how to
promote this operator's operand!"), function PromoteIntegerOperand,
file LegalizeIntegerTypes.cpp, line 666.
In-Reply-To:
Message-ID: <200903040624.n246Odu3021257@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3686
Eli Friedman changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #6 from Eli Friedman 2009-03-04 00:24:39 ---
Fixed in r66021.
--
Configure bugmail: http://llvm.org/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 Mar 4 00:29:54 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 00:29:54 -0600
Subject: [LLVMbugs] [Bug 3708] Fortran support in the online demo
In-Reply-To:
Message-ID: <200903040629.n246Tskb021933@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3708
Duncan Sands changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Duncan Sands 2009-03-04 00:29:54 ---
Fixed in CVS commit 1.96.
--
Configure bugmail: http://llvm.org/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 Mar 4 00:49:31 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 00:49:31 -0600
Subject: [LLVMbugs] [Bug 3666] X86 backend converts calls to constant
addresses to indirect calls.
In-Reply-To:
Message-ID: <200903040649.n246nViv022821@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3666
Evan Cheng changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Evan Cheng 2009-03-04 00:49:31 ---
Fixed. Revision 66024.
--
Configure bugmail: http://llvm.org/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 Mar 4 01:37:46 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 01:37:46 -0600
Subject: [LLVMbugs] [Bug 3717] New: Bugpoint crashes on the following
bitcode files.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3717
Summary: Bugpoint crashes on the following bitcode files.
Product: tools
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: bugpoint
AssignedTo: unassignedbugs at nondot.org
ReportedBy: haohui.mai at gmail.com
CC: llvmbugs at cs.uiuc.edu
Bugpoint asserted out when it is trying to simplify the code.
It exits with the following messages:
invalid llvm.dbg.declare intrinsic call
call void @llvm.dbg.declare(%struct.dev_archdata* null,
%struct.dev_archdata* bitcast (%llvm.dbg.variable.type* @llvm.dbg.variable4233
to %struct.dev_archdata*)) nounwind
Broken module found, compilation aborted!
0 bugpoint 0x0847857e
1 libc.so.6 0xb7de3098 abort + 392
2 bugpoint 0x0843077c
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 cs.uiuc.edu Wed Mar 4 01:42:48 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 01:42:48 -0600
Subject: [LLVMbugs] [Bug 3718] New: LLC crashes with the following bitcode
file
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3718
Summary: LLC crashes with the following bitcode file
Product: tools
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: llc
AssignedTo: unassignedbugs at nondot.org
ReportedBy: haohui.mai at gmail.com
CC: llvmbugs at cs.uiuc.edu
LLC crashes with the attached bitcode file. The attachment is a reduced version
from bugpoint, but bugpoint also crashed on this file.
The original file is generated with llvm-gcc-4.2 (with llvm 2.5), with -O0 -g
enabled.
--
Configure bugmail: http://llvm.org/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 Mar 4 02:12:37 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 02:12:37 -0600
Subject: [LLVMbugs] [Bug 3719] New: File uploading functionality doesn't
work on demo page
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3719
Summary: File uploading functionality doesn't work on demo page
Product: Website
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: General Website
AssignedTo: unassignedbugs at nondot.org
ReportedBy: baldrick at free.fr
CC: llvmbugs at cs.uiuc.edu
If I try to upload and compile a file using the demo page,
it recognizes the language but doesn't actually do anything.
--
Configure bugmail: http://llvm.org/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 Mar 4 02:32:04 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 02:32:04 -0600
Subject: [LLVMbugs] [Bug 3710] llvm-gcc fails to build: Assertion `Cost == C
&& " Cost exceeds InlineCost precision"' failed
In-Reply-To:
Message-ID: <200903040832.n248W40F029056@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3710
Duncan Sands changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #3 from Duncan Sands 2009-03-04 02:32:04 ---
gcc 4.1 is know to be broken, see
http://llvm.org/docs/GettingStarted.html#brokengcc
Here's an extract:
GCC 4.1.1: GCC fails to build LLVM with template concept check errors compiling
some files. At the time of this writing, GCC mainline (4.2) did not share the
problem.
GCC 4.1.1 on X86-64/amd64: GCC miscompiles portions of LLVM when compiling
llvm itself into 64-bit code. LLVM will appear to mostly work but will be
buggy, e.g. failing portions of its testsuite.
GCC 4.1.2 on OpenSUSE: Seg faults during libstdc++ build and on x86_64
platforms compiling md5.c gets a mangled constant.
GCC 4.1.2 (20061115 (prerelease) (Debian 4.1.1-21)) on Debian: Appears to
miscompile parts of LLVM 2.4. One symptom is ValueSymbolTable complaining about
symbols remaining in the table on destruction.
GCC 4.1.2 20071124 (Red Hat 4.1.2-42): Suffers from the same symptoms as the
previous one. It appears to work with ENABLE_OPTIMIZED=0 (the default).
Please try a different version of gcc, like gcc 4.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 Mar 4 02:33:43 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 02:33:43 -0600
Subject: [LLVMbugs] [Bug 3687] Assertion failed: ((i >= FTy->getNumParams()
|| FTy-> getParamType(i) == Params[i]->getType()) && " Calling a function
with a bad signature!"), function init, file Instructions.cpp, line 294.
In-Reply-To:
Message-ID: <200903040833.n248Xhsu029137@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3687
Ed Schouten changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ed at 80386.nl
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #8 from Ed Schouten 2009-03-04 02:33:43 ---
Yes, bug seems to be fixed now. Thanks a lot!
--
Configure bugmail: http://llvm.org/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 Mar 4 05:09:58 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 05:09:58 -0600
Subject: [LLVMbugs] [Bug 3719] File uploading functionality doesn't work on
demo page
In-Reply-To:
Message-ID: <200903041109.n24B9wbd013711@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3719
Duncan Sands changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Duncan Sands 2009-03-04 05:09:09 ---
Fixed in CVS commit 1.97.
--
Configure bugmail: http://llvm.org/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 Mar 4 09:28:19 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 09:28:19 -0600
Subject: [LLVMbugs] [Bug 3720] New: Scalar replacement introduces store with
incorrect alignment
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3720
Summary: Scalar replacement introduces store with incorrect
alignment
Product: libraries
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Scalar Optimizations
AssignedTo: unassignedbugs at nondot.org
ReportedBy: richard at xmos.com
CC: llvmbugs at cs.uiuc.edu
When the scalar replacement pass replaces a structure which is the source of a
llvm.memcpy then it replaces the memcpy with stores. It does not seem to be
taking into account the alignment of the memcpy when setting the alignment of
these stores.
running opt -scalar-repl on the following:
%struct.st = type <{ i16 }>
define void @f(i8* %p) nounwind {
entry:
%s = alloca %struct.st, align 4 ; <%struct.st*> [#uses=2]
%0 = getelementptr %struct.st* %s, i32 0, i32 0 ; [#uses=1]
store i16 1, i16* %0, align 4
%s1 = bitcast %struct.st* %s to i8* ; [#uses=1]
call void @llvm.memcpy.i32(i8* %p, i8* %s1, i32 2, i32 1)
ret void
}
declare void @llvm.memcpy.i32(i8* nocapture, i8* nocapture, i32, i32) nounwind
Results in the following output:
%struct.st = type <{ i16 }>
define void @f(i8* %p) nounwind {
entry:
%p1 = bitcast i8* %p to %struct.st* ; <%struct.st*> [#uses=1]
%p1.0 = getelementptr %struct.st* %p1, i32 0, i32 0 ; [#uses=1]
store i16 1, i16* %p1.0
ret void
}
declare void @llvm.memcpy.i32(i8* nocapture, i8* nocapture, i32, i32) nounwind
This is invalid - if %p isn't 16bit aligned then the store will be misaligned
and this may trap depending on the target.
--
Configure bugmail: http://llvm.org/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 Mar 4 10:32:54 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 10:32:54 -0600
Subject: [LLVMbugs] [Bug 3721] New: LLC generates undefined labels
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3721
Summary: LLC generates undefined labels
Product: tools
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: llc
AssignedTo: unassignedbugs at nondot.org
ReportedBy: haohui.mai at gmail.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=2653)
--> (http://llvm.org/bugs/attachment.cgi?id=2653)
test case
LLC is broken at revision 66035, but it works at revision 66001.
--
Configure bugmail: http://llvm.org/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 Mar 4 11:10:25 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 11:10:25 -0600
Subject: [LLVMbugs] [Bug 3722] New: LLVM doesn't store data initialized with
zero in BSS
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3722
Summary: LLVM doesn't store data initialized with zero in BSS
Product: clang
Version: unspecified
Platform: PC
OS/Version: FreeBSD
Status: NEW
Severity: enhancement
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: ed at 80386.nl
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=2654)
--> (http://llvm.org/bugs/attachment.cgi?id=2654)
Testcase
The attached application is only 6 KB when compiled with GCC, but 104 KB when
compiled with Clang. This is because the array at the top is initialized with
zeroes. GCC puts it in BSS, while Clang does 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 Wed Mar 4 11:32:07 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 11:32:07 -0600
Subject: [LLVMbugs] [Bug 3698] Clang doesn't support 'asm renaming' of
symbols
In-Reply-To:
Message-ID: <200903041732.n24HW7rK029278@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3698
Daniel Dunbar changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |daniel at zuster.org
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #4 from Daniel Dunbar 2009-03-04 11:32:06 ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090302/013424.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 Wed Mar 4 12:40:19 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 12:40:19 -0600
Subject: [LLVMbugs] [Bug 3709] Clang miscompiles crtend.
In-Reply-To:
Message-ID: <200903041840.n24IeJpT032031@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3709
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #7 from Chris Lattner 2009-03-04 12:40:19 ---
The problem here is that __CTOR_END__ has magic semantics that the compiler
doesn't know about, and is marked static. The proper way to tell the compiler
"don't touch" is to use __attribute__((used)), and doing so fixes the problem.
Please use something like this:
static func_ptr __attribute__((used)) __CTOR_END__[1]
__attribute__((section(".ctors"), aligned(sizeof(func_ptr)))) = { (func_ptr) 0
};
-Chris
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Wed Mar 4 13:17:12 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 13:17:12 -0600
Subject: [LLVMbugs] [Bug 3724] New: JIT Memory Manager causes false error
with any RWX memory region fragmentation
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3724
Summary: JIT Memory Manager causes false error with any RWX
memory region fragmentation
Product: libraries
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Keywords: quality-of-implementation
Severity: normal
Priority: P2
Component: Target-Independent JIT
AssignedTo: unassignedbugs at nondot.org
ReportedBy: eric.yew at gmail.com
CC: llvmbugs at cs.uiuc.edu
The JIT memory manager always returns the head of the FreeMemoryList in
response to a block allocation request from JITEmitter
(JITMemoryManager.cpp:303)
This can cause a "JIT: Ran out of space for generated machine code" error
whenever there's any fragmentation in the MemoryManger RWX region, even if
there's a huge amount of free space left.
Consider a multi-threaded application, where Thread A allocates a 100-byte
block at the beginning of the RWX region, then Thread B allocates a 100-byte
block directly after A's block. Thread A then frees its machine code block.
This would leave:
| <--100B Free--> | <--100B Alloc(Thread B)--> | <--15+MB Free Space--> |
^
Head of free list
Now, whenever anything else tries to allocate a JIT region, the Memory Manager
will always return the first (empty) 100B block. If this isn't big enough,
however, the current behavior of the JITEmitter is to abort with a "JIT: Ran
out of space for generated machine code" error (JITEmitter.cpp:893). I know
there's a //FIXME in there, but even when the JITEmitter requests another
allocation, the JIT MemoryManager will still return the head block.
Proposed Fix: Since the allocation size is unknown at alloc time, the JIT
MemoryManager should return the largest available block in the FreeMemoryList
on any allocation. I have a patch locally that implements this behavior and
corrects the problem. There is of course a performance penalty for this, but in
my application, in practice, the free list never grows beyond a handful of
entries despite being accessed asynchronously by many threads.
--
Configure bugmail: http://llvm.org/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 Mar 4 13:17:35 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 13:17:35 -0600
Subject: [LLVMbugs] [Bug 3722] LLVM doesn't store data initialized with zero
in BSS
In-Reply-To:
Message-ID: <200903041917.n24JHZG9001422@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3722
Daniel Dunbar changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |daniel at zuster.org
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #6 from Daniel Dunbar 2009-03-04 13:17:35 ---
Driver bug; fixed here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090302/013434.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 Wed Mar 4 13:21:20 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 13:21:20 -0600
Subject: [LLVMbugs] [Bug 3720] Scalar replacement introduces store with
incorrect alignment
In-Reply-To:
Message-ID: <200903041921.n24JLKOs001673@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3720
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Chris Lattner 2009-03-04 13:21:19 ---
Fixed:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090302/074633.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 Wed Mar 4 14:23:13 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 14:23:13 -0600
Subject: [LLVMbugs] [Bug 3726] New: [PATCH] ISO C++ fixes for GCC 4.4 / glibc
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3726
Summary: [PATCH] ISO C++ fixes for GCC 4.4 / glibc
Product: libraries
Version: 2.5
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: System Library
AssignedTo: unassignedbugs at nondot.org
ReportedBy: salimma at fedoraproject.org
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=2659)
--> (http://llvm.org/bugs/attachment.cgi?id=2659)
Patch for Unix/Signals.inc
The new version of glibc (2.9.90 on Rawhide), when used in combination with the
upcoming gcc 4.4, introduces some changes to the signatures of string-handling
functions: if the input is const, the return value is now also const.
This affects one file in LLVM 2.5 -- Signals.inc. Patch 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 cs.uiuc.edu Wed Mar 4 15:00:50 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 15:00:50 -0600
Subject: [LLVMbugs] [Bug 3726] [PATCH] ISO C++ fixes for GCC 4.4 / glibc
In-Reply-To:
Message-ID: <200903042100.n24L0oJT005903@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3726
Dan Gohman changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gohman at apple.com
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #1 from Dan Gohman 2009-03-04 15:00:50 ---
*** This bug has been marked as a duplicate of bug 3535 ***
--
Configure bugmail: http://llvm.org/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 Mar 4 15:05:14 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 15:05:14 -0600
Subject: [LLVMbugs] [Bug 3727] New: [PATCH] llvm-config's Makefile: change
sed's delimiter
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3727
Summary: [PATCH] llvm-config's Makefile: change sed's delimiter
Product: Build scripts
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Makefiles
AssignedTo: unassignedbugs at nondot.org
ReportedBy: salimma at fedoraproject.org
CC: llvmbugs at cs.uiuc.edu
llvm-config's Makefile uses sed with a delimiter of comma to build the final
version of the script. This causes problems when building in, e.g., Fedora,
since some compiler options passed by default contain commas, e.g.:
-Wp,-D_FORTIFY_SOURCE=2
We have carried this patch since llvm 2.1, but for some reason the patch has
never been upstreamed. If this could be applied, we could drop it from our
tree.
(Also, if someone could ping the Ocaml binding maintainer, this bug:
http://llvm.org/bugs/show_bug.cgi?id=3153 has a patch that applies to LLVM 2.4
and 2.5)
--
Configure bugmail: http://llvm.org/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 Mar 4 16:11:19 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 16:11:19 -0600
Subject: [LLVMbugs] [Bug 3728] New: Assertion failure in
llvm::ARMTargetLowering:: LowerOperation
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3728
Summary: Assertion failure in
llvm::ARMTargetLowering::LowerOperation
Product: libraries
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Backend: ARM
AssignedTo: unassignedbugs at nondot.org
ReportedBy: bharadwajy at gmail.com
CC: llvmbugs at cs.uiuc.edu
I encountered the following assertion during compilation using x86_64->arm
cross compiler that I built. llvm rev no: 66050.
Please find bugpoint-reduced-simplified.ll attached.
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 Wed Mar 4 17:20:19 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 17:20:19 -0600
Subject: [LLVMbugs] [Bug 3729] New: Regression: llvm 2.5 does not build on
PPC 64-bit
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3729
Summary: Regression: llvm 2.5 does not build on PPC 64-bit
Product: libraries
Version: 2.5
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Backend: PowerPC
AssignedTo: unassignedbugs at nondot.org
ReportedBy: salimma at fedoraproject.org
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=2661)
--> (http://llvm.org/bugs/attachment.cgi?id=2661)
Log describing the setting-up of the build chroot
Fedora packages llvm for Intel (ix86 and x86_64) and PPC (32-bit and 64-bit).
2.4 builds fine, but updating the package spec to build llvm-2.5 (no change is
made apart for applying an extra patch needed to build using GCC 4.4 / glibc),
attempts to build on PPC64 now fails:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1221676
llvm[2]: ======= Finished Linking Release Executable tblgen (without symbols)
make[2]: Leaving directory `/builddir/build/BUILD/llvm-2.5/utils/TableGen'
make[1]: Leaving directory `/builddir/build/BUILD/llvm-2.5/utils'
make[1]: Entering directory `/builddir/build/BUILD/llvm-2.5/lib/VMCore'
llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td
tblgen: IntrinsicEmitter.cpp:137: void EmitTypeForValueType(std::ostream&,
llvm::MVT::SimpleValueType): Assertion `false && "Unsupported ValueType!"'
failed.
make[1]: ***
[/builddir/build/BUILD/llvm-2.5/lib/VMCore/Release/Intrinsics.gen.tmp] Aborted
make[1]: Leaving directory `/builddir/build/BUILD/llvm-2.5/lib/VMCore'
make: *** [all] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.55THay (%build)
Full logs attached, as this is a temporary build and the logs will be purged in
a few days.
--
Configure bugmail: http://llvm.org/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 Mar 4 17:31:43 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 17:31:43 -0600
Subject: [LLVMbugs] [Bug 3729] llvm 2.5 does not build on PPC 64-bit (GCC
4.4, glibc 2.9.90)
In-Reply-To:
Message-ID: <200903042331.n24NVh3u012442@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3729
Bill Wendling changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Wed Mar 4 21:18:40 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 21:18:40 -0600
Subject: [LLVMbugs] [Bug 3688] crash with incomplete tag type as return/
parameter type for function declaration
In-Reply-To:
Message-ID: <200903050318.n253IelM020733@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3688
Eli Friedman changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Eli Friedman 2009-03-04 21:18:40 ---
Fixed in r66128.
--
Configure bugmail: http://llvm.org/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 Mar 4 22:30:49 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Mar 2009 22:30:49 -0600
Subject: [LLVMbugs] [Bug 3730] New: llvm-gcc crash with incomplete enum type
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3730
Summary: llvm-gcc crash with incomplete enum 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: sharparrow1 at yahoo.com
CC: llvmbugs at cs.uiuc.edu
Testcase:
enum y b(void);
struct x {enum y (*test)(void);} z = {b};
enum y {AAA,BBB};
int a() { return z.test(); }
cc1: Instructions.cpp:2164: static llvm::Instruction::CastOps
llvm::CastInst::getCastOpcode(const llvm::Value*, bool, const llvm::Type*,
bool): Assertion `SrcTy->isFirstClassType() && DestTy->isFirstClassType() &&
"Only first class types are castable!"' failed.
: In function ???a???:
:4: internal compiler error: Aborted
Another similar testcase:
enum y b(void);
struct x {enum y (*test)(void);} z = {b};
enum y {AAA,BBB};
enum y b(void) { return BBB; }
cc1: Function.cpp:164: llvm::Function::Function(const llvm::FunctionType*,
llvm::GlobalValue::LinkageTypes, const std::string&, llvm::Module*): Assertion
`FunctionType::isValidReturnType(getReturnType()) &&
!isa(getReturnType()) && "invalid return type"' failed.
: In function ???b???:
:4: internal compiler error: Aborted
These are contrived testcases I came up with while comparing the output of
llvm-gcc and clang for incomplete function types, so probably not a serious
issue, but it might be worth looking at.
--
Configure bugmail: http://llvm.org/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 Mar 5 00:42:50 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 00:42:50 -0600
Subject: [LLVMbugs] [Bug 3731] New: clang x86-32 doesn't implement ABI
properly on Linux
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3731
Summary: clang x86-32 doesn't implement ABI properly on Linux
Product: clang
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: daniel at zuster.org
CC: llvmbugs at cs.uiuc.edu
This is something of a meta bug; there are a number of differences in the ABI
between Darwin and Linux (and presumably FreeBSD, etc.) on x86-32. We should
make sure that the gcc compat test suite passes on Linux for x86-32; and do
some reasonable ABITest runs as well.
--
Configure bugmail: http://llvm.org/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 Mar 5 00:52:45 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 00:52:45 -0600
Subject: [LLVMbugs] [Bug 3732] New: LLC instruction scheduler misbehaves on
X86
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3732
Summary: LLC instruction scheduler misbehaves on X86
Product: tools
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: llc
AssignedTo: unassignedbugs at nondot.org
ReportedBy: haohui.mai at gmail.com
CC: llvmbugs at cs.uiuc.edu
Here is the test case:
; ModuleID = ''
declare i32 @foo()
define i32 @bar(i32* %flags) {
entry:
%flags.addr = load i32* %flags, align 4 ; [#uses=1]
%0 = call fastcc i32 @foo() nounwind ; [#uses=1]
call void asm sideeffect "push $0 ; popf",
"imr,~{dirflag},~{fpsr},~{flags},~{cc},~{memory}"(i32 %flags.addr) nounwind
%1 = icmp eq i32 %0, 0 ; [#uses=1]
br i1 %1, label %bb1, label %bb2
bb1: ; preds = %entry
ret i32 1
bb2: ; preds = %entry
ret i32 2
}
Here is the generated assembly:
bar:
.Leh_func_begin1:
.Llabel1:
pushl %esi
subl $8, %esp
movl 16(%esp), %eax
movl (%eax), %esi
call foo
movl %esi, 4(%esp)
testl %eax, %eax
#APP
push 4(%esp) ; popf
#NO_APP
jne .LBB1_3 # bb2
The POPF instruction is going to change the condition code register, which
means the branch is determined by the contents of %flags rather than the icmp
instruction.
The scheduler puts the TESTL instruction after the popf 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 cs.uiuc.edu Thu Mar 5 02:01:12 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 02:01:12 -0600
Subject: [LLVMbugs] [Bug 3734] New: Access to many passes missing from C API.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3734
Summary: Access to many passes missing from C API.
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: lennart at augustsson.net
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=2663)
--> (http://llvm.org/bugs/attachment.cgi?id=2663)
Tar file with new additional C API functions.
The C API does not give access to enough transformation passes to build any
kind of interesting optimization pipeline. The included tar file contains more
of them (still not all). The tar file contains two new files, and overwrites
two old files.
--
Configure bugmail: http://llvm.org/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 Mar 5 03:31:28 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 03:31:28 -0600
Subject: [LLVMbugs] [Bug 3688] crash with incomplete tag type as return/
parameter type for function declaration
In-Reply-To:
Message-ID: <200903050931.n259VR30012878@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3688
Ed Schouten changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ed at 80386.nl
Status|RESOLVED |REOPENED
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 Thu Mar 5 03:54:10 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 03:54:10 -0600
Subject: [LLVMbugs] [Bug 3735] New: Two different crashes inside Clang when
compiling unions with floats and integers .
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3735
Summary: Two different crashes inside Clang when compiling unions
with floats and integers.
Product: clang
Version: unspecified
Platform: PC
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: ed at 80386.nl
CC: llvmbugs at cs.uiuc.edu
Blocks: 3696
Created an attachment (id=2666)
--> (http://llvm.org/bugs/attachment.cgi?id=2666)
Reduced testcase
The attached code crashes with the following error:
Assertion failed: ((Accum == NoClass || Accum == Integer || Accum == SSE ||
Accum == SSEUp) && "Invalid accumulated classification during merge."),
function merge, file CGCall.cpp, line 478.
When void *k is removed from the struct, you get the following error:
Assertion failed: (0 && "Invalid classification for hi word."), function
classifyArgumentType, file CGCall.cpp, line 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 Thu Mar 5 11:19:15 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 11:19:15 -0600
Subject: [LLVMbugs] [Bug 3736] New: llc chokes on unhandled vector types
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3736
Summary: llc chokes on unhandled vector types
Product: libraries
Version: trunk
Platform: Macintosh
OS/Version: MacOS X
Status: NEW
Severity: normal
Priority: P2
Component: Backend: PowerPC
AssignedTo: unassignedbugs at nondot.org
ReportedBy: arplynn at gmail.com
CC: llvmbugs at cs.uiuc.edu
With the following testcase:
define <16 x float> @mm(<16 x float> %a, <16 x float> %b) nounwind readnone {
entry:
ret <16 x float> zeroinitializer
}
llc crashes as follows:
Return operand #1 has unhandled type v4f32
0 llc 0x00a02724 std::_Rb_tree, std::less,
std::allocator >::insert_unique(llvm::sys::Path const&) + 7652
1 libSystem.B.dylib 0x9693a99c _sigtramp + 68
Abort trap
--
Configure bugmail: http://llvm.org/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 Mar 5 11:49:27 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 11:49:27 -0600
Subject: [LLVMbugs] [Bug 3736] llc chokes on unhandled vector types
In-Reply-To:
Message-ID: <200903051749.n25HnRMr004154@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3736
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #1 from Chris Lattner 2009-03-05 11:49:27 ---
*** This bug has been marked as a duplicate of bug 2660 ***
--
Configure bugmail: http://llvm.org/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 Mar 5 11:56:16 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 11:56:16 -0600
Subject: [LLVMbugs] [Bug 1627] [PowerPC] Miscompilation of float selection
including NaNs
In-Reply-To:
Message-ID: <200903051756.n25HuGFx004578@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=1627
Dale Johannesen changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #7 from Dale Johannesen 2009-03-05 11:56:15 ---
Yes, although we generate compare-and-branch instead of trying to do something
clever. As far as I know all the problems with floating point compares are
fixed on PPC.
--
Configure bugmail: http://llvm.org/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 Mar 5 12:43:18 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 12:43:18 -0600
Subject: [LLVMbugs] [Bug 3737] New: clang rejects "__label__"
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3737
Summary: clang rejects "__label__"
Product: clang
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Semantic Analyzer
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: kremenek at apple.com
CC: llvmbugs at cs.uiuc.edu
gcc happily eats the following:
void foo(void) {
__label__ bad;
int x;
}
clang not so much:
$ clang t.c
t.c:6:3: error: expected expression
__label__ bad;
^
1 diagnostic generated.
Not only does clang reject this, but the error message is suboptimal.
--
Configure bugmail: http://llvm.org/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 Mar 5 12:44:09 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 12:44:09 -0600
Subject: [LLVMbugs] [Bug 3737] clang rejects "__label__"
In-Reply-To:
Message-ID: <200903051844.n25Ii9lS007052@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3737
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #1 from Chris Lattner 2009-03-05 12:44:08 ---
*** This bug has been marked as a duplicate of bug 3429 ***
--
Configure bugmail: http://llvm.org/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 Mar 5 13:00:20 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 13:00:20 -0600
Subject: [LLVMbugs] [Bug 3738] New: stack protector produces invalid IR in
test/CodeGen/Generic /stack-protector.ll
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3738
Summary: stack protector produces invalid IR in
test/CodeGen/Generic/stack-protector.ll
Product: libraries
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Common Code Generator Code
AssignedTo: unassignedbugs at nondot.org
ReportedBy: gohman at apple.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=2667)
--> (http://llvm.org/bugs/attachment.cgi?id=2667)
a hack to add Verifier passes
While debugging an unrelated problem, I added Verifier
passes to run after the late codegen phases. This is
turning up invalid IR in
test/CodeGen/Generic/stack-protector.ll
To reproduce, apply the attached patch, which adds the
Verifier passes, and run make check.
--
Configure bugmail: http://llvm.org/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 Mar 5 14:36:29 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 14:36:29 -0600
Subject: [LLVMbugs] [Bug 3739] New: x86-64 generates incorrect asm in
function prolog/ epilog trying to save XMM registers
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3739
Summary: x86-64 generates incorrect asm in function prolog/epilog
trying to save XMM registers
Product: libraries
Version: 2.5
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Backend: X86
AssignedTo: unassignedbugs at nondot.org
ReportedBy: craig at ni.com
CC: evan.cheng at apple.com, asl at math.spbu.ru, dalej at apple.com,
llvmbugs at cs.uiuc.edu, nicolas at capens.net
Depends on: 2801
On Win64, registers XMM6 - XMM15 are considered non-volatile and should be
callee-saved.
The bug this bug is a clone of (#2801) attempted to fix this, but the patch
suggested as the fix was only partially submitted; it added the XMM registers
to X86RegisterInfo::getCalleeSavesRegs(), but that's all.
The X86 function prolog/epilog code does not know how to save/restore XMM
registers and tries to emit a PUSH XMMn instruction, which is invalid; it emits
bad assembly. (When jitting, it encodes a push of a GP register instead.)
For example:
target triple = "x86_64-pc-windows"
declare extern_weak i32 @foo()
define i32 @func() {
entry:
%r = call i32 @foo() nounwind
ret i32 %r
}
% llvm-as < test.ll | llc -x86-asm-syntax=att
(I can't stand Intel asm syntax, so even though this is a Win64 target I try to
lessen the pain)
_text segment 'DATA'
align 16
.globl _func
_func:
$label1:
pushq %xmm15
pushq %xmm14
pushq %xmm13
pushq %xmm12
pushq %xmm11
pushq %xmm10
pushq %xmm9
pushq %xmm8
pushq %xmm7
pushq %xmm6
pushq %rsi
pushq %rdi
subq $88, %rsp
call _foo
addq $88, %rsp
popq %rdi
popq %rsi
popq %xmm6
popq %xmm7
popq %xmm8
popq %xmm9
popq %xmm10
popq %xmm11
popq %xmm12
popq %xmm13
popq %xmm14
popq %xmm15
ret
----
Note also that not only does the prolog/epilog emit incorrect instructions for
dealing with XMM*,
it also shouldn't be bothering to save/restore the registers in the first place
since they are not used in the function. (In
PEI::calculateCalleeSavedRegisters(), the Fn.getRegInfo().isPhysRegUsed(Reg)
call always returns true for all the XMM registers if the Function being
emitted has any call instructions.)
The part of the patch attached to #2801 which was not applied did attempt to
generate direct writes/reads to the stack for XMM registers instead of
push/pop, but still doesn't ensure alignment correctly.
+++ This bug was initially created as a clone of Bug #2801 +++
The x86-64 ABI specifies that XMM6 to XMM15 are non-volatile, and should be
preserved by the callee as needed. It appears that LLVM currently doesn't do
this, causing unpredictable behavior with floating-point calculations.
--
Configure bugmail: http://llvm.org/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 Mar 5 16:38:56 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 16:38:56 -0600
Subject: [LLVMbugs] [Bug 3732] LLC instruction scheduler misbehaves on X86
In-Reply-To:
Message-ID: <200903052238.n25Mcutk016993@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3732
Haohui Mai changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #2 from Haohui Mai 2009-03-05 16:38:55 ---
It does not work on revision 66001, but it works on 66208. Thank you.
*** This bug has been marked as a duplicate of bug 3701 ***
--
Configure bugmail: http://llvm.org/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 Mar 5 16:47:08 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 16:47:08 -0600
Subject: [LLVMbugs] [Bug 3607] crash on bitfield with incomplete type
In-Reply-To:
Message-ID: <200903052247.n25Ml8Ek017421@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3607
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Chris Lattner 2009-03-05 16:47:07 ---
Fixed:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090302/013526.html
GCC's warning is bogus: 'e0' has an unknown width. We now produce:
t.c:3:11: error: field has incomplete type 'enum e0'
enum e0 f : 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 Mar 5 18:11:25 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 18:11:25 -0600
Subject: [LLVMbugs] [Bug 3740] New: Odd missed optimization
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3740
Summary: Odd missed optimization
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: regehr at cs.utah.edu
CC: llvmbugs at cs.uiuc.edu
This is seen using r66136 on x86 on Ubuntu Hardy.
The code below should compile into "return 0", but fails to. If the line of
code in func_1() is pasted into main(), everything gets optimized properly.
regehr at john-home:~/volatile/tmp141$ cat small2.c
#include
#include
#define safe_lshift_macro_int32_t_s_s(left,right) \
(((((int32_t)(left)) < ((int32_t)0)) \
|| (((int)(right)) < ((int32_t)0)) \
|| (((int)(right)) >= sizeof(int32_t)*CHAR_BIT) \
|| (((int32_t)(left)) > ((INT32_MAX) >> ((int)(right))))) \
? ((int32_t)(left)) \
: (((int32_t)(left)) << ((int)(right))))
static int32_t
safe_lshift_func_int32_t_s_s(int32_t _left, int _right)
{
return safe_lshift_macro_int32_t_s_s(_left,_right);
}
static uint8_t g_6;
static void func_1 (void);
static void func_1 (void)
{
g_6 = safe_lshift_func_int32_t_s_s (g_6, g_6);
}
int main (void)
{
func_1 ();
return g_6;
}
regehr at john-home:~/volatile/tmp141$ llvm-gcc -O6 small2.c -S --emit-llvm -o -
; ModuleID = 'small2.c'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"
@g_6 = internal global i8 0 ; [#uses=2]
define i32 @main() nounwind {
entry:
%0 = load i8* @g_6, align 1 ; [#uses=2]
%1 = zext i8 %0 to i32 ; [#uses=5]
%2 = icmp ugt i8 %0, 31 ; [#uses=1]
br i1 %2, label %func_1.exit, label %bb6.i.i
bb6.i.i: ; preds = %entry
%3 = lshr i32 2147483647, %1 ; [#uses=1]
%4 = icmp slt i32 %3, %1 ; [#uses=1]
%5 = select i1 %4, i32 0, i32 %1 ; [#uses=1]
%..i = shl i32 %1, %5 ; [#uses=1]
br label %func_1.exit
func_1.exit: ; preds = %entry, %bb6.i.i
%6 = phi i32 [ %..i, %bb6.i.i ], [ %1, %entry ] ;
[#uses=2]
%7 = trunc i32 %6 to i8 ; [#uses=1]
store i8 %7, i8* @g_6, align 1
%8 = and i32 %6, 255 ; [#uses=1]
ret i32 %8
}
--
Configure bugmail: http://llvm.org/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 Mar 5 19:42:49 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 19:42:49 -0600
Subject: [LLVMbugs] [Bug 3738] stack protector produces invalid IR in
test/CodeGen/Generic/ stack-protector.ll
In-Reply-To:
Message-ID: <200903060142.n261gngk024110@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3738
Bill Wendling changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Bill Wendling 2009-03-05 19:42:48 ---
Fixed here:
http://llvm.org/viewvc/llvm-project?rev=66234&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 Thu Mar 5 20:18:06 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Mar 2009 20:18:06 -0600
Subject: [LLVMbugs] [Bug 718] bugpoint crashes on stripped bc files
In-Reply-To:
Message-ID: <200903060218.n262I6m1025489@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=718
Dan Gohman changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gohman at apple.com
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Dan Gohman 2009-03-05 20:18:06 ---
Instead of looking up the function by name, bugpoint can use
CloneModule's ValueMap to look up the new function. Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090302/074736.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 Fri Mar 6 08:29:10 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 6 Mar 2009 08:29:10 -0600
Subject: [LLVMbugs] [Bug 3741] New: Scalar replacement of Aggregates doesn't
handle "byval" parameters.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3741
Summary: Scalar replacement of Aggregates doesn't handle "byval"
parameters.
Product: new-bugs
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: fvbommel at wxs.nl
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=2674)
--> (http://llvm.org/bugs/attachment.cgi?id=2674)
A testcase. Only three loads and three stores should be produced after opt
-instcombine -scalarrepl.
Consider the following C code:
-----
typedef struct Type {
long a, b, c;
} Type;
Type foo(Type t) {
// Type u = t;
// #define t u
t.a += t.b;
t.b += t.c;
return t;
}
-----
Compiling this with llvm-gcc (-O0) and running 'opt -instcombine -scalarrepl'
over it produces the attached bitcode.
Note that the first two stores (to t.a and t.b) are completely redundant and
would obviously have been deleted if 't' had been represented as an alloca
instead of a byval parameter. (What's more, running 'opt -std-compile-opts'
instead only deletes one of them; -dse removes the store to t.b but not the one
to t.a)
I've tested this theory by uncommenting the first two lines in foo() to tell
llvm-gcc to copy the parameter to an alloca and use that instead. This change
produces only three stores (as opposed to the original 5) after 'opt
-instcombine -scalarrepl'.
I think this should be remedied by having scalar replacement of aggregates
treat byval parameters identical to allocas, since they have the exact same
properties except that they can't be deleted and don't have an undef value
before first being stored to.
(Or if that wouldn't work because of type issues, by introducing a pass that
does for byval parameters what scalarrepl does for allocas)
(There are also 7 loads in the original bitcode as opposed to 3 in the
alloca'ing one, but with '-std-compile-opts' the 4 extra ones are removed by
-gvn)
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Fri Mar 6 09:13:26 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 6 Mar 2009 09:13:26 -0600
Subject: [LLVMbugs] [Bug 3443] recent regression: undeclared function isn' t
infered the right type
In-Reply-To:
Message-ID: <200903061513.n26FDPxH032286@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3443
Douglas Gregor changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dgregor at apple.com
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Douglas Gregor 2009-03-06 09:13:20 ---
This code is ill-formed, and Clang is doing the right thing. GCC produces a
warning (normal mode) or an error (with -ansi), EDG produces an error
(always).
--
Configure bugmail: http://llvm.org/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 Mar 6 10:09:49 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 6 Mar 2009 10:09:49 -0600
Subject: [LLVMbugs] [Bug 3742] New: Missing warning: "noreturn function does
return"
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3742
Summary: Missing warning: "noreturn function does return"
Product: clang
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Semantic Analyzer
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: daniel at zuster.org
CC: llvmbugs at cs.uiuc.edu
--
void t1() __attribute__((noreturn));
void t1() {}
--
--
Configure bugmail: http://llvm.org/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 Mar 6 10:53:10 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 6 Mar 2009 10:53:10 -0600
Subject: [LLVMbugs] [Bug 3734] Access to many passes missing from C API.
In-Reply-To:
Message-ID: <200903061653.n26GrA7P003325@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3734
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Chris Lattner 2009-03-06 10:53:09 ---
Thanks!
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090302/074763.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 Fri Mar 6 11:52:14 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 6 Mar 2009 11:52:14 -0600
Subject: [LLVMbugs] [Bug 3735] Two different crashes inside Clang when
compiling unions with floats and integers .
In-Reply-To:
Message-ID: <200903061752.n26HqEEE006004@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3735
Daniel Dunbar changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Daniel Dunbar 2009-03-06 11:52:14 ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090302/013554.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 Fri Mar 6 12:38:19 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 6 Mar 2009 12:38:19 -0600
Subject: [LLVMbugs] [Bug 3688] GNU extension: support forward declarations
of enums
In-Reply-To:
Message-ID: <200903061838.n26IcJA2029500@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3688
Douglas Gregor changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #10 from Douglas Gregor 2009-03-06 12:38:06 ---
I thought our support for forward declaration of enums was worse off. Fixed the
remaining Sema issue here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090302/013558.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 Fri Mar 6 16:45:36 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 6 Mar 2009 16:45:36 -0600
Subject: [LLVMbugs] [Bug 2821] clang rejects ANSI C style prototype + K&R
style definition
In-Reply-To:
Message-ID: <200903062245.n26Mja91007080@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=2821
Douglas Gregor changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #6 from Douglas Gregor 2009-03-06 16:45:34 ---
Fixed here by implementing the GNU C semantics:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090302/013568.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 Fri Mar 6 17:25:48 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 6 Mar 2009 17:25:48 -0600
Subject: [LLVMbugs] [Bug 3743] New: -mmacosx-version-min inappropriate for
Mac OS X 10.4.11
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3743
Summary: -mmacosx-version-min inappropriate for Mac OS X 10.4.11
Product: Build scripts
Version: trunk
Platform: Macintosh
OS/Version: MacOS X
Status: NEW
Severity: blocker
Priority: P2
Component: Makefiles
AssignedTo: unassignedbugs at nondot.org
ReportedBy: scooter.phd at gmail.com
CC: llvmbugs at cs.uiuc.edu
The values for "-mmacosx-version-min" need to be carefully chosen, since they
vary from OSX version to version. On OSX 10.4.11, for example,
"-mmacosx-version-min" can only take on the following values (quoted from the
gcc man page):
-mmacosx-version-min=version
The earliest version of MacOS X that this executable will run on is
version. Typical values of version include 10.1, 10.2, and 10.3.9.
The default for this option is to make choices that seem to be most
useful.
Currently, this value for this flag is a blocker when compiling for 10.4.11
(yes, there are still a few of us out there who are mandated to use this OS
version.)
Compilation output follows:
===========================
% make VERBOSE=1
for dir in lib/System lib/Support utils lib/VMCore lib tools/llvm-config tools
docs; do \
if [ ! -f $dir/Makefile ]; then \
/Users/scottm/play/llvm/branches/llvm-spu/autoconf/mkinstalldirs $dir; \
/bin/cp /Users/scottm/play/llvm/branches/llvm-spu/$dir/Makefile
$dir/Makefile; \
fi; \
(make -C $dir all ) || exit 1; \
done
llvm[1]: Compiling Alarm.cpp for Debug build
if g++ -I/Users/scottm/play/llvm/branches/llvm-spu/include
-I/Users/scottm/play/llvm/branches/llvm-spu/lib/System
-I/Users/scottm/play/llvm/branches/llvm-spu/obj/i686-apple-darwin/include
-I/Users/scottm/play/llvm/branches/llvm-spu/obj/i686-apple-darwin/lib/System
-D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -g
-fno-exceptions -fno-common -Woverloaded-virtual -mmacosx-version-min=`sw_vers
-productVersion` -Wall -W -Wwrite-strings -Wunused -Wno-unused-parameter -c
-MMD -MP -MF
"/Users/scottm/play/llvm/branches/llvm-spu/obj/i686-apple-darwin/lib/System/Debug/Alarm.d.tmp"
-MT
"/Users/scottm/play/llvm/branches/llvm-spu/obj/i686-apple-darwin/lib/System/Debug/Alarm.o"
-MT
"/Users/scottm/play/llvm/branches/llvm-spu/obj/i686-apple-darwin/lib/System/Debug/Alarm.d"
/Users/scottm/play/llvm/branches/llvm-spu/lib/System/Alarm.cpp -o
/Users/scottm/play/llvm/branches/llvm-spu/obj/i686-apple-darwin/lib/System/Debug/Alarm.o
; \
then /bin/mv -f
"/Users/scottm/play/llvm/branches/llvm-spu/obj/i686-apple-darwin/lib/System/Debug/Alarm.d.tmp"
"/Users/scottm/play/llvm/branches/llvm-spu/obj/i686-apple-darwin/lib/System/Debug/Alarm.d";
else /bin/rm
"/Users/scottm/play/llvm/branches/llvm-spu/obj/i686-apple-darwin/lib/System/Debug/Alarm.d.tmp";
exit 1; fi
:1: error: Unknown value '10.4.11' of -mmacosx-version-min
make[1]: ***
[/Users/scottm/play/llvm/branches/llvm-spu/obj/i686-apple-darwin/lib/System/Debug/Alarm.o]
Error 1
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 Fri Mar 6 17:29:15 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 6 Mar 2009 17:29:15 -0600
Subject: [LLVMbugs] [Bug 3680] anonymous union: invalid error & poor
diagnostic
In-Reply-To:
Message-ID: <200903062329.n26NTFbh008915@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3680
Douglas Gregor changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #5 from Douglas Gregor 2009-03-06 17:29:15 ---
I've improved the error message a bit here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090302/013572.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 Fri Mar 6 18:41:50 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 6 Mar 2009 18:41:50 -0600
Subject: [LLVMbugs] [Bug 3744] New: Field Idx out of range!
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3744
Summary: Field Idx out of range!
Product: new-bugs
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: wendling at apple.com
CC: llvmbugs at cs.uiuc.edu
This code is causing problems:
$ cat t2.i
struct Empty {};
struct Union {
union {
int zero_arr[0];
} contents;
};
static inline void Foo(struct Union *u) {
int *array = u->contents.zero_arr;
}
static void Bar(struct Union *u) {
Foo(u);
}
$ llvm-gcc -c t2.i
Assertion failed: (MemberIndex < StructTy->getNumContainedTypes() && "Field Idx
out of range!"), function EmitLV_COMPONENT_REF, file
../../llvm-gcc.src/gcc/llvm-convert.cpp, line 5993.
t2.i: In function ???Foo???:
t2.i:7: internal compiler error: Abort trap
Please submit a full bug report,
with preprocessed source if appropriate.
See 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 cs.uiuc.edu Fri Mar 6 21:27:10 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 6 Mar 2009 21:27:10 -0600
Subject: [LLVMbugs] [Bug 3671] clang fails parse stdio.h from (gentoo)
glibc-2.6.1
In-Reply-To:
Message-ID: <200903070327.n273RA5T017911@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3671
Eli Friedman changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sharparrow1 at yahoo.com
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #7 from Eli Friedman 2009-03-06 21:27:09 ---
CodeGen looks fine; there isn't really anything special to handle.
--
Configure bugmail: http://llvm.org/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 Mar 7 00:26:21 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 7 Mar 2009 00:26:21 -0600
Subject: [LLVMbugs] [Bug 3746] New: Crash in isel with GEP of function
pointer
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3746
Summary: Crash in isel with GEP of function pointer
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
Testcase:
define void @a() {
getelementptr i32()* null, i32 1
ret void
}
Run through llvm-as | llc, gives the following:
llc: /home/eli/llvm/lib/Target/TargetData.cpp:468: unsigned char
llvm::TargetData::getAlignment(const llvm::Type*, bool) const: Assertion
`Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"' failed.
Possibly the verifier should catch this... but there are regression tests that
depend on GEPs of unsized types (!). In any case, crashing isn't nice.
--
Configure bugmail: http://llvm.org/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 Mar 7 00:30:54 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 7 Mar 2009 00:30:54 -0600
Subject: [LLVMbugs] [Bug 3747] New: Crash in llvm-as with void field in
struct
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3747
Summary: Crash in llvm-as with void field in struct
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: sharparrow1 at yahoo.com
CC: llvmbugs at cs.uiuc.edu
Testcase:
%x = type {void}
Run through llvm-as:
llvm-as: /home/eli/llvm/lib/VMCore/Type.cpp:346:
llvm::StructType::StructType(const std::vector >&, bool): Assertion `Types[i] !=
Type::VoidTy && "Void type for structure field!!"' 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 Sat Mar 7 04:52:53 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 7 Mar 2009 04:52:53 -0600
Subject: [LLVMbugs] [Bug 3748] New: ImplicitValueExpr appears inside
MemberExpr.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3748
Summary: ImplicitValueExpr appears inside MemberExpr.
Product: clang
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Semantic Analyzer
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: bolzoni at cs.unipr.it
CC: llvmbugs at cs.uiuc.edu, bagnara at cs.unipr.it
Test case:
code.c --->
struct S2{ void* d; };
unsigned f()
{
return __builtin_offsetof (struct S2, d);
}
---<
--->
$ clang -ast-dump code.c
(CompoundStmt 0x1fb2100
(ReturnStmt 0x1fb3240
(ImplicitCastExpr 0x1fb3200 'unsigned int'
(UnaryOperator 0x1fb31c0 'unsigned long' prefix
'__builtin_offsetof'
(MemberExpr 0x1fb3180 <, col:42> 'void *' .d 0x1fb2fe0
(UnaryOperator 0x1fb4310 <> 'struct S2' prefix '*'
(ImplicitValueInitExpr 0x1fb3110 <> 'struct S2
*')))))))
typedef struct __va_list_tag __builtin_va_list[1];
Read top-level variable decl: 'S2'
unsigned int f()
---<
The last two lines of the f definition's compound statement should not be
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 cs.uiuc.edu Sat Mar 7 09:12:34 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 7 Mar 2009 09:12:34 -0600
Subject: [LLVMbugs] [Bug 3749] New: linker adds spurious use to appending
globals
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3749
Summary: linker adds spurious use to appending globals
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Keywords: miscompilation
Severity: major
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: kamm-removethis at incasoftware.de
CC: llvmbugs at cs.uiuc.edu
When linking two modules containing appending globals with uses=0 with
llvm::Linker, the resulting global will have a uses count of one.
The cause for the extra use is found in LinkModules.cpp:1168, where a
ConstantExpr::getBitCast(NG, G1->getType()) is created as a replacement for
previous uses of G1 - even if there weren't any.
This bug is significant as the nonzero use count stops LLVM from processing
magic global constants such as llvm.global_ctors.
--
Configure bugmail: http://llvm.org/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 Mar 7 09:19:05 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 7 Mar 2009 09:19:05 -0600
Subject: [LLVMbugs] [Bug 3750] New: FreeBSD's ld-elf. so miscompiles when
array is marked as static
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3750
Summary: FreeBSD's ld-elf.so miscompiles when array is marked as
static
Product: clang
Version: unspecified
Platform: PC
URL: http://svn.freebsd.org/viewvc/base/head/libexec/rtld-
elf/rtld.c?view=markup
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: ed at 80386.nl
CC: llvmbugs at cs.uiuc.edu
Blocks: 3696
Created an attachment (id=2678)
--> (http://llvm.org/bugs/attachment.cgi?id=2678)
LLVM IR of rtld.c
We're having this issue with Clang, which we cannot reduce to a simple test
case. This is why we're just filing a bug report and hoping you folks know the
answer or can tell us how to track down the cause of the issue. Notice we
slightly changed the code to use __attribute__((__weak__)) instead of #pragma
weak (see 3679).
When rtld is compiled with Clang using -O or -O2, applications that use the
dynamic linker will die on startup:
ld-elf.so.1: assert failed: rtld.c:1199
This can be solved by compiling rtld with -O0 or marking the `exports' array in
the file as __used.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sat Mar 7 09:41:35 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 7 Mar 2009 09:41:35 -0600
Subject: [LLVMbugs] [Bug 3751] New: SourceLocation of -> or .
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3751
Summary: SourceLocation of -> or .
Product: clang
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: AST
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: bolzoni at cs.unipr.it
CC: llvmbugs at cs.uiuc.edu, bagnara at cs.unipr.it
The only public code of clang::MemberExpr concerning SourceLocations or
SourceRanges is (constructor a part):
---->
virtual SourceLocation getExprLoc() const { return MemberLoc; }
SourceLocation getMemberLoc() const { return MemberLoc; }
virtual SourceRange getSourceRange() const {
return SourceRange(getBase()->getLocStart(), MemberLoc);
}
----<
It seems there is no way to get the source location of . or -> , I think it is
a simple oversight. Would it be possible to add this feature?
--
Configure bugmail: http://llvm.org/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 Mar 7 13:24:14 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 7 Mar 2009 13:24:14 -0600
Subject: [LLVMbugs] [Bug 3751] SourceLocation of -> or .
In-Reply-To:
Message-ID: <200903071924.n27JOE6j023821@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3751
Ted Kremenek changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kremenek at apple.com
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Ted Kremenek 2009-03-07 13:24:12 ---
I believe that MemberExpr::getMemberLoc() returns the location of '.' or '->'
--
Configure bugmail: http://llvm.org/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 Mar 7 14:36:27 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 7 Mar 2009 14:36:27 -0600
Subject: [LLVMbugs] [Bug 3752] New: @encode() codegen does not match GCC
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3752
Summary: @encode() codegen does not match GCC
Product: clang
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: devlists at shadowlab.org
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=2681)
--> (http://llvm.org/bugs/attachment.cgi?id=2681)
Simple test case
GCC use to returns the same string pointer for all @encode() directive with the
same type, and so it's possible (using GCC) to compare @encode() values using
the '==' operator.
Actually, clang returns a different pointer for each @encode directive.
The SenTestingKit distributed with Xcode rely on this behavior in the Unit
Tests Assertions macros, and so, some test failed when they are compiled using
clang.
------------ encode.m ----------------
#include
int main(int argc, char **argv) {
if (@encode(id) != @encode(id))
fprintf(stderr, "types do not match !!!\n");
return 0;
}
----------------------------------
[MacBook:~/Desktop]% gcc -o encode encode.m
[MacBook:~/Desktop]% ./encode
[MacBook:~/Desktop]% ccc -o encode encode.m
[MacBook:~/Desktop]% ./encode
types do not match !!!
--
Configure bugmail: http://llvm.org/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 Mar 7 15:04:55 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 7 Mar 2009 15:04:55 -0600
Subject: [LLVMbugs] [Bug 3753] New: clang should warn about comparison with
string literal
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3753
Summary: clang should warn about comparison with string literal
Product: clang
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Semantic Analyzer
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: sharparrow1 at yahoo.com
CC: llvmbugs at cs.uiuc.edu
Constructs like the following should emit a warning a comparison with a string
literal is almost certainly a mistake. Comparing addresses of string literals
within the same file is probably safe, and comparing addresses across files is
likely to work, but most uses are probably not intentional.
First draft of wording:
warning: result of comparison with pointer to string literal is unspecified.
I was considering putting in a suggestion to use strcmp or something like that,
but it's hard to come up with wording that concise and doesn't sound insulting
to experienced programmers.
Examples:
>From a mailing list message:
if (@encode(__typeof__(a1)) != @encode(__typeof__(a2))) { ... }
One example from thousands of results from a Google Code Search for !=" :
if (!a->name.isEmpty() && a->type!="void") { ... }
gcc has a similar warning when -Wall is used, but they apparently missed the
case of @encode.
--
Configure bugmail: http://llvm.org/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 Mar 7 18:51:01 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 7 Mar 2009 18:51:01 -0600
Subject: [LLVMbugs] [Bug 3752] @encode() codegen does not match GCC
In-Reply-To:
Message-ID: <200903080051.n280p17v001141@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3752
Eli Friedman changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Eli Friedman 2009-03-07 18:50:51 ---
Yes, I already "fixed" this in r66346.
--
Configure bugmail: http://llvm.org/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 Mar 7 19:33:34 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 7 Mar 2009 19:33:34 -0600
Subject: [LLVMbugs] [Bug 3750] FreeBSD's ld-elf.so miscompiles when array is
marked as static
In-Reply-To:
Message-ID: <200903080133.n281XYCs002248@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3750
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #13 from Chris Lattner 2009-03-07 19:33:32 ---
This is not a compiler bug. The code also fails at -O0 if the exports array is
manually marked const. The reason for this that marking it const drops it into
a readonly section, which gets put after the text section. Because the global
contains pointers to other globals in it, it gets relocation entries for them.
Apparently the code in rtld.c cannot handle text relocations in RTLD itself,
which is the assertion that fires. Using attribute(used) is a good workaround,
but explicitly putting an attribute(section) on it to pin it to the data
section might be even better.
--
Configure bugmail: http://llvm.org/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 Mar 7 20:18:43 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 7 Mar 2009 20:18:43 -0600
Subject: [LLVMbugs] [Bug 3754] New: FunctionAttrs pass marks function with
MallocInst as readnone
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3754
Summary: FunctionAttrs pass marks function with MallocInst as
readnone
Product: libraries
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Interprocedural Optimizations
AssignedTo: unassignedbugs at nondot.org
ReportedBy: nicholas at mxc.ca
CC: llvmbugs at cs.uiuc.edu
$ cat m3.ll
define i32 @foo_malloc(i32 %n) nounwind noinline {
entry:
%0 = icmp eq i32 %n, 0 ; [#uses=1]
%iftmp.0.0 = select i1 %0, i32 1, i32 %n ;
[#uses=1]
%1 = malloc i8, i32 %iftmp.0.0 ; [#uses=1]
%2 = ptrtoint i8* %1 to i32 ; [#uses=1]
ret i32 %2
}
$ llvm-as < m3.ll | opt -functionattrs -stats -disable-output
===-------------------------------------------------------------------------===
... Statistics Collected ...
===-------------------------------------------------------------------------===
1 functionattrs - Number of functions marked readnone
That's wrong as can be seen from this C program:
#include
int foo_malloc(unsigned n) __attribute__((noinline));
int foo_malloc(unsigned n) {
return malloc(n ? n : 1);
}
int main(void) {
void *x, *y;
x = foo_malloc(10);
y = foo_malloc(10);
return x == y;
}
The malloc instruction does write to memory, but it's sorta a secret special
"new memory" pointer that no other pointer in LLVM can see. :) I'm filing this
bug instead of just fixing it because I'm not sure what the fix out to be.
Make FunctionAttrs treat MallocInst specially? Set
MallocInst->mayWriteToMemory() to true?
--
Configure bugmail: http://llvm.org/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 Mar 8 00:57:07 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Mar 2009 00:57:07 -0600
Subject: [LLVMbugs] [Bug 3751] SourceLocation of -> or .
In-Reply-To:
Message-ID: <200903080657.n286v7Fb013164@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3751
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sun Mar 8 05:28:32 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Mar 2009 05:28:32 -0500
Subject: [LLVMbugs] [Bug 3750] FreeBSD's ld-elf.so crashes on startup: data
not stored in .data .rel.ro.
In-Reply-To:
Message-ID: <200903081028.n28ASWtd022906@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3750
Ed Schouten changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
Summary|FreeBSD's ld-elf.so |FreeBSD's ld-elf.so crashes
|miscompiles when array is |on startup: data not stored
|marked as static |in .data.rel.ro.
--
Configure bugmail: http://llvm.org/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 Mar 8 07:05:02 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Mar 2009 07:05:02 -0500
Subject: [LLVMbugs] [Bug 3750] FreeBSD's ld-elf.so crashes on startup: data
not stored in .data .rel.ro.
In-Reply-To:
Message-ID: <200903081205.n28C52mA026089@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3750
Anton Korobeynikov changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |INVALID
--- Comment #15 from Anton Korobeynikov 2009-03-08 07:04:56 ---
(In reply to comment #14)
> It seems GCC stores the array in .data.rel.ro, while LLVM puts it in .rodata.
> It seems GCC does this because of -fpic.
Putting stuff into .data.rel.ro is just an optimization hint for linker, we
don't support it nowadays. Semantically it does not make any difference between
.rodata and .data.rel.ro.
--
Configure bugmail: http://llvm.org/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 Mar 8 09:30:56 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Mar 2009 09:30:56 -0500
Subject: [LLVMbugs] [Bug 3756] New: __attribute__((always_inline)) and
__builtin_constant_p
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3756
Summary: __attribute__((always_inline)) and __builtin_constant_p
Product: tools
Version: 2.5
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: llvm-gcc
AssignedTo: unassignedbugs at nondot.org
ReportedBy: madcoder at debian.org
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=2683)
--> (http://llvm.org/bugs/attachment.cgi?id=2683)
the sample source
llvm-gcc doesn't fold __builtin_constant_p inside
__attribute__((always_inline)) functions. The example is simple, in our code we
have:
__attribute__((always_inline)) static inline
void ifree(void *mem, mem_flags_t flags)
{
if (__builtin_constant_p(mem)) {
if (mem == NULL)
return;
}
if (__builtin_constant_p(flags)) {
switch (flags & MEM_POOL_MASK) {
case MEM_LIBC:
free(mem);
return;
default:
break;
}
}
__ifree(mem, flags);
}
We have lots of calls that look like: ifree(some_pointer, MEM_LIBC), and gcc
properly does constant folding. but llvm-gcc does not.
Attached are a C file, the .S file generated by gcc and the .S file generated
by llvm, where you can see that the former sees it should use a straight free()
call, and the latter calls __ifree.
--
Configure bugmail: http://llvm.org/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 Mar 8 10:36:44 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Mar 2009 10:36:44 -0500
Subject: [LLVMbugs] [Bug 3748] ImplicitValueExpr appears inside MemberExpr.
In-Reply-To:
Message-ID: <200903081536.n28FaiuI000748@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3748
bolzoni changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from bolzoni 2009-03-08 10:36:43 ---
If it is intended, fine.
--
Configure bugmail: http://llvm.org/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 Mar 8 13:38:52 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Mar 2009 13:38:52 -0500
Subject: [LLVMbugs] [Bug 3757] New: partial specialization doesn't preserve
attributes on call
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3757
Summary: partial specialization doesn't preserve attributes on
call
Product: libraries
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Interprocedural Optimizations
AssignedTo: unassignedbugs at nondot.org
ReportedBy: nicholas at mxc.ca
CC: llvmbugs at cs.uiuc.edu
The partial specialization pass doesn't preserve attributes on the call or
invoke instruction. That means things like tail call, but also all the
readnone/readonly noalias, sret, etc. This could cause a miscompilation for
anyone using partial specialization.
There's logic to copy attributes properly inside of DeadArgumentElimination.cpp
RemoveDeadStuffFromFunction(F) but it looks non-trivial to refactor.
--
Configure bugmail: http://llvm.org/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 Mar 8 13:48:08 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Mar 2009 13:48:08 -0500
Subject: [LLVMbugs] [Bug 3758] New: SmallVector::grow/swap should be shared
for POD T's
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3758
Summary: SmallVector::grow/swap should be shared for POD T's
Product: libraries
Version: 1.0
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Core LLVM classes
AssignedTo: unassignedbugs at nondot.org
ReportedBy: clattner at apple.com
CC: llvmbugs at cs.uiuc.edu
Looking at the exported symbol map of a couple of tools, I see a ton of things
like this:
llvm::SmallVectorImpl::grow(unsigned long)
llvm::SmallVectorImpl::grow(unsigned long)
llvm::SmallVectorImpl::grow(unsigned long)
llvm::SmallVectorImpl::grow(unsigned long)
llvm::SmallVectorImpl::grow(unsigned long)
llvm::SmallVectorImpl::grow(unsigned long)
llvm::SmallVectorImpl::grow(unsigned long)
llvm::SmallVectorImpl::grow(unsigned long)
llvm::SmallVectorImpl::operator=(llvm::SmallVectorImpl
const&)
These are all POD types, and there is no reason for them to all get their own
copy of these (somewhat large) methods. We only need to instantiate grow/swap
etc when T requires copy ctors etc.
--
Configure bugmail: http://llvm.org/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 Mar 8 14:41:08 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Mar 2009 14:41:08 -0500
Subject: [LLVMbugs] [Bug 3753] clang should warn about comparison with
string literal
In-Reply-To:
Message-ID: <200903081941.n28Jf8tH008537@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3753
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Chris Lattner 2009-03-08 14:41:08 ---
Mainline gcc has a similar warning, so I chose wording similar to it (but with
an explicit suggestion to use strcmp, something a newbie may not realize).
Implemented here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090302/013626.html
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at cs.uiuc.edu Sun Mar 8 15:02:52 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Mar 2009 15:02:52 -0500
Subject: [LLVMbugs] [Bug 3759] New: Assertion `i < getNumOperands() &&
"getOperand() out of range!"' failed.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3759
Summary: Assertion `i < getNumOperands() && "getOperand() out of
range!"' failed.
Product: libraries
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Common Code Generator Code
AssignedTo: unassignedbugs at nondot.org
ReportedBy: castet.matthieu at free.fr
CC: llvmbugs at cs.uiuc.edu
Hi,
I am trying to build ffmpeg with clang/llvm using r66380.
But I got "getOperand() out of range!" assertion on some files [1][2].
I don't know what you need to investigate the issue (I failed to create a small
testcase and -debug produce very large data).
To reproduce the problem :
$ svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
$ cd ffmpeg
$ ./configure --cc=ccc --enable-gpl --cpu=athlon-xp
$ clang -S -disable-free --relocation-model=static --unwind-tables=0
--fmath-errno=0 -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -I. -I./ffmpeg -g -O3 -Wundef
-std=c99 -o /tmp/tmpiqN2l-.s -x c ./libavcodec/motion_est.c
( using $ make should also show the problem)
[1]
$clang -S -disable-free --relocation-model=static --unwind-tables=0
--fmath-errno=0 -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -I. -I/home/mat/appli/ffmpeg -g -O3
-Wundef -std=c99 -o /tmp/tmpiqN2l-.s -x c
/home/mat/appli/ffmpeg/libavcodec/motion_est.c
clang: /mnt/data/tmp/llvm/llvm/include/llvm/CodeGen/MachineInstr.h:129:
llvm::MachineOperand& llvm::MachineInstr::getOperand(unsigned int): Assertion
`i < getNumOperands() && "getOperand() out of range!"' failed.
0 clang 0x08ddf9ee
1 clang 0x08ddff95
2 0xb7f8d400 __kernel_sigreturn + 0
3 libc.so.6 0xb7d07008 abort + 392
4 libc.so.6 0xb7cfe5ce __assert_fail + 238
5 clang 0x08492b22
6 clang 0x08b26f6b
7 clang 0x08b2be55
8 clang 0x08b2e18d
9 clang 0x08adc532
10 clang 0x0848bbf2
11 clang 0x08d6420c
12 clang 0x08d64cfa
13 clang 0x08d64e83
14 clang 0x0807ee8c
15 clang 0x0807ef8a
16 clang 0x082117ba
17 clang 0x080c64a6
18 clang 0x080c8799 main + 2016
19 libc.so.6 0xb7cf0775 __libc_start_main + 229
20 clang 0x080664f1
Stack dump:
0. Program arguments: clang -S -disable-free --relocation-model=static
--unwind-tables=0 --fmath-errno=0 -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -I.
-I/home/mat/appli/ffmpeg -g -O3 -Wundef -std=c99 -o /tmp/tmpiqN2l-.s -x c
/home/mat/appli/ffmpeg/libavcodec/motion_est.c -regalloc=local
1. parser at end of file
2. Code generation
3. Running pass 'Linear Scan Register Allocator' on function
'@sad_hpel_motion_search'
Abandon
[2]
(gdb) r -S -disable-free --relocation-model=static --unwind-tables=0
--fmath-errno=0 -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -I. -I/home/mat/appli/ffmpeg -g -O3
-Wundef -std=c99 -o /tmp/tmpiqN2l-.s -x c
/home/mat/appli/ffmpeg/libavcodec/motion_est.c
Starting program: /mnt/data/tmp/llvm/llvm/Debug/bin/clang -S -disable-free
--relocation-model=static --unwind-tables=0 --fmath-errno=0 -DHAVE_AV_CONFIG_H
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC99_SOURCE
-D_POSIX_C_SOURCE=200112 -I. -I/home/mat/appli/ffmpeg -g -O3 -Wundef -std=c99
-o /tmp/tmpiqN2l-.s -x c /home/mat/appli/ffmpeg/libavcodec/motion_est.c
[Thread debugging using libthread_db enabled]
clang: /mnt/data/tmp/llvm/llvm/include/llvm/CodeGen/MachineInstr.h:129:
llvm::MachineOperand& llvm::MachineInstr::getOperand(unsigned int): Assertion
`i < getNumOperands() && "getOperand() out of range!"' failed.
[New Thread 0xb7cf86d0 (LWP 17051)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7cf86d0 (LWP 17051)]
0xb7fad424 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fad424 in __kernel_vsyscall ()
#1 0xb7d25640 in raise () from /lib/i686/cmov/libc.so.6
#2 0xb7d27008 in abort () from /lib/i686/cmov/libc.so.6
#3 0xb7d1e5ce in __assert_fail () from /lib/i686/cmov/libc.so.6
#4 0x08492b22 in llvm::MachineInstr::getOperand (this=0x9ede350, i=21)
at /mnt/data/tmp/llvm/llvm/include/llvm/CodeGen/MachineInstr.h:129
#5 0x08b26f6b in hasLaterNon2AddrUse (MI=@0x9ede350, i=21, VirtReg=1720)
at VirtRegMap.cpp:1328
#6 0x08b2be55 in RewriteMBB (this=0x9cce658, MBB=@0xaf0946c, VRM=@0xad47b90,
Spills=@0xbfbc82d8, RegKills=@0xbfbc836c, KillOps=@0xbfbc8360)
at VirtRegMap.cpp:1658
#7 0x08b2e18d in runOnMachineFunction (this=0x9cce658, MF=@0xb795818,
VRM=@0xad47b90) at VirtRegMap.cpp:605
#8 0x08adc532 in runOnMachineFunction (this=0xa0bd390, fn=@0xb795818)
at RegAllocLinearScan.cpp:315
#9 0x0848bbf2 in llvm::MachineFunctionPass::runOnFunction (this=0xa0bd390,
F=@0x9c570d8)
at /mnt/data/tmp/llvm/llvm/include/llvm/CodeGen/MachineFunctionPass.h:42
#10 0x08d6420c in llvm::FPPassManager::runOnFunction (this=0xa0ab860,
F=@0x9c570d8) at PassManager.cpp:1327
#11 0x08d64cfa in llvm::FunctionPassManagerImpl::run (this=0xa0ab060,
F=@0x9c570d8) at PassManager.cpp:1284
#12 0x08d64e83 in llvm::FunctionPassManager::run (this=0xa07d3b0, F=@0x9c570d8)
---Type to continue, or q to quit---
at PassManager.cpp:1236
#13 0x0807ee8c in EmitAssembly (this=0x9a80f10) at Backend.cpp:420
#14 0x0807ef8a in HandleTranslationUnit (this=0x9a80f10, TU=@0x9a82700)
at Backend.cpp:151
#15 0x082117ba in clang::ParseAST (PP=@0x9a80ac8, Consumer=0x9a80f10,
TU=0x9a82700, PrintStats=false) at ParseAST.cpp:75
#16 0x080c64a6 in ProcessInputFile (PP=@0x9a80ac8, PPF=@0xbfbc8f7c,
InFile=@0x9a84b98, PA=EmitAssembly) at clang.cpp:1387
#17 0x080c8799 in main (argc=22, argv=0xbfbc90d4) at clang.cpp:1586
(gdb) p this
No symbol "this" in current context.
(gdb) up 3
#3 0xb7d1e5ce in __assert_fail () from /lib/i686/cmov/libc.so.6
(gdb) up
#4 0x08492b22 in llvm::MachineInstr::getOperand (this=0x9ede350, i=21)
at /mnt/data/tmp/llvm/llvm/include/llvm/CodeGen/MachineInstr.h:129
129 assert(i < getNumOperands() && "getOperand() out of range!");
(gdb) p this
$1 = (class llvm::MachineInstr * const) 0x9ede350
(gdb) p *this
$2 = {> = {Prev = 0xae8a5f8,
Next = 0x9ede400}, TID = 0x9130e84, NumImplicitOps = 0,
Operands = { >> = {
_M_impl = {> =
{<__gnu_cxx::new_allocator> = {}, },
_M_start = 0xbf16a70, _M_finish = 0xbf16c14,
_M_end_of_storage = 0xbf16cf0}}, },
MemOperands = { >> = {
_M_impl = { >> =
{<__gnu_cxx::new_allocator >> = {}, }, _M_node = {_M_next = 0x9ede36c,
_M_prev = 0x9ede36c}}}, }, Parent = 0xaf0946c,
debugLoc = {Idx = 4294967295}}
--
Configure bugmail: http://llvm.org/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 Mar 8 23:45:30 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Mar 2009 23:45:30 -0500
Subject: [LLVMbugs] [Bug 3743] -mmacosx-version-min inappropriate for Mac OS
X 10.4.11
In-Reply-To:
Message-ID: <200903090445.n294jUPN005969@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3743
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Chris Lattner 2009-03-08 23:45:26 ---
Fixed:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090302/074858.html
Please verify.
--
Configure bugmail: http://llvm.org/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 Mar 8 23:47:47 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Mar 2009 23:47:47 -0500
Subject: [LLVMbugs] [Bug 3746] Crash in isel with GEP of function pointer
In-Reply-To:
Message-ID: <200903090447.n294ll8M006072@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3746
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Chris Lattner 2009-03-08 23:47:46 ---
Fixed:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090302/074859.html
Opaque is specifically allowed because it is theoretically possible for the
opaque types to be resolved with llvm-link, and this is a pseudo-feature for
languages that want to lazily define their object model this way.
--
Configure bugmail: http://llvm.org/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 Mar 8 23:49:27 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Mar 2009 23:49:27 -0500
Subject: [LLVMbugs] [Bug 3760] New: simple loop pessimized by
-std-compile-opts
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3760
Summary: simple loop pessimized by -std-compile-opts
Product: libraries
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Loop Optimizer
AssignedTo: unassignedbugs at nondot.org
ReportedBy: nicholas at mxc.ca
CC: gohman at apple.com, llvmbugs at cs.uiuc.edu
This simple program:
define void @test(i32 %x, i32** %y) {
entry:
br label %loop
loop: ; preds = %loop, %entry
%tmp = phi i32 [ 0, %entry ], [ %tmp1, %loop ] ;
[#uses=1]
%tmp1 = add i32 %tmp, 1 ; [#uses=2]
%my = malloc i32 ; [#uses=1]
%z = getelementptr i32** %y, i32 %tmp
store i32* %my, i32** %z
%done = icmp eq i32 %tmp1, %x ; [#uses=1]
br i1 %done, label %out, label %loop
out: ; preds = %loop
ret void
}
is rewritten to use i64 induction variable and then zext/sext/trunc is added
all over to fix it up. On x86 the resulting .s is much worse.
--
Configure bugmail: http://llvm.org/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 Mar 8 23:51:02 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Mar 2009 23:51:02 -0500
Subject: [LLVMbugs] [Bug 3760] simple loop pessimized by -std-compile-opts
In-Reply-To:
Message-ID: <200903090451.n294p2k8006363@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3760
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Chris Lattner 2009-03-08 23:51:01 ---
Try adding a x86-32 target triple. Without it, the optimizer defaults to
optimizing for sparc 64.
--
Configure bugmail: http://llvm.org/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 Mar 8 23:51:28 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Mar 2009 23:51:28 -0500
Subject: [LLVMbugs] [Bug 3747] Crash in llvm-as with void field in struct
In-Reply-To:
Message-ID: <200903090451.n294pSDW006393@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3747
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Chris Lattner 2009-03-08 23:51:27 ---
This (and several other problems with void) is fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090302/074860.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 Mar 9 00:46:01 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 00:46:01 -0500
Subject: [LLVMbugs] [Bug 3744] Crash on index into zero element struct
In-Reply-To:
Message-ID: <200903090546.n295k1PO009475@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3744
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Summary|Field Idx out of range! |Crash on index into zero
| |element struct
--- Comment #2 from Chris Lattner 2009-03-09 00:46:01 ---
Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090309/074868.html
testcase here: test/FrontendC/2009-03-08-ZeroEltStructCrash.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 Mon Mar 9 00:52:36 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 00:52:36 -0500
Subject: [LLVMbugs] [Bug 3749] linker adds spurious use to appending globals
In-Reply-To:
Message-ID: <200903090552.n295qasX009756@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3749
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #4 from Chris Lattner 2009-03-09 00:52:36 ---
Ah, this should fix it. Please verify.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090309/074870.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 Mar 9 01:18:44 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 01:18:44 -0500
Subject: [LLVMbugs] [Bug 3676] ADT/hash_map raises warning on g++ 4.3
In-Reply-To:
Message-ID: <200903090618.n296IiGj010760@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3676
Nick Lewycky changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Nick Lewycky 2009-03-09 01:18:44 ---
Fixed by commits: 66398 66400 66406 66407
--
Configure bugmail: http://llvm.org/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 Mar 9 03:53:56 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 03:53:56 -0500
Subject: [LLVMbugs] [Bug 3761] New: inefficient codegen of x86 brcond/
select emits unnecessary comparison instructions
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3761
Summary: inefficient codegen of x86 brcond/select emits
unnecessary comparison instructions
Product: libraries
Version: 2.5
Platform: PC
URL: http://pastie.org/private/fofieg4h6gegqqkvxzynnq
OS/Version: All
Status: NEW
Keywords: code-quality, quality-of-implementation
Severity: enhancement
Priority: P2
Component: Backend: X86
AssignedTo: unassignedbugs at nondot.org
ReportedBy: just.s0m3.guy+llvmbugzilla at gmail.com
CC: llvmbugs at cs.uiuc.edu
The custom lowering code for BRCOND and SELECT in the X86 target backend
(X86ISelLowering.cpp) seems to always insert a comparison instruction.
This is not always necessary. If the conditional branch directly follows the
arithmetic operation, which sets the EFLAGS (such as ADD, SUB,...), which are
applicable to the specific condition which must be checked, there is no reason
to emit an additional comparison.
In the worst case, the additional comparison causes register moves and
copy-to-registers to be emitted, further bloating the output code.
For example, take the following c function:
//branchtest.c:
int main(){
int x = 1;
int y = 10;
x = x + y;
if(x>0)
return 1;
else
return 2;
}
Using llvm-gcc4.2-2.5 (release), the following llvm code is generated:
//branchtest.bc (gcc -c --emit-llvm branching.c -o branching.bc; llvm-dis <
branching.bc)
; ModuleID = ''
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"
target triple = "x86_64-unknown-linux-gnu"
define i32 @main() nounwind {
entry:
%retval = alloca i32 ; [#uses=2]
%y = alloca i32 ; [#uses=2]
%x = alloca i32 ; [#uses=4]
%0 = alloca i32 ; [#uses=3]
%"alloca point" = bitcast i32 0 to i32 ; [#uses=0]
store i32 1, i32* %x, align 4
store i32 10, i32* %y, align 4
%1 = load i32* %x, align 4 ; [#uses=1]
%2 = load i32* %y, align 4 ; [#uses=1]
%3 = add i32 %1, %2 ; [#uses=1]
store i32 %3, i32* %x, align 4
%4 = load i32* %x, align 4 ; [#uses=1]
%5 = icmp sgt i32 %4, 0 ; [#uses=1]
br i1 %5, label %bb, label %bb1
bb: ; preds = %entry
store i32 1, i32* %0, align 4
br label %bb2
bb1: ; preds = %entry
store i32 2, i32* %0, align 4
br label %bb2
bb2: ; preds = %bb1, %bb
%6 = load i32* %0, align 4 ; [#uses=1]
store i32 %6, i32* %retval, align 4
br label %return
return: ; preds = %bb2
%retval3 = load i32* %retval ; [#uses=1]
ret i32 %retval3
}
The problem occurs when trying to compile this to native x86, using llc:
/branching.s (llc -march=x86 -f branching.bc):
.file "branching/branching.bc"
.text
.align 16
.globl main
.type main, at function
main:
subl $16, %esp
movl $1, 4(%esp)
movl $10, 8(%esp)
movl 4(%esp), %eax
addl $10, %eax
movl %eax, 4(%esp)
testl %eax, %eax <==== this test is
unnecessary. the preceding addl sets the
flags correctly
jg .LBB1_4 # bb
.LBB1_1: # bb1
movl $2, (%esp)
.LBB1_2: # bb2
movl (%esp), %eax
movl %eax, 12(%esp)
.LBB1_3: # return
movl 12(%esp), %eax
addl $16, %esp
ret
.LBB1_4: # bb
movl $1, (%esp)
jmp .LBB1_2 # bb2
.size main, .-main
.section .note.GNU-stack,"", at progbits
Furthermore, it is unclear how exactly the desired functionality should be
implemented, as there don't appear to be an working examples.
--
Configure bugmail: http://llvm.org/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 Mar 9 04:29:49 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 04:29:49 -0500
Subject: [LLVMbugs] [Bug 3762] New: Constant folding methods need the
iterator treatment
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3762
Summary: Constant folding methods need the iterator treatment
Product: new-bugs
Version: unspecified
Platform: Other
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=2686)
--> (http://llvm.org/bugs/attachment.cgi?id=2686)
testcase .ll
When built with expensive checks,
opt -globalopt paq8p.bc -disable-output
barfs due to taking the address of the first
element of an empty vector. It happens here:
2216 if (Constant *C = ConstantFoldCall(Callee, &Formals[0],
2217 Formals.size())) {
This kind of problem was fixed elsewhere by
introducing methods that take iterators. It
looks like the constant methods need the same
treatment. The above code would then become
if (Constant *C = ConstantFoldCall(Callee, Formals.begin(),
Formals.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 cs.uiuc.edu Mon Mar 9 06:28:37 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 06:28:37 -0500
Subject: [LLVMbugs] [Bug 3763] New: Assertion failed: (getMinSignedBits() <=
64 && " Too many bits for int64_t"), function getSExtValue
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3763
Summary: Assertion failed: (getMinSignedBits() <= 64 && "Too many
bits for int64_t"), function getSExtValue
Product: libraries
Version: trunk
Platform: PC
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: Backend: X86
AssignedTo: unassignedbugs at nondot.org
ReportedBy: ed at 80386.nl
CC: llvmbugs at cs.uiuc.edu
Blocks: 3696
Created an attachment (id=2687)
--> (http://llvm.org/bugs/attachment.cgi?id=2687)
Testcase
When compiling the attached code with -O2, you get the following error:
Assertion failed: (getMinSignedBits() <= 64 && "Too many bits for int64_t"),
function getSExtValue, file llvm/include/llvm/ADT/APInt.h, line 1051.
Stack dump:
0. Program arguments: clang -S -disable-free --relocation-model=static
--disable-fp-elim --unwind-tables=0 --fmath-errno=1 -O2 -o - -x c test.c
1. parser at end of file
2. Code generation
3. Running pass 'X86 DAG->DAG Instruction Selection' on function
'@evUTCTime'
--
Configure bugmail: http://llvm.org/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 Mar 9 07:45:13 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 07:45:13 -0500
Subject: [LLVMbugs] [Bug 3764] New: A redefinition of a pre-processor macro
fails
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3764
Summary: A redefinition of a pre-processor macro fails
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: rich at pennware.com
CC: llvmbugs at cs.uiuc.edu
The clang pre-processor complains about the attached file.
According to the standard, the two definitions are identical.
--
Configure bugmail: http://llvm.org/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 Mar 9 11:14:29 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 11:14:29 -0500
Subject: [LLVMbugs] [Bug 3765] New: SourceLocation of ? and : in
clang::ConditionalOperator
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3765
Summary: SourceLocation of ? and : in clang::ConditionalOperator
Product: clang
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: AST
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: bolzoni at cs.unipr.it
CC: llvmbugs at cs.uiuc.edu, bagnara at cs.unipr.it
The clang::ConditionalOperator class does not seem to provide a way to get the
location of the operator's tokens themselves.
Would it possible add the member functions that return the location of `?' and
`:'?
--
Configure bugmail: http://llvm.org/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 Mar 9 14:01:03 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 14:01:03 -0500
Subject: [LLVMbugs] [Bug 3706] regalloc issue causes crash in fp stackifier
In-Reply-To:
Message-ID: <200903091901.n29J13PK015849@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3706
Evan Cheng changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #5 from Evan Cheng 2009-03-09 14:01:02 ---
Fixed.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090309/074886.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 Mar 9 15:22:53 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 15:22:53 -0500
Subject: [LLVMbugs] [Bug 3763] Assertion failed: (getMinSignedBits() <= 64
&& " Too many bits for int64_t"), function getSExtValue
In-Reply-To:
Message-ID: <200903092022.n29KMrK8018838@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3763
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Chris Lattner 2009-03-09 15:22:53 ---
Fixed:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090309/074891.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 Mar 9 15:33:55 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 15:33:55 -0500
Subject: [LLVMbugs] [Bug 3764] A redefinition of a pre-processor macro fails
In-Reply-To:
Message-ID: <200903092033.n29KXtEN019319@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3764
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Chris Lattner 2009-03-09 15:33:55 ---
Fixed, thanks!
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090309/013657.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 Mar 9 16:19:33 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 16:19:33 -0500
Subject: [LLVMbugs] [Bug 3767] New: static initializer-based registration
mechanism not portable
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3767
Summary: static initializer-based registration mechanism not
portable
Product: new-bugs
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: nlewycky at google.com
CC: llvmbugs at cs.uiuc.edu
Throughout the code, LLVM uses statically initialized variables with the
expectation that they will run before main. One example is registering the
possible backends, and the other is registering command line flags.
Quoth the Standard: It is implementation-defined whether or not the dynamic
initialization (8.5, 9.4, 12.1, 12.6.1) of an object of namespace scope is done
before the first statement of main. If the initialization is deferred to some
point in time after the first statement of main, it shall occur before the
first use of any function or object defined in the same translation unit as the
object to be initialized.
This mean that a static initializer need not execute until another function in
the TU is called. This comes up in MSVC++ and 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 Mon Mar 9 16:34:31 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 16:34:31 -0500
Subject: [LLVMbugs] [Bug 3724] JIT Memory Manager causes false error with
any RWX memory region fragmentation
In-Reply-To:
Message-ID: <200903092134.n29LYVoh021946@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3724
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #4 from Chris Lattner 2009-03-09 16:34:31 ---
Applied, thanks!
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090309/074923.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 Mar 9 16:44:25 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 16:44:25 -0500
Subject: [LLVMbugs] [Bug 3768] New: Clang does -D__STDC_HOSTED__=1,
even if -ffreestanding is passed.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3768
Summary: Clang does -D__STDC_HOSTED__=1, even if -ffreestanding
is passed.
Product: clang
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: ed at 80386.nl
CC: llvmbugs at cs.uiuc.edu
Blocks: 3696
Unlike GCC, Clang always defines -D__STDC_HOSTED__=1, even if -ffreestanding is
passed to the compiler. GCC defines -D__STDC_HOSTED__=0 in this case, which
seems to be the way it has to be 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 Mar 9 16:50:50 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 16:50:50 -0500
Subject: [LLVMbugs] [Bug 3768] Clang does -D__STDC_HOSTED__=1,
even if -ffreestanding is passed .
In-Reply-To:
Message-ID: <200903092150.n29LooND022596@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3768
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Chris Lattner 2009-03-09 16:50:50 ---
Fixed, thanks!
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090309/013670.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 Mar 9 17:53:09 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 17:53:09 -0500
Subject: [LLVMbugs] [Bug 3769] New: Crash with dot syntax on class methods
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3769
Summary: Crash with dot syntax on class methods
Product: clang
Version: unspecified
Platform: Macintosh
OS/Version: MacOS X
Status: NEW
Severity: normal
Priority: P2
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: catfish.man at gmail.com
CC: llvmbugs at cs.uiuc.edu
Created an attachment (id=2693)
--> (http://llvm.org/bugs/attachment.cgi?id=2693)
Test file
r66472 crashes on the attached preprocessed 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 Mon Mar 9 18:27:37 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 18:27:37 -0500
Subject: [LLVMbugs] [Bug 3759] regalloc crash (inline asm related?)
In-Reply-To:
Message-ID: <200903092327.n29NRbRj026526@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3759
Evan Cheng changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #5 from Evan Cheng 2009-03-09 18:27:37 ---
This is fixed by r66428. Please verify.
--
Configure bugmail: http://llvm.org/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 Mar 9 19:01:34 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 19:01:34 -0500
Subject: [LLVMbugs] [Bug 3769] Crash with dot syntax on class methods
In-Reply-To:
Message-ID: <200903100001.n2A01Y4J027799@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3769
snaroff at apple.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
--- Comment #3 from snaroff at apple.com 2009-03-09 19:01:33 ---
This doesn't crash for me. What platform? switches? Need more info to debug...
[steve-naroffs-imac-2:~/llvm/tools/clang] snaroff% cat crash.m
@interface Test {}
+ (Test *)crash;
@end
@implementation Test
- (void)cachesPath
{
static Test *cachesPath;
if (!cachesPath) {
Test *crash = Test.crash;
}
}
@end
[steve-naroffs-imac-2:~/llvm/tools/clang] snaroff% ../../Debug/bin/clang
crash.m
crash.m:5:1: warning: incomplete implementation
@implementation Test
^
crash.m:5:1: warning: method definition for 'crash' not found
2 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 Mon Mar 9 21:44:23 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Mar 2009 21:44:23 -0500
Subject: [LLVMbugs] [Bug 3743] -mmacosx-version-min inappropriate for Mac OS
X 10.4.11
In-Reply-To:
Message-ID: <200903100244.n2A2iNWh000383@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3743
Scott Michel changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #2 from Scott Michel 2009-03-09 21:44:23 ---
That gets the build a little farther. Now "-exported_symbol" is the next thing
build breaker.
--
Configure bugmail: http://llvm.org/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 Mar 10 00:14:25 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 10 Mar 2009 00:14:25 -0500
Subject: [LLVMbugs] [Bug 3771] New: [PATCH] EXEEXT missing in tool install,
causes llvm-gcc configure error in cygwin
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3771
Summary: [PATCH] EXEEXT missing in tool install, causes llvm-gcc
configure error in cygwin
Product: Build scripts
Version: 2.5
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Makefiles
AssignedTo: unassignedbugs at nondot.org
ReportedBy: baffo32 at gmail.com
CC: llvmbugs at cs.uiuc.edu, baffo32 at gmail.com
Patch for llvm/Makefile.rules
Although the binaries compiled by the llvm makefiles are given .exe extensions
on Windows, the extension is stripped when they are installed. The gcc
front-end package then refuses to configure against this installed llvm path
because the gcc configure script uses $(EXEEXT) when checking for llc. Adding
$(EXEEXT) to installed tool paths (as it already is for built tool paths) in
the llvm suite resolves 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 Mar 10 01:43:35 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 10 Mar 2009 01:43:35 -0500
Subject: [LLVMbugs] [Bug 3682] clang inline asm crash with + operand
constraint
In-Reply-To:
Message-ID: <200903100643.n2A6hZxO008223@zion.cs.uiuc.edu>
http://llvm.org/bugs/show_bug.cgi?id=3682
Chris Lattner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Chris Lattner 2009-03-10 01:43:35 ---
Fixed with many patches, culminating in:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090309/013710.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 Mar 10 08:34:58 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 10 Mar 2009 08:34:58 -0500
Subject: [LLVMbugs] [Bug 3773] New: Wrong encoding of a call instruction
when JITing on x86
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3773
Summary: Wrong encoding of a call instruction when JITing on x86
Product: libraries
Version: trunk
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Backend: X86
AssignedTo: unassignedbugs at nondot.org
ReportedBy: nicolas.geoffray at lip6.fr
CC: llvmbugs at cs.uiuc.edu
The following (useless and bugous) .ll program:
define void @main() {
start:
call void inttoptr (i64 0 to void ()*)()
ret void
}
Generates a wrong code when jitting on linux/x86 (and probably darwin/x86).
With llvm-svn, the result is:
JIT: Finished CodeGen of [0xb6d4f010] Function: main: 12 bytes of text, 0
relocations
JIT: Disassembled code:
b6d4f010: sub $0x4, %esp
b6d4f013: inc (%eax)
b6d4f015: add %al, (%eax)
b6d4f017: invalid
JIT: Binary code:
JIT: 00000000: ff04ec83 00000000 c304c483
With llvm-2.5, the result was:
JIT: Finished CodeGen of [0xb6d42010] Function: main: 11 bytes of text, 0
relocations
JIT: Disassembled code:
b6d42010: sub $0x4, %esp
b6d42013: xor %eax, %eax
b6d42015: call %eax
b6d42017: add $0x4, %esp
b6d4201a: ret
JIT: Binary code:
JIT: 00000000: 3104ec83 83d0ffc0 c304c4
--
Configure bugmail: http://llvm.org/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 Mar 10 09:11:01 2009
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 10 Mar 2009 09:11:01 -0500
Subject: [LLVMbugs] [Bug 3774] New: clang: ANALYZER_STORE_MODEL=region cast
failures
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=3774
Summary: clang: ANALYZER_STORE_MODEL=region cast failures
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: edwintorok at gmail.com
CC: llvmbugs at cs.uiuc.edu
I tested ANALYZER_STORE_MODEL=region, and I got some failures (with the default
store model I get no failures).
I know this feature is not yet ready, if you'd rather not receive bugreports
about it yet, please tell me.
$ grep clang: /tmp/scan-build-2009-03-10-3/failures/*.stderr.txt|cut -f2-
-d:|sort -u
clang: APInt.cpp:441: llvm::APInt llvm::APInt::operator+(const llvm::APInt&)
const: Assertion `BitWidth == RHS.BitWidth && "Bit widths must be the same"'
failed.
clang: GRExprEngine.cpp:2835: clang::SVal
clang::GRExprEngine::EvalBinOp(clang::BinaryOperator::Opcode, clang::SVal,
clang::SVal): Assertion `Op == BinaryOperator::Add || Op ==
BinaryOperator::Sub' failed.
clang: /home/edwin/llvm-svn/llvm/include/llvm/ADT/APSInt.h:226: llvm::APSInt
llvm::APSInt::operator+(const llvm::APSInt&) const: Assertion `IsUnsigned ==
RHS.IsUnsigned && "Signedness mismatch!"' failed.
clang: /home/edwin/llvm-svn/llvm/include/llvm/Support/Casting.h:199: typename
llvm::cast_retty::ret_type llvm::cast(const Y&) [with X =
clang::ElementRegion, Y = const clang::MemRegion*]: Assertion `isa