[llvm-bugs] [Bug 47793] New: Miscompilation of single loop with two assignments
https://bugs.llvm.org/show_bug.cgi?id=47793 Bug ID: 47793 Summary: Miscompilation of single loop with two assignments Product: new-bugs Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tuom.lar...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 24044 --> https://bugs.llvm.org/attachment.cgi?id=24044&action=edit Example The example shows a discrepancy when processing two arrays at once in single loop and processing each array in a separate loop. It should not matter whether one array is processed first or both arrays are processed simultaneously but the later case gives wrong answer. More precise instructions on how to reproduce the behaviour could be found in the linked example. It only happens with clang coming with macOS Catalina (sorry, I don't know which version it is as Apple apparently uses different version numbers as llvm.org) Perhaps the single loop gets optimised too aggressively but I'm really guessing here. Please find the example below. -- 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 47794] New: missed optimization to use MOVS to copy arrays
https://bugs.llvm.org/show_bug.cgi?id=47794
Bug ID: 47794
Summary: missed optimization to use MOVS to copy arrays
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: enh...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
For example the following code generates `MOVSQ` with GCC, and `call memcpy`
with Clang:
https://godbolt.org/z/15bPh5
```
#include
#include
#include
using namespace std;
random_device rd;
int main()
{
std::array a;
std::array b;
for(auto& e : a) { // prevent optimizing away
e = rd();
}
for(int i=0; i < a.size(); ++i) { // copy
b[i] = a[i];
}
for(auto const& e : b) { // prevent optimizing away
cout << e;
}
}
```
It seems that using MOVSQ is about 4-5 times faster:
Clang: https://quick-bench.com/q/LK5SmbOYZc8T-Kvy48jsf1tAL9w
GCC: https://quick-bench.com/q/qG8ApWJV7Ad-ghub2of6C_WWMYM
--
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 47793] Miscompilation of single loop with two assignments
https://bugs.llvm.org/show_bug.cgi?id=47793 Florian Hahn changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED CC||florian_h...@apple.com --- Comment #3 from Florian Hahn --- (In reply to Tuom Larsen from comment #2) > Sorry, I'm new to all this. Could you please point me to where you see the > undefined behaviour? I'm just copying bunch of uint16_t's. Even if I could > use memcpy, who knows what memcpy would in fact do and this is what broke(?). The problem is likely that you are accessing the same memory through uint16_t and uint64_t pointers. Clang assumes 'strict aliasing' by default IIRC and under those rules I think that is not allowed. See http://dbp-consulting.com/tutorials/StrictAliasing.html for an explanation. Please try your example with -fno-strict-aliasing. Your code should work as expected with that option. If not, please re-open the issue. -- 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 47795] New: [InstCombine] Failure to form funnel shifts for (shl ShVal, X) | (lshr ShVal, (Width - x)) when (Width - x) has multiple uses like for another funnel shift
https://bugs.llvm.org/show_bug.cgi?id=47795
Bug ID: 47795
Summary: [InstCombine] Failure to form funnel shifts for (shl
ShVal, X) | (lshr ShVal, (Width - x)) when (Width - x)
has multiple uses like for another funnel shift
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: craig.top...@gmail.com
CC: llvm-bugs@lists.llvm.org
As shown here https://skanthak.homepage.t-online.de/llvm.html#case21 or
https://godbolt.org/z/s4bGGs
Removing the m_OneUse here
-if (match(R, m_OneUse(m_Sub(m_SpecificInt(Width), m_Specific(L) {
+if (match(R, m_Sub(m_SpecificInt(Width), m_Specific(L {
Allows a funnel shift to be generated in bb.20
I suppose removing this may be bad if the target doesn't support funnel shift
natively?
--
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 47796] New: #pragma weak A = B doesn't handle the case where A is already declared
https://bugs.llvm.org/show_bug.cgi?id=47796
Bug ID: 47796
Summary: #pragma weak A = B doesn't handle the case where A is
already declared
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: richard-l...@metafoo.co.uk
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Testcase:
void f();
void g();
#pragma weak f = g
void h() { f(); }
... asserts in C mode, because it declares two different functions named 'f',
surprising the code that builds the CallExpr in h.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47796] #pragma weak A = B doesn't handle the case where A is already declared
https://bugs.llvm.org/show_bug.cgi?id=47796 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Smith --- *** This bug has been marked as a duplicate of bug 36130 *** -- 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 47789] Clang 10 disallows modifying const member by an unused member function in a templated class; while Clang 9 allows it
https://bugs.llvm.org/show_bug.cgi?id=47789 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Smith --- This is not a bug. The C++ language rules disallow templates that have no valid instantiations, but don't require implementations to diagnose such problems. (Clang always intends to diagnose such cases; what happened between Clang 9 and 10 was that we fixed a bug that incorrectly caused this pattern to result in a dependent class member access. That bugfix then allowed us to diagnose eagerly.) For what it's worth, the EDG frontend also rejects this code in its strict mode. -- 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@lists.llvm.org
https://bugs.llvm.org/show_bug.cgi?id=47797
Bug ID: 47797
Summary: Missing optimization with (var&const)==const
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: blub...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
$ clang -Oz
void t();
void x(int a) { if ((a&1234) == 1234) t(); }
void y(int a) { if (!(1234&~a)) t(); }
Output (x86_64):
x(int): # @x(int)
mov eax, 1234
and edi, eax
cmp edi, eax
je t() # TAILCALL
ret
y(int): # @y(int)
mov eax, 1234
and edi, eax
cmp edi, eax
je t() # TAILCALL
ret
Expected output: `not edi; test edi,1234; je t(); ret` for both, it's one byte
smaller.
It intuitively seems faster too, since and+cmp calculates a less-than flag that
not+test doesn't, but modern x86 performance is quite unintuitive, so who
knows.
Compiler Explorer: https://godbolt.org/z/Yeofdo
--
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 47508] [concepts] requires clause short-circuiting not working
https://bugs.llvm.org/show_bug.cgi?id=47508 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Smith --- *** This bug has been marked as a duplicate of bug 44833 *** -- 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 44677] Concept diagnostics in combination with inheritance are applied at the wrong place/time
https://bugs.llvm.org/show_bug.cgi?id=44677 Richard Smith changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Richard Smith --- The diagnostics here are correct. Line 12: using DBi = Derived; // Should be an error ... is valid. The compiler is not permitted to instantiate Derived here, because a complete type is not required. So there's no way to know that this instantiation would end up being ill-formed. Derived is only instantiated on line 16: DBi dbi; // note - should be error ... because this line requires DBi to be a complete type. So that's why the note points here. If you want better diagnostics here, you can require the template parameter of Derived to be Integral too: https://godbolt.org/z/f7zhqz -- 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 47798] New: invalid reassignment of non-absolute variable 'var_ddq_add'
https://bugs.llvm.org/show_bug.cgi?id=47798 Bug ID: 47798 Summary: invalid reassignment of non-absolute variable 'var_ddq_add' Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: MC Assignee: unassignedb...@nondot.org Reporter: isanb...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 24045 --> https://bugs.llvm.org/attachment.cgi?id=24045&action=edit Example file. This is another example of clang's integrated assembler not being able to assemble .S files in the Linux code base. bug.S is a reduced example. Here's the compilation line: $ clang -Qunused-arguments --target=x86_64-grtev5-linux-gnu -fno-PIE -m64 -Wa,-gdwarf-2 -mfentry -c -o /dev/null bad.S -v clang version google3-trunk (cf5df40c4cf1a53a02ab1d56a488642e3dda8f6d) Target: x86_64-grtev4-linux-gnu Thread model: posix InstalledDir: /usr/local/google/gbuild/tools/google/src/files/327060796/depot/google3/third_party/crosstool/v18/stable/installs/generic/wrappers/../../../toolchain/bin Configuration file: /usr/local/google/gbuild/tools/google/src/files/327060796/depot/google3/third_party/crosstool/v18/stable/installs/generic/wrappers/cfg/x86_64-grtev5-linux-gnu.cfg Found candidate GCC installation: /usr/local/google/gbuild/tools/google/src/files/327060796/depot/google3/third_party/crosstool/v18/stable/installs/generic/wrappers/../../../toolchain/bin/../lib/gcc/x86_64-grtev4-linux-gnu/4.9.x-google Selected GCC installation: /usr/local/google/gbuild/tools/google/src/files/327060796/depot/google3/third_party/crosstool/v18/stable/installs/generic/wrappers/../../../toolchain/bin/../lib/gcc/x86_64-grtev4-linux-gnu/4.9.x-google Candidate multilib: .;@m64 Selected multilib: .;@m64 "/usr/local/google/gbuild/tools/google/src/files/327060796/depot/google3/third_party/crosstool/v18/stable/installs/llvm/bin/clang" -cc1 -triple x86_64-grtev4-linux-gnu -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name bad.S -mrelocation-model static -mframe-pointer=all -fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables -target-cpu x86-64 -fno-split-dwarf-inlining -debugger-tuning=gdb -v -resource-dir /usr/local/google/gbuild/tools/google/src/files/327060796/depot/google3/third_party/crosstool/v18/stable/installs/llvm/lib/clang/google3-trunk -isysroot /usr/local/google/gbuild/tools/google/src/files/327060796/depot/google3/third_party/grte/v5_x86/release/usr/grte/v5 -internal-isystem /usr/local/google/gbuild/tools/google/src/files/327060796/depot/google3/third_party/grte/v5_x86/release/usr/grte/v5/usr/local/include -internal-isystem /usr/local/google/gbuild/tools/google/src/files/327060796/depot/google3/third_party/crosstool/v18/stable/installs/llvm/lib/clang/google3-trunk/include -internal-externc-isystem /usr/local/google/gbuild/tools/google/src/files/327060796/depot/google3/third_party/grte/v5_x86/release/usr/grte/v5/include -internal-externc-isystem /usr/local/google/gbuild/tools/google/src/files/327060796/depot/google3/third_party/grte/v5_x86/release/usr/grte/v5/usr/include -Wno-unused-command-line-argument -fdebug-compilation-dir /usr/local/google/home/morbo/prodkernel-gcc -ferror-limit 19 -mfentry -pthread -fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig -o /tmp/bad-0cac60.s -x assembler-with-cpp bad.S clang -cc1 version google3-trunk based upon LLVM google3-trunk default target x86_64-grtev4-linux-gnu ignoring nonexistent directory "/usr/local/google/gbuild/tools/google/src/files/327060796/depot/google3/third_party/grte/v5_x86/release/usr/grte/v5/usr/local/include" ignoring nonexistent directory "/usr/local/google/gbuild/tools/google/src/files/327060796/depot/google3/third_party/grte/v5_x86/release/usr/grte/v5/usr/include" #include "..." search starts here: #include <...> search starts here: /usr/local/google/gbuild/tools/google/src/files/327060796/depot/google3/third_party/crosstool/v18/stable/installs/llvm/lib/clang/google3-trunk/include /usr/local/google/gbuild/tools/google/src/files/327060796/depot/google3/third_party/grte/v5_x86/release/usr/grte/v5/include End of search list. "/usr/local/google/gbuild/tools/google/src/files/327060796/depot/google3/third_party/crosstool/v18/stable/installs/llvm/bin/clang" -cc1as -triple x86_64-grtev4-linux-gnu -filetype obj -main-file-name bad.S -target-cpu x86-64 -fdebug-compilation-dir /usr/local/google/home/morbo/prodkernel-gcc -dwarf-debug-producer "clang version google3-trunk (cf5df40c4cf1a53a02ab1d56a488642e3dda8f6d)" -dwarf-version=4 -mrelocation-model static -debug-info-kind=limited -dwarf-version=2 --mrelax-relocations -o /dev/null /tmp/bad-0cac60.s :1:15: error: invalid reassignment of non-absolute variable 'var_ddq_add' var_ddq_add = ddq_add_2 ^ :3:4: note: while in macro instantiation setddq %i ^ :11:2: note: while in macro
