[llvm-bugs] [Bug 48984] New: Failure to optimize out low bits of result of left shift of constant
https://bugs.llvm.org/show_bug.cgi?id=48984
Bug ID: 48984
Summary: Failure to optimize out low bits of result of left
shift of constant
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
int f(int a)
{
return ((2 << a) & 1) == 0;
}
This can be optimized to `return 1;`. This transformation is done by GCC, but
by LLVM.
Godbolt comparison here: https://godbolt.org/z/dTfsbx
alive2 check here: https://alive2.llvm.org/ce/z/U3DMgJ
--
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 48986] New: thread_limit clause on target directive not supported
https://bugs.llvm.org/show_bug.cgi?id=48986
Bug ID: 48986
Summary: thread_limit clause on target directive not supported
Product: OpenMP
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: tom.dea...@bristol.ac.uk
CC: llvm-bugs@lists.llvm.org
The `thread_limit` clause is not supported on the `target` directive.
This is a valid clause in OpenMP 5.1, but the top of LLVM 12 currently emits
this error:
Code:
#include
int main(void) {
int A[16];
#pragma omp target thread_limit(16)
#pragma omp teams distribute parallel for
for (int i = 0; i < 16; ++i)
A[i] = i;
printf("A[15]=%d\n", A[15]);
return 0;
}
Compile:
$ clang -O3 -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda -Xopenmp-target
-march=sm_75 omp_target_thread_limit.c
Output:
omp_target_thread_limit.c:7:22: error: unexpected OpenMP clause 'thread_limit'
in directive '#pragma omp target'
#pragma omp target thread_limit(16)
^
1 error generated.
--
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 48987] New: Data race during the creation of the predefined units 5 and 6
https://bugs.llvm.org/show_bug.cgi?id=48987 Bug ID: 48987 Summary: Data race during the creation of the predefined units 5 and 6 Product: flang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Runtime Assignee: unassignedb...@nondot.org Reporter: rofir...@gmail.com CC: david.tr...@arm.com, llvm-bugs@lists.llvm.org, sscalp...@nvidia.com, tke...@nvidia.com Created attachment 24470 --> https://bugs.llvm.org/attachment.cgi?id=24470&action=edit Delay setting unitMap until predefined units have been fully initialised Hi, function `ExternalFileUnit::GetUnitMap` in unit.cpp uses a CriticalSection RAII object to serialise the initialisation of the unit map. However it sets the global `unitMap` variable too early before the initialisation of the predefined units 6 (stdout) and 5 (stdin). In machines with lots of cores (we've been able to reproduce this in a 32-core machine) threads printing for the first time in parallel may observe the predefined units before they are fully initialised. The observed failure is that a function like `BeginExternalListOutput` invokes `SetDirection`. When using a `PRINT` statement this uses the default unit which `BeginExternaListOutput` will map to the unit id 6. SetDirection checks that the requested direction makes sense. E.g. for unit 6 this is "mayWrite()", however because the unit 6 has not been fully initialised yet the check returns false and an error is signaled. The attached patch keeps the unit map in a local variable once the predefined units have been initialized. Because `ExternalFileUnit::CreateNew` invokes `ExternalFileUnit::GetUnitMap` that would immediately lead to deadlock. We overloaded `CreateNew` to received the `UnitMap*` and avoid the deadlock. We can't see other calls to `CreateNew` in the code as it is now so the overload may not bee needed, but we are not sure if other calls to `CreateNew` may be needed in the future. I am not sure what is the policy at the moment, but I understand that we can proceed with a patch in phabricator for flang (not sure if this would impacts plans regarding fir-dev). -- 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 48988] New: Frontend crash delete constexpr
https://bugs.llvm.org/show_bug.cgi?id=48988
Bug ID: 48988
Summary: Frontend crash delete constexpr
Product: clang
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: golka.ger...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Here is a very simple piece of code that crashes on Clang 11.0 and 11.0.1:
constexpr int foo() {
delete NONEXSISTING_PTR;
return 5;
}
Reproducible example: https://godbolt.org/z/Ec7saK
Obviously no one will write such a code, but still the compiler shouldn't
crash.
--
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 48989] New: [LV] Fix crash when computing max VF too early
https://bugs.llvm.org/show_bug.cgi?id=48989 Bug ID: 48989 Summary: [LV] Fix crash when computing max VF too early Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: cullen.rho...@arm.com CC: llvm-bugs@lists.llvm.org Blocks: 48902 Fix: https://reviews.llvm.org/D94869 Commit: 8cda227 Needs cherry-picking onto 12.x release branch 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 41784] volatile copy assignment operator for std::atomic
https://bugs.llvm.org/show_bug.cgi?id=41784 Louis Dionne changed: What|Removed |Added CC||ldio...@apple.com Fixed By Commit(s)||c448ea948c28878735fefec734d ||8326ca2e4b33a Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Louis Dionne --- Should be fixed by https://reviews.llvm.org/D90968: commit c448ea948c28878735fefec734d8326ca2e4b33a Author: Ruslan Arutyunyan Date: Mon Feb 1 10:12:09 2021 -0500 [libc++] Fix for the Bug 41784 Add deleted volatile copy-assignment operator in the most derived atomic to fix the Bug 41784. The root cause: there is an `operator=(T) volatile` that has better match than the deleted copy-assignment operator of the base class when `this` is `volatile`. The compiler sees that right operand of the assignment operator can be converted to `T` and chooses that path without taking into account the deleted copy-assignment operator of the base class. The current behavior on libstdc++ is different from what we have in libc++. On the same test compilation fails with libstdc++. Proof: https://godbolt.org/z/nebPYd (everything is the same except the -stdlib option). I choose the way with explicit definition of copy-assignment for atomic in the most derived class. But probably we can fix that by moving `operator=(T)` overloads to the base class from both specializations. At first glance, it shouldn't break anything. Differential Revision: https://reviews.llvm.org/D90968 -- 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 48343] [InstCombine] Miscompile of sext(ashr(shl(trunc())))
https://bugs.llvm.org/show_bug.cgi?id=48343 Simon Pilgrim changed: What|Removed |Added Blocks|47800 | Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Simon Pilgrim --- Resolving - we're unlikely to perform any more (non-critical0 11.x releases and this fix is already in the 12.x release branch. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=47800 [Bug 47800] [meta] 11.0.1 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 48774] Improper "No explicit type declared for" error
https://bugs.llvm.org/show_bug.cgi?id=48774 Peter Klausler changed: What|Removed |Added CC||pklaus...@nvidia.com Status|NEW |RESOLVED Assignee|unassignedb...@nondot.org |pklaus...@nvidia.com Fixed By Commit(s)||46dadb65bc28e8706d4bb8664cc ||49ac52dc32e65 Resolution|--- |FIXED --- Comment #1 from Peter Klausler --- Fixed by disabling the old style PARAMETER statement by default. -- 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 48988] Frontend crash delete nonexisting pointer in constexpr function
https://bugs.llvm.org/show_bug.cgi?id=48988 Florian Hahn changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Florian Hahn --- This also appears fixed on the 12.x release branch. I could not reproduce the crash with clang version 12.0.0 (g...@github.com:llvm/llvm-project.git 07dc51637cc419cbd61383eb4e26713a8f931806) Please re-open in case there is a variation of the reproducer that causes a crash on current trunk. -- 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 48990] New: Unable to build on Power9 with 12.0.0-rc1
https://bugs.llvm.org/show_bug.cgi?id=48990
Bug ID: 48990
Summary: Unable to build on Power9 with 12.0.0-rc1
Product: new-bugs
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: release blocker
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: albionl...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Created attachment 24472
--> https://bugs.llvm.org/attachment.cgi?id=24472&action=edit
Build log for Power9 Ubuntu
Building 12.0.0-rc1, stage 2 on Power9 with RHEL and Ubuntu produces the
following (and similar errors, see attachment):
/home/conanap/12rc1/stage2/build/include/c++/v1/math.h:463:12: error: expected
'(' for function-style cast or type construction
return isinf(__lcpp_x);
^~~
/usr/include/math.h:661:20: note: expanded from macro 'isinf'
# define isinf(x) __MATH_TG ((x), __isinf, (x))
^
/usr/include/math.h:546:54: note: expanded from macro '__MATH_TG'
(__builtin_types_compatible_p (__typeof (TG_ARG), float), \
...
--
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 48141] LICM cannot sink stores out of loops when address calculation is a bit complicated
https://bugs.llvm.org/show_bug.cgi?id=48141 listm...@philipreames.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from listm...@philipreames.com --- Should be resolved. Please reopen if original test case is found not to be handled. For related test cases, please open a new bug and link to them in a comment on this one. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48991] New: Possible bugs in X86_64 assembler
https://bugs.llvm.org/show_bug.cgi?id=48991 Bug ID: 48991 Summary: Possible bugs in X86_64 assembler Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: MC Assignee: unassignedb...@nondot.org Reporter: kobalicek.p...@gmail.com CC: llvm-bugs@lists.llvm.org I'm trying to compare LLVM assembler with AsmJit and I have found few cases that I would like to report. I'm using LLVM build from main branch and llvm-mc tool, which is called like this for each supported instruction: """ echo "--Instruction String--" | llvm-mc --arch=x86-64 -x86-asm-syntax=intel -show-encoding -output-asm-variant=1 """ Here is a list of instructions that I think LLVM encodes wrongly: [1] "lcall tbyte ptr [rcx+rdx]" encodes as "FF1C11" (FWORD PTR) although it should be "48FF1C11" (TBYTE PTR). [2] "vextractps ecx, xmm2, 1" encodes as "62F37D0817D101" (AVX512) although it should be "C4E37917D101" (AVX). Here is a list of instructions that I think have wrong size of memory operands: [3] "clrssbsy qword ptr [m64]" - LLVM wants "clrssbsy dword ptr [m32]" although Intel manual specifies it's 8-byte operation and the operand is m64. [4] "rstorssp qword ptr [m64]" - LLVM wants "rstorssp dword ptr [m32]" although Intel manual specifies it's 8-byte operation and the operand is m64. Here is a list of instructions that LLVM supports, but not all documented variations: [5] "wrssd r32, r32" "wrssq r64, r64" "wrussd r32, r32" "wrussq r64, r64" For some reason LLVM only supports wr[u]ss[d|q] [mem], reg" form, but not "reg reg" form. However, Intel manual describes the following encodings: 0F 38 F6 WRSSD r/m32, r32 REX.W 0F 38 F6 WRSSQ r/m64, r64 66 0F 38 F5 WRUSSD r/m32, r32 66 REX.W 0F 38 F5 WRUSSQ r/m64, r64 Miscellaneous variations refused by LLVM, but disassembled by disassemblers: [6] "bswap r16" - bswap with 16-bit override prefix. [7] "movsxd r16, reg" - movsxd with 16-bit override prefix. [8] "movsxd r32, reg" - movsxd without REX.W prefix You would only want to encode these rarely, however, disassemblers encode these properly and these forms are not forbidden (CPU would execute these instructions). Conclusion: I think that somebody should check [1-2] especially as the binary produced by LLVM doesn't match the output I would expect. [3-4] are also interesting as LLVM refuses the correct size of memory operand it seems. The rest is most likely uninteresting. -- 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 27336 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in TransformTypos::RecursiveTransformLoop
Updates: Labels: Deadline-Approaching Comment #1 on issue 27336 by sheriffbot: llvm:clang-fuzzer: Stack-overflow in TransformTypos::RecursiveTransformLoop https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27336#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 27347 in oss-fuzz: llvm:clang-fuzzer: ASSERT: Entry != DelayedTypos.end() && "Failed to get the state for a TypoExpr!"
Updates: Labels: Deadline-Approaching Comment #1 on issue 27347 by sheriffbot: llvm:clang-fuzzer: ASSERT: Entry != DelayedTypos.end() && "Failed to get the state for a TypoExpr!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27347#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 27357 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-irce: Out-of-memory in llvm-opt-fuzzer--x86_64-irce
Updates: Labels: Deadline-Approaching Comment #1 on issue 27357 by sheriffbot: llvm:llvm-opt-fuzzer--x86_64-irce: Out-of-memory in llvm-opt-fuzzer--x86_64-irce https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27357#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 27385 in oss-fuzz: llvm:clangd-fuzzer: ASSERT: (uint16_t)DataLen == DataLen && (uint16_t)KeyLen == KeyLen
Updates: Labels: Deadline-Approaching Comment #1 on issue 27385 by sheriffbot: llvm:clangd-fuzzer: ASSERT: (uint16_t)DataLen == DataLen && (uint16_t)KeyLen == KeyLen https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27385#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 48992] New: LLVM fails some PassBuilderCallbacks tests with 12.0.0-rc1
https://bugs.llvm.org/show_bug.cgi?id=48992
Bug ID: 48992
Summary: LLVM fails some PassBuilderCallbacks tests with
12.0.0-rc1
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: marvin.schmidt1...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
On Exherbo I see the following test failures with 12.0.0-rc1:
Failed Tests (10):
LLVM-Unit :: IR/./IRTests/CGSCCCallbacksTest.InstrumentedInvalidatingPasses
LLVM-Unit :: IR/./IRTests/CGSCCCallbacksTest.InstrumentedPasses
LLVM-Unit :: IR/./IRTests/CGSCCCallbacksTest.InstrumentedSkippedPasses
LLVM-Unit :: IR/./IRTests/FunctionCallbacksTest.InstrumentedPasses
LLVM-Unit :: IR/./IRTests/FunctionCallbacksTest.InstrumentedSkippedPasses
LLVM-Unit ::
IR/./IRTests/LoopCallbacksTest.InstrumentedInvalidatingLoopNestPasses
LLVM-Unit :: IR/./IRTests/LoopCallbacksTest.InstrumentedInvalidatingPasses
LLVM-Unit :: IR/./IRTests/LoopCallbacksTest.InstrumentedPasses
LLVM-Unit :: IR/./IRTests/LoopCallbacksTest.InstrumentedSkippedPasses
LLVM-Unit :: IR/./IRTests/ModuleCallbacksTest.InstrumentedSkippedPasses
Testing Time: 205.97s
Unsupported : 1522
Passed : 40384
Expectedly Failed: 143
Failed :10
The tests failures all look like this:
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from LoopCallbacksTest
[ RUN ] LoopCallbacksTest.InstrumentedInvalidatingPasses
unknown file: Failure
Unexpected mock function call - returning directly.
Function call: runBeforeNonSkippedPass("PassManager",
8-byte object <10-98 B3-CF 9C-55 00-00>)
Google Mock tried the following 4 expectations, but none matched:
/var/tmp/paludis/build/dev-lang-llvm-12.0.0_rc1/work/llvm-project/llvm/unittests/IR/PassBuilderCallbacksTest.cpp:390:
tried expectation #0: EXPECT_CALL(*this,
runBeforeNonSkippedPass(Not(HasNameRegex("Mock")), HasName(IRName)))...
Expected arg #1: has name ""
Actual: 8-byte object <30-98 B3-CF 9C-55 00-00>, has name
''
Expected: to be called any number of times
Actual: called once - satisfied and active
/var/tmp/paludis/build/dev-lang-llvm-12.0.0_rc1/work/llvm-project/llvm/unittests/IR/PassBuilderCallbacksTest.cpp:390:
tried expectation #1: EXPECT_CALL(*this,
runBeforeNonSkippedPass(Not(HasNameRegex("Mock")), HasName(IRName)))...
Expected arg #1: has name "foo"
Actual: 8-byte object <30-98 B3-CF 9C-55 00-00>, has name
''
Expected: to be called any number of times
Actual: never called - satisfied and active
/var/tmp/paludis/build/dev-lang-llvm-12.0.0_rc1/work/llvm-project/llvm/unittests/IR/PassBuilderCallbacksTest.cpp:390:
tried expectation #2: EXPECT_CALL(*this,
runBeforeNonSkippedPass(Not(HasNameRegex("Mock")), HasName(IRName)))...
Expected arg #1: has name "loop"
Actual: 8-byte object <30-98 B3-CF 9C-55 00-00>, has name
''
Expected: to be called any number of times
Actual: never called - satisfied and active
/var/tmp/paludis/build/dev-lang-llvm-12.0.0_rc1/work/llvm-project/llvm/unittests/IR/PassBuilderCallbacksTest.cpp:902:
tried expectation #3: EXPECT_CALL(CallbacksHandle,
runBeforeNonSkippedPass(HasNameRegex("MockPassHandle"), HasName("loop")))...
Expected arg #0: has name regex "MockPassHandle"
Actual: "PassManager", has name
'PassManager'
Expected arg #1: has name "loop"
Actual: 8-byte object <30-98 B3-CF 9C-55 00-00>, has name
''
Expected: to be called once
Actual: never called - unsatisfied and active
unknown file: Failure
Unexpected mock function call - returning directly.
Function call: runBeforeNonSkippedPass("FunctionToLoopPassAdaptor", 8-byte
object <30-98 B3-CF 9C-55 00-00>)
Google Mock tried the following 4 expectations, but none matched:
/var/tmp/paludis/build/dev-lang-llvm-12.0.0_rc1/work/llvm-project/llvm/unittests/IR/PassBuilderCallbacksTest.cpp:390:
tried expectation #0: EXPECT_CALL(*this,
runBeforeNonSkippedPass(Not(HasNameRegex("Mock")), HasName(IRName)))...
Expected arg #1: has name ""
Actual: 8-byte object <80-B2 B3-CF 9C-55 00-00>, has name
''
Expected: to be called any number of times
Actual: called once - satisfied and active
/var/tmp/paludis/build/dev-lang-llvm-12.0.0_rc1/work/llvm-project/llvm/unittests/IR/PassBuilderCallbacksTest.cpp:390:
tried expectation #1: EXPECT_CALL(*this,
runBeforeNonSkippedPass(Not(HasNameRegex("Mock")), HasName(IRName)))...
Expected arg #1: has name "foo"
Actual: 8-byte object <80-B2 B3-CF 9C-55 00-00>, has name
''
Expected: to be called any number of times
Actual: never called - satisfied and a
[llvm-bugs] [Bug 48993] New: Recent shared_ptr storage change (https://reviews.llvm.org/D91201) causes CFI cast failures during make_shared
https://bugs.llvm.org/show_bug.cgi?id=48993
Bug ID: 48993
Summary: Recent shared_ptr storage change
(https://reviews.llvm.org/D91201) causes CFI cast
failures during make_shared
Product: libc++
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Consider this program that creates and destroys a shared_ptr object:
$ cat t.cpp
#include
struct Foo {
Foo() {}
virtual ~Foo() {}
};
int main(int argc, char **argv) { std::make_shared(); }
If you compile libc++, lld, clang, cfi, ubsan, etc, at ToT and build this
program like so, it results in CFI cast errors:
$ ./bin/clang++ t.cpp -flto=thin -fuse-ld=lld -stdlib=libc++ -fsanitize=cfi
-fno-sanitize-trap -fvisibility=hidden && LD_LIBRARY_PATH=lib ./a.out ;
echo $?
/usr/local/google/home/rnk/llvm-project/build/bin/../include/c++/v1/memory:2653:27:
runtime error: control flow integrity check for type 'Foo' failed during cast
to unrelated type (vtable address 0x)
0x: note: invalid vtable
/usr/local/google/home/rnk/llvm-project/build/bin/../include/c++/v1/memory:2653:27:
note: check failed in /usr/local/google/home/rnk/llvm-project/build/a.out,
vtable located in (unknown)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
/usr/local/google/home/rnk/llvm-project/build/bin/../include/c++/v1/memory:2653:27
in
1
Reverting 955dd7b7f3f6d / https://reviews.llvm.org/D91201 locally and
rebuilding libc++ to copy the headers makes the problem go away:
$ git revert 955dd7b7f3f6d
Removing
libcxx/test/std/utilities/memory/util.smartptr/util.smartptr.shared/util.smartptr.shared.create/allocate_shared_construct.pass.cpp
Removing
libcxx/test/std/utilities/memory/util.smartptr/util.smartptr.shared/libcxx.control_block_layout.pass.cpp
Auto-merging libcxx/include/memory
[main 5f7ab320457d] Revert "[libc++] LWG2070: Use Allocator construction for
objects created with allocate_shared"
4 files changed, 19 insertions(+), 429 deletions(-)
delete mode 100644
libcxx/test/std/utilities/memory/util.smartptr/util.smartptr.shared/libcxx.control_block_layout.pass.cpp
delete mode 100644
libcxx/test/std/utilities/memory/util.smartptr/util.smartptr.shared/util.smartptr.shared.create/allocate_shared_construct.pass.cpp
$ ninja cxx
[1 processes, 11/11 @ 17.6/s : 0.626s ] Creating library symlink
lib/libc++.so.1 lib/libc++.so
$ ./bin/clang++ t.cpp -flto=thin -fuse-ld=lld -stdlib=libc++ -fsanitize=cfi
-fno-sanitize-trap -fvisibility=hidden && LD_LIBRARY_PATH=lib ./a.out ;
echo $?
0
These are the lines of the change that matter:
_LIBCPP_HIDE_FROM_ABI
explicit __shared_ptr_emplace(_Alloc __a, _Args&& ...__args)
-#ifndef _LIBCPP_CXX03_LANG
-: __data_(piecewise_construct, _VSTD::forward_as_tuple(__a),
- _VSTD::forward_as_tuple(_VSTD::forward<_Args>(__args)...))
+: __storage_(_VSTD::move(__a))
+{
+#if _LIBCPP_STD_VER > 17
+using _TpAlloc = typename __allocator_traits_rebind<_Alloc,
_Tp>::type;
+_TpAlloc __tmp(*__get_alloc());
+allocator_traits<_TpAlloc>::construct(__tmp, __get_elem(),
_VSTD::forward<_Args>(__args)...);
#else
-: __data_(__a, _Tp(_VSTD::forward<_Args>(__args)...))
+::new ((void*)__get_elem()) _Tp(_VSTD::forward<_Args>(__args)...);
#endif
That change switches from calling the __compressed_pair constructor directly to
using placement new on the result of __get_elem. Inside __get_elem, the address
of the second pair element is cast to the type that will be constructed. That
reinterpret_cast on the memory before construction is the issue: CFI detects
cast confusion bugs by checking that the vtable is correct for the type of the
cast, but the vptr slot is still uninitialized.
--
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 48994] New: Add a GitHub action for checking libclang.so ABI in the release branch
https://bugs.llvm.org/show_bug.cgi?id=48994 Bug ID: 48994 Summary: Add a GitHub action for checking libclang.so ABI in the release branch Product: clang Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: tstel...@redhat.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk In LLVM 11.0.0, the libclang.so ABI was inadvertently changed. We need to add automated testing so this doesn't happen again. -- 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 48995] New: Failure to optimize certain redundant operations around type conversions
https://bugs.llvm.org/show_bug.cgi?id=48995
Bug ID: 48995
Summary: Failure to optimize certain redundant operations
around type conversions
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
int32_t f(int64_t a, int b)
{
return ~(int32_t)(~a >> b);
}
This can be optimized to `return a >> b;`. This transformation is done by GCC,
but not by LLVM.
--
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
