[llvm-bugs] [Bug 25368] New: Namespace lost in modules
https://llvm.org/bugs/show_bug.cgi?id=25368
Bug ID: 25368
Summary: Namespace lost in modules
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Modules
Assignee: unassignedclangb...@nondot.org
Reporter: geek4ci...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Classification: Unclassified
Created attachment 15198
--> https://llvm.org/bugs/attachment.cgi?id=15198&action=edit
Small testcase.zip
I didn't compile lib/CodeGen/CGExprConstant.cpp with -fcxx-modules.
clang/lib/CodeGen/CGExprConstant.cpp:1041:16: error:
no matching function for call to 'cast'
return cast(Res.getAddress());
^
llvm/include/llvm/Support/Casting.h:229:44: note:
candidate function [with X = clang::CodeGen::ConstantAddress, Y =
clang::CodeGen::Address] not viable: expects an l-value for 1st argument
inline typename cast_retty::ret_type cast(Y &Val) {
^
Seems namespace forwarders, Basic/LLVM.h, might not be effective there.
Appeased in r251713.
A small testcase is attached.
$ clang++ -std=c++11 -fmodules -fcxx-modules -c a.cc
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25369] New: [SCEV] Assertion `PN->getNumIncomingValues() == 2 && "Follows from having one latch!"' failed.
https://llvm.org/bugs/show_bug.cgi?id=25369 Bug ID: 25369 Summary: [SCEV] Assertion `PN->getNumIncomingValues() == 2 && "Follows from having one latch!"' failed. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: tob...@grosser.es CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15199 --> https://llvm.org/bugs/attachment.cgi?id=15199&action=edit Test case Since r249712 SCEV fails to compute backedge taken counts for loops with more than one entering edge (to the loop header). This has been working before. opt -scalar-evolution -analyze out.ll Printing analysis 'Scalar Evolution Analysis' for function 'hoge': Classifying expressions for: @hoge %tmp = add i32 %tmp10, -1 --> (-1 + (2 * undef) + %tmp7 + %tmp6) U: full-set S: full-setopt: /home/grosser/Projects/polly/git/lib/Analysis/ScalarEvolution.cpp:5757: llvm::Constant *llvm::ScalarEvolution::getConstantEvolutionLoopExitValue(llvm::PHINode *, const llvm::APInt &, const llvm::Loop *): Assertion `PN->getNumIncomingValues() == 2 && "Follows from having one latch!"' failed. 0 opt 0x01869e4e llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 46 1 opt 0x0186af89 2 opt 0x018699c3 llvm::sys::RunSignalHandlers() + 131 3 opt 0x0186b1e4 4 libpthread.so.0 0x7fac6085dd10 5 libc.so.6 0x7fac5ff96267 gsignal + 55 6 libc.so.6 0x7fac5ff97eca abort + 362 7 libc.so.6 0x7fac5ff8f03d 8 libc.so.6 0x7fac5ff8f0f2 9 opt 0x00c9d979 llvm::ScalarEvolution::getConstantEvolutionLoopExitValue(llvm::PHINode*, llvm::APInt const&, llvm::Loop const*) + 601 10 opt 0x00c9e612 llvm::ScalarEvolution::computeSCEVAtScope(llvm::SCEV const*, llvm::Loop const*) + 466 11 opt 0x00c99a69 llvm::ScalarEvolution::getSCEVAtScope(llvm::SCEV const*, llvm::Loop const*) + 921 12 opt 0x00c9ed19 llvm::ScalarEvolution::computeSCEVAtScope(llvm::SCEV const*, llvm::Loop const*) + 2265 13 opt 0x00c99a69 llvm::ScalarEvolution::getSCEVAtScope(llvm::SCEV const*, llvm::Loop const*) + 921 14 opt 0x00ca5d75 llvm::ScalarEvolution::print(llvm::raw_ostream&) const + 597 15 opt 0x00ca79d0 llvm::ScalarEvolutionWrapperPass::print(llvm::raw_ostream&, llvm::Module const*) const + 48 16 opt 0x0078d574 17 opt 0x01304ebf llvm::FPPassManager::runOnFunction(llvm::Function&) + 399 18 opt 0x013051d5 llvm::FPPassManager::runOnModule(llvm::Module&) + 117 19 opt 0x0130596a 20 opt 0x01305496 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 342 21 opt 0x01305e81 llvm::legacy::PassManager::run(llvm::Module&) + 33 22 opt 0x00799670 main + 7984 23 libc.so.6 0x7fac5ff81a40 __libc_start_main + 240 24 opt 0x00774e49 _start + 41 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25370] New: [ms] Miscompile with explicit call of default construct of virtual base
https://llvm.org/bugs/show_bug.cgi?id=25370
Bug ID: 25370
Summary: [ms] Miscompile with explicit call of default
construct of virtual base
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Consider:
struct Test {
virtual ~Test() {}
};
struct BrowserTest : virtual public Test {};
struct NonsecureURLRequestTest : public BrowserTest {
NonsecureURLRequestTest() : BrowserTest() {}
};
int main() {
new NonsecureURLRequestTest();
}
> clang-cl foo.cc -m32
> foo
This crashes. (With or without optimizations, 32-bit and 64-bit.)
If NonsecureURLRequestTest is defined like so
struct NonsecureURLRequestTest : public BrowserTest {
NonsecureURLRequestTest() {}
};
then everything works fine.
This causes the test failure in http://crbug.com/549765
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25371] New: Kaleidoscope Tutorial Ch2 falsely claims that it doesn't depend on LLVM
https://llvm.org/bugs/show_bug.cgi?id=25371 Bug ID: 25371 Summary: Kaleidoscope Tutorial Ch2 falsely claims that it doesn't depend on LLVM Product: Documentation Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: General docs Assignee: unassignedb...@nondot.org Reporter: modoca...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The documentation in `docs/tutorial/LangImpl2.rst` states of the example code: "Note that it is fully self-contained: you don’t need LLVM or any external libraries at all for this." It proceeds to claim the example code can be compiled with `clang++ -g -O3 toy.cpp`, which is not true. The problem is that the example code imports `llvm/ADT/STLExtras.h` and uses `llvm::make_unique`. Two possible solutions: 1. Remove the claim and show a compile command that will actually work with the LLVM import. 2. Remove references to `llvm::make_unique`, and actually have the code compile with a simple `clang++ -g -O3 toy.cpp`. I think #2 is the way to go, since readers new to LLVM won't immediately know what `llvm::make_unique` does anyway--best to stick to stdlib. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25369] [SCEV] Assertion `PN->getNumIncomingValues() == 2 && "Follows from having one latch!"' failed.
https://llvm.org/bugs/show_bug.cgi?id=25369 Sanjoy Das changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Sanjoy Das --- Should be fixed in r251770. Btw, as far as I can tell, before r249712 SCEV would just silently return the wrong answer for cases similar to @hoge; and r249712 only turned those cases into a failing assert. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25344] LNT build fails with -polly-position=before-vectorizer
https://llvm.org/bugs/show_bug.cgi?id=25344 Bug 25344 depends on bug 25369, which changed state. Bug 25369 Summary: [SCEV] Assertion `PN->getNumIncomingValues() == 2 && "Follows from having one latch!"' failed. https://llvm.org/bugs/show_bug.cgi?id=25369 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25360] clang crashes on valid code at -O1 on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=25360 Sanjoy Das changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs@nondot. |sanjoy@playingwithpointers. |org |com --- Comment #4 from Sanjoy Das --- (In reply to comment #3) > Even though this bisects to Mehdi's change, I think fundamentally this > is actually my r249211 change. > > The easiest "fix" (that I was hoping to avoid) is Checked in this fix in r251756 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25372] New: clang crashes on valid code at -O1, -Os, and -O2 on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=25372 Bug ID: 25372 Summary: clang crashes on valid code at -O1, -Os, and -O2 on x86_64-linux-gnu Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: s...@cs.ucdavis.edu CC: llvm-bugs@lists.llvm.org Classification: Unclassified The current clang trunk crashes when compiling the following test case at -O1, -Os, and -O2 on x86_64-linux-gnu in both 32-bit and 64-bit modes. This is a regression from 3.7.x. $ clang-trunk -v clang version 3.8.0 (trunk 251762) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/bin 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.4 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-trunk -O3 -c small.c $ clang-3.7.0 -O1 -c small.c $ $ clang-trunk -O1 -c small.c clang: /tmp/llvm/include/llvm/Support/Casting.h:237: typename llvm::cast_retty::ret_type llvm::cast(Y*) [with X = llvm::Instruction; Y = llvm::Value; typename llvm::cast_retty::ret_type = llvm::Instruction*]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. #0 0x2f00e48 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang+0x2f00e48) #1 0x2efff16 llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang+0x2efff16) #2 0x2f00134 (/usr/local/clang-trunk/bin/clang+0x2f00134) #3 0x7f5d1c1f5340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #4 0x7f5d1b203cc9 gsignal /build/buildd/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7f5d1b2070d8 abort /build/buildd/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7f5d1b1fcb86 __assert_fail_base /build/buildd/eglibc-2.19/assert/assert.c:92:0 #7 0x7f5d1b1fcc32 (/lib/x86_64-linux-gnu/libc.so.6+0x2fc32) #8 0x959dd6 _init (/usr/local/clang-trunk/bin/clang+0x959dd6) #9 0x1be0871 (/usr/local/clang-trunk/bin/clang+0x1be0871) #10 0x2c384ac llvm::SCEVExpander::replaceCongruentIVs(llvm::Loop*, llvm::DominatorTree const*, llvm::SmallVectorImpl&, llvm::TargetTransformInfo const*) (/usr/local/clang-trunk/bin/clang+0x2c384ac) #11 0x28c1f80 (/usr/local/clang-trunk/bin/clang+0x28c1f80) #12 0x2bccddb llvm::LPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang+0x2bccddb) #13 0x2e79633 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang+0x2e79633) #14 0x2b40a30 (/usr/local/clang-trunk/bin/clang+0x2b40a30) #15 0x2e79d78 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/clang-trunk/bin/clang+0x2e79d78) #16 0xc978ca 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+0xc978ca) #17 0xc7809a (/usr/local/clang-trunk/bin/clang+0xc7809a) #18 0xe8e84d clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/clang-trunk/bin/clang+0xe8e84d) #19 0xc7817e clang::CodeGenAction::ExecuteAction() (/usr/local/clang-trunk/bin/clang+0xc7817e) #20 0xaa4ae6 clang::FrontendAction::Execute() (/usr/local/clang-trunk/bin/clang+0xaa4ae6) #21 0xa7e4a1 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/local/clang-trunk/bin/clang+0xa7e4a1) #22 0xa64533 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/local/clang-trunk/bin/clang+0xa64533) #23 0xa5b800 cc1_main(llvm::ArrayRef, char const*, void*) (/usr/local/clang-trunk/bin/clang+0xa5b800) #24 0xa1b308 main (/usr/local/clang-trunk/bin/clang+0xa1b308) #25 0x7f5d1b1eeec5 __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:321:0 #26 0xa5a367 _start (/usr/local/clang-trunk/bin/clang+0xa5a367) 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-p
