From bugzilla-daemon at cs.uiuc.edu Mon Oct 1 07:15:37 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Oct 2007 07:15:37 -0500 Subject: [LLVMbugs] [Bug 1717] New: Compiler segfault Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1717 Summary: Compiler segfault Product: new-bugs Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: richard.smith at antixlabs.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1146) --> (http://llvm.org/bugs/attachment.cgi?id=1146) Tescase Compile attached source: $ llvm-gcc -c -emit-llvm bug.c -O0 -g bug.c:22: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. This only occurs with both -O0 and -g specified. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Oct 1 11:21:44 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Oct 2007 11:21:44 -0500 Subject: [LLVMbugs] [Bug 1715] getAnalysis doesn' t work from doInitialization(Module&) In-Reply-To: Message-ID: <200710011621.l91GLiZj012470@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1715 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dpatel at apple.com Status|NEW |RESOLVED Resolution| |LATER --- Comment #1 from Devang Patel 2007-10-01 11:21:44 --- By design, doInitialization() is performed before initializing analysis info for each pass. During doInitializatino(), getAnalysis is not available. getAnalysisToUpdate works because it does not go through pass specific analysis info list. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Oct 1 14:36:40 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Oct 2007 14:36:40 -0500 Subject: [LLVMbugs] [Bug 1717] Compiler segfault In-Reply-To: Message-ID: <200710011936.l91JaeOk021278@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1717 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |asl at math.spbu.ru Status|NEW |RESOLVED Resolution| |INVALID -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Oct 1 15:29:57 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Oct 2007 15:29:57 -0500 Subject: [LLVMbugs] [Bug 1718] New: Nightly Tester script should checkout llvm-gcc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1718 Summary: Nightly Tester script should checkout llvm-gcc Product: Test Suite Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Nightly Tester AssignedTo: unassignedbugs at nondot.org ReportedBy: tonic at nondot.org CC: llvmbugs at cs.uiuc.edu Right now, the nightly tester script relies on llvm-gcc already existing. The user has to manually update llvm-gcc otherwise dejagnu tests may fail. It would be much better if the testing script would do this for you (check out llvm-gcc, configure and build). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Oct 1 16:24:51 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Oct 2007 16:24:51 -0500 Subject: [LLVMbugs] [Bug 1603] llvm-gcc accepts illegal assignment to const ptr In-Reply-To: Message-ID: <200710012124.l91LOpX4025963@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1603 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Devang Patel 2007-10-01 16:24:51 --- Fixed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Oct 1 21:47:13 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Oct 2007 21:47:13 -0500 Subject: [LLVMbugs] [Bug 1719] New: noinline attribute gets dce'd before -inline Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1719 Summary: noinline attribute gets dce'd before -inline Product: libraries Version: 2.1 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Transformation Utilities AssignedTo: unassignedbugs at nondot.org ReportedBy: patil.nikhil at gmail.com CC: llvmbugs at cs.uiuc.edu a.c: void func() __attribute__((noinline)); void func() { } int main() { func(); } $ llvm-gcc -O3 a.c -c -emit-llvm; llvm-ld a.o $ llvm-dis a.out.bc -o - |grep func >/dev/null && echo "good" || echo "bad" bad $ opt -internalize -inline a.o |llvm-dis -o - |grep func >/dev/null && echo "good" || echo "bad" good $ opt -internalize -constmerge -inline a.o |llvm-dis -o - |grep func >/dev/null && echo "good" || echo "bad" bad One way to fix this is to disallow internalization of @llvm.noinline (treat it like "llvm.used"). Also doesn't this issue extend to a lot of other attributes, especially the new annotate("") attributes? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Oct 1 22:44:40 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 1 Oct 2007 22:44:40 -0500 Subject: [LLVMbugs] [Bug 1720] New: lli gives double free error on AMD64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1720 Summary: lli gives double free error on AMD64 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: stein at ir.iit.edu CC: llvmbugs at cs.uiuc.edu The test in llvm-test/MultiSource/Applications/d fails with the error message below from lli. What's more annoying is that this is not caught by RunSafely.sh. So, I have to manually kill lli to allow the tests to continue. It is similar for llvm-test/MultiSource/Benchmarks/mediabench/mpeg2/mpeg2dec To reproduce: 1) Go to llvm-test/MultiSource/Applications/d 2) Do make on AMD64 machine 3) You get error message below *** glibc detected *** /home/llvm/nightlytest/build/llvm/Debug/bin/lli: double free or corruption (out): 0x00000000012ecca0 *** ======= Backtrace: ========= /lib/libc.so.6[0x2added0bdb0d] /lib/libc.so.6(__libc_free+0x76)[0x2added0bf136] [0x2added317fa0] ======= Memory map: ======== 00400000-00d39000 r-xp 00000000 08:07 311769 /home/llvm/nightlytest/build/llvm/Debug/bin/lli 00e39000-00e3b000 rw-p 00939000 08:07 311769 /home/llvm/nightlytest/build/llvm/Debug/bin/lli 00e3b000-01635000 rw-p 00e3b000 00:00 0 [heap] 2addec7aa000-2addec7c5000 r-xp 00000000 08:06 2337064 /lib64/ld-2.5.so 2addec7c5000-2addec7c6000 rw-p 2addec7c5000 00:00 0 2addec7e2000-2addec7e3000 rw-p 2addec7e2000 00:00 0 2addec7e3000-2addec857000 r--p 00000000 08:07 2621455 /home/llvm/nightlytest/build/llvm/projects/llvm-test/MultiSource/Applications/d/Output/make_dparser.llvm.bc 2addec878000-2addec8b9000 rw-p 2addec878000 00:00 0 2addec8c5000-2addec8c6000 r--p 0001b000 08:06 2337064 /lib64/ld-2.5.so 2addec8c6000-2addec8c7000 rw-p 0001c000 08:06 2337064 /lib64/ld-2.5.so 2addec8c7000-2addec8dc000 r-xp 00000000 08:06 2337020 /lib64/libpthread-2.5.so 2addec8dc000-2addec9db000 ---p 00015000 08:06 2337020 /lib64/libpthread-2.5.so 2addec9db000-2addec9dc000 r--p 00014000 08:06 2337020 /lib64/libpthread-2.5.so 2addec9dc000-2addec9dd000 rw-p 00015000 08:06 2337020 /lib64/libpthread-2.5.so 2addec9dd000-2addec9e1000 rw-p 2addec9dd000 00:00 0 2addec9e1000-2addec9e8000 r-xp 00000000 08:06 1662018 /usr/lib64/libltdl.so.3.1.5 2addec9e8000-2addecae7000 ---p 00007000 08:06 1662018 /usr/lib64/libltdl.so.3.1.5 2addecae7000-2addecae8000 rw-p 00006000 08:06 1662018 /usr/lib64/libltdl.so.3.1.5 2addecae8000-2addecaea000 r-xp 00000000 08:06 2335647 /lib64/libdl-2.5.so 2addecaea000-2addecbea000 ---p 00002000 08:06 2335647 /lib64/libdl-2.5.so 2addecbea000-2addecbec000 rw-p 00002000 08:06 2335647 /lib64/libdl-2.5.so 2addecbec000-2addecbed000 rw-p 2addecbec000 00:00 0 2addecbed000-2addeccd5000 r-xp 00000000 08:06 1663417 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.2.1/libstdc++.so.6.0.9 2addeccd5000-2addecdd4000 ---p 000e8000 08:06 1663417 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.2.1/libstdc++.so.6.0.9 2addecdd4000-2addecdda000 r--p 000e7000 08:06 1663417 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.2.1/libstdc++.so.6.0.9 2addecdda000-2addecddd000 rw-p 000ed000 08:06 1663417 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.2.1/libstdc++.so.6.0.9 2addecddd000-2addecdf0000 rw-p 2addecddd000 00:00 0 2addecdf0000-2addece44000 r-xp 00000000 08:06 2337065 /lib64/libm-2.5.so 2addece44000-2addecf43000 ---p 00054000 08:06 2337065 /lib64/libm-2.5.so 2addecf43000-2addecf45000 rw-p 00053000 08:06 2337065 /lib64/libm-2.5.so 2addecf45000-2addecf52000 r-xp 00000000 08:06 1938602 /lib64/libgcc_s.so.1 2addecf52000-2added051000 ---p 0000d000 08:06 1938602 /lib64/libgcc_s.so.1 2added051000-2added052000 rw-p 0000c000 08:06 1938602 /lib64/libgcc_s.so.1 2added052000-2added053000 rw-p 2added052000 00:00 0 2added053000-2added185000 r-xp 00000000 08:06 2335716 /lib64/libc-2.5.so 2added185000-2added284000 ---p 00132000 08:06 2335716 /lib64/libc-2.5.so 2added284000-2added287000 r--p 00131000 08:06 2335716 /lib64/libc-2.5.so 2added287000-2added289000 rw-p 00134000 08:06 2335716 /lib64/libc-2.5.so 2added289000-2added290000 rw-p 2added289000 00:00 0 2added290000-2addee290000 rwxp 2added290000 00:00 0 2addf0000000-2addf0021000 rw-p 2addf0000000 00:00 0 2addf0021000-2addf4000000 ---p 2addf0021000 00:00 0 7fffbe2c7000-7fffbe300000 rw-p 7fffbe2c7000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vdso] make: *** Deleting file `Output/make_dparser.out-jit' make: *** [Output/make_dparser.out-jit] Interrupt -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 2 11:37:38 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 2 Oct 2007 11:37:38 -0500 Subject: [LLVMbugs] [Bug 1721] New: Incorrect evaluation of expression containing bitfield items Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1721 Summary: Incorrect evaluation of expression containing bitfield items Product: new-bugs Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: richard.smith at antixlabs.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1150) --> (http://llvm.org/bugs/attachment.cgi?id=1150) Test case (Tested with LLVM 2.1 with gcc 4.0) The attached demo has a 33 bit integer, with value 1<<32. The result of (item + item) should be zero because the value overflows, but the test fails at all optimisation levels. >From looking at the llvm disassembly it appears the result of the addition is not ANDed with 0x1FFFFFFFF as would be expected. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 2 14:14:53 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 2 Oct 2007 14:14:53 -0500 Subject: [LLVMbugs] [Bug 1722] New: -indvars does not rewrite the exit condition for a two-level loop nest Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1722 Summary: -indvars does not rewrite the exit condition for a two- level loop nest Product: libraries Version: 2.1 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Loop Optimizer AssignedTo: unassignedbugs at nondot.org ReportedBy: zhiruz at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1151) --> (http://llvm.org/bugs/attachment.cgi?id=1151) foo.bc //////// C code //////////////// void foo() { int i, j; for (i = 0; i < 100; ++i) for (j = 0; j < i; ++j) a[i][j] = i * j; } ;;;;;;;;;;;;;;;;; ll code piece for the loop nest ;;;;;;;;;;;;;;;;;;;;;; bb1: ; preds = %bb10 %tmp5 = mul i32 %i.0, %j.1 ; [#uses=1] %tmp7 = getelementptr [100 x [100 x i32]]* @a, i32 0, i32 %i.0, i32 %j.1 ; [#uses=1] store i32 %tmp5, i32* %tmp7, align 4 %tmp9 = add i32 %j.1, 1 ; [#uses=1] br label %bb10 bb10: ; preds = %bb18, %bb1 %j.1 = phi i32 [ %tmp9, %bb1 ], [ 0, %bb18 ] ; [#uses=4] %tmp13 = icmp slt i32 %j.1, %i.0 ; [#uses=1] br i1 %tmp13, label %bb1, label %bb15 bb15: ; preds = %bb10 %tmp17 = add i32 %i.0, 1 ; [#uses=1] br label %bb18 bb18: ; preds = %bb15, %entry %i.0 = phi i32 [ 0, %entry ], [ %tmp17, %bb15 ] ; [#uses=5] %tmp20 = icmp slt i32 %i.0, 100 ; [#uses=1] br i1 %tmp20, label %bb10, label %return ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; After "opt -indvars -simplifycfg", ;;;;;;;;;;;;;;;;; ll code piece after -indvars ;;;;;;;;;;;;;;;;;;;;;; bb1: ; preds = %bb10 %tmp5 = mul i32 %i.0, %j.1 ; [#uses=1] %tmp7 = getelementptr [100 x [100 x i32]]* @a, i32 0, i32 %i.0, i32 %j.1 ; [#uses=1] store i32 %tmp5, i32* %tmp7, align 4 %indvar.next = add i32 %j.1, 1 ; [#uses=1] br label %bb10 bb10: ; preds = %bb18, %bb1 %j.1 = phi i32 [ %indvar.next, %bb1 ], [ 0, %bb18 ] ; [#uses=4] %tmp13 = icmp slt i32 %j.1, %i.0 ; [#uses=1] br i1 %tmp13, label %bb1, label %bb15 bb15: ; preds = %bb10 %indvar.next1 = add i32 %i.0, 1 ; [#uses=1] br label %bb18 bb18: ; preds = %bb15, %entry %i.0 = phi i32 [ 0, %entry ], [ %indvar.next1, %bb15 ] ; [#uses=5] %exitcond = icmp ne i32 %i.0, 100 ; [#uses=1] br i1 %exitcond, label %bb10, label %return ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; I was hoping that the exit condition of the inner loop "%tmp13 = icmp slt i32 %j.1, %i.0" would be turned into "%tmp13 = icmp ne i32 %j.1, %i.0". But this didnt happen. I didnt use tail duplicate and loop rotate to get the first bitcode (attached as foo.bc). So my loop is in a bad form? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 2 22:18:00 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 2 Oct 2007 22:18:00 -0500 Subject: [LLVMbugs] [Bug 1572] Test new bugzilla install In-Reply-To: Message-ID: <200710030318.l933I0Ws027624@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1572 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #1 from Chris Lattner 2007-10-02 22:18:00 --- seems to 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 Tue Oct 2 23:00:27 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 2 Oct 2007 23:00:27 -0500 Subject: [LLVMbugs] [Bug 1719] noinline attribute gets dce'd before -inline In-Reply-To: Message-ID: <200710030400.l9340Rgi029961@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1719 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tonic at nondot.org Status|NEW |RESOLVED Keywords| |miscompilation Resolution| |FIXED --- Comment #1 from Chris Lattner 2007-10-02 23:00:26 --- Fixed, patch here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071001/054186.html Tanya, please verify whether your annotate attribute requires a similar fix. Thanks Nikhil! -Chris -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 2 23:12:54 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 2 Oct 2007 23:12:54 -0500 Subject: [LLVMbugs] [Bug 1721] Incorrect evaluation of expression containing bitfield items In-Reply-To: Message-ID: <200710030412.l934Csvk030470@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1721 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2007-10-02 23:12:51 --- This is not a bug. GCC happens to miscompile this code, but LLVM does it correctly. Specifically, in this statement: if (b.u33 + b.u33 != 0) printf ("fail\n"); The two operands to the plus are promoted to their next largest integer size (int64) before the addition, so the addition is actually produces 1ULL << 33, and is not subject to truncation. In other words, the code above is very different than: if (((b.u33 + b.u33) & 0x1FFFFFFFF) != 0) printf ("fail\n"); Apple GCC 4.0 appears to get this wrong, but LLVM does compile it correctly. -Chris -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 2 23:21:35 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 2 Oct 2007 23:21:35 -0500 Subject: [LLVMbugs] [Bug 1721] Incorrect evaluation of expression containing bitfield items In-Reply-To: Message-ID: <200710030421.l934LZXA030968@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1721 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |neil at daikokuya.co.uk Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #2 from Chris Lattner 2007-10-02 23:21:34 --- Actually, neil, some language lawyering would be appreciated in this case. The GCC tree in question does have the precision set to 33 bits for the PLUS_EXPR. Should we emit this as a i33 add? unit size align 64 symtab 1 alias set -1 precision 33 min max LLVM: i64> arg 0 ... ? I will investigate a bit more. -Chris -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 2 23:49:11 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 2 Oct 2007 23:49:11 -0500 Subject: [LLVMbugs] [Bug 1722] -indvars does not rewrite the exit condition for a two-level loop nest In-Reply-To: Message-ID: <200710030449.l934nBAn032340@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1722 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #1 from Chris Lattner 2007-10-02 23:49:11 --- llvm-gcc -O3 does this: %exitcond = icmp eq i32 %indvar.next, %indvar35 ; [#uses=1] br i1 %exitcond, label %bb17, label %bb1 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Oct 3 00:34:11 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 3 Oct 2007 00:34:11 -0500 Subject: [LLVMbugs] [Bug 1647] volatile attribute lost on pointer array dereferences In-Reply-To: Message-ID: <200710030534.l935YB4b002120@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1647 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Keywords| |miscompilation Resolution| |FIXED Target Milestone|--- |2.2 --- Comment #6 from Chris Lattner 2007-10-03 00:34:10 --- Fixed, patch here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071001/054194.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071001/054195.html testcase here: test/CFrontend/2007-10-02-VolatileArray.c -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 Oct 3 12:01:01 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 3 Oct 2007 12:01:01 -0500 Subject: [LLVMbugs] [Bug 1719] noinline attribute gets dce'd before -inline In-Reply-To: Message-ID: <200710031701.l93H11rG004343@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1719 Tanya Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #2 from Tanya Lattner 2007-10-03 12:01:00 --- Yes, a fix is needed for annotate attributes. You can see it with this example: llvm-gcc -c -emit-llvm test/CFrontend/2007-06-15-AnnotateAttribute.c -o - | opt -internalize -constmerge | llvm-dis -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Oct 3 12:06:14 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 3 Oct 2007 12:06:14 -0500 Subject: [LLVMbugs] [Bug 1719] noinline attribute gets dce'd before -inline In-Reply-To: Message-ID: <200710031706.l93H6EGt004623@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1719 Tanya Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #3 from Tanya Lattner 2007-10-03 12:06:14 --- Fixed. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071001/054201.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Oct 6 05:41:40 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 6 Oct 2007 05:41:40 -0500 Subject: [LLVMbugs] [Bug 1723] New: Build problems on OpenBSD Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1723 Summary: Build problems on OpenBSD Product: Build scripts Version: 2.1 Platform: Other OS/Version: OpenBSD Status: NEW Severity: normal Priority: P2 Component: Makefiles AssignedTo: unassignedbugs at nondot.org ReportedBy: laurie at tratt.net CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1153) --> (http://llvm.org/bugs/attachment.cgi?id=1153) Minimal build fixes for OpenBSD LLVM 2.1 doesn't install out of the box on OpenBSD-currend amd64. The minimum fixes needed to fix things for me are: 1) include/llvm/Pass.h doesn't know about intptr_t. Quick hack: include stdint.h. There's probably a more idiomatic way of fixing this. 2) include/llvm/ADT/DenseMap.h uses new style C++ casts which GCC 3.3.5 doesn't understand. Revert a previous patch which added these (nowhere else in the code base seems to have this problem). 3) Makefile.rules tries to install files as root during the normal build process (i.e. before "make install"). This then causes an error for LLVMHello. I've hacked this so that in the offending rule, install is only called if the compiler target is itself install. I suspect this is not OpenBSD specific, and would affect anyone who compiles as a normal user, calling only "make install" as root. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Oct 6 06:05:10 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 6 Oct 2007 06:05:10 -0500 Subject: [LLVMbugs] [Bug 1724] New: loop-unswitch crash Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1724 Summary: loop-unswitch crash Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Loop Optimizer AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1154) --> (http://llvm.org/bugs/attachment.cgi?id=1154) testcase The attached file was reduced from a gcc bootstrap. It fails with opt bugpoint-reduced-simplified.bc -loop-unswitch opt: /home/espindola/llvm/include/llvm/Analysis/Dominators.h:406: void llvm::DominanceFrontierBase::removeFromFrontier(std::_Rb_tree_iterator, std::allocator > > >, llvm::BasicBlock*): Assertion `I->second.count(Node) && "Node is not in DominanceFrontier of BB"' 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 Oct 7 12:57:31 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 7 Oct 2007 12:57:31 -0500 Subject: [LLVMbugs] [Bug 1723] Build problems on OpenBSD In-Reply-To: Message-ID: <200710071757.l97HvVaj002319@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1723 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Keywords| |build-problem Resolution| |FIXED Target Milestone|--- |2.2 --- Comment #7 from Chris Lattner 2007-10-07 12:57:30 --- Ok, patch applied, thanks! http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071001/054318.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Oct 7 17:28:21 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 7 Oct 2007 17:28:21 -0500 Subject: [LLVMbugs] [Bug 569] [jit] JIT cannot load native archives In-Reply-To: Message-ID: <200710072228.l97MSL1s010347@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=569 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #7 from Chris Lattner 2007-10-07 17:28:21 --- static archives can't be loaded. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Oct 7 17:30:30 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 7 Oct 2007 17:30:30 -0500 Subject: [LLVMbugs] [Bug 750] [llvmgcc] __builtin_llvm_insert/extract/ shufflevector intrinsics would be nice In-Reply-To: Message-ID: <200710072230.l97MUURD010501@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=750 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #1 from Chris Lattner 2007-10-07 17:30:30 --- It seems that noone is interested in this enough to make it happen. No 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 Sun Oct 7 17:32:04 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 7 Oct 2007 17:32:04 -0500 Subject: [LLVMbugs] [Bug 791] Improve Code Generation Docs In-Reply-To: Message-ID: <200710072232.l97MW4Io010630@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=791 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2007-10-07 17:32:04 --- Improvements will be made on demand. This bug is not precisely quantifiable, so there is no way to determine 'success'. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Oct 7 17:35:17 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 7 Oct 2007 17:35:17 -0500 Subject: [LLVMbugs] [Bug 941] Thread Local Storage (TLS) not supported In-Reply-To: Message-ID: <200710072235.l97MZHbJ010933@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=941 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #18 from Chris Lattner 2007-10-07 17:35:17 --- Target-independent support for this has been implemented. Targets can start doing their part on demand. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Oct 7 17:41:32 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 7 Oct 2007 17:41:32 -0500 Subject: [LLVMbugs] [Bug 1524] Improvements for mac release binaries In-Reply-To: Message-ID: <200710072241.l97MfWHO011273@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1524 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED Target Milestone|--- |2.1 --- Comment #1 from Chris Lattner 2007-10-07 17:41:32 --- LLVM 2.1 included this. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Oct 8 20:54:34 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 8 Oct 2007 20:54:34 -0500 Subject: [LLVMbugs] [Bug 1725] New: Node is not in DominanceFrontier of BB Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1725 Summary: Node is not in DominanceFrontier of BB Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: blocker Priority: P2 Component: Loop Optimizer AssignedTo: unassignedbugs at nondot.org ReportedBy: scottm at aero.org CC: llvmbugs at cs.uiuc.edu Compiling trunk, recompiling llvm-gcc-4.0: /work/scottm/llvm-gcc-4.0/trunk/obj/x86_64-unknown-linux-gnu/gcc/xgcc -B/work/scottm/llvm-gcc-4.0/trunk/obj/x86_64-unknown-linux-gnu/gcc/ -B/work/scottm/llvm-gcc-4.0/trunk/obj/x86_64-unknown-linux-gnu/../../x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/bin/ -B/work/scottm/llvm-gcc-4.0/trunk/obj/x86_64-unknown-linux-gnu/../../x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/lib/ -isystem /work/scottm/llvm-gcc-4.0/trunk/obj/x86_64-unknown-linux-gnu/../../x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/include -isystem /work/scottm/llvm-gcc-4.0/trunk/obj/x86_64-unknown-linux-gnu/../../x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../../gcc -I../../../gcc/. -I../../../gcc/../include -I../../../gcc/../libcpp/include -I/work/scottm/llvm/trunk/include -I/work/scottm/llvm-gcc-4.0/trunk/obj/x86_64-unknown-linux-gnu/../../../../llvm/trunk/obj/x86_64-unknown-linux-gnu//include -fexceptions -c ../../../gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o cc1: /work/scottm/llvm/trunk/include/llvm/Analysis/Dominators.h:437: void llvm::DominanceFrontierBase::removeFromFrontier(std::_Rb_tree_iterator, std::allocator > > >, llvm::BasicBlock*): Assertion `I->second.count(Node) && "Node is not in DominanceFrontier of BB"' failed. ../../../gcc/unwind-dw2.c:1326: internal compiler error: Aborted Haven't been able to generate a bc file yet. Will attach when I have one. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 9 12:25:14 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 9 Oct 2007 12:25:14 -0500 Subject: [LLVMbugs] [Bug 1725] Node is not in DominanceFrontier of BB In-Reply-To: Message-ID: <200710091725.l99HPEBS029603@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1725 Scott Michel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #4 from Scott Michel 2007-10-09 12:25:14 --- *** This bug has been marked as a duplicate of bug 1724 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 9 17:28:55 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 9 Oct 2007 17:28:55 -0500 Subject: [LLVMbugs] [Bug 1724] loop-unswitch crash In-Reply-To: Message-ID: <200710092228.l99MSt19009766@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1724 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #11 from Anton Korobeynikov 2007-10-09 17:28:55 --- (In reply to comment #10) > Does this help ? > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071008/054365.html > Yes, thanks alot -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Oct 10 15:09:09 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 10 Oct 2007 15:09:09 -0500 Subject: [LLVMbugs] [Bug 1726] New: Could remove a getTargetNode variant Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1726 Summary: Could remove a getTargetNode variant Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: dalej at apple.com CC: llvmbugs at cs.uiuc.edu This pattern in the PPC back end def PPCmffs : SDNode<"PPCISD::MFFS", SDTypeProfile<1, 0, [SDTCisVT<0, f64>]>, [SDNPOutFlag]>; def MFFS : XForm_42<63, 583, (outs F8RC:$rT), (ins), "mffs $rT", IntMFFS, [(set F8RC:$rT, (PPCmffs))]>, PPC970_DGroup_Single, PPC970_Unit_FPU; has 2 outputs and no inputs. tblgen generates a call to SDNode *getTargetNode(unsigned Opcode, MVT::ValueType VT1, MVT::ValueType VT2); which did not exist until I added it. It is possible to use *getTargetNode(unsigned Opcode, MVT::ValueType VT1, MVT::ValueType VT2, const SDOperand *Ops, unsigned NumOps); which would remove the need for the new function. (This does not strike me as a big deal; filing here because Evan asked for 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 Thu Oct 11 05:34:47 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 11 Oct 2007 05:34:47 -0500 Subject: [LLVMbugs] [Bug 1723] Build problems on OpenBSD In-Reply-To: Message-ID: <200710111034.l9BAYl6S010688@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1723 Laurence Tratt changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |REMIND --- Comment #8 from Laurence Tratt 2007-10-11 05:34:44 --- Hi all, Has anyone been able to look at patch #3, where Makefile.rules can try to incorrectly install things as root during the normal build process? -Laurie -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Oct 11 12:04:47 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 11 Oct 2007 12:04:47 -0500 Subject: [LLVMbugs] [Bug 1727] New: get svn requests out of access_log Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1727 Summary: get svn requests out of access_log Product: Website Version: unspecified Platform: Macintosh OS/Version: Mac System 9.x Status: NEW Severity: enhancement Priority: P2 Component: General Website AssignedTo: unassignedbugs at nondot.org ReportedBy: sabre at nondot.org CC: llvmbugs at cs.uiuc.edu The access_log is getting bloated, we need to filter PROPFIND requests out in httpd.conf. Here's an example that could be adapted to do this: http://www.webmasterworld.com/forum92/1795.htm It is filtering propfind requests to a separate file. -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 Oct 11 23:20:33 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 11 Oct 2007 23:20:33 -0500 Subject: [LLVMbugs] [Bug 1728] New: Inconsistent arguments to malloc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1728 Summary: Inconsistent arguments to malloc Product: new-bugs Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: minor Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: tbirch at apple.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1155) --> (http://llvm.org/bugs/attachment.cgi?id=1155) Test file showing the bug Compiling the attached file with `llvm-gcc -O3 -c test.c -emit-llvm -S -o test.ll` results in two malloc instructions with different arguments: 1) %tmp11617 = malloc [11 x %struct.foo*] ; <[11 x %struct.foo*]*> [#uses=2] 2) %tmp315 = malloc %struct.foo ; <%struct.foo*> [#uses=2] It seems that (2) is the correct behaviour and that (1), while allocating the correct size, should use 'malloc %struct.foo' instead. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Oct 12 00:31:41 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 12 Oct 2007 00:31:41 -0500 Subject: [LLVMbugs] [Bug 1728] Inconsistent arguments to malloc In-Reply-To: Message-ID: <200710120531.l9C5Vfkt024700@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1728 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2007-10-12 00:31:41 --- Fixed, testcase here: test/Transforms/InstCombine/malloc3.ll Patch here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071008/054440.html -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 Fri Oct 12 04:27:07 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 12 Oct 2007 04:27:07 -0500 Subject: [LLVMbugs] [Bug 1714] constant assertion fails while building libgfortran In-Reply-To: Message-ID: <200710120927.l9C9R7Xv007011@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1714 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #16 from Duncan Sands 2007-10-12 04:27:07 --- Fixed with commit 42861 to llvm-gcc-4.2. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Oct 12 06:43:40 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 12 Oct 2007 06:43:40 -0500 Subject: [LLVMbugs] [Bug 1729] New: bootstap broken on x86_64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1729 Summary: bootstap broken on x86_64 Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1156) --> (http://llvm.org/bugs/attachment.cgi?id=1156) testcase With the reduced attached testcase: espindola at death:~$ llc bugpoint-reduced-simplified.bc llc[0xcc91e2] llc[0xcc944e] /lib/libc.so.6[0x2aaaab8b16a0] llc(llvm::SimpleRegisterCoalescing::AdjustCopiesBackFrom(llvm::LiveInterval&, llvm::LiveInterval&, llvm::MachineInstr*)+0x6e)[0xb3d778] llc(llvm::SimpleRegisterCoalescing::JoinCopy(llvm::MachineInstr*, unsigned int, unsigned int, bool)+0xef5)[0xb3eb9f] llc(llvm::SimpleRegisterCoalescing::joinIntervals()+0x394)[0xb3f5b4] llc(llvm::SimpleRegisterCoalescing::runOnMachineFunction(llvm::MachineFunction&)+0x2b1)[0xb3fb3b] llc(llvm::MachineFunctionPass::runOnFunction(llvm::Function&)+0x33)[0x768505] llc(llvm::FPPassManager::runOnFunction(llvm::Function&)+0x10e)[0xc5cc62] llc(llvm::FunctionPassManagerImpl::run(llvm::Function&)+0x74)[0xc5ce88] llc(llvm::FunctionPassManager::run(llvm::Function&)+0x7f)[0xc5cfe5] llc(main+0x8ac)[0x74e81e] /lib/libc.so.6(__libc_start_main+0xf4)[0x2aaaab89db44] llc(cos+0x129)[0x74d089] -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Oct 13 09:27:28 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 13 Oct 2007 09:27:28 -0500 Subject: [LLVMbugs] [Bug 1730] New: lli segmentation fault Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1730 Summary: lli segmentation fault Product: tools Version: 2.1 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: lli AssignedTo: unassignedbugs at nondot.org ReportedBy: edwintorok at gmail.com CC: llvmbugs at cs.uiuc.edu $ lli -load=/usr/lib/libz.so -load=/usr/lib/libbz2.so -load=/usr/lib/libnsl.so -load=/usr/lib/libgmp.so clamscan.bc -ddaily.pdb lli[0x8551ab] /lib/libc.so.6[0x31c6c31710] [0x2ac206fc8303] Segmentation fault Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2b60324b5ea0 (LWP 29729)] 0x00002b6032a3b623 in ?? () (gdb) bt #0 0x00002b6032a3b623 in ?? () #1 0x0000000001d94800 in ?? () #2 0x0000000001627358 in ?? () #3 0x00000000000000bc in ?? () #4 0x00000031c6c7563c in free () from /lib/libc.so.6 #5 0x0000000001cbc1d0 in ?? () #6 0x0000000001c9c1e0 in ?? () #7 0x0000000000000010 in ?? () #8 0x0000000001c9c1d0 in ?? () #9 0x0000000000020010 in ?? () #10 0x00020010016273e8 in ?? () #11 0x0010000000000010 in ?? () #12 0x00007fff7860b770 in ?? () #13 0x00000000005c203d in ?? () #14 0x000000000058fc53 in X86CompilationCallback2 () #15 0x000000000058fbaa in X86CompilationCallback () #16 0x0000000000000007 in ?? () #17 0x00002b6032a3a92a in ?? () #18 0x0000000001626ca0 in ?? () #19 0x00000000005c937b in llvm::ExecutionEngine::EmitGlobalVariable () #20 0x00000031c6c7563c in free () from /lib/libc.so.6 #21 0x00000000005c4312 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::erase () #22 0x00000000005c203d in ?? () #23 0x000000000058fc53 in X86CompilationCallback2 () #24 0x000000000058fbaa in X86CompilationCallback () #25 0x0000000000000007 in ?? () ---Type to continue, or q to quit--- #26 0x00002b6032a38c00 in ?? () #27 0x0000000000000000 in ?? () If I use llc -march=x86-64 to compile it to native code, I get no segmentation faults (and no valgrind warnings). $ llvm-gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../llvm-gcc4.2-2.1.source/configure --prefix=/home/edwin/obj/../install --enable-llvm=/home/edwin/llvm-2.1/ --enable-languages=c --disable-multilib --disable-shared Thread model: posix gcc version 4.2.1(llvm) (Based on Apple Inc. build 5530) $ lvm-link -version Low Level Virtual Machine (http://llvm.org/): llvm version 2.1 Optimized build with assertions. $ lli -version Low Level Virtual Machine (http://llvm.org/): llvm version 2.1 Optimized build with assertions I tried to get a backtrace by using a Debug build of latest SVN (r42921), but I got nothing useful. Starting program: /home/edwin/llvm-svn/llvm/Debug/bin/lli -load=/usr/lib/libz.so -load=/usr/lib/libbz2.so -load=/usr/lib/libnsl.so -load=/usr/lib/libgmp.so clamscan.bc -ddaily.pdb warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffb81fd000 [Thread debugging using libthread_db enabled] [New Thread 0x2b81f2aafea0 (LWP 30005)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2b81f2aafea0 (LWP 30005)] 0x00002b81f3022ade in ?? () (gdb) bt #0 0x00002b81f3022ade in ?? () #1 0x0000000001882c8f in ?? () #2 0x0000000000000000 in ?? () (gdb) If i use -force-interpreter: Starting program: /home/edwin/llvm-svn/llvm/Debug/bin/lli -force-interpreter=true -load=/usr/lib/libz.so -load=/usr/lib/libbz2.so -load=/usr/lib/libnsl.so -load=/usr/lib/libgmp.so clamscan.bc -ddaily.pdb warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffffd9fd000 [Thread debugging using libthread_db enabled] [New Thread 0x2b63ad177ea0 (LWP 30021)] lli: APInt.cpp:99: llvm::APInt::APInt(const llvm::APInt&): Assertion `BitWidth <= IntegerType::MAX_INT_BITS && "bitwidth too large"' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x2b63ad177ea0 (LWP 30021)] 0x00000031c6c316a5 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00000031c6c316a5 in raise () from /lib/libc.so.6 #1 0x00000031c6c33100 in abort () from /lib/libc.so.6 #2 0x00000031c6c2ac2f in __assert_fail () from /lib/libc.so.6 #3 0x0000000000b1c801 in APInt (this=0x7ffffd9567a8, that=@0x7ffffd9566e8) at APInt.cpp:99 #4 0x0000000000723ef1 in GenericValue (this=0x7ffffd9567a0) at /home/edwin/llvm-svn/llvm/include/llvm/ExecutionEngine/GenericValue.h:26 #5 0x000000000084a134 in llvm::Interpreter::callExternalFunction (this=0xf94350, F=0x10d83b0, ArgVals=@0x7ffffd956930) at ExternalFunctions.cpp:112 #6 0x00000000008445a0 in llvm::Interpreter::callFunction (this=0xf94350, F=0x10d83b0, ArgVals=@0x7ffffd956930) at Execution.cpp:1318 #7 0x0000000000844c64 in llvm::Interpreter::visitCallSite (this=0xf94350, CS=@0x7ffffd956a50) at Execution.cpp:916 #8 0x000000000085183c in llvm::Interpreter::visitCallInst (this=0xf94350, I=@0x2a0c6f0) at Interpreter.h:164 #9 0x000000000085185b in llvm::InstVisitor::visitCall (this=0xf94350, I=@0x2a0c6f0) at /home/edwin/llvm-svn/llvm/include/llvm/Instruction.def:159 #10 0x0000000000851de4 in llvm::InstVisitor::visit (this=0xf94350, I=@0x2a0c6f0) at /home/edwin/llvm-svn/llvm/include/llvm/Instruction.def:159 #11 0x00000000008465a3 in llvm::Interpreter::run (this=0xf94350) at Execution.cpp:1354 #12 0x000000000084a3fa in llvm::Interpreter::runFunction (this=0xf94350, F=0x10d85f0, ArgValues=@0x7ffffd956bd0) at Interpreter.cpp:102 #13 0x0000000000869c07 in llvm::ExecutionEngine::runFunctionAsMain (this=0xf94350, Fn=0x10d85f0, argv=@0xf8d3b8, envp=0x7ffffd956ee0) at ExecutionEngine.cpp:284 #14 0x0000000000720efa in main (argc=8, argv=0x7ffffd956e98, envp=0x7ffffd956ee0) at lli.cpp:141 Any tips on how to debug this further? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Oct 13 11:50:52 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 13 Oct 2007 11:50:52 -0500 Subject: [LLVMbugs] [Bug 1731] New: libgcc2.c:541: internal compiler error: Segmentation fault Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1731 Summary: libgcc2.c:541: internal compiler error: Segmentation fault Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Keywords: compile-fail Severity: blocker Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: laguest at archangeli.co.uk CC: llvmbugs at cs.uiuc.edu Linux rogue 2.6.20-16-generic #2 SMP Sun Sep 23 18:31:23 UTC 2007 x86_64 GNU/Linux Ubuntu Feisty ../../llvm-gcc-4.2/configure --prefix=/home/laguest/opt/llvm --enable-llvm=/home/laguest/src/others/compilers/llvm-svn/x86_64/build $ make bootstrap echo stage3 > stage_final make[1]: Entering directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2' make[2]: Entering directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2' make[3]: Entering directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2' rm -f stage_current make[3]: Leaving directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2' make[2]: Leaving directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2' make[2]: Entering directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2' make[3]: Entering directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/libiberty' make[4]: Entering directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/libiberty/testsuite' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/libiberty/testsuite' make[3]: Leaving directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/libiberty' make[3]: Entering directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/intl' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/intl' make[3]: Entering directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/build-x86_64-unknown-linux-gnu/libiberty' make[4]: Entering directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/build-x86_64-unknown-linux-gnu/libiberty/testsuite' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/build-x86_64-unknown-linux-gnu/libiberty/testsuite' make[3]: Leaving directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/build-x86_64-unknown-linux-gnu/libiberty' make[3]: Entering directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/build-x86_64-unknown-linux-gnu/fixincludes' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/build-x86_64-unknown-linux-gnu/fixincludes' make[3]: Entering directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/zlib' true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -fkeep-inline-functions" "CXXFLAGS=-g -O2" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-O2 -g -O2 " "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=" "LIBCFLAGS=-g -fkeep-inline-functions" "LIBCFLAGS_FOR_TARGET=-O2 -g -O2 " "MAKE=make" "MAKEINFO=makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/home/laguest/opt/llvm" "infodir=/home/laguest/opt/llvm/info" "libdir=/home/laguest/opt/llvm/lib" "prefix=/home/laguest/opt/llvm" "tooldir=/home/laguest/opt/llvm/x86_64-unknown-linux-gnu" "AR=ar" "AS=as" "CC=gcc" "CXX=c++" "LD=ld" "LIBCFLAGS=-g -fkeep-inline-functions" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all multi-do # make make[3]: Leaving directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/zlib' make[3]: Entering directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/libcpp' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/libcpp' make[3]: Entering directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/libdecnumber' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/libdecnumber' make[3]: Entering directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/gcc' make \ CFLAGS="-g -fkeep-inline-functions -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common " \ CONFIG_H="config.h auto-host.h ../../../llvm-gcc-4.2/gcc/../include/ansidecl.h" \ MAKEOVERRIDES= \ -f libgcc.mk all make[4]: Entering directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/gcc' make GCC_FOR_TARGET="/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/./gcc/xgcc -B/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/./gcc/ -B/home/laguest/opt/llvm/x86_64-unknown-linux-gnu/bin/ -B/home/laguest/opt/llvm/x86_64-unknown-linux-gnu/lib/ -isystem /home/laguest/opt/llvm/x86_64-unknown-linux-gnu/include -isystem /home/laguest/opt/llvm/x86_64-unknown-linux-gnu/sys-include" \ AR_FOR_TARGET="ar" \ AR_CREATE_FOR_TARGET="ar rc" \ AR_EXTRACT_FOR_TARGET="ar x" \ AR_FLAGS_FOR_TARGET="" \ CC="gcc" CFLAGS="-g -fkeep-inline-functions -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common " \ BUILD_PREFIX="" \ BUILD_PREFIX_1="" \ LANGUAGES="" \ LIBGCC2_CFLAGS="-O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED " \ MULTILIB_CFLAGS="" T= crtbegin.o crtend.o crtbeginS.o crtendS.o crtbeginT.o crtfastmath.o make[5]: Entering directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/gcc' make[5]: `crtend.o' is up to date. make[5]: `crtbeginS.o' is up to date. make[5]: `crtendS.o' is up to date. make[5]: `crtbeginT.o' is up to date. make[5]: `crtfastmath.o' is up to date. make[5]: Leaving directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/gcc' /home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/./gcc/xgcc -B/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/./gcc/ -B/home/laguest/opt/llvm/x86_64-unknown-linux-gnu/bin/ -B/home/laguest/opt/llvm/x86_64-unknown-linux-gnu/lib/ -isystem /home/laguest/opt/llvm/x86_64-unknown-linux-gnu/include -isystem /home/laguest/opt/llvm/x86_64-unknown-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../../llvm-gcc-4.2/gcc -I../../../llvm-gcc-4.2/gcc/. -I../../../llvm-gcc-4.2/gcc/../include -I../../../llvm-gcc-4.2/gcc/../libcpp/include -I../../../llvm-gcc-4.2/gcc/../libdecnumber -I../libdecnumber -I/home/laguest/src/others/compilers/llvm-svn/llvm/include -I/home/laguest/src/others/compilers/llvm-svn/x86_64/build/include -DL_ffssi2 -fvisibility=hidden -DHIDE_EXPORTS -c ../../../llvm-gcc-4.2/gcc/libgcc2.c -o libgcc/./_ffssi2.o ../../../llvm-gcc-4.2/gcc/libgcc2.c:541: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make[4]: *** [libgcc/./_ffssi2.o] Error 1 make[4]: Leaving directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/gcc' make[3]: *** [stmp-multilib] Error 2 make[3]: Leaving directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/laguest/src/others/compilers/llvm-svn/x86_64/build-llvm-gcc-4.2' make: *** [bootstrap] 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 Sun Oct 14 05:13:23 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 14 Oct 2007 05:13:23 -0500 Subject: [LLVMbugs] [Bug 1729] bootstap broken on x86_64 In-Reply-To: Message-ID: <200710141013.l9EADNxT017653@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1729 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Evan Cheng 2007-10-14 05:13:22 --- I believe this is fixed now: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071008/054507.html Please verify. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Oct 14 11:35:23 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 14 Oct 2007 11:35:23 -0500 Subject: [LLVMbugs] [Bug 1732] New: llvmc doesn't work with default /usr/local/etc/llvm/c Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1732 Summary: llvmc doesn't work with default /usr/local/etc/llvm/c Product: tools Version: 2.1 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: llvmc AssignedTo: unassignedbugs at nondot.org ReportedBy: edwintorok at gmail.com CC: llvmbugs at cs.uiuc.edu $ cat t.c int main(){ return 0; $ llvm t.c -o t /usr/local/etc/llvm/c:55: Error: Expecting output type value /usr/local/etc/llvm/c had 1 errors. Terminating. line 55 of llvm/c is: optimizer.output = bytecode If I change it to bitcode, I get: $ llvmc t.c -o t llvmc: Can't find program '%llvmcc1%' -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Oct 15 04:21:07 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Oct 2007 04:21:07 -0500 Subject: [LLVMbugs] [Bug 1729] bootstap broken on x86_64 In-Reply-To: Message-ID: <200710150921.l9F9L7M2013395@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1729 Rafael ??vila de Esp??ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #3 from Rafael ??vila de Esp??ndola 2007-10-15 04:21:05 --- I have just attached a new testcase. This is also blocking bootstrap on x86-64. please add a test to "make check" after fixing this. 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 Oct 15 13:34:18 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Oct 2007 13:34:18 -0500 Subject: [LLVMbugs] [Bug 1729] bootstap broken on x86_64 In-Reply-To: Message-ID: <200710151834.l9FIYIfl006251@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1729 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #4 from Evan Cheng 2007-10-15 13:34:17 --- Fixed. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071015/054543.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Oct 15 14:28:41 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 15 Oct 2007 14:28:41 -0500 Subject: [LLVMbugs] [Bug 1733] New: llc crash in SimpleRegisterCoalescing::JoinCopy Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1733 Summary: llc crash in SimpleRegisterCoalescing::JoinCopy Product: new-bugs Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: enhancement 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=1163) --> (http://llvm.org/bugs/attachment.cgi?id=1163) testcase .ll $ llc bugpoint-reduced-simplified.bc llc((anonymous namespace)::PrintStackTrace()+0x1e)[0xdb3ef2] llc((anonymous namespace)::SignalHandler(int)+0x10e)[0xdb415e] /lib/libc.so.6[0x2ab25ad84d40] llc(llvm::SimpleRegisterCoalescing::JoinCopy(llvm::MachineInstr*, unsigned int, unsigned int, bool)+0xf80)[0xc23562] llc(llvm::SimpleRegisterCoalescing::CopyCoalesceInMBB(llvm::MachineBasicBlock*, std::vector >*, bool)+0x12a)[0xc239ba] llc(llvm::SimpleRegisterCoalescing::joinIntervals()+0x302)[0xc23d2c] llc(llvm::SimpleRegisterCoalescing::runOnMachineFunction(llvm::MachineFunction&)+0x2c0)[0xc24330] llc(llvm::MachineFunctionPass::runOnFunction(llvm::Function&)+0x33)[0x83dd9b] llc(llvm::FPPassManager::runOnFunction(llvm::Function&)+0x10e)[0xd46c18] llc(llvm::FunctionPassManagerImpl::run(llvm::Function&)+0x74)[0xd46e3e] llc(llvm::FunctionPassManager::run(llvm::Function&)+0x7f)[0xd46f95] llc(main+0x8a9)[0x82d285] /lib/libc.so.6(__libc_start_main+0xf4)[0x2ab25ad718e4] llc(atan+0x139)[0x82bca9] Segmentation fault (core dumped) $ valgrind --tool=memcheck llc bugpoint-reduced-simplified.bc ... ==12270== Invalid read of size 8 ==12270== at 0xC2353D: llvm::SimpleRegisterCoalescing::JoinCopy(llvm::MachineInstr*, unsigned, unsigned, bool) (SimpleRegisterCoalescing.cpp:428) ==12270== by 0xC239B9: llvm::SimpleRegisterCoalescing::CopyCoalesceInMBB(llvm::MachineBasicBlock*, std::vector >*, bool) (SimpleRegisterCoalescing.cpp:945) ==12270== by 0xC23D2B: llvm::SimpleRegisterCoalescing::joinIntervals() (SimpleRegisterCoalescing.cpp:982) ==12270== by 0xC2432F: llvm::SimpleRegisterCoalescing::runOnMachineFunction(llvm::MachineFunction&) (SimpleRegisterCoalescing.cpp:1191) ==12270== by 0x83DD9A: llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (MachineFunctionPass.h:41) ==12270== by 0xD46C17: llvm::FPPassManager::runOnFunction(llvm::Function&) (PassManager.cpp:1171) ==12270== by 0xD46E3D: llvm::FunctionPassManagerImpl::run(llvm::Function&) (PassManager.cpp:1129) ==12270== by 0xD46F94: llvm::FunctionPassManager::run(llvm::Function&) (PassManager.cpp:1074) ==12270== by 0x82D284: main (llc.cpp:295) ==12270== Address 0x40EF558 is 8 bytes after a block of size 128 alloc'd ==12270== at 0x4C20F19: operator new[](unsigned long) (vg_replace_malloc.c:199) ==12270== by 0xC29A89: llvm::SmallVectorImpl::grow(unsigned) (SmallVector.h:330) ==12270== by 0xC44F11: llvm::SmallVectorImpl::push_back(llvm::LiveRange const&) (SmallVector.h:144) ==12270== by 0xC44F44: llvm::SmallVectorImpl::insert(llvm::LiveRange*, llvm::LiveRange const&) (SmallVector.h:228) ==12270== by 0xC44067: llvm::LiveInterval::addRangeFrom(llvm::LiveRange, llvm::LiveRange*) (LiveInterval.cpp:219) ==12270== by 0xC2C7B3: llvm::LiveInterval::addRange(llvm::LiveRange) (LiveInterval.h:319) ==12270== by 0xC458D6: llvm::LiveIntervals::handlePhysicalRegisterDef(llvm::MachineBasicBlock*, llvm::ilist_iterator, unsigned, llvm::LiveInterval&, unsigned) (LiveIntervalAnalysis.cpp:682) ==12270== by 0xC46876: llvm::LiveIntervals::handleRegisterDef(llvm::MachineBasicBlock*, llvm::ilist_iterator, unsigned, unsigned) (LiveIntervalAnalysis.cpp:704) ==12270== by 0xC46BAC: llvm::LiveIntervals::computeIntervals() (LiveIntervalAnalysis.cpp:792) ==12270== by 0xC481BA: llvm::LiveIntervals::runOnMachineFunction(llvm::MachineFunction&) (LiveIntervalAnalysis.cpp:105) ==12270== by 0x83DD9A: llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (MachineFunctionPass.h:41) ==12270== by 0xD46C17: llvm::FPPassManager::runOnFunction(llvm::Function&) (PassManager.cpp:1171) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 16 04:45:12 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 16 Oct 2007 04:45:12 -0500 Subject: [LLVMbugs] [Bug 1734] New: bad assembly output breakes llvm-gcc bootstrap Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1734 Summary: bad assembly output breakes llvm-gcc bootstrap Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu The llvm-gcc bootstrap is broken because llvm is producing an output that gas doesn't like. With the attached test: llc test.bc -march=x86-64 -o -| as {standard input}: Assembler messages: {standard input}:1039: Error: suffix or operands invalid for `mov' Line 1039 is movb %eax, %c -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 16 14:30:59 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 16 Oct 2007 14:30:59 -0500 Subject: [LLVMbugs] [Bug 1734] bad assembly output breakes llvm-gcc bootstrap In-Reply-To: Message-ID: <200710161930.l9GJUxEn013029@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1734 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #9 from Evan Cheng 2007-10-16 14:30:58 --- Fixed. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071015/054575.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 Oct 17 04:57:01 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Oct 2007 04:57:01 -0500 Subject: [LLVMbugs] [Bug 1734] bad assembly output breakes llvm-gcc bootstrap In-Reply-To: Message-ID: <200710170957.l9H9v1fK017755@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1734 Rafael ??vila de Esp??ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #10 from Rafael ??vila de Esp??ndola 2007-10-17 04:56:59 --- The same test now fails with llc test.bc -march=x86-64 -o -| as {standard input}: Assembler messages: {standard input}:1062: Error: Incorrect register `%eax' used with `b' suffix {standard input}:1063: Error: Incorrect register `%eax' used with `b' suffix lines 106(2|3) are addb $250, %eax cmpb $5, %eax -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Oct 17 09:45:00 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 17 Oct 2007 09:45:00 -0500 Subject: [LLVMbugs] [Bug 1735] New: deadargelim changes result of function call Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1735 Summary: deadargelim changes result of function call Product: libraries Version: 2.0 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Interprocedural Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: jay.foad at antixlabs.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1165) --> (http://llvm.org/bugs/attachment.cgi?id=1165) bitcode for test case In the attached bitcode file, main() calls f() and checks the result: %tmp38 = call i32 ([...])* @f( [...] ) ; [#uses=1] %tmp39 = icmp eq i32 %tmp38, 4660 ; [#uses=1] If I run it through "opt -f -o post.o pre.o -deadargelim", this has changed to: %tmp38 = call i32 @f( [...] ) ; [#uses=0] %tmp39 = icmp eq i32 0, 4660 ; [#uses=1] The use of %tmp38 has been replaced with 0. But f() doesn't return 0, it returns 4660: store i32 4660, i32* %pb_addr %retval20 = bitcast i32* %retval to { }* ; <{ }*> [#uses=0] %tmp22 = load i32* %pb_addr ; [#uses=2] store i32 %tmp22, i32* %retval ret i32 %tmp22 So why has the result of the call been replaced with 0? This code is taken from gcc.c-torture/execute/20030914-2.c in the gcc testsuite. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Oct 18 02:51:01 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 18 Oct 2007 02:51:01 -0500 Subject: [LLVMbugs] [Bug 1734] bad assembly output breakes llvm-gcc bootstrap In-Reply-To: Message-ID: <200710180751.l9I7p1co022372@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1734 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #11 from Evan Cheng 2007-10-18 02:51:00 --- This should do it: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071015/054640.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 Oct 18 13:50:10 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 18 Oct 2007 13:50:10 -0500 Subject: [LLVMbugs] [Bug 1735] deadargelim changes result of function call In-Reply-To: Message-ID: <200710181850.l9IIoA5j019753@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1735 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Keywords| |miscompilation Resolution| |FIXED Target Milestone|--- |2.2 --- Comment #1 from Chris Lattner 2007-10-18 13:50:10 --- Fixed, patch here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071015/054669.html 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 Fri Oct 19 06:51:07 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Oct 2007 06:51:07 -0500 Subject: [LLVMbugs] [Bug 1736] New: Frontend incompatibility precluding use of llvm-gcc as a drop-in replacement of gcc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1736 Summary: Frontend incompatibility precluding use of llvm-gcc as a drop-in replacement of gcc Product: cfe Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Basic AssignedTo: unassignedbugs at nondot.org ReportedBy: vda.linux at googlemail.com CC: llvmbugs at cs.uiuc.edu Reduced testcase: struct stat {}; struct stat64 {}; int fxstat(int n, int fd, struct stat *sb); int fxstat64(int n, int fd, struct stat64 *sb); extern int fstat(int fd, struct stat *buf) asm("fstat64"); extern inline int fstat(int fd, struct stat *sb) { return fxstat(3, fd, sb); } extern inline int fstat64(int fd, struct stat64 *sb) { return fxstat64(3, fd, sb); } With llvm-gcc4.0-2.1: gcc -fgnu89-inline -std=gnu99 -c testcase.c error: unrecognized command line option "-fgnu89-inline" gcc -std=gnu99 -c testcase.c error: Assembler messages: /tmp/cc9R2Ci9.s:33: Error: symbol `fstat64' is already defined gcc -c testcase.c ok With gcc-4.2.1: gcc -fgnu89-inline -std=gnu99 -c testcase.c ok gcc -std=gnu99 -c testcase.c warning: C99 inline functions are not supported; using GNU89 gcc -c testcase.c ok -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Oct 19 06:54:14 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Oct 2007 06:54:14 -0500 Subject: [LLVMbugs] [Bug 1737] New: bad code with -std=gnu99 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1737 Summary: bad code with -std=gnu99 Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: llvm-gcc AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Compiling the attached file with llvm-gcc-4.0 with "-std=gnu99" results in test-llvm-99.s: Assembler messages: test-llvm-99.s:38: Error: symbol `fstat64' is already defined The problem looks like to be in llvm-gcc. The generated llvm IL contains define i32 @"\01fstat64"(i32 %__fd, %struct.stat* %__statbuf) .... define i32 @fstat64(i32 %__fd, %struct.stat* %__statbuf) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Oct 19 07:06:36 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Oct 2007 07:06:36 -0500 Subject: [LLVMbugs] [Bug 1737] bad code with -std=gnu99 In-Reply-To: Message-ID: <200710191206.l9JC6aSx012132@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1737 Rafael ??vila de Esp??ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #2 from Rafael ??vila de Esp??ndola 2007-10-19 07:06:36 --- *** This bug has been marked as a duplicate of bug 1736 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Oct 19 09:07:32 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Oct 2007 09:07:32 -0500 Subject: [LLVMbugs] [Bug 1736] Frontend incompatibility precluding use of llvm-gcc as a drop-in replacement of gcc In-Reply-To: Message-ID: <200710191407.l9JE7Wa8017316@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1736 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |asl at math.spbu.ru Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #3 from Anton Korobeynikov 2007-10-19 09:07:31 --- Please read comments in the PR1699. gcc 4.2 (and thus llvm-gcc 4.2) supports proper C99 notion of extern inline. *** This bug has been marked as a duplicate of bug 1699 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Oct 19 09:18:36 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Oct 2007 09:18:36 -0500 Subject: [LLVMbugs] [Bug 1699] multiple definition of inlined asm functions with llvm-gcc-4.2 In-Reply-To: Message-ID: <200710191418.l9JEIaLJ017870@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1699 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #13 from Anton Korobeynikov 2007-10-19 09:18:36 --- I cannot backport fixincludes part from mainline now due to GPLv2/GPLv3 clash. Let's see, what will be 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 Fri Oct 19 09:26:21 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 19 Oct 2007 09:26:21 -0500 Subject: [LLVMbugs] [Bug 1736] Frontend incompatibility precluding use of llvm-gcc as a drop-in replacement of gcc In-Reply-To: Message-ID: <200710191426.l9JEQLRd018246@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1736 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|DUPLICATE | --- Comment #6 from Anton Korobeynikov 2007-10-19 09:26:21 --- Ok. Maybe this was closed too early. We definitely need some language lawyer :) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Oct 22 13:06:47 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 22 Oct 2007 13:06:47 -0500 Subject: [LLVMbugs] [Bug 1738] New: llvm_fcmp_ord and llvm_fcmp_uno and assembly code generation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1738 Summary: llvm_fcmp_ord and llvm_fcmp_uno and assembly code generation Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Keywords: code-quality Severity: minor Priority: P2 Component: llc AssignedTo: unassignedbugs at nondot.org ReportedBy: edwintorok at gmail.com CC: llvmbugs at cs.uiuc.edu [previosuly posted on ML]: Missed optimization in llc, and llvm-gcc. The C backend in llc generates code like: static inline int llvm_fcmp_ord(double X, double Y) { return X == X && Y == Y; } static inline int llvm_fcmp_uno(double X, double Y) { return X != X || Y != Y; } First of all it generates a warning by clang and gcc (with certain flags): x.cbe.c:130: warning: comparing floating point with == or != is unsafe Now, C99 provides a macro for this kind of stuff, but unfortunately ANSI C doesn't have something like this (for unordered testing) AFAIK. *If* we would be using C99 the code could look like: return isunordered(X, Y); return !isunordered(X, Y); However the assembly code generated is much shorter if I am using the C99 macros, both on gcc and llvm-gcc. This raises 2 issues: * can llvm_fcmp_ord/uno be implemented in ANSI/ISO C differently, which doesn't generate a warning, *and* generates optimal code * can llvm-gcc be improved to recognize functions like llvm_fcmp_ord/uno, and generate the optimal code (one ucomisd, rather than two). Not that llvm_fcmp_ord/uno would be on a critical path in a program, but any optimization is good, and worth mentioning IMHO ;) Look: #include static inline int llvm_fcmp_ord(double X, double Y) { return X == X && Y == Y; } static inline int llvm_fcmp_uno(double X, double Y) { return X != X || Y != Y; } int x(double X, double Y) { return llvm_fcmp_uno(X,Y); } int xx(double X, double Y) { return isunordered(X, Y); } $ gcc -std=c99 -O3 -S x.c -o x.gcc.s $ llvm-gcc -std=c99 -O3 -S x.c -o x.llvm.s x.gcc.s: x: .LFB7: movl $1, %eax ucomisd %xmm0, %xmm0 jne .L5 jp .L5 xorl %eax, %eax ucomisd %xmm1, %xmm1 setp %al .L5: rep ; ret .LFE7: .size x, .-x .p2align 4,,15 .globl xx .type xx, @function xx: .LFB8: xorl %eax, %eax ucomisd %xmm1, %xmm0 setp %al ret x.llvm.s: x: pxor %xmm2, %xmm2 ucomisd %xmm2, %xmm0 setp %al ucomisd %xmm2, %xmm1 setp %cl orb %al, %cl movzbl %cl, %eax ret .size x, .-x .align 16 .globl xx .type xx, at function xx: ucomisd %xmm1, %xmm0 setp %al movzbl %al, %eax ret .size xx, .-xx -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 23 00:49:35 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 23 Oct 2007 00:49:35 -0500 Subject: [LLVMbugs] [Bug 1739] New: llvm-config --cflags in build dir prints incorrect -I flag Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1739 Summary: llvm-config --cflags in build dir prints incorrect -I flag Product: tools Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: llvm-config AssignedTo: unassignedbugs at nondot.org ReportedBy: sabre at nondot.org CC: llvmbugs at cs.uiuc.edu When running llvm-config in the build directory, it should point to the -I include directory in the source, not in the build directory. For example, it's printing: -I/Users/sabre/llvm/Debug/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS but /Users/sabre/llvm/Debug/include doesn't exist! -Chris -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 23 22:36:23 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 23 Oct 2007 22:36:23 -0500 Subject: [LLVMbugs] [Bug 1740] New: segfault when using va_arg on x86-68 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1740 Summary: segfault when using va_arg on x86-68 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: tomas.l.olsen at gmail.com CC: llvmbugs at cs.uiuc.edu Using the LLVM 2.1 release, the following test case segfaults when run; a.ll: define i32 @test(i32 %X, ...) { %ap = alloca i8*, i32 1024 %ap2 = bitcast i8** %ap to i8* call void @llvm.va_start(i8* %ap2) %tmp = va_arg i8** %ap, i32 call void @llvm.va_end(i8* %ap2) ret i32 %tmp } declare void @llvm.va_start(i8*) declare void @llvm.va_end(i8*) define i32 @main(i32, i8**, i8**) { %ret = call i32(i32, ...)* @test(i32 0, i32 0) ret i32 %ret } result: $ llvm-as -f a.ll && llc -f a.bc && gcc a.s && ./a.out 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 Tue Oct 23 23:36:35 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 23 Oct 2007 23:36:35 -0500 Subject: [LLVMbugs] [Bug 1739] llvm-config --cflags in build dir prints incorrect -I flag In-Reply-To: Message-ID: <200710240436.l9O4aZfP029367@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1739 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2007-10-23 23:36:35 --- It turns out that llvm-config had the right code for doing this, but was getting confused because my llvm tree lives behind a symlink. This patch fixes it: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071022/054838.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 Oct 24 00:42:22 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 24 Oct 2007 00:42:22 -0500 Subject: [LLVMbugs] [Bug 1738] llvm_fcmp_ord and llvm_fcmp_uno and assembly code generation In-Reply-To: Message-ID: <200710240542.l9O5gMo8032249@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1738 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2007-10-24 00:42:21 --- This PR has a number of issues: 1. clang and gcc emit a warning. I plan to eventually silence the warning in clang for X != X and X == X, as that is a good way to test for a nan. I can't do anything about C. 2. We can't include math.h in CBE output (this brings in macros which can rewrite the CBE stuff, wreaking havoc :(, so we can't get the standard macro definitions of isunordered, etc. 3. GCC isn't producing good code for this, I can't do anything about it, you should file a gcc bug :) 4. LLVM isn't generating good code for this: that is a problem, we can fix that, and I did!: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071022/054842.html Thanks for filing this, it's a great thing to be aware of. -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 Oct 24 00:50:57 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 24 Oct 2007 00:50:57 -0500 Subject: [LLVMbugs] [Bug 1741] New: BasicAA miscompilation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1741 Summary: BasicAA miscompilation Product: libraries Version: 2.1 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Global Analyses AssignedTo: unassignedbugs at nondot.org ReportedBy: sabre at nondot.org CC: llvmbugs at cs.uiuc.edu Consider this code: struct A { int x ;}; struct B : A { }; B a; int foo(A* b) { a.x = 1; b->x = 0; return a.x; } int main() { foo(&a); } llvm-gcc incorrectly misoptimizes foo to return 1 directly. If you reduce it down, it is because GVN is transforming this code invalidly: target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128" target triple = "i686-apple-darwin8" %struct.A = type { i32 } %struct.B = type { %struct.A } @a = global %struct.B zeroinitializer ; <%struct.B*> [#uses=2] define i32 @_Z3fooP1A(%struct.A* %b) { entry: store i32 1, i32* getelementptr (%struct.B* @a, i32 0, i32 0, i32 0), align 8 %tmp4 = getelementptr %struct.A* %b, i32 0, i32 0 ; [#uses=1] store i32 0, i32* %tmp4, align 4 %tmp7 = load i32* getelementptr (%struct.B* @a, i32 0, i32 0, i32 0), align 8 ; [#uses=1] ret i32 %tmp7 } It deletes the load and makes 'ret i32 1'. This invalid transformation is happening because BasicAA is returning no-alias for tmp4 and the @A gep constant expr: $ llvm-as < t.ll | opt -count-aa -gvn -count-aa-print-all-queries | llvm-dis No alias: [4B] i32* %tmp4, [4B] i32* getelementptr (%struct.B* @a, i32 0, i32 0, i32 0) ... This should be investigated, -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 zvrba at ifi.uio.no Wed Oct 24 06:09:08 2007 From: zvrba at ifi.uio.no (Zeljko Vrba) Date: Wed, 24 Oct 2007 13:09:08 +0200 Subject: [LLVMbugs] Compile error on 64-bit x86 Solaris Message-ID: <20071024110908.GA4889@gampen.ifi.uio.no> I'm using gcc-4.2.2 and while compiling, I get the following error: In file included from /home/zvrba/llvm-2.1/lib/VMCore/AsmWriter.cpp:18: /home/zvrba/llvm-2.1/include/llvm/Assembly/PrintModulePass.h:34: error: expected ',' or '...' before numeric constant /home/zvrba/llvm-2.1/include/llvm/Assembly/PrintModulePass.h:60: error: expected ',' or '...' before numeric constant /home/zvrba/llvm-2.1/include/llvm/Assembly/PrintModulePass.h:60: error: default argument missing for parameter 3 of 'llvm::PrintFunctionPass::PrintFunctionPass(const std::string&, llvm::OStream*, bool)' /home/zvrba/llvm-2.1/lib/VMCore/AsmWriter.cpp: In function 'void WriteConstantInt(std::ostream&, const llvm::Constant*, std::map, std::allocator >, std::less, std::allocator, std::allocator > > > >&, llvm::SlotMachine*)': /home/zvrba/llvm-2.1/lib/VMCore/AsmWriter.cpp:569: error: expected primary-expression before 'const' /home/zvrba/llvm-2.1/lib/VMCore/AsmWriter.cpp:569: error: expected `)' before 'const' PrintModulePass.h:34 is PrintModulePass(OStream *o, bool DS = false) .. Now, the problem is that the system header gets included which contains the following #defines: #define CS 15 #define DS 3 (among others). The LLVM code uses very much both of those names which results in a buch of compiler errors similar to the above. I have traced the error, and this header is included indirectly through . Unfortunately, other system header files also include so it's not _that_ simple to put #undef CS / #undef DS in the few (3) LLVM files that explicitly include . I have tried to modify the Makefile.rules that originally contains CPP.BaseFlags += -D_GNU_SOURCE ... [at line 455] to CPP.BaseFlags += -D_XPG4_2 ... This still produces the error. Setting the variable to CPP.BaseFlags += -D_XPG4_2 -U__EXTENSIONS__ produces _another_ compiler error saying that error: '::vfwscanf' has not been declared (among other "wide" functions). [I have played with those exact macros after reading through the header]. Any suggestions on how to fix this problem? I have been thinking of a global search/replace perl script (replacing eg. CS -> CSs, DS -> DSs), but given different contexts where these words can appear, this seems fragile (e.g. after parentheses, before parentheses, etc.) Best regards, Zeljko. From dalej at apple.com Wed Oct 24 11:32:32 2007 From: dalej at apple.com (Dale Johannesen) Date: Wed, 24 Oct 2007 09:32:32 -0700 Subject: [LLVMbugs] Compile error on 64-bit x86 Solaris In-Reply-To: <20071024110908.GA4889@gampen.ifi.uio.no> References: <20071024110908.GA4889@gampen.ifi.uio.no> Message-ID: On Oct 24, 2007, at 4:09 AM, Zeljko Vrba wrote: > I'm using gcc-4.2.2 and while compiling, I get the following error: > > In file included from /home/zvrba/llvm-2.1/lib/VMCore/AsmWriter.cpp: > 18: > /home/zvrba/llvm-2.1/include/llvm/Assembly/PrintModulePass.h:34: > error: expected ',' or '...' before numeric constant > /home/zvrba/llvm-2.1/include/llvm/Assembly/PrintModulePass.h:60: > error: expected ',' or '...' before numeric constant > /home/zvrba/llvm-2.1/include/llvm/Assembly/PrintModulePass.h:60: > error: default argument missing for parameter 3 of > 'llvm::PrintFunctionPass::PrintFunctionPass(const std::string&, > llvm::OStream*, bool)' > /home/zvrba/llvm-2.1/lib/VMCore/AsmWriter.cpp: In function 'void > WriteConstantInt(std::ostream&, const llvm::Constant*, > std::map std::char_traits, std::allocator >, std::less llvm::Type*>, std::allocator std::basic_string, > std::allocator > > > >&, llvm::SlotMachine*)': > /home/zvrba/llvm-2.1/lib/VMCore/AsmWriter.cpp:569: error: expected > primary-expression before 'const' > /home/zvrba/llvm-2.1/lib/VMCore/AsmWriter.cpp:569: error: expected > `)' before 'const' > > PrintModulePass.h:34 is > > PrintModulePass(OStream *o, bool DS = false) .. > > Now, the problem is that the system header gets > included which contains the following #defines: > > #define CS 15 > #define DS 3 > > (among others). The LLVM code uses very much both of those names > which results in a buch of compiler errors similar to the above. Those names are in the user namespace; it is incorrect for to be defining them. Any chance of getting your headers fixed? From sabre at nondot.org Wed Oct 24 12:21:54 2007 From: sabre at nondot.org (Chris Lattner) Date: Wed, 24 Oct 2007 10:21:54 -0700 (PDT) Subject: [LLVMbugs] Compile error on 64-bit x86 Solaris In-Reply-To: References: <20071024110908.GA4889@gampen.ifi.uio.no> Message-ID: On Wed, 24 Oct 2007, Dale Johannesen wrote: >> Now, the problem is that the system header gets >> included which contains the following #defines: >> >> #define CS 15 >> #define DS 3 >> >> (among others). The LLVM code uses very much both of those names >> which results in a buch of compiler errors similar to the above. > > Those names are in the user namespace; it is incorrect for > to be defining them. Any chance of getting your headers fixed? Two things: 1. Only .cpp files in lib/System should include . If there are others, we should eliminate them and move the system-specific functionality there. 2. Assuming that you can't change solaris :), it would be fine to do this: #include #undef CS // hack for broken solaris headers #undef DS // hack for broken solaris headers This is clearly ugly if spread through the source tree, which is why #1 is important :) -Chris -- http://nondot.org/sabre/ http://llvm.org/ From zvrba at ifi.uio.no Wed Oct 24 11:55:01 2007 From: zvrba at ifi.uio.no (Zeljko Vrba) Date: Wed, 24 Oct 2007 18:55:01 +0200 Subject: [LLVMbugs] Compile error on 64-bit x86 Solaris In-Reply-To: References: <20071024110908.GA4889@gampen.ifi.uio.no> Message-ID: <20071024165501.GE4889@gampen.ifi.uio.no> On Wed, Oct 24, 2007 at 09:32:32AM -0700, Dale Johannesen wrote: > > Those names are in the user namespace; it is incorrect for > to be defining them. Any chance of getting your headers fixed? > Hardly. Theoretically, you're right, but even Linux uses some names from the user namespace: #define unix 1 #define linux 1 #define i386 1 (dump obtained by cpp -dM; and these are just macros predefined by the cpp; w/o any other include files). Practically, your point is moot because system headers (unfortunately) *do* define a bunch of additional macros in the user namespace. Try to compile the following program in Linux and "get the developers to fix the headers": #include #include int f(int NGREG) { return NGREG + 1; } Simple gcc -c is sufficient. The only difference is that on Solaris the gets pulled in by . Or just substitute NGREG by e.g. REG_GS. IMHO, it is a bad coding style to name variables by a widely-accepted naming convention "reserved" (again, by convention) for macros (i.e. all capitals). From zvrba at ifi.uio.no Wed Oct 24 12:01:59 2007 From: zvrba at ifi.uio.no (Zeljko Vrba) Date: Wed, 24 Oct 2007 19:01:59 +0200 Subject: [LLVMbugs] Compile error on 64-bit x86 Solaris In-Reply-To: References: <20071024110908.GA4889@gampen.ifi.uio.no> Message-ID: <20071024170159.GF4889@gampen.ifi.uio.no> On Wed, Oct 24, 2007 at 10:21:54AM -0700, Chris Lattner wrote: > > Two things: > 1. Only .cpp files in lib/System should include . If there are > others, we should eliminate them and move the system-specific > functionality there. > 2. Assuming that you can't change solaris :), it would be fine to do this: > > #include > #undef CS // hack for broken solaris headers > #undef DS // hack for broken solaris headers > No, the problem is a "bit" more complicated: other LLVM files include headers *other than* , and those headers in turn include . Grepping shows that is included only from the following files: ./lib/System/Unix/Program.inc ./lib/System/Unix/Alarm.inc ./lib/System/Unix/Signals.inc I tried to add #undefs in those files, but that did not fix the problem. From sabre at nondot.org Wed Oct 24 12:52:59 2007 From: sabre at nondot.org (Chris Lattner) Date: Wed, 24 Oct 2007 10:52:59 -0700 (PDT) Subject: [LLVMbugs] Compile error on 64-bit x86 Solaris In-Reply-To: <20071024170159.GF4889@gampen.ifi.uio.no> References: <20071024110908.GA4889@gampen.ifi.uio.no> <20071024170159.GF4889@gampen.ifi.uio.no> Message-ID: On Wed, 24 Oct 2007, Zeljko Vrba wrote: > No, the problem is a "bit" more complicated: other LLVM files include > headers *other than* , and those headers in turn include > . Grepping shows that is included only from the > following files: Ok, which ones are we talking about? -Chris -- http://nondot.org/sabre/ http://llvm.org/ From zvrba at ifi.uio.no Wed Oct 24 12:34:28 2007 From: zvrba at ifi.uio.no (Zeljko Vrba) Date: Wed, 24 Oct 2007 19:34:28 +0200 Subject: [LLVMbugs] Compile error on 64-bit x86 Solaris In-Reply-To: References: <20071024110908.GA4889@gampen.ifi.uio.no> Message-ID: <20071024173427.GG4889@gampen.ifi.uio.no> On Wed, Oct 24, 2007 at 09:32:32AM -0700, Dale Johannesen wrote: > > Those names are in the user namespace; it is incorrect for > to be defining them. Any chance of getting your headers fixed? > To be even more to the point: this problem with names does *not* occur without __EXTENSIONS__ define that you use in the "master" makefile (presumably, to get some "wide" functions). But extensions are, by definition, platform-dependent and can define many names in the user namespace, so it does not logically follow that headers are "broken" because you _explicitly_ asked for extensions (and got more than you needed)! If anything, it's a problem of a single __EXTENSIONS__ feature macro that might pull in just about any name. From zvrba at ifi.uio.no Wed Oct 24 12:38:34 2007 From: zvrba at ifi.uio.no (Zeljko Vrba) Date: Wed, 24 Oct 2007 19:38:34 +0200 Subject: [LLVMbugs] Compile error on 64-bit x86 Solaris In-Reply-To: References: <20071024110908.GA4889@gampen.ifi.uio.no> <20071024170159.GF4889@gampen.ifi.uio.no> Message-ID: <20071024173834.GH4889@gampen.ifi.uio.no> On Wed, Oct 24, 2007 at 10:52:59AM -0700, Chris Lattner wrote: > > Ok, which ones are we talking about? > I haven't tracked it down yet. Namely, the following program compiles correctly: #include int f(int DS) { return DS+1; } even with the __EXTENSIONS__ define. Adding the header breaks it even w/o __EXTENSIONS__ define. So something else implicitly pulls in the ucontext.h header. I'll notify you when I track down the exact include chain that pulls in the ucontext.h or sys/ucontext.h header(s). From zvrba at ifi.uio.no Wed Oct 24 13:06:49 2007 From: zvrba at ifi.uio.no (Zeljko Vrba) Date: Wed, 24 Oct 2007 20:06:49 +0200 Subject: [LLVMbugs] Compile error on 64-bit x86 Solaris In-Reply-To: References: <20071024110908.GA4889@gampen.ifi.uio.no> <20071024170159.GF4889@gampen.ifi.uio.no> Message-ID: <20071024180648.GI4889@gampen.ifi.uio.no> On Wed, Oct 24, 2007 at 10:52:59AM -0700, Chris Lattner wrote: > On Wed, 24 Oct 2007, Zeljko Vrba wrote: > >No, the problem is a "bit" more complicated: other LLVM files include > >headers *other than* , and those headers in turn include > >. Grepping shows that is included only from the > >following files: > > Ok, which ones are we talking about? > Here's the chain of includes (dumped by -H option to g++) that leads to the inclusion of ucontext.h header (each . is an include depth): . /home/zvrba/llvm-2.1/include/llvm/Assembly/PrintModulePass.h .. /home/zvrba/llvm0.1/include/llvm/Pass.h ... /home/zvrba/llvm-2.1/include/llvm/Support/Streams.h ... /opt/gcc42/lib/gcc/i386-pc-solaris2.10/4.2.2/../../../../include/c++/4.2.2/vector .... /opt/gcc42/lib/gcc/i386-pc-solaris2.10/4.2.2/../../../../include/c++/4.2.2/bits/stl_algoba ..... /opt/gcc42/lib/gcc/i386-pc-solaris2.10/4.2.2/../../../../include/c++/4.2.2/climits ...... /opt/gcc42/lib/gcc/i386-pc-solaris2.10/4.2.2/include/limits.h ....... /opt/gcc42/lib/gcc/i386-pc-solaris2.10/4.2.2/include/syslimits.h ........ /opt/gcc42/lib/gcc/i386-pc-solaris2.10/4.2.2/include/limits.h ......... /usr/include/limits.h .......... /usr/include/iso/limits_iso.h ..... /opt/gcc42/lib/gcc/i386-pc-solaris2.10/4.2.2/../../../../include/c++/4.2.2/cstdlib ...... /usr/include/stdlib.h ....... /usr/include/iso/stdlib_iso.h ....... /usr/include/iso/stdlib_c99.h ....... /usr/include/sys/wait.h ........ /usr/include/sys/resource.h ........ /usr/include/sys/siginfo.h ......... /usr/include/sys/machsig.h .......... /usr/include/vm/faultcode.h ........ /usr/include/sys/procset.h ......... /usr/include/sys/signal.h .......... /usr/include/sys/iso/signal_iso.h .......... /usr/include/sys/ucontext.h ........... /usr/include/sys/regset.h ............ /usr/include/sys/privregs.h ............. /usr/include/ia32/sys/privregs.h .............. /usr/include/sys/controlregs.h ........... /usr/include/sys/signal.h includes which in turn includes everything up to and including . The inclusion of in is guarded by #if defined(__EXTENSIONS__) || defined(_XPG4) #include #endif From sabre at nondot.org Wed Oct 24 13:51:35 2007 From: sabre at nondot.org (Chris Lattner) Date: Wed, 24 Oct 2007 11:51:35 -0700 (PDT) Subject: [LLVMbugs] Compile error on 64-bit x86 Solaris In-Reply-To: <20071024180648.GI4889@gampen.ifi.uio.no> References: <20071024110908.GA4889@gampen.ifi.uio.no> <20071024170159.GF4889@gampen.ifi.uio.no> <20071024180648.GI4889@gampen.ifi.uio.no> Message-ID: On Wed, 24 Oct 2007, Zeljko Vrba wrote: >>> following files: >> >> Ok, which ones are we talking about? > Here's the chain of includes (dumped by -H option to g++) that leads > to the inclusion of ucontext.h header (each . is an include depth): Ugh. We can't hack every #include of > including . The inclusion of in is > guarded by > > #if defined(__EXTENSIONS__) || defined(_XPG4) > #include > #endif Please try to find a way to make sure these aren't defined :). Are the #defines of DS and CS guarded by anything in wait.h? -Chris -- http://nondot.org/sabre/ http://llvm.org/ From zvrba at ifi.uio.no Wed Oct 24 13:27:19 2007 From: zvrba at ifi.uio.no (Zeljko Vrba) Date: Wed, 24 Oct 2007 20:27:19 +0200 Subject: [LLVMbugs] Compile error on 64-bit x86 Solaris In-Reply-To: References: <20071024110908.GA4889@gampen.ifi.uio.no> <20071024170159.GF4889@gampen.ifi.uio.no> <20071024180648.GI4889@gampen.ifi.uio.no> Message-ID: <20071024182719.GJ4889@gampen.ifi.uio.no> On Wed, Oct 24, 2007 at 11:51:35AM -0700, Chris Lattner wrote: > On Wed, 24 Oct 2007, Zeljko Vrba wrote: > >>>following files: > >> > >>Ok, which ones are we talking about? > >Here's the chain of includes (dumped by -H option to g++) that leads > >to the inclusion of ucontext.h header (each . is an include depth): > > Ugh. We can't hack every #include of > No, it's not , but > >including . The inclusion of in is > >guarded by > > > >#if defined(__EXTENSIONS__) || defined(_XPG4) > >#include > >#endif > > Please try to find a way to make sure these aren't defined :). > If __EXTENSIONS__ aren't defined (I don't know yet what defines them), I get the following error (I specify -U__EXTENSIONS__ on the command line): /opt/gcc42/lib/gcc/i386-pc-solaris2.10/4.2.2/../../../../include/c++/4.2.2/cwchar:169: error: '::vfwscanf' has not been declared (and others) > > Are the #defines of DS and CS guarded by anything in wait.h? > They are guarded in by: #if !defined(_XPG4_2) || defined(__EXTENSIONS__) From zvrba at ifi.uio.no Wed Oct 24 13:30:02 2007 From: zvrba at ifi.uio.no (Zeljko Vrba) Date: Wed, 24 Oct 2007 20:30:02 +0200 Subject: [LLVMbugs] Compile error on 64-bit x86 Solaris In-Reply-To: <20071024182719.GJ4889@gampen.ifi.uio.no> References: <20071024110908.GA4889@gampen.ifi.uio.no> <20071024170159.GF4889@gampen.ifi.uio.no> <20071024180648.GI4889@gampen.ifi.uio.no> <20071024182719.GJ4889@gampen.ifi.uio.no> Message-ID: <20071024183002.GK4889@gampen.ifi.uio.no> On Wed, Oct 24, 2007 at 08:27:19PM +0200, Zeljko Vrba wrote: > On Wed, Oct 24, 2007 at 11:51:35AM -0700, Chris Lattner wrote: > > On Wed, 24 Oct 2007, Zeljko Vrba wrote: > > >>>following files: > > >> > > >>Ok, which ones are we talking about? > > >Here's the chain of includes (dumped by -H option to g++) that leads > > >to the inclusion of ucontext.h header (each . is an include depth): > > > > Ugh. We can't hack every #include of > > > No, it's not , but > Sorry, From bugzilla-daemon at cs.uiuc.edu Wed Oct 24 19:49:15 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 24 Oct 2007 19:49:15 -0500 Subject: [LLVMbugs] [Bug 1397] K&R style struct returning functions don't get sret attribute In-Reply-To: Message-ID: <200710250049.l9P0nF9v010789@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1397 Dale Johannesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #9 from Dale Johannesen 2007-10-24 19:49:14 --- I meant Duncan actually, but OK. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Oct 24 21:37:28 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 24 Oct 2007 21:37:28 -0500 Subject: [LLVMbugs] [Bug 1741] BasicAA miscompilation In-Reply-To: Message-ID: <200710250237.l9P2bSlg016111@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1741 Owen Anderson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Owen Anderson 2007-10-24 21:37:28 --- Fixed. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071022/054882.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 zvrba at ifi.uio.no Thu Oct 25 01:38:30 2007 From: zvrba at ifi.uio.no (Zeljko Vrba) Date: Thu, 25 Oct 2007 08:38:30 +0200 Subject: [LLVMbugs] Compile error on 64-bit x86 Solaris In-Reply-To: References: <20071024110908.GA4889@gampen.ifi.uio.no> <20071024170159.GF4889@gampen.ifi.uio.no> <20071024180648.GI4889@gampen.ifi.uio.no> Message-ID: <20071025063830.GL4889@gampen.ifi.uio.no> On Wed, Oct 24, 2007 at 11:51:35AM -0700, Chris Lattner wrote: > > Please try to find a way to make sure these aren't defined :). > Preprocessing shows that the __EXTENSIONS__ macro is gcc's builtin define (gcc 4.2.2): # 1 "/home/zvrba/llvm-2.1/lib/VMCore/AsmWriter.cpp" # 1 "" #define __cplusplus 1 -cut- #define __EXTENSIONS__ 1 ... The following in Makefile.rules seems to work on x86 Solaris 10: CPP.BaseFlags += -D_XPG6 -D_STDC_C99 -U__EXTENSIONS__ -D__STDC_LIMIT_MACROS However, the final link fails. ==== Additional fixes: the ARM target needs to #include in order to be able to use strncasecmp function. ==== BTW, another problem: make fails when running bison with: /home/zvrba/llvm-2.1/lib/AsmParser/llvmAsmParser.y: conflicts: 4 shift/reduce make[2]: *** [/home/zvrba/llvm-2.1/lib/AsmParser/llvmAsmParser.h] Broken Pipe I have handled the problem by deleting .y files and taking .cpp.cvs files. Manually running bison _works_, so something else is going on. From zvrba at ifi.uio.no Thu Oct 25 02:52:41 2007 From: zvrba at ifi.uio.no (Zeljko Vrba) Date: Thu, 25 Oct 2007 09:52:41 +0200 Subject: [LLVMbugs] Compile error on 64-bit x86 Solaris In-Reply-To: <20071025063830.GL4889@gampen.ifi.uio.no> References: <20071024110908.GA4889@gampen.ifi.uio.no> <20071024170159.GF4889@gampen.ifi.uio.no> <20071024180648.GI4889@gampen.ifi.uio.no> <20071025063830.GL4889@gampen.ifi.uio.no> Message-ID: <20071025075241.GM4889@gampen.ifi.uio.no> On Thu, Oct 25, 2007 at 08:38:30AM +0200, Zeljko Vrba wrote: > > The following in Makefile.rules seems to work on x86 Solaris 10: > CPP.BaseFlags += -D_XPG6 -D_STDC_C99 -U__EXTENSIONS__ -D__STDC_LIMIT_MACROS > Doesn't work. It worked only on partially compiled code; it tries to use the restrict keyword (because of _STDC_C99) and the compilation breaks. There doesn't seem to exist a combination of feature macros that at the same time: 1) enables all the features that LLVM wants 2) does not pull in constants that LLVM regularly uses as variable names. Finally I did the following: find . -name '*.h' -o -name '*.cpp' | xargs perl -pi -e 's/\b([SGEFCD]S)\b/\1s/g;' To replace the offending names with the same name followed by 's'. Similar find/replace should be done for the following names: EAX ECX EDX EBX ESP EBP ESI EDI EIP EFLAGS Further errors: /home/zvrba/llvm-build/mklib: line 6305: ../llvm-2.1/autoconf/install-sh: No such file or directory make[3]: *** [/home/zvrba/llvm-build/Release/lib/LLVMHello.la] Error 127 make[3]: Leaving directory `/home/zvrba/llvm-build/lib/Transforms/Hello' make[2]: *** [Hello/.makeall] Error 2 make[2]: Leaving directory `/home/zvrba/llvm-build/lib/Transforms' make[1]: *** [Transforms/.makeall] Error 2 make[1]: *** Waiting for unfinished jobs.... + I had to #undef some register names in other files (also the auto-generated ones) as they clash with registers defined in the system headers. I can send you a full diff if you want. == CONCLUSION: With a bunch of manual fiddling, #undefing and renaming of variables, I finally got it to link and build. Now I have to figure out how to install it, because make install gives a bunch of: /bin/sh: ../llvm-2.1/autoconf/install-sh: not found even though the file is there. Anyway, I'm sorry to report, but LLVM is a _mess_ to build on x86 Solaris 10. (And no, I don't blame it on the platform). If I get some cleanly compileable source tree (i.e. once after I've figured out how to make a compilation run unattended), I will send you the diff and you're free to do whatever you want to with it. From sabre at nondot.org Thu Oct 25 14:18:35 2007 From: sabre at nondot.org (Chris Lattner) Date: Thu, 25 Oct 2007 12:18:35 -0700 (PDT) Subject: [LLVMbugs] Compile error on 64-bit x86 Solaris In-Reply-To: <20071025063830.GL4889@gampen.ifi.uio.no> References: <20071024110908.GA4889@gampen.ifi.uio.no> <20071024170159.GF4889@gampen.ifi.uio.no> <20071024180648.GI4889@gampen.ifi.uio.no> <20071025063830.GL4889@gampen.ifi.uio.no> Message-ID: On Thu, 25 Oct 2007, Zeljko Vrba wrote: > The following in Makefile.rules seems to work on x86 Solaris 10: > CPP.BaseFlags += -D_XPG6 -D_STDC_C99 -U__EXTENSIONS__ -D__STDC_LIMIT_MACROS > However, the final link fails. Ok, when you get the link to succeed, please prepare a patch for makefile.rules that handles this. > Additional fixes: the ARM target needs to #include in > order to be able to use strncasecmp function. Dale, can you please change the ARM target to not use strncasecmp? It is a non-standard function that hurts portability. > BTW, another problem: make fails when running bison with: > > /home/zvrba/llvm-2.1/lib/AsmParser/llvmAsmParser.y: conflicts: 4 shift/reduce > make[2]: *** [/home/zvrba/llvm-2.1/lib/AsmParser/llvmAsmParser.h] Broken Pipe > > I have handled the problem by deleting .y files and taking .cpp.cvs files. > Manually running bison _works_, so something else is going on. No idea :) -Chris -- http://nondot.org/sabre/ http://llvm.org/ From bugzilla-daemon at cs.uiuc.edu Thu Oct 25 22:12:46 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 25 Oct 2007 22:12:46 -0500 Subject: [LLVMbugs] [Bug 907] [ppc] llc compiles many small loops from 464. h264ref into poor code In-Reply-To: Message-ID: <200710260312.l9Q3CkFk031569@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=907 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #3 from Chris Lattner 2007-10-25 22:12:44 --- This should be addressed in a readme. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Oct 26 11:54:45 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 26 Oct 2007 11:54:45 -0500 Subject: [LLVMbugs] [Bug 1742] New: invalid code generation on x86 with SSE enabled Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1742 Summary: invalid code generation on x86 with SSE enabled Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Keywords: miscompilation Severity: critical Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: tomas.l.olsen at gmail.com CC: llvmbugs at cs.uiuc.edu The following .ll does not work as expected. Instead of printing 36 it prints nan. 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:8" target triple = "i686-unknown-linux-gnu" %"1e1C" = type { double, double } @"1e1C__initZ" = constant %"1e1C" zeroinitializer ; <%"1e1C"*> [#uses=2] @stringliteral = internal constant [4 x i8] c"%f\0A\00" ; <[4 x i8]*> [#uses=1] define fastcc double @_D1e1C3dotMFKS1e1CZd(%"1e1C"* %this, %"1e1C"* %b) { entry: %tmp = getelementptr %"1e1C"* %this, i32 0, i32 0 ; [#uses=1] %tmp1 = getelementptr %"1e1C"* %b, i32 0, i32 0 ; [#uses=1] %tmp2 = load double* %tmp ; [#uses=1] %tmp3 = load double* %tmp1 ; [#uses=1] %tmp4 = mul double %tmp2, %tmp3 ; [#uses=1] %tmp5 = getelementptr %"1e1C"* %this, i32 0, i32 1 ; [#uses=1] %tmp6 = getelementptr %"1e1C"* %b, i32 0, i32 1 ; [#uses=1] %tmp7 = load double* %tmp5 ; [#uses=1] %tmp8 = load double* %tmp6 ; [#uses=1] %tmp9 = mul double %tmp7, %tmp8 ; [#uses=1] %tmp10 = add double %tmp4, %tmp9 ; [#uses=1] ret double %tmp10 } define fastcc i32 @_Dmain() { entry: %a = alloca %"1e1C" ; <%"1e1C"*> [#uses=4] %b = alloca %"1e1C" ; <%"1e1C"*> [#uses=4] %d = alloca double ; [#uses=3] %tmp = bitcast %"1e1C"* %a to i8* ; [#uses=1] %tmp1 = bitcast %"1e1C"* @"1e1C__initZ" to i8* ; [#uses=1] call void @llvm.memcpy.i32( i8* %tmp, i8* %tmp1, i32 16, i32 0 ) %tmp2 = bitcast %"1e1C"* %b to i8* ; [#uses=1] %tmp3 = bitcast %"1e1C"* @"1e1C__initZ" to i8* ; [#uses=1] call void @llvm.memcpy.i32( i8* %tmp2, i8* %tmp3, i32 16, i32 0 ) %tmp4 = getelementptr %"1e1C"* %a, i32 0, i32 0 ; [#uses=1] store double 2.000000e+00, double* %tmp4 %tmp5 = getelementptr %"1e1C"* %a, i32 0, i32 1 ; [#uses=1] store double 6.000000e+00, double* %tmp5 %tmp6 = getelementptr %"1e1C"* %b, i32 0, i32 0 ; [#uses=1] store double 3.000000e+00, double* %tmp6 %tmp7 = getelementptr %"1e1C"* %b, i32 0, i32 1 ; [#uses=1] store double 5.000000e+00, double* %tmp7 %tmp8 = call double @_D1e1C3dotMFKS1e1CZd( %"1e1C"* %a, %"1e1C"* %b ) ; [#uses=1] store double %tmp8, double* %d %tmp9 = load double* %d ; [#uses=1] %tmp10 = call i32 (i8*, ...)* @printf( i8* getelementptr ([4 x i8]* @stringliteral, i32 0, i32 0), double %tmp9 ) ; [#uses=0] ret i32 0 } declare void @llvm.memcpy.i32(i8*, i8*, i32, i32) declare i32 @printf(i8*, ...) define i32 @main(i32, i8**, i8**) { entry: %ret = call fastcc i32 @_Dmain( ) ; [#uses=1] ret i32 %ret } Following is a paste of the IRC chat I had with baldrick after finding the problem: lindquist: if I turn off SSE then I get 36 lindquist: the interesting thing is that _D1e1C3dotMFKS1e1CZd returns 36 in xmm0 so somehow it's not getting printed right! p $xmm0 v2_double = {36, 0} (from the debugger, after returning from the subroutine) 0x0804843f <_Dmain+159>: fstpl 0x10(%esp) 0x08048443 <_Dmain+163>: movsd 0x10(%esp),%xmm0 lindquist: I've got to go, but anyway here's the problem: _D1e1C3dotMFKS1e1CZd returns the result in xmm0 the above two lines correspond to store double %tmp8, double* %d and %tmp9 = load double* %d but it's not storing xmm0 to the stack, it's storing the value on the x86 floating point stack! (Which hasn't been used because we are using SSE here) lindquist: so it seems to me that some x86 code is confused, and hasn't realised that the return value was in an SSE register and not on the floating point stack lindquist: this is a bad bug, please report it baldrick, I will. thank you for clearing things up for me -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Oct 26 15:48:22 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 26 Oct 2007 15:48:22 -0500 Subject: [LLVMbugs] [Bug 1743] New: allocation inside loop blows out stack Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1743 Summary: allocation inside loop blows out stack Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: dalej at apple.com CC: llvmbugs at cs.uiuc.edu The following (derived from a gcc test) repeatedly allocates a variable-sized object inside a loop. The intent is that the object should be deallocated each iteration, to avoid blowing out the stack. llvm does not currently do this. (I can't find that the standard requires this behavior, but it seems like a good idea.) void *volatile p; int main (void) { int n; for (n=0; n<1000000; n++) { int x[n % 47 + 1]; x[0] = 1; p = x; } 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 Fri Oct 26 15:57:24 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 26 Oct 2007 15:57:24 -0500 Subject: [LLVMbugs] [Bug 1744] New: llvm-gcc crash on valid initializer Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1744 Summary: llvm-gcc crash on valid initializer Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: dalej at apple.com CC: llvmbugs at cs.uiuc.edu The following (derived from a gcc test) shows a form of global initializer too complex for llvm-gcc to handle. now what? llvm-gcc yy.c ../../llvm-gcc-4.0/gcc/llvm-backend.cpp:782: failed assertion `(TREE_CONSTANT(DECL_INITIAL(decl)) || TREE_CODE(DECL_INITIAL(decl)) == STRING_CST) && "Global initializer should be constant!"' typedef struct foo { int x; char *p; } FOO; FOO yy[] = { {1, "1"}, {2, "2"} }; int *z= (int *) &((yy + 1)->x); -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Oct 26 16:12:58 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 26 Oct 2007 16:12:58 -0500 Subject: [LLVMbugs] [Bug 1743] allocation inside loop blows out stack In-Reply-To: Message-ID: <200710262112.l9QLCwt2026223@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1743 Dale Johannesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Dale Johannesen 2007-10-26 16:12:58 --- Yes, the problem is the optimizer gets rid of it. But I think I oversimplified the test too much, sorry. I'll be back with one that actually 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 Fri Oct 26 16:26:27 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 26 Oct 2007 16:26:27 -0500 Subject: [LLVMbugs] [Bug 1745] New: Variable-sized allocation in loop blows out stack Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1745 Summary: Variable-sized allocation in loop blows out stack Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: dalej at apple.com CC: llvmbugs at cs.uiuc.edu OK, let's try this again. The following (reduced from a gcc test) repeatedly allocates a variable-sized object. The intent is that each should be deallocated before the next is allocated, to avoid blowing out the stack. llvm-gcc generates code to do this, but the optimizer decides the deallocation can be deleted (fails with -O2). I can't get it to fail with any of the standard looping constructs, which diminishes the importance considerably IMO. void *volatile p; int main (void) { int n = 0; lab:; int x[n % 47 + 1]; x[0] = 1; p = x; if (++n < 1000000) goto lab; 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 Fri Oct 26 19:09:08 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 26 Oct 2007 19:09:08 -0500 Subject: [LLVMbugs] [Bug 1746] New: llvm-gcc crash with virtual base classes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1746 Summary: llvm-gcc crash with virtual base classes Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: dalej at apple.com CC: llvmbugs at cs.uiuc.edu The following crash occurs in several g++ tests. Seems to be connected with virtual base classes. class C0 { public: int i0; }; class C1 : public C0 { public: int i1; }; class C2 : public C1 , virtual public C0 { public: int i2; }; class C3 : public C1 , public C2 , virtual public C0 { public: int i3; }; class C4 : virtual public C1 , virtual public C0 , virtual public C3 , public C2 { public: int i4; }; extern void foo4(C4&, int); main() { C4 c4; foo4(c4, 404); } now what? llvm-g++ ooo.cpp ooo.cpp:9: warning: direct base 'C0' inaccessible in 'C2' due to ambiguity ooo.cpp:14: warning: direct base 'C1' inaccessible in 'C3' due to ambiguity ooo.cpp:14: warning: direct base 'C0' inaccessible in 'C3' due to ambiguity ooo.cpp:20: warning: direct base 'C1' inaccessible in 'C4' due to ambiguity ooo.cpp:20: warning: direct base 'C0' inaccessible in 'C4' due to ambiguity ooo.cpp:20: warning: direct base 'C2' inaccessible in 'C4' due to ambiguity ../../llvm-gcc-4.0/gcc/llvm-types.cpp:1700: failed assertion `LLVMStructSize < GCCTypeSize && "LLVM type size doesn't match GCC type size!"' ooo.cpp: In constructor 'C4::C4()': ooo.cpp:20: internal compiler error: Abort trap -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Oct 27 22:58:37 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 27 Oct 2007 22:58:37 -0500 Subject: [LLVMbugs] [Bug 1660] compilation of llvm-gcc-4-2 dies In-Reply-To: Message-ID: <200710280358.l9S3wbvG013335@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1660 Gabor Greif changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #12 from Gabor Greif 2007-10-27 22:58:36 --- As of today llvm-gcc4.2 compiles. Thanks for taking care of PPC32! Resolving bug. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Oct 28 03:51:09 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 28 Oct 2007 03:51:09 -0500 Subject: [LLVMbugs] [Bug 1742] invalid code generation on x86 with SSE enabled In-Reply-To: Message-ID: <200710280851.l9S8p9VS003710@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1742 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Duncan Sands 2007-10-28 03:51:08 --- I'm closing this as invalid: the result of calling a fastcall function without specifying the fastcall convention on the call itself is undefined. However, if this .ll file was generated by llvm-gcc, then it indicates a bug in llvm-gcc, in which case we need a new bugreport against llvm-gcc with the original 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 Sun Oct 28 10:54:38 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 28 Oct 2007 10:54:38 -0500 Subject: [LLVMbugs] [Bug 1747] New: verification does not detect calling functions with incorrect calling convention Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1747 Summary: verification does not detect calling functions with incorrect calling convention Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Keywords: accepts-invalid Severity: enhancement Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: tomas.l.olsen at gmail.com CC: llvmbugs at cs.uiuc.edu define fastcc void @f( ) { ret void } define i32 @main(i32, i8**, i8**) { call void @f( ) ; invalid - missing fastcc ret i32 0 } The above snippet passes verification, seems like something that should not be too problematic to detect statically. I recently filed an invalid report 1742 due to 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 Oct 28 14:50:11 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 28 Oct 2007 14:50:11 -0500 Subject: [LLVMbugs] [Bug 1748] New: Unable to compile init/main.c from latest Linux kernel Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1748 Summary: Unable to compile init/main.c from latest Linux kernel Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Keywords: compile-fail Severity: normal Priority: P2 Component: llc AssignedTo: unassignedbugs at nondot.org ReportedBy: edwintorok at gmail.com CC: llvmbugs at cs.uiuc.edu I get a compile error when trying to use llvm-gcc to compile Linux 2.6.24-rc1. llvm-gcc succesfully produces a bitcode, but it can't compile to native. When I tell llvm-gcc to compile to bitcode only, and use llc, llc gives me same error, hence I reported the bug against llc. $ uname -a Linux lightspeed2 2.6.23-rc8-hrt1-cfs-v22-g1bef7dc0-dirty #17 Sun Sep 30 18:49:34 EEST 2007 x86_64 GNU/Linux $ CROSS_COMPILE=llvm- O=/home/edwin/builds/o make ... CC init/main.o Invalid operand found in inline asm: '# __raw_save_flags pushfq ; popq ${0:q}' INLINEASM , 36, %RSP, 1, %NOREG, 8 INLINEASM 36 %mreg(83) 1 %mreg(0) 8 {standard input}: Assembler messages: {standard input}:149: Error: junk at end of line, first unrecognized character is `(' {standard input}:438: Error: invalid character '"' in operand 1 make[1]: *** [init/main.o] Error 1 make: *** [init] Error 2 Using "CROSS_COMPILE=llvm- O=/home/edwin/builds/o KBUILD_VERBOSE=1 make", I see this command-line: llvm-gcc -Wp,-MD,init/.main.o.d -nostdinc -isystem /home/edwin/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.1/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O2 -march=k8 -m64 -mno-red-zone -mcmodel=kernel -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -fomit-frame-pointer -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -O5 -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(main)" -D"KBUILD_MODNAME=KBUILD_STR(main)" -c -o init/.tmp_main.o init/main.c I added -emit-llvm, and when running llc on the generated bitcode I get: $ opt -verify init/.tmp_main.o >/dev/null $ llc -f init/.tmp_main.o Invalid operand found in inline asm: '# __raw_save_flags pushfq ; popq ${0:q}' INLINEASM , 36, %RSP, 1, %NOREG, 8 INLINEASM 36 %mreg(83) 1 %mreg(0) 8 Attaching the generated bitcode... -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Oct 28 14:57:06 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 28 Oct 2007 14:57:06 -0500 Subject: [LLVMbugs] [Bug 1749] New: llvm-gcc internal error compiling ia32_signal.c Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1749 Summary: llvm-gcc internal error compiling ia32_signal.c Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: edwintorok at gmail.com CC: llvmbugs at cs.uiuc.edu Compiling ia32_signal.c with llvm gives an internal compiler error, $ uname -a Linux lightspeed2 2.6.23-rc8-hrt1-cfs-v22-g1bef7dc0-dirty #17 Sun Sep 30 18:49:34 EEST 2007 x86_64 GNU/Linux $ llvm-gcc -emit-llvm -Wp,-MD,arch/x86/ia32/.ia32_signal.o.d -nostdinc -isystem /home/edwin/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.1/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O2 -march=k8 -m64 -mno-red-zone -mcmodel=kernel -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -fomit-frame-pointer -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -O5 -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(ia32_signal)" -D"KBUILD_MODNAME=KBUILD_STR(ia32_signal)" -c -o arch/x86/ia32/.tmp_ia32_signal.o arch/x86/ia32/ia32_signal.c cc1: TargetData.cpp:88: unsigned int llvm::StructLayout::getElementContainingOffset(uint64_t) const: Assertion `(SI == &MemberOffsets[0] || *(SI-1) < Offset) && (SI+1 == &MemberOffsets[NumElements] || *(SI+1) > Offset) && "Upper bound didn't work!"' failed. arch/x86/ia32/ia32_signal.c: In function ???copy_siginfo_to_user32???: arch/x86/ia32/ia32_signal.c:44: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Attaching preprocessed source... -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Oct 28 15:10:56 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 28 Oct 2007 15:10:56 -0500 Subject: [LLVMbugs] [Bug 1750] New: Compiling ia32_signal.i Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1750 Summary: Compiling ia32_signal.i Product: cfe Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedbugs at nondot.org ReportedBy: edwintorok at gmail.com CC: llvmbugs at cs.uiuc.edu When compiling http://llvm.org/bugs/attachment.cgi?id=1169: clang -fsyntax-only ia32_signal.i clang: /home/edwin/llvm-svn/llvm/include/llvm/Support/Casting.h:199: typename llvm::cast_retty::ret_type llvm::cast(const Y&) [with X = clang::TypedefType, Y = const clang::Type*]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. clang[0x788b46] clang[0x788db2] /lib/libc.so.6[0x32d1c31710] /lib/libc.so.6(gsignal+0x35)[0x32d1c316a5] /lib/libc.so.6(abort+0x110)[0x32d1c33100] /lib/libc.so.6(__assert_fail+0xef)[0x32d1c2ac2f] clang(llvm::cast_retty::ret_type llvm::cast(clang::Type const* const&)+0x44)[0x6718b4] clang(clang::Type::getAsPointerType() const+0x4c)[0x66f738] clang(clang::Sema::CheckPointerTypesForAssignment(clang::QualType, clang::QualType)+0x55)[0x632fbb] clang(clang::Sema::CheckAssignmentConstraints(clang::QualType, clang::QualType)+0x1b7)[0x6332db] clang(clang::Sema::CheckSingleAssignmentConstraints(clang::QualType, clang::Expr*&)+0x55)[0x6336b9] clang(clang::Sema::CheckSingleInitializer(clang::Expr*&, bool, clang::QualType)+0x136)[0x62661a] clang(clang::Sema::CheckInitializer(clang::Expr*&, clang::QualType&, bool)+0x49)[0x626df7] clang(clang::Sema::AddInitializerToDecl(void*, void*)+0x123)[0x627151] clang(clang::Parser::ParseInitDeclaratorListAfterFirstDeclarator(clang::Declarator&)+0x147)[0x678e57] clang(clang::Parser::ParseSimpleDeclaration(unsigned int)+0xcc)[0x67901c] clang(clang::Parser::ParseDeclaration(unsigned int)+0x41)[0x679083] clang(clang::Parser::ParseStatementOrDeclaration(bool)+0x307)[0x685f49] clang(clang::Parser::ParseCompoundStatementBody(bool)+0x7c)[0x688ae0] clang(clang::Parser::ParseFunctionDefinition(clang::Declarator&)+0x156)[0x6743c2] clang(clang::Parser::ParseDeclarationOrFunctionDefinition()+0x2ca)[0x674748] clang(clang::Parser::ParseExternalDeclaration()+0x213)[0x674c59] clang(clang::Parser::ParseTopLevelDecl(void*&)+0x43)[0x674ca7] clang[0x61d081] clang(clang::ParseAST(clang::Preprocessor&, unsigned int, clang::ASTConsumer&, bool)+0xeb)[0x61d221] clang[0x5e247c] clang(main+0x335)[0x5e3e57] /lib/libc.so.6(__libc_start_main+0xf4)[0x32d1c1db44] clang[0x5c9f99] Aborted $ clang --version Low Level Virtual Machine (http://llvm.org/): llvm version 2.2svn DEBUG build with assertions. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Oct 28 15:14:03 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 28 Oct 2007 15:14:03 -0500 Subject: [LLVMbugs] [Bug 1751] New: Compiling init/main. c from Linux kernel aborts with assertion in Casting.h Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1751 Summary: Compiling init/main.c from Linux kernel aborts with assertion in Casting.h Product: cfe Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedbugs at nondot.org ReportedBy: edwintorok at gmail.com CC: llvmbugs at cs.uiuc.edu $ llvm-gcc -E -Wp,-MD,init/.main.o.d -nostdinc -isystem /home/edwin/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.1/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O2 -march=k8 -m64 -mno-red-zone -mcmodel=kernel -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -fomit-frame-pointer -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(main)" -D"KBUILD_MODNAME=KBUILD_STR(main)" init/main.c >main.i $ clang main.i clang: /home/edwin/llvm-svn/llvm/include/llvm/Support/Casting.h:199: typename llvm::cast_retty::ret_type llvm::cast(const Y&) [with X = clang::TypedefType, Y = const clang::Type*]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. clang[0x788b46] clang[0x788db2] /lib/libc.so.6[0x32d1c31710] /lib/libc.so.6(gsignal+0x35)[0x32d1c316a5] /lib/libc.so.6(abort+0x110)[0x32d1c33100] /lib/libc.so.6(__assert_fail+0xef)[0x32d1c2ac2f] clang(llvm::cast_retty::ret_type llvm::cast(clang::Type const* const&)+0x44)[0x6718b4] clang(clang::Type::getAsPointerType() const+0x4c)[0x66f738] clang(clang::Sema::CheckPointerTypesForAssignment(clang::QualType, clang::QualType)+0x55)[0x632fbb] clang(clang::Sema::CheckAssignmentConstraints(clang::QualType, clang::QualType)+0x1b7)[0x6332db] clang(clang::Sema::CheckSingleAssignmentConstraints(clang::QualType, clang::Expr*&)+0x55)[0x6336b9] clang(clang::Sema::CheckSingleInitializer(clang::Expr*&, bool, clang::QualType)+0x136)[0x62661a] clang(clang::Sema::CheckInitializer(clang::Expr*&, clang::QualType&, bool)+0x49)[0x626df7] clang(clang::Sema::AddInitializerToDecl(void*, void*)+0x123)[0x627151] clang(clang::Parser::ParseInitDeclaratorListAfterFirstDeclarator(clang::Declarator&)+0x147)[0x678e57] clang(clang::Parser::ParseSimpleDeclaration(unsigned int)+0xcc)[0x67901c] clang(clang::Parser::ParseDeclaration(unsigned int)+0x41)[0x679083] clang(clang::Parser::ParseStatementOrDeclaration(bool)+0x307)[0x685f49] clang(clang::Parser::ParseCompoundStatementBody(bool)+0x7c)[0x688ae0] clang(clang::Parser::ParseFunctionDefinition(clang::Declarator&)+0x156)[0x6743c2] clang(clang::Parser::ParseDeclarationOrFunctionDefinition()+0x2ca)[0x674748] clang(clang::Parser::ParseExternalDeclaration()+0x213)[0x674c59] clang(clang::Parser::ParseTopLevelDecl(void*&)+0x43)[0x674ca7] clang[0x61d081] clang(clang::ParseAST(clang::Preprocessor&, unsigned int, clang::ASTConsumer&, bool)+0xeb)[0x61d221] clang[0x5e247c] clang(main+0x335)[0x5e3e57] /lib/libc.so.6(__libc_start_main+0xf4)[0x32d1c1db44] clang[0x5c9f99] Aborted -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Oct 28 18:25:30 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 28 Oct 2007 18:25:30 -0500 Subject: [LLVMbugs] [Bug 1752] New: LoopSimplifier dies on crazy code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1752 Summary: LoopSimplifier dies on crazy code Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Loop Optimizer AssignedTo: unassignedbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1174) --> (http://llvm.org/bugs/attachment.cgi?id=1174) Bytecode in question Consider attached bytecode. Running either 'opt -loopsimplify' or just 'llc' results: opt: /home/asl/proj/llvm/src/lib/VMCore/Value.cpp:57: virtual llvm::Value::~Value(): Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed. ./opt((anonymous namespace)::PrintStackTrace()+0x22)[0x86c1910] ./opt((anonymous namespace)::SignalHandler(int)+0x102)[0x86c1bb8] [0xffffe420] /lib/libc.so.6(abort+0xec)[0xb7c8ef9c] /lib/libc.so.6(__assert_fail+0xde)[0xb7c86b5e] ./opt(llvm::Value::~Value()+0x156)[0x86741da] ./opt(llvm::User::~User()+0x1a)[0x85fc700] ./opt(llvm::Instruction::~Instruction()+0x47)[0x8634fe5] ./opt(llvm::TerminatorInst::~TerminatorInst()+0x1a)[0x863600e] ./opt(llvm::InvokeInst::~InvokeInst()+0x80)[0x8637b50] ./opt(llvm::iplist >::erase(llvm::ilist_iterator)+0x33)[0x83ede4b] ./opt(llvm::iplist >::pop_back()+0x74)[0x842db36] ./opt((anonymous namespace)::LoopSimplify::runOnFunction(llvm::Function&)+0x221)[0x85343b5] ./opt(llvm::FPPassManager::runOnFunction(llvm::Function&)+0x13d)[0x8656567] ./opt(llvm::FPPassManager::runOnModule(llvm::Module&)+0x76)[0x86566fe] ./opt(llvm::MPPassManager::runOnModule(llvm::Module&)+0x123)[0x8656859] ./opt(llvm::PassManagerImpl::run(llvm::Module&)+0x86)[0x8656c12] ./opt(llvm::PassManager::run(llvm::Module&)+0x1a)[0x8656d7e] ./opt(main+0xbd3)[0x83e1e8b] /lib/libc.so.6(__libc_start_main+0xe6)[0xb7c799d6] ./opt(realloc+0x75)[0x83d4ba1] -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Oct 28 21:31:30 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 28 Oct 2007 21:31:30 -0500 Subject: [LLVMbugs] [Bug 1752] LoopSimplifier dies on crazy code In-Reply-To: Message-ID: <200710290231.l9T2VUs8004606@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1752 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal Status|NEW |RESOLVED Resolution| |FIXED Target Milestone|--- |2.2 --- Comment #1 from Chris Lattner 2007-10-28 21:31:29 --- Fixed, patch here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071022/054959.html -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 Sun Oct 28 21:41:07 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 28 Oct 2007 21:41:07 -0500 Subject: [LLVMbugs] [Bug 1749] llvm-gcc internal error compiling ia32_signal.c In-Reply-To: Message-ID: <200710290241.l9T2f7ad005170@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1749 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Component|new bugs |Target Description Classes Keywords| |compile-fail Product|new-bugs |libraries Resolution| |FIXED Target Milestone|--- |2.2 Version|unspecified |1.0 --- Comment #5 from Chris Lattner 2007-10-28 21:41:06 --- Thanks for the bug report, and thanks for reducing it Anton! Fixed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071022/054960.html -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 Sun Oct 28 22:10:04 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 28 Oct 2007 22:10:04 -0500 Subject: [LLVMbugs] [Bug 1748] Unable to compile init/main.c from latest Linux kernel In-Reply-To: Message-ID: <200710290310.l9T3A4cO006548@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1748 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Component|llc |Backend: X86 Product|tools |libraries Resolution| |FIXED Target Milestone|--- |2.2 --- Comment #8 from Chris Lattner 2007-10-28 22:10:03 --- Fixed, patch here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071022/054961.html Thanks! -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 Mon Oct 29 00:12:29 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 29 Oct 2007 00:12:29 -0500 Subject: [LLVMbugs] [Bug 1751] Compiling init/main. c from Linux kernel aborts with assertion in Casting.h In-Reply-To: Message-ID: <200710290512.l9T5CTA8011517@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1751 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #2 from Chris Lattner 2007-10-29 00:12:29 --- This died in the same was as bug 1750, closing as a dup *** This bug has been marked as a duplicate of bug 1750 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Oct 29 00:48:54 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 29 Oct 2007 00:48:54 -0500 Subject: [LLVMbugs] [Bug 1745] Variable-sized allocation in loop blows out stack In-Reply-To: Message-ID: <200710290548.l9T5msfv013243@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1745 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal Status|NEW |RESOLVED Component|new bugs |Scalar Optimizations Keywords| |miscompilation Product|new-bugs |libraries Resolution| |FIXED Target Milestone|--- |2.2 Version|unspecified |trunk --- Comment #5 from Chris Lattner 2007-10-29 00:48:53 --- Fixed, patch here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071029/054965.html -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 Mon Oct 29 11:46:46 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 29 Oct 2007 11:46:46 -0500 Subject: [LLVMbugs] [Bug 1753] New: Alias analysis/other optimizations don' t work in the presence of ptrtoint/inttoptr Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1753 Summary: Alias analysis/other optimizations don't work in the presence of ptrtoint/inttoptr Product: new-bugs Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu Two llvm functions: define i32 @myfunc(i32 %a) { EntryBlock: %mem = alloca [16384 x i32] %memptr = getelementptr [16384 x i32] * %mem, i32 0, i32 0 %memint = ptrtoint i32 * %memptr to i32 %memint2 = add i32 %memint, 4 %memptr2 = inttoptr i32 %memint2 to i32* store i32 20, i32* %memptr2 store i32 10, i32* %memptr %retint = load i32* %memptr2 ret i32 %retint } define i32 @myfunc2(i32) { EntryBlock: %mem = alloca [16384 x i32] %memptr = getelementptr [16384 x i32] * %mem, i32 0, i32 0 %memptr2 = getelementptr [16384 x i32] * %mem, i32 0, i32 1 store i32 20, i32* %memptr2 store i32 10, i32* %memptr %retint = load i32* %memptr2 ret i32 %retint } Note that in both of these functions, %memptr2 ends up with the same value. Results after running code through "opt -std-compile-opts" then "llc" _myfunc: movl $65536, %eax call __alloca movl $20, 4(%esp) movl $10, (%esp) movl 4(%esp), %eax addl $65536, %esp ret _myfunc2: movl $20, %eax ret If I don't run the code through opt, both functions end up exactly the same. I'd appreciate any tips on how to fix this; I'm generating code like myfunc. I can probably work around it in my generating code (essentially by avoiding the conversion in easy casea), but it would make things more complicated, so it would be nice if llvm could handle it. (My best guess to the issue is that target-independent optimizations assume that a pointer from inttoptr can alias anything, and by the time the machine-specific information is available, the passes that deal with these sorts of optimizations have already run.) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Oct 29 12:36:48 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 29 Oct 2007 12:36:48 -0500 Subject: [LLVMbugs] [Bug 1754] New: Bunch of small memory leaks in LLVM Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1754 Summary: Bunch of small memory leaks in LLVM Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1175) --> (http://llvm.org/bugs/attachment.cgi?id=1175) Test bytecode Consider attached bytecode (this is just sim from testsuite). Running llc sim.bc under valgrind results: ==1613== Memcheck, a memory error detector. ==1613== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==1613== Using LibVEX rev 1732, a library for dynamic binary translation. ==1613== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==1613== Using valgrind-3.2.3, a dynamic binary instrumentation framework. ==1613== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==1613== For more details, rerun with: -v ==1613== ==1613== ==1613== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 9 from 1) ==1613== malloc/free: in use at exit: 34,574 bytes in 551 blocks. ==1613== malloc/free: 285,401 allocs, 284,850 frees, 44,914,462 bytes allocated. ==1613== For counts of detected errors, rerun with: -v ==1613== searching for pointers to 551 not-freed blocks. ==1613== checked 194,680 bytes. ==1613== ==1613== 8 bytes in 1 blocks are definitely lost in loss record 2 of 43 ==1613== at 0x4021D54: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==1613== by 0x84779E1: main (llc.cpp:249) ==1613== ==1613== ==1613== 18 bytes in 1 blocks are possibly lost in loss record 4 of 43 ==1613== at 0x4021D54: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==1613== by 0x410901B: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator const&) (in /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3) ==1613== by 0x41090AD: std::string::_Rep::_M_clone(std::allocator const&, unsigned) (in /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3) ==1613== by 0x4109664: std::string::reserve(unsigned) (in /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3) ==1613== by 0x4109E22: std::string::append(char const*, unsigned) (in /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3) ==1613== by 0x4109EE4: std::string::operator+=(char const*) (in /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3) ==1613== by 0x8476F4E: GetOutputStream(char const*) (llc.cpp:138) ==1613== by 0x847773A: main (llc.cpp:226) ==1613== ==1613== ==1613== 28 bytes in 1 blocks are definitely lost in loss record 6 of 43 ==1613== at 0x4021D54: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==1613== by 0x88F7636: llvm::ConstantCreator::create(llvm::Type const*, char const&) (Constants.cpp:1007) ==1613== by 0x88F32D9: llvm::ValueMap::getOrCreate(llvm::Type const*, char const&) (Constants.cpp:859) ==1613== by 0x88EE9D8: llvm::ConstantAggregateZero::get(llvm::Type const*) (Constants.cpp:1031) ==1613== by 0x88EBBEE: llvm::Constant::getNullValue(llvm::Type const*) (Constants.cpp:125) ==1613== by 0x86C9B42: llvm::BitcodeReader::ParseConstants() (BitcodeReader.cpp:605) ==1613== by 0x86CBCD6: llvm::BitcodeReader::ParseModule(std::string const&) (BitcodeReader.cpp:910) ==1613== by 0x86CD0E3: llvm::BitcodeReader::ParseBitcode() (BitcodeReader.cpp:1122) ==1613== by 0x86D0899: llvm::getBitcodeModuleProvider(llvm::MemoryBuffer*, std::string*) (BitcodeReader.cpp:1688) ==1613== by 0x86D0911: llvm::ParseBitcodeFile(llvm::MemoryBuffer*, std::string*) (BitcodeReader.cpp:1704) ==1613== by 0x84773A7: main (llc.cpp:186) ==1613== ==1613== ==1613== 52 bytes in 1 blocks are definitely lost in loss record 24 of 43 ==1613== at 0x4022274: operator new[](unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==1613== by 0x8949855: llvm::StructType::get(std::vector > const&, bool) (Type.cpp:1271) ==1613== by 0x87F4540: getGlobalVariablesUsing(llvm::Module&, std::string const&) (MachineModuleInfo.cpp:65) ==1613== by 0x87F8B6B: llvm::MachineModuleInfo::getGlobalVariablesUsing(llvm::Module&, std::string const&) (MachineModuleInfo.cpp:1578) ==1613== by 0x87FAF54: std::vector > llvm::MachineModuleInfo::getAnchoredDescriptors(llvm::Module&) (MachineModuleInfo.h:1163) ==1613== by 0x87F8ACC: llvm::MachineModuleInfo::SetupCompileUnits(llvm::Module&) (MachineModuleInfo.cpp:1560) ==1613== by 0x87F8A77: llvm::MachineModuleInfo::AnalyzeModule(llvm::Module&) (MachineModuleInfo.cpp:1548) ==1613== by 0x879B110: llvm::AsmPrinter::doInitialization(llvm::Module&) (AsmPrinter.cpp:107) ==1613== by 0x85BD584: llvm::X86SharedAsmPrinter::doInitialization(llvm::Module&) (X86AsmPrinter.cpp:123) ==1613== by 0x893E652: llvm::FPPassManager::doInitialization(llvm::Module&) (PassManager.cpp:1201) ==1613== by 0x893E49C: llvm::FunctionPassManagerImpl::doInitialization(llvm::Module&) (PassManager.cpp:1098) ==1613== by 0x893C960: llvm::FunctionPassManager::doInitialization() (PassManager.cpp:1081) ==1613== ==1613== ==1613== 56 bytes in 2 blocks are definitely lost in loss record 25 of 43 ==1613== at 0x4021D54: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==1613== by 0x88F8D70: llvm::ConstantCreator::create(llvm::Type const*, char const&) (Constants.cpp:1352) ==1613== by 0x88F50CF: llvm::ValueMap::getOrCreate(llvm::Type const*, char const&) (Constants.cpp:859) ==1613== by 0x88EF53D: llvm::UndefValue::get(llvm::Type const*) (Constants.cpp:1376) ==1613== by 0x86C9A0C: llvm::BitcodeReader::ParseConstants() (BitcodeReader.cpp:595) ==1613== by 0x86CD333: llvm::BitcodeReader::ParseFunctionBody(llvm::Function*) (BitcodeReader.cpp:1168) ==1613== by 0x86D03C1: llvm::BitcodeReader::materializeFunction(llvm::Function*, std::string*) (BitcodeReader.cpp:1602) ==1613== by 0x86D064C: llvm::BitcodeReader::materializeModule(std::string*) (BitcodeReader.cpp:1640) ==1613== by 0x86D093C: llvm::ParseBitcodeFile(llvm::MemoryBuffer*, std::string*) (BitcodeReader.cpp:1708) ==1613== by 0x84773A7: main (llc.cpp:186) ==1613== ==1613== ==1613== 424 (224 direct, 200 indirect) bytes in 8 blocks are definitely lost in loss record 30 of 43 ==1613== at 0x4021D54: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==1613== by 0x88F8A6E: llvm::ConstantCreator::create(llvm::PointerType const*, char const&) (Constants.cpp:1308) ==1613== by 0x88F4BC8: llvm::ValueMap::getOrCreate(llvm::PointerType const*, char const&) (Constants.cpp:859) ==1613== by 0x88EF4D5: llvm::ConstantPointerNull::get(llvm::PointerType const*) (Constants.cpp:1333) ==1613== by 0x88EBBDE: llvm::Constant::getNullValue(llvm::Type const*) (Constants.cpp:121) ==1613== by 0x86C9B42: llvm::BitcodeReader::ParseConstants() (BitcodeReader.cpp:605) ==1613== by 0x86CBCD6: llvm::BitcodeReader::ParseModule(std::string const&) (BitcodeReader.cpp:910) ==1613== by 0x86CD0E3: llvm::BitcodeReader::ParseBitcode() (BitcodeReader.cpp:1122) ==1613== by 0x86D0899: llvm::getBitcodeModuleProvider(llvm::MemoryBuffer*, std::string*) (BitcodeReader.cpp:1688) ==1613== by 0x86D0911: llvm::ParseBitcodeFile(llvm::MemoryBuffer*, std::string*) (BitcodeReader.cpp:1704) ==1613== by 0x84773A7: main (llc.cpp:186) ==1613== ==1613== ==1613== 352 bytes in 11 blocks are definitely lost in loss record 31 of 43 ==1613== at 0x4022274: operator new[](unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==1613== by 0x8517154: llvm::SmallVectorImpl::grow(unsigned) (SmallVector.h:330) ==1613== by 0x8826ADD: llvm::SmallVectorImpl::insert(unsigned*, unsigned const&) (SmallVector.h:242) ==1613== by 0x8826144: llvm::LiveInterval::addKills(llvm::VNInfo*, llvm::SmallVector const&) (LiveInterval.h:202) ==1613== by 0x8822D1F: llvm::SimpleRegisterCoalescing::SimpleJoin(llvm::LiveInterval&, llvm::LiveInterval&) (SimpleRegisterCoalescing.cpp:669) ==1613== by 0x88231AD: llvm::SimpleRegisterCoalescing::JoinIntervals(llvm::LiveInterval&, llvm::LiveInterval&, bool&) (SimpleRegisterCoalescing.cpp:731) ==1613== by 0x88220A8: llvm::SimpleRegisterCoalescing::JoinCopy(llvm::MachineInstr*, unsigned, unsigned) (SimpleRegisterCoalescing.cpp:371) ==1613== by 0x8824276: llvm::SimpleRegisterCoalescing::CopyCoalesceInMBB(llvm::MachineBasicBlock*, std::vector >&) (SimpleRegisterCoalescing.cpp:979) ==1613== by 0x8824565: llvm::SimpleRegisterCoalescing::joinIntervals() (SimpleRegisterCoalescing.cpp:1013) ==1613== by 0x8825200: llvm::SimpleRegisterCoalescing::runOnMachineFunction(llvm::MachineFunction&) (SimpleRegisterCoalescing.cpp:1226) ==1613== by 0x848951E: llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (MachineFunctionPass.h:41) ==1613== by 0x893CC56: llvm::FPPassManager::runOnFunction(llvm::Function&) (PassManager.cpp:1171) ==1613== ==1613== ==1613== 748 bytes in 17 blocks are definitely lost in loss record 33 of 43 ==1613== at 0x4021D54: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==1613== by 0x88EC72A: llvm::ConstantFP::get(llvm::Type const*, llvm::APFloat const&) (Constants.cpp:334) ==1613== by 0x896A033: llvm::ConstantFoldCastInstruction(unsigned, llvm::Constant const*, llvm::Type const*) (ConstantFold.cpp:191) ==1613== by 0x88EFDA2: getFoldedCast(llvm::Instruction::CastOps, llvm::Constant*, llvm::Type const*) (Constants.cpp:1518) ==1613== by 0x88F00CC: llvm::ConstantExpr::getFPTrunc(llvm::Constant*, llvm::Type const*) (Constants.cpp:1635) ==1613== by 0x87661D7: ExpandConstantFP(llvm::ConstantFPSDNode*, bool, llvm::SelectionDAG&, llvm::TargetLowering&) (LegalizeDAG.cpp:507) ==1613== by 0x8769EEA: (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDOperand) (LegalizeDAG.cpp:1118) ==1613== by 0x8765F56: (anonymous namespace)::SelectionDAGLegalize::HandleOp(llvm::SDOperand) (LegalizeDAG.cpp:458) ==1613== by 0x87655E3: (anonymous namespace)::SelectionDAGLegalize::LegalizeDAG() (LegalizeDAG.cpp:337) ==1613== by 0x8790746: llvm::SelectionDAG::Legalize() (LegalizeDAG.cpp:6502) ==1613== by 0x873DDB1: llvm::SelectionDAGISel::CodeGenAndEmitDAG(llvm::SelectionDAG&) (SelectionDAGISel.cpp:4744) ==1613== by 0x873DF73: llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*, llvm::MachineFunction&, llvm::FunctionLoweringInfo&) (SelectionDAGISel.cpp:4777) ==1613== ==1613== ==1613== 6,672 (2,528 direct, 4,144 indirect) bytes in 79 blocks are definitely lost in loss record 38 of 43 ==1613== at 0x4021D54: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==1613== by 0x849C164: llvm::MachineInstr::clone() const (MachineInstr.h:395) ==1613== by 0x884679B: llvm::LiveIntervals::addIntervalsForSpills(llvm::LiveInterval const&, llvm::VirtRegMap&, unsigned) (LiveIntervalAnalysis.cpp:263) ==1613== by 0x8811926: (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval(llvm::LiveInterval*) (RegAllocLinearScan.cpp:608) ==1613== by 0x880FFCA: (anonymous namespace)::RALinScan::linearScan() (RegAllocLinearScan.cpp:267) ==1613== by 0x880FB79: (anonymous namespace)::RALinScan::runOnMachineFunction(llvm::MachineFunction&) (RegAllocLinearScan.cpp:211) ==1613== by 0x848951E: llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (MachineFunctionPass.h:41) ==1613== by 0x893CC56: llvm::FPPassManager::runOnFunction(llvm::Function&) (PassManager.cpp:1171) ==1613== by 0x893CA15: llvm::FunctionPassManagerImpl::run(llvm::Function&) (PassManager.cpp:1129) ==1613== by 0x893C925: llvm::FunctionPassManager::run(llvm::Function&) (PassManager.cpp:1074) ==1613== by 0x8477E76: main (llc.cpp:296) ==1613== ==1613== ==1613== 5,840 (2,200 direct, 3,640 indirect) bytes in 50 blocks are definitely lost in loss record 39 of 43 ==1613== at 0x4021D54: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==1613== by 0x89499A8: llvm::PointerType::get(llvm::Type const*) (Type.cpp:1323) ==1613== by 0x86C87E0: llvm::BitcodeReader::ParseTypeTable() (BitcodeReader.cpp:331) ==1613== by 0x86CBC1C: llvm::BitcodeReader::ParseModule(std::string const&) (BitcodeReader.cpp:898) ==1613== by 0x86CD0E3: llvm::BitcodeReader::ParseBitcode() (BitcodeReader.cpp:1122) ==1613== by 0x86D0899: llvm::getBitcodeModuleProvider(llvm::MemoryBuffer*, std::string*) (BitcodeReader.cpp:1688) ==1613== by 0x86D0911: llvm::ParseBitcodeFile(llvm::MemoryBuffer*, std::string*) (BitcodeReader.cpp:1704) ==1613== by 0x84773A7: main (llc.cpp:186) ==1613== ==1613== ==1613== 18,752 (1,520 direct, 17,232 indirect) bytes in 38 blocks are definitely lost in loss record 40 of 43 ==1613== at 0x4021D54: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==1613== by 0x88EC0BC: llvm::ConstantInt::get(llvm::APInt const&) (Constants.cpp:242) ==1613== by 0x88EC023: llvm::ConstantInt::get(llvm::Type const*, unsigned long long, bool) (Constants.cpp:224) ==1613== by 0x88516DC: (anonymous namespace)::CodeGenPrepare::OptimizeLoadStoreInst(llvm::Instruction*, llvm::Value*, llvm::Type const*, llvm::DenseMap, llvm::DenseMapInfo >&) (CodeGenPrepare.cpp:896) ==1613== by 0x8851BBD: (anonymous namespace)::CodeGenPrepare::OptimizeBlock(llvm::BasicBlock&) (CodeGenPrepare.cpp:961) ==1613== by 0x884E3DB: (anonymous namespace)::CodeGenPrepare::runOnFunction(llvm::Function&) (CodeGenPrepare.cpp:78) ==1613== by 0x893CC56: llvm::FPPassManager::runOnFunction(llvm::Function&) (PassManager.cpp:1171) ==1613== by 0x893CA15: llvm::FunctionPassManagerImpl::run(llvm::Function&) (PassManager.cpp:1129) ==1613== by 0x893C925: llvm::FunctionPassManager::run(llvm::Function&) (PassManager.cpp:1074) ==1613== by 0x8477E76: main (llc.cpp:296) ==1613== ==1613== LEAK SUMMARY: ==1613== definitely lost: 7,716 bytes in 208 blocks. ==1613== indirectly lost: 25,216 bytes in 284 blocks. ==1613== possibly lost: 18 bytes in 1 blocks. ==1613== still reachable: 1,624 bytes in 58 blocks. ==1613== suppressed: 0 bytes in 0 blocks. ==1613== Reachable blocks (those to which a pointer was found) are not shown. ==1613== To see them, rerun with: --leak-check=full --show-reachable=yes -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Oct 29 16:30:12 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 29 Oct 2007 16:30:12 -0500 Subject: [LLVMbugs] [Bug 1755] New: loop trip counts don't fully consider modulo arithmetic Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1755 Summary: loop trip counts don't fully consider modulo arithmetic Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: Loop Optimizer AssignedTo: unassignedbugs at nondot.org ReportedBy: djg at cray.com CC: llvmbugs at cs.uiuc.edu For this testcase: void consume(unsigned); void foo(unsigned a, unsigned b) { unsigned i; for (i = a; i != b; ++i) { consume(i); } } llvm-gcc emits LLVM IR which doesn't record that the integer types are unsigned and that modulo arithmetic is required. Both Loop::getTripCount and ScalarEvolution::getIterationCount say that the tripcount is b-a (with adjustments for quirkiness in the latter). This is correct when a <= b but is not correct when a > b. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Oct 29 18:01:15 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 29 Oct 2007 18:01:15 -0500 Subject: [LLVMbugs] [Bug 1755] loop trip counts don't fully consider modulo arithmetic In-Reply-To: Message-ID: <200710292301.l9TN1FkN009347@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1755 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Oct 29 22:05:15 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 29 Oct 2007 22:05:15 -0500 Subject: [LLVMbugs] [Bug 1756] New: Casting 'constant float' to 'constant [4 x i8]' causes assertion failure. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1756 Summary: Casting 'constant float' to 'constant [4 x i8]' causes assertion failure. Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: tomas.l.olsen at gmail.com CC: llvmbugs at cs.uiuc.edu Casting 'constant float' to 'constant [4 x i8]' causes assertion failure: Assertion `SrcBitSize == DstBitSize && "BitCast requies types of same width"' failed. Test case: Constant* c = ConstantFP::get(Type::FloatTy, float(1.0)); c = ConstantExpr::getBitCast(c, ArrayType::get(Type::Int8Ty, gTargetData->getTypeSize(c->getType()))); gTargetData is a global created with code like: gTargetData = new llvm::TargetData(M); where module M has: target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:8" target triple = "x86_64-unknown-linux-gnu" set from code. Hope that is enough. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 30 00:13:34 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 30 Oct 2007 00:13:34 -0500 Subject: [LLVMbugs] [Bug 1756] Casting 'constant float' to 'constant [4 x i8]' causes assertion failure. In-Reply-To: Message-ID: <200710300513.l9U5DYuR000838@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1756 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2007-10-30 00:13:33 --- The assertion is right, that is invalid. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 30 00:31:41 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 30 Oct 2007 00:31:41 -0500 Subject: [LLVMbugs] [Bug 1757] New: Missed optimization: any number greater than two is not equal to two Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1757 Summary: Missed optimization: any number greater than two is not equal to two Product: new-bugs Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu declare i32 @asdf(); declare i32 @asdf2(); declare i32 @asdf3(); define i32 @myfunc(i32) { EntryBlock: %.demorgan = icmp sgt i32 %0, 2 br i1 %.demorgan, label %GreaterThanTwo, label %LessThanOrEqualToTwo GreaterThanTwo: icmp eq i32 %0, 2 br i1 %1, label %Impossible, label %NotTwoAndGreaterThanTwo NotTwoAndGreaterThanTwo: call i32 @asdf() ret i32 2 Impossible: call i32 @asdf2() ret i32 1 LessThanOrEqualToTwo: call i32 @asdf3() ret i32 0 } "opt -std-compile-opts" leaves this untransformed; the obvious optimization is to replace the second icmp with a constant zero and simplify the code appropriately. It seems like the assembly-level optimization passes should be able to catch this, although I'm not sure how LLVM deals with this kind of optimization. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 30 02:26:30 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 30 Oct 2007 02:26:30 -0500 Subject: [LLVMbugs] [Bug 1757] Missed optimization: any number greater than two is not equal to two In-Reply-To: Message-ID: <200710300726.l9U7QUph010476@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1757 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nicholas at mxc.ca Status|NEW |RESOLVED Resolution| |LATER --- Comment #2 from Anton Korobeynikov 2007-10-30 02:26:30 --- Running opt -predsimplify results: ; ModuleID = '' declare i32 @asdf() declare i32 @asdf2() declare i32 @asdf3() define i32 @myfunc(i32) { EntryBlock: %.demorgan = icmp sgt i32 %0, 2 ; [#uses=1] br i1 %.demorgan, label %GreaterThanTwo, label %LessThanOrEqualToTwo GreaterThanTwo: ; preds = %EntryBlock br i1 false, label %Impossible, label %NotTwoAndGreaterThanTwo NotTwoAndGreaterThanTwo: ; preds = %GreaterThanTwo call i32 @asdf( ) ; :1 [#uses=0] ret i32 2 Impossible: ; preds = %GreaterThanTwo call i32 @asdf2( ) ; :2 [#uses=0] ret i32 1 LessThanOrEqualToTwo: ; preds = %EntryBlock call i32 @asdf3( ) ; :3 [#uses=0] ret i32 0 } Unfortunately, predsimplify is not ready for enabling in the mainline. Resolving as 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 Tue Oct 30 14:39:19 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 30 Oct 2007 14:39:19 -0500 Subject: [LLVMbugs] [Bug 1758] New: opt -verify-each doesn' t catch invalid bitcode generated by a pass Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1758 Summary: opt -verify-each doesn't catch invalid bitcode generated by a pass 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 Created an attachment (id=1176) --> (http://llvm.org/bugs/attachment.cgi?id=1176) the invalid bitcode generated While learning how to write a FunctionPass/ModulePass I made the stupid mistake of inserting instructions after a 'ret' instruction in a BasicBlock. Needless to say, it generated invalid bitcode, however opt -verify-each didn't catch the problem, and the next optimizer pass crashed. However if I try to run llvm-dis on the invalid bitcode, it *does* say it is invalid. I think opt -verify-each behaviour should be consistent with llvm-dis's way of loading bitcode. Here it is the invalid bitcode generated (of course this won't even assemble with llvm-as, however LLVMBuilder happily creates it): define i32 @test1() { entry: %retval = alloca i32, align 4 ; [#uses=1] %"alloca point" = bitcast i32 0 to i32 ; [#uses=0] store i32 5, i32* @o, align 4 br label %return return: ; preds = %entry %retval1 = load i32* %retval ; [#uses=1] ret i32 %retval1 malloc i32 ; :0 [#uses=0] } opt: /home/edwin/llvm-svn/llvm/include/llvm/Support/CFG.h:98: llvm::SuccIterator::SuccIterator(Term_) [with Term_ = llvm::TerminatorInst*, BB_ = llvm::BasicBlock]: Assertion `T && "getTerminator returned null!"' failed. opt[0x9bfcae] opt[0x9bff1a] /lib/libc.so.6[0x32d1c31710] /lib/libc.so.6(gsignal+0x35)[0x32d1c316a5] /lib/libc.so.6(abort+0x110)[0x32d1c33100] /lib/libc.so.6(__assert_fail+0xef)[0x32d1c2ac2f] opt(llvm::SuccIterator::SuccIterator(llvm::TerminatorInst*)+0x4f)[0x6b927d] opt(llvm::succ_begin(llvm::BasicBlock*)+0x21)[0x6bc575] opt(llvm::GraphTraits::child_begin(llvm::BasicBlock*)+0x15)[0x6bc5a3] opt(unsigned int llvm::DFSPass >(llvm::DominatorTreeBase::NodeType>&, llvm::GraphTraits::NodeType*, unsigned int)+0x241)[0x8a0357] opt(void llvm::Calculate(llvm::DominatorTreeBase::NodeType>&, llvm::Function&)+0x64)[0x8a13da] opt(void llvm::DominatorTreeBase::recalculate(llvm::Function&)+0xba)[0x8a208a] opt(llvm::DominatorTree::runOnFunction(llvm::Function&)+0x21)[0x91e6cf] opt(llvm::FPPassManager::runOnFunction(llvm::Function&)+0x10e)[0x952876] opt(llvm::FPPassManager::runOnModule(llvm::Module&)+0x52)[0x9529e4] opt(llvm::MPPassManager::runOnModule(llvm::Module&)+0xec)[0x952570] opt(llvm::PassManagerImpl::run(llvm::Module&)+0x74)[0x952700] opt(llvm::PassManager::run(llvm::Module&)+0x20)[0x952762] opt(main+0x986)[0x6bee48] /lib/libc.so.6(__libc_start_main+0xf4)[0x32d1c1db44] opt(cos+0x121)[0x6b05d9] Aborted The buggy part of the pass that generates this invalid bitcode is: UnifyFunctionExitNodes &unifyExitNode = getAnalysis(); LLVMBuilder builder; BasicBlock* End = unifyExitNode.getReturnBlock(); builder.SetInsertPoint(End); builder.CreateMalloc(Type::Int32Ty); It should be 'builder.SetInsertPoint(End, End->begin());' of course. But my point is that the bitcode validator in opt should catch this error. Attached invalid bitcode file, and buggy pass. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 30 17:38:22 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 30 Oct 2007 17:38:22 -0500 Subject: [LLVMbugs] [Bug 1759] New: test/Codegen/array.c fails on x86-64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1759 Summary: test/Codegen/array.c fails on x86-64 Product: cfe Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: parser AssignedTo: unassignedbugs at nondot.org ReportedBy: wilsonkk at shaw.ca CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1180) --> (http://llvm.org/bugs/attachment.cgi?id=1180) a tar file of the array.i file and the debug output for the fail case I was trying to compile the test suite for clang yesterday and ran into an error for array.c. This is using a new svn update of clang and llvm from yesterday (Oct 29,2007). Thanks, K.Wilson -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Oct 30 18:33:09 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 30 Oct 2007 18:33:09 -0500 Subject: [LLVMbugs] [Bug 1760] New: test/Codegen/array.c fails with 'bus error' on Sparc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1760 Summary: test/Codegen/array.c fails with 'bus error' on Sparc Product: cfe Version: unspecified Platform: Sun OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: parser AssignedTo: unassignedbugs at nondot.org ReportedBy: wilsonkk at shaw.ca CC: llvmbugs at cs.uiuc.edu This failure is a tough one because the included .i file doesn't show much and there is no stack trace. From using the '-v' option to clang it seems that the bus error is immediately after reading in the include files. This is the output from the '-v' option: ignoring nonexistent directory "/usr/lib/gcc/i686-apple-darwin9/4.0.1/include" ignoring nonexistent directory "/usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include" ignoring nonexistent directory "/usr/lib/gcc/powerpc-apple-darwin9/4.0.1/../../../../powerpc-apple-darwin0/include" ignoring nonexistent directory "/usr/lib/gcc/i686-apple-darwin8/4.0.1/include" ignoring nonexistent directory "/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include" ignoring nonexistent directory "/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../../powerpc-apple-darwin8/include" ignoring nonexistent directory "/System/Library/Frameworks" ignoring nonexistent directory "/Library/Frameworks" ignoring duplicate directory "///usr/local/include" ignoring duplicate directory "///usr/include" #include "..." search starts here: #include <...> search starts here: ///usr/local/include ///usr/include ///usr/lib/gcc/sparc64-redhat-linux/3.4.2/include Bus error Thanks, K.Wilson -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Oct 31 07:39:44 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 31 Oct 2007 07:39:44 -0500 Subject: [LLVMbugs] [Bug 1753] Alias analysis/other optimizations don' t work in the presence of ptrtoint/inttoptr In-Reply-To: Message-ID: <200710311239.l9VCdi6G024496@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1753 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Eli Friedman 2007-10-31 07:39:39 --- Invalid. The inttoptr/ptrtoint steps get converted to getelementptr with the right arch specified. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Oct 31 08:53:24 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 31 Oct 2007 08:53:24 -0500 Subject: [LLVMbugs] [Bug 1753] instcombine not transforming inttoptr/ ptrtoint to getelementptr for global variable In-Reply-To: Message-ID: <200710311353.l9VDrOiK027388@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1753 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | Summary|Alias analysis/other |instcombine not transforming |optimizations don't work in |inttoptr/ptrtoint to |the presence of |getelementptr for global |ptrtoint/inttoptr |variable --- Comment #5 from Eli Friedman 2007-10-31 08:53:24 --- All right, reopening for the remaining issue, plus retitling since I've diagnosed it. I'm not familiar with instcombine, so I'm having trouble tracking down why the two cases are treated differently. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Oct 31 20:50:30 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 31 Oct 2007 20:50:30 -0500 Subject: [LLVMbugs] [Bug 1758] opt -verify-each doesn' t catch invalid bitcode generated by a pass In-Reply-To: Message-ID: <200711010150.lA11oUWR002896@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1758 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #4 from Chris Lattner 2007-10-31 20:50:29 --- Please see if the fix for 1568 fixed this, thanks! *** This bug has been marked as a duplicate of bug 1568 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Oct 31 22:46:00 2007 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 31 Oct 2007 22:46:00 -0500 Subject: [LLVMbugs] [Bug 1759] test/Codegen/array.c fails on x86-64 In-Reply-To: Message-ID: <200711010346.lA13k0KI010399@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1759 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Chris Lattner 2007-10-31 22:45:59 --- I assume this is a dup of 1760. If the fix for that bug doesn't fix this one, please reopen. *** This bug has been marked as a duplicate of bug 1760 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.