[llvm-bugs] Issue 6875 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: Null-dereference READ in llvm::Type::getPrimitiveSizeInBits
Comment #5 on issue 6875 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: Null-dereference READ in llvm::Type::getPrimitiveSizeInBits https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6875#c5 ClusterFuzz has detected this issue as fixed in range 201809210124:201809220126. Detailed report: https://oss-fuzz.com/testcase?key=485060700592 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-loop_vectorize Fuzz target binary: llvm-opt-fuzzer--x86_64-loop_vectorize Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x0008 Crash State: llvm::Type::getPrimitiveSizeInBits llvm::InnerLoopVectorizer::getOrCreateTripCount llvm::InnerLoopVectorizer::createVectorizedLoopSkeleton Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802190622:201802200626 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201809210124:201809220126 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=485060700592 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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] Issue 6875 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: Null-dereference READ in llvm::Type::getPrimitiveSizeInBits
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #6 on issue 6875 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: Null-dereference READ in llvm::Type::getPrimitiveSizeInBits https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6875#c6 ClusterFuzz testcase 485060700592 is verified as fixed, so closing issue as verified. 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39047] New: Incorrect "use 'template' keyword to treat 'xxx' as a dependent template name" inside of virtual member functions of template classes
https://bugs.llvm.org/show_bug.cgi?id=39047
Bug ID: 39047
Summary: Incorrect "use 'template' keyword to treat 'xxx' as a
dependent template name" inside of virtual member
functions of template classes
Product: clang
Version: 7.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: duncan.h...@utexas.edu
CC: llvm-bugs@lists.llvm.org
E.g. the following code fails to compile:
template
struct special_ptr
{
T* ptr;
template
special_ptr as()
{
special_ptr result;
result.ptr = reinterpret_cast(this->ptr);
return result;
}
};
template
struct thing
{
special_ptr intPtr;
virtual void do_something()
{
auto charPtr = this->intPtr.as();
}
};
struct empty {};
int main()
{
thing t;
}
You can also view it at https://godbolt.org/z/ywb5CS. Note that GCC does not
have a problem with it. If you change 'thing' to no longer be a class template
_or_ if you make 'do_something' no longer virtual, it compiles fine.
--
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 38814] [X86][SSE] BLENDV Simplification to AND/ANDN
https://bugs.llvm.org/show_bug.cgi?id=38814 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||342324 342806 --- Comment #3 from Sanjay Patel --- Trying a more comprehensive IR fix with: https://reviews.llvm.org/D52059 ( https://reviews.llvm.org/rL342324 ) and https://reviews.llvm.org/rL342806 This has the potential of regressing code if the boolean compare vector source gets lost (we can't re-form the blendv), so I'm watching for complaints, but marking this as fixed for 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 39003] faulty segfault with llvm::TargetMachine
https://bugs.llvm.org/show_bug.cgi?id=39003 Nicolas Lesser changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED CC||blitzrak...@gmail.com -- 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 39048] New: NRVO (elide-constructors) code generation is running in the C compiler
https://bugs.llvm.org/show_bug.cgi?id=39048
Bug ID: 39048
Summary: NRVO (elide-constructors) code generation is running
in the C compiler
Product: clang
Version: 7.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: nat-llvmb...@mulle-kybernetik.com
CC: llvm-bugs@lists.llvm.org
I had to fix a really peculiar bug when migrating mulle-clang from clang 6 to
clang 7. Maybe this affects others maybe not.
mulle-clang is an Objective-C compiler, based on C and its own runtime. It
can't do C++.
1)
In CompilerInvocation:
https://github.com/llvm-mirror/clang/blob/master/lib/Frontend/CompilerInvocation.cpp#L2457
Opts.ElideConstructors = !Args.hasArg(OPT_fno_elide_constructors);
is turned on by default. Also the driver says:
https://github.com/llvm-mirror/clang/blob/master/lib/Driver/ToolChains/Clang.cpp#L4281
// -felide-constructors is the default.
It's my opinion, that if the language is set to C, C++ only features should
not even be queried in the CompilerInvocation and be set to off. Then you would
never have to think about a possible need to query two different
LanguageOptions.
2)
During CodeGenFunction::EmitAutoVarAlloca
https://github.com/llvm-mirror/clang/blob/master/lib/CodeGen/CGDecl.cpp#L1143
a different path is taken, if the local variable is deemed to be NRVO
compatible:
```
if (Ty->isConstantSizeType()) {
bool NRVO = getLangOpts().ElideConstructors &&
D.isNRVOVariable();
```
The following NRVO code, which I didn't scrutinize, then triggers my type
assert.
3)
My variable declaration got set as isNRVOVariable during
Scope::mergeNRVOIntoParent(). This is run unconditionally during
Sema::ActOnPopScope.
I think it would be a fix and a general improvement for C anyway, to do this
only conditionally:
https://github.com/llvm-mirror/clang/blob/master/lib/Sema/SemaDecl.cpp#L1802
```
if( getLangOpts().CPlusPlus)
S->mergeNRVOIntoParent();
```
--
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 39049] New: Avoid relocations in position independent code by storing offset of program counter
https://bugs.llvm.org/show_bug.cgi?id=39049 Bug ID: 39049 Summary: Avoid relocations in position independent code by storing offset of program counter Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: sland...@gmail.com CC: llvm-bugs@lists.llvm.org The offset at which position independent code was loading is always stored in the program counter, and a simple addition/subtraction with a constant could be used instead of a relocation table that slows down program load. This will require an additional instruction at the call site, so a collaboration between llvm and lld. -- 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 39050] New: is_trivially_copyable_v misbehaves
https://bugs.llvm.org/show_bug.cgi?id=39050 Bug ID: 39050 Summary: is_trivially_copyable_v misbehaves Product: libc++ Version: 7.0 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: philippe.groa...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Tested on various c++17 compatible versions on godbolt. Assuming cppreference is correct (https://en.cppreference.com/w/cpp/named_req/TriviallyCopyable) and my interpretation of their text is also correct. std::is_trivially_copyable_v doesn't follow the standard's definition. Example 1, Trivial non-deleted destructor : The deleted destructor should fail the check : https://godbolt.org/z/5BOO68 Example 2, at least one copy constructor, move constructor, copy assignment operator, or move assignment operator is non-deleted : There are no copy/move ctors or assignement operators, should fail the check : https://godbolt.org/z/APcHua I tested on gcc with the same results. I'm assuming I've missed something. Does libc++ use is_trivially_copyable_v internally for vector resize? -- 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 39051] New: [7.0 Regression] libc++abi incorrectly aligns exceptions in 32 bit builds
https://bugs.llvm.org/show_bug.cgi?id=39051 Bug ID: 39051 Summary: [7.0 Regression] libc++abi incorrectly aligns exceptions in 32 bit builds Product: libc++abi Version: 7.0 Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: e...@efcs.ca CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Libc++ commit r339431 moved the _LIBCPP_HAS_NO_ALIGNED_ALLOCATION logic from to <__config>. As a result, it was defined when building libc++abi's fallback_malloc.cpp, which made libc++abi think posix_memalign was unavailable. This meant that libc++abi was silently falling back to using malloc. In 32 bit builds, malloc does not return correctly aligned memory for the exception header. This is a regression in the 7.0 release. The issues was fixed in libc++abi commit r342815. This change should be merged into the 7.1 release. @Marshall, Louis, can you sign off on this? -- 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 39052] New: [Modules TS] MSVC std library produces ambiguous type_info reference
https://bugs.llvm.org/show_bug.cgi?id=39052 Bug ID: 39052 Summary: [Modules TS] MSVC std library produces ambiguous type_info reference Product: clang Version: 7.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Modules Assignee: unassignedclangb...@nondot.org Reporter: mwaspl...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org When compiling an project on windows using the MSVC standard library I get an ambiguous reference to type_info: I have attached an archive of the most simple repro of the issue. It also includes the ii file from save-temps. Error Message: In file included from main.cpp:1: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\iostream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\istream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\ostream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\ios:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\xlocnum:10: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\streambuf:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\xiosbase:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\xlocale:8: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\stdexcept:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\exception:27: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\vcruntime_exception.h:10: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\eh.h:52:14: error: reference to 'type_info' is ambiguous type_info const& _Type, ^ note: candidate found by name lookup is 'type_info' note: candidate found by name lookup is 'type_info' C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\eh.h:52:14: error: reference to 'type_info' is ambiguous note: candidate found by name lookup is 'type_info' note: candidate found by name lookup is 'type_info' -- 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 10631 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: (!RS || !RS->isScavengingFrameIndex(FrameIndex)) && "Emergency spill slot is out
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@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 Proj-llvm Reported-2018-09-23 Type: Bug New issue 10631 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: (!RS | | !RS->isScavengingFrameIndex(FrameIndex)) && "Emergency spill slot is out https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10631 Detailed report: https://oss-fuzz.com/testcase?key=5768734862475264 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: (!RS || !RS->isScavengingFrameIndex(FrameIndex)) && "Emergency spill slot is out llvm::AArch64RegisterInfo::eliminateFrameIndex llvm::RegScavenger::spill Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710121744:201710130454 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5768734862475264 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 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. -- 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
