From bugzilla-daemon at cs.uiuc.edu Mon Dec 1 00:33:05 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Dec 2008 00:33:05 -0600 Subject: [LLVMbugs] [Bug 3123] clang miscompiling comma operator In-Reply-To: Message-ID: <200812010633.mB16X58u010335@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3123 Anders Carlsson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andersca at mac.com Status|RESOLVED |REOPENED Resolution|DUPLICATE | --- Comment #2 from Anders Carlsson 2008-12-01 00:33:04 --- Reopening this because it's somewhat different from 3060. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 1 00:44:27 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Dec 2008 00:44:27 -0600 Subject: [LLVMbugs] [Bug 3123] clang miscompiling comma operator In-Reply-To: Message-ID: <200812010644.mB16iREd010660@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3123 Anders Carlsson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #3 from Anders Carlsson 2008-12-01 00:44:26 --- Sending lib/AST/ExprConstant.cpp Transmitting file data . Committed revision 60334. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 1 00:45:07 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Dec 2008 00:45:07 -0600 Subject: [LLVMbugs] [Bug 3060] New IRgen of 'if' with constants is broken. In-Reply-To: Message-ID: <200812010645.mB16j7EO010697@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3060 Anders Carlsson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andersca at mac.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Anders Carlsson 2008-12-01 00:45:07 --- I think enough work has been done in this area to close it! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 1 11:45:49 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Dec 2008 11:45:49 -0600 Subject: [LLVMbugs] [Bug 3150] New: clang integer codegen bug Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3150 Summary: clang integer codegen bug 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 Using clang r60351 on Ubuntu Hardy on x86, the program below prints 0, whereas it should print 1. #include static int safe_mul_int_s_s (int si1, int si2) { return si1 * si2; } volatile int g_44; void func_38 (void); void func_38 (void) { g_44 = 1; return 1; } void func_18 (void); void func_18 (void) { if (safe_mul_int_s_s (1, 1 || 1)) { func_38 (); } } int main (void) { func_18 (); printf ("%d\n", g_44); 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 Mon Dec 1 13:28:00 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Dec 2008 13:28:00 -0600 Subject: [LLVMbugs] [Bug 3145] bogus "braces around scalar initializer" warning In-Reply-To: Message-ID: <200812011928.mB1JS0VS013205@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3145 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel at zuster.org Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #2 from Daniel Dunbar 2008-12-01 13:27:59 --- *** This bug has been marked as a duplicate of bug 2749 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 1 14:40:11 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Dec 2008 14:40:11 -0600 Subject: [LLVMbugs] [Bug 3147] Can no longer compile clang with gcc-4.2 on OpenBSD 4. 4 after r59835 In-Reply-To: Message-ID: <200812012040.mB1KeBSN016480@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3147 Constantine A. Murenin (cnst@{open,free}bsd.org) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Constantine A. Murenin (cnst@{open,free}bsd.org) 2008-12-01 14:40:10 --- (In reply to comment #2) > I believe this issue is fixed with r60364, but I can't verify it. Please test! http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20081201/009860.html Yes, indeed it does, the build is no longer broken. Marking FIXED, 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 Dec 1 14:55:18 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Dec 2008 14:55:18 -0600 Subject: [LLVMbugs] [Bug 3151] New: SelectionDAGLowering::Clusterify fails on 128 bit constants Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3151 Summary: SelectionDAGLowering::Clusterify fails on 128 bit constants 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=2251) --> (http://llvm.org/bugs/attachment.cgi?id=2251) testcase.ll The x86-64 linux build of the Fortran front-end fails with: APInt.h:1049: int64_t llvm::APInt::getSExtValue() const: Assertion `getMinSignedBits() <= 64 && "Too many bits for int64_t"' failed. This is because Clusterify is using getSExtValue, which doesn't work for 128 bit values. To reproduce: llc testcase.bc -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 1 15:42:02 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Dec 2008 15:42:02 -0600 Subject: [LLVMbugs] [Bug 3146] intrinsics declarations, when passed through llc -march=cpp, fail verification In-Reply-To: Message-ID: <200812012142.mB1Lg2na018526@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3146 Dale Johannesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Dale Johannesen 2008-12-01 15:42:01 --- Let's close then. We don't normally port fixes back into the releases (snapshots, really). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 1 16:20:09 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Dec 2008 16:20:09 -0600 Subject: [LLVMbugs] [Bug 3151] SelectionDAGLowering::Clusterify fails on 128 bit constants In-Reply-To: Message-ID: <200812012220.mB1MK9WG019824@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3151 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |asl at math.spbu.ru Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Anton Korobeynikov 2008-12-01 16:20:09 --- Yep, I know. Switch lowering appeared parallel to APInt stuff *** This bug has been marked as a duplicate of bug 3032 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 1 18:55:12 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Dec 2008 18:55:12 -0600 Subject: [LLVMbugs] [Bug 3152] New: optimizers fail to fold a load from bitcast pointer to a constant global Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3152 Summary: optimizers fail to fold a load from bitcast pointer to a constant global 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 follows; opt -std-compile-opts doesn't know how to fold it. Not that I really blame the LLVM optimizers, but this is the cause of a failure in the clang regression tests, and it shouldn't be that difficult to fix. 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 = "i686-pc-linux-gnu" %struct.s0 = type <{ i8, i8, i8, i8, i8, i8, i8, i8 }> internal constant %struct.s0 <{ i8 -17, i8 -66, i8 -17, i8 -66, i8 -83, i8 14, i8 0, i8 0 }> ; <%struct.s0*>:1 [#uses=1] define i32 @g0() nounwind readonly { entry: %tmp10.i = load i64* bitcast (%struct.s0* @0 to i64*), align 8 %tmp316.i = trunc i64 %tmp10.i to i32 ; [#uses=2] ret i32 %tmp316.i } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 1 20:16:21 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Dec 2008 20:16:21 -0600 Subject: [LLVMbugs] [Bug 3124] VirtRegMap: Assertion `KillRegs[0] == Dst || TRI->isSubRegister( KillRegs[0], Dst)' failed In-Reply-To: Message-ID: <200812020216.mB22GL8V027149@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3124 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Evan Cheng 2008-12-01 20:16:21 --- Fixed. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081201/070626.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 Dec 2 10:06:11 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 2 Dec 2008 10:06:11 -0600 Subject: [LLVMbugs] [Bug 3150] clang integer codegen bug In-Reply-To: Message-ID: <200812021606.mB2G6BhJ030383@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3150 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sharparrow1 at yahoo.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Eli Friedman 2008-12-02 10:05:49 --- Fixed in r60415; turns out the testcase simplifies to "int a() {return 1||1;}" getting miscompiled. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 2 14:31:32 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 2 Dec 2008 14:31:32 -0600 Subject: [LLVMbugs] [Bug 3107] No patterns for certain truncate operations. In-Reply-To: Message-ID: <200812022031.mB2KVWYD007287@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3107 Tilmann Scheller changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Tilmann Scheller 2008-12-02 14:31:32 --- Fixed in r60438 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 2 19:02:43 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 2 Dec 2008 19:02:43 -0600 Subject: [LLVMbugs] [Bug 3153] New: OCaml binding's Makefile.ocaml creates incorrect symlinks Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3153 Summary: OCaml binding's Makefile.ocaml creates incorrect symlinks Product: Build scripts Version: 2.4 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Makefiles AssignedTo: unassignedbugs at nondot.org ReportedBy: salimma at fedoraproject.org CC: llvmbugs at cs.uiuc.edu The build target 'install-deplibs' in Makefile.ocaml links files in $(PROJ_libdir) to $(PROJ_libocamldir). Unfortunately, when used within many build systems, all the $(PROJ_*) have $(DESTDIR) prepended to them, meaning the links created are invalid within the installed system. The proper fix, using autoconf/automake/configure, is to have all the PROJ_* variables *not* contain DESTDIR, and using $(DESTDIR)$(PROJ_*) in all the install targets. But if llvm is moving to cmake in the near future, it might not be worth fixing this. My current workaround is to patch Makefile.ocaml to use $(OVERRIDE_libdir) instead of $(PROJ_libdir) and pass the right value to 'make install' -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 2 19:29:39 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 2 Dec 2008 19:29:39 -0600 Subject: [LLVMbugs] [Bug 3122] PPC vector operations failing in "make check" using llvm-gcc In-Reply-To: Message-ID: <200812030129.mB31TdNO017123@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3122 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Dan Gohman 2008-12-02 19:29:38 --- Fixed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081201/070680.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 Dec 3 04:14:35 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 3 Dec 2008 04:14:35 -0600 Subject: [LLVMbugs] [Bug 3154] New: Assertion `I->contains(Start) && I->contains(End-1) && " Range is not entirely in interval!"' failed in llc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3154 Summary: Assertion `I->contains(Start) && I->contains(End-1) && "Range is not entirely in interval!"' failed in 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: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=2256) --> (http://llvm.org/bugs/attachment.cgi?id=2256) Testcase llc: LiveInterval.cpp:257: void llvm::LiveInterval::removeRange(unsigned int, unsigned int, bool): Assertion `I->contains(Start) && I->contains(End-1) && "Range is not entirely in interval!"' failed. Attached testcase is bugpoint-reduced from libavcodec/i386/flacdsp_mmx.c in ffmpeg; to reproduce, run llc on the attached on x86. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 3 05:02:04 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 3 Dec 2008 05:02:04 -0600 Subject: [LLVMbugs] [Bug 3140] .file directive is not emitted In-Reply-To: Message-ID: <200812031102.mB3B24H5011447@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3140 Rafael ??vila de Esp??ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #8 from Rafael ??vila de Esp??ndola 2008-12-03 05:02:01 --- Fixed on revision 60480. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 3 09:20:57 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 3 Dec 2008 09:20:57 -0600 Subject: [LLVMbugs] [Bug 3156] New: Couldn't allocate output reg for constraint 'r' (x86_32/OSX ) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3156 Summary: Couldn't allocate output reg for constraint 'r' (x86_32/OSX) Product: new-bugs Version: unspecified Platform: PC OS/Version: MacOS X Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sveina at gmail.com CC: llvmbugs at cs.uiuc.edu While attempting to rewire the mplayer build system for LLVM, I ran into this bug in llc. It is not overly surprising, as mplayer uses a lot of inline assembly that use every register available, but it still probably counts as a bug. It was produced with minimal changes to mplayer, merely substituting llvm-foo for its normal toolchain and doing the linking manually. Both the bugpoint reduced code, and the final output of the compilation process is 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 Dec 3 09:38:58 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 3 Dec 2008 09:38:58 -0600 Subject: [LLVMbugs] [Bug 3157] New: Couldn't allocate output reg for constraint 'r' (x86_32/OSX ) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3157 Summary: Couldn't allocate output reg for constraint 'r' (x86_32/OSX) Product: new-bugs Version: unspecified Platform: PC OS/Version: MacOS X Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: edwintorok at gmail.com CC: asl at math.spbu.ru, llvmbugs at cs.uiuc.edu, edwintorok at gmail.com, sveina at gmail.com Depends on: 3156 +++ This bug was initially created as a clone of Bug #3156 +++ Here is the segfault I see with mplayer.bc (this is a separate bug), look like it infloops: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fc4151256f0 (LWP 28146)] 0x0000000000a58b3e in (anonymous namespace)::RALinScan::getFreePhysReg () Current language: auto; currently asm#0 0x0000000000a58b3e in (anonymous namespace)::RALinScan::getFreePhysReg () #1 0x0000000000a5993d in (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval () #2 0x0000000000a5a503 in (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval () #3 0x0000000000a5a503 in (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval () #4 0x0000000000a5a503 in (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval () #5 0x0000000000a5a503 in (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval () #6 0x0000000000a5a503 in (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval () #7 0x0000000000a5a503 in (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval () #8 0x0000000000a5a503 in (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval () ..... #5452 0x0000000000a5a503 in (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval () #5453 0x0000000000a5a503 in (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval () #5454 0x0000000000a5a503 in (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval () #5455 0x0000000000a5a503 in (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval () #5456 0x0000000000a5c7eb in (anonymous namespace)::RALinScan::linearScan () #5457 0x0000000000a5d311 in (anonymous namespace)::RALinScan::runOnMachineFunction () #5458 0x0000000000bc799b in llvm::FPPassManager::runOnFunction () #5459 0x0000000000bc7d96 in llvm::FunctionPassManagerImpl::run () #5460 0x0000000000bc7f1e in llvm::FunctionPassManager::run () #5461 0x00000000004fe9c1 in main () -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 3 14:11:54 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 3 Dec 2008 14:11:54 -0600 Subject: [LLVMbugs] [Bug 3160] New: llvm-gcc bootstrap internal error during pch generation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3160 Summary: llvm-gcc bootstrap internal error during pch generation 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 SVN r60482 fails to bootstrap on my nightly cronjob. It failed yesterday too with same problem (I didn't have time to file bug yesterday, sorry). $ /home/edwin/llvm-bootstrap/llvm-obj/./gcc/xgcc -shared-libgcc -B/home/edwin/llvm-bootstrap/llvm-obj/./gcc -nostdinc++ -L/home/edwin/llvm-bootstrap/llvm-obj/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/edwin/llvm-bootstrap/llvm-obj/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/edwin/llvm-bootstrap/llvm-obj/../install/x86_64-unknown-linux-gnu/bin/ -B/home/edwin/llvm-bootstrap/llvm-obj/../install/x86_64-unknown-linux-gnu/lib/ -isystem /home/edwin/llvm-bootstrap/llvm-obj/../install/x86_64-unknown-linux-gnu/include -isystem /home/edwin/llvm-bootstrap/llvm-obj/../install/x86_64-unknown-linux-gnu/sys-include -x c++-header x.i In file included from /home/edwin/llvm-bootstrap/llvm-gcc4.2/libstdc++-v3/include/precompiled/stdc++.h:86: /home/edwin/llvm-bootstrap/llvm-obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/valarray:1037: internal compiler error: Segmentation fault Please submit a full bug report, -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 3 14:14:29 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 3 Dec 2008 14:14:29 -0600 Subject: [LLVMbugs] [Bug 3161] New: llc -mach=cellspu adds dash dot (-.) to branch targets Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3161 Summary: llc -mach=cellspu adds dash dot (-.) to branch targets 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: snowm at us.ibm.com CC: llvmbugs at cs.uiuc.edu For the c language input: void sub1(void) { printf("in sub1\n"); } int main(unsigned long long id) { sub1(); printf("returned from sub1\n"); return 0; } When the llc command with the option -march=cellspu is run, the code generated in the assembly file: brsl $lr, sub1-. should not have the -. appended to the target. If the -. is removed and the code is assembled and linked for the spu the test will execute successfully. Note that external symbols such as: brasl $lr, printf do not have the decoration. The same bitcode will generate correct output with the llc command and the -march=ppc32: bl sub1 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 3 15:33:02 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 3 Dec 2008 15:33:02 -0600 Subject: [LLVMbugs] [Bug 3163] New: llvm-gcc generates incorrect LLVM IR for weakref Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3163 Summary: llvm-gcc generates incorrect LLVM IR for weakref Product: tools Version: 2.4 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: llvm-gcc AssignedTo: unassignedbugs at nondot.org ReportedBy: jasandov at rice.edu CC: llvmbugs at cs.uiuc.edu Created an attachment (id=2263) --> (http://llvm.org/bugs/attachment.cgi?id=2263) proposed patch llvm-gcc generates incorrect LLVM IR for certain cases that use weakref (weakref is described here: http://people.redhat.com/aoliva/writeups/weakref/weakref.txt). Consider the two c programs: /* weakref_noref.c: */ extern void foo(void); static void foo_alias(void) __attribute__ ((weakref("foo"))); int main() { if (foo_alias) foo_alias(); return 0; } /* weakref_ref.c: */ extern void foo(void); static void foo_alias(void) __attribute__ ((weakref("foo"))); int main() { if (foo_alias) foo_alias(); foo(); return 0; } foo is declared as an external function, and foo_alias is defined as a weakref to foo. In the first example, foo is never referenced in the file, so the semantics of weakref dictate that foo (the target of the weakref) should be changed to an external weak symbol. In the second example, foo is referenced so it should remain unchanged by the weakref definition. In both cases, the uses of foo_alias should be replaced with foo (since foo_alias is an internal symbol, all uses are known). Compiling these files with llvm-gcc results in a correct object file, but the LLVM IR is incorrect. The assembly output from the native code generator is not technically correct, but it still seems to result in correct object file. The problem really appears in the CBE, as discovered in bug #3059. The output from the standard gcc installation uses the .weakref directive in the assembly output: $ gcc -S weakref_noref.c weakref_ref.c $ grep foo weakref_noref.s weakref_ref.s weakref_noref.s: movl $foo_alias, %eax weakref_noref.s: call foo_alias weakref_noref.s: .weakref foo_alias,foo weakref_ref.s: movl $foo_alias, %eax weakref_ref.s: call foo_alias weakref_ref.s: call foo weakref_ref.s: .weakref foo_alias,foo The output from llvm-gcc with the x86-64 backend uses the .weak directive, incorrectly specifying the foo_alias as weak: $ llvm-gcc -S weakref_noref.c weakref_ref.c $ grep foo weakref_noref.s weakref_ref.s weakref_noref.s: leaq foo_alias, %rax weakref_noref.s: call foo_alias weakref_noref.s: .weak foo_alias weakref_noref.s: .set foo_alias, foo weakref_noref.s: .weak foo weakref_ref.s: leaq foo_alias, %rax weakref_ref.s: call foo_alias weakref_ref.s: call foo weakref_ref.s: .weak foo_alias weakref_ref.s: .set foo_alias, foo The LLVM IR output confirms the incorrect definition for the alias: $ llvm-gcc -S -emit-llvm weakref_noref.c weakref_ref.c $ grep foo weakref_noref.s weakref_ref.s weakref_noref.s:@foo_alias = alias weak void ()* @foo ; [#uses=2] weakref_noref.s: br i1 icmp ne (void ()* @foo_alias, void ()* null), label %bb, label %bb1 weakref_noref.s: call void @foo_alias() nounwind weakref_noref.s:declare extern_weak void @foo() weakref_ref.s:@foo_alias = alias weak void ()* @foo ; [#uses=2] weakref_ref.s: br i1 icmp ne (void ()* @foo_alias, void ()* null), label %bb, label %bb1 weakref_ref.s: call void @foo_alias() nounwind weakref_ref.s: call void @foo() nounwind weakref_ref.s:declare void @foo() The declaration of foo appears correct, since it is an extern_weak declaration for the case where foo is not referenced (other than through weakref) and it is a normal (strong) declaration for the case in which foo is referenced. However, the definition of foo_alias is incorrect -- it is defined as a weak alias, but it should be an internal alias (since the definition in the c source code is static). The alias itself (from a weakref) should not be weak. Since LLVM does not currently have the capability to represent a weakref, it seems easiest to resolve all weakrefs in the llvm-gcc front end before generating LLVM IR. In fact, since the weakref is basically an internal alias, we can eliminate the alias and replace all uses with the aliasee. Essentially, this is what the assembler does for the .weakref directive (http://people.redhat.com/aoliva/writeups/weakref/weakref.txt). I have attached a proposed patch to do this. Using my patched version of llvm-gcc, I now get the following output: $ llvm-gcc -S weakref_noref.c weakref_ref.c $ grep foo weakref_noref.s weakref_ref.s weakref_noref.s: leaq foo, %rax weakref_noref.s: call foo weakref_noref.s: .weak foo weakref_ref.s: call foo weakref_ref.s: call foo $ llvm-gcc -S -emit-llvm weakref_noref.c weakref_ref.c $ grep foo weakref_noref.s weakref_ref.s weakref_noref.s: br i1 icmp ne (void ()* @foo, void ()* null), label %bb, label %bb1 weakref_noref.s: call void @foo() nounwind weakref_noref.s:declare extern_weak void @foo() weakref_ref.s: call void @foo() nounwind weakref_ref.s: call void @foo() nounwind weakref_ref.s:declare void @foo() As shown, all uses of foo_alias are replaced with the target of the weakref (foo). The declaration for foo is correct for both cases (it is extern_weak when foo is only referenced through weakref, and it is extern when foo is referenced directly). The x86-64 native code generator now generates correct assembly code and the CBE generates correct code (since there is no alias to deal with anymore). This patch should also resolve the problem in bug #3059. Could somebody more knowledgeable about the guts of llvm-gcc take a look at the patch and provide some feedback? It works for this case, but that definitely doesn't mean it's correct. 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 Dec 3 17:23:47 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 3 Dec 2008 17:23:47 -0600 Subject: [LLVMbugs] [Bug 3164] New: two constructors generated. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3164 Summary: two constructors generated. Product: clang Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: akasim at swri.org CC: llvmbugs at cs.uiuc.edu Note sure if this is right but I see that for each c++ constructor, I get two corresponding identical functions. Example class foo{ too(){}; }; I get these two functions: define void @_ZN3tooC1Ev(%struct.foo* %this); define void @_ZN3tooC2Ev(%struct.foo* %this); the bodies of these two functions are identical. Is this a bug ? Also, is there any documentation on how the function names are generated? I see that its always _ZN3, followed by struct name, followed by C (for constructor), followed by 1 or 2, then E, and then argument type infos. But I would like to see a document where the naming scheme is officially explained. Thanks. -Arif Kasim. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 3 17:53:11 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 3 Dec 2008 17:53:11 -0600 Subject: [LLVMbugs] [Bug 3164] two constructors generated. In-Reply-To: Message-ID: <200812032353.mB3NrB92004676@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3164 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #2 from Chris Lattner 2008-12-03 17:53:09 --- This is correct behavior and required by the C++ ABI, please see: http://www.codesourcery.com/public/cxx-abi/ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 4 21:13:20 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 4 Dec 2008 21:13:20 -0600 Subject: [LLVMbugs] [Bug 3165] New: removing ModuleProvider from ExecutionEngine doesn' t remove reverse global mappings Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3165 Summary: removing ModuleProvider from ExecutionEngine doesn't remove reverse global mappings 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: flld0 at greynode.net CC: llvmbugs at cs.uiuc.edu Created an attachment (id=2266) --> (http://llvm.org/bugs/attachment.cgi?id=2266) Code to demonstrate the problem When a module provider is removed from the ExecutionEngine, forward mappings from the module's GlobalValues are removed, but the reverse mappings remain. The problem seems to me to be in ExecutionEngine::clearGlobalMappingsFromModule. It loops over the module's global mappings, calling std::map<...>::erase(...) on both the forward and reverse maps. However, the variant of erase being called is the erase-by-key variant, and the GlobalValue * is passed to both calls. It's the key in the first map, but the value in the second. The obvious fix would be to look up the GlobalValue * in the first map to get the void * address, then erase the address from the reverse map and the GlobalValue * from the forward map. But: I've had one LLVM developer (Nickolas Lewycky) suggest to me, as a workaround for another problem, mapping multiple GlobalValue *'s to the same address. I'm not too worried about my particular workaround case, but if there are other more significant cases where multiple GlobalValue *'s map to the same address, then the whole notion of storing the reverse mapping in a single-valued map doesn't work. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 4 21:57:55 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 4 Dec 2008 21:57:55 -0600 Subject: [LLVMbugs] [Bug 3166] New: Patch to demangle function names when printing stack trace Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3166 Summary: Patch to demangle function names when printing stack trace Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Support Libraries AssignedTo: unassignedbugs at nondot.org ReportedBy: wesleypeck at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=2267) --> (http://llvm.org/bugs/attachment.cgi?id=2267) demangle function names during stack trace When an LLVM assertion fails a stack trace is produced during the subsequent abort. This patch adds support for demangling the function names printed out during this stack trace. Function names are demangled only if the header file dlfcn.h is present and only when compiling LLVM with GCC. The patch has been tested on OS X 10.5 but should work on linux as well. -- Wesley Peck -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 4 23:09:05 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 4 Dec 2008 23:09:05 -0600 Subject: [LLVMbugs] [Bug 3167] New: Sema:: CheckForConstantInitializer should pedwarn if a constant is not a strict constant Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3167 Summary: Sema::CheckForConstantInitializer should pedwarn if a constant is not a strict constant Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: andersca at mac.com CC: llvmbugs at cs.uiuc.edu "strict" being as defined in the C99 spec. We used to do this for the example below (in test/Sema/constant-builtins.c) but that warning was removed when PR3130 was fixed. short t = __builtin_constant_p(5353) ? 42 : somefunc(); // expected-warning {{expression is not a constant, but is accepted as one by GNU extensions}} -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 4 23:11:21 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 4 Dec 2008 23:11:21 -0600 Subject: [LLVMbugs] [Bug 3130] "int a = 2.0 ? 1 : 2;" crashes clang In-Reply-To: Message-ID: <200812050511.mB55BL8Z003171@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3130 Anders Carlsson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Anders Carlsson 2008-12-04 23:11:20 --- Sending lib/Sema/SemaDecl.cpp Adding test/CodeGen/PR3130-cond-constant.c Sending test/Sema/constant-builtins.c Transmitting file data ... Committed revision 60580. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 4 23:26:40 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 4 Dec 2008 23:26:40 -0600 Subject: [LLVMbugs] [Bug 3168] New: Assertion failure when using ocaml GC Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3168 Summary: Assertion failure when using ocaml GC Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: wesleypeck at gmail.com CC: llvmbugs at cs.uiuc.edu The LLVM code shown below causes an assertion failure: declare ccc void @oread_runtime_casenotcovered() declare void @llvm.gcroot(i8**,i8*) define i32* @append() gc "ocaml" { entry: switch i32 0, label %L2 [i32 0, label %L1] L1: %var8 = alloca i8* call void @llvm.gcroot(i8** %var8,i8* null) br label %L3 L2: call ccc void @oread_runtime_casenotcovered() unreachable L3: ret i32* null } Playing around with the code a bit, I have found that the assertion can be eliminated by doing any of the following: 1) Using the shadow-stack GC instead of the ocaml GC 2) Using opt between llvm-as and llc 3) Moving the alloca instruction to right below the entry label The assertion produced is the following: Assertion failed: (isa(Val) && "cast() argument of incompatible type!"), function cast, file /Users/peckw/Projects/llvm/llvm/include/llvm/Support/Casting.h, line 199. 0 llc 0x00953d9c _ZNSt8_Rb_treeIN4llvm3sys4PathES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE13insert_uniqueERKS2_ + 7948 1 libSystem.B.dylib 0x926da09b _sigtramp + 43 2 ??? 0xffffffff 0x0 + 4294967295 3 libSystem.B.dylib 0x92752ec2 raise + 26 4 libSystem.B.dylib 0x9276247f abort + 73 5 libSystem.B.dylib 0x92754063 __assert_rtn + 101 6 llc 0x005f2c36 _ZN4llvm15CvtRndSatSDNodeD1Ev + 90918 7 llc 0x005f30f6 _ZN4llvm15CvtRndSatSDNodeD1Ev + 92134 8 llc 0x00620263 _ZN4llvm15CvtRndSatSDNodeD1Ev + 276819 9 llc 0x0062e0ac _ZN4llvm4castINS_18DbgRegionStartInstENS_8CallInstEEENS_10cast_rettyIT_T0_E8ret_typeERKS5_ + 29212 10 llc 0x0062f3a4 _ZN4llvm4castINS_18DbgRegionStartInstENS_8CallInstEEENS_10cast_rettyIT_T0_E8ret_typeERKS5_ + 34068 11 llc 0x00630f43 _ZN4llvm4castINS_18DbgRegionStartInstENS_8CallInstEEENS_10cast_rettyIT_T0_E8ret_typeERKS5_ + 41139 12 llc 0x008cf49f _ZN4llvm12FunctionPassD1Ev + 33983 13 llc 0x008cfa38 _ZN4llvm12FunctionPassD1Ev + 35416 14 llc 0x008cfbe6 _ZN4llvm12FunctionPassD1Ev + 35846 15 llc 0x000030a7 _mh_execute_header + 8359 16 llc 0x00001d36 _mh_execute_header + 3382 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 5 06:04:50 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 5 Dec 2008 06:04:50 -0600 Subject: [LLVMbugs] [Bug 2843] llvm-gcc has -Wformat-nonliteral on by default, can' t switch it off In-Reply-To: Message-ID: <200812051204.mB5C4oIe025968@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2843 Rafael ??vila de Esp??ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #11 from Rafael ??vila de Esp??ndola 2008-12-05 06:04:49 --- Fixed in revision 60589 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 5 06:09:34 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 5 Dec 2008 06:09:34 -0600 Subject: [LLVMbugs] [Bug 3169] New: assert failure while building libgfortarn on linux x86-64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3169 Summary: assert failure while building libgfortarn on linux x86- 64 Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: llc AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=2269) --> (http://llvm.org/bugs/attachment.cgi?id=2269) testcase While building libgfortran on linux x86-64 the attached file causes an assertion failure. To reproduce /usr/local/espindola/llvm/llvm-gcc-build/./gcc/cc1 -fpreprocessed pow_i16_i4.i -quiet -dumpbase pow_i16_i4.c -mtune=generic -auxbase-strip .libs/pow_i16_i4.o -g -O2 -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -std=gnu99 -version -fPIC -o pow_i16_i4.s -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 5 06:13:43 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 5 Dec 2008 06:13:43 -0600 Subject: [LLVMbugs] [Bug 3169] assert failure while building libgfortarn on linux x86-64 In-Reply-To: Message-ID: <200812051213.mB5CDhbL026301@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3169 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |asl at math.spbu.ru Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #2 from Anton Korobeynikov 2008-12-05 06:13:42 --- *** This bug has been marked as a duplicate of bug 3032 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 5 10:27:23 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 5 Dec 2008 10:27:23 -0600 Subject: [LLVMbugs] [Bug 2845] ICE doesn't like cast to non-integer types In-Reply-To: Message-ID: <200812051627.mB5GRNIU001388@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2845 Anders Carlsson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andersca at mac.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Anders Carlsson 2008-12-05 10:27:20 --- We now support this - ExprConstant just need to have more warnings about ICEs - but I think that's tracked in a separate bug. Let's close this. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 5 10:36:40 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 5 Dec 2008 10:36:40 -0600 Subject: [LLVMbugs] [Bug 2963] "enumerator value is not an integer constant" error when using macros In-Reply-To: Message-ID: <200812051636.mB5GaeFa001795@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2963 Anders Carlsson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Anders Carlsson 2008-12-05 10:36:35 --- Sending include/clang/Basic/DiagnosticKinds.def Sending lib/Sema/SemaDecl.cpp Adding test/Sema/PR2963-enum-constant.c Transmitting file data ... Committed revision 60591. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 5 13:05:40 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 5 Dec 2008 13:05:40 -0600 Subject: [LLVMbugs] [Bug 2354] readdir broken with -D_FILE_OFFSET_BITS=64 ( asm on func discarded) In-Reply-To: Message-ID: <200812051905.mB5J5ecU006985@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2354 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #2 from Eli Friedman 2008-12-05 13:05:37 --- Yes, appears to be 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 Fri Dec 5 14:17:55 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 5 Dec 2008 14:17:55 -0600 Subject: [LLVMbugs] [Bug 3166] Patch to demangle function names when printing stack trace In-Reply-To: Message-ID: <200812052017.mB5KHtS9009739@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3166 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Dan Gohman 2008-12-05 14:17:47 --- Thanks for the patch! I modified it to better fit with LLVM coding style, and fixed a few bugs -- dli_sname can be NULL if no symbol is found, and fprintf shouldn't be used without a format string -- and I tested it on an Ubuntu Intrepid box, and applied it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Dec 6 16:04:51 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 6 Dec 2008 16:04:51 -0600 Subject: [LLVMbugs] [Bug 3170] New: loop unswitch never unswitches any loops Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3170 Summary: loop unswitch never unswitches any loops 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: dpatel at apple.com, llvmbugs at cs.uiuc.edu Take even the most trivial loop to unswitch: int a(int x, int y) { for (unsigned i = 0; i < y; i++) { if (x) { b(); } }return 0; } Loop unswitch somehow can't manage to unswitch it. The cause here is r58631; it changed FindLIVLoopCondition so that it always returns null, which means the unswitcher can never find any conditions to unswitch on. I somehow doubt that was the intention, but I can't figure out what it was trying 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 Sat Dec 6 16:28:39 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 6 Dec 2008 16:28:39 -0600 Subject: [LLVMbugs] [Bug 3171] New: not optimizing trivial loop (trip count computation) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3171 Summary: not optimizing trivial loop (trip count computation) Product: libraries Version: 1.0 Platform: PC OS/Version: All Status: NEW Keywords: code-quality Severity: normal Priority: P2 Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu We don't optimize away the dtor loop in this code: struct Foo { ~Foo() {} int i; }; struct NonPod { Foo foo[2]; }; void foo(void) { NonPod x; } http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 6 18:10:04 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 6 Dec 2008 18:10:04 -0600 Subject: [LLVMbugs] [Bug 3172] New: File with single "}" character causes infinite loop Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3172 Summary: File with single "}" character causes infinite loop Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: parser AssignedTo: unassignedclangbugs at nondot.org ReportedBy: andersca at mac.com CC: llvmbugs at cs.uiuc.edu iMac:clang andersca$ cat test2.c } iMac:clang andersca$ clang -fsyntax-only test2.c test2.c:1:1: error: expected identifier or '(' } ^ test2.c:1:1: error: expected identifier or '(' test2.c:1:1: error: expected identifier or '(' test2.c:1:1: error: expected identifier or '(' test2.c:1:1: error: expected identifier or '(' test2.c:1:1: error: expected identifier or '(' test2.c:1:1: error: expected identifier or '(' test2.c:1:1: error: expected identifier or '(' test2.c:1:1: error: expected identifier or '(' etc 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 Sat Dec 6 18:21:48 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 6 Dec 2008 18:21:48 -0600 Subject: [LLVMbugs] [Bug 2361] Undiagnosed file-scope VLA In-Reply-To: Message-ID: <200812070021.mB70LmiC004647@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2361 Anders Carlsson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andersca at mac.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Anders Carlsson 2008-12-06 18:21:47 --- Sending include/clang/Basic/DiagnosticKinds.def Sending lib/Sema/SemaDecl.cpp Sending test/Parser/builtin_classify_type.c Sending test/Sema/array-constraint.c Sending test/Sema/typedef-variable-type.c Sending test/Sema/vla.c Transmitting file data ...... Committed revision 60638. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 6 18:21:53 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 6 Dec 2008 18:21:53 -0600 Subject: [LLVMbugs] [Bug 2352] extern vla incorrectly accepted In-Reply-To: Message-ID: <200812070021.mB70Lr2t004667@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2352 Anders Carlsson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andersca at mac.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Anders Carlsson 2008-12-06 18:21:53 --- Sending include/clang/Basic/DiagnosticKinds.def Sending lib/Sema/SemaDecl.cpp Sending test/Parser/builtin_classify_type.c Sending test/Sema/array-constraint.c Sending test/Sema/typedef-variable-type.c Sending test/Sema/vla.c Transmitting file data ...... Committed revision 60638. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 6 21:41:41 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 6 Dec 2008 21:41:41 -0600 Subject: [LLVMbugs] [Bug 3173] New: EvaluateInteger crashes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3173 Summary: EvaluateInteger crashes Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: xuzhongxing at gmail.com CC: llvmbugs at cs.uiuc.edu clang crashes on this code: enum { A, B = A+50 }; clang: /home/xing/llvm/include/llvm/ADT/APSInt.h:166: llvm::APSInt& llvm::APSInt::operator+=(const llvm::APSInt&): Assertion `IsUnsigned == RHS.IsUnsigned && "Signedness mismatch!"' 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 Sun Dec 7 00:14:43 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 7 Dec 2008 00:14:43 -0600 Subject: [LLVMbugs] [Bug 3174] New: GVN invalidates memdep Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3174 Summary: GVN invalidates memdep Product: libraries Version: 1.0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu The GVN pass is invalidating memdep, which causes it to be recomputed for memcpy optimizer. We also run DSE substantially later, which means that extra passes have to get recomputed: Memory Dependence Analysis Global Value Numbering * Memory Dependence Analysis MemCpy Optimization Sparse Conditional Constant Propagation Combine redundant instructions Break critical edges in CFG Conditional Propagation * Dominator Tree Construction Memory Dependence Analysis Dead Store Elimination GVN would have to inform memdep about blocks it removes if it were to declare that it preserved it though (MergeBlockIntoPredecessor) and we'd have to teach memdep how to handle 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 Sun Dec 7 06:47:41 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 7 Dec 2008 06:47:41 -0600 Subject: [LLVMbugs] [Bug 3176] New: file with "}" triggers an infinite loop Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3176 Summary: file with "}" triggers an infinite loop Product: clang Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nunoplopes at sapo.pt CC: llvmbugs at cs.uiuc.edu the follwing command produces an infinite loop (because the token is never consumed and thus EOF is never reached): $ echo "}" | clang -fsyntax-only -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Dec 7 06:57:22 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 7 Dec 2008 06:57:22 -0600 Subject: [LLVMbugs] [Bug 3177] New: "__extension__ union" not supported Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3177 Summary: "__extension__ union" not supported Product: clang Version: unspecified Platform: All OS/Version: All Status: NEW Keywords: compile-fail Severity: normal Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nunoplopes at sapo.pt CC: llvmbugs at cs.uiuc.edu typedef union { __extension__ union { int a; float b; }; } x; produces the following error: a.c:3:3: error: expected unqualified-id __extension__ union { ^ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 7 09:36:36 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 7 Dec 2008 09:36:36 -0600 Subject: [LLVMbugs] [Bug 3176] file with "}" triggers an infinite loop In-Reply-To: Message-ID: <200812071536.mB7FaaEv032717@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3176 Nuno Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Nuno Lopes 2008-12-07 09:36:35 --- *** This bug has been marked as a duplicate of bug 3172 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 7 19:26:22 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 7 Dec 2008 19:26:22 -0600 Subject: [LLVMbugs] [Bug 3179] New: Code generator incorrectly reordering (or losing) stores Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3179 Summary: Code generator incorrectly reordering (or losing) stores 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: csdavec at swan.ac.uk CC: llvmbugs at cs.uiuc.edu The attached fail.ll demonstrates the problem in the @"._objc_method_SmalltalkTool()-run" function. This is called with two arguments, the first is a pointer to an object and the second is a selector. The selector is unused, the object is a structure containing a pointer to a class and a pointer to an object. At line 959, this argument is stored in an alloca. At line 960, the alloca is loaded again, into %3. At line 966, a GEP is used to calculate an offset 4 bytes from the pointer (the second element in the structure), and this is assigned to %7. At line 967, this is bitcast to an i8** and assigned %ivar. At line 979, a value is stored at the address pointed to by %ivar. At line 980, the value of the argument is once again loaded from the alloca. At line 985, this is passed to a function. The function to which it is passed logs the two words after the pointer address to the terminal; the second word is always 0 (the value from before the function was entered), in spite of a non-zero value being assigned to it. In this example, the store does not appear to ever complete - inspecting the pointer's target after the return from this function shows the same thing - that the store has not completed. I believe the other functions in this file can be ignored - I have left them in because this issue has a habit of disappearing seemingly at random. Adding other code after the existing code sometimes result the store being committed, then adding more will sometimes result in it not being committed again. This has been tested by me on FreeBSD/x86 and replicated by two others on Linux/x86. If the IR is not saying what I think it's saying, please let me know, otherwise please let me know if I can be of further assistance with test cases. Duplicating the last message send (the call to objc_msg_lookup() and then the call to the returned function) n times results in some bizarre behaviour. The value is correctly stored most of the time, however it fails when 3, 7, 11, or 15 message sends are entered in the function. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Dec 7 19:48:43 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 7 Dec 2008 19:48:43 -0600 Subject: [LLVMbugs] [Bug 3180] New: the C++ backend drops some function attributes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3180 Summary: the C++ backend drops some function attributes 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: flld0 at greynode.net CC: llvmbugs at cs.uiuc.edu The C++ backend, when serializing functions, loses some attributes. It looks like attributes added in Attributes.h have not also been added in CPPBackend.cpp. In 2.4 least noinline, alwaysinline, and optsize are not supported. Looking at viewvc, more have been added since 2.4. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 8 00:14:07 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 8 Dec 2008 00:14:07 -0600 Subject: [LLVMbugs] [Bug 3181] New: -fast bug on x86-64 with 32-bit gep indices Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3181 Summary: -fast bug on x86-64 with 32-bit gep indices Product: libraries Version: 1.0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: gohman at apple.com, llvmbugs at cs.uiuc.edu This testcase produces invalid asm with: llvm-as < t.ll | llc -march=x86-64 -fast define i32 @main() { ret i32 0 } define i32 @_l5_get(i32 %t3, i32* %t1) nounwind { %t9 = getelementptr i32* %t1, i32 %t3 ; [#uses=1] %t15 = load i32* %t9 ; [#uses=1] ret i32 %t15 } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 8 00:42:11 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 8 Dec 2008 00:42:11 -0600 Subject: [LLVMbugs] [Bug 3182] New: C++ backend generated code doesn' t compile for vector zero initializer Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3182 Summary: C++ backend generated code doesn't compile for vector zero initializer 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: flld0 at greynode.net CC: llvmbugs at cs.uiuc.edu The C++ code generated by the C++ backend for define <2xi64> @foo() { ret <2xi64> zeroinitializer } or any similar expression which causes the backend to emit code for a zero-initialized vector does not compile. The produced code ConstantAggregateZero* const_packed_2 = ConstantAggregateZero::get(VectorTy_0); doesn't compile because ConstantAggregateZero::get is declared to return a Constant *, rather than the more specific ConstantAggregateZero * Other constant types, in apparently analogous get methods, return more specific types - so perhaps a good fix is just to change the return type of ConstantAggregateZero::get to the more specific type. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 8 08:43:05 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 8 Dec 2008 08:43:05 -0600 Subject: [LLVMbugs] [Bug 3183] New: Possible memory leak in OwningArrayPtr::reset Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3183 Summary: Possible memory leak in OwningArrayPtr::reset Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Core LLVM classes AssignedTo: unassignedbugs at nondot.org ReportedBy: piotr.rak at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=2280) --> (http://llvm.org/bugs/attachment.cgi?id=2280) Patch with fix. OwningArrayPtr<>::reset uses operator delete instead of operator delete[]. It doesn't cause any real bug now, becouse it looks it is not used anywhere in code. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 8 09:08:03 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 8 Dec 2008 09:08:03 -0600 Subject: [LLVMbugs] [Bug 3184] New: Elaborated type specifiers in argument lists/ return types aren't declarations Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3184 Summary: Elaborated type specifiers in argument lists/return types aren't declarations Product: clang Version: unspecified Platform: All OS/Version: All Status: NEW Keywords: compile-fail Severity: minor Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sebastian.redl at getdesigned.at CC: llvmbugs at cs.uiuc.edu C++ 3.3.1p5 says: [...] for an elaborated-type-specifier of the form class-key identifier if the e-t-s is used in the decl-specifier-seq or parameter-declaration-clause of a function defined in namespace scope, the identifier is declared as a class-name in the namespace that contains the declaration; In other words, the following should compile: void f(class A*); void g() { A* a; } G++ compiles it, 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 Mon Dec 8 11:17:34 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 8 Dec 2008 11:17:34 -0600 Subject: [LLVMbugs] [Bug 3182] C++ backend generated code doesn' t compile for vector zero initializer In-Reply-To: Message-ID: <200812081717.mB8HHYXK028120@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3182 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gohman at apple.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Dan Gohman 2008-12-08 11:17:33 --- I agree. I changed ConstantAggregateZero::get to return ConstantAggregateZero*. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081208/070883.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 Dec 8 11:20:42 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 8 Dec 2008 11:20:42 -0600 Subject: [LLVMbugs] [Bug 3181] -fast bug on x86-64 with 32-bit gep indices In-Reply-To: Message-ID: <200812081720.mB8HKg5a028260@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3181 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Dan Gohman 2008-12-08 11:20:42 --- Fixed, along with a similar bug with 64-bit indices on x86-32, here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081208/070888.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 Dec 8 11:29:01 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 8 Dec 2008 11:29:01 -0600 Subject: [LLVMbugs] [Bug 3183] Possible memory leak in OwningArrayPtr::reset In-Reply-To: Message-ID: <200812081729.mB8HT1Tv028491@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3183 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kremenek at apple.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Ted Kremenek 2008-12-08 11:29:01 --- Fixed: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081208/070893.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 Dec 8 15:12:51 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 8 Dec 2008 15:12:51 -0600 Subject: [LLVMbugs] [Bug 3186] New: r60711 build broken Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3186 Summary: r60711 build broken 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 On x86-64 Linux, gcc 4.3.2: In file included from /home/edwin/llvm-bootstrap/llvm/lib/Target/PowerPC/PPCInstrInfo.cpp:18: /home/edwin/llvm-bootstrap/llvm/lib/Target/PowerPC/PPCGenInstrInfo.inc:287: error: 'SimpleLoad' is not a member of 'llvm::TID' /home/edwin/llvm-bootstrap/llvm/lib/Target/PowerPC/PPCGenInstrInfo.inc:288: error: 'SimpleLoad' is not a member of 'llvm::TID' -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 8 15:26:33 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 8 Dec 2008 15:26:33 -0600 Subject: [LLVMbugs] [Bug 3186] r60711 build broken In-Reply-To: Message-ID: <200812082126.mB8LQXWx003725@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3186 T??r??k Edwin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from T??r??k Edwin 2008-12-08 15:26:32 --- (In reply to comment #2) > (In reply to comment #1) > > Can you reproduce this in a clean build? > > > > I just did a make clean with same results. > > Buildbot doesn't fail though (but it is doing Debug build, I am doing Release), > perhaps TableGen is miscompiled? > > I'll try a Debug build now > Found the problem! I was doing a srcdir != objdir build, but I've done in the past a srcdir == objdir build, and haven't cleaned the directory properly, so .inc files remained in the srcdir, and the build picked that up instead of the one from objdir. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 8 15:59:28 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 8 Dec 2008 15:59:28 -0600 Subject: [LLVMbugs] [Bug 3172] File with single "}" character causes infinite loop In-Reply-To: Message-ID: <200812082159.mB8LxSgO004938@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3172 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2008-12-08 15:59:26 --- Fixed: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20081208/010021.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 Dec 8 17:45:06 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 8 Dec 2008 17:45:06 -0600 Subject: [LLVMbugs] [Bug 3170] loop unswitch never unswitches any loops In-Reply-To: Message-ID: <200812082345.mB8Nj6gV008838@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3170 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Devang Patel 2008-12-08 17:45:05 --- Revert the patch. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 9 12:23:13 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 9 Dec 2008 12:23:13 -0600 Subject: [LLVMbugs] [Bug 3179] Code generator incorrectly reordering (or losing) stores In-Reply-To: Message-ID: <200812091823.mB9INDUc021381@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3179 David Chisnall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #7 from David Chisnall 2008-12-09 12:23:11 --- After more hunting, it appears the bug is caused by clang not NULL-terminating the class name string, resulting in the class lookup failing and the resulting 0 being propagated upwards. LLVM is therefore working as expected. The reason adding extra code to the function caused it to work is that it, presumably, moved the alignment of things around so that the class string was followed by a null byte. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 9 12:44:54 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 9 Dec 2008 12:44:54 -0600 Subject: [LLVMbugs] [Bug 3161] llc -mach=cellspu adds dash dot (-.) to branch targets In-Reply-To: Message-ID: <200812091844.mB9IisSC022024@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3161 Scott Michel changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |scooter.phd at gmail.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Scott Michel 2008-12-09 12:44:54 --- Fixed last week circa r60522. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 9 12:54:37 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 9 Dec 2008 12:54:37 -0600 Subject: [LLVMbugs] [Bug 3190] New: VECTOR_SAVE_INLINE not defined for other-than-darwin targets Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3190 Summary: VECTOR_SAVE_INLINE not defined for other-than-darwin targets Product: tools Version: trunk Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: llvm-gcc AssignedTo: unassignedbugs at nondot.org ReportedBy: scooter.phd at gmail.com CC: llvmbugs at cs.uiuc.edu Someone added the VECTOR_SAVE_INLINE macro to the rs6k darwin configuration, but didn't add the same (or define an empty) macro for the linux target. This would be useful for the Cell BE platform. Make output follows: c++ -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o c-parser.o rs6000-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ llvm-main.o libbackend.a ../libcpp/libcpp.a /work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib/libLLVMBitReader.a /work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib/libLLVMipo.a /work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib/libLLVMBitWriter.a /work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib/LLVMPowerPCAsmPrinter.o /work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib/libLLVMAsmPrinter.a /work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib/LLVMPowerPCCodeGen.o /work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib/libLLVMSelectionDAG.a /work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib/libLLVMCodeGen.a /work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib/libLLVMScalarOpts.a /work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib/libLLVMTransformUtils.a /work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib/libLLVMipa.a /work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib/libLLVMAnalysis.a /work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib/libLLVMTarget.a /work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib/libLLVMCore.a /work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib/libLLVMSupport.a /work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib/libLLVMSystem.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/work/scottm/llvm-spu/obj/powerpc64-unknown-linux-gnu/Release/lib -lpthread -ldl -lm -lelf libbackend.a(rs6000.o): In function `rs6000_emit_prologue': /work/scottm/llvm-gcc-4.2/obj/powerpc64-unknown-linux-gnu/gcc/../../../gcc/config/rs6000/rs6000.c:16868: undefined reference to `VECTOR_SAVE_INLINE' -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 9 15:35:00 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 9 Dec 2008 15:35:00 -0600 Subject: [LLVMbugs] [Bug 3117] ice: Result type 0 illegal! In-Reply-To: Message-ID: <200812092135.mB9LZ0WA027574@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3117 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #4 from Duncan Sands 2008-12-09 15:34:58 --- Fixed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081208/070966.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 Dec 10 20:12:34 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 10 Dec 2008 20:12:34 -0600 Subject: [LLVMbugs] [Bug 3196] New: Incorrect calling convention for MVR functions on Linux Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3196 Summary: Incorrect calling convention for MVR functions on Linux 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: csdavec at swan.ac.uk CC: llvmbugs at cs.uiuc.edu Created an attachment (id=2291) --> (http://llvm.org/bugs/attachment.cgi?id=2291) Test case. Attached is a zip file containing: stub.c - a simple C program calling an external test function and implementing three other functions, for printing and creating a simple structure. f.ll - a failure case in LLVM, calling each of these functions. When compiled with stub.c (compiled by the system compiler), the resulting output should be: $ ./a.out 0 1 3 4 3 4 When compiling f.ll with LLVM and stub.c with GCC on FreeBSD, this is the case. When doing the same on Linux, it is not. Instead, the last two lines, which should be printing the structure returned by the C function, print something which looks like some uninitialised memory. scall.c - a C version of the test function in f.ll, for comparison. scall-freebsd-gcc.s - the assembly produced by GCC from this test file on FreeBSD (almost identical to the output from llc f.ll, on both FreeBSD and Linux) scall-linux-gcc.s - the assembly produced by GCC from this test file on Linux. Note the: leal -24(%ebp), %eax movl %eax, (%esp) between the first two call instructions - these are not present on FreeBSD or in the output from llc. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 10 22:57:04 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 10 Dec 2008 22:57:04 -0600 Subject: [LLVMbugs] [Bug 3197] New: llvm.umul.with.overflow.i32 broken on x86 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3197 Summary: llvm.umul.with.overflow.i32 broken on x86 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 Per summary; simple testcase below. declare {i32, i1} @llvm.umul.with.overflow.i32(i32, i32) define i32 @main() nounwind { entry: %t = call {i32, i1} @llvm.umul.with.overflow.i32(i32 -1, i32 -1) %sum = extractvalue {i32, i1} %t, 0 %obit = extractvalue {i32, i1} %t, 1 ; This should be 1 %notobit = xor i1 %obit, 1 %ret = zext i1 %notobit to i32 ret i32 %ret ; This should return 0 } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 11 01:33:00 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 11 Dec 2008 01:33:00 -0600 Subject: [LLVMbugs] [Bug 3198] New: GVN not eliminating fully redundant GEPs Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3198 Summary: GVN not eliminating fully redundant GEPs Product: libraries Version: 1.0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: resistor at mac.com, llvmbugs at cs.uiuc.edu In the testcase test/Transforms/GVN/rle-must-alias.ll, if you disable load elimination, you'll see that GVN produces: bb: ; preds = %entry %2 = tail call i32 (...)* @bar() nounwind ; [#uses=0] %3 = getelementptr [100 x i32]* @H, i32 0, i32 %i ; [#uses=1] %4 = load i32* %3, align 4 ; [#uses=1] store i32 %4, i32* @G, align 4 br label %bb3 bb1: ; preds = %entry %5 = tail call i32 (...)* @baz() nounwind ; [#uses=0] %6 = getelementptr [100 x i32]* @H, i32 0, i32 %i ; [#uses=1] %7 = load i32* %6, align 4 ; [#uses=2] store i32 %7, i32* @G, align 4 %8 = icmp eq i32 %7, 0 ; [#uses=1] br i1 %8, label %bb3, label %bb4 bb3: ; preds = %bb1, %bb %9 = getelementptr [100 x i32]* @H, i32 0, i32 %i ; [#uses=1] The %9 load is fully redundant with %3/%6. I thought that GVN could handle this case already? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 11 07:28:21 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 11 Dec 2008 07:28:21 -0600 Subject: [LLVMbugs] [Bug 3199] New: callee can't get the i64 parameter correctly. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3199 Summary: callee can't get the i64 parameter correctly. 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: dodohack at gmail.com CC: llvmbugs at cs.uiuc.edu when passing long long parameter mixed with short, int, (parameters should large than 8, so to run out of r3~r10), callee can't calculate the address of long long parameter passed by caller correctly(the alignment error, 4 bytes alignment should be added between long long's previous slot, not between long long's hi32 and lo32 slot). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 11 17:44:16 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 11 Dec 2008 17:44:16 -0600 Subject: [LLVMbugs] [Bug 3200] New: IRgen crash on alias of inline function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3200 Summary: IRgen crash on alias of inline function Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: LLVM Codegen AssignedTo: daniel at zuster.org ReportedBy: daniel at zuster.org CC: llvmbugs at cs.uiuc.edu clang crashes on -- static inline int foo() { return 0; } int bar() __attribute__((alias("foo")); -- because delayed emission of statics interacts badly with aliases. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 11 18:03:31 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 11 Dec 2008 18:03:31 -0600 Subject: [LLVMbugs] [Bug 3201] New: LLVM cannot be built as dynamic libraries Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3201 Summary: LLVM cannot be built as dynamic libraries Product: Build scripts Version: trunk Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P2 Component: Makefiles AssignedTo: danchr at gmail.com ReportedBy: danchr at gmail.com CC: llvmbugs at cs.uiuc.edu LLVM cannot be built as dynamic libraries, and this is a tracking bug for my effort to change that. I'll update the summary later. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 11 20:01:58 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 11 Dec 2008 20:01:58 -0600 Subject: [LLVMbugs] [Bug 2954] Type of enumerators is wrong in C++ In-Reply-To: Message-ID: <200812120201.mBC21wK4015800@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2954 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2008-12-11 20:01:57 --- Fixed by this commit: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20081208/010108.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 Dec 12 06:48:57 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 12 Dec 2008 06:48:57 -0600 Subject: [LLVMbugs] [Bug 3202] New: eh info show up in the symbol table Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3202 Summary: eh info show up in the symbol table Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: llc AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=2299) --> (http://llvm.org/bugs/attachment.cgi?id=2299) proposed patch Is it really necessary to place the unwind information in the sysbol table? An example: --------------------------------------- $ cat test.cc void f() {} $ llvm-g++ -c test.cc -o test-llvm.o $ g++ -c test.cc -o test-gcc.o $ nm test-llvm.o | grep -w d 0000000000000000 d EH_frame0 0000000000000018 d _Z1fv.eh $ nm test-gcc.o | grep -w d ----------------------------------- The attached patch fixes the problem by adding a ".L" prefix to the symbols. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 12 13:13:40 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 12 Dec 2008 13:13:40 -0600 Subject: [LLVMbugs] [Bug 3203] New: fast and burr schedulers break with complex EFLAGS usage Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3203 Summary: fast and burr schedulers break with complex EFLAGS usage 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 Created an attachment (id=2301) --> (http://llvm.org/bugs/attachment.cgi?id=2301) Testcase (code patch) Testcase is patch + IL. Patch is attached; IL is as follows: ; ModuleID = '/tmp/x.bc' 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 @a(i64 %a, i64 %b) nounwind readnone { entry: %0 = icmp ult i64 %a, %b ; [#uses=1] %1 = zext i1 %0 to i32 ; [#uses=1] ret i32 %1 } The issue is that llc compiling this testcase on x86 crashes in scheduling unless either "-pre-RA-sched=list-tdrr" or "-pre-RA-sched=list-td" is passed on the llc commandline. It's possible that this is my fault, but the fact that some schedulers work points to a flaw in the other schedulers rather than my patch. For some background, the patch is a hacky work-in-progress for generating significantly shorter code for comparisons between 64-bit integers on x86; the patch isn't complete, and some parts are still messy, but I think the concept is fundamentally sound. Roughly, the idea is that a comparison on x86 is just a subtraction, so we can do an efficient 64-bit comparison by just splitting the subtraction, and testing the flags on the top half; since the CF, OF and SF flags only depend on the top half of the result anyway, they will be set correctly. There is an issue in that the ZF flag isn't set correctly for the whole result, but this can be worked around: we simply don't use this method for equality comparisons, and we swap the operands for other comparisons that would normally require it. I think that the scheduler is getting confused by the explicitly modeled SBB, since it both uses and sets EFLAGS. For reference, the code generated with one of the top-down schedulers: a: movl 4(%esp), %eax movl 16(%esp), %ecx movl 8(%esp), %edx subl 12(%esp), %eax sbbl %ecx, %edx setb %al movzbl %al, %eax ret And the error generated with the default scheduler: llc: /home/eli/llvm/lib/CodeGen/ScheduleDAG.cpp:370: void llvm::ScheduleDAGTopologicalSort::AddPred(llvm::SUnit*, llvm::SUnit*): Assertion `!HasLoop && "Inserted edge creates a loop!"' failed. If more debug output would be helpful, please ask. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 12 19:40:25 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 12 Dec 2008 19:40:25 -0600 Subject: [LLVMbugs] [Bug 3205] New: always_inline doesn't always Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3205 Summary: always_inline doesn't always Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: alexr at leftfield.org CC: llvmbugs at cs.uiuc.edu ReadSwapShort isn't inlined into myfunc in the below code. Building with: "llvmc -O3 -S -emit-llvm cmap4.c -clang". Without -clang, it is inlined. inline __attribute__((always_inline)) unsigned short _OSSwapInt16(unsigned short _data) { return ((_data << 8) | (_data >> 8)); } inline __attribute__((always_inline)) unsigned short ReadSwapShort(unsigned char* data, unsigned int offset) { return _OSSwapInt16(*(unsigned short*) &data[offset]); } unsigned short myfunc(unsigned char* cmap, unsigned int offset, unsigned short c) { return ReadSwapShort(cmap, offset); } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 12 19:53:52 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 12 Dec 2008 19:53:52 -0600 Subject: [LLVMbugs] [Bug 3206] New: lack of select use (cmov) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3206 Summary: lack of select use (cmov) 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: alexr at leftfield.org CC: llvmbugs at cs.uiuc.edu On i386-apple-darwin, built with "llvmc -O3 -S select_reduced.c" with or without -clang. At the end of each case should be a select/cmov. inline __attribute__((always_inline)) unsigned short _OSSwapInt16(unsigned short _data) { return ((_data << 8) | (_data >> 8)); } inline __attribute__((always_inline)) unsigned short ReadSwapShort(unsigned char* data, unsigned int offset) { return _OSSwapInt16(*(unsigned short*) &data[offset]); } unsigned short* myfunc(unsigned short* endCodes, unsigned short probe, unsigned short entrySelector, unsigned short c) { #define PROBE_SHIFT \ {\ probe >>= 1;\ if (c > _OSSwapInt16(endCodes[probe >> 1]))\ endCodes = &endCodes[probe >> 1];\ } switch (entrySelector) { case 15: PROBE_SHIFT; // FALL-THRU case 14: PROBE_SHIFT; // FALL-THRU case 13: PROBE_SHIFT; // FALL-THRU case 12: PROBE_SHIFT; // FALL-THRU case 11: PROBE_SHIFT; // FALL-THRU case 10: PROBE_SHIFT; // FALL-THRU case 9: PROBE_SHIFT; // FALL-THRU case 8: PROBE_SHIFT; // FALL-THRU case 7: PROBE_SHIFT; // FALL-THRU case 6: PROBE_SHIFT; // FALL-THRU case 5: PROBE_SHIFT; // FALL-THRU case 4: PROBE_SHIFT; // FALL-THRU } return endCodes; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 13 02:36:54 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 13 Dec 2008 02:36:54 -0600 Subject: [LLVMbugs] [Bug 3207] New: Crash on invalid in DeclGroupOwningRef Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3207 Summary: Crash on invalid in DeclGroupOwningRef Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=2302) --> (http://llvm.org/bugs/attachment.cgi?id=2302) testcase clang parser.i produces a bunch of errors and then this crash: 5 libSystem.B.dylib 0x94bab47f abort + 73 7 clang 0x00630e52 clang::DeclGroupOwningRef::~DeclGroupOwningRef() + 72 8 clang 0x0065e51f clang::DeclStmt::~DeclStmt() + 41 9 clang 0x00596cb7 clang::Sema::DeleteStmt(void*) + 31 10 clang 0x006a7784 clang::ASTVector<&(clang::ActionBase::DeleteStmt(void*)), 32u>::destroy() + 114 11 clang 0x006a7955 clang::ASTVector<&(clang::ActionBase::DeleteStmt(void*)), 32u>::~ASTVector() + 17 12 clang 0x006a71c1 clang::Parser::ParseCompoundStatementBody(bool) + 1337 13 clang 0x006a71ef clang::Parser::ParseFunctionStatementBody(void*, clang::SourceLocation, clang::SourceLocation) + 33 14 clang 0x006abccc clang::Parser::ParseFunctionDefinition(clang::Declarator&) + 640 15 clang 0x006ac2d9 clang::Parser::ParseDeclarationOrFunctionDefinition() + 1525 16 clang 0x006ac708 clang::Parser::ParseExternalDeclaration() + 826 17 clang 0x006ac76b clang::Parser::ParseTopLevelDecl(void*&) + 85 18 clang 0x0059621a clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, bool, bool) + 454 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 13 02:38:15 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 13 Dec 2008 02:38:15 -0600 Subject: [LLVMbugs] [Bug 3208] New: missing diagnostic for void f(int) {} Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3208 Summary: missing diagnostic for void f(int) {} Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu This should produce a diagnostic about a missing argument name in C mode: void f(int) {} -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 13 10:01:57 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 13 Dec 2008 10:01:57 -0600 Subject: [LLVMbugs] [Bug 3209] New: CodeGen/unsupported.c fails on Linux amd64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3209 Summary: CodeGen/unsupported.c fails on Linux amd64 Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sebastian.redl at getdesigned.at CC: llvmbugs at cs.uiuc.edu The test case CodeGen/unsupported.c triggers an assertion when run on Linux/x86_64: ******************** TEST '/home/wasti/projects/llvm/tools/clang/test/CodeGen/unsupported.c' FAILED! ******************** Command: clang -verify -emit-llvm -o Output//home/wasti/projects/llvm/tools/clang/test/CodeGen/unsupported.c.out.tmp /home/wasti/projects/llvm/tools/clang/test/CodeGen/unsupported.c Incorrect Output: clang: Value.cpp:63: virtual llvm::Value::~Value(): Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed. 0 clang 0x00000000017b0172 1 clang 0x00000000017b04a8 2 libc.so.6 0x00002b739d5c7130 3 libc.so.6 0x00002b739d5c70c5 gsignal + 53 4 libc.so.6 0x00002b739d5c897e abort + 270 5 libc.so.6 0x00002b739d5c06ff __assert_fail + 239 6 clang 0x000000000175fe1c llvm::Value::~Value() + 324 7 clang 0x00000000016ec84b llvm::User::~User() + 91 8 clang 0x000000000171d97b llvm::Instruction::~Instruction() + 71 9 clang 0x000000000171e023 llvm::UnaryInstruction::~UnaryInstruction() + 33 10 clang 0x000000000171e0c5 llvm::AllocationInst::~AllocationInst() + 33 11 clang 0x000000000172d741 llvm::AllocaInst::~AllocaInst() + 33 12 clang 0x00000000012ee62d llvm::SymbolTableListTraits::deleteNode(llvm::Instruction*) + 43 13 clang 0x00000000012f2453 llvm::iplist >::erase(llvm::ilist_iterator) + 41 14 clang 0x0000000001635d8b llvm::iplist >::erase(llvm::ilist_iterator, llvm::ilist_iterator) + 35 15 clang 0x00000000016dee05 llvm::iplist >::clear() + 61 16 clang 0x00000000016de252 llvm::BasicBlock::~BasicBlock() + 60 17 clang 0x000000000162144b llvm::SymbolTableListTraits::deleteNode(llvm::BasicBlock*) + 43 18 clang 0x000000000162738b llvm::iplist >::erase(llvm::ilist_iterator) + 41 19 clang 0x000000000171993b llvm::iplist >::erase(llvm::ilist_iterator, llvm::ilist_iterator) + 35 20 clang 0x0000000001719993 llvm::iplist >::clear() + 61 21 clang 0x0000000001718202 llvm::Function::dropAllReferences() + 96 22 clang 0x00000000017322bb llvm::Module::dropAllReferences() + 57 23 clang 0x0000000001732669 llvm::Module::~Module() + 21 24 clang 0x000000000108d285 llvm::OwningPtr::reset(llvm::Module*) + 75 25 clang 0x000000000108d2c3 26 clang 0x0000000000c0c80c 27 clang 0x0000000001192eab clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, bool, bool) + 459 28 clang 0x0000000000c47f93 29 clang 0x0000000000c48d12 main + 1516 30 libc.so.6 0x00002b739d5b3b74 __libc_start_main + 244 31 clang 0x0000000000bfecf9 atan + 257 Output//home/wasti/projects/llvm/tools/clang/test/CodeGen/unsupported.c.out.script: line 1: 15800 Aborted clang -verify -emit-llvm -o Output//home/wasti/projects/llvm/tools/clang/test/CodeGen/unsupported.c.out.tmp /home/wasti/projects/llvm/tools/clang/test/CodeGen/unsupported.c ******************** TEST '/home/wasti/projects/llvm/tools/clang/test/CodeGen/unsupported.c' 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 Dec 13 12:59:43 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 13 Dec 2008 12:59:43 -0600 Subject: [LLVMbugs] [Bug 3209] CodeGen/unsupported.c fails on Linux amd64 In-Reply-To: Message-ID: <200812131859.mBDIxhWS018887@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3209 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2008-12-13 12:59:42 --- "fixed" http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20081208/010168.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 Dec 15 03:04:57 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Dec 2008 03:04:57 -0600 Subject: [LLVMbugs] [Bug 3210] New: missing CPUID entry for Core2 Quad Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3210 Summary: missing CPUID entry for Core2 Quad 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 In X86Subtarget.cpp: case 6: switch (Model) { case 1: return "pentiumpro"; case 3: case 5: case 6: return "pentium2"; case 7: case 8: case 10: case 11: return "pentium3"; case 9: case 13: return "pentium-m"; case 14: return "yonah"; case 15: return "core2"; default: return "i686"; } My CPU is: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz stepping : 7 So it will go to i686 instead of core2. I think more models should be added 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 Mon Dec 15 10:32:36 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Dec 2008 10:32:36 -0600 Subject: [LLVMbugs] [Bug 2753] repeated enum declaration crashes clang In-Reply-To: Message-ID: <200812151632.mBFGWa4n023116@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2753 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2008-12-15 10:32:34 --- Fixed in Subversion. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 15 11:40:56 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Dec 2008 11:40:56 -0600 Subject: [LLVMbugs] [Bug 3112] bootstrapped llvm-g++ fails to find files In-Reply-To: Message-ID: <200812151740.mBFHeuWK025481@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3112 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 15 11:41:24 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Dec 2008 11:41:24 -0600 Subject: [LLVMbugs] [Bug 3112] bootstrapped llvm-g++ fails to find files In-Reply-To: Message-ID: <200812151741.mBFHfO5t025535@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3112 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|WONTFIX |FIXED --- Comment #13 from Evan Cheng 2008-12-15 11:41:23 --- Rather. It's fixed by backing out my patch. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 15 12:15:46 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Dec 2008 12:15:46 -0600 Subject: [LLVMbugs] [Bug 3212] New: Violated assertion in clang revision 60757 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3212 Summary: Violated assertion in clang revision 60757 Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bagnara at cs.unipr.it CC: llvmbugs at cs.uiuc.edu $ wget http://people.csail.mit.edu/smcc/projects/single-file-programs/gcc.c.bz2 $ bunzip2 gcc.c.bz2 $ ~/clang/dest/bin/clang -w gcc.c gcc.c:2422:10: note: previous definition is here # define MIN(a, b) ((a) < (b) ? (a) : (b)) ^ gcc.c:2421:10: note: previous definition is here # define MAX(a, b) ((a) > (b) ? (a) : (b)) ^ clang: /home/roberto/clang/src/include/llvm/Support/Casting.h:199: typename llvm::cast_retty::ret_type llvm::cast(const Y&) [with X = clang::CXXRecordDecl, Y = clang::RecordDecl*]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. 0 clang 0x08c35835 1 libc.so.6 0x00b3d8b1 abort + 257 2 libc.so.6 0x00b353ce __assert_fail + 238 3 clang 0x086ba484 Aborted (core dumped) $ Here is a (not very informative) backtrace: (gdb) info stack #0 0x00110402 in __kernel_vsyscall () #1 0x00b3bfa0 in raise () from /lib/libc.so.6 #2 0x00b3d8b1 in abort () from /lib/libc.so.6 #3 0x00b353ce in __assert_fail () from /lib/libc.so.6 #4 0x086ba484 in clang::BuiltinCandidateTypeSet::AddTypesConvertedFrom () #5 0x00295e25 in ?? () #6 0x00000001 in ?? () #7 0x0910ddb0 in ?? () #8 0xb7ea000d in ?? () #9 0xb7eac45c in ?? () #10 0x090b6398 in ?? () #11 0x090aefd1 in ?? () #12 0x00000001 in ?? () #13 0xbf9bf5cc in ?? () #14 0xbf9c1a40 in ?? () #15 0x00000002 in ?? () #16 0x086be233 in clang::Sema::AddBuiltinOperatorCandidates () #17 0x00000020 in ?? () (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 Mon Dec 15 12:53:33 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Dec 2008 12:53:33 -0600 Subject: [LLVMbugs] [Bug 3213] New: Assertion `Arg < NumArgs' failed in clang revision 60757 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3213 Summary: Assertion `Arg < NumArgs' failed in clang revision 60757 Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bagnara at cs.unipr.it CC: llvmbugs at cs.uiuc.edu Created an attachment (id=2303) --> (http://llvm.org/bugs/attachment.cgi?id=2303) Testcase allowing to reproduce the problem $ ~/clang/dest/bin/clang catmaster_comb.c catmaster_comb.c:479:6: error: conflicting types for '__builtin_va_start' void __builtin_va_start(__builtin_va_list ) ; ^ note: previous declaration is here clang: /home/roberto/clang/src/parser/src/tools/clang/lib/Sema/../../include/clang/AST/Expr.h:774: clang::Expr* clang::CallExpr::getArg(unsigned int): Assertion `Arg < NumArgs && "Arg access out of range!"' failed. 0 clang 0x08c35835 1 libc.so.6 0x00b3d8b1 abort + 257 2 libc.so.6 0x00b353ce __assert_fail + 238 3 clang 0x086d5acc clang::Sema::SemaBuiltinVAStart(clang::CallExpr*) + 1004 4 clang 0xbfa90370 clang::Sema::SemaBuiltinVAStart(clang::CallExpr*) + 3074141328 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 Mon Dec 15 15:18:45 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Dec 2008 15:18:45 -0600 Subject: [LLVMbugs] [Bug 3214] New: Exception handling doesn't preserve callee-saved registers Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3214 Summary: Exception handling doesn't preserve callee-saved registers Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Keywords: miscompilation 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=2304) --> (http://llvm.org/bugs/attachment.cgi?id=2304) gzipped test case When I compile some simple exception-using code with LDC (http://www.dsource.org/projects/ldc): ----- module throws; void main() { throw new Exception("test"); } ----- and link it to an all-bc runtime (using llvm-gcc for the c files), this code segfaults after the runtime catches the exception. (Ubuntu 8.10 x86-64) >From what gdb tells me, it seems that callee-saved registers aren't preserved between the code in the try-block that contains the call to _Dmain (which is what the code above compiles to) when it throws an exception. This looks like an LLVM bug, not an LDC bug (since it's CPU-register level stuff). I'm attaching a .bc file. Unfortunately, it's rather large since it contains much of the D runtime so LDC isn't needed to examine this. ===== $ llc Message-ID: <200812152207.mBFM7nk8002549@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3213 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sharparrow1 at yahoo.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Eli Friedman 2008-12-15 16:07:48 --- Crash fixed in r61055. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 15 16:31:32 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Dec 2008 16:31:32 -0600 Subject: [LLVMbugs] [Bug 3215] New: Strange diagnostic for macro redefinition in system header Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3215 Summary: Strange diagnostic for macro redefinition in system header Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: preprocessor AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu Testcase: #define MAX(a,b) ((a)<(b)?(a):(b)) #include Diagnostic on Linux x86: :1:9: note: previous definition is here #define MAX(a,b) ((a)<(b)?(a):(b)) We either want to print out the whole diagnostic or none of it... -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 15 16:34:41 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Dec 2008 16:34:41 -0600 Subject: [LLVMbugs] [Bug 3212] Violated assertion in clang revision 60757 In-Reply-To: Message-ID: <200812152234.mBFMYfco003417@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3212 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sharparrow1 at yahoo.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Eli Friedman 2008-12-15 16:34:41 --- Fixed in r61056. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 15 17:17:11 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Dec 2008 17:17:11 -0600 Subject: [LLVMbugs] [Bug 3216] New: Incorrect codegen with shifting+sign extension ( possibly DAGCombiner?) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3216 Summary: Incorrect codegen with shifting+sign extension (possibly DAGCombiner?) 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: ; ModuleID = '-' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" target triple = "i386-pc-linux-gnu" %struct.Foo = type <{ i8 }> @foo = global %struct.Foo <{ i8 127 }>, align 1 ; <%struct.Foo*> [#uses=1] @.str = internal constant [17 x i8] c"f->_field2 = %x\0A\00" ; <[17 x i8]*> [#uses=1] define i32 @main(...) nounwind { entry: %tmp = load i8* getelementptr (%struct.Foo* @foo, i32 0, i32 0) ; [#uses=1] %bf.lo = lshr i8 %tmp, 5 ; [#uses=1] %bf.lo.cleared = and i8 %bf.lo, 7 ; [#uses=1] %0 = shl i8 %bf.lo.cleared, 5 ; [#uses=1] %bf.val.sext = ashr i8 %0, 5 ; [#uses=1] %conv = sext i8 %bf.val.sext to i32 ; [#uses=1] %call = call i32 (...)* @printf(i8* getelementptr ([17 x i8]* @.str, i32 0, i32 0), i32 %conv) ; [#uses=0] ret i32 0 } declare i32 @printf(...) This should print out "f->_field2 = 3"; however, wrong code is generated with "llc test.bc" on x86. "llc -fast test.bc", however, appears to generate correct code, leading me to suspect the DAGCombiner is messing up here. I'm going to try and see if I can track it down a bit further, but I figured it was better to file so I don't lose track of it. (Note: originally reported at http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20081215/010225.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 Dec 15 18:13:20 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Dec 2008 18:13:20 -0600 Subject: [LLVMbugs] [Bug 2712] Hello, World in `Writing an LLVM Pass' does not work In-Reply-To: Message-ID: <200812160013.mBG0DKqH006566@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2712 Peter Hawkins changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hawkinsp at cs.stanford.edu Status|RESOLVED |REOPENED Resolution|WORKSFORME | --- Comment #2 from Peter Hawkins 2008-12-15 18:13:19 --- Hi... I just experienced this problem as well. The problem is that the Hello world pass in the "Writing an LLVM pass" documentation is out of date; the Makefile no longer matches the Hello world example in the LLVM tree (the LLVMLIBS line). I have no problems building the copy in the LLVM source tree. However, if you copy and paste the example from: http://llvm.org/docs/WritingAnLLVMPass.html (as at December 15 2008) then it fails with the error that the original bug reporter gave. The documentation in SVN is also incorrect. Cheers, Peter -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 15 18:59:19 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Dec 2008 18:59:19 -0600 Subject: [LLVMbugs] [Bug 3217] New: GVN crash bootstrapping llvm-gcc on 32-bit Linux Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3217 Summary: GVN crash bootstrapping llvm-gcc on 32-bit Linux Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Scalar Optimizations AssignedTo: clattner at apple.com ReportedBy: nlewycky at google.com CC: nicholas at mxc.ca, llvmbugs at cs.uiuc.edu Created an attachment (id=2305) --> (http://llvm.org/bugs/attachment.cgi?id=2305) bugpoint reduced testcase The attached testcase triggers an assert in GVN. $ llvm/Debug/bin/opt -gvn bugpoint-reduced-simplified.bc WARNING: You're attempting to print out a bitcode file. This is inadvisable as it may cause display problems. If you REALLY want to taste LLVM bitcode first-hand, you can force output with the `-f' option. opt: GVN.cpp:1108: bool::GVN::processNonLocalLoad(llvm::LoadInst*, llvm::SmallVectorImpl&): Assertion `UnavailablePred != 0 && "Fully available value should be eliminated above!"' failed. 0 opt 0x086e26f7 1 opt 0x086e2b9c 2 0xffffe500 __kernel_sigreturn + 0 3 0x00000006 __kernel_sigreturn + 6918 4 libc.so.6 0x4eedd619 abort + 233 5 libc.so.6 0x4eed5031 __assert_fail + 257 6 opt 0x08411a54 7 opt 0x08411f80 8 opt 0x08412203 9 opt 0x08412990 10 opt 0x08412be0 11 opt 0x08412ddf 12 opt 0x0866c98c llvm::FPPassManager::runOnFunction(llvm::Function&) + 258 13 opt 0x0866cb36 llvm::FPPassManager::runOnModule(llvm::Module&) + 110 14 opt 0x0866c659 llvm::MPPassManager::runOnModule(llvm::Module&) + 205 15 opt 0x0866c7f6 llvm::PassManagerImpl::run(llvm::Module&) + 116 16 opt 0x0866c851 llvm::PassManager::run(llvm::Module&) + 27 17 opt 0x0838644b main + 4223 18 libc.so.6 0x4eec7ec2 __libc_start_main + 210 19 opt 0x08377a41 Aborted (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x4eedbc51 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0x4eedd619 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x4eed5031 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0x08411a54 in (anonymous namespace)::GVN::processNonLocalLoad ( this=0x880bd08, LI=0x8814b24, toErase=@0xffffd410) at GVN.cpp:1107 #5 0x08411f80 in (anonymous namespace)::GVN::processLoad (this=0x880bd08, L=0x8814b24, toErase=@0xffffd410) at GVN.cpp:1172 #6 0x08412203 in (anonymous namespace)::GVN::processInstruction ( this=0x880bd08, I=0x8814b24, toErase=@0xffffd410) at GVN.cpp:1295 #7 0x08412990 in (anonymous namespace)::GVN::processBlock (this=0x880bd08, BB=0x8812ed8) at GVN.cpp:1433 #8 0x08412be0 in (anonymous namespace)::GVN::iterateOnFunction ( this=0x880bd08, F=@0x8811df0) at GVN.cpp:1628 #9 0x08412ddf in (anonymous namespace)::GVN::runOnFunction (this=0x880bd08, F=@0x8811df0) at GVN.cpp:1395 #10 0x0866c98c in llvm::FPPassManager::runOnFunction (this=0x880bda0, F=@0x8811df0) at PassManager.cpp:1323 #11 0x0866cb36 in llvm::FPPassManager::runOnModule (this=0x880bda0, M=@0x880b260) at PassManager.cpp:1346 #12 0x0866c659 in llvm::MPPassManager::runOnModule (this=0x880b0b8, M=@0x880b260) at PassManager.cpp:1393 #13 0x0866c7f6 in llvm::PassManagerImpl::run (this=0x880d228, M=@0x880b260) at PassManager.cpp:1467 #14 0x0866c851 in llvm::PassManager::run (this=0xffffd718, M=@0x880b260) at PassManager.cpp:1499 #15 0x0838644b in main (argc=3, argv=0xffffd914) at opt.cpp:588 (gdb) up 6 #6 0x08412203 in (anonymous namespace)::GVN::processInstruction ( this=0x880bd08, I=0x8814b24, toErase=@0xffffd410) at GVN.cpp:1295 1295 bool changed = processLoad(L, toErase); (gdb) p L->dump() %iftmp.1374.0 = load %struct.tree_node** %iftmp.1374.0.in ; <%struct.tree_node*> [#uses=0] $1 = void -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 15 19:21:05 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Dec 2008 19:21:05 -0600 Subject: [LLVMbugs] [Bug 2916] SubReg implementation can not be used to insert the hi sub-register. In-Reply-To: Message-ID: <200812160121.mBG1L5nD008816@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2916 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |evan.cheng at apple.com Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Evan Cheng 2008-12-15 19:21:04 --- After thinking about it, I think the current behavior is fine. We're allowing target to specify its down sub-register indices so it's better to list each sub-register class explicitly. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 15 21:24:43 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Dec 2008 21:24:43 -0600 Subject: [LLVMbugs] [Bug 3116] SelectionDAG assertion fails: Binary operator types must match In-Reply-To: Message-ID: <200812160324.mBG3OhVu012948@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3116 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 15 22:57:47 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Dec 2008 22:57:47 -0600 Subject: [LLVMbugs] [Bug 3218] New: ternary confuses literal format string detection Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3218 Summary: ternary confuses literal format string detection Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: parser AssignedTo: unassignedclangbugs at nondot.org ReportedBy: giles at ghostscript.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=2306) --> (http://llvm.org/bugs/attachment.cgi?id=2306) simple test file demonstrating the problem clang r61068 throws a spurious security warning when a the format string argument is a ternary expression, even when both subexpressions are string literals. ./base/spprint.c:121:15: warning: format string is not a string literal (potentially insecure) sprintf(str, (fabs(v) > 1 ? "%1.1f" : "%1.8f"), v); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Source file is from Ghostscript svn. May be related to Bug 2965? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 16 00:23:04 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 16 Dec 2008 00:23:04 -0600 Subject: [LLVMbugs] [Bug 3219] New: fails to inline sqrt Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3219 Summary: fails to inline sqrt Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nicholas at mxc.ca CC: llvmbugs at cs.uiuc.edu On this program: #include double foo(double X) { return sqrt(X); } GCC will inline the fast path (non-negative X) and produce this: foo: pushl %ebp movl %esp, %ebp subl $8, %esp fldl 8(%ebp) fld %st(0) fsqrt fucomi %st(0), %st jp .L7 je .L8 fstp %st(0) jmp .L5 .L7: fstp %st(0) .p2align 4,,7 .p2align 3 .L5: fstpl (%esp) .p2align 4,,5 .p2align 3 call sqrt .p2align 4,,2 .p2align 3 jmp .L2 .p2align 4,,7 .p2align 3 .L8: fstp %st(1) .L2: leave .p2align 4,,1 .p2align 3 ret -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 16 01:11:01 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 16 Dec 2008 01:11:01 -0600 Subject: [LLVMbugs] [Bug 3217] GVN crash bootstrapping llvm-gcc on 32-bit Linux In-Reply-To: Message-ID: <200812160711.mBG7B1R5020237@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3217 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Chris Lattner 2008-12-16 01:11:01 --- Fixed, patch here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081215/071210.html Please verify that llvm-gcc builds for you, thanks for the bug report! -Chris -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 16 08:08:56 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 16 Dec 2008 08:08:56 -0600 Subject: [LLVMbugs] [Bug 3220] New: All enum declarations are empty in the AST. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3220 Summary: All enum declarations are empty in the AST. Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal 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 clang version: 61081 clang::EnumDecl:: enumerator_begin() == clang::EnumDecl:: enumerator_end() also non-empty enum declarations. Input file: enum colours { WHITE, BLACK, OCHRE, BURNT_SIENNA, INDIGO, AZURE }; enum colours a; In the program I have: clang::EnumDecl::enumerator_iterator i = enum_decl-> enumerator_begin(), e = enum_decl-> enumerator_end(); if (i == e) assert(0 && "The enum should not be empty!"); where the assert fails. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 16 13:57:59 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 16 Dec 2008 13:57:59 -0600 Subject: [LLVMbugs] [Bug 3196] Incorrect calling convention for MVR functions on Linux In-Reply-To: Message-ID: <200812161957.mBGJvxSF023180@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3196 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gohman at apple.com Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Dan Gohman 2008-12-16 13:57:54 --- MRV does not currently attempt to follow the C ABI for returning struct values. If you wish to have C-ABI-conforming output, it's necessary for the front-end to use sret arguments and other mechanisms in an ABI-appropriate way. If llvm-gcc is emitting the wrong thing on FreeBSD, then llvm-gcc has a bug. The intention is that llvm-gcc should emit correct code for the target ABI. This situation is not ideal, and I'd be happy to review patches to rectify it. Note that many targets have complex requirements for struct values. Also, note that LLVM IR doesn't carry full C type information, so front-ends would likely still need to be aware of much of the ABI complexity. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 16 14:27:15 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 16 Dec 2008 14:27:15 -0600 Subject: [LLVMbugs] [Bug 3197] llvm.umul.with.overflow.i32 broken on x86 In-Reply-To: Message-ID: <200812162027.mBGKRFvq024153@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3197 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Eli Friedman 2008-12-16 14:27:14 --- This bug doesn't really serve a purpose anymore, even though it's not technically fixed... closing. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 16 14:55:10 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 16 Dec 2008 14:55:10 -0600 Subject: [LLVMbugs] [Bug 2340] SimplifyCFG doesn't proerly clean up trivially dead instructions In-Reply-To: Message-ID: <200812162055.mBGKtApP025049@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2340 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Eli Friedman 2008-12-16 14:55:09 --- Revised version committed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 16 16:23:55 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 16 Dec 2008 16:23:55 -0600 Subject: [LLVMbugs] [Bug 3223] New: Debug information gives variables the wrong types Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3223 Summary: Debug information gives variables the wrong types Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: llvm-gcc AssignedTo: unassignedbugs at nondot.org ReportedBy: jyasskin at google.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=2308) --> (http://llvm.org/bugs/attachment.cgi?id=2308) Sample program showing incorrect debug information With llvm-gcc checked out at r60958, gdb gives the wrong types to variables. The 2.4 release did not have this problem (although it did have a different problem with arrays). $ ~/opensource/llvm-gcc/trunk/install/bin/llvm-gcc -g -o bad_types bad_types.c $ gdb bad_types GNU gdb 6.8-gg11 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux"... (gdb) b main Breakpoint 1 at 0x400438: file bad_types.c, line 2. (gdb) run Starting program: /home/jyasskin/tmp/bad_types Breakpoint 1, main () at bad_types.c:2 2 char* ptr = "Hello"; (gdb) n 3 int i = 2; (gdb) n 4 int arr[] = {1,2,3,4}; (gdb) n 5 } (gdb) p ptr $1 = (void *) 0x400570 (gdb) p i $2 = {2, 1, 2, 3} (gdb) p arr $3 = {1, 2, 3, 4} (gdb) If 'i' is the last variable, it correctly gets printed as an int rather than an array. The somewhat annoying workaround is to cast things to the right types before printing them. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 16 17:01:58 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 16 Dec 2008 17:01:58 -0600 Subject: [LLVMbugs] [Bug 3224] New: Debug information says all members at offset 0 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3224 Summary: Debug information says all members at offset 0 Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: llvm-gcc AssignedTo: unassignedbugs at nondot.org ReportedBy: jyasskin at google.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=2309) --> (http://llvm.org/bugs/attachment.cgi?id=2309) Sample program showing incorrect debug information $ ~/opensource/llvm-gcc/trunk/install/bin/llvm-gcc -g -o bad_types bad_types.c $ gdb bad_types GNU gdb 6.8-gg11 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux"... (gdb) b main Breakpoint 1 at 0x400438: file bad_types.c, line 7. (gdb) run Starting program: /home/jyasskin/tmp/bad_types Breakpoint 1, main () at bad_types.c:7 7 struct Foo f = {4, 7}; (gdb) n 8 return 0; (gdb) p /x f $1 = { bar = 0x4, baz = 0x959e0004 } (gdb) p &f $2 = (struct Foo *) 0x7fff959e9a20 (gdb) p &f.bar $3 = (short int *) 0x7fff959e9a20 (gdb) p &f.baz $4 = (int *) 0x7fff959e9a20 (gdb) Notice that Foo::bar and Foo::baz are claimed to be at the same address despite being different members. Needless to say, this makes it very hard to debug programs. You can work around it by manually computing the offset of the member you want, adding some number of bytes to a pointer by hand, and then casting it back to the right type, but that's not really reasonable. This is an llvm-gcc built from svn r60958. The 2.4 release did not have this problem. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 16 20:06:17 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 16 Dec 2008 20:06:17 -0600 Subject: [LLVMbugs] [Bug 3220] All enum declarations are empty in the AST. In-Reply-To: Message-ID: <200812170206.mBH26HbH003460@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3220 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Douglas Gregor 2008-12-16 20:06:14 --- Fixed by r61116. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 16 20:24:48 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 16 Dec 2008 20:24:48 -0600 Subject: [LLVMbugs] [Bug 3225] New: Wrong code legalizing 64-bit shift on x86 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3225 Summary: Wrong code legalizing 64-bit shift on x86 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 Created an attachment (id=2310) --> (http://llvm.org/bugs/attachment.cgi?id=2310) Testcase Testcase attached; should print out "4294967295" when run, but currently prints out "-1" on x86. Roughly, the issue is that DAGTypeLegalizer:: ExpandShiftWithKnownAmountBit is generating an undefined shift. This issue is often not visible on x86 because it requires a shift by zero, and shldl hides the issue; however, a carefully crafted testcase like the attached shows the issue. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 16 21:35:44 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 16 Dec 2008 21:35:44 -0600 Subject: [LLVMbugs] [Bug 3225] Wrong code legalizing 64-bit shift on x86 In-Reply-To: Message-ID: <200812170335.mBH3ZiJn006426@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3225 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Eli Friedman 2008-12-16 21:35:43 --- Fixed in r61119. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 17 00:35:38 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Dec 2008 00:35:38 -0600 Subject: [LLVMbugs] [Bug 3226] New: clang will infinite loop on the attached code snippet when it has goto-out-of- @try support Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3226 Summary: clang will infinite loop on the attached code snippet when it has goto-out-of- at try support Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: andersca at mac.com CC: llvmbugs at cs.uiuc.edu void f() { @try { goto L; } @finally { L: printf("finally\n"); } return; } int main(int argc, char **argv) { f(); 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 Wed Dec 17 00:37:30 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Dec 2008 00:37:30 -0600 Subject: [LLVMbugs] [Bug 3227] New: investigate llvm-gcc bootstrap failure on linux Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3227 Summary: investigate llvm-gcc bootstrap failure on linux 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, jyasskin at google.com llvm-gcc fails to build with a bootstrap comparison failure on both 32-bit and 64-bit X86 Linux. The symptom looks like this: Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs Bootstrap comparison failure! ./c-decl.o differs ./cp/decl.o differs ./df-core.o differs ./gcc.o differs ./i386.o differs ./stor-layout.o differs ./tree-pretty-print.o differs ./tree.o differs make[2]: *** [compare] Error 1 make[1]: *** [stage3-bubble] Error 2 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 17 00:56:30 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Dec 2008 00:56:30 -0600 Subject: [LLVMbugs] [Bug 3228] New: Bad behavior with labels+blocks extension Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3228 Summary: Bad behavior with labels+blocks extension 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 int a() {A:return ^{A:return 1;}();} "clang -fblocks" gives an error; llvm-gcc accepts this. int a() {goto A; return ^{A:return 1;}();} "clang -fblocks" accepts this. llvm-gcc gives an error. It's hard to say what the correct behavior is without a complete specification, but defining sane semantics for the second testcase seems difficult at best. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 17 01:34:08 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Dec 2008 01:34:08 -0600 Subject: [LLVMbugs] [Bug 3208] missing diagnostic for void f(int) {} In-Reply-To: Message-ID: <200812170734.mBH7Y8I1013717@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3208 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2008-12-17 01:33:50 --- Implemented here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20081215/010280.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 Dec 17 01:40:19 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Dec 2008 01:40:19 -0600 Subject: [LLVMbugs] [Bug 3177] "__extension__ union" not supported In-Reply-To: Message-ID: <200812170740.mBH7eJIl013965@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3177 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #1 from Chris Lattner 2008-12-17 01:40:12 --- This works for me with mainline, I get: t3.c:2:17: warning: declaration does not declare anything __extension__ union { ^ which is because we don't support the anonymous union extension. Doug is interested in working on anon unions, and I think we have another bugzilla to track that somewhere. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 17 06:54:12 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Dec 2008 06:54:12 -0600 Subject: [LLVMbugs] [Bug 3177] "__extension__ union" not supported In-Reply-To: Message-ID: <200812171254.mBHCsCiN001000@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3177 Nuno Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Component|Semantic Analyzer |C++ Resolution|WORKSFORME | --- Comment #2 from Nuno Lopes 2008-12-17 06:54:06 --- sorry, I forgot to mention that this happens in C++ mode only. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 17 11:14:08 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Dec 2008 11:14:08 -0600 Subject: [LLVMbugs] [Bug 3229] New: clang r61131 segfaults on invalid code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3229 Summary: clang r61131 segfaults on invalid code Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bagnara at cs.unipr.it CC: llvmbugs at cs.uiuc.edu, bolzoni at cs.unipr.it $ ./clang /tmp/bug.c /tmp/bug.c:9530:24: error: expected '=', ',', ';', 'asm', or '__attribute__' aft er declarator __inline static size_t __strcspn_c1(char const *__s , int __reject ) ^ /tmp/bug.c:9549:24: error: expected '=', ',', ';', 'asm', or '__attribute__' aft er declarator __inline static size_t __strcspn_c2(char const *__s , int __reject1 , int __re ject2 ) ^ [...] /tmp/bug.c:10716:12: note: previous declaration is here static int vsf_sysutil_translate_sig(enum EVSFSysUtilSignal sig ) ; ^ /tmp/bug.c:10769:61: error: variable has incomplete type 'enum EVSFSysUtilSignal' static int vsf_sysutil_translate_sig(enum EVSFSysUtilSignal sig ) ^ 0 clang 0x08a01585 1 clang 0x09c326f0 Segmentation fault (core dumped) $ gdb ./clang core.6716 GNU gdb Red Hat Linux (6.6-16.fc7rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". warning: Can't read pathname for load map: Input/output error. Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libelf.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libelf.so.1 Reading symbols from /usr/local/lib/libstdc++.so.6...done. Loaded symbols for /usr/local/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/local/lib/libgcc_s.so.1...done. Loaded symbols for /usr/local/lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Core was generated by `./clang /tmp/bug.c'. Program terminated with signal 11, Segmentation fault. #0 0x08462785 in clang::Sema::UsualUnaryConversions () (gdb) info stack #0 0x08462785 in clang::Sema::UsualUnaryConversions () #1 0xbf979844 in ?? () #2 0x00080da0 in ?? () #3 0xbf97a0e0 in ?? () #4 0x08532fc4 in clang::Parser::ParseParenExprOrCondition () #5 0x0848a234 in clang::Sema::ActOnStartOfSwitchStmt () #6 0xbf97a0e0 in ?? () #7 0xbf9797e8 in ?? () #8 0x00080d99 in ?? () #9 0x00080daa in ?? () #10 0x09d3e990 in ?? () #11 0xbf97a0e0 in ?? () #12 0x00000000 in ?? () (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 Wed Dec 17 15:09:02 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Dec 2008 15:09:02 -0600 Subject: [LLVMbugs] [Bug 3230] New: sched creates crazy register pressure + spilling Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3230 Summary: sched creates crazy register pressure + spilling Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Keywords: code-quality Severity: normal Priority: P2 Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: gohman at apple.com, llvmbugs at cs.uiuc.edu Consider: --- int test2(void); #define my_copy(x) tmp = test2(); err |= tmp int test(void){ int err = 0, tmp; my_copy( 0); my_copy( 1); my_copy( 2); my_copy( 3); my_copy( 4); my_copy( 5); my_copy( 6); my_copy( 7); my_copy( 8); my_copy( 9); my_copy(10); my_copy(11); my_copy(12); my_copy(13); my_copy(14); my_copy(15); my_copy(16); my_copy(17); my_copy(18); my_copy(19); my_copy(20); my_copy(21); my_copy(22); my_copy(23); my_copy(24); my_copy(25); my_copy(26); my_copy(27); my_copy(28); my_copy(29); my_copy(30); my_copy(31); return err; } --- we currently compile it to: call L_test2$stub movl %eax, -96(%ebp) call L_test2$stub movl %eax, -100(%ebp) call L_test2$stub movl %eax, -104(%ebp) call L_test2$stub movl %eax, -108(%ebp) ... orl -32(%ebp), %esi orl -36(%ebp), %esi orl -40(%ebp), %esi orl -44(%ebp), %esi ... If each or is scheduled immediately after its call, we'd get much better code and no spilling at all. GCC 4.0 (but not 4.2) produces: ... call L_test2$stub orl %eax, %esi call L_test2$stub orl %eax, %esi call L_test2$stub orl %eax, %esi call L_test2$stub orl %eax, %esi ... Which is much nicer. We actually get this code with: $ llvm-gcc t.c -S -o - -O0 -emit-llvm | llvm-as | opt -mem2reg | llc -fast Because -fast doesn't mess around with the schedule. If you turn on the dag scheduler, it will "break" the code. This is derived from GCC PR 38533. -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 Dec 17 15:13:47 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Dec 2008 15:13:47 -0600 Subject: [LLVMbugs] [Bug 3231] New: Makefile documentation could be clearer Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3231 Summary: Makefile documentation could be clearer Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: minor Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: viridia at gmail.com CC: llvmbugs at cs.uiuc.edu In Makefile.config.in, it says "there are several locations that need to be defined", but it's unclear as to whether these a) need to be defined by the user, b) need to be defined by the configuration script, or c) are defined by this file. In Makefile.common, it says that you can define "Sources", however Makefile.rules overwrites the definition of Sources. It seems as though you want to set SOURCES. In Makefile.common, it says you can define "SourceDir", however that variable appears nowhere in the LLVM source tree other than in that comment. In Makefile.common, the distinction between LLVM_SRC_ROOT and PROJ_SRC_ROOT is not really clear, mainly because it doesn't really define what a "project" is. (I'm assuming it's a subproject.) In Makefile.common, the following text is unclear as to what is meant: # For building, # LLVM, LLVM_SRC_ROOT = PROJ_SRC_ROOT It could be read as "if you want to build, then you should set these", or "when building, these will be set." -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 17 16:22:55 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Dec 2008 16:22:55 -0600 Subject: [LLVMbugs] [Bug 3229] clang r61131 segfaults on invalid code In-Reply-To: Message-ID: <200812172222.mBHMMtCI019567@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3229 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sharparrow1 at yahoo.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Eli Friedman 2008-12-17 16:22:54 --- Fixed in r61160. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 17 18:50:39 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Dec 2008 18:50:39 -0600 Subject: [LLVMbugs] [Bug 3227] llvm-gcc bootstrap failure In-Reply-To: Message-ID: <200812180050.mBI0odwC024633@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3227 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #11 from Nick Lewycky 2008-12-17 18:50:37 --- It works! Thanks Bill! I have no idea *how* it could have been GVN with all the optimization passes disabled, but that's a mystery I'm not keen to delve into now. Next up is figuring out what went wrong with nocapture... I'll reopen this bug if things don't work on my 32-bitter at home. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 17 19:12:29 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Dec 2008 19:12:29 -0600 Subject: [LLVMbugs] [Bug 3177] "__extension__ union" not supported in C++ mode In-Reply-To: Message-ID: <200812180112.mBI1CTUj025429@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3177 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED Summary|"__extension__ union" not |"__extension__ union" not |supported |supported in C++ mode --- Comment #3 from Chris Lattner 2008-12-17 19:12:28 --- Fixed: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20081215/010326.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 Dec 17 20:04:22 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Dec 2008 20:04:22 -0600 Subject: [LLVMbugs] [Bug 2790] warning on return value in void function should be on by default In-Reply-To: Message-ID: <200812180204.mBI24MTO027012@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2790 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Chris Lattner 2008-12-17 20:04:20 --- Fixed: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20081215/010327.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 Dec 17 23:08:41 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Dec 2008 23:08:41 -0600 Subject: [LLVMbugs] [Bug 3167] Sema:: CheckForConstantInitializer should pedwarn if a constant is not a strict constant In-Reply-To: Message-ID: <200812180508.mBI58fXb000622@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3167 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #1 from Chris Lattner 2008-12-17 23:08:39 --- This is explicitly allowed by the "extensions spec" because ?: has special semantics when the condition is a __builtin_constant_p expr. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 17 23:53:18 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Dec 2008 23:53:18 -0600 Subject: [LLVMbugs] [Bug 2929] Bugpoint should preserve the nounwind attribute when code extracting In-Reply-To: Message-ID: <200812180553.mBI5rICq002227@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2929 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2008-12-17 23:53:17 --- Done: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081215/071303.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 18 00:31:53 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 18 Dec 2008 00:31:53 -0600 Subject: [LLVMbugs] [Bug 2756] infinite loop in instcombine after mem2reg In-Reply-To: Message-ID: <200812180631.mBI6Vrkf003576@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2756 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #6 from Nick Lewycky 2008-12-18 00:31:52 --- I agree in general, but in this case it's hard to analyze for vectors. What we already did is the equivalent to the scalar case: %A = sub <2 x i8> 0, %y %B = sdiv <2 x i8> %x, %A --> %B = sdiv <2 x i8> %x, %y With r61195 I just added the ability to flip negatives in constant vectors: %A = sdiv <2 x i8> %x, --> %A = sdiv <2 x i8> %x, But for a non-constant vector we'd have walk the insertelement chain that made up the vector, looking for negate-able values. That's hard enough to implement that I wont do it unless you demonstrate it's a real-world problem. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 18 00:50:46 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 18 Dec 2008 00:50:46 -0600 Subject: [LLVMbugs] [Bug 2759] C99 array declarators accepted in C90 mode In-Reply-To: Message-ID: <200812180650.mBI6okSW004199@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2759 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2008-12-18 00:50:44 --- Done, thanks Neil! http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20081215/010332.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 18 01:44:46 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 18 Dec 2008 01:44:46 -0600 Subject: [LLVMbugs] [Bug 3232] New: Disable gcc inliner Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3232 Summary: Disable gcc inliner Product: tools Version: 2.2 Platform: PC OS/Version: All Status: NEW Keywords: code-quality Severity: normal Priority: P2 Component: llvm-gcc AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu llvm-gcc is running the GCC tree-inliner as well as the llvm inliner. This has certain advantages, but also brings certain problems. For example, it seriously unrolls code like this C++ code (which is a huge code size problem and not really a win): #include template< typename X > inline X factorial( X n ) { if ( n ) return n * factorial(n - 1); return 1; } int main(){ double x = factorial( ( double )19 ); printf( "factorial( (double)19 ): %f\n", x ); return 0; } $ llvm-gcc main.opt.cpp -S -o - -emit-llvm -O3 -mllvm -disable-llvm-optzns Which is basically horrible. Turning off the GCC inliner would also fix Bug 2999, but we have to watch out for 2353. -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 Thu Dec 18 01:46:54 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 18 Dec 2008 01:46:54 -0600 Subject: [LLVMbugs] [Bug 3111] inlining recursive function instead of tail call eliminating it In-Reply-To: Message-ID: <200812180746.mBI7ksOO005955@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3111 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #2 from Chris Lattner 2008-12-18 01:46:52 --- This is definitely the GCC inliner, duping to Bug 3232 *** This bug has been marked as a duplicate of bug 3232 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 18 02:12:02 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 18 Dec 2008 02:12:02 -0600 Subject: [LLVMbugs] [Bug 3233] New: gethostbyaddr miscompile on x86-64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3233 Summary: gethostbyaddr miscompile on x86-64 Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nicholas at mxc.ca CC: llvmbugs at cs.uiuc.edu, jyasskin at google.com Created an attachment (id=2315) --> (http://llvm.org/bugs/attachment.cgi?id=2315) bugpoint-reduced testcase This looks like an x86-64 ABI problem with structures (either struct.hostent or struct.in_addr) when calling gethostbyaddr_r. I've attached the bugpoint.test.bc and will attach the original .c testcase. $ ./x.cbe 0x7ffff87d4f90 yx-in-f100.google.com 74.125.45.100 Done. $ ./x.llvm yx-in-f100.google.com Segmentation fault -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 18 12:10:40 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 18 Dec 2008 12:10:40 -0600 Subject: [LLVMbugs] [Bug 2974] Invalid debug information for array types In-Reply-To: Message-ID: <200812181810.mBIIAeGQ003681@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2974 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Devang Patel 2008-12-18 12:10:39 --- This test case was unintentionally fixed by my recent patch that enabled use of DebugInfo, instead of MachineModule, in llvm-gcc. However, underlying bug is exposed by int x[10][20]; int y; ... (gdb) whatis x type = int [10][20] (gdb) whatis y type = int [10][20] :) This is now fixed in r61204. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 18 12:15:46 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 18 Dec 2008 12:15:46 -0600 Subject: [LLVMbugs] [Bug 3223] Debug information gives variables the wrong types In-Reply-To: Message-ID: <200812181815.mBIIFkXH003874@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3223 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Devang Patel 2008-12-18 12:15:45 --- Fixed. Committed revision 61204. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 18 12:29:38 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 18 Dec 2008 12:29:38 -0600 Subject: [LLVMbugs] [Bug 3224] Debug information says all members at offset 0 In-Reply-To: Message-ID: <200812181829.mBIITcsH004397@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3224 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Devang Patel 2008-12-18 12:29:36 --- Fixed. Committed revision 61206. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 18 14:08:11 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 18 Dec 2008 14:08:11 -0600 Subject: [LLVMbugs] [Bug 3234] New: Improve diagnostics for missing Obj-C properties Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3234 Summary: Improve diagnostics for missing Obj-C properties Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: andersca at mac.com CC: llvmbugs at cs.uiuc.edu This: void f(NSObject *o) { o.foo; } results in the following error when compiled with gcc: iMac:clang andersca$ gcc -fsyntax-only t.m t.m: In function 'f': t.m:5: error: request for member 'sliff' in something not a structure or union And when compiled with clang: iMac:clang andersca$ clang -fsyntax-only t.m t.m:5:5: error: member reference base type 'NSObject *' is not a structure or union o.sliff; ~ ^ It would be nice to give a better diagnostic about missing properties if we notice that the object in question is an Objective-C object. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 18 14:46:29 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 18 Dec 2008 14:46:29 -0600 Subject: [LLVMbugs] [Bug 3223] Debug information gives variables the wrong types In-Reply-To: Message-ID: <200812182046.mBIKkTH3009904@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3223 Jeffrey Yasskin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #4 from Jeffrey Yasskin 2008-12-18 14:46:20 --- This is better, but not fixed. After syncing llvm-gcc to head, gdb output on the same test program follows: (gdb) b main Breakpoint 1 at 0x400438: file bad_types.c, line 2. (gdb) run Starting program: /home/jyasskin/tmp/bad_types Breakpoint 1, main () at bad_types.c:2 2 char* ptr = "Hello"; (gdb) n 3 int i = 2; (gdb) n 4 int arr[] = {1,2,3,4}; (gdb) n 5 } (gdb) p ptr $1 = (void *) 0x400570 (gdb) p i $2 = 2 (gdb) p arr $3 = {1, 2, 3, 4} (gdb) The pointer's type is still lost. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 18 16:14:46 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 18 Dec 2008 16:14:46 -0600 Subject: [LLVMbugs] [Bug 3223] Debug information gives variables the wrong types In-Reply-To: Message-ID: <200812182214.mBIMEkXx013090@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3223 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #5 from Devang Patel 2008-12-18 16:14:45 --- Committed revision 61221. Try again. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 19 01:57:26 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Dec 2008 01:57:26 -0600 Subject: [LLVMbugs] [Bug 3235] New: instcombine crash on i128 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3235 Summary: instcombine crash on i128 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 $ opt -instcombine -disable-output x.bc opt: llvm/include/llvm/ADT/APInt.h:1051: int64_t llvm::APInt::getSExtValue() const: Assertion `getMinSignedBits() <= 64 && "Too many bits for int64_t"' failed. This fires when building Fortran on x86-64 linux, and was introduced by: r59403 | lattner | 2008-11-16 06:38:51 +0100 (Sun, 16 Nov 2008) | 2 lines simplify a bunch more instcombines to use m_Specific etc. Testcase: define i128 @m(i1 %f) nounwind { entry: %tmp = select i1 %f, i128 18446744073709551615, i128 9223372036854775807 ; [#uses=1] ret i128 %tmp } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 19 05:05:03 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Dec 2008 05:05:03 -0600 Subject: [LLVMbugs] [Bug 3202] eh info show up in the symbol table In-Reply-To: Message-ID: <200812191105.mBJB53ua012055@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3202 Rafael ??vila de Esp??ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #13 from Rafael ??vila de Esp??ndola 2008-12-19 05:04:46 --- Fixed on commit 61242. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 19 05:47:47 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Dec 2008 05:47:47 -0600 Subject: [LLVMbugs] [Bug 3236] New: precompiled headers are broken on linux x86-64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3236 Summary: precompiled headers are broken on linux x86-64 Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: llvm-gcc AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Run the command ./gcc/cc1plus -fpreprocessed stdc++.ii -quiet -dumpbase stdc++.h -mtune=generic -auxbase stdc++ -g -g -O2 -O0 -Winvalid-pch -Wno-deprecated -version -o stdc++.s --output-pch= foo.gch With the attached file. It will consume all available memory and crash. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 19 10:29:44 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Dec 2008 10:29:44 -0600 Subject: [LLVMbugs] [Bug 3236] precompiled headers are broken on linux x86-64 In-Reply-To: Message-ID: <200812191629.mBJGTi5B025927@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3236 Rafael ??vila de Esp??ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Rafael ??vila de Esp??ndola 2008-12-19 10:29:35 --- Fixed at revision 61243. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 19 10:49:23 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Dec 2008 10:49:23 -0600 Subject: [LLVMbugs] [Bug 3237] New: llvm-debug breaks on enums for which TREE_CHAIN is null Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3237 Summary: llvm-debug breaks on enums for which TREE_CHAIN is null 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 This fired when compiling Ada with -g on this type: > The code that barfs is: case ENUMERAL_TYPE: { // enum { a, b, ..., z }; llvm::SmallVector Elements; if (TYPE_SIZE(type)) { for (tree Link = TYPE_VALUES(type); Link; Link = TREE_CHAIN(Link)) { tree EnumValue = TREE_VALUE(Link); int64_t Value = getInt64(EnumValue, tree_int_cst_sgn(EnumValue) > 0); const char *EnumName = IDENTIFIER_POINTER(TREE_PURPOSE(Link)); Elements.push_back(DebugFactory.CreateEnumerator(EnumName, Value)); } } llvm::DIArray EltArray = DebugFactory.GetOrCreateArray(&Elements[0], Elements.size()); expanded_location Loc = GetNodeLocation(TREE_CHAIN(type), false); The problem is that TREE_CHAIN(type) is null. Not sure what this code expects TREE_CHAIN to give? Anyway, the Ada type is a dummy introduced by the front-end and as such has no location 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 Fri Dec 19 11:29:22 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Dec 2008 11:29:22 -0600 Subject: [LLVMbugs] [Bug 3234] Improve diagnostics for missing Obj-C properties In-Reply-To: Message-ID: <200812191729.mBJHTMM3027776@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3234 Anders Carlsson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Anders Carlsson 2008-12-19 11:29:19 --- http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20081215/010356.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 Dec 19 12:54:31 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Dec 2008 12:54:31 -0600 Subject: [LLVMbugs] [Bug 3235] instcombine crash on i128 In-Reply-To: Message-ID: <200812191854.mBJIsVuv030419@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3235 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #4 from Duncan Sands 2008-12-19 12:54:29 --- This seems to have gone away in tot. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 19 15:00:33 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Dec 2008 15:00:33 -0600 Subject: [LLVMbugs] [Bug 3149] possible integer miscompilation In-Reply-To: Message-ID: <200812192100.mBJL0XmD002204@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3149 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #38 from Evan Cheng 2008-12-19 15:00:32 --- Fixed. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081215/071372.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 Dec 19 16:07:22 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Dec 2008 16:07:22 -0600 Subject: [LLVMbugs] =?utf-8?q?=5BBug_3238=5D_New=3A__Peculiar_use_of_?= =?utf-8?b?4oCYdW5zaWduZWTigJkgaW5kaWNlcyBpbiDigJhQb3N0UkFTY2hlZHVsZXJM?= =?utf-8?b?aXN0IC4gY3Bw4oCZ?= Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3238 Summary: Peculiar use of ???unsigned??? indices in ???PostRASchedulerList.cpp??? Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P2 Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: danchr at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=2320) --> (http://llvm.org/bugs/attachment.cgi?id=2320) Fix The file ???lib/CodeGen/PostRASchedulerList.cpp??? contains two index arrays of unsigned type, where the value ???-1u??? is used to invalidate an index. GCC 3.4.6 on RHEL5.2 issued warnings about this. To be honest, I know little about C++ or what exactly this code does; it's just that it feels very wrong to me to store -1 in a variable which is explicitly declared to not have that value. The attached patch fixes this by using a signed integer for the index; I've had it in my local branch for a few days, and it seems to work fine :) If using a signed integer is unacceptable, perhaps using ~0 or UINT_MAX to designate an invalid index would be 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 Fri Dec 19 16:34:00 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Dec 2008 16:34:00 -0600 Subject: [LLVMbugs] =?utf-8?q?=5BBug_3238=5D__Peculiar_use_of_=E2=80=98uns?= =?utf-8?q?igned=E2=80=99_indices_in_=E2=80=98PostRASchedulerList_=2E_cpp?= =?utf-8?b?4oCZ?= In-Reply-To: Message-ID: <200812192234.mBJMY0Vn005285@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3238 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Dan Gohman 2008-12-19 16:33:59 --- -1u is idiomatic, but it's not difficult to change. Fixed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081215/071374.html I didn't test this on RHEL5.2; please reply if needed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 19 17:26:54 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Dec 2008 17:26:54 -0600 Subject: [LLVMbugs] [Bug 3240] New: Add *AsmPrinterForceLink to the targets which don' t have them Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3240 Summary: Add *AsmPrinterForceLink to the targets which don't have them Product: libraries Version: trunk Platform: Macintosh OS/Version: Mac System 9.x Status: NEW Severity: normal Priority: P2 Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: danchr at gmail.com CC: llvmbugs at cs.uiuc.edu Blocks: 3201 Created an attachment (id=2322) --> (http://llvm.org/bugs/attachment.cgi?id=2322) Patch against lib/Target The attached patch adds a bogus *AsmPrinterForceLink definition to each of ARMAsmPrinter.cpp, AlphaAsmPrinter.cpp, CBackend.cpp, CPPBackend.cpp, IA64AsmPrinter.cpp, MSILWriter.cpp, MipsAsmPrinter.cpp, PIC16AsmPrinter.cpp, SPUAsmPrinter.cpp, SparcAsmPrinter.cpp and XCoreAsmPrinter.cpp. Or, in other words, the targets which don't already have such definitions. These definitions are already used by the CMake build on Windows, and could be used by the Makefile build system in the future. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 20 00:57:54 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 20 Dec 2008 00:57:54 -0600 Subject: [LLVMbugs] [Bug 3241] New: ice: Node scheduled below its height! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3241 Summary: ice: Node scheduled below its height! 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 Seen using r61273 on Ubuntu Hardy on x86. regehr at john-home:~/volatile/tmp78$ llvm-gcc -O2 small.c cc1: ScheduleDAGRRList.cpp:277: void::ScheduleDAGRRList::ScheduleNodeBottomUp(llvm::SUnit*, unsigned int): Assertion `CurCycle >= SU->getHeight() && "Node scheduled below its height!"' failed. small.c:30: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See for instructions. regehr at john-home:~/volatile/tmp78$ cat small.c typedef char uint8_t; typedef int uint32_t; uint32_t g_10; uint32_t g_256; uint32_t g_348; uint32_t g_620; uint32_t g_847; uint32_t func_18 (uint8_t p_20, uint32_t p_21) { uint32_t l_24; uint32_t l_1252; uint32_t l_1444; uint32_t l_1384; func_31 (1, 1, g_348, 1, g_10, 1, 0x12845838L, p_21); if (func_148 (func_55 (l_1444, l_24, 1 ^ p_21, l_1252, g_256, l_1384, 1, 1), 1 <= safe_add_macro_uint32_t_u_u (g_847, 1) != g_620, 1)) { uint32_t l_1524; if (safe_mod_macro_uint16_t_u_u (l_1524, 1)) { } } } uint32_t func_148 (uint32_t p_149, uint32_t p_151, uint32_t p_152) { return p_151; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 20 09:55:21 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 20 Dec 2008 09:55:21 -0600 Subject: [LLVMbugs] [Bug 3242] New: Error: suffix or operands invalid for `sar' Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3242 Summary: Error: suffix or operands invalid for `sar' 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 Seen using r61273 on Ubuntu Hardy on x86. regehr at john-home:~/volatile/tmp79$ llvm-gcc -O0 small.c small.c: In function ???func_105???: small.c:23: warning: right shift count >= width of type /tmp/ccOHrIz8.s: Assembler messages: /tmp/ccOHrIz8.s:36: Error: suffix or operands invalid for `sar' regehr at john-home:~/volatile/tmp79$ cat small.c typedef char int8_t; typedef int int32_t; typedef char uint32_t; uint32_t func_105 (int32_t p_106) { 1, func_51 (1) || 0x5296D32418DFC5AELL && 0x5296D32418DFC5AELL > +0x5296D32418DFC5AELL && -9223372036854775807LL - 1 + 0x5296D32418DFC5AELL || 0x5296D32418DFC5AELL && 0x5296D32418DFC5AELL < +0x5296D32418DFC5AELL && 0x5296D32418DFC5AELL < +0x5296D32418DFC5AELL ? : 0x5296D32418DFC5AELL * 0 >= sizeof (int8_t) * 8 ? 1 : p_106 >> (0x5296D32418DFC5AELL && 0x5296D32418DFC5AELL > +0x5296D32418DFC5AELL && +0x5296D32418DFC5AELL || 0x5296D32418DFC5AELL && 0x5296D32418DFC5AELL < +0x5296D32418DFC5AELL && 0x5296D32418DFC5AELL < +0x5296D32418DFC5AELL ? 0x5296D32418DFC5AELL : 0x5296D32418DFC5AELL), 1 ? 1 : 1, 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 Sat Dec 20 10:40:29 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 20 Dec 2008 10:40:29 -0600 Subject: [LLVMbugs] [Bug 3241] ice: Node scheduled below its height! In-Reply-To: Message-ID: <200812201640.mBKGeTR2015083@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3241 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gohman at apple.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Dan Gohman 2008-12-20 10:40:28 --- Fixed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081215/071383.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Dec 20 11:22:07 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 20 Dec 2008 11:22:07 -0600 Subject: [LLVMbugs] [Bug 3242] Error: suffix or operands invalid for `sar' In-Reply-To: Message-ID: <200812201722.mBKHM7aX016389@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3242 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gohman at apple.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Dan Gohman 2008-12-20 11:22:05 --- Undefined behavior doesn't mean we get to emit invalid asm :-). Fixed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081215/071388.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Dec 20 11:33:35 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 20 Dec 2008 11:33:35 -0600 Subject: [LLVMbugs] [Bug 3243] New: null ptr dereference Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3243 Summary: null ptr dereference 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 Seen using r61273 on Ubuntu Hardy on x86. regehr at john-home:~/volatile/tmp80$ valgrind --trace-children=yes llvm-gcc -Os small.c ==10892== Memcheck, a memory error detector. ==10892== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==10892== Using LibVEX rev 1804, a library for dynamic binary translation. ==10892== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==10892== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==10892== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==10892== For more details, rerun with: -v ==10892== ==10925== Memcheck, a memory error detector. ==10925== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==10925== Using LibVEX rev 1804, a library for dynamic binary translation. ==10925== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==10925== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==10925== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==10925== For more details, rerun with: -v ==10925== ==10925== Invalid read of size 4 ==10925== at 0x88E1FB0: llvm::SimpleRegisterCoalescing::JoinIntervals(llvm::LiveInterval&, llvm::LiveInterval&, bool&) (in /home/regehr/libexec/gcc/i686-pc-linux-gnu/4.2.1/cc1) ==10925== Address 0x8 is not stack'd, malloc'd or (recently) free'd small.c:52: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ==10925== ==10925== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 21 from 1) ==10925== malloc/free: in use at exit: 510,974 bytes in 1,800 blocks. ==10925== malloc/free: 9,729 allocs, 7,929 frees, 1,812,954 bytes allocated. ==10925== For counts of detected errors, rerun with: -v ==10925== searching for pointers to 1,800 not-freed blocks. ==10925== checked 1,696,948 bytes. ==10925== ==10925== LEAK SUMMARY: ==10925== definitely lost: 0 bytes in 0 blocks. ==10925== possibly lost: 871 bytes in 16 blocks. ==10925== still reachable: 510,103 bytes in 1,784 blocks. ==10925== suppressed: 0 bytes in 0 blocks. ==10925== Rerun with --leak-check=full to see details of leaked memory. ==10892== ==10892== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 21 from 1) ==10892== malloc/free: in use at exit: 18,634 bytes in 73 blocks. ==10892== malloc/free: 479 allocs, 406 frees, 40,652 bytes allocated. ==10892== For counts of detected errors, rerun with: -v ==10892== searching for pointers to 73 not-freed blocks. ==10892== checked 145,304 bytes. ==10892== ==10892== LEAK SUMMARY: ==10892== definitely lost: 4,224 bytes in 32 blocks. ==10892== possibly lost: 0 bytes in 0 blocks. ==10892== still reachable: 14,410 bytes in 41 blocks. ==10892== suppressed: 0 bytes in 0 blocks. ==10892== Rerun with --leak-check=full to see details of leaked memory. regehr at john-home:~/volatile/tmp80$ cat small.c typedef short int int16_t; __extension__ typedef int int64_t; typedef unsigned char uint8_t; typedef unsigned short int uint16_t; typedef int uint32_t; __extension__ typedef int uint64_t; int16_t safe_mul_func_int16_t_s_s (int16_t _si1, uint32_t _si2) { return _si1 && _si2 && _si1 + _si2 || _si1 && _si2 && _si2 < +_si1 || _si1 && _si2 && _si1 < +_si2 || _si1 && _si2 && _si1 && _si2 < (1 / _si1) ? : _si1 * _si2; } uint32_t safe_mod_func_uint8_t_u_u (uint8_t _ui1, uint8_t _ui2) { return _ui2 == 0 ? : (_ui1 % _ui2); } uint32_t safe_mod_func_uint16_t_u_u (uint16_t _ui1, uint16_t _ui2) { return _ui2 == 0 ? : (_ui1 % _ui2); } uint32_t g_30; uint32_t func_5 (uint64_t p_7, uint32_t p_8, uint32_t p_10) { uint32_t l_11 = 0xC39BL; return l_11; } uint32_t func_120 (uint64_t p_121) { uint32_t l_168 = -1L; uint32_t l_170; if (safe_mul_func_int16_t_s_s (safe_mod_func_uint8_t_u_u ((1 > 0 && p_121 > 0 > 127 - p_121 || 1 < 0 && p_121 < 0 < -128 - p_121 ? 1 : 1) || sizeof (int64_t) * 8 ? safe_mod_func_uint16_t_u_u (p_121, func_5 (l_168, p_121, 1)) : 1 >> p_121, l_168), 1)) { func_5 (p_121, g_30, 0 ? 1 : safe_mul_ (l_170, 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 Sat Dec 20 11:38:36 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 20 Dec 2008 11:38:36 -0600 Subject: [LLVMbugs] [Bug 3244] New: ice: Don't know how to copy this physical register! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3244 Summary: ice: Don't know how to copy this physical register! 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 Seen using r61273 on Ubuntu Hardy on x86. regehr at john-home:~/volatile/tmp81$ llvm-gcc -O2 small.c cc1: ScheduleDAGRRList.cpp:781: void::ScheduleDAGRRList::ListScheduleBottomUp(): Assertion `false && "Don't know how to copy this physical register!"' failed. small.c:20: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See for instructions. regehr at john-home:~/volatile/tmp81$ cat small.c typedef short int int16_t; typedef char uint8_t; typedef int uint32_t; uint8_t safe_mul_func_uint8_t_u_u (uint8_t _ui1, uint32_t _ui2) { return _ui1 * _ui2; } int16_t g_62; uint32_t g_487; uint32_t func_85 (int16_t p_86, uint32_t p_87, uint32_t p_88); uint32_t func_42 (uint32_t p_43, uint32_t p_44, uint32_t p_45, uint32_t p_46) { func_78 (func_85 (safe_mul_func_uint8_t_u_u (func_7 (0xC22AAA77DD28626BLL, 1), (-2147483647 - 1 ? g_487 : 1) * g_62), 1, 1), p_46, 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 Sat Dec 20 17:43:20 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 20 Dec 2008 17:43:20 -0600 Subject: [LLVMbugs] [Bug 3245] New: Assertion `D == 0 && "Destroy method not called."' on invalid code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3245 Summary: Assertion `D == 0 && "Destroy method not called."' on invalid code Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: parser AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu Testcase: static void x() { int bx=0; { COPY3_IF_LT(by) } } Run through clang -fsyntax-only, crashes with the following assertion: clang: /home/eli/llvm/tools/clang/lib/AST/DeclGroup.cpp:67: clang::DeclGroupOwningRef::~DeclGroupOwningRef(): Assertion `D == 0 && "Destroy method not called."' 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 Dec 20 18:46:41 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 20 Dec 2008 18:46:41 -0600 Subject: [LLVMbugs] [Bug 3246] New: Assertion failure with inline assembly on PowerPC Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3246 Summary: Assertion failure with inline assembly on PowerPC Product: clang Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: minor Priority: P2 Component: parser AssignedTo: unassignedclangbugs at nondot.org ReportedBy: arplynn at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=2326) --> (http://llvm.org/bugs/attachment.cgi?id=2326) Simple C test-case. On a PowerPC 32-bit system running Mac OS X 10.5, clang (invoked with clang -emit-llvm-bc -std=c99 testcase.c -o=testcase.bc) dies from an assertion failure with the following message with the attached testcase: Assertion failed: (Verify(Ty, constraints) && "Function type not legal for constraints!"), function InlineAsm, file InlineAsm.cpp, line 43. 0 clang 0x00d97cd4 std::_Rb_tree, std::less, std::allocator >::insert_unique(llvm::sys::Path const&) + 7652 1 libSystem.B.dylib 0x92ccb99c _sigtramp + 68 2 libSystem.B.dylib 0x010050b0 _sigtramp + 1848874840 3 libSystem.B.dylib 0x6273741c _sigtramp + 18446744072898394820 gcc-4.2 (invoked with gcc-4.2 -S -O0 -std=c99 -pipe testcase.c -o - | less) correctly compiles the code. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 20 19:17:21 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 20 Dec 2008 19:17:21 -0600 Subject: [LLVMbugs] [Bug 3246] Assertion failure with inline assembly on PowerPC In-Reply-To: Message-ID: <200812210117.mBL1HL1X029894@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3246 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sharparrow1 at yahoo.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Eli Friedman 2008-12-20 19:17:20 --- Fixed in r61298. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 20 22:59:39 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 20 Dec 2008 22:59:39 -0600 Subject: [LLVMbugs] [Bug 3247] New: Assertion in VLA codegen with sizeof+cast Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3247 Summary: Assertion in VLA codegen with sizeof+cast Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu Testcase: int a() {return sizeof(*(char(*)[printf("asdf\n")])0);} Assertion: clang: /home/eli/llvm/tools/clang/lib/CodeGen/CodeGenFunction.cpp:419: llvm::Value* clang::CodeGen::CodeGenFunction::GetVLASize(const clang::VariableArrayType*): Assertion `SizeEntry && "Did not emit size for type"' failed. I don't remember completely what the rules are here... -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Dec 20 23:29:56 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 20 Dec 2008 23:29:56 -0600 Subject: [LLVMbugs] [Bug 3248] New: Operand of sizeof(vla) not evaluated Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3248 Summary: Operand of sizeof(vla) not evaluated Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu Testcase: int a(int x) {int a, (*y)[x]; return sizeof(*(puts("asdf"),y));} The emitted IL should have a call to puts, but the call isn't emitted in clang. Per C99 6.5.3.4p2, "If the type of the operand [of a sizeof] is a variable length array type, the operand is evaluated; otherwise, the operand is not evaluated and the result is an integer constant." -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Dec 21 00:29:30 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 21 Dec 2008 00:29:30 -0600 Subject: [LLVMbugs] [Bug 3249] New: Crash in llvm-gcc with variably modified type and pointer subtraction Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3249 Summary: Crash in llvm-gcc with variably modified type and pointer subtraction 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: int a() {return (char(*)[printf("asdf\n")])0 + 1 - (char(*)[printf("asdf\n")])0;} Output: : In function ???a???: :1: warning: implicit declaration of function ???printf??? :1: warning: incompatible implicit declaration of built-in function ???printf??? Unhandled expression! TREE_CODE: 118 unit size align 32 symtab 1 alias set -1 precision 32 min max LLVM: i32 pointer_to_this > side-effects invariant public arg 0 used ignored asm-frame-size 0 SI file line 1 size unit size align 32 context LLVM: i32* %0 chain used ignored asm-frame-size 0 SI file line 1 size unit size align 32 context >>> :1: internal compiler error: in Emit, at llvm-convert.cpp:947 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 Sun Dec 21 09:37:05 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 21 Dec 2008 09:37:05 -0600 Subject: [LLVMbugs] [Bug 3250] New: ice: shiftAmt <= BitWidth && "Invalid shift amount" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3250 Summary: ice: shiftAmt <= BitWidth && "Invalid shift amount" 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 Seen using r61306 on Ubuntu Hardy on x86. regehr at john-home:~/volatile/tmp86$ llvm-gcc -O1 small.c cc1: /home/regehr/llvm/include/llvm/ADT/APInt.h:681: llvm::APInt llvm::APInt::shl(uint32_t) const: Assertion `shiftAmt <= BitWidth && "Invalid shift amount"' failed. small.c:21: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See for instructions. regehr at john-home:~/volatile/tmp86$ cat small.c unsigned safe_sub_func_short_u_u (short _ui1, short _ui2) { return -_ui2; } unsigned g_115; unsigned func_106 (int p_107) { if (safe_sub_func_short_u_u (1, 0 ? 1 : 0 ? 1 : 1 >= sizeof (unsigned) ? 0 ? 1 : +1 : (unsigned) (0 > 9223372036854775807LL ? 1 : safe_div_ (p_107, 1)) >> (g_115 == 1 == 0 ? -9L : (-9L / (g_115 == 1))))) func_120 (1); } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Dec 21 10:38:34 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 21 Dec 2008 10:38:34 -0600 Subject: [LLVMbugs] [Bug 3251] New: ice: Invalid node ID for RAUW analysis! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3251 Summary: ice: Invalid node ID for RAUW analysis! 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 Seen using r61306 on Ubuntu Hardy on x86. regehr at john-home:~/volatile/tmp85$ llvm-gcc -O1 small.c small.c:8: warning: overflow in implicit constant conversion cc1: LegalizeTypes.cpp:702: void llvm::DAGTypeLegalizer::ReplaceValueWith(llvm::SDValue, llvm::SDValue): Assertion `N->getNodeId() != DAGTypeLegalizer::ReadyToProcess && N->getNodeId() != DAGTypeLegalizer::Processed && "Invalid node ID for RAUW analysis!"' failed. small.c:40: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See for instructions. regehr at john-home:~/volatile/tmp85$ cat small.c long long safe_lshift_func_uint64_t_u_s (long long _left, int _right) { return _right || _right >= sizeof (long long) || _left > 18446744073709551615ULL >> _right ? : _left << _right; } int g_4 = 0x095A97963BA20B95LL; long long g_5 = 0xBFB2C41AC3DC99CDLL; const int g_36 = 0x7048L; int g_50; int func_11 (char p_13) { safe_lshift_func_uint64_t_u_s (0 >= (1 <= (g_5, g_4) > (1 != p_13) - (long long) func_52 (g_50, 1)) >= p_13, 1) ^ safe_lshift_func_uint64_t_u_s (0 >= (1 <= safe_lsh (g_5, 1) > (1 != p_13) - (long long) func_52 (g_50, 1)) >= p_13, 1) ? 1 : func_56 (1, 1); } int func_52 (int p_53, long long p_54) { return g_36; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 22 04:03:36 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 22 Dec 2008 04:03:36 -0600 Subject: [LLVMbugs] [Bug 3252] New: Assertion failed: (success && " Illegal argument to getIntegerConstantExpr") Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3252 Summary: Assertion failed: (success && "Illegal argument to getIntegerConstantExpr") 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 when compiling the attached program (got via gcc -E so it should be compilable everywhere) "clang cat.c" works while "clang -emit-llvm-bc" crashes with Assertion failed: (success && "Illegal argument to getIntegerConstantExpr"), function getIntegerConstantExprValue, file /tmp/llvm/tools/clang/lib/CodeGen/../../include/clang/AST/Expr.h, line 167. Abort (core dumped) this is with clang/llvm as of r61333, this regression occured recently (2-3 weeks ago at most) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 22 09:32:20 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 22 Dec 2008 09:32:20 -0600 Subject: [LLVMbugs] [Bug 3253] New: missed optimization: shl + test -> bt Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3253 Summary: missed optimization: shl + test -> bt Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: edwintorok at gmail.com CC: llvmbugs at cs.uiuc.edu Consider this code: int foo(char *c) { return strcspn(c, ":\r\n"); } llvm-gcc translates this into this (which is better than gcc, which does 3 cmpb!): .text .align 16 .globl foo .type foo, at function foo: xorl %eax, %eax jmp .LBB1_2 # bb24 .LBB1_1: # bb23 incq %rax .LBB1_2: # bb24 movb (%rdi,%rax), %cl movl $1, %edx shlq %cl, %rdx cmpb $58, %cl ja .LBB1_1 # bb23 .LBB1_3: # bb24 movabsq $288230376151720961, %rcx testq %rcx, %rdx je .LBB1_1 # bb23 .LBB1_4: # bb35 ret .size foo, .-foo Tron on #llvm suggested that it could be improved even further: * movl $1, %rdx; shl %cl, %rdx; test %ecx, %edx == bt * loading the huge constant (the instruction is 10 bytes long!) should be moved out of the loop -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 22 10:48:26 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 22 Dec 2008 10:48:26 -0600 Subject: [LLVMbugs] [Bug 3252] Assertion failed: (success && " Illegal argument to getIntegerConstantExpr") In-Reply-To: Message-ID: <200812221648.mBMGmQ4C015479@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3252 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andersca at mac.com, | |daniel at zuster.org Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #2 from Daniel Dunbar 2008-12-22 10:48:22 --- Minimized TC: -- struct s { char f1[104]; }; void f0(unsigned idx) { unsigned len = __builtin_offsetof(struct s, f1[idx]); } -- This is a dup of 2910. *** This bug has been marked as a duplicate of bug 2910 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 22 11:54:40 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 22 Dec 2008 11:54:40 -0600 Subject: [LLVMbugs] [Bug 3245] Assertion `D == 0 && "Destroy method not called."' on invalid code In-Reply-To: Message-ID: <200812221754.mBMHse45017686@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3245 Sebastian Redl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Sebastian Redl 2008-12-22 11:54:39 --- As I suspected, this was a latent bug merely made visible by my cleaning work. Sema::DeleteStmt/Expr simply used the wrong method of destroying the AST nodes, but the node in question was previously simply leaked. Now that it was actually destroyed, the bug surfaced. Fixed: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20081222/010436.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 Dec 22 13:36:46 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 22 Dec 2008 13:36:46 -0600 Subject: [LLVMbugs] [Bug 3254] New: __attribute__ ((aligned)) is ignored Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3254 Summary: __attribute__ ((aligned)) is ignored Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: parser AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bagnara at cs.unipr.it CC: llvmbugs at cs.uiuc.edu, bolzoni at cs.unipr.it While the version with the argument is parsed correctly, the version without the argument seems to be simply eaten. For a testcase, use the example given in http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Variable-Attributes.html#Variable-Attributes, i.e., short array[3] __attribute__ ((aligned)); -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Dec 22 16:12:29 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 22 Dec 2008 16:12:29 -0600 Subject: [LLVMbugs] [Bug 3218] ternary confuses literal format string detection In-Reply-To: Message-ID: <200812222212.mBMMCTvb025987@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3218 Nuno Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nunoplopes at sapo.pt Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #3 from Nuno Lopes