[llvm-bugs] [Bug 30720] [LTO] Try to be option compatible with the gold plugin
https://bugs.llvm.org/show_bug.cgi?id=30720 George Rimar changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from George Rimar --- With r324322 I believe we are automatically compatible with gold plugin options now. -- 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 34300] clang-format regression in current 5.0
https://bugs.llvm.org/show_bug.cgi?id=34300 Merlin Nimier-David changed: What|Removed |Added CC||merlin.nim...@gmail.com Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Merlin Nimier-David --- *** This bug has been marked as a duplicate of bug 36004 *** -- 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 35033] clang-format reformats already formatted code (comment before preprocessor directive)
https://bugs.llvm.org/show_bug.cgi?id=35033 Merlin Nimier-David changed: What|Removed |Added CC||merlin.nim...@gmail.com Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Merlin Nimier-David --- *** This bug has been marked as a duplicate of bug 36004 *** -- 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 36004] clang-format preprocessor indentation instability and trailing directive's off by one
https://bugs.llvm.org/show_bug.cgi?id=36004 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Hans Wennborg --- (In reply to Mark Zeren from comment #6) > Hans, please merge r323904 and r324246 into release_60. Merged in r324329 and r324331, respectively. -- 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 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 36004, which changed state. Bug 36004 Summary: clang-format preprocessor indentation instability and trailing directive's off by one https://bugs.llvm.org/show_bug.cgi?id=36004 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 36248] New: [clang-format] C++11 attribute confused for Objective-C code
https://bugs.llvm.org/show_bug.cgi?id=36248
Bug ID: 36248
Summary: [clang-format] C++11 attribute confused for
Objective-C code
Product: clang
Version: trunk
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: merlin.nim...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
The following C++ header file is confused for Objective-C code:
```
#pragma once
#include
class SomeClass : public Object {
int member;
};
void some_function() {
hello();
}
[[ noreturn ]] void other_function(int arg);
```
Removing the `[[ noreturn ]]` attribute results in correct detection.
My project uses a `.clang-format` configuration file that only specifies
configuration for `Language: Cpp`, and so invoking clang-format results in an
error:
$ clang-format -style=file simple.h
Configuration file(s) do(es) not support Objective-C:
/path/to/project/.clang-format
I also tried forcing language detection with:
$ clang-format -style=file -assume-filename=simple.hpp simple.h
but that results in the same error (I guess because this option is only active
when reading from stdin).
---
Workarounds:
$ mv simple.h simple.hpp
$ clang-format -style=file simple.hpp
Or:
$ cat simple.h | clang-format -style=file -assume-filename=simple.hpp
--
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 36249] New: Missing expansion of VLD1d64TPseudoWB_register and VLD1d64QPseudoWB_register
https://bugs.llvm.org/show_bug.cgi?id=36249 Bug ID: 36249 Summary: Missing expansion of VLD1d64TPseudoWB_register and VLD1d64QPseudoWB_register Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: thomas.preudho...@linaro.org CC: llvm-bugs@lists.llvm.org Created attachment 19815 --> https://bugs.llvm.org/attachment.cgi?id=19815&action=edit Reproducer for missing lowering of VLD1d64TPseudoWB_register and VLD1d64QPseudoWB_register Hi, The attached MIR testcase triggers an assert failure compiled with llc -mtriple armv7. This is due to missed lowering for VLD1d64TPseudoWB_register and VLD1d64QPseudoWB_register. -- 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 36250] New: DAGCombiner::SimplifySetCC fails for illegal integer types not compatible with getShiftAmountTy
https://bugs.llvm.org/show_bug.cgi?id=36250
Bug ID: 36250
Summary: DAGCombiner::SimplifySetCC fails for illegal integer
types not compatible with getShiftAmountTy
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: joker@gmail.com, llvm-bugs@lists.llvm.org,
spatel+l...@rotateright.com
Reduced from https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5787
define void @f() {
%1 = load i448, i448* undef
%2 = sub i448 0, %1
%3 = icmp eq i448 %1, %2
store i1 %3, i1* undef
ret void
}
--
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 30720] [LTO] Try to be option compatible with the gold plugin
https://bugs.llvm.org/show_bug.cgi?id=30720 George Rimar changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from George Rimar --- Reopening. Probably I was too fast when closing this. There is still a list of options that are handled manually and even if we don't need them, r324322 would not catch all possible new options if any. -- 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] Issue 6051 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: ArgIdx == 2 && "Invalid argument index"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-02-06 Type: Bug New issue 6051 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: ArgIdx == 2 && "Invalid argument index" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6051 Detailed report: https://oss-fuzz.com/testcase?key=6583734288515072 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-gvn Fuzz target binary: llvm-opt-fuzzer--x86_64-gvn Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: ArgIdx == 2 && "Invalid argument index" llvm::MemoryLocation::getForArgument llvm::AAResults::getModRefInfo Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802050757:201802060728 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6583734288515072 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36251] New: Crash in "intern-state" thread after removing breakpoints and continue
https://bugs.llvm.org/show_bug.cgi?id=36251 Bug ID: 36251 Summary: Crash in "intern-state" thread after removing breakpoints and continue Product: lldb Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: danti...@nvidia.com CC: llvm-bugs@lists.llvm.org Created attachment 19816 --> https://bugs.llvm.org/attachment.cgi?id=19816&action=edit Test program to debug under LLDB Crash after removing breakpoints and continue: #0 0x70e027b6 in std::__uniq_ptr_impl >::_M_ptr (this=0x28) at /usr/include/c++/7/bits/unique_ptr.h:147 #1 0x70e01cbe in std::unique_ptr >::get (this=0x28) at /usr/include/c++/7/bits/unique_ptr.h:337 #2 0x70e00860 in lldb_private::BreakpointOptions::GetThreadSpecNoCreate (this=0x0) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Breakpoint/BreakpointOptions.cpp:524 #3 0x70df6474 in lldb_private::BreakpointLocation::ValidForThisThread (this=0x61ad90, thread=0x7fffd40018f0) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Breakpoint/BreakpointLocation.cpp:387 #4 0x70df8c2b in lldb_private::BreakpointLocationCollection::ValidForThisThread (this=0x55e020, thread=0x7fffd40018f0) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Breakpoint/BreakpointLocationCollection.cpp:152 #5 0x70e10dd8 in lldb_private::BreakpointSite::ValidForThisThread (this=0x55dfd0, thread=0x7fffd40018f0) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Breakpoint/BreakpointSite.cpp:146 #6 0x714d602c in lldb_private::process_gdb_remote::ProcessGDBRemote::SetThreadStopInfo (this=0x5f1a40, tid=27530, expedited_register_map=..., signo=5 '\005', thread_name=..., reason=..., description=..., exc_type=0, exc_data=..., thread_dispatch_qaddr=18446744073709551615, queue_vars_valid=false, associated_with_dispatch_queue=lldb_private::eLazyBoolCalculate, dispatch_queue_t=18446744073709551615, queue_name=..., queue_kind=lldb::eQueueKindUnknown, queue_serial=0) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:1880 #7 0x714da439 in lldb_private::process_gdb_remote::ProcessGDBRemote::SetThreadStopInfo (this=0x5f1a40, stop_packet=...) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:2371 #8 0x714da598 in lldb_private::process_gdb_remote::ProcessGDBRemote::RefreshStateAfterStop (this=0x5f1a40) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:2407 #9 0x7110378c in lldb_private::Process::ShouldBroadcastEvent (this=0x5f1a40, event_ptr=0x7fffdc014a00) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Target/Process.cpp:3658 #10 0x7110411d in lldb_private::Process::HandlePrivateEvent (this=0x5f1a40, event_sp=...) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Target/Process.cpp:3907 #11 0x71104959 in lldb_private::Process::RunPrivateStateThread (this=0x5f1a40, is_secondary_thread=false) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Target/Process.cpp:4106 #12 0x711044b2 in lldb_private::Process::PrivateStateThread (arg=0x614210) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Target/Process.cpp:3999 #13 0x70f7a6e7 in lldb_private::HostNativeThreadBase::ThreadCreateTrampoline (arg=0x616250) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Host/common/HostNativeThreadBase.cpp:66 #14 0x77bbf36d in start_thread () from /lib64/libpthread.so.0 #15 0x7fffef3d6b4f in clone () from /lib64/libc.so.6 Steps to reproduce and full backtrace: $ gdb -q /home/dantipov/.local/llvm-6.0.0/bin/lldb Reading symbols from /home/dantipov/.local/llvm-6.0.0/bin/lldb...done. (gdb) r Starting program: /home/dantipov/.local/llvm-6.0.0/bin/lldb [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7fffede7e700 (LWP 28281)] (lldb) version lldb version 6.0.0 (http://llvm.org/svn/llvm-project/lldb/tags/RELEASE_600/rc1 revision 324341) clang revision 324341 llvm revision 324341 (lldb) at 27528 [New Thread 0x7fffed67d700 (LWP 28619)] [New Thread 0x7fffece7c700 (LWP 28620)] [New Thread 0x7fffe7fff700 (LWP 28624)] Process 27528 stopped * thread #1, name = 'bug', stop reason = signal SIGSTOP frame #0: 0x7fc50e8f989d libpthread.so.0`pthread_join + 189 libpthread.so.0`pthread_join: -> 0x7fc50e8f989d <+189>: movslq 0x2d0(%rbx), %rdx 0x7fc50e8f98a4 <+196>: testl %edx, %edx 0x7fc50e8f98a6 <+198>: jne0x7fc50e8f9890; <+176> 0x7fc50e8f98a8 <+200>: movl %r13d, %edi thread #2, name = 'worker 0', stop reason = signal SIGSTOP frame #0: 0
[llvm-bugs] [Bug 36252] New: [AMDGPU][MC][CODEGEN] Incorrect definition of GATHER4 opcodes
https://bugs.llvm.org/show_bug.cgi?id=36252 Bug ID: 36252 Summary: [AMDGPU][MC][CODEGEN] Incorrect definition of GATHER4 opcodes Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org Currently GATHER4 opcodes are defined in a way similar to other non-atomic MIMG opcodes. Dst size depends on how many bits are set in DMask which can have any 4-bit value. However, GATHER4 opcodes have a few differences from other MIMG instructions: - DMask must have only one bit set to 1; - Dst size is fixed: - for SI, CI and gfx8.0, dst size is 4 dwords. - for gfx8.1 and gfx9, dst size is 4 or 2 dwords depending on d16. This difference affects: - MC layer - Codegen -- 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 6994] Warning on use of implicit this
https://bugs.llvm.org/show_bug.cgi?id=6994 Alexander Kornienko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- 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] Issue 6052 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: ID < (MDStringRef.size()) + GlobalMetadataBitPosIndex.size()
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-02-06 Type: Bug New issue 6052 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: ID < (MDStringRef.size()) + GlobalMetadataBitPosIndex.size() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6052 Detailed report: https://oss-fuzz.com/testcase?key=5423687848165376 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-gvn Fuzz target binary: llvm-opt-fuzzer--x86_64-gvn Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: ID < (MDStringRef.size()) + GlobalMetadataBitPosIndex.size() llvm::MetadataLoader::MetadataLoaderImpl::lazyLoadOneMetadata llvm::MetadataLoader::MetadataLoaderImpl::resolveForwardRefsAndPlaceholders Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802050757:201802060728 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5423687848165376 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 8404] ICE in ScheduleDAG.cpp:460: "Wrong topological sorting"
https://bugs.llvm.org/show_bug.cgi?id=8404 Nirav Dave changed: What|Removed |Added CC||nir...@google.com Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #6 from Nirav Dave --- The test no longer fails, but based on the DAG it looks like this was the due to a hole in cycle detection around indirect chain dependencies which was fixed in rL324359. -- 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 15941] llc crash: "Wrong topological sorting"
https://bugs.llvm.org/show_bug.cgi?id=15941 Nirav Dave changed: What|Removed |Added Status|NEW |RESOLVED CC||nir...@google.com Resolution|--- |FIXED --- Comment #10 from Nirav Dave --- The missed cycles / false dependencies TokenFactors were resolved by rL324359 and rL323977 respectively. -- 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 19237] ISel DAG: HandleMergeInputChains is overly conservative
https://bugs.llvm.org/show_bug.cgi?id=19237 Nirav Dave changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nirav Dave --- This particular testcase has improved already but a nonconservative fix landed in rL324359. -- 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 36164] [SelectionDAG] Seemingly incorrect updating of chains in UpdateChains()
https://bugs.llvm.org/show_bug.cgi?id=36164 Nirav Dave changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Nirav Dave --- Landed @ rL323977 -- 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 33469] UTIME_OMIT shouldn't be used to detect presence of utimensat()
https://bugs.llvm.org/show_bug.cgi?id=33469 Nico Weber changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||nicolaswe...@gmx.de --- Comment #17 from Nico Weber --- r324385 -- 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 36025] asan: AddressSanitizer-*-linux-dynamic :: TestCases/Linux/asan_rt_confict_test-1.cc fails on Gentoo stand-alone build
https://bugs.llvm.org/show_bug.cgi?id=36025 Michał Górny changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Michał Górny --- Indeed the patch fixes it for me. Thanks! *** This bug has been marked as a duplicate of bug 35996 *** -- 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 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 36025, which changed state. Bug 36025 Summary: asan: AddressSanitizer-*-linux-dynamic :: TestCases/Linux/asan_rt_confict_test-1.cc fails on Gentoo stand-alone build https://bugs.llvm.org/show_bug.cgi?id=36025 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE -- 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 36253] New: llvm.bitreverse.i64 returns wrong value
https://bugs.llvm.org/show_bug.cgi?id=36253
Bug ID: 36253
Summary: llvm.bitreverse.i64 returns wrong value
Product: libraries
Version: 5.0
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: k...@redstar.de
CC: llvm-bugs@lists.llvm.org
Created attachment 19818
--> https://bugs.llvm.org/attachment.cgi?id=19818&action=edit
LLVM IR demonstring the problem.
The following code produces an unexpected output. It is a reduced version of
the following D code:
import ldc.intrinsics;
import core.stdc.stdio : printf;
int main()
{
auto exp = 1UL << 63;
printf("%lx\n", exp);
auto arg = 1UL << 0;
printf("%lx\n", arg);
auto val = llvm_bitreverse(arg);
printf("%lx\n", val);
return exp != val;
}
LLVM IR:
source_filename = "bitop.d"
target datalayout = "e-m:e-i64:64-n32:64"
target triple = "powerpc64le-unknown-linux-gnu"
@.str = private unnamed_addr constant [5 x i8] c"%lx\0A\00"
declare signext i32 @printf(i8*, ...)
declare i64 @llvm.bitreverse.i64(i64)
define signext i32 @main(i32 signext %argc_arg, i8** %argv_arg) {
%exp = alloca i64, align 8
%arg = alloca i64, align 8
%val = alloca i64, align 8
store i64 -9223372036854775808, i64* %exp
%1 = load i64, i64* %exp
%2 = call signext i32 (i8*, ...) @printf(i8* getelementptr inbounds ([5 x
i8], [5 x i8]* @.str, i32 0, i32 0), i64 %1)
store i64 1, i64* %arg
%3 = load i64, i64* %arg
%4 = call signext i32 (i8*, ...) @printf(i8* getelementptr inbounds ([5 x
i8], [5 x i8]* @.str, i32 0, i32 0), i64 %3)
%5 = load i64, i64* %arg
%6 = call i64 @llvm.bitreverse.i64(i64 %5)
store i64 %6, i64* %val
%7 = load i64, i64* %val
%8 = call signext i32 (i8*, ...) @printf(i8* getelementptr inbounds ([5 x
i8], [5 x i8]* @.str, i32 0, i32 0), i64 %7)
%9 = load i64, i64* %exp
%10 = load i64, i64* %val
%11 = icmp ne i64 %9, %10
%12 = zext i1 %11 to i32
ret i32 %12
}
Compile and run:
llc -filetype=obj bitop.ll
gcc bitop.o -o bitop
./bitop
echo "Ret: $?"
Result:
8000
1
8000
Ret: 1
If you change the line
%6 = call i64 @llvm.bitreverse.i64(i64 %5)
to
%6 = call i64 @llvm.bitreverse.i64(i64 %3)
or to
%6 = call i64 @llvm.bitreverse.i64(i64 1)
then the expected output
8000
1
8000
Ret: 0
is produced.
LLVM used:
ubuntu@ldc:/tmp/unittest$ /home/ubuntu/build-llvm/bin/llc --version
LLVM (http://llvm.org/):
LLVM version 5.0.1git-6af15925d78
DEBUG build with assertions.
Default target: powerpc64le-unknown-linux-gnu
Host CPU: pwr8
Registered Targets:
nvptx - NVIDIA PTX 32-bit
nvptx64 - NVIDIA PTX 64-bit
ppc32 - PowerPC 32
ppc64 - PowerPC 64
ppc64le - PowerPC 64 LE
Environment:
ubuntu@ldc:/tmp/unittest$ uname -a
Linux ldc 4.13.0-32-generic #35-Ubuntu SMP Thu Jan 25 09:05:20 UTC 2018 ppc64le
ppc64le ppc64le GNU/Linux
--
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] Issue 6057 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: !carry
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-02-06 Type: Bug New issue 6057 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: !carry https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6057 Detailed report: https://oss-fuzz.com/testcase?key=5660146232459264 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--aarch64-gisel Fuzz target binary: llvm-isel-fuzzer--aarch64-gisel Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !carry llvm::detail::IEEEFloat::addOrSubtractSignificand llvm::detail::IEEEFloat::multiplySignificand Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801290646:201801300702 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5660146232459264 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36254] New: LLVM trunk generates AVX512BW instructions on KNL architecture
https://bugs.llvm.org/show_bug.cgi?id=36254 Bug ID: 36254 Summary: LLVM trunk generates AVX512BW instructions on KNL architecture Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: wenzel.ja...@epfl.ch CC: llvm-bugs@lists.llvm.org After upgrading to the latest trunk, I've noticed that LLVM sometimes generates instructions AVX512BW instructions for the -march=knl target. These naturally cause the application to fail. See e.g. the following LLDB trace, where a "kmovd" instruction appears. This instruction should never be emitted, as it is not part of AVX512F/ER/CD. Process 161252 launched: '/home/wjakob/mitsuba2/dist/mitsuba2' (x86_64) Process 161252 stopped * thread #1, name = 'mitsuba', stop reason = signal SIGILL: illegal instruction operand frame #0: 0x41b1a5f6 libmitsuba-core.so`mitsuba::RadicalInverse::eval_scrambled(unsigned long, enoki::Packet) const + 182 libmitsuba-core.so`mitsuba::RadicalInverse::eval_scrambled: -> 0x41b1a5f6 <+182>: kmovd dword ptr [rsp + 0x24], k1 0x41b1a5fd <+189>: vptestmq k1, zmm3, zmm3 0x41b1a603 <+195>: kmovd dword ptr [rsp + 0x20], k1 0x41b1a60a <+202>: vpbroadcastq zmm1, rcx The application that causes this is unfortunately very large, so I hope that this trace is helpful enough to look for a potential cause. -- 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 36255] New: Clang++ crashes on assertion when compiling source
https://bugs.llvm.org/show_bug.cgi?id=36255 Bug ID: 36255 Summary: Clang++ crashes on assertion when compiling source Product: clang Version: trunk Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: i...@kapsi.fi CC: llvm-bugs@lists.llvm.org Created attachment 19819 --> https://bugs.llvm.org/attachment.cgi?id=19819&action=edit Pre-processed source file and run-script related to the crash I am not very knowledgeable how Clang works and thus I am unable to give any hints what exactly went wrong. Attached are the pre-processed source and run-script. clang version 7.0.0 Target: x86_64-portbld-freebsd11.1 Thread model: posix InstalledDir: /usr/local/llvm-devel/bin And here is the crash backtrace: Assertion failed: (Info.Ctx.hasSameType(BaseIt->getType(), BaseType) && "base class initializers not in expected order"), function HandleConstructorCall, file /wrkdirs/usr/ports/devel/llvm-devel/work/llvm-4f82436e1ddfde29383d98790bbac9de3612f092/tools/clang/lib/AST/ExprConstant.cpp, line 4383. #0 0x01e777f8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/llvm-devel/bin/clang-7.0+0x1e777f8) #1 0x01e77e16 (/usr/local/llvm-devel/bin/clang-7.0+0x1e77e16) #2 0x000804fe2926 (/lib/libthr.so.3+0xe926) #3 0x000804fe1ecf (/lib/libthr.so.3+0xdecf) Stack dump: 0. Program arguments: /usr/local/llvm-devel/bin/clang-7.0 -cc1 -triple x86_64-portbld-freebsd11.1 -emit-obj -mrelax-all -disable-free -main-file-name meta.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -resource-dir /usr/local/llvm-devel/lib/clang/7.0.0 -I include -internal-isystem /usr/include/c++/v1 -pedantic --std=c++1z -fdeprecated-macro -fdebug-compilation-dir /home/dev/projects/c++/meta -ferror-limit 19 -fmessage-length 113 -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/meta-84dcf9.o -x c++ meta.cpp 1. parser at end of file 2. meta.cpp:278:5: LLVM IR generation of declaration 'main' 3. meta.cpp:278:5: Generating code for declaration 'main' clang-7.0: error: unable to execute command: Abort trap (core dumped) clang-7.0: error: clang frontend command failed due to signal (use -v to see invocation) clang version 7.0.0 Target: x86_64-portbld-freebsd11.1 Thread model: posix InstalledDir: /usr/local/llvm-devel/bin clang-7.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-7.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-7.0: note: diagnostic msg: /tmp/meta-e36efc.cpp clang-7.0: note: diagnostic msg: /tmp/meta-e36efc.sh clang-7.0: note: diagnostic msg: -- 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 36256] New: [X86] Couple lit tests generate KMOVQ instructions on KNL which doesn't support KMOVQ
https://bugs.llvm.org/show_bug.cgi?id=36256 Bug ID: 36256 Summary: [X86] Couple lit tests generate KMOVQ instructions on KNL which doesn't support KMOVQ Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: craig.top...@gmail.com CC: llvm-bugs@lists.llvm.org While investing PR36254, I discovered that this two tests try to preserve k-registers with a spill size of 64 bits which trigger us to use kmovq. But KNL doesn't support KMOVQ/KMOVD and should use a spill size of 16 bits. LLVM :: CodeGen/X86/avx512-intel-ocl.ll LLVM :: CodeGen/X86/x86-interrupt_cc.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 36257] New: llvm-dsymutil crash @llvm::DWARFFormValue::extractValue on rustc-produced object
https://bugs.llvm.org/show_bug.cgi?id=36257 Bug ID: 36257 Summary: llvm-dsymutil crash @llvm::DWARFFormValue::extractValue on rustc-produced object Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: llvm-dwarfdump Assignee: unassignedb...@nondot.org Reporter: mh+l...@glandium.org CC: fr...@apple.com, llvm-bugs@lists.llvm.org Stack trace: #0 0x0081422a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (../workspace/build/src/llvm/build/bin/llvm-dsymutil+0x81422a) #1 0x008126ee llvm::sys::RunSignalHandlers() (../workspace/build/src/llvm/build/bin/llvm-dsymutil+0x8126ee) #2 0x0081282a SignalHandler(int) (../workspace/build/src/llvm/build/bin/llvm-dsymutil+0x81282a) #3 0x7f948b3c20a0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0xf0a0) #4 0x00705a24 llvm::DWARFFormValue::extractValue(llvm::DWARFDataExtractor const&, unsigned int*, llvm::DWARFFormParams, llvm::DWARFContext const*, llvm::DWARFUnit const*) (../workspace/build/src/llvm/build/bin/llvm-dsymutil+0x705a24) #5 0x006dddc9 llvm::DWARFAbbreviationDeclaration::getAttributeValue(unsigned int, llvm::dwarf::Attribute, llvm::DWARFUnit const&) const (../workspace/build/src/llvm/build/bin/llvm-dsymutil+0x6dddc9) #6 0x00701143 llvm::DWARFDie::find(llvm::dwarf::Attribute) const (../workspace/build/src/llvm/build/bin/llvm-dsymutil+0x7011 43) #7 0x0070124e llvm::DWARFDie::getAttributeValueAsReferencedDie(llvm::dwarf::Attribute) const (../workspace/build/src/llvm/build/bin/llvm-dsymutil+0x70124e) #8 0x0070138e llvm::DWARFDie::findRecursively(llvm::ArrayRef) const (../workspace/build/src/llvm/build/bin/llvm-dsymutil+0x70138e) #9 0x007013b2 llvm::DWARFDie::findRecursively(llvm::ArrayRef) const (../workspace/build/src/llvm/build/bin/llvm-dsymutil+0x7013b2) A somewhat reduced testcase is available at: https://queue.taskcluster.net/v1/task/ODoRBkEDRVKjy74Ymhxw0g/runs/0/artifacts/public/build/dsymutil-crasher.tar.xz (This should "only" expire in a year) Untar, go into the "crasher" directory this extracts, and run the "run-me.sh" script. If you want to use something else than `llvm-dsymutil` from your $PATH, set the DSYMUTIL environment variable to the path of the dsymutil you want to use. -- 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 36258] New: Include comprehensive list of all LLDB settings
https://bugs.llvm.org/show_bug.cgi?id=36258 Bug ID: 36258 Summary: Include comprehensive list of all LLDB settings Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: michael.ei...@gmail.com CC: llvm-bugs@lists.llvm.org It would be great to see a full list of the settings for LLDB. Or, if it already exists, to make it easier to find. -- 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 36259] New: Analyzer reports memory leak when returning vector of pointers from function in shared library
https://bugs.llvm.org/show_bug.cgi?id=36259
Bug ID: 36259
Summary: Analyzer reports memory leak when returning vector of
pointers from function in shared library
Product: clang
Version: 5.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: jakob.le...@gmail.com
CC: llvm-bugs@lists.llvm.org
The following example causes a potential memory leak report:
example-bad.cpp
#include
std::vector create_ints()
{
return { new int };
}
-
$ scan-build-5.0 clang++-5.0 -shared example-bad.cpp -std=c++11 -fPIC
scan-build: Using '/usr/lib/llvm-5.0/bin/clang' for static analysis
example-bad.cpp:6:12: warning: Potential memory leak
return { new int };
^~~
The following example doesn't cause the memory leak report though:
example-good.cpp
int * create_int()
{
return new int;
}
-
$ scan-build-5.0 clang++-5.0 -shared example-good.cpp -std=c++11 -fPIC
...
scan-build: No bugs found.
I would like the first example to not cause the report, just like the second.
The allocated memory is supposed to be returned by the program linked to the
library.
--
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 36260] New: Possibly missed optimization (performance and code size) when comparing floats as raw binary
https://bugs.llvm.org/show_bug.cgi?id=36260
Bug ID: 36260
Summary: Possibly missed optimization (performance and code
size) when comparing floats as raw binary
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: kobalicek.p...@gmail.com
CC: llvm-bugs@lists.llvm.org
The following code
--
#include
#include
#include
union F64 {
double d;
uint64_t u;
};
uint32_t compareBin(double a, double b) noexcept {
F64 a_ = { a };
F64 b_ = { b };
return a_.u == b_.u;
}
uint32_t compareDbl(double a, double b) noexcept {
return a == b;
}
Compiles to (-O2 -mavx2 -fno-math-errno):
-
compareBin(double, double): # @compareBin(double, double)
vmovq rcx, xmm0
vmovq rdx, xmm1
xor eax, eax
cmp rcx, rdx
sete al
ret
compareDbl(double, double): # @compareDbl(double, double)
vcmpeqsd xmm0, xmm0, xmm1
vmovq rax, xmm0
and eax, 1
ret
I think the `compareBin` should use the same approach as `compareDbl`, which
would be:
compareBin(double, double):
vpcmpeqq xmm0, xmm0, xmm1
vmovq rax, xmm0
and eax, 1
ret
--
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 32000] Cannot mangle swiftcall convention in MS C++ ABI
https://bugs.llvm.org/show_bug.cgi?id=32000 Saleem Abdulrasool changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Saleem Abdulrasool --- Discussed with Microsoft offline. They have reserved 'S' for the Swift CC. This has been implemented in SVN r324439. -- 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 33777] llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion `Node2Index[SU.NodeNum] > Node2Index[PD.getSUnit()->NodeNum]
https://bugs.llvm.org/show_bug.cgi?id=33777 Nirav Dave changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Nirav Dave --- (In reply to Simon Pilgrim from comment #9) > Nirav, any chance that your recent patches have fixed this? Yes. Looking at the DAGs this looks to be almost the same issue as PR36164. -- 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 19555] Segmentation fault in llvm::InstrEmitter::getVR
https://bugs.llvm.org/show_bug.cgi?id=19555 Nirav Dave changed: What|Removed |Added Status|NEW |RESOLVED CC||nir...@google.com Resolution|--- |DUPLICATE --- Comment #2 from Nirav Dave --- *** This bug has been marked as a duplicate of bug 8404 *** -- 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] Issue 6063 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: use_empty() && "Uses remain when a value is destroyed!"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-02-07 Type: Bug New issue 6063 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: use_empty() && "Uses remain when a value is destroyed!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6063 Detailed report: https://oss-fuzz.com/testcase?key=4644837069422592 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-gvn Fuzz target binary: llvm-opt-fuzzer--x86_64-gvn Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: use_empty() && "Uses remain when a value is destroyed!" llvm::Value::~Value llvm::DenseMapBasestd::__1::unique_ptr Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802050757:201802060728 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4644837069422592 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36261] New: Compilation error in std::tuple when using -fmodules-ts and -std=c++17
https://bugs.llvm.org/show_bug.cgi?id=36261 Bug ID: 36261 Summary: Compilation error in std::tuple when using -fmodules-ts and -std=c++17 Product: libc++ Version: 5.0 Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: kumaran.santha...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Created attachment 19821 --> https://bugs.llvm.org/attachment.cgi?id=19821&action=edit compile.sh 1. Install Clang 5.0 2. Download http://releases.llvm.org/5.0.1/libcxx-5.0.1.src.tar.xz 3. Untar the package into a directory 4. Save the attached compile.sh script into the directory 5. ./compile.sh -std=c++11 6. ./compile.sh -std=c++17 Using -std=c++11 succeeds while using -std=c++17 produces a compilation error. The problem appears to be in the #ifdef block starting at line 993 in the libcxx-5.0.1.src/include/tuple header file. -- 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
