[llvm-bugs] [Bug 28935] New: crash at -Os and above in 64-bit mode on x86_64-linux-gnu (Assertion `getTypeSizeInBits(Op->getType()) < getTypeSizeInBits(Ty) && "This is not an extending conversion!"' f
https://llvm.org/bugs/show_bug.cgi?id=28935 Bug ID: 28935 Summary: crash at -Os and above in 64-bit mode on x86_64-linux-gnu (Assertion `getTypeSizeInBits(Op->getType()) < getTypeSizeInBits(Ty) && "This is not an extending conversion!"' failed.) Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: chengnian...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified $ clang-trunk -v clang version 4.0.0 (trunk 278233) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0 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.5 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/4.9.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ clang-trunk -Os small.c clang-4.0: /tmp/llvm-builder/llvm-source-trunk/lib/Analysis/ScalarEvolution.cpp:1407: const llvm::SCEV* llvm::ScalarEvolution::getZeroExtendExpr(const llvm::SCEV*, llvm::Type*): Assertion `getTypeSizeInBits(Op->getType()) < getTypeSizeInBits(Ty) && "This is not an extending conversion!"' failed. #0 0x01c22da5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang-4.0+0x1c22da5) #1 0x01c20d0e llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang-4.0+0x1c20d0e) #2 0x01c20e72 SignalHandler(int) (/usr/local/clang-trunk/bin/clang-4.0+0x1c20e72) #3 0x7fe050527330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #4 0x7fe04f318c37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7fe04f31c028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7fe04f311bf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 #7 0x7fe04f311ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #8 0x014faf7c llvm::ScalarEvolution::getZeroExtendExpr(llvm::SCEV const*, llvm::Type*) (/usr/local/clang-trunk/bin/clang-4.0+0x14faf7c) #9 0x01ad67d2 (anonymous namespace)::IndVarSimplify::run(llvm::Loop*) [clone .part.454] (/usr/local/clang-trunk/bin/clang-4.0+0x1ad67d2) #10 0x01ad93d9 (anonymous namespace)::IndVarSimplifyLegacyPass::runOnLoop(llvm::Loop*, llvm::LPPassManager&) [clone .part.455] (/usr/local/clang-trunk/bin/clang-4.0+0x1ad93d9) #11 0x02492b5f llvm::LPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang-4.0+0x2492b5f) #12 0x018a5763 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang-4.0+0x18a5763) #13 0x02471bc0 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) (/usr/local/clang-trunk/bin/clang-4.0+0x2471bc0) #14 0x018a5dff llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/clang-trunk/bin/clang-4.0+0x18a5dff) #15 0x01d7bea0 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/usr/local/clang-trunk/bin/clang-4.0+0x1d7bea0) #16 0x023716e8 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/usr/local/clang-trunk/bin/clang-4.0+0x23716e8) #17 0x026c419b clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x26c419b) #18 0x02371ade clang::CodeGenAction::ExecuteAction() (/usr/local/clang-trunk/bin/clang-4.0+0x2371ade) #19 0x0208ee46 clang::FrontendAction::Execute() (/usr/local/clang-trunk/bin/clang-4.0+0x208ee46) #20 0x02069e4e clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/local/clang-trunk/bin/clang-4.0+0x2069e4e) #21 0x02114946 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/local/clang-trunk/bin/clang-4.0+0x2114946) #22 0x00a52ee8 cc1_main(llvm::ArrayRef, char const*, void*) (/usr/local/clang-trunk/bin/clang-4.0+0xa52ee8) #23 0x009fdbcf main (/usr/local/clang-trunk/bin/clang-4.0+0x9fdbcf) #24 0x7fe04f303f45 __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-star
[llvm-bugs] [Bug 28936] New: std/numerics/complex.number/complex.transcendentals/asin.pass.cpp depends on the sign bit of NaN numbers
https://llvm.org/bugs/show_bug.cgi?id=28936
Bug ID: 28936
Summary: std/numerics/complex.number/complex.transcendentals/as
in.pass.cpp depends on the sign bit of NaN numbers
Product: libc++
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: release blocker
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: vasileios.kalinti...@imgtec.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Blocks: 28600
Classification: Unclassified
I marked this test as a release blocker because it is failing in the 3.9rc1
release. However, even though I'm not too familiar with the IEEE754 standard, I
believe that this test relies on behaviour specified by the newer, 2008
revision.
One test case that fails is std::complex(NAN, -2) which on the MIPS
board produces r=(NAN, NAN), instead of the expected (NAN,-NAN) value:
else if (std::isnan(testcases[i].real()) && std::isfinite(testcases[i].imag()))
{
assert(std::isnan(r.real()));
assert(std::isnan(r.imag()));
assert(std::signbit(testcases[i].imag()) == std::signbit(r.imag()));
}
All the cases from "cases.h" that fail on the asin.pass.cpp test, depend on the
sign-bit being set for NaNs too.
--
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 28937] New: clang is not knowing using const-attribute for the standard math functions
https://llvm.org/bugs/show_bug.cgi?id=28937
Bug ID: 28937
Summary: clang is not knowing using const-attribute for the
standard math functions
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: n...@chello.at
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
unlike gcc, clang doesn`t seem to have the knowledge about std math functions
builtin.
Similar to knowing memcpy and generating optimized code, clang should know that
all math functions only depend on their arguments.
For the code snippet below, I would expect that
* Clang should only call the function once
What happens is that
* Clang cant deduce that the function is "const" and doesnt remove any call
(apparently this could also be solved in the std library, but I doubt its wise
to depend on this, rather than simply expect that the standard functions are
deterministic)
(code snippet)
#include
float failttooptimize(float a)
{
return sin(a) + sin(a) + sin(a);
}
__attribute__((const)) double cos(double a);
float canoptimize(float a)
{
return cos(a) + cos(a) + cos(a);
}
clang version 3.8.1-5 (tags/RELEASE_381/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/i586-linux-gnu/4.9
Found candidate GCC installation: /usr/bin/../lib/gcc/i586-linux-gnu/4.9.2
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.4
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.2
Found candidate GCC installation: /usr/lib/gcc/i586-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i586-linux-gnu/4.9.2
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
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
"/usr/lib/llvm-3.8/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -S
-disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model
static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu x86-64 -momit-leaf-frame-pointer
-v -dwarf-column-info -debugger-tuning=gdb -coverage-file /tmp/test.c
-resource-dir /usr/lib/llvm-3.8/bin/../lib/clang/3.8.1 -internal-isystem
/usr/local/include -internal-isystem
/usr/lib/llvm-3.8/bin/../lib/clang/3.8.1/include -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include
-internal-externc-isystem /usr/include -O3 -fdebug-compilation-dir /tmp
-ferror-limit 19 -fmessage-length 211 -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp
-o test.s -x c test.c
clang -cc1 version 3.8.1 based upon LLVM 3.8.1 default target
x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/llvm-3.8/bin/../lib/clang/3.8.1/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
--
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 28908] error: ran out of registers during register allocation
https://llvm.org/bugs/show_bug.cgi?id=28908 Sean Bruno changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME -- 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 28938] New: X86: MachineBasicBlock::getFirstTerminator returns end() in llvm::getFuncletMembership
https://llvm.org/bugs/show_bug.cgi?id=28938 Bug ID: 28938 Summary: X86: MachineBasicBlock::getFirstTerminator returns end() in llvm::getFuncletMembership Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: dexonsm...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified If you add an assertion after the call to MachineBasicBlock::getFirstTerminator in llvm::getFuncletMembership that it's not the end() iterator, 48 X86 testcases fail. IIUC, every MachineBasicBlock should end with a terminator, so this seems like a bug in X86. I'm about to commit a patch that papers over this by checking for end() (to avoid dereferencing it) to unblock my work on bug 26753. Here are the tests that fail locally for me if you use an assertion instead: -- Failing Tests (48): LLVM :: CodeGen/WinEH/wineh-nested-unwind.ll LLVM :: CodeGen/WinEH/wineh-noret-cleanup.ll LLVM :: CodeGen/X86/branchfolding-catchpads.ll LLVM :: CodeGen/X86/catchpad-dynamic-alloca.ll LLVM :: CodeGen/X86/catchpad-lifetime.ll LLVM :: CodeGen/X86/catchpad-realign-savexmm.ll LLVM :: CodeGen/X86/catchpad-regmask.ll LLVM :: CodeGen/X86/catchpad-weight.ll LLVM :: CodeGen/X86/catchret-empty-fallthrough.ll LLVM :: CodeGen/X86/catchret-fallthrough.ll LLVM :: CodeGen/X86/catchret-regmask.ll LLVM :: CodeGen/X86/cleanuppad-inalloca.ll LLVM :: CodeGen/X86/cleanuppad-large-codemodel.ll LLVM :: CodeGen/X86/cleanuppad-realign.ll LLVM :: CodeGen/X86/deopt-bundles.ll LLVM :: CodeGen/X86/funclet-layout.ll LLVM :: CodeGen/X86/late-address-taken.ll LLVM :: CodeGen/X86/pr26757.ll LLVM :: CodeGen/X86/pr27501.ll LLVM :: CodeGen/X86/regalloc-spill-at-ehpad.ll LLVM :: CodeGen/X86/seh-catch-all-win32.ll LLVM :: CodeGen/X86/seh-catch-all.ll LLVM :: CodeGen/X86/seh-catchpad.ll LLVM :: CodeGen/X86/seh-except-finally.ll LLVM :: CodeGen/X86/seh-exception-code.ll LLVM :: CodeGen/X86/seh-finally.ll LLVM :: CodeGen/X86/seh-safe-div-win32.ll LLVM :: CodeGen/X86/seh-safe-div.ll LLVM :: CodeGen/X86/seh-stack-realign.ll LLVM :: CodeGen/X86/tail-dup-catchret.ll LLVM :: CodeGen/X86/tail-merge-wineh.ll LLVM :: CodeGen/X86/win-catchpad-csrs.ll LLVM :: CodeGen/X86/win-catchpad-nested-cxx.ll LLVM :: CodeGen/X86/win-catchpad-nested.ll LLVM :: CodeGen/X86/win-catchpad-varargs.ll LLVM :: CodeGen/X86/win-catchpad.ll LLVM :: CodeGen/X86/win-cleanuppad.ll LLVM :: CodeGen/X86/win-funclet-cfi.ll LLVM :: CodeGen/X86/win-mixed-ehpersonality.ll LLVM :: CodeGen/X86/win32-eh-states.ll LLVM :: CodeGen/X86/win32-eh.ll LLVM :: CodeGen/X86/win32-seh-catchpad-realign.ll LLVM :: CodeGen/X86/win32-seh-catchpad.ll LLVM :: CodeGen/X86/win32-seh-nested-finally.ll LLVM :: CodeGen/X86/wineh-coreclr.ll LLVM :: CodeGen/X86/wineh-exceptionpointer.ll LLVM :: DebugInfo/COFF/comdat.ll LLVM :: Transforms/IndVarSimplify/iv-widen-elim-ext.ll -- -- 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 28938] X86: MachineBasicBlock::getFirstTerminator returns end() in llvm::getFuncletMembership
https://llvm.org/bugs/show_bug.cgi?id=28938 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Reid Kleckner --- Removed FIXME and confirmed that the end iterator check is the correct fix in r278344. -- 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 28939] New: test infra: convert pexpect errors into failures
https://llvm.org/bugs/show_bug.cgi?id=28939 Bug ID: 28939 Summary: test infra: convert pexpect errors into failures Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified When LLDB runs pexpect tests, and the pexpect condition does not match (typically due to a pexpect timeout), this shows up as a test error. This is because unittest sees an exception thrown that isn't one of its assert exceptions. In reality, the pexpect timeout is a failure - something didn't match. It isn't an error, which is reserved to indicate something totally off the rails went wrong. A non-match is a failure, not an off-the-rails error. We should be able to catch pexpect timeouts and adapt them to show up as failures. -- 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 27199] test infra: an exceptional exit outside of any test method should be cleared on rerun with no exceptional exit
https://llvm.org/bugs/show_bug.cgi?id=27199 Todd Fiala changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Todd Fiala --- Duping this over to 27423, which better captures what needs to happen here. *** This bug has been marked as a duplicate of bug 27423 *** -- 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 28934] LLVMRunFunction does not work properly with MCJIT
https://llvm.org/bugs/show_bug.cgi?id=28934 Lang Hames changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Lang Hames --- Hi Henning, Some history to explain the current state of things: ExecutionEngine's interface has always been the union of the functionality provided by the Interpreter, the JIT (now deleted), and MCJIT. LLVMRunFunction shouldn't be deprecated as it still works for the Interpreter, but I have added comments to ExecutionEngine.h explaining the limitations when using MCJIT, and I have changed MCJIT::runFunction to abort with a meaningful error at runtime if called with unsupported arguments (r278348). The underlying problem was the decision to try to support all execution engine features in a single interface. The ORC APIs (LLVM's next generation of JIT APIs) avoid this problem by breaking away from the ExecutionEngine interface. If you want to check out the new APIs you'll find a tutorial series (under development) at: http://llvm.org/docs/tutorial/BuildingAJIT1.html . The headers are in include/llvm/ExecutionEngine/Orc, and some simple C bindings are available at include/llvm-c/OrcCBindings.h . Cheers, Lang. -- 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 28940] New: LLDB calls wrong C++ method when virtual hides non-virtual
https://llvm.org/bugs/show_bug.cgi?id=28940
Bug ID: 28940
Summary: LLDB calls wrong C++ method when virtual hides
non-virtual
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: dber...@dberlin.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
If i have a virtual in a subclass that hides a non-virtual in a base-class,
LLDB calls the non-virtual.
Example from LLVM:
class Value {
..
/// \brief Support for debugging, callable in GDB: V->dump()
void dump() const;
}
class MemoryAccess: public Value {
virtual void dump() const;
}
(lldb) p Dominator->MemoryAccess::dump()
1 = MemoryDef(liveOnEntry)
(this is the correct dump)
(lldb) p Dominator->dump()
While deleting: void %
Use still stuck around after Def is destroyed:Unknown value to print out!
UNREACHABLE executed at ../lib/IR/AsmWriter.cpp:3437!
error: Execution was interrupted, reason: signal SIGABRT.
The process has been returned to the state before expression evaluation.
This is calling Value::dump().
What dump is called certainly depends on the pointer type.
If the pointer type here was Value*, i would expect this behavior.
However, it is "const MemoryAccess *Dominator", so it should be calling the
virtual dump here.
(and for anyone curious, fixing llvm ... would be hard :P)
gdb calls the correct dump here :)
--
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 28870] Clang crashes after r277787 when compiling OpenTCP-1.0.4
https://llvm.org/bugs/show_bug.cgi?id=28870 Gabor Ballabas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Gabor Ballabas --- (In reply to comment #4) > Re-introduced in r278264, let me know if you see any issue. Hi Bruno, Everything works fine after the new patch. Thanks for the help! -- 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 28941] New: Document new PARAMATTR_CODE_ENTRY format
https://llvm.org/bugs/show_bug.cgi?id=28941 Bug ID: 28941 Summary: Document new PARAMATTR_CODE_ENTRY format Product: Documentation Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: General docs Assignee: unassignedb...@nondot.org Reporter: ibad...@cisco.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified It seems the encoding for parameter attributes changed in LLVM 3.3. The format described here (with a bitmap): http://llvm.org/docs/BitCodeFormat.html#paramattr-code-entry-record is the format produced by LLVM 3.2 -- what now corresponds to PARAMATTR_CODE_ENTRY_OLD in the BitcodeReader code. -- 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 28824] wrong code (segfault) at -O3 on x86_64-linux-gnu in the 32-bit mode
https://llvm.org/bugs/show_bug.cgi?id=28824 Michael Kuperstein changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Michael Kuperstein --- Fixed in r278370. -- 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 28936] std/numerics/complex.number/complex.transcendentals/asin.pass.cpp depends on the sign bit of NaNs
https://llvm.org/bugs/show_bug.cgi?id=28936 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Marshall Clow (home) --- Committed as revision 278387 -- 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 28600] [meta] 3.9.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=28600 Bug 28600 depends on bug 28824, which changed state. Bug 28824 Summary: wrong code (segfault) at -O3 on x86_64-linux-gnu in the 32-bit mode https://llvm.org/bugs/show_bug.cgi?id=28824 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 28600] [meta] 3.9.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=28600 Bug 28600 depends on bug 28936, which changed state. Bug 28936 Summary: std/numerics/complex.number/complex.transcendentals/asin.pass.cpp depends on the sign bit of NaNs https://llvm.org/bugs/show_bug.cgi?id=28936 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 28942] New: MachineScheduler: clusterNeighboringMemOps can lead to unstable output
https://llvm.org/bugs/show_bug.cgi?id=28942 Bug ID: 28942 Summary: MachineScheduler: clusterNeighboringMemOps can lead to unstable output Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: gbe...@codeaurora.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified The code in BaseMemOpClusterMutation::clusterNeighboringMemOps() builds a sorted list of MemOpInfos, and the ordering of this list can ultimately effect the code generated (whether loads/stores get clustered when scheduling). std::sort is used to sort the entries, which is not stable w.r.t. the order of equal elements. Unstable output could be generated for the same input if two different implementations of std::sort were used. The clustering decision for equal MemOpInfos could also be altered e.g. by the addition of extra MemOpInfos in the list before or after the equal elements. I ran into the latter case refactoring the code for AArch64InstrInfo::getMemOpBaseRegImmOfs(). -- 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 28719] clang crashes on valid code at -O3 on x86_64-linux-gnu with "error in backend: Broken function found, compilation aborted!"
https://llvm.org/bugs/show_bug.cgi?id=28719 Geoff Berry changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs@nondot. |gbe...@codeaurora.org |org | -- 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 28600] [meta] 3.9.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=28600 Bug 28600 depends on bug 28719, which changed state. Bug 28719 Summary: clang crashes on valid code at -O3 on x86_64-linux-gnu with "error in backend: Broken function found, compilation aborted!" https://llvm.org/bugs/show_bug.cgi?id=28719 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 28363] BDNZ not generated for simple loops
https://llvm.org/bugs/show_bug.cgi?id=28363 Ehsan Amiri changed: 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 26417] Add AVX-512 support in X86TargetLowering::emitFMA3Instr
https://llvm.org/bugs/show_bug.cgi?id=26417 vyacheslav.n.kloch...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #7 from vyacheslav.n.kloch...@gmail.com --- This patch resolved the issue. https://reviews.llvm.org/rL278431 -- 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 28883] IfConversion crash
https://llvm.org/bugs/show_bug.cgi?id=28883 Kyle Butt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Kyle Butt --- The patch has been re-committed with a fix for this problem. -- 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 28944] New: IRCE breaks loop-info
https://llvm.org/bugs/show_bug.cgi?id=28944
Bug ID: 28944
Summary: IRCE breaks loop-info
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: michael.v.zolotuk...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
When trying to improve LoopInfo verifier, I found that one of IRCE tests
started to fail. Looks like it doesn't update LI as it creates new loops, or
something like this.
To reproduce apply a patch from https://reviews.llvm.org/D23437 and then:
$ cat fail.ll
define void @inner_loop(i32* %arr, i32* %a_len_ptr, i32 %n) {
entry:
%len = load i32, i32* %a_len_ptr, !range !0
%first.itr.check = icmp sgt i32 %n, 0
br i1 %first.itr.check, label %loop, label %exit
loop: ; preds = %in.bounds, %entry
%idx = phi i32 [ 0, %entry ], [ %idx.next, %in.bounds ]
%idx.next = add i32 %idx, 1
%abc = icmp slt i32 %idx, %len
br i1 %abc, label %in.bounds, label %out.of.bounds
in.bounds:; preds = %loop
%addr = getelementptr i32, i32* %arr, i32 %idx
store i32 0, i32* %addr
%next = icmp slt i32 %idx.next, %n
br i1 %next, label %loop, label %exit
out.of.bounds:; preds = %loop
ret void
exit: ; preds = %in.bounds, %entry
ret void
}
!0 = !{i32 0, i32 2147483647}
$ opt -verify-loop-info -irce-print-changed-loops -irce < ww.ll -S
irce: in function inner_loop: constrained Loop at depth 1 containing:
%loop,%in.bounds
Assertion failed: (LoopHeaders1.size() == LoopHeaders2.size() && "LoopInfo is
incorrect."), function verifyByRecomputation, file
/Users/mvzolotu/devel/trunk/llvm/include/llvm/Analysis/LoopInfoImpl.h, line
600.
Stack dump:
0. Program arguments: bin/opt -verify-loop-info -irce-print-changed-loops
-irce -S
1. Running pass 'Function Pass Manager' on module ''.
2. Running pass 'Loop Pass Manager' on function '@inner_loop'
Abort trap: 6
--
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 28946] New: crash at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (Assertion `(KnownZero & KnownOne) == 0 && "Bits known to be one AND zero?"' failed.)
+0x206bade)
#22 0x021165d6
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/local/clang-trunk/bin/clang-4.0+0x21165d6)
#23 0x00a53078 cc1_main(llvm::ArrayRef, char const*,
void*) (/usr/local/clang-trunk/bin/clang-4.0+0xa53078)
#24 0x009fdc7f main (/usr/local/clang-trunk/bin/clang-4.0+0x9fdc7f)
#25 0x7f7f1c7bff45 __libc_start_main
/build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:321:0
#26 0x00a4ef2d _start (/usr/local/clang-trunk/bin/clang-4.0+0xa4ef2d)
Stack dump:
0. Program arguments: /usr/local/clang-trunk/bin/clang-4.0 -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
-momit-leaf-frame-pointer -dwarf-column-info -debugger-tuning=gdb -resource-dir
/usr/local/clang-trunk/bin/../lib/clang/4.0.0 -c-isystem . -c-isystem
/usr/local/include/csmith-2.2.0/ -c-isystem /usr/local/include/csmith-2.2.0/
-internal-isystem /usr/local/include -internal-isystem
/usr/local/clang-trunk/bin/../lib/clang/4.0.0/include -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include
-internal-externc-isystem /usr/include -O3 -w -fdebug-compilation-dir
/home/cnsun/ramdisk/hermes/run-1/res/20160811-clang-trunk-m64-g-O3-build-142550/delta
-ferror-limit 19 -fmessage-length 118 -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp
-o /tmp/small-62f90c.o -x c small.c
1. parser at end of file
2. Per-module optimization passes
3. Running pass 'Function Pass Manager' on module 'small.c'.
4. Running pass 'Combine redundant instructions' on function '@main'
clang-4.0: error: unable to execute command: Aborted (core dumped)
clang-4.0: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 4.0.0 (trunk 278347)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
clang-4.0: 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-4.0: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-4.0: note: diagnostic msg: /tmp/small-8e8c67.c
clang-4.0: note: diagnostic msg: /tmp/small-8e8c67.sh
clang-4.0: note: diagnostic msg:
$ cat small.c
static int a = 10992;
int main() {
5 - a *((4 || 3) << 18) / 5 << 0;
a = 8737;
return 0;
}
$
--
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
