[llvm-bugs] Issue 5032 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: getActiveBits() <= 64 && "Too many bits for uint64_t"
Comment #2 on issue 5032 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: getActiveBits() <= 64 && "Too many bits for uint64_t" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5032#c2 ClusterFuzz has detected this issue as fixed in range 201801090613:201801100627. Detailed report: https://oss-fuzz.com/testcase?key=5327169480818688 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-instcombine Fuzz target binary: llvm-opt-fuzzer--x86_64-instcombine Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: getActiveBits() <= 64 && "Too many bits for uint64_t" llvm::InstCombiner::visitAShr llvm::InstCombiner::run Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801010614:201801020611 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801090613:201801100627 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5327169480818688 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 4718 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: C.ashr(*ShiftAmt).shl(*ShiftAmt) == C && "Compare known true or false was not fo
Comment #3 on issue 4718 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: C.ashr(*ShiftAmt).shl(*ShiftAmt) == C && "Compare known true or false was not fo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4718#c3 ClusterFuzz has detected this issue as fixed in range 201801090613:201801100627. Detailed report: https://oss-fuzz.com/testcase?key=5678891130683392 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-instcombine Fuzz target binary: llvm-opt-fuzzer--x86_64-instcombine Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: C.ashr(*ShiftAmt).shl(*ShiftAmt) == C && "Compare known true or false was not fo llvm::InstCombiner::foldICmpShlConstant llvm::InstCombiner::foldICmpInstWithConstant Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201712190608:201712210617 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801090613:201801100627 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5678891130683392 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] [Bug 35883] New: Merge r322160 into the 6.0 branch: [OMPT] Fix cast and printf of wait_id in lock test
https://bugs.llvm.org/show_bug.cgi?id=35883 Bug ID: 35883 Summary: Merge r322160 into the 6.0 branch: [OMPT] Fix cast and printf of wait_id in lock test Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: ASSIGNED Severity: release blocker Priority: P Component: Runtime Library Assignee: andrey.churba...@intel.com Reporter: hah...@hahnjo.de CC: h...@chromium.org, llvm-bugs@lists.llvm.org Blocks: 35804 Andrey, Hans, is this ok to merge? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=35804 [Bug 35804] [meta] 6.0.0 Release Blockers -- 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 5032 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: getActiveBits() <= 64 && "Too many bits for uint64_t"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 5032 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: getActiveBits() <= 64 && "Too many bits for uint64_t" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5032#c3 ClusterFuzz testcase 5327169480818688 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] Issue 4718 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: C.ashr(*ShiftAmt).shl(*ShiftAmt) == C && "Compare known true or false was not fo
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #4 on issue 4718 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: C.ashr(*ShiftAmt).shl(*ShiftAmt) == C && "Compare known true or false was not fo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4718#c4 ClusterFuzz testcase 5678891130683392 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 35884] New: LoopDeletion causes an assert `use_empty() && "Uses remain when a value is destroyed!"'
https://bugs.llvm.org/show_bug.cgi?id=35884
Bug ID: 35884
Summary: LoopDeletion causes an assert `use_empty() && "Uses
remain when a value is destroyed!"'
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: serguei.kat...@azul.com
CC: llvm-bugs@lists.llvm.org
For the following simple reproducer:
define i64 @foo() {
entry:
br label %badloop
badloop:
%indvar1 = phi i64 [ 3, %entry ], [ %indvar2, %badloop_iter ]
%check = icmp ult i64 %indvar1, 400
br i1 %check, label %badloop_iter, label %loopexit
badloop_iter:
%indvar2 = add i64 %indvar1, 1
%baddef = add i64 0, 0
br label %badloop
loopexit:
ret i64 0
deadcode:
ret i64 %baddef
}
> opt -S -loop-deletion test.ll
While deleting: i64 %baddef
Use still stuck around after Def is destroyed: ret i64 %baddef
opt: ../../lib/IR/Value.cpp:92: llvm::Value::~Value(): Assertion `use_empty()
&& "Uses remain when a value is destroyed!"' failed.
The cause of this is that %baddef is defined in BB which does not dominate exit
and as a result LCCSA does not create a Phi node for it.
As a result LoopDeletion detects that loop is invariant and tries to delete it.
Assert happens when %baddef instruction is deleted due to it has use in
unreachable block.
The IR is well-formed because %baddef dominates all instructions in unreachable
block.
--
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 5214 in oss-fuzz: llvm/clang-fuzzer: ASSERT: !Old || Old->getCachedLinkage() == D->getCachedLinkage()
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, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-01-10 Type: Bug New issue 5214 by ClusterFuzz-External: llvm/clang-fuzzer: ASSERT: !Old || Old->getCachedLinkage() == D->getCachedLinkage() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5214 Detailed report: https://oss-fuzz.com/testcase?key=4618585776324608 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !Old || Old->getCachedLinkage() == D->getCachedLinkage() clang::LinkageComputer::getLVForDecl clang::NamedDecl::getLinkageInternal Sanitizer: address (ASAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4618585776324608 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 35662] Possible bug in lowering of conditional branch
https://bugs.llvm.org/show_bug.cgi?id=35662 Jonas Paulsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonas Paulsson --- Fixed with r322161. -- 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 34883] [LoopDataPrefetch] - places prefetches between a load and its single user, which disrupts instruction selection.
https://bugs.llvm.org/show_bug.cgi?id=34883 Jonas Paulsson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Jonas Paulsson --- r322163 -- 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 35882] anonymous union cause clang-tidy report false positive message
https://bugs.llvm.org/show_bug.cgi?id=35882 Alexander Kornienko changed: What|Removed |Added Product|clang-tools-extra |clang Assignee|unassignedclangbugs@nondot. |dcough...@apple.com |org | CC||llvm-bugs@lists.llvm.org Component|clang-tidy |Static Analyzer -- 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 35886] New: Inconsistent narrowing errors
https://bugs.llvm.org/show_bug.cgi?id=35886
Bug ID: 35886
Summary: Inconsistent narrowing errors
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: free...@shaneware.biz
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
I'm using freebsd - testing projects/clang600-import for future 12-release but
I can get the same with earlier clang versions by setting
-Werror=c++11-narrowing
It appears that clang 6.0 imported into freebsd base is forcing c++11-narrowing
warnings to be treated as an error were earlier releases don't. I'm ok with
that but find the reports inconsistent.
--
There is an inconsistency were assigning a long to an int gives an error, but
passing a long to a function that takes an int does not. Also returning a long
from an int func() does not give an error.
So assigning to a smaller size triggers a narrowing error, while passing a
larger variable to/from a function does not.
--
This code appears to be treating a literal 1.0 as a double, so it promotes the
float to a double and then errors when the double result is being shortened to
be stored in a float. Yet the line before treats the 0.5 literal as a float and
has no error. The difference would be that the error comes from an array
initialisation. Changing 1.0 to 1.0f can remove this error.
The following code snippet is taken from the 2.1 branch of the godot project -
https://github.com/godotengine/godot/tree/2.1/servers/spatial_sound/spatial_sound_server_sw.cpp
//lines 691-692
float p = sd.panning.x * 0.5 + 0.5; // OK
float panf[2] = { (1.0 - p), p }; // narrowing error
The same error shows in 7 other similar lines of float array initialisations.
--
example code demonstrating report --
clang++ -std=c++11 -Werror=c++11-narrowing test.cpp
int testcall(int idx)
{
long x[] = {1,2,3,4,5,6};
// returning a long as an int doesn't give an error
return x[idx];
}
struct Property {
int format, nitems;
};
int main(int argc, char ** argv)
{
int actual_format = 5;
long nitems = 25;
// this gives a c++11-narowing error for long to int
Property p = { actual_format, nitems };
// passing a long to an int parameter doesn't give an error
testcall(nitems);
float a = 1.8;
float b = 1.0 + a * 0.5; // OK
float c[2] = { 1.0 - b, b }; // error
return 0;
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35887] New: Repository appears to no longer be signed
https://bugs.llvm.org/show_bug.cgi?id=35887 Bug ID: 35887 Summary: Repository appears to no longer be signed Product: Packaging Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: deb packages Assignee: unassignedb...@nondot.org Reporter: kjer...@gmail.com CC: llvm-bugs@lists.llvm.org When running apt update on Ubuntu 16.04 I get the following: > Get:13 http://apt.llvm.org/xenial llvm-toolchain-xenial-4.0 Release [3,354 B] > Err:14 http://apt.llvm.org/xenial llvm-toolchain-xenial-4.0 Release.gpg > > 503 first byte timeout > Reading package lists... Done > E: The repository 'http://apt.llvm.org/xenial llvm-toolchain-xenial-4.0 > Release' is no longer signed. > N: Updating from such a repository can't be done securely, and is therefore > disabled by default. > N: See apt-secure(8) manpage for repository creation and user configuration > details. -- 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 5223 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: getActiveBits() <= 64 && "Too many bits for uint64_t"
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, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-01-10 Type: Bug New issue 5223 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: getActiveBits() <= 64 && "Too many bits for uint64_t" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5223 Detailed report: https://oss-fuzz.com/testcase?key=6166292676476928 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-instcombine Fuzz target binary: llvm-opt-fuzzer--x86_64-instcombine Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: getActiveBits() <= 64 && "Too many bits for uint64_t" llvm::InstCombiner::visitAllocaInst llvm::InstCombiner::run Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201712190608:201712210617 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6166292676476928 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 27733] [ms] clang-cl fails to compile WTL header "atlctrlx.h" and several related samples
https://bugs.llvm.org/show_bug.cgi?id=27733 mib.bugzi...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from mib.bugzi...@gmail.com --- The source bug will be resolved in the open source project. -- 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 35888] New: Flacky crash when building for ARM Chromium 62+
https://bugs.llvm.org/show_bug.cgi?id=35888 Bug ID: 35888 Summary: Flacky crash when building for ARM Chromium 62+ Product: clang Version: 5.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: lti...@igalia.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org When compiling a version of Chromium 62/63 for ARM, the build seems to be crashing in some cases at this point: [21324/30694] ../../../../../../bin/clang++-4.0 -MMD -MF obj/content/browser/browser/navigation_url_loader_network_service.o.d -DENABLE_SCREEN_CAPTURE=1 -DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DNO_TCMALLOC -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DOFFICIAL_BUILD -DCHROMIUM_BUILD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DCR_CLANG_REVISION=\"313786-1\" -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DCONTENT_IMPLEMENTATION -DV8_USE_EXTERNAL_STARTUP_DATA -DATK_LIB_DIR=\"/usr/lib/arm-linux-gnueabihf\" -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_32 -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_26 -DGL_GLEXT_PROTOTYPES -DUSE_GLX -DUSE_EGL -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DHAVE_PTHREAD -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DU_STATIC_IMPLEMENTATION -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DUCHAR_TYPE=uint16_t -DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS -DSK_HAS_PNG_LIBRARY -DSK_HAS_WEBP_LIBRARY -DSK_HAS_JPEG_LIBRARY -DSK_SUPPORT_GPU=1 -DLEVELDB_PLATFORM_CHROMIUM=1 -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0 -DFEATURE_ENABLE_VOICEMAIL -DGTEST_RELATIVE_PATH -DWEBRTC_CHROMIUM_BUILD -DWEBRTC_POSIX -DWEBRTC_LINUX -DWTF_USE_WEBAUDIO_FFMPEG=1 -DWTF_USE_DEFAULT_RENDER_THEME=1 -DNO_MAIN_THREAD_WRAPPING -DFLAC__NO_DLL -I../.. -Igen -I/usr/include/atk-1.0 -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/libpng16 -I../../third_party/libwebp/src -I../../third_party/khronos -I../../gpu -I../../third_party/protobuf/src -I../../third_party/ced/src -I../../third_party/icu/source/common -I../../third_party/icu/source/i18n -I../../skia/config -I../../skia/ext -I../../third_party/skia/include/c -I../../third_party/skia/include/config -I../../third_party/skia/include/core -I../../third_party/skia/include/effects -I../../third_party/skia/include/encode -I../../third_party/skia/include/gpu -I../../third_party/skia/include/images -I../../third_party/skia/include/lazy -I../../third_party/skia/include/pathops -I../../third_party/skia/include/pdf -I../../third_party/skia/include/pipe -I../../third_party/skia/include/ports -I../../third_party/skia/include/utils -I../../third_party/skia/third_party/vulkan -I../../third_party/skia/src/gpu -I../../third_party/skia/src/sksl -I../../third_party/leveldatabase -I../../third_party/leveldatabase/src -I../../third_party/leveldatabase/src/include -I../../third_party/webrtc_overrides -I../../testing/gtest/include -I../../third_party/webrtc -I../../third_party/webrtc_overrides -I../../third_party/webrtc -I../../third_party/protobuf/src -Igen/protoc_out -Igen/components/metrics/proto -I../../third_party/boringssl/src/include -I/usr/include/nss -I/usr/include/nspr -I../../third_party/libwebm/source -Igen -I../../third_party/WebKit -Igen/third_party/WebKit -I../../v8/include -Igen/v8/include -I../../third_party/mesa/src/include -I../../third_party/WebKit/Source -I../../third_party/WebKit -Igen/blink -Igen/third_party/WebKit -I../../third_party/angle/src/common/third_party/base -Igen/angle -I../../third_party/brotli/include -I../../third_party/libyuv/include -I../../third_party/re2/src -I../../third_party/zlib -I/usr/include/dbus-1.0 -I/usr/lib/arm-linux-gnueabihf/dbus-1.0/include -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -fPIC -pipe -pthread -fcolor-diagnostics -no-canonical-prefixes --target=arm-linux-gnueabihf -march=armv7-a -mfloat-abi=hard -mtune=generic-armv7-a -mfpu=neon -mthumb -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -Wno-undefined-var-template -Wno-nonportable-include-path -Wno-address-of-packed-member -Wno-user-defined-warnings -O2 -fno-ident -fdata-sections -ffunction-sections -fomit-frame-pointer -gdwarf-3 -g1 -fvisi
[llvm-bugs] [Bug 35889] New: SmallVector: use-after-poison MSAN error in destructor
https://bugs.llvm.org/show_bug.cgi?id=35889 Bug ID: 35889 Summary: SmallVector: use-after-poison MSAN error in destructor Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Core LLVM classes Assignee: unassignedb...@nondot.org Reporter: st...@obrien.cc CC: llvm-bugs@lists.llvm.org The topmost class, `SmallVector`, has internal storage for some elements; `N - 1` elements' bytes worth of space. Meanwhile a base class `SmallVectorTemplateCommon` has room for one element as well, totaling `N` elements' worth of space. The space for the N elements is contiguous and straddles `SmallVectorTemplateCommon` and `SmallVector`. A class "between" those two owning the storage, `SmallVectorImpl`, in its destructor, calls the destructor for elements contained in the vector, if any. It uses `destroy_range(begin, end)` to destroy all items in sequence, starting from the end. By the time the destructor for `SmallVectorImpl` is running, though, the memory for elements `[1, N)` is already poisoned, due to `SmallVector`'s destructor having done its thing already. So if the element type `T` has a nontrivial destructor that accesses any members of the `T` instance being destroyed, we'll run into a use-after-poison bug. This patch moves the destruction loop into `SmallVector`'s destructor, so any memory being accessed while dtors are running is not yet poisoned. [Phabricator diff and repro steps coming] -- 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 35890] New: SCEV expander assertion in LSR
https://bugs.llvm.org/show_bug.cgi?id=35890 Bug ID: 35890 Summary: SCEV expander assertion in LSR Product: tools Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: opt Assignee: unassignedb...@nondot.org Reporter: a...@azul.com CC: llvm-bugs@lists.llvm.org Created attachment 19648 --> https://bugs.llvm.org/attachment.cgi?id=19648&action=edit input IR to pass with -loop-reduce With the following bugpoint code attached, llvm trunk (without rL321550) crashes when trying to retrieve a PostIncExpr because the PostIncExpr is not an AddRecurrence. rL321550 limits the depth in recursive call to getAddRec because we were missing passing the depth. I think the change only hides the actual problem in SCEV because limiting the recursion depth is only a compile time restriction and not a functional requirement. Is this correct? Command to use: opt -loop-reduce reduced.ll Trunk with the following diff [1] still crashes with assertion failure: Assertion failed: (isa(Val) && "cast() argument of incompatible type!") when trying to cast the result of getAddRec into SCEVAddRecExpr: #4 0x75147dcc in llvm::cast () Diff to apply is basically the revert of rL321550: diff --git a/lib/Analysis/ScalarEvolution.cpp b/lib/Analysis/ScalarEvolution.cpp index 10b5c74e378..32fd05d2ea4 100644 --- a/lib/Analysis/ScalarEvolution.cpp +++ b/lib/Analysis/ScalarEvolution.cpp @@ -2358,7 +2358,7 @@ const SCEV *ScalarEvolution::getAddExpr(SmallVectorImpl &Ops, FoundMatch = true; } if (FoundMatch) -return getAddExpr(Ops, Flags, Depth + 1); +return getAddExpr(Ops, Flags); // Check for truncates. If all the operands are truncated from the same // type, see if factoring out the truncate would permit the result to be -- 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 35891] New: Merge r322200 into the 6.0 branch
https://bugs.llvm.org/show_bug.cgi?id=35891 Bug ID: 35891 Summary: Merge r322200 into the 6.0 branch Product: libraries Version: 4.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: ma...@braunis.de CC: llvm-bugs@lists.llvm.org I am proposing r322200 to be merged into llvm 6.0 (see also https://reviews.llvm.org/D40876). It fixes a compiler crash and should only affect the behavior in rare cases (calls with dozens of parameters). -- 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 35889] SmallVector: use-after-poison MSAN error in destructor
https://bugs.llvm.org/show_bug.cgi?id=35889 Evgenii Stepanov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||eugeni.stepa...@gmail.com, ||masc...@google.com --- Comment #1 from Evgenii Stepanov --- Same as PR34595. I'd love to see the patch! *** This bug has been marked as a duplicate of bug 34595 *** -- 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 35892] New: Global variable always appears null
https://bugs.llvm.org/show_bug.cgi?id=35892 Bug ID: 35892 Summary: Global variable always appears null Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: ztur...@google.com CC: amcca...@google.com, llvm-bugs@lists.llvm.org, l...@inglorion.net, r...@google.com Generate CMake like this: cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=D:/src/llvmbuild/cl/Release/x64/bin/clang-cl.exe -DCMAKE_CXX_COMPILER=D:/src/llvmbuild/cl/Release/x64/bin/clang-cl.exe ..\..\..\..\llvm-mono\llvm This self-hosts using clang + msvc linker. Now debug lld in Visual Studio, putting a breakpoint in Writer::run(). On the first line, try to print the value of `Config`. It says the value is null. However, it's obvious from inspecting the code that the value cannot possibly be null or else the program would crash. So we have some bad debug info here. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35777] Invalid InsertValueInst operands!
https://bugs.llvm.org/show_bug.cgi?id=35777 Simon Pilgrim changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Simon Pilgrim --- Reopening until its merged into the 6.00 release branch -- 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 35777, which changed state. Bug 35777 Summary: Invalid InsertValueInst operands! https://bugs.llvm.org/show_bug.cgi?id=35777 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 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 35865, which changed state. Bug 35865 Summary: [SLP] Regression (r310260): Not a vector MVT! UNREACHABLE executed https://bugs.llvm.org/show_bug.cgi?id=35865 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35865] [SLP] Regression (r310260): Not a vector MVT! UNREACHABLE executed
https://bugs.llvm.org/show_bug.cgi?id=35865 Simon Pilgrim changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED Fixed By Commit(s)||322106 --- Comment #2 from Simon Pilgrim --- Reopening until its merged into the 6.00 release branch -- 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 35628, which changed state. Bug 35628 Summary: [SLP] "Replacing out-of-tree value with undef" in SLPVectorizer.cpp https://bugs.llvm.org/show_bug.cgi?id=35628 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35628] [SLP] "Replacing out-of-tree value with undef" in SLPVectorizer.cpp
https://bugs.llvm.org/show_bug.cgi?id=35628 Simon Pilgrim changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED Fixed By Commit(s)||321993 --- Comment #4 from Simon Pilgrim --- Reopening until its merged into the 6.00 release branch -- 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 5227 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: Index + MRI->getType(Res).getSizeInBits() <
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, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-01-10 Type: Bug New issue 5227 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: Index + MRI->getType(Res).getSizeInBits() <= MRI->getType(Src).getSizeInBits() & https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5227 Detailed report: https://oss-fuzz.com/testcase?key=6228718214184960 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: Index + MRI->getType(Res).getSizeInBits() <= MRI->getType(Src).getSizeInBits() & llvm::MachineIRBuilder::buildExtract llvm::LegalizerHelper::narrowScalar Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801020611:201801030610 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6228718214184960 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 35893] New: Merge r322223 into 6.0 branch
https://bugs.llvm.org/show_bug.cgi?id=35893
Bug ID: 35893
Summary: Merge r33 into 6.0 branch
Product: libraries
Version: 4.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: ma...@braunis.de
CC: llvm-bugs@lists.llvm.org
It turned out my refactoring in r321035 ("AArch64/X86: Factor out common bzero
logic; NFC") wasn't a NFC after all. Please cherry pick my fix in r33 into
the 6.0 branch.
--
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 35886] Inconsistent narrowing errors
https://bugs.llvm.org/show_bug.cgi?id=35886 Eli Friedman changed: What|Removed |Added Status|NEW |RESOLVED CC||efrie...@codeaurora.org Resolution|--- |INVALID --- Comment #1 from Eli Friedman --- > It appears that clang 6.0 imported into freebsd base is forcing > c++11-narrowing warnings to be treated as an error were earlier releases > don't. >From the release notes: Clang’s default C++ dialect is now gnu++14 instead of gnu++98. This means Clang will by default accept code using features from C++14 and conforming GNU extensions. Projects incompatible with C++14 can add -std=gnu++98 to their build settings to restore the previous behaviour. -- 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 5228 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-instcombine: Timeout in llvm_llvm-opt-fuzzer--x86_64-instcombine
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, akils...@apple.com Labels: ClusterFuzz Unreproducible Engine-libfuzzer Proj-llvm Reported-2018-01-10 Type: Bug New issue 5228 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-instcombine: Timeout in llvm_llvm-opt-fuzzer--x86_64-instcombine https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5228 Detailed report: https://oss-fuzz.com/testcase?key=5976423111065600 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-instcombine Fuzz target binary: llvm-opt-fuzzer--x86_64-instcombine Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Timeout (exceeds 25 secs) Crash Address: Crash State: llvm_llvm-opt-fuzzer--x86_64-instcombine Sanitizer: address (ASAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5976423111065600 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. Note: This crash might not be reproducible with the provided testcase. That said, for the past 14 days we've been seeing this crash frequently. If you are unable to reproduce this, please try a speculative fix based on the crash stacktrace in the report. The fix can be verified by looking at the crash statistics in the report, a day after the fix is deployed. We will auto-close the bug if the crash is not seen for 14 days. 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 35895] New: --plugin-opt=Os is not recongized
https://bugs.llvm.org/show_bug.cgi?id=35895 Bug ID: 35895 Summary: --plugin-opt=Os is not recongized Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org Clang passes -plugin-opt=Os to lld when LTO is enabled and -Os is passed. lld does not recognize the flag. It shows the following error message: ld.lld: error: --plugin-opt: number expected, but got 's' -- 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 5231 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: (!N.getNode() || N.getValueType() == MVT::Other) && "DAG root value is not a cha
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, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-01-11 Type: Bug New issue 5231 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: (!N.getNode() || N.getValueType() == MVT::Other) && "DAG root value is not a cha https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5231 Detailed report: https://oss-fuzz.com/testcase?key=5148675740270592 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--aarch64-O2 Fuzz target binary: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: (!N.getNode() || N.getValueType() == MVT::Other) && "DAG root value is not a cha llvm::SelectionDAG::ReplaceAllUsesWith llvm::SelectionDAG::ReplaceAllUsesWith Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801090613:201801100627 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5148675740270592 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] Issue 5232 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::Visit
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, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-01-11 Type: Bug New issue 5232 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::StmtVisitorBasebool>::Visit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5232 Detailed report: https://oss-fuzz.com/testcase?key=5659776680722432 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffcc2213a40 Crash State: clang::StmtVisitorBasebool>::Visit EvaluateLValue Evaluate Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801090613:201801100627 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5659776680722432 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 34595] SmallVector use-after-dtor
https://bugs.llvm.org/show_bug.cgi?id=34595 Steve O'Brien changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35896] New: MSAN read-past-string-end in CXString
https://bugs.llvm.org/show_bug.cgi?id=35896 Bug ID: 35896 Summary: MSAN read-past-string-end in CXString Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: libclang Assignee: unassignedclangb...@nondot.org Reporter: st...@obrien.cc CC: kli...@google.com, llvm-bugs@lists.llvm.org Class `CXString` has a method `createRef(llvm::StringRef)` that tries to reference the bytes of an existing string, without copying, if possible. (We can assume the pre-existing string bytes' memory remains unchanged, allocated, and otherwise "good".) A `StringRef` represents a run of sequential chars in memory; whereas a `CXString` always points to a C-like string, i.e., there must be an array somewhere of bytes, terminated by a NUL character. `StringRef` doesn't have that NUL terminator requirement; so `createRef`, which wants to recycle existing memory might be dealing with a NUL-terminated string (which it can reuse) or otherwise has to copy the non-NUL terminated bytes into a new array, with one extra byte for that terminator. The trouble is this: `CXString` checks the byte at `str[stringLength]`, which is technically out-of-bounds for the string. If that byte is 0 then it's a NUL-terminated C string and it can be reused (otherwise it has to be copied). Since that access is one past the bounds of the string, this raises an MSAN error. One easy fix is to always copy the string data and never attempt to reuse bytes from a `StringRef`. I fear that increased byte-copies will waste both memory and CPU. (As correct as this approach is, it's inefficient.) Another is to make `CXString`s look more like `StringRef`s, and include a length / end-of-string pointer, to avoid the NUL requirement. But as this library is used in primarily another language (via `cindex` python bindings) I'm not sure whether this is feasible or not. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35886] Inconsistent narrowing errors
https://bugs.llvm.org/show_bug.cgi?id=35886
Shane changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED|REOPENED
--- Comment #2 from Shane ---
While the compiler defaults used in that particular build are the reason for
seeing the results I reported as errors and not warnings, it doesn't change the
inconsistent results that I have reported. You can use clang 3.8 with
-std=c++11 and get the same result, you can also use -Wno-error=c++11-narrowing
and turn the errors into warnings, but that doesn't change the inconsistencies
- some narrowing is reported and some is ignored, or in some cases the types
used in a calculation are larger than needed which causes narrowing when the
final type is the same.
Using a literal in a float array initialisation it is treated as a double value
while assigning the same literal to a single float variable it is treated as a
float.
float d = 1.8;
float e = 1.0 - d; // here 1.0 is a float - OK
float f[2] = { 1.0 - d, e }; // here 1.0 is a double so gets narrowed to a
float
test.cpp:44:20: error: non-constant-expression cannot be narrowed from type
'double' to 'float' in initializer list
[-Wc++11-narrowing]
float f[2] = { 1.0 - d, e }; // here 1.0 is a double so gets narrowed to a
float
^~~
test.cpp:44:20: note: insert an explicit cast to silence this issue
float f[2] = { 1.0 - d, e }; // here 1.0 is a double so gets narrowed to a
float
^~~
static_cast( )
So the first array item appears to be calculated by interpreting the literal as
a double so the float used in the calculation would also be promoted to a
double, then the result gets narrowed to a float, whether that is treated as an
error or warning depends on the settings but it is still inconsistent compared
to the previous line and sounds like some excessive conversion steps are being
taken, so manually casting this value is wanted for the optimisation rather
than turning it into a warning and ignoring it.
Also the example of passing a long to an int function parameter or returning a
long as an int function value is ignored when (I think) it should give the same
narrowing warning or error as assigning a variable to a smaller one.
--
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 35886] Inconsistent narrowing errors
https://bugs.llvm.org/show_bug.cgi?id=35886 Richard Smith changed: What|Removed |Added Status|REOPENED|RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |INVALID --- Comment #3 from Richard Smith --- (In reply to Shane from comment #2) > While the compiler defaults used in that particular build are the reason for > seeing the results I reported as errors and not warnings, it doesn't change > the inconsistent results that I have reported. Whether a conversion is or is not narrowing, and whether narrowing is permitted or ill-formed, is specified by the C++ standard. You're not alone in finding it both to be inconsistent and to reject completely reasonable code; that's why Clang provides a flag to turn off the error. For a description of the rules, see the standard text at http://eel.is/c++draft/dcl.init.list#7 or the explanation at http://en.cppreference.com/w/cpp/language/list_initialization -- 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 25806] Can't set breakpoint in static initializer
https://bugs.llvm.org/show_bug.cgi?id=25806 Eugene Zemtsov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Eugene Zemtsov --- Fixed by r322251. -- 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 35898] New: __builtin_cpu_supports does not exist on PowerPC
https://bugs.llvm.org/show_bug.cgi?id=35898
Bug ID: 35898
Summary: __builtin_cpu_supports does not exist on PowerPC
Product: compiler-rt
Version: 6.0
Hardware: Other
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: compiler-rt
Assignee: unassignedb...@nondot.org
Reporter: danie...@au1.ibm.com
CC: llvm-bugs@lists.llvm.org
Like https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Built-in-Functions.html
Was attempting:
__builtin_cpu_supports("arch_2_07")
ARM Feature request: bug 34284
--
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 5236 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::Parser::ConsumeAndStoreUntil
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, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-01-11 Type: Bug New issue 5236 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::Parser::ConsumeAndStoreUntil https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5236 Detailed report: https://oss-fuzz.com/testcase?key=6731277102219264 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fffb3368fb8 Crash State: clang::Parser::ConsumeAndStoreUntil Sanitizer: address (ASAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6731277102219264 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 35899] New: -globals-aa affected by dbg intrinsic leading to different code after instcombine
https://bugs.llvm.org/show_bug.cgi?id=35899
Bug ID: 35899
Summary: -globals-aa affected by dbg intrinsic leading to
different code after instcombine
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: mikael.hol...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19650
--> https://bugs.llvm.org/attachment.cgi?id=19650&action=edit
reproducer
opt -S -o - foo.ll -globals-aa -instcombine
and
opt -S -o - foo.ll -strip-debug -globals-aa -instcombine
yields different results on the attached foo.ll.
We get
define void @foo() {
store i8 42, i8* @g, align 1
call void @bar(i8 1)
%_tmp = load i8, i8* @g, align 1
call void @gaz(i8 %_tmp)
ret void
}
and
define void @foo() {
store i8 42, i8* @g, align 1
call void @bar(i8 1)
call void @gaz(i8 42)
ret void
}
It seems like the
call void @llvm.dbg.value(metadata i64 0, metadata !6, metadata
!DIExpression()), !dbg !13
in
define void @bar(i8 %p) {
call void @llvm.dbg.value(metadata i64 0, metadata !6, metadata
!DIExpression()), !dbg !13
ret void
}
disturbs -globals-aa then leading to instcombine not doing the optimization.
I don't know -globals-aa at all, but I examined what happened in
GlobalsModRef.cpp a little bit and I found that if I do
- if (isAllocationFn(&I, &TLI) || isFreeCall(&I, &TLI)) {
+ if (isa(I))
+continue;
+ else if (isAllocationFn(&I, &TLI) || isFreeCall(&I, &TLI)) {
in GlobalsAAResult::AnalyzeCallGraph around line 578 then I don't get the
difference anymore. I've no idea if that's a sane fix or not though.
--
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
