[llvm-bugs] [Bug 44853] New: -mno-save-restore spams a RISCV Linux kernel build
https://bugs.llvm.org/show_bug.cgi?id=44853 Bug ID: 44853 Summary: -mno-save-restore spams a RISCV Linux kernel build Product: clang Version: trunk Hardware: Other OS: All Status: NEW Severity: enhancement Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: natechancel...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk When building the Linux kernel for RISCV, there is a bunch of warning spam around -mno-save-restore, which is explicitly specified in arch/riscv/Makefile. $ make -j$(nproc) -s ARCH=riscv CC=clang-11 CROSS_COMPILE=riscv64-linux-gnu- O=out.riscv distclean defconfig all ... '-save-restore' is not a recognized feature for this target (ignoring feature) '-save-restore' is not a recognized feature for this target (ignoring feature) '-save-restore' is not a recognized feature for this target (ignoring feature) '-save-restore' is not a recognized feature for this target (ignoring feature) ... I assume this warning is coming from the backend since -msave-restore warns from clang. $ echo | clang-11 --target=riscv64-linux-gnu -msave-restore -c -x c -o /dev/null - clang: warning: the clang compiler does not support '-msave-restore' '+save-restore' is not a recognized feature for this target (ignoring feature) $ echo | clang-11 --target=riscv64-linux-gnu -mno-save-restore -c -x c -o /dev/null - '-save-restore' is not a recognized feature for this target (ignoring feature) This warning happens on every translation unit so it is very noisy. We could silence it by just not passing -mno-save-restore when building with clang but that seems fragile in case -msave-restore ever became default. We’ll do whatever you feel is best though. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44588] [InstCombine] icmp not pushed through shufflevector
https://bugs.llvm.org/show_bug.cgi?id=44588 Nikita Popov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||87f6314f8cd1fd5bb0ce04eff6c ||5843529c6ab53, ||e086e23024e4fb202628e988f69 ||1c158eebf095c --- Comment #3 from Nikita Popov --- This has been fixed by https://reviews.llvm.org/D73575 and https://reviews.llvm.org/D73647. -- 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 3082] loop-extractor infinite memory usage
https://bugs.llvm.org/show_bug.cgi?id=3082 Ehud Katz changed: What|Removed |Added Status|CONFIRMED |RESOLVED Fixed By Commit(s)||rG3b70ee27a503 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 8929] loop extract isn't a well behaved function pass
https://bugs.llvm.org/show_bug.cgi?id=8929 Ehud Katz changed: What|Removed |Added Fixed By Commit(s)||rG3b70ee27a503 Status|CONFIRMED |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 44854] New: -fPIC causes issues with building the Linux kernel
https://bugs.llvm.org/show_bug.cgi?id=44854
Bug ID: 44854
Summary: -fPIC causes issues with building the Linux kernel
Product: libraries
Version: trunk
Hardware: Other
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: RISC-V
Assignee: unassignedb...@nondot.org
Reporter: natechancel...@gmail.com
CC: a...@lowrisc.org, llvm-bugs@lists.llvm.org
Attempting to build a Linux kernel with tip of tree results in an assembler
error in fs/nfs/flexfilelayout/flexfilelayout.o:
$ make -j$(nproc) ARCH=riscv CC=clang-11 CROSS_COMPILE=riscv64-linux-gnu-
HOSTCC=clang-11 O=/out.riscv distclean defconfig
fs/nfs/flexfilelayout/flexfilelayout.o
...
/tmp/flexfilelayout-143baf.s: Assembler messages:
[0/99810]
/tmp/flexfilelayout-143baf.s:37: Error: bad expression
/tmp/flexfilelayout-143baf.s:37: Error: illegal operands `auipc
a0,%got_pcrel_hi(kmalloc_caches)'
/tmp/flexfilelayout-143baf.s:232: Error: bad expression
/tmp/flexfilelayout-143baf.s:232: Error: illegal operands `auipc
a2,%got_pcrel_hi(kmalloc_caches)'
/tmp/flexfilelayout-143baf.s:359: Error: bad expression
/tmp/flexfilelayout-143baf.s:359: Error: illegal operands `auipc
a0,%got_pcrel_hi(mem_map)'
/tmp/flexfilelayout-143baf.s:367: Error: bad expression
/tmp/flexfilelayout-143baf.s:367: Error: illegal operands `auipc
a2,%got_pcrel_hi(pfn_base)'
/tmp/flexfilelayout-143baf.s:374: Error: bad expression
/tmp/flexfilelayout-143baf.s:374: Error: illegal operands `auipc
a3,%got_pcrel_hi(va_pa_offset)'
/tmp/flexfilelayout-143baf.s:429: Error: bad expression
/tmp/flexfilelayout-143baf.s:429: Error: illegal operands `auipc
a1,%got_pcrel_hi(kmalloc_caches)'
/tmp/flexfilelayout-143baf.s:478: Error: bad expression
/tmp/flexfilelayout-143baf.s:478: Error: illegal operands `auipc
a0,%got_pcrel_hi(kmalloc_caches)'
/tmp/flexfilelayout-143baf.s:755: Error: bad expression
/tmp/flexfilelayout-143baf.s:755: Error: illegal operands `auipc
a0,%got_pcrel_hi(init_user_ns)'
/tmp/flexfilelayout-143baf.s:797: Error: bad expression
/tmp/flexfilelayout-143baf.s:797: Error: illegal operands `auipc
a0,%got_pcrel_hi(init_user_ns)'
/tmp/flexfilelayout-143baf.s:1702: Error: bad expression
/tmp/flexfilelayout-143baf.s:1702: Error: illegal operands `auipc
a0,%got_pcrel_hi(kmalloc_caches)'
/tmp/flexfilelayout-143baf.s:1777: Error: bad expression
/tmp/flexfilelayout-143baf.s:1777: Error: illegal operands `auipc
a1,%got_pcrel_hi(kmalloc_caches)'
/tmp/flexfilelayout-143baf.s:3291: Error: bad expression
/tmp/flexfilelayout-143baf.s:3291: Error: illegal operands `auipc
a2,%got_pcrel_hi(__per_cpu_offset)'
/tmp/flexfilelayout-143baf.s:3599: Error: bad expression
/tmp/flexfilelayout-143baf.s:3599: Error: illegal operands `auipc
a1,%got_pcrel_hi(layoutstats_timer)'
/tmp/flexfilelayout-143baf.s:4219: Error: bad expression
/tmp/flexfilelayout-143baf.s:4219: Error: illegal operands `auipc
a1,%got_pcrel_hi(layoutstats_timer)'
/tmp/flexfilelayout-143baf.s:4718: Error: bad expression
/tmp/flexfilelayout-143baf.s:4718: Error: illegal operands `auipc
a1,%got_pcrel_hi(layoutstats_timer)'
/tmp/flexfilelayout-143baf.s:5644: Error: bad expression
/tmp/flexfilelayout-143baf.s:5644: Error: illegal operands `auipc
a3,%got_pcrel_hi(mem_map)'
/tmp/flexfilelayout-143baf.s:5654: Error: bad expression
/tmp/flexfilelayout-143baf.s:5654: Error: illegal operands `auipc
a2,%got_pcrel_hi(pfn_base)'
/tmp/flexfilelayout-143baf.s:5661: Error: bad expression
/tmp/flexfilelayout-143baf.s:5661: Error: illegal operands `auipc
a3,%got_pcrel_hi(va_pa_offset)'
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)
...
I narrowed it down to the use of -fPIC, which is used with kernel modules:
https://elixir.bootlin.com/linux/v5.5.2/source/arch/riscv/Makefile#L16
creduce spits out:
$ cat flexfilelayout.i
a() { b(a); }
$ cat test.sh
clang-11 --target=riscv64-linux-gnu --prefix=/usr/bin/ --gcc-toolchain=/usr
-no-integrated-as -mabi=lp64 -march=rv64imac -mcmodel=medany -O2 -c -o /
dev/null flexfilelayout.i || exit ${?}
! clang-11 --target=riscv64-linux-gnu --prefix=/usr/bin/ --gcc-toolchain=/usr
-no-integrated-as -mabi=lp64 -march=rv64imac -mcmodel=medany -O2 -fPIC
-c -o /dev/null flexfilelayout.i
Full preprocessed file available here:
https://gist.gi
[llvm-bugs] [Bug 44855] New: Combining a pointer to array of const TYPE with an otherwise size-compatible array of TYPE should work and yield only a _pedantic_ warning
https://bugs.llvm.org/show_bug.cgi?id=44855
Bug ID: 44855
Summary: Combining a pointer to array of const TYPE with an
otherwise size-compatible array of TYPE should work
and yield only a _pedantic_ warning
Product: clang
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: psko...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
C++ allows e.g., combining (int const(*)[100])x with (int (*)[100])y as in
0? (int(*)[100])0 : (int const(*)[100])0
yielding an expression of type int const(*)[100].
The C standard technically disallows this (could be considered a defect in the
standard) but this kind of combining/conversion is completely harmless and so
GCC only warns about it under -pedantic.
Consequently, under GCC, it is possible to disable these warnings by enclosing
the "offending" code snippets in (__extension__({ ;}).
This doesn't work on clang, because the above elicits a full (rather than just
a pedantic) warning on clang.
Furthermore, the combined type on clang is void* rather than int(*)[100].
The gcc behavior is more useful.
Some examples with comments at: https://gcc.godbolt.org/z/e7sXdB
--
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 20606 in oss-fuzz: llvm:clang-fuzzer: Null-dereference READ in clang::Sema::getDestructorName
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-02-09 Type: Bug New issue 20606 by ClusterFuzz-External: llvm:clang-fuzzer: Null-dereference READ in clang::Sema::getDestructorName https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20606 Detailed Report: https://oss-fuzz.com/testcase?key=5718571042996224 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x0008 Crash State: clang::Sema::getDestructorName clang::Parser::ParseUnqualifiedId clang::Parser::tryParseCXXIdExpression Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202002070552:202002090525 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5718571042996224 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 44856] New: Illegal Instruction on startup from gn if built with clang on armv7hnl-linux
https://bugs.llvm.org/show_bug.cgi?id=44856 Bug ID: 44856 Summary: Illegal Instruction on startup from gn if built with clang on armv7hnl-linux Product: new-bugs Version: 10.0 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 Building gn (http://gn.googlesource.com/) with clang results in a crash on startup (Illegal Instruction) on armv7hnl. It works on any other architecture and on armv7hnl with gcc instead of clang. To reproduce (no reduced test case yet): git clone https://gn.googlesource.com/gn cd gn export CC=clang export CXX=clang++ python build/gen.py --no-static-libstdc++ ninja -C out out/gn_unittests [Illegal Instruction on armv7hnl, success everywhere else] git clone https://gn.googlesource.com/gn cd gn export CC=gcc export CXX=g++ python build/gen.py --no-static-libstdc++ ninja -C out out/gn_unittests [works] -- 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 44857] New: -Wctad-maybe-unsupported fires on move_iterator
https://bugs.llvm.org/show_bug.cgi?id=44857
Bug ID: 44857
Summary: -Wctad-maybe-unsupported fires on move_iterator
Product: libc++
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: arthur.j.odw...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
// https://godbolt.org/z/acPvrB
When manually enabling `-Wctad-maybe-unsupported` on the command line:
:10:17: warning: 'move_iterator' may not intend to support class
template argument deduction [-Wctad-maybe-unsupported]
std::sample(std::move_iterator(in.begin()), std::move_iterator(in.end()),
std::back_inserter(out),
^
/opt/compiler-explorer/clang-trunk-20200209/bin/../include/c++/v1/iterator:1187:28:
note: add a deduction guide to suppress this warning
class _LIBCPP_TEMPLATE_VIS move_iterator
^
My impression is that `move_iterator` is one of those classes that's pretty
much always safe to use with CTAD. I mean it's even safer than `vector`, unless
I'm missing something, because an "vector of vector" is a different beast from
a regular "vector", but a "move iterator of move iterator" is almost
indistinguishable from a "move iterator."
So it seems backwards that Clang would issue no warning on `vector{v}` but
issue a bogus warning on `move_iterator(it)`.
(I would still like to see a general-purpose `-Wctad` analogous to `-Wvla`, but
if `-Wctad-maybe-unsupported` is going to exist, then it shouldn't warn on
`move_iterator`. I also would not object to just removing
`-Wctad-maybe-unsupported`; I'm not aware that it warns on anything I care
about, and vice versa it fails to warn on all the STL things I do care about,
such as `vector` and `optional` and `pair`. I also noticed today that it
doesn't warn on `uniform_int_distribution`, and I'm not sure yet how I feel
about that.)
--
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 44858] New: Load register with negative immediate leads to 'invalid instruction'
https://bugs.llvm.org/show_bug.cgi?id=44858 Bug ID: 44858 Summary: Load register with negative immediate leads to 'invalid instruction' Product: libraries Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: ste...@agner.ch CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org, ties.st...@arm.com Created attachment 23111 --> https://bugs.llvm.org/attachment.cgi?id=23111&action=edit reproducer assembly Trying to use Encoding T4 of LDR (immediate, Thumb) which allows a negative immediate leads to `invalid instruction`: $ llvm-mc -triple=armv7-linux-gnueabi repr-wrong-selection.s .text .code 16 .globl _start _start: repr-wrong-selection.s:6:2: error: invalid instruction ldr.w r3, [r1, #-4]! ^ -- 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 44858] Load register with negative immediate leads to 'invalid instruction'
https://bugs.llvm.org/show_bug.cgi?id=44858 Eli Friedman changed: What|Removed |Added CC||efrie...@quicinc.com Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Eli Friedman --- LLVM understands the instruction, it's just getting confused by the ".w" suffix. *** This bug has been marked as a duplicate of bug 43382 *** -- 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 44859] New: apt.llvm.org uses weekdays instead of months
https://bugs.llvm.org/show_bug.cgi?id=44859 Bug ID: 44859 Summary: apt.llvm.org uses weekdays instead of months Product: Website Version: unspecified Hardware: Other OS: All Status: NEW Severity: enhancement Priority: P Component: General Website Assignee: unassignedb...@nondot.org Reporter: pavel.kryu...@phystech.edu CC: llvm-bugs@lists.llvm.org, m...@sqlby.me Currently News section of https://apt.llvm.org/ has: > Fri 23th 2020 - Snapshot becomes 11, branch 10 created > Sun 19th 2020 - Ubuntu Cosmic removed (EOL) > Oct 30th 2019 - Ubuntu Eoan (19.10) support > Aug 20th 2019 - Ubuntu Trusty removed (EOL) > Aug 01th 2019 - Snapshot becomes 10, branch 9 created Fri and Sun should be replaced with Jan -- 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 44860] New: Function symbol from assembler misses lowest bit set in Thumb mode
https://bugs.llvm.org/show_bug.cgi?id=44860 Bug ID: 44860 Summary: Function symbol from assembler misses lowest bit set in Thumb mode Product: libraries Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: ste...@agner.ch CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org, ties.st...@arm.com Created attachment 23113 --> https://bugs.llvm.org/attachment.cgi?id=23113&action=edit reproducer assembly Using the .type directive to mark a label as a function in Thumb mode does not get the correct symbol table entry. .syntax unified .text .thumb __setup_mmu: it ne blne __setup_mmu .type __setup_mmu, %function // Move this line before __setup_mmu for correct behaviour. llvm-mc --triple=armv7a-linux-gnueabihf blne.s -filetype=obj -o blne.o --arm-add-build-attributes llvm-readelf --symbols blne.o Symbol table '.symtab' contains 3 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 NOTYPE LOCAL DEFAULT 2 $t.0 2: 0 FUNCLOCAL DEFAULT 2 __setup_mmu This has been observed when trying to build Linux for 32-bit ARM in Thumb2 mode. When the object file gets linked, the linker inserts a blx instruction which switches the CPU instruction set... -- 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 44810] clang-cl (10.0.0-rc1) + MsBuild = memory hog
https://bugs.llvm.org/show_bug.cgi?id=44810 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED CC||r...@google.com Resolution|--- |DUPLICATE --- Comment #2 from Reid Kleckner --- I think this is a dupe of 44823, and we have some existing discussion of the issue there. Thanks for the report! *** This bug has been marked as a duplicate of bug 44823 *** -- 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 20610 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable
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-02-10 Type: Bug New issue 20610 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20610 Detailed Report: https://oss-fuzz.com/testcase?key=5188660863696896 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc226dce08 Crash State: clang::DiagnosticIDs::isUnrecoverable clang::DiagnosticIDs::ProcessDiag clang::DiagnosticsEngine::EmitCurrentDiagnostic Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202002070552:202002090525 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5188660863696896 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 20611 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: !SCEVCheckBlock->getParent()->hasOptSize() && "Cannot SCEV check stride or overf
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-02-10 Type: Bug New issue 20611 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: !SCEVCheckBlock->getParent()->hasOptSize() && "Cannot SCEV check stride or overf https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20611 Detailed Report: https://oss-fuzz.com/testcase?key=5690197763424256 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-loop_vectorize Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !SCEVCheckBlock->getParent()->hasOptSize() && "Cannot SCEV check stride or overf llvm::InnerLoopVectorizer::emitSCEVChecks llvm::InnerLoopVectorizer::createVectorizedLoopSkeleton Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201908010319:201908020315 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5690197763424256 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 44861] New: InstCombine incorrectly rewrites indices of gep inbounds
https://bugs.llvm.org/show_bug.cgi?id=44861
Bug ID: 44861
Summary: InstCombine incorrectly rewrites indices of gep
inbounds
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: juneyoung@sf.snu.ac.kr
CC: llvm-bugs@lists.llvm.org
```
$ cat input.ll
declare void @g(i8*)
define void @foo(i8* %ptr, i1 %cc1, i1 %cc2, i1 %cc3, i32 %arg) {
entry:
br i1 %cc1, label %do.end, label %if.then
if.then:
br i1 %cc2, label %do.body, label %do.end
do.body:
%phi = phi i32 [ %arg, %if.then ]
%phi.ext = zext i32 %phi to i64
%ptr2 = getelementptr inbounds i8, i8* %ptr, i64 %phi.ext
%ptr3 = getelementptr inbounds i8, i8* %ptr2, i64 -1
call void @g(i8* %ptr3)
br i1 %cc3, label %do.end, label %if.then
do.end:
ret void
}
$ opt -instcombine -S -o - input.ll
declare void @g(i8*)
define void @foo(i8* %ptr, i1 %cc1, i1 %cc2, i1 %cc3, i32 %arg) {
br i1 %cc1, label %do.end, label %if.then
if.then: ; preds = %do.body, %entry
br i1 %cc2, label %do.body, label %do.end
do.body: ; preds = %if.then
%phi.ext = zext i32 %arg to i64
%ptr2 = getelementptr inbounds i8, i8* %ptr, i64 -1
%ptr3 = getelementptr inbounds i8, i8* %ptr2, i64 %phi.ext
call void @g(i8* nonnull %ptr3)
br i1 %cc3, label %do.end, label %if.then
do.end: ; preds = %do.body, %if.then,
%entry
ret void
}
```
If %arg is 1, ptr3 in the source is `gep inb (gep inb ptr, 1), -1` whereas ptr3
in the target is `gep inb (gep inb ptr, -1), 1`.
This is incorrect because ptr3 in the tgt may be poison whereas ptr3 in the
source isn'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] [Bug 26580] Copy relocation against protected symbol doesn't work
https://bugs.llvm.org/show_bug.cgi?id=26580
Fangrui Song changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW |RESOLVED
CC||i...@maskray.me
--- Comment #22 from Fangrui Song ---
The original issue is "Copy relocation against protected symbol doesn't work".
I agree with Rich Felker (https://gcc.gnu.org/ml/gcc/2016-04/msg00168.html) and
Cary Coutant (https://sourceware.org/ml/binutils/2016-03/msg00407.html
https://gcc.gnu.org/ml/gcc/2016-04/msg00158.html
https://gcc.gnu.org/ml/gcc/2016-04/msg00169.html) that we should
keep using direct access against protected symbols and disallow copy
relocations against protected symbols.
I appreciate that Cary Coutant and Rafael Ávila de Espíndola added diagnostics
to gold and lld, respectively:
gold (https://sourceware.org/bugzilla/show_bug.cgi?id=19823)
lld (https://bugs.llvm.org/show_bug.cgi?id=31476)
And I hope the following resolutions could be reworked:
GCC 5 x86-64 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248)
i386 was flagged as a reproduce
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55012)
__attribute__((visibility("protected"))) int a;
int foo() { return a; } // GCC>=5 uses R_X86_64_GOTPCREL/R_X86_64_REX_GOTPCRELX
instead of R_X86_64_PC32
binutils 2.26: R_X86_64_PC32 can no longer be used against a protected symbol
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=ca3fe95e469b9daec153caa2c90665f5daaec2b5
--
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 44862] New: Multiple libomp tests failing after 4fe839ef3a51e0ea2e72ea2f8e209790489407a2
https://bugs.llvm.org/show_bug.cgi?id=44862 Bug ID: 44862 Summary: Multiple libomp tests failing after 4fe839ef3a51e0ea2e72ea2f8e209790489407a2 Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: lukebe...@hotmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org When building clang with $ cmake -DLLVM_ENABLE_PROJECTS='clang;openmp' -DCMAKE_BUILD_TYPE=Release -G "Unix Makefiles" ../llvm && make check-all -j4 on Linux x86, 90+ libomp tests failing tests are failing after https://github.com/llvm/llvm-project/commit/4fe839ef3a51e0ea2e72ea2f8e209790489407a2 [CMake] Rename EXCLUDE_FROM_ALL and make it an argument to add_lit_testsuite Failing Tests (90): Clang :: Driver/crash-report.c libomp :: affinity/format/api.c libomp :: affinity/format/api2.c libomp :: affinity/format/fields_values.c libomp :: affinity/format/nested.c libomp :: affinity/format/nested2.c libomp :: api/has_openmp.c libomp :: api/kmp_aligned_malloc.c libomp :: api/omp_alloc_def_fb.c libomp :: api/omp_alloc_hbw.c libomp :: api/omp_alloc_null_fb.c libomp :: api/omp_get_num_devices.c libomp :: api/omp_get_num_threads.c libomp :: api/omp_get_wtime.c libomp :: api/omp_in_parallel.c libomp :: env/kmp_set_dispatch_buf.c libomp :: env/omp_target_offload.c libomp :: env/omp_wait_policy.c libomp :: flush/omp_flush.c libomp :: lock/omp_init_lock.c libomp :: lock/omp_lock.c libomp :: misc_bugs/stack-propagate.c libomp :: misc_bugs/teams-no-par.c libomp :: ompt/cancel/cancel_parallel.c libomp :: ompt/cancel/cancel_taskgroup.c libomp :: ompt/loadtool/tool_available/tool_available.c libomp :: ompt/loadtool/tool_available/tool_available.c libomp :: ompt/loadtool/tool_available/tool_available.c libomp :: ompt/loadtool/tool_available_search/tool_available_search.c libomp :: ompt/loadtool/tool_not_available/tool_not_available.c libomp :: ompt/loadtool/tool_not_available/tool_not_available.c libomp :: ompt/misc/api_calls_from_other_thread.cpp libomp :: ompt/misc/finalize_tool.c libomp :: ompt/misc/interoperability.cpp libomp :: ompt/misc/threads_nested.c libomp :: ompt/misc/unset_callback.c libomp :: ompt/parallel/dynamic_enough_threads.c libomp :: ompt/parallel/dynamic_not_enough_threads.c libomp :: ompt/parallel/max_active_levels_serialized.c libomp :: ompt/parallel/nested.c libomp :: ompt/parallel/nested.c libomp :: ompt/parallel/nested_lwt.c libomp :: ompt/parallel/nested_serialized.c libomp :: ompt/parallel/no_thread_num_clause.c libomp :: ompt/parallel/no_thread_num_clause.c libomp :: ompt/parallel/parallel_if0.c libomp :: ompt/parallel/serialized.c libomp :: ompt/synchronization/barrier/explicit.c libomp :: ompt/synchronization/barrier/for_loop.c libomp :: ompt/synchronization/barrier/parallel_region.c libomp :: ompt/synchronization/barrier/single.c libomp :: ompt/synchronization/critical.c libomp :: ompt/synchronization/flush.c libomp :: ompt/synchronization/master.c libomp :: ompt/synchronization/nest_lock.c libomp :: ompt/synchronization/ordered.c libomp :: ompt/synchronization/reduction/empty_reduce.c libomp :: ompt/synchronization/reduction/empty_reduce.c libomp :: ompt/synchronization/reduction/tree_reduce.c libomp :: ompt/synchronization/reduction/tree_reduce.c libomp :: ompt/synchronization/taskgroup.c libomp :: ompt/synchronization/test_lock.c libomp :: ompt/synchronization/test_nest_lock_parallel.c libomp :: ompt/tasks/explicit_task.c libomp :: ompt/tasks/task_in_joinbarrier.c libomp :: ompt/tasks/task_memory.c libomp :: ompt/tasks/task_types.c libomp :: ompt/tasks/taskyield.c libomp :: ompt/teams/serial_teams.c libomp :: ompt/worksharing/for/auto_serialized.c libomp :: ompt/worksharing/for/auto_split.c libomp :: ompt/worksharing/for/dynamic.c libomp :: ompt/worksharing/for/dynamic_serialized.c libomp :: ompt/worksharing/for/dynamic_split.c libomp :: ompt/worksharing/for/guided_serialized.c libomp :: ompt/worksharing/for/guided_split.c libomp :: ompt/worksharing/for/runtime.c libomp :: ompt/worksharing/for/runtime_split.c libomp :: ompt/worksharing/for/runtime_split.c libomp :: parallel/omp_nested.c libomp :: parallel/omp_parallel_copyin.c libomp :: parallel/omp_parallel_default.c libomp :: parallel/omp_parallel_firstprivate.c libomp :: parallel/omp_parallel_if.c libomp :: parallel/omp_parallel_private.c libomp :: tasking/bug_nested_proxy_task.c libomp :: tasking/bug_proxy_task_dep_waitin
