[llvm-bugs] [Bug 38417] New: clang: python bindings, test_code_complete_availability fails
https://bugs.llvm.org/show_bug.cgi?id=38417
Bug ID: 38417
Summary: clang: python bindings,
test_code_complete_availability fails
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mgo...@gentoo.org
CC: llvm-bugs@lists.llvm.org
Blocks: 38406
Created attachment 20633
--> https://bugs.llvm.org/attachment.cgi?id=20633&action=edit
dev-python:clang-python-7.0.:20180802-074944.log
This is a regression since 6.0*.
==
FAIL: test_code_complete_availability
(tests.cindex.test_code_completion.TestCodeCompletion)
--
Traceback (most recent call last):
File
"/var/tmp/portage/dev-python/clang-python-7.0./work/clang-python-7.0./bindings/python/tests/cindex/test_code_completion.py",
line 70, in test_code_complete_availability
self.check_completion_results(cr, expected)
File
"/var/tmp/portage/dev-python/clang-python-7.0./work/clang-python-7.0./bindings/python/tests/cindex/test_code_completion.py",
line 14, in check_completion_results
self.assertIn(c, completions)
AssertionError: "{'const', TypedText} || Priority: 40 || Availability:
Available || Brief comment: None" not found in ["{'P', TypedText} || Priority:
50 || Availability: Available || Brief comment: None", "{'Q', TypedText} ||
Priority: 50 || Availability: Available || Brief comment: None", "{'namespace',
TypedText} | {' ', HorizontalSpace} | {'name', Placeholder} | {'=', Equal} |
{'namespace', Placeholder} || Priority: 40 || Availability: Available || Brief
comment: None", "{'using', TypedText} | {' ', HorizontalSpace} | {'namespace',
Text} | {' ', HorizontalSpace} | {'identifier', Placeholder} || Priority: 40 ||
Availability: Available || Brief comment: None", "{'asm', TypedText} | {'(',
LeftParen} | {'string-literal', Placeholder} | {')', RightParen} || Priority:
40 || Availability: Available || Brief comment: None", "{'typedef', TypedText}
| {' ', HorizontalSpace} | {'type', Placeholder} | {' ', HorizontalSpace} |
{'name', Placeholder} || Priority: 40 || Availability: Available || Brief
comment: None", "{'using', TypedText} | {' ', HorizontalSpace} | {'qualifier',
Placeholder} | {'::', Text} | {'name', Placeholder} || Priority: 40 ||
Availability: Available || Brief comment: None", "{'extern', TypedText} ||
Priority: 40 || Availability: Available || Brief comment: None", "{'static',
TypedText} || Priority: 40 || Availability: Available || Brief comment: None",
"{'inline', TypedText} || Priority: 40 || Availability: Available || Brief
comment: None", "{'short', TypedText} || Priority: 50 || Availability:
Available || Brief comment: None", "{'long', TypedText} || Priority: 50 ||
Availability: Available || Brief comment: None", "{'signed', TypedText} ||
Priority: 50 || Availability: Available || Brief comment: None", "{'unsigned',
TypedText} || Priority: 50 || Availability: Available || Brief comment: None",
"{'void', TypedText} || Priority: 50 || Availability: Available || Brief
comment: None", "{'char', TypedText} || Priority: 50 || Availability: Available
|| Brief comment: None", "{'int', TypedText} || Priority: 50 || Availability:
Available || Brief comment: None", "{'float', TypedText} || Priority: 50 ||
Availability: Available || Brief comment: None", "{'double', TypedText} ||
Priority: 50 || Availability: Available || Brief comment: None", "{'enum',
TypedText} || Priority: 50 || Availability: Available || Brief comment: None",
"{'struct', TypedText} || Priority: 50 || Availability: Available || Brief
comment: None", "{'union', TypedText} || Priority: 50 || Availability:
Available || Brief comment: None", "{'const', TypedText} || Priority: 50 ||
Availability: Available || Brief comment: None", "{'volatile', TypedText} ||
Priority: 50 || Availability: Available || Brief comment: None", "{'bool',
TypedText} || Priority: 50 || Availability: Available || Brief comment: None&quo
[llvm-bugs] [Bug 38342] vectorized f64->i32 loses bits in f32 intermediate
https://bugs.llvm.org/show_bug.cgi?id=38342 David Bolvansky changed: What|Removed |Added Status|ASSIGNED|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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 38342, which changed state. Bug 38342 Summary: vectorized f64->i32 loses bits in f32 intermediate https://bugs.llvm.org/show_bug.cgi?id=38342 What|Removed |Added Status|ASSIGNED|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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37872] Instcombine: transform shl(inexact shr(x)) with different constant shifts.
https://bugs.llvm.org/show_bug.cgi?id=37872 Bug 37872 depends on bug 31275, which changed state. Bug 31275 Summary: Binary rotation is not detected after multiplication https://bugs.llvm.org/show_bug.cgi?id=31275 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31275] Binary rotation is not detected after multiplication
https://bugs.llvm.org/show_bug.cgi?id=31275 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||338270 --- Comment #3 from Simon Pilgrim --- Fixed in rL338270 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38418] New: [SLP] "PHI nodes not grouped at top of basic block!" after "SLP Vectorizer" after r338380
https://bugs.llvm.org/show_bug.cgi?id=38418
Bug ID: 38418
Summary: [SLP] "PHI nodes not grouped at top of basic block!"
after "SLP Vectorizer" after r338380
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ilia.tara...@intel.com
CC: llvm-bugs@lists.llvm.org
This test crashes after "SLP Vectorizer" after r338380 :
= nice.cpp
struct b2Vec2
{
b2Vec2 (float x, float y) : x(x), y(y)
{
}
void operator -= (const b2Vec2 & v)
{
x -= v.x;
y -= v.y;
}
float x, y;
};
struct b2Vec3
{
b2Vec3 (int x, int y, int z) : x(0), y(0), z(0)
{
}
float x, y, z;
};
struct b2Mat33
{
b2Vec3 Solve33 (const b2Vec3 & b) const;
b2Vec2 Solve22 (const b2Vec2 & b) const;
};
inline float b2Cross (const b2Vec2 & a, const b2Vec2 & b)
{
return a.x - a.y * b.x;
}
inline b2Vec2 operator * (int s, const b2Vec2 & a)
{
return b2Vec2(s * a.x, s * a.y);
}
struct b2Velocity;
class b2RevoluteJoint
{
void SolveVelocityConstraints (b2Velocity * velocities);
b2Vec3 m_impulse;
bool m_enableLimit;
int m_indexA;
b2Vec2 m_rA;
b2Vec2 m_rB;
int m_invMassA;
int m_invIA;
int m_invIB;
b2Mat33 m_mass;
};
struct b2Velocity
{
b2Vec2 v;
int w;
};
void b2RevoluteJoint:: SolveVelocityConstraints (b2Velocity * velocities)
{
b2Vec2 vA = velocities->v;
int wA = 0;
b2Vec2 vB = velocities->v;
int wB = 0;
int mA = m_invMassA;
float iA = m_invIA, iB = m_invIB;
if (m_enableLimit)
{
b2Vec2 Cdot1 = vB;
b2Vec3 Cdot (0, 0, 0);
b2Vec3 impulse = m_mass.Solve33(Cdot);
int newImpulse = m_impulse.z;
if (newImpulse)
{
b2Vec2 rhs = Cdot1;
b2Vec2 reduced = m_mass.Solve22(rhs);
impulse.x = reduced.x;
impulse.z = m_impulse.z;
} else
{
}
b2Vec2 P (impulse.x, impulse.y);
vA -= mA * P;
wA -= iA * (b2Cross(m_rA, P) + impulse.z);
wB += iB * (b2Cross(m_rB, P));
} else
{
b2Vec2 Cdot = vB;
b2Vec2 impulse = m_mass.Solve22(Cdot);
vA -= impulse;
wA -= iA * b2Cross(m_rA, impulse);
wB += iB * b2Cross(m_rB, impulse);
}
velocities->v = vA;
velocities[m_indexA].w = wA;
velocities->w = wB;
}
===
>>> clang -v
clang version 8.0.0 (trunk 338677)
Target: x86_64-unknown-linux-gnu
Thread model: posix
...
>>> clang++ -c -O2 -ffast-math nice.cpp
PHI nodes not grouped at top of basic block!
%impulse.sroa.6.0 = phi float [ %11, %if.then6 ], [ %call.fca.1.extract,
%if.then ]
label %if.end
fatal error: error in backend: Broken function found, compilation aborted!
clang-8: error: clang frontend command failed with exit code 70 (use -v to see
invocation)
clang version 8.0.0 (trunk 338677)
Target: x86_64-unknown-linux-gnu
Thread model: posix
IR reproducer:
= fine.ll =
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; Function Attrs: uwtable
define dso_local void @foo() local_unnamed_addr align 2 {
br i1 false, label %16, label %1
; :1: ; preds = %0
br i1 undef, label %3, label %2
; :2: ; preds = %1
br label %3
; :3: ; preds = %2, %1
%4 = phi <2 x float> [ undef, %2 ], [ undef, %1 ]
%5 = phi float [ undef, %2 ], [ undef, %1 ]
%6 = extractelement <2 x float> %4, i32 0
%7 = extractelement <2 x float> %4, i32 1
%8 = fmul fast float %6, undef
%9 = fmul fast float %7, undef
%10 = fsub fast float undef, %8
%11 = fsub fast float undef, %9
%12 = fmul fast float undef, %6
%13 = fsub fast float undef, %12
%14 = fmul fast float undef, %6
%15 = fsub fast float undef, %14
br label %17
; :16: ; preds = %0
br label %17
; :17: ; preds = %16, %3
%18 = phi float [ undef, %16 ], [ %10, %3 ]
%19 = phi float [ undef, %16 ], [ %11, %3 ]
%20 = phi float [ undef, %16 ], [ %15, %3 ]
%21 = phi float [ undef, %16 ], [ %13, %3 ]
ret void
}
===
>>> opt fine.ll -verify
>>> opt fine.ll -slp-vectorizer -o fine.opt.ll
PHI nodes not grouped at top of basic block!
%5 = phi float [ undef, %2 ], [ undef, %1 ]
label %3
LLVM ERROR: Broken function found, compilation aborted!
This test started failing after :
r338380 | abataev | 2018-07-31 16:02:43 +0200 (Tue, 31 Jul 2018) | 13 lines
[SLP] Fix PR38339: Inst
[llvm-bugs] [Bug 38307] Handling of "AT>" linkerscript command looks wrong
https://bugs.llvm.org/show_bug.cgi?id=38307 George Rimar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from George Rimar --- r338697 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38419] New: std::filesystem::path::native() should return an std::wstring on Windows
https://bugs.llvm.org/show_bug.cgi?id=38419 Bug ID: 38419 Summary: std::filesystem::path::native() should return an std::wstring on Windows Product: libc++ Version: 7.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: vanboxem.ru...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com As the native path format on Windows is arguably UTF-16 (and MSVC's standard lib does this as well, as does Boost.Filesystem, not sure about libstdc++), std::filesystem::path should obey that choice. Most efficient solution would be to let path use wchar_t throughout, but an acceptable solution would be to convert to the correct type on a call to native(). This ensures compatibility between code written with MSVC compiled against libc++. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38420] New: Unsequenced modifications of variable within a constexpr function used in constant expression context not considered ill-formed
https://bugs.llvm.org/show_bug.cgi?id=38420
Bug ID: 38420
Summary: Unsequenced modifications of variable within a
constexpr function used in constant expression context
not considered ill-formed
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: yaghmour.sha...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Given
constexpr int f(int x) {return x++ + x++;}
int main() {
constexpr int x = 2;
constexpr int y = f(x);
}
clang does not consider the declaration of y ill-formed but I believe it
should.
x++ + x++
is undefined behavior since we have unsequenced modifications to x. See
[intro.execution]p10 http://eel.is/c++draft/intro.execution#10 and this should
be ill-formed in a context requiring a constant expression since undefined
behavior is ill-formed in a constant expression see [expr.cons]p2.6
http://eel.is/c++draft/expr.const#2.6
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38421] New: Assertion `Val && "isa<> used on a null pointer"' failed, since SVN r338464, "[P0936R0] add [[clang::lifetimebound]] attribute"
https://bugs.llvm.org/show_bug.cgi?id=38421 Bug ID: 38421 Summary: Assertion `Val && "isa<> used on a null pointer"' failed, since SVN r338464, "[P0936R0] add [[clang::lifetimebound]] attribute" Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: mar...@martin.st CC: llvm-bugs@lists.llvm.org When compiling Qt for i686 mingw-w64 with the very latest clang, this triggers the assertion 'Val && "isa<> used on a null pointer"'. This happens if clang is built GCC 5.3, but not when it's built in debug mode, and not when built with clang. When this happens, I get a backtrace like this: clang-7: ../include/llvm/Support/Casting.h:106: static bool llvm::isa_impl_cl::doit(const From*) [with To = clang::AttributedType; From = clang::Type]: Assertion `Val && "isa<> used on a null pointer"' failed. Stack dump: 0. Program arguments: /home/martin/code/llvm-bisect/build-with-debug-info/bin/clang-7 -cc1 -triple i686-w64-windows-gnu -emit-obj -mrelax-all -disable-free -main-file-name qwindowsmime-638816.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-ver bose -mconstructor-aliases -target-cpu pentium4 -dwarf-column-info -debugger-tuning=gdb -coverage-notes-file /tmp/foo.gcno -resource-dir /home/martin/code/llvm-bisect/build-with-debug-info/lib/clang/7.0.0 -D UNICODE -internal-isystem /usr/i686-w64-mingw32/include/c++ -internal-isystem /u sr/i686-w64-mingw32/include/c++/i686-w64-mingw32 -internal-isystem /usr/i686-w64-mingw32/include/c++/backward -internal-isystem /usr/i686-w64-mingw32/include/c++/5.3-win32 -internal-isystem /usr/i686-w64-mingw32/include/c++/5.3-win32/i686-w64-mingw32 -internal-isystem /usr/i686-w64-mingw 32/include/c++/5.3-win32/backward -internal-isystem /usr/include/c++/5.3-win32 -internal-isystem /usr/include/c++/5.3-win32/i686-w64-mingw32 -internal-isystem /usr/include/c++/5.3-win32/backward -internal-isystem /usr/lib/gcc/i686-w64-mingw32/5.3-win32/include/c++ -internal-isystem /usr/ lib/gcc/i686-w64-mingw32/5.3-win32/include/c++/i686-w64-mingw32 -internal-isystem /usr/lib/gcc/i686-w64-mingw32/5.3-win32/include/c++/backward -internal-isystem /home/martin/code/llvm-bisect/build-with-debug-info/lib/clang/7.0.0/include -internal-isystem /usr/i686-w64-mingw32/sys-root/mi ngw/include -internal-isystem /usr/i686-w64-mingw32/include -internal-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 0 -fno-use-cxa-atexit -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdwarf-exceptions -fdiagnostics-show-option -o foo.o -x c++ qwindowsmime-638816.cpp 1. /home/martin/clang-nightly/i686-w64-mingw32/include/_mingw.h:552:32: current parser token ';' #0 0x019ee72a llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/martin/code/llvm-bisect/build-with-debug-info/../lib/Support/Unix/Signals.inc:494:0 #1 0x019ecc3c llvm::sys::RunSignalHandlers() /home/martin/code/llvm-bisect/build-with-debug-info/../lib/Support/Signals.cpp:67:0 #2 0x019ecda7 SignalHandler(int) /home/martin/code/llvm-bisect/build-with-debug-info/../lib/Support/Unix/Signals.inc:343:0 #3 0x7fd88aa19390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #4 0x7fd88978b428 gsignal /build/glibc-Cl5G7W/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0 #5 0x7fd88978d02a abort /build/glibc-Cl5G7W/glibc-2.23/stdlib/abort.c:91:0 #6 0x7fd889783bd7 __assert_fail_base /build/glibc-Cl5G7W/glibc-2.23/assert/assert.c:92:0 #7 0x7fd889783c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82) #8 0x008d6aea llvm::isa_impl_cl::doit(clang::Type const*) /home/martin/code/llvm-bisect/build-with-debug-info/../include/llvm/Support/Casting.h:142:0 #9 0x008d6aea llvm::isa_impl_wrap::doit(clang::Type const* const&) /home/martin/code/llvm-bisect/build-with-debug-info/../include/llvm/Support/Casting.h:133:0 #10 0x008d6aea llvm::isa_impl_wrap::doit(clang::Type const* const&) /home/martin/code/llvm-bisect/build-with-debug-info/../include/llvm/Support/Casting.h:125:0 #11 0x008d6aea bool llvm::isa(clang::Type const* const&) (.isra.2083.part.2084) /home/martin/code/llvm-bisect/build-with-debug-info/../include/llvm/Support/Casting.h:144:0 #12 0x02e3b139 bool llvm::isa(clang::Type const* const&) /home/martin/code/llvm-bisect/build-with-debug-info/../tools/clang/lib/Sema/SemaDecl.cpp:6020:0 #13 0x02e3b139 llvm::cast_retty::ret_type llvm::cast(clang::Type const*) /home/martin/code/llvm-bisect/build-with-debug-info/../include/llvm/Support/Casting.h:255:0 #14 0x02e3b139 clang::ConcreteTypeLoc::getTypePtr() const /home/martin/code/llvm-bisect/build-with-debug-info/../tools/clang/include/cl
[llvm-bugs] [Bug 38422] New: Investigate why 3 (disabled) tests hang on AArch64
https://bugs.llvm.org/show_bug.cgi?id=38422 Bug ID: 38422 Summary: Investigate why 3 (disabled) tests hang on AArch64 Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: fuzzer Assignee: unassignedb...@nondot.org Reporter: peter.sm...@linaro.org CC: llvm-bugs@lists.llvm.org This is a follow up from PR38034, where 3 libfuzzer tests were marked unsupported on AArch64 as they were hanging. Ideally we would like to understand why the tests are hanging on AArch64 and fix the underlying cause. The 3 tests marked unsupported are: countertest.test fuzzer-oom.test disable-leaks.test I've investigated a little further to work out why the -timeout flag doesn't abort the test. The -timeout flag is per run of the user callback and not the overall test. As each run of the user callback is very fast (< 100ms) then we are extremely unlikely to hit the 15s timeout. I've checked that -max_total_time works. I've also been able to make the test pass at -O0 and -O1. This makes me suspicious of the conditional instructions like cinc that are present in the -O2 compilation of LLVMFuzzerTestOneInput. It is possible that the code coverage isn't increasing when different paths of the cinc (increment) are being taken and this is causing no new coverage information from being generated. Information copied from PR38034 When I run countertest.test on my Ubuntu 16.04 X86 box I very quickly get: INFO: Seed: 1 INFO: Loaded 1 modules (53 inline 8-bit counters): 53 [0x7e6f00, 0x7e6f35), INFO: Loaded 1 PC tables (53 PCs): 53 [0x5aaed0,0x5ab220), INFO: A corpus is not provided, starting from an empty corpus #2 INITED cov: 4 ft: 5 corp: 1/1b lim: 4 exec/s: 0 rss: 26Mb #10 NEWcov: 8 ft: 9 corp: 2/3b lim: 4 exec/s: 0 rss: 27Mb L: 2/2 MS: 3 CopyPart-ChangeBit-InsertByte- #15 NEWcov: 9 ft: 12 corp: 3/7b lim: 4 exec/s: 0 rss: 27Mb L: 4/4 MS: 5 CopyPart-ShuffleBytes-ShuffleBytes-InsertByte-CrossOver- #1029 NEWcov: 10 ft: 13 corp: 4/11b lim: 4 exec/s: 0 rss: 27Mb L: 4/4 MS: 4 ChangeBinInt-CopyPart-ChangeByte-CrossOver- #1047 REDUCE cov: 10 ft: 13 corp: 4/10b lim: 4 exec/s: 0 rss: 27Mb L: 3/4 MS: 3 CopyPart-CopyPart-EraseBytes- #1088 REDUCE cov: 10 ft: 13 corp: 4/9b lim: 4 exec/s: 0 rss: 27Mb L: 2/4 MS: 1 EraseBytes- #1125 REDUCE cov: 11 ft: 14 corp: 5/10b lim: 4 exec/s: 0 rss: 27Mb L: 1/4 MS: 2 ShuffleBytes-EraseBytes- #1338 REDUCE cov: 11 ft: 15 corp: 6/14b lim: 4 exec/s: 0 rss: 27Mb L: 4/4 MS: 3 InsertByte-CopyPart-ChangeBinInt- #1764 REDUCE cov: 12 ft: 16 corp: 7/16b lim: 4 exec/s: 0 rss: 27Mb L: 2/4 MS: 1 ChangeByte- #3772 NEWcov: 12 ft: 19 corp: 8/22b lim: 6 exec/s: 0 rss: 27Mb L: 6/6 MS: 3 CMP-InsertByte-InsertByte- DE: "seed"- #18577 NEWcov: 12 ft: 20 corp: 9/28b lim: 6 exec/s: 0 rss: 28Mb L: 6/6 MS: 5 CrossOver-ShuffleBytes-ChangeBit-ChangeByte-ChangeBit- BINGO! When I run on aarch64 I get: INFO: Seed: 1 INFO: Loaded 1 modules (12 inline 8-bit counters): 12 [0x609080, 0x60908c), INFO: Loaded 1 PC tables (12 PCs): 12 [0x5c6b40,0x5c6c00), INFO: A corpus is not provided, starting from an empty corpus #2 INITED cov: 4 ft: 6 corp: 1/1b lim: 4 exec/s: 0 rss: 30Mb #10 NEWcov: 4 ft: 7 corp: 2/3b lim: 4 exec/s: 0 rss: 30Mb L: 2/2 MS: 3 CopyPart-ChangeBit-InsertByte- #14 NEWcov: 5 ft: 8 corp: 3/6b lim: 4 exec/s: 0 rss: 30Mb L: 3/3 MS: 4 CopyPart-ShuffleBytes-ShuffleBytes-InsertByte- #17 NEWcov: 5 ft: 9 corp: 4/10b lim: 4 exec/s: 0 rss: 31Mb L: 4/4 MS: 3 InsertByte-EraseBytes-CrossOver- #2029 NEWcov: 5 ft: 10 corp: 5/16b lim: 6 exec/s: 0 rss: 31Mb L: 6/6 MS: 2 CopyPart-CrossOver- #6660 NEWcov: 6 ft: 11 corp: 6/17b lim: 6 exec/s: 0 rss: 31Mb L: 1/6 MS: 1 ChangeByte- #1048576pulse cov: 6 ft: 11 corp: 6/17b lim: 6 exec/s: 349525 rss: 78Mb #2097152pulse cov: 6 ft: 11 corp: 6/17b lim: 6 exec/s: 349525 rss: 125Mb #4194304pulse cov: 6 ft: 11 corp: 6/17b lim: 6 exec/s: 349525 rss: 219Mb #8388608pulse cov: 6 ft: 11 corp: 6/17b lim: 6 exec/s: 335544 rss: 408Mb #16777216 pulse cov: 6 ft: 11 corp: 6/17b lim: 6 exec/s: 328965 rss: 785Mb ... The pulses continue but at a much slower rate. When I print out the printable characters in the output they don't seem to be varying much from: " ((h( (((h( (((h( (((h( 0 U0 U0 U0( U10( ((( T(( 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38423] New: [X86][SSE] Add ISD::MULHS/MULHU vXi64 support
https://bugs.llvm.org/show_bug.cgi?id=38423
Bug ID: 38423
Summary: [X86][SSE] Add ISD::MULHS/MULHU vXi64 support
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: andrea.dibia...@gmail.com, craig.top...@gmail.com,
lebedev...@gmail.com, llvm-bugs@lists.llvm.org,
spatel+l...@rotateright.com
I haven't thoroughly tested this but MULHU should be something like:
define <2 x i64> @mulh_2u64(<2 x i64>, <2 x i64>) {
%3 = and <2 x i64> %0,
%4 = lshr <2 x i64> %0,
%5 = and <2 x i64> %1,
%6 = lshr <2 x i64> %1,
%7 = mul nuw <2 x i64> %6, %4
%8 = mul nuw <2 x i64> %5, %4
%9 = mul nuw <2 x i64> %6, %3
%10 = mul nuw <2 x i64> %5, %3
%11 = and <2 x i64> %8,
%12 = and <2 x i64> %9,
%13 = add nuw nsw <2 x i64> %11, %12
%14 = lshr <2 x i64> %10,
%15 = add nuw nsw <2 x i64> %13, %14
%16 = lshr <2 x i64> %15,
%17 = lshr <2 x i64> %8,
%18 = add <2 x i64> %17, %7
%19 = lshr <2 x i64> %9,
%20 = add <2 x i64> %18, %19
%21 = add <2 x i64> %20, %16
ret <2 x i64> %21
}
mulh_2u64:
vpxor %xmm2, %xmm2, %xmm2
vpblendw $204, %xmm2, %xmm0, %xmm3 # xmm3 =
xmm0[0,1],xmm2[2,3],xmm0[4,5],xmm2[6,7]
vpblendw $204, %xmm2, %xmm1, %xmm4 # xmm4 =
xmm1[0,1],xmm2[2,3],xmm1[4,5],xmm2[6,7]
vpsrlq $32, %xmm0, %xmm0
vpsrlq $32, %xmm1, %xmm1
vpmuludq %xmm0, %xmm1, %xmm5
vpmuludq %xmm3, %xmm1, %xmm1
vpmuludq %xmm0, %xmm4, %xmm0
vpmuludq %xmm3, %xmm4, %xmm3
vpblendw $204, %xmm2, %xmm0, %xmm4 # xmm4 =
xmm0[0,1],xmm2[2,3],xmm0[4,5],xmm2[6,7]
vpblendw $204, %xmm2, %xmm1, %xmm2 # xmm2 =
xmm1[0,1],xmm2[2,3],xmm1[4,5],xmm2[6,7]
vpsrlq $32, %xmm0, %xmm0
vpsrlq $32, %xmm3, %xmm3
vpsrlq $32, %xmm1, %xmm1
vpaddq %xmm2, %xmm4, %xmm2
vpaddq %xmm5, %xmm0, %xmm0
vpaddq %xmm3, %xmm2, %xmm2
vpaddq %xmm1, %xmm0, %xmm0
vpsrlq $32, %xmm2, %xmm2
vpaddq %xmm2, %xmm0, %xmm0
retq
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37776] Invalid optimization with `fmax` and `-inf`
https://bugs.llvm.org/show_bug.cgi?id=37776 Sanjay Patel changed: What|Removed |Added Fixed By Commit(s)||338716 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Sanjay Patel --- https://reviews.llvm.org/rL338716 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38424] New: Vectorizing math calls containing pointers
https://bugs.llvm.org/show_bug.cgi?id=38424 Bug ID: 38424 Summary: Vectorizing math calls containing pointers Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: a.bat...@hotmail.com, hfin...@anl.gov, hideki.sa...@intel.com, llvm-bugs@lists.llvm.org, rob.lougher.l...@gmail.com While veclib can handle vectorizing basic math functions, it seems we likely to struggle with more complex functions that uses a pointer to return some results: e.g. float modff(float arg, float* iptr); void sincosf(float x, float *s, float *c); AFAICT if we try to implement these the vectorizers will convert these into: <4 x float> modff4(<4 x float> arg, <4 x float*> iptr); void sincosf4(<4 x float> x, <4 x float*> s, <4 x float*> c); instead of the more useful: <4 x float> modff4(<4 x float> arg, <4 x float> *iptr); void sincosf4(<4 x float> x, <4 x float> *s, <4 x float> *c); -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38425] New: Backport r338599 to 7.0
https://bugs.llvm.org/show_bug.cgi?id=38425 Bug ID: 38425 Summary: Backport r338599 to 7.0 Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: v...@tsyrklevich.net CC: llvm-bugs@lists.llvm.org Blocks: 38406 r338599 is a fix for https://bugs.llvm.org/show_bug.cgi?id=38200 (X86FastISel did not handle !absolute_symbol GVs correctly.) Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=38406 [Bug 38406] [meta] 7.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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38426] New: [OpenCL C++] Lambda/Functions broken in templates
https://bugs.llvm.org/show_bug.cgi?id=38426
Bug ID: 38426
Summary: [OpenCL C++] Lambda/Functions broken in templates
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: erich.ke...@intel.com
CC: llvm-bugs@lists.llvm.org
as you can see here:
https://godbolt.org/g/PnxFQJ
It appears that some of the OpenCL C++ implementation messes with the
qualifiers of function types, so this breaks. I believe the lambda issue has
to do with address-space modification, but I'm not sure yet.
void func();
template
void foo(Func F) {
F();
}
int main() {
foo(func);
foo([](){});
}
:8:5: error: function cannot be called 'main'
int main() {
^
:9:9: error: taking address of function is not allowed
foo(func);
^
:5:5: error: no matching function for call to object of type '(lambda
at :10:9)'
F();
^
:10:5: note: in instantiation of function template specialization
'foo<(lambda at :10:9)>' requested here
foo([](){});
^
:10:9: note: candidate function not viable: address space mismatch in
'this' argument ('(lambda at :10:9)'), parameter type must be 'const
(lambda at :10:9)'
foo([](){});
^
:10:9: note: conversion candidate of type 'void (*)()'
3 errors generated.
Compiler returned: 1
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37978] Add LLDB repository to Diffusion
https://bugs.llvm.org/show_bug.cgi?id=37978 Jonas Devlieghere changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jonas Devlieghere --- The LLDB repository was added. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38421] Assertion `Val && "isa<> used on a null pointer"' failed, since SVN r338464, "[P0936R0] add [[clang::lifetimebound]] attribute"
https://bugs.llvm.org/show_bug.cgi?id=38421 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Smith --- This was caused by a GCC bug. We've already changed clang to work around the bug. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38427] New: Crash under isLeftShiftResultUnrepresentable
https://bugs.llvm.org/show_bug.cgi?id=38427
Bug ID: 38427
Summary: Crash under isLeftShiftResultUnrepresentable
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: ale...@google.com
CC: llvm-bugs@lists.llvm.org
$ cat test.c
int a;
void b() {
char c = d() - 5;
c == 0;
a -= c;
a == 3;
(long)a << 48;
}
$ ./clang-tidy -checks=-*,clang-analyzer* test.c -- -std=c99
PC: @ 0x55e508f35909 (unknown) llvm::APInt::isSingleWord()
@ 0x55e51723bca8192 FailureSignalHandler()
@ 0x7f36b6d2e9a0 (unknown) (unknown)
@ 0x55e508f393df 32 llvm::APInt::countLeadingZeros()
@ 0x55e51108d060192 isLeftShiftResultUnrepresentable()
@ 0x55e51108c29b224 (anonymous
namespace)::UndefResultChecker::checkPostStmt()
@ 0x55e511676c62192 (anonymous
namespace)::CheckStmtContext::runChecker()
@ 0x55e51166ee44240 expandGraphWithCheckers<>()
@ 0x55e51166e62f208
clang::ento::CheckerManager::runCheckersForStmt()
@ 0x55e5116c61b5 32
clang::ento::CheckerManager::runCheckersForPostStmt()
@ 0x55e5116fef3e608
clang::ento::ExprEngine::VisitBinaryOperator()
@ 0x55e5116b5495384 clang::ento::ExprEngine::Visit()
@ 0x55e5116af75a192 clang::ento::ExprEngine::ProcessStmt()
@ 0x55e5116af2d9160
clang::ento::ExprEngine::processCFGElement()
@ 0x55e5116f811a160 clang::ento::CoreEngine::HandlePostStmt()
@ 0x55e5116f7284160
clang::ento::CoreEngine::dispatchWorkItem()
@ 0x55e5116f6c6d256 clang::ento::CoreEngine::ExecuteWorkList()
@ 0x55e511015328160 clang::ento::ExprEngine::ExecuteWorkList()
@ 0x55e510fdca9b192 (anonymous
namespace)::AnalysisConsumer::ActionExprEngine()
@ 0x55e510fdc3a6192 (anonymous
namespace)::AnalysisConsumer::HandleCode()
@ 0x55e510fd6815288 (anonymous
namespace)::AnalysisConsumer::HandleDeclsCallGraph()
@ 0x55e510fd5807208 (anonymous
namespace)::AnalysisConsumer::runAnalysisOnTranslationUnit()
@ 0x55e510fd4696 48 (anonymous
namespace)::AnalysisConsumer::HandleTranslationUnit()
@ 0x55e511d258d8128
clang::MultiplexConsumer::HandleTranslationUnit()
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38428] New: xor i1 (xor i1 %x, %y), true -> icmp eq i1 %x, %y
https://bugs.llvm.org/show_bug.cgi?id=38428 Bug ID: 38428 Summary: xor i1 (xor i1 %x, %y), true -> icmp eq i1 %x, %y Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: lebedev...@gmail.com CC: llvm-bugs@lists.llvm.org %t = xor i1 %x, %y %r = xor i1 %t, true => %r = icmp eq i1 %x, %y https://godbolt.org/g/52qJrW https://rise4fun.com/Alive/LNo Not sure, is this for instcombine? Stumbled into while trying to come with the sign-change test for sanitizer. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38429] New: Make sure lld-link's /Brepro sets the right "this is not a real timestamp" flags
https://bugs.llvm.org/show_bug.cgi?id=38429 Bug ID: 38429 Summary: Make sure lld-link's /Brepro sets the right "this is not a real timestamp" flags Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org I happened to see this today: https://github.com/dotnet/roslyn/issues/5940 It explains what to do if the pe timestamp field is a hash and not a real timestamp. We should make sure that lld does all this. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38430] New: Preprocessing is much slower than GCC on small files
https://bugs.llvm.org/show_bug.cgi?id=38430 Bug ID: 38430 Summary: Preprocessing is much slower than GCC on small files Product: clang Version: 6.0 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: husseyde...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 20634 --> https://bugs.llvm.org/attachment.cgi?id=20634&action=edit Makefile Clang 6.0.1, installed from Termux repos. GCC 8.2.0, installed from its-pointless.github.io Termux, LG G3 System information: Linux localhost 3.4.113-LineageXTD-R7 #1 SMP PREEMPT Fri Jun 15 20:42:06 CEST 2018 armv7l Android Termux-packages arch: arm Android version: 8.1.0, LineageOS Device manufacturer: LGE Device model: LG-D851 Note that I have gotten similar results on Ubuntu WSL, but I need to do further testing. While preprocessing very large files has a similar result with clang sometimes being faster, clang has terrible performance when invoked many times in a row with small files: For example, cd to your main include directory, and run these shell commands: mkdir -p ~/cpptest I=0 for file in *.h; do echo "#include <$file>" > ~/cpptest/$I.h I=$((I+1)); done Now, put the attached Makefile in ~/cpptest and time make, first with CPP="clang-6.0 -E", make clean, and next with CPP="gcc-8 -E". Remove any lines or files that error and run again. $ time make CPP="clang-6.0 -E" real1m14.787s user0m46.860s sys 0m22.390s $ make clean $ time make CPP="gcc-8 -E" real0.19.910s user0m11.390s sys 0m5.880s $ -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38431] New: "too many template arguments for class template" disallows sensible empty-parameter-pack instantiation
https://bugs.llvm.org/show_bug.cgi?id=38431
Bug ID: 38431
Summary: "too many template arguments for class template"
disallows sensible empty-parameter-pack instantiation
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: tonyele...@hotmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
If I compile this:
template struct X {};
template void f ( X) {}
template struct A { X x; };
int main() {
f<> ( X{} );
A<> a{ X{} };
}
...(with no additional command line flags) I get:
a.cpp:2:38: error: too many template arguments for class template 'X'
template void f ( X) {}
^ ~~
a.cpp:1:28: note: template is declared here
template struct X {};
~~~^
a.cpp:3:38: error: too many template arguments for class template 'X'
template struct A { X x; };
^ ~~
a.cpp:1:28: note: template is declared here
template struct X {};
~~~^
a.cpp:6:5: error: no matching function for call to 'f'
f<> ( X{} );
^~~
3 errors generated.
...but I'm guessing (and GCC 8.2 and GCC trunk apparently agree) that this code
is valid because f() and A can be reasonably instantiated with an empty
parameter pack, as illustrated in main(). I think the error should only come at
the point of any instantiation that actually instantiates X with too many
template arguments.
Godbolt indicates that this happens on 6.0.0 and trunk (338661).
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38432] New: Merge r338569 into the 7.0 branch : AMDGPU: Allow fp32-denormals feature for r600 targets
https://bugs.llvm.org/show_bug.cgi?id=38432 Bug ID: 38432 Summary: Merge r338569 into the 7.0 branch : AMDGPU: Allow fp32-denormals feature for r600 targets Product: new-bugs Version: 7.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jan.ves...@rutgers.edu CC: llvm-bugs@lists.llvm.org Blocks: 38406 Is it OK to merge the following revision(s) to the 7.0 branch? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=38406 [Bug 38406] [meta] 7.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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38433] New: Merge r338610 into the 7.0 branch : AMDGPU/R600: Convert kernel param loads to use PARAM_I_ADDRESS
https://bugs.llvm.org/show_bug.cgi?id=38433 Bug ID: 38433 Summary: Merge r338610 into the 7.0 branch : AMDGPU/R600: Convert kernel param loads to use PARAM_I_ADDRESS Product: new-bugs Version: 7.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jan.ves...@rutgers.edu CC: llvm-bugs@lists.llvm.org Blocks: 38406 Is it OK to merge the following revision(s) to the 7.0 branch? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=38406 [Bug 38406] [meta] 7.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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31399] [CodeGen] suboptimal code for ffs()
https://bugs.llvm.org/show_bug.cgi?id=31399 Craig Topper changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Craig Topper --- The other case has been fixed in r338613 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38434] New: [polly] miscompile due to missing overflow check for isl expressions
https://bugs.llvm.org/show_bug.cgi?id=38434
Bug ID: 38434
Summary: [polly] miscompile due to missing overflow check for
isl expressions
Product: Polly
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Optimizer
Assignee: polly-...@googlegroups.com
Reporter: efrie...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
Consider the following loop:
void a(int* restrict x,int * restrict x2, long long g, long long g2, int n) {
for (int i = 0; i < n; ++i) {
x[i]++;
if (g < 0x4000 - g2/8) x2[i]++;
}
}
polly currently miscompiles this loop. It has no runtime check because polly
correctly computes that "g < 0x4000 - g2/8" can't overflow.
However, isl "simplifies" the condition to "if ((p_0 <= -1 && p_0 + 8 * p_1 <=
36893488147419103224) || (p_0 >= 0 && p_0 + 8 * p_1 <= 36893488147419103231))",
and polly blindly assumes the math will not overflow an i64.
This is a synthetic testcase. (I ran into something sort of similar which
inspired this, but it overflowed in the runtime check instead of miscompiling.)
IR version follows; reproduce with "opt -polly-codegen
-polly-process-unprofitable".
define void @a(i32* noalias nocapture %x, i32* noalias nocapture %x2, i64 %g,
i64 %g2, i32 %n) {
entry:
%cmp10 = icmp sgt i32 %n, 0
br i1 %cmp10, label %for.body.lr.ph, label %for.cond.cleanup
for.body.lr.ph:
%div = sdiv i64 %g2, 8
%sub = sub nsw i64 4611686018427387904, %div
%cmp1 = icmp sgt i64 %sub, %g
%wide.trip.count = zext i32 %n to i64
br label %for.body
for.cond.cleanup:
ret void
for.body:
%indvars.iv = phi i64 [ 0, %for.body.lr.ph ], [ %indvars.iv.next, %for.inc ]
%arrayidx = getelementptr inbounds i32, i32* %x, i64 %indvars.iv
%0 = load i32, i32* %arrayidx, align 4
%inc = add nsw i32 %0, 1
store i32 %inc, i32* %arrayidx, align 4
br i1 %cmp1, label %if.then, label %for.inc
if.then:
%arrayidx3 = getelementptr inbounds i32, i32* %x2, i64 %indvars.iv
%1 = load i32, i32* %arrayidx3, align 4
%inc4 = add nsw i32 %1, 1
store i32 %inc4, i32* %arrayidx3, align 4
br label %for.inc
for.inc:
%indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
%exitcond = icmp eq i64 %indvars.iv.next, %wide.trip.count
br i1 %exitcond, label %for.cond.cleanup, label %for.body
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38431] "too many template arguments for class template" disallows sensible empty-parameter-pack instantiation
https://bugs.llvm.org/show_bug.cgi?id=38431 Richard Smith changed: What|Removed |Added CC||richard-l...@metafoo.co.uk Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Smith --- (In reply to tonyelewis from comment #0) > I'm guessing that this > code is valid because f() and A can be reasonably instantiated with an empty > parameter pack Your guess turns out to be incorrect. See http://eel.is/c++draft/temp#res-8.3: "The program is ill-formed, no diagnostic required, if [...] every valid specialization of a variadic template requires an empty template parameter pack" So Clang is correct to diagnose this. (And the other compilers are correct to accept it if they so choose.) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38435] New: [ARM]
https://bugs.llvm.org/show_bug.cgi?id=38435 Bug ID: 38435 Summary: [ARM] Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: japarici...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 20635 --> https://bugs.llvm.org/attachment.cgi?id=20635&action=edit Output of --reproduce These are the input object files. Observe the instruction at : `bl <__nop>`. $ arm-none-eabi-objdump -Cd app.o | head -n11 app.o: file format elf32-littlearm Disassembly of section .text.main: : 0: be00bkpt0x 2: f7ff fffe bl 0 <__nop> 6: be00bkpt0x 8: e7fdb.n 6 $ arm-none-eabi-objdump -Cd libasm.a In archive libasm.a: asm.o: file format elf32-littlearm Disassembly of section .text: <__nop>: 0: 4770bx lr When linking with LLD, becomes `blx 850`. This instruction causes a HardFault (SIGILL like) exception when executed. (AIUI the argument of BLX should be a register, not an address) $ lld -flavor gnu app.o -o app --gc-sections -L . -Bstatic --whole-archive -lasm --no-whole-archive -Tlink.x -Bdynamic --reproduce repro.tar $ arm-none-eabi-objdump -Cd app | head -n11 app: file format elf32-littlearm Disassembly of section .text: 0840 : 840: be00bkpt0x 842: f000 e806 blx 850 846: be00bkpt0x 848: e7fdb.n 846 When linking with GNU LD, becomes `bl 852`. This program executes without raising an exception. $ arm-none-eabi-ld app.o -o app --gc-sections -L . -Bstatic --whole-archive -lasm --no-whole-archive -Tlink.x -Bdynamic $ arm-none-eabi-objdump -Cd app | head -n11 app: file format elf32-littlearm Disassembly of section .text: 0840 : 840: be00bkpt0x 842: f000 f806 bl 852 <__nop> 846: be00bkpt0x 848: e7fdb.n 846 Version information: LLVM: https://github.com/llvm-mirror/llvm/commit/0b5d0cfa8e55ac076285efb25e102597751db49c LLD: https://github.com/llvm-mirror/lld/commit/bcfc39dfc8e40fd7744828abfb4ae4f9e69dc32b GNU LD: 2.31 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
