[llvm-bugs] [Bug 44007] New: assertion failure in APFloat.fusedMultiplyAdd with subnormal arguments
https://bugs.llvm.org/show_bug.cgi?id=44007
Bug ID: 44007
Summary: assertion failure in APFloat.fusedMultiplyAdd with
subnormal arguments
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: RESOLVED
Severity: enhancement
Priority: P
Component: Support Libraries
Assignee: unassignedb...@nondot.org
Reporter: jay.f...@gmail.com
CC: ehudk...@gmail.com, llvm-bugs@lists.llvm.org
CC: ehudk...@gmail.com
Resolution: DUPLICATE
Status: RESOLVED
If I add this unit test:
diff --git a/llvm/unittests/ADT/APFloatTest.cpp
b/llvm/unittests/ADT/APFloatTest.cpp
index c76347ed056..a6398bbb684 100644
--- a/llvm/unittests/ADT/APFloatTest.cpp
+++ b/llvm/unittests/ADT/APFloatTest.cpp
@@ -530,6 +530,15 @@ TEST(APFloatTest, FMA) {
EXPECT_FALSE(losesInfo);
EXPECT_EQ(4.0f, M1.convertToFloat());
}
+
+ // Regression test that failed an assertion.
+ {
+APFloat f1(-8.85242279E-41f);
+APFloat f2(2.0f);
+APFloat f3(8.85242279E-41f);
+f1.fusedMultiplyAdd(f2, f3, APFloat::rmNearestTiesToEven);
+EXPECT_EQ(-8.85242279E-41f, f1.convertToFloat());
+ }
}
TEST(APFloatTest, MinNum) {
then it fails with an assertion failure:
ADTTests: /home/jayfoad2/git/llvm-project/llvm/lib/Support/APFloat.cpp:1521:
llvm::lostFraction llvm::detail::IEEEFloat::addOrSubtractSignificand(const
llvm::detail::IEEEFloat &, bool): Assertion `!carry' failed.
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x76890801 in __GI_abort () at abort.c:79
#2 0x7688039a in __assert_fail_base (fmt=0x76a077d8 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x20a334 "!carry",
file=file@entry=0x2280bf
"/home/jayfoad2/git/llvm-project/llvm/lib/Support/APFloat.cpp",
line=line@entry=1521,
function=function@entry=0x27527b "llvm::lostFraction
llvm::detail::IEEEFloat::addOrSubtractSignificand(const llvm::detail::IEEEFloat
&, bool)") at assert.c:92
#3 0x76880412 in __GI___assert_fail (assertion=0x20a334 "!carry",
file=0x2280bf "/home/jayfoad2/git/llvm-project/llvm/lib/Support/APFloat.cpp",
line=1521,
function=0x27527b "llvm::lostFraction
llvm::detail::IEEEFloat::addOrSubtractSignificand(const llvm::detail::IEEEFloat
&, bool)") at assert.c:101
#4 0x009499a6 in llvm::detail::IEEEFloat::addOrSubtractSignificand
(this=0x7fffd3d0, rhs=..., subtract=true) at
/home/jayfoad2/git/llvm-project/llvm/lib/Support/APFloat.cpp:1521
#5 0x0094918e in llvm::detail::IEEEFloat::multiplySignificand
(this=0x7fffd3d0, rhs=..., addend=0x7fffd390) at
/home/jayfoad2/git/llvm-project/llvm/lib/Support/APFloat.cpp:1066
#6 0x0094b726 in llvm::detail::IEEEFloat::fusedMultiplyAdd
(this=0x7fffd3d0, multiplicand=..., addend=...,
rounding_mode=llvm::APFloatBase::rmNearestTiesToEven) at
/home/jayfoad2/git/llvm-project/llvm/lib/Support/APFloat.cpp:1818
#7 0x004bc29a in llvm::APFloat::fusedMultiplyAdd (this=0x7fffd3c8,
Multiplicand=..., Addend=..., RM=llvm::APFloatBase::rmNearestTiesToEven) at
/home/jayfoad2/git/llvm-project/llvm/include/llvm/ADT/APFloat.h:1017
#8 0x00454202 in (anonymous namespace)::APFloatTest_FMA_Test::TestBody
(this=0xb14b00) at
/home/jayfoad2/git/llvm-project/llvm/unittests/ADT/APFloatTest.cpp:539
#9 0x00a300be in
testing::internal::HandleSehExceptionsInMethodIfSupported
(object=0xb14b00, method=&virtual testing::Test::TestBody(), location=0x294442
"the test body") at
/home/jayfoad2/git/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc:2402
#10 0x00a1ef62 in
testing::internal::HandleExceptionsInMethodIfSupported
(object=0xb14b00, method=&virtual testing::Test::TestBody(), location=0x294442
"the test body") at
/home/jayfoad2/git/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc:2455
#11 0x00a0cd76 in testing::Test::Run (this=0xb14b00) at
/home/jayfoad2/git/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc:2474
#12 0x00a0d633 in testing::TestInfo::Run (this=0xa95eb0) at
/home/jayfoad2/git/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc:2656
#13 0x00a0db8c in testing::TestCase::Run (this=0xa95bd0) at
/home/jayfoad2/git/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc:2774
#14 0x00a132d1 in testing::internal::UnitTestImpl::RunAllTests
(this=0xa95140) at
/home/jayfoad2/git/llvm-project/llvm/utils/unittest/googletest/src/gtest.cc:4649
#15 0x00a32c5e in
testing::internal::HandleSehExceptionsInMethodIfSupported (object=0xa95140,
method=(bool
(testing::internal::UnitTestImpl::*)(testing::internal::UnitTestImpl * const))
0
[llvm-bugs] [Bug 44052] New: Pre-built binaries for ubuntu 19.04 link against a too-recent libz3
https://bugs.llvm.org/show_bug.cgi?id=44052 Bug ID: 44052 Summary: Pre-built binaries for ubuntu 19.04 link against a too-recent libz3 Product: Packaging Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: binary tarballs Assignee: unassignedb...@nondot.org Reporter: ani...@astier.eu CC: llvm-bugs@lists.llvm.org Pre-built LLVM 9.0.0 binaries for "Ubuntu 19.04" link against a too recent libz3 for Ubuntu 19.04: http://releases.llvm.org/download.html clang+llvm-9.0.0-x86_64-pc-linux-gnu $ ./clang ./clang: error while loading shared libraries: libz3.so.4.8: cannot open shared object file: No such file or directory clang+llvm-9.0.0-x86_64-pc-linux-gnu $ ./clangd ./clangd: error while loading shared libraries: libz3.so.4.8: cannot open shared object file: No such file or directory libz3 4.8 needs Ubuntu 19.10: https://packages.ubuntu.com/search?keywords=libz3-4 The good news is that the pre-built package for Ubuntu 18.04 does work on Ubuntu 19.04. I initially considered opening a bug against the website to just rename Ubuntu 19.04 to Ubuntu 19.10 on the download page, but I'll leave that to your judgement. -- 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 44053] New: lldb can't run static initializers on AArch64 Ubuntu
https://bugs.llvm.org/show_bug.cgi?id=44053
Bug ID: 44053
Summary: lldb can't run static initializers on AArch64 Ubuntu
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: diana.pi...@linaro.org
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
TestStaticInitializers.py fails on AArch64 Linux for dwarf and dwo with:
runCmd: expr -p -- struct Foo { Foo() { inc_counter(); } }; Foo f;
runCmd failed!
error: couldn't run static initializers: couldn't run static initializer:
FAILURE
FAIL: LLDB (/home/diana.picus/llvm-envs/lldb/build/bin/clang-10-aarch64) ::
test_dwo (TestStaticInitializers.StaticInitializers)
>>: success
--
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 44054] New: Missing overflow check for ++x compared to x += 1
https://bugs.llvm.org/show_bug.cgi?id=44054
Bug ID: 44054
Summary: Missing overflow check for ++x compared to x += 1
Product: compiler-rt
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: ubsan
Assignee: unassignedb...@nondot.org
Reporter: cullm...@absint.de
CC: llvm-bugs@lists.llvm.org
If you use this example:
int main()
{
signed char x = 127;
x += 1;
return 0;
}
with -fsanitize=integer you get a proper:
main.cpp:4:7: runtime error: implicit conversion from type 'int' of value 128
(32-bit, signed) to type 'signed char' changed the value to -128 (8-bit,
signed)
If you alter this to
int main()
{
signed char x = 127;
++x;
return 0;
}
no longer any check is done. In the IR already the call to the overflow stuff
is missing.
I am not sure if this is the right component to report, thought.
(Or if I miss some option to get this kind of overflow alarm)
--
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 44055] New: TestRequireHWBreakpoints.py fails on AArch64 Ubuntu
https://bugs.llvm.org/show_bug.cgi?id=44055 Bug ID: 44055 Summary: TestRequireHWBreakpoints.py fails on AArch64 Ubuntu Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: diana.pi...@linaro.org CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org 'thread step-over', 'step-out', 'step-in' and 'until' all seem to return success, although an error is expected after setting target.require-hardware-breakpoint to true. FAILURE FAIL: LLDB (/home/diana.picus/llvm-envs/lldb/build/bin/clang-10-aarch64) :: test_step_out (TestRequireHWBreakpoints.BreakpointLocationsTestCase) >>: success -- 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 42151] [GVN] Incorrect transformation if there is a !invariant.load
https://bugs.llvm.org/show_bug.cgi?id=42151 Evgeniy Brevnov changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44056] New: python _lldb.so is a broken symlink on regular Linux distro packages
https://bugs.llvm.org/show_bug.cgi?id=44056 Bug ID: 44056 Summary: python _lldb.so is a broken symlink on regular Linux distro packages Product: lldb Version: 9.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: thi...@kde.org CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org Ref: https://github.com/clearlinux/distribution/issues/1502 The $PYTHONSITEDIR/lldb/_lldb.so file is a symlink to $LIBDIR/liblldb.so, but the .so file is usually not included in regular packages, only development ones. That makes the symlink broken. Fedora workaround: https://src.fedoraproject.org/rpms/lldb/blob/master/f/lldb.spec#_94 OpenSUSE workaround: https://build.opensuse.org/package/view_file/openSUSE:Factory/llvm9/llvm9.spec?expand=1 line 896 Clear Linux workaround: https://github.com/clearlinux-pkgs/lldb/blob/9.0.0-3/install_append -- 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 44057] New: Incorrect stepping through inlined function on AArch64 Ubuntu
https://bugs.llvm.org/show_bug.cgi?id=44057 Bug ID: 44057 Summary: Incorrect stepping through inlined function on AArch64 Ubuntu Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: diana.pi...@linaro.org CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org Created attachment 22839 --> https://bugs.llvm.org/attachment.cgi?id=22839&action=edit Log of stepping from caller_trivial_1 into caller_trivial_2 TestInlineStepping.py fails on AArch64: AssertionError: Step into stopped at wrong place: expected: /home/buildslave/buildslave/lldb-cmake-aarch64/llvm-project/lldb/packages/Python/lldbsuite/test/functionalities/inline-stepping/calling.cpp:78 got: /home/buildslave/buildslave/lldb-cmake-aarch64/llvm-project/lldb/packages/Python/lldbsuite/test/functionalities/inline-stepping/calling.cpp:98:18. -- 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 44058] New: LCSSA corrupts SCEV
https://bugs.llvm.org/show_bug.cgi?id=44058
Bug ID: 44058
Summary: LCSSA corrupts SCEV
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: suc-dan...@yandex.ru
CC: llvm-bugs@lists.llvm.org
Consider following IR:
define void @foo(i32* %arg, i32* %arg1, i1 %arg2) {
bb:
br label %bb3
bb3: ; preds = %bb13, %bb
%tmp = load i32, i32* %arg
%tmp4 = load i32, i32* %arg1
%tmp5 = add i32 %tmp4, %tmp
%tmp6 = icmp sgt i32 %tmp5, %tmp
br i1 %tmp6, label %bb7, label %bb11
bb7: ; preds = %bb3
br i1 %arg2, label %bb10, label %bb8
bb8: ; preds = %bb7
%tmp9 = add nsw i32 %tmp, 1
ret void
bb10: ; preds = %bb7
br label %bb11
bb11: ; preds = %bb10, %bb3
%tmp12 = phi i32 [ 0, %bb3 ], [ %tmp4, %bb10 ]
br label %bb13
bb13: ; preds = %bb13, %bb11
%tmp14 = phi i32 [ %tmp15, %bb13 ], [ 0, %bb11 ]
%tmp15 = add nuw nsw i32 %tmp14, 1
%tmp16 = icmp slt i32 %tmp15, %tmp12
br i1 %tmp16, label %bb13, label %bb3
}
SCEV of trip count for bb13 loop is `(-1 + (1 smax ((-1 * %tmp) + ((%tmp +
%tmp4) smax %tmp`
LCSSA inserts following phi into bb8: %tmp.lcssa = phi i32 [ %tmp, %bb7 ]
When the phi is inserted, LCSSA calls ValueHandleBase::ValueIsRAUWd(%tmp,
%tmp.lcssa). Since %tmp is SCEVUnknown,
SCEVUnknown::allUsesReplacedWith(%tmp.lcssa) is called.
After that point SCEV of trip count for bb13 loop is `(-1 + (1 smax ((-1 *
%tmp.lcssa) + ((%tmp4 + %tmp.lcssa) smax %tmp.lcssa`
Please note that %bb13 isn't reachable from %bb8, so this SCEV is incorrect.
With this patch applied: https://reviews.llvm.org/D70423
Following command:
opt -passes="verify,lcssa,verify"
-verify-scev-strict -S repro.ll
fails with following message:
Trip Count for Loop at depth 2 containing: %bb13
Changed!
Old: (-1 + (1 smax ((-1 * %tmp.lcssa) + ((%tmp4 + %tmp.lcssa) smax
%tmp.lcssa
New: (-1 + (1 smax ((-1 * %tmp) + ((%tmp + %tmp4) smax %tmp
Delta: ((-1 * (1 smax ((-1 * %tmp) + ((%tmp + %tmp4) smax %tmp +
(1 smax ((-1 * %tmp.lcssa) + ((%tmp4 + %tmp.lcssa) smax %tmp.lcssa
It is possible to reproduce the problem even without that patch, but it is less
convenient. With this command:
opt -passes="print,lcssa,print" -S repro.ll
The same problem is visible, but it requires manual checking (or parsing) of
the output.
Important note: both commands contain an extra pass before LCSSA
(verify or print). In both cases they are
required to query SCEV so that when LCSSA runs it has some cached values to
corrupt.
In my opinion behavior of SCEVUnknown::allUsesReplacedWith is reasonable for
the case when *all* uses of the value are replaced, so the problem is that
LCSSA calls ValueHandleBase::ValueIsRAUWd when only some uses of the value are
replaced (hence the solution is to call something like SE->forgetValue
instead). But I'd like to hear others' opinions on this matter.
--
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 43971] [SelectionDAG] Loop in SelectionDAG (DAGCombiner)
https://bugs.llvm.org/show_bug.cgi?id=43971 Simon Pilgrim changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||bbf4af3109d1 --- Comment #7 from Simon Pilgrim --- Fixed bug in rGbbf4af3109d1 This removes XFormVExtractWithShuffleIntoLoad which causes a few minor regressions, which will be addressed in future commits. -- 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 44059] New: The LLDB test for the entry values will fail due to changes in the compiler
https://bugs.llvm.org/show_bug.cgi?id=44059 Bug ID: 44059 Summary: The LLDB test for the entry values will fail due to changes in the compiler Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: djordje.todoro...@rt-rk.com CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org The test will be disabled (temporarily), since we are trying to change the approach for production of the entry values. The D68206 is the first patch from the set of patches. -- 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 44060] New: HowToUseLLJIT example asserts in debug build on windows
https://bugs.llvm.org/show_bug.cgi?id=44060 Bug ID: 44060 Summary: HowToUseLLJIT example asserts in debug build on windows Product: Documentation Version: 9.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: General docs Assignee: unassignedb...@nondot.org Reporter: rob.co...@ai-solutions.com CC: llvm-bugs@lists.llvm.org It works fine in a release build. In a debug build It aborts due to an assert failure on Core.cpp (383) because the lhs flags are (Exported | Callable) and the rhs flags are (Callable). -- 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 44061] New: shuffled/unsorted assembler output
https://bugs.llvm.org/show_bug.cgi?id=44061
Bug ID: 44061
Summary: shuffled/unsorted assembler output
Product: libraries
Version: 7.0
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: MC
Assignee: unassignedb...@nondot.org
Reporter: baem...@gmx.de
CC: llvm-bugs@lists.llvm.org
I do use a target assembler streamer, which implements the method emitValue().
Then
1) emitValue() hat to emit newlines by itself
2) comments are not at their correct place, but in lines below the emitted
values
An implemented method emitValue() is used at the end of
MCAsmStreamer::EmitValueImpl():
void MCAsmStreamer::EmitValueImpl(const MCExpr *Value, unsigned Size,
SMLoc Loc) {
...
assert(Directive && "Invalid size for machine code value!");
OS << Directive;
if (MCTargetStreamer *TS = getTargetStreamer()) {
TS->emitValue(Value); /// <- here it is used.
} else {
Value->print(OS, MAI);
EmitEOL();
}
}
The proposed solution is to emit the EOL in both cases:
assert(Directive && "Invalid size for machine code value!");
OS << Directive;
if (MCTargetStreamer *TS = getTargetStreamer()) {
TS->emitValue(Value); /// <- here it is used.
} else {
Value->print(OS, MAI);
}
EmitEOL();
}
In this case emitValue() does not have to emit EOLs and comments are at their
correct place. At least in my back-end this works as expected.
Boris
--
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 44062] New: instcombine: doesn't remove redundant allocation / memory access with aligned_alloc
https://bugs.llvm.org/show_bug.cgi?id=44062
Bug ID: 44062
Summary: instcombine: doesn't remove redundant allocation /
memory access with aligned_alloc
Product: tools
Version: 8.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: opt
Assignee: unassignedb...@nondot.org
Reporter: u...@polymagelabs.com
CC: llvm-bugs@lists.llvm.org
In the snippet below, the allocated storage is optimized away when a malloc is
used, but not when an aligned_alloc is used. (aligned_alloc has effectively
similar semantics for the purpose of relevant opts here, and it has been in
glibc since 2.16 and in the C11 standard.) When a malloc is used, once the
load/stores are hoisted out by LICM, -instcombine gets rid of the heap
allocation and *s is effectively in a virtual register. But the same thing
doesn't happen with aligned_alloc; the allocation and the store to it remain.
https://godbolt.org/z/WCUF9n
#include
#define N 100
void foo(int Y[N], int A[N][N], int X[N]) {
for (int i = 0; i < N; ++i) {
// Allocated storage optimized away when malloc is used.
// int *s = (int*)malloc((sizeof(int)));
int *s = (int *)aligned_alloc(sizeof(int), sizeof(int));
*s = Y[i];
for (int j = 0; j < N; ++j) {
*s += A[i][j] * X[j];
}
Y[i] += *s;
free(s);
}
}
--
On this note, this issue exists with posix_memalign as well. With
posix_memalign, in fact, the load/stores to *s in the loop aren't replaced by a
scalar. Although this is an artificial C/C++ example to reproduce this issue,
the more interesting/real use case is for example when a pass/utility has to
generate an allocation for a buffer of vector element types -- as such, an
alignment to vector size boundaries is desired, which malloc doesn't provide
for > 16 bytes.
--
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 44063] New: Autolink PR in Commit Messages to Bugzilla URL
https://bugs.llvm.org/show_bug.cgi?id=44063 Bug ID: 44063 Summary: Autolink PR in Commit Messages to Bugzilla URL Product: new-bugs Version: unspecified Hardware: All OS: All 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 We need to configure github to link to our external bug tracker. See https://help.github.com/en/github/administering-a-repository/configuring-autolinks-to-reference-external-resources For instructions. After this commits like: https://github.com/llvm/llvm-project/commit/8723b95cefa4 Should link to: https://bugs.llvm.org/show_bug.cgi?id=43585 We should use both "PR" and "PR#" as the reference prefix. -- 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 44064] New: Missing warning for comparison with string literals (expanded from macro)
https://bugs.llvm.org/show_bug.cgi?id=44064
Bug ID: 44064
Summary: Missing warning for comparison with string literals
(expanded from macro)
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
#define PATH_DELIMITER "/"
int foo() {
return PATH_DELIMITER != "/";
}
int foo2() {
return "/" != "/";
}
Clang warns only for foo2, GCC for both and GCC caught a real bug.
I suspect this is just a missing diagnostic... or?
--
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 44066] New: long compile time after enabling MemorySSA as loop dependency
https://bugs.llvm.org/show_bug.cgi?id=44066 Bug ID: 44066 Summary: long compile time after enabling MemorySSA as loop dependency Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Transformation Utilities Assignee: unassignedb...@nondot.org Reporter: yuanfang.c...@sony.com CC: llvm-bugs@lists.llvm.org Created attachment 22841 --> https://bugs.llvm.org/attachment.cgi?id=22841&action=edit bitcode reproducer After rL370384, the compile time for an internal test increases from 12s to ~63s clang++ -c -O3 -g -fno-vectorize -fno-slp-vectorize -fno-strict-aliasing test.ll -x ir Attached is a reduced reproducer that on my Intel i7-6900K takes 1.3s before rL370384, and 2.4s after it. -- 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 44067] New: [SLPVectorizer] Generation of seed operands in the wrong order for insertelement.
https://bugs.llvm.org/show_bug.cgi?id=44067
Bug ID: 44067
Summary: [SLPVectorizer] Generation of seed operands in the
wrong order for insertelement.
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: v.porpo...@gmail.com
CC: a.bat...@hotmail.com, anton.a.afanas...@gmail.com,
llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk,
spatel+l...@rotateright.com
There seems to be a bug in findBuildVector() when the insertelement
instructions are not in increasing index order.
For example:
%Ins1 = insertelement <2 x float> undef, float %Elem1, i32 1 ; NOTE: index=1
%Ins0 = insertelement <2 x float> %Ins1, float %Elem0, i32 0 ; NOTE: index=0
This generates a seed vector of %Elem1, %Elem0, but it should generate the
reverse: %Elem0, %Elem1.
Test:
define dso_local <2 x float> @foo({{float, float}}* %A, float %B) {
entry:
%0 = bitcast {{float, float}}* %A to <2 x float>*
%1 = load <2 x float>, <2 x float>* %0
%L0 = extractelement <2 x float> %1, i32 0
%L1 = extractelement <2 x float> %1, i32 1
%Mul0 = fmul float %L0, 2.00e+00
%Mul1 = fmul float %L1, 2.00e+00
%Ins1 = insertelement <2 x float> undef, float %Mul1, i32 1
%Ins0 = insertelement <2 x float> %Ins1, float %Mul0, i32 0
ret <2 x float> %Ins0
}
Compile:
opt -slp-vectorizer -S -mtriple=x86_64-unknown-linux-gnu test.ll
--
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 43997] [LLD/ELF] LLD change inflates elf binary size when linked with no-rosegment
https://bugs.llvm.org/show_bug.cgi?id=43997 Fangrui Song changed: What|Removed |Added Resolution|--- |WONTFIX Status|REOPENED|RESOLVED --- Comment #9 from Fangrui Song --- Posted a qemu patch last Friday https://lists.nongnu.org/archive/html/qemu-devel/2019-11/msg02480.html Some sections need to be placed first, e.g. .interp and some .note*. Core dumpers give priority to first few pages. So the option may end up placing R sections in both sides of RX. The code size inefficiency will also lower its utility. R and RW on both sides of RX makes it less likely to cause relocation overflows for large executables/shared objects. Another point worth mentioning: -Ttext and -Ttext-segment are different in GNU ld, but both lld and gold implement -Ttext and -Ttext-segment as aliases. gold sets the segment address (GNU ld -Ttext-segment behavior) while lld sets the .text address (GNU ld -Ttext behavior). We probably should remove -Ttext-segment to avoid confusion, if we don't intend to support it (it is very old-fashioned). -- 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 44068] New: LLDB Not Stepping into Multiple Inheritance Virtual Functions
https://bugs.llvm.org/show_bug.cgi?id=44068
Bug ID: 44068
Summary: LLDB Not Stepping into Multiple Inheritance Virtual
Functions
Product: lldb
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: acwilso...@gmail.com
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
Created attachment 22842
--> https://bugs.llvm.org/attachment.cgi?id=22842&action=edit
Reproducer program.
Overview:
Using LLDB to debug polymorphic objects that have multiple inheritance will not
step into virtual functions.
Steps to Reproduce:
```
$ clang++ -std=c++11 -g -O0 reproducer.cpp -o clang.out
$ lldb clang.out
(lldb) target create "clang.out"
Current executable set to 'clang.out' (x86_64).
(lldb) b 36
Breakpoint 1: where = clang.out`main + 103 at
reproducer.cpp:36:16, address = 0x00400d67
(lldb) r
Process 2764 launched: '/home/rdtscp/Documents/lldb_reproducer/clang.out'
(x86_64)
Process 2764 stopped
* thread #1, name = 'clang.out', stop reason = breakpoint 1.1
frame #0: 0x00400d67 clang.out`main(argc=1,
argv=0x7fffe808) at reproducer.cpp:36:16
33 int main(int argc, char **argv) {
34 using namespace Test;
35 std::shared_ptr object = std::shared_ptr(new
Concrete());
-> 36 int output = object->vFun();
37 std::cout << output << std::endl;
38 return output;
39 }
(lldb) s
Process 2764 stopped
* thread #1, name = 'clang.out', stop reason = step in
frame #0: 0x00400d86 clang.out`main(argc=1,
argv=0x7fffe808) at reproducer.cpp:37:16
34 using namespace Test;
35 std::shared_ptr object = std::shared_ptr(new
Concrete());
36 int output = object->vFun();
-> 37 std::cout << output << std::endl;
38 return output;
39 }
(lldb)
```
Altering the `Concrete` class to be:
```
class Concrete : // public Base,
public Interface {
public:
virtual int vFun() override {
volatile int x = rand();
if (x > 0)
return x;
else
return 0;
}
};
```
Will result in:
```
$ clang++ -std=c++11 -g -O0 reproducer.cpp -o clang.out
$ lldb clang.out
(lldb) target create "clang.out"
Current executable set to 'clang.out' (x86_64).
(lldb) b 36
Breakpoint 1: where = clang.out`main + 104 at reproducer.cpp:36:16, address =
0x00400cf8
(lldb) r
Process 2869 launched: '/home/rdtscp/Documents/lldb_reproducer/clang.out'
(x86_64)
Process 2869 stopped
* thread #1, name = 'clang.out', stop reason = breakpoint 1.1
frame #0: 0x00400cf8 clang.out`main(argc=1,
argv=0x7fffe808) at reproducer.cpp:36:16
33 int main(int argc, char **argv) {
34 using namespace Test;
35 std::shared_ptr object = std::shared_ptr(new
Concrete());
-> 36 int output = object->vFun();
37 std::cout << output << std::endl;
38 return output;
39 }
(lldb) s
Process 2869 stopped
* thread #1, name = 'clang.out', stop reason = step in
frame #0: 0x00400fec
clang.out`Test::Concrete::vFun(this=0x00615c20) at reproducer.cpp:23:24
20 public Interface {
21 public:
22 virtual int vFun() override {
-> 23 volatile int x = rand();
24 if (x > 0)
25 return x;
26 else
(lldb)
```
The above shows that making the `Concrete` class inherit from the `Base` class
prevents us from stepping into `vFun()`.
System Settings:
```
OS: Debian GNU/Linux 9.11 (stretch) x86_64
Model: VirtualBox 1.2
Kernel: 4.9.0-11-amd64
Uptime: 1 hour, 3 minutes
Packages: 1722
Shell: zsh 5.3.1
CPU: Intel i5-7360U (1) @ 2.3GHz
GPU: VMware SVGA II Adapter
Memory: 219MB / 996MB
```
```
$ clang++ --version
clang version 9.0.0-svn364966-1~exp1+0~20190702204433.1332~1.gbpb44072 (trunk)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ lldb --version
lldb version 9.0.0
```
Additional Information:
I tried using:
```
g++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
```
To see if my code was incorrect, but g++ and gdb were able to step into
"vFun()" fun.
--
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 44069] New: Infinite shuffle+extract legalization loop
https://bugs.llvm.org/show_bug.cgi?id=44069
Bug ID: 44069
Summary: Infinite shuffle+extract legalization loop
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: aemer...@apple.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
The following IR causes a hang with llc -O0 on x86:
define hidden void @foo() unnamed_addr #0 align 2 {
entry:
%0 = load <4 x float>, <4 x float>* undef, align 16
%vecext.i4849 = extractelement <4 x float> %0, i32 0
%1 = load <4 x i32>, <4 x i32>* null, align 16
%permil281 = shufflevector <4 x i32> %1, <4 x i32> undef, <4 x i32>
%2 = bitcast <4 x i32> %permil281 to <4 x float>
%vecext1.i4794 = extractelement <4 x float> %2, i32 0
%sub.i4795 = fsub float %vecext1.i4794, %vecext.i4849
%vecins.i4796 = insertelement <4 x float> %2, float %sub.i4795, i32 0
store <4 x float> %vecins.i4796, <4 x float>* undef, align 16
unreachable
}
attributes #0 = { "use-soft-float"="false" }
It seems that there's a combine in X86ISelLowering in
XFormVExtractWithShuffleIntoLoad() which is matching the load->shuffle->extract
element and then generating another shuffle->extractelement, which I assume is
intended for further optimization by DAGCombine. However, it just up in a
legalization loop on the extract.
--
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 44070] New: Please merge miscompilation fix to release branch
https://bugs.llvm.org/show_bug.cgi?id=44070 Bug ID: 44070 Summary: Please merge miscompilation fix to release branch Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: tliv...@google.com CC: llvm-bugs@lists.llvm.org Blocks: 42474 https://bugs.llvm.org/show_bug.cgi?id=44012 is a nasty little miscompilation bug that was fixed in G194d7ec081c31ee4ed82bfa3cade4ef30afab912 (https://github.com/llvm/llvm-project/commit/194d7ec081c31ee4ed82bfa3cade4ef30afab912). This is a very low-risk fix to merge. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=42474 [Bug 42474] [meta] 9.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 44069] Infinite shuffle+extract legalization loop
https://bugs.llvm.org/show_bug.cgi?id=44069 Amara Emerson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Amara Emerson --- Ah, yes, that fixes it. *** This bug has been marked as a duplicate of bug 43971 *** -- 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 44049] Control Flow Guard checking code is corrupting function pointers
https://bugs.llvm.org/show_bug.cgi?id=44049 Reid Kleckner changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Reid Kleckner --- Should be fixed: http://github.com/llvm/llvm-project/commit/606a2bd6218e8378728b6c1e021e64bb57084a97 -- 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 43360] [meta] 9.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=43360 Bug 43360 depends on bug 43380, which changed state. Bug 43380 Summary: Please merge r367981 to 9.0.0 https://bugs.llvm.org/show_bug.cgi?id=43380 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 43380] Please merge r367981 to 9.0.0
https://bugs.llvm.org/show_bug.cgi?id=43380 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)|r367981 |r367981 0f34f1b --- Comment #3 from Tom Stellard --- Merged: 0f34f1b -- 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 44071] New: "thunk creation not converged" error
https://bugs.llvm.org/show_bug.cgi?id=44071 Bug ID: 44071 Summary: "thunk creation not converged" error Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org It is reported by an internal user of lld that lld prints out "thunk creation not converged" error when building Chromium Here is the error. FAILED: libstandalonelibwebviewchromium.so libstandalonelibwebviewchromium.so.TOC lib.unstripped/libstandalonelibwebviewchromium.so python "../../build/toolchain/gcc_solink_wrapper.py" --readelf="../../third_party/android_ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-readelf" --nm="../../third_party/android_ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-nm" --strip=../../buildtools/third_party/eu-strip/bin/eu-strip --sofile="./lib.unstripped/libstandalonelibwebviewchromium.so" --tocfile="./libstandalonelibwebviewchromium.so.TOC" --output="./libstandalonelibwebviewchromium.so" -- ../../third_party/llvm-build/Release+Asserts/bin/clang++ -shared -Wl,-soname="libstandalonelibwebviewchromium.so" -Wl,-shared,-Bsymbolic -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -fuse-ld=lld -Wl,-z,max-page-size=4096 -Wl,--color-diagnostics -Wl,--no-rosegment -Wl,--exclude-libs=libgcc.a -Wl,--exclude-libs=libvpx_assembly_arm.a --target=aarch64-linux-android21 -Wl,-mllvm,-enable-machine-outliner=never -Werror -Wl,--warn-shared-textrel -Wl,-O2 -Wl,--gc-sections -Wl,--strip-debug -nostdlib++ --sysroot=../../third_party/android_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot -B../../third_party/android_ndk/toolchains/llvm/prebuilt/linux-x86_64 -Wl,--warn-shared-textrel -fprofile-instr-generate -Wl,--version-script=../../build/android/android_only_jni_exports.lst -Wl,-wrap,calloc -Wl,-wrap,free -Wl,-wrap,malloc -Wl,-wrap,memalign -Wl,-wrap,posix_memalign -Wl,-wrap,pvalloc -Wl,-wrap,realloc -Wl,-wrap,valloc -Wl,--dynamic-linker,/system/bin/linker64 -o "./lib.unstripped/libstandalonelibwebviewchromium.so" @"./libstandalonelibwebviewchromium.so.rsp" ld.lld: error: thunk creation not converged clang: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed. "thunk creation not converged" lld error Here is a build configuration. gn args: ffmpeg_branding = "Chrome" is_component_build = false is_debug = false proprietary_codecs = true strip_absolute_paths_from_debug_symbols = true strip_debug_info = true symbol_level = 1 target_cpu = "arm64" target_os = "android" use_goma = true use_clang_coverage = true autoninja -C out/Release android_webview/test:libstandalonelibwebviewchromium or autoninja -C out/Release webview_instrumentation_apk -- 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
