[llvm-bugs] Issue 18325 in oss-fuzz: llvm:clang-fuzzer: Null-dereference READ in clang::Sema::DeclareImplicitCopyConstructor
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-10-18 Type: Bug New issue 18325 by ClusterFuzz-External: llvm:clang-fuzzer: Null-dereference READ in clang::Sema::DeclareImplicitCopyConstructor https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18325 Detailed Report: https://oss-fuzz.com/testcase?key=5726005905326080 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x Crash State: clang::Sema::DeclareImplicitCopyConstructor void llvm::function_refRegressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=201906300300:201910150335 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5726005905326080 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. 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 need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43708] New: -Wc++2a-compat erroneously emitted before preprocessing is complete
https://bugs.llvm.org/show_bug.cgi?id=43708 Bug ID: 43708 Summary: -Wc++2a-compat erroneously emitted before preprocessing is complete Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: C++2a Assignee: unassignedclangb...@nondot.org Reporter: enieb...@boost.org CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Compile the following with -std=c++17 -Wc++2a-compat -Werror: #define LPAREN ( #define EXPAND(...) __VA_ARGS__ #define EAT(...) EAT(requires) // OK, no warning. EXPAND(EAT LPAREN requires)) // Oops, warning. This file emits no tokens after full preprocessing; however, the compiler still complains about the presence of the `requires` keyword on the last line. Note that `EAT(requires)` compiles without warning, which leads me to believe that the warning is looking for C++20 keywords after each macro expansion instead of after full expansion. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 18084] Assertion failed: (Weights.size() >= 2 && "Need at least two branch weights!"), function createBranchWeights
https://bugs.llvm.org/show_bug.cgi?id=18084 Andriy Gapon changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #2 from Andriy Gapon --- Overcome by time, actually. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42389] InstCombine: lshr + "sext" => ashr canonicalization
https://bugs.llvm.org/show_bug.cgi?id=42389 Roman Lebedev changed: What|Removed |Added Status|RESOLVED|REOPENED 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41268] Fail hard (or support) wildcard characters
https://bugs.llvm.org/show_bug.cgi?id=41268 Jordan Rupprecht changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Fixed By Commit(s)||r375169 --- Comment #10 from Jordan Rupprecht --- Glob support improved in r375149, llvm-objcopy change landed in r375169. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43707] New: Constructing objects in expressions doesn't work on Windows
https://bugs.llvm.org/show_bug.cgi?id=43707
Bug ID: 43707
Summary: Constructing objects in expressions doesn't work on
Windows
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: teempe...@gmail.com
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
Trying to construct an object in the expression parser doesn't seem to work on
Windows.
Simple reproducer is in
test/commands/expression/ignore-artificial-constructors:
```
struct Foo {
// Triggers that we emit an artificial constructor for Foo.
virtual ~Foo() = default;
};
int main() {
Foo f;
// Try to construct foo in our expression.
return 0; //%self.expect("expr Foo()", substrs=["(Foo) $0 = {}"])
}
```
This fails on Windows with the following error:
```
AssertionError: False is not True : Command 'expr Foo()
Error output:
error: The expression could not be prepared to run in the target
' returns successfully
```
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43706] New: Compiling CUDA does not predefine macros according to doc
https://bugs.llvm.org/show_bug.cgi?id=43706
Bug ID: 43706
Summary: Compiling CUDA does not predefine macros according to
doc
Product: clang
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: eldlistmaili...@tropicsoft.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
According to the documentation regarding clang and CUDA at
https://llvm.org/docs/CompileCudaWithLLVM.html#detecting-clang-vs-nvcc-from-code,
when compiling a CUDA file with clang, the macros __clang__, __CUDA__, and
__CUDACC__ are predefined. Yet given this source as 'clang_cuda_example.cu':
#if !defined(__clang__)
#if !defined(__CUDACC__)
#if !defined(__CUDA__)
#error The predefined macros __clang__ and __CUDACC__ and __CUDA__ are not
defined
#else
#error The predefined macros __clang__ and __CUDACC__ are not defined
#endif
#elif !defined(__CUDA__)
#error The predefined macros __clang__ and __CUDA__ are not defined
#else
#error The predefined macro __clang__ is not defined
#endif
#elif !defined(__CUDACC__)
#if !defined(__CUDA__)
#error The predefined macros __CUDACC__ and __CUDA__ are not defined
#else
#error The predefined macro __CUDACC__ is not defined
#endif
#elif !defined(__CUDA__)
#error The predefined macro __CUDA__ is not defined
#endif
int main(void) { return 0; }
If I compile this with:
clang++ -c -m64 -nocudainc -nocudalib -x cuda clang_cuda_example.cu
the output is:
"clang_cuda_example.cu:17:2: error: The predefined macro __CUDACC__ is not
defined
#error The predefined macro __CUDACC__ is not defined
^
1 error generated when compiling for sm_20."
So either the documentation regarding clang and CUDA is incorrect or there is a
bug in clang when compiling CUDA files. If something else must be present when
compiling a CUDA file so that the __CUDAACC__ macro is predefined the
documentation should specify what that is.
I realize that my test does not actually compile any CUDA code despite the
source file ending with .cu and also telling the clang compiler, through the
'-x cuda' compiler option, that I am compiling a CUDA file. I am trying to test
clang compilation of CUDA code for a change I made in the Boost preprocessor
library, of which I am the maintainer, and I need a minimum test which shows
that clang compiling a CUDA file does indeed define the predefined macros which
the documentation says it does.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43705] New: [InstCombine] ashr disguised as lshr+signmask
https://bugs.llvm.org/show_bug.cgi?id=43705
Bug ID: 43705
Summary: [InstCombine] ashr disguised as lshr+signmask
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
I don't really personally need this, but i just noticed that we don't do this
fold,
so documenting. One might write such a monstrosity because technically,
arithmetic right shift is implementation defined until C++20 (don't know about
C.)
https://godbolt.org/z/XPn2Dw
#include
int t0(unsigned x, unsigned y) {
uint32_t bottom = x >> y;
uint32_t top = (-(x >> 31)) << (32 - y);
return top | bottom;
}
int t1(unsigned x, unsigned y) {
uint32_t bottom = x >> y;
uint32_t top = (-(x >> 31)) & (-1U << (32 - y));
return top | bottom;
}
int t2(unsigned x) {
uint32_t bottom = x >> 4;
uint32_t top = (-(x >> 31)) << (32 - 4);
return top | bottom;
}
int t3(unsigned x) {
uint32_t bottom = x >> 4;
uint32_t top = (-(x >> 31)) & (-1UL << (32 - 4));
return top | bottom;
}
These are all should be just arithmetic right-shift:
https://rise4fun.com/Alive/USf
Name: ashr disguised
%3 = lshr i32 %x, %1
%4 = ashr i32 %x, 31
%5 = sub i32 32, %1
%6 = shl i32 %4, %5
%r = or i32 %6, %3
=>
%r = ashr i32 %x, %1
Name: ashr disguised, with mask
%3 = lshr i32 %x, %1
%4 = ashr i32 %x, 31
%5 = sub i32 32, %1
%6 = shl i32 -1, %5
%7 = and i32 %6, %4
%r = or i32 %7, %3
=>
%r = ashr i32 %x, %1
Name: ashr disguised, constants
Pre: C2 u>= C1 && C3 == C2-C1
%2 = lshr i32 %x, C1
%3 = ashr i32 %x, C2
%4 = shl i32 %3, C3
%r = or i32 %4, %2
=>
%r = ashr i32 %x, C1
Name: ashr disguised, constants, with mask
Pre: C2 u>= C1 && countLeadingOnes(C3) == C1 && countTrailingZeros(C3) == 32-C1
%2 = lshr i32 %x, C1
%3 = ashr i32 %x, C2
%4 = and i32 %3, C3
%r = or i32 %4, %2
=>
%r = ashr i32 %x, C1
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43704] New: Broken symlink in libclang-cpp10
https://bugs.llvm.org/show_bug.cgi?id=43704 Bug ID: 43704 Summary: Broken symlink in libclang-cpp10 Product: Packaging Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: deb packages Assignee: unassignedb...@nondot.org Reporter: ignat.losku...@gmail.com CC: llvm-bugs@lists.llvm.org % adequate libclang-cpp10 libclang-cpp10: broken-symlink /usr/lib/llvm-10/lib/libclang-cpp.so.10 -> libclang-cpp-10.so.1 There also exists the `libclang-cpp.so.1 -> ../../x86_64-linux-gnu/libclang-cpp-10.so.1` symlink in the same directory, which seems to be correct. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43703] New: std::steady_clock::now() frequently overflows on Windows
https://bugs.llvm.org/show_bug.cgi?id=43703 Bug ID: 43703 Summary: std::steady_clock::now() frequently overflows on Windows Product: libc++ Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: stev...@microsoft.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com std::steady_clock::now() multiplies the result from QueryPerformanceCounter() by nano::den (10^9), which frequently overflows, producing a negative int64_t value. libc++ should perform this calculation more carefully to avoid overflow. Current implementation: return time_point(duration(counter.QuadPart * nano::den / freq.QuadPart)); Proposed fixed implementation: const auto first_part = (counter.QuadPart / freq.QuadPart) * nano::den; const auto second_part = (counter.QuadPart % freq.QuadPart) * nano::den / freq.QuadPart; return time_point(duration(first_part + second_part)); -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13486 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: Direct-leak in BitcodeReader::parseConstants
Updates: Labels: Fuzz-Blocker Comment #3 on issue 13486 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2: Direct-leak in BitcodeReader::parseConstants https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13486#c3 This crash occurs very frequently on linux platform and is likely preventing the fuzzer llvm-isel-fuzzer--x86_64-O2 from making much progress. Fixing this will allow more bugs to be found. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43702] New: platform process list -v doesn't show all processes on Windows.
https://bugs.llvm.org/show_bug.cgi?id=43702 Bug ID: 43702 Summary: platform process list -v doesn't show all processes on Windows. Product: lldb Version: 9.0 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: teempe...@gmail.com CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org platform process list -v on windows doesn't show all the process arguments, making this test useless for that platform. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 16436 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: isValidElementType(ElementType) && "Element type of a VectorType must " "be an i
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 16436 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: isValidElementType(ElementType) && "Element type of a VectorType must " "be an i https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16436#c1 ClusterFuzz testcase 5734489359122432 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=201906300300:201910150335 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 18312 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-earlycse: ASSERT: Index < Length && "Invalid index!"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-10-17 Type: Bug New issue 18312 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-earlycse: ASSERT: Index < Length && "Invalid index!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18312 Detailed Report: https://oss-fuzz.com/testcase?key=5758050387886080 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-earlycse Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: Index < Length && "Invalid index!" BitcodeReader::parseModule llvm::BitcodeModule::getModuleImpl Sanitizer: memory (MSAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&revision=201910160332 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5758050387886080 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. 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 need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43146] Compiler fails to optimize big endian load since clang 8.0
https://bugs.llvm.org/show_bug.cgi?id=43146 Sanjay Patel changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)|r373833 |r375025 Status|REOPENED|RESOLVED --- Comment #18 from Sanjay Patel --- Should be fixed again (using a more specialized implementation to limit SLP): https://reviews.llvm.org/rL375025 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42885] optimization bug with -march=haswell/skylake
https://bugs.llvm.org/show_bug.cgi?id=42885 Sanjay Patel changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #4 from Sanjay Patel --- Should be fixed again (using a more specialized implementation to limit SLP): https://reviews.llvm.org/rL375025 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42708] Vectorization of 8 byte load prevents load merging
https://bugs.llvm.org/show_bug.cgi?id=42708 Sanjay Patel changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||r375025 --- Comment #10 from Sanjay Patel --- Should be fixed again (using a more specialized implementation to limit SLP): https://reviews.llvm.org/rL375025 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43701] New: llvm do not generate __emutls_v.xx symbol for TLS variable alias
https://bugs.llvm.org/show_bug.cgi?id=43701 Bug ID: 43701 Summary: llvm do not generate __emutls_v.xx symbol for TLS variable alias Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: uncle...@sina.com CC: llvm-bugs@lists.llvm.org Created attachment 22686 --> https://bugs.llvm.org/attachment.cgi?id=22686&action=edit source and build command and a patch to fix this bug 0. Program arguments: /usr/lib/llvm-7/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -coverage-notes-file /home/xxx/path/test.gcno -resource-dir /usr/lib/llvm-7/lib/clang/7.0.1 -D INCLUDE_SOURCE -internal-isystem /usr/local/include -internal-isystem /usr/lib/llvm-7/lib/clang/7.0.1/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir /home/xxx/path -ferror-limit 19 -fmessage-length 321 -femulated-tls -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o test.o -x c test.c -faddrsig 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'test.c'. 4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@getnewname' #0 0x7f9e1fc3fc2f llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0x9cec2f) #1 0x7f9e1fc3e160 llvm::sys::RunSignalHandlers() (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0x9cd160) #2 0x7f9e1fc3ff42 (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0x9cef42) #3 0x7f9e22c98730 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12730) #4 0x7f9e2016dfe4 llvm::SelectionDAG::getGlobalAddress(llvm::GlobalValue const*, llvm::SDLoc const&, llvm::EVT, long, bool, unsigned char) (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0xefcfe4) #5 0x7f9e201d079a llvm::TargetLowering::LowerToTLSEmulatedModel(llvm::GlobalAddressSDNode const*, llvm::SelectionDAG&) const (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0xf5f79a) #6 0x7f9e21512524 llvm::X86TargetLowering::LowerGlobalTLSAddress(llvm::SDValue, llvm::SelectionDAG&) const (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0x22a1524) #7 0x7f9e2152e5e7 llvm::X86TargetLowering::LowerOperation(llvm::SDValue, llvm::SelectionDAG&) const (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0x22bd5e7) #8 0x7f9e20092bb4 (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0xe21bb4) #9 0x7f9e200921d0 llvm::SelectionDAG::Legalize() (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0xe211d0) #10 0x7f9e201a0816 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0xf2f816) #11 0x7f9e2019f62e llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0xf2e62e) #12 0x7f9e2019c966 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0xf2b966) #13 0x7f9e214e43c1 (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0x22733c1) #14 0x7f9e1fe9fdf9 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0xc2edf9) #15 0x7f9e1fd30668 llvm::FPPassManager::runOnFunction(llvm::Function&) (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0xabf668) #16 0x7f9e1fd308c3 llvm::FPPassManager::runOnModule(llvm::Module&) (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0xabf8c3) #17 0x7f9e1fd30c8b llvm::legacy::PassManagerImpl::run(llvm::Module&) (/lib/x86_64-linux-gnu/libLLVM-7.so.1+0xabfc8b) #18 0x006f21e5 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/usr/lib/llvm-7/bin/clang+0x6f21e5) #19 0x00c344a5 (/usr/lib/llvm-7/bin/clang+0xc344a5) #20 0x010b8415 clang::ParseAST(clang::Sema&, bool, bool) (/usr/lib/llvm-7/bin/clang+0x10b8415) #21 0x00ad243f clang::FrontendAction::Execute() (/usr/lib/llvm-7/bin/clang+0xad243f) #22 0x00a93738 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/lib/llvm-7/bin/clang+0xa93738) #23 0x00b608d6 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/lib/llvm-7/bin/clang+0xb608d6) #24 0x006aa014 cc1_main(llvm::ArrayRef, char const*, void*) (/usr/lib/llvm-7/bin/clang+0x6aa014) #25 0x006a84b7 main (/usr/lib/llvm-7/bin/clang+0x6a84b7) #26 0x7f9e1edb309b __libc_start_ma
[llvm-bugs] Issue 18311 in oss-fuzz: llvm:clang-fuzzer: ASSERT: cast(SubExpr)->getQualifier() && "fixed to a member ref with no nes
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-10-17 Type: Bug New issue 18311 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: cast(SubExpr)->getQualifier() && "fixed to a member ref with no nes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18311 Detailed Report: https://oss-fuzz.com/testcase?key=5758145414037504 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: cast(SubExpr)->getQualifier() && "fixed to a member ref with no nes clang::Sema::FixOverloadedFunctionReference FinishOverloadedCallExpr Sanitizer: address (ASAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&revision=201910160332 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5758145414037504 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. 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 need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43700] New: Label array with unused result results in clang crash
https://bugs.llvm.org/show_bug.cgi?id=43700
Bug ID: 43700
Summary: Label array with unused result results in clang crash
Product: clang
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: spiritual.dragon.of...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Created attachment 22685
--> https://bugs.llvm.org/attachment.cgi?id=22685&action=edit
Attached: Backtrace, preprocessed source and associated run script
Overview:
Declaring a label array with at least 3 labels while not assigning the result
to a variable, causes a segmentation fault to occur.
Attached is the resulting log of the command "clang -v
clang_empty_lbl_array.c".
Steps to reproduce:
Compile the code shown below (which should result in an empty main()) with the
command "clang clang_empty_lbl_array.c".
int main () {
(void * []) { &&L3, &&L2, &&L1 };
L1: ;
L2: ;
L3: ;
}
Actual Results:
clang crashes, resulting in no executable being generated.
Expected Results:
Generation of executable (with a warning) equivalent to:
int main () {
L1: ;
L2: ;
L3: ;
}
Build Date & Hardware:
Built 17/Oct/2019 on:
> clang --version
clang version 9.0.0 (tags/RELEASE_900/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43698] New: TSAN provides incorrect context to signal handler for async SIGPROF
https://bugs.llvm.org/show_bug.cgi?id=43698 Bug ID: 43698 Summary: TSAN provides incorrect context to signal handler for async SIGPROF Product: compiler-rt Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: tsan Assignee: unassignedb...@nondot.org Reporter: petermarsh...@chromium.org CC: llvm-bugs@lists.llvm.org Here's the code I'm talking about: https://github.com/llvm/llvm-project/blob/9917c76107f827ec2ac19cbd5a42939ddd3bd2be/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp#L2016 TSAN seems to differentiate between sync and async signals. SIGPROF is not listed as a sync signal in is_sync_signal() - this seems correct to me. But here's the problem. rtl_generic_sighandler() delays the sending of async signals (from other threads). It does this by copying the ctx struct into pending_signals. It then continues running the target program, and at certain points later it will deliver pending async signals. But the context that it delivers to the user-installed signal handler is the one that it copied at the time of the actual signal. This context is now stale, as the target program continued to run in the meantime. In V8 we have a background thread which sends SIGPROF to the main thread via pthread_kill() to trigger a sample in our sampling profiler. In the signal handler we use the context to unwind the stack and later symbolize the return addresses we take from the stack in order to get a stack trace of JavaScript code. We found through debugging that this context is wrong when we compile with TSAN, and this causes us to read garbage values off the stack which causes our stack walking to fail. By wrong I mean, we walk the stack but discover we aren't in the code that contains the PC provided by the context argument. There are tests currently in LLVM e.g. compiler-rt/test/tsan/signal_errno.cpp which sends a SIGPROF from another thread, but the handler does not rely on the contents of the context argument being correct. None of the tests check the context argument which is I think why this bug has gone unnoticed. Repro: A test/repro would basically look like compiler-rt/test/tsan/signal_thread.cpp except that in the handler, we somehow need to verify that the context argument relates to the current active stack and not a previous snapshot of the stack, taken at the time the signal was actually received. I'm not sure exactly how to test that, maybe someone has a suggestion. Expected result: The context argument should always relate to the current stack/registers when the signal handler is received, not a past snapshot. Affected platforms/versions: I think the bug affects Linux and Mac and affects all versions. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43699] New: [AMDGPU][GlobalISel] EXPENSIVE_CHECKS failures with inst-select-fabs.mir and inst-select-fneg.mir
https://bugs.llvm.org/show_bug.cgi?id=43699 Bug ID: 43699 Summary: [AMDGPU][GlobalISel] EXPENSIVE_CHECKS failures with inst-select-fabs.mir and inst-select-fneg.mir Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: llvm-bugs@lists.llvm.org, matthew.arsena...@amd.com We're seeing intermittent test failure on the GlobalISel fneg/fabs tests: C:\ps4-buildslave2\llvm-clang-x86_64-expensive-checks-win\llvm\test\CodeGen\AMDGPU\GlobalISel\inst-select-fabs.mir:222:9: error: GCN: expected string not found in input ; GCN: [[COPY:%[0-9]+]]:vreg_64 = COPY $vgpr0_vgpr1 ^ :801:2: note: scanning from here %0:vreg_64(s64) = COPY $vgpr0_vgpr1 C:\ps4-buildslave2\llvm-clang-x86_64-expensive-checks-win\llvm\test\CodeGen\AMDGPU\GlobalISel\inst-select-fneg.mir:222:9: error: GCN: expected string not found in input ; GCN: [[COPY:%[0-9]+]]:vreg_64 = COPY $vgpr0_vgpr1 ^ :861:2: note: scanning from here %0:vreg_64(s64) = COPY $vgpr0_vgpr1 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43687] opt -loop-idiom crashing with opt: ../lib/Transforms/Scalar/LoopIdiomRecognize.cpp:1986: ... Assertion ... "Unexpected exit edges."' failed.
https://bugs.llvm.org/show_bug.cgi?id=43687 Roman Lebedev changed: What|Removed |Added Fixed By Commit(s)||375100 Status|NEW |RESOLVED Assignee|unassignedb...@nondot.org |lebedev...@gmail.com Resolution|--- |FIXED --- Comment #3 from Roman Lebedev --- r375100. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40660] Another Python3 unicode encode error fix
https://bugs.llvm.org/show_bug.cgi?id=40660 Russell Gallop changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||russell_gal...@sn.scee.net --- Comment #1 from Russell Gallop --- It looks like this was fixed in r363388. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 18306 in oss-fuzz: llvm:llvm-isel-fuzzer--wasm32-O2: ASSERT: (Known.Zero & Known.One) == 0 && "Bits known to be one AND zero?"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-10-17 Type: Bug New issue 18306 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--wasm32-O2: ASSERT: (Known.Zero & Known.One) == 0 && "Bits known to be one AND zero?" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18306 Detailed Report: https://oss-fuzz.com/testcase?key=5761153988296704 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--wasm32-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: (Known.Zero & Known.One) == 0 && "Bits known to be one AND zero?" computeKnownBits computeKnownBitsFromOperator Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201805251801:201805260721 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5761153988296704 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. 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 need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42699] EmitGEPOffset() incorrectly adds NUW to multiplications
https://bugs.llvm.org/show_bug.cgi?id=42699 Nuno Lopes changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Nuno Lopes --- Fixed in https://reviews.llvm.org/rGb6534b2a26fa94e4d09d271faf538b1e4b19ab5d 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
