[llvm-bugs] [Bug 3952] CFG: @finally code is executed for any 'exit' from a @try block
https://llvm.org/bugs/show_bug.cgi?id=3952 Timothy J. Wood changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Timothy J. Wood --- Many moons later, I'm no longer able to reproduce this problem, with Xcode 8.1 b3. -- 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 4292] +[NSData dataWithBytesNoCopy:] incorrectly treated as returning a +1 ref
https://llvm.org/bugs/show_bug.cgi?id=4292 Timothy J. Wood changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Timothy J. Wood --- This seems to work fine in Xcode 8.1 b3. Thanks! -- 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 30805] New: PPCInstrInfo::analyzeCompare() ignores some compare opcodes
https://llvm.org/bugs/show_bug.cgi?id=30805 Bug ID: 30805 Summary: PPCInstrInfo::analyzeCompare() ignores some compare opcodes Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: ameh...@ca.ibm.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified As Nemanja pointed out, at least XSCMPUDP is missing. We need to check if we have other missing opcodes as well or not. -- 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 28586] [optional] Support for C++17 optional
https://llvm.org/bugs/show_bug.cgi?id=28586 Eric Fiselier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Eric Fiselier --- std::optional has been committed. See the ABI changelog or commit history for the exact revision. -- 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 20320] clang_reparseTranslationUnit crashes while serializing the AST
https://llvm.org/bugs/show_bug.cgi?id=20320 Erik Verbruggen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Erik Verbruggen --- Fixed in r285275 -- 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 30806] New: Wrong code generation at -O2 leading to division by zero
https://llvm.org/bugs/show_bug.cgi?id=30806
Bug ID: 30806
Summary: Wrong code generation at -O2 leading to division by
zero
Product: new-bugs
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: cl...@martinien.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17500
--> https://llvm.org/bugs/attachment.cgi?id=17500&action=edit
Repro
Attached repro causes a division by zero although it shouldn't (I tried my best
to rule out undefined behavior, but if I missed something let me know).
Build with build.sh and run "div_by_zero"
In run.cpp "array" is only being assigned a non-NULL pointer when both a and b
are both > 0:
if(a > 0 && b > 0) // false at runtime!
{
try {
array.reset(new size_t[b]());
}
catch (...)
{
}
}
But later on the following code gets executed even though array.get() must
return NULL:
if (array.get() != 0) // Should be false at runtime; even adding "&& a > 0"
here does not help
{
// Also this crashes:
//const size_t partSize = a != 0 ? b / a : 0;
const size_t partSize = b / a; // Crash here - Division by zero
Side note:
It works at -O1. I know that for earlier clang versions (I think 3.6) this
broke even at -O1, but the workaround seen above ("Also this crashes") worked
there.
Best regards,
Martin
--
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 30626] Compiler crash inside SLP Vectorizer ("Use still stuck around after Def is destroyed")
https://llvm.org/bugs/show_bug.cgi?id=30626 Alexey Bataev changed: What|Removed |Added Status|NEW |RESOLVED CC||a.bat...@hotmail.com Resolution|--- |FIXED --- Comment #5 from Alexey Bataev --- Fixed in r285286 -- 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 30807] New: [AliasSetTracker] Should ignore intrinsics that don't actually affect memory
https://llvm.org/bugs/show_bug.cgi?id=30807
Bug ID: 30807
Summary: [AliasSetTracker] Should ignore intrinsics that don't
actually affect memory
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: mcros...@codeaurora.org
CC: dber...@dberlin.org, gbe...@codeaurora.org,
hfin...@anl.gov, llvm-bugs@lists.llvm.org
Classification: Unclassified
In r285191, a patch was committed to allow AST to ignoring assume,
lifetime_[start|end], and invariant[start|end] intrinsics. Unfortunately, this
caused one of the asan tests (i.e., use-after-scope-loop-bug.cc) to begin
failing on all the bots.
The test is as follows:
int main() {
// Variable goes in and out of scope.
for (int i = 0; i < 3; ++i) {
int x[3] = {i, i, i};
p = x + i;
}
return *p; // BOOM
}
After r285191, LICM is able to sink the stores to x[] after the loop body.
This appears to be reasonable behavior, but LICM (and likely other code motion
passes) will need to either 1) remove the lifetime markers from things you
hoist/sink or 2) extend the lifetime markers accordingly with the latter
solution being strongly preferred. The algorithm for that is that when you
eliminate or sink things past them, you move the end to wherever the lowest
point you sunk to is. You move starts to a block that post-dominates both the
new end and the old end.
r285191 was reverted in r285227 to return the bots to green.
--
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 30808] New: [mc][gfx8] s_load_dword to support offsets up to 20 bits width
https://llvm.org/bugs/show_bug.cgi?id=30808 Bug ID: 30808 Summary: [mc][gfx8] s_load_dword to support offsets up to 20 bits width Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: artem.tama...@amd.com CC: andrey.kasau...@gmail.com, artem.tama...@amd.com, i.am.permi...@gmail.com, llvm-bugs@lists.llvm.org, nikolay.haus...@amd.com, sam.kol...@amd.com, valery.pykh...@gmail.com Classification: Unclassified Example of failing instruction: > s_load_dword s[0], s[0:1], 256 With 255 assembles OK. GCN3 doc says that there are 20-bits in the instruction for immediate unsigned byte offset. The bug if gfx8-specific. Tested with r285055 (git# 797783e). None lit tests available on hand. -- 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 28735] error in backend when compiling v8 on s390x
https://llvm.org/bugs/show_bug.cgi?id=28735 Dan Horák changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dan Horák --- seems the issue went away with [sharkcz@devel11 ~]$ clang-3.9 -v clang version 3.9.0 (tags/RELEASE_390/final) Target: s390x-ibm-linux Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/s390x-redhat-linux/6.2.1 Found candidate GCC installation: /usr/lib/gcc/s390x-redhat-linux/6.2.1 Selected GCC installation: /usr/bin/../lib/gcc/s390x-redhat-linux/6.2.1 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 -- 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 30809] New: TODO: Verify clang-cl can find VS15 compiler
https://llvm.org/bugs/show_bug.cgi?id=30809 Bug ID: 30809 Summary: TODO: Verify clang-cl can find VS15 compiler Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: amcca...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Visual Studio 15 has a different directory layout. The clang-cl driver searches for installed versions of cl.exe in order to do things like set the default for -fms-compatibility-version. Once Visual Studio 15 is out of preview, we should ensure that the clang-cl's search can efficiently find the installed version of cl.exe. Microsoft blog post on the changes to the installation directory tree: https://blogs.msdn.microsoft.com/vcblog/2016/10/07/compiler-tools-layout-in-visual-studio-15/ -- 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 30810] New: __asan_shadow_memory_dynamic_address is initialized too late relative to other code
https://llvm.org/bugs/show_bug.cgi?id=30810 Bug ID: 30810 Summary: __asan_shadow_memory_dynamic_address is initialized too late relative to other code Product: compiler-rt Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: dma...@mozilla.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified One of our DLLs contains this global: bool mmx_enabled = has_cpuid_bits(1u, edx, (1u<<23)); which gets initialized here: mozglue!`anonymous namespace'::has_cpuid_bits mozglue!??__Emmx_enabled@sse_private@mozilla@@YAXXZ+0x1f mozglue!_GLOBAL__sub_I_SSE.cpp+0x22 ucrtbase!_initterm+0x43 mozglue!dllmain_crt_process_attach+0xa7 mozglue!dllmain_crt_dispatch+0x3b mozglue!dllmain_dispatch+0x59 mozglue!_DllMainCRTStartup+0x1c ntdll!LdrxCallInitRoutine+0x16 But __asan_shadow_memory_dynamic_address isn't initialized until slightly later: mozglue!`dynamic initializer for '__asan_shadow_memory_dynamic_address''+0xb ucrtbase!_initterm+0x43 mozglue!dllmain_crt_process_attach+0xa7 mozglue!dllmain_crt_dispatch+0x3b mozglue!dllmain_dispatch+0x59 mozglue!_DllMainCRTStartup+0x1c ntdll!LdrxCallInitRoutine+0x16 It happens to work on 32-bit builds where a shadow region of 0x3000 is hard-coded into has_cpuid_bits, but it crashes on 64-bit builds where has_cpuid_bits needs to use the dynamic address. -- 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 30532] fatal error: error in backend: out of range pc-relative fixup value
https://llvm.org/bugs/show_bug.cgi?id=30532 Saleem Abdulrasool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Saleem Abdulrasool --- SVN r285312. This should hopefully address this particular issue. Ideally we would generate the straight code form if possible, but that is an optimization that can be addressed later. -- 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 30803] lld too aggressive at relaxing got access
https://llvm.org/bugs/show_bug.cgi?id=30803 Rafael Ávila de Espíndola changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Rafael Ávila de Espíndola --- Fixed in r285317. -- 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 30811] New: Unconditionally passed `-lto_library` to the linker on Darwin confused by symlinks
https://llvm.org/bugs/show_bug.cgi?id=30811 Bug ID: 30811 Summary: Unconditionally passed `-lto_library` to the linker on Darwin confused by symlinks Product: clang Version: trunk Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: howarth.mailing.li...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The change https://reviews.llvm.org/rL285254 to unconditionally pass `-lto_library` to the linker on Darwin is confused by the use of compiler symlinks. This approach doesn't work if the user installs clang in a buried subdirectory such as /sw/opt/llvm-4.0 but accesses the compilers via a /sw/bin/clang-4.0 symlink pointing at /sw/opt/llvm-4.0/bin/clang-4.0... $ /sw/bin/clang-4.0 -flto himenoBMTxpa.c clang-4.0: warning: libLTO.dylib relative to clang installed dir not found; using 'ld' default search path instead [-Wliblto] ... "/usr/bin/ld" -demangle -object_path_lto /var/folders/vh/xthx1f251nqfj804049zl1wmgn/T/cc-083c59.o -no_deduplicate -dynamic -arch x86_64 -macosx_version_min 10.11.0 -o a.out /var/folders/vh/xthx1f251nqfj804049zl1wmgn/T/himenoBMTxpa-34b8ea.o -lSystem /sw/opt/llvm-4.0/bin/../lib/clang/4.0.0/lib/darwin/libclang_rt.osx.a $ /sw/opt/llvm-4.0/bin/clang-4.0 -flto himenoBMTxpa.c -v ... "/usr/bin/ld" -demangle -object_path_lto /var/folders/vh/xthx1f251nqfj804049zl1wmgn/T/cc-afbbef.o -lto_library /sw/opt/llvm-4.0/lib/libLTO.dylib -no_deduplicate -dynamic -arch x86_64 -macosx_version_min 10.11.0 -o a.out /var/folders/vh/xthx1f251nqfj804049zl1wmgn/T/himenoBMTxpa-44b09e.o -lSystem /sw/opt/llvm-4.0/bin/../lib/clang/4.0.0/lib/darwin/libclang_rt.osx.a -- 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 30812] New: Binds for OpenMP offloading actions are not yet implemented for NVPTX targets
https://llvm.org/bugs/show_bug.cgi?id=30812 Bug ID: 30812 Summary: Binds for OpenMP offloading actions are not yet implemented for NVPTX targets Product: OpenMP Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Clang Compiler Support Assignee: unassignedclangb...@nondot.org Reporter: sfan...@us.ibm.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This entry is to document that clang driver support for OpenMP offloading is not yet prepared to generate jobs for NVPTX targets even though it is able to generate the actions correctly, including when compiling with both OpenMP and CUDA support. Generated jobs require NVPTX/CUDA toolchain support to be implemented which is work under progress. The OpenMP implementation cannot use the current implementation that CUDA uses given that it interprets linking differently: it expects linking to happen between code from different compilation units whereas CUDA just bundles the implementations for different arch into a fatbinary. -- 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 30813] New: Assertion `ShiftBits != 0 && MaskBits <= Size' failed.
https://llvm.org/bugs/show_bug.cgi?id=30813
Bug ID: 30813
Summary: Assertion `ShiftBits != 0 && MaskBits <= Size' failed.
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: vsevolod.livins...@frtk.ru
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17502
--> https://llvm.org/bugs/attachment.cgi?id=17502&action=edit
Reproducer.
Assertion `ShiftBits != 0 && MaskBits <= Size' failed. Everything works fine
with -O1 and above.
Reproducer:
short a, b;
struct d {
int c : 1017;
};
struct f {
d e;
};
struct {
f g;
} h;
int i;
void j() {
long k = unsigned((unsigned long)5 >>
(i & long(405769815438914582 < (b >= 0)) / 1));
h.g.e.c = a;
}
LLVM version:
clang version 4.0.0 (trunk 284990)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/vlivinsk/workspace/llvm/bin-trunk/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
Error:
>$ clang++ -O0 small.cpp
clang-4.0:
/home/vlivinsk/workspace/llvm/llvm-trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:3064:
llvm::SDValue {anonymous}::DAGCombiner::visitANDLike(llvm::SDValue,
llvm::SDValue, llvm::SDNode*): Assertion `ShiftBits != 0 && MaskBits <= Size'
failed.
#0 0x014298b8 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0x14298b8)
#1 0x0142750e llvm::sys::RunSignalHandlers()
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0x142750e)
#2 0x01427682 SignalHandler(int)
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0x1427682)
#3 0x7f9d37ea93d0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x113d0)
#4 0x7f9d3705f418 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35418)
#5 0x7f9d3706101a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3701a)
#6 0x7f9d37057bd7 (/lib/x86_64-linux-gnu/libc.so.6+0x2dbd7)
#7 0x7f9d37057c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
#8 0x00786148 (anonymous
namespace)::DAGCombiner::visitANDLike(llvm::SDValue, llvm::SDValue,
llvm::SDNode*) [clone .isra.512]
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0x786148)
#9 0x01a57249 (anonymous
namespace)::DAGCombiner::visitAND(llvm::SDNode*)
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0x1a57249)
#10 0x01a5d83f (anonymous namespace)::DAGCombiner::visit(llvm::SDNode*)
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0x1a5d83f)
#11 0x01a5e99f (anonymous
namespace)::DAGCombiner::combine(llvm::SDNode*)
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0x1a5e99f)
#12 0x01a607df llvm::SelectionDAG::Combine(llvm::CombineLevel,
llvm::AAResults&, llvm::CodeGenOpt::Level)
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0x1a607df)
#13 0x01b13b58 llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0x1b13b58)
#14 0x01b1e2dc
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0x1b1e2dc)
#15 0x01b204f9
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) [clone
.part.722] [clone .constprop.746]
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0x1b204f9)
#16 0x009e9d04 (anonymous
namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0x9e9d04)
#17 0x00d37955
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0xd37955)
#18 0x0103f803 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0x103f803)
#19 0x0103f8cc llvm::FPPassManager::runOnModule(llvm::Module&)
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0x103f8cc)
#20 0x0103f36d llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0x103f36d)
#21 0x015b34e8 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions
const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction,
std::unique_ptr >)
(/home/vlivinsk/workspace/llvm/bin-trunk/bin/clang-4.0+0x15b34e8)
#22 0x01be2623
clang::BackendConsumer::HandleTranslationUnit(cl
[llvm-bugs] [Bug 30535] Crash on atomics/builtins when optimization is enabled
https://llvm.org/bugs/show_bug.cgi?id=30535 Martin Storsjö changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Martin Storsjö --- It seems like this issue has been fixed in SVN r284633. -- 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 30532] fatal error: error in backend: out of range pc-relative fixup value
https://llvm.org/bugs/show_bug.cgi?id=30532 Martin Storsjö changed: What|Removed |Added Status|RESOLVED|REOPENED CC||mar...@martin.st Resolution|FIXED |--- --- Comment #5 from Martin Storsjö --- It doesn't seem to be a complete fix; see https://llvm.org/bugs/show_bug.cgi?id=30356 for an issue which still can be triggered. -- 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 30619] segfault in ConvertTypeToDiagnosticString when compiling
https://llvm.org/bugs/show_bug.cgi?id=30619 rtr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||rtr...@google.com Resolution|--- |FIXED --- Comment #3 from rtr...@google.com --- Fixed in r285370. -- 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 30814] New: linker script command line option handling
https://llvm.org/bugs/show_bug.cgi?id=30814 Bug ID: 30814 Summary: linker script command line option handling Product: lld Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: b...@comstyle.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified While testing out linking the OpenBSD/amd64 boot blocks/loader with lld I noticed what looks like an issue with the command line option handling for linker scripts.. ld.lld -nostdlib -Ttext 0 -x -s -Bstatic -e start -nopie -melf_i386 -L/usr/libdata -o mbr mbr.o ld.lld: error: cannot open text: No such file or directory ld.lld: error: cannot open 0: No such file or directory ld.lld -nostdlib -Ttext 0x -x -s -Bstatic -e start -nopie -melf_i386 -L/usr/libdata -o cdbr cdbr.o ld.lld: error: cannot open text: No such file or directory ld.lld: error: cannot open 0x: No such file or directory ld.lld -nostdlib -Bstatic -Ttext 0x40120 -x -nopie -melf_i386 -L/usr/libdata -o boot.new srt0.o conf.o boot.o bootarg.o cmd.o vars.o gidt.o random_i386.o cmd_i386.o dev_i386.o exec_i386.o gateA20.o machdep.o bioscons.o biosdev.o diskprobe.o memprobe.o time.o softraid.o alloc.o ctime.o exit.o getchar.o memcmp.o memcpy.o memset.o printf.o putchar.o snprintf.o strcmp.o strerror.o strlen.o strncmp.o strncpy.o strtol.o strtoll.o close.o closeall.o cons.o cread.o dev.o disklabel.o dkcksum.o fstat.o lseek.o open.o read.o readdir.o stat.o elf32.o elf64.o loadfile.o ufs.o aes_xts.o explicit_bzero.o hmac_sha1.o pbkdf2.o rijndael.o sha1.o divdi3.o moddi3.o qdivrem.o strlcpy.o adler32.o crc32.o inflate.o inftrees.o ld.lld: error: cannot open text: No such file or directory ld.lld: error: cannot open 0x40120: No such file or directory -- 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 30815] New: linking OpenBSD/amd64 kernel
https://llvm.org/bugs/show_bug.cgi?id=30815
Bug ID: 30815
Summary: linking OpenBSD/amd64 kernel
Product: lld
Version: unspecified
Hardware: PC
OS: OpenBSD
Status: NEW
Severity: normal
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: b...@comstyle.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I'm opening this as a tracker for issues that pertain to linking the
OpenBSD/amd64 kernel with lld. With the recent work that went into the
improvements with the linker script support lld can now link the kernel without
any errors or warnings (because of other additional fixes that went in), but
the resulting kernel is not bootable vs the kernel built with bfd (our binutils
2.17 + patches). It looks like it is failing to load the kernel with the boot
loader.
$ make LD=ld
ld -T ../../../../arch/amd64/conf/ld.script -X --warn-common -nopie -S -o bsd
${SYSTEM_HEAD} vers.o ${OBJS}
textdatabss dec hex
9116384 267112 671744 10055240996e48
$ rm bsd
$ make LD=ld.lld
ld.lld -T ../../../../arch/amd64/conf/ld.script -X --warn-common -nopie -S -o
bsd ${SYSTEM_HEAD} vers.o ${OBJS}
textdatabss dec hex
9120789 267112 671744 10059645997f7d
--
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 30784] Reassociate removes call but preserves CG, asserts
https://llvm.org/bugs/show_bug.cgi?id=30784 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Davide Italiano --- r285380 -- 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 30816] New: Parser rejects gep which passes the verifier
https://llvm.org/bugs/show_bug.cgi?id=30816
Bug ID: 30816
Summary: Parser rejects gep which passes the verifier
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: LLVM assembly language parser
Assignee: unassignedb...@nondot.org
Reporter: dav...@freebsd.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
> cat t.ll
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
@GV = global i64 0
define <8 x i64*> @patatino2() {
%el = getelementptr inbounds i64, i64* @GV, <8 x i64>
ret <8 x i64*> %el
}
> ~/llvm/Debug+Asserts/bin/opt -S t.ll -O2 | ~/llvm/Debug+Asserts/bin/llc -o -
> ~/llvm/Debug+Asserts/bin/llc: :10:18: error: getelementptr index type
> missmatch
> ret <8 x i64*> getelementptr (i64, i64* @GV, <8 x i64> i64 1, i64 0, i64 1, i64 0, i64 1>)
--
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 28277] The kind of cursor on a local template variable decleration is CXCursor_NoDeclFound (0n71)
https://llvm.org/bugs/show_bug.cgi?id=28277 David Schulz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from David Schulz --- *** This bug has been marked as a duplicate of bug 28278 *** -- 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 30817] New: Negative line number on 'expected relocation error'
https://llvm.org/bugs/show_bug.cgi?id=30817 Bug ID: 30817 Summary: Negative line number on 'expected relocation error' Product: new-bugs Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: pmatos@linki.tools CC: llvm-bugs@lists.llvm.org Classification: Unclassified test.S: .4byte ~foo #include "foo.h" foo.h: is an empty file. Then run: $ clang -cc1as -filetype obj -main-file-name test.S -dwarf-version=4 -fdebug-compilation-dir /home/pmatos/Clients/embecosm/BUGS/b447/asm-lineno -mrelocation-model static -dwarf-version=4 -o test.o test.s test.S:-2:8: error: expected relocatable expression .4byte ~foo ^ I very much doubt there's a line -2 in the file. However, I know what the problem is. At this point the parsing of the asm has finished. However the error handler calls DiagHandler which assumes the parsing is ongoing and uses CppHashLoc variables. These variable are however of no more use because they all now point to the last Hash line seen in the file, not the one before the error. I will submit a patch to fix this soon. -- 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 30260] optional not working
https://llvm.org/bugs/show_bug.cgi?id=30260 Eric Fiselier changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Eric Fiselier --- This has been fixed in both and . Additionally I added even more tests for std::optional in r285384. Closing as 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
