[llvm-bugs] Issue 19880 in oss-fuzz: llvm:clang-fuzzer: Segv on unknown address in EvaluateObjectArgument
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.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 Security_Severity-High Reported-2020-01-07 Type: Bug-Security New issue 19880 by ClusterFuzz-External: llvm:clang-fuzzer: Segv on unknown address in EvaluateObjectArgument https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19880 Detailed Report: https://oss-fuzz.com/testcase?key=5664409284509696 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Segv on unknown address Crash Address: Crash State: EvaluateObjectArgument ExprEvaluatorBase::handleCallExpr clang::StmtVisitorBasebool>::Visit Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm=201911200438:201911230451 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5664409284509696 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] Issue 19870 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Token::getIdentifierInfo
Comment #1 on issue 19870 by da...@1stclassauto.glass: llvm:clang-fuzzer: Stack-overflow in clang::Token::getIdentifierInfo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19870#c1 (No comment was entered for this change.) Attachments: Annotation 2019-07-02 002343.png 620 KB -- 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 44475] New: compiler-rt complains unnecessarily about missing C++ headers on macOS
https://bugs.llvm.org/show_bug.cgi?id=44475 Bug ID: 44475 Summary: compiler-rt complains unnecessarily about missing C++ headers on macOS Product: compiler-rt Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: ste...@uplinklabs.net CC: llvm-bugs@lists.llvm.org It seems really strange that compiler-rt's cmake/Modules/CompilerRTCompile.cmake complains about C++ headers being missing on macOS, when the build in question is happening in a full git clone of the llvm-project tree, and "libcxx;libcxxabi" are present in LLVM_ENABLE_PROJECTS for the build. The message recommends pursuing a manual step of running "installheaders" in libcxx. Couldn't that be replaced by a build step when libcxx/libcxxabi are part of the build? The output in question: --- [6289/6380] Checking that just-built clang can find C++ headers... FAILED: projects/compiler-rt/lib/sanitizer_common/tests/CMakeFiles/CompilerRTUnitTestCheckCxx cd /Users/steven/dev/llvm/build/llvm/projects/compiler-rt/lib/sanitizer_common/tests && bash -c "echo '#include ' | /Users/steven/dev/llvm/build/llvm/./bin/clang -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -E -x c++ - > /dev/null;if [ \$? != 0 ] ; then echo; echo 'Your just-built clang cannot find C++ headers, which are needed to build and run compiler-rt tests.'; echo 'You should copy or symlink your system C++ headers into /Users/steven/dev/llvm/build/llvm/include/c++'; if [ -d \$(dirname \$(dirname \$(xcrun -f clang)))/include/c++ ];then echo 'e.g. with:';echo ' cp -r' \$(dirname \$(dirname \$(xcrun -f clang)))/include/c++ '/Users/steven/dev/llvm/build/llvm/include/'; elif [ -d \$(dirname \$(dirname \$(xcrun -f clang)))/lib/c++ ];then echo 'e.g. with:';echo ' cp -r' \$(dirname \$(dirname \$(xcrun -f clang)))/lib/c++ '/Users/steven/dev/llvm/build/llvm/include/'; fi; echo 'This can also be fixed by checking out the libcxx project from llvm.org and installing the headers'; echo 'into your build directory:'; echo ' cd /Users/steven/dev/llvm/llvm-project/llvm/projects && svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx'; echo ' cd /Users/steven/dev/llvm/build/llvm && make -C /Users/steven/dev/llvm/llvm-project/llvm/projects/libcxx installheaders HEADER_DIR=/Users/steven/dev/llvm/build/llvm/include'; echo; false;fi" :1:10: fatal error: 'iostream' file not found #include ^~ 1 error generated. Your just-built clang cannot find C++ headers, which are needed to build and run compiler-rt tests. You should copy or symlink your system C++ headers into /Users/steven/dev/llvm/build/llvm/include/c++ e.g. with: cp -r /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++ /Users/steven/dev/llvm/build/llvm/include/ This can also be fixed by checking out the libcxx project from llvm.org and installing the headers into your build directory: cd /Users/steven/dev/llvm/llvm-project/llvm/projects && svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx cd /Users/steven/dev/llvm/build/llvm && make -C /Users/steven/dev/llvm/llvm-project/llvm/projects/libcxx installheaders HEADER_DIR=/Users/steven/dev/llvm/build/llvm/include ninja: build stopped: subcommand failed. --- -- 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 43944] variadic template function passed an initializer list fails with argument count mismatch error rather than expected "couldn't deduce template parameter" error
https://bugs.llvm.org/show_bug.cgi?id=43944
Richard Smith changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #2 from Richard Smith ---
Fixed in llvmorg-10-init-16681-g907cefe7214. (This is slightly speculative;
I've mailed the C++ committee core working group to discuss this, but I think
deducing T as a pack of one unknown element here rather than as an empty pack
is obviously the right thing to do.)
We now accept the testcase from comment#0, and diagnose the testcase from
comment#1 as:
test.cc:28:5: error: no matching function for call to 'variadic'
variadic({0});
^~~~
test.cc:12:27: note: candidate template ignored: substitution failure: deduced
incomplete pack <(no value)> for template parameter 'T'
template void variadic(T&&...) {}
~ ^
test.cc:32:5: error: no matching function for call to 'single'
single({0});
^~
test.cc:14:24: note: candidate template ignored: couldn't infer template
argument 'T'
template void single(T&&) {}
^
Note that we accept the
x = {0};
line now, as a call to the move assignment operator (that is, as "x = X{0};"),
because deduction for the templated operator= now fails due to failing to
deduce a complete value for parameter T.
--
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 19870 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Token::getIdentifierInfo
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.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-2020-01-07 Type: Bug New issue 19870 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Token::getIdentifierInfo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19870 Detailed Report: https://oss-fuzz.com/testcase?key=5669417644195840 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc58c24ff8 Crash State: clang::Token::getIdentifierInfo clang::Parser::ParseOptionalCXXScopeSpecifier clang::Parser::TryAnnotateName Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=202001050425:202001060422 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5669417644195840 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] Issue 19866 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: !IsScalable && "Request for a fixed size on a scalable object"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.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-2020-01-07 Type: Bug New issue 19866 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: !IsScalable && "Request for a fixed size on a scalable object" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19866 Detailed Report: https://oss-fuzz.com/testcase?key=5705451346067456 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-instcombine Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !IsScalable && "Request for a fixed size on a scalable object" llvm::FindAvailablePtrLoadStore llvm::FindAvailableLoadedValue Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201912130427:201912200437 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5705451346067456 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] Issue 19863 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-O2: ASSERT: isa(Val) && "cast() argument of incompatible type!"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.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-2020-01-06 Type: Bug New issue 19863 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-O2: ASSERT: isa(Val) && "cast() argument of incompatible type!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19863 Detailed Report: https://oss-fuzz.com/testcase?key=5740322965684224 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: isa(Val) && "cast() argument of incompatible type!" calculateCXXStateNumbers llvm::calculateWinCXXEHStateNumbers Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201710160455:201710190451 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5740322965684224 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 13590] Select condition not propagated to values
https://bugs.llvm.org/show_bug.cgi?id=13590 David Bolvansky changed: What|Removed |Added CC||david.bolvan...@gmail.com Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from David Bolvansky --- https://godbolt.org/z/q9bYds -- 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 44473] New: Different behavior for #include when using -iquote with/without header maps
https://bugs.llvm.org/show_bug.cgi?id=44473
Bug ID: 44473
Summary: Different behavior for #include when using -iquote
with/without header maps
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: 6f6...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
When using the -iquote flag to clang, the behavior of an #include directive is
different if the argument passed is a directory or a header map.
This works as expected:
$ cat test.c
#include "foo.h"
int bar() { return foo(); }
$ cat some/include/path/foo.h
int foo(void);
$ clang -c -iquote some/include/path test.c
$
However, if foo.h comes via a header map:
$ ~/bin/hmapdump headers.hmap
Header:
Magic: hmap
Version: 1
Reserved: 0
StringsOffset: 72
NumEntries: 3
NumBuckets: 4
MaxValueLength: 23
Buckets:
0: empty
1: empty
2: 1 7 26
3: empty
StringsTable:
0:
1: foo.h
7: some/include/path/
26: foo.h
Entries:
[2] 'foo.h' -> 'some/include/path/' 'foo.h'
$ clang -c -iquote headers.hmap test.c
test.c:1:10: fatal error: 'foo.h' file not found
#include "foo.h"
^~~
1 error generated.
Is this by design or is it a bug?
--
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 44472] New: Wrong optimization: devirtualization vs. conditional equivalence
https://bugs.llvm.org/show_bug.cgi?id=44472
Bug ID: 44472
Summary: Wrong optimization: devirtualization vs. conditional
equivalence
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ch3r...@openwall.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
This is based on bug 34548, comment 49, and bug 44313. It seems there was an
effort to fix the problem as it applies to devirtualization independently from
the general case, so filing this separately. As mentioned in the referenced
comment, GVN changes a pointer to an older one inside the `if` (it doesn't
matter which pointer is on the left in the comparison and which one is on the
right). Visible only with -fstrict-vtable-pointers.
Devirtualization seems not to be concerned with past-the-end pointers and with
`restrict`, so the focus is on the case of a living object located at the same
place where another, now dead, object was located, e.g.:
- after new/delete/new (or malloc/free/malloc);
- after placement new;
- when two local variables in disjoint blocks occupy the same space.
It seems comparison of naked pointers and casts to integers are handled. What I
spotted missing:
- conversions to pointers to classes without virtual tables -- probably just an
oversight;
- direct memory access like memcpy/memcmp -- much more serious problem.
Example with pointers to a class without virtual tables and a placement new:
--
#include
#include
struct B {
void m() {}
};
struct X : B {
virtual void foo() { puts("foo"); }
};
struct Y : B {
virtual void bar() { puts("bar"); }
};
static_assert(sizeof(X) == sizeof(Y));
int main()
{
B *q = new Y;
X *p = new (q) X;
if (p == q)
p->foo();
}
--
$ clang++ -std=c++2a -Wall -fstrict-vtable-pointers test.cc && ./a.out
foo
$ clang++ -std=c++2a -Wall -fstrict-vtable-pointers -O3 test.cc && ./a.out
bar
--
clang x86-64 version: clang version 10.0.0
(https://github.com/llvm/llvm-project.git
c5fb73c5d1b3f1adb77d99fc85c594b48bff08f9)
--
--
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 44471] New: [SelectionDAG] OptLevelChanger::SavedFastISel uninitialized variable warning
https://bugs.llvm.org/show_bug.cgi?id=44471
Bug ID: 44471
Summary: [SelectionDAG] OptLevelChanger::SavedFastISel
uninitialized variable warning
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: llvm-bugs@lists.llvm.org, llvm-...@ndave.org,
paul_robin...@playstation.sony.com,
spatel+l...@rotateright.com
https://llvm.org/reports/scan-build/report-SelectionDAGISel.cpp-~OptLevelChanger-9-1.html#EndPath
OptLevelChanger(SelectionDAGISel ,
CodeGenOpt::Level NewOptLevel) : IS(ISel) {
SavedOptLevel = IS.OptLevel;
if (NewOptLevel == SavedOptLevel)
return;
IS.OptLevel = NewOptLevel;
IS.TM.setOptLevel(NewOptLevel);
DEBUG(dbgs() << "\nChanging optimization level for Function "
<< IS.MF->getFunction()->getName() << "\n");
DEBUG(dbgs() << "\tBefore: -O" << SavedOptLevel
<< " ; After: -O" << NewOptLevel << "\n");
SavedFastISel = IS.TM.Options.EnableFastISel;
if (NewOptLevel == CodeGenOpt::None) {
IS.TM.setFastISel(IS.TM.getO0WantsFastISel());
DEBUG(dbgs() << "\tFastISel is "
<< (IS.TM.Options.EnableFastISel ? "enabled" : "disabled")
<< "\n");
}
}
Static analyzer has noticed that SavedFastISel is not initialized if the
"NewOptLevel == SavedOptLevel" warl out occurs.
--
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 36067] Unsupported ASM constraints for RISCV target
https://bugs.llvm.org/show_bug.cgi?id=36067 Luís Marques changed: What|Removed |Added Resolution|--- |FIXED CC||luismarq...@lowrisc.org Status|NEW |RESOLVED --- Comment #3 from Luís Marques --- These constraints now all work (to test the 'f' constraint don't forget to enable the floating-point extensions). Marking as resolved. -- 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 44470] New: insn->consumedDisplacement is Overwritten Before Being Used
https://bugs.llvm.org/show_bug.cgi?id=44470 Bug ID: 44470 Summary: insn->consumedDisplacement is Overwritten Before Being Used Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: cameron.sm...@pnnl.gov CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com Created attachment 22992 --> https://bugs.llvm.org/attachment.cgi?id=22992=edit X86::readDisplacement() In the file llvm/lib/Target/X86/Disassembler/X86DisassemblerDecoder.cpp in the function readDisplacement (line 1235), insn->consumedDisplacement is set to true on line 1245. In the proceeding switch statement, the same variable may be set to false (if insn->eaDisplacement == EA_DSP_NONE), but the line immediately after the switch (line 1269) always sets it back to true. I think this can be fixed by removing line 1269. I've attached a copy of the function in question. -- 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 18256 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in Evaluate
Updates: Labels: Deadline-Approaching Comment #2 on issue 18256 by sheriff...@chromium.org: llvm:clang-fuzzer: Stack-overflow in Evaluate https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18256#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 18251 in oss-fuzz: llvm:llvm-isel-fuzzer--wasm32-O2: Abrt in llvm::llvm_unreachable_internal
Updates: Labels: Deadline-Approaching Comment #2 on issue 18251 by sheriff...@chromium.org: llvm:llvm-isel-fuzzer--wasm32-O2: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18251#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 18198 in oss-fuzz: llvm:clang-fuzzer: ASSERT: NextLocalOffset + TokLength + 1 > NextLocalOffset && NextLocalOffset + TokLength
Updates: Labels: Deadline-Approaching Comment #2 on issue 18198 by sheriff...@chromium.org: llvm:clang-fuzzer: ASSERT: NextLocalOffset + TokLength + 1 > NextLocalOffset && NextLocalOffset + TokLength https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18198#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 18208 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_unroll: Use-of-uninitialized-value in bool llvm::DenseMapBase
Updates: Labels: Deadline-Approaching Comment #2 on issue 18208 by sheriff...@chromium.org: llvm:llvm-opt-fuzzer--x86_64-loop_unroll: Use-of-uninitialized-value in bool llvm::DenseMapBasellvm::detail::DenseSetEm https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18208#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 18240 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-gvn: ASSERT: isFPPredicate() && "Invalid FCmp predicate value"
Updates: Labels: Deadline-Approaching Comment #2 on issue 18240 by sheriff...@chromium.org: llvm:llvm-opt-fuzzer--x86_64-gvn: ASSERT: isFPPredicate() && "Invalid FCmp predicate value" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18240#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 44407] Building offloading app is extremely slow
https://bugs.llvm.org/show_bug.cgi?id=44407 Alexey Bataev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- 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 44469] New: [x86] x & ~0xFFFF could be emitted as 16-bit xor
https://bugs.llvm.org/show_bug.cgi?id=44469
Bug ID: 44469
Summary: [x86] x & ~0x could be emitted as 16-bit xor
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: til...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
uint64_t foo(uint64_t x)
{
return x & 0x''';
}
GCC: xor ax, ax(3 bytes)
Clang: and rax, 0x' (6 bytes)
Same thing for 32-bit "x & 0x'".
As far as I'm aware the only reason 16-bit instructions are usually avoided is
because they always implicitly depend on the upper bits (but this dependency is
required here) and because the size override increases encoding length (not the
case here because it saves a 32-bit immediate).
--
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 44468] New: Cannot access members of temporary objects created via CTAD
https://bugs.llvm.org/show_bug.cgi?id=44468
Bug ID: 44468
Summary: Cannot access members of temporary objects created via
CTAD
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++17
Assignee: unassignedclangb...@nondot.org
Reporter: tony.wasse...@gmx.de
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
When creating temporary objects of deduced template argument type, clang fails
to compile a program that attempts to access a member of the created object.
Example: `MyTemplate { t }.a`.
A workaround is to wrap the created object in an std::move, like
`std::move(MyTemplate { t }).a`.
Interestingly, this issue only seems to happen when the constructor argument
itself is a dependent name.
Full example: https://godbolt.org/z/Tj6TC7 . GCC and MSVC consider this example
valid.
--
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 43660] [X86] Use combineLogicBlendIntoConditionalNegate for SSSE3+ targets
https://bugs.llvm.org/show_bug.cgi?id=43660 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)|rG6a6e6f04ec|rG6a6e6f04ec,rGe3bd0118903c --- Comment #2 from Simon Pilgrim --- Fixed in rGe3bd0118903c -- 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 44467] New: [ARM][load / store optimization pass] Missed optimization: coalesce pre-increment
https://bugs.llvm.org/show_bug.cgi?id=44467
Bug ID: 44467
Summary: [ARM][load / store optimization pass] Missed
optimization: coalesce pre-increment
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Keywords: missing-feature
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: diogo.samp...@arm.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Created attachment 22991
--> https://bugs.llvm.org/attachment.cgi?id=22991=edit
Minimal MIR case
Missed optimization:
When running
llc --print-before-all --start-before=arm-ldst-opt missed.mir -o -
we obtain:
push.w {r4, r5, r6, r7, r8, r10, r11, lr}
sub sp, #8
strdr0, r1, [sp]@ 8-byte Folded Spill
@ InlineAsm Start
@ InlineAsm End
ldrdr0, r1, [sp], #8@ 8-byte Folded Reload
pop.w {r4, r5, r6, r7, r8, r10, r11, pc}
I would expect the strd to be pre-incremented, as:
push.w {r4, r5, r6, r7, r8, r10, r11, lr}
strdr0, r1, [sp, #-8]!
@ InlineAsm Start
@ InlineAsm End
ldrdr0, r1, [sp], #8
pop.w {r4, r5, r6, r7, r8, r10, r11, pc}
--
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 44459] Error when compiling Boost MP11 mp_similar
https://bugs.llvm.org/show_bug.cgi?id=44459 Tobias Loew changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- 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
