From bugzilla-daemon at llvm.org Mon Jun 1 01:42:04 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 01 Jun 2015 08:42:04 +0000 Subject: [LLVMbugs] [Bug 23715] New: error: invalid symbol redefinition __asm Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23715 Bug ID: 23715 Summary: error: invalid symbol redefinition __asm Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: LLVM assembly language parser Assignee: unassignedbugs at nondot.org Reporter: javier_3 at runbox.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This error shows up when compiling with O2 or O3, but not with O0 or O1. Note that the error is triggered in a file included from line 3 of to_write_C and _before_ that error I get a warning from line 387 of that same file. ./to_write_C.c:387:21: warning: unused variable 'p' [-Wunused-variable] default: {void* p=va_arg(ap,void*);} //let's hope this is right ^ In file included from ATfileoutput.th:8: In file included from ./to_write_C.c:3: ./to_write_CLANG.c:12:1: error: invalid symbol redefinition __asm{ ^ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 1 02:06:45 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 01 Jun 2015 09:06:45 +0000 Subject: [LLVMbugs] [Bug 23716] New: Frontend crashes on clang::Sema::tryCaptureVariable Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23716 Bug ID: 23716 Summary: Frontend crashes on clang::Sema::tryCaptureVariable Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangbugs at nondot.org Reporter: krzysztof.sinica at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified ./clang -std=c++14 -stdlib=libstdc++ -I/usr/include/x86_64-linux-gnu/c++/5 ~/main.cpp 0 clang 0x0000000002436c48 llvm::sys::PrintStackTrace(_IO_FILE*) + 40 1 clang 0x000000000243808b 2 libpthread.so.0 0x00007fd91aafe340 3 clang 0x00000000013ae923 clang::DeclContext::getRedeclContext() + 19 4 clang 0x00000000008fb96d 5 clang 0x0000000000ccdb5f clang::Sema::tryCaptureVariable(clang::VarDecl*, clang::SourceLocation, clang::Sema::TryCaptureKind, clang::SourceLocation, bool, clang::QualType&, clang::QualType&, unsigned int const*) + 255 6 clang 0x0000000000cd0b6d clang::Sema::tryCaptureVariable(clang::VarDecl*, clang::SourceLocation, clang::Sema::TryCaptureKind, clang::SourceLocation) + 61 7 clang 0x0000000000ecc0ed 8 clang 0x0000000000ecbc56 9 clang 0x0000000000eb6f7e 10 clang 0x0000000000eb7d67 11 clang 0x0000000000eccb1f 12 clang 0x0000000000eb6ac3 13 clang 0x0000000000eb6204 14 clang 0x0000000000ec1421 15 clang 0x0000000000eb61b1 clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList const&) + 65 16 clang 0x0000000000edd9ec clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 3772 17 clang 0x0000000000e8c918 clang::Sema::DeduceReturnType(clang::FunctionDecl*, clang::SourceLocation, bool) + 56 18 clang 0x0000000000c8fc90 clang::Sema::DiagnoseUseOfDecl(clang::NamedDecl*, clang::SourceLocation, clang::ObjCInterfaceDecl const*, bool) + 1536 19 clang 0x0000000000def329 20 clang 0x0000000000df4cf1 clang::Sema::BuildCallToObjectOfClassType(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation) + 4609 21 clang 0x0000000000c96740 clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, bool) + 1296 22 clang 0x0000000000a9adeb clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult) + 4011 23 clang 0x0000000000a9f7c8 clang::Parser::ParseCastExpression(bool, bool, bool&, clang::Parser::TypeCastState) + 17480 24 clang 0x0000000000a989c2 clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 130 25 clang 0x0000000000a98929 clang::Parser::ParseExpression(clang::Parser::TypeCastState) + 9 26 clang 0x0000000000ad1299 clang::Parser::ParseExprStatement() + 41 27 clang 0x0000000000ad0cb1 clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) + 2881 28 clang 0x0000000000ad00ff clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, bool, clang::SourceLocation*) + 143 29 clang 0x0000000000ad67af clang::Parser::ParseCompoundStatementBody(bool) + 1791 30 clang 0x0000000000ad7016 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 182 31 clang 0x0000000000a67185 clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) + 2261 32 clang 0x0000000000a76db7 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 2583 33 clang 0x0000000000a665e4 clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) + 788 34 clang 0x0000000000a660b0 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) + 384 35 clang 0x0000000000a654be clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) + 3118 36 clang 0x0000000000a647c8 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 360 37 clang 0x0000000000a610f6 clang::ParseAST(clang::Sema&, bool, bool) + 422 38 clang 0x000000000070dde9 clang::FrontendAction::Execute() + 57 39 clang 0x00000000006e3613 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 803 40 clang 0x00000000006c9a6b clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2795 41 clang 0x00000000006c179e cc1_main(llvm::ArrayRef, char const*, void*) + 702 42 clang 0x00000000006c87a2 main + 11506 43 libc.so.6 0x00007fd919cb0ec5 __libc_start_main + 245 44 clang 0x00000000006c1409 _start + 41 Stack dump: 0. Program arguments: /home/user/clang/clang+llvm-3.6.1-x86_64-linux-gnu/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.25 -dwarf-column-info -resource-dir /home/user/clang/clang+llvm-3.6.1-x86_64-linux-gnu/bin/../lib/clang/3.6.1 -I /usr/include/x86_64-linux-gnu/c++/5 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/5.0.0/../../../../include/c++/5.0.0 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/5.0.0/../../../../include/x86_64-linux-gnu/c++/5.0.0 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/5.0.0/../../../../include/x86_64-linux-gnu/c++/5.0.0 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/5.0.0/../../../../include/c++/5.0.0/backward -internal-isystem /usr/local/include -internal-isystem /home/user/clang/clang+llvm-3.6.1-x86_64-linux-gnu/bin/../lib/clang/3.6.1/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++14 -fdeprecated-macro -fdebug-compilation-dir /home/user/clang/clang+llvm-3.6.1-x86_64-linux-gnu/bin -ferror-limit 19 -fmessage-length 238 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o /tmp/main-e38255.o -x c++ /home/user/main.cpp 1. /home/user/main.cpp:25:7: current parser token ')' 2. /home/user/main.cpp:19:34: parsing function body 'main' 3. /home/user/main.cpp:19:34: in compound statement ('{}') clang: error: unable to execute command: Segmentation fault clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.6.1 (tags/RELEASE_361/final) Target: x86_64-unknown-linux-gnu Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/main-535d96.cpp clang: note: diagnostic msg: /tmp/main-535d96.sh clang: note: diagnostic msg: ******************** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 1 02:13:00 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 01 Jun 2015 09:13:00 +0000 Subject: [LLVMbugs] [Bug 23632] llc optimises unaligned intrinsic to aligned load In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23632 igorb changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |igor.breger at intel.com Resolution|--- |FIXED --- Comment #1 from igorb --- Fixed in r238724 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 1 02:16:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 01 Jun 2015 09:16:58 +0000 Subject: [LLVMbugs] [Bug 23717] New: -Wfloat-equal issued too much Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23717 Bug ID: 23717 Summary: -Wfloat-equal issued too much Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: javier_3 at runbox.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The code at SemaChecking.cpp, function Sema::CheckFloatComparison, issues the warning warn_floatingpoint_eq (-Wfloat-equal) in case of using == or != with floating point operands, but prevents the issuing of the warning in some special cases, among which: // Special case: check for comparisons against literals that can be exactly // represented by APFloat. So if the code reads if(x==0.0F) no warning is issued, but if the user simply writes if(x==0) the warning is issued. Given that both pieces of code get translated to exactly the same and the user obviously knows what he is doing when writing if(x==0), my point is that in the second case the warning should not be issued too. I get dozens of annoying warning because of comparisons against zero, but I don't want to turn off that warning because I think it's really meaningful in the other cases, e.g. if(x==y). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 1 05:06:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 01 Jun 2015 12:06:56 +0000 Subject: [LLVMbugs] [Bug 23719] New: OpenCL: Crash with a vector initializer list with a value that is a function call Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23719 Bug ID: 23719 Summary: OpenCL: Crash with a vector initializer list with a value that is a function call Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: pekka.jaaskelainen at tut.fi CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14411 --> https://llvm.org/bugs/attachment.cgi?id=14411&action=edit backtrace // reproduce with: // clang -DBUG test_vec_init.c -c -emit-llvm -o - -S typedef float float2 __attribute__((__ext_vector_type__(2))); float2 func(float2 a) { return a; } void test_vec_init() { volatile float2 a = (float2) ( 1.0f, 2.0f ); #ifndef BUG // This works. volatile float2 res = func(a); volatile float2 x = (float2) (res.x, res.y); #else // This crashes. volatile float2 x = (float2) (func(a).x, a.x); #endif } When compiled in C mode (without -x cl) it doesn't crash. Backtrace attached. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 1 09:09:33 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 01 Jun 2015 16:09:33 +0000 Subject: [LLVMbugs] [Bug 23720] New: MachineInstr verification error with sub-reg liveness enabled in R600 backend Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23720 Bug ID: 23720 Summary: MachineInstr verification error with sub-reg liveness enabled in R600 backend Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Register Allocator Assignee: unassignedbugs at nondot.org Reporter: tstellar at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14413 --> https://llvm.org/bugs/attachment.cgi?id=14413&action=edit Reduced test case This bug can be reproduced by applying the attached patch to enable sub-reg liveness and running the attached test case with llc: ./llc -verify-machineinstrs -march=amdgcn r600-sub-reg-liveness-crash.ll -o - -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 1 09:35:30 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 01 Jun 2015 16:35:30 +0000 Subject: [LLVMbugs] [Bug 21945] clang crashes with -ferror-limit=1 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21945 Eugene changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kevg at sphinxsearch.com Resolution|--- |FIXED --- Comment #3 from Eugene --- http://llvm.org/viewvc/llvm-project?view=revision&revision=238758 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 1 12:07:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 01 Jun 2015 19:07:39 +0000 Subject: [LLVMbugs] [Bug 23721] New: "double indirection not handled" crash with -fsanitize=address Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23721 Bug ID: 23721 Summary: "double indirection not handled" crash with -fsanitize=address Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: oleg00 at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified clang: /usr/global/zeev/llvm-3.6.1.src/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:781: void llvm::DwarfCompileUnit::addComplexAddress(const llvm::DbgVariable&, llvm::DIE&, llvm::dwarf::Attribute, const llvm::MachineLocation&): Assertion `!DV.getVariable().isIndirect() && "double indirection not handled"' failed. #0 0x7fcc900713b2 llvm::sys::PrintStackTrace(_IO_FILE*) (/usr/global/zeev/install/jpm/ro/3rd/llvm/3.6.1/x86_64-linux-2.6-libc6/bin/../lib/libLLVM-3.6.so+0xcd23b2) Compiles fines without the sanitizer. Also compiles fine when I remove the always_inline attribute from one of the functions in the call chain. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 1 14:27:12 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 01 Jun 2015 21:27:12 +0000 Subject: [LLVMbugs] [Bug 23720] MachineInstr verification error with sub-reg liveness enabled in R600 backend In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23720 Matthias Braun changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedbugs at nondot.org |matze at braunis.de --- Comment #2 from Matthias Braun --- Fixed by r238785. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 1 15:32:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 01 Jun 2015 22:32:36 +0000 Subject: [LLVMbugs] [Bug 20927] [ARM64] Inefficient range check sequence In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20927 Matthias Braun changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |matze at braunis.de Resolution|--- |FIXED Assignee|unassignedbugs at nondot.org |matze at braunis.de --- Comment #1 from Matthias Braun --- Fixed by r238793. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 1 18:06:18 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 01:06:18 +0000 Subject: [LLVMbugs] [Bug 23722] New: clang gives compiler where gcc does not when dealing with extern "C" function declarations Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23722 Bug ID: 23722 Summary: clang gives compiler where gcc does not when dealing with extern "C" function declarations Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: eldlistmailingz at tropicsoft.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified I regularly test clang on Windows targeting mingw/gcc-4.8.1 against Boost libraries. Clang is failing compilation where gcc-4.8.1 succeeds when it comes to extern "C" declarations in Boost's internal winapi library and in the mingw/w32api package. The code which illustrates this bug is: #include #include int main() { boost::detail::winapi::FILETIME_ ft; boost::detail::winapi::GetSystemTimeAsFileTime(&ft); return 0; } Compiled with gcc-4.8.1 using Boost bjam with command line parameters of: -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -march=i686 -m32 we get no errors and a successful compilation. Compiled with the latest clang built from source with command line parameters of: -c -x c++ -O0 -g -fno-inline -Wall -g -march=i686 -m32 we get errors of: "In file included from test_winapi.cpp:2: In file included from /mingw/include\windows.h:62: /mingw/include\winbase.h:1217:24: error: conflicting types for 'FileTimeToLocalFileTime' WINBASEAPI BOOL WINAPI FileTimeToLocalFileTime(CONST FILETIME *,LPFILETIME); ^ ..\..\..\boost/detail/winapi/time.hpp:73:9: note: previous declaration is here FileTimeToLocalFileTime(const FILETIME_* lpFileTime, ^ In file included from test_winapi.cpp:2: In file included from /mingw/include\windows.h:62: /mingw/include\winbase.h:1394:24: error: conflicting types for 'GetSystemTime' WINBASEAPI VOID WINAPI GetSystemTime(LPSYSTEMTIME); ^ ..\..\..\boost/detail/winapi/time.hpp:76:9: note: previous declaration is here GetSystemTime(SYSTEMTIME_* lpSystemTime); ^ In file included from test_winapi.cpp:2: In file included from /mingw/include\windows.h:62: /mingw/include\winbase.h:1397:24: error: conflicting types for 'GetSystemTimeAsFileTime' WINBASEAPI void WINAPI GetSystemTimeAsFileTime(LPFILETIME); ^ ..\..\..\boost/detail/winapi/time.hpp:70:9: note: previous declaration is here GetSystemTimeAsFileTime(FILETIME_* lpFileTime); ^ In file included from test_winapi.cpp:2: In file included from /mingw/include\windows.h:62: /mingw/include\winbase.h:1754:24: error: conflicting types for 'SystemTimeToFileTime' WINBASEAPI BOOL WINAPI SystemTimeToFileTime(const SYSTEMTIME*,LPFILETIME); ^ ..\..\..\boost/detail/winapi/time.hpp:78:9: note: previous declaration is here SystemTimeToFileTime(const SYSTEMTIME_* lpSystemTime, ^" Notice that the program itself is only invoking the GetSystemTimeAsFileTime function, but clang is saying that all "mismatched" declarations indicate errors. If we take a look at GetSystemTimeAsFileTime in the mingw headers we see within an extern "C" block: typedef struct _FILETIME { DWORD dwLowDateTime; DWORD dwHighDateTime; } FILETIME,*PFILETIME,*LPFILETIME; WINBASEAPI void WINAPI GetSystemTimeAsFileTime(LPFILETIME); and when we preprocess this function call we see: void __attribute__((__stdcall__)) GetSystemTimeAsFileTime(LPFILETIME); If we take a look at GetSystemTimeAsFileTime in the Boost headers we see within an extern "C" block: typedef struct _FILETIME { DWORD_ dwLowDateTime; DWORD_ dwHighDateTime; } FILETIME_, *PFILETIME_, *LPFILETIME_; __declspec(dllimport) void WINAPI GetSystemTimeAsFileTime(FILETIME_* lpFileTime); and when we preprocess this function call we see: __attribute__((dllimport)) void __attribute__((__stdcall__)) GetSystemTimeAsFileTime(FILETIME_* lpFileTime); Clang appears to be saying that the since the declarations of the GetSystemTimeAsFileTime don't match exactly because one of them has the __attribute__((dllimport)) while the other does not, it is an error. For gcc, which sees exactly the same preprocessed code, it is not an error. I don't know, based on the C++ standard, whether it is an error or not but if it is I would like it explained according to the C++ standard why it is. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 1 20:40:37 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 03:40:37 +0000 Subject: [LLVMbugs] [Bug 23722] clang gives compiler where gcc does not when dealing with extern "C" function declarations In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23722 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |INVALID --- Comment #1 from Richard Smith --- The problem is that the two function declarations have different parameter types. The windows.h version takes ::_FILETIME*, whereas the boost version takes boost::detail::winapi::_FILETIME*. Because they're 'extern "C"' functions, they are redeclarations of the same function, and are ill-formed because they have different types. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 1 20:49:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 03:49:07 +0000 Subject: [LLVMbugs] [Bug 23723] New: is_always_equal unimplemented Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23723 Bug ID: 23723 Summary: is_always_equal unimplemented Product: libc++ Version: 3.6 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: david_work at me.com CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified Although LWG DR 2467, a minor adjustment to allocator_traits::is_always_equal, is marked as complete on the C++1z status page, the identifier "is_always_equal" does not appear at all in . There was a recent custom-SFINAE rewrite of allocator_traits, but it's also absent from my local repo which should only be slightly older. Looks like it was never implemented. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 1 21:05:53 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 04:05:53 +0000 Subject: [LLVMbugs] [Bug 23713] Missing include for Documentation.h in clang-c/Index.h In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23713 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |INVALID --- Comment #2 from Richard Smith --- We had such a #include, but removed it for 3.7; see: http://clang.llvm.org/docs/ReleaseNotes.html#internal-api-changes The fix is to update libclang client code to include Documentation.h if it uses the documentation portion of the libclang API. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 1 22:45:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 05:45:40 +0000 Subject: [LLVMbugs] [Bug 23725] New: GCC finds "set but not used" but Clang doesn't Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23725 Bug ID: 23725 Summary: GCC finds "set but not used" but Clang doesn't Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: wkoszek at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Host machine (OSX): wk% clang -v Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix Vagrant VM with Ubuntu ubuntu/trusty64: vagrant at vagrant-ubuntu-trusty-64:/vagrant/unix/samples$ cc -v Using built-in specs. COLLECT_GCC=cc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) With GCC: vagrant at vagrant-ubuntu-trusty-64:/vagrant/unix/samples$ make cc -g -ggdb -O2 -Wall -pedantic -std=c99 -I../../samples -I../.. -o sample_0 ../../samples/sample_0.c ../../cla.c cc -g -ggdb -O2 -Wall -pedantic -std=c99 -I../../samples -I../.. -o sample_1 ../../samples/sample_1.c ../../cla.c cc -g -ggdb -O2 -Wall -pedantic -std=c99 -I../../samples -I../.. -o sample_2 ../../samples/sample_2.c ../../cla.c cc -g -ggdb -O2 -Wall -pedantic -std=c99 -I../../samples -I../.. -o sample_3 ../../samples/sample_3.c ../../cla.c cc -g -ggdb -O2 -Wall -pedantic -std=c99 -I../../samples -I../.. -o sample_4 ../../samples/sample_4.c ../../cla.c ../../samples/sample_4.c: In function ‘nf_cmdlist_build’: ../../samples/sample_4.c:84:14: warning: variable ‘reg_list’ set but not used [-Wunused-but-set-variable] struct cla *reg_list; ^ cc -g -ggdb -O2 -Wall -pedantic -std=c99 -I../../samples -I../.. -o sample_5 ../../samples/sample_5.c ../../cla.c vagrant at vagrant-ubuntu-trusty-64:/vagrant/unix/samples$ vim ../^C Clang doesn't give me any warning. It can't figure out that reg_list isn't used. Code: git clone https://github.com/wkoszek/libcla.git Commit: https://github.com/wkoszek/libcla/commit/a4b5afe528ce67daf10e23e838f5643ef5865c0b Just comment out line 114 to get the same result. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 00:02:13 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 07:02:13 +0000 Subject: [LLVMbugs] [Bug 23726] New: got error when compile c++ code under VS2013 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23726 Bug ID: 23726 Summary: got error when compile c++ code under VS2013 Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: zs0723 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14416 --> https://llvm.org/bugs/attachment.cgi?id=14416&action=edit testclang.cpp and testclang.sh 1>------ Build started: Project: testclang, Configuration: Release Win32 ------ 1> Basic Block in function '?clear at ios_base@std@@QAEXH_N at Z' does not have terminator! 1> label %entry 1>CL : fatal error : error in backend: Broken function found, compilation aborted! 1>clang-cl.exe : error : clang frontend command failed with exit code 70 (use -v to see invocation) 1> clang version 3.7.0 (trunk) 1> Target: i686-pc-windows-msvc 1> Thread model: posix 1> clang-cl.exe: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. 1> clang-cl.exe: note: diagnostic msg: 1> ******************** 1> 1> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: 1> Preprocessed source(s) and associated run script(s) are located at: 1> clang-cl.exe: note: diagnostic msg: C:\Users\zhangv6\AppData\Local\Temp\testclang-412e75.cpp 1> clang-cl.exe: note: diagnostic msg: C:\Users\zhangv6\AppData\Local\Temp\testclang-412e75.sh 1> clang-cl.exe: note: diagnostic msg: 1> 1> ******************** ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== The version is : LLVM-3.7.0-r238743-win32.exe -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 01:44:45 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 08:44:45 +0000 Subject: [LLVMbugs] [Bug 23727] New: libclang fails to build in 64-bit mode using Visual Studio 2013 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23727 Bug ID: 23727 Summary: libclang fails to build in 64-bit mode using Visual Studio 2013 Product: Build scripts Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: vinay_sajip at yahoo.co.uk CC: llvmbugs at cs.uiuc.edu Classification: Unclassified libclang fails to build in 64-bit mode on Visual Studio 2013, though it builds without errors in 32-bit mode. (Release configuration) The reason is that the linker options and inputs for certain projects are wrong in 64-bit mode. After a number of changes were made, libclang was successfully built in 64-bit mode. Specifically, project-by-project, the changes made were as follows: clang-tblgen: Additional option /machine:x86 was specified in linker options (removed). In the linker input, the following hardcoded library paths were changed from ..\..\..\..\Release\lib\FOO.lib to ..\..\..\..\x64\Release\FOO.lib: ..\..\..\..\Release\lib\LLVMSupport.lib ..\..\..\..\Release\lib\LLVMTableGen.lib llvm-tblgen: Additional option /machine:x86 was specified in linker options (removed). In the linker input, the following hardcoded library paths were changed from ..\..\..\..\Release\lib\FOO.lib to ..\..\..\..\x64\Release\FOO.lib: ..\..\..\..\Release\lib\LLVMSupport.lib ..\..\..\..\Release\lib\LLVMTableGen.lib libclang: Additional option /machine:x86 was specified in linker options (removed). In the linker input, the following hardcoded library paths were changed from ..\..\..\..\Release\lib\FOO.lib to ..\..\..\..\x64\Release\FOO.lib ..\..\..\..\Release\lib\clangAST.lib ..\..\..\..\Release\lib\clangBasic.lib ..\..\..\..\Release\lib\clangFrontend.lib ..\..\..\..\Release\lib\clangIndex.lib ..\..\..\..\Release\lib\clangLex.lib ..\..\..\..\Release\lib\clangSema.lib ..\..\..\..\Release\lib\clangTooling.lib ..\..\..\..\Release\lib\clangARCMigrate.lib ..\..\..\..\Release\lib\LLVMCore.lib ..\..\..\..\Release\lib\LLVMSupport.lib ..\..\..\..\Release\lib\clangFormat.lib ..\..\..\..\Release\lib\clangToolingCore.lib ..\..\..\..\Release\lib\clangASTMatchers.lib ..\..\..\..\Release\lib\clangDriver.lib ..\..\..\..\Release\lib\clangParse.lib ..\..\..\..\Release\lib\LLVMMCParser.lib ..\..\..\..\Release\lib\LLVMOption.lib ..\..\..\..\Release\lib\clangSerialization.lib ..\..\..\..\Release\lib\clangEdit.lib ..\..\..\..\Release\lib\LLVMBitReader.lib ..\..\..\..\Release\lib\clangStaticAnalyzerCheckers.lib ..\..\..\..\Release\lib\clangStaticAnalyzerCore.lib ..\..\..\..\Release\lib\clangRewrite.lib ..\..\..\..\Release\lib\clangAnalysis.lib ..\..\..\..\Release\lib\LLVMMC.lib Possibly a parameterised directory is better, such as $(SolutionDir)$(Platform)\$(Configuration)\ - however it would need to be consistent across x86 and x64 to be maximally useful. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 03:50:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 10:50:31 +0000 Subject: [LLVMbugs] [Bug 23729] New: Clang has missing/different macros than gcc - causing compatibility issues Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23729 Bug ID: 23729 Summary: Clang has missing/different macros than gcc - causing compatibility issues Product: clang Version: 3.6 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: npl at chello.at CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14419 --> https://llvm.org/bugs/attachment.cgi?id=14419&action=edit gcc defines Hello, I tried compiling out project at work, which is a realtime firmware for arm. Ideally clang would be just able to generate correct code, but it misbehaves on a few accounts. I consider some of these macros pretty much defacto-standard, as eg. newlib is using and depending on these. __SOFTFP__ is not set, implicating hardware floating point support __USES_INITFINI__ is not set, resulting in initialisation functions not being called And several macros are quite different: __ARM_SIZEOF_WCHAR_T 32 vs. 4 __FLT_* sizes are different, probably just nonrelevant extra precision __INTPTR_TYPE__,__UINT32_TYPE__,__WINT_TYPE__ etc. int vs. long int (kills binary compatibility) I used these 2 commands (clang needed the system directories defined, din`t pick them up correctly) LC_ALL=C /opt/toolchain/bin/arm-none-eabi-g++ -fmessage-length=0 -DNVALGRIND -Wignored-qualifiers -mcpu=arm926ej-s -fstrict-aliasing -ftls-model=local-exec -fno-threadsafe-statics -ffunction-sections -fdata-sections -mpoke-function-name -DPOKE_FUNCTION_NAME -Wpointer-arith -Wno-psabi -Wsign-compare -fstrict-overflow -Wnoexcept -std=gnu++11 -Wall -O2 -g2 \ \ -E -P -dD -x c++ -v - < /dev/null 2>&1 LC_ALL=C /opt/toolchain/bin/arm-none-eabi-clang++ -fmessage-length=0 -DNVALGRIND -Wignored-qualifiers -mcpu=arm926ej-s -fstrict-aliasing -ftls-model=local-exec -fno-threadsafe-statics -ffunction-sections -fdata-sections -fshort-enums -fshort-enums -Wpointer-arith -Wsign-compare -Wimplicit-fallthrough -std=gnu++11 -Wall -O2 -g3 \ \ -nostdinc -I/opt/toolchain-4.8/lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/include/c++/4.8.4 -I/opt/toolchain-4.8/lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/include/c++/4.8.4/arm-none-eabi/armv5te -I/opt/toolchain-4.8/lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/include/c++/4.8.4/backward -I/opt/toolchain-4.8/lib/gcc/arm-none-eabi/4.8.4/include -I/opt/toolchain-4.8/lib/gcc/arm-none-eabi/4.8.4/include-fixed -I/opt/toolchain-4.8/lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/include \ -E -P -dD -x c++ -v - < /dev/null 2>&1 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 07:21:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 14:21:49 +0000 Subject: [LLVMbugs] [Bug 23732] New: C++ global initializers are "optimized" away when used with section attribute Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23732 Bug ID: 23732 Summary: C++ global initializers are "optimized" away when used with section attribute Product: clang Version: 3.6 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: npl at chello.at CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14421 --> https://llvm.org/bugs/attachment.cgi?id=14421&action=edit Code showing the issue Hello, Having a static instance of a class with an initializer usually will create a function (in __init_array) so that the constructor is called early. Using the section attribute will result in the function being omitted and the programm ill-formed. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 08:01:02 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 15:01:02 +0000 Subject: [LLVMbugs] [Bug 23733] New: [Windows] Clang doesn't support std::atomic with Microsoft's STL Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23733 Bug ID: 23733 Summary: [Windows] Clang doesn't support std::atomic with Microsoft's STL Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: sebastian.redl at getdesigned.at CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified This code doesn't work with clang-cl for Visual Studio 2013: void test() { std::atomic fptr(nullptr); fptr.load(); } The problem is that in atomic's implementation, all pointer atomics (which includes pointer-to-function atomics) store a void* internally, and load() static_casts the void* to the actual pointer type. Apparently, Microsoft's compiler accepts a static_cast((void*)0). clang-cl does not. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 08:16:48 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 15:16:48 +0000 Subject: [LLVMbugs] [Bug 23697] ld/sd don't support some addressing modes In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23697 David Chisnall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |csdavec at swan.ac.uk Resolution|--- |DUPLICATE --- Comment #1 from David Chisnall --- *** This bug has been marked as a duplicate of bug 23734 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 08:16:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 15:16:49 +0000 Subject: [LLVMbugs] [Bug 23370] [meta] Using Clang/LLVM as the FreeBSD/mips system compiler In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23370 Bug 23370 depends on bug 23697, which changed state. Bug 23697 Summary: ld/sd don't support some addressing modes https://llvm.org/bugs/show_bug.cgi?id=23697 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 08:16:12 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 15:16:12 +0000 Subject: [LLVMbugs] [Bug 23734] New: [mips] MipsAsmParser doesn't handle expressions with multiple leading parens Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23734 Bug ID: 23734 Summary: [mips] MipsAsmParser doesn't handle expressions with multiple leading parens Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: MIPS Assignee: unassignedbugs at nondot.org Reporter: csdavec at swan.ac.uk CC: llvmbugs at cs.uiuc.edu Classification: Unclassified These expressions occur a lot in the FreeBSD kernel, as a result of macro expansion. For example (simplified from the original): sd $7, ((8) - 1) + 40 ($29) The loop in MipsAsmParser::parseMemOffset consumes the two leading parens and then calls MCAsmParser::parseParenExpression(). This then parses until the end of the ((8) - 1) expression. The next token is then +, which is unexpected (lparen then register is expected). This is caused by the desire to be able to parse ((%lo .... )) expressions, using the existing infrastructure. I suspect that the correct solution is to extend AsmParser to allow unrecognised tokens to be handled by targets in parseExpression(). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 09:35:57 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 16:35:57 +0000 Subject: [LLVMbugs] [Bug 23723] is_always_equal unimplemented In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23723 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Marshall Clow (home) --- Fixed in revision 238848. Thanks for the reminder; I closed the LWG issue because it was just a wording clarification; not really a code change. However, the feature was part of N4258, which hadn't been implemented yet (and is marked as not yet implemented) so I guess it was a bit premature. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 11:16:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 18:16:56 +0000 Subject: [LLVMbugs] [Bug 23735] New: SeparateConstOffsetFromGEP makes a wrong assumption that index of inbounds GEP are non-negative Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23735 Bug ID: 23735 Summary: SeparateConstOffsetFromGEP makes a wrong assumption that index of inbounds GEP are non-negative Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: wujingyue at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified http://llvm.org/docs/doxygen/html/SeparateConstOffsetFromGEP_8cpp_source.html#l00658 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 11:24:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 18:24:07 +0000 Subject: [LLVMbugs] [Bug 23712] Split of debug info in SROA triggers assertion in verifier In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23712 Adrian Prantl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |WONTFIX -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 12:40:53 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 19:40:53 +0000 Subject: [LLVMbugs] [Bug 23736] New: bug in inline namespaces Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23736 Bug ID: 23736 Summary: bug in inline namespaces Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: vanyacpp at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified This code defines function a::f, but I believe it should defines function a::b::f. GCC defines a::b::f. namespace a { inline namespace b { void f(); } } void a::f() { } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 15:08:45 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 22:08:45 +0000 Subject: [LLVMbugs] [Bug 23737] New: SROA replaces atomic volatile load with volatile load Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23737 Bug ID: 23737 Summary: SROA replaces atomic volatile load with volatile load Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: david.majnemer at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified consider: target triple = "x86_64-pc-linux" define void @f(i64** %x) { entry: %ptr = alloca i64, align 8 store i64 0, i64* %ptr, align 8 %load = load atomic volatile i64, i64* %ptr seq_cst, align 8 ret void } running -sroa results in: target triple = "x86_64-pc-linux" define void @f(i64** %x) { entry: %ptr = alloca i64, align 8 store i64 0, i64* %ptr, align 8 %ptr.0.load = load volatile i64, i64* %ptr, align 8 ret void } This doesn't seem correct. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 15:15:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 22:15:26 +0000 Subject: [LLVMbugs] [Bug 23733] [Windows] Clang doesn't support std::atomic with Microsoft's STL In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23733 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Resolution|--- |FIXED Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com |org | --- Comment #1 from David Majnemer --- Fixed in r238877. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 15:15:27 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 22:15:27 +0000 Subject: [LLVMbugs] [Bug 13707] [meta] VCPP compatibility issues In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=13707 Bug 13707 depends on bug 23733, which changed state. Bug 23733 Summary: [Windows] Clang doesn't support std::atomic with Microsoft's STL https://llvm.org/bugs/show_bug.cgi?id=23733 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 15:58:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 22:58:05 +0000 Subject: [LLVMbugs] [Bug 23738] New: SelectionDAG crashes on switch-case: Assertion failed: ((High - Low + 1).sle(BitWidth) && "Case range must fit in bit mask!") Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23738 Bug ID: 23738 Summary: SelectionDAG crashes on switch-case: Assertion failed: ((High - Low + 1).sle(BitWidth) && "Case range must fit in bit mask!") Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedbugs at nondot.org Reporter: sanjoy at playingwithpointers.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Running llc on declare void @g() declare void @h() define void @f(i4 %a) { entry: switch i4 %a, label %left [ i4 0, label %right i4 1, label %right i4 -5, label %right ] right: call void @g() ret void left: call void @h() ret void } crashes with an assertion failure. debug+asserts-x86 $ ~/Code/llvm.git/build/release+asserts-all/bin/llc ~/tmp/reduced.ll Assertion failed: ((High - Low + 1).sle(BitWidth) && "Case range must fit in bit mask!"), function buildBitTests, file ../../lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp, line 7613. 0 llc 0x000000010f7d0899 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 57 1 llc 0x000000010f7d148b SignalHandler(int) + 875 2 libsystem_platform.dylib 0x00007fff8a866f1a _sigtramp + 26 3 llc 0x00000001100ed45c llvm::InlineCostAnalysis::ID + 63417 4 llc 0x000000010f7d1076 abort + 22 5 llc 0x000000010f7d1051 __assert_rtn + 81 6 llc 0x000000010f6f672e llvm::SelectionDAGBuilder::buildBitTests(std::__1::vector >&, unsigned int, unsigned int, llvm::SwitchInst const*, llvm::SelectionDAGBuilder::CaseCluster&) + 5374 7 llc 0x000000010f6f7386 llvm::SelectionDAGBuilder::findBitTestClusters(std::__1::vector >&, llvm::SwitchInst const*) + 3062 8 llc 0x000000010f6c75b0 llvm::SelectionDAGBuilder::visitSwitch(llvm::SwitchInst const&) + 2560 9 llc 0x000000010f6c4689 llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 73 10 llc 0x000000010f7106f8 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 40 11 llc 0x000000010f71036e llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 8830 12 llc 0x000000010f70d104 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1444 13 llc 0x000000010ede95d4 (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 20 14 llc 0x000000010f19929c llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 140 15 llc 0x000000010f40bf93 llvm::FPPassManager::runOnFunction(llvm::Function&) + 515 16 llc 0x000000010f40c1db llvm::FPPassManager::runOnModule(llvm::Module&) + 43 17 llc 0x000000010f40c793 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 1123 18 llc 0x000000010e6c3c7a main + 8362 19 libdyld.dylib 0x00007fff96fa55c9 start + 1 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 16:11:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 23:11:31 +0000 Subject: [LLVMbugs] [Bug 23603] invalid sinking of invariant loads in codegen In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23603 Sanjoy Das changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Sanjoy Das --- Fixed in r238881. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 16:22:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 02 Jun 2015 23:22:17 +0000 Subject: [LLVMbugs] [Bug 23740] New: dependent expr created by delayed typo correction leads to crash Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23740 Bug ID: 23740 Summary: dependent expr created by delayed typo correction leads to crash Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: david.majnemer at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified consider: void f(long *a, long b) { __atomic_or_fetch(a, b, c); } results in: clang/lib/AST/ExprConstant.cpp:8659: {anonymous}::ICEDiag CheckICE(const clang::Expr*, const clang::ASTContext&): Assertion `!E->isValueDependent() && "Should not see value dependent exprs!"' failed. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 2 18:10:00 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 03 Jun 2015 01:10:00 +0000 Subject: [LLVMbugs] [Bug 23741] New: Machine operand's 'IsDead' flag set in the register coalescing pass becomes invalid after virtual register rewriter pass Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23741 Bug ID: 23741 Summary: Machine operand's 'IsDead' flag set in the register coalescing pass becomes invalid after virtual register rewriter pass Product: new-bugs Version: trunk Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: arphaman at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14425 --> https://llvm.org/bugs/attachment.cgi?id=14425&action=edit LLVM IR that reproduces the bug. The register coalescing pass sets the IsDead register flag on a physical register machine operand while re materializing a COPY instruction. But this flag isn't cleared in the virtual register rewriter pass, when a virtual register in one of the machine operand in a successor MBB is replaced with the same physical register. This behavior can be observed when running llc and printing the machine instructions on the attached file 'hoist-common.ll' (llc -march=x86-64 -print-machineinstrs hoist-common.ll). The output after register coalescing pass has an instruction that marks EAX as dead (%EAX = MOV32r0 %EFLAGS, %AL) in MBB#2, but the output after virtual register rewriter pass has a KILL instruction that uses EAX (%AL = KILL %AL, %EAX) in MBB#3, which is a successor to MBB#2. The commit that introduced the setting of the IsDead machine operand flag in the re materializer in the register coalescing pass is r184002 (http://llvm.org/viewvc/llvm-project?view=revision&revision=184002). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 3 03:18:37 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 03 Jun 2015 10:18:37 +0000 Subject: [LLVMbugs] [Bug 23082] Assertion failed: isa(IRType) && "Trying to return a non-vector type in a vector register!" In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23082 Andrea Di Biagio changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrea Di Biagio --- Fixed at revision 238861 http://llvm.org/viewvc/llvm-project?view=revision&revision=238861 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 3 04:51:33 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 03 Jun 2015 11:51:33 +0000 Subject: [LLVMbugs] [Bug 23743] New: Sibling loops confuse spill placement Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23743 Bug ID: 23743 Summary: Sibling loops confuse spill placement Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Register Allocator Assignee: unassignedbugs at nondot.org Reporter: james.molloy at arm.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14426 --> https://llvm.org/bugs/attachment.cgi?id=14426&action=edit Testcase In the attached testcase there is one loop with two child loops. The two child loops are siblings to each other. A reloaded is inserted in the second sibling loop, instead of a different register being spilled outside the second loop. The register being spilled is %vreg7: selectOrSplit rGPR:%vreg45 [576r,656B:0)[656B,976r:1)[976r,1104B:2) 0 at 576r 1 at 656B-phi 2 at 976r w=2.185477e+05 %R10 is available at cost 1 Only trying the first 10 regs. should evict: %vreg23 [160r,1184B:0) 0 at 160r w= 4.682460e+04 should evict: %vreg1 [80r,1184B:0) 0 at 80r w= 2.164171e+04 should evict: %vreg8 [560r,1104B:0) 0 at 560r w= 2.003648e+04 should evict: %vreg7 [496r,1104B:0) 0 at 496r w= 1.771947e+04 evicting %R6 interference: Cascade 4 unassigning %vreg7 from %R6: R6 assigning %vreg45 to %R6: R6 [576r,656B:0)[656B,976r:1)[976r,1104B:2) 0 at 576r 1 at 656B-phi 2 at 976r queuing new interval: %vreg7 [496r,1104B:0) 0 at 496r %vreg7 has the lowest spill cost because it is within an if/else inside the second loop. However, spilling %vreg23 or %vreg1 would not be as costly as %vreg7 because both of those registers are live-through the second loop (they are only used in the first loop). It appears the spill placement algorithm is aware of loop nest depth (implied by block frequency) but unaware of loop hierarchy. Compile with: llc -O3 test.ll and note: .LBB0_5: @ %bb21 @ Parent Loop BB0_2 Depth=1 @ => This Inner Loop Header: Depth=2 sub.w r8, r7, #2 cmp r8, r4 bhi .LBB0_7 @ BB#6: @ %bb27 @ in Loop: Header=BB0_5 Depth=2 ldrb.w r5, [r9, r7] lsl.w r2, lr, r11 eors r2, r5 ldr r5, [sp, #8] @ 4-byte Reload ***NAUGHTY*** and.w lr, r2, r5 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 3 09:08:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 03 Jun 2015 16:08:50 +0000 Subject: [LLVMbugs] [Bug 23744] New: Less efficient encoding of and using direct object emission Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23744 Bug ID: 23744 Summary: Less efficient encoding of and using direct object emission Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: MC Assignee: unassignedbugs at nondot.org Reporter: russell_gallop at sn.scee.net CC: llvmbugs at cs.uiuc.edu Classification: Unclassified "and" has a less efficient encoding when using direct object emission, compared to outputting assembly (-O1/2/3). Found with running check_cfc.py dash_s_no_change on the llvm-test-suite (r238815). Reduced from function_try_block.cpp $ cat test.cpp static int a; void fn1() { if (a) a = 0; a = 1; } $ clang++ -O1 -c test.cpp && objdump -d test.o test.o: file format elf64-x86-64 ... 0000000000000000 <_Z3fn1v>: 0: 0f b6 05 00 00 00 00 movzbl 0x0(%rip),%eax # 7 <_Z3fn1v+0x7> 7: 25 01 00 00 00 and $0x1,%eax ... $ clang++ -O1 -c test.cpp -via-file-asm && objdump -d test.o test.o: file format elf64-x86-64 ... 0000000000000000 <_Z3fn1v>: 0: 0f b6 05 00 00 00 00 movzbl 0x0(%rip),%eax # 7 <_Z3fn1v+0x7> 7: 83 e0 01 and $0x1,%eax ... -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 3 12:08:48 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 03 Jun 2015 19:08:48 +0000 Subject: [LLVMbugs] [Bug 23746] New: test-suite lacks CMake support Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23746 Bug ID: 23746 Summary: test-suite lacks CMake support Product: Test Suite Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Nightly Tester Assignee: unassignedbugs at nondot.org Reporter: grosbach at apple.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified test-suite is solely autoconf driven. This in itself isn't a huge deal, but it also is unable to configure and run against a CMake+ninja LLVM/clang build via --with-llvmobj. We should improve the interoperability of the test suite and CMake style LLVM builds. Ideally this would mean implementing CMake scripts for the test suite, but could also be generally resolved by teaching the current Makefiles to work well with various CMake generated build directories. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 3 16:17:09 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 03 Jun 2015 23:17:09 +0000 Subject: [LLVMbugs] [Bug 23748] New: Tag lookup should not find hidden declarations Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23748 Bug ID: 23748 Summary: Tag lookup should not find hidden declarations Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Modules Assignee: unassignedclangbugs at nondot.org Reporter: rjmccall at apple.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14432 --> https://llvm.org/bugs/attachment.cgi?id=14432&action=edit a test case demonstrating the problem Currently, LookupResult::isHiddenDeclarationVisible() is defined as follows: bool isHiddenDeclarationVisible() const { return AllowHidden || LookupKind == Sema::LookupTagName; } This is trying to ensure that elaborated type specifiers are linked into existing declaration chains even if those declarations are hidden. This is necessary in C because we don't perform a second redeclaration lookup when the initial lookup didn't find anything. (It's not necessary in C++ because we have to perform that redeclaration lookup anyway, because of friends.) Unfortunately, it can lead to incorrect results if the tag lookup finds something hidden in an inner scope when it should have found something non-hidden in an outer scope. That can't happen in C because there's only one open scope to which modules can add declarations, the global scope; but it can happen in C++ because of namespaces. I've attached a simple testcase which reproduces the problem. The code should compile because the elaborated type specifier should find the non-hidden declaration ::A from Module.h instead of the hidden declaration ns::A from Submodule.h. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 3 17:35:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 00:35:39 +0000 Subject: [LLVMbugs] [Bug 23749] New: CMake option to Linking Clang and extra tools with dynamic libclang Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23749 Bug ID: 23749 Summary: CMake option to Linking Clang and extra tools with dynamic libclang Product: clang Version: unspecified Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: eugene.zelenko at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I think will be good idea to provide CMake option to link Clang and its tools (extra, Include What You Use, etc) with libclang instead of static libraries, already presented in libclang. This will reduce size of resulting binaries. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 3 18:42:22 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 01:42:22 +0000 Subject: [LLVMbugs] [Bug 23750] New: preprocessor should warn on #include_next with a filename different from the including name Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23750 Bug ID: 23750 Summary: preprocessor should warn on #include_next with a filename different from the including name Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: richard-llvm at metafoo.co.uk CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Suppose: main.cpp: #include "foo/bar.h" foo/bar.h: #pragma once // or an include guard #include_next "bar.h" baz/bar.h: extern int n; ... and we compile main.cpp with -Ifoo -Ibaz: main.cpp includes foo/bar.h foo/bar.h includes *itself* Note that baz/bar.h is never included, and confusion reigns. We should issue a warning if a file issues a #include_once with a name that would not have found that same file in the starting search directory for the #include_next search (that is, if the includer used the wrong name for the file). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 3 18:58:03 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 01:58:03 +0000 Subject: [LLVMbugs] [Bug 23517] Constant builtin operands should be emitted as constants, even with UBSan In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23517 Ahmed Bougacha changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Ahmed Bougacha --- This should be fixed by r239002. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 3 21:17:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 04:17:40 +0000 Subject: [LLVMbugs] [Bug 23751] New: wrong code at -Os and above on x86_64-linux-gnu Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23751 Bug ID: 23751 Summary: wrong code at -Os and above on x86_64-linux-gnu Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: su at cs.ucdavis.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following code is miscompiled by the current clang trunk on x86_64-linux-gnu at -Os and above in both 32-bit and 64-bit modes. This is a regression from 3.6.x. $ clang-trunk -v clang version 3.7.0 (trunk 238951) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.1.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.1.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang-trunk -O1 small.c; ./a.out $ clang-3.6.1 -Os small.c; ./a.out $ $ clang-trunk -Os small.c $ ./a.out Aborted (core dumped) $ -------------------------------- int *a, b, **c = &a, d; unsigned fn1 (int p1, int p2) { return p1 + p2; } void fn2 (unsigned char p) { *c = &b; *a = p > fn1 (p, d | -2); } int main () { fn2 (2); if (b != 1) __builtin_abort (); return 0; } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 3 21:20:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 04:20:47 +0000 Subject: [LLVMbugs] [Bug 23752] New: wrong code at -O1 and above on x86_64-linux-gnu Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23752 Bug ID: 23752 Summary: wrong code at -O1 and above on x86_64-linux-gnu Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: su at cs.ucdavis.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following code is miscompiled by the current clang trunk on x86_64-linux-gnu at -O1 and above in both 32-bit and 64-bit modes. This is a regression from 3.6.x. $ clang-trunk -v clang version 3.7.0 (trunk 238951) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.1.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.1.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang-trunk -O0 small.c; ./a.out $ clang-3.6.1 -O1 small.c; ./a.out $ $ clang-trunk -O1 small.c $ ./a.out Aborted (core dumped) $ ------------------------------ int a, b[2], c, d, *e = &a; static int fn1 (int p) { return p; } int main () { int f = 0; for (; d < 2; d++) { *e = f; if (fn1 (&c != &b[1])) f = 1; } if (a != 1) __builtin_abort (); return 0; } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 3 21:28:45 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 04:28:45 +0000 Subject: [LLVMbugs] [Bug 23753] New: clang crashes at -O1 and above on x86_64-linux-gnu Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23753 Bug ID: 23753 Summary: clang crashes at -O1 and above on x86_64-linux-gnu Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: su at cs.ucdavis.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The current clang trunk crashes when compiling the following test case on x86_64-linux-gnu at -O1 and above in both 32-bit and 64-bit modes. This is a regression from 3.6.x. $ clang-trunk -v clang version 3.7.0 (trunk 238951) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.1.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.1.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang-trunk -O0 -c small.c $ clang-3.6.1 -O1 -c small.c $ $ clang-trunk -O1 -c small.c clang: /tmp/llvm/include/llvm/Support/Casting.h:237: typename cast_retty::ret_type llvm::cast(Y *) [X = llvm::ConstantInt, Y = llvm::Value]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. #0 0x2acbd48 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang+0x2acbd48) #1 0x2acd0eb (/usr/local/clang-trunk/bin/clang+0x2acd0eb) #2 0x7f4071e8b340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #3 0x7f4070e26cc9 gsignal /build/buildd/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #4 0x7f4070e2a0d8 abort /build/buildd/eglibc-2.19/stdlib/abort.c:91:0 #5 0x7f4070e1fb86 __assert_fail_base /build/buildd/eglibc-2.19/assert/assert.c:92:0 #6 0x7f4070e1fc32 (/lib/x86_64-linux-gnu/libc.so.6+0x2fc32) #7 0x29536dc (/usr/local/clang-trunk/bin/clang+0x29536dc) #8 0x2967b33 llvm::ConstantExpr::getGetElementPtr(llvm::Type*, llvm::Constant*, llvm::ArrayRef, bool, llvm::Type*) (/usr/local/clang-trunk/bin/clang+0x2967b33) #9 0x282cfd3 (/usr/local/clang-trunk/bin/clang+0x282cfd3) #10 0x282c236 llvm::SCEVExpander::expandAddToGEP(llvm::SCEV const* const*, llvm::SCEV const* const*, llvm::PointerType*, llvm::Type*, llvm::Value*) (/usr/local/clang-trunk/bin/clang+0x282c236) #11 0x282e063 llvm::SCEVExpander::visitAddExpr(llvm::SCEVAddExpr const*) (/usr/local/clang-trunk/bin/clang+0x282e063) #12 0x282d312 llvm::SCEVExpander::expand(llvm::SCEV const*) (/usr/local/clang-trunk/bin/clang+0x282d312) #13 0x282f994 llvm::SCEVExpander::getAddRecExprPHILiterally(llvm::SCEVAddRecExpr const*, llvm::Loop const*, llvm::Type*, llvm::Type*, llvm::Type*&, bool&) (/usr/local/clang-trunk/bin/clang+0x282f994) #14 0x283091a llvm::SCEVExpander::expandAddRecExprLiterally(llvm::SCEVAddRecExpr const*) (/usr/local/clang-trunk/bin/clang+0x283091a) #15 0x282d312 llvm::SCEVExpander::expand(llvm::SCEV const*) (/usr/local/clang-trunk/bin/clang+0x282d312) #16 0x283056b llvm::SCEVExpander::expandCodeFor(llvm::SCEV const*, llvm::Type*, llvm::Instruction*) (/usr/local/clang-trunk/bin/clang+0x283056b) #17 0x25670a5 (/usr/local/clang-trunk/bin/clang+0x25670a5) #18 0x2550756 (/usr/local/clang-trunk/bin/clang+0x2550756) #19 0x2546dea (/usr/local/clang-trunk/bin/clang+0x2546dea) #20 0x27c71ae llvm::LPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang+0x27c71ae) #21 0x2a2fb44 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang+0x2a2fb44) #22 0x2a2fd7b llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/local/clang-trunk/bin/clang+0x2a2fd7b) #23 0x2a30265 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/clang-trunk/bin/clang+0x2a30265) #24 0x95d74d clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) (/usr/local/clang-trunk/bin/clang+0x95d74d) #25 0x94fae5 (/usr/local/clang-trunk/bin/clang+0x94fae5) #26 0xb65e83 clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/clang-trunk/bin/clang+0xb65e83) #27 0x756f0e clang::FrontendAction::Execute() (/usr/local/clang-trunk/bin/clang+0x756f0e) #28 0x72863c clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/local/clang-trunk/bin/clang+0x72863c) #29 0x70b6ec clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/local/clang-trunk/bin/clang+0x70b6ec) #30 0x7028b2 cc1_main(llvm::ArrayRef, char const*, void*) (/usr/local/clang-trunk/bin/clang+0x7028b2) #31 0x709e7e main (/usr/local/clang-trunk/bin/clang+0x709e7e) #32 0x7f4070e11ec5 __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:321:0 #33 0x70252d _start (/usr/local/clang-trunk/bin/clang+0x70252d) Stack dump: 0. Program arguments: /usr/local/clang-trunk/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.24 -momit-leaf-frame-pointer -dwarf-column-info -coverage-file /data2/c-hunter-results/C/instrument-bugs/CSMITH/CLANG/20150517-clang-trunk-m64-g-O3-build-054213/small.c -resource-dir /usr/local/clang-trunk/bin/../lib/clang/3.7.0 -internal-isystem /usr/local/include -internal-isystem /usr/local/clang-trunk/bin/../lib/clang/3.7.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O1 -fdebug-compilation-dir /data2/c-hunter-results/C/instrument-bugs/CSMITH/CLANG/20150517-clang-trunk-m64-g-O3-build-054213 -ferror-limit 19 -fmessage-length 94 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o small.o -x c small.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'small.c'. 4. Running pass 'Loop Pass Manager' on function '@fn1' 5. Running pass 'Loop Strength Reduction' on basic block '%for.body' clang: error: unable to execute command: Aborted (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (trunk 238951) Target: x86_64-unknown-linux-gnu Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/small-a1eb8a.c clang: note: diagnostic msg: /tmp/small-a1eb8a.sh clang: note: diagnostic msg: ******************** $ ------------------------------ int a[1], b, *c = &b; char d; void fn1 () { int e; for (; e; e++) { b = &a[e] != (int *)&d; *c = 0; } } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 3 21:36:48 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 04:36:48 +0000 Subject: [LLVMbugs] [Bug 23754] New: clang crashes on valid code at -O2 and -O3 on x86_64-linux-gnu Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23754 Bug ID: 23754 Summary: clang crashes on valid code at -O2 and -O3 on x86_64-linux-gnu Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: su at cs.ucdavis.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The current clang trunk crashes when compiling the following test case on x86_64-linux-gnu at -O2 and -O3 in both 32-bit and 64-bit modes. This is a regression from 3.6.x. $ clang-trunk -v clang version 3.7.0 (trunk 238951) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.1.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.1.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang-trunk -Os small.c; ./a.out $ clang-3.6.1 -O2 small.c; ./a.out $ $ clang-trunk -O2 small.c clang: /tmp/llvm/include/llvm/Support/Casting.h:237: typename cast_retty::ret_type llvm::cast(Y *) [X = llvm::ConstantInt, Y = llvm::Value]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. #0 0x2acbd48 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang+0x2acbd48) #1 0x2acd0eb (/usr/local/clang-trunk/bin/clang+0x2acd0eb) #2 0x7f221aff4340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #3 0x7f2219f8fcc9 gsignal /build/buildd/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #4 0x7f2219f930d8 abort /build/buildd/eglibc-2.19/stdlib/abort.c:91:0 #5 0x7f2219f88b86 __assert_fail_base /build/buildd/eglibc-2.19/assert/assert.c:92:0 #6 0x7f2219f88c32 (/lib/x86_64-linux-gnu/libc.so.6+0x2fc32) #7 0x29536dc (/usr/local/clang-trunk/bin/clang+0x29536dc) #8 0x2967b33 llvm::ConstantExpr::getGetElementPtr(llvm::Type*, llvm::Constant*, llvm::ArrayRef, bool, llvm::Type*) (/usr/local/clang-trunk/bin/clang+0x2967b33) #9 0x282cfd3 (/usr/local/clang-trunk/bin/clang+0x282cfd3) #10 0x282c236 llvm::SCEVExpander::expandAddToGEP(llvm::SCEV const* const*, llvm::SCEV const* const*, llvm::PointerType*, llvm::Type*, llvm::Value*) (/usr/local/clang-trunk/bin/clang+0x282c236) #11 0x282e063 llvm::SCEVExpander::visitAddExpr(llvm::SCEVAddExpr const*) (/usr/local/clang-trunk/bin/clang+0x282e063) #12 0x282d312 llvm::SCEVExpander::expand(llvm::SCEV const*) (/usr/local/clang-trunk/bin/clang+0x282d312) #13 0x283056b llvm::SCEVExpander::expandCodeFor(llvm::SCEV const*, llvm::Type*, llvm::Instruction*) (/usr/local/clang-trunk/bin/clang+0x283056b) #14 0x25670a5 (/usr/local/clang-trunk/bin/clang+0x25670a5) #15 0x2550756 (/usr/local/clang-trunk/bin/clang+0x2550756) #16 0x2546dea (/usr/local/clang-trunk/bin/clang+0x2546dea) #17 0x27c71ae llvm::LPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang+0x27c71ae) #18 0x2a2fb44 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang+0x2a2fb44) #19 0x2a2fd7b llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/local/clang-trunk/bin/clang+0x2a2fd7b) #20 0x2a30265 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/clang-trunk/bin/clang+0x2a30265) #21 0x95d74d clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) (/usr/local/clang-trunk/bin/clang+0x95d74d) #22 0x94fae5 (/usr/local/clang-trunk/bin/clang+0x94fae5) #23 0xb65e83 clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/clang-trunk/bin/clang+0xb65e83) #24 0x756f0e clang::FrontendAction::Execute() (/usr/local/clang-trunk/bin/clang+0x756f0e) #25 0x72863c clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/local/clang-trunk/bin/clang+0x72863c) #26 0x70b6ec clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/local/clang-trunk/bin/clang+0x70b6ec) #27 0x7028b2 cc1_main(llvm::ArrayRef, char const*, void*) (/usr/local/clang-trunk/bin/clang+0x7028b2) #28 0x709e7e main (/usr/local/clang-trunk/bin/clang+0x709e7e) #29 0x7f2219f7aec5 __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:321:0 #30 0x70252d _start (/usr/local/clang-trunk/bin/clang+0x70252d) Stack dump: 0. Program arguments: /usr/local/clang-trunk/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.24 -momit-leaf-frame-pointer -dwarf-column-info -resource-dir /usr/local/clang-trunk/bin/../lib/clang/3.7.0 -internal-isystem /usr/local/include -internal-isystem /usr/local/clang-trunk/bin/../lib/clang/3.7.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -fdebug-compilation-dir /data2/c-hunter-results/C/instrument-bugs/CSMITH/CLANG/20150522-clang-trunk-m64-g-O3-build-054017 -ferror-limit 19 -fmessage-length 94 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/small-3bce16.o -x c small.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'small.c'. 4. Running pass 'Loop Pass Manager' on function '@main' 5. Running pass 'Loop Strength Reduction' on basic block '%for.cond.1.preheader.i' clang: error: unable to execute command: Aborted (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (trunk 238951) Target: x86_64-unknown-linux-gnu Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/small-b94542.c clang: note: diagnostic msg: /tmp/small-b94542.sh clang: note: diagnostic msg: ******************** $ ------------------------------------ int a[22], b, d, e; char c; void fn1 (char *p) { int f; for (f = 0; f < 22; f++) for (e = 0; e < 2; e++) for (; b; b++) d = &a[f] != (int *)p; } int main () { fn1 (&c); return 0; } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 3 23:02:00 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 06:02:00 +0000 Subject: [LLVMbugs] [Bug 23755] New: attempted to build llvm again using formerly built llvm Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23755 Bug ID: 23755 Summary: attempted to build llvm again using formerly built llvm Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: goochmi at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified downloaded sources for 3.6.1 extracted the tarballs clang extra tools was symlinked into the clang source tree as tools/extra clang was symlinked into llvm source tree as tools/clang lld was symlinked into llvm source tree as tools/lld compiler-rt was symlinked into llvm source tree as projects/compiler-rt libcxx was symlinked into llvm source tree as projects/libcxx libcxxabi was symlinked into llvm source tree as projects/libcxxabi I built this once using GCC and libstdc++. I was hoping to build it again using the now available clang/clang++ and libc++/libc++abi, but when I attempt this, various executable linking stages fail claiming they can't find __cxa_guard_acquire, __cxa_guard_release, and __cxa_pure_virtual this seems to indicate something isn't being linked against libc++, or that libc++ lacks those symbols/targets for some reason. it is ENTIRELY possible that I did something incorrectly with my former build or setup or that I am doing something incorrectly this time. the command for cmake would be something like this correct?: cmake /path/to/llvm/source/tree \ -DCMAKE_INSTALL_PREFIX=/UCHC/HPC/Gooch/biotoolmodules/llvm_suite/3.6.1 \ -DCMAKE_C_COMPILER=/UCHC/HPC/Gooch/biotoolmodules/llvm_suite/3.6.1/bin/clang \ -DCMAKE_CXX_COMPILER=/UCHC/HPC/Gooch/biotoolmodules/llvm_suite/3.6.1/bin/clang++ \ -DLLVM_ENABLE_LIBCXX=1 \ -DLIBCXX_CXX_ABI=libcxxabi if not, what am I missing? -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 4 00:02:53 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 07:02:53 +0000 Subject: [LLVMbugs] [Bug 23753] clang crashes at -O1 and above on x86_64-linux-gnu In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23753 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Component|-New Bugs |Core LLVM classes Resolution|--- |FIXED Assignee|unassignedclangbugs at nondot. |unassignedbugs at nondot.org |org | Product|clang |libraries --- Comment #3 from David Majnemer --- Fixed in r239015. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 4 00:09:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 07:09:07 +0000 Subject: [LLVMbugs] [Bug 23754] clang crashes on valid code at -O2 and -O3 on x86_64-linux-gnu In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23754 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Resolution|--- |DUPLICATE --- Comment #1 from David Majnemer --- This seems identical to PR23753 and doesn't reproduce after applying it's fix, r239015. *** This bug has been marked as a duplicate of bug 23753 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 4 07:54:43 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 14:54:43 +0000 Subject: [LLVMbugs] [Bug 23756] New: crash caused by assignment to anonymous class Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23756 Bug ID: 23756 Summary: crash caused by assignment to anonymous class Product: new-bugs Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: tomilovanatoliy at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14433 --> https://llvm.org/bugs/attachment.cgi?id=14433&action=edit source Crush with following message: clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.6.0 (tags/RELEASE_360/final 235480) Target: x86_64-unknown-linux-gnu Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/main-f52826.cpp clang: note: diagnostic msg: /tmp/main-f52826.sh clang: note: diagnostic msg: ******************** Invocation: "/usr/local/bin/clang" "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-emit-obj" "-mrelax-all" "-disable-free" "-disable-llvm-verifier" "-main-file-name" "main.cpp" "-mrelocation-model" "static" "-mthread-model" "posix" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-fuse-init-array" "-target-cpu" "x86-64" "-target-linker-version" "2.22" "-dwarf-column-info" "-Weverything" "-Wno-c++98-compat" "-Wno-c++98-compat-pedantic" "-Wno-c++98-compat" "-pedantic" "-w" "-std=gnu++1z" "-fdeprecated-macro" "-ferror-limit" "19" "-fmessage-length" "0" "-mstackrealign" "-fobjc-runtime=gcc" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" "-x" "c++" "main-f52826.cpp" -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 4 08:55:25 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 15:55:25 +0000 Subject: [LLVMbugs] [Bug 23738] SelectionDAG crashes on switch-case: Assertion failed: ((High - Low + 1).sle(BitWidth) && "Case range must fit in bit mask!") In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23738 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- Fixed in r239048. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 4 09:08:16 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 16:08:16 +0000 Subject: [LLVMbugs] [Bug 23757] New: incorrect comparison result between INT_MAX and INT_MIN with optimizations Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23757 Bug ID: 23757 Summary: incorrect comparison result between INT_MAX and INT_MIN with optimizations Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: todd at cloudera.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following program gives different results with -O1 vs -O0: #define __STDC_LIMIT_MACROS #include #include #include using namespace std; bool Increment32(int32_t* cell_ptr) { int32_t orig = *cell_ptr; int32_t inc; // Signed overflow is undefined in C. So, we'll use a branch here // instead of counting on undefined behavior. if (orig == INT32_MAX) { inc = INT32_MIN; } else { inc = orig + 1; } *cell_ptr = inc; return inc > orig; } int main(int argc, char** argv) { int32_t input = INT32_MAX; cout << "input: " << input << endl; bool ret = Increment32(&input); cout << "output: " << input << endl; if (ret) { cout << "BAD ANSWER" << endl; } return 0; } I narrowed it down to the following set of passes on llvm 3.4: todd at todd-ThinkPad-T540p:/tmp$ $I/clang++ -O0 -c -emit-llvm test.cc todd at todd-ThinkPad-T540p:/tmp$ $I/opt -sroa -simplifycfg -instcombine -o test-opt.bc test.bc ; $I/clang++ -o test test-opt.bc ; ./test input: 2147483647 output: -2147483648 WRONG ANSWER I also verified that a 3.7 build (from the chromium toolchain) has the same bug. Compiling with -fwrapv or -fsanitize=undefined makes the error go away. gcc doesn't have the same issue. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 4 10:30:54 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 17:30:54 +0000 Subject: [LLVMbugs] [Bug 23758] New: Gigantic block frequencies produced by clang in PGO Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23758 Bug ID: 23758 Summary: Gigantic block frequencies produced by clang in PGO Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: congh at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14434 --> https://llvm.org/bugs/attachment.cgi?id=14434&action=edit CFG with edge frequencies. When compiling spec2000 in PGO mode, I noticed many very large block frequencies for some programs. They are too big to be true. One example is 164.gzip in spec2000. I made the profile data from running the binary with options "input.random 60". The produced CFG is attached here, which shows the hottest block has the frequency over 14E12. Note that the frequency of the entry node is only 17, which means that the hottest node runs almost 1E12 times more that the entry. To find out the actual frequency of that hot node, I profiled the same program using GCC, and also inserted a counter manually to the program. Both showed that the hottest node ran only about 4E7 times more than the entry. So I think there may be something wrong in LLVM's frequency calculation. (In the attached CFG, the numbers on edges are frequencies.) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 4 11:01:08 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 18:01:08 +0000 Subject: [LLVMbugs] [Bug 23741] Machine operand's 'IsDead' flag set in the register coalescing pass becomes invalid after virtual register rewriter pass In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23741 Quentin Colombet changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Quentin Colombet --- Oh wait, EAX is never really used. Only AL is. The MIR is then valid to me. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 4 12:58:38 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 19:58:38 +0000 Subject: [LLVMbugs] [Bug 23761] New: Installing scan-build and scan-view Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23761 Bug ID: 23761 Summary: Installing scan-build and scan-view Product: clang Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Static Analyzer Assignee: kremenek at apple.com Reporter: eugene.zelenko at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I think will be good idea to install scan-build and scan-view with as part of Clang installation. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 4 15:54:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 22:54:52 +0000 Subject: [LLVMbugs] [Bug 23710] [Win64] Indirect tail calls on non-Windows can use clobbered non-volatile register In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23710 Charles Davis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Charles Davis --- This should be fixed by r239111. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 4 16:11:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 04 Jun 2015 23:11:58 +0000 Subject: [LLVMbugs] [Bug 23757] incorrect comparison result between INT_MAX and INT_MIN with optimizations In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23757 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Resolution|--- |FIXED Assignee|unassignedbugs at nondot.org |david.majnemer at gmail.com --- Comment #3 from David Majnemer --- Fixed in r239115. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 4 17:03:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 00:03:55 +0000 Subject: [LLVMbugs] [Bug 23763] New: Floating Point Exception with -loop-vectorize and 0-sized type Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23763 Bug ID: 23763 Summary: Floating Point Exception with -loop-vectorize and 0-sized type Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedbugs at nondot.org Reporter: alex at crichton.co CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14438 --> https://llvm.org/bugs/attachment.cgi?id=14438&action=edit bugpoint-reduced IR When optimized with the `-loop-vectorize` pass via `opt`, the attached IR will trigger a floating point exception (divide-by-zero) in the optimization passes. The stack trace on failure is: $ ./Debug+Asserts/bin/opt bugpoint-reduced-simplified.ll -loop-vectorize -S 0 opt 0x00000000024c281e llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 46 1 opt 0x00000000024c3859 2 opt 0x00000000024c648d 3 libpthread.so.0 0x00007fc4b82a7340 4 opt 0x0000000001e4d8b8 llvm::isInductionPHI(llvm::PHINode*, llvm::ScalarEvolution*, llvm::ConstantInt*&) + 488 5 opt 0x0000000001a619c9 6 opt 0x0000000001a5fea0 7 opt 0x0000000001a400a9 8 opt 0x0000000001a3eacc 9 opt 0x0000000001a3e076 10 opt 0x00000000023e9c5b llvm::FPPassManager::runOnFunction(llvm::Function&) + 427 11 opt 0x00000000023e9f68 llvm::FPPassManager::runOnModule(llvm::Module&) + 104 12 opt 0x00000000023ea64a 13 opt 0x00000000023ea21e llvm::legacy::PassManagerImpl::run(llvm::Module&) + 302 14 opt 0x00000000023eac11 llvm::legacy::PassManager::run(llvm::Module&) + 33 15 opt 0x000000000084322e main + 7486 16 libc.so.6 0x00007fc4b72a6ec5 __libc_start_main + 245 17 opt 0x000000000081c474 Stack dump: 0. Program arguments: ./Debug+Asserts/bin/opt /home/alex/code/rust4/bugpoint-reduced-simplified.ll -loop-vectorize -S 1. Running pass 'Function Pass Manager' on module '/home/alex/code/rust4/bugpoint-reduced-simplified.ll'. 2. Running pass 'Loop Vectorization' on function '@foo' zsh: floating point exception (core dumped) ./Debug+Asserts/bin/opt ~/code/rust4/bugpoint-reduced-simplified.ll -S -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 4 17:38:27 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 00:38:27 +0000 Subject: [LLVMbugs] [Bug 23764] New: Clang and GCC disagree about triviality of type with defaulted non-const copy constructor (breaks ABI!) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23764 Bug ID: 23764 Summary: Clang and GCC disagree about triviality of type with defaulted non-const copy constructor (breaks ABI!) Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: kenton at sandstorm.io CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified The program below outputs 0 when compiled with Clang and 1 when compiled with G++. Unfortunately, this disagreement means that Clang and G++ implement different argument-passing conventions for functions which take an argument with such a type, and therefore libraries which use such types in their API (like Cap'n Proto) cannot be used unless the library and caller are built with the same compiler. #include class C { public: C(C&) = default; }; int main() { std::cout << __has_trivial_copy(C) << std::endl; return 0; } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 4 18:03:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 01:03:47 +0000 Subject: [LLVMbugs] [Bug 23766] New: musttail calls are not allowed to precede unreachable Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23766 Bug ID: 23766 Summary: musttail calls are not allowed to precede unreachable Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: kavon.farvardin at gmail.com CC: compnerd at compnerd.org, llvmbugs at cs.uiuc.edu Classification: Unclassified Consider the following code: declare void @g() noreturn define void @f() { entry: musttail call void @g() noreturn unreachable } llc rejects this with the following error: musttail call must be precede a ret with an optional bitcast musttail call void @g() #0 llc: musttail.ll: error: input module is broken! A conversation on IRC led to the conclusion that `unreachable` following a `musttail call` should be permitted. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 4 18:40:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 01:40:52 +0000 Subject: [LLVMbugs] [Bug 23767] New: Incorrect invalidation of iterator when using ranged deque::erase for first element in deque of size 2. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23767 Bug ID: 23767 Summary: Incorrect invalidation of iterator when using ranged deque::erase for first element in deque of size 2. Product: libc++ Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: hocheung20 at gmail.com CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified Created attachment 14439 --> https://llvm.org/bugs/attachment.cgi?id=14439&action=edit Short test program illustrating ranged deque::erase bug. According to the standard, all iterators and references are invalidated, unless the erased elements are at the end or the beginning of the container, in which case only the iterators and references to the erased elements are invalidated. In the case of deque of size 2, if you used ranged erase for remove the first element. Any iterators to the last element will no longer be valid. See attached example program. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 4 22:34:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 05:34:40 +0000 Subject: [LLVMbugs] [Bug 23764] Clang and GCC disagree about triviality of type with defaulted non-const copy constructor (breaks ABI!) In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23764 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Resolution|--- |DUPLICATE --- Comment #1 from David Majnemer --- Looks like a dupe of PR21010. *** This bug has been marked as a duplicate of bug 21010 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 4 22:56:02 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 05:56:02 +0000 Subject: [LLVMbugs] [Bug 23764] Clang and GCC disagree about triviality of type with defaulted non-const copy constructor (breaks ABI!) In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23764 Kenton Varda changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|DUPLICATE |--- --- Comment #2 from Kenton Varda --- I don't think this is a duplicate of bug 21010. They both describe problems related to copy triviality, but that bug describes a problem with destructors, whereas this bug describes a different problem with constructors. Moreover, this bug describes an ABI incompatibility with GCC which is causing real-world crashes when trying to link a clang-built binary against a GCC-built library or vice versa with valid code. In contrast, bug 21010 describes a case that I don't think could lead to an ABI problem with valid code (since it describes a class that shouldn't be allowed to be passed by value in the first place). This ABI incompatibility is the primary concern in my bug. (I think my class C may actually be non-trivially-copyable according to the standard, but that's not primarily what I care about.) It does seem like Richard's proposed rule would (perhaps accidentally?) solve the problem: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1590 This would at least solve the problem in my use cases because all my classes that have a default non-const copy constructor also have a trivial move constructor. It doesn't completely solve the problem in the case of a class with non-trivial move constructor, but that does seem like an odd case. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 5 03:53:37 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 10:53:37 +0000 Subject: [LLVMbugs] [Bug 23763] Floating Point Exception with -loop-vectorize and 0-sized type In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23763 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Resolution|--- |FIXED Assignee|unassignedbugs at nondot.org |david.majnemer at gmail.com --- Comment #2 from David Majnemer --- Fixed in r239143. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 5 07:54:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 14:54:56 +0000 Subject: [LLVMbugs] [Bug 23768] New: Machine CSE removes register-defining LDM, causing assertion failure Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23768 Bug ID: 23768 Summary: Machine CSE removes register-defining LDM, causing assertion failure Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedbugs at nondot.org Reporter: john.brawn.123 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14440 --> https://llvm.org/bugs/attachment.cgi?id=14440&action=edit Input IR that causes the assertion failure Compiling the attached bugpoint-reduced-simplified.ll with trunk (r239136) llc causes the assertion failure lib/CodeGen/LiveVariables.cpp:133: void llvm::LiveVariables::HandleVirtRegUse(unsigned int, llvm::MachineBasicBlock*, llvm::MachineInstr*): Assertion `MRI->getVRegDef(reg) && "Register use before def!"' failed. This has started happening since r238473, when the ARM backend started lowering memcpy->MCOPY->LDM+STM, but what's causing the assertion failure is that Machine CSE is getting this input: BB#0: derived from LLVM BB %testArray.exit.critedge %vreg0 = tLDRpci , pred:14, pred:%noreg; mem:LD4[ConstantPool] tGPR:%vreg0 %vreg1 = tLDRpci , pred:14, pred:%noreg; mem:LD4[ConstantPool] tGPR:%vreg1 %vreg3 = tLDMIA_UPD %vreg0, pred:14, pred:%noreg, %vreg4, %vreg5, %vreg6; tGPR:%vreg3,%vreg0,%vreg4,%vreg5,%vreg6 %vreg2 = tSTMIA_UPD %vreg1, pred:14, pred:%noreg, %vreg4, %vreg5, %vreg6; tGPR:%vreg2,%vreg1,%vreg4,%vreg5,%vreg6 %vreg8 = tLDMIA_UPD %vreg3, pred:14, pred:%noreg, %vreg9, %vreg10, %vreg11; tGPR:%vreg8,%vreg3,%vreg9,%vreg10,%vreg11 %vreg7 = tSTMIA_UPD %vreg2, pred:14, pred:%noreg, %vreg9, %vreg10, %vreg11; tGPR:%vreg7,%vreg2,%vreg9,%vreg10,%vreg11 %vreg13 = tLDMIA_UPD %vreg0, pred:14, pred:%noreg, %vreg14, %vreg15, %vreg16; tGPR:%vreg13,%vreg0,%vreg14,%vreg15,%vreg16 %vreg12 = tSTMIA_UPD %vreg1, pred:14, pred:%noreg, %vreg14, %vreg15, %vreg16; tGPR:%vreg12,%vreg1,%vreg14,%vreg15,%vreg16 %vreg18 = tLDMIA_UPD %vreg13, pred:14, pred:%noreg, %vreg19, %vreg20, %vreg21; tGPR:%vreg18,%vreg13,%vreg19,%vreg20,%vreg21 %vreg17 = tSTMIA_UPD %vreg12, pred:14, pred:%noreg, %vreg19, %vreg20, %vreg21; tGPR:%vreg17,%vreg12,%vreg19,%vreg20,%vreg21 tBX_RET pred:14, pred:%noreg It then does the following optimisation: Examining: %vreg13 = tLDMIA_UPD %vreg0, pred:14, pred:%noreg, %vreg14, %vreg15, %vreg16; tGPR:%vreg13,%vreg0,%vreg14,%vreg15,%vreg16 *** Found a common subexpression: %vreg3 = tLDMIA_UPD %vreg0, pred:14, pred:%noreg, %vreg4, %vreg5, %vreg6; tGPR:%vreg3,%vreg0,%vreg4,%vreg5,%vreg6 Examining: %vreg18 = tLDMIA_UPD %vreg3, pred:14, pred:%noreg, %vreg19, %vreg20, %vreg21; tGPR:%vreg18,%vreg3,%vreg19,%vreg20,%vreg21 *** Found a common subexpression: %vreg8 = tLDMIA_UPD %vreg3, pred:14, pred:%noreg, %vreg9, %vreg10, %vreg11; tGPR:%vreg8,%vreg3,%vreg9,%vreg10,%vreg11 giving the result BB#0: derived from LLVM BB %testArray.exit.critedge %vreg0 = tLDRpci , pred:14, pred:%noreg; mem:LD4[ConstantPool] tGPR:%vreg0 %vreg1 = tLDRpci , pred:14, pred:%noreg; mem:LD4[ConstantPool] tGPR:%vreg1 %vreg3 = tLDMIA_UPD %vreg0, pred:14, pred:%noreg, %vreg4, %vreg5, %vreg6; tGPR:%vreg3,%vreg0,%vreg4,%vreg5,%vreg6 %vreg2 = tSTMIA_UPD %vreg1, pred:14, pred:%noreg, %vreg4, %vreg5, %vreg6; tGPR:%vreg2,%vreg1,%vreg4,%vreg5,%vreg6 %vreg8 = tLDMIA_UPD %vreg3, pred:14, pred:%noreg, %vreg9, %vreg10, %vreg11; tGPR:%vreg8,%vreg3,%vreg9,%vreg10,%vreg11 %vreg7 = tSTMIA_UPD %vreg2, pred:14, pred:%noreg, %vreg9, %vreg10, %vreg11; tGPR:%vreg7,%vreg2,%vreg9,%vreg10,%vreg11 %vreg12 = tSTMIA_UPD %vreg1, pred:14, pred:%noreg, %vreg14, %vreg15, %vreg16; tGPR:%vreg12,%vreg1,%vreg14,%vreg15,%vreg16 %vreg17 = tSTMIA_UPD %vreg12, pred:14, pred:%noreg, %vreg19, %vreg20, %vreg21; tGPR:%vreg17,%vreg12,%vreg19,%vreg20,%vreg21 tBX_RET pred:14, pred:%noreg Virtual registers 14-16 and 19-21 now have no definition, leading to the above assertion failure. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 5 11:04:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 18:04:39 +0000 Subject: [LLVMbugs] [Bug 23756] crash caused by assignment to anonymous class In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23756 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Component|new bugs |C++'1z Resolution|--- |FIXED Assignee|unassignedbugs at nondot.org |unassignedclangbugs at nondot. | |org Product|new-bugs |clang --- Comment #1 from David Majnemer --- Fixed in r239170. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 5 11:05:41 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 18:05:41 +0000 Subject: [LLVMbugs] [Bug 23751] wrong code at -Os and above on x86_64-linux-gnu In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23751 Sanjoy Das changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs at nondot. |sanjoy at playingwithpointers. |org |com --- Comment #2 from Sanjoy Das --- Fixed in r239171 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 5 12:01:01 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 19:01:01 +0000 Subject: [LLVMbugs] [Bug 23769] New: scan-build results in Qt include errors starting with CMake 3.1.0 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23769 Bug ID: 23769 Summary: scan-build results in Qt include errors starting with CMake 3.1.0 Product: clang Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kremenek at apple.com Reporter: jason.erb at sparist.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Starting with CMake 3.1.0, running scan-build on a CMake project using Qt results in Qt include errors of the form: fatal error: 'QtCore/QObject' file not found #include ^ CMake 3.0.2 does not result in these errors. The CMake 3.1.0 changelog: http://www.cmake.org/cmake/help/v3.1/release/3.1.0.html -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 5 13:17:43 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 20:17:43 +0000 Subject: [LLVMbugs] [Bug 23770] New: Propagating dll attributes to template bases doesn't work for explicit instantiation Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23770 Bug ID: 23770 Summary: Propagating dll attributes to template bases doesn't work for explicit instantiation Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: hans at chromium.org CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Blocks: 13707 Classification: Unclassified Consider: template struct BaseTemplate { void f() {} }; template struct Template : BaseTemplate { }; extern template struct Template; template struct __declspec(dllexport) Template; MSVC will export BaseTemplate::f() here, but clang-cl fails to do so. (This is really just another aspect of Issue 23667.) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 5 14:58:35 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 21:58:35 +0000 Subject: [LLVMbugs] [Bug 20456] [Inline ASM][AArch64] Integer exceeds imm range In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20456 zhaoshiz at codeaurora.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 5 15:18:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 22:18:26 +0000 Subject: [LLVMbugs] [Bug 23771] New: UNREACHABLE in X86ELFObjectWriter.cpp:48 introduced by r232837 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23771 Bug ID: 23771 Summary: UNREACHABLE in X86ELFObjectWriter.cpp:48 introduced by r232837 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: rafael.espindola at gmail.com Reporter: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified r232837 broke 16bit calls for x86: .code16 call message asserts now. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 5 15:20:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 22:20:58 +0000 Subject: [LLVMbugs] [Bug 23772] New: [AArch64] r226200 can emit illegal thumb2 instruction: "sub sp, r12, #80" Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23772 Bug ID: 23772 Summary: [AArch64] r226200 can emit illegal thumb2 instruction: "sub sp, r12, #80" Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: zhaoshiz at codeaurora.org CC: apazos at codeaurora.org, hfinkel at anl.gov, llvmbugs at cs.uiuc.edu, mcrosier at codeaurora.org Classification: Unclassified r226200 allows coalescing into SP but missed a corner case: %vreg907 = COPY %SP; GPRnopc:%vreg907 %vreg908 = t2SUBri %vreg907, 80, pred:14, pred:%noreg, opt:%noreg; GPRnopc:%vreg908,%vreg907 %SP = COPY %vreg908; GPRnopc:%vreg908 When %vreg908 is coalesced into SP but %vreg907 is not, it's likely to emit an illegal instruction: sub sp, r12, #80 In Thumb2, we can only use SP as Rd if and only if Rn is also SP. This patch, when trying remove "%SP = COPY %vreg908", checks if %vreg907 is SP already. If not, be conservative and do not coalesce %vreg908 into SP. http://reviews.llvm.org/D10287 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 5 15:34:46 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 22:34:46 +0000 Subject: [LLVMbugs] [Bug 23767] Incorrect invalidation of iterator when using ranged deque::erase for first element in deque of size 2. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23767 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Marshall Clow (home) --- Fixed in revision 239196. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 5 16:41:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 05 Jun 2015 23:41:07 +0000 Subject: [LLVMbugs] [Bug 23773] New: check-asan failure on windows 8.1 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23773 Bug ID: 23773 Summary: check-asan failure on windows 8.1 Product: compiler-rt Version: 3.6 Hardware: PC OS: other Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedbugs at nondot.org Reporter: raymond.forbes at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I am trying to build clang with ASAN on Windows 8 using Visual Studio Update 3. C:\tools\llvm-build>ninja check-asan Recompacting log... Recompacting deps... [23/31] cmd.exe /C "cd /D C:\tools\llvm-build\projects\compiler...rt/lib/asan/tests/default/Asan-i386-with-calls-Noinst-Test.exe" Creating library C:/tools/llvm-build/projects/compiler-rt/lib/asan/tests/default/Asan-i386-with-calls-Noinst-Test.lib and objec t C:/tools/llvm-build/projects/compiler-rt/lib/asan/tests/default/Asan-i386-with-calls-Noinst-Test.exp [29/31] cmd.exe /C "cd /D C:\tools\llvm-build\projects\compiler...ler-rt/lib/asan/tests/default/Asan-i386-inline-Noinst-Test.exe" Creating library C:/tools/llvm-build/projects/compiler-rt/lib/asan/tests/default/Asan-i386-inline-Noinst-Test.lib and object C: /tools/llvm-build/projects/compiler-rt/lib/asan/tests/default/Asan-i386-inline-Noinst-Test.exp [29/31] cmd.exe /C "cd /D C:\tools\llvm-build\projects\compiler...san/tests/default/Asan-i386-inline-Test.exe -fsanitize=address" Creating library C:/tools/llvm-build/projects/compiler-rt/lib/asan/tests/default/Asan-i386-inline-Test.lib and object C:/tools/ llvm-build/projects/compiler-rt/lib/asan/tests/default/Asan-i386-inline-Test.exp [30/31] cmd.exe /C "cd /D C:\tools\llvm-build\projects\compiler...tests/default/Asan-i386-with-calls-Test.exe -fsanitize=address" Creating library C:/tools/llvm-build/projects/compiler-rt/lib/asan/tests/default/Asan-i386-with-calls-Test.lib and object C:/to ols/llvm-build/projects/compiler-rt/lib/asan/tests/default/Asan-i386-with-calls-Test.exp [31/31] Running the AddressSanitizer tests FAILED: cmd.exe /C "cd /D C:\tools\llvm-build\projects\compiler-rt\test\asan && c:\tools\Python27\python.exe C:/tools/llvm/utils/l it/lit.py -sv --no-progress-bar C:/tools/llvm-build/projects/compiler-rt/test/asan/I386WindowsConfig C:/tools/llvm-build/projects/ compiler-rt/test/asan/Unit" -- Testing: 489 tests, 4 threads -- FAIL: AddressSanitizer-i386-windows :: TestCases/Windows/shadow_mapping_failure.cc (324 of 489) ******************** TEST 'AddressSanitizer-i386-windows :: TestCases/Windows/shadow_mapping_failure.cc' FAILED ****************** ** Script: -- C:/tools/llvm-build/./bin/clang-cl.exe -fsanitize=address -Wno-deprecated-declarations -WX -D_HAS_EXCEPTIONS=0 -Zi -O0 c:\tools\l lvm\projects\compiler-rt\test\asan\TestCases\Windows\shadow_mapping_failure.cc -FeC:\tools\llvm-build\projects\compiler-rt\test\as an\I386WindowsConfig\TestCases\Windows\Output\shadow_mapping_failure.cc.tmp not C:\tools\llvm-build\projects\compiler-rt\test\asan\I386WindowsConfig\TestCases\Windows\Output\shadow_mapping_failure.cc.tmp 2 >&1 | FileCheck c:\tools\llvm\projects\compiler-rt\test\asan\TestCases\Windows\shadow_mapping_failure.cc -- Exit Code: 1 Command Output (stdout): -- Command 0: "C:/tools/llvm-build/./bin/clang-cl.exe" "-fsanitize=address" "-Wno-deprecated-declarations" "-WX" "-D_HAS_EXCEPTIONS=0 " "-Zi" "-O0" "c:\tools\llvm\projects\compiler-rt\test\asan\TestCases\Windows\shadow_mapping_failure.cc" "-FeC:\tools\llvm-build\p rojects\compiler-rt\test\asan\I386WindowsConfig\TestCases\Windows\Output\shadow_mapping_failure.cc.tmp" Command 0 Result: 0 Command 0 Output: Creating library C:\tools\llvm-build\projects\compiler-rt\test\asan\I386WindowsConfig\TestCases\Windows\Output\shadow_mapping_f ailure.cc.lib and object C:\tools\llvm-build\projects\compiler-rt\test\asan\I386WindowsConfig\TestCases\Windows\Output\shadow_mapp ing_failure.cc.exp Command 0 Stderr: Command 1: "not" "C:\tools\llvm-build\projects\compiler-rt\test\asan\I386WindowsConfig\TestCases\Windows\Output\shadow_mapping_fai lure.cc.tmp" Command 1 Result: 0 Command 1 Output: Command 1 Stderr: Command 2: "FileCheck" "c:\tools\llvm\projects\compiler-rt\test\asan\TestCases\Windows\shadow_mapping_failure.cc" Command 2 Result: 1 Command 2 Output: Command 2 Stderr: c:\tools\llvm\projects\compiler-rt\test\asan\TestCases\Windows\shadow_mapping_failure.cc:16:15: error: expected string not found i n input // CHECK-DAG: 0x{{[0-9a-f]*}}-0x{{[0-9a-f]*}} {{.*}}kernel32.dll ^ :4:2: note: scanning from here 0x010c0000-0x415e0000 C:\tools\llvm-build\projects\compiler-rt\test\asan\I386WindowsConfig\TestCases\Windows\Output\shadow_mappin g_failure.cc.tmp ^ :5:13: note: possible intended match here 0x71ba0000-0x71ce1000 C:\windows\SYSTEM32\dbghelp.dll ^ -- ******************** Testing Time: 75.79s ******************** Failing Tests (1): AddressSanitizer-i386-windows :: TestCases/Windows/shadow_mapping_failure.cc Expected Passes : 255 Unsupported Tests : 233 Unexpected Failures: 1 ninja: build stopped: subcommand failed. C:\tools\llvm-build> -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 5 19:30:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 06 Jun 2015 02:30:40 +0000 Subject: [LLVMbugs] [Bug 23771] UNREACHABLE in X86ELFObjectWriter.cpp:48 introduced by r232837 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23771 Rafael Ávila de Espíndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Rafael Ávila de Espíndola --- Fixed in r239214. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 5 21:57:12 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 06 Jun 2015 04:57:12 +0000 Subject: [LLVMbugs] [Bug 23752] wrong code at -O1 and above on x86_64-linux-gnu In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23752 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedbugs at nondot.org |david.majnemer at gmail.com --- Comment #2 from David Majnemer --- Fixed in r239217. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 6 06:28:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 06 Jun 2015 13:28:52 +0000 Subject: [LLVMbugs] [Bug 23775] New: Segfault when using wrong macros in printf Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23775 Bug ID: 23775 Summary: Segfault when using wrong macros in printf Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: laochailan at web.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14441 --> https://llvm.org/bugs/attachment.cgi?id=14441&action=edit backtrace appearing after the printf error message is printed. I stumbled on this segfault while programming. I do not know if it is really related to the frontend. Steps to Reproduce: 1) Attempt building the source code 2) clang crashes 3) Remove the printf in line 31498 and there is no segfault. Build Date & Platform: Arch Linux $ clang --version clang version 3.6.1 (tags/RELEASE_361/final) Target: x86_64-unknown-linux-gnu Thread model: posix -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 6 13:30:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 06 Jun 2015 20:30:40 +0000 Subject: [LLVMbugs] [Bug 23621] Assertion failed: (!isCommon()), function getOffset, file include/llvm/MC/MCSymbol.h, line 69. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23621 Colin LeMahieu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |colinl at codeaurora.org Resolution|--- |FIXED --- Comment #2 from Colin LeMahieu --- Fixed in 239227 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 6 14:16:20 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 06 Jun 2015 21:16:20 +0000 Subject: [LLVMbugs] [Bug 23776] New: static_assert fails when applied to function parameter Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23776 Bug ID: 23776 Summary: static_assert fails when applied to function parameter Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangbugs at nondot.org Reporter: bremende55 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified #include void f(const std::array & m) { static_assert(m.size() == 3, "error"); // does not compile! } int main() { std::array arr; static_assert(arr.size() == 3, "error"); // does compile f(arr); } /* The program compiles with g++ 5.1, but not with clang 3.7. clang++ -v -std=c++14 clangtest.cpp yields: clang version 3.7.0 (trunk 239219) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2 Found candidate GCC installation: /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.1.0 Found candidate GCC installation: /usr/local/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2 Found candidate GCC installation: /usr/local/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0 Selected GCC installation: /usr/local/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 "/usr/local/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name clangtest.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 13.2 -v -dwarf-column-info -resource-dir /usr/local/bin/../lib/clang/3.7.0 -internal-isystem /usr/local/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0 -internal-isystem /usr/local/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/x86_64-unknown-linux-gnu -internal-isystem /usr/local/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/backward -internal-isystem /usr/local/include -internal-isystem /usr/local/bin/../lib/clang/3.7.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++14 -fdeprecated-macro -fdebug-compilation-dir /home/me/basiccpp/divcpp -ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o /tmp/clangtest-9f401f.o -x c++ clangtest.cpp clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target x86_64-unknown-linux-gnu ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/local/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0 /usr/local/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/x86_64-unknown-linux-gnu /usr/local/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/backward /usr/local/include /usr/local/bin/../lib/clang/3.7.0/include /usr/include End of search list. clangtest.cpp:4:17: error: static_assert expression is not an integral constant expression static_assert(m.size() == 3, "error"); // does not compile ^~~~~~~~~~~~~ 1 error generated. */ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 7 06:51:41 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 07 Jun 2015 13:51:41 +0000 Subject: [LLVMbugs] [Bug 23777] New: cmake: race condition between ocaml docs & modules Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23777 Bug ID: 23777 Summary: cmake: race condition between ocaml docs & modules Product: Build scripts Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: mgorny at gentoo.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Long story short: Building OCaml documentation for llvm cd /var/tmp/portage/sys-devel/llvm-9999-r1/work/llvm-9999-abi_x86_64.amd64/bindings/ocaml/llvm && /usr/bin/ocamlfind ocamldoc -I /var/tmp/portage/sys-devel/llvm-9999-r1/work/llvm-9999-abi_x86_64.amd64/bindings/ocaml/llvm -I /var/tmp/portage/sys-devel/llvm-9999-r1/work/llvm-9999-abi_x86_64.amd64/./lib64/ocaml/ -dump /var/tmp/portage/sys-devel/llvm-9999-r1/work/llvm-9999-abi_x86_64.amd64/bindings/ocaml/llvm/llvm.odoc /var/tmp/portage/sys-devel/llvm-9999-r1/work/llvm-9999-abi_x86_64.amd64/bindings/ocaml/llvm/llvm.mli /var/tmp/portage/sys-devel/llvm-9999-r1/work/llvm-9999-abi_x86_64.amd64/bindings/ocaml/llvm/llvm.ml File "/var/tmp/portage/sys-devel/llvm-9999-r1/work/llvm-9999-abi_x86_64.amd64/bindings/ocaml/llvm/llvm.ml", line 1: Error: Could not find the .cmi file for interface /var/tmp/portage/sys-devel/llvm-9999-r1/work/llvm-9999-abi_x86_64.amd64/bindings/ocaml/llvm/llvm.mli. -- And this is because make -jN attempts to build OCaml docs before the OCaml modules themselves. If I manually 'make' in OCaml bindings directory first, docs build fine. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 7 09:43:03 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 07 Jun 2015 16:43:03 +0000 Subject: [LLVMbugs] [Bug 23778] New: Llc crashes if CodeGen/PowerPC/crbit-asm.ll test is compiled with -O1 or -O0 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23778 Bug ID: 23778 Summary: Llc crashes if CodeGen/PowerPC/crbit-asm.ll test is compiled with -O1 or -O0 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedbugs at nondot.org Reporter: llvm.mail.list at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The test relies on availability of the CR bits feature and the PPC::CRBITRCRegClass register class. CRBITRCRegClass is added when the CR bits feature is on (see PPCTargetLowering constructor), while the CR bits feature itself is available for -O2 or greater only (see function computeFSAdditions in lib/Target/PowerPC/PPCTargetMachine.cpp). Compiling the CodeGen/PowerPC/crbit-asm.ll test with -O0 or -O1 crashes llc. Llc tries to copy to a register of type i1, which is illegal if CR bits is off. This signals the assertion "Copying to an illegal type!" in the getCopyToParts function (lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 7 11:02:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 07 Jun 2015 18:02:17 +0000 Subject: [LLVMbugs] [Bug 23779] New: Segfault when globals reference constants when targeting OSX Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23779 Bug ID: 23779 Summary: Segfault when globals reference constants when targeting OSX Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedbugs at nondot.org Reporter: alex at crichton.co CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following IR will cause `llc` to segfault when executed with no extra arguments: target triple = "x86_64-apple-darwin" @a = external global i8 @b = internal unnamed_addr constant i8* @a @c = global i8** @b Note that if the IR instead targets 64-bit linux the segfault does not happen. the backtrace given is: 0 llc 0x00000000021f4c36 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 44 1 llc 0x00000000021f4f4b 2 llc 0x00000000021f3a4c 3 libpthread.so.0 0x00007f7ad0a59340 4 llc 0x0000000000dde9b0 5 llc 0x0000000001894131 6 llc 0x00000000018947b4 7 llc 0x000000000189486a llvm::AsmPrinter::EmitGlobalConstant(llvm::Constant const*) + 96 8 llc 0x000000000188c853 llvm::AsmPrinter::EmitGlobalVariable(llvm::GlobalVariable const*) + 3241 9 llc 0x000000000188f3cf llvm::AsmPrinter::doFinalization(llvm::Module&) + 237 10 llc 0x00000000021372f1 llvm::FPPassManager::doFinalization(llvm::Module&) + 83 11 llc 0x00000000021376eb 12 llc 0x0000000002137c1d llvm::legacy::PassManagerImpl::run(llvm::Module&) + 249 13 llc 0x0000000002137e57 llvm::legacy::PassManager::run(llvm::Module&) + 39 14 llc 0x0000000000c3fea5 15 llc 0x0000000000c3ef50 main + 242 16 libc.so.6 0x00007f7acfa58ec5 __libc_start_main + 245 17 llc 0x0000000000c3bff9 Stack dump: 0. Program arguments: ./Debug+Asserts/bin/llc /home/alex/bugpoint-reduced-simplified.ll zsh: segmentation fault (core dumped) ./Debug+Asserts/bin/llc ~/bugpoint-reduced-simplified.ll -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 7 12:22:57 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 07 Jun 2015 19:22:57 +0000 Subject: [LLVMbugs] [Bug 23777] cmake: race condition between ocaml docs & modules In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23777 Peter Zotov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Peter Zotov --- r239259 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 7 12:25:29 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 07 Jun 2015 19:25:29 +0000 Subject: [LLVMbugs] [Bug 23776] static_assert fails when applied to function parameter In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23776 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |INVALID --- Comment #1 from Richard Smith --- Sorry, Clang is correct here. The subexpression 'm' makes this expression non-constant per [expr.const] (5.20)/2.9, because this means the static_assert condition contains: "an id-expression that refers to a variable or data member of reference type unless the reference has a preceding initialization and either — it is initialized with a constant expression or — it is a non-static data member of an object whose lifetime began within the evaluation of e;" (Basically, the evaluation of the expression 'm' attempts to resolve which object is denoted by the reference, which fails.) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 8 05:04:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 08 Jun 2015 12:04:49 +0000 Subject: [LLVMbugs] [Bug 23780] New: cmake: make it possible to override HTML doc install dir Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23780 Bug ID: 23780 Summary: cmake: make it possible to override HTML doc install dir Product: Build scripts Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: mgorny at gentoo.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Currently the Sphinx HTML doc are unconditionally installed into /usr/share/doc/${project}/html (project = llvm, cmake, ...). This kinda misfits the Gentoo layout of /usr/share/doc. For this reason, it would be nice if we could override the install locations easily rather than having to move files after 'make install'. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 8 05:31:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 08 Jun 2015 12:31:47 +0000 Subject: [LLVMbugs] [Bug 23781] New: cmake: race condition between different sphinx targets Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23781 Bug ID: 23781 Summary: cmake: race condition between different sphinx targets Product: Build scripts Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: mgorny at gentoo.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified If multiple Sphinx targets are declared in the same directory, they all share a common doctree directory. Now, if multiple targets are enabled and parallel make is used, multiple instances of Sphinx can be started simultaneously with the same doctree directory, resulting in race conditions. This is hard to reproduce but I've been able to see one regarding os.makedirs() hitting EEXIST. Not that I believe this isn't a bug in Python but I doubt this is something we can rely upon being fixed for us. Potential solutions are: 1. add an ordering dep between the two targets. Let only one Sphinx instance run in parallel, and then run the other reusing already-generated doctrees. 2. Use separate doctree directories. This means that Sphinx would generate the same doctrees twice. Not sure how much slower that would be, actually. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 8 05:35:30 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 08 Jun 2015 12:35:30 +0000 Subject: [LLVMbugs] [Bug 15221] cmake does not support udis86 dep In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=15221 Michał Górny changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Michał Górny --- udis86 was removed completely. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 8 07:22:12 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 08 Jun 2015 14:22:12 +0000 Subject: [LLVMbugs] [Bug 23782] New: Use clang-format on types error messages Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23782 Bug ID: 23782 Summary: Use clang-format on types error messages Product: clang Version: 3.6 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: schnetter at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Here is a "typical" compiler error message I'm receiving from clang: {{{ ./fun/grid_impl.hpp:84:4: note: candidate template ignored: substitution failure [with D = 2, F = fun::detail::tree_fmapStencilMulti_g<2, cxx::detail::funobj_impl > &, G = unsigned long &, C = adt::maxarray, T = adt::tree, adt::grid, adt::dummy, 2>, adt::dummy, adt::detail::nested_default_policy >, cell_t>, Args = , cxx::detail::funobj_impl &>, $6 = nullptr, CT = adt::grid, adt::tree, adt::grid, adt::dummy, 2>, adt::dummy, adt::detail::nested_default_policy >, cell_t>, 2>, BC = adt::grid, adt::dummy, 1>]: no type named 'type' in 'cxx::invoke_of, adt::grid, adt::dummy, 2>, adt::dummy, adt::detail::nested_default_policy >, cell_t>, long>' }}} To understand this tapeworm, I have to copy-paste it into an editor, look for matching single quotes, and then manually format (indent) the text between the quotes. Here is an idea: Couldn't one use clang-format to automated? The error message would then look like {{{ ./fun/grid_impl.hpp:84:4: note: candidate template ignored: substitution failure [with: D = 2, F = fun::detail::tree_fmapStencilMulti_g< 2, cxx::detail::funobj_impl> &, G = unsigned long &, C = adt::maxarray, T = adt::tree< adt::nested, adt::grid, adt::dummy, 2>, adt::dummy, adt::detail::nested_default_policy>, cell_t>, Args = , cxx::detail::funobj_impl &>, $6 = nullptr, CT = adt::grid< adt::maxarray, adt::tree, adt::grid, adt::dummy, 2>, adt::dummy, adt::detail::nested_default_policy>, cell_t>, 2>, BC = adt::grid, adt::dummy, 1> ]: no type named 'type' in cxx::invoke_of< unsigned long &, adt::tree< adt::nested, adt::grid, adt::dummy, 2>, adt::dummy, adt::detail::nested_default_policy>, cell_t>, long> }}} which is orders of magnitude more readable. Alternatively, a simple hierarchical output would also be good... -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 8 08:57:04 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 08 Jun 2015 15:57:04 +0000 Subject: [LLVMbugs] [Bug 23783] New: Unable to run "check-all" target when building LLVM 3.6.1 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23783 Bug ID: 23783 Summary: Unable to run "check-all" target when building LLVM 3.6.1 Product: Build scripts Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: stevenaura at live.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14447 --> https://llvm.org/bugs/attachment.cgi?id=14447&action=edit Results of check-all Dear LLVM developers, I have successfully compiled the 3.6.1 version of LLVM-Clang-LLDB-Compiler-RT-LibCxx-LibCxxABI-TestSuite bundle. However, when I tried 'ninja check-all', the check failed right at the first target "[1/150] Generating sanitizer_bitvector_test.cc.x86_64.o". I think the reason is that LLVM is trying to use the system GCC header files, but I compiled LLVM with another GCC toolchain (GCC 4.8.4) that I compiled and installed in a non-root directory. Please let me know how to fix this issue. Here is the relevant information: * CentOS 6.6 * x86_64 architecture (Intel(R) Xeon(R) CPU W3550 @ 3.07GHz) * Tools used for installation: 1) gcc/4.8.4 2) ninja 3) zlib/1.2.8 4) python-miniconda * Linux Kernel version 2.6.32-504.16.2.el6.x86_64 * CMake build command cmake -G "Ninja" -DCMAKE_C_COMPILER=/Scr/scr-test-steven/install/gcc/4.8.4/bin/gcc -DCMAKE_CXX_COMPILER=/Scr/scr-test-steven/install/gcc/4.8.4/bin/c++ -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/Scr/scr-test-steven/install/llvm/3.6.1 /Scr/scr-test-steven/Programs/LLVM/llvm-3.6.1.src -DLLDB_DISABLE_PYTHON=1 -DCMAKE_CXX_FLAGS:STRING="-I/Scr/scr-test-steven/install/gcc/4.8.4/include -I/Scr/scr-test-steven/Programs/LLVM/llvm-3.6.1.src/tools/clang/include -I/Scr/scr-test-steven/install/libedit/3.1/include -I/Scr/scr-test-steven/install/miniconda/include/python2.7 -L/Scr/scr-test-steven/install/gcc/4.8.4/lib64 -L/Scr/scr-test-steven/install/libedit/3.1/lib -L/Scr/scr-test-steven/install/miniconda/lib -L/Scr/scr-test-steven/install/miniconda/lib/python2.7" -DPYTHON_HOME=/Scr/scr-test-steven/install/miniconda -DLLVM_LIB_SEARCH_PATH=/Scr/scr-test-steven/Programs/LLVM/build_llvm-3.6.1/lib * 'ninja check' results (see attachment) Thanks. Yuhang Wang -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 8 12:47:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 08 Jun 2015 19:47:31 +0000 Subject: [LLVMbugs] [Bug 23715] error: invalid symbol redefinition __asm In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23715 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from Reid Kleckner --- So far, I don't see any behavior that looks like a clang bug. Basically, if you want to compile Windows headers, then you probably need -fms-extensions. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 8 13:30:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 08 Jun 2015 20:30:56 +0000 Subject: [LLVMbugs] [Bug 23786] New: msan false negative on a trivial uninitialized read Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23786 Bug ID: 23786 Summary: msan false negative on a trivial uninitialized read Product: compiler-rt Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedbugs at nondot.org Reporter: msebor at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Memory sanitizer doesn't report the uninitialized read in the call to printf in the program below. It does, however, report the uninitialized read of the same object in the return statement when it's executed. Similar false negatives can be reproduced with similarly simple programs, including the one below the test case. $ cat t.c && /build/llvm-trunk/bin/clang -fsanitize=memory -O0 t.c && ./a.out && echo SUCCESS && ./a.out 1 #include void __attribute__ ((weak)) foo (int *p) { *p = *p + 1; } int main (int argc, char *argv[]) { int a; int *p = &a; foo (p); printf ("%i\n", *p); if (1 < argc) return *p; } 32756 SUCCESS 32697 ==32134==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x7fb8d6ce0946 (/build/msan/a.out+0x88945) #1 0x7fb8d5b4ffe0 (/lib64/libc.so.6+0x1ffdf) #2 0x7fb8d6c7135f (/build/msan/a.out+0x1935e) SUMMARY: MemorySanitizer: use-of-uninitialized-value (/build/msan/a.out+0x88945) Exiting Another program for which the sanitizer does't issue a diagnostic: #include void __attribute__ ((weak)) bar (int n) { exit (n | 1); } int main (int argc, char *argv[]) { int a; bar (a); } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 8 13:53:28 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 08 Jun 2015 20:53:28 +0000 Subject: [LLVMbugs] [Bug 23787] New: assert "frontend claimed part of a token?" while building a slightly tweaked libyuv Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23787 Bug ID: 23787 Summary: assert "frontend claimed part of a token?" while building a slightly tweaked libyuv Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified fbarchard reported a compiler crash that reduces to: thakis$ cat repro.ii typedef unsigned char uint8; __declspec(naked) void I422ToRGBARow_SSSE3(const uint8* y_buf, const uint8* u_buf, const uint8* v_buf, uint8* dst_rgba, int width) { __asm { push esi push edi mov eax, [esp + 8 + 4] mov esi, [esp + 8 + 8] mov edi, [esp + 8 + 12] mov edx, [esp + 8 + 16] mov ecx, [esp + 8 + 20] sub edi, esi convertloop: __asm { __asm movd xmm0, [esi] __asm movd xmm1, [esi + edi] __asm lea esi, [esi + 4] __asm punpcklbw xmm0, xmm1 __asm punpcklwd xmm0, xmm0 } __asm { __asm movdqa xmm1, xmm0 __asm movdqa xmm2, xmm0 __asm movdqa xmm3, xmm0 __asm movdqa xmm0, kYuvConstants.kUVBiasB __asm pmaddubsw xmm1, kYuvConstants.kUVToB __asm psubw xmm0, xmm1 __asm movdqa xmm1, kYuvConstants.kUVBiasG __asm pmaddubsw xmm2, kYuvConstants.kUVToG __asm psubw xmm1, xmm2 __asm movdqa xmm2, kYuvConstants.kUVBiasR __asm pmaddubsw xmm3, kYuvConstants.kUVToR __asm psubw xmm2, xmm3 __asm movq xmm3, qword ptr [eax] __asm lea eax, [eax + 8] __asm punpcklbw xmm3, xmm3 __asm pmulhuw xmm3, kYuvConstants.kYToRgb __asm paddsw xmm0, xmm3 __asm paddsw xmm1, xmm3 __asm paddsw xmm2, xmm3 __asm psraw xmm0, 6 __asm psraw xmm1, 6 __asm psraw xmm2, 6 __asm packuswb xmm0, xmm0 __asm packuswb xmm1, xmm1 __asm packuswb xmm2, xmm2 } __asm { __asm pcmpeqb xmm5, xmm5 __asm punpcklbw xmm1, xmm2 __asm punpcklbw xmm5, xmm0 __asm movdqa xmm0, xmm5 __asm punpcklwd xmm5, xmm1 __asm punpckhwd xmm0, xmm1 __asm movdqu 0[edx], xmm5 __asm movdqu 16[edx], xmm0 __asm lea edx, [edx + 32] } sub ecx, 8 jg convertloop pop edi pop esi ret } } thakis$ /Users/thakis/src/llvm-build/bin/clang "-cc1" "-fms-compatibility" "-x" "c++" repro.ii Assertion failed: (End.getPointer() <= EndPtr && "frontend claimed part of a token?"), function ParseIntelIdentifier, file /Users/thakis/src/llvm-svn/lib/Target/X86/AsmParser/X86AsmParser.cpp, line 1336. 0 clang 0x0000000103261799 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 57 1 clang 0x00000001032622db SignalHandler(int) + 779 2 libsystem_platform.dylib 0x00007fff8f3515aa _sigtramp + 26 3 libsystem_platform.dylib 000000000000000000 _sigtramp + 1892346480 4 clang 0x0000000103261f16 abort + 22 5 clang 0x0000000103261ef1 __assert_rtn + 81 6 clang 0x00000001029f2581 (anonymous namespace)::X86AsmParser::ParseIntelIdentifier(llvm::MCExpr const*&, llvm::StringRef&, llvm::InlineAsmIdentifierInfo&, bool, llvm::SMLoc&) + 769 7 clang 0x00000001029f0e65 (anonymous namespace)::X86AsmParser::ParseIntelMemOperand(long long, llvm::SMLoc, unsigned int) + 245 8 clang 0x00000001029ec956 (anonymous namespace)::X86AsmParser::ParseOperand() + 4054 9 clang 0x00000001029def9f (anonymous namespace)::X86AsmParser::ParseInstruction(llvm::ParseInstructionInfo&, llvm::StringRef, llvm::SMLoc, llvm::SmallVectorImpl > >&) + 6687 10 clang 0x0000000103082a88 (anonymous namespace)::AsmParser::parseStatement((anonymous namespace)::ParseStatementInfo&, llvm::MCAsmParserSemaCallback*) + 3816 11 clang 0x000000010307dff5 (anonymous namespace)::AsmParser::parseMSInlineAsm(void*, std::__1::basic_string, std::__1::allocator >&, unsigned int&, unsigned int&, llvm::SmallVectorImpl >&, llvm::SmallVectorImpl, std::__1::allocator > >&, llvm::SmallVectorImpl, std::__1::allocator > >&, llvm::MCInstrInfo const*, llvm::MCInstPrinter const*, llvm::MCAsmParserSemaCallback&) + 485 12 clang 0x0000000103cd509b clang::Parser::ParseMicrosoftAsmStatement(clang::SourceLocation) + 5355 13 clang 0x0000000103cd6370 clang::Parser::ParseAsmStatement(bool&) + 1968 14 clang 0x0000000103cca456 clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) + 854 15 clang 0x0000000103cca05b clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, bool, clang::SourceLocation*) + 155 16 clang 0x0000000103cd1e7f clang::Parser::ParseCompoundStatementBody(bool) + 1855 17 clang 0x0000000103cd270c clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 188 18 clang 0x0000000103ce88ee clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) + 1966 19 clang 0x0000000103c619ed clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 2861 20 clang 0x0000000103ce7ed4 clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) + 692 21 clang 0x0000000103ce7897 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) + 375 22 clang 0x0000000103ce6747 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) + 2935 23 clang 0x0000000103ce5a9c clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 524 24 clang 0x0000000103c4e576 clang::ParseAST(clang::Sema&, bool, bool) + 390 25 clang 0x0000000103495453 clang::FrontendAction::Execute() + 67 26 clang 0x0000000103463c3c clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 972 27 clang 0x00000001034d64cb clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 4043 28 clang 0x0000000102188c6c cc1_main(llvm::ArrayRef, char const*, void*) + 1068 29 clang 0x0000000102187905 main + 11029 30 libdyld.dylib 0x00007fff837335fd start + 1 Stack dump: 0. Program arguments: /Users/thakis/src/llvm-build/bin/clang -cc1 -fms-compatibility -x c++ repro.ii 1. repro.ii:30:1: current parser token '}' 2. repro.ii:7:37: parsing function body 'I422ToRGBARow_SSSE3' 3. repro.ii:7:37: in compound statement ('{}') -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 8 14:26:37 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 08 Jun 2015 21:26:37 +0000 Subject: [LLVMbugs] [Bug 23788] New: please add 64-bit Windows binaries Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23788 Bug ID: 23788 Summary: please add 64-bit Windows binaries Product: Website Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: General Website Assignee: unassignedbugs at nondot.org Reporter: jmsachs at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified download list (http://llvm.org/releases/download.html) contains 32-bit Windows binaries but not 64-bit Windows binaries. Please add the 64-bit binaries. Use case: I am trying to use libclang with the Python bindings, but my version of Python is 64-bit and it will not use the 32-bit libclang.dll -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 8 14:39:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 08 Jun 2015 21:39:05 +0000 Subject: [LLVMbugs] [Bug 23789] New: clang should warn on "trivially" self-recursive functions Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23789 Bug ID: 23789 Summary: clang should warn on "trivially" self-recursive functions Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Consider this common pattern: class Frame { Frame* FindFrame(uint32_t id) { return const_cast(const_cast(this))->FindFrame(id); } const Frame* FindFrame(uint32_t id) const; }; The parens in the inlined functions are off, it needs to be: return const_cast(const_cast(this)->FindFrame(id)); cl.exe finds this: e:\b\build\slave\win_x64_gn\build\src\mandoline\tab\frame.h(58) : warning C4717: 'mandoline::Frame::FindFrame' : recursive on all control paths, function will cause runtime stack overflow clang doesn't. It should. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 8 16:12:54 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 08 Jun 2015 23:12:54 +0000 Subject: [LLVMbugs] [Bug 23786] msan false negative on a trivial uninitialized read In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23786 Evgeniy Stepanov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |eugeni.stepanov at gmail.com Resolution|--- |LATER --- Comment #1 from Evgeniy Stepanov --- This is a combination of: https://code.google.com/p/memory-sanitizer/issues/detail?id=43 https://code.google.com/p/memory-sanitizer/issues/detail?id=79 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 8 17:32:53 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 00:32:53 +0000 Subject: [LLVMbugs] [Bug 23790] New: CStringChecker assumes strcmp only returns -1, 0, or 1 when it can return any integer value Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23790 Bug ID: 23790 Summary: CStringChecker assumes strcmp only returns -1, 0, or 1 when it can return any integer value Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kremenek at apple.com Reporter: rtrieu at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified test/Analysis/string.c 703 void strcmp_1() { 704 char *x = "234"; 705 char *y = "123"; 706 clang_analyzer_eval(strcmp(x, y) == 1); // expected-warning{{TRUE}} 707 } This is from the test for CStringChecker. The function strcmp can return any positive value in this case. It is not constrained to returning 1. The true evaluation here is incorrect. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 8 18:04:35 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 01:04:35 +0000 Subject: [LLVMbugs] [Bug 23770] Propagating dll attributes to template bases doesn't work for explicit instantiation In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23770 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- This wasn't as bad as I thought. Should be fixed in r239375. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 8 18:04:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 01:04:36 +0000 Subject: [LLVMbugs] [Bug 13707] [meta] VCPP compatibility issues In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=13707 Bug 13707 depends on bug 23770, which changed state. Bug 23770 Summary: Propagating dll attributes to template bases doesn't work for explicit instantiation https://llvm.org/bugs/show_bug.cgi?id=23770 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 01:01:45 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 08:01:45 +0000 Subject: [LLVMbugs] [Bug 23715] error: invalid symbol redefinition __asm In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23715 Javier changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID |--- --- Comment #7 from Javier --- And of course I am compiling with -fms-extensions. Dind't you read my latest message? I said they are turned on by default when using Clang on Windows. How else would it compile without errors with -O0 or -O1? Here is the clang invocation as reported by clang with the -v option: -cc1 -triple i686-pc-windows-msvc -emit-obj -disable-free -main-file-name ATfileinput.th -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu pentium4 -momit-leaf-frame-pointer -v -dwarf-column-info -coverage-file "C:\\Users\\Javier\\Desktop\\Proyecto\\relativa\\ATcrt\\ATfileinput.th" -resource-dir "C:\\Users\\Javier\\Clang\\build\\Release\\bin\\..\\lib\\clang\\3.7.0" -D _DLL -D _MT -internal-isystem "C:\\Users\\Javier\\Clang\\build\\Release\\bin\\..\\lib\\clang\\3.7.0\\include" -internal-isystem "C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\VC\\INCLUDE" -internal-isystem "C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\VC\\ATLMFC\\INCLUDE" -internal-isystem "C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\include" -O2 -Weverything -std=c11 -fdebug-compilation-dir "C:\\Users\\Javier\\Desktop\\Proyecto\\relativa\\ATcrt" -ferror-limit 19 -fmessage-length 0 -mstackrealign -fno-signed-char -fms-extensions -fms-compatibility -fms-compatibility-version=18 -fno-threadsafe-statics -fdelayed-template-parsing -fobjc-runtime=gcc -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o ATfileinput.o -x c ATfileinput.th clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target i686-pc-windows-msvc And here are more lines of the error report: In file included from ./to_write_C.c:3: ./to_write_CLANG.c:12:1: error: invalid symbol redefinition __asm{ ^ :9:2: note: instantiated into assembly here L__MSASMLABEL_.1__big_loop: xor edx, edx ^ In file included from ATfileoutput.th:8: In file included from ./to_write_C.c:3: ./to_write_CLANG.c:12:1: error: invalid symbol redefinition __asm{ ^ :17:2: note: instantiated into assembly here L__MSASMLABEL_.0__small_entry: cmp eax, 10 ^ In file included from ATfileoutput.th:8: In file included from ./to_write_C.c:3: ./to_write_CLANG.c:12:1: error: invalid symbol redefinition __asm{ ^ :19:2: note: instantiated into assembly here L__MSASMLABEL_.3__small_loop: xor edx, edx ^ [...] -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 02:15:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 09:15:26 +0000 Subject: [LLVMbugs] [Bug 23791] New: Clang emit wrong mangling of long double type for PPC64 in the Red Hat Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23791 Bug ID: 23791 Summary: Clang emit wrong mangling of long double type for PPC64 in the Red Hat Product: clang Version: trunk Hardware: Other OS: other Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: bluechristlove at 163.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified In the PPC64 architecture, Clang recognize the long double type and set the long double format type as llvm::APFloat::PPCDoubleDouble which is in PPCTargetInfo constructor of the file lib/Basic/Targets.cpp. The detail is like this: [code] PPCTargetInfo(const llvm::Triple &Triple) : TargetInfo(Triple), HasVSX(false), HasP8Vector(false), HasP8Crypto(false), HasDirectMove(false), HasQPX(false), HasHTM(false), HasBPERMD(false), HasExtDiv(false) { BigEndian = (Triple.getArch() != llvm::Triple::ppc64le); LongDoubleWidth = LongDoubleAlign = 128; LongDoubleFormat = &llvm::APFloat::PPCDoubleDouble; } [/code] and then in the function getTypeForFormat of file lib/codegen/CodeGenTypes.cpp, which return the type of PPC_FP128Ty, the code is like this: [code] if (&format == &llvm::APFloat::PPCDoubleDouble) return llvm::Type::getPPC_FP128Ty(VMContext); [/code] // file: a.cpp Let me show one simple example: [code] void foo(long double){} int main(){} [/code] Compile command: clang++ a.cpp -S -emit-llvm Then view a.ll ... ; Function Attrs: nounwind define void @_Z3foog(ppc_fp128) #0 { entry: %.addr = alloca ppc_fp128, align 16 store ppc_fp128 %0, ppc_fp128* %.addr, align 16 ret void } ... we can find ppc_fp128, but let us view the object file of a.cpp. clang++ -c a.cpp readelf -Ws a.o Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS a.cpp 2: 0000000000000000 0 SECTION LOCAL DEFAULT 1 3: 0000000000000000 0 SECTION LOCAL DEFAULT 2 4: 0000000000000000 0 SECTION LOCAL DEFAULT 3 5: 0000000000000000 0 SECTION LOCAL DEFAULT 4 6: 0000000000000000 0 SECTION LOCAL DEFAULT 5 7: 0000000000000000 24 FUNC GLOBAL DEFAULT 1 _Z3fooe 8: 0000000000000018 20 FUNC GLOBAL DEFAULT 1 main we can find that ppc_fp128 is encoded as 'e', which is in the function CXXNameMangler::mangleType of the file lib/ast/ItaniumMangle.cpp, the code is: [code] case BuiltinType::LongDouble: Out << 'e'; break; [/code] But in the PPC64，this should be 'g'. Let us compile this code using gcc g++ -c a.cpp readelf -Ws a.o Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS a.cpp 2: 0000000000000000 0 SECTION LOCAL DEFAULT 1 3: 0000000000000000 0 SECTION LOCAL DEFAULT 2 4: 0000000000000000 0 SECTION LOCAL DEFAULT 3 5: 0000000000000000 0 SECTION LOCAL DEFAULT 4 6: 0000000000000000 0 SECTION LOCAL DEFAULT 6 7: 0000000000000000 0 SECTION LOCAL DEFAULT 7 8: 0000000000000000 0 SECTION LOCAL DEFAULT 5 9: 0000000000000000 44 FUNC GLOBAL DEFAULT 1 _Z3foog 10: 000000000000002c 44 FUNC GLOBAL DEFAULT 1 main We can find that the mangling name is _Z3foog, not _Z3fooe. Because of this issue, which make some case can not pass. [code] #include #include #include #include #include #include typedef std::char_traits It_; typedef std::ostreambuf_iterator Osit_; struct Mymon_ : public std::money_put { Mymon_(std::size_t refs) : std::money_put(refs) { } }; struct Myimon_ : public std::money_put { Myimon_(std:: size_t refs) : std::money_put(refs) { } }; int main() { Mymon_ fac(1), fac2(0); } [/code] If we use clang++ to compile, which will report a linker error:\ a.o:(.data.rel.ro._ZTV6Mymon_[_ZTV6Mymon_]+0x30): undefined reference to `std::__gnu_cxx_ldbl128::money_put > >::do_put(std::ostreambuf_iterator >, bool, std::ios_base&, char, long double) const' clang: error: linker command failed with exit code 1 (use -v to see invocation)\ If we readelf -Ws a.o we can find this entry: 37: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _ZNKSt17__gnu_cxx_ldbl1289money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES4_bRSt8ios_basece But gcc is like this: 46: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _ZNKSt17__gnu_cxx_ldbl1289money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES4_bRSt8ios_basecg Then we grep this in the libstdc++.so of a.o which produced by gcc: readelf -Ws /usr/lib64/libstdc++.so.6 | grep _ZNKSt17__gnu_cxx_ldbl1289money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES4_bRSt8ios_basecg 2948: 000000000016cbf8 756 FUNC WEAK DEFAULT 25 _ZNKSt17__gnu_cxx_ldbl1289money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES4_bRSt8ios_basecg@@GLIBCXX_LDBL_3.4 This can be found in the libstdc++ But this can not be found by the a.o which produced by clang, because Clang emit wrong name mangling of long double in the PPC64 mentioned above. So, in the CXXNameMangler::mangleType of the file lib/ast/ItaniumMangle.cpp, when the case is case BuiltinType::LongDouble, Clang should detect the Target. If the target is PPC64, which should be emit 'g', not 'e'. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 03:32:16 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 10:32:16 +0000 Subject: [LLVMbugs] [Bug 23792] New: cmake: Install clang resources into /usr/lib/clang (without LLVM_LIBDIR_SUFFIX) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23792 Bug ID: 23792 Summary: cmake: Install clang resources into /usr/lib/clang (without LLVM_LIBDIR_SUFFIX) Product: Build scripts Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: mgorny at gentoo.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The clang resource dir (/usr/lib*/clang) contains two sets of files: - headers (that are not arch-specific at all), - compiler-rt libraries (that are suffixed for multiple arches). Therefore, it makes no sense to respect LLVM_LIBDIR_SUFFIX and install resources into /usr/lib64 or the like. In fact, it can cause QA warnings in stricter environments as 32-bit libraries end up in lib64. Please consider either dropping LLVM_LIBDIR_SUFFIX from clang resource & compiler-rt installs, or making it configurable separately. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 03:37:22 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 10:37:22 +0000 Subject: [LLVMbugs] [Bug 23793] New: cmake/clang: LLVM_LIBDIR_SUFFIX is not always correct for LLVMgold.so lookup Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23793 Bug ID: 23793 Summary: cmake/clang: LLVM_LIBDIR_SUFFIX is not always correct for LLVMgold.so lookup Product: Build scripts Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: mgorny at gentoo.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified clang uses CLANG_LIBDIR_SUFFIX (which is forced to ${LLVM_LIBDIR_SUFFIX}) to provide LLVMgold.so plugin path. This is not always correct, since libClangDriver may be built for a different ABI than the system binutils. In other words, 32-bit libClangDriver will pass: -plugin .../lib32/LLVMgold.so while binutils expects: -plugin .../lib64/LLVMgold.so Therefore, please make it possible to override libdir suffix for LLVMgold.so path. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 03:40:29 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 10:40:29 +0000 Subject: [LLVMbugs] [Bug 23794] New: [PATCH] OpenCL: Add new types for OpenCL 2.0 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23794 Bug ID: 23794 Summary: [PATCH] OpenCL: Add new types for OpenCL 2.0 Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: pedro.ferreira at imgtec.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14449 --> https://llvm.org/bugs/attachment.cgi?id=14449&action=edit Patch to add types Hi all, This patch adds the new OpenCL types for 2.0 described at https://www.khronos.org/registry/cl/sdk/2.0/docs/man/xhtml/otherDataTypes.html The types are: image2d_depth_t image2d_array_depth_t image2d_msaa_t image2d_array_msaa_t image2d_msaa_depth_t image2d_array_msaa_depth_t queue_t ndrange_t clk_event_t reserve_id_t let me know if something looks wrong. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 05:51:04 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 12:51:04 +0000 Subject: [LLVMbugs] [Bug 23795] New: Clang/CodeGen crashes after semantic error with ObjC++. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23795 Bug ID: 23795 Summary: Clang/CodeGen crashes after semantic error with ObjC++. Product: clang Version: trunk Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: 1101.debian at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The issue relates only to ObjC++ with C++11 or higher. Run the following command: clang -cc1 -emit-obj -std=c++14 -x objective-c++ main.mm where main.mm contains: typedef struct UIEdgeInsets { float top, left, bottom, right; } UIEdgeInsets; __attribute__((objc_root_class)) @interface View @property (nonatomic) UIEdgeInsets contentInset; @end @implementation View - (void)someMethod { self.contentInset = {.top = 10}; } @end Clang reports the issue: main.mm:19:26: error: cannot compile this scalar expression yet continue evaluation and crashes at CodeGen phase. Full crashlog: main.mm:13:26: error: cannot compile this scalar expression yet self.contentInset = {.top = 10}; ^~~~~~~~~ 0 clang 0x000000010f86f61e llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 46 1 clang 0x000000010f870ee9 PrintStackTraceSignalHandler(void*) + 25 2 clang 0x000000010f871348 SignalHandler(int) + 584 3 libsystem_platform.dylib 0x00007fff92705f1a _sigtramp + 26 4 libsystem_platform.dylib 0xffffffffffffffff _sigtramp + 1838129407 5 clang 0x000000010f0e39bb llvm::StoreInst::StoreInst(llvm::Value*, llvm::Value*, bool, unsigned int, llvm::AtomicOrdering, llvm::SynchronizationScope, llvm::Instruction*) + 91 6 clang 0x000000010f0e3aed llvm::StoreInst::StoreInst(llvm::Value*, llvm::Value*, bool, unsigned int, llvm::AtomicOrdering, llvm::SynchronizationScope, llvm::Instruction*) + 109 7 clang 0x000000010f0e3853 llvm::StoreInst::StoreInst(llvm::Value*, llvm::Value*, bool, unsigned int, llvm::Instruction*) + 115 8 clang 0x000000010f0e3639 llvm::StoreInst::StoreInst(llvm::Value*, llvm::Value*, bool, llvm::Instruction*) + 73 9 clang 0x00000001103659b8 llvm::IRBuilder >::CreateStore(llvm::Value*, llvm::Value*, bool) + 88 10 clang 0x000000011021576f clang::CodeGen::CodeGenFunction::EmitStoreOfScalar(llvm::Value*, llvm::Value*, bool, unsigned int, clang::QualType, llvm::MDNode*, bool, clang::QualType, unsigned long long) + 1343 11 clang 0x000000011021593e clang::CodeGen::CodeGenFunction::EmitStoreOfScalar(llvm::Value*, clang::CodeGen::LValue, bool) + 238 12 clang 0x00000001102076de clang::CodeGen::CodeGenFunction::EmitStoreThroughLValue(clang::CodeGen::RValue, clang::CodeGen::LValue, bool) + 2926 13 clang 0x00000001101e4d94 clang::CodeGen::CodeGenFunction::EmitScalarInit(clang::Expr const*, clang::ValueDecl const*, clang::CodeGen::LValue, bool) + 276 14 clang 0x00000001102285ba (anonymous namespace)::AggExprEmitter::EmitInitializationToLValue(clang::Expr*, clang::CodeGen::LValue) + 954 15 clang 0x00000001102254d9 (anonymous namespace)::AggExprEmitter::VisitInitListExpr(clang::InitListExpr*) + 2473 16 clang 0x0000000110221397 clang::StmtVisitorBase::Visit(clang::Stmt*) + 3127 17 clang 0x000000011021f9a9 (anonymous namespace)::AggExprEmitter::Visit(clang::Expr*) + 73 18 clang 0x000000011021f5e4 clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const*, clang::CodeGen::AggValueSlot) + 356 19 clang 0x0000000110205df7 clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, clang::CodeGen::AggValueSlot, bool) + 423 20 clang 0x0000000110282aa4 clang::CodeGen::CodeGenFunction::OpaqueValueMappingData::bind(clang::CodeGen::CodeGenFunction&, clang::OpaqueValueExpr const*, clang::Expr const*) + 244 21 clang 0x000000011021bd93 emitPseudoObjectExpr(clang::CodeGen::CodeGenFunction&, clang::PseudoObjectExpr const*, bool, clang::CodeGen::AggValueSlot) + 755 22 clang 0x000000011021ba74 clang::CodeGen::CodeGenFunction::EmitPseudoObjectRValue(clang::PseudoObjectExpr const*, clang::CodeGen::AggValueSlot) + 100 23 clang 0x0000000110225f39 (anonymous namespace)::AggExprEmitter::VisitPseudoObjectExpr(clang::PseudoObjectExpr*) + 217 24 clang 0x0000000110221637 clang::StmtVisitorBase::Visit(clang::Stmt*) + 3799 25 clang 0x000000011021f9a9 (anonymous namespace)::AggExprEmitter::Visit(clang::Expr*) + 73 26 clang 0x000000011021f5e4 clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const*, clang::CodeGen::AggValueSlot) + 356 27 clang 0x0000000110205df7 clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, clang::CodeGen::AggValueSlot, bool) + 423 28 clang 0x0000000110205c1d clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 109 29 clang 0x000000011031fd96 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 582 30 clang 0x000000011032b695 clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 133 31 clang 0x0000000110273189 clang::CodeGen::CodeGenFunction::GenerateObjCMethod(clang::ObjCMethodDecl const*) + 281 32 clang 0x000000011039407a clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 1546 33 clang 0x00000001104aca5d (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 157 34 clang 0x000000011036f940 clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 192 35 clang 0x0000000110eb65fd clang::ParseAST(clang::Sema&, bool, bool) + 941 36 clang 0x000000010fcec1ca clang::ASTFrontendAction::ExecuteAction() + 522 37 clang 0x000000011036e023 clang::CodeGenAction::ExecuteAction() + 3987 38 clang 0x000000010fceb740 clang::FrontendAction::Execute() + 112 39 clang 0x000000010fc78cff clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1023 40 clang 0x000000010fd60160 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3200 41 clang 0x000000010da93b09 cc1_main(llvm::ArrayRef, char const*, void*) + 2473 42 clang 0x000000010da86e93 ExecuteCC1Tool(llvm::ArrayRef, llvm::StringRef) + 163 43 clang 0x000000010da85d1c main + 1244 44 libdyld.dylib 0x00007fff89c675c9 start + 1 Stack dump: 0. Program arguments: clang -cc1 -emit-obj -std=c++14 -x objective-c++ main.mm 1. parser at end of file 2. main.mm:12:1: LLVM IR generation of declaration 'View::someMethod' [1] 22997 segmentation fault clang -cc1 -emit-obj -std=c++14 -x objective-c++ main.mm -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 08:14:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 15:14:58 +0000 Subject: [LLVMbugs] [Bug 23797] New: check_cxx_compiler_flag Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23797 Bug ID: 23797 Summary: check_cxx_compiler_flag Product: Build scripts Version: 3.4 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: swojskichlopak at wp.pl CC: llvmbugs at cs.uiuc.edu Classification: Unclassified source code from git clone http://llvm.org/git/lldb.git $ cmake .. -- The C compiler identification is GNU 4.9.2 -- The CXX compiler identification is GNU 4.9.2 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Found PythonLibs: /usr/lib64/libpython2.7.so (found version "2.7.9") CMake Error at cmake/modules/LLDBConfig.cmake:118 (check_cxx_compiler_flag): Unknown CMake command "check_cxx_compiler_flag". Call Stack (most recent call first): CMakeLists.txt:1 (include) CMake Warning (dev) in CMakeLists.txt: No cmake_minimum_required command is present. A line of code such as cmake_minimum_required(VERSION 3.0) should be added at the top of the file. The version specified may be lower if you wish to support older CMake versions for this project. For more information run "cmake --help-policy CMP0000". This warning is for project developers. Use -Wno-dev to suppress it. -- Configuring incomplete, errors occurred! See also "/home/gg/src/rpm/SOURCES/test/lldb/build/CMakeFiles/CMakeOutput.log". System: PCLinuxOS 64bit Mate Cmake: cmake 3.0.2 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 09:26:25 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 16:26:25 +0000 Subject: [LLVMbugs] [Bug 23798] New: sprintf format with %.2X mis-formats a char with a value of 0xFF Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23798 Bug ID: 23798 Summary: sprintf format with %.2X mis-formats a char with a value of 0xFF Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: james.baker at bullochtech.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14451 --> https://llvm.org/bugs/attachment.cgi?id=14451&action=edit C++ test file. sprintf(szDest, "%.2X", szIn[i]) outputs "FFFFFFFF" even when szIn is a char array. It should output "FF". Here is code to show the problem: #include #include void succeeds() { char data[] = "ABCD2345678"; char dest[128]; char temp[3]; memset(dest, 0, sizeof(dest)); for(int i = 0; i < strlen(data); i++){ sprintf(temp, "%.2X", data[i]); printf("Part: %s\n", temp); strcat(dest, temp); } printf("Result: %s\n", dest); } void fails() { char data[] = "\xFF\xFF\xFF\xFF""2345678"; char dest[128]; char temp[3]; memset(dest, 0, sizeof(dest)); for(int i = 0; i < strlen(data); i++){ sprintf(temp, "%.2X", data[i]); printf("Part: %s\n", temp); strcat(dest, temp); } printf("Result: %s\n", dest); } int main(int argc, char ** argv) { succeeds(); fails(); return 0; } -------END CODE-------- This outputs like this in clang++ (Based on 3.6.0) on the Mac: Part: 41 Part: 42 Part: 43 Part: 44 Part: 32 Part: 33 Part: 34 Part: 35 Part: 36 Part: 37 Part: 38 Result: 4142434432333435363738 Part: FFFFFFFF Part: FFFFFFFF Part: FFFFFFFF Part: FFFFFFFF Part: 32 Part: 33 Part: 34 Part: 35 Part: 36 Part: 37 Part: 38 Result: FFFFFFFFFFFFF32333435363738 And it outputs this on Windows (trunk as of June 5 2015) until it crashes: Part: 41 Part: 42 Part: 43 Part: 44 Part: 32 Part: 33 Part: 34 Part: 35 Part: 36 Part: 37 Part: 38 Result: 4142434432333435363738 Part: FFFFFFFF <--- crashes at this point On the Raspberry Pi (Ubuntu Mate) Clang++ version 3.6.0: Part: 41 Part: 42 Part: 43 Part: 44 Part: 32 Part: 33 Part: 34 Part: 35 Part: 36 Part: 37 Part: 38 Result: 4142434432333435363738 Part: FF Part: FF Part: FF Part: FF Part: 32 Part: 33 Part: 34 Part: 35 Part: 36 Part: 37 Part: 38 Result: FFFFFFFF32333435363738 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 09:42:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 16:42:10 +0000 Subject: [LLVMbugs] [Bug 23798] sprintf format with %.2X mis-formats a char with a value of 0xFF when part of a char array In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23798 hstong at ca.ibm.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |hstong at ca.ibm.com Resolution|--- |INVALID --- Comment #1 from hstong at ca.ibm.com --- I suggest that you use "%.2hhX" or add a cast to "unsigned char". -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 09:58:15 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 16:58:15 +0000 Subject: [LLVMbugs] [Bug 16678] Wrong behavior for large integer literal with -std=c89 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=16678 hstong at ca.ibm.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #3 from hstong at ca.ibm.com --- Fixed in r239356. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 11:06:04 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 18:06:04 +0000 Subject: [LLVMbugs] [Bug 23791] Clang emit wrong mangling of long double type for PPC64 in the Red Hat In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23791 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Component|Frontend |LLVM Codegen Resolution|--- |FIXED --- Comment #3 from David Majnemer --- Fixed in r239421. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 11:06:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 18:06:50 +0000 Subject: [LLVMbugs] [Bug 23800] New: Invalid shufflevector operands Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23800 Bug ID: 23800 Summary: Invalid shufflevector operands Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: moritz.pflanzer14 at imperial.ac.uk CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14452 --> https://llvm.org/bugs/attachment.cgi?id=14452&action=edit Test-case with produces the wrong code The following (OpenCL) code results in undef operands of a shufflevector LLVM IR instruction when compiled with clang. $ clang -S -emit-llvm -O0 -o - input.c Clang and LLVM have been built from trunk. The bug does not occur with "Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)". Test-case: typedef unsigned int uint16 __attribute((ext_vector_type(16))); typedef unsigned int uint8 __attribute((ext_vector_type(8))); void test1(void) { (uint16)(((uint16)0).s0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0); } Part of LLVM IR: %5 = shufflevector <16 x i32> %3, <16 x i32> undef, <16 x i64> -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 11:34:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 18:34:58 +0000 Subject: [LLVMbugs] [Bug 23801] New: New assert: !ExprNeedsCleanups && "Unaccounted cleanups in function", file ..\tools\clang\lib\Sema\SemaDecl.cpp, line 10836 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23801 Bug ID: 23801 Summary: New assert: !ExprNeedsCleanups && "Unaccounted cleanups in function", file ..\tools\clang\lib\Sema\SemaDecl.cpp, line 10836 Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: hans at chromium.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Clang r239408 fails with this assert when building parts of Chromium. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 12:41:27 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 19:41:27 +0000 Subject: [LLVMbugs] [Bug 23802] New: cast-expression from lvalue to rvalue reference fails while reinterpret_cast for the same conversion works Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23802 Bug ID: 23802 Summary: cast-expression from lvalue to rvalue reference fails while reinterpret_cast for the same conversion works Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: andrey.vul at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Consider the following example: // begin a.cc struct S {}; int x; S&& y1 = (S&&)x; S&& y2 = reinterpret_cast(x); S& z1 = (S&)x; //end a.cc The casts initializing y1 and y2 should behave the same but the cast-expression gives the diagnostic: "error: cannot cast from lvalue of type 'int' to rvalue reference type 'S &&'; types are not compatible" The expression initializing z1 works as intended. I conclude that reinterpret_cast is neglected as a candidate in a cast-expression when the target is a rvalue reference, violating 5.4p4.4. clang++ -v output: clang version 3.6.1 (tags/RELEASE_361/final) Target: x86_64-pc-linux-gnu Thread model: posix Selected GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2 "/usr/bin/x86_64-pc-linux-gnu-clang-3.6.1" -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name a.cc -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.25 -v -dwarf-column-info -resource-dir /usr/bin/../lib/clang/3.6.1 -internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/include/g++-v4 -internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/include/g++-v4/x86_64-pc-linux-gnu -internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/include/g++-v4/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.6.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -Wall -Wextra -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 132 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/a-85edcb.o -x c++ a.cc clang -cc1 version 3.6.1 based upon LLVM 3.6.1 default target x86_64-pc-linux-gnu ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/include/g++-v4 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/include/g++-v4/x86_64-pc-linux-gnu /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/include/g++-v4/backward /usr/bin/../lib/clang/3.6.1/include /usr/include End of search list. a.cc:3:10: error: cannot cast from lvalue of type 'int' to rvalue reference type 'S &&'; types are not compatible S&& y1 = (S&&)x; ^~~~~~ 1 error generated. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 15:37:20 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 22:37:20 +0000 Subject: [LLVMbugs] [Bug 23119] RegisterScavenger ignores kill flags on predicated instructions In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23119 Tobias Edler von Koch changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Tobias Edler von Koch --- Fixed in r239439. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 15:51:54 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 09 Jun 2015 22:51:54 +0000 Subject: [LLVMbugs] [Bug 23804] New: "NumBytes should never be 0 when realignment is needed" failed Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23804 Bug ID: 23804 Summary: "NumBytes should never be 0 when realignment is needed" failed Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: unassignedbugs at nondot.org Reporter: eugeni.stepanov at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14458 --> https://llvm.org/bugs/attachment.cgi?id=14458&action=edit IR dump $ cat 3.cc void f(int *); int main() { int t; f(&t); f(&t); } $ /code/llvm/build/bin/clang++ --target=aarch64-none-linux-gnu -fsanitize=address 3.cc -O1 -c clang-3.7: ../lib/Target/AArch64/AArch64FrameLowering.cpp:370: virtual void llvm::AArch64FrameLowering::emitPrologue(llvm::MachineFunction &, llvm::MachineBasicBlock &) const: Assertion `!(NeedsRealignment && NumBytes==0) && "NumBytes should never be 0 when realignment is needed"' failed. 0 clang-3.7 0x000000000163192a llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 42 1 clang-3.7 0x0000000001632cab 2 libpthread.so.0 0x00007f45ed13c340 3 libc.so.6 0x00007f45ec364cc9 gsignal + 57 4 libc.so.6 0x00007f45ec3680d8 abort + 328 5 libc.so.6 0x00007f45ec35db86 6 libc.so.6 0x00007f45ec35dc32 7 clang-3.7 0x000000000071d420 llvm::AArch64FrameLowering::emitPrologue(llvm::MachineFunction&, llvm::MachineBasicBlock&) const + 5056 8 clang-3.7 0x00000000010cd358 9 clang-3.7 0x000000000106369c llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 124 10 clang-3.7 0x00000000012e4364 llvm::FPPassManager::runOnFunction(llvm::Function&) + 468 11 clang-3.7 0x00000000012e459b llvm::FPPassManager::runOnModule(llvm::Module&) + 43 12 clang-3.7 0x00000000012e4a85 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 901 13 clang-3.7 0x0000000001a9f7fd clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) + 7981 14 clang-3.7 0x0000000001a914d5 15 clang-3.7 0x0000000002037d83 clang::ParseAST(clang::Sema&, bool, bool) + 483 16 clang-3.7 0x00000000017e14ce clang::FrontendAction::Execute() + 62 17 clang-3.7 0x00000000017afd8c clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 892 18 clang-3.7 0x0000000001860859 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3049 19 clang-3.7 0x00000000006e95ac cc1_main(llvm::ArrayRef, char const*, void*) + 700 20 clang-3.7 0x00000000006e7df2 main + 11794 21 libc.so.6 0x00007f45ec34fec5 __libc_start_main + 245 22 clang-3.7 0x00000000006e4edc Stack dump: 0. Program arguments: /code/llvm/build/bin/clang-3.7 -cc1 -triple aarch64-none-linux-gnu -emit-obj -disable-free -main-file-name 3.cc -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu generic -target-feature +neon -target-abi aapcs -dwarf-column-info -coverage-file /code/llvm/build-android-aarch64/3.cc -resource-dir /code/llvm/build/bin/../lib/clang/3.7.0 -internal-isystem /usr/local/include -internal-isystem /code/llvm/build/bin/../lib/clang/3.7.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O1 -fdeprecated-macro -fdebug-compilation-dir /code/llvm/build-android-aarch64 -ferror-limit 19 -fmessage-length 158 -fsanitize=address -fsanitize-blacklist=/code/llvm/build/bin/../lib/clang/3.7.0/asan_blacklist.txt -fno-assume-sane-operator-new -mstackrealign -fallow-half-arguments-and-returns -fno-signed-char -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o 3.o -x c++ ../3.cc 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '../3.cc'. 4. Running pass 'Prologue/Epilogue Insertion & Frame Finalization' on function '@main' clang-3.7: error: unable to execute command: Aborted (core dumped) clang-3.7: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (trunk 239440) Target: aarch64-none-linux-gnu Thread model: posix clang-3.7: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.7: note: diagnostic msg: Attaching the IR dump with ASan instrumentation. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 17:41:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 10 Jun 2015 00:41:50 +0000 Subject: [LLVMbugs] [Bug 23805] New: [OMP] Assertion `!Scope.isNormalCleanup() || !HasPrebranchedFallthrough || (Scope.getNormalBlock() && FallthroughSource->getTerminator()->getSuccessor(0) == Scope.getNormalBlock())' failed Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23805 Bug ID: 23805 Summary: [OMP] Assertion `!Scope.isNormalCleanup() || !HasPrebranchedFallthrough || (Scope.getNormalBlock() && FallthroughSource->getTerminator()->getSuccessor(0) == Scope.getNormalBlock())' failed Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Build the following test case with: clang -cc1 -O3 -fopenmp contrast_domain-29da62.cpp -emit-obj contrast_domain-29da62.cpp: int a; void fn1() { #pragma omp for for (int j = 0; j < a; j++) ; } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 20:18:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 10 Jun 2015 03:18:07 +0000 Subject: [LLVMbugs] [Bug 23806] New: Deeply nested includes cause clang to get "stuck". Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23806 Bug ID: 23806 Summary: Deeply nested includes cause clang to get "stuck". Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: popizdeh at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified test.cpp #include "test.cpp" #include "test.cpp" running: clang -fsyntax-only test.cpp gives: fatal error: too many errors emitted, stopping now [-ferror-limit=] clang never exits, it has to be killed. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 9 23:50:30 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 10 Jun 2015 06:50:30 +0000 Subject: [LLVMbugs] [Bug 23631] icmp eq <16 x i1> works incorrectly on AVX512 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23631 Elena Demikhovsky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |elena.demikhovsky at intel.com Resolution|--- |FIXED --- Comment #1 from Elena Demikhovsky --- Committed revision 239460. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 10 03:33:15 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 10 Jun 2015 10:33:15 +0000 Subject: [LLVMbugs] [Bug 14269] clang crashes when trying to get address of the bitfield and generates incorrect code In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=14269 Andrey Bokhanko changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrey Bokhanko --- Fixed in r239153. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 10 09:30:08 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 10 Jun 2015 16:30:08 +0000 Subject: [LLVMbugs] [Bug 23808] New: segmentation fault in std::unique_ptr virtual destructor Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23808 Bug ID: 23808 Summary: segmentation fault in std::unique_ptr virtual destructor Product: libc++ Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: benni.buch at gmail.com CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified #include struct A{ virtual ~A() = default; }; struct B: A{}; int main(){ // segmentation fault in B's destructor auto b = std::make_unique< B >(); } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 10 09:56:30 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 10 Jun 2015 16:56:30 +0000 Subject: [LLVMbugs] [Bug 23809] New: InstCombine should keep useful @llvm.assume calls Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23809 Bug ID: 23809 Summary: InstCombine should keep useful @llvm.assume calls Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: wujingyue at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14461 --> https://llvm.org/bugs/attachment.cgi?id=14461&action=edit the test case as mentioned in the description I have some WIP that leverages @llvm.assume in some optimization passes other than InstCombine. However, it doesn't work yet because InstCombine removes @llvm.assume calls that are useful for later optimizations. For example, given define i32 @foo(i32 %a, i32 %b) { %sum = add i32 %a, %b %1 = icmp sge i32 %sum, 0 call void @llvm.assume(i1 %1) ret i32 %sum } "opt -instcombine" emits define i32 @foo(i32 %a, i32 %b) { %sum = add i32 %a, %b ret i32 %sum } removing the @llvm.assume call so later optimizations won't know sum is non-negative any more. (Note that the opt I use here is with http://reviews.llvm.org/D10283 patched. This patch fixes a bug in ValueTracking). The reasons that InstCombine removes this assume call are: 1) SimplifyICmpInst proves %1 is true based on the assume call. 2) then, InstCombine (http://llvm.org/docs/doxygen/html/InstCombineCompares_8cpp_source.html#l02649) replaces all uses of %1 with true including the use in the assume call. 3) Somewhere later, llvm.assume(true) is considered trivially dead and thus removed from the IR. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 10 10:53:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 10 Jun 2015 17:53:40 +0000 Subject: [LLVMbugs] [Bug 23810] New: [ms] unqualified lookup into dependent base class failure Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23810 Bug ID: 23810 Summary: [ms] unqualified lookup into dependent base class failure Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: hans at chromium.org CC: llvmbugs at cs.uiuc.edu, nicolasweber at gmx.de, rnk at google.com Classification: Unclassified After Clang r239373, the following test case fails: $ clang -cc1 -triple i686-pc-windows-msvc18.0.0 -fms-extensions -fms-compatibility -std=c++11 -fdelayed-template-parsing getparent.ii void GetParent(int); struct CWindow { void GetParent() {} }; template struct CWindowImplRoot : TBase { void ForwardNotifications(); }; template void CWindowImplRoot::ForwardNotifications() { GetParent(); } template struct CWindowImpl : CWindowImplRoot { }; struct CAxFrameWindow : CWindowImpl {}; struct __declspec(dllexport) S : CWindowImpl {}; getparent.ii:11:5: error: no matching function for call to 'GetParent' GetParent(); ^~~~~~~~~ getparent.ii:1:8: note: candidate function not viable: requires 1 argument, but 0 were provided void GetParent(int); ^ (Reduced from build failure currently occurring in Chromium: http://build.chromium.org/p/chromium.fyi/builders/ClangToTWin64%28dll%29/builds/635/steps/compile/logs/stdio) Before r239373, we would not propagate dllexport from CWindowImpl to its base CWindowImplRoot, because the latter had previously been instantiated. Because of that, it seems we didn't use to instantiate ForwardNotifications() and hit this error. The lookup problem existed before r239373, though. If the CAxFrameWindow definition is removed, the same lookup error occurs in previous Clangs (including 3.6). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 10 12:52:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 10 Jun 2015 19:52:55 +0000 Subject: [LLVMbugs] [Bug 23811] New: Overload resolution works when function reference type is used as lhs of assignment but not a cast-expression Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23811 Bug ID: 23811 Summary: Overload resolution works when function reference type is used as lhs of assignment but not a cast-expression Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: andrey.vul at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following code tests [over.over]/1.2 and [over.over]/1.6. Clang resolves the address of the overloaded function in the first case but not the second case. SOURCE: cat /tmp/a.cc template T f(T x) { return x + 1; } int main() { typedef int (&&fp1)(int); fp1&& p10 = f; // ok fp1&& p11 = static_cast(f); // fail } INVOCATION: clang++ -std=c++11 -v clang version 3.6.1 (tags/RELEASE_361/final) Target: x86_64-pc-linux-gnu Thread model: posix Selected GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2 "/usr/bin/x86_64-pc-linux-gnu-clang-3.6.1" -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name a.cc -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.25 -v -dwarf-column-info -resource-dir /usr/bin/../lib/clang/3.6.1 -internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/include/g++-v4 -internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/include/g++-v4/x86_64-pc-linux-gnu -internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/include/g++-v4/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.6.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 150 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/a-810097.o -x c++ a.cc clang -cc1 version 3.6.1 based upon LLVM 3.6.1 default target x86_64-pc-linux-gnu ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/include/g++-v4 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/include/g++-v4/x86_64-pc-linux-gnu /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/include/g++-v4/backward /usr/bin/../lib/clang/3.6.1/include /usr/include End of search list. a.cc:8:14: error: address of overloaded function 'f' cannot be static_cast to type 'fp1 &&' fp1&& p11 = static_cast(f); ^~~~~~~~~~~~~~~~~~~~~ a.cc:1:22: note: candidate function template T f(T x) { ^ 1 error generated. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 10 12:55:46 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 10 Jun 2015 19:55:46 +0000 Subject: [LLVMbugs] [Bug 23812] New: Single-element initializer_list invokes wrong constructor Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23812 Bug ID: 23812 Summary: Single-element initializer_list invokes wrong constructor Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: j4cbo at dropbox.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Test case: #include #include struct Q { Q() { std::cout << "default\n"; } Q(Q const&) { std::cout << "copy\n"; } Q(Q&&) { std::cout << "move\n"; } Q(std::initializer_list) { std::cout << "initializer list\n"; } }; int main() { Q x = Q { Q() }; } "Q { Q() }" should invoke the initializer_list constructor, but recent Clang (trunk as of today, r239482) treats it as a move instead. For comparison, clang 3.6 and older, gcc 4.9, 5.1, and MSVC2015 all select the initializer_list constructor. This is really bad for us, as it silently changes the meaning of code in a subtle way (manifests as making our JSON library elide single-element array literals). :( -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 10 17:48:44 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 00:48:44 +0000 Subject: [LLVMbugs] [Bug 23814] New: instcombine issue with statically linking in libc and whole-program optimizations Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23814 Bug ID: 23814 Summary: instcombine issue with statically linking in libc and whole-program optimizations Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: opt Assignee: unassignedbugs at nondot.org Reporter: alonzakai at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified -instcombine did something that I found surprising: transformed @printf into @puts, even though @printf was defined, not declared, and it was internal. In more detail, imagine that we link in libc statically and strip out the parts we don't actually use, and call internalize, giving us this: @.str = private unnamed_addr constant [18 x i8] c"printf from main\0A\00", align 1 define internal i32 @printf(i8* %c, ...) #0 { call void asm sideeffect " magic! ", "~{dirflag},~{fpsr},~{flags}"() #1, !srcloc !1 ret i32 0 } define internal i32 @main() #0 { %0 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([18 x i8], [18 x i8]* @.str, i32 0, i32 0)) ret i32 0 } (the @printf here just has an asm that does "magic!" instead of writing out a full printf). Now, if we want to do some whole-program optimizations, we might run -instcombine, giving us define internal i32 @printf(i8* %c, ...) #0 { call void asm sideeffect " magic! ", "~{dirflag},~{fpsr},~{flags}"() #1, !srcloc !1 ret i32 0 } define internal i32 @main() #0 { %puts = call i32 @puts(i8* getelementptr inbounds ([17 x i8], [17 x i8]* @str, i64 0, i64 0)) ret i32 0 } declare i32 @puts(i8* nocapture) #1 @main's call to the internal @printf, a define, has been turned into a call of a declare of @puts. But, since we already linked in libc statically, this is not what we wanted - we are not going to link in anything else. It surprises me that -instcombine is willing to transform a call to an internally defined method. Should it perhaps leave such calls alone? If it does not leave them alone, I think there might be other dangers. Imagine if @puts were present in this file. And if some whole-program optimization noticed that all @puts calls have some property, and it then optimized @puts given that assumption (say, that the input is 5 chars or less). This could be valid, because everything is internalized, so we see all the possible calls to @puts. But then turning a @printf into a @puts might lead to surprising results. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 10 18:20:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 01:20:05 +0000 Subject: [LLVMbugs] [Bug 23815] New: Segmentation fault with a deep template instantiation depth Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23815 Bug ID: 23815 Summary: Segmentation fault with a deep template instantiation depth Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangbugs at nondot.org Reporter: david at doublewise.net CC: llvmbugs at cs.uiuc.edu Classification: Unclassified david at i5-fedora ~/test> ulimit unlimited david at i5-fedora ~/test> clang++ -v clang version 3.6.0 (tags/RELEASE_360/final) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.3 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 david at i5-fedora ~/test> clang++ -c -std=c++11 source/main.cpp -o /dev/null -ftemplate-depth=1800 clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.6.0 (tags/RELEASE_360/final) Target: x86_64-unknown-linux-gnu Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/main-a2abc3.cpp clang: note: diagnostic msg: /tmp/main-a2abc3.sh clang: note: diagnostic msg: ******************** The following program segfaults. The exact number of elements that cause a segfault varies with unrelated code before the function call, which makes me suspect some sort of stack overflow, but ulimit shows unlimited. template struct S { static constexpr int value = S::value; }; template struct S { static constexpr int value = x; }; template int function() { return S::value; } int result = function< 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 >(); -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 10 18:39:44 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 01:39:44 +0000 Subject: [LLVMbugs] [Bug 23815] Segmentation fault with a deep template instantiation depth In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23815 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rnk at google.com Resolution|--- |INVALID --- Comment #1 from Reid Kleckner --- -ftemplate-depth is our safety limit to avoid crashing like this, and you turned it off. I don't think there's anything actionable for us here. https://llvm.org/bugs/show_bug.cgi?id=23685 is a recent report of roughly the same thing. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 10 19:39:06 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 02:39:06 +0000 Subject: [LLVMbugs] [Bug 23801] New assert: !ExprNeedsCleanups && "Unaccounted cleanups in function", file ..\tools\clang\lib\Sema\SemaDecl.cpp, line 10836 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23801 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dgregor at apple.com Component|-New Bugs |C++ Resolution|--- |FIXED --- Comment #8 from David Majnemer --- Fixed in r239503. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 10 21:30:15 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 04:30:15 +0000 Subject: [LLVMbugs] [Bug 23816] New: Invariant loads are not hoisted all the way out of certain simple nested loops Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23816 Bug ID: 23816 Summary: Invariant loads are not hoisted all the way out of certain simple nested loops Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: opt Assignee: unassignedbugs at nondot.org Reporter: broune at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified In this simple example, *a is hoisted out of the inner loop, but not out of the outer loop with -O2. I think -O2 should be powerful enough to hoist *a out of both loops for this example. __attribute__((noinline)) float computeSum(float* a, int N, int M) { float sum = 0; #pragma nounroll for (int i = 0; i < N; ++i) { #pragma nounroll for (int j = 0; j < M; ++j) { sum += *a; } } return sum; } int main(int argc, char** argv) { float a = 42; return computeSum(&a, 1000, 1); } The reason is that -O2 does not have loop unswitching enabled. To have a safe place to hoist *a out to, we need to loop unswitch on the condition M > 0. I assume loop unswitching is disabled because it can cause code bloat and slower code in some cases, though note that in this case, the version of the loop for M <= 0 does nothing, so a safe version of loop unswitching that only fires on such cases could run with -O2. This wouldn't work for cases where the outer loop does more than just run an inner loop, but it would be a good start and it would also speed things up by not having to check M>0 for every iteration of the outer loop. An alternative would be for licm to introduce a check for M>0 outside the outer loop, which would create a safe place to put the load. With -O3 the load does get hoisted all the way out as loop unswitching is enabled there. However, loop unswitching only fires on loops that are smaller than a threshold. If we set the threshold to a smaller value like 10, to simulate a larger loop, then loop unswitching does not fire here and the load does not get hoisted even for -O3. The loop unswitch pass does have code to detect trivial cases where one of the two versions of the loop is empty, but it's not powerful enough to recognize that for this example (it mostly detects cases similar to "if (loop-invariant) break;"). This bug is for -O2 to handle (i.e. hoist loads all the way out) the above simple example and for -O3 to handle similar loops that are larger than the threshold for loop unswitching. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 11 03:18:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 10:18:07 +0000 Subject: [LLVMbugs] [Bug 23023] clang-cl: cannot compile operator""if In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23023 Andrey Bokhanko changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrey Bokhanko --- This is not assigned to anyone, so let me take the liberty of closing it. Marcel, please reopen if you still see any problems. Yours, Andrey Bokhanko =============== Software Engineer Intel Compiler Team Intel -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 11 05:19:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 12:19:50 +0000 Subject: [LLVMbugs] [Bug 23370] [meta] Using Clang/LLVM as the FreeBSD/mips system compiler In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23370 Bug 23370 depends on bug 22389, which changed state. Bug 22389 Summary: Incomplete MIPS IAS support for immediate branch pseudo-instructions. https://llvm.org/bugs/show_bug.cgi?id=22389 What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 11 05:19:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 12:19:49 +0000 Subject: [LLVMbugs] [Bug 22389] Incomplete MIPS IAS support for immediate branch pseudo-instructions. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22389 Toma Tabacu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Toma Tabacu --- Basic support for this was added in r239523. There might be some problems with more complex arithemtic expressions and not all of the memonnics are supported yet, but those seem like separate bug tickets to me. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 11 05:27:44 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 12:27:44 +0000 Subject: [LLVMbugs] [Bug 5172] Clang need to implement '#pragma redefine_extname' to support C++ on Solaris. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=5172 Andrey Bokhanko changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #13 from Andrey Bokhanko --- Fix committed; r239466. Andrey -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 11 05:27:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 12:27:47 +0000 Subject: [LLVMbugs] [Bug 4696] [meta] The AuroraUX source tree does not fully compile with Clang In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=4696 Bug 4696 depends on bug 5172, which changed state. Bug 5172 Summary: Clang need to implement '#pragma redefine_extname' to support C++ on Solaris. https://llvm.org/bugs/show_bug.cgi?id=5172 What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 11 05:49:27 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 12:49:27 +0000 Subject: [LLVMbugs] [Bug 23817] New: Local static variable initialization is not thread safe Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23817 Bug ID: 23817 Summary: Local static variable initialization is not thread safe Product: compiler-rt Version: 3.6 Hardware: PC OS: Windows NT Status: NEW Severity: release blocker Priority: P Component: compiler-rt Assignee: unassignedbugs at nondot.org Reporter: ali.demiroz at sap.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified llvm-3.6.0rc4.src\lib\Support\Windows\Memory.inc at line 81, there is a local static variable usage to ensure calling "getAllocationGranularity" function only once. But unlike GCC, MSVC does not use any barrier to provide synchronization for local-scoped static variables. So as a consequence, this code causes a division by zero at line 82 in Memory.inc when second thread sees that cs:dword_143A26070 is set but cs:off_143A26068 is initialized yet. Generated assembly: mov eax, cs:dword_143A26070 test al, 1 jnz short loc_14251B165 or eax, 1 lea rcx, [rsp+88h+var_38] mov cs:dword_143A26070, eax call cs:__imp_GetSystemInfo mov eax, [rsp+88h+var_34] mov ecx, [rsp+88h+var_10] cmp eax, ecx jbe short loc_14251B159 mov ecx, eax loc_14251B159: mov cs:off_143A26068, rcx xor r8d, r8d jmp short loc_14251B16C loc_14251B165: mov rcx, cs:off_143A26068 loc_14251B16C: xor edx, edx lea rax, [rbp-1] add rax, rcx div rcx mov qword ptr [rsp+88h+var_58], rax test rdi, rdi jz short loc_14251B1C0 ... -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 11 11:24:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 18:24:05 +0000 Subject: [LLVMbugs] [Bug 19763] Inline asm with constraint 'i' fails with --fsanitize=undefined In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=19763 Ahmed Bougacha changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |ahmed.bougacha at gmail.com Resolution|--- |FIXED --- Comment #6 from Ahmed Bougacha --- Should be fixed by r239549, with a fallback to emitting an expression if the operand doesn't accept register or memory, but doesn't require an immediate either. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 11 11:41:37 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 18:41:37 +0000 Subject: [LLVMbugs] [Bug 23818] New: Function not inlined when it should probably be Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23818 Bug ID: 23818 Summary: Function not inlined when it should probably be Product: clang Version: trunk Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: ldionne.2 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14462 --> https://llvm.org/bugs/attachment.cgi?id=14462&action=edit Minimal working example Hi, I have run into a situation[1] where a function should probably be inlined but it isn't, resulting in very suboptimal code to be generated. The gist of the problem goes as follows: auto f() { return /* some very large structure which is quite complicated to construct, but which can also be constructed as a constant expression. In other words, the expression in the return statement, while being complex, is only composed of constant expressions. */; } int main() { // In the generated assembly, the code for `f` is generated, which // is O.K. because `f` has external linkage. That assembly is pretty // bad, since it has to pass the huge structure returned by f by // value, which spills. // // However, this call right here to `f()` is not optimized away. // In other words, even though the definition of `f` is visible // to the optimizer, `f` is called, resulting in the awful code // to be executed. // // If `f` is marked as inline, the call is optimized to nothing // (and the code of f is not even generated). f(); } A minimal working example with comments is attached. I realize this is a quality of implementation issue more than an actual bug, but I think my actual use case[1] justifies at least looking into the problem. Regards, Louis [1]: http://article.gmane.org/gmane.comp.lib.boost.devel/261035 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 11 13:41:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 20:41:26 +0000 Subject: [LLVMbugs] [Bug 23819] New: -Wpessimizing-move sometimes issued where -Wredundant-move would be appropriate Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23819 Bug ID: 23819 Summary: -Wpessimizing-move sometimes issued where -Wredundant-move would be appropriate Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: richard-llvm at metafoo.co.uk CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Case 1: "moving a temporary object prevents copy elision" diagnosed even though no copy would be made anyway: struct X {}; X g(); void h(X&&); void f() { h(std::move(g())); } Case 2: "moving a local object in a return statement prevents copy elision" issued even though copy elision is not possible, because we're returning a function parameter: X f(X x) { return std::move(x); } In both of these cases we should issue a -Wredundant-move warning instead. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 11 13:42:35 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 20:42:35 +0000 Subject: [LLVMbugs] [Bug 23820] New: -Wredundant-move issued on non-redundant moves in C++11 (that would be redundant in C++14) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23820 Bug ID: 23820 Summary: -Wredundant-move issued on non-redundant moves in C++11 (that would be redundant in C++14) Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: richard-llvm at metafoo.co.uk CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified This produces a -Wredundant-move warning, but removing the std::move call makes the code ill-formed in C++11: #include struct X { X(); X(X&&); }; struct Y : X {}; X f() { Y y; return std::move(y); } The warning is correct in C++14. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 11 14:22:48 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 21:22:48 +0000 Subject: [LLVMbugs] [Bug 23810] [ms] unqualified lookup into dependent base class failure In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23810 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- r239558 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 11 15:23:45 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 22:23:45 +0000 Subject: [LLVMbugs] [Bug 23817] Local static variable initialization Memory::allocateMappedMemory is not thread safe on Windows In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23817 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Reid Kleckner --- Thanks, fixed in r239566 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 11 16:02:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 23:02:50 +0000 Subject: [LLVMbugs] [Bug 23821] New: Unnecessary instructions generated for logical vector shift by (__m128i)0 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23821 Bug ID: 23821 Summary: Unnecessary instructions generated for logical vector shift by (__m128i)0 Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: charles_li at playstation.sony.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified On X86, logically shifting a vector by “(__m128i) 0” will cause unnecessary instructions at -O2 ( "(__m128i) 0" being a 128-bit vector constant of value 0 ) Here is an example of poor code gen assembling the following results in a vector xor followed by vector shift logical left. Since xor of a register with itself is 0 and shifting a value by 0 is itself, the 2 instructions are redundant. test.cpp: __m128i logic_left_shift_vec_0_of_64( __m128i a ) { return _mm_sll_epi64( a, (__m128i) {0, 0} ); } clang test.cpp -S -O2 test.s: vpxor %xmm1, %xmm1, %xmm1 vpsllq %xmm1, %xmm0, %xmm0 retq Here is an example of where Clang does good code gen, in this intrinsic, 0 is a scalar integer When assembling at -O2, only return instruction is generated. test2.cpp: __m128i logic_left_shift_int_0_of_64( __m128i a ) { return _mm_slli_epi64( a, 0 ); } clang test2.cpp -S -O2 test2.s: retq Here is another example of good code gen, Arithmetic shift of a vector by “(__m128i) 0”. In this example, despite the 0 being a vector immediate, Clang is still able to deduce that shifting by 0 has no effect. __m128i arith_right_shift_int_0_of_32( __m128i a ) { return _mm_srai_epi32( a, 0 ); } clang test3.cpp -S -O2 retq Here are all of the vector shift intrinsics that results in poor code gen. /***************************************************/ #include // Logical shift by vec immediate zero __m128i logic_left_shift_vec_0_of_64( __m128i a ) { return _mm_sll_epi64( a, (__m128i) {0, 0} ); } __m128i logic_right_shift_vec_0_of_64( __m128i a ) { return _mm_srl_epi64( a, (__m128i) {0, 0} ); } __m128i logic_left_shift_vec_0_of_32( __m128i a ) { return _mm_sll_epi32( a, (__m128i) {0, 0} ); } __m128i logic_right_shift_vec_0_of_32( __m128i a ) { return _mm_srl_epi32( a, (__m128i) {0, 0} ); } __m128i logic_left_shift_vec_0_of_16( __m128i a ) { return _mm_sll_epi16( a, (__m128i) {0, 0} ); } __m128i logic_right_shift_vec_0_of_16( __m128i a ) { return _mm_srl_epi16( a, (__m128i) {0, 0} ); } /***************************************************/ For comparison, here are the other vector shift intrinsics that result in good code gen. /***************************************************/ // Logical shift by int immediate zero __m128i logic_left_shift_int_0_of_64( __m128i a ) { return _mm_slli_epi64( a, 0 ); } __m128i logic_right_shift_int_0_of_64( __m128i a ) { return _mm_srli_epi64( a, 0 ); } __m128i logic_left_shift_int_0_of_32( __m128i a ) { return _mm_slli_epi32( a, 0 ); } __m128i logic_right_shift_int_0_of_32( __m128i a ) { return _mm_srli_epi32( a, 0 ); } __m128i logic_left_shift_int_0_of_16( __m128i a ) { return _mm_slli_epi16( a, 0 ); } __m128i logic_right_shift_int_0_of_16( __m128i a ) { return _mm_srli_epi16( a, 0 ); } // Arithmetic Shifts __m128i arith_right_shift_vec_0_of_32( __m128i a ) { return _mm_sra_epi32( a, (__m128i) {0, 0} ); } __m128i arith_right_shift_int_0_of_32( __m128i a ) { return _mm_srai_epi32( a, 0 ); } __m128i arith_right_shift_vec_0_of_16( __m128i a ) { return _mm_sra_epi16( a, (__m128i) {0, 0} ); } __m128i arith_right_shift_int_0_of_16( __m128i a ) { return _mm_srai_epi16( a, 0 ); } /***************************************************/ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 11 16:48:12 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 11 Jun 2015 23:48:12 +0000 Subject: [LLVMbugs] [Bug 23823] New: Regression: UNREACHABLE executed at C:\src\chrome\src\third_party\llvm\tools\clang\lib\CodeGen\CodeGenFunction.cpp:124! while running check-all in a bootstrap build Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23823 Bug ID: 23823 Summary: Regression: UNREACHABLE executed at C:\src\chrome\src\third_party\llvm\tools\clang\lib\Cod eGen\CodeGenFunction.cpp:124! while running check-all in a bootstrap build Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14463 --> https://llvm.org/bugs/attachment.cgi?id=14463&action=edit repro Do a bootstrap build of llvm at r329558 (i.e. first build clang, then build clang with that clang, then run tests). clang crashes while building one of the lld tests: [55/232] Building CXX object tools\lld\unittests\DriverTests\CMakeFiles\DriverTests.dir\DarwinLdDriverTest.cpp.obj FAILED: C:\src\chrome\src\third_party\llvm-bootstrap-install\bin\clang-cl.exe /nologo -wd4146 -wd4180 -wd4244 -wd4258 -wd4267 -wd4291 -wd 345 -wd4351 -wd4355 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4800 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4324 -w14062 -we4238 /W4 /Zc:sizedDealloc- /MD /O2 /Ob2 -Itools\ ld\unittests\CoreTests -IC:\src\chrome\src\third_party\llvm\tools\lld\unittests\CoreTests -IC:\src\chrome\src\third_party\llvm\tools\lld\in lude -Itools\lld\include -Iinclude -IC:\src\chrome\src\third_party\llvm\include -IC:\src\chrome\src\third_party\llvm\utils\unittest\googlet st\include -UNDEBUG -wd4530 -wd4062 -Wno-variadic-macros /EHs-c- /GR- /showIncludes -DGTEST_HAS_PTHREAD=0 -DGTEST_HAS_RTTI=0 -DGTEST_HAS SEH=0 -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_SC _SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS /Fotools\lld\unittests CoreTests\CMakeFiles\CoreTests.dir\RangeTest.cpp.obj /Fdtools\lld\unittests\CoreTests\CMakeFiles\CoreTests.dir\ -c C:\src\chrome\src\third_ arty\llvm\tools\lld\unittests\CoreTests\RangeTest.cpp non-canonical or dependent type in IR-generation UNREACHABLE executed at C:\src\chrome\src\third_party\llvm\tools\clang\lib\CodeGen\CodeGenFunction.cpp:124! 0x000000013FCC5F95 (0x0000000000000016 0x00000000ACCA8BF7 0x0000000141671680 0x0000000076CF912A) 0x000007FEED6BEE1D (0x0000000100000001 0x0000000000000000 0x00000001413E26C0 0x000000000000007C), raise() + 0x1E9 bytes(s) 0x000007FEED6C4A14 (0x00000001413E26C0 0x0000000000ABC590 0x000000000000007C 0x0000000140192ECC), abort() + 0x18 bytes(s) 0x000000013FCCA7E6 (0x0000000004B6C010 0x0000000000000000 0x0000000000000000 0x0000000140D0AE19) 0x000000014019402F (0x0000000004B6C010 0x0000000004B6C1C0 0x0000000004848FE0 0x0000000140D19B2E) 0x000000014023B33D (0x0000000000ABC880 0x0000000004B69C00 0x0000000000ABC880 0x0000000140D28EFE) 0x00000001402243E6 (0x0000000004B69CA8 0x0000000004B6E828 0x0000000000ABC880 0x0000000000000001) 0x000000014022181B (0x0000000004B6E808 0x0000000000ABC760 0x00000000000005C6 0x0000000004B69CA8) 0x000000014018D502 (0x0000000000000498 0x00000000000005C6 0x00000000000005C6 0x0000000003796690) 0x0000000140191813 (0x0000000000C43710 0x0000000004B69CA8 0x0000000004B69CA8 0x0000000000C43710) 0x00000001400E7591 (0x0000000004B69CA8 0x0000000004B69CA8 0x0000000000ABD250 0x0000000000000000) 0x00000001400E7057 (0x0000000000C7DC30 0x0000000004B69CA8 0x0000000000ABDD58 0x0000000000ABD320) 0x00000001400E6BE3 (0x0000000000ABDD58 0x0000000004B69CA8 0x0000000000C794E8 0x0000000000ABD390) 0x00000001400E94DF (0x00007A2C29F62504 0x0000000000ABDE40 0x0000000000ABDD58 0x0000000000C77FB0) 0x00000001400DEB6F (0x0000000004B69CA8 0x0000000004B69CA8 0x0000000000C20C60 0x0000000000000000) 0x00000001400D0214 (0x0000000000C20C60 0x0000000004B69CA8 0x0000000000C4B450 0x0000000000000000) 0x00000001405B50B6 (0x0000000004B69CA8 0x0000000000ABDF00 0x0000000000BD9B70 0xFFFFFFFF00000002) 0x000000013FE8E9AD (0x0000000000BD9B70 0x0000000000000000 0x0000000000BCDD80 0x0000000000000005) 0x00000001400CFDE3 (0x0000000141671390 0x0000000000000000 0x0000000000000001 0x0000000000000000) 0x000000013FE8E859 (0x0000000000000000 0x0000000000BE9750 0x0000000000BE8740 0x0000000000000000) 0x000000013FE6576D (0x0000000000BDC5C0 0x0000000000BD9B70 0x0000000000ABE219 0x0000000000ABEE88) 0x000000013FEDF79D (0x0000000000ABEE88 0x0000000000BDC900 0x0000000000BDEAB0 0x0000000000BDC5C0) 0x000000013F57AB7E (0x0000000000000040 0x0000000000000000 0x0000000141659010 0x0000000000ABE990) 0x000000013F57610A (0x0000000000000072 0x0000000000BE7776 0x0000000000ABE9F0 0x0000000000000000) 0x000000013F5796BE (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000) 0x0000000140ED8BE7 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000) 0x0000000076AC59CD (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), BaseThreadInitThunk() + 0xD bytes(s) 0x0000000076CFB981 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), RtlUserThreadStart() + 0x21 bytes(s) clang-cl.exe: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (trunk 239558) Target: x86_64-pc-windows-msvc Thread model: posix clang-cl.exe: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed sourc , and associated run script. clang-cl.exe: note: diagnostic msg: -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 11 21:38:00 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 12 Jun 2015 04:38:00 +0000 Subject: [LLVMbugs] [Bug 23824] New: clang allows invalid lambda expression in decltype Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23824 Bug ID: 23824 Summary: clang allows invalid lambda expression in decltype Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangbugs at nondot.org Reporter: ryan.burn at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following invalid code compiles with clang (-std=c++14). #include template constexpr int f() { using Func = decltype( [](auto x) { return x; } ); return 0; } int main() { std::integral_constant()> x; return 0; } Both gcc and EDG reject it. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 12 01:33:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 12 Jun 2015 08:33:26 +0000 Subject: [LLVMbugs] [Bug 23827] New: bad code generated code for branches (&, &&) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23827 Bug ID: 23827 Summary: bad code generated code for branches (&, &&) Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: fkastrati at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified consider the following code snippet (c++): void ampamp(int x, int y) { if (x < 3 && y > 10 ) printf("%d%d", x, y); } void amp(int x, int y) { if ((x < 3) & (y > 10) ) printf("%d%d", x, y); } the assembly code generated by clang++ (all versions I tested), is not optimal. Basically, for both methods the assembly code is identical. For the method "amp" (with single `&') there should be generated only one jump, as branch misprediction penalty is very high otherwise As a side note: the code by intel's compiler (ICC) is however generating optimal code for such scenarios, at least for versions icc13, and icc15 that I've tested. See: http://goo.gl/oiTPX5 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 12 07:18:27 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 12 Jun 2015 14:18:27 +0000 Subject: [LLVMbugs] [Bug 23293] libcxx: racy use-after-free on condition_variable In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23293 Eric Fiselier changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Eric Fiselier --- Fixed in r239577. Thanks for the analysis and sorry for the delay. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 12 09:12:54 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 12 Jun 2015 16:12:54 +0000 Subject: [LLVMbugs] [Bug 23828] New: [ms] "Expected MSInheritanceAttr on the CXXRecordDecl!" assert when passing address of base class member function through subclass access path Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23828 Bug ID: 23828 Summary: [ms] "Expected MSInheritanceAttr on the CXXRecordDecl!" assert when passing address of base class member function through subclass access path Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This is not a recent regression, we just didn't have code like this in Chromium until yesterday. thakis$ cat repro.cc template void use(const T &); struct Base { void Method(); }; class Child : public Base {}; void f() { use(&Child::Method); } thakis$ ~/src/llvm-build/bin/clang -cc1 -triple x86_64-apple-windows-msvc -emit-obj repro.cc Assertion failed: (IA && "Expected MSInheritanceAttr on the CXXRecordDecl!"), function getMSInheritanceModel, file /Users/thakis/src/llvm-rw/tools/clang/lib/AST/MicrosoftCXXABI.cpp, line 159. 0 clang 0x0000000103b294c9 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 57 1 clang 0x0000000103b29feb SignalHandler(int) + 875 2 libsystem_platform.dylib 0x00007fff858dcf1a _sigtramp + 26 3 libsystem_platform.dylib 0x00007fff6ba4c764 _sigtramp + 3860265060 4 clang 0x0000000103b29bc6 abort + 22 5 clang 0x0000000103b29ba1 __assert_rtn + 81 6 clang 0x0000000104f638c7 clang::CXXRecordDecl::getMSInheritanceModel() const + 167 7 clang 0x0000000104f63ba9 (anonymous namespace)::MicrosoftCXXABI::getMemberPointerWidthAndAlign(clang::MemberPointerType const*) const + 57 8 clang 0x0000000104ddae8d clang::ASTContext::getTypeInfoImpl(clang::Type const*) const + 1309 9 clang 0x0000000104dda7d2 clang::ASTContext::getTypeInfo(clang::Type const*) const + 194 10 clang 0x0000000104dda571 clang::ASTContext::getTypeInfoInChars(clang::Type const*) const + 113 11 clang 0x0000000104038338 clang::CodeGen::CodeGenModule::ConstructAttributeList(clang::CodeGen::CGFunctionInfo const&, clang::Decl const*, llvm::SmallVector&, unsigned int&, bool) + 4680 12 clang 0x0000000104158031 clang::CodeGen::CodeGenModule::SetFunctionAttributes(clang::GlobalDecl, llvm::Function*, bool, bool) + 225 13 clang 0x000000010415a54b clang::CodeGen::CodeGenModule::GetOrCreateLLVMFunction(llvm::StringRef, llvm::Type*, clang::GlobalDecl, bool, bool, bool, llvm::AttributeSet) + 523 14 clang 0x000000010415d530 clang::CodeGen::CodeGenModule::GetAddrOfFunction(clang::GlobalDecl, llvm::Type*, bool, bool) + 128 15 clang 0x0000000104090c45 EmitFunctionDeclLValue(clang::CodeGen::CodeGenFunction&, clang::Expr const*, clang::FunctionDecl const*) + 117 16 clang 0x000000010408864c clang::CodeGen::CodeGenFunction::EmitDeclRefLValue(clang::DeclRefExpr const*) + 876 17 clang 0x0000000104081684 clang::CodeGen::CodeGenFunction::EmitLValue(clang::Expr const*) + 868 18 clang 0x00000001040bf870 (anonymous namespace)::ScalarExprEmitter::VisitCastExpr(clang::CastExpr*) + 1904 19 clang 0x00000001040b7b6d clang::StmtVisitorBase::Visit(clang::Stmt*) + 493 20 clang 0x00000001040af748 clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 104 21 clang 0x0000000104091cc6 clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, clang::CodeGen::ReturnValueSlot) + 582 22 clang 0x00000001040befec (anonymous namespace)::ScalarExprEmitter::VisitCallExpr(clang::CallExpr const*) + 172 23 clang 0x00000001040b7b98 clang::StmtVisitorBase::Visit(clang::Stmt*) + 536 24 clang 0x00000001040af748 clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 104 25 clang 0x00000001040812aa clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, clang::CodeGen::AggValueSlot, bool) + 250 26 clang 0x00000001040811a7 clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 55 27 clang 0x00000001041231f1 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 433 28 clang 0x000000010412afab clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 91 29 clang 0x000000010414d8fa clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 1194 30 clang 0x000000010415c6a3 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) + 1283 31 clang 0x000000010415909a clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) + 298 32 clang 0x000000010415b4bd clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 1085 33 clang 0x000000010415e214 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 228 34 clang 0x00000001041c825f (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 127 35 clang 0x0000000104147f95 clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 165 36 clang 0x0000000104507fb3 clang::ParseAST(clang::Sema&, bool, bool) + 371 37 clang 0x0000000104146c1b clang::CodeGenAction::ExecuteAction() + 123 38 clang 0x0000000103d58be3 clang::FrontendAction::Execute() + 67 39 clang 0x0000000103d2763c clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 972 40 clang 0x0000000103d99e6b clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 4043 41 clang 0x0000000102a9d45c cc1_main(llvm::ArrayRef, char const*, void*) + 1068 42 clang 0x0000000102a9c105 main + 11029 43 libdyld.dylib 0x00007fff888b45c9 start + 1 44 libdyld.dylib 0x0000000000000006 start + 2004138558 Stack dump: 0. Program arguments: /Users/thakis/src/llvm-build/bin/clang -cc1 -triple x86_64-apple-windows-msvc -emit-obj repro.cc 1. parser at end of file 2. repro.cc:4:6: LLVM IR generation of declaration 'f' 3. repro.cc:4:6: Generating code for declaration 'f' Illegal instruction: 4 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 12 09:39:57 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 12 Jun 2015 16:39:57 +0000 Subject: [LLVMbugs] [Bug 23829] New: assertion coming from Casting.h Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23829 Bug ID: 23829 Summary: assertion coming from Casting.h Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: javier_3 at runbox.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14464 --> https://llvm.org/bugs/attachment.cgi?id=14464&action=edit preprocessed file, comand line and crash report Whenever I compile any c++ file I get this error at the end. I attach one of those file, preprocessed, and a text file where you can see the crash report and the command line I used to compile the file. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 12 10:07:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 12 Jun 2015 17:07:07 +0000 Subject: [LLVMbugs] [Bug 23831] New: deleting null pointer indirection is far too aggressive Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23831 Bug ID: 23831 Summary: deleting null pointer indirection is far too aggressive Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: danalbert at google.com CC: chh at google.com, enh at google.com, llvmbugs at cs.uiuc.edu, nlewycky at google.com, srhines at google.com, timmurray at google.com Blocks: 21420 Classification: Unclassified $ cat foo.cpp int main() { *(int*)0 = 0; } $ clang++ foo.cpp foo.cpp:2:3: warning: indirection of non-volatile null pointer will be deleted, not trap [-Wnull-dereference] *(int*)0 = 0; ^~~~~~~~ foo.cpp:2:3: note: consider using __builtin_trap() or qualifying pointer with 'volatile' 1 warning generated. This is far too aggressive. It's very obvious what the user wanted (each case of this I've had to clean up in android had a comment like "force a crash". Yes, the user almost always wanted abort() or __builtin_trap() rather than what they wrote, but we can't rewrite the world's code over night, so this hinders adoption. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 12 10:32:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 12 Jun 2015 17:32:49 +0000 Subject: [LLVMbugs] [Bug 23832] New: Switch statement lowering leads to incorrect profile data. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23832 Bug ID: 23832 Summary: Switch statement lowering leads to incorrect profile data. Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: congh at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified In lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp, switch statements are lowered to nested if statements or jump table. When building those if statements, the original edge weights information are lost, leading to incorrect block frequencies/branch probabilities in generated code. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 12 10:56:19 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 12 Jun 2015 17:56:19 +0000 Subject: [LLVMbugs] [Bug 23828] [ms] "Expected MSInheritanceAttr on the CXXRecordDecl!" assert when passing address of base class member function through subclass access path In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23828 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dgregor at apple.com Component|Frontend |C++ Resolution|--- |FIXED Assignee|david.majnemer at gmail.com |unassignedclangbugs at nondot. | |org --- Comment #4 from David Majnemer --- Fixed in r239625. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 12 11:39:11 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 12 Jun 2015 18:39:11 +0000 Subject: [LLVMbugs] [Bug 23833] New: If the contents of a nullptr_t are modified through type-punned union, conversions from that nullptr_t to bool don't behave the same as conversion from nullptr to bool Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23833 Bug ID: 23833 Summary: If the contents of a nullptr_t are modified through type-punned union, conversions from that nullptr_t to bool don't behave the same as conversion from nullptr to bool Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: andrey.vul at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified According to [conv.ptr]/1, conversion from nullptr_t to bool is equivalent to conversion from null pointer to bool. The Standard does not specify whether conversion should happen from internal state initialized at construction or from some pseudo-function `constexpr nullpt_t::operator bool() const { return false; }`. The test case uses a union to mutate the internals of a nullptr_t and then checks if nullptr_t still converts correctly to bool, as if it were an invariant of the type. In effect, the value of the nullptr_t need not be accessed at cast since it's intended to decay to null pointer constant when used as a prvalue. But the value is accessed, causing the test case to fail. ### SOURCE: cat a.cc #include union { int x; nullptr_t y; } a = {37}; int main() { assert(!static_cast(a.y)); } ## INVOCATION: clang++ -std=c++11 -v a.cc clang version 3.6.1 (tags/RELEASE_361/final) Target: powerpc64le-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/powerpc64le-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/powerpc64le-linux-gnu/4.9.1 Selected GCC installation: /usr/lib/gcc/powerpc64le-linux-gnu/4.9 Candidate multilib: .;@m64 Selected multilib: .;@m64 "/gsa/tlbgsa-h1/09/andreyv/clang/bin/clang-3.6" -cc1 -triple powerpc64le-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name a.cc -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu ppc64le -target-abi elfv2 -v -dwarf-column-info -resource-dir /gsa/tlbgsa-h1/09/andreyv/clang/bin/../lib/clang/3.6.1 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/c++/4.9 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/powerpc64le-linux-gnu/c++/4.9 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/powerpc64le-linux-gnu/c++/4.9 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/c++/4.9/backward -internal-isystem /usr/local/include -internal-isystem /gsa/tlbgsa-h1/09/andreyv/clang/bin/../lib/clang/3.6.1/include -internal-externc-isystem /usr/include/powerpc64le-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 129 -mstackrealign -fno-signed-char -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/a-98ec2a.o -x c++ a.cc clang -cc1 version 3.6.1 based upon LLVM 3.6.1 default target powerpc64le-unknown-linux-gnu ignoring nonexistent directory "/include" ignoring duplicate directory "/usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/powerpc64le-linux-gnu/c++/4.9" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/c++/4.9 /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/powerpc64le-linux-gnu/c++/4.9 /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/c++/4.9/backward /usr/local/include /gsa/tlbgsa-h1/09/andreyv/clang/bin/../lib/clang/3.6.1/include /usr/include/powerpc64le-linux-gnu /usr/include End of search list. "/usr/bin/ld" --eh-frame-hdr -m elf64lppc -dynamic-linker /lib64/ld64.so.2 -o a.out /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../powerpc64le-linux-gnu/crt1.o /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../powerpc64le-linux-gnu/crti.o /usr/lib/gcc/powerpc64le-linux-gnu/4.9/crtbegin.o -L/usr/lib/gcc/powerpc64le-linux-gnu/4.9 -L/usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../powerpc64le-linux-gnu -L/lib/powerpc64le-linux-gnu -L/lib/../lib64 -L/usr/lib/powerpc64le-linux-gnu -L/usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../.. -L/gsa/tlbgsa-h1/09/andreyv/clang/bin/../lib -L/lib -L/usr/lib /tmp/a-98ec2a.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/powerpc64le-linux-gnu/4.9/crtend.o /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../powerpc64le-linux-gnu/crtn.o -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 12 13:19:19 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 12 Jun 2015 20:19:19 +0000 Subject: [LLVMbugs] [Bug 23835] New: Mail from phabricator doesn't always thread correctly Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23835 Bug ID: 23835 Summary: Mail from phabricator doesn't always thread correctly Product: Website Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Phabricator Assignee: unassignedbugs at nondot.org Reporter: llvm-bugs at justinbogner.com CC: klimek at google.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14468 --> https://llvm.org/bugs/attachment.cgi?id=14468&action=edit Screenshot showing the issue in the mail archive Emails from phabricator don't always show up as a single thread of replies in the archive. You can see an example in the attached image, for the "[PATCH] Improve formatting of lambda functions." thread from http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150608/thread.html -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 12 14:03:30 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 12 Jun 2015 21:03:30 +0000 Subject: [LLVMbugs] [Bug 23836] New: Clang crash when using std::unordered_map with std::array and empty initialization Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23836 Bug ID: 23836 Summary: Clang crash when using std::unordered_map with std::array and empty initialization Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: rtrieu at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Reduced test case: #include #include void foo() { std::array, 5> v = {}; } Command: clang b.cpp -std=c++11 Reduced test case without includes: # 1 "unordered_map" 1 3 namespace std { template struct __array_traits { typedef _Tp _Type[_Nm]; }; template struct array { typedef std::__array_traits<_Tp, _Nm> _AT_Type; typename _AT_Type::_Type _M_elems; }; template class unordered_map { explicit unordered_map() { } }; } // namespace std # 1 "foo.cc" 1 void Foo() { std::array, 5> v = {}; } Command: clang -cc1 -std=c++11 c.cpp lib/Sema/SemaInit.cpp: 443 if (!VerifyOnly) { 444 SemaRef.Diag(CtorDecl->getLocation(), 445 diag::warn_invalid_initializer_from_system_header); >446 SemaRef.Diag(Entity.getDecl()->getLocation(), 447 diag::note_used_in_initialization_here); 448 } On line 446, Entity.getDecl() returns a null pointer, leading to a null dereference in getLocation() Backtrace: #0 0x16003aa llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/bin/clang-3.5+0x16003aa) #1 0x160173b SignalHandler(int) (/usr/local/bin/clang-3.5+0x160173b) #2 0x7f0eb742c340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #3 0x2448132 (anonymous namespace)::InitListChecker::PerformEmptyInit(clang::Sema&, clang::SourceLocation, clang::InitializedEntity const&, bool) (/usr/local/bin/clang-3.5+0x2448132) #4 0x2441ccb (anonymous namespace)::InitListChecker::FillInEmptyInitializations(clang::InitializedEntity const&, clang::InitListExpr*, bool&, bool) (/usr/local/bin/clang-3.5+0x2441ccb) #5 0x2439646 (anonymous namespace)::InitListChecker::InitListChecker(clang::Sema&, clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, bool) (/usr/local/bin/clang-3.5+0x2439646) #6 0x2430556 clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::QualType*) (/usr/local/bin/clang-3.5+0x2430556) #7 0x24481e0 (anonymous namespace)::InitListChecker::PerformEmptyInit(clang::Sema&, clang::SourceLocation, clang::InitializedEntity const&, bool) (/usr/local/bin/clang-3.5+0x24481e0) #8 0x244d0f3 (anonymous namespace)::InitListChecker::FillInEmptyInitForField(unsigned int, clang::FieldDecl*, clang::InitializedEntity const&, clang::InitListExpr*, bool&, bool) (/usr/local/bin/clang-3.5+0x244d0f3) #9 0x2441fdb (anonymous namespace)::InitListChecker::FillInEmptyInitializations(clang::InitializedEntity const&, clang::InitListExpr*, bool&, bool) (/usr/local/bin/clang-3.5+0x2441fdb) #10 0x2439646 (anonymous namespace)::InitListChecker::InitListChecker(clang::Sema&, clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, bool) (/usr/local/bin/clang-3.5+0x2439646) #11 0x2430556 clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::QualType*) (/usr/local/bin/clang-3.5+0x2430556) #12 0x2260936 clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool, bool) (/usr/local/bin/clang-3.5+0x2260936) #13 0x1ff0524 clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) (/usr/local/bin/clang-3.5+0x1ff0524) #14 0x1fee198 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, clang::SourceLocation*, clang::Parser::ForRangeInit*) (/usr/local/bin/clang-3.5+0x1fee198) #15 0x1fe9df7 clang::Parser::ParseSimpleDeclaration(unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&, bool, clang::Parser::ForRangeInit*) (/usr/local/bin/clang-3.5+0x1fe9df7) #16 0x1fe9a3a clang::Parser::ParseDeclaration(unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) (/usr/local/bin/clang-3.5+0x1fe9a3a) #17 0x20539bd clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) (/usr/local/bin/clang-3.5+0x20539bd) #18 0x2053651 clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, bool, clang::SourceLocation*) (/usr/local/bin/clang-3.5+0x2053651) #19 0x205ac6f clang::Parser::ParseCompoundStatementBody(bool) (/usr/local/bin/clang-3.5+0x205ac6f) #20 0x205b4b3 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) (/usr/local/bin/clang-3.5+0x205b4b3) #21 0x1fdc980 clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) (/usr/local/bin/clang-3.5+0x1fdc980) #22 0x1fee09f clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, clang::SourceLocation*, clang::Parser::ForRangeInit*) (/usr/local/bin/clang-3.5+0x1fee09f) #23 0x1fdbfed clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) (/usr/local/bin/clang-3.5+0x1fdbfed) #24 0x1fdba3c clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) (/usr/local/bin/clang-3.5+0x1fdba3c) #25 0x1fdab6b clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) (/usr/local/bin/clang-3.5+0x1fdab6b) #26 0x1fda09b clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) (/usr/local/bin/clang-3.5+0x1fda09b) #27 0x1fd60b6 clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/bin/clang-3.5+0x1fd60b6) #28 0x17ac19e clang::FrontendAction::Execute() (/usr/local/bin/clang-3.5+0x17ac19e) #29 0x177b86c clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/local/bin/clang-3.5+0x177b86c) #30 0x18292e8 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/local/bin/clang-3.5+0x18292e8) #31 0x7040ec cc1_main(llvm::ArrayRef, char const*, void*) (/usr/local/bin/clang-3.5+0x7040ec) #32 0x702f70 main (/usr/local/bin/clang-3.5+0x702f70) #33 0x7f0eb6943ec5 __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:321:0 #34 0x70014c _start (/usr/local/bin/clang-3.5+0x70014c) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 12 14:29:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 12 Jun 2015 21:29:49 +0000 Subject: [LLVMbugs] [Bug 23823] Regression: UNREACHABLE executed at C:\src\chrome\src\third_party\llvm\tools\clang\lib\CodeGen\CodeGenFunction.cpp:124! while running check-all in a bootstrap build In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23823 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Hans Wennborg --- Should be fixed by r239639. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 12 15:58:46 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 12 Jun 2015 22:58:46 +0000 Subject: [LLVMbugs] [Bug 23837] New: [META] Fix as many instructions with missing DebugLoc as possible. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23837 Bug ID: 23837 Summary: [META] Fix as many instructions with missing DebugLoc as possible. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Miscellaneous Instrumentation passes Assignee: unassignedbugs at nondot.org Reporter: vonosmas at gmail.com CC: dblaikie at gmail.com, echristo at gmail.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Generally, LLVM does very bad job in ensuring that, when debug info is enabled (-gline-tables-only or above), all necessary([1]) instructions indeed have DebugLoc attached to them, or that DebugLoc are preserved as we transform the code. For example: * DebugLoc can be easily missed as we split/rearrange basic blocks. * Synthesized instructions in GVN, SCEV etc. often have no debug info. Once we have an instruction I with no DebugLoc, this "missing" DebugLoc would propagate through the program - e.g. every time we construct IRBuilder<> with I as insertion point, it will fail to set correct DebugLoc for instructions it creates. This is painful - with optimizations enabled, we may often fail to provide reasonable line info for instructions, or (worse case, which often happens) incorrectly return line info for *some* preceding instruction which happened to have DebugLoc, but may be completely irrelevant (e.g. come from a different inlined subroutine). I've did several improvements recently: http://llvm.org/viewvc/llvm-project?rev=239438&view=rev http://llvm.org/viewvc/llvm-project?rev=239479&view=rev http://llvm.org/viewvc/llvm-project?rev=239550&view=rev http://llvm.org/viewvc/llvm-project?rev=239551&view=rev http://llvm.org/viewvc/llvm-project?rev=239584&view=rev http://llvm.org/viewvc/llvm-project?rev=239585&view=rev http://llvm.org/viewvc/llvm-project?rev=239643&view=rev But there are many more cases to fix, and even if we fix them all, we should be able to somehow prevent further breakages. * We can improve API for creating new instructions that would force callers to set DebugLoc (or explicitly pass empty one, promising to set it up later). * Add module verifier check that would enforce that if function has *some* attached DebugLocs, then all ([1]) instruction should have them. * Add asserts to places where we believe DebugLoc should always be present if line tables are enabled (e.g. we need it in SanitizerCoverage pass where we know that PCs of certain instructions would be collected, and possibly symbolized later). * Some combination of above. Notes: [1] - Function prologue instructions (alloca's etc.) intentionally have no DebugLoc. PHI nodes *sometimes* do have them, but it's not clear whether there's a contract of some sort. Many users actually call BB->getFirstNonPHI()->getDebugLoc() to get the "entry" debug location, probably because they believe it will be the first insertion point / non-transient instruction. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 12 20:01:13 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 13 Jun 2015 03:01:13 +0000 Subject: [LLVMbugs] [Bug 23838] New: multiple definitions of static variables inside functions Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23838 Bug ID: 23838 Summary: multiple definitions of static variables inside functions Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: heavenandhell171 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Clang is not generating comdats for static variables of classes with virtual members. $ cat > h.h class error_category { public: virtual void fn() {} }; inline error_category& make_error_code() { static error_category C; return C; } $ cat > t1.cpp #include "h.h" int main(int argc, char **argv) { make_error_code(); return 0; } $ cat > t2.cpp #include "h.h" void foo() { make_error_code(); } $ clang++ -std=c++11 t1.cpp t2.cpp -target i686-windows-gnu C:\Dev\MSys2\tmp\test2-135e49.o:(.data+0x0): multiple definition of `make_error_code()::C' C:\Dev\MSys2\tmp\test-bf4e7c.o:(.data+0x0): first defined here clang++.exe: error: linker command failed with exit code 1 (use -v to see invocation) I'm targeting Mingw here, but it doesn't work when targeting MSVC either. Removing virtual from 'void fn()' makes clang work. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 13 04:02:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 13 Jun 2015 11:02:40 +0000 Subject: [LLVMbugs] [Bug 23839] New: Target/Hexagon/MCTargetDesc/HexagonMCDuplexInfo.cpp:397: possible bad if ? Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23839 Bug ID: 23839 Summary: Target/Hexagon/MCTargetDesc/HexagonMCDuplexInfo.cpp:39 7: possible bad if ? Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: dcb314 at hotmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified [trunk/llvm/lib/Target/Hexagon/MCTargetDesc/HexagonMCDuplexInfo.cpp:397]: (style) Same expression on both sides of '&&'. MCI.getOperand(2).isImm() && MCI.getOperand(2).isImm() && -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 13 06:28:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 13 Jun 2015 13:28:39 +0000 Subject: [LLVMbugs] [Bug 9249] clang --help doesn't list useful options In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=9249 Nikola Smiljanić changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |popizdeh at gmail.com Resolution|--- |FIXED --- Comment #2 from Nikola Smiljanić --- All of these are now listed. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 13 06:42:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 13 Jun 2015 13:42:39 +0000 Subject: [LLVMbugs] [Bug 16666] quiet_NaN returns negative NaN In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=16666 Nikola Smiljanić changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |popizdeh at gmail.com Resolution|--- |FIXED --- Comment #1 from Nikola Smiljanić --- I think this is fixed now, at least the output for clang 3.6 is the same as gcc. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 13 06:49:06 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 13 Jun 2015 13:49:06 +0000 Subject: [LLVMbugs] [Bug 19169] crash on invalid attempting to specialize a template method as a template variable In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=19169 Nikola Smiljanić changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |popizdeh at gmail.com Resolution|--- |FIXED --- Comment #2 from Nikola Smiljanić --- Fixed in linked review. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 13 06:50:32 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 13 Jun 2015 13:50:32 +0000 Subject: [LLVMbugs] [Bug 19052] clang 3.4 and trunk segfaults on lambda which uses static object of sorrounding function In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=19052 Nikola Smiljanić changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |popizdeh at gmail.com Resolution|--- |FIXED --- Comment #1 from Nikola Smiljanić --- Compiles fine with 3.6 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 13 06:59:09 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 13 Jun 2015 13:59:09 +0000 Subject: [LLVMbugs] [Bug 20611] crash with lambda (auto) return type In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20611 Nikola Smiljanić changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |popizdeh at gmail.com Resolution|--- |FIXED --- Comment #3 from Nikola Smiljanić --- Doesn't crash with 3.6, emits: test.cpp:6:33: error: expected a type auto l = [](auto& container) -> (auto) { ^ test.cpp:6:34: error: 'auto' not allowed in function prototype auto l = [](auto& container) -> (auto) { -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 13 09:32:14 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 13 Jun 2015 16:32:14 +0000 Subject: [LLVMbugs] [Bug 23451] Segfault with generic lambda and a decltype(undefined_variable) return type In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23451 Meador Inge changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |meadori at gmail.com Resolution|--- |FIXED --- Comment #2 from Meador Inge --- It is fixed in Clang trunk (3.7.0). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 13 09:36:20 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 13 Jun 2015 16:36:20 +0000 Subject: [LLVMbugs] [Bug 23824] clang allows invalid lambda expression in decltype In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23824 Meador Inge changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 13 10:22:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 13 Jun 2015 17:22:36 +0000 Subject: [LLVMbugs] [Bug 23661] [3.5] Crash when creating tuple with at least 5 elements using libc++ In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23661 Meador Inge changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |meadori at gmail.com Resolution|--- |FIXED --- Comment #2 from Meador Inge --- This compiles fine with Clang trunk (3.7.0): $ cat -b pr23661.cpp 1 #include 2 3 template 4 std::tuple tup(T ...things) { 5 return std::tuple(things...); 6 } 7 8 int main() { 9 #ifndef CRASH 10 tup(1, 2, 3, 4); // Ok 11 #else 12 tup(1, 2, 3, 4, 5); // Crash! 13 #endif 14 } $ ./bin/clang++ --version clang version 3.7.0 (trunk 239652) (llvm/trunk 239650) Target: x86_64-apple-darwin14.3.0 Thread model: posix $ ./bin/clang++ -std=c++11 -stdlib=libc++ -DCRASH pr23661.cpp -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 13 10:30:14 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 13 Jun 2015 17:30:14 +0000 Subject: [LLVMbugs] [Bug 23655] ErrorOr.Comparison test is failing under GNU/Linux Debian In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23655 Rafael Ávila de Espíndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Rafael Ávila de Espíndola --- Fixed in r239683. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 13 12:04:35 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 13 Jun 2015 19:04:35 +0000 Subject: [LLVMbugs] [Bug 23840] New: SFINAE failure with variadic non-type template parameter Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23840 Bug ID: 23840 Summary: SFINAE failure with variadic non-type template parameter Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: avi at cloudius-systems.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified The sample code: ====== begin sample ===== template struct x1 { using type = int; }; template struct x2 { }; template ::type...> void f(T x) { } template ::type...> void f(T x) { } int main(int ac, char** av) { f(1); } ====== end sample ==== Does not compile, as clang does not reject the second overload of f(T), even though x2::type does not exist. g++ compiles this. This error is particularly bad since it causes std::experimental::optional<> from libstdc++ 5 not to build. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 13 17:03:33 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 14 Jun 2015 00:03:33 +0000 Subject: [LLVMbugs] [Bug 23841] New: uses-allocator construction for std::pair broken Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23841 Bug ID: 23841 Summary: uses-allocator construction for std::pair broken Product: libc++ Version: 3.6 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: david_work at me.com CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified Uses-allocator construction is not applied to std::pair value_types. The following program is valid and accepted by GCC. #include #include #include #include #include template< typename t > struct al : std::allocator< t > { al() = default; template< typename u > al( al< u > const & ) {} typedef std::false_type propagate_on_container_move_assignment; typedef std::false_type is_always_equal; template< typename u > struct rebind { typedef al< u > other; }; }; struct val; typedef std::scoped_allocator_adaptor< al< val > > alt; struct val { val( int ) {} val( val const & ) = delete; val( val const &, alt ) {} }; struct yeah { template< typename t > bool operator () ( t const &, t const & ) const { return true; } }; int main() { std::list< val, alt > l; l.emplace_back( 41 ); // OK std::set< val, yeah, alt > sok; sok.emplace( 40 ); // OK std::set< std::pair< int, val >, yeah, alt > s; s.emplace( 5, 42 ); // rejected std::map< int, val, yeah, alt > m; m.emplace( 6, 42 ); // rejected } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 02:32:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 14 Jun 2015 09:32:51 +0000 Subject: [LLVMbugs] [Bug 23842] New: Assertion with ThreadSafeRefCountedBase::Release Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23842 Bug ID: 23842 Summary: Assertion with ThreadSafeRefCountedBase::Release Product: compiler-rt Version: 3.6 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedbugs at nondot.org Reporter: ali.demiroz at sap.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I am getting this assertion randomly within my program. It's occurrence is very rare. Assertion failed: NewRefCount >= 0 && "Reference count was already zero.", file D:\x\workspace\hana-externals.clang-OD-ntamd64-ntamd64\src\include\llvm/ADT/IntrusiveRefCntPtr.h, line 112 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 04:22:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 14 Jun 2015 11:22:10 +0000 Subject: [LLVMbugs] [Bug 23843] New: building rpm will include upward workspace directory Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23843 Bug ID: 23843 Summary: building rpm will include upward workspace directory Product: Build scripts Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: tps at vr-web.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified If you set up /var/lib/jenkins/sharedspace/llvm/llmv/ /var/lib/jenkins/sharedspace/build then cd /var/lib/jenkins/sharedspace/build cmake -G "Unix Makefiles" ../llvm make cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM will include /var/lib/jenkins into the rpm (no files, only the directory). installing build rpm leads to an error: rpm -vhU /var/lib/jenkins/sharedspace/llvm/build/LLVM-3.7.0svn-Linux.rpm Vorbereiten... ######################################## Datei /var/lib/jenkins aus der Installation von llvm-3.7.0svn-1.x86_64 kollidiert mit der Datei aus dem Paket jenkins-1.617-1.1.noarch If installed on a system without jenkins, install runs fine, but creates an empty directory "/var/lib/jenkins". At some point the procedures include, in all cases, a directory "../.." up from the build-directory. The most bad thing: this directory might be removed completely in case of deinstalling with option --purge given. If your build directory is "/xxy/xxz" you end up with "/" deleted (but you have to be really ignorant to achieve this ;-) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 05:00:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 14 Jun 2015 12:00:07 +0000 Subject: [LLVMbugs] [Bug 14031] Crash In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=14031 Nikola Smiljanić changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |popizdeh at gmail.com Resolution|--- |INVALID --- Comment #3 from Nikola Smiljanić --- Bug report doesn't have enough information. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 06:53:28 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 14 Jun 2015 13:53:28 +0000 Subject: [LLVMbugs] [Bug 14170] Compiler crash during instantiation of variadic template function In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=14170 Nikola Smiljanić changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |popizdeh at gmail.com Resolution|--- |FIXED --- Comment #3 from Nikola Smiljanić --- Doesn't crash with 3.6 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 08:12:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 14 Jun 2015 15:12:52 +0000 Subject: [LLVMbugs] [Bug 23844] New: clang accepts invalid declaration of member template in local class Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23844 Bug ID: 23844 Summary: clang accepts invalid declaration of member template in local class Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: octoploid at yandex.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified markus at x4 /tmp % cat foo.ii int main() { struct A { template using nested = void; }; } markus at x4 /tmp % clang++ -c -std=c++11 foo.ii markus at x4 /tmp % g++ -c -std=c++11 foo.ii foo.ii: In function ‘int main()’: foo.ii:3:5: error: invalid declaration of member template in local class template using nested = void; ^ markus at x4 /tmp % icpc -c -std=c++11 foo.ii foo.ii(3): error: a template declaration is not allowed here template using nested = void; ^ compilation aborted for foo.ii (code 2) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 08:56:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 14 Jun 2015 15:56:55 +0000 Subject: [LLVMbugs] [Bug 23845] New: Apparent miscompilation with BBVectorize and sqrt Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23845 Bug ID: 23845 Summary: Apparent miscompilation with BBVectorize and sqrt Product: new-bugs Version: 3.6 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: nick at indigorenderer.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14470 --> https://llvm.org/bugs/attachment.cgi?id=14470&action=edit unoptimised IR In the unoptimised IR there are two calls to wombat326, each of which does a sqrt. (see wobble211) In the optimised code there is only one sqrt call. One sqrt call seems to have been erroneously removed. Disabling BBVectorize seems to remove the miscompilation. Optimisation passes are basically the standard -03, with vectorisation passes enabled. Platform: LLVM 3.6, windows 64-bit. Using LLVM for jitting. Unoptimised IR: https://gist.github.com/anonymous/55f29c2b165efd66f0a3#file-gistfile1-ll-L98 Optimised IR: https://gist.github.com/anonymous/5029a142fcc946d708a8 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 14:22:54 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 14 Jun 2015 21:22:54 +0000 Subject: [LLVMbugs] [Bug 19002] Crash with simple union initializers In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=19002 Davide Italiano changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Davide Italiano --- r239446 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 15:36:29 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 14 Jun 2015 22:36:29 +0000 Subject: [LLVMbugs] [Bug 23829] assertion coming from Casting.h In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23829 Javier changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Javier --- *** This bug has been marked as a duplicate of bug 23601 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 20:54:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 03:54:31 +0000 Subject: [LLVMbugs] [Bug 23846] New: Crash while compiling Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23846 Bug ID: 23846 Summary: Crash while compiling Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: todd at cloudera.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I hit the following crash using r238013 to build my project: 0 clang 0x0000000000f0a645 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37 1 clang 0x0000000000f09a11 2 libpthread.so.0 0x0000003797c0f500 3 clang 0x0000000000eb0be4 llvm::APInt::countLeadingZerosSlowCase() const + 36 4 clang 0x0000000000eb0cba llvm::APInt::EqualSlowCase(unsigned long) const + 90 5 clang 0x0000000000b34101 6 clang 0x0000000000b4efb9 llvm::ConstantExpr::getGetElementPtr(llvm::Type*, llvm::Constant*, llvm::ArrayRef, bool, llvm::Type*) + 57 7 clang 0x0000000000871c06 llvm::SimplifyGEPInst(llvm::ArrayRef, llvm::DataLayout const&, llvm::TargetLibraryInfo const*, llvm::DominatorTree const*, llvm::AssumptionCache*, llvm::Instruction const*) + 246 8 clang 0x000000000087282b llvm::SimplifyInstruction(llvm::Instruction*, llvm::DataLayout const&, llvm::TargetLibraryInfo const*, llvm::DominatorTree const*, llvm::AssumptionCache*) + 683 9 clang 0x0000000000dd72b1 10 clang 0x0000000000dd8575 11 clang 0x0000000000c08c3f llvm::FPPassManager::runOnFunction(llvm::Function&) + 623 12 clang 0x0000000000c08d1e llvm::legacy::FunctionPassManagerImpl::run(llvm::Function&) + 126 13 clang 0x0000000000c08dd4 llvm::legacy::FunctionPassManager::run(llvm::Function&) + 36 14 clang 0x000000000130601d clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) + 3837 15 clang 0x00000000012f13b0 16 clang 0x0000000001815885 clang::ParseAST(clang::Sema&, bool, bool) + 741 17 clang 0x0000000001087b86 clang::FrontendAction::Execute() + 118 18 clang 0x0000000001066c71 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 289 19 clang 0x000000000110f673 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1939 20 clang 0x00000000006ccf48 cc1_main(llvm::ArrayRef, char const*, void*) + 968 21 clang 0x00000000006cc68e main + 9902 22 libc.so.6 0x000000379781ecdd __libc_start_main + 253 23 clang 0x00000000006c8b99 Stack dump: 0. Program arguments: /data1/jenkins-workspace/xxx-gerrit/BUILD_TYPE/TSAN/label/xxx-gerrit-slaves/thirdparty/clang-238013/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -main-file-name module_builder.cc -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-feature +sse4.2 -momit-leaf-frame-pointer -g -dwarf-column-info -fno-unique-section-names -coverage-file /data1/jenkins-workspace/xxx-gerrit/BUILD_TYPE/TSAN/label/xxx-gerrit-slaves/src/xxx/codegen/CMakeFiles/codegen.dir/module_builder.cc.o -resource-dir /data1/jenkins-workspace/xxx-gerrit/BUILD_TYPE/TSAN/label/xxx-gerrit-slaves/thirdparty/clang-238013/bin/../lib/clang/3.7.0 -isystem /data1/jenkins-workspace/xxx-gerrit/BUILD_TYPE/TSAN/label/xxx-gerrit-slaves/thirdparty/installed/include -D DYNAMIC_ANNOTATIONS_ENABLED -D XXX_HEADERS_NO_STUBS=1 -D KUDU_HEADERS_USE_RICH_SLICE=1 -D XXX_HEADERS_USE_SHORT_STATUS_MACROS=1 -D XXX_STATIC_DEFINE -D LLVM_SUPPORT_VALGRIND_H -D THREAD_SANITIZER -D _GLIBCXX_EXTERN_TEMPLATE=0 -D __STDC_CONSTANT_MACROS -D __STDC_LIMIT_MACROS -D codegen_EXPORTS -D __STDC_FORMAT_MACROS -I /data1/jenkins-workspace/xxx-gerrit/BUILD_TYPE/TSAN/label/xxx-gerrit-slaves/src -internal-isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7 -internal-isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/x86_64-redhat-linux -internal-isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/backward -internal-isystem /usr/local/include -internal-isystem /data1/jenkins-workspace/xxx-gerrit/BUILD_TYPE/TSAN/label/xxx-gerrit-slaves/thirdparty/clang-238013/bin/../lib/clang/3.7.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O1 -Wall -Wno-sign-compare -Wno-deprecated -Wno-c++11-extensions -fdebug-compilation-dir /data1/jenkins-workspace/xxx-gerrit/BUILD_TYPE/TSAN/label/xxx-gerrit-slaves/src/xxx/codegen -ferror-limit 19 -fmessage-length 0 -fsanitize=thread -fsanitize-blacklist=/data1/jenkins-workspace/xxx-gerrit/BUILD_TYPE/TSAN/label/xxx-gerrit-slaves/build-support/sanitize-blacklist.txt -pthread -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o CMakeFiles/codegen.dir/module_builder.cc.o -x c++ /data1/jenkins-workspace/xxx-gerrit/BUILD_TYPE/TSAN/label/xxx-gerrit-slaves/src/xxx/codegen/module_builder.cc 1. parser at end of file 2. Per-function optimization 3. Running pass 'Early CSE' on function '@_ZN4xxx7codegen13ModuleBuilder4InitEv' clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (trunk) Target: x86_64-unknown-linux-gnu Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. Unfortunately the project isn't open source as of yet, so I can't share the preprocessed source generally. If the above isn't enough to repro, feel free to reply and I can probably get you a copy of the preprocessed source via email. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 22:58:32 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 05:58:32 +0000 Subject: [LLVMbugs] [Bug 14265] Crash on invalid trying to delete a member function declared with a typedef'd function type In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=14265 Nikola Smiljanić changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |popizdeh at gmail.com Resolution|--- |FIXED --- Comment #2 from Nikola Smiljanić --- No longer crashes, tested with r235949. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 23:00:02 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 06:00:02 +0000 Subject: [LLVMbugs] [Bug 15346] Crash when parsing a recursive decltype() return In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=15346 Nikola Smiljanić changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |popizdeh at gmail.com Resolution|--- |FIXED --- Comment #2 from Nikola Smiljanić --- No longer crashes, tested with r235949. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 23:01:01 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 06:01:01 +0000 Subject: [LLVMbugs] [Bug 17500] Explicit template specialization cause crash In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17500 Nikola Smiljanić changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |popizdeh at gmail.com Resolution|--- |FIXED --- Comment #3 from Nikola Smiljanić --- No longer crashes, tested with r235949. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 23:22:35 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 06:22:35 +0000 Subject: [LLVMbugs] [Bug 16203] clang++ 3.3 (trunk 171695) crash when compile In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=16203 Nikola Smiljanić changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Nikola Smiljanić --- No longer crashes, tested with r235949. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 23:25:18 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 06:25:18 +0000 Subject: [LLVMbugs] [Bug 18568] Crash: lambda capturing templated object with initializer In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=18568 Nikola Smiljanić changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |popizdeh at gmail.com Resolution|--- |FIXED --- Comment #2 from Nikola Smiljanić --- No longer crashes, tested with r235949. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 23:26:16 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 06:26:16 +0000 Subject: [LLVMbugs] [Bug 20497] Clang crashes on nested class template with member initializer In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20497 Nikola Smiljanić changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |popizdeh at gmail.com Resolution|--- |FIXED --- Comment #1 from Nikola Smiljanić --- No longer crashes, tested with r235949. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 23:27:03 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 06:27:03 +0000 Subject: [LLVMbugs] [Bug 20996] crash on invalid return of an object with a deleted destructor In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20996 Nikola Smiljanić changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |popizdeh at gmail.com Resolution|--- |FIXED --- Comment #1 from Nikola Smiljanić --- No longer crashes, tested with r235949. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 14 23:29:29 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 06:29:29 +0000 Subject: [LLVMbugs] [Bug 18635] clang crashes in llvm::Module::getNamedValue on thread_local std::unique_ptr In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=18635 Nikola Smiljanić changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Nikola Smiljanić --- Fixed by linked review. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 03:00:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 10:00:51 +0000 Subject: [LLVMbugs] [Bug 23663] OpenMP crash In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23663 İsmail Dönmez changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #17 from İsmail Dönmez --- Since original bug is fixed, I am closing this bug as fixed. Thank you! For the other crash I'll send an email to openmp-dev. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 07:00:18 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 14:00:18 +0000 Subject: [LLVMbugs] [Bug 23848] New: range metadata can be ignored Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23848 Bug ID: 23848 Summary: range metadata can be ignored Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: pitrou at free.fr CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14474 --> https://llvm.org/bugs/attachment.cgi?id=14474&action=edit IR file reproducing the issue If you take the attached IR file and try to optimize it using "opt -O3 -S shape_is_pos.ll", you will get the following output (i.e. LLVM doesn't realize the condition is always true): define i1 @is_positive(i64 %arg) #0 { entry: %result = icmp sgt i64 %arg, -1 ret i1 %result } OTOH if you uncomment the two lines were llvm.assume is called, you get the following (the return code is properly optimized to true): define i1 @is_positive(i64 %arg) #0 { entry: %is_pos = icmp sgt i64 %arg, -1 tail call void @llvm.assume(i1 %is_pos) ret i1 true } (this is something I stumbled on, in a more complicated form, in Numba; unfortunately llvm.assume() can also pessimize some of our benchmarks) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 09:06:28 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 16:06:28 +0000 Subject: [LLVMbugs] [Bug 23849] New: Implement CWG 1579: Return by converting move constructor Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23849 Bug ID: 23849 Summary: Implement CWG 1579: Return by converting move constructor Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangbugs at nondot.org Reporter: howard.hinnant at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified New rules for implicit move on return for C++14: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579 Here is a test to detect if the rules are implemented. This should not compile in C++11 and should compile in C++14: struct X { X() = default; X(X&&) = default; }; struct Y { Y() = default; Y(Y&&) = default; Y(X&&) {} }; Y test() { X x; return x; } int main() { auto y = test(); } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 11:35:18 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 18:35:18 +0000 Subject: [LLVMbugs] [Bug 23593] MSVC Compiling Broken InlineFunction.cpp Revision 237624 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23593 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |hans at chromium.org Resolution|--- |WORKSFORME --- Comment #3 from Hans Wennborg --- As this isn't reproducing for me or any of the buildbots, I'll close this as worksforme. Manoel, if this is still breaking the build for you, could you please paste the error message you're seeing when building? -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 13:06:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 20:06:40 +0000 Subject: [LLVMbugs] [Bug 23850] New: inlined symbols remain undefined in object code Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23850 Bug ID: 23850 Summary: inlined symbols remain undefined in object code Product: clang Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: thomas.dubuisson at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified When using `-ON` where `N < 2` the generated object code fails to either inline functions or generate code for said functions: ``` % clang -O0 -c bug.c % objdump -t bug.o bug.o: file format elf64-x86-64 SYMBOL TABLE: 0000000000000000 l df *ABS* 0000000000000000 bug.c 0000000000000000 l d .text 0000000000000000 .text 0000000000000000 l d .data 0000000000000000 .data 0000000000000000 l d .bss 0000000000000000 .bss 0000000000000000 l d .comment 0000000000000000 .comment 0000000000000000 l d .note.GNU-stack 0000000000000000 .note.GNU-stack 0000000000000000 l d .eh_frame 0000000000000000 .eh_frame 0000000000000000 g F .text 000000000000000d g 0000000000000000 *UND* 0000000000000000 f [tommd at vodka]/tmp% cat bug.c inline void f() {} void g() { f(); } ``` Notice how `f` is marked `inline` then appears as `UND` in the objdump. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 13:09:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 20:09:39 +0000 Subject: [LLVMbugs] [Bug 23851] New: metadata on branch not preserved with loop unswitch Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23851 Bug ID: 23851 Summary: metadata on branch not preserved with loop unswitch Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: weimingz at codeaurora.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The metadata attached with the unswitched branch was not preserved. test case: ;RUN: opt -loop-unswitch -simplifycfg -S < %s | FileCheck %s define i32 @foo(i32 %a, i32 %b) { ;CHECK-LABEL: foo entry: br label %for.body.lr.ph for.body.lr.ph: ; preds = %entry %cmp.10 = icmp sgt i32 %b, 0 br i1 %cmp.10, label %for.body, label %for.cond.cleanup for.body: ; preds = %for.inc, %for.body.lr.ph %i.013 = phi i32 [ 0, %for.body.lr.ph ], [ %inc, %for.inc ] %t2.012 = phi i32 [ 200, %for.body.lr.ph ], [ %t2.1, %for.inc ] %t1.011 = phi i32 [ 100, %for.body.lr.ph ], [ %t1.1, %for.inc ] %cmp1 = icmp eq i32 %a, 12345 br i1 %cmp1, label %if.then, label %if.else, !prof !0 ; CHECK: %cmp1 = icmp eq i32 %a, 12345 ; CHECK-NEXT: br i1 %cmp1, label %if.then.us, label %if.else, !prof !0 if.then: ; preds = %for.body ; CHECK: if.then.us: ; CHECK: %shr.us = ashr i32 %b, 1 ; CHECK: tail call i32 @bar(i32 %shr.us) ; CHECK: add nuw nsw i32 %i.{{.*}}, 1 ; CHECK: %exitcond.us = icmp eq i32 %inc.us, %b ; CHECK: br i1 %exitcond.us, label %for.cond.cleanup, label %if.then.us %shr = ashr i32 %b, 1 %call = tail call i32 @bar(i32 %shr) %add = add nsw i32 %call, %t1.011 br label %for.inc if.else: ; preds = %for.body %call2 = tail call i32 @bar(i32 %b) %mul = mul nsw i32 %call2, %t2.012 br label %for.inc ; CHECK: if.else: ; CHECK: tail call i32 @bar(i32 %b) ; CHECK: %inc = add nuw nsw i32 %i.{{[0-9]+}}, 1 ; CHECK: %exitcond = icmp eq i32 %inc, %b ; CHECK: br i1 %exitcond, label %for.cond.cleanup, label %if.else for.inc: ; preds = %if.then, %if.else %t1.1 = phi i32 [ %add, %if.then ], [ %t1.011, %if.else ] %t2.1 = phi i32 [ %t2.012, %if.then ], [ %mul, %if.else ] %inc = add nuw nsw i32 %i.013, 1 %exitcond = icmp eq i32 %inc, %b br i1 %exitcond, label %for.cond.cleanup, label %for.body for.cond.cleanup: ; preds = %for.inc, %for.body.lr.ph %t2.0.lcssa = phi i32 [ 200, %for.body.lr.ph ], [ %t2.1, %for.inc ] %t1.0.lcssa = phi i32 [ 100, %for.body.lr.ph ], [ %t1.1, %for.inc ] %add3 = add nsw i32 %t2.0.lcssa, %t1.0.lcssa ret i32 %add3 } ;CHECK: !0 = !{!"branch_weights", {{.*}}} declare i32 @bar(i32) !0 = !{!"branch_weights", i32 64, i32 4} -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 13:10:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 20:10:49 +0000 Subject: [LLVMbugs] [Bug 23850] inlined symbols remain undefined in object code In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23850 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rnk at google.com Resolution|--- |INVALID --- Comment #1 from Reid Kleckner --- This is how C99 inline is supposed to work: http://clang.llvm.org/compatibility.html#inline -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 13:17:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 20:17:05 +0000 Subject: [LLVMbugs] [Bug 23839] Target/Hexagon/MCTargetDesc/HexagonMCDuplexInfo.cpp:397: possible bad if ? In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23839 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |echristo at gmail.com Resolution|--- |FIXED --- Comment #1 from Eric Christopher --- Fixed thusly: dzur:~/sources/llvm> git svn dcommit Committing to https://llvm.org/svn/llvm-project/llvm/trunk ... M lib/Target/Hexagon/MCTargetDesc/HexagonMCDuplexInfo.cpp Committed r239751 Thanks! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 13:20:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 20:20:31 +0000 Subject: [LLVMbugs] [Bug 23852] New: vector of const - push_back fail Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23852 Bug ID: 23852 Summary: vector of const - push_back fail Product: libc++ Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: majestio at ya.ru CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified #include int main() { std::vector v1; // all ok std::vector v2 = {1, 2, 3, 4}; // all ok v1.push_back(17); // error, why? } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 14:03:30 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 21:03:30 +0000 Subject: [LLVMbugs] [Bug 23853] New: Assertion `isa(D) && "declaration not instantiated in this scope"' failed -- in instantiation of struct inside lambda inside template struct Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23853 Bug ID: 23853 Summary: Assertion `isa(D) && "declaration not instantiated in this scope"' failed -- in instantiation of struct inside lambda inside template struct Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: andrey.vul at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified We have a template class containing a lambda which itself contains an inner class. Both inner structures -- the lambda and its inner class -- depdend on the template parameter of the outer class. Instantiation of this gives the assertion failure in the summary. ### SOURCE: cat t.cc template struct S { S(R x1) { [] (R x2) -> void { struct A { R x3; A(R x4) : x3(x4) {} }; A a(x2); }(x1); } }; S t (0); int main() { } ## INVOCATION: clang++ -v -std=c++11 -c t.cc clang version 3.6.1 (tags/RELEASE_361/final) Target: powerpc64le-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/powerpc64le-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/powerpc64le-linux-gnu/4.9.1 Selected GCC installation: /usr/lib/gcc/powerpc64le-linux-gnu/4.9 Candidate multilib: .;@m64 Selected multilib: .;@m64 "/gsa/tlbgsa-h1/09/andreyv/clang/bin/clang-3.6" -cc1 -triple powerpc64le-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name t.cc -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu ppc64le -target-abi elfv2 -v -dwarf-column-info -coverage-file /tmp/t.cc -resource-dir /gsa/tlbgsa-h1/09/andreyv/clang/bin/../lib/clang/3.6.1 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/c++/4.9 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/powerpc64le-linux-gnu/c++/4.9 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/powerpc64le-linux-gnu/c++/4.9 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/c++/4.9/backward -internal-isystem /usr/local/include -internal-isystem /gsa/tlbgsa-h1/09/andreyv/clang/bin/../lib/clang/3.6.1/include -internal-externc-isystem /usr/include/powerpc64le-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 135 -mstackrealign -fno-signed-char -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o t.o -x c++ t.cc clang -cc1 version 3.6.1 based upon LLVM 3.6.1 default target powerpc64le-unknown-linux-gnu ignoring nonexistent directory "/include" ignoring duplicate directory "/usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/powerpc64le-linux-gnu/c++/4.9" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/c++/4.9 /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/powerpc64le-linux-gnu/c++/4.9 /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/c++/4.9/backward /usr/local/include /gsa/tlbgsa-h1/09/andreyv/clang/bin/../lib/clang/3.6.1/include /usr/include/powerpc64le-linux-gnu /usr/include End of search list. clang-3.6: /scratch/andreyv/llvm-3.6.1.src/tools/clang/lib/Sema/SemaTemplateInstantiate.cpp:2818: llvm::PointerUnion*>* clang::LocalInstantiationScope::findInstantiationOf(const clang::Decl*): Assertion `isa(D) && "declaration not instantiated in this scope"' failed. #0 0x12703d14 llvm::sys::PrintStackTrace(_IO_FILE*) /scratch/andreyv/llvm-3.6.1.src/lib/Support/Unix/Signals.inc:423:0 #1 0x12704090 PrintStackTraceSignalHandler(void*) /scratch/andreyv/llvm-3.6.1.src/lib/Support/Unix/Signals.inc:480:0 #2 0x127027b0 SignalHandler(int) /scratch/andreyv/llvm-3.6.1.src/lib/Support/Unix/Signals.inc:199:0 0 clang-3.6 0x0000000012703d14 llvm::sys::PrintStackTrace(_IO_FILE*) + 68 1 clang-3.6 0x0000000012704090 2 clang-3.6 0x00000000127027b0 3 0x00003fffa5a80478 __kernel_sigtramp_rt64 + 0 4 libc.so.6 0x00003fffa55d06b8 gsignal + 72 5 libc.so.6 0x00003fffa55d295c abort + 636 6 libc.so.6 0x00003fffa55c6274 7 libc.so.6 0x00003fffa55c6364 __assert_fail + 100 8 clang-3.6 0x000000001475abc4 clang::LocalInstantiationScope::findInstantiationOf(clang::Decl const*) + 500 9 clang-3.6 0x00000000147ae6d4 clang::Sema::FindInstantiatedDecl(clang::SourceLocation, clang::NamedDecl*, clang::MultiLevelTemplateArgumentList const&) + 492 10 clang-3.6 0x00000000147ae4a8 clang::Sema::FindInstantiatedContext(clang::SourceLocation, clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) + 88 11 clang-3.6 0x00000000147aec20 clang::Sema::FindInstantiatedDecl(clang::SourceLocation, clang::NamedDecl*, clang::MultiLevelTemplateArgumentList const&) + 1848 12 clang-3.6 0x00000000147ad578 clang::Sema::InstantiateMemInitializers(clang::CXXConstructorDecl*, clang::CXXConstructorDecl const*, clang::MultiLevelTemplateArgumentList const&) + 1676 13 clang-3.6 0x00000000147aadf8 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 2536 14 clang-3.6 0x00000000147af394 clang::Sema::PerformPendingInstantiations(bool) + 364 15 clang-3.6 0x00000000147aafa4 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 2964 16 clang-3.6 0x00000000147af394 clang::Sema::PerformPendingInstantiations(bool) + 364 17 clang-3.6 0x0000000014078e80 clang::Sema::ActOnEndOfTranslationUnit() + 788 18 clang-3.6 0x0000000013da174c clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 548 19 clang-3.6 0x0000000013d96a8c clang::ParseAST(clang::Sema&, bool, bool) + 692 20 clang-3.6 0x00000000129d96f0 clang::ASTFrontendAction::ExecuteAction() + 468 21 clang-3.6 0x0000000012e95858 clang::CodeGenAction::ExecuteAction() + 1388 22 clang-3.6 0x00000000129d8ff8 clang::FrontendAction::Execute() + 188 23 clang-3.6 0x0000000012986600 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1044 24 clang-3.6 0x0000000012ba8b5c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1316 25 clang-3.6 0x0000000010db9038 cc1_main(llvm::ArrayRef, char const*, void*) + 876 26 clang-3.6 0x0000000010daac88 27 clang-3.6 0x0000000010dab3d4 main + 1040 28 libc.so.6 0x00003fffa55b4e80 29 libc.so.6 0x00003fffa55b5074 __libc_start_main + 196 Stack dump: 0. Program arguments: /gsa/tlbgsa-h1/09/andreyv/clang/bin/clang-3.6 -cc1 -triple powerpc64le-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name t.cc -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu ppc64le -target-abi elfv2 -v -dwarf-column-info -coverage-file /tmp/t.cc -resource-dir /gsa/tlbgsa-h1/09/andreyv/clang/bin/../lib/clang/3.6.1 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/c++/4.9 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/powerpc64le-linux-gnu/c++/4.9 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/powerpc64le-linux-gnu/c++/4.9 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.9/../../../../include/c++/4.9/backward -internal-isystem /usr/local/include -internal-isystem /gsa/tlbgsa-h1/09/andreyv/clang/bin/../lib/clang/3.6.1/include -internal-externc-isystem /usr/include/powerpc64le-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 135 -mstackrealign -fno-signed-char -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o t.o -x c++ t.cc 1. parser at end of file 2. t.cc:2:2: instantiating function definition 'S' 3. t.cc:6:5: instantiating function definition 'A' clang-3.6: error: unable to execute command: Aborted clang-3.6: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.6.1 (tags/RELEASE_361/final) Target: powerpc64le-unknown-linux-gnu Thread model: posix clang-3.6: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.6: note: diagnostic msg: ******************** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 15:05:45 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 22:05:45 +0000 Subject: [LLVMbugs] [Bug 23853] Assertion `isa(D) && "declaration not instantiated in this scope"' failed -- in instantiation of struct inside lambda inside template struct In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23853 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Resolution|--- |DUPLICATE --- Comment #1 from David Majnemer --- Doesn't reproduce on trunk, likely a dupe of PR18653. *** This bug has been marked as a duplicate of bug 18653 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 15:28:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 22:28:31 +0000 Subject: [LLVMbugs] [Bug 23854] New: Adding a reviewer in Phabricator to a bug does not email the new reviewer Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23854 Bug ID: 23854 Summary: Adding a reviewer in Phabricator to a bug does not email the new reviewer Product: Website Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Phabricator Assignee: unassignedbugs at nondot.org Reporter: rtrieu at google.com CC: klimek at google.com, llvmbugs at cs.uiuc.edu Classification: Unclassified On patch http://reviews.llvm.org/D9665, I was added as a reviewer, but Phabricator did not email me. I did not see any mail about this patch until the author pinged it. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 15:35:25 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 15 Jun 2015 22:35:25 +0000 Subject: [LLVMbugs] [Bug 23788] please add 64-bit Windows binaries In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23788 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Hans Wennborg --- This week's snapshot is now available at http://llvm.org/builds/ and it includes a 64-bit version as well. Unless there are any problems, there will be a 64-bit version in the 3.7.0 release too. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 18:10:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 16 Jun 2015 01:10:52 +0000 Subject: [LLVMbugs] [Bug 23855] New: Generic lambda causes linker error when capturing non-POD object with implicit copy ctor Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23855 Bug ID: 23855 Summary: Generic lambda causes linker error when capturing non-POD object with implicit copy ctor Product: clang Version: 3.6 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangbugs at nondot.org Reporter: jvp4846 at g.rit.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14475 --> https://llvm.org/bugs/attachment.cgi?id=14475&action=edit Test case Note: This sounds really similar to bug 22354, but it's still present in 3.6. Compiling the attached test case under clang 3.6 succeeds, but *fails* during linking: $ clang++-3.6 -std=c++1y test.cpp /tmp/test-1c245e.o: In function `see_the_animals()': test.cpp:(.text+0x1a): undefined reference to `zoo::zoo(zoo const&)' clang: error: linker command failed with exit code 1 (use -v to see invocation) Here's my clang version (it should be from the LLVM apt repo): Ubuntu clang version 3.6.0-2ubuntu1~trusty1 (tags/RELEASE_360/final) (based on LLVM 3.6.0) Target: x86_64-pc-linux-gnu Thread model: posix -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 18:10:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 16 Jun 2015 01:10:55 +0000 Subject: [LLVMbugs] [Bug 18252] clang crashes when compiling recursive variadic template expression In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=18252 Nikola Smiljanić changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Nikola Smiljanić --- OK closing, thanks for double-checking. P.S. Exchange Logic M -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 18:32:34 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 16 Jun 2015 01:32:34 +0000 Subject: [LLVMbugs] [Bug 23855] Generic lambda causes linker error when capturing non-POD object with implicit copy ctor In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23855 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |DUPLICATE --- Comment #2 from Richard Smith --- Bug 22354 was fixed after 3.6 was released. This is, as far as I can tell, the same issue; your testcase works fine with Clang trunk. Thanks for the report! *** This bug has been marked as a duplicate of bug 22354 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 18:45:32 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 16 Jun 2015 01:45:32 +0000 Subject: [LLVMbugs] [Bug 23856] New: Generic lambda init-captures can't be captured again Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23856 Bug ID: 23856 Summary: Generic lambda init-captures can't be captured again Product: clang Version: 3.6 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangbugs at nondot.org Reporter: jvp4846 at g.rit.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14476 --> https://llvm.org/bugs/attachment.cgi?id=14476&action=edit Test case Sorry for the confusing bug title; I couldn't come up with a better description that wasn't incredibly verbose. Anyway... If you use an init-capture with a generic lambda, and then in turn capture that capture in another lambda, the compiler fails, thinking that the variable used in the init-capture's *initializer* is being *captured*. See the test file, which produces these errors on clang 3.4, 3.5, and 3.6 (full versions below): -------------------- $ clang++-3.4 -std=c++1y test.cpp test.cpp:10:17: error: variable 'i' cannot be implicitly captured in a lambda with no capture-default specified auto f = [cap=i*2](auto) { ^ test.cpp:5:3: note: in instantiation of function template specialization 'main()::::operator()' requested here f(1); // (1) ^ test.cpp:13:3: note: in instantiation of function template specialization 'metafunc< >' requested here metafunc(f); ^ test.cpp:9:7: note: 'i' declared here int i = 1; ^ test.cpp:10:12: note: lambda expression begins here auto f = [cap=i*2](auto) { ^ 1 error generated. -------------------- The full versions of clang are: Ubuntu clang version 3.4.2- (branches/release_34) (based on LLVM 3.4.2) Target: x86_64-pc-linux-gnu Thread model: posix Debian clang version 3.5.2-svn232162-1~exp1 (branches/release_35) (based on LLVM 3.5.2) Target: x86_64-pc-linux-gnu Thread model: posix Ubuntu clang version 3.6.0-2ubuntu1~trusty1 (tags/RELEASE_360/final) (based on LLVM 3.6.0) Target: x86_64-pc-linux-gnu Thread model: posix -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 19:03:44 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 16 Jun 2015 02:03:44 +0000 Subject: [LLVMbugs] [Bug 23856] Generic lambda init-captures can't be captured again In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23856 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |FIXED --- Comment #1 from Richard Smith --- Thanks for the report, this is already fixed in trunk (I fixed this at the same time as PR23855.) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 20:46:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 16 Jun 2015 03:46:47 +0000 Subject: [LLVMbugs] [Bug 23657] no matching constructor for initialization of 'string' (aka 'basic_string') In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23657 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marshall Clow (home) --- Just tried this with: Apple's shipping clang and libc++ - failed. Apple's shipping clang and ToT libc++ - failed TotClang and Apple's shipping libc++ - compiled w/o error TotClang and ToT libc++ - compiled w/o error. Closing. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 15 21:01:14 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 16 Jun 2015 04:01:14 +0000 Subject: [LLVMbugs] [Bug 23852] vector of const - push_back fail In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23852 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID Assignee|unassignedclangbugs at nondot. |mclow.lists at gmail.com |org | --- Comment #1 from Marshall Clow (home) --- The standard says the requirement for push_back is that the value type (T) of a vector needs to be "T shall be CopyInsertable into X." (where X is the container) [Table 100] What does that mean? [23.2.1/15] says: Given a container type X having an allocator_type identical to A and a value_type identical to T and given an lvalue m of type A, a pointer p of type T*, an expression v of type (possibly const) T ... (skip ahead to p15.4) T is CopyInsertable into X means that, in addition to T being MoveInsertable into X, the following expression is well-formed: allocator_traits::construct(m, p, v) and its evaluation causes the following postcondition to hold: The value of v is unchanged and is equivalent to *p. So, it needs to be able to this: std::allocator a; const int *p; int v = 17; std::allocator_traits>::construct(m, p, v); but p is a pointer to const int - and so the allocator cannot construct a new int there. Hence, the compile failure. In general, containers of const types is a bad idea. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 16 04:39:32 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 16 Jun 2015 11:39:32 +0000 Subject: [LLVMbugs] [Bug 23857] New: [AArch64] Sutraction interferes with umin generation Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23857 Bug ID: 23857 Summary: [AArch64] Sutraction interferes with umin generation Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: opt Assignee: unassignedbugs at nondot.org Reporter: silviu.baranga at arm.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14478 --> https://llvm.org/bugs/attachment.cgi?id=14478&action=edit IR reproducer The following code will not generate umin/umax instructions because of the subtract used to compute a. void test(unsigned char *in0, unsigned char *in1, unsigned char *out, unsigned n) { unsigned i; unsigned char a, b; for (i = 0; i < n; i++) { a = 255 - in0[i]; // Replacing with a = in0[i] allows us to generate umin b = in1[i]; out[i] = (unsigned char) (a < b ? a : b); } } Reproduce with: clang -cc1 -triple aarch64--linux-gnueabi test.c -S -o out.s -mllvm -force-vector-width=16 -O3 -vectorize-loops I've also attached a.ll which contains two similar functions obtained from this code. This shows that removing the xor (sub) operation allows us to generate umin: opt -O3 aa.ll -o aa1.ll -S -force-vector-width=16 bin/llc -O3 aa1.ll -o aa1.s Found on trunk (4a867c7a05bd0560cc16b3c16286e1c76073334e), Mon Jun 15 09:19:41 2015. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 16 08:03:01 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 16 Jun 2015 15:03:01 +0000 Subject: [LLVMbugs] [Bug 23858] New: allow BasicBlock for MetaData Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23858 Bug ID: 23858 Summary: allow BasicBlock for MetaData Product: libraries Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Core LLVM classes Assignee: unassignedbugs at nondot.org Reporter: leissa at cs.uni-saarland.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Can you plz include the following fix for 3.6.2? It is already fixed in master: diff --git a/lib/IR/Metadata.cpp b/lib/IR/Metadata.cpp index 63e5730..d5fdc38 100644 --- a/lib/IR/Metadata.cpp +++ b/lib/IR/Metadata.cpp @@ -252,7 +252,7 @@ ValueAsMetadata *ValueAsMetadata::get(Value *V) { auto &Context = V->getContext(); auto *&Entry = Context.pImpl->ValuesAsMetadata[V]; if (!Entry) { - assert((isa(V) || isa(V) || isa(V)) && + assert((isa(V) || isa(V) || isa(V) || isa(V)) && "Expected constant or function-local value"); assert(!V->NameAndIsUsedByMD.getInt() && "Expected this to be the only metadata use"); -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 16 10:42:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 16 Jun 2015 17:42:36 +0000 Subject: [LLVMbugs] [Bug 23859] New: When someone commits a review, an unhelpful email is (sometimes?) sent to the list Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23859 Bug ID: 23859 Summary: When someone commits a review, an unhelpful email is (sometimes?) sent to the list Product: Website Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Phabricator Assignee: unassignedbugs at nondot.org Reporter: llvm-bugs at justinbogner.com CC: klimek at google.com, llvmbugs at cs.uiuc.edu Classification: Unclassified When a review on phab finishes and the author commits, phab seems to send out an email with the patch in it and no other content. It should say that the review is being closed or something. For example, in http://reviews.llvm.org/D10468, the change was committed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150615/282005.html and phab sent a fairly uninformative email to the list 4 minutes later, here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150615/282007.html -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 16 12:16:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 16 Jun 2015 19:16:05 +0000 Subject: [LLVMbugs] [Bug 23525] Incorrect block frequency generated for entries of irregular loops In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23525 Diego Novillo changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Diego Novillo --- Fixed. http://llvm.org/viewvc/llvm-project?rev=239843&view=rev. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 16 12:46:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 16 Jun 2015 19:46:05 +0000 Subject: [LLVMbugs] [Bug 23860] New: SemaDecl.cpp:1072: void clang::Sema::PushDeclContext(clang::Scope*, clang::DeclContext*): Assertion `getContainingDC(DC) == CurContext && "The next DeclContext should be lexically contained in the current one." Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23860 Bug ID: 23860 Summary: SemaDecl.cpp:1072: void clang::Sema::PushDeclContext(clang::Scope*, clang::DeclContext*): Assertion `getContainingDC(DC) == CurContext && "The next DeclContext should be lexically contained in the current one." Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: andrey.vul at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified ... related to parsing a template structure containing a template function whose default argument is an evaluation of a capture-less lambda containing a structure with a member function. The same assertion failure occurs on 3.6. 3.5 doesn't ICE but makes the linker unhappy: "/usr/bin/ld: /usr/lib/debug/usr/lib/powerpc64le-linux-gnu/crt1.o(.debug_info): relocation %d has invalid symbol index 14" and failure to emit the symbol "main". ### SOURCE: cat t.cpp template struct A { template int f(T x = []()->int{ struct B { int g() { return 0; } } y; if (y.g() != 0) return 1; return 0; }()) { return x; } }; int main() { } ### INVOCATION: clang++ -std=c+11 -v t.cpp clang version 3.7.0 (trunk 239822) Target: powerpc64le-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/powerpc64le-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/powerpc64le-linux-gnu/4.8.2 Found candidate GCC installation: /usr/lib/gcc/powerpc64le-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/powerpc64le-linux-gnu/4.9.1 Selected GCC installation: /usr/lib/gcc/powerpc64le-linux-gnu/4.8 Candidate multilib: .;@m64 Selected multilib: .;@m64 "/home/andrey/clang.trunk/bin/clang-3.7" -cc1 -triple powerpc64le-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name t.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu ppc64le -target-abi elfv2 -v -dwarf-column-info -resource-dir /home/andrey/clang.trunk/bin/../lib/clang/3.7.0 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/c++/4.8 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/powerpc64le-linux-gnu/c++/4.8 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/powerpc64le-linux-gnu/c++/4.8 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/c++/4.8/backward -internal-isystem /usr/local/include -internal-isystem /home/andrey/clang.trunk/bin/../lib/clang/3.7.0/include -internal-externc-isystem /usr/include/powerpc64le-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 0 -mstackrealign -fno-signed-char -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o /tmp/t-8a2f40.o -x c++ t.cpp clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target powerpc64le-unknown-linux-gnu ignoring nonexistent directory "/include" ignoring duplicate directory "/usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/powerpc64le-linux-gnu/c++/4.8" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/c++/4.8 /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/powerpc64le-linux-gnu/c++/4.8 /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/c++/4.8/backward /usr/local/include /home/andrey/clang.trunk/bin/../lib/clang/3.7.0/include /usr/include/powerpc64le-linux-gnu /usr/include End of search list. clang-3.7: /scratch/andreyv/llvm/tools/clang/lib/Sema/SemaDecl.cpp:1072: void clang::Sema::PushDeclContext(clang::Scope*, clang::DeclContext*): Assertion `getContainingDC(DC) == CurContext && "The next DeclContext should be lexically contained in the current one."' failed. #0 0x12c18760 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /scratch/andreyv/llvm/lib/Support/Unix/Signals.inc:437:0 #1 0x12c18b50 PrintStackTraceSignalHandler(void*) /scratch/andreyv/llvm/lib/Support/Unix/Signals.inc:494:0 #2 0x12c17338 SignalHandler(int) /scratch/andreyv/llvm/lib/Support/Unix/Signals.inc:211:0 0 clang-3.7 0x0000000012c18760 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 68 1 clang-3.7 0x0000000012c18b50 2 clang-3.7 0x0000000012c17338 3 0x00003fff8bb70478 __kernel_sigtramp_rt64 + 0 4 libc.so.6 0x00003fff8b6b0a88 gsignal + 72 5 libc.so.6 0x00003fff8b6b693c abort + 620 6 libc.so.6 0x00003fff8b6a65b4 7 libc.so.6 0x00003fff8b6a66a4 __assert_fail + 100 8 clang-3.7 0x00000000147d7c4c clang::Sema::PushDeclContext(clang::Scope*, clang::DeclContext*) + 108 9 clang-3.7 0x000000001488b5e8 clang::Sema::ActOnStartDelayedMemberDeclarations(clang::Scope*, clang::Decl*) + 136 10 clang-3.7 0x000000001449a1c8 clang::Parser::ParseLexedMethodDeclarations(clang::Parser::ParsingClass&) + 372 11 clang-3.7 0x0000000014499e68 clang::Parser::LateParsedClass::ParseLexedMethodDeclarations() + 60 12 clang-3.7 0x000000001449a214 clang::Parser::ParseLexedMethodDeclarations(clang::Parser::ParsingClass&) + 448 13 clang-3.7 0x000000001442d9c8 clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&, unsigned int, clang::Decl*) + 4228 14 clang-3.7 0x00000000144289a0 clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext, clang::Parser::ParsedAttributesWithRange&) + 8948 15 clang-3.7 0x0000000014406220 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*) + 10020 16 clang-3.7 0x000000001448c414 clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int, clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 568 17 clang-3.7 0x000000001448c14c clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 1024 18 clang-3.7 0x000000001448bd0c clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 284 19 clang-3.7 0x00000000143ff528 clang::Parser::ParseDeclaration(unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 508 20 clang-3.7 0x00000000143e6c88 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) + 3028 21 clang-3.7 0x00000000143e6058 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 808 22 clang-3.7 0x00000000143e1488 clang::ParseAST(clang::Sema&, bool, bool) + 432 23 clang-3.7 0x0000000012f08b1c clang::ASTFrontendAction::ExecuteAction() + 468 24 clang-3.7 0x000000001340ad90 clang::CodeGenAction::ExecuteAction() + 1400 25 clang-3.7 0x0000000012f0842c clang::FrontendAction::Execute() + 188 26 clang-3.7 0x0000000012ea9e1c clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1044 27 clang-3.7 0x00000000130e3928 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1316 28 clang-3.7 0x0000000010f58e48 cc1_main(llvm::ArrayRef, char const*, void*) + 876 29 clang-3.7 0x0000000010f48ff4 30 clang-3.7 0x0000000010f4955c main + 1040 31 libc.so.6 0x00003fff8b694d00 32 libc.so.6 0x00003fff8b694ef8 __libc_start_main + 200 Stack dump: 0. Program arguments: /home/andrey/clang.trunk/bin/clang-3.7 -cc1 -triple powerpc64le-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name t.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu ppc64le -target-abi elfv2 -v -dwarf-column-info -resource-dir /home/andrey/clang.trunk/bin/../lib/clang/3.7.0 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/c++/4.8 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/powerpc64le-linux-gnu/c++/4.8 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/powerpc64le-linux-gnu/c++/4.8 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/c++/4.8/backward -internal-isystem /usr/local/include -internal-isystem /home/andrey/clang.trunk/bin/../lib/clang/3.7.0/include -internal-externc-isystem /usr/include/powerpc64le-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 0 -mstackrealign -fno-signed-char -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o /tmp/t-8a2f40.o -x c++ t.cpp 1. t.cpp:16:2: current parser token ';' 2. t.cpp:1:18: parsing struct/union/class body 'A' clang-3.7: error: unable to execute command: Aborted clang-3.7: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (trunk 239822) Target: powerpc64le-unknown-linux-gnu Thread model: posix clang-3.7: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.7: note: diagnostic msg: ******************** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 16 13:26:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 16 Jun 2015 20:26:10 +0000 Subject: [LLVMbugs] [Bug 23861] New: Frontend crash trying to evaluate constexpr (valid code) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23861 Bug ID: 23861 Summary: Frontend crash trying to evaluate constexpr (valid code) Product: clang Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangbugs at nondot.org Reporter: davide at freebsd.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified [davide at rabbit1 /exps/llvm2/build/bin]$ ./clang -std=c++14 crash.cc Assertion failed: (Result && "missing value for local variable"), function evaluateVarDeclInit, file ../tools/clang/lib/AST/ExprConstant.cpp, line 1964. clang-3.7: error: unable to execute command: Abort trap (core dumped) ###################### #include int main() { constexpr int i = 1; struct A { constexpr int a() { return i; } }; } ###################### evalValDeclInit() tries to get the value of 'VD' as temporary based on the frame, which turns out to be null, triggering the assert. In fact, we have the value for that VarDecl, and the following (probably wrong) patch forces the evaluation. I'll try to investigate further, but let's keep track this on bugzilla so I won't forget. Ideas welcome. (gdb) p VD->dump() VarDecl 0x807cc7e38 col:19 referenced i 'const int' cinit `-IntegerLiteral 0x807cc7e98 'int' 1 Index: AST/ExprConstant.cpp =================================================================== --- AST/ExprConstant.cpp (revision 239766) +++ AST/ExprConstant.cpp (working copy) @@ -1961,6 +1961,13 @@ // If this is a local variable, dig out its value. if (Frame) { Result = Frame->getTemporary(VD); + // Try to evaluate the hard way. +#if 1 + if (!Result) { + VD->evaluateValue(); + Result = VD->getEvaluatedValue(); + } +#endif assert(Result && "missing value for local variable"); return true; } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 16 15:03:21 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 16 Jun 2015 22:03:21 +0000 Subject: [LLVMbugs] [Bug 23862] New: Misleading error message in trunk CMakeLists.txt Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23862 Bug ID: 23862 Summary: Misleading error message in trunk CMakeLists.txt Product: libc++abi Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedbugs at nondot.org Reporter: eugene.zelenko at gmail.com CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified In next conditional statement LIBCXXABI_LIBUNWIND_SOURCES is checked but message complains about LIBCXXABI_LIBCXX_PATH. if (LIBCXXABI_LIBUNWIND_SOURCES STREQUAL "LIBCXXABI_LIBUNWIND_SOURCES-NOTFOUND") message(WARNING "LIBCXXABI_LIBCXX_PATH was not specified and couldn't be infered.") set(LIBCXXABI_LIBUNWIND_SOURCES "") endif() -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 16 15:26:59 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 16 Jun 2015 22:26:59 +0000 Subject: [LLVMbugs] [Bug 23863] New: DAGCombiner missing byte swap idioms Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23863 Bug ID: 23863 Summary: DAGCombiner missing byte swap idioms Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: charlesturner7c5 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified LLVM is missing an opportunity to reduce the following byte-swap routine into (when available) target-specific byte swap routines: uint32_t bswap(uint32_t x) { x = (x & 0x0000FFFF) << 16 | (x & 0xFFFF0000) >> 16; x = (x & 0x00FF00FF) << 8 | (x & 0xFF00FF00) >> 8; return x; } Also noticed this one mentioned in lib/Target/README.txt that I'll add here, unsigned long reverse(unsigned v) { unsigned t; t = v ^ ((v << 16) | (v >> 16)); t &= ~0xff0000; v = (v << 24) | (v >> 8); return v ^ (t >> 8); } DAGCombiner should be taught about the first one at least, since GCC does recognise that idiom. Whether LLVM should ever recognise the second one is left to taste. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 16 17:25:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 00:25:36 +0000 Subject: [LLVMbugs] [Bug 23808] segmentation fault in std::unique_ptr virtual destructor In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23808 Benjamin Buch changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Benjamin Buch --- Fixed in "Debian clang version 3.7.0-svn239806-1 (trunk) (based on LLVM 3.7.0)" -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 16 18:18:11 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 01:18:11 +0000 Subject: [LLVMbugs] [Bug 23864] New: no way to close a differential issue without it being accepted Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23864 Bug ID: 23864 Summary: no way to close a differential issue without it being accepted Product: Website Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Phabricator Assignee: unassignedbugs at nondot.org Reporter: richard-llvm at metafoo.co.uk CC: klimek at google.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Phab doesn't let us close a revision that's not accepted, leaving no way to close reviews that don't result in an accepted patch (for instance, if the bug is fixed in a different way, or the direction of the change is rejected). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 16 20:42:25 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 03:42:25 +0000 Subject: [LLVMbugs] [Bug 23865] New: Dumping machine instructions is slow on large functions. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23865 Bug ID: 23865 Summary: Dumping machine instructions is slow on large functions. Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedbugs at nondot.org Reporter: matze at braunis.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14479 --> https://llvm.org/bugs/attachment.cgi?id=14479&action=edit example that dumps slowly Using "llc -print-machineinstrs" is extremely slow on large files. The attached 235K example dumps at the speed of ~0.5s per basic block on a debug build for me. It seems like Value::printAsOperand() internally creates a SlotTracker again for each operand, which ends up enumerating all the values in the function again and again. Extract from an instruments profile for 10 seconds: Running Time Self (ms) Symbol Name 10015.0ms 99.8% 0.0 start 10015.0ms 99.8% 0.0 main 10014.0ms 99.8% 0.0 compileModule(char**, llvm::LLVMContext&) 9933.0ms 99.0% 0.0 llvm::legacy::PassManager::run(llvm::Module&) 9933.0ms 99.0% 0.0 llvm::legacy::PassManagerImpl::run(llvm::Module&) 9932.0ms 99.0% 0.0 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) 9931.0ms 99.0% 0.0 llvm::FPPassManager::runOnModule(llvm::Module&) 9931.0ms 99.0% 0.0 llvm::FPPassManager::runOnFunction(llvm::Function&) 9832.0ms 98.0% 0.0 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) 9514.0ms 94.8% 0.0 (anonymous namespace)::MachineFunctionPrinterPass::runOnMachineFunction(llvm::MachineFunction&) 9514.0ms 94.8% 0.0 llvm::MachineFunction::print(llvm::raw_ostream&, llvm::SlotIndexes*) const 9513.0ms 94.8% 0.0 llvm::MachineBasicBlock::print(llvm::raw_ostream&, llvm::SlotIndexes*) const 9030.0ms 90.0% 0.0 llvm::Value::printAsOperand(llvm::raw_ostream&, bool, llvm::Module const*) const 9030.0ms 90.0% 0.0 WriteAsOperandInternal(llvm::raw_ostream&, llvm::Value const*, (anonymous namespace)::TypePrinting*, (anonymous namespace)::SlotTracker*, llvm::Module const*) 9030.0ms 90.0% 0.0 (anonymous namespace)::SlotTracker::getLocalSlot(llvm::Value const*) 9030.0ms 90.0% 0.0 (anonymous namespace)::SlotTracker::initialize() 9030.0ms 90.0% 1.0 (anonymous namespace)::SlotTracker::processFunction() 8976.0ms 89.4% 259.0 (anonymous namespace)::SlotTracker::processFunctionMetadata(llvm::Function const&) 7281.0ms 72.5% 286.0 (anonymous namespace)::SlotTracker::processInstructionMetadata(llvm::Instruction const&) 302.0ms 3.0% 32.0 llvm::Function::getAllMetadata(llvm::SmallVectorImpl >&) const 270.0ms 2.6% 29.0 llvm::BasicBlock::end() const 257.0ms 2.5% 37.0 llvm::BasicBlock::begin() const 185.0ms 1.8% 42.0 llvm::ilist_iterator::operator++() 151.0ms 1.5% 73.0 llvm::ilist_iterator::operator++() 129.0ms 1.2% 129.0 llvm::ilist_iterator::operator!=(llvm::ilist_iterator const&) const 39.0ms 0.3% 39.0 llvm::ilist_iterator::operator!=(llvm::ilist_iterator const&) const 37.0ms 0.3% 37.0 llvm::ilist_iterator::operator*() const 27.0ms 0.2% 0.0 20.0ms 0.1% 20.0 llvm::SmallVectorTemplateCommon, void>::end() 10.0ms 0.0% 10.0 llvm::ilist_iterator::operator*() const 8.0ms 0.0% 8.0 llvm::SmallVectorTemplateCommon, void>::begin() 1.0ms 0.0% 0.0 llvm::SmallVector, 4u>::SmallVector() 22.0ms 0.2% 0.0 19.0ms 0.1% 1.0 (anonymous namespace)::SlotTracker::CreateFunctionSlot(llvm::Value const*) 3.0ms 0.0% 0.0 llvm::AttributeSet::getFnAttributes() const 2.0ms 0.0% 1.0 llvm::cast_retty::ret_type llvm::dyn_cast(llvm::Instruction const*) 2.0ms 0.0% 2.0 llvm::Value::getType() const 2.0ms 0.0% 0.0 (anonymous namespace)::SlotTracker::CreateAttributeSetSlot(llvm::AttributeSet) 1.0ms 0.0% 0.0 llvm::Type::isVoidTy() const 1.0ms 0.0% 0.0 llvm::cast_retty::ret_type llvm::dyn_cast(llvm::Instruction const*) 1.0ms 0.0% 0.0 llvm::BasicBlock::begin() const 482.0ms 4.8% 0.0 llvm::MachineInstr::print(llvm::raw_ostream&, bool) const 1.0ms 0.0% 1.0 llvm::MachineBasicBlock::isLandingPad() const 1.0ms 0.0% 0.0 llvm::MachineJumpTableInfo::print(llvm::raw_ostream&) const 318.0ms 3.1% 0.0 (anonymous namespace)::AArch64DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) 27.0ms 0.2% 0.0 llvm::DominatorTreeWrapperPass::runOnFunction(llvm::Function&) 24.0ms 0.2% 0.0 (anonymous namespace)::VerifierLegacyPass::runOnFunction(llvm::Function&) 19.0ms 0.1% 0.0 (anonymous namespace)::CFGSimplifyPass::runOnFunction(llvm::Function&) 12.0ms 0.1% 1.0 (anonymous namespace)::CodeGenPrepare::runOnFunction(llvm::Function&) 6.0ms 0.0% 0.0 llvm::LoopInfoWrapperPass::runOnFunction(llvm::Function&) 4.0ms 0.0% 0.0 llvm::BranchProbabilityInfo::runOnFunction(llvm::Function&) 1.0ms 0.0% 0.0 llvm::PMDataManager::removeDeadPasses(llvm::Pass*, llvm::StringRef, llvm::PassDebuggingString) 1.0ms 0.0% 0.0 (anonymous namespace)::ConstantHoisting::runOnFunction(llvm::Function&) 1.0ms 0.0% 1.0 0x10adac8f6 1.0ms 0.0% 0.0 (anonymous namespace)::AtomicExpand::runOnFunction(llvm::Function&) 1.0ms 0.0% 0.0 (anonymous namespace)::UnreachableBlockElim::runOnFunction(llvm::Function&) 1.0ms 0.0% 1.0 llvm::PMDataManager::dumpRequiredSet(llvm::Pass const*) const 1.0ms 0.0% 0.0 (anonymous namespace)::PartiallyInlineLibCalls::runOnFunction(llvm::Function&) 1.0ms 0.0% 0.0 (anonymous namespace)::AArch64PromoteConstant::runOnModule(llvm::Module&) 1.0ms 0.0% 0.0 llvm::PMTopLevelManager::initializeAllAnalysisInfo() 63.0ms 0.6% 0.0 llvm::parseIRFile(llvm::StringRef, llvm::SMDiagnostic&, llvm::LLVMContext&) 13.0ms 0.1% 0.0 llvm::verifyModule(llvm::Module const&, llvm::raw_ostream*) 4.0ms 0.0% 0.0 llvm::LLVMTargetMachine::addPassesToEmitFile(llvm::legacy::PassManagerBase&, llvm::raw_pwrite_stream&, llvm::TargetMachine::CodeGenFileType, bool, void const*, void const*, llvm::MachineFunctionInitializer*) 1.0ms 0.0% 0.0 llvm::TargetLibraryInfoImpl::TargetLibraryInfoImpl(llvm::Triple const&) 1.0ms 0.0% 0.0 llvm::cl::ParseCommandLineOptions(int, char const* const*, char const*) 15.0ms 0.1% 0.0 _dyld_start -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 16 20:55:06 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 03:55:06 +0000 Subject: [LLVMbugs] [Bug 23866] New: r2338791 leads to miscompile of 403.gcc Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23866 Bug ID: 23866 Summary: r2338791 leads to miscompile of 403.gcc Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: unassignedbugs at nondot.org Reporter: matze at braunis.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified r238793 leads to a miscompile of spec 2006 403.gcc (the 200.i and scilab.i inputs produce wrong results). I narrowed it down to the result_ready_cost() function. I will reverted the commit for now as the analysis of this large function will probably take more time. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 17 01:41:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 08:41:10 +0000 Subject: [LLVMbugs] [Bug 23868] New: Runtime GP fault when throwing aligned type Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23868 Bug ID: 23868 Summary: Runtime GP fault when throwing aligned type Product: new-bugs Version: 3.6 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: greg at hewgill.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I have a type that is declared with __attribute__((aligned(16))). When building with clang on OS X on x86_64, the following code causes a GP fault when attempting to throw a value containing this type. The fault happens because the compiler generates a 128-bit move instruction which must be aligned on a 16-byte boundary, but the address is not correctly aligned. Here is a program that reproduces the problem: #include #include struct __attribute__((aligned(16))) int128 { uint64_t w[2]; }; int main() { try { int128 x; throw x; } catch (int128 &e) { printf("%p %lu\n", &e, sizeof(e)); } } And the disassembly with the fault location marked with `->`: a.out`main: 0x100000db0 <+0>: pushq %rbp 0x100000db1 <+1>: movq %rsp, %rbp 0x100000db4 <+4>: subq $0x40, %rsp 0x100000db8 <+8>: movl $0x10, %eax 0x100000dbd <+13>: movl %eax, %edi 0x100000dbf <+15>: callq 0x100000e8c ; symbol stub for: __cxa_allocate_exception 0x100000dc4 <+20>: movaps -0x10(%rbp), %xmm0 -> 0x100000dc8 <+24>: movaps %xmm0, (%rax) 0x100000dcb <+27>: movq 0x23e(%rip), %rsi ; (void *)0x0000000100001058 0x100000dd2 <+34>: xorl %ecx, %ecx 0x100000dd4 <+36>: movl %ecx, %edx 0x100000dd6 <+38>: movq %rax, %rdi 0x100000dd9 <+41>: callq 0x100000e9e ; symbol stub for: __cxa_throw Current register: (lldb) register read rax rax = 0x0000000100905b08 It looks like what is happening is the __cxa_allocate_exception function has no knowledge of the alignment requirements of the type for which it is allocating storage. On my system it happens to allocate an address that ends in 8, and is therefore not 16-byte aligned. When the `movaps` instruction attempts to move data into that memory location, the CPU faults due to unaligned access. Compiler info (`clang` from Xcode 6.3.2): $ clang --version Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 17 05:00:41 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 12:00:41 +0000 Subject: [LLVMbugs] [Bug 23869] New: clang-check not linking Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23869 Bug ID: 23869 Summary: clang-check not linking Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Modules Assignee: unassignedclangbugs at nondot.org Reporter: jmikedupont at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified using debian gcc 4.7.4-3 and https://github.com/llvm-mirror/clang.git branch master commit dbc8c32dde18a4611afe51c281ceefd2201e6b89 Date: Tue Jun 16 22:32:44 2015 +0000 and using llvm mirror commit 4a80b4b0c017c9c13b3c3e806b8f6159addb9bed Date: Wed Jun 17 01:21:20 2015 +0000 Linking CXX executable ../../bin/clang-check CMakeFiles/clang-check.dir/ClangCheck.cpp.o: In function `std::unique_ptr > clang::tooling::newFrontendActionFactory<(anonymous namespace)::ClangCheckActionFactory>((anonymous namespace)::ClangCheckActionFactory*, clang::tooling::SourceFileCallbacks*)::FrontendActionFactoryAdapter::ConsumerFactoryAdaptor::ConsumerFactoryAdaptor((anonymous namespace)::ClangCheckActionFactory*, clang::tooling::SourceFileCallbacks*)': ClangCheck.cpp:(.text._ZZN5clang7tooling24newFrontendActionFactoryIN12_GLOBAL__N_123ClangCheckActionFactoryEEESt10unique_ptrINS0_21FrontendActionFactoryESt14default_deleteIS5_EEPT_PNS0_19SourceFileCallbacksEEN28FrontendActionFactoryAdapter22ConsumerFactoryAdaptorC2EPS3_SC_+0x27): undefined reference to `vtable for std::unique_ptr > clang::tooling::newFrontendActionFactory<(anonymous namespace)::ClangCheckActionFactory>((anonymous namespace)::ClangCheckActionFactory*, clang::tooling::SourceFileCallbacks*)::FrontendActionFactoryAdapter::ConsumerFactoryAdaptor' collect2: error: ld returned 1 exit status make[2]: *** [bin/clang-check] Error 1 make[2]: Target `tools/clang-check/CMakeFiles/clang-check.dir/build' not remade because of errors. make[1]: *** [tools/clang-check/CMakeFiles/clang-check.dir/all] Error 2 make[1]: Target `all' not remade because of errors. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 17 05:08:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 12:08:47 +0000 Subject: [LLVMbugs] [Bug 23869] clang-check not linking In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23869 James Michael Dupont changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from James Michael Dupont --- *** This bug has been marked as a duplicate of bug 22991 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 17 08:05:45 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 15:05:45 +0000 Subject: [LLVMbugs] [Bug 23870] New: clang crash when assembling load from .quad for AArch32 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23870 Bug ID: 23870 Summary: clang crash when assembling load from .quad for AArch32 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM Assignee: unassignedbugs at nondot.org Reporter: richard.barton at arm.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14481 --> https://llvm.org/bugs/attachment.cgi?id=14481&action=edit Commandline from crash report The following assembly code causes a syserr in the llvm backend for ARMv8 AArch32 ldr r1, bar ... .align 3 bar: .quad(symbol) The pertinent information in the stack dump seems to be: Unknown fixup kind! UNREACHABLE executed at .../llvm/lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp:326! Then a stack dump. Reproducer attached. I think this is incorrect input as this assembly would probably load half of the quadword into r1 (endianness dependent) which is probably not what the user wants. Instead there should be some sort of graceful failure message as there is no 64-bit relocation available. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 17 08:20:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 15:20:17 +0000 Subject: [LLVMbugs] [Bug 23871] New: Passing a string literal to a .byte directive crashes the assembler Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23871 Bug ID: 23871 Summary: Passing a string literal to a .byte directive crashes the assembler Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: unassignedbugs at nondot.org Reporter: richard.barton at arm.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following assembly input causes a syserr when assembling for AArch64: .byte("Passing a string to the .byte directive causes clang to crash") Reproduce with clang --target=aarch64-none-eabi t.s Pertinent output seems to be: Unknown ELF relocation type UNREACHABLE executed at /tmp/plgbuild/abs_build/405292_12928/trunk/work/src/llvm/lib/Target/AArch64/MCTargetDesc/AArch64ELFObjectWriter.cpp:244! Then a stack dump from clang. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 17 08:33:20 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 15:33:20 +0000 Subject: [LLVMbugs] [Bug 23872] New: Integrated assembler error message when using .type directive with @ in AArch32 assembly Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23872 Bug ID: 23872 Summary: Integrated assembler error message when using .type directive with @ in AArch32 assembly Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: richard.barton at arm.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14483 --> https://llvm.org/bugs/attachment.cgi?id=14483&action=edit Reproducer The following assembly (also attached) incorrectly uses @ with the .type directive. In AArch32 assembler (like GAS) this is a comment symbol, so the following error is emitted. clang --target=armv8a-arm-none-eabi -c foo.s foo.s:4:16: error: expected STT_, '#', '@', '%' or "" .type bar, @function ^ The error message should not be suggesting '@' as a replacement when assembling AArch32. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 17 10:56:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 17:56:07 +0000 Subject: [LLVMbugs] [Bug 23873] New: Documentation for CMake options Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23873 Bug ID: 23873 Summary: Documentation for CMake options Product: libc++abi Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedbugs at nondot.org Reporter: eugene.zelenko at gmail.com CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified It'll be great to document various CMake options (gcc_eh, how to choose gcc_eh from particular version of GCC, unwind library, etc) on http://libcxxabi.llvm.org and in README file. Proper combinations of CMake options for various platforms (Linux, Mac OS X, etc) will be very helpful. Same for libc++ (gcc_s). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 17 11:30:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 18:30:51 +0000 Subject: [LLVMbugs] [Bug 23874] New: Inliner sometimes produces invalid debug info Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23874 Bug ID: 23874 Summary: Inliner sometimes produces invalid debug info Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Transformation Utilities Assignee: unassignedbugs at nondot.org Reporter: dschuff at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I have an IR file with an approximate structure as follows. It has an inner and outer function with debug info and a middle function without debug info. The inner is inlined into the middle, and then the middle is inlined into the outer. After inlining when the module verifier visits the DISubprogram for the middle function, it checks the first instruction in middle (which originally came from inner), gets the inlinedAtScope, finds that it points to inner, and fails verification. ; Function Attrs: nounwind uwtable define void @inner() #0 { entry: !dbg !13 ret void, !dbg !14 } ; Function Attrs: nounwind uwtable define void @middle() #0 { entry: call void @inner() ret void } ; Function Attrs: nounwind uwtable define void @outer() #0 { entry: call void @middle(), !dbg !21 ret void, !dbg !18 } I'm trying to figure out what the cause is; I tried building a simple reproducer from scratch similar to the above, but I can't reproduce it. I have attached a reproducer which is reduced by bugpoint; bugpoint did a pretty good job reducing the code but did nothing to the debug info, which is still huge, so I'm looking for some suggestions for making that smaller. I tried removing the !llvm.dbg.cu from the module; this had mostly the effect I was looking for, in causing most of the metadata to go away, but it also caused the problem to no longer reproduce. Any suggestions? notes on the reproducer: In the attached file, inner is _ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEaSERKS5_, middle is _ZNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEE3strERKNS_12basic_stringIcS2_S4_EE, and outer is _ZN7testing7MessageC2Ev To reproduce just run opt -inline bugpoint-reduced-simplified.bc The actual error is !dbg attachment points at wrong subprogram for function !22062 = !DISubprogram(name: "str", linkageName: "_ZNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEE3strERKNS_12basic_stringIcS2_S4_EE", scope: !"_ZTSNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEEE", file: !519, line: 453, type: !15385, isLocal: false, isDefinition: true, scopeLine: 454, flags: DIFlagPrototyped, isOptimized: true, function: void (%"class.std::__1::basic_stringbuf.130.422.2573.3290.4485.5202.6875.8070.8787.10460.10699.10938.11416.12372.17258"*, %"class.std::__1::basic_string.5.297.2448.3165.4360.5077.6750.7945.8662.10335.10574.10813.11291.12247.17254"*)* @_ZNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEE3strERKNS_12basic_stringIcS2_S4_EE, declaration: !15384, variables: !22063) void (%"class.std::__1::basic_stringbuf.130.422.2573.3290.4485.5202.6875.8070.8787.10460.10699.10938.11416.12372.17258"*, %"class.std::__1::basic_string.5.297.2448.3165.4360.5077.6750.7945.8662.10335.10574.10813.11291.12247.17254"*)* @_ZNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEE3strERKNS_12basic_stringIcS2_S4_EE %cmp.i = icmp eq %"class.std::__1::basic_string.5.297.2448.3165.4360.5077.6750.7945.8662.10335.10574.10813.11291.12247.17254"* %__str_, %__s, !dbg !91052 !91057 = !DILocation(line: 2411, column: 14, scope: !91058) !91058 = distinct !DILexicalBlock(scope: !59819, file: !32233, line: 2411, column: 9) !59819 = !DISubprogram(name: "operator=", linkageName: "_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEaSERKS5_", scope: !"_ZTSNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE", file: !32233, line: 2409, type: !53554, isLocal: false, isDefinition: true, scopeLine: 2410, flags: DIFlagPrototyped, isOptimized: true, function: void (%"class.std::__1::basic_string.5.297.2448.3165.4360.5077.6750.7945.8662.10335.10574.10813.11291.12247.17254"*, %"class.std::__1::basic_string.5.297.2448.3165.4360.5077.6750.7945.8662.10335.10574.10813.11291.12247.17254"*)* @_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEaSERKS5_, declaration: !58684, variables: !59820) LLVM ERROR: Broken module found, compilation aborted! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 17 11:37:25 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 18:37:25 +0000 Subject: [LLVMbugs] [Bug 23875] New: AnalyzeBranch() fails on non-equality comparison between a float value and zero on X86. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23875 Bug ID: 23875 Summary: AnalyzeBranch() fails on non-equality comparison between a float value and zero on X86. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: congh at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified In LLVM and on X86, AnalyzeBranch() returns true (which means failure) on the branch in the following function: void foo(float f) { if (f != 0) printf("*"); } The generated machine code for this function is: BB#0: derived from LLVM BB %entry Live Ins: %XMM0 %XMM1 = XORPSrr %XMM1, %XMM1 UCOMISSrr %XMM0, %XMM1, %EFLAGS JNE_1 , %EFLAGS JNP_1 , %EFLAGS Successors according to CFG: BB#1(1) BB#2(101) BB#1: derived from LLVM BB %if.then Predecessors according to CFG: BB#0 %EDI = MOV32ri 42 TAILJMPd64 , , %RSP, %RSP, %EDI BB#2: derived from LLVM BB %if.end Predecessors according to CFG: BB#0 RETQ To reproduce this problem, compile the test case shown in the bottom with the command: clang++ -O2 test.C -c -mllvm -debug 2>&1 | grep "unanalyzable fallthrough" You will see the message: Pre-merging due to unanalyzable fallthrough: BB#0 (derived from LLVM BB 'entry') -> BB#1 (derived from LLVM BB 'if.then') which is emitted from lib/CodeGen/MachineBlockPlacement.cpp. The test case: #include void foo(float f) { if (f != 0) printf("*"); } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 17 11:39:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 18:39:31 +0000 Subject: [LLVMbugs] [Bug 23876] New: Incorrect CFG edge weights calculated for loop preheader. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23876 Bug ID: 23876 Summary: Incorrect CFG edge weights calculated for loop preheader. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedbugs at nondot.org Reporter: congh at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified For the attached test case, LLVM generates a new loop preheader with new edges, but the weights on those edges are assigned incorrectly. As a result, the sum of frequencies on incoming edges to the preheader is not equal to the sum of frequencies on outgoing edges (see the attached CFG, in which BB#2 is the newly generated preheader). To reproduce this issue, compile the test case in the following commands: clang++ -O2 -fprofile-instr-generate test.C ./a.out llvm-profdata merge -output=profdata default.profraw clang++ -O2 -fprofile-instr-use=profdata test.C -mllvm -print-after-all &> test.dump In the dumped file, you can see the following IR. Note that the edge weight on BB#2 to BB#3 is 7 comparing to 46 on BB#2 to BB at 1, which is incorrect as the edge BB#2 to BB#3 is never taken. # Machine code for function _Z3fooP4listi: Post SSA Function Live Ins: %RDI in %vreg2, %ESI in %vreg3 BB#0: derived from LLVM BB %entry Live Ins: %ESI %RDI TEST32rr %ESI, %ESI, %EFLAGS JNE_1 , %EFLAGS Successors according to CFG: BB#3(1008003) BB#2(11020005) BB#2: derived from LLVM BB %while.body, Align 4 (16 bytes) Live Ins: %BH %BL %BP %BPL %BX %DI %DIL %EBP %EBX %EDI %RBP %RBX %RDI %R12 %R13 %R14 %R15 %R12B %R13B %R14B %R15B %R12D %R13D %R14D %R15D %R12W %R13W %R14W %R15W %BH %BL %BP %BPL %BX %DI %DIL %EBP %EBX %EDI %RBP %RBX %RDI %R12 %R13 %R14 %R15 %R12B %R13B %R14B %R15B %R12D %R13D %R14D %R15D %R12W %R13W %R14W %R15W Predecessors according to CFG: BB#0 TEST64rr %RDI, %RDI, %EFLAGS JE_1 , %EFLAGS Successors according to CFG: BB#3(7) BB#1(46) BB#1: derived from LLVM BB %while.body Live Ins: %RDI Predecessors according to CFG: BB#2 BB#4 %RDI = MOV64rm %RDI, 1, %noreg, 0, %noreg; mem:LD8[%next5](tbaa=<0x1f56438>) Successors according to CFG: BB#4 BB#4: Predecessors according to CFG: BB#1 TEST64rr %RDI, %RDI, %EFLAGS JNE_1 , %EFLAGS Successors according to CFG: BB#3 BB#1 BB#3: derived from LLVM BB %if.end Predecessors according to CFG: BB#0 BB#2 BB#4 RETQ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 17 13:13:42 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 20:13:42 +0000 Subject: [LLVMbugs] [Bug 23877] New: `clang -print-file-name` doesn't respect LIBRARY_PATH Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23877 Bug ID: 23877 Summary: `clang -print-file-name` doesn't respect LIBRARY_PATH Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangbugs at nondot.org Reporter: jvp4846 at g.rit.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Unlike GCC, clang ignores LIBRARY_PATH when looking up a library via `-print-file-name`, but it *does* consult LIBRARY_PATH when actually linking: jim at huginn ~ $ LIBRARY_PATH=$HOME/lib gcc -print-file-name=libboost_iostreams.so /home/jim/lib/../lib/libboost_iostreams.so jim at huginn ~ $ LIBRARY_PATH=$HOME/lib clang-3.6 -print-file-name=libboost_iostreams.so /usr/bin/../lib/gcc/x86_64-linux-gnu/5.1.0/../../../x86_64-linux-gnu/libboost_iostreams.so jim at huginn ~ $ LIBRARY_PATH=$HOME/lib clang-3.6 -shared -olibfoo.so -lboost_iostreams jim at huginn ~ $ ldd libfoo.so linux-vdso.so.1 => (0x00007fff5c5fe000) libboost_iostreams.so.1.55.0 => /home/jim/lib/libboost_iostreams.so.1.55.0 (0x00007f2d2cb3f000) ... jim at huginn ~ $ clang-3.6 --version Ubuntu clang version 3.6.2-svn239700-1~exp1 (branches/release_36) (based on LLVM 3.6.2) Target: x86_64-pc-linux-gnu Thread model: posix -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 17 14:07:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 21:07:56 +0000 Subject: [LLVMbugs] [Bug 23878] New: [ms] virtual member pointer call gets miscompiled Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23878 Bug ID: 23878 Summary: [ms] virtual member pointer call gets miscompiled Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Consider: C:\src\chrome\src\out\Debug>type repro.cc struct Channel { virtual void Connect() = 0; }; struct SupportsAttachmentBrokering { virtual void GetAttachmentBroker() = 0; }; struct ChannelReader : virtual public SupportsAttachmentBrokering { void GetAttachmentBroker() override {} }; struct ChannelWin : public Channel, public ChannelReader { void Connect() override { void (ChannelWin::*ptr)() = &ChannelWin::OnIOCompleted; (this->*ptr)(); // crashes } virtual void OnIOCompleted() {} }; int main() { ChannelWin channel; channel.Connect(); } This program runs fine when build with cl.exe, but crashes when built with clang-cl.exe: C:\src\chrome\src\out\Debug>cl repro.cc /Feasdf && asdf Microsoft (R) C/C++ Optimizing Compiler Version 18.00.31101 for x86 Copyright (C) Microsoft Corporation. All rights reserved. repro.cc Microsoft (R) Incremental Linker Version 12.00.31101.0 Copyright (C) Microsoft Corporation. All rights reserved. /out:asdf.exe repro.obj C:\src\chrome\src\out\Debug>"..\..\third_party/llvm-build/Release+Asserts/bin/clang-cl" -m32 repro.cc /Feasdf.exe && asdf # ^ This makes a "asdf.ese has stopped working" dialog appear -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 17 16:22:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 23:22:49 +0000 Subject: [LLVMbugs] [Bug 23463] Old LLVM IR file causing assertion `cast(Scope)->describes(MF->getFunction())' to fail In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23463 Paul Robinson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |paul_robinson at playstation.s | |ony.com Resolution|--- |INVALID --- Comment #3 from Paul Robinson --- I think we're content to walk away from this one. We got caught by a mid-release change with insufficiently updated metadata in a private test. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 17 16:50:54 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 17 Jun 2015 23:50:54 +0000 Subject: [LLVMbugs] [Bug 23880] New: Phabricator sometimes likes to send duplicate messages Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23880 Bug ID: 23880 Summary: Phabricator sometimes likes to send duplicate messages Product: Website Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Phabricator Assignee: unassignedbugs at nondot.org Reporter: llvm-bugs at justinbogner.com CC: klimek at google.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Every so often two almost identical mails show up on a phabricator thread. It looked to me like this happens when somebody top-posts in an email reply to a phabricator thread - one mail goes to the list from the email author, another from phab. If this is what's happening, we should teach phab not to send the mail if the destination is already in the recipients list. When I was looking at an example of this happening though, it looks like it might be more complicated than that. Consider these two mails: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150615/281960.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150615/281961.html They're identical, except the former is missing the part with inline replies. You'd think my explanation above was correct: the latter was from Chandler to the list, and the former from phab. This theory gets a bit muddier though, because both of these emails have the following headers: X-Phabricator-Sent-This-Message: Yes X-Phabricator-Mail-Tags: So I guess *both* came from phabricator? That's weird. In any case, I'd really like to only receive the version with the full content, and not the one that repeats the start of the content. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 18 03:09:04 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 18 Jun 2015 10:09:04 +0000 Subject: [LLVMbugs] [Bug 23370] [meta] Using Clang/LLVM as the FreeBSD/mips system compiler In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23370 Bug 23370 depends on bug 20968, which changed state. Bug 20968 Summary: Unsupported assembler branch mnemonics https://llvm.org/bugs/show_bug.cgi?id=20968 What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 18 03:09:03 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 18 Jun 2015 10:09:03 +0000 Subject: [LLVMbugs] [Bug 20968] Unsupported assembler branch mnemonics In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20968 Toma Tabacu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Toma Tabacu --- Fixed in r239905 (doesn't include the immediate operand variants). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 18 07:31:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 18 Jun 2015 14:31:17 +0000 Subject: [LLVMbugs] [Bug 23881] New: Assertion failed: DD && "queried property of class with no definition" Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23881 Bug ID: 23881 Summary: Assertion failed: DD && "queried property of class with no definition" Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: yaron.keren at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14488 --> https://llvm.org/bugs/attachment.cgi?id=14488&action=edit example code Compiling the attached bad-syntax program with: clang -std=c++0x -target i686-pc-linux Future.cpp results in Assertion failed: DD && "queried property of class with no definition", file C:\llvm-clean\tools\clang\include\clang/AST/DeclCXX.h, line 592 clang is r239879 (yesterday). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 18 08:03:57 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 18 Jun 2015 15:03:57 +0000 Subject: [LLVMbugs] [Bug 23882] New: Segfault on compiling std::bind with placeholders Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23882 Bug ID: 23882 Summary: Segfault on compiling std::bind with placeholders Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: afalin at xakep.ru CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14489 --> https://llvm.org/bugs/attachment.cgi?id=14489&action=edit Original source $ clang++ original.cpp --std=c++11 x86_64-pc-linux-gnu-clang-3.6.1: error: unable to execute command: Segmentation fault x86_64-pc-linux-gnu-clang-3.6.1: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.6.1 (tags/RELEASE_361/final) Target: x86_64-pc-linux-gnu Thread model: posix x86_64-pc-linux-gnu-clang-3.6.1: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. x86_64-pc-linux-gnu-clang-3.6.1: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: x86_64-pc-linux-gnu-clang-3.6.1: note: diagnostic msg: /tmp/original-1a075e.cpp x86_64-pc-linux-gnu-clang-3.6.1: note: diagnostic msg: /tmp/original-1a075e.sh x86_64-pc-linux-gnu-clang-3.6.1: note: diagnostic msg: ******************** (gdb) bt #0 0x0000000000db6e18 in TryUserDefinedConversion(clang::Sema&, clang::Expr*, clang::QualType, bool, bool, bool, bool, bool, bool) () #1 0x0000000000db74fd in TryImplicitConversion(clang::Sema&, clang::Expr*, clang::QualType, bool, bool, bool, bool, bool, bool) () #2 0x0000000000db36af in TryCopyInitialization(clang::Sema&, clang::Expr*, clang::QualType, bool, bool, bool, bool) () #3 0x0000000000db47a5 in clang::Sema::AddOverloadCandidate(clang::FunctionDecl*, clang::DeclAccessPair, llvm::ArrayRef, clang::OverloadCandidateSet&, bool, bool, bool) () #4 0x0000000000d48361 in ResolveConstructorOverload(clang::Sema&, clang::SourceLocation, llvm::MutableArrayRef, clang::OverloadCandidateSet&, llvm::ArrayRef, clang::OverloadCandidate*&, bool, bool, bool, bool) () #5 0x0000000000d485bd in TryConstructorInitialization(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::QualType, clang::InitializationSequence&, bool) () #6 0x0000000000d525b2 in clang::InitializationSequence::InitializeFrom(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, bool) () #7 0x0000000000d53129 in clang::Sema::PerformCopyInitialization(clang::InitializedEntity const&, clang::SourceLocation, clang::ActionResult, bool, bool) () #8 0x0000000000ccda22 in clang::Sema::GatherArgumentsForCall(clang::SourceLocation, clang::FunctionDecl*, clang::FunctionProtoType const*, unsigned int, llvm::ArrayRef, llvm::SmallVectorImpl&, clang::Sema::VariadicCallType, bool, bool) () #9 0x0000000000c267c0 in clang::Sema::CompleteConstructorCall(clang::CXXConstructorDecl*, llvm::MutableArrayRef, clang::SourceLocation, llvm::SmallVectorImpl&, bool, bool) () #10 0x0000000000d4ce20 in clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::QualType*) () #11 0x0000000000d5314b in clang::Sema::PerformCopyInitialization(clang::InitializedEntity const&, clang::SourceLocation, clang::ActionResult, bool, bool) () #12 0x0000000000ccda22 in clang::Sema::GatherArgumentsForCall(clang::SourceLocation, clang::FunctionDecl*, clang::FunctionProtoType const*, unsigned int, llvm::ArrayRef, llvm::SmallVectorImpl&, clang::Sema::VariadicCallType, bool, bool) () #13 0x0000000000c267c0 in clang::Sema::CompleteConstructorCall(clang::CXXConstructorDecl*, llvm::MutableArrayRef, clang::SourceLocation, llvm::SmallVectorImpl&, bool, bool) () ... #5417 0x0000000000ccda22 in clang::Sema::GatherArgumentsForCall(clang::SourceLocation, clang::FunctionDecl*, clang::FunctionProtoType const*, unsigned int, llvm::ArrayRef, llvm::SmallVectorImpl&, clang::Sema::VariadicCallType, bool, bool) () ---Type to continue, or q to quit--- #5418 0x0000000000cce99a in clang::Sema::ConvertArgumentsForCall(clang::CallExpr*, clang::Expr*, clang::FunctionDecl*, clang::FunctionProtoType const*, llvm::ArrayRef, clang::SourceLocation, bool) () #5419 0x0000000000ccfa11 in clang::Sema::BuildResolvedCallExpr(clang::Expr*, clang::NamedDecl*, clang::SourceLocation, llvm::ArrayRef, clang::SourceLocation, clang::Expr*, bool) () #5420 0x0000000000ccff1f in clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, bool) () #5421 0x0000000000e83a28 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCallExpr(clang::CallExpr*) () #5422 0x0000000000e7f2ef in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) () #5423 0x0000000000e780de in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) () #5424 0x0000000000e79775 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) () #5425 0x0000000000e798a3 in clang::Sema::SubstType(clang::TypeSourceInfo*, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName) () #5426 0x0000000000e05057 in clang::Sema::SubstDefaultTemplateArgumentIfAvailable(clang::TemplateDecl*, clang::SourceLocation, clang::SourceLocation, clang::Decl*, llvm::SmallVectorImpl&, bool&) () #5427 0x0000000000e54a79 in clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*, llvm::SmallVectorImpl&, unsigned int, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl const*) () #5428 0x0000000000e5e304 in clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*, clang::TemplateArgumentListInfo*, llvm::ArrayRef, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&) () #5429 0x0000000000db3d3b in clang::Sema::AddMethodTemplateCandidate(clang::FunctionTemplateDecl*, clang::DeclAccessPair, clang::CXXRecordDecl*, clang::TemplateArgumentListInfo*, clang::QualType, clang::Expr::Classification, llvm::ArrayRef, clang::OverloadCandidateSet&, bool) () #5430 0x0000000000db3f03 in clang::Sema::AddMethodCandidate(clang::DeclAccessPair, clang::QualType, clang::Expr::Classification, llvm::ArrayRef, clang::OverloadCandidateSet&, bool) () #5431 0x0000000000dc35a2 in clang::Sema::BuildCallToObjectOfClassType(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation) () #5432 0x0000000000cd06e4 in clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, bool) () #5433 0x0000000000e83a28 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCallExpr(clang::CallExpr*) () #5434 0x0000000000e7f2ef in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) () #5435 0x0000000000e780de in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) () #5436 0x0000000000e79775 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) () #5437 0x0000000000e7ad3a in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::QualType) () #5438 0x0000000000e7af23 in clang::Sema::SubstType(clang::QualType, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName) () #5439 0x0000000000e16673 in clang::Sema::CheckTemplateIdType(clang::TemplateName, clang::SourceLocation, clang::TemplateArgumentListInfo&) () #5440 0x0000000000e8aae2 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateSpecializationType(clang::TypeLocBuilder&, clang::TemplateSpecializationTypeLoc, clang::TemplateName) () #5441 0x0000000000e7890f in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) () #5442 0x0000000000e79775 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) () #5443 0x0000000000e87835 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateArgument(clang::TemplateArgumentLoc const&, clang::TemplateArgumentLoc&) () #5444 0x0000000000e8aa40 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateSpecializationType(clang::TypeLocBuilder&, clang::TemplateSpecializationTypeLoc, clang::TemplateName) () #5445 0x0000000000e7890f in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) () #5446 0x0000000000e79775 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) () #5447 0x0000000000e87835 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateArgument(clang::TemplateArgumentLoc const&, clang::TemplateArgumentLoc&) () #5448 0x0000000000e8aa40 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateSpecializationType(clang::TypeLocBuilder&, clang::TemplateSpecializationTypeLoc, clang::TemplateName) () #5449 0x0000000000e7890f in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) () #5450 0x0000000000e79775 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) () #5451 0x0000000000e7ad3a in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::QualType) () #5452 0x0000000000e7af23 in clang::Sema::SubstType(clang::QualType, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName) () #5453 0x0000000000e16673 in clang::Sema::CheckTemplateIdType(clang::TemplateName, clang::SourceLocation, clang::TemplateArgumentListInfo&) () ---Type to continue, or q to quit--- #5454 0x0000000000e8aae2 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateSpecializationType(clang::TypeLocBuilder&, clang::TemplateSpecializationTypeLoc, clang::TemplateName) () #5455 0x0000000000e7890f in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) () #5456 0x0000000000e79775 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) () #5457 0x0000000000e87835 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateArgument(clang::TemplateArgumentLoc const&, clang::TemplateArgumentLoc&) () #5458 0x0000000000e8aa40 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateSpecializationType(clang::TypeLocBuilder&, clang::TemplateSpecializationTypeLoc, clang::TemplateName) () #5459 0x0000000000e7890f in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) () #5460 0x0000000000e79775 in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) () #5461 0x0000000000e798a3 in clang::Sema::SubstType(clang::TypeSourceInfo*, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName) () #5462 0x0000000000e05057 in clang::Sema::SubstDefaultTemplateArgumentIfAvailable(clang::TemplateDecl*, clang::SourceLocation, clang::SourceLocation, clang::Decl*, llvm::SmallVectorImpl&, bool&) () #5463 0x0000000000e54a79 in clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*, llvm::SmallVectorImpl&, unsigned int, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl const*) () #5464 0x0000000000e5e304 in clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*, clang::TemplateArgumentListInfo*, llvm::ArrayRef, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&) () #5465 0x0000000000db4a93 in clang::Sema::AddTemplateOverloadCandidate(clang::FunctionTemplateDecl*, clang::DeclAccessPair, clang::TemplateArgumentListInfo*, llvm::ArrayRef, clang::OverloadCandidateSet&, bool) () #5466 0x00000000005d480d in TryUserDefinedConversion(clang::Sema&, clang::QualType, clang::InitializationKind const&, clang::Expr*, clang::InitializationSequence&, bool) () #5467 0x0000000000d5289f in clang::InitializationSequence::InitializeFrom(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, bool) () #5468 0x0000000000be8705 in clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool, bool) () #5469 0x0000000000a9c28a in clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) () #5470 0x0000000000aaade1 in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, clang::SourceLocation*, clang::Parser::ForRangeInit*) () #5471 0x0000000000aabc79 in clang::Parser::ParseSimpleDeclaration(unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&, bool, clang::Parser::ForRangeInit*) () #5472 0x0000000000aabf4d in clang::Parser::ParseDeclaration(unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) () #5473 0x0000000000b005ff in clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) () #5474 0x0000000000b007f8 in clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, bool, clang::SourceLocation*) () #5475 0x0000000000b032fe in clang::Parser::ParseCompoundStatementBody(bool) () #5476 0x0000000000b051f6 in clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) () #5477 0x0000000000a92d29 in clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) () #5478 0x0000000000aab05b in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, clang::SourceLocation*, clang::Parser::ForRangeInit*) () #5479 0x0000000000a8e911 in clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) () #5480 0x0000000000a8efb9 in clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) [clone .part.170] () #5481 0x0000000000a8efef in clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) () #5482 0x0000000000a94453 in clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) () #5483 0x0000000000a94bf0 in clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) () #5484 0x0000000000a89d13 in clang::ParseAST(clang::Sema&, bool, bool) () #5485 0x0000000000717f86 in clang::FrontendAction::Execute() () #5486 0x00000000006f2a41 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) () #5487 0x00000000006da813 in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) () #5488 0x00000000006d41c0 in cc1_main(llvm::ArrayRef, char const*, void*) () #5489 0x00000000006d37d2 in main () -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 18 08:16:19 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 18 Jun 2015 15:16:19 +0000 Subject: [LLVMbugs] [Bug 23513] msvc14 Compilation failed In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23513 Dan Liew changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |dan at su-root.co.uk Resolution|FIXED |--- --- Comment #9 from Dan Liew --- @Reid I just took a look at r237743 because it was incorporated into a downstream project that uses LLVM. Shouldn't we be using check_cxx_compiler_flag() rather than check_c_compiler_flag()? I say this because the file causing problems is C++ code not C code. Although a user typically uses the same compiler for both C and C++ code a user can tell CMake to use different compilers for C and C++ code. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 18 11:10:01 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 18 Jun 2015 18:10:01 +0000 Subject: [LLVMbugs] [Bug 23883] New: clang-cl incorrectly pass include directories Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23883 Bug ID: 23883 Summary: clang-cl incorrectly pass include directories Product: clang Version: 3.6 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: arkady.shapkin at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I'm trying toolset LLVM-vs2013 with my solution, but clang-cl cannot find my include files: src\perm.cpp(12,10): fatal error : 'mylib/tools2/perm.h' file not found #include clang-cl somehow pass all include directories (/I) as one big -I "..." parameter. clang-cl parameters for cpp file: /Yc"mylib/tools2/perm.h" /GS /analyze- /W3 /Zc:wchar_t /I"C:\Work\TDCode.local\mylib\trunk\" /I"C:\Work\TDCode.local\mylib\trunk\mylib\workspaces\..\..\" /I"C:\Work\TDCode.local\mylib\trunk\mylib\workspaces\..\..\contrib\" /I"C:\Work\TDCode.local\mylib\trunk\mylib\workspaces\..\..\_result\x86_vc90_Debug_DynamicBoost\generated\" /I"C:\Work\TDCode.local\mylib\trunk\mylib\workspaces\..\..\_result\include\" /I"C:\Work\TDCode.local\mylib\trunk\mylib\workspaces\..\..\_result\AllPlatforms\generated\" /I"C:\Program Files (x86)\Visual Leak Detector\include" /Zi /Gm- /O2 /Fd"C:\Work\TDCode.local\mylib\trunk\mylib\workspaces\..\..\_result\x86_vc90_Debug_DynamicBoost\temp\tools2\vc120.pdb" /fp:precise /Zp1 /D "BUILD_TOOLS2" /D "STRICT" /D "_CONVERSION_DONT_USE_THREAD_LOCALE" /D "_CRT_NON_CONFORMING_SWPRINTFS" /D "BOOST_ALL_DYN_LINK" /D "NULL=nullptr" /D "WIN32" /D "NOMINMAX" /D "_SCL_SECURE_NO_WARNINGS" /D "_CRT_SECURE_NO_WARNINGS" /D "_WINDOWS" /D "_WINDLL" /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /GR /Gd /Oy- /MDd /Fa"C:\Work\TDCode.local\mylib\trunk\mylib\workspaces\..\..\_result\x86_vc90_Debug_DynamicBoost\temp\tools2\" /EHsc /nologo /Fo"C:\Work\TDCode.local\mylib\trunk\mylib\workspaces\..\..\_result\x86_vc90_Debug_DynamicBoost\temp\tools2\" /Fp"C:\Work\TDCode.local\mylib\trunk\mylib\workspaces\..\..\_result\x86_vc90_Debug_DynamicBoost\temp\tools2\tools2.pch" -v Visual Studio output: 1>ClCompile: 1> clang version 3.6.1 (tags/RELEASE_361/final) 1> Target: i686-pc-windows-msvc 1> Thread model: posix 1>clang-cl.exe : warning : argument unused during compilation: '/Gm-' 1>clang-cl.exe : warning : argument unused during compilation: '/GS' 1>clang-cl.exe : warning : argument unused during compilation: '/fp:precise' 1>clang-cl.exe : warning : argument unused during compilation: '/Ycmylib/tools2/perm.h' 1>clang-cl.exe : warning : argument unused during compilation: '/FpC:\Work\TDCode.local\mylib\trunk\mylib\workspaces\..\..\_result\x86_vc90_Debug_DynamicBoost\temp\tools2\tools2.pch' 1>clang-cl.exe : warning : argument unused during compilation: '/FdC:\Work\TDCode.local\mylib\trunk\mylib\workspaces\..\..\_result\x86_vc90_Debug_DynamicBoost\temp\tools2\vc120.pdb' 1>clang-cl.exe : warning : argument unused during compilation: '/MP' 1> "C:\\Program Files (x86)\\LLVM\\msbuild-bin\\CL.exe" -cc1 -triple i686-pc-windows-msvc -emit-obj -disable-free -main-file-name perm.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -relaxed-aliasing -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu pentium4 -D_DEBUG -D_MT -D_DLL --dependent-lib=msvcrtd --dependent-lib=oldnames -fexceptions -fcxx-exceptions -fdiagnostics-format msvc -v -gline-tables-only -dwarf-column-info -coverage-file "C:\\Work\\TDCode.local\\mylib\\trunk\\mylib\\tools2\\perm.cpp" -resource-dir "C:\\Program Files (x86)\\LLVM\\msbuild-bin\\..\\lib\\clang\\3.6.1" -D BUILD_TOOLS2 -D STRICT -D _CONVERSION_DONT_USE_THREAD_LOCALE -D _CRT_NON_CONFORMING_SWPRINTFS -D BOOST_ALL_DYN_LINK -D NULL=nullptr -D WIN32 -D NOMINMAX -D _SCL_SECURE_NO_WARNINGS -D _CRT_SECURE_NO_WARNINGS -D _WINDOWS -D _WINDLL -D _MBCS -I "C:\\Work\\TDCode.local\\mylib\\trunk /IC:\\Work\\TDCode.local\\mylib\\trunk\\mylib\\workspaces\\..\\.. /IC:\\Work\\TDCode.local\\mylib\\trunk\\mylib\\workspaces\\..\\..\\contrib /IC:\\Work\\TDCode.local\\mylib\\trunk\\mylib\\workspaces\\..\\..\\_result\\x86_vc90_Debug_DynamicBoost\\generated /IC:\\Work\\TDCode.local\\mylib\\trunk\\mylib\\workspaces\\..\\..\\_result\\include /IC:\\Work\\TDCode.local\\mylib\\trunk\\mylib\\workspaces\\..\\..\\_result\\AllPlatforms\\generated /IC:\\Program Files (x86)\\Visual Leak Detector\\include" -internal-isystem "C:\\Program Files (x86)\\LLVM\\msbuild-bin\\..\\lib\\clang\\3.6.1\\include" -internal-isystem "C:\\Program Files (x86)\\Visual Leak Detector\\include" -internal-isystem "C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\include" -internal-isystem "C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\atlmfc\\include" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\8.1\\Include\\um" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\8.1\\Include\\shared" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\8.1\\Include\\winrt" -O2 -Wall -Wno-error -std=c++11 -fdeprecated-macro -fdebug-compilation-dir "C:\\Work\\TDCode.local\\mylib\\trunk\\mylib\\tools2" -ferror-limit 19 -fmessage-length 0 -mstackrealign -fms-extensions -fms-compatibility -fms-compatibility-version=18.0 -fdelayed-template-parsing -fobjc-runtime=gcc -fpack-struct=1 -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o "C:\\Work\\TDCode.local\\mylib\\trunk\\mylib\\workspaces\\..\\..\\_result\\x86_vc90_Debug_DynamicBoost\\temp\\tools2\\perm.obj" -x c++ "src\\perm.cpp" 1> clang -cc1 version 3.6.1 based upon LLVM 3.6.1 default target i686-pc-windows-gnu 1> ignoring nonexistent directory "C:\Work\TDCode.local\mylib\trunk /IC:\Work\TDCode.local\mylib\trunk\mylib\workspaces\..\.. /IC:\Work\TDCode.local\mylib\trunk\mylib\workspaces\..\..\contrib /IC:\Work\TDCode.local\mylib\trunk\mylib\workspaces\..\..\_result\x86_vc90_Debug_DynamicBoost\generated /IC:\Work\TDCode.local\mylib\trunk\mylib\workspaces\..\..\_result\include /IC:\Work\TDCode.local\mylib\trunk\mylib\workspaces\..\..\_result\AllPlatforms\generated /IC:\Program Files (x86)\Visual Leak Detector\include" 1> #include "..." search starts here: 1> #include <...> search starts here: 1> C:\Program Files (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.1\include 1> C:\Program Files (x86)\Visual Leak Detector\include 1> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include 1> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\include 1> C:\Program Files (x86)\Windows Kits\8.1\Include\um 1> C:\Program Files (x86)\Windows Kits\8.1\Include\shared 1> C:\Program Files (x86)\Windows Kits\8.1\Include\winrt 1> End of search list. 1>src\perm.cpp(12,10): fatal error : 'mylib/tools2/perm.h' file not found 1> #include 1> ^ 1> 1 error generated. It would be great if it will be fixed in the next version -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 18 11:44:28 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 18 Jun 2015 18:44:28 +0000 Subject: [LLVMbugs] [Bug 23884] New: WinEHPrepare failed to demote instruction Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23884 Bug ID: 23884 Summary: WinEHPrepare failed to demote instruction Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedbugs at nondot.org Reporter: alex at crichton.co CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Compiling this IR: ``` target triple = "x86_64-pc-windows-msvc" declare i32 @__C_specific_handler(...) declare void @bar() declare void @baz() declare void @free(i8*) define void @foo() { invoke void @baz() to label %normal unwind label %unwind1 normal: unreachable unwind1: %lp5 = landingpad { i8*, i32 } personality i32 (...)* @__C_specific_handler cleanup %rem = load i8*, i8** undef, align 8 invoke void @bar() to label %normal unwind label %unwind2 unwind2: %lp6 = landingpad { i8*, i32 } personality i32 (...)* @__C_specific_handler cleanup invoke void @baz() to label %normal2 unwind label %unwind3 normal2: call void @free(i8* %rem) unreachable unwind3: %lp4 = landingpad { i8*, i32 } personality i32 (...)* @__C_specific_handler cleanup unreachable } ``` will end up yielding the following when compiled with llc: Failed to demote instruction used in exception handler of function foo: %rem = load i8*, i8** undef, align 8 LLVM ERROR: WinEHPrepare failed to demote instruction This may be a dupe of one of these bugs, but I didn't see a reduced version of them so I wasn't sure unfortnately: * https://llvm.org/bugs/show_bug.cgi?id=23427 * https://llvm.org/bugs/show_bug.cgi?id=23557 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 18 13:28:59 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 18 Jun 2015 20:28:59 +0000 Subject: [LLVMbugs] [Bug 23883] clang-cl incorrectly pass include directories parameters to clang In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23883 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rnk at google.com Resolution|--- |DUPLICATE --- Comment #1 from Reid Kleckner --- This looks the same as PR23709, which is probably an issue in response file parsing. *** This bug has been marked as a duplicate of bug 23709 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 18 14:09:38 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 18 Jun 2015 21:09:38 +0000 Subject: [LLVMbugs] [Bug 23789] clang should warn on "trivially" self-recursive functions In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23789 Nico Weber changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Nico Weber --- r240056 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 18 14:38:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 18 Jun 2015 21:38:55 +0000 Subject: [LLVMbugs] [Bug 23886] New: broadcast of i64 generates broadcast of v2i64 (vbroadcasti128) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23886 Bug ID: 23886 Summary: broadcast of i64 generates broadcast of v2i64 (vbroadcasti128) Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: ahmed.bougacha at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified define <4 x i64> @broadcast64(<2 x i64>* %src) { %l = load <2 x i64>* %src, align 16 %r = shufflevector <2 x i64> %l, <2 x i64> undef, <4 x i32> ret <4 x i64> %r } -> vbroadcasti128 (%rdi), %ymm0 whereas I expected (without folding): vmovaps (%rdi), %xmm0 vbroadcastq %xmm0, %ymm0 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 18 18:01:27 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 19 Jun 2015 01:01:27 +0000 Subject: [LLVMbugs] [Bug 23890] New: -fuse-ld doesn't recognize lld and path to ld Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23890 Bug ID: 23890 Summary: -fuse-ld doesn't recognize lld and path to ld Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangbugs at nondot.org Reporter: eugene.zelenko at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I tried to use -fuse-ld specify lld as linker, but Clang doesn't recognize it. Path to ld (from custom build of binutils) was not recognized too. -fuse-ld doesn't appear on "clang -help" of Clang manual. This is reasonable since LLD is part of LLVM and alternative to ld. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 18 19:13:01 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 19 Jun 2015 02:13:01 +0000 Subject: [LLVMbugs] [Bug 23891] New: scoped enumeration error messages are an embarrassment Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23891 Bug ID: 23891 Summary: scoped enumeration error messages are an embarrassment Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: chandlerc at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified I just got the worst syntax error message I've seen in a long time: In file included from ../lib/CodeGen/PostRASchedulerList.cpp:27: ../include/llvm/Analysis/AliasAnalysis.h:129:57: error: invalid operands to binary expression ('llvm::FunctionModRefLocation' and 'llvm::ModRefInfo') DoesNotAccessMemory = FunctionModRefLocation::Nowhere | ModRefInfo::NoModRef, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~ ../include/llvm/Analysis/AliasAnalysis.h:137:48: error: invalid operands to binary expression ('llvm::FunctionModRefLocation' and 'llvm::ModRefInfo') FunctionModRefLocation::ArgumentPointees | ModRefInfo::Ref, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~ ../include/llvm/Analysis/AliasAnalysis.h:145:48: error: invalid operands to binary expression ('llvm::FunctionModRefLocation' and 'llvm::ModRefInfo') FunctionModRefLocation::ArgumentPointees | ModRefInfo::ModRef, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~ ../include/llvm/Analysis/AliasAnalysis.h:153:54: error: invalid operands to binary expression ('llvm::FunctionModRefLocation' and 'llvm::ModRefInfo') OnlyReadsMemory = FunctionModRefLocation::Anywhere | ModRefInfo::Ref, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~ The bug is that these are scoped enumerations and so there is no '|' operator (it would require an implicit conversion to int). But the error message literally tells me nothing other than that there *is* an error. =[ =[ =[ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 19 00:49:00 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 19 Jun 2015 07:49:00 +0000 Subject: [LLVMbugs] [Bug 17453] support for __attribute__((mode())) with vector types In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17453 Alexey Frolov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Alexey Frolov --- Fixed in r240125. Alexey Frolov ============= Software Engineer Intel Compiler Team Intel -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 19 02:05:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 19 Jun 2015 09:05:49 +0000 Subject: [LLVMbugs] [Bug 23892] New: clang++ crashed compiling an old C++ source file Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23892 Bug ID: 23892 Summary: clang++ crashed compiling an old C++ source file Product: clang Version: trunk Hardware: PC OS: other Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: crash at triad.rr.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14495 --> https://llvm.org/bugs/attachment.cgi?id=14495&action=edit Clang++ asked me to submit these files here I built LLVM and CLANG using the quick start directions and the MSVC quick start guides. The first source file I compiled worked fine and executable worked. The second C++ source I tried caused clang to crash and it informed me that I should submit this bug report -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 19 02:47:53 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 19 Jun 2015 09:47:53 +0000 Subject: [LLVMbugs] [Bug 23893] New: False positive (divide by zero), involving ALIGNOF() Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23893 Bug ID: 23893 Summary: False positive (divide by zero), involving ALIGNOF() Product: clang Version: 3.4 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kremenek at apple.com Reporter: arnsholt at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified In the MoarVM project, we have some code that looks like this (computing offsets for struct members): size_t cur_size; size_t align = ALIGNOF(void *); /* Stuff we don't care about here, setting cur_size */ if (cur_size % align) cur_size += align - cur_size % align; The static analyzer thinks that `align` is initialized to 0 and thus that there's a potential divide-by-zero in the modulo operation. This is clearly not possible, since the smallest possible ALIGNOF value is 1. Our ALIGNOF is implemented like this: #define ALIGNOF(t) ((char *)(&((struct { char c; t _h; } *)0)->_h) - (char *)0) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 19 04:59:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 19 Jun 2015 11:59:36 +0000 Subject: [LLVMbugs] [Bug 23894] New: @llvm.assume is ignored in case of pointer values Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23894 Bug ID: 23894 Summary: @llvm.assume is ignored in case of pointer values Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: tom.aernoudt at synopsys.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14496 --> https://llvm.org/bugs/attachment.cgi?id=14496&action=edit testcase @llvm.assume does not trigger constant propgation in case of pointer values. eg No constant propagation is done to the retun statement for the following code: struct X { unsigned long long* a; }; unsigned long long* fail(X* x) { __builtin_assume(x->a == (unsigned long long*)12345678); return x->a; } While for the following code this works as expected: struct Y { unsigned long long a; }; unsigned long long ok(Y* y) { __builtin_assume(y->a == 12345678); return y->a; } The attached testcase can be used to reproduce the issue. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 19 08:54:45 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 19 Jun 2015 15:54:45 +0000 Subject: [LLVMbugs] [Bug 18843] Cannot create shared_ptr to const derived from enable_shared_from_this In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=18843 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Marshall Clow (home) --- Committed revision 240136 to fix this. Thanks, Howard! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 19 09:10:46 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 19 Jun 2015 16:10:46 +0000 Subject: [LLVMbugs] [Bug 23895] New: cannot initialize arrays of type char16_t Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23895 Bug ID: 23895 Summary: cannot initialize arrays of type char16_t Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: javier_3 at runbox.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Consider the following code: static const wchar_t a[]=u"foo"; static const char16_t b[]=u"foo"; static const char16_t c[4]=u"foo"; static const char16_t d[4]={'f','o','o',0}; static const char16_t * const e=u"foo"; void foo(){ e=d; } All five declarations fail except that of d. The error messages are: error: initializing wide char array with incompatible wide string literal static const wchar_t a[]=u"foo"; ^ error: array initializer must be an initializer list static const char16_t b[]=u"foo"; ^ error: array initializer must be an initializer list static const char16_t c[4]=u"foo"; ^ error: cannot initialize a variable of type 'const char16_t *const' (aka 'const unsigned short *const') with an lvalue of type 'const char16_t [4]' static const char16_t * const e=u"foo"; The last one is really curious given that e=d; is accepted, and d is also a const char16_t [4]. The first one is explicitly allowed by the C11 standard. In 6.7.9.15 we can read: An array with element type compatible with a qualified or unqualified version of wchar_t may be initialized by a wide string literal, and in 6.4.5.3, [...] A wide string literal is the same, except prefixed by the letter L, u, or U. So u"foo" is a wide string literal which, by explicit wording in 6.7.9 (Initializations) may be used for initializing an array of whcar_t elements. The last one should be allowed, the same as e=d is, for the string literal u"foo" is, again by 6.4.5 (par. 6): The multibyte character sequence is then used to initialize an array of static storage duration and length just sufficient to contain the sequence. So it is an static array of type char16_t [4] that should be valid as the right operand of = where the right hand side is of type const char16_t *. This is a very annoying bug because it precludes the use of u-prefixed strings for the constant strings of the program, hence for all the program (if they need be of type wchar_t, then the functions taking them must be so, and so on). In particular, I would have to undo all the changes like static const char16_t* const ff[]={ u"All", u"FormaP", u"Color", u"ColorP" ... } where I replaced wchar_t by char16_t and L" by u", and I have more than one thousand, and all the functions that operate on wchar_t strings, which I have changed to take / return char16_t strings. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 19 11:57:14 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 19 Jun 2015 18:57:14 +0000 Subject: [LLVMbugs] [Bug 23897] New: x86_64 fp128 incorrect mangled name, calling convention Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23897 Bug ID: 23897 Summary: x86_64 fp128 incorrect mangled name, calling convention Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: chh at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified clang -target x86_64-linux-android uses IEEEquad format (fp128) for long double. See latest change in http://reviews.llvm.org/D8357. This is equivalent to gcc's __float128 type, but clang x86_64-linux-android's long double type is still incompatible with gcc's __float128, or Android's gcc long double for x86_64. (1) Android x86_64 g++ uses mangled name 'g' for long double and __float128 types, but clang target x86_64-linux-android uses 'e' for long double type. (2) According to AMD64 ABI http://www.x86-64.org/documentation/abi.pdf __float128 values should be passed and returned in SSE registers, xmm0 etc., but llvm uses %rsi and %rdi now. llvm's X86CallingConv.td has handled f64 and f80, but not f128 yet. The following test case runs on native x86_64 host with g++ and long double implemented as fp80. (a) llvm x86_64-linux-android's long double is fp128 but is not passed/returned as __float128. (b) llvm x86_64-linux-gnu's long double is fp80 and is passed/returned as __float80. $ cat t.cpp typedef double D; typedef long double LD; extern "C" { void printf(const char*, ...); int memcmp(const void *s1, const void *s2, unsigned long); void print_double_ptr(void*p); void print_long_double_ptr(void*p); void print_float80_ptr(void*p); void print_float128_ptr(void*p); void print_double_value(double v); void print_long_double_value(long double v); // pass my long double and let gcc x64 print it as __float80. void print_float80_value(long double v); // pass my long double and let gcc x64 print it as __float128. void print_float128_value(long double v); } D myd = 1.0; LD myld = 1.0L; extern D gd; // gcc x64 double extern LD gld; // gcc x64 long double extern LD gf80; // gcc x64 __float80 extern LD gf128; // gcc x64 __float128 void mycompare(const char *msg, const void *s1, const void *s2, unsigned long n) { printf("%s: they are %s\n", msg, memcmp(s1, s2, n) ? "different" : "the same"); } extern "C" LD get_my_LD_as_LD() { return myld; } extern "C" LD get_my_LD_as_F80() { return myld; } extern "C" LD get_my_LD_as_F128() { return myld; } void mytest() { mycompare("my long double vs gcc long double", &myld, &gld, sizeof(myld)); mycompare("my long double vs gcc __float80", &myld, &gf80, sizeof(myld)); mycompare("my long double vs gcc __float128", &myld, &gf128, sizeof(myld)); print_double_ptr(&myd); print_long_double_ptr(&myld); print_float80_ptr(&myld); print_float128_ptr(&myld); printf("==== pass my long double to gcc x64 printer:\n"); print_double_value(myd); print_long_double_value(myld); print_float80_value(myld); print_float128_value(myld); } $ cat dump.cpp typedef double D; typedef long double LD; typedef __float80 F80; typedef __float128 F128; extern "C" { void printf(const char*, ...); void print_double_ptr(void*p) { printf(" as double ptr %f\n", (double)*(double*)p); } void print_long_double_ptr(void*p) { printf(" as long double ptr %f\n", (double)*(long double*)p); } void print_float80_ptr(void*p) { printf(" as __float80 ptr %f\n", (double)*(__float80*)p); } void print_float128_ptr(void*p) { printf(" as __float128 ptr %f\n", (double)*(__float128*)p); } void print_double_value(double v) { printf(" as double %f\n", (double)v); } void print_long_double_value(long double v) { printf(" as long double %f\n", (double)v); } void print_float80_value(F80 v) { printf(" as __float80 %f\n", (double)v); } void print_float128_value(F128 v) { printf(" as __float128 %f\n", (double)v); } } D gd = 1.0; LD gld = 1.0L; F80 gf80 = 1.0L; F128 gf128 = 1.0L; extern "C" LD get_my_LD_as_LD(); extern "C" F80 get_my_LD_as_F80(); extern "C" F128 get_my_LD_as_F128(); void get_print_long_double() { printf("==== get and print my long double:\n"); print_long_double_value(get_my_LD_as_LD()); print_float80_value(get_my_LD_as_F80()); print_float128_value(get_my_LD_as_F128()); } int main() { extern void mytest(); printf("gcc x64 sizeof(double)=%zu\nsizeof(long double)=%zu\n" "sizeof(__float80)=%zu\nsizeof(__float128)=%zu\n", sizeof(D), sizeof(LD), sizeof(F80), sizeof(F128)); mytest(); get_print_long_double(); return 0; } $ clang++ -target x86_64-linux-android -c -o ./t.android.o ./t.cpp $ g++ -o dump.android.exe dump.cpp t.android.o $ dump.android.exe gcc x64 sizeof(double)=8 sizeof(long double)=16 sizeof(__float80)=16 sizeof(__float128)=16 my long double vs gcc long double: they are different my long double vs gcc __float80: they are different my long double vs gcc __float128: they are the same as double ptr 1.000000 as long double ptr 0.000000 as __float80 ptr 0.000000 as __float128 ptr 1.000000 ==== pass my long double to gcc x64 printer: as double 1.000000 as long double -nan as __float80 -nan as __float128 0.000000 ==== get and print my long double: as long double 0.000000 as __float80 0.000000 as __float128 0.000000 $ clang++ -target x86_64-linux-gnu -c -o ./t.gnu.o ./t.cpp $ g++ -o dump.gnu.exe dump.cpp t.gnu.o $ dump.gnu.exe gcc x64 sizeof(double)=8 sizeof(long double)=16 sizeof(__float80)=16 sizeof(__float128)=16 my long double vs gcc long double: they are the same my long double vs gcc __float80: they are the same my long double vs gcc __float128: they are different as double ptr 1.000000 as long double ptr 1.000000 as __float80 ptr 1.000000 as __float128 ptr 0.000000 ==== pass my long double to gcc x64 printer: as double 1.000000 as long double 1.000000 as __float80 1.000000 as __float128 0.000000 ==== get and print my long double: as long double 1.000000 as __float80 1.000000 as __float128 0.000000 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 19 13:12:33 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 19 Jun 2015 20:12:33 +0000 Subject: [LLVMbugs] [Bug 23898] New: (null) in diagnostic Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23898 Bug ID: 23898 Summary: (null) in diagnostic Product: clang Version: 3.6 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: alexandermbock at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified void f() { union { int a; }; class C { void g() { a = 5; } }; } clang says: error: reference to local variable (null) declared in enclosing function 'f' a = 5; ^ note: (null) declared here union { ^ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 19 14:58:03 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 19 Jun 2015 21:58:03 +0000 Subject: [LLVMbugs] [Bug 23899] New: -Wbraced-scalar-init should explain the ATOMIC_FLAG_INIT rule if applicable Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23899 Bug ID: 23899 Summary: -Wbraced-scalar-init should explain the ATOMIC_FLAG_INIT rule if applicable Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangbugs at nondot.org Reporter: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified -Wbraced-scalar-init will (correctly!) warn on the following code: class X { std::atomic_flag f; X() : f(ATOMIC_FLAG_INIT) {} // Invalid! X() : f{ATOMIC_FLAG_INIT} {} // Also invalid! }; because ATOMIC_FLAG_INIT is usually #define'd to {0}. Unfortunately, it doesn't explain why this is a problem. C++14 [atomics.flag]/4 states this: "The macro ATOMIC_FLAG_INIT shall be defined in such a way that it can be used to initialize an object of type atomic_flag to the clear state. The macro can be used in the form: "atomic_flag guard = ATOMIC_FLAG_INIT; "It is unspecified whether the macro can be used in other initialization contexts." The way to initialize the atomic flag is "std::atomic_flag f = ATOMIC_FLAG_INIT;". That exact syntax, only. Frankly, Wbraced-scalar-init picks this up by accident. A happy accident. But since we're here, we should detect the attempt to initialize a std::atomic_flag with ATOMIC_FLAG_INIT in any means except the one permitted syntax above. Tell the user that they need to use an in-class initializer, instead of complaining about extra braces. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 19 16:21:00 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 19 Jun 2015 23:21:00 +0000 Subject: [LLVMbugs] [Bug 23900] New: Regression(r240130): clang crashes when compiling file Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23900 Bug ID: 23900 Summary: Regression(r240130): clang crashes when compiling file Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: MC Assignee: unassignedbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified "C:\\src\\chrome\\src\\third_party\\llvm-build\\Release+Asserts\\bin\\clang.exe" "-cc1" "-triple" "x86_64-pc-windows-msvc18.0.0" "-emit-obj" "-mrelax-all" "-disable-free" "-main-file-name" "destructor_access_finalized_field.cpp" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-momit-leaf-frame-pointer" "-dwarf-column-info" "-Wno-inaccessible-base" "-std=c++11" "-fdeprecated-macro" "-ferror-limit" "19" "-fmessage-length" "0" "-mstackrealign" "-fms-extensions" "-fms-compatibility" "-fms-compatibility-version=18" "-fno-threadsafe-statics" "-fdelayed-template-parsing" "-fobjc-runtime=gcc" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" "-x" "c++" "destructor_access_finalized_field-ccb1f2.cpp" 0x000000014112D7A2 (0xFFFFFFFFFFFFFFFF 0xFFFFFFFFFFFFFFFF 0x0000000000000000 0x0000000000000000) 0x00000001411130E1 (0x000000000000001D 0x0000000000B19330 0x0000000002B00930 0x0000000140A7F4D1) 0x000000014110A00F (0x000000000000002F 0x0000000002B4A040 0x00000001424B7C84 0x0000000002B1B250) 0x00000001410B4408 (0x0000011D00620036 0x0000000000BF0430 0x0000000002B00AB8 0x0000000000000000) 0x00000001410B418C (0x0000000000000002 0x0000000000000020 0x0000000002B020B8 0x0000000140501E65) 0x00000001410B13E6 (0x0000000000000000 0x0000000002AF8880 0x0000000000B19330 0x00000000009CDA78) 0x000000014051F6A4 (0x0000000000000008 0x0000000002AF8880 0x00000000009CDA78 0x0000000002AF8860) 0x00000001408518FC (0x000000000000001A 0x0000000002B15CD0 0x00000000009CDA50 0x00000000009CDA80) 0x00000001409D8B44 (0x0000000142F9CAAC 0x0000000002B15CB0 0x0000000000000002 0x0000000002B15CB0) 0x00000001409D8DAB (0x0000000000B45310 0x00000001409D8F72 0x000000014298BBC0 0x0000000002AE51E0) 0x00000001409D93AD (0x0000000000000000 0x0000000000000028 0x0000015000950023 0x0000000000BF0430) 0x00000001412CBF15 (0x0000000000000000 0x00000001412C9692 0x0000000000000EB8 0x00000000009CE108) 0x00000001412C8E1C (0x00000000009CE1E0 0x0000000142C06486 0x0000000000000000 0x0000000000000000) 0x000000014182B4B3 (0x0000000100000009 0x0000000000B1B340 0x0000000000000001 0x0000000000000000) 0x0000000140FDB5FE (0x0000000000000008 0x0000000000B1B340 0x0000000000B1D458 0x0000000000000001) 0x0000000140FCC76D (0x0000000000000002 0x000000000000000C 0x0000000000000001 0x0000000000000000) 0x0000000141056D5F (0x0000000000AF0000 0x0000000142F89701 0x0000000000000000 0x0000000000B18D20) 0x000000013FC564B4 (0x000000000000002B 0x0000000000000089 0x0000000000B09730 0x0000000000B09740) 0x000000013FC548FE (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000) 0x00000001424B53C3 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000) 0x0000000076ED59CD (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), BaseThreadInitThunk() + 0xD bytes(s) 0x000000007710B981 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), RtlUserThreadStart() + 0x21 bytes(s) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 19 17:00:00 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 20 Jun 2015 00:00:00 +0000 Subject: [LLVMbugs] [Bug 23901] New: Crash on invalid on error suppressed by error-limit Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23901 Bug ID: 23901 Summary: Crash on invalid on error suppressed by error-limit Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: klimek at google.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified unknown_type foo(unknown_type); template class Bar {}; extern template class Bar; template class Bar; Commandline: clang -cc1 -fsyntax-only -std=c++11 -ferror-limit 1 s.ii Backtrace: clang: llvm/tools/clang/include/clang/AST/DeclCXX.h:592: struct DefinitionData &clang::CXXRecordDecl::data() const: Assertion `DD && "queried property of class with no definition"' failed. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 19 21:49:45 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 20 Jun 2015 04:49:45 +0000 Subject: [LLVMbugs] [Bug 23902] New: clang segfaults on undefined variable Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23902 Bug ID: 23902 Summary: clang segfaults on undefined variable Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: schopf.dan at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14498 --> https://llvm.org/bugs/attachment.cgi?id=14498&action=edit associated run script Compiling the following simple C program makes clang segfault: #include #include int main() { printf("%g", fabs(a)); return 0; } Declaring a solves the problem. # clang -v test.c clang version 3.7.0 (68aba8badebea3aee8c39002ac01fa12d978747e) (883d498abf4db0e059a1250147e07f4e9c47d9e3) Target: x86_64-pc-linux-gnu Thread model: posix Selected GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2 "/usr/bin/x86_64-pc-linux-gnu-clang-3.7" -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -v -dwarf-column-info -resource-dir /usr/bin/../lib/clang/3.7.0 -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.7.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir /home/daniel/workspace -ferror-limit 19 -fmessage-length 191 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-d1dd8d.o -x c test.c clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target x86_64-pc-linux-gnu ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/bin/../lib/clang/3.7.0/include /usr/include End of search list. x86_64-pc-linux-gnu-clang-3.7: error: unable to execute command: Segmentation fault x86_64-pc-linux-gnu-clang-3.7: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (68aba8badebea3aee8c39002ac01fa12d978747e) (883d498abf4db0e059a1250147e07f4e9c47d9e3) Target: x86_64-pc-linux-gnu Thread model: posix x86_64-pc-linux-gnu-clang-3.7: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. x86_64-pc-linux-gnu-clang-3.7: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: x86_64-pc-linux-gnu-clang-3.7: note: diagnostic msg: /tmp/test-252330.c x86_64-pc-linux-gnu-clang-3.7: note: diagnostic msg: /tmp/test-252330.sh x86_64-pc-linux-gnu-clang-3.7: note: diagnostic msg: ******************** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 19 23:46:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 20 Jun 2015 06:46:17 +0000 Subject: [LLVMbugs] [Bug 23903] New: GCC's -Wstrict-overflow not implemented Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23903 Bug ID: 23903 Summary: GCC's -Wstrict-overflow not implemented Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: chengniansun at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified $: cat t.c int main(int argc, char **argv) { if (argc + 3 < argc) return 0; else return 1; } $: clang-trunk -Weverything -Wno-unused-parameter -O3 t.c $: gcc-trunk -Wall -O3 t.c t.c: In function ¡®main¡¯: t.c:2:3: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow] if (argc + 3 < argc) ^ $: $: -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 20 07:33:09 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 20 Jun 2015 14:33:09 +0000 Subject: [LLVMbugs] [Bug 23904] New: Clang cannot deduce the template parameter when function parameter type is reference to array and template argument is braced-init-list Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23904 Bug ID: 23904 Summary: Clang cannot deduce the template parameter when function parameter type is reference to array and template argument is braced-init-list Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: boostcpp at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Clang cannot deduce the template parameter when function template's parameter type is reference to array and template argument is braced-init-list. void f( int (&&a)[3] ) { } template < typename T, std::size_t N > void g( T (&&a)[N] ) { } template < typename T, std::size_t N > void h( const T (&a)[N] ) { } int main() { // GCC and Clang accept it f( {1,2,3} ) ; // GCC accept it // Clang reject it // couldn't infer template argument 'T'(and 'N' too) g( {1,2,3} ) ; h( {1,2,3} ) ; } I think GCC is right on here so template parameters can be deduced. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 20 10:24:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 20 Jun 2015 17:24:10 +0000 Subject: [LLVMbugs] [Bug 10098] Should codegen to CVTDQ2PD etc but is scalarized In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=10098 Simon Pilgrim changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |llvm-dev at redking.me.uk Resolution|--- |FIXED --- Comment #2 from Simon Pilgrim --- The CVTDQ2PD scalarization issues were fixed in rL239855. The SEXT extension issues were fixed in rL237885. The ZEXT extension and CVTPD2PS truncation issue have been fixed for quite some time. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 20 12:05:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 20 Jun 2015 19:05:58 +0000 Subject: [LLVMbugs] [Bug 23905] New: incomplete type diagnostic Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23905 Bug ID: 23905 Summary: incomplete type diagnostic Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: prathamesh.kulkarni at linaro.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Hi, For the following case, clang gives error for struct but not for enum: extern struct foo s; extern enum bar b; int main() { (void) s; (void) b; } f1.c:9:10: error: incomplete type 'struct foo' where a complete type is required (void) s; ^ f1.c:1:8: note: forward declaration of 'struct foo' struct foo; ^ 1 error generated. Is this possibly a bug ? clang --version: Ubuntu clang version 3.6.0-2ubuntu1 (tags/RELEASE_360/final) (based on LLVM 3.6.0) Target: x86_64-pc-linux-gnu Thread model: posix Thank you, Prathamesh -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 20 15:53:43 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 20 Jun 2015 22:53:43 +0000 Subject: [LLVMbugs] [Bug 23906] New: clang compiles invalid multiple inheritance code Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23906 Bug ID: 23906 Summary: clang compiles invalid multiple inheritance code Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: ryan.burn at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified This fails to compile with gcc and EDG but compiles with clang: #include #include #include template class Pack { public: Pack(const Value& value) : _value(value) {} Value value() const { return _value; } private: Value _value; }; template decltype(auto) unpack(Tag, Pack& pack) { return pack.value(); } struct tag1 {}; struct tag2 {}; struct A3 : Pack, Pack { A3(int x, double y) : Pack(x), Pack(y) {} }; int main() { A3 a3(1, 2); assert(unpack(tag1(), a3) == 1); assert(unpack(tag2(), a3) == 2); } Per discussion on stackoverflow http://stackoverflow.com/questions/30814981/will-this-template-function-correctly-match-a-class-with-multiple-bases it looks like a compiler bug with clang -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 20 21:15:00 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 21 Jun 2015 04:15:00 +0000 Subject: [LLVMbugs] [Bug 23907] New: Assertion Failure: SelectionDAGBuilder.cpp Name "not null terminated" handling @llvm.framerecover Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23907 Bug ID: 23907 Summary: Assertion Failure: SelectionDAGBuilder.cpp Name "not null terminated" handling @llvm.framerecover Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: mitchell.wheeler at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Note: I'm not entirely sure what component is responsible for this bug, but if I had to guess I think it's a WinEH issue (which I understand is very much a work in progress, but I figure you guys are still interested in assertion failures) What: assert(Name.data()[Name.size()] == '\0' && "not null terminated"); Where: SelectionDAGBuilder.cpp:4982 When: Compiling libcxx for x86_64-pc-windows-msvc using clan trunk -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 21 09:37:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 21 Jun 2015 16:37:31 +0000 Subject: [LLVMbugs] [Bug 23584] noexcept in destructor of class with anonymous union causes crash In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23584 Davide Italiano changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |davide at freebsd.org Resolution|--- |FIXED --- Comment #6 from Davide Italiano --- r240242 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 21 10:06:20 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 21 Jun 2015 17:06:20 +0000 Subject: [LLVMbugs] [Bug 23908] New: Consider emitting all variables in collectVariableInfo(), even ones with no ranges Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23908 Bug ID: 23908 Summary: Consider emitting all variables in collectVariableInfo(), even ones with no ranges Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedbugs at nondot.org Reporter: dexonsmith at apple.com CC: aprantl at apple.com, dblaikie at gmail.com, llvmbugs at cs.uiuc.edu Classification: Unclassified If a variable in `DbgValues` has no ranges, we currently don't emit it. In the review thread leading to r240244, David and Adrian suggested that we should emit it anyway. As an example of why, consider: int foo(int f) { if (bar()) { bool f = false; // ... } // ... } If the local variable `f` is optimized out, the debugger should still "know" about it. Otherwise, evaluating `expression f` when stepping through the `if` statement will refer to the parameter. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 21 18:36:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 01:36:47 +0000 Subject: [LLVMbugs] [Bug 23909] New: Inefficient encoding with llc -filetype=obj Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23909 Bug ID: 23909 Summary: Inefficient encoding with llc -filetype=obj Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, rnk at google.com Classification: Unclassified ---------------------------------------------- target triple = "x86_64-pc-windows-msvc18.0.0" define void @f(i32 %x) personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to i8*) { invoke void @h() to label %invoke.cont unwind label %lpad invoke.cont: ret void lpad: landingpad { i8*, i32 } cleanup call void @g(i32 %x) ret void } declare void @h() declare i32 @__CxxFrameHandler3(...) declare void @g(i32 %x) ------------------------------------------- Going directly to a .o produces f.cleanup: .... 29: 8b 8a 34 00 00 00 movl 52(%rdx), %ec Going via assembly produces f.cleanup: .... 29: 8b 4a 34 movl 52(%rdx), %ecx -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 21 20:48:48 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 03:48:48 +0000 Subject: [LLVMbugs] [Bug 23910] New: clang dpesm Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23910 Bug ID: 23910 Summary: clang dpesm Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: davide at freebsd.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 03:47:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 10:47:49 +0000 Subject: [LLVMbugs] [Bug 23372] COFF Global Variable failing In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23372 Manoel Teixeira changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from Manoel Teixeira --- Sorry, it was my fault. I have emitted incorrectly part of the code. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 07:23:15 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 14:23:15 +0000 Subject: [LLVMbugs] [Bug 21341] Segmentation fault in std::string on revision 217082 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21341 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #7 from Marshall Clow (home) --- > I think that's just an ODR violation. Since you have two different definitions of std::vector in your program, you get undefined behavior. I don't think this is a bug in libc++. Closing. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 07:25:23 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 14:25:23 +0000 Subject: [LLVMbugs] [Bug 17980] Container support In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17980 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Marshall Clow (home) --- This has gone through the standardization process (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4510), and all the containers mentioned in that paper have had "incomplete type" support added. We're not going to do deque. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 07:54:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 14:54:36 +0000 Subject: [LLVMbugs] [Bug 23911] New: Clang performs extra initialization of memcpy-able struct member Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23911 Bug ID: 23911 Summary: Clang performs extra initialization of memcpy-able struct member Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: d.zobnin.bugzilla at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14502 --> https://llvm.org/bugs/attachment.cgi?id=14502&action=edit Generated IR code When compiling the following test: int glob = 0; struct A { int x; A() { x = 10; } }; struct B { B() { glob = 15; } B(const B &other) { glob = 25; } }; struct C { A a; // memcpy-able member B b; // non-trivial copy initialization }; int main() { C c1; C c2(c1); return 0; } Clang generates the following code for copy-constructor of C: $ clang -cc1 -O0 test.cpp -emit-llvm -o - ; Function Attrs: inlinehint nounwind define linkonce_odr void @_ZN1CC2ERKS_(%struct.C* %this, %struct.C* dereferenceable(8)) unnamed_addr #1 com dat align 2 { entry: %this.addr = alloca %struct.C*, align 8 %.addr = alloca %struct.C*, align 8 store %struct.C* %this, %struct.C** %this.addr, align 8 store %struct.C* %0, %struct.C** %.addr, align 8 %this1 = load %struct.C*, %struct.C** %this.addr %a = getelementptr inbounds %struct.C, %struct.C* %this1, i32 0, i32 0 %1 = load %struct.C*, %struct.C** %.addr, align 8 %a2 = getelementptr inbounds %struct.C, %struct.C* %1, i32 0, i32 0 %2 = bitcast %struct.A* %a to i8* %3 = bitcast %struct.A* %a2 to i8* call void @llvm.memcpy.p0i8.p0i8.i64(i8* %2, i8* %3, i64 4, i32 4, i1 false) %b = getelementptr inbounds %struct.C, %struct.C* %this1, i32 0, i32 1 %4 = load %struct.C*, %struct.C** %.addr, align 8 %b3 = getelementptr inbounds %struct.C, %struct.C* %4, i32 0, i32 1 call void @_ZN1BC1ERKS_(%struct.B* %b, %struct.B* dereferenceable(1) %b3) %a4 = getelementptr inbounds %struct.C, %struct.C* %this1, i32 0, i32 0 %5 = load %struct.C*, %struct.C** %.addr, align 8 %a5 = getelementptr inbounds %struct.C, %struct.C* %5, i32 0, i32 0 %6 = bitcast %struct.A* %a4 to i8* %7 = bitcast %struct.A* %a5 to i8* call void @llvm.memcpy.p0i8.p0i8.i64(i8* %6, i8* %7, i64 4, i32 4, i1 false) ret void } As you can see, there's an extra initialization of memcpy-able member C.a. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 08:12:11 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 15:12:11 +0000 Subject: [LLVMbugs] [Bug 21361] ostream::seekp() not standard-compliant In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21361 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marshall Clow (home) --- Fixed in revision 240286. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 08:20:32 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 15:20:32 +0000 Subject: [LLVMbugs] [Bug 12027] std::map::erase(iterator) is ambiguous if S has a template constructor In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=12027 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marshall Clow (home) --- This was fixed when we implemented LWG2059 (adopted in Lenexa) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 08:22:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 15:22:05 +0000 Subject: [LLVMbugs] [Bug 10193] std::stringbuf performance vs libstdc++ In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=10193 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Marshall Clow (home) --- Marking this as "closed", since we're much better than we used to be. If you think there's still a significant performance delta, please reopen this bug. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 08:44:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 15:44:51 +0000 Subject: [LLVMbugs] [Bug 23453] test/tools/gold/slp-vectorize.ll fails on i686 hosts In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23453 Rafael Ávila de Espíndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Rafael Ávila de Espíndola --- Should be fixed by r240289. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 08:53:03 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 15:53:03 +0000 Subject: [LLVMbugs] [Bug 22907] libc++ fails to build with error: "Random device not implemented for this architecture" In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22907 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #14 from Marshall Clow (home) --- Three months with no response. Please re-open this bug if the problem reappears. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 09:02:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 16:02:58 +0000 Subject: [LLVMbugs] [Bug 19153] Some iterators non-standard In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=19153 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Marshall Clow (home) --- LWG 2438, which does not mandate inheritance, was adopted in Lenexa. Closing this bug as "wontfix" - because the iterators are no longer non-standard. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 10:54:11 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 17:54:11 +0000 Subject: [LLVMbugs] [Bug 23900] Regression(r240130): clang crashes when compiling file In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23900 Rafael Ávila de Espíndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Rafael Ávila de Espíndola --- Fixed in r240300. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 12:08:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 19:08:17 +0000 Subject: [LLVMbugs] [Bug 23912] New: Handling of ARM Errata 602117 (and testcase) is broken Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23912 Bug ID: 23912 Summary: Handling of ARM Errata 602117 (and testcase) is broken Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: ARM Assignee: unassignedbugs at nondot.org Reporter: matze at braunis.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified While working on the ARMLoadStoreOptimizer code I realized that the handling of Cortex-M3 Errata 602117 and the llvm-lit test that checks for it are faulty. If you use the following test instead, you still see an invalid ldrd created, even with -mcpu=cortex-m3. ; we call the following two to force values into specific registers. declare i64* @get_ptr() declare void @use_i64(i64 %v) define void @test_ldrd(i64 %a) nounwind readonly { %ptr = call i64* @get_ptr() %v = load i64, i64* %ptr, align 8 call void @use_i64(i64 %v) ret void } Results in: ... bl _get_ptr ldrd r0, r1, [r0] bl _use_i64 ... -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 13:04:12 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 20:04:12 +0000 Subject: [LLVMbugs] [Bug 23913] New: Use lld for stage 2 Clang build Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23913 Bug ID: 23913 Summary: Use lld for stage 2 Clang build Product: lld Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedbugs at nondot.org Reporter: eugene.zelenko at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I think will be good idea to be able to use lld as linker for stage 2 Clang build. In addition to archive goal as alternative to system linker, such builds will good test for lld. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 13:52:25 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 20:52:25 +0000 Subject: [LLVMbugs] [Bug 23349] [SSE] scalar intrinsics don't fold loads In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23349 Ahmed Bougacha changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ahmed Bougacha --- r240326. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 15:33:04 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 22:33:04 +0000 Subject: [LLVMbugs] [Bug 23914] New: Long .symver directives generate symbols with empty names Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23914 Bug ID: 23914 Summary: Long .symver directives generate symbols with empty names Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: MC Assignee: unassignedbugs at nondot.org Reporter: eugeni.stepanov at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified $ cat 1.cc int x = 0; asm (".symver " "x" "," "aaaaaaaaaaaaaaaaaa" "@@@" "AAAAAAAAAAAAA"); $ clang++ -c 1.cc && objdump 1.o 1.o: file format elf64-x86-64 SYMBOL TABLE: 0000000000000000 l df *ABS* 0000000000000000 1.cc 0000000000000000 g O .bss 0000000000000004 $ /code/llvm/build/bin/clang++ -c 1.cc -fno-integrated-as && objdump -t 1.o 1.o: file format elf64-x86-64 SYMBOL TABLE: 0000000000000000 l df *ABS* 0000000000000000 1.cc 0000000000000000 l d .text 0000000000000000 .text 0000000000000000 l d .data 0000000000000000 .data 0000000000000000 l d .bss 0000000000000000 .bss 0000000000000000 l d .note.GNU-stack 0000000000000000 .note.GNU-stack 0000000000000000 l d .comment 0000000000000000 .comment 0000000000000000 g O .bss 0000000000000004 aaaaaaaaaaaaaaaaaa@@AAAAAAAAAAAAA Remove any character from "aaa..aa" or "AA...AA" and we are back to the correct behavior. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 15:39:18 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 22:39:18 +0000 Subject: [LLVMbugs] [Bug 23915] New: __bases and __direct_bases intrinsics are not supported (N2965) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23915 Bug ID: 23915 Summary: __bases and __direct_bases intrinsics are not supported (N2965) Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: alexfrolov1878 at yandex.ru CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Clang cannot compile GCC header tr2/type_traits (see below). Type traits "bases" and "direct_bases" were proposed as N2965 for C++11 standard, but were not included. The feature is well-documented (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2965.html) and is supported by GCC. There are some questions and requests regarding this feature on developer forums (for example, http://stackoverflow.com/questions/18435001/what-is-the-status-of-n2965-stdbases-and-stddirect-bases). $ clang --version clang version 3.7.0 (trunk) Target: x86_64-unknown-linux-gnu Thread model: posix $ cat test.cpp #include $ clang -std=c++11 -c test.cpp In file included from test.cpp:1: /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/tr2/type_traits:90:45: error: '_Tp' does not refer to a value typedef __reflection_typelist<__bases(_Tp)...> type; ^ /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/tr2/type_traits:87:21: note: declared here template ^ /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/tr2/type_traits:97:52: error: '_Tp' does not refer to a value typedef __reflection_typelist<__direct_bases(_Tp)...> type; ^ /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/tr2/type_traits:94:21: note: declared here template ^ 2 errors generated. As you can see, Clang does not support __bases and __direct_bases intrinsics. Alexey Frolov ============= Software Engineer Intel Compiler Team Intel -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 16:15:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 23:15:51 +0000 Subject: [LLVMbugs] [Bug 23916] New: Clang doesn't like 'void inline'. Regression wrt. gcc Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23916 Bug ID: 23916 Summary: Clang doesn't like 'void inline'. Regression wrt. gcc Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: wkoszek at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14504 --> https://llvm.org/bugs/attachment.cgi?id=14504&action=edit Sample.c code mentioned in the bug case Our codebase used 'void inline' variable, and it seems like Clang doesn't like it. ----------------------- sample.c --------------------------------- #include #ifdef FIX #define PREFIX static #else #define PREFIX #endif struct stats { int pkt; }; typedef struct stats stats_t; PREFIX void inline recv_stats(stats_t* stats, void *p) { stats->pkt++; } int main() { stats_t stats; recv_stats(&stats, 0); } -------------------------------------------------------------------- vm:~/vr/accelerator% cc -v Using built-in specs. COLLECT_GCC=cc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) vm:~/vr/accelerator% cc sample.c -o sample vm:~/vr/accelerator% cc -DFIX sample.c -o sample.fix vm:~/vr/accelerator% ls -la sample sample.fix -rwxrwxr-x 1 wkoszek wkoszek 8497 Jun 22 16:10 sample -rwxrwxr-x 1 wkoszek wkoszek 8497 Jun 22 16:10 sample.fix vm:~/vr/accelerator% clang sample.c -o sample /tmp/sample-b5c729.o: In function `main': sample.c:(.text+0x17): undefined reference to `recv_stats' clang: error: linker command failed with exit code 1 (use -v to see invocation) vm:~/vr/accelerator% clang -DFIX sample.c -o sample This leads to: vm:~/vr/accelerator% cc -c -o sample-cc.o sample.c vm:~/vr/accelerator% clang -c -o sample-clang.o sample.c vm:~/vr/accelerator% nm sample-cc.o 000000000000001d T main 0000000000000000 T recv_stats vm:~/vr/accelerator% nm sample-clang.o 0000000000000000 T main U recv_stats Conclusion: if a function is "void inline", GCC compiled the function OK and put it in the .text section. Clang compiles the code OK, but puts the code in unknown section. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 16:36:25 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 22 Jun 2015 23:36:25 +0000 Subject: [LLVMbugs] [Bug 23914] Long .symver directives generate symbols with empty names In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23914 Evgeniy Stepanov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Evgeniy Stepanov --- Fixed in r240357. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 22:37:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 05:37:36 +0000 Subject: [LLVMbugs] [Bug 23851] metadata on branch not preserved with loop unswitch In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23851 Weiming Zhao changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Weiming Zhao --- r240378 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 23:52:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 06:52:17 +0000 Subject: [LLVMbugs] [Bug 23920] New: Phabricator should have an Herald rule to add llvm-commits Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23920 Bug ID: 23920 Summary: Phabricator should have an Herald rule to add llvm-commits Product: Website Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Phabricator Assignee: unassignedbugs at nondot.org Reporter: deadalnix at gmail.com CC: klimek at google.com, llvmbugs at cs.uiuc.edu Classification: Unclassified The fact that llvm-commits needs to be added manually and diff discarded when it is forgoten is kind of ridiculous. It can be automated easily by someone with phab admin rights. Go to herald and create a new rule (http://reviews.llvm.org/herald/new/) Choose Differential Diffs. Choose Global. - Condition always (or llvm-commits not subscribed if one want to play nice). - Add subscriber: llvm-commits This will avoid a lot of mess up with phabricator. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 22 23:54:38 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 06:54:38 +0000 Subject: [LLVMbugs] [Bug 23921] New: Phabricator had a bad time with this patch that renamed some files. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23921 Bug ID: 23921 Summary: Phabricator had a bad time with this patch that renamed some files. Product: Website Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Phabricator Assignee: unassignedbugs at nondot.org Reporter: llvm-bugs at justinbogner.com CC: klimek at google.com, llvmbugs at cs.uiuc.edu Classification: Unclassified The following patch from phabricator isn't even close to something that could apply: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150622/283256.html It modifies files that didn't exist, and it completely lacks the removal of the file that was moved. You can see what the patch was actually trying to do in the review and in the mailing list followup that included the patch directly: http://reviews.llvm.org/D10636 http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20150622/8ef2382a/attachment.obj -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 00:31:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 07:31:51 +0000 Subject: [LLVMbugs] [Bug 23878] [ms] virtual member pointer call gets miscompiled In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23878 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com |org | --- Comment #4 from David Majnemer --- Fixed in r240384. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 03:25:14 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 10:25:14 +0000 Subject: [LLVMbugs] [Bug 23922] New: GVN incorrectly propagates exact attribute Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23922 Bug ID: 23922 Summary: GVN incorrectly propagates exact attribute Product: libraries Version: trunk Hardware: All OS: All Status: NEW Keywords: miscompilation Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: nunoplopes at sapo.pt CC: david.majnemer at gmail.com, llvmbugs at cs.uiuc.edu, regehr at cs.utah.edu Classification: Unclassified $ cat bug.ll define i2 @func16731728(i2, i1, i4, i2, i1, i4, i2, i1, i4, i2, i1, i4) { %13 = sdiv exact i2 %0, -2 %14 = sdiv i2 %0, -2 %15 = select i1 %1, i2 %13, i2 %14 ret i2 %15 } $ opt -gvn -S bug.ll define i2 @func16731728(i2, i1, i4, i2, i1, i4, i2, i1, i4, i2, i1, i4) { %13 = sdiv exact i2 %0, -2 ret i2 %13 } This is wrong if we assume that select only propagates poison/undef through the dynamically chosen value (which I believe is the current interpretation of how select works). $ ./alive.py gvn.opt ---------------------------------------- Optimization: func16731728 Precondition: true %13 = sdiv exact i2 %0, -2 %14 = sdiv i2 %0, -2 %15 = select i1 %1, i2 %13, i2 %14 => %15 = sdiv exact i2 %0, -2 ERROR: Domain of undefinedness of Target is smaller than Source's for i2 %15 Example: %0 i2 = 0x3 (3, -1) %1 i1 = 0x0 (0) %13 i2 = 0x0 (0) %14 i2 = 0x0 (0) Source value: 0x0 (0) Target value: undef -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 03:45:01 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 10:45:01 +0000 Subject: [LLVMbugs] [Bug 23923] New: "redefine_extname" pragma handled incorrectly in case of a local var with the same name Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23923 Bug ID: 23923 Summary: "redefine_extname" pragma handled incorrectly in case of a local var with the same name Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: andreybokhanko at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This bug report captures what Richard Smith wrote in a code review message (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150608/130447.html): > We should also filter out internal-linkage declarations and non-TU-scope > declarations when we perform the deferred handling of > `ExtnameUndeclaredIdentifiers` in `ActOnVariableDeclarator` and > `ActOnFunctionDeclarator`. ... > Here's a trivial testcase (it's easy to cook up more, the bug is quite blatant): > > #pragma redefine_extname foo bar > int f() { > int foo = 0; > return foo; > } > int foo() { return 1; } > > The redefine_extname gets applied to the local variable 'foo', and the > global function 'foo' does not get renamed. Yours, Andrey Bokhanko =============== Software Engineer Intel Compiler Team Intel -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 04:10:02 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 11:10:02 +0000 Subject: [LLVMbugs] [Bug 23924] New: Clang exception handling: wrong IR generation for aggregated members' destructors calls during stack unwinding Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23924 Bug ID: 23924 Summary: Clang exception handling: wrong IR generation for aggregated members' destructors calls during stack unwinding Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: d.zobnin.bugzilla at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14508 --> https://llvm.org/bugs/attachment.cgi?id=14508&action=edit Generated IR code When compiling the following test: struct A { int x; A() { x = 10; } ~A() { x = 20; } }; struct B { int y; B() { y = 15; } B(const B &other) { y = 25; throw 1; } }; struct C { int z; // memcpy-able member A a; // memcpy-able member B b; // explicit copy ctor }; int main() { try { C c1; C c2(c1); } catch (...) { return 1; } return 0; } Clang generates the following code for copy-constructor of C: $ clang -cc1 -fexceptions -fcxx-exceptions -O0 test.cpp -emit-llvm -o test.ll ; Function Attrs: inlinehint define linkonce_odr void @_ZN1CC2ERKS_(%struct.C* %this, %struct.C* dereferenceable(12)) unnamed_addr #1 comdat align 2 personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) { entry: %this.addr = alloca %struct.C*, align 8 %.addr = alloca %struct.C*, align 8 %exn.slot = alloca i8* %ehselector.slot = alloca i32 store %struct.C* %this, %struct.C** %this.addr, align 8 store %struct.C* %0, %struct.C** %.addr, align 8 %this1 = load %struct.C*, %struct.C** %this.addr %z = getelementptr inbounds %struct.C, %struct.C* %this1, i32 0, i32 0 %1 = load %struct.C*, %struct.C** %.addr %z2 = getelementptr inbounds %struct.C, %struct.C* %1, i32 0, i32 0 %2 = bitcast i32* %z to i8* %3 = bitcast i32* %z2 to i8* call void @llvm.memcpy.p0i8.p0i8.i64(i8* %2, i8* %3, i64 8, i32 4, i1 false) %b = getelementptr inbounds %struct.C, %struct.C* %this1, i32 0, i32 2 %4 = load %struct.C*, %struct.C** %.addr, align 8 %b3 = getelementptr inbounds %struct.C, %struct.C* %4, i32 0, i32 2 invoke void @_ZN1BC1ERKS_(%struct.B* %b, %struct.B* dereferenceable(4) %b3) to label %invoke.cont unwind label %lpad invoke.cont: ; preds = %entry ret void lpad: ; preds = %entry %5 = landingpad { i8*, i32 } cleanup %6 = extractvalue { i8*, i32 } %5, 0 store i8* %6, i8** %exn.slot %7 = extractvalue { i8*, i32 } %5, 1 store i32 %7, i32* %ehselector.slot %8 = bitcast %struct.C* %this1 to %struct.A* invoke void @_ZN1AD1Ev(%struct.A* %8) to label %invoke.cont.4 unwind label %terminate.lpad invoke.cont.4: ; preds = %lpad br label %eh.resume eh.resume: ; preds = %invoke.cont.4 %exn = load i8*, i8** %exn.slot %sel = load i32, i32* %ehselector.slot %lpad.val = insertvalue { i8*, i32 } undef, i8* %exn, 0 %lpad.val.5 = insertvalue { i8*, i32 } %lpad.val, i32 %sel, 1 resume { i8*, i32 } %lpad.val.5 terminate.lpad: ; preds = %lpad %9 = landingpad { i8*, i32 } catch i8* null %10 = extractvalue { i8*, i32 } %9, 0 call void @__clang_call_terminate(i8* %10) #5 unreachable } As you can see, there's an instruction in %lpad block "%8 = bitcast %struct.C* %this1 to %struct.A*", which prepares the address of member C.a to call its destructor and is incorrect, because I believe it must be a "getelementptr inbounds" instruction for this purpose. I will handle this case. Denis Zobnin ============= Software Engineer Intel Compiler Team Intel -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 04:21:35 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 11:21:35 +0000 Subject: [LLVMbugs] [Bug 23925] New: InstAlias instructions are not printed if the orig instruction has duplicated operands Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23925 Bug ID: 23925 Summary: InstAlias instructions are not printed if the orig instruction has duplicated operands Product: tools Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: TableGen Assignee: unassignedbugs at nondot.org Reporter: dylanmckay34 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified In a backend I maintain, there are several instructions which take two operands - a source1/destination register, and another source register. For example, `MUL Rd, Rr` => `Rd = Rd * Rr` This is implemented by have three operands in the source, but with 'let Constraints = "$src1 = $dst". * `tst Rd` maps to `and Rd, Rd` * `clr Rd` maps to `eor Rd, Rd` * `ser Rd` maps to `ldi Rd, 0xff` The first two instructions, when printed, are not written as `tst Rd` or `clr Rd` - they are printed as `and Rd, Rd` and `eor Rd, Rd`. The last instruction correctly maps to `ser Rd` when printed. It appears that instruction aliases with repeated operands in the patterns do not work correctly with regards to the instruction printer. A brief debugging shows that inside `printAliasInstr` in `AVRGenAsmWriter.inc` (generated by TableGen) checks if the `MCInst` has `2` operands (presumably a brief sanity check), before it checks whether the instruction corresponds to `tst` or `clr` - however, the instruction always contains `3` operands - `Rd` repeated three times, causing the conditional to never be true, and the alias to not be printed. In `utils/TableGen`, the `CodeGenInstAlias` class holds information about an alias - the string pattern, the instruction that is being aliased, and the arguments to the instruction. TableGen isn't adding duplicate operands from the `CodeGenInstruction Result` into the `ResultOperands` field in the `CodeGenInstAlias` if it is a duplicate. The bug also exists on the issue tracker for AVR-LLVM here (https://github.com/avr-llvm/llvm/issues/89). Because of this bug, we can parse the aliases, but we must write the fully qualified, non aliases instruction in our tests. It also makes the generated assembly a little bit less readable. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 05:13:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 12:13:58 +0000 Subject: [LLVMbugs] [Bug 23926] New: Reassociate wrongly preserves nuw Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23926 Bug ID: 23926 Summary: Reassociate wrongly preserves nuw Product: libraries Version: trunk Hardware: All OS: All Status: NEW Keywords: miscompilation Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: nunoplopes at sapo.pt CC: david.majnemer at gmail.com, llvmbugs at cs.uiuc.edu, regehr at cs.utah.edu Classification: Unclassified $ cat bug.ll define i2 @func78000101(i2, i2) { %3 = add nuw i2 %0, 1 %4 = sub nuw nsw i2 %1, %3 ret i2 %4 } $ opt -reassociate -S bug.ll define i2 @func78000101(i2, i2) { %.neg = sub i2 0, %0 %.neg1 = add nuw i2 %.neg, -1 %3 = add i2 %.neg1, %1 ret i2 %3 } $ ./alive.py bug.opt ---------------------------------------- Optimization: func78000101 Precondition: true %3 = add nuw i2 %0, 1 %4 = sub nuw nsw i2 %1, %3 ret i2 %4 => %.neg = sub i2 0, %0 %.neg1 = add nuw i2 %.neg, -1 %3 = add i2 %.neg1, %1 ret i2 %3 ERROR: Domain of undefinedness of Target is smaller than Source's for i2 %3 Example: %0 i2 = 0x2 (2, -2) %1 i2 = 0x0 (0) %.neg i2 = 0x2 (2, -2) %.neg1 i2 = 0x1 (1) Undef inputs: %1 Source value: 0x3 (3, -1) Target value: undef -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 07:04:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 14:04:26 +0000 Subject: [LLVMbugs] [Bug 23927] New: CodeGenModule::EmitTargetMetadata() is redundant on all targets but xcore Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23927 Bug ID: 23927 Summary: CodeGenModule::EmitTargetMetadata() is redundant on all targets but xcore Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: yaron.keren at gmail.com CC: llvmbugs at cs.uiuc.edu, richard-llvm at metafoo.co.uk Classification: Unclassified The loop in EmitTargetMetadata introduced in r212263 iterates over all MangledDeclNames (the module may have 1000s of them), for every one performing a lookup in the module symbol table and then calling emitTargetMD() which is a no-op on all targets but xcore. Hopefully all of this optimizes out in release builds. In Debug builds the code is still there, slowing down every run as EmitTargetMetadata is always called by CodeGenModule::Release(). This xcore-specific functionality should probably move into xcore target rather than living in CodeGenModule. At the very least it should bail out early if target != xcore and skip the loop. I don't know if this is wrong: EmitDeclMetadata() is called if (getCodeGenOpts().EmitDeclMetadata) but EmitTargetMetadata() is always called regardless the flag. In addition, MangledDeclNames was modified from a DenseMap into a MapVector, a heavier and slower data structure. If the code is decoupled into xmos target maybe MangledDeclNames could be DenseMap again. Finally, this code does not appear to be covered by regression tests at all. If the whole function is #if 0 *and* MangledDeclNames is DenseMap, regression tests pass, at least on Windows and Linux. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 08:07:19 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 15:07:19 +0000 Subject: [LLVMbugs] [Bug 23916] Clang doesn't like 'void inline'. Regression wrt. gcc In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23916 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dimitry at andric.com Resolution|--- |INVALID --- Comment #6 from Dimitry Andric --- This is normal C99 behaviour, please refer to: http://clang.llvm.org/compatibility.html#inline Executive summary: in C, use 'static inline' or 'extern inline', never just 'inline'. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 10:14:32 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 17:14:32 +0000 Subject: [LLVMbugs] [Bug 23928] New: "NATIVE" fails to tidy up w/ "ninja clean" Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23928 Bug ID: 23928 Summary: "NATIVE" fails to tidy up w/ "ninja clean" Product: Build scripts Version: trunk Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: grosbach at apple.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified grosbaj at enkidu ~/s/build-llvm> ninja clean [1/1] Cleaning all built files... FAILED: /Users/grosbaj/bin/ninja -t clean ninja: error: remove(NATIVE): Directory not empty Cleaning... 2902 files. ninja: build stopped: subcommand failed.1 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 10:41:28 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 17:41:28 +0000 Subject: [LLVMbugs] [Bug 23929] New: Code completion for macros broken when modules enabled Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23929 Bug ID: 23929 Summary: Code completion for macros broken when modules enabled Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Modules Assignee: unassignedclangbugs at nondot.org Reporter: jordan_rose at apple.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14510 --> https://llvm.org/bugs/attachment.cgi?id=14510&action=edit lit-style test case The new logic for macros in modules breaks code completion, because Preprocessor::macro_begin/_end no longer covers all visible macros. See the attached test case. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 11:43:46 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 18:43:46 +0000 Subject: [LLVMbugs] [Bug 23740] dependent expr created by delayed typo correction leads to crash In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23740 Kaelyn Takata changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs at nondot. |rikka at google.com |org | --- Comment #1 from Kaelyn Takata --- It should be noted that the crash is when compiling the code a C; as C++ there is no crash. The crash has been fixed in r240441. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 12:13:54 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 19:13:54 +0000 Subject: [LLVMbugs] [Bug 23775] Segfault when using wrong macros in printf In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23775 Kaelyn Takata changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs at nondot. |rikka at google.com |org | --- Comment #4 from Kaelyn Takata --- The crash was indeed related to typo correction, and has been fixed in r240443. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 13:18:14 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 20:18:14 +0000 Subject: [LLVMbugs] [Bug 23930] New: llvm-nm shows more symbols than nm Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23930 Bug ID: 23930 Summary: llvm-nm shows more symbols than nm Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified On ARM: $ cat test.s .section .foobar,"",%progbits .asciz "foo" $ llvm-mc test.s -o test.o -filetype=obj -triple=armv7-pc-linux $ llvm-nm test.o 00000000 ? $d.0 $ nm test.o -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 13:50:28 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 20:50:28 +0000 Subject: [LLVMbugs] [Bug 23931] New: Clang allows a virtual member function inside a union Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23931 Bug ID: 23931 Summary: Clang allows a virtual member function inside a union Product: clang Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: andrey.vul at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified >From [class.union]p2: "A union can have member functions (including constructors and destructors), but not virtual (10.3) functions." The source in question compiles when a failure diagnostic is warranted. ### SOURCE: u.cc union A { virtual void f(); }; ### INVOCATION: clang++ -std=c++11 -c -v u.cc clang version 3.7.0 (trunk 239822) Target: powerpc64le-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/powerpc64le-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/powerpc64le-linux-gnu/4.8.2 Found candidate GCC installation: /usr/lib/gcc/powerpc64le-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/powerpc64le-linux-gnu/4.9.1 Selected GCC installation: /usr/lib/gcc/powerpc64le-linux-gnu/4.8 Candidate multilib: .;@m64 Selected multilib: .;@m64 "/home/andrey/clang.trunk/bin/clang-3.7" -cc1 -triple powerpc64le-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name u.cc -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu ppc64le -target-abi elfv2 -v -dwarf-column-info -coverage-file /tmp/u.cc -resource-dir /home/andrey/clang.trunk/bin/../lib/clang/3.7.0 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/c++/4.8 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/powerpc64le-linux-gnu/c++/4.8 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/powerpc64le-linux-gnu/c++/4.8 -internal-isystem /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/c++/4.8/backward -internal-isystem /usr/local/include -internal-isystem /home/andrey/clang.trunk/bin/../lib/clang/3.7.0/include -internal-externc-isystem /usr/include/powerpc64le-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 0 -mstackrealign -fno-signed-char -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o u.o -x c++ u.cc clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target powerpc64le-unknown-linux-gnu ignoring nonexistent directory "/include" ignoring duplicate directory "/usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/powerpc64le-linux-gnu/c++/4.8" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/c++/4.8 /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/powerpc64le-linux-gnu/c++/4.8 /usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/c++/4.8/backward /usr/local/include /home/andrey/clang.trunk/bin/../lib/clang/3.7.0/include /usr/include/powerpc64le-linux-gnu /usr/include End of search list. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 14:11:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 21:11:52 +0000 Subject: [LLVMbugs] [Bug 22560] fatal error: error in backend: Cannot select: intrinsic %llvm.arm.mcr In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22560 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Bob Wilson --- Fixed in clang svn r240462, with a follow-up fix in r240463 to improve the error handling for this. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 14:58:11 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 21:58:11 +0000 Subject: [LLVMbugs] [Bug 21004] __ldrexd in builtinsARM.def is incorrect In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21004 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bob.wilson at apple.com Resolution|--- |FIXED --- Comment #1 from Bob Wilson --- This was fixed in r228678 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 16:53:09 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 23 Jun 2015 23:53:09 +0000 Subject: [LLVMbugs] [Bug 23932] New: Assertion failed: ((!Initializer || isa(Initializer) || isa(Initializer)) && "Initializer expression that cannot have been implicitly created."), function BuildCXXNew Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23932 Bug ID: 23932 Summary: Assertion failed: ((!Initializer || isa(Initializer) || isa(Initializer)) && "Initializer expression that cannot have been implicitly created."), function BuildCXXNew Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: compnerd at compnerd.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Reduced test case: // %clang_cc1 -emit-obj -fobjc-arc -Os -x objective-c++ %s // REQUIRES: asserts template const id *f() { return new id; } auto i = f(); // template const id *f() { new id[32]; return nullptr; } With ARC, id needs to be value initialized. The TreeTransform over the template specialization will transform the ImplicitValueInitExpr into a ParenListExpr, which breaks the initialization type check in BuildCXXNew. The commented out test case is relevant as the single id case can be handled by adding parenthesis to avoid setup the DirectInitRange value, while the same workaround cannot be applied to the second case. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 17:09:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 00:09:56 +0000 Subject: [LLVMbugs] [Bug 23886] broadcast of i64 generates broadcast of v2i64 (vbroadcasti128) In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23886 Ahmed Bougacha changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedbugs at nondot.org |ahmed.bougacha at gmail.com --- Comment #2 from Ahmed Bougacha --- Disabled the pattern in r240488. As for actually matching the instruction, let's see how the intrinsic-vs-native discussion plays out. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 17:29:27 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 00:29:27 +0000 Subject: [LLVMbugs] [Bug 21764] package scan-build with compiler In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21764 Eugene Zelenko changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |eugene.zelenko at gmail.com Resolution|--- |DUPLICATE --- Comment #3 from Eugene Zelenko --- I'm marking as duplicate for my newer report because I have there CMake files which work for Linux. *** This bug has been marked as a duplicate of bug 23761 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 23 19:11:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 02:11:52 +0000 Subject: [LLVMbugs] [Bug 23933] New: Convert inline asm to MCInsts (nuke the pre-MC AsmPrinter) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23933 Bug ID: 23933 Summary: Convert inline asm to MCInsts (nuke the pre-MC AsmPrinter) Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: MC Assignee: unassignedbugs at nondot.org Reporter: dexonsmith at apple.com CC: llvmbugs at cs.uiuc.edu, pete.cooper at gmail.com, rafael.espindola at gmail.com Classification: Unclassified Quoting Rafael in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150622/283583.html -- The way inline asm is implemented is * We kept most of the old (pre-MC) assembly printer around. * We use it to print/expand inline asm to a string. * We parse that string. So anything that can show up in inline asm needs a name by which we can find it again. I think the way to fix this is to directly transition from the inline asm pattern "bsr $0,%eax" to a MCInst with an operand pointing to whatever we created for $0. That will let us nuke the old printer and save memory by not creating names just in case they are used in inline asm. -- Filing this so we don't forget the plan. Once that's done, we should bring r240130/r240302 back, dropping names from temp symbols. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 24 05:12:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 12:12:10 +0000 Subject: [LLVMbugs] [Bug 23674] llc uses feature rsqrt.approx.ftz.f64 that requires a later version In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23674 Jonas Hahnfeld changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonas Hahnfeld --- Ok, sorry, my error: It tells you exactly what to do! You have to specify "-mattr=ptx42" on the `llc` command (which is mentioned nowhere in the documentation!) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 24 06:34:54 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 13:34:54 +0000 Subject: [LLVMbugs] [Bug 23934] New: eeeeeeeeeee Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23934 Bug ID: 23934 Summary: eeeeeeeeeee Product: Bugzilla Admin Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: UI Assignee: unassignedbugs at nondot.org Reporter: netfuzzer at yandex.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified dddwwwwdf -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 24 06:35:16 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 13:35:16 +0000 Subject: [LLVMbugs] [Bug 23934] eeeeeeeeeee In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23934 mario changed: What |Removed |Added ---------------------------------------------------------------------------- CC|llvmbugs at cs.uiuc.edu | -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 24 10:34:02 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 17:34:02 +0000 Subject: [LLVMbugs] [Bug 23935] New: Bootstrapping clang fails because of emmintrin.h Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23935 Bug ID: 23935 Summary: Bootstrapping clang fails because of emmintrin.h Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: bero at linaro.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14512 --> https://llvm.org/bugs/attachment.cgi?id=14512&action=edit fix When using cmake to bootstrap clang (crosscompiling the entire llvm+clang+libc++ combo), the build fails because various files in (at least) tools/clang/lib/Base and tools/clang/lib/Lex try to #include , which is part of clang and therefore doesn't exist in the target sysroot yet. The patch I'm attaching fixes the problem for me by making clang look for headers in its source directory. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 24 10:50:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 17:50:26 +0000 Subject: [LLVMbugs] [Bug 23936] New: [powerpc-ubuntu] code generation failure for some OpenCL built-ins Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23936 Bug ID: 23936 Summary: [powerpc-ubuntu] code generation failure for some OpenCL built-ins Product: new-bugs Version: trunk Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: kanagak86 at yahoo.ca CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14513 --> https://llvm.org/bugs/attachment.cgi?id=14513&action=edit coge generator bug from PPC The attached file causes a crash on PPC64 (Power 8) - Ubuntu 3.16.0-23-generic. The workload is from OpenCL 1.1 built-ins. There were couple of built-ins build failure on vector data type; int, long, float with vec size; 8 or 16. Some of the builtins examples: mul_hi_long, asin_h (vec16) and etc. The last revision that it worked on was 3.6 r222776. The problem seem to be there for all 3.6.1. I have attached simplified version of the code generator bug created from bug point. Here's the snap shot of the Error: Impossible reg-to-reg copy UNREACHABLE executed at PPCInstrInfo.cpp:768! #0 0x10a55b5c llvm::sys::PrintStackTrace(_IO_FILE*) (/home/kajank/compiler/llvm_361_r240134/Release+Asserts/bin/llc+0x10a55b5c) #1 0x10a56998 PrintStackTraceSignalHandler(void*) (/home/kajank/compiler/llvm_361_r240134/Release+Asserts/bin/llc+0x10a56998) #2 0x10a57368 SignalHandler(int) (/home/kajank/compiler/llvm_361_r240134/Release+Asserts/bin/llc+0x10a57368) 0 llc 0x0000000010a55b5c llvm::sys::PrintStackTrace(_IO_FILE*) + 120 1 llc 0x0000000010a56998 2 llc 0x0000000010a57368 3 0x00003fff94ee0478 __kernel_sigtramp_rt64 + 0 4 libc.so.6 0x00003fff94a006b8 gsignal + 72 5 libc.so.6 0x00003fff94a0295c abort + 636 6 llc 0x0000000010a3b3d0 llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) + 684 7 llc 0x00000000101a8e40 llvm::PPCInstrInfo::copyPhysReg(llvm::MachineBasicBlock&, llvm::MachineBasicBlock::bundle_iterator >, llvm::DebugLoc, unsigned int, unsigned int, bool) const + 2280 8 llc 0x00000000104270cc 9 llc 0x00000000104a702c llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 216 10 llc 0x000000001095595c llvm::FPPassManager::runOnFunction(llvm::Function&) + 424 11 llc 0x0000000010955cb8 llvm::FPPassManager::runOnModule(llvm::Module&) + 72 12 llc 0x0000000010956360 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 1088 13 llc 0x00000000109569dc llvm::legacy::PassManager::run(llvm::Module&) + 28 14 llc 0x00000000100f8da0 main + 7744 15 libc.so.6 0x00003fff949e4e80 16 libc.so.6 0x00003fff949e5074 __libc_start_main + 196 Stack dump: 0. Program arguments: llc bugpoint-reduced-simplified.bc 1. Running pass 'Function Pass Manager' on module 'bugpoint-reduced-simplified.bc'. 2. Running pass 'Post-RA pseudo instruction expansion pass' on function '@mul_hi_long8' Aborted -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 24 12:28:19 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 19:28:19 +0000 Subject: [LLVMbugs] [Bug 23929] Code completion for macros broken when modules enabled In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23929 Jordan Rose changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jordan Rose --- Fixed in r240571. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 24 13:10:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 20:10:47 +0000 Subject: [LLVMbugs] [Bug 23912] Handling of ARM Errata 602117 (and testcase) is broken In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23912 Matthias Braun changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedbugs at nondot.org |matze at braunis.de --- Comment #1 from Matthias Braun --- Fixed in r240582. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 24 14:28:38 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 21:28:38 +0000 Subject: [LLVMbugs] [Bug 23926] Reassociate wrongly preserves nuw In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23926 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedbugs at nondot.org |david.majnemer at gmail.com --- Comment #3 from David Majnemer --- Fixed in r240593. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 24 14:45:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 21:45:51 +0000 Subject: [LLVMbugs] [Bug 21917] Error in std::pair default constructor when elements are not default-constructible In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21917 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Marshall Clow (home) --- The sample code compiles w/o error on ToT. We discussed the change that Eric suggested here: http://reviews.llvm.org/D7384, but this was never applied. I suspect that a change to is_default_constructible caused this to start working. If anyone thinks that this is still broken, please reopen. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 24 14:52:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 21:52:40 +0000 Subject: [LLVMbugs] [Bug 23922] GVN incorrectly propagates exact attribute In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23922 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedbugs at nondot.org |david.majnemer at gmail.com --- Comment #1 from David Majnemer --- Fixed in r240595. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 24 15:03:34 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 22:03:34 +0000 Subject: [LLVMbugs] [Bug 23937] New: AVX512: scalar FMA 132/231 instructions are not supported Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23937 Bug ID: 23937 Summary: AVX512: scalar FMA 132/231 instructions are not supported Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: ahmed.bougacha at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Consider: $ echo '0x62 0xf2 0xf5 0x08 0xa9 0xc2' | ./bin/llvm-mc -disassemble .section __TEXT,__text,regular,pure_instructions vfmadd213sd %xmm2, %xmm1, %xmm0 Replacing 0xa9 (213) with 0xb9 (231) or 0x99 (132) doesn't work: $ echo '0x62 0xf2 0xf5 0x08 0x99 0xc2' | ./bin/llvm-mc -disassemble .section __TEXT,__text,regular,pure_instructions :1:1: warning: invalid instruction encoding 0x62 0xf2 0xf5 0x08 0x99 0xc2 ^ :1:26: warning: invalid instruction encoding 0x62 0xf2 0xf5 0x08 0x99 0xc2 ^ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 24 15:27:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 22:27:26 +0000 Subject: [LLVMbugs] [Bug 23938] New: Phabricator thinks FilCab needs to be more friendly Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23938 Bug ID: 23938 Summary: Phabricator thinks FilCab needs to be more friendly Product: Website Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Phabricator Assignee: unassignedbugs at nondot.org Reporter: chris.bieneman at me.com CC: klimek at google.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Either Phabricator has decided FilCab needs to be more friendly or it failed to parse his email. Phab link: http://reviews.llvm.org/D10710 Email link: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150622/283803.html -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 24 15:45:02 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 22:45:02 +0000 Subject: [LLVMbugs] [Bug 23939] New: Accepts invalid when undeduced context encountered deducing from a trailing parameter pack Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23939 Bug ID: 23939 Summary: Accepts invalid when undeduced context encountered deducing from a trailing parameter pack Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: hstong at ca.ibm.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified In the call to "f" from "h" below, the deduction for T at 1 should find both "fptype" and "Func" and fail. ### SOURCE (): template struct A; void g(); void g(bool); typedef void (*fptype)(); struct Func { operator fptype(); } func; template void f(A *ap, T ...b); void h(A *ap) { f(ap, g, func); } ### COMPILER INVOCATION: clang++ -std=c++11 -c -x c++ - ### ACTUAL OUTPUT: (Clean compile). ### EXPECTED OUTPUT: (Error message). ### COMPILER VERSION INFO: clang version 3.7.0 (trunk) Target: powerpc64le-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/ppc64le-redhat-linux/4.8.2 Found candidate GCC installation: /usr/lib/gcc/ppc64le-redhat-linux/4.8.3 Selected GCC installation: /usr/lib/gcc/ppc64le-redhat-linux/4.8.3 Candidate multilib: .;@m64 Selected multilib: .;@m64 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 24 16:11:13 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 24 Jun 2015 23:11:13 +0000 Subject: [LLVMbugs] [Bug 23940] New: UNREACHABLE executed at Frontend\InitHeaderSearch.cpp:311! Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23940 Bug ID: 23940 Summary: UNREACHABLE executed at Frontend\InitHeaderSearch.cpp:311! Product: clang Version: 3.6 Hardware: PC OS: Windows XP Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: romaric.lecart at live.fr CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14516 --> https://llvm.org/bugs/attachment.cgi?id=14516&action=edit Source file and crash dump of clang.exe I tried to use the -m16 switch to generate 16-bit code but clang crash. Here is the output : c:\tmp>clang -c -m16 -v main.c clang version 3.6.1 (tags/RELEASE_361/final) Target: i686-pc-windows-code16 Thread model: posix "C:\\Program Files (x86)\\LLVM\\bin\\clang.exe" -cc1 -triple i686-pc-windows-code16 -emit-obj -mrelax-all -disable-free -main-file-name main.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu pentium4 -v -dwarf-column-info -coverage-file "c:\\tmp\\main.c" -resource-dir "C:\\Program Files (x86)\\LLVM\\bin\\..\\lib\\clang\\3.6.1" -fdebug-compilation-dir "c:\\tmp" -ferror-limit 19 -fmessage-length 80 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o main.o -x c main.c clang -cc1 version 3.6.1 based upon LLVM 3.6.1 default target i686-pc-windows-gnu ignoring nonexistent directory "/usr/local/include" Include management is handled in the driver. UNREACHABLE executed at D:\src\llvm_release_build_3.6.1-final\llvm\tools\clang\lib\Frontend\InitHeaderSearch.cpp:311! clang.exe: error: clang frontend command failed with exit code 255 (use -v to see invocation) I also attached the crash dump and the source file Note : without the switch -m16 , that works perfectly -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Jun 24 17:20:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 00:20:17 +0000 Subject: [LLVMbugs] [Bug 23941] New: AVX512: unable to select vcvtps2ph/ph2ps from fpext/fptrunc Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23941 Bug ID: 23941 Summary: AVX512: unable to select vcvtps2ph/ph2ps from fpext/fptrunc Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: ahmed.bougacha at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This fails to select the native instructions with +avx512f,-f16c: define float @test_extend32(half* %addr) { %val16 = load half, half* %addr %val32 = fpext half %val16 to float ret float %val32 } When users specify -mavx512f without any CPU (so without specifying F16C), this means we'll get the libcalls instead of the cvt instructions, because of the hasF16C() checks guarding legality. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 08:56:21 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 15:56:21 +0000 Subject: [LLVMbugs] [Bug 23923] "redefine_extname" pragma handled incorrectly in case of a local var with the same name In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23923 Andrey Bokhanko changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrey Bokhanko --- Fix committed, r240653. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 08:53:06 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 15:53:06 +0000 Subject: [LLVMbugs] [Bug 23952] New: Crash on explicit destructor call in move assignment operator Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23952 Bug ID: 23952 Summary: Crash on explicit destructor call in move assignment operator Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: davorin.ucakar at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Compiling the following minimal case crashes Clang: template struct List { List() = default; ~List() = default; List& operator = (List&&) { List::~List(); return *this; } }; int main() { List f1, f2; f2 = static_cast&&>(f1); return 0; } [davorin at lumpy tests]$ clang++ -v -std=c++11 scratch.cc clang version 3.6.1 (tags/RELEASE_361/final) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.1.0 Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.1.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0 Found candidate GCC installation: /usr/lib64/gcc/x86_64-unknown-linux-gnu/5.1.0 Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.1.0 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 "/usr/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name scratch.cc -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.25.0 -v -dwarf-column-info -resource-dir /usr/bin/../lib/clang/3.6.1 -internal-isystem /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0 -internal-isystem /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/x86_64-unknown-linux-gnu -internal-isystem /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.6.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /home/davorin/Razvoj/openzone/src/tests -ferror-limit 19 -fmessage-length 157 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/scratch-201313.o -x c++ scratch.cc clang -cc1 version 3.6.1 based upon LLVM 3.6.1 default target x86_64-unknown-linux-gnu ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0 /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/x86_64-unknown-linux-gnu /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/backward /usr/local/include /usr/bin/../lib/clang/3.6.1/include /usr/include End of search list. #0 0x7faf77f58822 llvm::sys::PrintStackTrace(_IO_FILE*) (/usr/bin/../lib/libLLVM-3.6.so+0xf97822) #1 0x7faf77f56e19 (/usr/bin/../lib/libLLVM-3.6.so+0xf95e19) #2 0x7faf76db4660 __restore_rt (/usr/bin/../lib/libpthread.so.0+0x10660) #3 0x120a037 (/usr/bin/clang+0x120a037) #4 0x120a739 (/usr/bin/clang+0x120a739) #5 0x120b1fa clang::FormatASTNodeDiagnosticArgument(clang::DiagnosticsEngine::ArgumentKind, long, llvm::StringRef, llvm::StringRef, llvm::ArrayRef >, llvm::SmallVectorImpl&, void*, llvm::ArrayRef) (/usr/bin/clang+0x120b1fa) #6 0x13ed070 clang::Diagnostic::FormatDiagnostic(char const*, char const*, llvm::SmallVectorImpl&) const (/usr/bin/clang+0x13ed070) #7 0x70de2f clang::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level, clang::Diagnostic const&) (/usr/bin/clang+0x70de2f) #8 0x13ef060 clang::DiagnosticIDs::EmitDiag(clang::DiagnosticsEngine&, clang::DiagnosticIDs::Level) const (/usr/bin/clang+0x13ef060) #9 0x13ef2b6 clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&) const (/usr/bin/clang+0x13ef2b6) #10 0x13e8384 clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool) (/usr/bin/clang+0x13e8384) #11 0xac311a clang::Sema::EmitCurrentDiagnostic(unsigned int) (/usr/bin/clang+0xac311a) #12 0xac366b (/usr/bin/clang+0xac366b) #13 0xde9c1a clang::Sema::FindInstantiatedDecl(clang::SourceLocation, clang::NamedDecl*, clang::MultiLevelTemplateArgumentList const&) (/usr/bin/clang+0xde9c1a) #14 0xdbbd2f (/usr/bin/clang+0xdbbd2f) #15 0xdd1fdf (/usr/bin/clang+0xdd1fdf) #16 0xdc2ad7 (/usr/bin/clang+0xdc2ad7) #17 0xdc6e1f (/usr/bin/clang+0xdc6e1f) #18 0xdc2cd1 (/usr/bin/clang+0xdc2cd1) #19 0xdd899d (/usr/bin/clang+0xdd899d) #20 0xdd964b (/usr/bin/clang+0xdd964b) #21 0xdd978b (/usr/bin/clang+0xdd978b) #22 0xdd8c95 (/usr/bin/clang+0xdd8c95) #23 0xddbe7f clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList const&) (/usr/bin/clang+0xddbe7f) #24 0xdefd82 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) (/usr/bin/clang+0xdefd82) #25 0xdeef6b clang::Sema::PerformPendingInstantiations(bool) (/usr/bin/clang+0xdeef6b) #26 0xac94df clang::Sema::ActOnEndOfTranslationUnit() (/usr/bin/clang+0xac94df) #27 0xa25330 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) (/usr/bin/clang+0xa25330) #28 0xa1ad73 clang::ParseAST(clang::Sema&, bool, bool) (/usr/bin/clang+0xa1ad73) #29 0x6d4b36 clang::FrontendAction::Execute() (/usr/bin/clang+0x6d4b36) #30 0x6af2c9 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/bin/clang+0x6af2c9) #31 0x696554 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/bin/clang+0x696554) #32 0x690e40 cc1_main(llvm::ArrayRef, char const*, void*) (/usr/bin/clang+0x690e40) #33 0x68de7b main (/usr/bin/clang+0x68de7b) #34 0x7faf7648a790 __libc_start_main (/usr/bin/../lib/libc.so.6+0x20790) #35 0x690499 _start (/usr/bin/clang+0x690499) Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name scratch.cc -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.25.0 -v -dwarf-column-info -resource-dir /usr/bin/../lib/clang/3.6.1 -internal-isystem /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0 -internal-isystem /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/x86_64-unknown-linux-gnu -internal-isystem /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.6.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /home/davorin/Razvoj/openzone/src/tests -ferror-limit 19 -fmessage-length 157 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/scratch-201313.o -x c++ scratch.cc 1. parser at end of file 2. scratch.cc:7:9: instantiating function definition 'operator=' clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.6.1 (tags/RELEASE_361/final) Target: x86_64-unknown-linux-gnu Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/scratch-bfeea6.cpp clang: note: diagnostic msg: /tmp/scratch-bfeea6.sh clang: note: diagnostic msg: ******************** /tmp/scratch-bfeea6.cpp: # 1 "" # 1 "scratch.cc" template struct List { List() = default; ~List() = default; List& operator = (List&&) { List::~List(); return *this; } }; int main() { List f1, f2; f2 = static_cast&&>(f1); return 0; } /tmp/scratch-bfeea6.sh: "/usr/bin/clang" "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-emit-obj" "-mrelax-all" "-disable-free" "-disable-llvm-verifier" "-main-file-name" "scratch.cc" "-mrelocation-model" "static" "-mthread-model" "posix" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-fuse-init-array" "-target-cpu" "x86-64" "-target-linker-version" "2.25.0" "-v" "-dwarf-column-info" "-std=c++11" "-fdeprecated-macro" "-ferror-limit" "19" "-fmessage-length" "157" "-mstackrealign" "-fobjc-runtime=gcc" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-x" "c++" "scratch-bfeea6.cpp" -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 08:43:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 15:43:52 +0000 Subject: [LLVMbugs] [Bug 23951] New: __has_include not reported by "clang -dM -E - < /dev/null" Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23951 Bug ID: 23951 Summary: __has_include not reported by "clang -dM -E - < /dev/null" Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangbugs at nondot.org Reporter: nikolai.kosjar at digia.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified __has_include (and also *_next) is *not* reported by "clang -dM -E - < /dev/null" but it's there: ~/work/clang-bugs % clang-3.6 --version Ubuntu clang version 3.6.0-2ubuntu1~trusty1 (tags/RELEASE_360/final) (based on LLVM 3.6.0) Target: x86_64-pc-linux-gnu Thread model: posix ~/work/clang-bugs % cat confirmPredefinedHasIncludeMacro.cpp #if defined(__has_include) # error "OK, __has_include" #endif ~/work/clang-bugs % clang-3.6 -dM -E - < /dev/null | grep has_include zsh: done clang-3.6 -dM -E - < /dev/null | zsh: exit 1 grep --color=auto has_include By the way, is this the preferred way to check for predefined macros in clang? -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 08:41:24 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 15:41:24 +0000 Subject: [LLVMbugs] [Bug 23779] Segfault when globals reference constants when targeting OSX In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23779 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Bruno Cardoso Lopes --- Committed r240649 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 07:56:15 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 14:56:15 +0000 Subject: [LLVMbugs] [Bug 23949] New: "failed template argument deduction" with function pointers and multiple parameter packs Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23949 Bug ID: 23949 Summary: "failed template argument deduction" with function pointers and multiple parameter packs Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: michael at ensslin.cc CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Take this example: $ cat t28.cpp template struct S { template void foo(void (*)(Us..., Ts ...)) {} }; void f(float, int) {} int main() { S().foo(f); } $ clang++-3.7 -std=c++14 t28.cpp t28.cpp:10:11: error: no matching member function for call to 'foo' S().foo(f); ~~~~~~~~~^~~~~~~~~~ t28.cpp:4:7: note: candidate template ignored: failed template argument deduction void foo(void (*)(Us..., Ts ...)) {} ^ 1 error generated. $ clang++-3.7 --version Debian clang version 3.7.0-svn239806-1+b1 (trunk) (based on LLVM 3.7.0) Target: x86_64-pc-linux-gnu Thread model: posix Note that g++ has this issue as well, but it supposedly works with MSVC. The issue can be fixed by swapping the order of Us... and Ts... in the function pointer type, or by replacing the function pointer type by some other type like std::tuple. Related: http://stackoverflow.com/questions/31040075 g++ error, for completeness: $ g++-4.9 -std=c++14 t28.cpp t28.cpp: In function ‘int main()’: t28.cpp:10:23: error: no matching function for call to ‘S::foo(void (&)(float, int))’ S().foo(f); ^ t28.cpp:10:23: note: candidate is: t28.cpp:4:7: note: template void S::foo(void (*)(Us ..., Ts ...)) [with Us = {Us ...}; Ts = {int}] void foo(void (*)(Us..., Ts ...)) {} ^ t28.cpp:4:7: note: template argument deduction/substitution failed: t28.cpp:10:23: note: mismatched types ‘int’ and ‘float’ S().foo(f); ^ $ g++-4.9 --version g++-4.9 (Debian 4.9.2-22) 4.9.2 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 07:53:04 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 14:53:04 +0000 Subject: [LLVMbugs] [Bug 23948] New: Crash in CodeCompleteConstructorInitializer for invalid code Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23948 Bug ID: 23948 Summary: Crash in CodeCompleteConstructorInitializer for invalid code Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: libclang Assignee: unassignedclangbugs at nondot.org Reporter: nikolai.kosjar at digia.com CC: klimek at google.com, llvmbugs at cs.uiuc.edu Classification: Unclassified $ cat lala.cpp struct Foo { template Foo() : // complete after ':' {} }; $ clang-3.6 -cc1 -code-completion-at lala.cpp:5:10 lala.cpp lala.cpp:3:15: error: unknown type name 'T' template ^ 0 libLLVM-3.6.so.1 0x00007f103e4dc912 llvm::sys::PrintStackTrace(_IO_FILE*) + 34 1 libLLVM-3.6.so.1 0x00007f103e4daeb1 2 libpthread.so.0 0x00007f103d0c4340 3 clang-3.6 0x0000000000891747 4 clang-3.6 0x0000000000afc97a clang::Sema::CodeCompleteConstructorInitializer(clang::Decl*, llvm::ArrayRef) + 810 5 clang-3.6 0x0000000000a2aad2 clang::Parser::ParseConstructorInitializer(clang::Decl*) + 690 6 clang-3.6 0x0000000000a77e28 clang::Parser::ParseLexedMethodDef(clang::Parser::LexedMethod&) + 760 7 clang-3.6 0x0000000000a77a9e clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 142 8 clang-3.6 0x0000000000a32ca9 clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&, unsigned int, clang::Decl*) + 2089 9 clang-3.6 0x0000000000a33a2a clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext, clang::Parser::ParsedAttributesWithRange&) + 1514 10 clang-3.6 0x0000000000a1ec04 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*) + 4628 11 clang-3.6 0x0000000000a0a494 clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) + 84 12 clang-3.6 0x0000000000a0ac26 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) + 1014 13 clang-3.6 0x0000000000a0df03 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) + 259 14 clang-3.6 0x0000000000a0e64c clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 460 15 clang-3.6 0x0000000000a083e0 clang::ParseAST(clang::Sema&, bool, bool) + 352 16 clang-3.6 0x00000000006e81d6 clang::FrontendAction::Execute() + 118 17 clang-3.6 0x00000000006c7078 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 280 18 clang-3.6 0x00000000006b18c4 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1892 19 clang-3.6 0x00000000006ac6f8 cc1_main(llvm::ArrayRef, char const*, void*) + 1304 20 clang-3.6 0x00000000006aab56 main + 8246 21 libc.so.6 0x00007f103c7f4ec5 __libc_start_main + 245 22 clang-3.6 0x00000000006ab74c Stack dump: 0. Program arguments: clang-3.6 -cc1 -code-completion-at lala.cpp:5:10 lala.cpp 1. lala.cpp:5:10: current parser token '' 2. lala.cpp:1:1: parsing struct/union/class body 'Foo' zsh: segmentation fault (core dumped) clang-3.6 -cc1 -code-completion-at lala.cpp:5:10 lala.cpp $ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 07:36:14 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 14:36:14 +0000 Subject: [LLVMbugs] [Bug 23947] New: CMake+Mips: find_library() doesn't work correctly when recursing 64-bit (both N32 and N64 ABI's) compiler on Debian Jessie Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23947 Bug ID: 23947 Summary: CMake+Mips: find_library() doesn't work correctly when recursing 64-bit (both N32 and N64 ABI's) compiler on Debian Jessie Product: Build scripts Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: daniel.sanders at imgtec.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Here's the Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785401 To summarize: * libdl and libpthread aren't found but are installed in /usr/lib32 * libxml2 is found, but it's the O32 binary which is link-incompatible with N32/N64. Also, semi-related but not officially reported to Debian yet: * zlib is present but is not usable. There is no zconf.h in the N32/N64 search paths. This blocks 64-bit Mips releases using cmake. We don't do 64-bit releases yet but we hope to soon. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 06:46:24 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 13:46:24 +0000 Subject: [LLVMbugs] [Bug 23945] New: Compiler crash in incorrect, heavily-templated code Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23945 Bug ID: 23945 Summary: Compiler crash in incorrect, heavily-templated code Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: michael at ensslin.cc CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14518 --> https://llvm.org/bugs/attachment.cgi?id=14518&action=edit tar.xz archive of test.cpp and the crash reproducers. Take this failed attempt at a template specialization: #include template struct S { template void foo(std::tuple, Us ...) { } }; template void S::foo<>(std::tuple) {} clang++{3.5, 3.6, 3.7} -std=c++{11, 14} will crash and print a stacktrace, albeit slightly different ones (as is to be expected, I guess). I'm using the compiler versions from the Debian Sid repository. $ clang++-3.7 -std=c++14 -c test.cpp test.cpp:13:20: error: cannot specialize a member of an unspecialized template void S::foo<>(std::tuple) {} ^ ~~ 0 libLLVM-3.7.so.1 0x00007f53beeb49b5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37 1 libLLVM-3.7.so.1 0x00007f53beeb3fc9 2 libpthread.so.0 0x00007f53bda158d0 3 clang 0x00000000012b3168 clang::ASTContext::getSubstTemplateTypeParmType(clang::TemplateTypeParmType const*, clang::QualType) const + 200 4 clang 0x0000000000e7d30f 5 clang 0x0000000000e8a8f9 6 clang 0x0000000000e8b955 7 clang 0x0000000000e954e5 8 clang 0x0000000000e9927f 9 clang 0x0000000000e8a769 10 clang 0x0000000000e8a95f 11 clang 0x0000000000e8b955 12 clang 0x0000000000e8ba43 clang::Sema::SubstType(clang::TypeSourceInfo*, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName) + 83 13 clang 0x0000000000e9e9d8 clang::Sema::SubstParmVarDecl(clang::ParmVarDecl*, clang::MultiLevelTemplateArgumentList const&, int, llvm::Optional, bool) + 88 14 clang 0x0000000000e9f1ba 15 clang 0x0000000000e9f577 16 clang 0x0000000000ea0cc0 clang::Sema::SubstFunctionDeclType(clang::TypeSourceInfo*, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName, clang::CXXRecordDecl*, unsigned int) + 1872 17 clang 0x0000000000ea81e2 clang::TemplateDeclInstantiator::SubstFunctionType(clang::FunctionDecl*, llvm::SmallVectorImpl&) + 114 Stack dump: 0. Program arguments: /usr/lib/llvm-3.7/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name test.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.25 -dwarf-column-info -coverage-file /tmp/llvmbug/test.cpp -resource-dir /usr/lib/llvm-3.7/bin/../lib/clang/3.7.0 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/x86_64-linux-gnu/c++/4.9 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/x86_64-linux-gnu/c++/4.9 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/backward -internal-isystem /usr/local/include -internal-isystem /usr/lib/llvm-3.7/bin/../lib/clang/3.7.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++14 -fdeprecated-macro -fdebug-compilation-dir /tmp/llvmbug -ferror-limit 19 -fmessage-length 190 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o test.o -x c++ test.cpp 1. test.cpp:13:49: current parser token '{' clang: error: unable to execute command: Segmentation fault clang: error: clang frontend command failed due to signal (use -v to see invocation) Debian clang version 3.7.0-svn239806-1+b1 (trunk) (based on LLVM 3.7.0) Target: x86_64-pc-linux-gnu Thread model: posix The crash reproducers, as suggested by the error message, are attached (but they're rather bloated, due to my #include , which I didn't manage to remove, so I suggest not using them. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 05:15:08 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 12:15:08 +0000 Subject: [LLVMbugs] [Bug 23943] New: clang crashes due to infinite template recursion Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23943 Bug ID: 23943 Summary: clang crashes due to infinite template recursion Product: clang Version: 3.6 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: wojas1222 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14517 --> https://llvm.org/bugs/attachment.cgi?id=14517&action=edit the crash backtrace Clang crashes when given a type dependent on infinite-recursive template as a template parameter. The code is not valid as it is, but the clang crashing was not the expected reaction. You can reproduce the issue by compiling the following code with Clang 3.6.1 (I'm using the build from MSYS2) template struct Concat { typedef int type; }; template struct Iota { typedef typename Concat< typename Iota::type >::type type; }; Iota::type err; int main() {} The run script is as follows: "C:\\__MOJE\\prog\\MSYS2_Toolset64\\mingw64\\bin\\clang++.exe" "-cc1" "-triple" "x86_64-w64-windows-gnu" "-emit-obj" "-mrelax-all" "-disable-free" "-disable-llvm-verifier" "-main-file-name" "ice.cpp" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-target-linker-version" "2.25" "-dwarf-column-info" "-std=c++11" "-fdeprecated-macro" "-ferror-limit" "19" "-fmessage-length" "0" "-mstackrealign" "-fno-use-cxa-atexit" "-fobjc-runtime=gcc" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" "-x" "c++" "ice-143b03.cpp" The trace is in the attachment. The clang++ -v output is: clang version 3.6.1 (tags/RELEASE_361/final) Target: x86_64-w64-windows-gnu Thread model: posix -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 02:11:08 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 09:11:08 +0000 Subject: [LLVMbugs] [Bug 23942] New: Some invalid pure-specifiers incorrectly accepted Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23942 Bug ID: 23942 Summary: Some invalid pure-specifiers incorrectly accepted Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: rs2740 at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Clang accepts without any diagnostic struct Meow { virtual void purr() = 0x0; virtual void hiss() = 00; }; Per the grammar in [class.mem], the only valid pure-specifier is `= 0`. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 01:52:14 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 08:52:14 +0000 Subject: [LLVMbugs] [Bug 23405] CodeGen crash with "Physical register dependency violated?" In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23405 Paweł Bylica changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedbugs at nondot.org |chfast at gmail.com --- Comment #6 from Paweł Bylica --- Fixed in r240538 (http://reviews.llvm.org/rL240538) by patch http://reviews.llvm.org/D9993 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 13:28:21 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 20:28:21 +0000 Subject: [LLVMbugs] [Bug 23953] New: LLVM fails to codegenerate functions whose name matches an llvm. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23953 Bug ID: 23953 Summary: LLVM fails to codegenerate functions whose name matches an llvm. Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: echristo at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 13:43:11 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 20:43:11 +0000 Subject: [LLVMbugs] [Bug 23940] UNREACHABLE executed at Frontend\InitHeaderSearch.cpp:311! In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23940 romaric.lecart at live.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from romaric.lecart at live.fr --- Oops, I haven't seen the triple. I did not expect generate a 16 bits binary for windows, but I wanted to see if I could use clang to build a bootloader. So, I replaced the triple by i386-pc-linux-code16. That works for what I want to do. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 14:01:18 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 21:01:18 +0000 Subject: [LLVMbugs] [Bug 23930] llvm-nm shows more symbols than nm In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23930 Rafael Ávila de Espíndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Rafael Ávila de Espíndola --- Fixed in r240695 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 15:03:28 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 22:03:28 +0000 Subject: [LLVMbugs] [Bug 23954] New: [Vectorizer] loop vectorizer crash creating mul with bad operands Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23954 Bug ID: 23954 Summary: [Vectorizer] loop vectorizer crash creating mul with bad operands Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedbugs at nondot.org Reporter: dschuff at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The simple test below crashes with the following assertion: opt: /s/llvm-upstream/llvm/lib/IR/Instructions.cpp:1702: static llvm::BinaryOperator *llvm::BinaryOperator::Create(llvm::Instruction::BinaryOps, llvm::Value *, llvm::Value *, const llvm::Twine &, llvm::Instruction *): Assertion `S1->getType() == S2->getType() && "Cannot create binary operator with two operands of differing type!"' failed. This is called from lib/Transforms/Vectorize/LoopVectorizer.cpp:857 I'll investigate but I'm not too familiar with this code so I though I'd get it up here too. Pasted below are the full stack trace and the reproducer. #0 0x00007ffff65b7cc9 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff65bb0d8 in __GI_abort () at abort.c:89 #2 0x00007ffff65b0b86 in __assert_fail_base (fmt=0x7ffff6701830 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion at entry=0x2252449 "S1->getType() == S2->getType() && \"Cannot create binary operator with two operands of differing type!\"", file=file at entry=0x22505e5 "/s/llvm-upstream/llvm/lib/IR/Instructions.cpp", line=line at entry=1702, function=function at entry=0x22524b0 "static llvm::BinaryOperator *llvm::BinaryOperator::Create(llvm::Instruction::BinaryOps, llvm::Value *, llvm::Value *, const llvm::Twine &, llvm::Instruction *)") at assert.c:92 #3 0x00007ffff65b0c32 in __GI___assert_fail ( assertion=0x2252449 "S1->getType() == S2->getType() && \"Cannot create binary operator with two operands of differing type!\"", file=0x22505e5 "/s/llvm-upstream/llvm/lib/IR/Instructions.cpp", line=1702, function=0x22524b0 "static llvm::BinaryOperator *llvm::BinaryOperator::Create(llvm::Instruction::BinaryOps, llvm::Value *, llvm::Value *, const llvm::Twine &, llvm::Instruction *)") at assert.c:101 #4 0x00000000013b1022 in llvm::BinaryOperator::Create (Op=llvm::Instruction::Mul, S1=0x2da9aa0, S2=0x2d943b0, Name=..., InsertBefore=0x0) at /s/llvm-upstream/llvm/lib/IR/Instructions.cpp:1701 #5 0x0000000000b2c512 in llvm::IRBuilder >::CreateInsertNUWNSWBinOp ( this=0x7fffffffc188, Opc=llvm::Instruction::Mul, LHS=0x2da9aa0, RHS=0x2d943b0, Name=..., HasNUW=false, HasNSW=false) at /s/llvm-upstream/llvm/include/llvm/IR/IRBuilder.h:705 #6 0x0000000000ef8ccb in llvm::IRBuilder >::CreateMul ( this=0x7fffffffc188, LHS=0x2da9aa0, RHS=0x2d943b0, Name=..., HasNUW=false, HasNSW=false) at /s/llvm-upstream/llvm/include/llvm/IR/IRBuilder.h:771 #7 0x00000000019de534 in (anonymous namespace)::LoopVectorizationLegality::InductionInfo::transform (this=0x7fffffffbf38, B=..., Index=0x2da9aa0) at /s/llvm-upstream/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:857 #8 0x00000000019dfd10 in (anonymous namespace)::InnerLoopVectorizer::createEmptyLoop (this=0x7fffffffc760) at /s/llvm-upstream/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:2802 #9 0x00000000019d04fb in (anonymous namespace)::InnerLoopVectorizer::vectorize (this=0x7fffffffc760, L=0x7fffffffccc0) at /s/llvm-upstream/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:274 #10 0x00000000019ce1f8 in (anonymous namespace)::LoopVectorize::processLoop (this=0x2d94180, L=0x2da1750) at /s/llvm-upstream/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:1667 #11 0x00000000019cd190 in (anonymous namespace)::LoopVectorize::runOnFunction (this=0x2d94180, F=...) at /s/llvm-upstream/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:1476 #12 0x00000000013ddacd in llvm::FPPassManager::runOnFunction (this=0x2d95ab0, F=...) at /s/llvm-upstream/llvm/lib/IR/LegacyPassManager.cpp:1520 #13 0x00000000013ddde5 in llvm::FPPassManager::runOnModule (this=0x2d95ab0, M=...) at /s/llvm-upstream/llvm/lib/IR/LegacyPassManager.cpp:1540 #14 0x00000000013de4d0 in (anonymous namespace)::MPPassManager::runOnModule (this=0x2d91800, M=...) at /s/llvm-upstream/llvm/lib/IR/LegacyPassManager.cpp:1596 #15 0x00000000013de0a6 in llvm::legacy::PassManagerImpl::run (this=0x2d91450, M=...) at /s/llvm-upstream/llvm/lib/IR/LegacyPassManager.cpp:1698 #16 0x00000000013de981 in llvm::legacy::PassManager::run (this=0x7fffffffd8f8, M=...) at /s/llvm-upstream/llvm/lib/IR/LegacyPassManager.cpp:1729 #17 0x0000000000798e8c in main (argc=3, argv=0x7fffffffdcd8) at /s/llvm-upstream/llvm/tools/opt/opt.cpp:599 target datalayout = "e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128" ; Function Attrs: nounwind uwtable define i32 @bfd_arch_i386_fill_fill(i64 %p1) #0 { entry: br i1 undef, label %while.end, label %while.body while.body: ; preds = %while.body, %entry %p.05 = phi i8* [ %add.ptr, %while.body ], [ null, %entry ] ;%p.05 = i8* %p1.addr.04 = phi i64 [ %sub, %while.body ], [ %p1, %entry ] %add.ptr = getelementptr inbounds i8, i8* %p.05, i32 2 %sub = add nsw i64 %p1.addr.04, -2 %tobool = icmp eq i64 %sub, 0 br i1 %tobool, label %while.end, label %while.body while.end: ; preds = %while.body, %entry ret i32 undef } attributes #0 = { nounwind uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "unsafe-fp-math"="false" "use-soft-float"="false" } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 15:11:00 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 22:11:00 +0000 Subject: [LLVMbugs] [Bug 22491] [cwg948] "type name does not allow constexpr specifier to be specified" using constexpr in condition In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22491 Meador Inge changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Meador Inge --- Fixed http://reviews.llvm.org/rL240707 . -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 16:16:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 23:16:17 +0000 Subject: [LLVMbugs] [Bug 23539] ASan broken on Mac OS X 10.8 after merge with UBsan run-time In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23539 Alexey Samsonov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 16:25:41 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 23:25:41 +0000 Subject: [LLVMbugs] [Bug 23955] New: Upper 8 registers are no longer available to asm statement Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23955 Bug ID: 23955 Summary: Upper 8 registers are no longer available to asm statement Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: hjl.tools at gmail.com CC: llvmbugs at cs.uiuc.edu, matze at braunis.de Classification: Unclassified Before r239309, this works: [hjl at gnu-32 bin]$ cat x.c void foo (int p) { register int reg __asm__("r8") = p; __asm__ __volatile__("# %0" : : "r" (reg)); } [hjl at gnu-32 bin]$ ./clang -S -O2 x.c [hjl at gnu-32 bin]$ cat x.s .text .file "x.c" .globl foo .align 16, 0x90 .type foo, at function foo: # @foo .cfi_startproc # BB#0: movl %edi, %r8d #APP #NO_APP retq .Lfunc_end0: .size foo, .Lfunc_end0-foo .cfi_endproc Now, I got [hjl at gnu-6 bin]$ ./clang -S -O2 x.c x.c:5:24: error: couldn't allocate input reg for constraint '{r8}' __asm__ __volatile__("# %0" : : "r" (reg)); ^ 1 error generated. [hjl at gnu-6 bin]$ If I use "r8d", I get [hjl at gnu-6 bin]$ cat x.c void foo (int p) { register int reg __asm__("r8d") = p; __asm__ __volatile__("# %0" : : "r" (reg)); } [hjl at gnu-6 bin]$ ./clang -S -O2 x.c x.c:4:28: error: unknown register name 'r8d' in asm register int reg __asm__("r8d") = p; ^ 1 error generated. [hjl at gnu-6 bin]$ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 16:35:21 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 23:35:21 +0000 Subject: [LLVMbugs] [Bug 23956] New: -Wdocumentation may recognize Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23956 Bug ID: 23956 Summary: -Wdocumentation may recognize Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: geek4civic at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified http://www.stack.nl/~dimitri/doxygen/manual/autolink.html ** Links to web pages and mail addresses Doxygen will automatically replace any URLs and mail addresses found in the documentation by links (in HTML). To manually specify link text, use the HTML 'a' tag: link text which will be automatically translated to other output formats by Doxygen. FYI, it's unavailable; \link http://example.com/path/to/url Descriptions... \endlink -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 16:50:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 25 Jun 2015 23:50:52 +0000 Subject: [LLVMbugs] [Bug 23953] LLVM fails to codegenerate functions whose name matches an llvm. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23953 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from David Majnemer --- Fixed in r240735. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 17:15:30 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 00:15:30 +0000 Subject: [LLVMbugs] [Bug 23412] -Wformat warns when using format specifier macros from MS headers In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23412 Nico Weber changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Nico Weber --- r240741 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 17:55:34 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 00:55:34 +0000 Subject: [LLVMbugs] [Bug 23716] Frontend crashes on clang::Sema::tryCaptureVariable In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23716 Meador Inge changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Meador Inge --- Fixed http://reviews.llvm.org/rL240740 . -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Jun 25 18:03:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 01:03:36 +0000 Subject: [LLVMbugs] [Bug 23957] New: Assertion `UpdatedSlot < StackTop && Dest < 7' failed on i686 MSVC Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23957 Bug ID: 23957 Summary: Assertion `UpdatedSlot < StackTop && Dest < 7' failed on i686 MSVC Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedbugs at nondot.org Reporter: alex at crichton.co CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following IR: target triple = "i686-pc-windows-msvc" define void @foo() { entry-block: %w = load double, double* undef %r = fptoui double %w to i32 store i32 %r, i32* undef %t = fsub double %w, %w store double %t, double* undef ret void } will generate the following error when run through llc ``` llc: /home/alex/code/llvm/lib/Target/X86/X86FloatingPoint.cpp:1232: void {anonymous}::FPS::handleTwoArgFP(llvm::MachineBasicBlock::iterator&): Assertion `UpdatedSlot < StackTop && Dest < 7' failed. 0 llc 0x000000000223a714 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 44 1 llc 0x000000000223aa29 2 llc 0x000000000223952a 3 libpthread.so.0 0x00007f4b7b970340 4 libc.so.6 0x00007f4b7a984cc9 gsignal + 57 5 libc.so.6 0x00007f4b7a9880d8 abort + 328 6 libc.so.6 0x00007f4b7a97db86 7 libc.so.6 0x00007f4b7a97dc32 8 llc 0x0000000001574bde 9 llc 0x0000000001572805 10 llc 0x0000000001572136 11 llc 0x0000000001a48f0b llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 95 12 llc 0x000000000217d0dc llvm::FPPassManager::runOnFunction(llvm::Function&) + 290 13 llc 0x000000000217d259 llvm::FPPassManager::runOnModule(llvm::Module&) + 97 14 llc 0x000000000217d5af 15 llc 0x000000000217dc8d llvm::legacy::PassManagerImpl::run(llvm::Module&) + 249 16 llc 0x000000000217dec7 llvm::legacy::PassManager::run(llvm::Module&) + 39 17 llc 0x0000000000c575f7 18 llc 0x0000000000c565da main + 242 19 libc.so.6 0x00007f4b7a96fec5 __libc_start_main + 245 20 llc 0x0000000000c535d9 Stack dump: 0. Program arguments: ../llvm/build/Debug+Asserts/bin/llc ./bugpoint-reduced-simplified.ll 1. Running pass 'Function Pass Manager' on module './bugpoint-reduced-simplified.ll'. 2. Running pass 'X86 FP Stackifier' on function '@foo' zsh: abort (core dumped) ../llvm/build/Debug+Asserts/bin/llc ./bugpoint-reduced-simplified.ll ``` -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 00:17:42 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 07:17:42 +0000 Subject: [LLVMbugs] [Bug 17673] [Vectorizer] Recognize strided access for vectorization In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17673 Hao Liu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hao Liu --- 3 kinds of cases can be recognized and vectorized by interleaved access after the commits r239285 and r239291. So resolve this issue. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 00:17:43 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 07:17:43 +0000 Subject: [LLVMbugs] [Bug 17677] [Vectorizer] Implement stride access In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17677 Bug 17677 depends on bug 17673, which changed state. Bug 17673 Summary: [Vectorizer] Recognize strided access for vectorization https://llvm.org/bugs/show_bug.cgi?id=17673 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 00:20:23 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 07:20:23 +0000 Subject: [LLVMbugs] [Bug 17679] [Vectorizer] Implement interleaved stride vectorization In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17679 Bug 17679 depends on bug 17677, which changed state. Bug 17677 Summary: [Vectorizer] Implement stride access https://llvm.org/bugs/show_bug.cgi?id=17677 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 00:20:22 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 07:20:22 +0000 Subject: [LLVMbugs] [Bug 17678] [Vectorizer] Implement non-interleaved stride vectorization In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17678 Bug 17678 depends on bug 17677, which changed state. Bug 17677 Summary: [Vectorizer] Implement stride access https://llvm.org/bugs/show_bug.cgi?id=17677 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 00:20:22 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 07:20:22 +0000 Subject: [LLVMbugs] [Bug 17677] [Vectorizer] Implement stride access In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17677 Hao Liu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 00:27:04 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 07:27:04 +0000 Subject: [LLVMbugs] [Bug 17679] [Vectorizer] Implement interleaved stride vectorization In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17679 Hao Liu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 00:27:04 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 07:27:04 +0000 Subject: [LLVMbugs] [Bug 17680] [Vectorizer] Recognize reduction stride vectorization In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17680 Bug 17680 depends on bug 17679, which changed state. Bug 17679 Summary: [Vectorizer] Implement interleaved stride vectorization https://llvm.org/bugs/show_bug.cgi?id=17679 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 00:27:04 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 07:27:04 +0000 Subject: [LLVMbugs] [Bug 17681] [Vectorizer] Recognize memory stride access In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17681 Bug 17681 depends on bug 17679, which changed state. Bug 17679 Summary: [Vectorizer] Implement interleaved stride vectorization https://llvm.org/bugs/show_bug.cgi?id=17679 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 00:28:30 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 07:28:30 +0000 Subject: [LLVMbugs] [Bug 17678] [Vectorizer] Implement non-interleaved stride vectorization In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17678 Hao Liu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hao Liu --- This can be recognized and vectorized by interleaved access after the commits r239285, r239291. I'm resolving this issue. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 00:28:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 07:28:31 +0000 Subject: [LLVMbugs] [Bug 17680] [Vectorizer] Recognize reduction stride vectorization In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17680 Bug 17680 depends on bug 17678, which changed state. Bug 17678 Summary: [Vectorizer] Implement non-interleaved stride vectorization https://llvm.org/bugs/show_bug.cgi?id=17678 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 00:28:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 07:28:31 +0000 Subject: [LLVMbugs] [Bug 17681] [Vectorizer] Recognize memory stride access In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17681 Bug 17681 depends on bug 17678, which changed state. Bug 17678 Summary: [Vectorizer] Implement non-interleaved stride vectorization https://llvm.org/bugs/show_bug.cgi?id=17678 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 00:29:16 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 07:29:16 +0000 Subject: [LLVMbugs] [Bug 17680] [Vectorizer] Recognize reduction stride vectorization In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17680 Hao Liu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hao Liu --- This can be recognized and vectorized by interleaved access after the commits r239285, r239291. I'm resolving this issue. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 00:31:57 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 07:31:57 +0000 Subject: [LLVMbugs] [Bug 17681] [Vectorizer] Recognize memory stride access In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17681 Hao Liu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 00:54:27 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 07:54:27 +0000 Subject: [LLVMbugs] [Bug 23958] New: Simple construct that is otherwise diagnosed is not found when class is split up into source and header Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23958 Bug ID: 23958 Summary: Simple construct that is otherwise diagnosed is not found when class is split up into source and header Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kremenek at apple.com Reporter: christian.kandeler at theqtcompany.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified For instance, this code: struct SomeClass { SomeClass(); }; SomeClass::SomeClass() { int *i = 0; *i = 0; } yields the following error, as expected: "someclass.cpp:5:8: warning: Dereference of null pointer (loaded from variable 'i')" However, if you put the declaration of SomeClass into a header and the implementation into a source file (see attachment), then nothing gets diagnosed anymore. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 01:30:54 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 08:30:54 +0000 Subject: [LLVMbugs] [Bug 23827] bad generated code for conditionals connected by (&) In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23827 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |chandlerc at gmail.com Resolution|--- |INVALID --- Comment #4 from Chandler Carruth --- Fisnik, on what processor and with what benchmark do you measure the problem with 'amp's generated code? Why is the branch misprediction penalty very high there? I don't really understand that at all. Fundamentally, I disbelieve that these should ever be compiled differently. They are identical code sequences functionally, and we should generate an identical sequence of instructions. Also, note that all versions of GCC also generate two jumps in both test cases. ICC is the only one that generates different code, and the code sequence it generates for 'amp' seems absurdly worse than what Clang and GCC do for both test cases and what ICC itself odes for 'ampamp'. Finally, do note that with Clang's output you have prolog/epilog idiocy in the code that has nothing to do with the testcase. AFAICT, other than that silliness, Clang, GCC, and ICC for 'ampamp' all agree, and I think that code is the best code. Please re-open with measurements and details about what you think is going wrong here if there is an actual performance problem. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 01:41:44 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 08:41:44 +0000 Subject: [LLVMbugs] [Bug 23959] New: lib/Target/Hexagon/HexagonInstrInfo.cpp:1982: bad return expression ? Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23959 Bug ID: 23959 Summary: lib/Target/Hexagon/HexagonInstrInfo.cpp:1982: bad return expression ? Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: dcb314 at hotmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified llvm/lib/Target/Hexagon/HexagonInstrInfo.cpp:1978]: (style) Same expression on both sides of '||'. Source code is return (Opcode == Hexagon::J2_jumpt) || (Opcode == Hexagon::J2_jumpf) || (Opcode == Hexagon::J2_jumptnewpt) || (Opcode == Hexagon::J2_jumpfnewpt) || (Opcode == Hexagon::J2_jumpt) || (Opcode == Hexagon::J2_jumpf); There looks to be an opportunity to simplify the code. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 01:57:16 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 08:57:16 +0000 Subject: [LLVMbugs] [Bug 23960] New: lib/Target/AMDGPU/SIInstrInfo.cpp: 3 * redundant condition ? Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23960 Bug ID: 23960 Summary: lib/Target/AMDGPU/SIInstrInfo.cpp: 3 * redundant condition ? Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: dcb314 at hotmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified 1. [trunk/llvm/lib/Target/AMDGPU/SIInstrInfo.cpp:939]: (style) Redundant condition: Src1.isReg(). 'A && (!A || B)' is equivalent to 'A || B' Source code is if (!Src1->isReg() || (Src1->isReg() && RI.isSGPRClass(MRI->getRegClass(Src1->getReg())))) return false; Same thing at lines 943 and 999. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 04:18:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 11:18:50 +0000 Subject: [LLVMbugs] [Bug 23962] New: crash on broken pipe Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23962 Bug ID: 23962 Summary: crash on broken pipe Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified $ ./bin/clang -S -x c /dev/null -o - | false clang-3.7: error: unable to execute command: Broken pipe clang-3.7: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (trunk 240761) (llvm/trunk 240771) Target: x86_64-unknown-linux-gnu Thread model: posix clang-3.7: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.7: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-3.7: note: diagnostic msg: /tmp/null-7dad1e.c clang-3.7: note: diagnostic msg: /tmp/null-7dad1e.sh clang-3.7: note: diagnostic msg: ******************** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 04:23:08 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 11:23:08 +0000 Subject: [LLVMbugs] [Bug 23963] New: [Regression][x86_64-w64-mingw32] Failure to compile simple switch-statement due to unrelocatable expression Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23963 Bug ID: 23963 Summary: [Regression][x86_64-w64-mingw32] Failure to compile simple switch-statement due to unrelocatable expression Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: lunow at math.hu-berlin.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Hi, I am using clang ToT $ cat test.cpp int foo(int x) { switch (x) { default: case 0: return 0; case 1: return 1; case 2: return 2; case 3: return 3; } } $ clang test.cpp -target x86_64-w64-mingw32 fatal error: error in backend: expected relocatable expression -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 05:45:13 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 12:45:13 +0000 Subject: [LLVMbugs] [Bug 21296] Performance regression on ARM within (219545, 219569] In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21296 Renato Golin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Renato Golin --- This was fixed ages ago. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 06:03:19 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 13:03:19 +0000 Subject: [LLVMbugs] [Bug 21420] [Meta] Android+Clang platform support In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21420 Bug 21420 depends on bug 23460, which changed state. Bug 23460 Summary: [aarch64][inline assembler] Clang should turn add into sub when necessary https://llvm.org/bugs/show_bug.cgi?id=23460 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 06:03:16 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 13:03:16 +0000 Subject: [LLVMbugs] [Bug 23460] [aarch64][inline assembler] Clang should turn add into sub when necessary In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23460 Renato Golin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |renato.golin at linaro.org Resolution|--- |DUPLICATE --- Comment #6 from Renato Golin --- It seems that the original code can be re-written in C, but the ultimate inline asm issue is being dealt with by another bug, so closing as duplicate. *** This bug has been marked as a duplicate of bug 20978 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 06:03:18 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 13:03:18 +0000 Subject: [LLVMbugs] [Bug 18926] [Meta] ARM Integrated assembler support In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=18926 Bug 18926 depends on bug 23460, which changed state. Bug 23460 Summary: [aarch64][inline assembler] Clang should turn add into sub when necessary https://llvm.org/bugs/show_bug.cgi?id=23460 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 07:29:06 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 14:29:06 +0000 Subject: [LLVMbugs] [Bug 23964] New: __dfsw_memchr is miscompiled by llvm Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23964 Bug ID: 23964 Summary: __dfsw_memchr is miscompiled by llvm Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: hjl.tools at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified On Fedora/21 x86-64, llvm r240771 miscompiled __dfsw_memchr: Command Output (stderr): -- /export/gnu/import/git/llvm/projects/compiler-rt/test/dfsan/custom.cc:817:39: warning: data argument not used by format string [-Wformat-extra-args] assert(sprintf(buf, "Hello world!", 42, "hello") == 12); ~~~~~~~~~~~~~~ ^ /usr/include/assert.h:86:5: note: expanded from macro 'assert' ((expr) \ ^ 1 warning generated. custom.cc.tmp: /export/gnu/import/git/llvm/projects/compiler-rt/test/dfsan/custom.cc:698: void test_memchr(): Assertion `crv == &str1[2]' failed. /export/build/gnu/llvm-clang-bootstrap-cmake/stage2/build-x86_64-linux/projects/compiler-rt/test/dfsan/Output/custom.cc.script: line 4: 14618 Aborted DFSAN_OPTIONS="strict_data_dependencies=0" /export/build/gnu/llvm-clang-bootstrap-cmake/stage2/build-x86_64-linux/projects/compiler-rt/test/dfsan/Output/custom.cc.tmp Dump of assembler code for function __dfsw_memchr: 0x0000555555559630 <+0>: push %rbp 0x0000555555559631 <+1>: push %r15 0x0000555555559633 <+3>: push %r14 0x0000555555559635 <+5>: push %rbx 0x0000555555559636 <+6>: push %rax 0x0000555555559637 <+7>: mov %r8d,%ebx 0x000055555555963a <+10>: mov %ecx,%ebp 0x000055555555963c <+12>: mov 0x30(%rsp),%r15 => 0x0000555555559641 <+17>: lea 0x3b91d0(%rip),%rax # 0x555555912818 <_ZN7__dfsan10flags_dataE> 0x0000555555559648 <+24>: cmpb $0x0,0x2(%rax) 0x000055555555964c <+28>: je 0x555555559652 <__dfsw_memchr+34> 0x000055555555964e <+30>: xor %eax,%eax 0x0000555555559650 <+32>: jmp 0x555555559675 <__dfsw_memchr+69> 0x0000555555559652 <+34>: mov %rdx,%rsi 0x0000555555559655 <+37>: callq 0x555555557e60 0x000055555555965a <+42>: mov %ax,%r14w 0x000055555555965e <+46>: movzwl %bp,%edi 0x0000555555559661 <+49>: movzwl %bx,%esi 0x0000555555559664 <+52>: callq 0x555555557c50 0x0000555555559669 <+57>: movzwl %r14w,%edi 0x000055555555966d <+61>: movzwl %ax,%esi __dfsw_memchr compiled with g++: Dump of assembler code for function __dfsw_memchr(void*, int, size_t, dfsan_label, dfsan_label, dfsan_label, dfsan_label*): 0x0000000000006b30 <+0>: push %r14 0x0000000000006b32 <+2>: push %r13 0x0000000000006b34 <+4>: mov %r8d,%r14d 0x0000000000006b37 <+7>: push %r12 0x0000000000006b39 <+9>: push %rbp 0x0000000000006b3a <+10>: mov %rdi,%r13 0x0000000000006b3d <+13>: push %rbx 0x0000000000006b3e <+14>: mov %ecx,%r12d 0x0000000000006b41 <+17>: mov %rdx,%rbx 0x0000000000006b44 <+20>: callq 0x37e0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It is missing from llvm. 0x0000000000006b49 <+25>: mov %rax,%rbp 0x0000000000006b4c <+28>: lea 0x23e8fd(%rip),%rax # 0x245450 <_ZN7__dfsan10flags_dataE> 0x0000000000006b53 <+35>: cmpb $0x0,0x2(%rax) 0x0000000000006b57 <+39>: je 0x6b80 <__dfsw_memchr(void*, int, size_t, dfsan_label, dfsan_label, dfsan_label, dfsan_label*)+80> 0x0000000000006b59 <+41>: mov 0x30(%rsp),%rax 0x0000000000006b5e <+46>: test %rbp,%rbp 0x0000000000006b61 <+49>: mov $0x0,%ecx 0x0000000000006b66 <+54>: cmove %ecx,%r12d 0x0000000000006b6a <+58>: mov %r12w,(%rax) It happens on Fedora/21, not on Fedora 20. It worked on Fedora 21 on May 30, 2015. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 07:56:35 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 14:56:35 +0000 Subject: [LLVMbugs] [Bug 23507] integrated arm assembler should support pre-UAL syntax In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23507 Renato Golin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 07:56:35 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 14:56:35 +0000 Subject: [LLVMbugs] [Bug 18926] [Meta] ARM Integrated assembler support In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=18926 Bug 18926 depends on bug 23507, which changed state. Bug 23507 Summary: integrated arm assembler should support pre-UAL syntax https://llvm.org/bugs/show_bug.cgi?id=23507 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 07:56:35 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 14:56:35 +0000 Subject: [LLVMbugs] [Bug 21420] [Meta] Android+Clang platform support In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21420 Bug 21420 depends on bug 23507, which changed state. Bug 23507 Summary: integrated arm assembler should support pre-UAL syntax https://llvm.org/bugs/show_bug.cgi?id=23507 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 09:09:16 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 16:09:16 +0000 Subject: [LLVMbugs] [Bug 23965] New: False positive in checker: Use of memory after it is freed Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23965 Bug ID: 23965 Summary: False positive in checker: Use of memory after it is freed Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kremenek at apple.com Reporter: me at moshekaplan.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14522 --> https://llvm.org/bugs/attachment.cgi?id=14522&action=edit Original source file (airserv-ng.c) When analyzing airserv-ng.c, clang reports a use after free. https://github.com/aircrack-ng/aircrack-ng/blob/master/src/airserv-ng.c#L140 However, the memory is NULLed immediately after the call to free. Therefore, if (c == NULL) is true and it breaks out of the loop. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 09:43:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 16:43:49 +0000 Subject: [LLVMbugs] [Bug 23966] New: UNREACHABLE executed at ..\lib\Target\X86\X86TargetObjectFile.cpp:148 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23966 Bug ID: 23966 Summary: UNREACHABLE executed at ..\lib\Target\X86\X86TargetObjectFile.cpp:148 Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: hans at chromium.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14524 --> https://llvm.org/bugs/attachment.cgi?id=14524&action=edit unreduced repro >From a 64-bit Chromium build on Windows. Attaching repro. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 09:52:59 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 16:52:59 +0000 Subject: [LLVMbugs] [Bug 23809] InstCombine should keep useful @llvm.assume calls In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23809 Jingyue Wu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jingyue Wu --- fixed in r240683 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 10:46:11 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 17:46:11 +0000 Subject: [LLVMbugs] [Bug 23958] Simple construct that is otherwise diagnosed is not found when class is split up into source and header In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23958 Anna Zaks changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 11:56:08 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 18:56:08 +0000 Subject: [LLVMbugs] [Bug 23966] UNREACHABLE executed at ..\lib\Target\X86\X86TargetObjectFile.cpp:148 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23966 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedbugs at nondot.org |david.majnemer at gmail.com --- Comment #5 from David Majnemer --- Fixed in r240811. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 11:56:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 18:56:39 +0000 Subject: [LLVMbugs] [Bug 23967] New: llvm_map_components_to_libnames(XXX all) includes gtest and gtest_main Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23967 Bug ID: 23967 Summary: llvm_map_components_to_libnames(XXX all) includes gtest and gtest_main Product: Build scripts Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: dan at su-root.co.uk CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I have noticed that when using ``llvm_map_components_to_libnames(...)`` that when the component is specified as ``all`` the ``gtest`` and ``gtest_main`` targets are includes which is wrong. These are not LLVM libraries and worse when we actually install LLVM somewhere these libraries are not shipped which can cause link failures in a project that consumes the exported LLVM targets if they don't have gtest on their system. I'm working on a fix now. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 15:01:08 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 22:01:08 +0000 Subject: [LLVMbugs] [Bug 23968] New: Wtautological-undefined-compare disabled with double-macros Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23968 Bug ID: 23968 Summary: Wtautological-undefined-compare disabled with double-macros Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: nlewycky at google.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Testcase: #define NULL nullptr #define MYIF(x) if (x) {} struct X {}; void test(X &x) { MYIF(&x == NULL) } with -std=c++11 should issue a warning, but doesn't. If you use 'nullptr' in place of NULL directly, it does. If you write the if-stmt out instead of using a macro for it, it does. But if you use two macros, it doesn't fire. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 15:06:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 22:06:10 +0000 Subject: [LLVMbugs] [Bug 23969] New: "mcount" is deprecated for arm backend Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23969 Bug ID: 23969 Summary: "mcount" is deprecated for arm backend Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: shenhan at google.com CC: echristo at gmail.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Current ARM bpapi (Base Platform Application Binary Interface) no longer uses "mcount" as function profiler name, instead it uses "__gnu_mcount_nc". (Refer to trunk gcc - gcc/config/arm/bpapi.h ARM_FUNCTION_PROFILER.) Also checking the system libc.so, __gnu_mcount_nc is properly defined. Notwithstanding the fact that "_mcount" and "mcount" are defined in libc.so, they are not the default-version symbol, to link against these symbols, a version script file has to be provided to the linker, otherwise we get an undefined symbol error. May I suggest override this value in ARMTaretInfo as - this->MCountName = "__gnu_mcount_nc"; -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 15:08:09 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 22:08:09 +0000 Subject: [LLVMbugs] [Bug 23902] clang segfaults on undefined variable In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23902 Davide Italiano changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Davide Italiano --- r240443 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 15:29:46 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 22:29:46 +0000 Subject: [LLVMbugs] [Bug 23865] Dumping machine instructions is slow on large functions. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23865 Duncan changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Duncan --- I did something similar in r240842, r240845, and r240848. Takes ~9 seconds now. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 15:47:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 22:47:36 +0000 Subject: [LLVMbugs] [Bug 23970] New: 0o for Octal Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23970 Bug ID: 23970 Summary: 0o for Octal Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: olafvdspek at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified People don't expect 010 == 8 to be true. Could you support a clearer prefix for octal numbers (0o)? Step 2 might be a warning for the old octal prefix. AFAIK Python added support some time ago: https://www.python.org/dev/peps/pep-3127/ I'm aware this isn't standard C++ but if this is possible I'd like to propose it to ISO C++ as well. I've started a discussion at isocpp.org as well: https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/IXXXDo3Y1rA -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 15:54:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 26 Jun 2015 22:54:51 +0000 Subject: [LLVMbugs] [Bug 23971] New: __attribute__((naked)) broken for possibly-returning functions Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23971 Bug ID: 23971 Summary: __attribute__((naked)) broken for possibly-returning functions Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: eugeni.stepanov at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Naked functions get unreachable statement at the end, which may be propagated into their callers. # cat 1.c __attribute__((naked,noinline)) void f() { asm volatile("bx lr\n\t"); } int g() { f(); return 42; } # clang -c 1.c -S -emit-llvm -o - -O1 define void @f() #0 { entry: tail call void asm sideeffect "bx lr\0A\09", "~{dirflag},~{fpsr},~{flags}"() #2, !srcloc !1 unreachable } ; Function Attrs: noreturn nounwind uwtable define i32 @g() #1 { entry: tail call void @f() unreachable } "return 42" in g() is gone. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Jun 26 19:23:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 27 Jun 2015 02:23:56 +0000 Subject: [LLVMbugs] [Bug 23970] 0o for Octal In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23970 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |LATER --- Comment #2 from Chris Lattner --- I agree with Richard: feel free to do this in your own local branch, and please do take it up with the C/C++ committees. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 27 00:54:16 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 27 Jun 2015 07:54:16 +0000 Subject: [LLVMbugs] [Bug 23971] __attribute__((naked)) broken for possibly-returning functions In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23971 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Component|LLVM Codegen |Interprocedural | |Optimizations Resolution|--- |FIXED Assignee|unassignedclangbugs at nondot. |unassignedbugs at nondot.org |org | Product|clang |libraries --- Comment #1 from David Majnemer --- Fixed in r240876. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 27 01:39:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 27 Jun 2015 08:39:07 +0000 Subject: [LLVMbugs] [Bug 23954] [Vectorizer] loop vectorizer crash creating mul with bad operands In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23954 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedbugs at nondot.org |david.majnemer at gmail.com --- Comment #2 from David Majnemer --- Fixed in r240877. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 27 03:46:25 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 27 Jun 2015 10:46:25 +0000 Subject: [LLVMbugs] [Bug 23973] New: Template specialization of non-type template parameter with variadic dependence is not picked Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23973 Bug ID: 23973 Summary: Template specialization of non-type template parameter with variadic dependence is not picked Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: andreas.noever at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Clang rejects the testcase below with error: implicit instantiation of undefined template 'Variadic' GCC does not complain. Replacing the variadic template with a non variadic one works. template using handler_t = void(*)(Args...); template struct Variadic; template struct Variadic> { }; /* // This works template struct Variadic> { }; */ void test() { Variadic> b; } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 27 09:51:43 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 27 Jun 2015 16:51:43 +0000 Subject: [LLVMbugs] [Bug 23974] New: [MS] Crash while trying to compile code with exceptions Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23974 Bug ID: 23974 Summary: [MS] Crash while trying to compile code with exceptions Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: ismail at donmez.ws CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14527 --> https://llvm.org/bugs/attachment.cgi?id=14527&action=edit test.cpp (gzipped) > clang++ -fexceptions test.cpp 0x00007FF660DDC004 (0x000000F0F5FDFFF8 0x000000F0F037D669 0x000000F0F5F43EF8 0x0000000000000000) 0x00007FF6615462C4 (0x000000F000000000 0x000000F0F5F43B30 0x000000F000000001 0x000000F0F5F42870) 0x00007FF661549B93 (0x000000F0F571CE10 0x000000F0F571CE10 0x000000F0F5F43B48 0x000000000000000F) 0x00007FF6614B7DCE (0x0000000000000000 0x000000F0F5EED2E8 0x000000F0F5EC3070 0x000000F0F5FDFEA0) 0x00007FF6614BCEE3 (0x000000F0F5F2B640 0x00000000000000F6 0x0000000000000003 0x000000F000000000) 0x00007FF660BB6004 (0x00007FF662523EC8 0x000000F0F5085900 0x0000000000000000 0x000000F0F5F2B640) 0x00007FF660FB8716 (0x000000F0F5EED2E8 0x000000F0F0561F40 0x000000F0F5085901 0x000000F0F5085900) 0x00007FF660FB885F (0x0000000000000000 0x000000F0F5F59301 0x0000000000000000 0x000000F0F5085900) 0x00007FF660FB8ACF (0x0000000000000002 0x000000F0F0561F70 0x0000000000000000 0x000000F0F5F59370) 0x00007FF660FB8201 (0x000000F0F0561F40 0x000000F0F0561F40 0x000000F0F037DCB0 0x00007FF6625F1F98) 0x00007FF6615F6C04 (0x000000F0F0518560 0x000000F0F0508640 0x000000F0F5EDCF48 0x000000F0F0518560) 0x00007FF6615F6D13 (0x0000000000000000 0x000000F0F0508420 0x000000F0F0508420 0x000000F0F0552390) 0x00007FF6615EA1E4 (0x000000F0F0596690 0x0000000000000000 0x0000000000000000 0x0000000000000000) 0x00007FF6619BCB35 (0x0000000000000000 0x0000000000000000 0x000000F0F050FC00 0x0000000000000000) 0x00007FF6614150FE (0x000000F0F0520550 0x0000000000000000 0x0000000000000040 0x0000000000000000) 0x00007FF6615E9C10 (0x000000F0F050FC00 0x000000F0F0520550 0x0000000000000001 0x000000F0F052B7A0) 0x00007FF661414FB5 (0x000000F0F050FC00 0x00007FF662830AD0 0x000000F0F050FC00 0x000000F0F050FC00) 0x00007FF6613EEE97 (0x00007FF661287EC0 0x0000000000000000 0x000000F0F037E279 0x00007FF662830D28) 0x00007FF6614555C6 (0x0000000000000001 0x000000F0F052CF00 0x000000F0F052B7A0 0x0000000000000000) 0x00007FF660B8EEFB (0x00007FF662815010 0x00007FF600000000 0xFFFFFFFFFFFFFFFF 0x0000000000000000) 0x00007FF660B8AD01 (0x0000000000000000 0x000000F0F037EA50 0x00007FF662250898 0x0000000000000000) 0x00007FF660B8DA6D (0x0000000000000000 0x00007FF66014B000 0x0000000000000001 0x00007FF66014B000) 0x00007FF66213E23C (0x0000000000000000 0x00007FF66213E2A4 0x0000000000000000 0x0000000000000000) 0x00007FFA299A29A2 (0x00007FFA299A2980 0x0000000000000000 0x0000000000000000 0x0000000000000000), BaseThreadInitThunk() + 0x22 bytes(s) 0x00007FFA2BD2B454 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), RtlUserThreadStart() + 0x34 bytes(s) clang++.exe: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (https://github.com/llvm-mirror/clang.git e58d2c6fc11a21cd6deac9b2e88095ca7814f161) (https://github.com/llvm-mirror/llvm.git b9fec3eb617427a77d2b73fd962e90bb4b5d734f) Target: x86_64-pc-windows-msvc Thread model: posix clang++.exe: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang++.exe: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang++.exe: note: diagnostic msg: C:\cygwin64\tmp\test-18b0e4.cpp clang++.exe: note: diagnostic msg: C:\cygwin64\tmp\test-18b0e4.sh clang++.exe: note: diagnostic msg: ******************** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 27 11:02:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 27 Jun 2015 18:02:47 +0000 Subject: [LLVMbugs] [Bug 23975] New: Assert in SLSR on Luxmark Hotel Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23975 Bug ID: 23975 Summary: Assert in SLSR on Luxmark Hotel Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: Matthew.Arsenault at amd.com CC: llvmbugs at cs.uiuc.edu, wujingyue at gmail.com Classification: Unclassified Created attachment 14528 --> https://llvm.org/bugs/attachment.cgi?id=14528&action=edit Function reduced testcase Testcase is the function reduced IR, but I'm hitting multiple bugpoint bugs when trying to reduce it further. Run testcase with opt -S -separate-const-offset-from-gep -slsr -o - luxmark_hotel_slsr_crash.ll The SLSR pass crashes attempting to do an invalid RAUW. It is atempting to replace a value of type %struct.Matrix4x4 addrspace(1)* with a value of type float addrspace(1)* opt: /home/matt/src/llvm/lib/IR/Value.cpp:358: void llvm::Value::replaceAllUsesWith(llvm::Value*): Assertion `New->getType() == getType() && "replaceAllUses of value with new value of different type!"' failed. Program received signal SIGABRT, Aborted. 0x00007fffe739d528 in raise () from /usr/lib/libc.so.6 (gdb) bt #0 0x00007fffe739d528 in raise () from /usr/lib/libc.so.6 #1 0x00007fffe739e93a in abort () from /usr/lib/libc.so.6 #2 0x00007fffe73963a7 in __assert_fail_base () from /usr/lib/libc.so.6 #3 0x00007fffe7396452 in __assert_fail () from /usr/lib/libc.so.6 #4 0x00007fffeb1ae2be in llvm::Value::replaceAllUsesWith (this=0x728c88, New=0x763cf0) at /home/matt/src/llvm/lib/IR/Value.cpp:357 #5 0x00007fffe93d765c in (anonymous namespace)::StraightLineStrengthReduce::rewriteCandidateWithBasis (this=0x71fb70, C=..., Basis=...) at /home/matt/src/llvm/lib/Transforms/Scalar/StraightLineStrengthReduce.cpp:677 #6 0x00007fffe93d78dc in (anonymous namespace)::StraightLineStrengthReduce::runOnFunction (this=0x71fb70, F=...) at /home/matt/src/llvm/lib/Transforms/Scalar/StraightLineStrengthReduce.cpp:704 #7 0x00007fffeb15df61 in llvm::FPPassManager::runOnFunction (this=0x746540, F=...) at /home/matt/src/llvm/lib/IR/LegacyPassManager.cpp:1520 #8 0x00007fffeb15e0c0 in llvm::FPPassManager::runOnModule (this=0x746540, M=...) at /home/matt/src/llvm/lib/IR/LegacyPassManager.cpp:1540 #9 0x00007fffeb15e3ef in (anonymous namespace)::MPPassManager::runOnModule (this=0x741050, M=...) at /home/matt/src/llvm/lib/IR/LegacyPassManager.cpp:1596 #10 0x00007fffeb15ea50 in llvm::legacy::PassManagerImpl::run (this=0x740ca0, M=...) at /home/matt/src/llvm/lib/IR/LegacyPassManager.cpp:1698 #11 0x00007fffeb15ec55 in llvm::legacy::PassManager::run (this=0x7fffffffdb20, M=...) at /home/matt/src/llvm/lib/IR/LegacyPassManager.cpp:1729 #12 0x000000000048641d in main (argc=7, argv=0x7fffffffe038) at /home/matt/src/llvm/tools/opt/opt.cpp:599 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 27 12:19:37 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 27 Jun 2015 19:19:37 +0000 Subject: [LLVMbugs] [Bug 23931] Clang allows a virtual member function inside a union In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23931 Davide Italiano changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Davide Italiano --- r240889. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 27 16:54:57 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 27 Jun 2015 23:54:57 +0000 Subject: [LLVMbugs] [Bug 23976] New: Cast linear array to rectangular array compilation failure Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23976 Bug ID: 23976 Summary: Cast linear array to rectangular array compilation failure Product: clang Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: jhart.public at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Reinterpreting a dynamically allocated N*M block of int as an NxM rectangular array fails with clang++ 3.5, producing a spurious error message: test.cpp:5:8: error: non-const lvalue reference to type 'int [n][m]' cannot bind to a value of unrelated type 'int [n][m]' Code compiles successfully on the same platform with gcc 4.9. test case: #include void f(int *mem, int n, int m) { int (&array)[n][m] = *reinterpret_cast(mem); assert((void*)&array == (void*)mem); assert(sizeof(array) == (n*m)*sizeof(int)); } int main() { const int N = 3; const int M = 4; int *p = new int[N*M]; f(p, N, M); delete[] p; } clang++ -v output: Debian clang version 3.5.2-1 (tags/RELEASE_352/final) (based on LLVM 3.5.2) Target: x86_64-pc-linux-gnu -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Jun 27 21:23:46 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 28 Jun 2015 04:23:46 +0000 Subject: [LLVMbugs] [Bug 23963] [Regression][x86_64-w64-mingw32] Failure to compile simple switch-statement due to unrelocatable expression In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23963 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Component|-New Bugs |Driver Resolution|--- |FIXED --- Comment #2 from David Majnemer --- Fixed in r240902. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 28 07:24:38 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 28 Jun 2015 14:24:38 +0000 Subject: [LLVMbugs] [Bug 23977] New: Segmentation fault while compiling duktape Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23977 Bug ID: 23977 Summary: Segmentation fault while compiling duktape Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: matvejchikov at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified $ make clang -Xclang -msoft-float -Xclang -no-implicit-float -c duktape.c 0 libLLVM-3.6.so 0x00007fcd8588f822 llvm::sys::PrintStackTrace(_IO_FILE*) + 50 1 libLLVM-3.6.so 0x00007fcd8588de19 2 libpthread.so.0 0x00007fcd846eb660 3 libLLVM-3.6.so 0x00007fcd853e330a 4 libLLVM-3.6.so 0x00007fcd853e3a0b 5 libLLVM-3.6.so 0x00007fcd853e532f 6 libLLVM-3.6.so 0x00007fcd853e6ba0 7 libLLVM-3.6.so 0x00007fcd84f5a7a7 llvm::FPPassManager::runOnFunction(llvm::Function&) + 487 8 libLLVM-3.6.so 0x00007fcd84f5a9fb llvm::FPPassManager::runOnModule(llvm::Module&) + 43 9 libLLVM-3.6.so 0x00007fcd84f5a401 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 769 10 clang 0x000000000086b9d3 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 3219 11 clang 0x000000000085b4fb 12 clang 0x0000000000a1aeba clang::ParseAST(clang::Sema&, bool, bool) + 826 13 clang 0x00000000006d4b36 clang::FrontendAction::Execute() + 118 14 clang 0x00000000006af2c9 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 313 15 clang 0x0000000000696554 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1828 16 clang 0x0000000000690e40 cc1_main(llvm::ArrayRef, char const*, void*) + 1296 17 clang 0x000000000068de7b main + 955 18 libc.so.6 0x00007fcd83dc1790 __libc_start_main + 240 19 clang 0x0000000000690499 _start + 41 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name duktape.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.25.0 -dwarf-column-info -coverage-file /home/ilya/projects/kjs/kernel/duktape/duktape.c -resource-dir /usr/bin/../lib/clang/3.6.1 -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.6.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir /home/ilya/projects/kjs/kernel/duktape -ferror-limit 19 -fmessage-length 159 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -msoft-float -no-implicit-float -o duktape.o -x c duktape.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'duktape.c'. 4. Running pass 'Fast Register Allocator' on function '@duk_push_number' clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.6.1 (tags/RELEASE_361/final) Target: x86_64-unknown-linux-gnu Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/duktape-3f6af8.c clang: note: diagnostic msg: /tmp/duktape-3f6af8.sh clang: note: diagnostic msg: ******************** Makefile:4: ошибка выполнения рецепта для цели «duktape.o» make: *** [duktape.o] Ошибка 254 "/usr/bin/clang" "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-emit-obj" "-mrelax-all" "-disable-free" "-disable-llvm-verifier" "-main-file-name" "duktape.c" "-mrelocation-model" "static" "-mthread-model" "posix" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-fuse-init-array" "-target-cpu" "x86-64" "-target-linker-version" "2.25.0" "-dwarf-column-info" "-ferror-limit" "19" "-fmessage-length" "159" "-mstackrealign" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-msoft-float" "-no-implicit-float" "-x" "c" "duktape-3f6af8.c" -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 28 10:45:22 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 28 Jun 2015 17:45:22 +0000 Subject: [LLVMbugs] [Bug 23975] Assert in SLSR on Luxmark Hotel In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23975 Jingyue Wu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jingyue Wu --- fixed in 240910 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Jun 28 21:03:19 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 04:03:19 +0000 Subject: [LLVMbugs] [Bug 21439] [mach-o] Fails to find symbols in complicated static libraries. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21439 tamird at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from tamird at gmail.com --- Looks like this is fixed now. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 03:38:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 10:38:39 +0000 Subject: [LLVMbugs] [Bug 23979] New: Cannot copy AL to XMMO Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23979 Bug ID: 23979 Summary: Cannot copy AL to XMMO Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: chfast at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified llc with FastISel (-O0) fails to compile the IR for X86 target. Assert fails with comment: "Cannot copy AL to XMM0. Cannot emit physreg copy instruction." Test code: target triple = "x86_64-unknown-linux-gnu" define <8 x i1> @test() { %C = icmp ult <8 x i16> zeroinitializer, zeroinitializer br label %B B: %I = insertelement <8 x i1> %C, i1 undef, i32 0 ret <8 x i1> %I } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 06:24:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 13:24:47 +0000 Subject: [LLVMbugs] [Bug 23981] New: Ocaml bindings fail to build: in llvm_executionengine nativeint when Int64 expected Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23981 Bug ID: 23981 Summary: Ocaml bindings fail to build: in llvm_executionengine nativeint when Int64 expected Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: Alain.Lichnewsky at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Making LLVM from trunk (commit f03400827bd4865 in git svn Thu Jun 25 10:56:57 2015), when OCaml bindings enabled causes the following error: llvm[3]: Compiling llvm_executionengine.ml for Release+Asserts build File ".../LLVM/build/bindings/ocaml/executionengine/Release+Asserts/llvm_executionengine.ml", line 54, characters 28-77: Error: This expression has type nativeint but an expression was expected of type int64 Configuration details: - system : Linux Ubuntu 64 bits - processor: Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz - OCaml: ocamlc -version 4.01.0 (from Ubuntu distribution) - OCaml libraries (installed for making LLVM): ctypes : commit cfb72eebbac89f* Wed Jun 17 21:45:28 2015 bytes : commit 716589723f39ce* Tue Jun 16 13:17:48 2015 Also, I would like to know if OCaml bindings are actively maintained for use in a project if evaluation turns positive. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 06:43:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 13:43:05 +0000 Subject: [LLVMbugs] [Bug 23982] New: Infinite DAG combining when targeting AVX2 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23982 Bug ID: 23982 Summary: Infinite DAG combining when targeting AVX2 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: chfast at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified When compiling the following test with `llc -mattr=+avx2`: target triple = "x86_64-unknown-linux-gnu" define <16 x i1> @test(<16 x i16> %In) { br label %Header Header: ; preds = %Middle, %Header, %0 %H = shufflevector <16 x i16> %In, <16 x i16> zeroinitializer, <16 x i32> %L = load <8 x i1>, <8 x i1>* undef br i1 undef, label %Header, label %Middle Middle: ; preds = %Header br i1 undef, label %Header, label %Footer Footer: ; preds = %Middle %S = select i1 undef, <8 x i1> undef, <8 x i1> %L %C = icmp slt <16 x i16> %H, undef ret <16 x i1> %C } DAGCombiner goes into infinite loop mode. The repeating combining sequence is: Combining: 0x36247a0: v16i16 = bitcast 0x3623d80 [ORD=2] ... into: 0x3622f40: v16i16 = vector_shuffle 0x3621f30, 0x3627c20<16,1,u,3,u,5,6,7,8,9,10,u,12,u,14,15> [ORD=2] Combining: 0x3627630: v8i32 = X86ISD::BLENDI 0x3629360, 0x36279c0, 0x362b6a0 [ORD=2] Combining: 0x3629100: v16i16 = bitcast 0x36242e0 [ORD=2] Combining: 0x36242e0: v32i8 = vselect 0x361f1f0, 0x3623400, 0x36238c0 [ORD=2] ... into: 0x3621f30: v32i8 = vector_shuffle 0x3623400, 0x36238c0<32,33,2,3,u,u,6,7,u,u,10,11,12,13,14,15,16,17,18,19,20,21,u,u,24,25,u,u,28,29,30,31> [ORD=2] Combining: 0x3629100: v16i16 = bitcast 0x3621f30 [ORD=2] Combining: 0x3627630: v8i32 = X86ISD::BLENDI 0x3629360, 0x36279c0, 0x362b6a0 [ORD=2] Combining: 0x3629100: v16i16 = bitcast 0x36242e0 [ORD=2] ... into: 0x361f1f0: v16i16 = vector_shuffle 0x3623d80, 0x36247a0<16,1,u,3,u,5,6,7,8,9,10,u,12,u,14,15> [ORD=2] Combining: 0x3627630: v8i32 = X86ISD::BLENDI 0x3629360, 0x36279c0, 0x362b6a0 [ORD=2] Combining: 0x3622f40: v16i16 = bitcast 0x3627c20 [ORD=2] Combining: 0x3627c20: v32i8 = vselect 0x3621f30, 0x3623400, 0x36238c0 [ORD=2] ... into: 0x3623d80: v32i8 = vector_shuffle 0x3623400, 0x36238c0<32,33,2,3,u,u,6,7,u,u,10,11,12,13,14,15,16,17,18,19,20,21,u,u,24,25,u,u,28,29,30,31> [ORD=2] Combining: 0x3622f40: v16i16 = bitcast 0x3623d80 [ORD=2] Combining: 0x3627630: v8i32 = X86ISD::BLENDI 0x3629360, 0x36279c0, 0x362b6a0 [ORD=2] Combining: 0x3622f40: v16i16 = bitcast 0x3627c20 [ORD=2] ... into: 0x3621f30: v16i16 = vector_shuffle 0x36242e0, 0x3629100<16,1,u,3,u,5,6,7,8,9,10,u,12,u,14,15> [ORD=2] -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 08:40:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 15:40:51 +0000 Subject: [LLVMbugs] [Bug 23984] New: -Wtautological-compare doesn't warn on comparing default-initialized enums Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23984 Bug ID: 23984 Summary: -Wtautological-compare doesn't warn on comparing default-initialized enums Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Consider this snippet, where someone tried to call GetVersion() but instead default-initialized an enum: $ cat test.cc namespace base { enum Version { kXP, kVista }; Version GetVersion(); } void f() { if (base::Version() == base::kXP) ; } I'd expect that comparison to be flagged by -Wtautological-compare, but it isn't: $ bin/clang -Weverything test.cc -c test.cc:6:6: warning: no previous prototype for function 'f' [-Wmissing-prototypes] void f() { ^ 1 warning generated. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 08:43:14 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 15:43:14 +0000 Subject: [LLVMbugs] [Bug 16154] Clang incorrectly throws -Wtautological-constant-out-of-range-compare with enums In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=16154 Nico Weber changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |nicolasweber at gmx.de Resolution|FIXED |--- --- Comment #3 from Nico Weber --- Unfixed in r183575, right? -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 08:43:28 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 15:43:28 +0000 Subject: [LLVMbugs] [Bug 22062] In C -Wtautological-constant-out-of-range-compare should not trigger for out of range enums In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22062 Nico Weber changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |nicolasweber at gmx.de Resolution|--- |DUPLICATE --- Comment #1 from Nico Weber --- *** This bug has been marked as a duplicate of bug 16154 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 11:38:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 18:38:51 +0000 Subject: [LLVMbugs] [Bug 23985] New: assertion failure when determining c11 _Atomic struct layout Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23985 Bug ID: 23985 Summary: assertion failure when determining c11 _Atomic struct layout Product: clang Version: 3.6 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: michael.b.bassett at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14531 --> https://llvm.org/bugs/attachment.cgi?id=14531&action=edit original source file as well of post-cpp source and clang invocation Received an assertion failure when attempting to compile the bug_case.c (attached): Assertion failed: (Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"), function getTypeSizeInBits, file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.6/clang-3.6/work/llvm-3.6.1.src/include/llvm/IR/DataLayout.h, line 500. A more complicated variant of this case arose when attempting to construct a struct holding a pointer and a counter in order to cope with the ABA problem when implementing a lock-free queue. This construct will arise in many atomic containers composed of linked elements. A workaround is to use a void pointer in struct ptr instead of a pointer to the linked type. This bug is not present in clang-3.5 but is in clang-3.6.1. This same behavior is exhibited as of clang-3.7 (trunk 239386). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 11:47:16 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 18:47:16 +0000 Subject: [LLVMbugs] [Bug 23967] llvm_map_components_to_libnames(XXX all) includes gtest and gtest_main In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23967 Dan Liew changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dan Liew --- Fixed by r240981 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 12:08:35 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 19:08:35 +0000 Subject: [LLVMbugs] [Bug 23986] New: RIP-relative memory references Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23986 Bug ID: 23986 Summary: RIP-relative memory references Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: david.l.kreitzer at intel.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified llvm-mc is encoding some RIP-relative instructions incorrectly by failing to relax arith imm8 instruction forms. For example: ------------- t.s ----------------- bar: .section imul imul $foo, bar(%rip), %bx imul $foo, bar(%rip), %ebx imul $foo, bar(%rip), %rbx ----------------------------------- This is the current behavior. Note that in each case, $foo is encoded as an 8-bit immediate even though it is not guaranteed to fit in 8 bits. bash-4.3$ llvm-mc -filetype=obj -triple x86_64-pc-linux-gnu t.s -o t.o bash-4.3$ objdump -d --section=imul t.o t.o: file format elf64-x86-64 Disassembly of section imul: 0000000000000000 : 0: 66 6b 1d 00 00 00 00 imul $0x0,0x0(%rip),%bx # 8 7: 00 8: 6b 1d 00 00 00 00 00 imul $0x0,0x0(%rip),%ebx # f f: 48 6b 1d 00 00 00 00 imul $0x0,0x0(%rip),%rbx # 17 16: 00 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 13:13:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 20:13:39 +0000 Subject: [LLVMbugs] [Bug 23985] assertion failure when determining c11 _Atomic struct layout In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23985 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com |org | --- Comment #3 from David Majnemer --- Fixed in r240989. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 13:13:14 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 20:13:14 +0000 Subject: [LLVMbugs] [Bug 23987] New: -Wnullability-completeness broken for templated types Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23987 Bug ID: 23987 Summary: -Wnullability-completeness broken for templated types Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: b17c0de at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Consider the following code in a header: _Pragma("clang assume_nonnull begin") template inline void f(T x) {} _Pragma("clang assume_nonnull end") This gives the following bogus warning: ./nullability.h:3:15: warning: pointer is missing a nullability type specifier (__nonnull or __nullable) [-Wnullability-completeness] -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 13:19:42 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 20:19:42 +0000 Subject: [LLVMbugs] [Bug 23427] WinEHPrepare failed to demote instruction In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23427 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Reid Kleckner --- Duping Windows EH bugs against PR22975. *** This bug has been marked as a duplicate of bug 22975 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 13:19:59 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 20:19:59 +0000 Subject: [LLVMbugs] [Bug 23557] WinEHPrepare failed to demote instruction In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23557 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rnk at google.com Resolution|--- |DUPLICATE --- Comment #3 from Reid Kleckner --- Duping Windows EH bugs against PR22975. *** This bug has been marked as a duplicate of bug 22975 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 13:18:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 20:18:39 +0000 Subject: [LLVMbugs] [Bug 23974] [MS] Crash while trying to compile code with exceptions In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23974 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rnk at google.com Resolution|--- |DUPLICATE --- Comment #1 from Reid Kleckner --- Duping Windows EH bugs against PR22975. *** This bug has been marked as a duplicate of bug 22975 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 13:21:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 20:21:40 +0000 Subject: [LLVMbugs] [Bug 23518] "PHI node entries do not match predecessors" (fatal error: error in backend), having an array as data member In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23518 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Reid Kleckner --- Duping Windows EH bugs against PR22975. *** This bug has been marked as a duplicate of bug 22975 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 13:22:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 20:22:26 +0000 Subject: [LLVMbugs] [Bug 23520] Symbol must already have been defined in ExecutePostLayoutBinding In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23520 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Reid Kleckner --- Duping Windows EH bugs against PR22975. *** This bug has been marked as a duplicate of bug 22975 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 14:02:25 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 21:02:25 +0000 Subject: [LLVMbugs] [Bug 23988] New: thumbv7 instruction selection failure v2i64 = cttz Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23988 Bug ID: 23988 Summary: thumbv7 instruction selection failure v2i64 = cttz Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM Assignee: unassignedbugs at nondot.org Reporter: chh at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14532 --> https://llvm.org/bugs/attachment.cgi?id=14532&action=edit preprocessed .cpp file and compilation command Enclosed are script and source to reproduce a crash in NDK clang (*1). It crashes upstream clang too (revision 239800). Looks like cost model has changed which invalidates the workaround for the last crash: https://android-review.googlesource.com/#/c/120011/1/lib/Target/ARM/ARMTargetTransformInfo.cpp . Investigating fatal error: error in backend: Cannot select: 0xe035d80: v2i64 = cttz 0xe035264 [ORD=4] [ID=34] dbg:/usr/local/google/_blaze_wuu/7e341fa8ce94ae7e022303126d53824a/google3/util/bits/bits.h:297:10 0xe035264: v2i64 = bitcast 0xe03649c [ORD=3] [ID=28] dbg:/usr/local/google/_blaze_wuu/7e341fa8ce94ae7e022303126d53824a/google3/util/geometry/s2cellid.h:438:49 0xe03649c: v2f64,ch = load 0xd66fd20, 0xdfa70ec, 0xe035408 [ORD=3] [ID=23] dbg:/usr/local/google/_blaze_wuu/7e341fa8ce94ae7e022303126d53824a/google3/util/geometry/s2cellid.h:438:49 0xdfa70ec: i32,ch = CopyFromReg 0xd66fd20, 0xdfaac80 [ORD=2] [ID=18] 0xdfaac80: i32 = Register %vreg7 [ID=1] 0xe035408: i32 = undef [ID=3] In function: _ZNK11S2CellUnion16LeafCellsCoveredEv -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 14:37:15 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 21:37:15 +0000 Subject: [LLVMbugs] [Bug 23955] Upper 8 registers are no longer available to asm statement In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23955 Matthias Braun changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Matthias Braun --- Recommitted the patch with a fix for this in r241002. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 15:05:34 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 22:05:34 +0000 Subject: [LLVMbugs] [Bug 23827] bad generated code for conditionals connected by (&) In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23827 Sanjay Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID |--- --- Comment #10 from Sanjay Patel --- I've attached a test program (test harness in C, actual tests in asm) to check performance of the current branch optimization that's happening for x86 in the DAG. To try it out on Linux or Mac: $ clang 23827_tester.c 23827_tests.s $ ./a.out As-is, the test program is modeling this C code: extern int bar();//{ return 0; } int foo(int x, int y) { if (x != 0 && y != 0) return bar(); return 1; } I used clang to compile that down to asm while toggling the setJumpIsExpensive() hook. The 'super' cases are the asm for a bigger compound predicate because the DAG optimization appears to happily turn any size predicate into multiple branches: extern int bar();//{ return 0; } int foo(int w, int x, int y, int z) { if (w != 0 && x != 0 && y != 0 && z != 0) return bar(); return 1; } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 16:19:33 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 23:19:33 +0000 Subject: [LLVMbugs] [Bug 23942] Some invalid pure-specifiers incorrectly accepted In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23942 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |FIXED --- Comment #2 from Richard Smith --- Fixed in r241019. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 16:34:46 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 29 Jun 2015 23:34:46 +0000 Subject: [LLVMbugs] [Bug 23990] New: [MS ABI] Clang crashes emitting array delete Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23990 Bug ID: 23990 Summary: [MS ABI] Clang crashes emitting array delete Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: david.majnemer at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified consider: struct S { int x; void *operator new[](size_t); void operator delete[](void *p, size_t); }; void f(S *s) { delete [] s; } we crash in CallArrayDelete::Emit because we are trying to multiple by NumElements. However, NumElements is null because we decided we didn't need an array cookie. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 20:31:09 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 30 Jun 2015 03:31:09 +0000 Subject: [LLVMbugs] [Bug 23990] [MS ABI] Clang crashes emitting array delete In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23990 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com |org | --- Comment #1 from David Majnemer --- Fixed in r241038. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Jun 29 21:41:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 30 Jun 2015 04:41:52 +0000 Subject: [LLVMbugs] [Bug 23964] -fno-builtin is broken In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23964 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Component|new bugs |LLVM Codegen Resolution|--- |FIXED Assignee|unassignedbugs at nondot.org |unassignedclangbugs at nondot. | |org Product|new-bugs |clang --- Comment #20 from David Majnemer --- Fixed in r241043. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 01:48:21 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 30 Jun 2015 08:48:21 +0000 Subject: [LLVMbugs] [Bug 23991] New: ObjectLinkingLayer should deregister EH frame Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23991 Bug ID: 23991 Summary: ObjectLinkingLayer should deregister EH frame Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: OrcJIT Assignee: unassignedbugs at nondot.org Reporter: tom.aernoudt at synopsys.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified llvm::Orc::ObjectLinkingLayer should deregister EH Frames when an objectSet is removed (removeObjectSet) or when it is destructed (~ObjectLinkingLayer) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 03:15:42 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 30 Jun 2015 10:15:42 +0000 Subject: [LLVMbugs] [Bug 2921] alloca >4k stack probes on windows/visual studio In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=2921 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Anton Korobeynikov --- Fixed long ago -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 03:22:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 30 Jun 2015 10:22:56 +0000 Subject: [LLVMbugs] [Bug 23992] New: CloneModule does not remap personality of a function correctly Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23992 Bug ID: 23992 Summary: CloneModule does not remap personality of a function correctly Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Transformation Utilities Assignee: unassignedbugs at nondot.org Reporter: tom.aernoudt at synopsys.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14537 --> https://llvm.org/bugs/attachment.cgi?id=14537&action=edit testcase It looks like the CloneModule utility function does not remap the personality operand of a function correctly. After cloning the module following assert is triggered when printing the module with module->print(llvm::outs(), 0, true): testCloneModule: /localdev/aernoudt/programs/llvm/git/llvm/lib/IR/AsmWriter.cpp:203: void predictValueUseListOrder(const llvm::Value*, const llvm::Function*, {anonymous}::OrderMap&, llvm::UseListOrderStack&): Assertion `IDPair.first && "Unmapped value"' failed. The unmapped value is the personality operand of the function testFunction. The issue can be reproduced with the attached testcase (on a debug build of llvm): > clang++ -c -O3 -std=c++11 -emit-llvm -o test.bc test.cc > g++ `llvm-config --cxxflags` -o testCloneModule testCloneModule.cc `llvm-config --ldflags` `llvm-config --system-libs --libs core ipo bitreader irreader` > ./cloneModule --> Fail: assert triggered Disabling exceptions, which removes the personality operand of the function testFunction makes the test pass: > clang++ -c -O3 -std=c++11 -emit-llvm -DNO_EXCEPTIONS -fno-exceptions -o test.bc test.cc > g++ `llvm-config --cxxflags` -o testCloneModule testCloneModule.cc `llvm-config --ldflags` `llvm-config --system-libs --libs core ipo bitreader irreader` > ./cloneModule --> Ok -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 06:08:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 30 Jun 2015 13:08:56 +0000 Subject: [LLVMbugs] [Bug 23993] New: clang-cl /arch:IA32 generates CMOV instructions not supported by selected arch Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23993 Bug ID: 23993 Summary: clang-cl /arch:IA32 generates CMOV instructions not supported by selected arch Product: clang Version: 3.6 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: amadvance at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Using clang-cl /arch:IA32 should not generate CMOV instructions that are not supported by a generic i686. Visual Studio documentation is clear about that. CMOV instructions should be generated only with /arch:SSE2. See: https://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx "In addition to using the SSE and SSE2 instructions, the compiler also uses other instructions that are present on the processor revisions that support SSE and SSE2. An example is the CMOV instruction that first appeared on the Pentium Pro revision of the Intel processors." The problem seems to be the "-target-cpu pentium4" selection. A "i686" would work. A workaround is to add in the command line: -Xclang -target-cpu -Xclang i686 Here an example with clang 3.6.0: ...> type test.c extern int i; extern int j; int f(int g) { i++; if (g) return j; else return 1; } ...> clang-cl -O2 /arch:IA32 -v -c test.c -o test.obj clang version 3.6.0 (tags/RELEASE_360/final) Target: i686-pc-windows-msvc Thread model: posix "D:\\compiler\\clang-3.6\\bin\\clang-cl.exe" -cc1 -triple i686-pc-windows-msvc -emit-obj -disable-free -main-file-name test.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -relaxed-aliasing -fmath-errno -masm-verbose -mc onstructor-aliases -target-cpu pentium4 -D_MT --dependent-lib=libcmt --dependent-lib=oldnames -fdiagnostics-format msvc -v -dwarf-column-info -coverage-file "C:\\Users\\am\\Desktop\\clangtest\\test.c" -resource-dir "D:\\compiler\\clang-3.6\ \bin\\..\\lib\\clang\\3.6.0" -internal-isystem "D:\\compiler\\clang-3.6\\bin\\..\\lib\\clang\\3.6.0\\include" -internal- isystem "d:\\compiler\\msvc71\\vc7\\include" -internal-isystem "d:\\compiler\\msvc71\\vc7\\atlmfc\\include" -internal-is ystem "d:\\compiler\\msvc71\\vc7\\PlatformSDK\\include" -O2 -fdebug-compilation-dir "C:\\Users\\am\\Desktop\\clangtest" -ferror-limit 19 -fmessage-length 120 -mstackrealign -fms-extensions -fms-compatibility -fms-compatibility-version=17.00 -fdelayed-template-parsing -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize -slp -o test.obj -x c test.c clang -cc1 version 3.6.0 based upon LLVM 3.6.0 default target i686-pc-windows-gnu #include "..." search starts here: #include <...> search starts here: D:\compiler\clang-3.6\bin\..\lib\clang\3.6.0\include d:\compiler\msvc71\vc7\include d:\compiler\msvc71\vc7\atlmfc\include d:\compiler\msvc71\vc7\PlatformSDK\include End of search list. ...> dumpbin /DISASM test.obj Dump of file test.obj File Type: COFF OBJECT _f: 00000000: 55 push ebp 00000001: 89 E5 mov ebp,esp 00000003: FF 05 00 00 00 00 inc dword ptr [_i] 00000009: 83 7D 08 00 cmp dword ptr [ebp+8],0 0000000D: B8 01 00 00 00 mov eax,1 00000012: 0F 45 05 00 00 00 cmovne eax,dword ptr [_j] 00 00000019: 5D pop ebp 0000001A: C3 ret -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 07:59:48 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 30 Jun 2015 14:59:48 +0000 Subject: [LLVMbugs] [Bug 23957] Assertion `UpdatedSlot < StackTop && Dest < 7' failed on i686 MSVC In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23957 Michael Kuperstein changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |michael.m.kuperstein at intel. | |com Resolution|--- |FIXED --- Comment #3 from Michael Kuperstein --- Fixed in r241069. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 08:53:30 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 30 Jun 2015 15:53:30 +0000 Subject: [LLVMbugs] [Bug 23995] New: clang segfaults while doing decltype(auto) with a template Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23995 Bug ID: 23995 Summary: clang segfaults while doing decltype(auto) with a template Product: clang Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangbugs at nondot.org Reporter: bloch_j at epita.fr CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14541 --> https://llvm.org/bugs/attachment.cgi?id=14541&action=edit The compilation logs Steps to Reproduce: $ cat sigsegv.cpp template int fun() { return 0; } int main() { int tata = 0; decltype(auto) a = fun; } $ clang++ -o sigsegv -std=c++11 sigsegv.cpp # The dump is in attachment. Actual Results: clang segfaults Expected Results: Fail compilation with an error. (cf gcc behavior in attachment) Additional information: Without the decltype or the template, clang does not crash. The same problem appears compiling with c++ standard >= 0x. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 10:24:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 30 Jun 2015 17:24:05 +0000 Subject: [LLVMbugs] [Bug 23616] TSAN incorrectly models condition variable semantics In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23616 Dmitry Vyukov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Dmitry Vyukov --- Fixed in r241082. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 12:45:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 30 Jun 2015 19:45:17 +0000 Subject: [LLVMbugs] [Bug 23993] clang-cl /arch:IA32 generates CMOV instructions not supported by selected arch In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23993 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rnk at google.com Resolution|--- |FIXED --- Comment #1 from Reid Kleckner --- Thanks for the report. I added handling for /arch: along with -march= in r241077. Your test case no longer uses cmov. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 14:33:33 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 30 Jun 2015 21:33:33 +0000 Subject: [LLVMbugs] [Bug 23996] New: Incorrect/inefficient pushw encodings for x86-64 targets Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23996 Bug ID: 23996 Summary: Incorrect/inefficient pushw encodings for x86-64 targets Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: david.l.kreitzer at intel.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Below is an illustration of the problems. The first pushw is incorrectly encoded as pushq. The second pushw is encoded correctly but inefficiently as it uses a 16-bit immediate rather than an 8-bit immediate. Note also that the gas-generated instruction "66 6a 2a" is incorrectly printed by llvm-objdump as pushq. All 3 problems can be fixed by fixing the instruction descriptors for the 16-bit push immediate forms. ------------------------------ bash-4.3$ cat t.s .section push,"x" pushw $foo pushw $42 bash-4.3$ llvm-mc t.s -filetype=obj -o - | llvm-objdump -d - : file format ELF64-x86-64 Disassembly of section push: push: 0: 68 00 00 00 00 pushq $0 5: 66 68 2a 00 pushw $42 bash-4.3$ gcc -c t.s && llvm-objdump -d t.o t.o: file format ELF64-x86-64 Disassembly of section push: push: 0: 66 68 00 00 pushw $0 4: 66 6a 2a pushq $42 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 14:54:13 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 30 Jun 2015 21:54:13 +0000 Subject: [LLVMbugs] [Bug 23907] Assertion Failure: SelectionDAGBuilder.cpp Name "not null terminated" handling @llvm.framerecover In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23907 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Reid Kleckner --- This was probably fixed by r240300. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 15:02:00 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 30 Jun 2015 22:02:00 +0000 Subject: [LLVMbugs] [Bug 23997] New: LoopVectorizer dropping inbounds from GEPs Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23997 Bug ID: 23997 Summary: LoopVectorizer dropping inbounds from GEPs Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedbugs at nondot.org Reporter: listmail at philipreames.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I've noticed that the LoopVectorizer seems to not mark the GEPs it generates as inbounds, even when the original GEPs being replaced are in bounds. Specifically, this can be reproduced with just about any vectorizable loop which contains either a load or store to a loop variant location derived from a pointer typed induction variable. Consider: define void @test2(i8* %base, i8* %end) { entry: br label %loop loop: %p = phi i8* [%base, %entry], [%next, %loop] store i8 0, i8* %p %next = getelementptr inbounds i8, i8* %p, i64 1 %cmp = icmp slt i8* %p, %end br i1 %cmp, label %loop, label %exit exit: ret void } The generated code for vector.body is: vector.body %index = phi i64 [ %index.next, %vector.body ], [ 0, %overflow.checked ] %next.gep = getelementptr i8, i8* %base, i64 %index ;;<-- KEY LINE %4 = bitcast i8* %next.gep to <4 x i8>* store <4 x i8> zeroinitializer, <4 x i8>* %4, align 1 %index.next = add i64 %index, 4 %5 = icmp eq i64 %index.next, %n.vec br i1 %5, label %middle.block, label %vector.body, !llvm.loop !5 Interestingly, using a integer induction variable for this loop and then deriving p off of that on every iteration does end up with the new phis having inbounds. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 15:14:34 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 30 Jun 2015 22:14:34 +0000 Subject: [LLVMbugs] [Bug 23992] CloneModule does not remap personality of a function correctly In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23992 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from David Majnemer --- Fixed in r241122. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 15:36:20 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 30 Jun 2015 22:36:20 +0000 Subject: [LLVMbugs] [Bug 23998] New: ARM inline asm - cp10/cp11 rejected under armv7a Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23998 Bug ID: 23998 Summary: ARM inline asm - cp10/cp11 rejected under armv7a Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: shenhan at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified glibc macro FPU_GETCW, FPU_SETCP (see below) is rejected by clang because ARMAsmParser thinks that cp10, cp11 is not accessible under armv7/armv8. That's not correct for armv7a with neon/vfp feature. According to ARMv7a Architecture Reference manual - A2.9 Any implementation that includes either or both of the Advanced SIMD extension and the VFP extension must enable access to both CP10 and CP11. Code reference - > sysdeps/arm/fpu__control.h #define _FPU_GETCW(cw) \ __asm__ __volatile__ ("mrc p10, 7, %0, cr1, cr0, 0" : "=r" (cw)) #define _FPU_SETCW(cw) \ __asm__ __volatile__ ("mcr p10, 7, %0, cr1, cr0, 0" : : "r" (cw)) > ARMAsmParser.cpp - ARMAsmParser::OperandMatchResultTy ... ... // ARMv7 and v8 don't allow cp10/cp11 due to VFP/NEON specific instructions if ((hasV7Ops() || hasV8Ops()) && (Num == 10 || Num == 11)) return MatchOperand_NoMatch; -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 16:15:21 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 30 Jun 2015 23:15:21 +0000 Subject: [LLVMbugs] [Bug 23999] New: Clang trunk segfault when compiling sdl2_gfx Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23999 Bug ID: 23999 Summary: Clang trunk segfault when compiling sdl2_gfx Product: clang Version: trunk Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: amdmi3 at amdmi3.ru CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified On FreeBSD 11, while compiling sdl2_gfx package (http://www.ferzkopp.net/Software/SDL_gfx-2.0/) with MMX support enabled (CFLAGS=-DMMX): --- clang: error: unable to execute command: Segmentation fault clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (trunk) Target: x86_64-portbld-freebsd11.0 Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. libtool: compile: clang-devel -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"SDL2_gfx\" -DVERSION=\"1.0.1\" -DSIZEOF_LONG=8 -I. -O2 -pipe -DUSE_MMX -fstack-protector -fno-strict-aliasing -O -DUSE_MMX -I/usr/local/include/SDL2 -I/usr/local/include -D_REENTRANT -D_THREAD_SAFE -MT SDL2_gfxPrimitives.lo -MD -MP -MF .deps/SDL2_gfxPrimitives.Tpo -c SDL2_gfxPrimitives.c -o SDL2_gfxPrimitives.o >/dev/null 2>&1 clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/SDL2_imageFilter-12485b.c clang: note: diagnostic msg: /tmp/SDL2_imageFilter-12485b.sh clang: note: diagnostic msg: ******************** Makefile:426: recipe for target 'SDL2_imageFilter.lo' failed --- Happens both with system clang 3.6.1: FreeBSD clang version 3.6.1 (tags/RELEASE_361/final 237755) 20150525 Target: x86_64-unknown-freebsd11.0 Thread model: posix and clang 3.7 (r236894) from ports: clang version 3.7.0 (trunk) Target: x86_64-portbld-freebsd11.0 Thread model: posix Mentioned files attached. For the note, the problem does not show itself if -march=nocona is added to compiler flags. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 17:30:06 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Jul 2015 00:30:06 +0000 Subject: [LLVMbugs] [Bug 23995] clang segfaults while doing decltype(auto) with a template In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23995 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com |org | --- Comment #2 from David Majnemer --- Fixed in r241131. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 20:14:02 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Jul 2015 03:14:02 +0000 Subject: [LLVMbugs] [Bug 24000] New: clang 3.6.1 crashes when building codeblocks on FreeBSD Message-ID: https://llvm.org/bugs/show_bug.cgi?id=24000 Bug ID: 24000 Summary: clang 3.6.1 crashes when building codeblocks on FreeBSD Product: clang Version: 3.6 Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: amdmi3 at amdmi3.ru CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified FreeBSD current, clang from base system: FreeBSD clang version 3.6.1 (tags/RELEASE_361/final 237755) 20150525 Target: x86_64-unknown-freebsd11.0 Thread model: posix Trying to compile codeblocks (http://www.codeblocks.org/) --- /bin/sh ../../libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I../../src/include -I/usr/local/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -D_THREAD_SAFE -I../../src/include -I../../src/sdk/wxscintilla/include -I../../src/sdk/wxpropgrid/include -I../../src/include/tinyxml -I../../src/include/scripting/include -I../../src/include/scripting/bindings -I../../src/include/scripting/sqplus -I../../src/include/mozilla_chardet -I../../src/include/mozilla_chardet/mfbt -I../../src/include/mozilla_chardet/nsprpub/pr/include -I../../src/include/mozilla_chardet/xpcom -I../../src/include/mozilla_chardet/xpcom/base -I../../src/include/mozilla_chardet/xpcom/glue -I/usr/local/include -ansi -DTIXML_USE_STL -O2 -ffast-math -DCB_AUTOCONF -O2 -pipe -march=nocona -fstack-protector -fno-strict-aliasing -std=c++11 -fPIC -DPIC -fexceptions -MT cbthreadpool.lo -MD -MP -MF .deps/cbthreadpool.Tpo -c -o cbthreadpool.lo cbthreadpool.cpp libtool: compile: c++ -DHAVE_CONFIG_H -I. -I../../src/include -I/usr/local/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -D_THREAD_SAFE -I../../src/include -I../../src/sdk/wxscintilla/include -I../../src/sdk/wxpropgrid/include -I../../src/include/tinyxml -I../../src/include/scripting/include -I../../src/include/scripting/bindings -I../../src/include/scripting/sqplus -I../../src/include/mozilla_chardet -I../../src/include/mozilla_chardet/mfbt -I../../src/include/mozilla_chardet/nsprpub/pr/include -I../../src/include/mozilla_chardet/xpcom -I../../src/include/mozilla_chardet/xpcom/base -I../../src/include/mozilla_chardet/xpcom/glue -I/usr/local/include -ansi -DTIXML_USE_STL -O2 -ffast-math -DCB_AUTOCONF -O2 -pipe -march=nocona -fstack-protector -fno-strict-aliasing -std=c++11 -fPIC -DPIC -fexceptions -MT cbthreadpool.lo -MD -MP -MF .deps/cbthreadpool.Tpo -c cbthreadpool.cpp -fPIC -DPIC -o .libs/cbthreadpool.o Assertion failed: (EST == EST_Dynamic && "EST case not considered earlier."), function CalledDecl, file /usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaDeclCXX.cpp, line 210. Stack dump: 0. Program arguments: /usr/bin/c++ -cc1 -triple x86_64-unknown-freebsd11.0 -emit-obj -disable-free -main-file-name cbthreadpool.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -relaxed-aliasing -menable-no-infs -menable-no-nans -menable-unsafe-fp-math -ffp-contract=fast -ffast-math -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu nocona -dwarf-column-info -coverage-file /ssd/batchports-mem/devel/codeblocks/work/codeblocks-13.12/src/sdk/.libs/cbthreadpool.o -resource-dir /usr/bin/../lib/clang/3.6.1 -dependency-file .deps/cbthreadpool.Tpo -sys-header-deps -MP -MT cbthreadpool.lo -D HAVE_CONFIG_H -D _FILE_OFFSET_BITS=64 -D _LARGE_FILES -D __WXGTK__ -D _THREAD_SAFE -D TIXML_USE_STL -D CB_AUTOCONF -D PIC -D PIC -I . -I ../../src/include -I /usr/local/lib/wx/include/gtk2-unicode-release-2.8 -I /usr/local/include/wx-2.8 -I ../../src/include -I ../../src/sdk/wxscintilla/include -I ../../src/sdk/wxpropgrid/include -I ../../src/include/tinyxml -I ../../src/include/scripting/include -I ../../src/include/scripting/bindings -I ../../src/include/scripting/sqplus -I ../../src/include/mozilla_chardet -I ../../src/include/mozilla_chardet/mfbt -I ../../src/include/mozilla_chardet/nsprpub/pr/include -I ../../src/include/mozilla_chardet/xpcom -I ../../src/include/mozilla_chardet/xpcom/base -I ../../src/include/mozilla_chardet/xpcom/glue -I /usr/local/include -internal-isystem /usr/include/c++/v1 -O2 -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /ssd/batchports-mem/devel/codeblocks/work/codeblocks-13.12/src/sdk -ferror-limit 19 -fmessage-length 0 -pthread -stack-protector 1 -mstackrealign -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o .libs/cbthreadpool.o -x c++ cbthreadpool.cpp 1. ../../src/include/cbthreadpool.h:180:33: current parser token ';' 2. ../../src/include/cbthreadpool.h:19:1: parsing struct/union/class body 'cbThreadPool' c++: error: unable to execute command: Abort trap c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 3.6.1 (tags/RELEASE_361/final 237755) 20150525 Target: x86_64-unknown-freebsd11.0 Thread model: posix c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/cbthreadpool-737e5c.cpp c++: note: diagnostic msg: /tmp/cbthreadpool-737e5c.sh c++: note: diagnostic msg: ******************** *** Error code 1 Stop. --- https://people.freebsd.org/~amdmi3/cbthreadpool-737e5c.cpp https://people.freebsd.org/~amdmi3/cbthreadpool-737e5c.sh clang head, however, doesn't have this problem, just reporting c++ error (below), so I guess the bug may already be fixed, but reporting anyway just to be safe. --- /bin/sh ../../libtool --tag=CXX --mode=compile clang++-devel -DHAVE_CONFIG_H -I. -I../../src/include -I/usr/local/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -D_THREAD_SAFE -I../../src/include -I../../src/sdk/wxscintilla/include -I../../src/sdk/wxpropgrid/include -I../../src/include/tinyxml -I../../src/include/scripting/include -I../../src/include/scripting/bindings -I../../src/include/scripting/sqplus -I../../src/include/mozilla_chardet -I../../src/include/mozilla_chardet/mfbt -I../../src/include/mozilla_chardet/nsprpub/pr/include -I../../src/include/mozilla_chardet/xpcom -I../../src/include/mozilla_chardet/xpcom/base -I../../src/include/mozilla_chardet/xpcom/glue -I/usr/local/include -ansi -DTIXML_USE_STL -O2 -ffast-math -DCB_AUTOCONF -O2 -pipe -fstack-protector -fno-strict-aliasing -std=c++11 -fPIC -DPIC -fexceptions -MT cbthreadpool.lo -MD -MP -MF .deps/cbthreadpool.Tpo -c -o cbthreadpool.lo cbthreadpool.cpp libtool: compile: clang++-devel -DHAVE_CONFIG_H -I. -I../../src/include -I/usr/local/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -D_THREAD_SAFE -I../../src/include -I../../src/sdk/wxscintilla/include -I../../src/sdk/wxpropgrid/include -I../../src/include/tinyxml -I../../src/include/scripting/include -I../../src/include/scripting/bindings -I../../src/include/scripting/sqplus -I../../src/include/mozilla_chardet -I../../src/include/mozilla_chardet/mfbt -I../../src/include/mozilla_chardet/nsprpub/pr/include -I../../src/include/mozilla_chardet/xpcom -I../../src/include/mozilla_chardet/xpcom/base -I../../src/include/mozilla_chardet/xpcom/glue -I/usr/local/include -ansi -DTIXML_USE_STL -O2 -ffast-math -DCB_AUTOCONF -O2 -pipe -fstack-protector -fno-strict-aliasing -std=c++11 -fPIC -DPIC -fexceptions -MT cbthreadpool.lo -MD -MP -MF .deps/cbthreadpool.Tpo -c cbthreadpool.cpp -fPIC -DPIC -o .libs/cbthreadpool.o In file included from cbthreadpool.cpp:18: ../../src/include/cbthreadpool.h:112:11: error: exception specification of overriding function is more lax than base version class cbWorkerThread : public wxThread ^ /usr/include/c++/v1/memory:1409:22: note: in instantiation of template class 'std::__1::allocator' requested here typedef typename allocator_type::value_type value_type; ^ /usr/include/c++/v1/vector:337:22: note: in instantiation of template class 'std::__1::allocator_traits >' requested here typedef typename __alloc_traits::size_type size_type; ^ /usr/include/c++/v1/vector:478:15: note: in instantiation of template class 'std::__1::__vector_base >' requested here : private __vector_base<_Tp, _Allocator> ^ ../../src/include/cbthreadpool.h:180:24: note: in instantiation of template class 'std::__1::vector >' requested here WorkerThreadsArray m_threads; // the working threads are stored here ^ /usr/local/include/wx-2.8/wx/thread.h:563:13: note: overridden virtual function is here virtual ~wxThread(); ^ In file included from cbthreadpool.cpp:18: ../../src/include/cbthreadpool.h:188:29: error: exception specification is not available until end of class definition CountedPtr m_semaphore; // used to synchronise the Worker Threads ^ ../../src/include/cbthreadpool.h:188:29: error: exception specification is not available until end of class definition ../../src/include/cbthreadpool.h:98:9: error: exception specification is not available until end of class definition ~CountedPtr() throw(); ^ ../../src/include/cbthreadpool.h:223:22: note: in instantiation of member function 'cbThreadPool::CountedPtr::~CountedPtr' requested here inline cbThreadPool::cbThreadPool(wxEvtHandler *owner, int id, int concurrentThreads, unsigned int stackSize) ^ 4 errors generated. --- -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 20:33:42 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Jul 2015 03:33:42 +0000 Subject: [LLVMbugs] [Bug 24001] New: Missing revision number in "landed in this commit" message. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=24001 Bug ID: 24001 Summary: Missing revision number in "landed in this commit" message. Product: Website Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Phabricator Assignee: unassignedbugs at nondot.org Reporter: chisophugis at gmail.com CC: klimek at google.com, llvmbugs at cs.uiuc.edu Classification: Unclassified I'm seeing this fragment in emails after a Phab review is closed by a commit: REPOSITORY rL LLVM It seems like the `rL` is supposed to be followed by the revision number? That would certainly be more useful. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 21:20:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Jul 2015 04:20:52 +0000 Subject: [LLVMbugs] [Bug 24001] Missing revision number in "landed in this commit" message. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=24001 David Blaikie changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dblaikie at gmail.com Resolution|--- |DUPLICATE --- Comment #1 from David Blaikie --- *** This bug has been marked as a duplicate of bug 23859 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Jun 30 22:43:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Jul 2015 05:43:56 +0000 Subject: [LLVMbugs] [Bug 23999] Clang trunk segfault when compiling sdl2_gfx In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23999 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Component|C++ |Scalar Optimizations Resolution|--- |FIXED Assignee|unassignedclangbugs at nondot. |unassignedbugs at nondot.org |org | Product|clang |libraries --- Comment #3 from David Majnemer --- Fixed in r241142 and r241143. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: