From bugzilla-daemon at cs.uiuc.edu Tue Dec 1 00:05:04 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 1 Dec 2009 00:05:04 -0600 Subject: [LLVMbugs] [Bug 5640] run away jump threading In-Reply-To: Message-ID: <200912010605.nB1654mW015676@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5640 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Chris Lattner 2009-12-01 00:05:03 --- Awesome, that repros. Fixed in r90211, 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 Tue Dec 1 07:38:32 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 1 Dec 2009 07:38:32 -0600 Subject: [LLVMbugs] [Bug 5657] New: Cygwin build fails due to missing library Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5657 Summary: Cygwin build fails due to missing library Product: Build scripts Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Makefiles AssignedTo: unassignedbugs at nondot.org ReportedBy: julien.etienne at gmail.com CC: llvmbugs at cs.uiuc.edu Hello, Using an up to date cygwin installation (updated the 01/12/2009), I am getting the following build error: ld: warning: cannot find entry symbol __cygwin_dll_entry at 12; defaulting to 63cc1000 Step to reproduce: 1- Get an up to date cygwin 2- Check out the llvm trunk (current rev is 90219) 3- Create the build directory: "mkdir build-cygwin" 4- Go in this directory and configure: "cd build-cygwin && ../configure" 5- Launch the build: "make -j3" The build fails with the following message: make[1]: Entering directory `/cygdrive/d/Documents/src/llvm-svn/build-cygwin/runtime' make[2]: Entering directory `/cygdrive/d/Documents/src/llvm-svn/build-cygwin/runtime/libprofile' llvm[2]: Compiling BasicBlockTracing.c for Debug build (PIC) llvm[2]: Compiling BlockProfiling.c for Debug build (PIC) llvm[2]: Compiling CommonProfiling.c for Debug build (PIC) llvm[2]: Compiling EdgeProfiling.c for Debug build (PIC) llvm[2]: Compiling FunctionProfiling.c for Debug build (PIC) llvm[2]: Compiling OptimalEdgeProfiling.c for Debug build (PIC) llvm[2]: Linking Debug Loadable Module profile_rt.dll /usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld: warning: cannot find entry symbol __cygwin_dll_entry at 12; defaulting to 63cc1000 /cygdrive/d/Documents/src/llvm-svn/build-cygwin/runtime/libprofile/Debug/BasicBlockTracing.o: In function `BBTraceAtExitHandler': /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/BasicBlockTracing.c:35: undefined reference to `_free' /cygdrive/d/Documents/src/llvm-svn/build-cygwin/runtime/libprofile/Debug/BasicBlockTracing.o: In function `llvm_start_basic_block_tracing': /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/BasicBlockTracing.c:59: undefined reference to `_malloc' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/BasicBlockTracing.c:64: undefined reference to `_atexit' /cygdrive/d/Documents/src/llvm-svn/build-cygwin/runtime/libprofile/Debug/BlockProfiling.o: In function `llvm_start_block_profiling': /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/BlockProfiling.c:43: undefined reference to `_atexit' /cygdrive/d/Documents/src/llvm-svn/build-cygwin/runtime/libprofile/Debug/CommonProfiling.o: In function `save_arguments': /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:44: undefined reference to `_memmove' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:47: undefined reference to `_strcmp' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:49: undefined reference to `_puts' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:51: undefined reference to `_strdup' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:52: undefined reference to `_memmove' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:56: undefined reference to `_printf' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:39: undefined reference to `_strncmp' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:61: undefined reference to `_strlen' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:63: undefined reference to `_malloc' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:65: undefined reference to `_strlen' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:66: undefined reference to `_memcpy' /cygdrive/d/Documents/src/llvm-svn/build-cygwin/runtime/libprofile/Debug/CommonProfiling.o: In function `write_profiling_data': /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:91: undefined reference to `_open' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:93: undefined reference to `_fprintf' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:95: undefined reference to `_perror' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:103: undefined reference to `_write' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:104: undefined reference to `_write' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:105: undefined reference to `_write' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:108: undefined reference to `_write' /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:114: undefined reference to `_write' /cygdrive/d/Documents/src/llvm-svn/build-cygwin/runtime/libprofile/Debug/CommonProfiling.o:/cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/CommonProfiling.c:115: more undefined references to `_write' follow /cygdrive/d/Documents/src/llvm-svn/build-cygwin/runtime/libprofile/Debug/EdgeProfiling.o: In function `llvm_start_edge_profiling': /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/EdgeProfiling.c:43: undefined reference to `_atexit' /cygdrive/d/Documents/src/llvm-svn/build-cygwin/runtime/libprofile/Debug/FunctionProfiling.o: In function `llvm_start_func_profiling': /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/FunctionProfiling.c:40: undefined reference to `_atexit' /cygdrive/d/Documents/src/llvm-svn/build-cygwin/runtime/libprofile/Debug/OptimalEdgeProfiling.o: In function `llvm_start_opt_edge_profiling': /cygdrive/d/Documents/src/llvm-svn/runtime/libprofile/OptimalEdgeProfiling.c:43: undefined reference to `_atexit' collect2: ld returned 1 exit status make[2]: *** [/cygdrive/d/Documents/src/llvm-svn/build-cygwin/Debug/lib/profile_rt.dll] Error 1 make[2]: Leaving directory `/cygdrive/d/Documents/src/llvm-svn/build-cygwin/runtime/libprofile' make[1]: *** [libprofile/.makeall] Error 2 make[1]: Leaving directory `/cygdrive/d/Documents/src/llvm-svn/build-cygwin/runtime' make: *** [all] Error 1 Looking at the error and the link command line shows that the "-nostdlib" option is triggering the issue. I am not sure at which level this setting must be changed but the following patch (cygwin specific) did work for me and fixed the issue: svn diff Makefile.rules Index: Makefile.rules =================================================================== --- Makefile.rules (revision 90219) +++ Makefile.rules (working copy) @@ -554,7 +554,7 @@ endif else ifeq ($(HOST_OS),Cygwin) - SharedLinkOptions=-shared -nostdlib -Wl,--export-all-symbols \ + SharedLinkOptions=-shared -Wl,--export-all-symbols \ -Wl,--enable-auto-import -Wl,--enable-auto-image-base else SharedLinkOptions=-shared I now have llvm install under cygwin and for the moment I experienced no issue. Best Regards, Julien -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 1 11:48:55 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 1 Dec 2009 11:48:55 -0600 Subject: [LLVMbugs] [Bug 5659] New: Assertion failed: (cast(C->getType())-> getElementType() == Ty && "Computed GetElementPtr has unexpected type!"), function SymbolicallyEvaluateGEP, file ConstantFolding.cpp, line 609. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5659 Summary: Assertion failed: (cast(C->getType())- >getElementType() == Ty && "Computed GetElementPtr has unexpected type!"), function SymbolicallyEvaluateGEP, file ConstantFolding.cpp, line 609. Product: libraries Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: Interprocedural Analyses AssignedTo: unassignedbugs at nondot.org ReportedBy: rdivacky at freebsd.org CC: llvmbugs at cs.uiuc.edu witten ~# cat 003.cpp struct font_params { int x_height; }; typedef int font_params::*param_t; static struct { const char *name; param_t par; } param_table[] = { { "x-height", &font_params::x_height }, }; int main(int argc, char **argv) { } witten ~# clang++ --version #llvm of the same revision clang version 1.1 (trunk 90031) Target: i386-unknown-freebsd9.0 Thread model: posix witten ~# clang++ -O2 003.cpp Assertion failed: (cast(C->getType())->getElementType() == Ty && "Computed GetElementPtr has unexpected type!"), function SymbolicallyEvaluateGEP, file ConstantFolding.cpp, line 609. Stack dump: 0. Program arguments: /usr/local/bin/../libexec/clang-cc -triple i386-unknown-freebsd9.0 -S -disable-free -main-file-name 003.cpp -relocation-model static -disable-fp-elim -unwind-tables=0 -mcpu pentium4 -O2 -fmessage-length 152 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-ztELyX.s -x c++ 003.cpp 1. parser at end of file 2. Per-function optimization 3. Running pass 'Combine redundant instructions' on function '@__cxx_global_initialization' clang: error: compiler command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 1 12:56:39 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 1 Dec 2009 12:56:39 -0600 Subject: [LLVMbugs] [Bug 5651] Source-level debugging information causes bad label names In-Reply-To: Message-ID: <200912011856.nB1IudQv024879@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5651 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Devang Patel 2009-12-01 12:56:39 --- Fixed. r90247 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 1 15:47:47 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 1 Dec 2009 15:47:47 -0600 Subject: [LLVMbugs] [Bug 5662] New: source manager include stack isn't correct when using PCH Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5662 Summary: source manager include stack isn't correct when using PCH Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: AST AssignedTo: unassignedclangbugs at nondot.org ReportedBy: daniel at zuster.org CC: kremenek at apple.com, llvmbugs at cs.uiuc.edu, dgregor at apple.com When using implicit PCH includes, the source manager include stack isn't correct. This means diagnostics come out incorrectly, and breaks some assumptions in the indexer. Test case in clang/test/PCH/source-manager-stack.h. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 1 16:26:12 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 1 Dec 2009 16:26:12 -0600 Subject: [LLVMbugs] [Bug 5391] assertion triggered in LiveIntervalAnalysis In-Reply-To: Message-ID: <200912012226.nB1MQCx2032761@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5391 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Evan Cheng 2009-12-01 16:26:11 --- Fixed. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091130/092049.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 1 18:37:35 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 1 Dec 2009 18:37:35 -0600 Subject: [LLVMbugs] [Bug 5663] New: Lazy bitcode loading interacts badly with global opts Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5663 Summary: Lazy bitcode loading interacts badly with global opts Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Core LLVM classes AssignedTo: unassignedbugs at nondot.org ReportedBy: jyasskin at google.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=3904) --> (http://llvm.org/bugs/attachment.cgi?id=3904) C++ program demonstrating bad behavior $ g++ `llvm-config --cxxflags --ldflags --libs` modprovider_crash.cpp -o modprovider_crash -Wall -g $ llvm-as modprovider_crash.ll $ ./modprovider_crash modprovider_crash.bc LLVM ERROR: Error reading bitcode file: Invalid LOAD record $ At ToT, globaldce deletes functions with ghost linkage, which forgets the fact that the BitcodeReader can materialize them from the backing file. With the attached patch, we get the above problem instead, where globaldce doesn't realize that @globl has a user hidden away in the bitcode file. Globaldce then deletes @globl which causes ModuleProvider::materializeFunction to fail. deadargelim is likely to have a similar problem when it thinks it can eliminate an argument to a function but can't update callers hidden in the 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 Tue Dec 1 21:42:17 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 1 Dec 2009 21:42:17 -0600 Subject: [LLVMbugs] [Bug 5664] New: DISABLE_INLINE build fix Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5664 Summary: DISABLE_INLINE build fix Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: alp at nuanti.com CC: llvmbugs at cs.uiuc.edu DISABLE_INLINE needs to be before the declaration when building with MSVC. Error 1 error C2144: syntax error : 'int' should be preceded by ';' c:\Documents and Settings\alp\My Documents\Visual Studio 2008\Projects\llvm\lib\Target\ARM\ARMBaseInstrInfo.cpp 423 Fix (only tested on MSVC): --- a/lib/Target/ARM/ARMBaseInstrInfo.cpp +++ b/lib/Target/ARM/ARMBaseInstrInfo.cpp @@ -419,8 +419,9 @@ bool ARMBaseInstrInfo::isPredicable(MachineInstr *MI) const { } /// FIXME: Works around a gcc miscompilation with -fstrict-aliasing +DISABLE_INLINE static unsigned getNumJTEntries(const std::vector &JT, - unsigned JTI) DISABLE_INLINE; + unsigned JTI); static unsigned getNumJTEntries(const std::vector &JT, unsigned JTI) { return JT[JTI].MBBs.size(); -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 2 00:25:44 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 2 Dec 2009 00:25:44 -0600 Subject: [LLVMbugs] [Bug 5663] Lazy bitcode loading interacts badly with global opts In-Reply-To: Message-ID: <200912020625.nB26Pirt015756@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5663 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Chris Lattner 2009-12-02 00:25:44 --- This is "behaves correctly", as we discussed on IRC, it would be better to use a custom pass that is specific to your environment. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 2 12:27:46 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 2 Dec 2009 12:27:46 -0600 Subject: [LLVMbugs] [Bug 5668] New: thumb2 folding of constant addresses unhelpful Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5668 Summary: thumb2 folding of constant addresses unhelpful Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: bagel99 at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=3907) --> (http://llvm.org/bugs/attachment.cgi?id=3907) test case When addresses are a displacement from a constant (this can happen in device drivers), the resulting address gets folded rather than using base+displacement addressing. This results in code bloat. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 2 12:30:10 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 2 Dec 2009 12:30:10 -0600 Subject: [LLVMbugs] [Bug 5669] New: MSP430 as backend component Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5669 Summary: MSP430 as backend component Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: bagel99 at gmail.com CC: llvmbugs at cs.uiuc.edu A "Backend: MSP430" does not show up in the component 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 Wed Dec 2 12:52:56 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 2 Dec 2009 12:52:56 -0600 Subject: [LLVMbugs] [Bug 5669] MSP430 as backend component In-Reply-To: Message-ID: <200912021852.nB2IquOO025494@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5669 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2009-12-02 12:52:56 --- Added to bugzilla. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 2 16:15:40 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 2 Dec 2009 16:15:40 -0600 Subject: [LLVMbugs] [Bug 5670] New: Unknown type Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5670 Summary: Unknown type 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: cyrildupuit at hotmail.com CC: llvmbugs at cs.uiuc.edu Hello, I am new to clang and I have tried to compile a simple application to test the analysis functionnality of this compiler. I have built the compiler as specified in http://clang.llvm.org/get_started.html without any problem. After that, I have tried to compile a simple example to verify that the compiler works fine on my machine. This is the file (file.c) : #include int main(void) { int * p; p = malloc(100); if(p == (void *)0) free(p); p[0] = 10; return p[101]; } The command line is as follow : clang-cc -DWIN32 -D_DEBUG -D_CONSOLE file.c -analyze The result of the execution is : In file included from file.c:1: In file included from C:\Program Files\Microsoft Visual Studio 9.0\VC\include/st dlib.h:23: C:\Program Files\Microsoft Visual Studio 9.0\VC\include/crtdefs.h:562:9: error: unknown type name '__int64' typedef __int64 __time64_t; /* 64-bit time value */ ^ In file included from file.c:1: C:\Program Files\Microsoft Visual Studio 9.0\VC\include/stdlib.h:384:9: error: u nknown type name '__int64' __int64 __cdecl _abs64(__int64); ^ The type __int64 is not known by the compiler. Is it possible to support this variable type ? I am very interresting to test the analysis functionnality of this compiler. Best regards, Cyril -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 2 18:10:14 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 2 Dec 2009 18:10:14 -0600 Subject: [LLVMbugs] [Bug 5670] Unknown type In-Reply-To: Message-ID: <200912030010.nB30AEbZ004883@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5670 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2009-12-02 18:10:14 --- clang-cc is an internal interface in the compiler, please use 'clang' which passes a bunch of options to clang-cc. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 2 18:56:01 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 2 Dec 2009 18:56:01 -0600 Subject: [LLVMbugs] [Bug 5673] New: Assertion in instcombine Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5673 Summary: Assertion in instcombine Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: clattner at apple.com, llvmbugs at cs.uiuc.edu Created an attachment (id=3908) --> (http://llvm.org/bugs/attachment.cgi?id=3908) Testcase $ ./opt -instcombine test.ll -disable-output yields: opt: /home/asl/proj/llvm/src_arm/lib/Target/TargetData.cpp:546: unsigned char llvm::TargetData::getAlignment(const llvm::Type*, bool) const: Assertion `Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"' failed. testcase is attached. This prevents newlib 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 Wed Dec 2 19:05:58 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 2 Dec 2009 19:05:58 -0600 Subject: [LLVMbugs] [Bug 5673] Assertion in instcombine In-Reply-To: Message-ID: <200912030105.nB315wxF007451@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5673 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2009-12-02 19:05:57 --- Fixed in r90369 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 3 00:58:57 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 3 Dec 2009 00:58:57 -0600 Subject: [LLVMbugs] [Bug 5664] DISABLE_INLINE build fix In-Reply-To: Message-ID: <200912030658.nB36wvvw018982@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5664 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2009-12-03 00:58:56 --- Thanks, applied here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091130/092116.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 3 01:19:26 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 3 Dec 2009 01:19:26 -0600 Subject: [LLVMbugs] [Bug 5645] llvm fails to fold function to a constant when built with clang In-Reply-To: Message-ID: <200912030719.nB37JQKH019854@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5645 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Chris Lattner 2009-12-03 01:19:26 --- Eli fixed this: $ clang t.cc -S -o - -emit-llvm -O3 ... define i32 @_Z2f6v() nounwind ssp { if.then.i156: ret i32 1251552576 } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 3 02:15:06 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 3 Dec 2009 02:15:06 -0600 Subject: [LLVMbugs] [Bug 5675] New: llvm-c/Target.h can not compile with Visual Studio in C Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5675 Summary: llvm-c/Target.h can not compile with Visual Studio in C Product: libraries Version: 2.6 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Target-Independent JIT AssignedTo: unassignedbugs at nondot.org ReportedBy: baptiste.lepilleur at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=3909) --> (http://llvm.org/bugs/attachment.cgi?id=3909) Patch to remove inline keyword llvm-c/Target.h fails to compile with Visual Studio when compiling in C mode due to the usage of the inline keyword (C99 specific I think). I run into this while trying to compile llvm-py python extension. I solved this by removing the inline keyword. As the function are static this compile correctly. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 3 06:45:11 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 3 Dec 2009 06:45:11 -0600 Subject: [LLVMbugs] [Bug 5659] c++ member pointer codegen assert In-Reply-To: Message-ID: <200912031245.nB3CjBgY012697@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5659 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sharparrow1 at yahoo.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Eli Friedman 2009-12-03 06:45:11 --- clang codegen bug fixed in r90450. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 3 07:39:58 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 3 Dec 2009 07:39:58 -0600 Subject: [LLVMbugs] [Bug 2302] Incorrect optimization with recursive call to main In-Reply-To: Message-ID: <200912031339.nB3Ddwc9014673@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2302 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |benny.kra at gmail.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Benjamin Kramer 2009-12-03 07:39:58 --- Chris fixed this in r80887. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 3 18:58:19 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 3 Dec 2009 18:58:19 -0600 Subject: [LLVMbugs] [Bug 5680] New: bitcode files do not preserve order of use lists Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5680 Summary: bitcode files do not preserve order of use lists Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Bitcode Writer AssignedTo: unassignedbugs at nondot.org ReportedBy: bob.wilson at apple.com CC: llvmbugs at cs.uiuc.edu The order of entries in use lists is deterministic but that order is not preserved in bitcode files. Serializing/deserializing the IR to a bitcode file in between passes may change the behavior of those passes if they depend on the order of use lists. This is a problem for bugpoint and for manual debugging as well. I ran into this while trying to track down a performance problem in llvm-gcc. Writing a bitcode file and running llc produced slightly different results that prevented me from reproducing the performance issues. I tracked this down to CodeGenPrepare splitting critical edges by iterating over the basic block predecessor list and selecting the first suitable edge to split. The order of predecessors was different in llc than in llvm-gcc, which caused a different edge to be split. The problem applies to all use lists, not just basic block predecessors. It would be good to add information to the bitcode files to preserve the use list order, at least as an option for debugging. It would also be good to have a way to keep that same information in llvm assembly files so that disassembling a bitcode file preserves the information. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 4 00:30:29 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 4 Dec 2009 00:30:29 -0600 Subject: [LLVMbugs] [Bug 5551] Bug in ipsccp with different results depending of architecture ( 16b/32b/little or big endian) In-Reply-To: Message-ID: <200912040630.nB46UTcZ017677@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5551 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Chris Lattner 2009-12-04 00:30:29 --- Nice catch! Fixed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091130/092166.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 4 01:07:00 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 4 Dec 2009 01:07:00 -0600 Subject: [LLVMbugs] [Bug 5617] Inconsistency when reporting macro location In-Reply-To: Message-ID: <200912040707.nB4770L0019333@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5617 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Chris Lattner 2009-12-04 01:06:59 --- A preprocessor-only example is: $ cat t.c #if CL #endif $ clang-cc "-DCL=?" -Eonly t.c Fixed here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091130/024888.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 4 15:28:15 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 4 Dec 2009 15:28:15 -0600 Subject: [LLVMbugs] [Bug 5687] New: Kaleidoscope tutorial code doesn't build with OCaml 3.11.1 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5687 Summary: Kaleidoscope tutorial code doesn't build with OCaml 3.11.1 Product: new-bugs Version: 2.6 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: g36130 at gmail.com CC: llvmbugs at cs.uiuc.edu The code included in the docs (http://llvm.org/docs/tutorial/OCamlLangImpl7.html) doesn't build for OCaml 3.11.1 and LLVM 2.6. I could easily fix the issue by redefining the functions below. Maybe the bindings have been modified recently? let double_type= Llvm.double_type context let append_block= Llvm.append_block context I wanted to provide a patch but couldn't find the files in SVN. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 4 16:51:29 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 4 Dec 2009 16:51:29 -0600 Subject: [LLVMbugs] [Bug 4262] llvm-gcc should generate available_externally function bodies etc In-Reply-To: Message-ID: <200912042251.nB4MpTke003754@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=4262 Bill Wendling changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #6 from Bill Wendling 2009-12-04 16:51:27 --- Unfortunately, I had to revert this patch: http://llvm.org/viewvc/llvm-project?rev=90612&view=rev See this discussion for why: http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-December/027646.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Dec 5 02:27:49 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 5 Dec 2009 02:27:49 -0600 Subject: [LLVMbugs] [Bug 5692] New: clang rejects invalid code with wrong diagnostic Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5692 Summary: clang rejects invalid code with wrong diagnostic Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Keywords: quality-of-implementation Severity: normal Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu This invalid code (u is not defined): void foo() { (union u)4; } is rejected with: t.c:3:3: error: cast to union type from type 'int' not present in union (union u)4; ^ ~ The diagnostic should say that 'u' is not complete. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Dec 5 16:11:04 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 5 Dec 2009 16:11:04 -0600 Subject: [LLVMbugs] [Bug 5694] New: ARM backend miscompiles a <= (0 - b) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5694 Summary: ARM backend miscompiles a <= (0 - b) Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: vargaz at gmail.com CC: llvmbugs at cs.uiuc.edu The ARM backend seems to miscompile the attached testcase. Expected result: Hello, World: 0 Actual result on X86: Hello, World: 0 Actual result on ARM: Hello, World: 1 Compiled using: llc -march=arm bug.ll I think the problem is that it generates the following code: cmn r0, r1 movls r2, #1 but the cmn instruction sets the condition flags differently than the cmp instruction. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Dec 6 01:29:02 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 6 Dec 2009 01:29:02 -0600 Subject: [LLVMbugs] [Bug 5698] New: odd performance bug Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5698 Summary: odd performance bug Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu The innocent-looking function below takes many minutes to compile at -Os using either llvm-gcc and clang. I can't repro using llc since it seems to lack an Os flag and doesn't exhibit the behavior at -O[0123]. I'm using r90568. typedef unsigned char uint8_t; typedef uint8_t error_t; void DelugeMetadataP__BlockWrite__eraseDone (uint8_t imgNum, error_t error); void DelugeMetadataP__nextImage (void); uint8_t DelugeMetadataP__state; uint8_t DelugeMetadataP__currentImageIdx; void DelugeMetadataP__nextImage (void); void DelugeMetadataP__BlockWrite__eraseDone (uint8_t imgNum, error_t error) { { switch ((int) DelugeMetadataP__state) { case 3:; switch ((int) DelugeMetadataP__state) { case 3:; DelugeMetadataP__BlockWrite__eraseDone (imgNum, error); break; case 2:; DelugeMetadataP__currentImageIdx = (uint8_t) ((int) DelugeMetadataP__currentImageIdx + 1); DelugeMetadataP__nextImage (); break; } break; case 2:; DelugeMetadataP__currentImageIdx = (uint8_t) ((int) DelugeMetadataP__currentImageIdx + 1); DelugeMetadataP__nextImage (); break; } return; } } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Dec 6 02:46:32 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 6 Dec 2009 02:46:32 -0600 Subject: [LLVMbugs] [Bug 5699] New: -dM doesn't work properly for variadic macros Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5699 Summary: -dM doesn't work properly for variadic macros Product: clang Version: unspecified Platform: PC OS/Version: NetBSD Status: NEW Severity: normal Priority: P2 Component: preprocessor AssignedTo: unassignedclangbugs at nondot.org ReportedBy: neil at daikokuya.co.uk CC: llvmbugs at cs.uiuc.edu #define h(...) __VA_ARGS__ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Dec 6 04:00:42 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 6 Dec 2009 04:00:42 -0600 Subject: [LLVMbugs] [Bug 5318] diff crashes when used in a Clang test In-Reply-To: Message-ID: <200912061000.nB6A0gX9008544@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5318 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel at zuster.org Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Daniel Dunbar 2009-12-06 04:00:42 --- This isn't a clang 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 Dec 6 11:18:49 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 6 Dec 2009 11:18:49 -0600 Subject: [LLVMbugs] [Bug 5698] Jump-threading taking a long time In-Reply-To: Message-ID: <200912061718.nB6HInex012118@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5698 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2009-12-06 11:18:48 --- Fixed, thanks again, http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091130/092264.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 Dec 6 15:24:08 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 6 Dec 2009 15:24:08 -0600 Subject: [LLVMbugs] [Bug 5701] New: assertion failed when tried to generate XML Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5701 Summary: assertion failed when tried to generate XML Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: AST AssignedTo: unassignedclangbugs at nondot.org ReportedBy: yozh at mx1.ru CC: llvmbugs at cs.uiuc.edu === # cat ~/hello.cpp #include using namespace std; int main() { std::cout << "hello" << std::endl; return 0; } # ./clang-cc -ast-print-xml ~/hello.cpp Assertion failed: (NodeStack.size() > 1 && "too much backtracking"), function toParent, file DocumentXML.cpp, line 51. Stack dump: 0. Program arguments: ./clang-cc -ast-print-xml /home/nga/hello.cpp 1. parser at end of file zsh: abort ./clang-cc -ast-print-xml ~/hello.cpp === Used trunk, r90717. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Dec 6 19:59:03 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 6 Dec 2009 19:59:03 -0600 Subject: [LLVMbugs] [Bug 5699] -dM doesn't work properly for variadic macros In-Reply-To: Message-ID: <200912070159.nB71x3rI030086@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5699 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2009-12-06 19:59:02 --- Nice catch, we were also getting gnu-style variadic macros wrong. Fixed here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091130/025020.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 Dec 6 20:33:45 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 6 Dec 2009 20:33:45 -0600 Subject: [LLVMbugs] [Bug 5703] New: Assertion in LiveIntervals Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5703 Summary: Assertion in LiveIntervals Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Created an attachment (id=3916) --> (http://llvm.org/bugs/attachment.cgi?id=3916) Testcase Consider the code attached. Running LLC yields an assertion: $ ./llc intr.ll llc: /home/asl/proj/llvm/src/include/llvm/CodeGen/LiveIntervalAnalysis.h:87: llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int): Assertion `I != r2iMap_.end() && "Interval does not exist for register"' 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 Mon Dec 7 06:56:39 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 7 Dec 2009 06:56:39 -0600 Subject: [LLVMbugs] [Bug 2193] compiling X86ISelDAGToDAG.cpp with llvm-g++ -O3 exhausts memory In-Reply-To: Message-ID: <200912071256.nB7Cud8G002155@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2193 T??r??k Edwin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #26 from T??r??k Edwin 2009-12-07 06:56:38 --- (In reply to comment #25) > I have a suspicion this bug was fixed with r72411 and r72426. Could someone > please reverify this bug or close it? > Yes, it can now be compiled within 1G of memory, however VERY slowly (~2m30s, vs 44s with gcc 4.3). Interestingly opt -O2 is taking a lot of time too, not only llc! I'll open another bug about that, this one is 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 Dec 7 07:06:29 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 7 Dec 2009 07:06:29 -0600 Subject: [LLVMbugs] [Bug 5708] New: X86ISelDAGToDAG.ii is very to slow compile with llvm-g++ Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5708 Summary: X86ISelDAGToDAG.ii is very to slow compile with llvm-g++ 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 With llvm-g++ r90759 it takes ~2m30s to compile X86ISelDAGToDag at -O2, the same file compiled with gcc 4.3.4 takes 44s (on an Intel Core 2 Quad Q9550 @2.83Ghz) opt -O2 takes 57s (most time spent in inlining, dse and gvn), llc takes 1m45s (most time spent in register coalescer). ===-------------------------------------------------------------------------=== ... Pass execution timing report ... ===-------------------------------------------------------------------------=== Total Execution Time: 56.7436 seconds (56.8448 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 21.1693 ( 37.4%) 0.0200 ( 14.7%) 21.1893 ( 37.3%) 21.1669 ( 37.2%) Function Integration/Inlining 16.5410 ( 29.2%) 0.0040 ( 2.9%) 16.5450 ( 29.2%) 16.5990 ( 29.2%) Dead Store Elimination 13.4608 ( 23.8%) 0.0120 ( 8.8%) 13.4728 ( 23.7%) 13.4672 ( 23.7%) Global Value Numbering 0.9241 ( 1.6%) 0.0040 ( 2.9%) 0.9281 ( 1.6%) 0.9382 ( 1.7%) Combine redundant instructions 0.6240 ( 1.1%) 0.0000 ( 0.0%) 0.6240 ( 1.1%) 0.6235 ( 1.1%) Combine redundant instructions .... 56.6075 (100.0%) 0.1360 (100.0%) 56.7436 (100.0%) 56.8448 (100.0%) TOTAL ===-------------------------------------------------------------------------=== Instruction Selection and Scheduling ===-------------------------------------------------------------------------=== Total Execution Time: 3.0202 seconds (3.1079 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 0.5160 ( 17.8%) 0.0040 ( 3.1%) 0.5200 ( 17.2%) 0.4981 ( 16.0%) DAG Legalization 0.4440 ( 15.4%) 0.0040 ( 3.1%) 0.4480 ( 14.8%) 0.4875 ( 15.7%) Instruction Selection 0.3760 ( 13.0%) 0.0200 ( 15.6%) 0.3960 ( 13.1%) 0.4228 ( 13.6%) Type Legalization 0.3760 ( 13.0%) 0.0280 ( 21.9%) 0.4040 ( 13.4%) 0.4164 ( 13.4%) Instruction Scheduling 0.3880 ( 13.4%) 0.0200 ( 15.6%) 0.4080 ( 13.5%) 0.4152 ( 13.4%) Instruction Creation 0.2400 ( 8.3%) 0.0080 ( 6.2%) 0.2480 ( 8.2%) 0.2538 ( 8.2%) DAG Combining 1 0.2000 ( 6.9%) 0.0080 ( 6.2%) 0.2080 ( 6.9%) 0.2172 ( 7.0%) Vector Legalization 0.1480 ( 5.1%) 0.0040 ( 3.1%) 0.1520 ( 5.0%) 0.1797 ( 5.8%) DAG Combining after legalize types 0.1600 ( 5.5%) 0.0240 ( 18.7%) 0.1840 ( 6.1%) 0.1632 ( 5.3%) DAG Combining 2 0.0440 ( 1.5%) 0.0080 ( 6.2%) 0.0520 ( 1.7%) 0.0540 ( 1.7%) Instruction Scheduling Cleanup 2.8922 (100.0%) 0.1280 (100.0%) 3.0202 (100.0%) 3.1079 (100.0%) TOTAL ===-------------------------------------------------------------------------=== ... Pass execution timing report ... ===-------------------------------------------------------------------------=== Total Execution Time: 104.5785 seconds (104.6539 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 93.9219 ( 90.3%) 0.1840 ( 32.2%) 94.1059 ( 90.0%) 94.1709 ( 90.0%) Simple Register Coalescing 4.1883 ( 4.0%) 0.2760 ( 48.3%) 4.4643 ( 4.3%) 4.4549 ( 4.3%) X86 DAG->DAG Instruction Selection 1.6761 ( 1.6%) 0.0080 ( 1.4%) 1.6841 ( 1.6%) 1.6592 ( 1.6%) Live Variable Analysis 0.9801 ( 0.9%) 0.0040 ( 0.7%) 0.9841 ( 0.9%) 1.0015 ( 1.0%) Linear Scan Register Allocator 0.9241 ( 0.9%) 0.0000 ( 0.0%) 0.9241 ( 0.9%) 0.9935 ( 0.9%) Post RA top-down list latency scheduler ...... 104.0065 (100.0%) 0.5720 (100.0%) 104.5785 (100.0%) 104.6539 (100.0%) TOTAL -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 7 07:14:06 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 7 Dec 2009 07:14:06 -0600 Subject: [LLVMbugs] [Bug 2915] [llvm2.4-prerelease] MultiSource/Benchmarks/MallocBench/gs/ gs JIT regression In-Reply-To: Message-ID: <200912071314.nB7DE65E002863@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2915 T??r??k Edwin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from T??r??k Edwin 2009-12-07 07:14:06 --- This was fixed (ulimit 300M). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 7 07:17:33 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 7 Dec 2009 07:17:33 -0600 Subject: [LLVMbugs] [Bug 4252] Compiling interp.i takes 54 seconds: 78% time spent in Simple Register Coalescing In-Reply-To: Message-ID: <200912071317.nB7DHXPJ003048@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=4252 T??r??k Edwin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from T??r??k Edwin 2009-12-07 07:17:32 --- (In reply to comment #4) > Is this still an issue? > No, this one is fixed. However the coalescer still has issues on other large files (see PR5708). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 7 07:22:05 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 7 Dec 2009 07:22:05 -0600 Subject: [LLVMbugs] [Bug 5246] llc: crash when debuginfo present In-Reply-To: Message-ID: <200912071322.nB7DM5Gw003322@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5246 T??r??k Edwin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from T??r??k Edwin 2009-12-07 07:22:05 --- No, it doesn't crash anymore. It does spend 8 seconds with llc -O0, but I think that is expected for a file of its size (this bitcode is an llvm-ld -disable-opt of the entire ClamAV application IIRC). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 7 12:30:29 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 7 Dec 2009 12:30:29 -0600 Subject: [LLVMbugs] [Bug 5274] clang: doesn't add noalias attribute for restrict qualifier In-Reply-To: Message-ID: <200912071830.nB7IUTFp014286@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5274 Nuno Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nunoplopes at sapo.pt Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Nuno Lopes 2009-12-07 12:30:29 --- fixed in r90778. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 7 13:50:36 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 7 Dec 2009 13:50:36 -0600 Subject: [LLVMbugs] [Bug 5709] New: "Attributes after last parameter!" error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5709 Summary: "Attributes after last parameter!" error Product: new-bugs Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: pawel.worach at gmail.com CC: llvmbugs at cs.uiuc.edu Blocks: 3696 Created an attachment (id=3918) --> (http://llvm.org/bugs/attachment.cgi?id=3918) mknodes.i # clang -v clang version 1.1 (trunk 90786) Target: x86_64-unknown-freebsd8.0 Thread model: posix # clang -c mknodes.i Attributes after last parameter! i32 (...)* @vfprintf Broken module found, compilation aborted! Stack dump: 0. Program arguments: /usr/opt/llvm/bin/../libexec/clang-cc -triple x86_64-unknown-freebsd8.0 -S -disable-free -main-file-name mknodes.i -mrelocation-model static -mdisable-fp-elim -munwind-tables -mcpu x86-64 -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-j0KBCJ.s -x cpp-output mknodes.i 1. parser at end of file 2. Per-function optimization r90772 seems to be 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 Tue Dec 8 07:36:52 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 8 Dec 2009 07:36:52 -0600 Subject: [LLVMbugs] [Bug 5713] New: llvm-gcc build broken on x86-64 linux due to crash in DwarfDebug:: computeSizeAndOffset Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5713 Summary: llvm-gcc build broken on x86-64 linux due to crash in DwarfDebug::computeSizeAndOffset 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: baldrick at free.fr CC: dpatel at apple.com, llvmbugs at cs.uiuc.edu Created an attachment (id=3920) --> (http://llvm.org/bugs/attachment.cgi?id=3920) testcase .ll $ llc guard.ll ... 3 llc 0x000000000122789e std::vector >::end() const + 16 4 llc 0x00000000012235e0 std::vector >::empty() const + 24 5 llc 0x000000000121d01e llvm::DwarfDebug::computeSizeAndOffset(llvm::DIE*, unsigned int, bool) + 66 6 llc 0x000000000121d1e0 llvm::DwarfDebug::computeSizeAndOffset(llvm::DIE*, unsigned int, bool) + 516 ... Testcase attached. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 8 09:01:50 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 8 Dec 2009 09:01:50 -0600 Subject: [LLVMbugs] [Bug 5713] llvm-gcc build broken on x86-64 linux due to crash in DwarfDebug ::computeSizeAndOffset In-Reply-To: Message-ID: <200912081501.nB8F1oOA009117@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5713 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Devang Patel 2009-12-08 09:01:49 --- Fixed. r90857. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 8 10:20:17 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 8 Dec 2009 10:20:17 -0600 Subject: [LLVMbugs] [Bug 5715] New: Fails to build from source on ia64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5715 Summary: Fails to build from source on ia64 Product: new-bugs Version: trunk Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: arthur.loiret at gmail.com CC: llvmbugs at cs.uiuc.edu Hello, LLVM fails to build on ia64: llvm[3]: Linking Release executable lli (without symbols) ia64-linux-gnu-g++ -I/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/include -I/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/tools/lli -I/build/buildd/llvm-snapshot-20091207/include -I/build/buildd/llvm-snapshot-20091207/tools/lli -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEBIAN_INFO='" (Debian 20091207-1)"' -O2 -fomit-frame-pointer -fno-exceptions -fPIC -Woverloaded-virtual -g -O2 -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -O2 -Wl,-R -Wl,/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/Release/bin -Wl,-export-dynamic -L/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/Release/lib -L/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/Release/lib -o /build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/Release/bin/lli /build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/tools/lli/Release/lli.o \ -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMBitReader -lLLVMInterpreter -lLLVMJIT -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMSupport -lLLVMSystem -L/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/Release/lib -lpthread -ldl -lm /build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/Release/lib/libLLVMJIT.a(JIT.o): In function `llvm::ExecutionEngine::InstallExceptionTableRegister(void (*)(void*))': /build/buildd/llvm-snapshot-20091207/include/llvm/ExecutionEngine/ExecutionEngine.h:385: undefined reference to `__register_frame' /build/buildd/llvm-snapshot-20091207/include/llvm/ExecutionEngine/ExecutionEngine.h:385: undefined reference to `__register_frame' collect2: ld returned 1 exit status Full build log: https://buildd.debian.org/fetch.cgi?pkg=llvm-snapshot&arch=ia64&ver=20091207-1&stamp=1260219896&file=log&as=raw Full report: https://buildd.debian.org/~luk/status/package.php?p=llvm-snapshot -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 8 11:27:23 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 8 Dec 2009 11:27:23 -0600 Subject: [LLVMbugs] [Bug 5717] New: thumb2 has divide instructions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5717 Summary: thumb2 has divide instructions Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: bagel99 at gmail.com CC: llvmbugs at cs.uiuc.edu The thumb2 instructions include unsigned and signed divide. Attached is a simple test routine. (I'll try and add a patch later, bugzilla appears to only allow one attachment). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 8 11:46:38 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 8 Dec 2009 11:46:38 -0600 Subject: [LLVMbugs] [Bug 5720] New: aliases with internal linkage don't work very well Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5720 Summary: aliases with internal linkage don't work very well 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: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Created an attachment (id=3924) --> (http://llvm.org/bugs/attachment.cgi?id=3924) fpcmp.ll If an alias A with internal linkage points to a symbol S with linkonce linkage, then if the linker throws away the copy of S it is pointing to then you can get a link-time error, of the sort "A referenced in section .text, defined in discarded section .B.section". What would be convenient is for this situation to behave exactly the same as you would get by replacing all uses of A by B everywhere. It is true that aliases with internal linkage are in some sense pointless - because you can just RAUW+delete them, and indeed GlobalOpt does this (probably the constant folder should fold them too). However there are also advantages to allowing them - for example the Internalize pass can produce them, and it looks like they are convenient for llvm-gcc (ok, dragonegg) in some circumstances - and you can't always rely on GlobalOpt or the constant folder being run. I suggest teaching codegen to use the aliasee B whenever the alias A has internal linkage, and not output aliases with internal linkage. This effectively results in RAUW A with B at codegen time. It also avoids requiring support from linkers etc for this odd sort of alias. As for the testcase, do: llc CommandLine.ll && llc fpcmp.ll && g++ -o fpcmp fpcmp.s CommandLine.s `llvm-config --libs` and observe how it fails to link: `llvm::cl::desc::desc(char const*)' referenced in section `.text' of /tmp/cc2rAgh5.o: defined in discarded section `.gnu.linkonce.t._ZN4llvm2cl4descC2EPKc' of /tmp/cc2rAgh5.o ... fpcmp attached here, will attach CommandLine.ll 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 Dec 8 11:57:33 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 8 Dec 2009 11:57:33 -0600 Subject: [LLVMbugs] [Bug 5721] New: test failure on test/CodeGen/Thumb2/large-stack.ll Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5721 Summary: test failure on test/CodeGen/Thumb2/large-stack.ll Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu FAIL: /home/nlewycky/llvm/test/CodeGen/Thumb2/large-stack.ll Failed with exit(1) at line 1 while running: llc < /home/nlewycky/llvm/test/CodeGen/Thumb2/large-stack.ll -march=thumb -mattr=+thumb2 | FileCheck /home/nlewycky/llvm/test/CodeGen/Thumb2/large-stack.ll /home/nlewycky/llvm/test/CodeGen/Thumb2/large-stack.ll:21:21: error: expected string not found in input ; CHECK: sub sp, #20 ^ :43:2: note: scanning from here sub sp, #16 ^ :43:2: note: possible intended match here sub sp, #16 ^ The failure is when building @test3. Here's the generated assembly for that function on my beagleboard: test3: stmfd sp!, {r4, r7, r11, lr} add r7, sp, #4 sub.w sp, sp, #805306368 sub sp, #16 mov r4, sp bic r4, r4, #15 mov sp, r4 movs r0, #0 add.w r1, sp, #805306368 str r0, [r1, #+8] mov sp, r7 sub sp, #4 ldmfd.w sp!, {r4, r7, r11, pc} .size test3, .-test3 Is this perhaps a platform issue? ARM on Linux vs. Darwin? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 8 12:01:07 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 8 Dec 2009 12:01:07 -0600 Subject: [LLVMbugs] [Bug 5722] New: llc needs -Os option Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5722 Summary: llc needs -Os option Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: bagel99 at gmail.com CC: llvmbugs at cs.uiuc.edu For targets in embedded systems, the size of code is often more important than execution speed. GCC has the -Os option to indicate optimize for space. As an example, thumb2 code now generates movw/movt instead of using the constant pool. While this speeds up *some* cores, it does take significantly more space. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 8 13:53:53 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 8 Dec 2009 13:53:53 -0600 Subject: [LLVMbugs] [Bug 5723] New: TLS Acces in pic Leaf Causes Stack Corruption Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5723 Summary: TLS Acces in pic Leaf Causes Stack Corruption Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: greened at obbligato.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=3926) --> (http://llvm.org/bugs/attachment.cgi?id=3926) Dynamic Library Source When compiling a leaf routine in pic mode that has a thread-local storage access, LLVM fails to allocate stack space for the call to __get_tls_addr. llc generates the following for the attached library code (function "leaf"): .L_Z4leafv_label.Llabel2: .LBB_Z4leafv_1: # @CFE_debug_label_0 .byte 0x66; leaq ptr at TLSGD(%rip), %rdi; .word 0x6666; rex64 call __tls_get_addr at PLT movq (%rax), %rax movq %rax, -8(%rsp) .LBB_Z4leafv_2: # @CFE_debug_label_2 .byte 0x66; leaq link_ptr at TLSGD(%rip), %rdi; .word 0x6666; rex64 call __tls_get_addr at PLT The second call to __tls_get_addr clobbers the spilled register. The problem is the llc thinks "leaf" is a leaf function when in fact it's not, due to the late-generated call. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 8 14:22:05 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 8 Dec 2009 14:22:05 -0600 Subject: [LLVMbugs] [Bug 5724] New: restFP should use lfd, not stfd Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5724 Summary: restFP should use lfd, not stfd Product: compiler-rt Version: unspecified Platform: Macintosh OS/Version: All Status: NEW Severity: critical Priority: P2 Component: compiler-rt AssignedTo: unassignedbugs at nondot.org ReportedBy: chmeeedalf at gmail.com CC: llvmbugs at cs.uiuc.edu Summary says it all. For restoring floating point registers on ppc, lfd should be used. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 8 14:29:48 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 8 Dec 2009 14:29:48 -0600 Subject: [LLVMbugs] [Bug 5725] New: issue a diagnostic when an include file/ partial path matches with wrong case Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5725 Summary: issue a diagnostic when an include file/partial path matches with wrong case Product: new-bugs Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: deeppatel1987 at gmail.com CC: llvmbugs at cs.uiuc.edu Clang should issue a diagnostic when an include file or path matches on a case-insensitive file system, but with the wrong case. If the problem is with a portion of a path specified on the command line, it should only be warned about once. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 8 14:45:41 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 8 Dec 2009 14:45:41 -0600 Subject: [LLVMbugs] [Bug 5726] New: Incorrrect debug info with clang and mem2reg Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5726 Summary: Incorrrect debug info with clang and mem2reg 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 Consider this source code: int add(int a, int b) { return a + b; } int main() { return add(5, 3); } There are 2 issues when using clang here: 1). the returns from the function are attributed to the line that has '}', not to the line that has 'return '. One could argue that this is correct behavior. It would be IFF only the 'ret' instruction would have the location of '}', but see 2) 2. opt -mem2reg collapses some instruction's location with the next ones (such as call add, ret -> the call's location becomes ret's. I think this is a bug. The result is that after compiling with clang -O0 -g, even a simple pass like -mem2reg causes incorrect debug info, which is confusing when trying to single-step in the debugger. When compiled with clang -g, the add in function main is correctly attributed to simple.c:8:5 (see attached testcase.bc): define i32 @main() nounwind { entry: %retval = alloca i32 ; [#uses=3] store i32 0, i32* %retval %call = call i32 @add(i32 5, i32 3), !dbg !12 ; [#uses=1] store i32 %call, i32* %retval, !dbg !12 %0 = load i32* %retval, !dbg !15 ; [#uses=1] ret i32 %0, !dbg !15 } !12 = metadata !{i32 8, i32 5, metadata !13, null} !15 = metadata !{i32 9, i32 1, metadata !14, null} However the return is incorrectly attributed to line simple.c:9:1 (which is just a }, not the return itself). Now run opt -mem2reg, it will look like this: define i32 @main() nounwind { entry: %call = call i32 @add(i32 5, i32 3), !dbg !6 ; [#uses=1] ret i32 %call, !dbg !6 } !6 = metadata !{i32 9, i32 1, metadata !7, null} Thus the call to add is attributed to 9:1, whereas there is no code on that (it is the return from function, the }). This looks awkward in a debugger: Breakpoint 1, main () at simple.c:7 7 { (gdb) s 9 } (gdb) s add () at simple.c:4 4 } The debugger doesn't show any of the useful source lines as executing. Compare this with gcc at -O1, which is slightly better: Breakpoint 1, main () at examples/in/simple.c:8 8 return add(5, 3); (gdb) s add (a=5, b=3) at examples/in/simple.c:2 2 { (gdb) s add (a=5, b=3) at examples/in/simple.c:4 4 } (gdb) s main () at examples/in/simple.c:9 9 } Or even with the output from llvm-gcc -O1 which is much better: Breakpoint 1, main () at simple.c:7 7 { (gdb) s 8 return add(5, 3); (gdb) s add () at simple.c:3 3 return a + b; (gdb) 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 Tue Dec 8 17:19:06 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 8 Dec 2009 17:19:06 -0600 Subject: [LLVMbugs] [Bug 5722] llc needs -Os option In-Reply-To: Message-ID: <200912082319.nB8NJ6cD027577@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5722 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |evan.cheng at apple.com Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #1 from Evan Cheng 2009-12-08 17:19:05 --- -Os is translated by llvm-gcc / clang into "optsize" function note. That tells the code generator the function needs to be optimized for code size by -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 8 17:23:45 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 8 Dec 2009 17:23:45 -0600 Subject: [LLVMbugs] [Bug 5728] New: Miscompilation with fastcall Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5728 Summary: Miscompilation with fastcall 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 Blocks: 5511 Created an attachment (id=3928) --> (http://llvm.org/bugs/attachment.cgi?id=3928) Testcase (IL) C testcase: static __attribute((fastcall)) void*a(void*x,double y,int z) { return 0; } __attribute((fastcall)) void*b(void*x,double y){return a(x,y,10);} int main() { b(0,0); return 0; } Compiling and running the result with clang on x86-32 Linux leads to a crash. It looks like something is wrong with the epilogue for b(). IL testcase attached; to reproduce the issue with the IL testcase, use llc -O0. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 8 19:27:36 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 8 Dec 2009 19:27:36 -0600 Subject: [LLVMbugs] [Bug 5729] New: Certain tail calls cause assertion failure Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5729 Summary: Certain tail calls cause assertion failure Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Backend: X86 AssignedTo: jyasskin at google.com ReportedBy: jyasskin at google.com CC: nicholas at mxc.ca, llvmbugs at cs.uiuc.edu Created an attachment (id=3929) --> (http://llvm.org/bugs/attachment.cgi?id=3929) Crashing tail call The attached IR crashes on x86-64 with the following assertion error: $ Debug/bin/llvm-as ~/tmp/lli_crash.ll $ Debug/bin/lli -disable-lazy-compilation ~/tmp/lli_crash.bc $ gdb --args Debug/bin/lli -tailcallopt -disable-lazy-compilation ~/tmp/lli_crash.bc (gdb) run Starting program: /usr/local/google/jyasskin/llvm/trunk/obj/Debug/bin/lli -tailcallopt -disable-lazy-compilation /home/jyasskin/tmp/lli_crash.bc [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". lli: /usr/local/google/jyasskin/llvm/trunk/src/lib/Target/X86/X86ISelLowering.cpp:2072: virtual llvm::SDValue llvm::X86TargetLowering::LowerCall(llvm::SDValue, llvm::SDValue, llvm::CallingConv::ID, bool, bool, const llvm::SmallVectorImpl&, const llvm::SmallVectorImpl&, llvm::DebugLoc, llvm::SelectionDAG&, llvm::SmallVectorImpl&): Assertion `((Callee.getOpcode() == ISD::Register && (cast(Callee)->getReg() == X86::EAX || cast(Callee)->getReg() == X86::R9)) || Callee.getOpcode() == ISD::TargetExternalSymbol || Callee.getOpcode() == ISD::TargetGlobalAddress) && "Expecting an global address, external symbol, or register"' failed. Program received signal SIGABRT, Aborted. 0x00007ffff6813095 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00007ffff6813095 in raise () from /lib/libc.so.6 #1 0x00007ffff6814af0 in abort () from /lib/libc.so.6 #2 0x00007ffff680c2df in __assert_fail () from /lib/libc.so.6 #3 0x0000000000ad5cbe in llvm::X86TargetLowering::LowerCall (this=0x1675348, Chain=..., Callee=..., CallConv=llvm::CallingConv::Fast, isVarArg=false, isTailCall=true, Outs=..., Ins=..., dl=..., DAG=..., InVals=...) at /usr/local/google/jyasskin/llvm/trunk/src/lib/Target/X86/X86ISelLowering.cpp:2067 #4 0x0000000000bba289 in llvm::TargetLowering::LowerCallTo (this=0x1675348, Chain=..., RetTy=0x166c7d0, RetSExt=false, RetZExt=false, isVarArg=false, isInreg=false, NumFixedArgs=1, CallConv=llvm::CallingConv::Fast, isTailCall=true, isReturnValueUsed=true, Callee=..., Args=std::vector of length 1, capacity 1 = {...}, DAG=..., dl=...) at /usr/local/google/jyasskin/llvm/trunk/src/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:5428 #5 0x0000000000bc2843 in llvm::SelectionDAGBuilder::LowerCallTo (this=0x1699a00, CS=..., Callee=..., isTailCall=true, LandingPad=0x0) at /usr/local/google/jyasskin/llvm/trunk/src/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:4219 #6 0x0000000000bd2dd6 in llvm::SelectionDAGBuilder::visitCall (this=0x1699a00, I=...) at /usr/local/google/jyasskin/llvm/trunk/src/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:4366 #7 0x0000000000bde98e in llvm::SelectionDAGBuilder::visit (this=0x1699a00, Opcode=45, I=...) at /usr/local/google/jyasskin/llvm/trunk/src/include/llvm/Instruction.def:161 #8 0x0000000000bdea52 in llvm::SelectionDAGBuilder::visit (this=0x1699a00, I=...) at /usr/local/google/jyasskin/llvm/trunk/src/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:582 #9 0x0000000000bf4b78 in llvm::SelectionDAGISel::SelectBasicBlock (this=0x1695500, LLVMBB=0x16745d0, Begin=..., End=..., HadTailCall=@0x7fffffffdb9e) at /usr/local/google/jyasskin/llvm/trunk/src/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:411 #10 0x0000000000bf5730 in llvm::SelectionDAGISel::SelectAllBasicBlocks (this=0x1695500, Fn=..., MF=..., MMI=0x16869b0, DW=0x169b320, TII=...) at /usr/local/google/jyasskin/llvm/trunk/src/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:844 #11 0x0000000000bf6577 in llvm::SelectionDAGISel::runOnMachineFunction (this=0x1695500, mf=...) at /usr/local/google/jyasskin/llvm/trunk/src/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:341 #12 0x0000000000d2e421 in llvm::MachineFunctionPass::runOnFunction (this=0x1695500, F=...) at /usr/local/google/jyasskin/llvm/trunk/src/lib/CodeGen/MachineFunctionPass.cpp:27 #13 0x0000000000fe2f10 in llvm::FPPassManager::runOnFunction (this=0x16788d0, F=...) at /usr/local/google/jyasskin/llvm/trunk/src/lib/VMCore/PassManager.cpp:1336 #14 0x0000000000fe4b8f in llvm::FunctionPassManagerImpl::run (this=0x16782f0, F=...) at /usr/local/google/jyasskin/llvm/trunk/src/lib/VMCore/PassManager.cpp:1288 #15 0x0000000000fe4d36 in llvm::FunctionPassManager::run (this=0x1675020, F=...) at /usr/local/google/jyasskin/llvm/trunk/src/lib/VMCore/PassManager.cpp:1218 #16 0x0000000000cc8ae1 in llvm::JIT::runJITOnFunctionUnlocked (this=0x16807d0, F=0x16732c0, locked=...) at /usr/local/google/jyasskin/llvm/trunk/src/lib/ExecutionEngine/JIT/JIT.cpp:601 #17 0x0000000000cc8f17 in llvm::JIT::getPointerToFunction (this=0x16807d0, F=0x16732c0) at /usr/local/google/jyasskin/llvm/trunk/src/lib/ExecutionEngine/JIT/JIT.cpp:667 #18 0x00000000008e6e4c in main (argc=4, argv=0x7fffffffe298, envp=0x7fffffffe2c0) at /usr/local/google/jyasskin/llvm/trunk/src/tools/lli/lli.cpp:211 This was introduced in r88984. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 8 21:06:13 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 8 Dec 2009 21:06:13 -0600 Subject: [LLVMbugs] [Bug 5709] "Attributes after last parameter!" error In-Reply-To: Message-ID: <200912090306.nB936DRc004324@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5709 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Eli Friedman 2009-12-08 21:06:12 --- Fixed in r90936. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 9 03:39:10 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 9 Dec 2009 03:39:10 -0600 Subject: [LLVMbugs] [Bug 5732] New: friend class method declaration fails Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5732 Summary: friend class method declaration fails Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mainmanmauricio at gmail.com CC: llvmbugs at cs.uiuc.edu Trying to compile a boost header on Linux x84_64 with clang++ from today's trunk, crashes with: clang-cc: SemaLookup.cpp:528: bool clang::Sema::CppLookupName(clang::LookupResult&, clang::Scope*): Assertion `Ctx && Ctx->isFileContext() && "We should have been looking only at file context here already."' failed. A minimal program reproducing the issue follows: namespace boost { class exception; namespace exception_detail { char const * get_diagnostic_information( exception const & ); } class exception { friend class exception_detail; // works friend char const * exception_detail::get_diagnostic_information ( exception const & ); // 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 Wed Dec 9 04:12:57 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 9 Dec 2009 04:12:57 -0600 Subject: [LLVMbugs] [Bug 5733] New: Assertion in PHITransAddr Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5733 Summary: Assertion in PHITransAddr Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: quickslyver at free.fr CC: llvmbugs at cs.uiuc.edu Created an attachment (id=3930) --> (http://llvm.org/bugs/attachment.cgi?id=3930) testcase Found running gcc torture suite on clang $ clang-cc tests/compile/gcc/20070520-1.c -emit-llvm -o - -O3 Non phi translatable instruction found in PHITransAddr, either something is missing from InstInputs or CanPHITrans is wrong: %tmp274 = xor i32 %stride, -1 ; [#uses=1] clang-cc: /home/steissier/documents/projets/IP/pitchoun16/tools/llvm-pitchoun16/llvm/lib/Analysis/PHITransAddr.cpp:302: bool llvm::PHITransAddr::PHITranslateValue(llvm::BasicBlock*, llvm::BasicBlock*): Assertion `Verify() && "Invalid PHITransAddr!"' failed. [...] testcase attached -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 9 11:19:16 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 9 Dec 2009 11:19:16 -0600 Subject: [LLVMbugs] [Bug 5733] Assertion in PHITransAddr In-Reply-To: Message-ID: <200912091719.nB9HJGqb019996@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5733 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2009-12-09 11:19:16 --- Fixed here, thanks! http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091207/092393.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 9 13:22:54 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 9 Dec 2009 13:22:54 -0600 Subject: [LLVMbugs] [Bug 5735] New: JIT should not codegen available_externally functions. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5735 Summary: JIT should not codegen available_externally functions. Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Target-Independent JIT AssignedTo: unassignedbugs at nondot.org ReportedBy: jyasskin at google.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=3931) --> (http://llvm.org/bugs/attachment.cgi?id=3931) Failing test + assertion The attached patch currently fails because the JIT tries to compile the available_externally function instead of dlsym'ing the existing definition. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 9 15:29:12 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 9 Dec 2009 15:29:12 -0600 Subject: [LLVMbugs] [Bug 5737] New: available_externally should be discoverable on ghost functions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5737 Summary: available_externally should be discoverable on ghost functions Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Core LLVM classes AssignedTo: unassignedbugs at nondot.org ReportedBy: jyasskin at google.com CC: llvmbugs at cs.uiuc.edu, nlewycky at google.com Before a function has been lazy-loaded from bitcode, its linkage is 'ghost'. When the JIT needs the address of an available_externally function, it needs to dlsym it from the main executable, but it has to waste time loading the function from bitcode to determine that it doesn't need any of the IR it just loaded. If 'ghost' or 'available_externally' were something other than a linkage, this wouldn't be a 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 Wed Dec 9 16:12:34 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 9 Dec 2009 16:12:34 -0600 Subject: [LLVMbugs] [Bug 5738] New: Helper libraries for unit testing Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5738 Summary: Helper libraries for unit testing Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Support Libraries AssignedTo: unassignedbugs at nondot.org ReportedBy: jyasskin at google.com CC: llvmbugs at cs.uiuc.edu, nlewycky at google.com We're starting to write a collection of functions and classes helpful for unit testing, but we don't have anywhere to put them. For example, http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/ExecutionEngine/JIT/JITTest.cpp?view=markup contains a RecordingJITMemoryManager class and a LoadAssembly(char*) helper function, both of which could be useful for other tests. We probably want a couple different helper libraries with different dependencies so that the VMCore unit tests don't have to depend on the JIT. I'd like someone who knows the build system to set up the Makefiles appropriately so that individual test writers like me can just add files/functions to the right places to share them. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 9 16:26:29 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 9 Dec 2009 16:26:29 -0600 Subject: [LLVMbugs] [Bug 5739] New: _mm_alignr_epi8 sets immediate wrong in llvm-gcc, clang Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5739 Summary: _mm_alignr_epi8 sets immediate wrong in llvm-gcc, clang Product: new-bugs Version: 2.6 Platform: PC OS/Version: Linux Status: NEW Keywords: miscompilation Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: llvm at shiftleft.org CC: llvmbugs at cs.uiuc.edu The SSE3 function _mm_alignr_epi8, which lowers to palignr, is given the wrong immediate by both llvm-gcc and clang. Version numbers: llvm-gcc: llvm-gcc (GCC) 4.2.1 (Based on Apple Inc. build 5649) (LLVM build) clang: clang version 1.1 (trunk 85640) Target: x86_64-unknown-linux-gnu Thread model: posix LLVM: Low Level Virtual Machine (http://llvm.org/): llvm version 2.7svn DEBUG build with assertions. Built Oct 30 2009 (18:06:39). Host: x86_64-unknown-linux-gnu gcc: gcc (Ubuntu 4.4.1-4ubuntu8) 4.4.1 Linux distro: Ubuntu 8.10 "Karmic" Linux peppercorn 2.6.31-16-generic #52-Ubuntu SMP Thu Dec 3 22:07:16 UTC 2009 x86_64 GNU/Linux Test case: //////////////////////////////////////////// #include int main(int argc, char **argv) { __m128i x = _mm_setzero_si128(), y = _mm_alignr_epi8(x, x, 1); return 0; } //////////////////////////////////////////// $ llvm-gcc -S -mssse3 test.c -o - | grep palignr palignr $8, %xmm1, %xmm1 $ clang -S -mssse3 test.c -o - | grep palignr palignr $0, %xmm1, %xmm1 $ gcc -S -mssse3 test.c -o - | grep palignr palignr $1, %xmm1, %xmm0 gcc is correct, but clang and llvm-gcc give different wrong results. From other testing, it appears that llvm-gcc always sets the immediate too high by a factor of 8. Clang sometimes sets it to 0 and sometimes sets it to 1. The code in the test case is obviously dead, but the optimizer is off here and the bug occurs in real code as well. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 9 17:32:58 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 9 Dec 2009 17:32:58 -0600 Subject: [LLVMbugs] [Bug 5739] _mm_alignr_epi8 sets immediate wrong in llvm-gcc, clang In-Reply-To: Message-ID: <200912092332.nB9NWwil001264@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5739 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Eric Christopher 2009-12-09 17:32:58 --- Fixed in llvm-gcc, just verified that clang still has a problem. Just wanted to verify. Current codegen llvm-gcc: palignr $1, %xmm1, %xmm1 Current codegen clang: palignr $0, %xmm1, %xmm1 I'll file a bug against clang. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 9 17:34:36 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 9 Dec 2009 17:34:36 -0600 Subject: [LLVMbugs] [Bug 5743] New: clang palignr codegen bug Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5743 Summary: clang palignr codegen bug Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: echristo at gmail.com CC: llvmbugs at cs.uiuc.edu, echristo at gmail.com Looks like clang has incorrect codegen for the following test: #include int main(int argc, char **argv) { __m128i x = _mm_setzero_si128(), y = _mm_alignr_epi8(x, x, 1); return 0; } Where it's generating: palignr $0, %xmm1, %xmm1 The constant should be $1. I'm guessing somewhere we've got an extra divide by 8. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 9 17:49:55 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 9 Dec 2009 17:49:55 -0600 Subject: [LLVMbugs] [Bug 5744] New: Assertion failed: (C->getType()->getScalarSizeInBits() > Ty->getScalarSizeInBits()&& "SrcTy must be larger than DestTy for Trunc!") Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5744 Summary: Assertion failed: (C->getType()->getScalarSizeInBits() > Ty->getScalarSizeInBits()&& "SrcTy must be larger than DestTy for Trunc!") Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: pawel.worach at gmail.com CC: llvmbugs at cs.uiuc.edu Blocks: 3696 Created an attachment (id=3933) --> (http://llvm.org/bugs/attachment.cgi?id=3933) bugpoint-reduced-simplified.bc Assert in opt when building vfs_bio.c from the FreeBSD kernel. llvm/clang r90987. # opt bugpoint-reduced-simplified.bc -inline -scalarrepl -gvn -constmerge WARNING: You're attempting to print out a bitcode file. This is inadvisable as it may cause display problems. If you REALLY want to taste LLVM bitcode first-hand, you can force output with the `-f' option. Assertion failed: (C->getType()->getScalarSizeInBits() > Ty->getScalarSizeInBits()&& "SrcTy must be larger than DestTy for Trunc!"), function getTrunc, file Constants.cpp, line 1220. Stack dump: 0. Program arguments: opt bugpoint-reduced-simplified.bc -inline -scalarrepl -gvn -constmerge 1. Running pass 'CallGraph Pass Manager' on module 'bugpoint-reduced-simplified.bc'. 2. Running pass 'Global Value Numbering' on function '@flushbufqueues' Abort (core dumped) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 9 18:12:01 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 9 Dec 2009 18:12:01 -0600 Subject: [LLVMbugs] [Bug 5744] Assertion failed: (C->getType()->getScalarSizeInBits() > Ty-> getScalarSizeInBits()&& "SrcTy must be larger than DestTy for Trunc!") In-Reply-To: Message-ID: <200912100012.nBA0C1Dr002705@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5744 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2009-12-09 18:12:01 --- Fixed, thanks! http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091207/092410.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 9 18:41:12 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 9 Dec 2009 18:41:12 -0600 Subject: [LLVMbugs] [Bug 5746] New: JIT should use available_externally globals to find more things it doesn' t need to codegen Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5746 Summary: JIT should use available_externally globals to find more things it doesn't need to codegen Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Target-Independent JIT AssignedTo: unassignedbugs at nondot.org ReportedBy: jyasskin at google.com CC: llvmbugs at cs.uiuc.edu, nlewycky at google.com Say we have C code like: static int func(void) { ... } typedef int (*FuncPtr)(void); extern const FuncPtr NS_UniquelyNamedFunc = &func; If this code is compiled into the JIT's runtime, we can also compile it to bitcode and mark NS_UniquelyNamedFunc as available_externally, since the JIT can use dlsym() to look it up in the runtime. However, we can't mark 'func' as available_externally since its symbol will be renamed and hidden to avoid name collisions with other translation units. Even once PR5735 is fixed, this will cause the JIT to unnecessarily codegen func. It's unnecessary because there's guaranteed to be a pointer with the same semantics, since it escaped the translation unit. Proposed algorithm for improving this: 1. dlsym the available_externally GlobalVariable to get its address in the real program. 2. Traverse its initializer and that address in parallel. (http://code.google.com/p/unladen-swallow/source/browse/trunk/Util/ConstantMirror.cc#266 traverses memory according to an llvm::Type, so we can copy from there.) 3. Each time we find a pointer @p in the initializer, call addGlobalMapping(@p, value_from_memory) to match it up and prevent the JIT from trying to compile it again. For this to be useful, we'd have to do the traversal before trying to JIT any function that used a value from one of these globals. Since the optimizers try to remove references to the global and replace it with its field, we can't rely on the global still being used by the IR when the JIT gets to it. That means this utility needs to available for explicit calls from the user in addition to operating automatically from the JIT. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 9 19:38:32 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 9 Dec 2009 19:38:32 -0600 Subject: [LLVMbugs] [Bug 5743] clang palignr codegen bug In-Reply-To: Message-ID: <200912100138.nBA1cWVC006495@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5743 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2009-12-09 19:38:32 --- I checked in a minimal fix here: r91032 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 10 04:06:09 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 10 Dec 2009 04:06:09 -0600 Subject: [LLVMbugs] [Bug 5747] New: oprofile support not working Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5747 Summary: oprofile support not working 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 LLVM compiled with oprofile was crashing, I fixed that in r91046, however oprofile is still not working correctly. I tried it on a simple code: int main() { while(1) {}} Compile that to bc with clang -O0 -g -emit-llvm -c, and run with lli $ lli --debug-only=oprofile-jit-event-listener x.bc Connected to OProfile agent. Mapping 0x7f5c24449010 to x.c:1 Mapping 0x7f5c24449018 to x.c:1 Everything seems fine there, however oprofile can't process the samples: $ sudo opreport opreport error: No sample file found: try running opcontrol --dump or specify a session containing sample files $ sudo less /var/lib/oprofile/samples/oprofiled.log oprofiled started Thu Dec 10 11:58:36 2009 kernel pointer size: 8 Start opjitconv was triggered Read buffer of 1746 entries. CPU_SWITCH to 3 CPU_SWITCH to 1 CPU_SWITCH to 0 CPU_SWITCH to 1 CPU_SWITCH to 2 CPU_SWITCH to 3 ... start time/end time is 1260439116/1260439129 opjitconv: Ending with rc = 2. This code is usually OK, but can be useful for debugging purposes. JIT dump processing complete. JIT dump processing complete. Start opjitconv was triggered Read bustart time/end time is 1260439116/1260439139 opjitconv: Ending with rc = 2. This code is usually OK, but can be useful for debugging purposes. JIT dump processing complete. buffer of 1167 entries. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 10 07:08:18 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 10 Dec 2009 07:08:18 -0600 Subject: [LLVMbugs] [Bug 5748] New: RFE: full dwarf debug info for JITed code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5748 Summary: RFE: full dwarf debug info for JITed code 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 Currently the JIT only creates dwarf unwind tables, and symbol names, which is enough to get a backtrace in gdb but not much else. I would like if the JIT would emit source file/line debug info, and variable debug info. Here's my suggestion towards implementing this: 1) DwarfDebug.cpp should be changed to not use AsmPrinter but rather use an API that can both emit to an in-memory ELF (using ELFWriter), and to an assembly file (when statically compiling). Then JITDebugRegisterer could use it to create an ELF with source filename, and line/column number debug info. This would already allow some JITed code to be debugged with gdb. Next, debug info for the values of function arguments, and local variables should be added to the JITed code, so that gdb in backtraces we can see what the parameters are, and what their values are. DwarfDebug already supports this, if the values are on the stack AFAIK. It should only be a matter of emitting the tables in memory rather than in asm form to disk. Sure variable debug info won't work with optimized code, but one could run reg2mem to put the values on the stack for which DwarfDebug knows how to emit debug info (or use -O0 that doesn't run mem2reg at all). When DwarfDebug itself will support representing the value of not-stack allocated variables (for example variables/arguments kept in registers), the JITed code would automatically get that support too. One issue is that currently JITDebugRegisterer creates one ELF file per function, which is OK right now (might even be OK if only source/line number debug info is added), but I think it would grow huge if for each JITed function we emit all the type/macro/variables debug info again. (a debug build of lli is 83M right now, I don't want to find out how big that would if each function would be separate elf). Perhaps we could emit multiple functions to the same ELF, i.e. when a new ELF needs to be emitted we unregister the old ELF from gdb, add the new function/debug info to it, and reregister the new ELF file. 2) Implement emission of source/line debug info (and variable debug info) using ELFWriter. This could be a short term solution for the source/line debug info, but it would just duplicate the functionality of DwarfDebug, and we'd still have no debug info for variables on the stack and in registers. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 10 16:29:56 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 10 Dec 2009 16:29:56 -0600 Subject: [LLVMbugs] [Bug 3173] Cached constant value in EnumConstantDecl not consistent with type of constant In-Reply-To: Message-ID: <200912102229.nBAMTuij031927@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3173 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #15 from Eli Friedman 2009-12-10 16:29:56 --- Done in r91070. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 10 16:44:13 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 10 Dec 2009 16:44:13 -0600 Subject: [LLVMbugs] [Bug 5750] New: RFE: include warning for shared data Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5750 Summary: RFE: include warning for shared data Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: daniel at zuster.org CC: llvmbugs at cs.uiuc.edu clang should include an optional (off by default) warning which warns about the use of any shared data (local static data, globals, etc.). The idea is to warn about things which may block concurrency. Getting this warning right will take some work, but it would be very useful for projects (like LLVM/Clang itself) which want to migrate to being reentrant. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 10 20:43:20 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 10 Dec 2009 20:43:20 -0600 Subject: [LLVMbugs] [Bug 5754] New: LegalizeVectorTypes asserts on Vector SIGN_EXTEND_INREG Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5754 Summary: LegalizeVectorTypes asserts on Vector SIGN_EXTEND_INREG Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: major Priority: P2 Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: micah.villmow at amd.com CC: llvmbugs at cs.uiuc.edu Test case(couresy of Eli Friedman): define <8 x i32> @a(<8 x i32> %a) { %b = trunc <8 x i32> %a to <8 x i16> %c = sext <8 x i16> %b to <8 x i32> ret <8 x i32> %c } Assertion: LegalizeVectorTypes.cpp:389 llvm_unreachable("Do not know how to split the result of this operator!"); Proposed Solution: 1) Disable DAG Combination for vector types // fold (sext (truncate x)) -> (sextinreg x). in ~DAGCombiner.cpp:3024 2) Enable SplitVecRes_SIGN_EXTEND_INREG in LegalizeVectorTypes.cpp: void DAGTypeLegalizer::SplitVecRes_BinOp(SDNode *N, SDValue &Lo, SDValue &Hi) { SDValue LHSLo, LHSHi; GetSplitVector(N->getOperand(0), LHSLo, LHSHi); EVT RHSLo, RHSHi; GetSplitDestVTs(N->getOperand(1), RHSLo, RHSHi); DebugLoc dl = N->getDebugLoc(); Lo = DAG.getNode(N->getOpcode(), dl, LHSLo.getValueType(), LHSLo, DAG.getValueType(RHSLo)); Hi = DAG.getNode(N->getOpcode(), dl, LHSHi.getValueType(), LHSHi, DAG.getValueType(RHSHi)); } The second solution causes expansion of sign_extend_inreg to assert because Operand(1) is of type MVT::Other instead of the same type as Operand(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 Dec 11 07:49:19 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 11 Dec 2009 07:49:19 -0600 Subject: [LLVMbugs] [Bug 5757] New: Assertion fails: ReplaceAllUsesWith in SelectionDAG Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5757 Summary: Assertion fails: ReplaceAllUsesWith in SelectionDAG Product: libraries Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Keywords: compile-fail Severity: normal Priority: P2 Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: stephan.reiter at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=3934) --> (http://llvm.org/bugs/attachment.cgi?id=3934) LLVM module for reproduction of the problem. Attempting to compile the attached LLVM with llc built from today's trunk (Dec 11th) on Windows XP 64-bit aborts with the following errors message: Replacing.3 0x257afa8: i64 = select 0x2522978, 0x2523990, 0x251f078 With: 0x2523c78: i32 = mul 0x2522d58, 0x2523990 Assertion failed: (!From->hasAnyUseOfValue(i) || From->getValueType(i) == To->getValueType(i)) && "Cannot use this version of ReplaceAllUsesWith!", file trunk\lib\CodeGen\SelectionDAG\SelectionDAG.cpp, line 4871 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 11 09:24:46 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 11 Dec 2009 09:24:46 -0600 Subject: [LLVMbugs] [Bug 5758] New: indvars assertion with indirect branch Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5758 Summary: indvars assertion with indirect branch 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: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Created an attachment (id=3935) --> (http://llvm.org/bugs/attachment.cgi?id=3935) testcase .ll $ opt -indvars llvm-target.ll --disable-output opt: llvm/lib/Analysis/LoopInfo.cpp:324: void llvm::Loop::getUniqueExitBlocks(llvm::SmallVectorImpl&) const: Assertion `isLoopSimplifyForm() && "getUniqueExitBlocks assumes the loop is in canonical form!"' 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 Fri Dec 11 09:39:10 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 11 Dec 2009 09:39:10 -0600 Subject: [LLVMbugs] [Bug 5759] New: Debug generation crashes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5759 Summary: Debug generation crashes Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=3936) --> (http://llvm.org/bugs/attachment.cgi?id=3936) testcase Reduction from building libstdc++ with llvm-gcc (i.e., a bootstrap). To reproduce: ./cc1plus -fpreprocessed codecvt.ii -g -o codecvt.ll -emit-llvm or llc bugpoint-reduced-simplified.ll -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 11 13:40:19 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 11 Dec 2009 13:40:19 -0600 Subject: [LLVMbugs] [Bug 5723] TLS Acces in pic Leaf Causes Stack Corruption In-Reply-To: Message-ID: <200912111940.nBBJeJD8025098@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5723 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Anton Korobeynikov 2009-12-11 13:40:18 --- Fixed in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091207/092470.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 11 14:05:36 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 11 Dec 2009 14:05:36 -0600 Subject: [LLVMbugs] [Bug 5758] indvars assertion with indirect branch In-Reply-To: Message-ID: <200912112005.nBBK5a6P026076@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5758 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Dan Gohman 2009-12-11 14:05:35 --- Fixed in r91147. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 11 14:07:52 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 11 Dec 2009 14:07:52 -0600 Subject: [LLVMbugs] [Bug 5757] Assertion fails: ReplaceAllUsesWith in SelectionDAG In-Reply-To: Message-ID: <200912112007.nBBK7qkM026166@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5757 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gohman at apple.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Dan Gohman 2009-12-11 14:07:52 --- Fixed in r91145. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 11 14:32:52 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 11 Dec 2009 14:32:52 -0600 Subject: [LLVMbugs] [Bug 5765] New: [CMake build] LLVM_MULTITHREADED is not set Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5765 Summary: [CMake build] LLVM_MULTITHREADED is not set 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 It should be set the same way as set by configure for both Unix and Win32, otherwise for example all the Win32 multithreading code is dead. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 11 15:32:12 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 11 Dec 2009 15:32:12 -0600 Subject: [LLVMbugs] [Bug 5754] LegalizeVectorTypes asserts on Vector SIGN_EXTEND_INREG In-Reply-To: Message-ID: <200912112132.nBBLWC5v029518@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5754 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gohman at apple.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Dan Gohman 2009-12-11 15:32:11 --- r91158 fixes the target-independent legalization of SIGN_EXTEND_INREG. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Dec 12 01:38:17 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 12 Dec 2009 01:38:17 -0600 Subject: [LLVMbugs] [Bug 5767] New: Cannot parse valid C-gnu89 code (array decay problem?) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5767 Summary: Cannot parse valid C-gnu89 code (array decay problem?) Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bagnara at cs.unipr.it CC: llvmbugs at cs.uiuc.edu $ cat bug.c struct hek { char hek_key[1]; }; extern void foo(char* p); extern struct hek* zoo(); void bar() { foo(({ ({ struct hek *p; p = zoo(); p; })->hek_key; })); } $ gcc -std=gnu89 -c bug.c $ icc -std=gnu89 -c bug.c $ clang -c -std=gnu89 bug.c bug.c:10:7: error: incompatible type passing 'char [1]', expected 'char *' foo(({ ^~ 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 Sat Dec 12 11:12:07 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 12 Dec 2009 11:12:07 -0600 Subject: [LLVMbugs] [Bug 5765] [CMake build] LLVM_MULTITHREADED is not set In-Reply-To: Message-ID: <200912121712.nBCHC7aa018729@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5765 ??scar Fuentes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from ??scar Fuentes 2009-12-12 11:12:06 --- Please reopen the bug if the previous explanation is not applicable to your case. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Dec 12 12:21:59 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 12 Dec 2009 12:21:59 -0600 Subject: [LLVMbugs] [Bug 5768] New: Invalid codegen for shifts Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5768 Summary: Invalid codegen for shifts Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Consider the following code: #include uint8_t lshr8(uint8_t a, uint8_t cnt) { return a >> cnt; } "clang -ccc-host-triple msp430-elf foo.c -O3 -emit-llvm" yields define zeroext i8 @lshr8(i8 zeroext %a, i8 zeroext %cnt) nounwind readnone { entry: %conv = zext i8 %a to i16 %conv2 = zext i8 %cnt to i16 %shr = lshr i16 %conv, %conv2 %conv3 = trunc i16 %shr to i8 ret i8 %conv3 } note that useless ext's / truncs were added. They are not removed by optimizers (this is another 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 Sat Dec 12 12:56:27 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 12 Dec 2009 12:56:27 -0600 Subject: [LLVMbugs] [Bug 5200] msp430 backend: ice: Do not know how to legalize this operator! In-Reply-To: Message-ID: <200912121856.nBCIuRdT021922@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5200 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Anton Korobeynikov 2009-12-12 12:56:26 --- Implemented in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091207/092495.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Dec 12 13:03:25 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 12 Dec 2009 13:03:25 -0600 Subject: [LLVMbugs] [Bug 5769] New: Coalescer deficiency Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5769 Summary: Coalescer deficiency Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Created an attachment (id=3939) --> (http://llvm.org/bugs/attachment.cgi?id=3939) Testcase Consider attached code. The output of the codegen is: shl16: cmp.b #0, r14 mov.w r15, r12 jeq .LBB1_2 .LBB1_1: rla.w r12 sub.b #1, r14 mov.w r12, r15 jne .LBB1_1 .LBB1_2: ret Note that two moves of r12 <-> r15 are fully redundant and can be coalesced away. Even worse, the mov inserted inside loop is quite expensive, at least it should be outside. It resulted from the phi node in LBB1_2 basic block, so, definitely a code pessimization here. Funny, but turning i16 to i8 yields optimal code. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Dec 12 13:09:19 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 12 Dec 2009 13:09:19 -0600 Subject: [LLVMbugs] [Bug 5770] New: Assertion in leak checker Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5770 Summary: Assertion in leak checker Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Created an attachment (id=3940) --> (http://llvm.org/bugs/attachment.cgi?id=3940) Testcase Consider the attached testcase. Running llc yields: $ ./llc sh.ll llc: /home/asl/proj/llvm/src/lib/VMCore/LeaksContext.h:50: void LeakDetectorImpl::addGarbage(const T*) [with T = void]: Assertion `Ts.count(Cache) == 0 && "Object already in set!"' failed. running llc under valgrind hides the problem (no warnings / errors as well) It seems that something does not clean all the used stuff - assertion goes aways, when few functions are removed from the .ll file.... -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Dec 12 14:30:39 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 12 Dec 2009 14:30:39 -0600 Subject: [LLVMbugs] [Bug 5771] New: HAVE_DLFCN_H does not imply Dl_info Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5771 Summary: HAVE_DLFCN_H does not imply Dl_info Product: Build scripts Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: cmake AssignedTo: unassignedbugs at nondot.org ReportedBy: dje.gcc at gmail.com CC: llvmbugs at cs.uiuc.edu Various files in lib/System/Unix, such as Path.inc and Signals.inc guard use of Dl_info with HAVE_DLFCN_H but the existence of the header file does not imply Dl_info and the support functions that use it are provided. Similarly lib/System/Unix/DynamicLibrary.cpp includes dlfcn.h without using the guard macro. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Dec 12 15:13:04 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 12 Dec 2009 15:13:04 -0600 Subject: [LLVMbugs] [Bug 5768] Invalid codegen for shifts In-Reply-To: Message-ID: <200912122113.nBCLD44w026278@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5768 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sharparrow1 at yahoo.com Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Eli Friedman 2009-12-12 15:13:03 --- C99 6.5.7p3: "The integer promotions are performed on each of the operands." The extensions are required by the standard. The optimizers can't remove them because "lshr i8 %a, %cnt" is undefined if %cnt is in the range 8-15. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Dec 12 17:42:30 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 12 Dec 2009 17:42:30 -0600 Subject: [LLVMbugs] [Bug 5773] New: Creating a JIT-ExecutionEngine overrides the CodeModel set by TargetMachine Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5773 Summary: Creating a JIT-ExecutionEngine overrides the CodeModel set by TargetMachine Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: ebo at 4geeks.de CC: llvmbugs at cs.uiuc.edu The constructor of X86TargetMachine sets the CodeModel from Default to Small on x86_32 targets. When creating a new ExecutionEngine via ExecutionEngine::create((ModuleProvider *MP, bool ForceInterpreter=false, ...) this gets reset to Default by ExecutionEngine::createJit. The value is taken from EngineBuilder::CMModel, which gets initialized to Default. On this code path there is no way to influence this value. X86FastISel only implements the Small code model and tests for cm == CodeModel::Small, thus fails even on 32bit. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Dec 12 19:03:37 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 12 Dec 2009 19:03:37 -0600 Subject: [LLVMbugs] [Bug 4705] llc : Assertion failed: (Reg && "this is not a register!") In-Reply-To: Message-ID: <200912130103.nBD13bUe001243@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=4705 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #12 from Anton Korobeynikov 2009-12-12 19:03:37 --- Fixed in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091207/092504.html This turned out to be weird typo during EVT-ization: only 3 entries were requested for the VT list having 4 elements. Thus, the last element occupis unallocated area and would happily be overwritten in next VT list construction. I believe nobody saw such weird behaviour since very few targets (do we have any except msp430?) has nodes with exactly 4 results... -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Dec 13 03:13:34 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 13 Dec 2009 03:13:34 -0600 Subject: [LLVMbugs] [Bug 5774] New: Missed optimisation from flags on SUB Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5774 Summary: Missed optimisation from flags on SUB Product: libraries Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P2 Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: arplynn at gmail.com CC: llvmbugs at cs.uiuc.edu Consider the following test case: define i32 @foo1 ( i32 %a, i32 %b ) nounwind { entry: %sub = sub i32 %a, %b %diff = icmp slt i32 %a, %b %select = select i1 %diff, i32 %b, i32 %a %call = call i32 @bar ( i32 %sub, i32 %select ) ret i32 %call } define i32 @foo2 ( i32 %a, i32 %b ) nounwind { entry: %sub = sub i32 %a, %b %diff = icmp slt i32 %sub, 0 %select = select i1 %diff, i32 %b, i32 %a %call = call i32 @bar ( i32 %sub, i32 %select ) ret i32 %call } declare i32 @bar ( i32 %a, i32 %b ) nounwind Whilst the effect of both foo1 and foo2 are equivalent, foo2 uses the negative flag from the result of the sub for the condition; foo1 instead generates an extra compare instruction (on X86). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Dec 13 23:02:49 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 13 Dec 2009 23:02:49 -0600 Subject: [LLVMbugs] [Bug 4438] Using the preprocessor from within macros fails In-Reply-To: Message-ID: <200912140502.nBE52nrL029351@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=4438 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Chris Lattner 2009-12-13 23:02:48 --- Fixed here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091207/025343.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 14 00:17:41 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 14 Dec 2009 00:17:41 -0600 Subject: [LLVMbugs] [Bug 5238] Clang should recognize merge conflicts In-Reply-To: Message-ID: <200912140617.nBE6HflC032216@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5238 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2009-12-14 00:17:40 --- Implemented here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091214/025346.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 14 07:28:20 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 14 Dec 2009 07:28:20 -0600 Subject: [LLVMbugs] [Bug 5777] New: JITTests segfaults when built with gcc 3.4.6 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5777 Summary: JITTests segfaults when built with gcc 3.4.6 Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: edwintorok at gmail.com CC: llvmbugs at cs.uiuc.edu On CentOS 4 (and RHEL4), i686 after building LLVM in release mode (ENABLE_OPTIMIZED=1), JITTests fails due to a segfault: [edwin at localhost JIT]$ Release/JITTests [==========] Running 17 tests from 4 test cases. [----------] Global test environment set-up. [----------] 1 test from JIT [ RUN ] JIT.GlobalInFunction Stack dump: 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@F1' Segmentation fault I rebuilt CodeGen, Target, and ExecutionEngine with make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION="-O2 -g", and compiled the unittest with make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION="-O2 -g" KEEP_SYMBOLS=1 to get a backtrace in gdb: Starting program: /home/edwin/llvm/unittests/ExecutionEngine/JIT/Release/JITTests [Thread debugging using libthread_db enabled] [New Thread -1208768832 (LWP 9303)] [==========] Running 17 tests from 4 test cases. [----------] Global test environment set-up. [----------] 1 test from JIT [ RUN ] JIT.GlobalInFunction Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208768832 (LWP 9303)] llvm::SelectionDAG::getGlobalAddress (this=0x8fe9298, GV=0x8fe9298, Offset=0, isTargetGA=true, TargetFlags=Variable "TargetFlags" is not available. ) at /home/edwin/llvm/include/llvm/Support/Recycler.h:41 41 static void setPrev(RecyclerStruct *t, RecyclerStruct *p) { t->Prev = p; } Current language: auto; currently c++ (gdb) bt #0 llvm::SelectionDAG::getGlobalAddress (this=0x8fe9298, GV=0x8fe9298, Offset=0, isTargetGA=true, TargetFlags=Variable "TargetFlags" is not available. ) at /home/edwin/llvm/include/llvm/Support/Recycler.h:41 #1 0x08389b4f in llvm::X86TargetLowering::LowerGlobalAddress (this=0x8fe9298, GV=0x8fd63b4, dl={Idx = 150823860}, Offset=4294967295, DAG=@0x0) at /home/edwin/llvm/include/llvm/CodeGen/SelectionDAG.h:287 #2 0xbfe4eb88 in ?? () #3 0x083c3e94 in llvm::X86TargetLowering::LowerGlobalAddress ( this=0xbfe4f518, Op={Node = 0x8fd3fd4, ResNo = 150902016}, DAG=@0x0) at /home/edwin/llvm/include/llvm/CodeGen/SelectionDAGNodes.h:1426 #4 0x08fd3fd4 in ?? () #5 0x083dd3d6 in llvm::X86TargetLowering::LowerOperation (this=0xbfe4f518, Op= {Node = 0x0, ResNo = 150902148}, DAG=@0x8bba0a0) at X86ISelLowering.cpp:7177 #6 0xbfe4f828 in ?? () (gdb) quit I also see lots of warnings like these during build: include/llvm/CodeGen/JITCodeEmitter.h:172: warning: cast to pointer from integer of different size Also in ExecutionEngineTests (although it passes) I see these warnings: ExecutionEngineTest.cpp:106: warning: passing NULL used for non-pointer converting 3 of 'static testing::AssertionResult testing::internal::EqHelper< true>::Compare(const char*, const char*, const T1&, T2*) [with T1=int, T2=const llvm::GlobalValue] Script started on Mon 14 Dec 2009 01:26:56 PM EET System info: $ uname -a Linux localhost.localdomain 2.6.9-89.ELsmp #1 SMP Mon Jun 22 12:32:43 EDT 2009 i686 i686 i386 GNU/Linux $ gcc -v Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux Thread model: posix gcc version 3.4.6 20060404 (Red Hat 3.4.6-11) $ g++ -v Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux Thread model: posix gcc version 3.4.6 20060404 (Red Hat 3.4.6-11) $ ld -v GNU ld version 2.15.92.0.2 20040927 Attached is config.log, and the output of JITTests after I enabled --debug in it (llvm::DebugFlag = true). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 14 09:33:42 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 14 Dec 2009 09:33:42 -0600 Subject: [LLVMbugs] [Bug 5759] Debug generation crashes In-Reply-To: Message-ID: <200912141533.nBEFXgeH002381@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5759 devang.patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from devang.patel 2009-12-14 09:33:42 --- This was fixed on friday. Please try mainline again. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 14 12:22:41 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 14 Dec 2009 12:22:41 -0600 Subject: [LLVMbugs] [Bug 5778] New: llvm-gcc4.2-2.6.source fails to build out of the box Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5778 Summary: llvm-gcc4.2-2.6.source fails to build out of the box Product: Projects Version: 2.6 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Java AssignedTo: unassignedbugs at nondot.org ReportedBy: eric.schweitz at gmail.com CC: llvmbugs at cs.uiuc.edu Downloaded the tarballs and attempted to build on a linux system with GCC 3.4.6 per the instructions. Tried rebuilding LLVM 2.6 with OPTIMIZE_OPTION=-O2 as explained in the README as well to no effect. /.../llvm-gcc4.2-2.6.source/obj/./gcc/xgcc -B/.../llvm-gcc4.2-2.6.source/obj/./gcc/ -B/.../llvm-gcc4.2-2.6.source/obj/../install/i686-pc-linux-gnu/bin/ -B/.../llvm-gcc4.2-2.6.source/obj/../install/i686-pc-linux-gnu/lib/ -isystem /.../llvm-gcc4.2-2.6.source/obj/../install/i686-pc-linux-gnu/include -isystem /.../llvm-gcc4.2-2.6.source/obj/../install/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber -I/.../llvm-2.6/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer \ -c ../../gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o cc1: /.../llvm-2.6/include/llvm/ADT/ilist.h:197: typename bidirectional_iterator::reference llvm::ilist_iterator::operator*() const [with NodeTy = llvm::RecyclerStruct]: Assertion `Traits::getNext(NodePtr) != 0 && "Dereferencing end()!"' failed. ../../gcc/crtstuff.c:378: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make[3]: *** [crtbegin.o] Error 1 make[3]: Leaving directory `/.../llvm-gcc4.2-2.6.source/obj/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/.../llvm-gcc4.2-2.6.source/obj' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/.../llvm-gcc4.2-2.6.source/obj' make: *** [all] Error 2 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 14 12:43:23 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 14 Dec 2009 12:43:23 -0600 Subject: [LLVMbugs] [Bug 1974] Anders pass can produce miscompiled code In-Reply-To: Message-ID: <200912141843.nBEIhN8p010191@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=1974 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #4 from Chris Lattner 2009-12-14 12:43:22 --- The andersaa pass is unmaintained and is still experimental, it doesn't make sense to track individual bugs until it basically works. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 14 12:51:52 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 14 Dec 2009 12:51:52 -0600 Subject: [LLVMbugs] [Bug 5778] llvm-gcc4.2-2.6.source fails to build out of the box In-Reply-To: Message-ID: <200912141851.nBEIpqvf010601@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5778 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2009-12-14 12:51:51 --- That's a known broken version of GCC: http://llvm.org/docs/GettingStarted.html#brokengcc http://llvm.org/bugs/show_bug.cgi?id=1056 Please try upgrading to a version of gcc that doesn't miscompile 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 Mon Dec 14 15:12:11 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 14 Dec 2009 15:12:11 -0600 Subject: [LLVMbugs] [Bug 5754] LegalizeVectorTypes asserts on Vector SIGN_EXTEND_INREG In-Reply-To: Message-ID: <200912142112.nBELCBbQ016545@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5754 Micah Villmow changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #4 from Micah Villmow 2009-12-14 15:12:11 --- I've attached a test case that asserts on x86 backend. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 14 16:10:52 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 14 Dec 2009 16:10:52 -0600 Subject: [LLVMbugs] [Bug 5783] New: simplifylibcalls should constant fold strstr Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5783 Summary: simplifylibcalls should constant fold strstr Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu, regehr at cs.utah.edu One of the major things punishing clang on John Regehr's test is that clang doesn't constant fold strstr, here's a trivial case: const char *foo() { return strstr ("22.84.16 (Xaw toolkit)", "-cvs"); } e.g.: http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/077024.c -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 14 18:20:23 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 14 Dec 2009 18:20:23 -0600 Subject: [LLVMbugs] [Bug 5754] LegalizeVectorTypes asserts on Vector SIGN_EXTEND_INREG In-Reply-To: Message-ID: <200912150020.nBF0KNer024662@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5754 Micah Villmow changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #5 from Micah Villmow 2009-12-14 18:20:23 --- This seems to have fixed the issue. I'll file a new bug if I run across anything else. 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 Tue Dec 15 03:37:15 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 15 Dec 2009 03:37:15 -0600 Subject: [LLVMbugs] [Bug 5732] friend class method declaration fails In-Reply-To: Message-ID: <200912150937.nBF9bFRH027244@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5732 Maurice Gittens changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Maurice Gittens 2009-12-15 03:37:14 --- Turns out that this particular crash no longer occurs with current trunk. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 15 11:23:52 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 15 Dec 2009 11:23:52 -0600 Subject: [LLVMbugs] [Bug 5789] New: totally empty .o file generated with -fomit-frame-pointer Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5789 Summary: totally empty .o file generated with -fomit-frame- pointer Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu See below. regehr at john-home:~$ clang -Os -fomit-frame-pointer 003534.c -c regehr at john-home:~$ objdump -d 003534.o 003534.o: file format elf32-i386 regehr at john-home:~$ clang -v clang version 1.1 (trunk 91411) Target: i386-pc-linux-gnu Thread model: posix regehr at john-home:~$ cat 003534.c struct __anonstruct_f1_2 { char *a1[10]; char *a2; char strbuff[20]; }; struct __anonstruct_f2_3 { int *i1; }; struct __anonstruct_NESTED_1 { struct __anonstruct_f1_2 f1; struct __anonstruct_f2_3 f2[5]; }; typedef struct __anonstruct_NESTED_1 NESTED; int afunc (int a___0); NESTED glob1; int afunc (int a___0) { NESTED loc1; char locbuff[30]; char indexbuff[10]; { loc1.f1.a2 = glob1.f1.a2; return (*(loc1.f2[3].i1) + ((int) locbuff[0] - (int) indexbuff[0])); } } /* Checksum = E0526A95 */ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 15 11:41:59 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 15 Dec 2009 11:41:59 -0600 Subject: [LLVMbugs] [Bug 2461] __attribute__ ((noreturn)) in a function parameter In-Reply-To: Message-ID: <200912151741.nBFHfxIX012004@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2461 Charles Davis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #19 from Charles Davis 2009-12-15 11:41:59 --- (In reply to comment #18) > Thank you Charles. You're welcome. > I hope you can take a look at the other affected attributes > (mainly stdcall) please ? > Where do you think I'm headed next? The whole reason I'm even on the CC list for this bug was that my original bug (which related to stdcall) got resolved as a dupe of this one. I'm thinking about reopening it. It's similar, but it's not quite the same as this bug. I take it you're trying to compile Wine, too? (I saw your patch on wine-patches, so I know you're involved with them. Good to see a fellow Wine dev.) That's what got me interested in all this. Anyway, my patch got committed (with test pending), so now I'm going to resolve this 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 Tue Dec 15 11:47:36 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 15 Dec 2009 11:47:36 -0600 Subject: [LLVMbugs] [Bug 5790] New: Internal compiler error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5790 Summary: Internal compiler error Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: llvm-g++ AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu This is a reduction of build libstdc++ for arm. This is very hard to reproduce, something is having a non deterministic behavior. With address randomization this fails 1 out of 3 runs. valgrind reports no errors. The command line to reproduce is cc1plus -fpreprocessed pool_allocator.ii -quiet -dumpbase pool_allocator.cc -march=armv6 -auxbase-strip .libs/pool_allocator.o -g -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -version -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -fPIC -o pool_allocator.s When it fails, the error is -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 15 12:31:30 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 15 Dec 2009 12:31:30 -0600 Subject: [LLVMbugs] [Bug 5789] totally empty .o file generated with -fomit-frame-pointer In-Reply-To: Message-ID: <200912151831.nBFIVUDs013851@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5789 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2009-12-15 12:31:29 --- The compiler is right. You're loading through an undefined pointer, which is undefined behavior. It has realized that your function is not reachable, so it deletes the body. If you use '-emit-llvm -S' you'll see that it has an 'unreachable' instruction in the entry of the llvm ir. The .s file probably just has a label for the function. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 15 13:15:33 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 15 Dec 2009 13:15:33 -0600 Subject: [LLVMbugs] [Bug 5783] simplifylibcalls should optimize various strstr idioms In-Reply-To: Message-ID: <200912151915.nBFJFXei015332@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5783 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED Summary|simplifylibcalls should |simplifylibcalls should |constant fold strstr |optimize various strstr | |idioms --- Comment #2 from Chris Lattner 2009-12-15 13:15:33 --- Implemented here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091214/092629.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 15 14:48:45 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 15 Dec 2009 14:48:45 -0600 Subject: [LLVMbugs] [Bug 5610] gcc is not always slower than clang In-Reply-To: Message-ID: <200912152048.nBFKmjU2020663@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5610 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #13 from Chris Lattner 2009-12-15 14:48:44 --- I committed a small improvement in r91449. This testcase is too insane to really be interesting, closing as wont fix. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 15 18:10:00 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 15 Dec 2009 18:10:00 -0600 Subject: [LLVMbugs] [Bug 5792] New: Dependence on anonymity should grant private linkage Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5792 Summary: Dependence on anonymity should grant private linkage Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rjmccall at apple.com CC: llvmbugs at cs.uiuc.edu The current implementation of anonymous namespaces gives private linkage to all entities semantically contained in an anonymous namespace. This is conservative; I claim we can extend this to all "anonymous" objects, where an object is anonymous iff: 1) It is declared within an anonymous namespace. 2) It is declared static. 3) It is a class or function template specialization with an anonymous template argument. 4) it is a function with an anonymous argument type. The rules of C++ forbid such objects from being referenced outside the current translation unit. In fact, having them be non-private could theoretically cause spurious link errors. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 15 20:19:45 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 15 Dec 2009 20:19:45 -0600 Subject: [LLVMbugs] [Bug 5794] New: not getting trip count of nested loop Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5794 Summary: not getting trip count of nested loop Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Global Analyses AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu, regehr at cs.utah.edu This code: int pmat (int m, int n, double *y __attribute__ ((__unused__))) __attribute__ ((__unused__)); int pmat (int m, int n, double *y __attribute__ ((__unused__))) __attribute__ ((__unused__)); int pmat (int m, int n, double *y __attribute__ ((__unused__))) { int i; int j; int k; { k = 0; i = 0; while (i < m) { j = 0; while (j < n) { k++; j++; } i++; } return (0); } } /* Checksum = FCADC848 */ is compiling to: define i32 @pmat(i32 %m, i32 %n, double* nocapture %y) nounwind readnone { entry: %0 = icmp sgt i32 %m, 0 ; [#uses=1] %.not = xor i1 %0, true ; [#uses=1] %1 = icmp sgt i32 %n, 0 ; [#uses=1] %or.cond = or i1 %.not, %1 ; [#uses=1] br i1 %or.cond, label %bb5, label %bb3 bb3: ; preds = %bb3, %entry %i.010 = phi i32 [ %2, %bb3 ], [ 0, %entry ] ; [#uses=1] %2 = add nsw i32 %i.010, 1 ; [#uses=2] %3 = icmp slt i32 %2, %m ; [#uses=1] br i1 %3, label %bb3, label %bb5 bb5: ; preds = %bb3, %entry ret i32 0 } We should realize that the loop is output free and dead and remove it. This comes from John Regehr 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 Tue Dec 15 20:23:37 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 15 Dec 2009 20:23:37 -0600 Subject: [LLVMbugs] [Bug 5795] New: not merging duplicate blocks Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5795 Summary: not merging duplicate blocks Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Keywords: code-quality Severity: normal Priority: P2 Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu, regehr at cs.utah.edu Many of John's testcases are cases like this: typedef unsigned char __u8; typedef unsigned short __u16; typedef unsigned int __u32; typedef __u8 u_int8_t; typedef __u16 u_int16_t; typedef __u16 __be16; typedef __u32 __be32; union __anonunion_in6_u_168 { __u8 u6_addr8[16]; __be16 u6_addr16[8]; __be32 u6_addr32[4]; }; struct in6_addr { union __anonunion_in6_u_168 in6_u; }; struct in_addr { __be32 s_addr; }; union nf_inet_addr { __u32 all[4]; __be32 ip; __be32 ip6[4]; struct in_addr in; struct in6_addr in6; }; struct __anonstruct_tcp_258 { __be16 port; }; struct __anonstruct_udp_259 { __be16 port; }; struct __anonstruct_icmp_260 { __be16 id; }; struct __anonstruct_dccp_261 { __be16 port; }; struct __anonstruct_sctp_262 { __be16 port; }; struct __anonstruct_gre_263 { __be16 key; }; union nf_conntrack_man_proto { __be16 all; struct __anonstruct_tcp_258 tcp; struct __anonstruct_udp_259 udp; struct __anonstruct_icmp_260 icmp; struct __anonstruct_dccp_261 dccp; struct __anonstruct_sctp_262 sctp; struct __anonstruct_gre_263 gre; }; struct nf_conntrack_man { union nf_inet_addr u3; union nf_conntrack_man_proto u; u_int16_t l3num; }; struct __anonstruct_tcp_266 { __be16 port; }; struct __anonstruct_udp_267 { __be16 port; }; struct __anonstruct_icmp_268 { u_int8_t type; u_int8_t code; }; struct __anonstruct_dccp_269 { __be16 port; }; struct __anonstruct_sctp_270 { __be16 port; }; struct __anonstruct_gre_271 { __be16 key; }; union __anonunion_u_265 { __be16 all; struct __anonstruct_tcp_266 tcp; struct __anonstruct_udp_267 udp; struct __anonstruct_icmp_268 icmp; struct __anonstruct_dccp_269 dccp; struct __anonstruct_sctp_270 sctp; struct __anonstruct_gre_271 gre; }; struct __anonstruct_dst_264 { union nf_inet_addr u3; union __anonunion_u_265 u; u_int8_t protonum; u_int8_t dir; }; struct nf_conntrack_tuple { struct nf_conntrack_man src; struct __anonstruct_dst_264 dst; }; void nf_ct_dump_tuple (struct nf_conntrack_tuple const *t); void nf_ct_dump_tuple (struct nf_conntrack_tuple const *t) { struct nf_conntrack_tuple const *_cil_inline_tmp_3842; struct nf_conntrack_tuple const *_cil_inline_tmp_3843; { switch ((int) t->src.l3num) { case 2:; _cil_inline_tmp_3842 = t; break; case 10:; _cil_inline_tmp_3843 = t; break; } return; } } /* Checksum = 201B2224 */ which we compile down to: switch i32 %2, label %return [ i32 2, label %bb i32 10, label %bb1 ] bb: ; preds = %entry ret void bb1: ; preds = %entry ret void return: ; preds = %entry ret void } If those return blocks were merged, the switch would be deleted. This probably doesn't occur in real code though. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 16 00:14:45 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 00:14:45 -0600 Subject: [LLVMbugs] [Bug 5797] New: msp430 backend: possible assembly generation error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5797 Summary: msp430 backend: possible assembly generation error Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: asl at math.spbu.ru, llvmbugs at cs.uiuc.edu Clang can turn the attached .i file into msp430 assembly, but then this can't be linked into an elf file. regehr at john-home:~$ clang -ccc-host-triple msp430-generic-generic -ccc-clang-archs msp430 -x c foo.i -w -S -Os regehr at john-home:~$ msp430-gcc -Os -mmcu=msp430x1611 foo.s -o foo.elfmsp430-ld: section .rodata [0000466c -> 0000466d] overlaps section .data [0000466c -> 0000468b] regehr at john-home:~$ msp430-gcc -v Reading specs from /usr/bin/../lib/gcc-lib/msp430/3.2.3/specs Configured with: /home/xubuntos/tinyos-toolchain-packages/sources/msp430-build-tinyos-2.1/build/gcc-3.2.3/configure --target=msp430 --prefix=/home/xubuntos/tinyos-toolchain-packages/sources/msp430-build-tinyos-2.1/packages/usr --program-prefix=msp430- Thread model: single gcc version 3.2.3 regehr at john-home:~$ msp430-ld -v GNU ld version 2.17 regehr at john-home:~$ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 16 01:35:31 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 01:35:31 -0600 Subject: [LLVMbugs] [Bug 5721] test failure on test/CodeGen/Thumb2/large-stack.ll In-Reply-To: Message-ID: <200912160735.nBG7ZVht011345@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5721 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Nick Lewycky 2009-12-16 01:35:31 --- Fixed in r91521. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 16 02:44:40 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 02:44:40 -0600 Subject: [LLVMbugs] [Bug 3758] SmallVector::grow/swap should be shared for POD T's In-Reply-To: Message-ID: <200912160844.nBG8ie4N019288@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3758 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2009-12-16 02:44:39 --- This is done, in a series of patches leading up to r91529 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 16 02:45:08 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 02:45:08 -0600 Subject: [LLVMbugs] [Bug 5800] New: [tblgen] invalid vtable initialization of object Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5800 Summary: [tblgen] invalid vtable initialization of object Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: daniel at zuster.org CC: llvmbugs at cs.uiuc.edu, andersca at mac.com, mrs at apple.com This code shouldn't link and is the root cause of tblgen crashing on X86, when it first tries to load from the vtable. -- ddunbar at giles:tmp$ cat t.cpp #include class RecTy { }; class IntRecTy : public RecTy { public: virtual int *convertValue(int *BI); }; void *f0() { return new IntRecTy(); } int main() { void **p = (void**) f0(); printf("p[0] = %p, p[1] = %p\n", p[0], p[1]); return 0; } ddunbar at giles:tmp$ clang++ t.cpp ddunbar at giles:tmp$ ./a.out p[0] = 0x0, p[1] = 0x0 ddunbar at giles:tmp$ g++ t.cpp Undefined symbols: "vtable for IntRecTy", referenced from: IntRecTy::IntRecTy()in ccXu4I8R.o ld: symbol(s) not found collect2: ld returned 1 exit status ddunbar at giles:tmp$ -- -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 16 03:00:20 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 03:00:20 -0600 Subject: [LLVMbugs] [Bug 5797] msp430 backend: possible assembly generation error In-Reply-To: Message-ID: <200912160900.nBG90KnD026050@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5797 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Anton Korobeynikov 2009-12-16 03:00:19 --- This is the problem with msp430-ld-provided linker scripts - basically they allowed section .rodata, but did not specify, where (in the binary) it should go. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 16 03:25:55 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 03:25:55 -0600 Subject: [LLVMbugs] [Bug 5801] New: clang doesn't codegen calls to memset to use llvm.memset Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5801 Summary: clang doesn't codegen calls to memset to use llvm.memset Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Keywords: code-quality Severity: normal Priority: P2 Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu, regehr at cs.utah.edu In this testcase, llvm-gcc is able to optimize away the entire function but clang can't. The difference is that llvm-gcc compiles the user call to memset to use the intrinsic. This exposes the intrinsic to the first run of scalarrepl, where clang doesn't get to hack on it until simplifylibcalls handles it. ---- typedef unsigned int size_t; void _gcry_burn_stack (int bytes); extern void * memset (void *__s, int __c, size_t __n); void _gcry_burn_stack (int bytes) { char buf[64]; int _cil_inline_tmp_0; { memset ((void *) (buf), 0, 64U); bytes = (int) ((unsigned int) bytes - 64U); if (bytes > 0) { _cil_inline_tmp_0 = bytes; if (bytes > 0) { _gcry_burn_stack (bytes); } } return; } } ---- $ llvm-gcc t.c -S -o - -m32 -march=core2 -mtune=core2 -fomit-frame-pointer -fno-stack-protector -O0 -emit-llvm | opt -O3 -S $ clang t.c -S -o - -m32 -march=core2 -mtune=core2 -fomit-frame-pointer -fno-stack-protector -O0 -emit-llvm | opt -O3 -S This comes from John's code size comparison 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 Wed Dec 16 04:35:03 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 04:35:03 -0600 Subject: [LLVMbugs] [Bug 5802] New: llc infloops on sha256.c at -O1 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5802 Summary: llc infloops on sha256.c at -O1 Product: new-bugs Version: trunk 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 With r91521 clang -O2 doesn't finish generating code for sha256.c from ClamAV. clang, and opt -O2 work, however llc hangs. llc -O0 works, but llc -O1 or llc -O2 doesn't finish (waited 3 minutes). Bytecode attached. llc -O1 --debug outputs lots of these messages (which seem to replace and -> zero_extend -> and in an endless cycle): Replacing.2 0x16695e0: i64 = and 0x1683cb0, 0x16869f0 With: 0x167f210: i64 = zero_extend 0x1669200 Replacing.3 0x167f210: i64 = zero_extend 0x1669200 With: 0x16695e0: i64 = and 0x16869f0, 0x1683cb0 Replacing.2 0x16869f0: i64 = zero_extend 0x166bfd8 With: 0x163a220: i64 = any_extend 0x166bfd8 Replacing.2 0x16695e0: i64 = and 0x163a220, 0x1683cb0 With: 0x167f210: i64 = zero_extend 0x1669200 Replacing.3 0x167f210: i64 = zero_extend 0x1669200 With: 0x16695e0: i64 = and 0x1683cb0, 0x163a220 Replacing.2 0x1683cb0: i64 = zero_extend 0x166bfd8 With: 0x16869f0: i64 = any_extend 0x166bfd8 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 16 06:27:35 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 06:27:35 -0600 Subject: [LLVMbugs] [Bug 5804] New: building with STL in parallel mode gets tblgen stuck Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5804 Summary: building with STL in parallel mode gets tblgen stuck Product: new-bugs Version: trunk Platform: PC URL: https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1779 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 export CXXFLAGS="-O2 -W -Wformat=2 -Wswitch -Wshadow -Wwrite-strings -Wuninitialized -Wall -pipe -mtune=core2 -march=core2 -fomit-frame-pointer -ffast-math -msse2 -msse -mmmx -mfpmath=sse -D_FORTIFY_SOURCE=2 -Wpointer-arith -fstack-protector -Wstack-protector -Wextra -Wcast-align -Wcast-qual -Wdisabled-optimization -Wendif-labels -Wfloat-equal -Wformat-nonliteral -Winline -Wpointer-arith -Wundef -D_GLIBCXX_PARALLEL -fopenmp" export LDFLAGS=-lgomp ./llvm/configure make ENABLE_OPTIMIZED=1 -j4 when generating the X86 .inc files, tblgen gets stuck for minutes here: llvm[0]: Building X86.td register names with tblgen llvm[0]: Building X86.td register information header with tblgen llvm[0]: Building X86.td register info implementation with tblgen llvm[0]: Building X86.td instruction names with tblge If I run 'make' instead of 'make -j4' then it does make some progress, however it is very very slow. This bug was originally reported by Nigel Horne for ClamAV (which includes LLVM in the git version now). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 16 07:49:07 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 07:49:07 -0600 Subject: [LLVMbugs] [Bug 5806] New: it should be possible to build LLVM without dlopen() support Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5806 Summary: it should be possible to build LLVM without dlopen() support Product: new-bugs Version: trunk 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 Currently when LLVM is built on *nix, it requires dlopen(). However there may be cases when the dlopen() support is completely unused in a program that uses LLVM (i.e. DisableSymbolSearching, no plugins, etc.). In that case dlopen() adds additional complications (need to pass -ldl on Linux, nothing and FreeBSD, and who knows what on HP-UX, etc.). Since dlopen is not needed, that seems like unnecessary complication. Also EngineBuilder::create returns NULL if it can't dlopen self. However the JIT works just fine w/o dlopen. I suggest LLVM to have a ./configure --disable-dlopen to disable dlopen support, in which case EngineBuilder should still work, and in DynamicLibrary.cpp it should return NULL/error when trying to dlopen something. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 16 11:36:16 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 11:36:16 -0600 Subject: [LLVMbugs] [Bug 5807] New: likely wrong code bug Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5807 Summary: likely wrong code bug Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu In the C code below, x is incremented each time foo() is called. In the LLVM code it is not. regehr at john-home:~$ clang -Os llvm-bad-loop.c -S -emit-llvm -o - ; ModuleID = 'llvm-bad-loop.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple = "i386-pc-linux-gnu" @y = common global i32 0, align 4 ; [#uses=1] define i32 @foo(i32 %x) nounwind readnone optsize { entry: %shr = ashr i32 %x, 7 ; [#uses=1] ret i32 %shr } define i32 @main() noreturn nounwind optsize { entry: br label %while.body while.body: ; preds = %entry, %while.body volatile store i32 undef, i32* @y br label %while.body } regehr at john-home:~$ cat llvm-bad-loop.c int foo (int x) { return x>>7; } volatile int y; int main (void) { unsigned int x; while (1) { y = foo (x++); } } regehr at john-home:~$ clang -v clang version 1.1 (trunk 91411) Target: i386-pc-linux-gnu Thread model: posix -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 16 11:37:10 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 11:37:10 -0600 Subject: [LLVMbugs] [Bug 5807] likely wrong code bug In-Reply-To: Message-ID: <200912161737.nBGHbACN023051@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5807 John Regehr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from John Regehr 2009-12-16 11:37:10 --- Ack nevermind, sorry, bad C 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 Wed Dec 16 12:52:50 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 12:52:50 -0600 Subject: [LLVMbugs] [Bug 5800] [tblgen] invalid vtable initialization of object In-Reply-To: Message-ID: <200912161852.nBGIqoiM025957@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5800 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #7 from Douglas Gregor 2009-12-16 12:52:50 --- Fixed here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091214/025503.html Chris and Anders: we *could* turn off the zero-initialization code in C++98/03, since that text wasn't actually in the standard. However, in the absence of some important benchmark that slows down because of the zero-initialization code, I'd like to keep C++98/03 and C++0x consistent in this regard. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 16 18:15:02 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 18:15:02 -0600 Subject: [LLVMbugs] [Bug 5801] clang doesn't codegen calls to memset to use llvm.memset In-Reply-To: Message-ID: <200912170015.nBH0F2Cl005542@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5801 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sharparrow1 at yahoo.com Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Eli Friedman 2009-12-16 18:15:01 --- Fixed in r91573. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 16 18:40:59 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 18:40:59 -0600 Subject: [LLVMbugs] [Bug 5802] llc infloops on sha256.c at -O1 In-Reply-To: Message-ID: <200912170040.nBH0ex63006712@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5802 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Evan Cheng 2009-12-16 18:40:58 --- I've reverted the dag combine transform: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091214/092714.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 16 21:36:49 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 21:36:49 -0600 Subject: [LLVMbugs] [Bug 5813] New: msp430 backend: Error: operand out of range Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5813 Summary: msp430 backend: Error: operand out of range Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: asl at math.spbu.ru, llvmbugs at cs.uiuc.edu This is seen on Edwin Foo's branch-- so not sure if I should report it here? Anyway see below. Sorry for the gross testcase, my reducers didn't get any further than this. regehr at john-home:~/volatile/bugs/tmp247$ clang -v clang version 1.1 (trunk 114) Target: i386-pc-linux-gnu Thread model: posix regehr at john-home:~/volatile/bugs/tmp247$ clang -Os -w -ccc-host-triple msp430-elf -c small.c /tmp/cc-kZIVEF.s: Assembler messages: /tmp/cc-kZIVEF.s:15: Error: operand out of range: 523 /tmp/cc-kZIVEF.s:19: Error: operand out of range: 517 clang: error: assembler command failed with exit code 1 (use -v to see invocation) regehr at john-home:~/volatile/bugs/tmp247$ cat small.c typedef signed char int8_t; typedef int int32_t; typedef unsigned short int uint16_t; typedef unsigned int uint32_t; struct S0 { uint32_t f1; uint32_t f2; }; struct S1 { int8_t f5; }; struct S2 { volatile struct S1 f7; }; struct S1 g_3 = { 1L }; int32_t g_10; int32_t *g_26 = &g_10; const volatile struct S2 g_74 = { 1L }; struct S0 g_83 = { -7L, 0L }; struct S0 *volatile g_84 = &g_83; int32_t *g_123 = &g_10; int32_t **g_122 = &g_123; int32_t g_175; int32_t ***volatile g_194 = &g_122; int32_t *func_38 (int32_t * p_39); struct S0 func_40 (uint16_t p_41); int int323 (const int8_t p_24, int32_t * p_25) { int32_t **l_27 = &g_26; int32_t l_95; const struct S1 *l_98 = &g_3; if (0 == *l_27) { } else { int32_t l_170; int32_t *volatile l_176 = &g_175; if (p_24) { func_38 (func_38 (func_38 (&l_170))); if (func_44 (l_98, &g_3, &g_123)) if (+func_28 (0) || func_28 (1L)) { } else *g_122 = func_38 (func_38 (0)); for (g_83.f1; g_83.f1; g_83.f1 = safe (g_83.f1, 1)) { } struct S0 *l_208 = &g_83; *l_208 = func_40 (0); if (*l_176 != (*g_122 != 0)) { int32_t *l = &l_95; l = func_38 (0); l = func_38 (func_38 (func_38 (func_38 (**g_194)))); } } } return 0; } int32_t * func_38 (int32_t * p_39) { *g_84 = func_40 (g_74.f7.f5); return 0; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 16 22:12:11 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 22:12:11 -0600 Subject: [LLVMbugs] [Bug 5814] New: msp430 backend: memory safety problem Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5814 Summary: msp430 backend: memory safety problem Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: asl at math.spbu.ru, llvmbugs at cs.uiuc.edu Valgrind indicates that there is likely some funny stuff going on with memory management here. regehr at john-home:~/volatile/bugs/tmp248$ clang -Os -w -ccc-host-triple msp430-elf -c small.c 0 clang 0x0926c71a 1 clang 0x0926c58f 2 0x00cec400 __kernel_sigreturn + 0 3 clang 0x081f6123 4 clang 0x086796c8 5 clang 0x08678ba4 6 clang 0x091b176f 7 clang 0x0904968a 8 clang 0x090491e2 9 clang 0x09048093 10 clang 0x09047897 11 clang 0x090472e9 12 clang 0x091e7603 13 clang 0x091e7346 14 clang 0x091e6fc5 15 clang 0x08142282 16 clang 0x08141356 17 clang 0x08393127 18 clang 0x0806dc86 19 clang 0x0806d919 20 clang 0x0804ffc9 21 clang 0x08054a6f main + 267 22 libc.so.6 0x0014cb56 __libc_start_main + 230 23 clang 0x0804e961 Stack dump: 0. Program arguments: /home/regehr/llvm-msp430/build/bin/clang -cc1 -triple msp430-elf- -S -disable-free -main-file-name small.c -mrelocation-model static -mdisable-fp-elim -Os -w -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-1eGmXx.s -x c small.c 1. Program arguments: -triple msp430-elf- -S -disable-free -main-file-name small.c -mrelocation-model static -mdisable-fp-elim -Os -w -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-1eGmXx.s -x c small.c clang: error: compiler command failed due to signal 11 (use -v to see invocation) regehr at john-home:~/volatile/bugs/tmp248$ clang -v clang version 1.1 (trunk 114) Target: i386-pc-linux-gnu Thread model: posix regehr at john-home:~/volatile/bugs/tmp248$ cat small.c typedef int int32_t; struct S1 { int32_t f0; }; const int32_t ** func_41 (int32_t * p_42) { struct S1 l_44 = { 0xF963L }; struct S1 *l_45 = &l_44; *l_45 = l_44; return 0; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 16 22:18:09 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 22:18:09 -0600 Subject: [LLVMbugs] [Bug 5815] New: msp430 backend: warning: internal error: unsupported relocation error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5815 Summary: msp430 backend: warning: internal error: unsupported relocation error Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: asl at math.spbu.ru, llvmbugs at cs.uiuc.edu regehr at john-home:~/volatile/bugs/tmp249$ clang -Os -w -ccc-host-triple msp430-elf -c small.c regehr at john-home:~/volatile/bugs/tmp249$ clang -ccc-host-triple msp430-elf -Wl,-m,msp430x1611 -L/home/regehr/llvm-msp430/build/msp430/lib -L/home/regehr /llvm-msp430/build/lib/msp430 -o small.elf small.o small.o: In function `int324': small.c:(.text+0xa): warning: internal error: unsupported relocation error regehr at john-home:~/volatile/bugs/tmp249$ clang -v clang version 1.1 (trunk 114) Target: i386-pc-linux-gnu Thread model: posix regehr at john-home:~/volatile/bugs/tmp249$ cat small.c typedef int int32_t; typedef unsigned char uint8_t; int32_t g_5; int32_t *volatile g_4 = &g_5; uint8_t g = 1; int32_t g_38 = 1; int324 (int32p_35) { int32_t *l_39 = &g_38; *l_39 |= *g_4; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Wed Dec 16 23:03:53 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Wed, 16 Dec 2009 23:03:53 -0600 Subject: [LLVMbugs] [Bug 5816] New: Scalarrepl leads to nasty results with function equivalent to fixed-size memmove Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5816 Summary: Scalarrepl leads to nasty results with function equivalent to fixed-size memmove 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, regehr at cs.utah.edu C Testcase: #include void a(char* a, char* b) { char c[100]; memcpy(c, a, sizeof(c)); memcpy(b, c, sizeof(c)); } IR Testcase (C testcase run through -mem2reg): define void @a(i8* %a, i8* %b) nounwind { entry: %c = alloca [100 x i8], align 1 ; <[100 x i8]*> [#uses=2] %arraydecay = getelementptr inbounds [100 x i8]* %c, i32 0, i32 0 ; [#uses=1] call void @llvm.memcpy.i32(i8* %arraydecay, i8* %a, i32 100, i32 1) %arraydecay2 = getelementptr inbounds [100 x i8]* %c, i32 0, i32 0 ; [#uses=1] call void @llvm.memcpy.i32(i8* %b, i8* %arraydecay2, i32 100, i32 1) ret void } declare void @llvm.memcpy.i32(i8* nocapture, i8* nocapture, i32, i32) nounwind Result of running -scalarrepl: define void @a(i8* %a, i8* %b) nounwind { entry: %0 = bitcast i8* %a to i800* ; [#uses=1] %srcval1 = load i800* %0, align 1 ; [#uses=1] %1 = bitcast i8* %b to i800* ; [#uses=1] store i800 %srcval1, i800* %1, align 1 ret void } The i800 load+store turns into completely nasty code, essentially an expanded memmove. Testcase derived from pattern seen in "embarassing" code examples. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 17 04:38:42 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 17 Dec 2009 04:38:42 -0600 Subject: [LLVMbugs] [Bug 3910] Many tests failing with ruby 1.9.1(r23098) compiled with clang( r68030) In-Reply-To: Message-ID: <200912171038.nBHAcgXj013603@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3910 Nuno Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nunoplopes at sapo.pt Status|NEW |RESOLVED Resolution| |INVALID --- Comment #5 from Nuno Lopes 2009-12-17 04:38:42 --- This bug is not really useful. Please open one bug report with a test case for each issue you isolate. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 17 05:35:38 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 17 Dec 2009 05:35:38 -0600 Subject: [LLVMbugs] [Bug 3962] Invalid uses of restrict not diagnosed In-Reply-To: Message-ID: <200912171135.nBHBZch5015687@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3962 Nuno Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nunoplopes at sapo.pt Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Nuno Lopes 2009-12-17 05:35:37 --- fixed in r91601. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 17 08:43:24 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 17 Dec 2009 08:43:24 -0600 Subject: [LLVMbugs] [Bug 5817] New: sema crashes when initializing an array where the type was defined within a typedef Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5817 Summary: sema crashes when initializing an array where the type was defined within a typedef Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nunoplopes at sapo.pt CC: llvmbugs at cs.uiuc.edu $ cat a.cpp typedef int type[][2]; const type foo = {0}; $ clang -fsyntax-only a.cpp clang: include/llvm/Support/Casting.h:199: typename llvm::cast_retty::ret_type llvm::cast(const Y&) [with X = clang::ArrayTypeLoc, Y = clang::TypeLoc]: Assertion `isa(Val) && "cast() argument of incompatible type!"' 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 Thu Dec 17 14:49:56 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 17 Dec 2009 14:49:56 -0600 Subject: [LLVMbugs] [Bug 5790] Internal compiler error In-Reply-To: Message-ID: <200912172049.nBHKnuUW003471@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5790 Rafael ??vila de Esp??ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #9 from Rafael ??vila de Esp??ndola 2009-12-17 14:49:55 --- *** This bug has been marked as a duplicate of bug 5770 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 17 15:48:28 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 17 Dec 2009 15:48:28 -0600 Subject: [LLVMbugs] [Bug 5735] JIT should not codegen available_externally functions. In-Reply-To: Message-ID: <200912172148.nBHLmS3t005684@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5735 Jeffrey Yasskin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #2 from Jeffrey Yasskin 2009-12-17 15:48:28 --- Fixed by r91626. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 17 16:38:16 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 17 Dec 2009 16:38:16 -0600 Subject: [LLVMbugs] [Bug 5822] New: StringRef::endswith compiles into gross code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5822 Summary: StringRef::endswith compiles into gross code Product: libraries Version: 1.0 Platform: PC OS/Version: All Status: NEW Keywords: code-quality Severity: normal Priority: P2 Component: Support Libraries AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu, daniel at zuster.org This code: #include "llvm/ADT/StringRef.h" bool test(llvm::StringRef R) { return R.endswith("x"); } bool test2(llvm::StringRef R) { return !R.empty() && R.back() == 'x'; } compiles into: define zeroext i8 @_Z4testN4llvm9StringRefE(i8* %R.0, i64 %R.1) nounwind readonly ssp { entry: %0 = add i64 %R.1, -1 ; [#uses=2] %1 = icmp ult i64 %0, %R.1 ; [#uses=1] %iftmp.50.0.i.i.i = select i1 %1, i64 %0, i64 %R.1 ; [#uses=4] %2 = icmp ugt i64 %iftmp.50.0.i.i.i, %R.1 ; [#uses=1] %iftmp.51.0.i.i.i = select i1 %2, i64 %iftmp.50.0.i.i.i, i64 %R.1 ; [#uses=2] %3 = icmp ult i64 %iftmp.51.0.i.i.i, %R.1 ; [#uses=1] %iftmp.50.0.i5.i.i = select i1 %3, i64 %iftmp.51.0.i.i.i, i64 %R.1 ; [#uses=1] %4 = sub i64 %iftmp.50.0.i5.i.i, %iftmp.50.0.i.i.i ; [#uses=1] %5 = icmp eq i64 %4, 1 ; [#uses=1] br i1 %5, label %bb.i.i, label %_ZNK4llvm9StringRef8endswithES0_.exit bb.i.i: ; preds = %entry %6 = getelementptr inbounds i8* %R.0, i64 %iftmp.50.0.i.i.i ; [#uses=1] %lhsv = load i8* %6 ; [#uses=1] %7 = icmp eq i8 %lhsv, 120 ; [#uses=1] %retval.i.i = zext i1 %7 to i8 ; [#uses=1] ret i8 %retval.i.i _ZNK4llvm9StringRef8endswithES0_.exit: ; preds = %entry ret i8 0 } which is pretty gross. This is due to instcombine not zapping the max's, which may be due to StringRef being written wrong (e.g. using unsigned instead of signed integers). GCC also generates nasty code. This should compile down into: return !R.empty() && R.back() == 'x'; which codegen's to: define zeroext i8 @_Z5test2N4llvm9StringRefE(i8* %R.0, i64 %R.1) ssp { entry: %0 = icmp eq i64 %R.1, 0 ; [#uses=1] br i1 %0, label %bb8, label %_ZNK4llvm9StringRef4backEv.exit _ZNK4llvm9StringRef4backEv.exit: ; preds = %entry %1 = add i64 %R.1, -1 ; [#uses=1] %2 = getelementptr inbounds i8* %R.0, i64 %1 ; [#uses=1] %3 = load i8* %2, align 1 ; [#uses=1] %4 = icmp eq i8 %3, 120 ; [#uses=1] %retval = zext i1 %4 to i8 ; [#uses=1] ret i8 %retval bb8: ; preds = %entry ret i8 0 } In .s, this is the difference: __Z4testN4llvm9StringRefE: Leh_func_begin1: leaq -1(%rsi), %rax movq %rsi, %rcx cmpq %rsi, %rax cmovae %rsi, %rax cmpq %rsi, %rax cmova %rax, %rcx cmpq %rsi, %rcx cmovae %rsi, %rcx subq %rax, %rcx cmpq $1, %rcx jne LBB1_2 cmpb $120, (%rdi,%rax) sete %al movzbl %al, %eax ret LBB1_2: xorl %eax, %eax ret vs __Z5test2N4llvm9StringRefE: Leh_func_begin2: testq %rsi, %rsi je LBB2_2 cmpb $120, -1(%rsi,%rdi) sete %al movzbl %al, %eax ret LBB2_2: xorl %eax, %eax ret -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Thu Dec 17 17:26:12 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Thu, 17 Dec 2009 17:26:12 -0600 Subject: [LLVMbugs] [Bug 5824] New: clang codegen introduces extra struct copy calling function returning struct Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5824 Summary: clang codegen introduces extra struct copy calling function returning struct Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu Testcase: struct a { int a[10]; }; struct a a(); struct a b() { return a(); } Output (clang -x c - -o - -S -emit-llvm): define void @b(%struct.a* noalias sret %agg.result) nounwind { entry: %tmp = alloca %struct.a ; <%struct.a*> [#uses=2] call void (%struct.a*, ...)* @a(%struct.a* noalias sret %tmp) %tmp1 = bitcast %struct.a* %agg.result to i8* ; [#uses=1] %tmp2 = bitcast %struct.a* %tmp to i8* ; [#uses=1] call void @llvm.memcpy.i32(i8* %tmp1, i8* %tmp2, i32 40, i32 4) ret void } The memcpy isn't necessary and shouldn't be there. This affects correctness in some edge cases in C++, and leads to inefficient code in other cases. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 18 05:03:40 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 18 Dec 2009 05:03:40 -0600 Subject: [LLVMbugs] [Bug 5827] New: clang generates bogus unwind code for indirect function call Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5827 Summary: clang generates bogus unwind code for indirect function call Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nunoplopes at sapo.pt CC: llvmbugs at cs.uiuc.edu $ cat a.cpp typedef int int64_t __attribute__ ((__mode__ (__DI__))); typedef int64_t UTextMapOffsetToNative(); class RuleBasedBreakIterator { UTextMapOffsetToNative *mapOffsetToNative; int checkDictionary(int x); }; class UStack { public: UStack(int); virtual ~UStack(); }; int RuleBasedBreakIterator::checkDictionary(int x) { UStack breaks(0); return (int)(x ? 0 : mapOffsetToNative()); } $ clang -S -emit-llvm -o - a.cpp | llc -o a.o (ok) $ clang -O2 -S -emit-llvm -o - a.cpp | llc -o a.o Invoke result does not dominate all uses! %call = invoke i64 %tmp5() to label %cond.end unwind label %ehcleanup ; [#uses=1] %extract.t = trunc i64 %call to i32 ; [#uses=1] Broken module found, compilation aborted! Stack dump: 0. Program arguments: llc -o a.o 1. Running pass 'Module Verifier' on function '@_ZN22RuleBasedBreakIterator15checkDictionaryEi' Aborted the weird part: $ clang -S -emit-llvm -o - a.cpp | opt -std-compile-opts | llc -O2 -o a.o (ok) $ clang -O2 -c -o - a.cpp clang: SelectionDAGBuilder.cpp:706: llvm::SDValue llvm::SelectionDAGBuilder::getValue(const llvm::Value*): Assertion `InReg && "Value not in map!"' failed. Stack dump: 2. Code generation 3. Running pass 'X86 DAG->DAG Instruction Selection' on function '@_ZN22RuleBasedBreakIterator15checkDictionaryEi Is clang running any optimization pass at -O2 that is not included in opt -std-compile-opts? If not, there's something weird going on.. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 18 05:34:31 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 18 Dec 2009 05:34:31 -0600 Subject: [LLVMbugs] [Bug 5828] New: Fails to build from source on mips Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5828 Summary: Fails to build from source on mips Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: arthur.loiret at gmail.com CC: llvmbugs at cs.uiuc.edu Hello, LLVM fails to build on mips: make[4]: Entering directory `/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/utils/unittest/UnitTestMain' /build/buildd/llvm-snapshot-20091207/autoconf/mkinstalldirs /build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/utils/unittest/UnitTestMain/Release > /dev/null /bin/date > /build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/utils/unittest/UnitTestMain/Release/.dir llvm[4]: Compiling TestMain.cpp for Release build if mips-linux-gnu-g++ -I/build/buildd/llvm-snapshot-20091207/utils/unittest/googletest/include -Wno-missing-field-initializers -Wno-variadic-macros -I/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/include -I/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/utils/unittest/UnitTestMain -I/build/buildd/llvm-snapshot-20091207/include -I/build/buildd/llvm-snapshot-20091207/utils/unittest/UnitTestMain -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEBIAN_INFO='" (Debian 20091207-1)"' -O2 -fomit-frame-pointer -fno-exceptions -fPIC -Woverloaded-virtual -g -O2 -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -c -MMD -MP -MF "/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/utils/unittest/UnitTestMain/Release/TestMain.d.tmp" -MT "/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/utils/unittest/UnitTestMain/Release/TestMain.o" -MT "/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/utils/unittest/UnitTestMain/Release/TestMain.d" /build/buildd/llvm-snapshot-20091207/utils/unittest/UnitTestMain/TestMain.cpp -o /build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/utils/unittest/UnitTestMain/Release/TestMain.o ; \ then /bin/mv -f "/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/utils/unittest/UnitTestMain/Release/TestMain.d.tmp" "/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/utils/unittest/UnitTestMain/Release/TestMain.d"; else /bin/rm "/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/utils/unittest/UnitTestMain/Release/TestMain.d.tmp"; exit 1; fi llvm[4]: Building Release Archive Library libUnitTestMain.a /bin/rm -f /build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/Release/lib/libUnitTestMain.a ar cru /build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/Release/lib/libUnitTestMain.a /build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/utils/unittest/UnitTestMain/Release/TestMain.o ranlib /build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/Release/lib/libUnitTestMain.a make[4]: Leaving directory `/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/utils/unittest/UnitTestMain' make[3]: Leaving directory `/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/utils/unittest' make[2]: Leaving directory `/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/utils' make[2]: Entering directory `/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/lib/VMCore' /build/buildd/llvm-snapshot-20091207/autoconf/mkinstalldirs /build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/lib/VMCore/Release > /dev/null /bin/date > /build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/lib/VMCore/Release/.dir llvm[2]: Building Intrinsics.gen.tmp from Intrinsics.td /build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/Release/bin/tblgen -I /build/buildd/llvm-snapshot-20091207/lib/VMCore -I /build/buildd/llvm-snapshot-20091207/include -I /build/buildd/llvm-snapshot-20091207/include -I /build/buildd/llvm-snapshot-20091207/lib/Target /build/buildd/llvm-snapshot-20091207/include/llvm/Intrinsics.td -o /build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/lib/VMCore/Release/Intrinsics.gen.tmp -gen-intrinsic make[2]: *** [/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/lib/VMCore/Release/Intrinsics.gen.tmp] Segmentation fault make[2]: Leaving directory `/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot/lib/VMCore' make[1]: *** [all] Error 1 make[1]: Leaving directory `/build/buildd/llvm-snapshot-20091207/build-llvm-snapshot' make: *** [/build/buildd/llvm-snapshot-20091207/debian/stamps/build-stamp-llvm-core] Error 2 Full build log: https://buildd.debian.org/fetch.cgi?pkg=llvm-snapshot&arch=mips&ver=20091207-1&stamp=1261021074&file=log&as=raw Full report: https://buildd.debian.org/~luk/status/package.php?p=llvm-snapshot -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 18 19:06:56 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 18 Dec 2009 19:06:56 -0600 Subject: [LLVMbugs] [Bug 5835] New: tailcallopt produces non-PIC relocation on linux. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5835 Summary: tailcallopt produces non-PIC relocation on linux. Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: jyasskin at google.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=3961) --> (http://llvm.org/bugs/attachment.cgi?id=3961) Sample .ll file $ llvm-as mandelbrot.ll $ llc -tailcallopt -relocation-model=pic mandelbrot.bc -o mandelbrot.s $ gcc mandelbrot.s -o mandelbrot.so -fPIC -shared -fno-strict-aliasing /usr/bin/ld: /tmp/cctwYEcT.o: relocation R_X86_64_PC32 against `pixel' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4) $ /usr/bin/ld -v GNU ld (GNU Binutils for Ubuntu) 2.18.0.20080103 It works without -tailcallopt: $ llc -relocation-model=pic mandelbrot.bc -o mandelbrot.s $ gcc mandelbrot.s -o mandelbrot.so -fPIC -shared -fno-strict-aliasing $ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Fri Dec 18 19:32:54 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Fri, 18 Dec 2009 19:32:54 -0600 Subject: [LLVMbugs] [Bug 5815] msp430 backend: warning: internal error: unsupported relocation error In-Reply-To: Message-ID: <200912190132.nBJ1WsOj015581@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5815 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Anton Korobeynikov 2009-12-18 19:32:53 --- Fixed in r91739 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Dec 19 00:32:24 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 19 Dec 2009 00:32:24 -0600 Subject: [LLVMbugs] [Bug 5837] New: loop rotate (really ssaupdate) inserts many duplicate phi nodes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5837 Summary: loop rotate (really ssaupdate) inserts many duplicate phi nodes Product: libraries Version: 1.0 Platform: PC OS/Version: All Status: NEW Keywords: code-quality Severity: normal Priority: P2 Component: Transformation Utilities AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu Loop rotate transforms this input testcase with no phi nodes to this: for.body: ; preds = %bb.nph, %for.cond %j.05 = phi i64 [ 1, %bb.nph ], [ %j.0, %for.cond ] ; [#uses=1] %j.04 = phi i64 [ 1, %bb.nph ], [ %j.0, %for.cond ] ; [#uses=1] %j.03 = phi i64 [ 1, %bb.nph ], [ %j.0, %for.cond ] ; [#uses=1] %j.02 = phi i64 [ 1, %bb.nph ], [ %j.0, %for.cond ] ; [#uses=1] %arrayidx = getelementptr inbounds double* %G, i64 %j.05 ; [#uses=1] %tmp3 = load double* %arrayidx ; [#uses=1] %sub = sub i64 %j.04, 1 ; [#uses=1] %arrayidx6 = getelementptr inbounds double* %G, i64 %sub ; [#uses=1] This can't be good. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sat Dec 19 01:02:24 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sat, 19 Dec 2009 01:02:24 -0600 Subject: [LLVMbugs] [Bug 5827] instcombine phi slicing crash on phi of invoke In-Reply-To: Message-ID: <200912190702.nBJ72OLA027412@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5827 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED Summary|clang generates bogus unwind|instcombine phi slicing |code for indirect function |crash on phi of invoke |call | --- Comment #10 from Chris Lattner 2009-12-19 01:02:23 --- Fixed here, thanks again Eli! http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091214/092861.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 Dec 20 14:30:19 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 20 Dec 2009 14:30:19 -0600 Subject: [LLVMbugs] [Bug 5841] New: clang cannot compile initialized struct containing union Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5841 Summary: clang cannot compile initialized struct containing union Product: new-bugs Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: rene at freebsd.org CC: llvmbugs at cs.uiuc.edu while compiling gettext 0.17 ( http://www.gnu.org/software/gettext/ ) with recent clang (e.g. r91792), from the build: libtool: compile: clang -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/local/share/locale\" -DLIBDIR=\"/usr/local/libdata\" -DBUILDING_LIBINTL -DBUILDING_DLL -DIN_LIBINTL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC -Dset_relocation_prefix=libintl_set_relocation_prefix -Drelocate=libintl_relocate -DDEPENDS_ON_LIBICONV=1 -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -O2 -pipe -fno-strict-aliasing -fvisibility=hidden ./plural-exp.c -fPIC -DPIC -o .libs/plural-exp.o Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple i386-unknown-freebsd8.0 -S -disable-free -main-file-name plural-exp.c -pic-level 2 -mdisable-fp-elim -target-cpu pentium4 -resource-dir /usr/lib/clang/1.1 -DLOCALEDIR="/usr/local/share/locale" -DLOCALE_ALIAS_PATH="/usr/local/share/locale" -DLIBDIR="/usr/local/libdata" -DBUILDING_LIBINTL -DBUILDING_DLL -DIN_LIBINTL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR="/usr/local/lib" -DNO_XMALLOC -Dset_relocation_prefix=libintl_set_relocation_prefix -Drelocate=libintl_relocate -DDEPENDS_ON_LIBICONV=1 -DHAVE_CONFIG_H -DPIC -I. -I. -I.. -I/usr/local/include -O2 -fmessage-length 0 -fvisibility hidden -fgnu-runtime -fdiagnostics-show-option -o /tmp/cc-KCH8M7.s -x c ./plural-exp.c 1. ./plural-exp.c:61:2: current parser token ';' clang: error: compiler command failed due to signal 11 (use -v to see invocation) Offending code: struct expression GERMANIC_PLURAL = { .nargs = 2, .operation = not_equal, .val = { .args = { [0] = (struct expression *) &plvar, [1] = (struct expression *) &plone } } }; /* line 61 */ with expression being defined as: /* This is the representation of the expressions to determine the plural form. */ struct expression { int nargs; /* Number of arguments. */ enum expression_operator operation; union { unsigned long int num; /* Number value for `num'. */ struct expression *args[3]; /* Up to three arguments. */ } val; }; An older revision (e.g. r88856) compiled the file. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Dec 20 16:17:53 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 20 Dec 2009 16:17:53 -0600 Subject: [LLVMbugs] [Bug 5636] clang: optimization changes behaviour In-Reply-To: Message-ID: <200912202217.nBKMHrg0026224@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5636 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Chris Lattner 2009-12-20 16:17:53 --- need more information, as requested by anton -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Dec 20 16:32:22 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 20 Dec 2009 16:32:22 -0600 Subject: [LLVMbugs] [Bug 5701] assertion failed when tried to generate XML In-Reply-To: Message-ID: <200912202232.nBKMWMBZ026967@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5701 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #2 from Chris Lattner 2009-12-20 16:32:21 --- *** This bug has been marked as a duplicate of bug 5006 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Dec 20 16:43:19 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 20 Dec 2009 16:43:19 -0600 Subject: [LLVMbugs] [Bug 3684] Newline token has start of line flag. In-Reply-To: Message-ID: <200912202243.nBKMhJQL027416@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=3684 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #2 from Chris Lattner 2009-12-20 16:43:18 --- It's not worth impacting the performance of the lexer to fix this. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Sun Dec 20 16:45:02 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 20 Dec 2009 16:45:02 -0600 Subject: [LLVMbugs] [Bug 2739] Unused function parameters In-Reply-To: Message-ID: <200912202245.nBKMj2CL027519@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2739 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Chris Lattner 2009-12-20 16:45:02 --- We support -Wunused-parameter now: t.c:1:14: warning: unused parameter 'p' [-Wunused-parameter] char* f(int* p, int x) { ^ t.c:1:21: warning: unused parameter 'x' [-Wunused-parameter] char* f(int* p, int 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 Sun Dec 20 16:47:39 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 20 Dec 2009 16:47:39 -0600 Subject: [LLVMbugs] [Bug 2325] sema should diagnose illegal jump into statement expression In-Reply-To: Message-ID: <200912202247.nBKMld7Z027709@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2325 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #12 from Chris Lattner 2009-12-20 16:47:38 --- I think this is basically fixed, if there is still a remaining issue, it should be a new 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 Dec 20 16:48:15 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 20 Dec 2009 16:48:15 -0600 Subject: [LLVMbugs] [Bug 2304] CHECKER: add field sensitivity to checker In-Reply-To: Message-ID: <200912202248.nBKMmFAf027757@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2304 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|4399 | Blocks| |4399 Status|NEW |RESOLVED Resolution| |FIXED --- Comment #8 from Chris Lattner 2009-12-20 16:48:14 --- I'm pretty sure this is 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 Sun Dec 20 16:48:59 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Sun, 20 Dec 2009 16:48:59 -0600 Subject: [LLVMbugs] [Bug 2015] __attribute__ ((__transparent_union__)) not implemented In-Reply-To: Message-ID: <200912202248.nBKMmxrk027846@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=2015 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #17 from Chris Lattner 2009-12-20 16:48:59 --- Per the previous comment, this was fixed a long time ago. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 21 00:46:47 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 21 Dec 2009 00:46:47 -0600 Subject: [LLVMbugs] [Bug 5822] StringRef::endswith compiles into gross code In-Reply-To: Message-ID: <200912210646.nBL6kle7011466@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5822 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Chris Lattner 2009-12-21 00:46:47 --- Ok, we now generate better code for this than GCC does. Getting it fully optimal as currently written is not worth the effort, Eli is going to just rewrite endswith to be less insane. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 21 01:14:46 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 21 Dec 2009 01:14:46 -0600 Subject: [LLVMbugs] [Bug 5843] New: [bash] crash in clang::InitializedEntity::InitializedEntity Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5843 Summary: [bash] crash in clang::InitializedEntity::InitializedEntity Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Semantic Analyzer AssignedTo: unassignedclangbugs at nondot.org ReportedBy: daniel at zuster.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com clang crashes on the attached input (from bash): -- ddunbar at giles:tmp$ clang -c t.i 0 clang 0x0000000101239fcd PrintStackTrace(void*) + 38 1 clang 0x000000010123a55b SignalHandler(int) + 336 2 libSystem.B.dylib 0x00007fff88921eaa _sigtramp + 26 3 libSystem.B.dylib 000000000000000000 _sigtramp + 2003689840 4 clang 0x00000001003da8a6 clang::InitializedEntity::InitializedEntity(clang::ASTContext&, unsigned int, clang::InitializedEntity const&) + 266 5 clang 0x00000001003e66a2 clang::InitializedEntity::InitializeElement(clang::ASTContext&, unsigned int, clang::InitializedEntity const&) + 42 6 clang 0x00000001003e3c9f (anonymous namespace)::InitListChecker::FillInValueInitializations(clang::InitializedEntity const&, clang::InitListExpr*, bool&) + 1977 7 clang 0x00000001003e3b41 (anonymous namespace)::InitListChecker::FillInValueInitializations(clang::InitializedEntity const&, clang::InitListExpr*, bool&) + 1627 8 clang 0x00000001003e3b41 (anonymous namespace)::InitListChecker::FillInValueInitializations(clang::InitializedEntity const&, clang::InitListExpr*, bool&) + 1627 9 clang 0x00000001003e126b (anonymous namespace)::InitListChecker::InitListChecker(clang::Sema&, clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&) + 243 10 clang 0x00000001003e12d6 clang::Sema::CheckInitList(clang::InitializedEntity const&, clang::InitListExpr*&, clang::QualType&) + 56 11 clang 0x00000001003e4b1d clang::Sema::CheckInitializerTypes(clang::Expr*&, clang::QualType&, clang::InitializedEntity const&, clang::InitializationKind const&) + 2171 12 clang 0x000000010034113d clang::Sema::AddInitializerToDecl(clang::OpaquePtr<0>, clang::ASTOwningResult<&(clang::ActionBase::DeleteExpr(void*))>, bool) + 3661 13 clang 0x0000000100341391 clang::Sema::AddInitializerToDecl(clang::OpaquePtr<0>, clang::ASTOwningResult<&(clang::ActionBase::DeleteExpr(void*))>) + 81 14 clang 0x000000010054c72a clang::Parser::ParseDeclarationAfterDeclarator(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&) + 1670 15 clang 0x000000010054cca0 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*) + 718 16 clang 0x0000000100585d5b clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AttributeList*, clang::AccessSpecifier) + 1065 17 clang 0x0000000100585dc7 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*, clang::AccessSpecifier) + 83 18 clang 0x00000001005879db clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList) + 2149 19 clang 0x0000000100587b19 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 247 20 clang 0x000000010030a685 clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer*) + 523 21 clang 0x000000010005f582 clang::ASTFrontendAction::ExecuteAction() + 256 22 clang 0x000000010005f672 clang::FrontendAction::Execute() + 226 23 clang 0x0000000100026963 cc1_main(char const**, char const**, char const*, void*) + 1929 24 clang 0x000000010002a2fe main + 252 25 clang 0x0000000100025664 start + 52 Stack dump: 0. Program arguments: /Volumes/Data/Users/ddunbar/llvm.obj.64/Debug/bin/clang -cc1 -triple x86_64-apple-darwin10.0 -S -disable-free -main-file-name t.i -pic-level 1 -mdisable-fp-elim -munwind-tables -target-cpu core2 -fno-math-errno -resource-dir /Volumes/Data/Users/ddunbar/llvm.obj.64/Debug/lib/clang/1.1 -fmessage-length 88 -stack-protector 1 -fblocks -fdiagnostics-show-option -o /var/folders/DQ/DQ8GT3++HESEzT1obWBynE+++TI/-Tmp-/cc-ytX4Ap.s -x cpp-output t.i 1. /tmp/RootsDir/bash-80.roots/bash-80/bash/lib/intl/plural-exp.c:61:2: current parser token ';' clang: error: compiler command failed due to signal 11 (use -v to see invocation) ddunbar at giles:tmp$ -- -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 21 01:16:46 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 21 Dec 2009 01:16:46 -0600 Subject: [LLVMbugs] [Bug 5837] ssaupdate inserts many duplicate phi nodes In-Reply-To: Message-ID: <200912210716.nBL7GkBI012537@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5837 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2009-12-21 01:16:45 --- Fixed here, now we only get one PHI: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091221/092901.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 21 11:21:01 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 21 Dec 2009 11:21:01 -0600 Subject: [LLVMbugs] [Bug 5845] New: compiler-rt build fails at powidf2_test Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5845 Summary: compiler-rt build fails at powidf2_test Product: new-bugs Version: trunk Platform: All OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: rene at freebsd.org CC: llvmbugs at cs.uiuc.edu FreeBSD 8 (both on i386 and amd64), while building compiler-rt r91825 (last changed r86542) according to the instructions on http://compiler-rt.llvm.org/ : [ 89%] Building C object test/CMakeFiles/powidf2_test.dir/Unit/powidf2_test.c.o Linking C executable powidf2_test CMakeFiles/powidf2_test.dir/Unit/powidf2_test.c.o(.text+0x47): In function `test__powidf2': : undefined reference to `__signbit' CMakeFiles/powidf2_test.dir/Unit/powidf2_test.c.o(.text+0x53): In function `test__powidf2': : undefined reference to `__signbit' gmake[2]: *** [test/powidf2_test] Error 1 gmake[1]: *** [test/CMakeFiles/powidf2_test.dir/all] Error 2 gmake: *** [all] Error 2 cmake 2.8.0, gmake 3.81, gcc 4.2.1 20070719 [FreeBSD] -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 21 11:48:06 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 21 Dec 2009 11:48:06 -0600 Subject: [LLVMbugs] [Bug 5846] New: Linear Scan Runs Out of Registers Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5846 Summary: Linear Scan Runs Out of Registers Product: libraries Version: trunk 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 Created an attachment (id=3968) --> (http://llvm.org/bugs/attachment.cgi?id=3968) bugpoint-reduced testcase Generating code for x86_64 with the attached testcase causes LinearScan to crash: llc: llvm-project.official/llvm/trunk/lib/CodeGen/RegAllocLinearScan.cpp:1183: void::RALinScan::assignRegOrStackSlotAtInterval(llvm::LiveInterval*): Assertion `false && "Ran out of registers during register allocation!"' failed. 0 llc 0x000000000170f9d2 1 llc 0x000000000170ffb8 2 libc.so.6 0x00002b0f35963c10 3 libc.so.6 0x00002b0f35963b95 gsignal + 53 4 libc.so.6 0x00002b0f35964f90 abort + 272 5 libc.so.6 0x00002b0f3595d256 __assert_fail + 246 6 llc 0x00000000013fa460 (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval(llvm::LiveInterval*) + 5426 7 llc 0x00000000013fbe59 (anonymous namespace)::RALinScan::linearScan() + 589 8 llc 0x00000000013fc686 (anonymous namespace)::RALinScan::runOnMachineFunction(llvm::MachineFunction&) + 494 9 llc 0x00000000013ca3d5 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 83 10 llc 0x000000000168ebf8 llvm::FPPassManager::runOnFunction(llvm::Function&) + 336 11 llc 0x00000000016907b5 llvm::FunctionPassManagerImpl::run(llvm::Function&) + 79 12 llc 0x0000000001690956 llvm::FunctionPassManager::run(llvm::Function&) + 112 13 llc 0x0000000000b24ed2 main + 3156 14 libc.so.6 0x00002b0f35951154 __libc_start_main + 244 15 llc 0x0000000000b23469 Stack dump: 0. Program arguments: /ptmp/dag/build.llvm.trunk.official.debug/x86_64-unknown-linux-gnu/Debug/bin/llc /users/dag/crash.bc -o crash.s 1. Running pass 'Linear Scan Register Allocator' on function '@main' Abort This fails in a variety of other ways with earlier LLVM releases, so it appears this probably has existed for quite some time. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 21 16:11:14 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 21 Dec 2009 16:11:14 -0600 Subject: [LLVMbugs] [Bug 5769] Coalescer deficiency In-Reply-To: Message-ID: <200912212211.nBLMBEjh027023@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5769 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WORKSFORME --- Comment #4 from Jakob Stoklund Olesen 2009-12-21 16:11:12 --- It looks like the coalescer is doing the right thing with subreg intervals now. Please reopen if you can reproduce. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 21 16:26:37 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 21 Dec 2009 16:26:37 -0600 Subject: [LLVMbugs] [Bug 5773] Creating a JIT-ExecutionEngine overrides the CodeModel set by TargetMachine In-Reply-To: Message-ID: <200912212226.nBLMQbMR027592@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5773 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #6 from Eric Christopher 2009-12-21 16:26:36 --- Going to call it fixed then. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Mon Dec 21 18:06:40 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Mon, 21 Dec 2009 18:06:40 -0600 Subject: [LLVMbugs] [Bug 5843] [bash] crash in clang::InitializedEntity::InitializedEntity In-Reply-To: Message-ID: <200912220006.nBM06e3V031497@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5843 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2009-12-21 18:06:39 --- Fixed here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091221/025688.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 22 00:08:16 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 22 Dec 2009 00:08:16 -0600 Subject: [LLVMbugs] [Bug 5795] not merging duplicate blocks In-Reply-To: Message-ID: <200912220608.nBM68GQU010823@zion.cs.uiuc.edu> http://llvm.org/bugs/show_bug.cgi?id=5795 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2009-12-22 00:08:15 --- Implemented here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091221/092966.html This should substantially improve our results on your testsuite compared to GCC, it occurs in many of the cases where we're "embarrassing". -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 22 04:04:23 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 22 Dec 2009 04:04:23 -0600 Subject: [LLVMbugs] [Bug 5851] New: llvm binds wrong symbols for stdcall functions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5851 Summary: llvm binds wrong symbols for stdcall functions Product: tools Version: 2.6 Platform: PC OS/Version: Windows XP Status: NEW Keywords: compile-fail Severity: major Priority: P2 Component: llvm-as AssignedTo: unassignedbugs at nondot.org ReportedBy: ga55gees6m at sneakemail.com CC: llvmbugs at cs.uiuc.edu --- struct A { __stdcall void (*p)(); }; static __stdcall void MyFunc() { } struct A B={MyFunc}; --- >llvm-gcc -pipe -c tmp.c -o tmp.o --- >ld tmp.o -o tmp.exe tmp.o:fake:(.data+0x0): undefined reference to `MyFunc' --- It must be MyFunc at 0 to begin with... It definitely generates cdecl symbol for stdcall function. This prevents building COM vtables. IR looks ok, so this an llvm-as bug, I'm unsure who is responsible for generation of right symbols. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at cs.uiuc.edu Tue Dec 22 04:12:52 2009 From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu) Date: Tue, 22 Dec 2009 04:12:52 -0600 Subject: [LLVMbugs] [Bug 5852] New: gcc doesn' t generate proper attributes in IR with -mrtd option Message-ID: