From bugzilla-daemon at cs.uiuc.edu Fri Aug 1 02:17:38 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 1 Aug 2008 02:17:38 -0500 Subject: [LLVMbugs] [Bug 2621] New: Improve SCEV AddRec binomial expansion Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2621 Summary: Improve SCEV AddRec binomial expansion Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1877) --> (http://llvm.org/bugs/attachment.cgi?id=1877) Patch Per description; basically, the current binomial expansion for AddRec sucks, especially for K > 2. A rewrite of the expansion is attached. The primary improvement is that it replaces the division operation with a shift and inverse multiply, which makes the generated code smaller, faster, and more accurate. The way that this method works is slightly unintuitive... the code might need more comments. The fundamental trick is that we can do exact division by an odd number by multiplying by the inverse. Here, we first shift out the factors of 2, then do the remaining division by multiplication. By itself, this is a nice improvement, because the division can be expensive. However, the reason this is really useful here is that it radically reduces the number of bits we need to keep track of while multiplying. With this patch, instead of requiring K * Width bits to be accurate, the algorithm requires only K + Width bits; the number of 2's that can be factored out of K! is always less than K. The bits of overflow beyond the part that's going to be shifted into the final result can be safely ignored because multiplying by the inverse doesn't use those bits. Other smaller changes: this makes the binomial expansion always accurate; it will bail out instead of silently returning a wrong answer (the algorithm is sound for any reasonable size K and arbitrary-width integers, but the patch avoids generating >64-bit integers because CodeGen doesn't like them). It also computes the terms before zero-extending them; this helps a lot when the size used for calculation is larger than the native register width because CodeGen isn't smart enough to eliminate the carry when the extension is done first. An extreme example: int a(unsigned u) {unsigned v=0,w=0,x=0,y=0,z=0; for (unsigned i = 0; i < u; i++) {v += w; w += x; x += y; y += z; z += 1;} return v;} The attached reduces the x86 code for the expansion of the return value from 73 instructions, including two calls to __udivdi3, to 32 instructions without any libcalls. Not to mention that it isn't a fair comparison because the code without this patch generates the wrong answer for large values of u. Does this approach seem reasonable? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 1 03:49:08 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 1 Aug 2008 03:49:08 -0500 Subject: [LLVMbugs] [Bug 2622] New: movlps does not get selected for 4, 5, 2, 3 shuffle to/ from memory Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2622 Summary: movlps does not get selected for 4,5,2,3 shuffle to/from memory 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: nicolas at capens.net CC: llvmbugs at cs.uiuc.edu The following LLVM IR is not generating optimal x86 code: external global <4 x float>, align 16 ; <<4 x float>*>:0 [#uses=1] external global <4 x float>, align 16 ; <<4 x float>*>:1 [#uses=1] external global <4 x float>, align 1 ; <<4 x float>*>:2 [#uses=2] define internal void @""() { load <4 x float>* @0, align 16 ; <<4 x float>>:1 [#uses=1] load <4 x float>* @1, align 16 ; <<4 x float>>:2 [#uses=1] add <4 x float> %1, %2 ; <<4 x float>>:3 [#uses=1] load <4 x float>* @2, align 1 ; <<4 x float>>:4 [#uses=1] shufflevector <4 x float> %4, <4 x float> %3, <4 x i32> < i32 4, i32 5, i32 2, i32 3 > ; <<4 x float>>:5 [#uses=1] store <4 x float> %5, <4 x float>* @2, align 1 ret void } What I'm getting is: push ebp mov ebp,esp and esp,0FFFFFFF0h movaps xmm0,xmmword ptr ds:[1757E80h] addps xmm0,xmmword ptr ds:[1757E90h] movups xmm1,xmmword ptr ds:[1757E88h] movsd xmm1,xmm0 movups xmmword ptr ds:[1757E88h],xmm1 mov esp,ebp pop ebp ret But I was rather hoping to see something like: push ebp mov ebp,esp and esp,0FFFFFFF0h movaps xmm0,xmmword ptr ds:[1757E80h] addps xmm0,xmmword ptr ds:[1757E90h] movlps xmmword ptr ds:[1757E88h],xmm1 mov esp,ebp pop ebp ret Curiously, it looks like instruction selection already has a pattern to select movlps for this situation, but for some reason it doesn't actually end up in the result. Same for movhps and a 1,2,6,7 shuffle. Additionally, it looks like a pattern could be added for using movlps/ movhps as an insert from memory (a pattern for extract already seems present, though I haven't verfied yet that it gets selected). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 1 10:49:59 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 1 Aug 2008 10:49:59 -0500 Subject: [LLVMbugs] [Bug 2623] New: Assertion failure calling function with struct-typed phi value Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2623 Summary: Assertion failure calling function with struct-typed phi value Product: new-bugs Version: unspecified Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: csdavec at swan.ac.uk CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1878) --> (http://llvm.org/bugs/attachment.cgi?id=1878) Test case. Compiling the attached bitcode produces the following error: $ llc bugpoint-reduced-simplified.bc Assertion failed: (0 && "Unknown type!"), function getMVT, file ValueTypes.cpp, line 109. The same error appears when it's compiled using the JIT. It appears to be related to the phi node, since generating the same function call without a value which was returned directly from a function (not accessed via a phi instruction) compiles and generates the correct (ABI-compliant) 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 Fri Aug 1 12:40:58 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 1 Aug 2008 12:40:58 -0500 Subject: [LLVMbugs] [Bug 2624] New: Ada loops not unrolled Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2624 Summary: Ada loops not unrolled Product: new-bugs Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu The loop unroller doesn't want to unroll the attached testcase, even though it is very simple and there are only two iterations. I think this may be because the condition is tested before incrementing the induction variable. This is how the Ada f-e generates for loops (unlike in C, where the induction variable is incremented first and the condition tested afterwards). I guess this is why I never (as far as I can remember) saw an Ada loop unrolled by LLVM... -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 2 17:18:26 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 2 Aug 2008 17:18:26 -0500 Subject: [LLVMbugs] [Bug 2625] New: Code snippet fails during code generation. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2625 Summary: Code snippet fails during code generation. Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: rich at pennware.com CC: llvmbugs at cs.uiuc.edu The following fails with an abort with llc: ; ModuleID = 't0042.ubc' define i32 @main({ i32, { i32 } }*) { entry: %state = alloca { i32, { i32 } }* ; <{ i32, { i32 } }**> [#uses=2] store { i32, { i32 } }* %0, { i32, { i32 } }** %state %retval = alloca i32 ; [#uses=2] store i32 0, i32* %retval load { i32, { i32 } }** %state ; <{ i32, { i32 } }*>:1 [#uses=1] store { i32, { i32 } } zeroinitializer, { i32, { i32 } }* %1 br label %return return: ; preds = %entry load i32* %retval ; :2 [#uses=1] ret i32 %2 } ~/ellcc/ellcc] main% llc t0042.ubc llc: /home/rich/llvm-trunk-new/lib/VMCore/ValueTypes.cpp:109: static llvm::MVT llvm::MVT::getMVT(const llvm::Type*, bool): Assertion `0 && "Unknown type!"' failed. llc[0x8b5105e] llc[0x8b51190] [0x110400] /lib/libc.so.6(abort+0x101)[0xa62f91] /lib/libc.so.6(__assert_fail+0xee)[0xa5a93e] llc(_ZN4llvm3MVT6getMVTEPKNS_4TypeEb+0x6f)[0x8b00073] llc(_ZNK4llvm14TargetLowering12getValueTypeEPKNS_4TypeEb+0x26)[0x8566396] llc(_ZN4llvm20SelectionDAGLowering8getValueEPKNS_5ValueE+0x9e0)[0x88243ba] llc(_ZN4llvm20SelectionDAGLowering10visitStoreERNS_9StoreInstE+0xcf)[0x882cc6b] llc(_ZN4llvm20SelectionDAGLowering5visitEjRNS_4UserE+0x28f)[0x885277b] llc(_ZN4llvm20SelectionDAGLowering5visitERNS_11InstructionE+0x28)[0x8852a18] llc(_ZN4llvm16SelectionDAGISel17BuildSelectionDAGERNS_12SelectionDAGEPNS_10BasicBlockERSt6vectorISt4pairIPNS_12MachineInstrEjESaIS9_EERNS_20FunctionLoweringInfoE+0x3a4)[0x8835aee] llc(_ZN4llvm16SelectionDAGISel16SelectBasicBlockEPNS_10BasicBlockERNS_15MachineFunctionERNS_20FunctionLoweringInfoERNS_18RecyclingAllocatorINS_16BumpPtrAllocatorENS_6SDNodeELj136ELj4EEE+0xb7)[0x8836307] llc(_ZN4llvm16SelectionDAGISel20SelectAllBasicBlocksERNS_8FunctionERNS_15MachineFunctionERNS_20FunctionLoweringInfoE+0x7a)[0x8837b38] llc(_ZN4llvm16SelectionDAGISel13runOnFunctionERNS_8FunctionE+0x210)[0x8838688] llc[0x873efb1] llc(_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x135)[0x8ade227] llc(_ZN4llvm23FunctionPassManagerImpl3runERNS_8FunctionE+0x6e)[0x8ade4ac] llc(_ZN4llvm19FunctionPassManager3runERNS_8FunctionE+0x89)[0x8ade5fb] llc(main+0x9a2)[0x83cb334] /lib/libc.so.6(__libc_start_main+0xe0)[0xa4e390] llc[0x83c99c1] Abort -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 3 02:48:16 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 3 Aug 2008 02:48:16 -0500 Subject: [LLVMbugs] [Bug 2626] New: 2006-01-23-InitializedBitField.c uses over-width bools Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2626 Summary: 2006-01-23-InitializedBitField.c uses over-width bools Product: Test Suite Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Nightly Tester AssignedTo: unassignedbugs at nondot.org ReportedBy: nicholas at mxc.ca CC: llvmbugs at cs.uiuc.edu GCC 4.3 refuses to compile 2006-01-23-InitializedBitField.c with these errors: 2006-01-23-InitializedBitField.c:49: error: width of 'D' exceeds its type 2006-01-23-InitializedBitField.c:50: error: width of 'D2' exceeds its type 2006-01-23-InitializedBitField.c:71: error: width of 'D' exceeds its type 2006-01-23-InitializedBitField.c:72: error: width of 'D2' exceeds its type 2006-01-23-InitializedBitField.c:79: error: width of 'D' exceeds its type because of this construct: struct S7 { _Bool D : 8; _Bool D2 : 8; int D3 : 8; long long : 9; float B; } s7 = { 1, 0, 123, 1.023f }; which is fair. It may be that the ABI defines that type to be 8 bits or whatever in memory, but that doesn't mean you can demand it be any larger than 1 bit. This construct should be removed from the test. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Aug 3 03:18:40 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 3 Aug 2008 03:18:40 -0500 Subject: [LLVMbugs] [Bug 2627] New: clang doesn't understand "q"/"Q" constraint for __asm Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2627 Summary: clang doesn't understand "q"/"Q" constraint for __asm Product: clang Version: unspecified Platform: Other OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: parser AssignedTo: unassignedbugs at nondot.org ReportedBy: cperciva at freebsd.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1884) --> (http://llvm.org/bugs/attachment.cgi?id=1884) builds with gcc, errors out with clang FreeBSD's machine/endian.h on AMD64 contains the following definition: #define __byte_swap_word_var(x) \ __extension__ ({ register __uint16_t __X = (x); \ __asm ("xchgb %h0, %b0" : "+Q" (__X)); \ __X; }) On i386, the definition is the same except with "+Q" replaced by "+q". In both cases, clang exits with an error message complaining about the "+Q" or "+q": "error: invalid output constraint in asm" -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 3 05:16:00 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 3 Aug 2008 05:16:00 -0500 Subject: [LLVMbugs] [Bug 2628] New: Valgrind detected invalid read during llvm-gcc bootstrap Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2628 Summary: Valgrind detected invalid read during llvm-gcc bootstrap Product: new-bugs Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Invalid read of size 1 at 0xB5319B: _cpp_convert_input (charset.c:1695) by 0xB5BC91: read_file_guts (files.c:590) by 0xB5BD43: read_file (files.c:617) by 0xB5BE85: should_stack_file (files.c:666) by 0xB5C0AF: _cpp_stack_file (files.c:744) by 0xB5C4F1: _cpp_stack_include (files.c:872) by 0xB54229: do_include_common (directives.c:765) by 0xB54260: do_include (directives.c:776) by 0xB53AC5: _cpp_handle_directive (directives.c:484) by 0xB60E6F: _cpp_lex_token (lex.c:900) by 0xB65895: cpp_get_token (macro.c:1102) by 0x40A66D: c_lex_with_flags (c-lex.c:404) Address 0x66d2d5f is 1 bytes before a block of size 1 alloc'd at 0x4C26A81: realloc (vg_replace_malloc.c:429) by 0x115D0C0: xrealloc (xmalloc.c:179) by 0xB53186: _cpp_convert_input (charset.c:1689) by 0xB5BC91: read_file_guts (files.c:590) by 0xB5BD43: read_file (files.c:617) by 0xB5BE85: should_stack_file (files.c:666) by 0xB5C0AF: _cpp_stack_file (files.c:744) by 0xB5C4F1: _cpp_stack_include (files.c:872) by 0xB54229: do_include_common (directives.c:765) by 0xB54260: do_include (directives.c:776) by 0xB53AC5: _cpp_handle_directive (directives.c:484) by 0xB60E6F: _cpp_lex_token (lex.c:900) This was while executing: gcc-4.2.llvm-objects/./prev-gcc/cc1 -quiet -I. -I. -I../../gcc-4.2.llvm/gcc -I../../gcc-4.2.llvm/gcc/. -I../../gcc-4.2.llvm/gcc/../include -I../../gcc-4.2.llvm/gcc/../libcpp/include -I../../gcc-4.2.llvm/gcc/../libdecnumber -I../libdecnumber -Illvm-objects/include -Illvm.top/llvm/include -Illvm-objects/../llvm/include -iprefix gcc-4.2.llvm-objects/prev-gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.2.1/ -isystem gcc-4.2.llvm-objects/./prev-gcc/include -DIN_GCC -DHAVE_CONFIG_H -DENABLE_LLVM -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -DSTANDARD_STARTFILE_PREFIX="../../../" -DSTANDARD_EXEC_PREFIX="/usr/local/gnat-llvm/lib/gcc/" -DSTANDARD_LIBEXEC_PREFIX="/usr/local/gnat-llvm/libexec/gcc/" -DDEFAULT_TARGET_VERSION="4.2.1" -DDEFAULT_TARGET_MACHINE="x86_64-unknown-linux-gnu" -DSTANDARD_BINDIR_PREFIX="/usr/local/gnat-llvm/bin/" -DTOOLDIR_BASE_PREFIX="../../../../" ../../gcc-4.2.llvm/gcc/gcc.c -quiet -dumpbase gcc.c -mtune=generic -auxbase-strip gcc.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -fno-common -o /tmp/cco2SriU.s -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Aug 3 09:37:54 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 3 Aug 2008 09:37:54 -0500 Subject: [LLVMbugs] [Bug 2629] New: llvm-gcc won't build on linux Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2629 Summary: llvm-gcc won't build on linux Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: nicholas at mxc.ca CC: llvmbugs at cs.uiuc.edu It's not immediately clear to me whether this is due to a miscompiled xgcc or a change in the implementation of atomic primitives in Apple's gcc. Either way, here's the compile failure: /usr/local/google/home/nlewycky/llvm-gcc/build/./gcc/xgcc -B/usr/local/google/home/nlewycky/llvm-gcc/build/./gcc/ -B/usr/local/google/home/nlewycky/llvm-gcc/install/i686-pc-linux-gnu/bin/ -B/usr/local/google/home/nlewycky/llvm-gcc/install/i686-pc-linux-gnu/lib/ -isystem /usr/local/google/home/nlewycky/llvm-gcc/install/i686-pc-linux-gnu/include -isystem /usr/local/google/home/nlewycky/llvm-gcc/install/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../src/libgomp -I. -I../../../src/libgomp/config/linux/x86 -I../../../src/libgomp/config/linux -I../../../src/libgomp/config/posix -I../../../src/libgomp -Wall -Werror -ftls-model=initial-exec -march=i486 -pthread -mtune=i686 -O2 -g -O2 -MT alloc.lo -MD -MP -MF .deps/alloc.Tpo -c ../../../src/libgomp/alloc.c -o alloc.o In file included from ../../../src/libgomp/libgomp.h:50, from ../../../src/libgomp/alloc.c:32: ../../../src/libgomp/config/linux/sem.h: In function 'gomp_sem_wait': ../../../src/libgomp/config/linux/sem.h:45: error: incompatible type for argument 1 of '__sync_bool_compare_and_swap' ../../../src/libgomp/config/linux/sem.h: In function 'gomp_sem_post': ../../../src/libgomp/config/linux/sem.h:52: error: incompatible type for argument 1 of '__sync_bool_compare_and_swap' In file included from ../../../src/libgomp/libgomp.h:51, from ../../../src/libgomp/alloc.c:32: ../../../src/libgomp/config/linux/mutex.h: In function 'gomp_mutex_lock': ../../../src/libgomp/config/linux/mutex.h:47: error: incompatible type for argument 1 of '__sync_bool_compare_and_swap' ../../../src/libgomp/config/linux/mutex.h: In function 'gomp_mutex_unlock': ../../../src/libgomp/config/linux/mutex.h:54: error: incompatible type for argument 1 of '__sync_lock_test_and_set' make[4]: *** [alloc.lo] Error 1 make[4]: Leaving directory `/usr/local/google/home/nlewycky/llvm-gcc/build/i686-pc-linux-gnu/libgomp' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/local/google/home/nlewycky/llvm-gcc/build/i686-pc-linux-gnu/libgomp' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/google/home/nlewycky/llvm-gcc/build/i686-pc-linux-gnu/libgomp' make[1]: *** [all-target-libgomp] Error 2 make[1]: Leaving directory `/usr/local/google/home/nlewycky/llvm-gcc/build' make: *** [all] Error 2 The code it's complaining about looks like this: extern void gomp_mutex_lock_slow (gomp_mutex_t *mutex); static inline void gomp_mutex_lock (gomp_mutex_t *mutex) { if (!__sync_bool_compare_and_swap (mutex, 0, 1)) gomp_mutex_lock_slow (mutex); } and those __sync* functions are defined here: http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Atomic-Builtins.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 Aug 3 12:43:49 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 3 Aug 2008 12:43:49 -0500 Subject: [LLVMbugs] [Bug 2615] mips cannot return double. In-Reply-To: Message-ID: <200808031743.m73HhnmM023196@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2615 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Bruno Cardoso Lopes 2008-08-03 12:43:49 --- This bug is not present for EABI or single float only environments (where 2 integer registers are used to hold f64 values), but only for normal O32 ABI ones. I fixed for O32 ABI now, it's also worth mentioning that this ABI is not fully implemented. Please, continue to report bugs as you fell the need, so I can implement what is missing from O32. Thanks, The fix : http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/Mips/MipsCallingConv.td?r1=54311&r2=54312&view=diff&pathrev=54312 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 3 23:55:44 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 3 Aug 2008 23:55:44 -0500 Subject: [LLVMbugs] [Bug 2631] New: va_list + va_arg breaks clang on FreeBSD Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2631 Summary: va_list + va_arg breaks clang on FreeBSD Product: clang Version: unspecified Platform: Other OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: parser AssignedTo: unassignedbugs at nondot.org ReportedBy: cperciva at freebsd.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1886) --> (http://llvm.org/bugs/attachment.cgi?id=1886) C code which breaks $ ~/llvm/tools/clang/utils/ccc -o testme testme.c testme.c clang -emit-llvm-bc -o testme.o testme.c testme.c:12:8: error: first argument to 'va_arg' is of type 'struct __va_list_tag *' and not 'va_list' s = va_arg(ap, char *); ^~~~~~ 1 diagnostic generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Aug 4 02:32:19 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 4 Aug 2008 02:32:19 -0500 Subject: [LLVMbugs] [Bug 2189] Inconsistencies with array typedefs In-Reply-To: Message-ID: <200808040732.m747WJYW017255@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2189 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Chris Lattner 2008-08-04 02:32:19 --- (finally) Fixed! http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080804/006798.html Eli, please let me know if you run into similar bogosity. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 4 15:05:59 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 4 Aug 2008 15:05:59 -0500 Subject: [LLVMbugs] [Bug 2628] Valgrind detected invalid read during llvm-gcc bootstrap In-Reply-To: Message-ID: <200808042005.m74K5xbv025195@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2628 Bill Wendling changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Bill Wendling 2008-08-04 15:05:58 --- Fixed: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080804/065644.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 Aug 4 17:44:00 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 4 Aug 2008 17:44:00 -0500 Subject: [LLVMbugs] [Bug 2634] New: Remat applied to updated value Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2634 Summary: Remat applied to updated value Product: libraries Version: 2.3 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Register Allocator AssignedTo: unassignedbugs at nondot.org ReportedBy: greened at obbligato.org CC: llvmbugs at cs.uiuc.edu In SPEC CPU 2006 leslie3d, a value is spilled, split and one of the splits is spilled again. The value happens to be rematable and when the split interval is spilled two-address rewriting causes the enregistered value to be changed. But live interval analysis has outdated information and thinks it can insert a remat of the old value just after the new value is written to the register. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Aug 4 18:56:08 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 4 Aug 2008 18:56:08 -0500 Subject: [LLVMbugs] [Bug 2621] Improve SCEV AddRec binomial expansion In-Reply-To: Message-ID: <200808042356.m74Nu8ZT000669@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2621 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Eli Friedman 2008-08-04 18:56:08 --- Updated to address the review comments, and committed in r54332. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080804/065651.html. I'll be filing a few followups, as I mentioned in the commit message. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 4 19:44:54 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 4 Aug 2008 19:44:54 -0500 Subject: [LLVMbugs] [Bug 2635] New: x86 codegen for long AddRec expansion could be improved Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2635 Summary: x86 codegen for long AddRec expansion could be improved Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1889) --> (http://llvm.org/bugs/attachment.cgi?id=1889) Testcase (IL) IL attached, generated from the following testcase: int a(unsigned b) { unsigned x1=0,x2=0,x3=0,x4=0,x5=0,x6=0,x7=0,x8=0,x9=0,x10=0,x11=0,x12=0,x13=0,x14=0,x15=0,x16=0,x17=0,i; for (i = 0; i < b; i++) {x1+=x2+=x3+=x4+=x5+=x6+=x7+=x8+=x9+=x10+=x11+=x12+=x13+=x14+=x15+=x16+=x17+=1;} return x1; } The issue is essentially that CodeGen ends up spilling the result of almost every single instruction; I haven't actually tried to hand-optimize it, but I think that if it actually did all the operations in the best order, and it was clever enough to remat the additions, it wouldn't have to spill anything. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Aug 4 20:44:05 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 4 Aug 2008 20:44:05 -0500 Subject: [LLVMbugs] [Bug 2601] clang skips promotions for compound assignment operators In-Reply-To: Message-ID: <200808050144.m751i5qG004286@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2601 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- CC|llvmbugs at cs.uiuc.edu |daniel at zuster.org -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 5 02:12:07 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 02:12:07 -0500 Subject: [LLVMbugs] [Bug 2568] regalloc losing a write-back In-Reply-To: Message-ID: <200808050712.m757C7ou014546@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2568 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #12 from Evan Cheng 2008-08-05 02:12:06 --- Fixed. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080804/065664.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Aug 5 08:07:17 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 08:07:17 -0500 Subject: [LLVMbugs] [Bug 2636] New: Assertion failed: (false && " Serializization for type not supported."), function EmitImpl, file TypeSerialization.cpp, line 56. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2636 Summary: Assertion failed: (false && "Serializization for type not supported."), function EmitImpl, file TypeSerialization.cpp, line 56. Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: AST AssignedTo: unassignedbugs at nondot.org ReportedBy: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu clang crashes when serializing certain input files. Here's a delta-reduced testcase: $ cat bla.c int *(funcp)(int, int); __typeof(funcp) fp2; $ clang -serialize bla.c Assertion failed: (false && "Serializization for type not supported."), function EmitImpl, file TypeSerialization.cpp, line 56. 0 clang 0x002f182b _ZN4llvm3sys7Program17FindProgramByNameERKSs + 611 1 clang 0x002f1af5 _ZN4llvm3sys28PrintStackTraceOnErrorSignalEv + 593 2 libSystem.B.dylib 0x966ed09b _sigtramp + 43 3 ??? 0xffffffff 0x0 + 4294967295 4 libSystem.B.dylib 0x96765ec2 raise + 26 5 libSystem.B.dylib 0x9677547f abort + 73 6 libSystem.B.dylib 0x96767063 __assert_rtn + 101 7 clang 0x001a8f29 _ZNK5clang4Type8EmitImplERN4llvm10SerializerE + 55 8 clang 0x001a94a4 _ZNK5clang4Type4EmitERN4llvm10SerializerE + 108 9 clang 0x0014f090 _ZNK5clang10ASTContext4EmitERN4llvm10SerializerE + 218 10 clang 0x001a10fc _ZN4llvm14SerializeTraitIN5clang10ASTContextEE4EmitERNS_10SerializerERKS2_ + 24 11 clang 0x001a112e _ZN4llvm10Serializer12EmitOwnedPtrIN5clang10ASTContextEEEvPT_ + 48 12 clang 0x0019f99b _ZNK5clang15TranslationUnit4EmitERN4llvm10SerializerE + 217 13 clang 0x001a06d8 _ZN5clang20EmitASTBitcodeBufferERKNS_15TranslationUnitERSt6vectorIhSaIhEE + 232 14 clang 0x001a075d _ZN5clang18EmitASTBitcodeFileERKNS_15TranslationUnitERKN4llvm3sys4PathE + 91 15 clang 0x001a0808 _ZN5clang18EmitASTBitcodeFileEPKNS_15TranslationUnitERKN4llvm3sys4PathE + 30 16 clang 0x0000416d _ZN45_GLOBAL__N_ASTConsumers.cpp_00000000_12721AD620SingleFileSerializerD0Ev + 53 17 clang 0x00108fb2 _ZN5clang8ParseASTERNS_12PreprocessorEPNS_11ASTConsumerEb + 630 18 clang 0x0002a6ce _Z16InitializeGCModeRN5clang11LangOptionsE + 5850 19 clang 0x0002de02 main + 1596 20 clang 0x000019c2 start + 54 21 ??? 0x00000003 0x0 + 3 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 5 10:37:49 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 10:37:49 -0500 Subject: [LLVMbugs] [Bug 2579] `./configure` check for Carbon.h fails with CC=clang In-Reply-To: Message-ID: <200808051537.m75Fbnsq012840@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2579 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel at zuster.org Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Daniel Dunbar 2008-08-05 10:37:49 --- This should be resolved. Please confirm and close. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 5 10:38:17 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 10:38:17 -0500 Subject: [LLVMbugs] [Bug 2427] clang redefines size_t silently but then complains In-Reply-To: Message-ID: <200808051538.m75FcHHu012909@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2427 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel at zuster.org Status|NEW |RESOLVED Resolution| |FIXED --- Comment #9 from Daniel Dunbar 2008-08-05 10:38:17 --- This should be resolved. Please confirm and close. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 5 10:45:51 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 10:45:51 -0500 Subject: [LLVMbugs] [Bug 2582] implicit cast of pointer to integer should generate warning In-Reply-To: Message-ID: <200808051545.m75FjpsV013287@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2582 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Daniel Dunbar 2008-08-05 10:45:51 --- Fixed: http://llvm.org/viewvc/llvm-project?view=rev&revision=54335 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 5 10:54:32 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 10:54:32 -0500 Subject: [LLVMbugs] =?utf-8?q?=5BBug_2517=5D__scan-build_reports_=E2=80=9C?= =?utf-8?q?missing_-dealloc=E2=80=9D_where_-dealloc_is_unnecessary?= In-Reply-To: Message-ID: <200808051554.m75FsWuH013685@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2517 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Ted Kremenek 2008-08-05 10:54:31 --- The MissingDealloc check will continue to be a work in progress. The current version of the check satisfies the original request in this PR. We should open up new PRs as specific requests come in for refinements to the MissingDealloc check. Closing. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Aug 5 10:55:33 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 10:55:33 -0500 Subject: [LLVMbugs] [Bug 2158] clang has no doxygen In-Reply-To: Message-ID: <200808051555.m75FtXfS013759@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2158 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel at zuster.org Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Daniel Dunbar 2008-08-05 10:55:32 --- Fixed: http://clang.llvm.org/doxygen -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 5 11:16:28 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 11:16:28 -0500 Subject: [LLVMbugs] [Bug 2001] clang bitfield assignment produces wrong value In-Reply-To: Message-ID: <200808051616.m75GGSDP014569@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2001 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel at zuster.org Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Daniel Dunbar 2008-08-05 11:16:25 --- Added test case: http://llvm.org/viewvc/llvm-project?view=rev&revision=54352 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 5 11:18:16 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 11:18:16 -0500 Subject: [LLVMbugs] [Bug 2637] New: -serialze tries to serialize invalid ASTs Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2637 Summary: -serialze tries to serialize invalid ASTs Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: AST AssignedTo: unassignedbugs at nondot.org ReportedBy: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu If clang gets passes the -serialize switch, serialization is even attempted if the input file is invalid. This makes e.g. producing minimized testcases for -serialize with delta harder, because if I use clang -serialize bla.c | grep "Assertion failed: (isa(d) && "DeclRefExpr can only own FunctionDecls for implicitly def. funcs."), function EmitImpl, file StmtSerialization.cpp, line 498. 0 clang 0x002f182b _ZN4llvm3sys7Program17FindProgramByNameERKSs + 611 1 clang 0x002f1af5 _ZN4llvm3sys28PrintStackTraceOnErrorSignalEv + 593 2 libSystem.B.dylib 0x966ed09b _sigtramp + 43 3 ??? 0xffffffff 0x0 + 4294967295 4 libSystem.B.dylib 0x96765ec2 raise + 26 5 libSystem.B.dylib 0x9677547f abort + 73 6 libSystem.B.dylib 0x96767063 __assert_rtn + 101 7 clang 0x00198a65 _ZNK5clang11DeclRefExpr8EmitImplERN4llvm10SerializerE + 183 8 clang 0x00196ca9 _ZNK5clang4Stmt4EmitERN4llvm10SerializerE + 77 9 clang 0x001a9c6c _ZN4llvm14SerializeTraitIN5clang4StmtEE4EmitERNS_10SerializerERKS2_ + 24 10 clang 0x0019bd1a _ZN4llvm10Serializer18BatchEmitOwnedPtrsIN5clang4StmtEEEvjPKPT_ + 104 11 clang 0x0019816f _ZNK5clang8CallExpr8EmitImplERN4llvm10SerializerE + 121 12 clang 0x00196ca9 _ZNK5clang4Stmt4EmitERN4llvm10SerializerE + 77 13 clang 0x001a9c6c _ZN4llvm14SerializeTraitIN5clang4StmtEE4EmitERNS_10SerializerERKS2_ + 24 14 clang 0x001a9c9e _ZN4llvm10Serializer12EmitOwnedPtrIN5clang4StmtEEEvPT_ + 48 15 clang 0x001980a0 _ZNK5clang8CastExpr8EmitImplERN4llvm10SerializerE + 80 16 clang 0x00196ca9 _ZNK5clang4Stmt4EmitERN4llvm10SerializerE + 77 17 clang 0x0019bb7a _ZN4llvm14SerializeTraitIKN5clang4ExprEE4EmitERNS_10SerializerERS3_ + 24 18 clang 0x00177e10 _ZN4llvm10Serializer18BatchEmitOwnedPtrsIKN5clang4ExprEKNS2_10ScopedDeclEEEvPT_PT0_ + 66 19 clang 0x001761b6 _ZNK5clang7VarDecl10EmitOutRecERN4llvm10SerializerE + 50 20 clang 0x0017730c _ZNK5clang7VarDecl8EmitImplERN4llvm10SerializerE + 42 21 clang 0x00176156 _ZNK5clang4Decl4EmitERN4llvm10SerializerE + 66 22 clang 0x001a10b0 _ZN4llvm14SerializeTraitIN5clang4DeclEE4EmitERNS_10SerializerERKS2_ + 24 23 clang 0x001a10e2 _ZN4llvm10Serializer12EmitOwnedPtrIN5clang4DeclEEEvPT_ + 48 24 clang 0x0019f940 _ZNK5clang15TranslationUnit4EmitERN4llvm10SerializerE + 126 25 clang 0x001a06d8 _ZN5clang20EmitASTBitcodeBufferERKNS_15TranslationUnitERSt6vectorIhSaIhEE + 232 26 clang 0x001a075d _ZN5clang18EmitASTBitcodeFileERKNS_15TranslationUnitERKN4llvm3sys4PathE + 91 27 clang 0x001a0808 _ZN5clang18EmitASTBitcodeFileEPKNS_15TranslationUnitERKN4llvm3sys4PathE + 30 28 clang 0x0000416d _ZN45_GLOBAL__N_ASTConsumers.cpp_00000000_12721AD620SingleFileSerializerD0Ev + 53 29 clang 0x00108fb2 _ZN5clang8ParseASTERNS_12PreprocessorEPNS_11ASTConsumerEb + 630 30 clang 0x0002a6ce _Z16InitializeGCModeRN5clang11LangOptionsE + 5850 31 clang 0x0002de02 main + 1596 32 clang 0x000019c2 start + 54 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 Tue Aug 5 12:41:10 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 12:41:10 -0500 Subject: [LLVMbugs] [Bug 2638] New: Missing optimization (fold of ashr and sext) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2638 Summary: Missing optimization (fold of ashr and sext) Product: new-bugs Version: unspecified Platform: Macintosh OS/Version: All Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: daniel at zuster.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1892) --> (http://llvm.org/bugs/attachment.cgi?id=1892) Input .c file LLVM misses some optimization of the attached test case: -- ddunbar at ddunbar2:CodeGen$ llvm-gcc -c --emit-llvm -o - ~/rt/gaz.c | opt -std-compile-opts | llvm-dis ; ModuleID = '' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128" target triple = "i386-apple-darwin9" define i32 @foo(i32 %i) nounwind { entry: %tmp12 = trunc i32 %i to i8 ; [#uses=1] %tmp16 = shl i8 %tmp12, 6 ; [#uses=1] %sextr23 = ashr i8 %tmp16, 6 ; [#uses=1] %sextr2324 = sext i8 %sextr23 to i32 ; [#uses=1] ret i32 %sextr2324 } For reference, here is the bytecode that comes from the IR generated by clang, after optimization: -- clang -- ; ModuleID = '' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128" target triple = "i686-apple-darwin9.4.0" define i32 @foo(i32 %i) nounwind { entry: %tmp9 = shl i32 %i, 30 ; [#uses=1] %tmp10 = ashr i32 %tmp9, 30 ; [#uses=1] ret i32 %tmp10 } The difference comes from the way the bitfield load is generated.... No clue if this is worthwhile. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 5 13:20:16 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 13:20:16 -0500 Subject: [LLVMbugs] [Bug 2639] New: opt -loop-deletion -loop-rotate triggers assert in domfrontier Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2639 Summary: opt -loop-deletion -loop-rotate triggers assert in domfrontier 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: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=1893) --> (http://llvm.org/bugs/attachment.cgi?id=1893) testcase $ ~/llvm/Debug/bin/opt b.bc -loop-deletion -loop-rotate -f -o b2.bc opt: /usr/local/src/llvm/include/llvm/Analysis/Dominators.h:940: void llvm::DominanceFrontierBase::addBasicBlock(llvm::BasicBlock*, const std::set, std::allocator >&): Assertion `find(BB) == end() && "Block already in DominanceFrontier!"' failed. /home/nlewycky/llvm/Debug/bin/opt[0x86b097e] /home/nlewycky/llvm/Debug/bin/opt[0x86b0be0] [0xffffe500] [0x6] /lib/tls/i686/cmov/libc.so.6(abort+0xe9)[0x49739619] /lib/tls/i686/cmov/libc.so.6(__assert_fail+0x101)[0x49731031] /home/nlewycky/llvm/Debug/bin/opt(_ZN4llvm21DominanceFrontierBase13addBasicBlockEPNS_10BasicBlockERKSt3setIS2_St4lessIS2_ESaIS2_EE+0x108)[0x8473908] /home/nlewycky/llvm/Debug/bin/opt(_ZN4llvm17SplitCriticalEdgeEPNS_14TerminatorInstEjPNS_4PassEb+0x71a)[0x84d72da] /home/nlewycky/llvm/Debug/bin/opt(_ZN4llvm9SplitEdgeEPNS_10BasicBlockES1_PNS_4PassE+0xa9)[0x84d516d] /home/nlewycky/llvm/Debug/bin/opt[0x8471852] /home/nlewycky/llvm/Debug/bin/opt[0x8472749] /home/nlewycky/llvm/Debug/bin/opt[0x84727c8] /home/nlewycky/llvm/Debug/bin/opt(_ZN4llvm13LPPassManager13runOnFunctionERNS_8FunctionE+0x3cd)[0x856279b] /home/nlewycky/llvm/Debug/bin/opt(_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x13d)[0x863bf8f] /home/nlewycky/llvm/Debug/bin/opt(_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x6e)[0x863c15a] /home/nlewycky/llvm/Debug/bin/opt(_ZN4llvm13MPPassManager11runOnModuleERNS_6ModuleE+0x108)[0x863bc0a] /home/nlewycky/llvm/Debug/bin/opt(_ZN4llvm15PassManagerImpl3runERNS_6ModuleE+0x6e)[0x863bdc4] /home/nlewycky/llvm/Debug/bin/opt(_ZN4llvm11PassManager3runERNS_6ModuleE+0x1b)[0x863be19] /home/nlewycky/llvm/Debug/bin/opt(main+0xb54)[0x8374abe] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xd2)[0x49723ec2] /home/nlewycky/llvm/Debug/bin/opt(__gxx_personality_v0+0x331)[0x8366565] Aborted Interestingly enough, you need the "-f -o" part, otherwise it won't trigger, not even with -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 Tue Aug 5 14:48:46 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 14:48:46 -0500 Subject: [LLVMbugs] [Bug 2640] New: PassManager unable to schedule lcssa Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2640 Summary: PassManager unable to schedule lcssa Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Core LLVM classes AssignedTo: unassignedbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu The pass manager asserts when run with -loop-deletion -loop-index-split. What's going on? $ echo | llvm-as > empty.bc $ opt -loop-deletion -loop-index-split empty.bc -disable-output -debug-pass=Structure Pass Arguments: -domtree -loops -scalar-evolution -loopsimplify -domfrontier -scalar-evolution -lcssa -loop-deletion -domfrontier Target Data Layout ModulePass Manager FunctionPass Manager Dominator Tree Construction Natural Loop Construction Scalar Evolution Analysis -- Scalar Evolution Analysis Canonicalize natural loops Dominance Frontier Construction Scalar Evolution Analysis Loop Pass Manager Loop-Closed SSA Form Pass Delete dead loops -- Delete dead loops -- Loop-Closed SSA Form Pass -- Dominance Frontier Construction Dominance Frontier Construction Loop Pass Manager -- Dominance Frontier Construction -- Scalar Evolution Analysis -- Dominator Tree Construction -- Canonicalize natural loops -- Natural Loop Construction Unable to schedule 'Loop-Closed SSA Form Pass' required by 'Index Split Loops' opt: PassManager.cpp:990: virtual void llvm::PMDataManager::addLowerLevelRequiredPass(llvm::Pass*, llvm::Pass*): Assertion `0 && "Unable to schedule pass"' failed. #0 0xffffe410 in __kernel_vsyscall () #1 0x49737c51 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0x49739619 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x49731031 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0x0863998e in llvm::PMDataManager::addLowerLevelRequiredPass ( this=0x87b77d0, P=0x87b7700, RequiredPass=0x87b7ae0) at PassManager.cpp:990 #5 0x0863cbb0 in llvm::PMDataManager::add (this=0x87b77d0, P=0x87b7700, ProcessAnalysis=true) at PassManager.cpp:800 #6 0x08563277 in llvm::LoopPass::assignPassManager (this=0x87b7700, PMS=@0x87b7478, PreferredType=llvm::PMT_Unknown) at LoopPass.cpp:325 #7 0x08646e6a in llvm::PassManagerImpl::addTopLevelPass (this=0x87b7408, P=0x87b7700) at PassManager.cpp:304 #8 0x0863a2d0 in llvm::PMTopLevelManager::schedulePass (this=0x87b7474, P=0x87b7700) at PassManager.cpp:462 #9 0x08640e09 in llvm::PassManagerImpl::add (this=0x87b7408, P=0x87b7700) at PassManager.cpp:280 #10 0x0863a2fb in llvm::PassManager::add (this=0xffffd5a4, P=0x87b7700) at PassManager.cpp:1413 #11 0x08375fb4 in (anonymous namespace)::addPass (PM=@0xffffd5a4, P=0x87b7700) at opt.cpp:234 #12 0x083746c8 in main (argc=5, argv=0xffffd794) at opt.cpp:404 Note that both loop deletion and loop index splitting require and preserve lcssa. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 5 15:00:33 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 15:00:33 -0500 Subject: [LLVMbugs] [Bug 2641] New: bugpoint could trap function parameters Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2641 Summary: bugpoint could trap function parameters Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: bugpoint AssignedTo: unassignedbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu When analyzing a miscompile, Bugpoint could try instrumenting the function to keep track of the arguments received before running the rest of the function. Alternately, it could do this at the call site. It should then use that info to construct a simpler testcase than the usual "bugpoint-tooptimize.bc" which is the entire other half of the program. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 5 16:09:43 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 16:09:43 -0500 Subject: [LLVMbugs] [Bug 2642] New: Constant floating-point vector multiplies don't fold Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2642 Summary: Constant floating-point vector multiplies don't fold Product: new-bugs Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: nicolas at capens.net CC: llvmbugs at cs.uiuc.edu The following LLVM IR generates x86 code with two separate vector multiplies instead of one: external global <4 x float>, align 16 ; <<4 x float>*>:0 [#uses=1] external global <4 x float>, align 16 ; <<4 x float>*>:1 [#uses=1] define internal void @""() { load <4 x float>* @0, align 16 ; <<4 x float>>:1 [#uses=1] mul <4 x float> %1, < float 2.000000e+000, float 2.000000e+000, float 2.000000e+000, float 2.000000e+000 > ; <<4 x float>>:2 [#uses=1] mul <4 x float> %2, < float 3.000000e+000, float 3.000000e+000, float 3.000000e+000, float 3.000000e+000 > ; <<4 x float>>:3 [#uses=1] store <4 x float> %3, <4 x float>* @1, align 16 ret void } Replacing the vectors with scalars does result in a single multiply by 6.0. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Aug 5 16:34:36 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 16:34:36 -0500 Subject: [LLVMbugs] [Bug 2643] New: bitfield initialization triggers assertion Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2643 Summary: bitfield initialization triggers assertion Product: clang Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: LLVM Codegen AssignedTo: unassignedbugs at nondot.org ReportedBy: nunoplopes at sapo.pt CC: llvmbugs at cs.uiuc.edu The following code triggers an assertion in clang (with --emit-llvm): typedef struct _phar_entry_info { int is_modified:1; int is_deleted:1; } phar_entry_info; void phar_mount_entry() { phar_entry_info entry = {0}; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Aug 5 16:52:26 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 16:52:26 -0500 Subject: [LLVMbugs] [Bug 2596] valgrind error in VirtRegMap.cpp In-Reply-To: Message-ID: <200808052152.m75LqQe9026295@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2596 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Evan Cheng 2008-08-05 16:52:23 --- Fixed. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080804/065700.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Aug 5 17:06:38 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 17:06:38 -0500 Subject: [LLVMbugs] [Bug 2625] Code snippet fails during code generation. In-Reply-To: Message-ID: <200808052206.m75M6c50026871@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2625 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Dan Gohman 2008-08-05 17:06:37 --- Fixed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080804/065649.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Aug 5 17:07:02 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 17:07:02 -0500 Subject: [LLVMbugs] [Bug 2623] Assertion failure calling function with struct-typed phi value In-Reply-To: Message-ID: <200808052207.m75M72Zg026900@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2623 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Dan Gohman 2008-08-05 17:07:02 --- Fixed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080804/065650.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Aug 5 17:19:50 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 17:19:50 -0500 Subject: [LLVMbugs] [Bug 2620] Cannot yet select error from the x86 backend In-Reply-To: Message-ID: <200808052219.m75MJoFd027432@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2620 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Evan Cheng 2008-08-05 17:19:49 --- Fixed. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080804/065701.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Aug 5 18:54:13 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 5 Aug 2008 18:54:13 -0500 Subject: [LLVMbugs] [Bug 2644] New: miscompile with -loop-rotate -indvars Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2644 Summary: miscompile with -loop-rotate -indvars Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Loop Optimizer AssignedTo: unassignedbugs at nondot.org ReportedBy: nlewycky at google.com CC: dpatel at apple.com, llvmbugs at cs.uiuc.edu Created an attachment (id=1896) --> (http://llvm.org/bugs/attachment.cgi?id=1896) testcase; the part that gets miscompiled I have a miscompile: $ opt -loop-rotate -indvars c.bc | llc -f -o x2.s nlewycky at ducttape:~/local$ gcc x.s x2.s -o x -lm nlewycky at ducttape:~/local$ ./x Hilbert Slice. Test case 1 of size 120. One-Norm(A) ---------- 1.833333e+00. Segmentation fault Without the 'opt' phase, the program runs correctly. This is a bugpoint reduction of sgefa. I should mention that opt -loop-rotate | opt -indvars appears to produce different output (it's hard to spot amongst the variable renamings, but it looks like a GEP is missing or in a different spot). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 6 00:33:55 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 6 Aug 2008 00:33:55 -0500 Subject: [LLVMbugs] [Bug 2643] bitfield initialization triggers assertion In-Reply-To: Message-ID: <200808060533.m765XtqU008614@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2643 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #1 from Daniel Dunbar 2008-08-06 00:33:54 --- Fixed: http://llvm.org/viewvc/llvm-project?view=rev&revision=54397 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?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 Aug 6 02:36:16 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 6 Aug 2008 02:36:16 -0500 Subject: [LLVMbugs] [Bug 2638] Missing optimization (fold of ashr and sext) In-Reply-To: Message-ID: <200808060736.m767aGoq013103@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2638 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2008-08-06 02:36:16 --- Implemented: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080804/065725.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 Aug 6 08:07:07 2008 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 6 Aug 2008 08:07:07 -0500 Subject: [LLVMbugs] [Bug 2645] New: Vector splat within loop not optimized Message-ID: http://llvm.org/bugs/show_bug.cgi?id=2645 Summary: Vector splat within loop not optimized Product: new-bugs Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: enhancement Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: nicolas at capens.net CC: llvmbugs at cs.uiuc.edu The following LLVM IR does not generate optimal x86 code for the vector splat: define internal void @""(i8*) { ;