[llvm-bugs] Issue 31244 in oss-fuzz: llvm:clang-objc-fuzzer: Stack-overflow in std::__1::enable_if::value, llvm::hash_code
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-02-22 Type: Bug New issue 31244 by ClusterFuzz-External: llvm:clang-objc-fuzzer: Stack-overflow in std::__1::enable_if::value, llvm::hash_code https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31244 Detailed Report: https://oss-fuzz.com/testcase?key=5138069645819904 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-objc-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffd45670fa8 Crash State: std::__1::enable_if::value, llvm::hash_code llvm::FoldingSetBase::FindNodeOrInsertPos clang::ASTContext::getFunctionNoProtoType Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202011130615:202011140605 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5138069645819904 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 49306] New: Loop-interchange : Some triangular loop nests are interchanged
https://bugs.llvm.org/show_bug.cgi?id=49306
Bug ID: 49306
Summary: Loop-interchange : Some triangular loop nests are
interchanged
Product: tools
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: opt
Assignee: unassignedb...@nondot.org
Reporter: flemair...@gmail.com
CC: llvm-bugs@lists.llvm.org
$ clang -Os -mllvm -enable-loopinterchange=true traingular_fail.c && ./a.out
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
$ clang -Os -mllvm -enable-loopinterchange=false triangular_fail.c && ./a.out
0 2 7 83 0 0 9 43 0 0 0 0 0 0 0 0
$ cat triangular_fail.c
#include
int foo() {
int A[4][4] = {{ 0, 0, 0, 0},
{ 0, 0, 0, 0},
{ 0, 0, 0, 0},
{ 0, 0, 0, 0}};
int B[4][4] = {{ 16, 2, 7, 83},
{ 35, 8, 9, 43},
{ 47, 123, 32, 0},
{ 21, 11, 19, 29}};
for (int i = 0; i < 4; ++i)
for (int j = 0; j < i; ++j)
A[j][i] = B[j][i];
for (int i = 0; i < 4; ++i)
for (int j = 0; j < 4; j++)
printf("%d ", A[i][j]);
printf("\n");
return 0;
}
int main() {
foo();
return 0;
}
LoopInterchange does not detect the issue with the operation `j___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49307] New: Clang++ error in backend Cannot select t11
https://bugs.llvm.org/show_bug.cgi?id=49307 Bug ID: 49307 Summary: Clang++ error in backend Cannot select t11 Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: dosarudan...@gmail.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 24558 --> https://bugs.llvm.org/attachment.cgi?id=24558&action=edit Follow the README instruction to compile test4 target. Uncomment the test4.cpp:22 If the queues[0]->enqueue(0); line from test4.cpp:22 is uncommented I get this weird compile error: fatal error: error in backend: Cannot select: t11: i32,ch = AtomicLoad<(load seq_cst 4 from %ir._M_i.i.i.i.i.i)> t6:1, t10 t10: i64 = add nuw t6, Constant:i64<8> t6: i64,ch = load<(load 8 from %ir.arg, !tbaa !9, addrspace 1)> t0, t15, undef:i64 t15: i64,ch = load<(dereferenceable invariant load 8 from i64 addrspace(101)* null, addrspace 101)> t0, TargetExternalSymbol:i64'_ZTSZZ4mainENKUlRN2cl4sycl7handlerEE39_16clES2_EUlNS0_7nd_itemILi340_63_param_0', undef:i64 t1: i64 = TargetExternalSymbol'_ZTSZZ4mainENKUlRN2cl4sycl7handlerEE39_16clES2_EUlNS0_7nd_itemILi340_63_param_0' t3: i64 = undef t3: i64 = undef t9: i64 = Constant<8> In function: _ZTSZZ4mainENKUlRN2cl4sycl7handlerEE39_16clES2_EUlNS0_7nd_itemILi340_63 clang-12: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 13.0.0 (https://github.com/intel/llvm 73b7da0314703154d613d7883a3483468e7e461a) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /home/dadosaru/sycl_workspace/llvm/build/bin clang-12: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs. CMakeFiles/test4.dir/build.make:102: recipe for target 'test4' failed make[3]: *** [test4] Error 70 CMakeFiles/Makefile2:129: recipe for target 'CMakeFiles/test4.dir/all' failed make[2]: *** [CMakeFiles/test4.dir/all] Error 2 CMakeFiles/Makefile2:136: recipe for target 'CMakeFiles/test4.dir/rule' failed make[1]: *** [CMakeFiles/test4.dir/rule] Error 2 Makefile:150: recipe for target 'test4' failed make: *** [test4] Error 2 -- 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 49308] New: [AMDGPU][MC][DOC] Incorrect description of MADAK, MADMK, etc
https://bugs.llvm.org/show_bug.cgi?id=49308 Bug ID: 49308 Summary: [AMDGPU][MC][DOC] Incorrect description of MADAK, MADMK, etc Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org Instructions which have implicit literal operands (v_madak_f32, v_madmk_f32, etc) cannot specify literals for other operands. However documentation states that src0 can be a literal. This should be corrected for GFX7, GFX8, GFX9 and GFX10. -- 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 31118] AVX512: inefficient code generation
https://bugs.llvm.org/show_bug.cgi?id=31118 Simon Pilgrim changed: What|Removed |Added Resolution|--- |INVALID CC||llvm-...@redking.me.uk Status|NEW |RESOLVED --- Comment #2 from Simon Pilgrim --- Resolving very old bug without enough specific info to go on for triage - Roland please feel free to reopen this with more specific details if you can. -- 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 49309] New: [AMDGPU][MC][GFX9+][DOC] Incorrect description of SMEM offset operand
https://bugs.llvm.org/show_bug.cgi?id=49309 Bug ID: 49309 Summary: [AMDGPU][MC][GFX9+][DOC] Incorrect description of SMEM offset operand Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org The description states that signed 21-bit offsets are not supported. This is a documentation bug and should be corrected for GFX9 and GFX10. -- 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 48902] [meta] 12.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=48902 Bug 48902 depends on bug 49227, which changed state. Bug 49227 Summary: Merge d22140687500f90830fe416d9c1e317f7c4535d5 into 12.0.0 https://bugs.llvm.org/show_bug.cgi?id=49227 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49227] Merge d22140687500f90830fe416d9c1e317f7c4535d5 into 12.0.0
https://bugs.llvm.org/show_bug.cgi?id=49227
James Henderson changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED|REOPENED
CC||jh7370.2...@my.bristol.ac.u
||k
--- Comment #2 from James Henderson ---
We are seeing a failure of the test that is part of the commit on our version
of the release branch, following this cherry-pick. The failure is almost
certainly due to a missing prerequisite lit change. The lit change in question
I think we'd need is
https://github.com/llvm/llvm-project/commit/42a21778f61cdc8462ce2cfb6ad7bc1992b2063c,
although there are some known issues with that change (see
https://reviews.llvm.org/D95246), so it would probably be safer to make a
different change to the test.
I am not currently set up to work with the release branch, and am not in a good
place to provide the new fix instead. However, I can describe it here.
Essentially, all that needs to happen is one of the two following:
1) Delete the -DMSG=%errc_ENOENT bits from lines 36 and 38 of the test, and
replace the `[[MSG]]` on lines 40 and 46 with `{{[Nn]))o such file or
directory`.
2) Replace the `%errc_ENOENT` on lines 36 and 38 with `{{[Nn]))o such file or
directory`, possibly with additional quoting to avoid any shell character
issues, I'm not sure.
--
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 49310] New: [C++4OpenCL] Inconsistent diagnostics for taking function address
https://bugs.llvm.org/show_bug.cgi?id=49310
Bug ID: 49310
Summary: [C++4OpenCL] Inconsistent diagnostics for taking
function address
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: anastasia.stul...@arm.com
CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org
An inconsistent diagnostic is given when function addresses are taken i.e.
template functions are not diagnosed while normal functions are.
template
void f1(){}
void f2(){}
void bar(){
f1;
f2;//error: taking address of function is not allowed
}
It is not clear though why the diagnostic was added since OpenCL C never
restricted taking addresses of functions. Perhaps it was considered useless
since function pointers can't be used. However, taking an address doesn't imply
that the function will necessarily be called even if it is the most common use
case. In addition to that, the diagnostic is handled in Parser and not Sema
where it conceptually belongs. Potentially we need to see if we can just remove
the diagnostic.
--
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 45977] Failure to optimize combined ors/nots/xors into single not
https://bugs.llvm.org/show_bug.cgi?id=45977 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Simon Pilgrim --- Resolving - I added test coverage at 19084887d9222 to check for InstCombine regressions -- 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 49311] New: typedef syntax for `using [[gnu::vector_size]]` not accepted
https://bugs.llvm.org/show_bug.cgi?id=49311 Bug ID: 49311 Summary: typedef syntax for `using [[gnu::vector_size]]` not accepted Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: C++2a Assignee: unassignedclangb...@nondot.org Reporter: koncek.mar...@gmail.com CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk The following line: using simd_t = int [[gnu::vector_size(16)]]; is not accepted by Clang (but is accepted by GCC). Note that a typedef declaration is accepted also by Clang: typedef int simd_t [[gnu::vector_size(16)]]; See: https://gcc.godbolt.org/z/zYc7ec -- 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 31247 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in void llvm::SmallVectorImpl::resizeImpl
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-02-22 Type: Bug New issue 31247 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in void llvm::SmallVectorImpl::resizeImpl https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31247 Detailed Report: https://oss-fuzz.com/testcase?key=5587813250760704 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffe940f5e78 Crash State: void llvm::SmallVectorImpl::resizeImpl clang::Sema::ActOnNumericConstant clang::Parser::ParseCastExpression Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202009230606:202009240614 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5587813250760704 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 49312] New: [OpenMP] UB when hidden helper threads is 1
https://bugs.llvm.org/show_bug.cgi?id=49312 Bug ID: 49312 Summary: [OpenMP] UB when hidden helper threads is 1 Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: rofir...@gmail.com CC: llvm-bugs@lists.llvm.org Hi, while investigating another issue, we found that the macro `KMP_GTID_TO_SHADOW_GTID` is defined in `kmp.h` as follows #define KMP_GTID_TO_SHADOW_GTID(gtid) ((gtid) % (__kmp_hidden_helper_threads_num - 1) + 2) When there is only one helper thread the macro attempts to compute `(gtid % 0) - 2`. Setting the environment variable `LIBOMP_NUM_HIDDEN_HELPER_THREADS` to `1` should be enough to trigger this. Perhaps using only one helper thread is not 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 49313] New: relative refstring.h include in libcxxabi makes too strong assumptions
https://bugs.llvm.org/show_bug.cgi?id=49313 Bug ID: 49313 Summary: relative refstring.h include in libcxxabi makes too strong assumptions Product: libc++abi Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com a7b65741441556d295079fc4f2391d99fd1c (unreviewed? at least doesn't link to phab) adds this line to libc++abi's libcxxabi/src/stdlib_stdexcept.cpp: +#include "../../libcxx/src/include/refstring.h" This assumes a certain relative layout, which happens to not be the layout we have libc++ and libc++abi relative to in chromium. It's also not very easy to change things to give them that layout -- many third-party directories in chromium put code in "t_p/depname/src" (via a git submodules like thing) and then put a build file in "t_p/depname". We're trying to update our libc++abi now that we've successfully updated our libc++, and this is a problem. We could add a random -I flag that this relative path resolves against. I'll do this for now, but it's a bit ugly. Maybe we can find something nicer to do on this bug. Options: - say `#include "refstring.h"` and set up the include path in the build system - revert the change -- refstring.h has changed exactly once since that change, and that was likely the change motivating a7b65741441556d295079fc4f2391d99fd1c . Nothing else in libc++abi includes libcxx stuff, and that seems like a good thing layering-wise. The duplication is unfortunate, but maybe less unfortunate than a cyclic dep?h -- 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 49314] New: 11.1.0: test suite is failing
https://bugs.llvm.org/show_bug.cgi?id=49314
Bug ID: 49314
Summary: 11.1.0: test suite is failing
Product: clang
Version: 11.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: kloczko.tom...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
gcc 11.0.1
python lit 0.11.1
Python 3.8.8
llvm 11.1.0 build with using LTO on linking all binaries
[tkloczko@barrel clang-11.1.0.src]$
LD_LIBRARY_PATH=/home/tkloczko/rpmbuild/BUILDROOT/clang-11.1.0-7.fc35.x86_64/usr/lib64
/usr/bin/cmake --build x86_64-redhat-linux-gnu -j48 --verbose --target
check-all --verbose -v
[1/2] cd /home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/bindings/python &&
/usr/bin/cmake -E env
CLANG_LIBRARY_PATH=/home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/x86_64-redhat-linux-gnu/lib64
/usr/bin/python3.8 -m unittest discover
./home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/bindings/python/tests/cindex/test_diagnostics.py:100:
DeprecationWarning: Please use assertRegex instead.
self.assertRegexpMatches(children[0].spelling,
.
--
Ran 126 tests in 1.087s
OK
[1/2] cd /home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/x86_64-redhat-linux-gnu
&& /usr/bin/python3.8 /usr/bin/lit -sv --param USE_Z3_SOLVER=0
/home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/x86_64-redhat-linux-gnu/tools/extra/test
/home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/x86_64-redhat-linux-gnu/tools/extra/clangd/test/../unittests
/home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/x86_64-redhat-linux-gnu/tools/extra/clangd/test
/home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/x86_64-redhat-linux-gnu/test
lit: /usr/lib/python3.8/site-packages/lit/llvm/config.py:345: note: using
clang:
/home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/x86_64-redhat-linux-gnu/bin/clang
lit: /usr/lib/python3.8/site-packages/lit/llvm/config.py:345: note: using
clang:
/home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/x86_64-redhat-linux-gnu/bin/clang
lit: /usr/lib/python3.8/site-packages/lit/TestingConfig.py:99: fatal: unable to
parse config file
'/home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/test/utils/update_cc_test_checks/lit.local.cfg',
traceback: Traceback (most recent call last):
File "/usr/lib/python3.8/site-packages/lit/TestingConfig.py", line 88, in
load_from_path
exec(compile(data, path, 'exec'), cfg_globals, None)
File
"/home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/test/utils/update_cc_test_checks/lit.local.cfg",
line 21, in
assert os.path.isfile(script_path)
AssertionError
FAILED: CMakeFiles/check-all
cd /home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/x86_64-redhat-linux-gnu &&
/usr/bin/python3.8 /usr/bin/lit -sv --param USE_Z3_SOLVER=0
/home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/x86_64-redhat-linux-gnu/tools/extra/test
/home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/x86_64-redhat-linux-gnu/tools/extra/clangd/test/../unittests
/home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/x86_64-redhat-linux-gnu/tools/extra/clangd/test
/home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/x86_64-redhat-linux-gnu/test
ninja: build stopped: subcommand failed.
[tkloczko@barrel clang-11.1.0.src]$ cat
"/home/tkloczko/rpmbuild/BUILD/clang-11.1.0.src/test/utils/update_cc_test_checks/lit.local.cfg"
import os
import lit.util
# python 2.7 backwards compatibility
try:
from shlex import quote as shell_quote
except ImportError:
from pipes import quote as shell_quote
config.test_format = lit.formats.ShTest(execute_external=False)
config.suffixes = ['.test']
clang_path = os.path.join(config.clang_tools_dir, 'clang')
extra_args = '--clang ' + shell_quote(clang_path)
opt_path = os.path.join(config.llvm_tools_dir, 'opt')
extra_args += ' --opt ' + shell_quote(opt_path)
script_path = os.path.join(config.llvm_src_root, 'utils',
'update_cc_test_checks.py')
assert os.path.isfile(script_path)
config.substitutions.append(
('%update_cc_test_checks', "%s %s %s" % (
shell_quote(config.python_executable), shell_quote(script_path),
extra_args)))
--
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 49315] New: ICE when assigning a function to a pointer.
https://bugs.llvm.org/show_bug.cgi?id=49315
Bug ID: 49315
Summary: ICE when assigning a function to a pointer.
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: anastasia.stul...@arm.com
CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org
When the extension for the function pointers is used
#pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
void foo();
void bar(){
void (*f)() = foo;
}
frontend fails to compile it failing in the incorrect address space conversion
check.
diff --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index e03183c1a42f..8aece0b63037 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -15823,6 +15823,7 @@ bool Sema::DiagnoseAssignmentResult(AssignConvertType
ConvTy,
isInvalid = true;
+// FIXME: On function types we should not be taking a pointee.
Qualifiers lhq = SrcType->getPointeeType().getQualifiers();
Qualifiers rhq = DstType->getPointeeType().getQualifiers();
+// FIXME: The right check should take the address space compatibility into
account.
if (lhq.getAddressSpace() != rhq.getAddressSpace()) {
This issue is not triggered in C++ for OpenCL mode that seems to follow
different conversion path.
--
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 49316] New: program with #pragma pack(1) and __int128 behaves differents under O1 and higher optimization
https://bugs.llvm.org/show_bug.cgi?id=49316
Bug ID: 49316
Summary: program with #pragma pack(1) and __int128 behaves
differents under O1 and higher optimization
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: zhan3...@purdue.edu
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Following code has different behaviors under different optimization level. I am
not sure whether it is caused by asan or optimization, tbh.
$ cat test.c
#pragma pack(1)
struct {
char a;
__int128 b;
} c;
__int128 *d = &c.b;
int main() { *d = 0; }
In short, when compiling with '-O0', the exit code is 0. But when compiling
with '-O1', the exit code is 139 (segment fault).
O0 (program returns 0): https://godbolt.org/z/x3d68s
O1 (program returns 139): https://godbolt.org/z/bef6T9
O2 (program returns 139): https://godbolt.org/z/brvz77
O3 (program returns 139): https://godbolt.org/z/K8sEaa
Os (program returns 129): https://godbolt.org/z/PxToY5
I further use asan to report more details:
O0 (normal): https://godbolt.org/z/5G9bbv
O1 (segfault): https://godbolt.org/z/3ob34b
AddressSanitizer:DEADLYSIGNAL
=
==1==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x004f3ddc bp
0x sp 0x7ffead06c7b0 T0)
==1==The signal is caused by a READ memory access.
==1==Hint: this fault was caused by a dereference of a high value address (see
register values below). Disassemble the provided pc to learn which register
was used.
#0 0x4f3ddc (/app/output.s+0x4f3ddc)
#1 0x7f4b493950b2 (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#2 0x41adad (/app/output.s+0x41adad)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/app/output.s+0x4f3ddc)
==1==ABORTING
--
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 49316] #pragma pack(1) and __int128 lead to bad optimization under O1 and higher optimization
https://bugs.llvm.org/show_bug.cgi?id=49316 Zhuo Zhang 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 49317] New: [meta] 12.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=49317 Bug ID: 49317 Summary: [meta] 12.0.1 Release Blockers Product: new-bugs Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tstel...@redhat.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org -- 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 49196] ARM 32 Bits Windows MSVC C compiler is Fixed in Version LLVM/Clang 11.0.1, But C++ Still Crash
https://bugs.llvm.org/show_bug.cgi?id=49196 Reid Kleckner changed: What|Removed |Added Resolution|--- |DUPLICATE CC||r...@google.com Status|NEW |RESOLVED --- Comment #1 from Reid Kleckner --- The error comes from instruction selection for Windows EH instructions: fatal error: error in backend: Cannot select: 0x55b833e46688: ch = catchret Basically, nobody has implemented exception handling for Windows ARM 32. You can work around the issue by disabling EH with -fno-exceptions. *** This bug has been marked as a duplicate of bug 38341 *** -- 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 45849] llvm-cov: macro constant in if expression lead to incorrect coverage
https://bugs.llvm.org/show_bug.cgi?id=45849 Zequan Wu changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Zequan Wu --- Fixed at https://github.com/llvm/llvm-project/commit/d83511dd26ca8d0dd5be6302ad7b55de05cedab2 -- 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 35397] [AMDGPU][MC][GFX8][GFX9] Use of bound_ctrl is incompatible with SP3
https://bugs.llvm.org/show_bug.cgi?id=35397 Dmitry changed: What|Removed |Added Fixed By Commit(s)||4813518 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 28066 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isa(Val) && "cast() argument of incompatible type!"
Updates: Labels: Deadline-Approaching Comment #1 on issue 28066 by sheriffbot: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isa(Val) && "cast() argument of incompatible type!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28066#c1 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 28077 in oss-fuzz: llvm:llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::StringMapImpl::LookupBucketFor
Updates: Labels: Deadline-Approaching Comment #1 on issue 28077 by sheriffbot: llvm:llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::StringMapImpl::LookupBucketFor https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28077#c1 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 28096 in oss-fuzz: llvm:clang-objc-fuzzer: ASSERT: NextLocalOffset + TokLength + 1 > NextLocalOffset && NextLocalOffset + TokLength
Updates: Labels: Deadline-Approaching Comment #1 on issue 28096 by sheriffbot: llvm:clang-objc-fuzzer: ASSERT: NextLocalOffset + TokLength + 1 > NextLocalOffset && NextLocalOffset + TokLength https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28096#c1 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 28183 in oss-fuzz: llvm:clang-objc-fuzzer: ASSERT: (LHSExpr->containsErrors() || RHSExpr->containsErrors()) && "Should only occur i
Updates: Labels: Deadline-Approaching Comment #1 on issue 28183 by sheriffbot: llvm:clang-objc-fuzzer: ASSERT: (LHSExpr->containsErrors() || RHSExpr->containsErrors()) && "Should only occur i https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28183#c1 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 48902] [meta] 12.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=48902 Bug 48902 depends on bug 49215, which changed state. Bug 49215 Summary: Regression (12.0) Assertion `ValTy->isFPOrFPVectorTy() && "Expected float point or integer vector type."' failed https://bugs.llvm.org/show_bug.cgi?id=49215 What|Removed |Added Status|REOPENED|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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49215] Regression (12.0) Assertion `ValTy->isFPOrFPVectorTy() && "Expected float point or integer vector type."' failed
https://bugs.llvm.org/show_bug.cgi?id=49215 Tom Stellard changed: What|Removed |Added Status|REOPENED|RESOLVED Fixed By Commit(s)|5b250a27ec78|5b250a27ec78 a3545a0b0777 Resolution|--- |FIXED --- Comment #8 from Tom Stellard --- Merged: a3545a0b0777 -- 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 17550] tuple::operator=(derived_from_tuple)
https://bugs.llvm.org/show_bug.cgi?id=17550 Louis Dionne changed: What|Removed |Added Fixed By Commit(s)||a0839b14df6de99fe29bee7cdff ||f182d50de665d Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #12 from Louis Dionne --- Fix merged: commit a0839b14df6de99fe29bee7cdfff182d50de665d Author: Louis Dionne Date: Tue Jul 31 11:56:20 2018 -0400 [libc++] Fix tuple assignment from types derived from a tuple-like The implementation of tuple's constructors and assignment operators currently diverges from the way the Standard specifies them, which leads to subtle cases where the behavior is not as specified. In particular, a class derived from a tuple-like type (e.g. pair) can't be assigned to a tuple with corresponding members, when it should. This commit re-implements the assignment operators (BUT NOT THE CONSTRUCTORS) in a way much closer to the specification to get rid of this bug. Most of the tests have been stolen from Eric's patch https://reviews.llvm.org/D27606. As a fly-by improvement, tests for noexcept correctness have been added to all overloads of operator=. We should tackle the same issue for the tuple constructors in a future patch - I'm just trying to make progress on fixing this long-standing bug. PR17550 rdar://15837420 Differential Revision: https://reviews.llvm.org/D50106 -- 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 49139] Cherry-pick 0b70c86e2007d3f32968f0a7d9efe8eab3bf0f0a to 12.x release
https://bugs.llvm.org/show_bug.cgi?id=49139 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)|0b70c86e2007d3f32968f0a7d9e |0b70c86e2007d3f32968f0a7d9e |fe8eab3bf0f0a |fe8eab3bf0f0a 76e4c93ea42b --- Comment #3 from Tom Stellard --- Merged: 76e4c93ea42b -- 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 48902] [meta] 12.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=48902 Bug 48902 depends on bug 49139, which changed state. Bug 49139 Summary: Cherry-pick 0b70c86e2007d3f32968f0a7d9efe8eab3bf0f0a to 12.x release https://bugs.llvm.org/show_bug.cgi?id=49139 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49299] Merge b42d57a100c5df6ace68f686f5adaabeafe8a0f6 into release/12.x
https://bugs.llvm.org/show_bug.cgi?id=49299 Tom Stellard changed: What|Removed |Added Fixed By Commit(s)|b42d57a100c5df6ace68f686f5a |b42d57a100c5df6ace68f686f5a |daabeafe8a0f6 |daabeafe8a0f6 3444f052006c Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Tom Stellard --- Merged: 3444f052006c -- 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 48902] [meta] 12.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=48902 Bug 48902 depends on bug 49299, which changed state. Bug 49299 Summary: Merge b42d57a100c5df6ace68f686f5adaabeafe8a0f6 into release/12.x https://bugs.llvm.org/show_bug.cgi?id=49299 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49243] Cherry-pick ecea7218fb9b994b26471e9877851cdb51a5f1d4 and cdef5a7161767c2c4b3b7cb2542cf1d29b6d4a09
https://bugs.llvm.org/show_bug.cgi?id=49243 Tom Stellard changed: What|Removed |Added Fixed By Commit(s)|ecea7218fb9b994b26471e98778 |ecea7218fb9b994b26471e98778 |51cdb51a5f1d4 |51cdb51a5f1d4 |cdef5a7161767c2c4b3b7cb2542 |cdef5a7161767c2c4b3b7cb2542 |cf1d29b6d4a09 |cf1d29b6d4a09 d84046334015 ||b60110090a94 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Tom Stellard --- Merged: b60110090a94 -- 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 48902] [meta] 12.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=48902 Bug 48902 depends on bug 49243, which changed state. Bug 49243 Summary: Cherry-pick ecea7218fb9b994b26471e9877851cdb51a5f1d4 and cdef5a7161767c2c4b3b7cb2542cf1d29b6d4a09 https://bugs.llvm.org/show_bug.cgi?id=49243 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49319] New: FileCheck Crash with Malformed Regex
https://bugs.llvm.org/show_bug.cgi?id=49319 Bug ID: 49319 Summary: FileCheck Crash with Malformed Regex Product: Test Suite Version: trunk Hardware: All OS: Linux Status: NEW Severity: normal Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: nadiasggeb...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org Tested on LLVM with the most recent commit: a08e609d2eac7737bfc14cd4ee35b2cabe1238b6. Given the following "check.mlir" ``` // CHECK: [[a:*]] ``` Running with ``` ./bin/FileCheck ../check.mlir ``` I expect to see FileCheck emit an error about invalid regex or wait for input on stdin, but instead I see the attached segmentation fault and subsequent stack trace. -- 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 31262 in oss-fuzz: llvm:llvm-isel-fuzzer--x86_64-O2: ASSERT: (isUIntN(8 * Size, Value) || isIntN(8 * Size, Value)) && "Invalid size"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-02-22 Type: Bug New issue 31262 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--x86_64-O2: ASSERT: (isUIntN(8 * Size, Value) || isIntN(8 * Size, Value)) && "Invalid size" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31262 Detailed Report: https://oss-fuzz.com/testcase?key=6530253766918144 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--x86_64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: (isUIntN(8 * Size, Value) || isIntN(8 * Size, Value)) && "Invalid size" llvm::MCStreamer::emitIntValue llvm::StackMaps::emitCallsiteEntries Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202011050602:202011060627 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6530253766918144 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 49320] New: Cherry-pick JumpThreading noalias decl fix to 12.0.0
https://bugs.llvm.org/show_bug.cgi?id=49320 Bug ID: 49320 Summary: Cherry-pick JumpThreading noalias decl fix to 12.0.0 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: nikita@gmail.com CC: llvm-bugs@lists.llvm.org Blocks: 48902 If it's still possible, please cherry-pick https://github.com/llvm/llvm-project/commit/5e7e499b912d2c9ebaa91b5783ca123dbedeabcc to the release branch, which fixes handling of noalias.scope.decl intrinsics inside JumpThreading. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=48902 [Bug 48902] [meta] 12.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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45958] [Vplan] Wrong vec.phi generation
https://bugs.llvm.org/show_bug.cgi?id=45958 Florian Hahn changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||15a74b64dfa9 --- Comment #2 from Florian Hahn --- We can now model the def-use chains in VPlan directly, which allows us to keep track of incoming (VPValue, VPBB) pairs directly in VPlan, to fix this issue. Should be fixed in https://reviews.llvm.org/rG15a74b64dfa9bc1213cd582415f849b4dba51bad -- 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 49321] New: forming reference to nullptr is not rejected in constexpr
https://bugs.llvm.org/show_bug.cgi?id=49321
Bug ID: 49321
Summary: forming reference to nullptr is not rejected in
constexpr
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: ldalessan...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
I think this UB should be rejected.
```
constexpr bool foo(int* i) {
int& j = *i;
return true;
}
static_assert(foo(nullptr));
```
https://godbolt.org/z/cKo3jf
--
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 49322] New: SystemZ stack temporary overflow
https://bugs.llvm.org/show_bug.cgi?id=49322
Bug ID: 49322
Summary: SystemZ stack temporary overflow
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: SystemZ
Assignee: unassignedb...@nondot.org
Reporter: jist...@redhat.com
CC: llvm-bugs@lists.llvm.org
This bug was reduced from one of the failures in Rust #80810:
https://github.com/rust-lang/rust/issues/80810
When a large integer argument on s390x is converted to indirect, but the type
is not a multiple of 64 bits, the writes to the stack are all still in 64-bit
chunks and may clobber neighboring values on the stack.
### arg-i96.ll
target datalayout = "E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-a:8:16-n32:64"
target triple = "s390x-unknown-linux-gnu"
declare hidden void @fn1(i96) unnamed_addr
define hidden i32 @fn2() unnamed_addr {
start:
%0 = alloca i32, align 4
store i32 -1, i32* %0, align 4
call void @fn1(i96 0)
%1 = load i32, i32* %0, align 4
ret i32 %1
}
### llc -O0
.text
.file "arg-i96.ll"
.hidden fn2 # -- Begin function fn2
.globl fn2
.p2align4
.type fn2,@function
fn2:# @fn2
.cfi_startproc
# %bb.0:# %start
stmg%r14, %r15, 112(%r15)
.cfi_offset %r14, -48
.cfi_offset %r15, -40
aghi%r15, -176
.cfi_def_cfa_offset 336
mvhi172(%r15), -1
mvghi 168(%r15), 0
mvghi 160(%r15), 0
la %r2, 160(%r15)
brasl %r14, fn1@PLT
l %r2, 172(%r15)
lmg %r14, %r15, 288(%r15)
br %r14
.Lfunc_end0:
.size fn2, .Lfunc_end0-fn2
.cfi_endproc
# -- End function
.hidden fn1
.section".note.GNU-stack","",@progbits
###
In this reproducer, the 32-bit store to %0 -- mvhi 172(%r15), -1 -- is
immediately overwritten by the overflowing 64-bit store to the end of %1 --
mvghi 168(%r15), 0.
With --print-after-all, you can also see the 12-byte (96-bit) frame allocation
with two 8-byte writes.
# *** IR Dump After Finalize ISel and expand pseudo-instructions ***:
# Machine code for function fn2: IsSSA, TracksLiveness
Frame Objects:
fi#0: size=4, align=4, at location [SP]
fi#1: size=12, align=8, at location [SP]
bb.0.start:
MVHI %stack.0, 0, -1 :: (store 4 into %ir.0)
ADJCALLSTACKDOWN 0, 0
MVGHI %stack.1, 8, 0 :: (store 8 into %stack.1)
MVGHI %stack.1, 0, 0 :: (store 8 into %stack.1)
%0:gr64bit = LA %stack.1, 0, $noreg
$r2d = COPY %0:gr64bit
CallBRASL @fn1, $r2d, ,
implicit-def dead $r14d, implicit-def dead $cc, implicit $fpc
ADJCALLSTACKUP 0, 0
%1:gr32bit = L %stack.0, 0, $noreg :: (dereferenceable load 4 from %ir.0)
$r2l = COPY %1:gr32bit
Return implicit $r2l
# End machine code for function fn2.
--
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 48902] [meta] 12.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=48902 Bug 48902 depends on bug 49318, which changed state. Bug 49318 Summary: cppcoreguidlines-prefer-member-initializer is unusable in release branch https://bugs.llvm.org/show_bug.cgi?id=49318 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49323] New: deque::insert doesn't cleanup if exception is fired by an element copy constructor
https://bugs.llvm.org/show_bug.cgi?id=49323 Bug ID: 49323 Summary: deque::insert doesn't cleanup if exception is fired by an element copy constructor Product: libc++ Version: 10.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Standards Issues Assignee: unassignedclangb...@nondot.org Reporter: picke...@synopsys.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Created attachment 24562 --> https://bugs.llvm.org/attachment.cgi?id=24562&action=edit compile the test case for any target and execute it. It will display "FAIL" The "deque::insert()" of multiple elements does not properly clean up if a copy constructor of one of the elements fires an exception. See attached test case. -- 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 49297] [llvm-cov] Revert D85036
https://bugs.llvm.org/show_bug.cgi?id=49297 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Tom Stellard --- Merged: a92ceea91116e7b95d23eff634507fa2cff86ef2 -- 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 48902] [meta] 12.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=48902 Bug 48902 depends on bug 49297, which changed state. Bug 49297 Summary: [llvm-cov] Revert D85036 https://bugs.llvm.org/show_bug.cgi?id=49297 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48902] [meta] 12.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=48902 Bug 48902 depends on bug 49320, which changed state. Bug 49320 Summary: Cherry-pick JumpThreading noalias decl fix to 12.0.0 https://bugs.llvm.org/show_bug.cgi?id=49320 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49320] Cherry-pick JumpThreading noalias decl fix to 12.0.0
https://bugs.llvm.org/show_bug.cgi?id=49320 Tom Stellard changed: What|Removed |Added Fixed By Commit(s)|5e7e499b912d2c9ebaa91b5783c |5e7e499b912d2c9ebaa91b5783c |a123dbedeabcc |a123dbedeabcc da7fa7457800 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Tom Stellard --- Merged: da7fa7457800 -- 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 49324] New: The performance of some vector operator is worse than GCC
https://bugs.llvm.org/show_bug.cgi?id=49324 Bug ID: 49324 Summary: The performance of some vector operator is worse than GCC Product: libc++ Version: 8.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: 499537...@qq.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Created attachment 24563 --> https://bugs.llvm.org/attachment.cgi?id=24563&action=edit testcase clang++ -O2 test.cpp ./a,out g++ -O2 test.cpp ./a.out clang++ -v clang version 8.0.1 (based on LLVM 8.0.1) g++ -v gcc version 7.3.0 result for example: test clangxxO2/gxxO2 test_int8_t[data5(data.begin(), data.end())] 13.03 test_int8_t[data1.assign(1, 100)] 9.58 test_int8_t[data7.assign(data.begin(), data.end())] 18.81 We have other operator worse than GCC, like map and unordered_set. For vector assign, the main function consumed is __construct_range_forward. libcxx use the __construct_range_forward Each element is constructed using the construct method, which is constructed using the placement new method. GCC uses std::uninitialized_copy to copy the memory. The performance is significantly better than that of libcxx. see: https://bugs.llvm.org/show_bug.cgi?id=48893#add_comment -- 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 49325] New: changing the floating point environment interacts badly with interprocedural optimizations
https://bugs.llvm.org/show_bug.cgi?id=49325
Bug ID: 49325
Summary: changing the floating point environment interacts
badly with interprocedural optimizations
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: richard-l...@metafoo.co.uk
CC: llvm-bugs@lists.llvm.org
Testcase:
https://godbolt.org/z/E8Kje7
This example is miscompiled by reordering the call to f(j, a) between two
fesetround calls. There are at least two different bugs here (for the testcase
with inlining disabled and the testcase with inlining enabled):
1) With inlining disabled, the call to function f is reordered past a call to
function fesetround. 'f' is attributed as 'readnone' (plus 'willreturn
nounwind'), so this transform superficially appears correct, but is not: we
can't reorder a function that reads the FP environment past a function that
changes the FP environment (at least, not within a 'strictfp' function). It's
not clear to me whether it's wrong to mark 'f' as 'readnone', or whether we
should track the FP environment separately from reads of memory, but I suspect
the latter might be a better choice.
2) With inlining enabled, the inliner adds an 'fadd' instruction to 'g'. That's
wrong: 'fadd' can be freely reordered past function calls, but we certainly
don't want to allow 'fadd' to be reordered past a call to 'fesetround'. I think
the right approach here is that the inliner should produce constrained FP
intrinsic calls (assuming the default rounding mode) when inlining into a
'strictfp' function.
As a complementary problem to (2), we also have:
3) Inlining a constrained FP intrinsic call into a non-'strictfp' function
should convert the constrained FP intrinsic call into an unconstrained
instruction. This is important because we need to emit the libc++ wrapper
functions around C math functions as 'strictfp', and don't want that to be a
pessimization.
Right now:
#include
#pragma STDC FENV_ACCESS ON
float f() { return std::rint(10.5); }
... produces wrong results with Clang+libc++ (and also with Clang+libstdc++),
because std::rint is built with FENV_ACCESS OFF, so its call to rint is treated
as unconstrained. We could fix that by using FENV_ACCESS ON in libc++'s
wrapper, but that will pessimize all FENV_ACCESS OFF calls unless the
inliner is able to undo that when inlining into non-strictfp functions.
--
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 35637] Really bad codegen for libc++ vector
https://bugs.llvm.org/show_bug.cgi?id=35637 hiraditya changed: What|Removed |Added Status|NEW |RESOLVED CC||hiradi...@msn.com Resolution|--- |FIXED --- Comment #11 from hiraditya --- This bug is fixed with Eric's patch. clang trunk -O3 generates: ``` f1(): # @f1() pushr14 pushrbx pushrax mov rbx, rdi xorps xmm0, xmm0 movups xmmword ptr [rdi], xmm0 mov qword ptr [rdi + 16], 0 mov edi, 8294400 calloperator new(unsigned long) mov qword ptr [rbx], rax lea r14, [rax + 8294400] mov qword ptr [rbx + 16], r14 mov edx, 8294400 mov rdi, rax xor esi, esi callmemset@PLT mov qword ptr [rbx + 8], r14 mov rax, rbx add rsp, 8 pop rbx pop r14 ret f2(): # @f2() pushr15 pushr14 pushrbx mov edi, 24 calloperator new(unsigned long) mov r15, rax xorps xmm0, xmm0 movups xmmword ptr [rax], xmm0 mov qword ptr [rax + 16], 0 mov edi, 8294400 calloperator new(unsigned long) mov qword ptr [r15], rax mov rbx, rax add rbx, 8294400 mov qword ptr [r15 + 16], rbx mov edx, 8294400 mov rdi, rax xor esi, esi callmemset@PLT mov qword ptr [r15 + 8], rbx mov rax, r15 pop rbx pop r14 pop r15 ret mov r14, rax mov rdi, r15 calloperator delete(void*) mov rdi, r14 call_Unwind_Resume@PLT main: # @main xor eax, eax ret ``` -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49326] New: wrapper functions break functionality
https://bugs.llvm.org/show_bug.cgi?id=49326
Bug ID: 49326
Summary: wrapper functions break
functionality
Product: libc++
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: richard-l...@metafoo.co.uk
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Depends on: 49325
libc++'s wrapper functions are built in FENV_ACCESS OFF mode. This
means that LLVM will generate code for them assuming that they can only be
called in the default rounding mode. This causes calls to them in non-default
rounding modes to not work:
https://godbolt.org/z/zr4bdY
#include
#include
#include
#pragma STDC FENV_ACCESS ON
int main(void) {
auto default_rounding = std::fegetround();
std::fesetround(FE_UPWARD);
std::printf("%+4.1f", std::rint(10.5f));
std::fesetround(default_rounding);
}
... incorrectly prints '+10.0' when compiled with '-O2 -stdlib=libc++'.
Presumably we should define the wrapper functions in an FENV_ACCESS ON region.
In order for this to not introduce a performance regression, we'll presumably
need part (3) of #49325 fixed first.
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=49325
[Bug 49325] changing the floating point environment interacts badly with
interprocedural optimizations
--
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 31280 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-02-23 Type: Bug New issue 31280 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31280 Detailed Report: https://oss-fuzz.com/testcase?key=5035946661773312 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffd95d1fc68 Crash State: clang::DeclContext::lookup clang::DeclContext::using_directives UnqualUsingDirectiveSet::addUsingDirectives Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202101130625:202101140605 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5035946661773312 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 49327] New: Regression (12.0) Assertion `It->second == &Insn && "Cached first special instruction is wrong!"' failed.
https://bugs.llvm.org/show_bug.cgi?id=49327 Bug ID: 49327 Summary: Regression (12.0) Assertion `It->second == &Insn && "Cached first special instruction is wrong!"' failed. Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: b...@lindev.ch CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Trying to compile Python 3.9.2 with clang 12 (release branch as of 2021/02/23) with LTO enabled results in: ld: /home/bero/abf/llvm/BUILD/llvm-project-release-12.x/llvm/lib/Analysis/InstructionPrecedenceTracking.cpp:87: void llvm::InstructionPrecedenceTracking::validate(const llvm::BasicBlock *) const: Assertion `It->second == &Insn && "Cached first special instruction is wrong!"' failed. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /usr/bin/ld --build-id --eh-frame-hdr -m elf_x86_64 -shared -o libpython3.9.so.1.0 /usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.2.1/../../../../lib64/crti.o /usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.2.1/crtbeginS.o -L/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.2.1 -L/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.2.1/../../../../lib64 -L/usr/bin/../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/bin/../lib -L/lib -L/usr/lib -plugin /usr/bin/../lib64/LLVMgold.so -plugin-opt=mcpu=znver1 -plugin-opt=O3 -O2 -O2 -hlibpython3.9.so.1.0 Modules/getbuildinfo.o Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/token.o Parser/pegen/pegen.o Parser/pegen/parse.o Parser/pegen/parse_string.o Parser/pegen/peg_api.o Parser/myreadline.o Parser/parsetok.o Parser/tokenizer.o Objects/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/call.o Objects/capsule.o Objects/cellobject.o Objects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genericaliasobject.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/interpreteridobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/odictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Objects/picklebufobject.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/ast_opt.o Python/ast_unparse.o Python/bltinmodule.o Python/ceval.o Python/codecs.o Python/compile.o Python/context.o Python/dynamic_annotations.o Python/errors.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/hamt.o Python/hashtable.o Python/import.o Python/importdl.o Python/initconfig.o Python/marshal.o Python/modsupport.o Python/mysnprintf.o Python/mystrtoul.o Python/pathconfig.o Python/peephole.o Python/preconfig.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pyhash.o Python/pylifecycle.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/bootstrap_hash.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/thread.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/pystrhex.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/dynload_shlib.o Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/_weakref.o Modules/_functoolsmodule.o Modules/_operator.o Modules/_collectionsmodule.o Modules/_abc.o Modules/itertoolsmodule.o Modules/atexitmodule.o Modules/signalmodule.o Modules/_stat.o Modules/timemodule.o Modules/_threadmodule.o Modules/_localemodule.o Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o Modules/faulthandler.o Modules/_tracemalloc.o Modules/_peg_parser.o Modules/symtablemodule.o Modules/xxsubtype.o Python/frozen.o -lcrypt -lintl -lpthread -ldl -lutil -lm -lm -u__llvm_profile_runtime /usr/lib64/clang/12.0.0/lib/linux/libclang_rt.profile-x86_64.a -lgcc --as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.2.1/crtendS.o /usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.2.1/../../../../lib64/crtn.o
[llvm-bugs] [Bug 46294] compiler-rt soft float support guarded by the wrong macro ( __SOFT_FP__ instead of __SOFTFP__)
https://bugs.llvm.org/show_bug.cgi?id=46294 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||i...@maskray.me --- Comment #1 from Fangrui Song --- Fixed by 18035991cdbbc24aba9ca4c7168cc0cf60d90c31 (target: 13.0.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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46628] check-builtins fails on musl libc system
https://bugs.llvm.org/show_bug.cgi?id=46628 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||i...@maskray.me --- Comment #1 from Fangrui Song --- Fixed by 99d650b3699eaf23adcff6b28ebbc7ec4b890b3b [compiler-rt][test] Make glibc-* feature detection work on a musl distribution -- 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
