[llvm-bugs] [Bug 46018] flang when invoked without options just hangs [instead of providing an error message]
https://bugs.llvm.org/show_bug.cgi?id=46018 Richard Barton changed: What|Removed |Added Status|NEW |RESOLVED CC||richard.bar...@arm.com Resolution|--- |FIXED --- Comment #2 from Richard Barton --- Flang now prints a message explaining what is happening: > flang Enter Fortran source Use EOF character (^D) to end file As Steve says, the new driver will not have this behaviour and not show this 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47416] New: [x86] Failure to remove all statements in function that doesn't return anything but should
https://bugs.llvm.org/show_bug.cgi?id=47416
Bug ID: 47416
Summary: [x86] Failure to remove all statements in function
that doesn't return anything but should
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
int f(int a, int b)
{
if ((a < 4 && b == 'r') || (a == 1 && (b == 'h' || b == 'i')) || (a == 2))
a = b;
}
Compiling this results in this assembly output:
f(int, int):
cmp edi, 1
It should be possible to remove the `cmp edi, 1` as far as I know. I guess this
isn't really by itself considering the behaviour is undefined anyway but this
behaviour itself seems rather weird.
--
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 47417] New: Class member used in a member function has not yet been instantiated
https://bugs.llvm.org/show_bug.cgi?id=47417 Bug ID: 47417 Summary: Class member used in a member function has not yet been instantiated Product: new-bugs Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: lozanb...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 23927 --> https://bugs.llvm.org/attachment.cgi?id=23927&action=edit Minimal case that describes the issue If in a template class we have a constexpr member function which also has 'used' attribute, then in the function we cannot use member variables which are declared below the member function. In such a case, we'll get the following error: error: no member 'X' in 'Y'; it has not yet been instantiated If we move the declaration of the member variables above the function definition, then everything works properly. Also, if we remove constexpr or __attribute__((used)) then it works properly. -- 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 47418] New: Destructor not called when returning object from template class method
https://bugs.llvm.org/show_bug.cgi?id=47418 Bug ID: 47418 Summary: Destructor not called when returning object from template class method Product: clang Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: tavplu...@gmail.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 23928 --> https://bugs.llvm.org/attachment.cgi?id=23928&action=edit minimized code to reproduce a bug, version 2 LeakSanitizer and valgrind report a strange memory leak when building the following code with clang. No leaks are found when building it with gcc. Seems like it's a bug in clang and some destructor is not called. Original code: https://github.com/ClickHouse/ClickHouse/pull/14295 See attached file with minimized code. How to reproduce: $ clang++-10 -v clang version 10.0.0-4ubuntu1~18.04.2 Target: x86_64-pc-linux-gnu ... $ clang++-10 -std=c++17 -fsanitize=address minimized2.cpp $ ./a.out 0 ctor 7ffe1e6d8920 copy 60300010 move 60300040 dtor 60300010 dtor 7ffe1e6d8920 dtor 60300040 1 ctor 7ffe1e6d8920 copy 60300070 move 603000a0 dtor 7ffe1e6d8920 dtor 603000a0 2 ctor 7ffe1e6d8920 copy 603000d0 move 60300100 dtor 603000d0 dtor 7ffe1e6d8920 dtor 60300100 3 = ==3408==ERROR: LeakSanitizer: detected memory leaks Direct leak of 32 byte(s) in 1 object(s) allocated from: #0 0x4c43dd in operator new(unsigned long) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4c43dd) #1 0x4ca50b in __gnu_cxx::new_allocator::allocate(unsigned long, void const*) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4ca50b) #2 0x4ca4b3 in std::allocator_traits >::allocate(std::allocator&, unsigned long) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4ca4b3) #3 0x4ca3f2 in std::_Vector_base >::_M_allocate(unsigned long) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4ca3f2) #4 0x4c9e6f in void std::vector >::_M_range_initialize(Elem const*, Elem const*, std::forward_iterator_tag) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4c9e6f) #5 0x4c7f09 in std::vector >::vector(std::initializer_list, std::allocator const&) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4c7f09) #6 0x4ccb51 in TableFunctionTemplate::getActualTableStructure() const (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4ccb51) #7 0x4c7028 in main (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4c7028) #8 0x7f4eae5d5b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 Indirect leak of 42 byte(s) in 1 object(s) allocated from: #0 0x4c43dd in operator new(unsigned long) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4c43dd) #1 0x4c949b in __gnu_cxx::new_allocator::allocate(unsigned long, void const*) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4c949b) #2 0x4c93e3 in std::allocator_traits >::allocate(std::allocator&, unsigned long) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4c93e3) #3 0x4c8ffb in std::__cxx11::basic_string, std::allocator >::_M_create(unsigned long&, unsigned long) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4c8ffb) #4 0x4c8a53 in void std::__cxx11::basic_string, std::allocator >::_M_construct(char const*, char const*, std::forward_iterator_tag) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4c8a53) #5 0x4c884b in void std::__cxx11::basic_string, std::allocator >::_M_construct_aux(char const*, char const*, std::__false_type) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4c884b) #6 0x4c85f4 in void std::__cxx11::basic_string, std::allocator >::_M_construct(char const*, char const*) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4c85f4) #7 0x4c8475 in std::__cxx11::basic_string, std::allocator >::basic_string >(char const*, std::allocator const&) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4c8475) #8 0x4ca819 in Print::Print(Print const&) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4ca819) #9 0x4ca6fc in Elem::Elem(Elem const&) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4ca6fc) #10 0x4ca67c in void std::_Construct(Elem*, Elem const&) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4ca67c) #11 0x4ca5ae in Elem* std::__uninitialized_copy::__uninit_copy(Elem const*, Elem const*, Elem*) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4ca5ae) #12 0x4ca568 in Elem* std::uninitialized_copy(Elem const*, Elem const*, Elem*) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4ca568) #13 0x4ca448 in Elem* std::__uninitialized_copy_a(Elem const*, Elem const*, Elem*, std::allocator&) (/home/avtokmakov/ch/llvm-bugreport/a.out+0x4ca448) #14 0x4c9f76 in void std::vector >::_M_range_initialize(Elem const*, Elem const*, std
[llvm-bugs] [Bug 47419] New: teams construct in implicit parallel has incorrect number of threads/teams
https://bugs.llvm.org/show_bug.cgi?id=47419
Bug ID: 47419
Summary: teams construct in implicit parallel has incorrect
number of threads/teams
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Runtime Library
Assignee: unassignedb...@nondot.org
Reporter: jacob.weight...@hpe.com
CC: llvm-bugs@lists.llvm.org
Consider the following program:
```
#include
#include
int main(void) {
printf("num_teams = %d\n", omp_get_num_teams());
printf("num_threads = %d\n", omp_get_num_threads());
#pragma omp teams num_teams(4)
{
if(omp_get_team_num() == 0) {
printf("num_teams = %d\n", omp_get_num_teams());
printf("num_threads = %d\n", omp_get_num_threads());
}
printf("team: %d; thread: %d\n",
omp_get_team_num(),
omp_get_thread_num());
}
}
```
At present, Clang prints out (up to the ordering of the print statements):
```
num_teams = 1
num_threads = 1
num_teams = 4
num_threads = 12
team: 0; thread: 0
team: 1; thread: 0
team: 2; thread: 0
team: 3; thread: 0
```
The OpenMP 5.0 spec (section 2.7) states that
> The teams construct creates a league of initial teams and the initial thread
> in each team executes the region.
and (section 3.2.2):
> The omp_get_num_threads routine returns the number of threads in the current
> team.
The latter print statements indicate that the num_teams clause is respected,
and there is 1 thread per team. Therefore, one should expect that
omp_get_num_threads should return 1 inside of the teams region.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 25213 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in IntExprEvaluator::VisitBinaryOperator
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 25213 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in IntExprEvaluator::VisitBinaryOperator https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25213#c1 ClusterFuzz testcase 5013034995810304 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202009030629:202009040608 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 25214 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::FunctionProtoType::getExceptionSpecInfo
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 25214 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::FunctionProtoType::getExceptionSpecInfo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25214#c1 ClusterFuzz testcase 5660612062085120 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202009030629:202009040608 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47420] New: [SystemZ] '0 == memcmp(...)' not optimized anymore
https://bugs.llvm.org/show_bug.cgi?id=47420
Bug ID: 47420
Summary: [SystemZ] '0 == memcmp(...)' not optimized anymore
Product: libraries
Version: trunk
Hardware: PC
URL: https://godbolt.org/z/q45ocv
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: SystemZ
Assignee: unassignedb...@nondot.org
Reporter: slavomir.kuc...@broadcom.com
CC: llvm-bugs@lists.llvm.org, uweig...@de.ibm.com
Starting with LLVM 9, the following code
int test1(const char* l, const char* r) {
return memcmp(l,r,2) == 0;
}
is basically transformed into
int test1(const char* l, const char* r) {
return bcmp(l,r,2) == 0;
}
which is not optimized by the SystemZ backend anymore - an actual function call
is generated.
https://godbolt.org/z/q45ocv
--
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 47421] New: Clang should provide annotations to force or verify tail call optimization
https://bugs.llvm.org/show_bug.cgi?id=47421 Bug ID: 47421 Summary: Clang should provide annotations to force or verify tail call optimization Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: C Assignee: unassignedclangb...@nondot.org Reporter: maxime.chevalierboisv...@shopify.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk It's possible to use tail calls to implement bytecode interpreters in C/C++ in a way that is much cleaner than with computed GOTOs, and potentially more efficient as well. This is because, with computed GOTOs, you end up with a large function body with very many labeled code blocks, such that every code block can potentially jump to every other. This makes it hard for any compiler to do register allocation effectively. With tail calls, you can define a tail-recursive function for every opcode in your interpreter such that every instruction simply calls the next one. Tail calls also potentially give us a clean ABI (function call boundaries) where an interpreter could efficiently dispatch to code generated by a JIT compiler. However, this is only possible if one can ensure that tail recursion is in fact optimized by the C/C++ compiler. Clang currently does a fairly good job at optimizing tail calls, however, it's not something developers can rely on. It happens behind the scenes, and to know whether tail call optimization was performed or not, one has to carefully study the disassembly. In our case, we have tried to convert the Ruby interpreter to a tail recursive implementation, and found that tail call optimization was performed for some, but not all Ruby opcodes. The Ruby codebase is very large, which makes it difficult to tell which opcodes did not get optimized and why. The usefulness of tail call optimization is clearly recognized in other programming languages, but the fact that we currently can't rely on them severely limits their usefulness. It would be very desirable to have some kind of annotation to force the compiler to make specific function calls into tail calls (eg: must_tail), or to force every control flow path leaving a given function to become tail calls, or to at least produce a compilation error if this cannot be done, so that the outcome is visible to the programmer. I believe it's in the spirit of C to allow "unsafe" operations to be performed if the programmer specifies this is what must happen, and so forcing tail calls seems acceptable to me, so long as function call signatures are compatible, but if that isn't possible, at least forcing a compiler error message (or even just a warning) to be produced would already be a useful step forward. -- 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 47422] New: Avoiding the destructor in C++17 mode miscompilation
https://bugs.llvm.org/show_bug.cgi?id=47422 Bug ID: 47422 Summary: Avoiding the destructor in C++17 mode miscompilation Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: kutdan...@yandex.ru CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org https://godbolt.org/z/5WTvox After "1" in the output the destructor is called only twice in C++17 mode. This leads to a lead In <=C++14 and in gcc it works. I don't see any violations of the standard there Probably it was like this since C++17 support -- 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 47423] New: [PowerPC] Overloads of vec_cmpne in altivec.h incorrectly guarded for Power9
https://bugs.llvm.org/show_bug.cgi?id=47423
Bug ID: 47423
Summary: [PowerPC] Overloads of vec_cmpne in altivec.h
incorrectly guarded for Power9
Product: clang
Version: 10.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Headers
Assignee: unassignedclangb...@nondot.org
Reporter: nemanja.i@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
According to Appendix A of the ELFv2 ABI specification, the availability of the
vec_cmpne overloads is not predicated on ISA 3.0. However, the implementation
in Clang is.
To reproduce:
#include
vector bool int test(vector signed int a, vector signed int b) {
return vec_cmpne(a, b);
}
Compile:
$ clang -O3 b.c -S -o - -mcpu=power8
b.c:3:10: warning: implicit declaration of function 'vec_cmpne' is invalid in
C99 [-Wimplicit-function-declaration]
return vec_cmpne(a, b);
^
b.c:3:10: error: returning 'int' from a function with incompatible result type
'__vector __bool unsigned int' (vector of 4 'unsigned int' values)
return vec_cmpne(a, b);
^~~
1 warning and 1 error generated.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 23377 in oss-fuzz: llvm:clang-fuzzer: ASSERT: E->isRValue() && "missing lvalue-to-rvalue conv in bool condition"
Updates: Labels: Deadline-Approaching Comment #1 on issue 23377 by sheriffbot: llvm:clang-fuzzer: ASSERT: E->isRValue() && "missing lvalue-to-rvalue conv in bool condition" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23377#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47424] New: false-positive [clang-analyzer-deadcode.DeadStores] with reference
https://bugs.llvm.org/show_bug.cgi?id=47424
Bug ID: 47424
Summary: false-positive [clang-analyzer-deadcode.DeadStores]
with reference
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: tiagomacar...@gmail.com
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
With the following code [clang-analyzer-deadcode.DeadStores] will report
'b=true' as never read, but ~S() will read it.
https://godbolt.org/z/dqfrc1
#include
struct S {
const bool& m_b;
S(bool const& b) : m_b(b) {}
~S() { std::cout << m_b; }
};
int main() {
bool b = false;
S s(b);
b = true;
}
--
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 47173] explicit type for variables in function declaration not recognized
https://bugs.llvm.org/show_bug.cgi?id=47173 Nichols A. Romero changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #2 from Nichols A. Romero --- Thanks for the fix Peter. -- 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 47425] New: return type for isnan instrinsic math function causes problem in conditional
https://bugs.llvm.org/show_bug.cgi?id=47425 Bug ID: 47425 Summary: return type for isnan instrinsic math function causes problem in conditional Product: flang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedb...@nondot.org Reporter: narom...@anl.gov CC: david.tr...@arm.com, jper...@nvidia.com, kirankuma...@gmail.com, llvm-bugs@lists.llvm.org, sscalp...@nvidia.com Created attachment 23930 --> https://bugs.llvm.org/attachment.cgi?id=23930&action=edit conditional on return value is isnan Assuming isnan is a standard Fortran intrinsic math function, this short program fails to compile with Flang. It compiles successfully with PGI, ifort, and gfortran. [naromero@naromero-desktop bugs]$ /nfs/gce/projects/naromero-workspace/llvm-master/bin/flang -c testisnan.F testisnan.F:6:11: error: Must have LOGICAL type, but is INTEGER(4) if (isnan(dum)) write (*,*) 'dum is NaN' ^^ -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 25429 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-09-05 Type: Bug New issue 25429 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25429 Detailed Report: https://oss-fuzz.com/testcase?key=5656315123466240 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffcd46d0fc8 Crash State: clang::DeclContext::lookup LookupDirect CppNamespaceLookup Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202009010628:202009020614 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5656315123466240 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47426] New: _mm_load_si128() expands to two movq's.
https://bugs.llvm.org/show_bug.cgi?id=47426
Bug ID: 47426
Summary: _mm_load_si128() expands to two movq's.
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: anmpa...@cisco.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
Given the test:
1 #include
2 #include
3 #include
4
5 uint32_t read_128b(__m128i *ptr)
6 {
7 __m128i val = _mm_load_si128(ptr);
8 return ((uint32_t *) &val)[0]|
9 ((uint32_t *) &val)[1]|
10 ((uint32_t *) &val)[2]|
11 ((uint32_t *) &val)[3];
12 }
With clang version 12.0.0 (https://github.com/llvm/llvm-project.git
4eef14f9780d9fc9a88096a3cabd669bcfa02bbc 09/04/2020) the _mm_load_si128()
is translated at '-O2 -msse2' to:
movq(%rdi), %rcx
movq8(%rdi), %rdx
This is not in accordance with Ref. [0], which specifies:
Synopsis
__m128i _mm_load_si128 (__m128i const* mem_addr)
#include
Instruction: movdqa xmm, m128
CPUID Flags: SSE2
(Note: gcc-10.1.0 and icc.16.0.5.027b both generate a movdqa as expected).
The accesses at lines 8 thro' 11 cause the problematic 64-bit loads; modifying
the code (see marker: '<<<') so that:
1 #include
2 #include
3 #include
4
5 uint32_t read_128b(__m128i *ptr, uint8_t index) <<<
6 {
7 __m128i val = _mm_load_si128(ptr);
8 return ((uint32_t *) &val)[index];<<<
9 }
- we see that the _mm_load_si128() is translated to: movaps (%rdi), %xmm0
as expected. (Note: Per Ref. [1], movaps and movdqa are interchangeable).
The _mm_load_si128() builtin is defined in: clang/lib/Headers/emmintrin.h
with attribute: __min_vector_width__(128)
#define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__, \
__target__("sse2"), \
__min_vector_width__(128)))
...
/// ...
/// This intrinsic corresponds to the VMOVDQA / MOVDQA instruction.
/// ...
static __inline__ __m128i __DEFAULT_FN_ATTRS
_mm_load_si128(__m128i const *__p)
{
return *__p;
}
Per Ref. [2], "This attribute may be attached to a function and informs the
backend that this function desires vectors of at least this width to be
generated. ... This attribute is meant to be a hint to control target
heuristics that may generate narrower vectors than what the target hardware
supports." So, it is reasonable to expect that the vector pointed to by '__p'
is always treated in its 128-bit entirety.
_mm_load_si128() is converted to the following optimal LLVM IR:
; Function Attrs: alwaysinline norecurse nounwind readonly uwtable
define internal fastcc <2 x i64> @_mm_load_si128(<2 x i64>* nocapture readonly
%__p) unnamed_addr #2 {
entry:
%0 = load <2 x i64>, <2 x i64>* %__p, align 16, !tbaa !2
ret <2 x i64> %0
}
The Function Integration/Inlining pass inlines this _mm_load_si128() body into
read_128b():
%0 = load <2 x i64>, <2 x i64>* %ptr, align 16, !tbaa !2
However, (owing to the 32-bit accesses in the subsequent |-expression),
the Combine redundant instructions pass converts this load to:
%1 = load i128, i128* %0, align 16, !tbaa !2
- which, the X86 DAG->DAG Instruction Selection pass converts to:
%1:gr64 = MOV64rm %0:gr64, 1, $noreg, 0, $noreg :: \
(load 8 from %ir.0, align 16, !tbaa !2)
%2:gr64 = MOV64rm %0:gr64, 1, $noreg, 8, $noreg :: \
(load 8 from %ir.0 + 8, align 16, !tbaa !2)
- the problematic 64-bit loads.
Per Ref. [3]/Rationale: "Platforms may rely on volatile loads and stores of
natively supported data width to be executed as single instruction. For
example, in C this holds for an l-value of volatile primitive type with native
hardware support, but not necessarily for aggregate types. The frontend
upholds
these expectations, which are intentionally unspecified in the IR. The rules
above ensure that IR transformations do not violate the frontend’s contract
with the language."
Thus, the LLVM IR generated for the loads and stores in a function with the
__attribute__((min_vector_width(width))) that operate on vectors 'width'-wide
should satisfy the properties:
a. at-least 'width'-wide
b. marked 'volatile' (to prevent any subsequent phases from splitting them
up)
Assuming that property-a is correctly maintained by the front-end; the problem
reduces to ensuring that property-b holds.
Hand-modifying the generated LLVM IR:
define internal <2 x i64> @_mm_load_si128(<2 x i64>* %__p) #2 {
entry:
! %0 = load <2 x i64>, <2 x i64>* %__p, align 16
ret <2 x i64> %0
}
--- 1,11
defi
