[llvm-bugs] [Bug 44692] New: clang reports error from macro for wrong line
https://bugs.llvm.org/show_bug.cgi?id=44692
Bug ID: 44692
Summary: clang reports error from macro for wrong line
Product: clang
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: schopf@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Compiling the attached code produces a misleading error message because the
indicated line is wrong.
Steps to reproduce:
1. Compile this code:
#define ALL_COMMANDS \
CMD(Play) \
CMD(Stop)
struct base {
virtual int Play() = 0;
};
struct foo : public base {
#define CMD(a) \
int a() override { \
return 0; \
}
ALL_COMMANDS
};
Actual result:
test.cpp:15:2: error: only virtual member functions can be marked 'override'
ALL_COMMANDS
^
test.cpp:2:11: note: expanded from macro 'ALL_COMMANDS'
CMD(Play) \
^
test.cpp:11:11: note: expanded from macro '\
CMD'
int a() override { \
^
1 error generated.
Expected result:
The actual error comes from line 3, which is CMD(Stop), and not line 2. This
can be very misleading when trying to fix the error.
This also happens with the latest trunk: https://godbolt.org/z/DUrFwo
--
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 44690] Include guards missing for compression.h
https://bugs.llvm.org/show_bug.cgi?id=44690
Gabor Greif changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED|REOPENED
--- Comment #2 from Gabor Greif ---
(In reply to Jonas Devlieghere from comment #1)
> This code is in debugserver which is macOS-only. We always have
> libcompresion there. Furthermore it entirely separate from the rest of LLDB
> and doesn't read the header that defines HAVE_LIBCOMPRESSION.
>
> I don't think you want to build debugserver for NixOS. It should only be a
> target on Darwin. See tools/CMakeLists.txt:
>
> 13 if (CMAKE_SYSTEM_NAME MATCHES "Darwin")
> 14 add_lldb_tool_subdirectory(darwin-debug)
> 15 if(NOT LLDB_USE_SYSTEM_DEBUGSERVER)
> 16 add_lldb_tool_subdirectory(debugserver)
> 17 endif()
> 18 endif()
Hi Jonas, thanks for your reply!
NixOS and `Nixpkgs` are often confused. The former is a Linux-based OS, the
latter a package collection like fink, macports or homebrew.
Indeed Nixpkgs has a Darwin target, and LLDB is installable on it. I just
looked:
$ ls /nix/store/bypgwpzl5i88ncmr65hnifjlmwp69kj6-lldb-7.1.0/bin/
darwin-debug lldb lldb-argdumper lldb-mi lldb-server lldb-test
Unfortunately LLDB 8 (and later) won't compile from source any more. This is
why I am reaching out.
https://github.com/llvm/llvm-project/blob/release/7.x/lldb/tools/debugserver/source/RNBRemote.cpp
still has the guards, they were removed in
https://github.com/llvm/llvm-project/commit/681f6c2f552fb9b57380f4bfd453e1fc9b6a099e#diff-302e60b129d98a39031cd9f6b2d855c7
I see some options going forward:
- Nixpkgs could patch the file, restoring compilability (somehow)
- Nixpkgs could include libcompression (new package) and depend Darwin `lldb`
on it
- LLVM-project could make `lldb-server` compilable again for sandboxed,
no-compression-lib environments
- Nixpkgs could disable the `llvmPackages_{8,9,10}.lldb` sets.
In any case CMAKE configury should detect the absence of libcompression and
error out early if it is a hard compilation requirement.
--
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 44116] Umbrella: Call site / entry value debug information
https://bugs.llvm.org/show_bug.cgi?id=44116 Bug 44116 depends on bug 44059, which changed state. Bug 44059 Summary: The LLDB test for the entry values will fail due to changes in the compiler https://bugs.llvm.org/show_bug.cgi?id=44059 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 44059] The LLDB test for the entry values will fail due to changes in the compiler
https://bugs.llvm.org/show_bug.cgi?id=44059 Djordje Todorovic changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |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 44693] New: False positive on calling new(std::size_t, std::align_val_t)
https://bugs.llvm.org/show_bug.cgi?id=44693
Bug ID: 44693
Summary: False positive on calling new(std::size_t,
std::align_val_t)
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: cassio.n...@gmail.com
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
Consider:
struct X {
alignas(32) char c;
};
int main() {
X* p = new X; // #1
delete p;
}
compiled with
scan-build clang++ -g -std=c++17 main.cpp
yields warning: Function taking 2 arguments is called with fewer (1)
X* p = new X;"
^
Since X is an over-aligned type, in C++17 the new expression in #1 makes the
compiler to call operator new(std::size_t, std::align_val_t). It seems the
static analyzer believes the compiler behaves as per C++14 and makes a call to
new(std::size_t).
At least the warning could output a more informative message mentioning
over-alignment.
--
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 44694] New: [X86][AVX] Failure to combine to HADDPD
https://bugs.llvm.org/show_bug.cgi?id=44694
Bug ID: 44694
Summary: [X86][AVX] Failure to combine to HADDPD
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: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
https://godbolt.org/z/U2jZo3
#include
__m256d add_pd(__m256d a, __m256d b) {
return __builtin_shufflevector(a, b, -1, 2, 4, 6) +
__builtin_shufflevector(a, b, -1, 3, 5, 7);
}
define <4 x double> @_Z6add_pdDv4_dS_(<4 x double> %0, <4 x double> %1) {
%3 = shufflevector <4 x double> %0, <4 x double> %1, <4 x i32>
%4 = shufflevector <4 x double> %0, <4 x double> %1, <4 x i32>
%5 = fadd <4 x double> %3, %4
ret <4 x double> %5
}
_Z6add_pdDv4_dS_: # @_Z6add_pdDv4_dS_
vperm2f128 $49, %ymm1, %ymm0, %ymm0 # ymm0 = ymm0[2,3],ymm1[2,3]
vinsertf128 $1, %xmm1, %ymm0, %ymm1
vunpcklpd %ymm0, %ymm1, %ymm2 # ymm2 = ymm1[0],ymm0[0],ymm1[2],ymm0[2]
vshufpd $14, %ymm0, %ymm1, %ymm0 # ymm0 = ymm1[0],ymm0[1],ymm1[3],ymm0[3]
vaddpd %ymm0, %ymm2, %ymm0
retq
Which should be combine to:
vperm2f128 $49, %ymm1, %ymm0, %ymm2 # ymm2 = ymm0[2,3],ymm1[2,3]
vinsertf128 $1, %xmm1, %ymm0, %ymm0
vhaddpd %ymm2, %ymm0, %ymm0
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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44695] New: [DebugInfo] Static variables declared inside functions always have the function scope
https://bugs.llvm.org/show_bug.cgi?id=44695
Bug ID: 44695
Summary: [DebugInfo] Static variables declared inside functions
always have the function scope
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: ch.besson...@gmail.com
CC: apra...@apple.com, jdevliegh...@apple.com,
keith.wal...@arm.com, llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
If a static variable is defined inside of some bracketed block in a function,
clang/llvm will handle it as it has the function scope, not the corresponded
bracketed block scope.
Conside the following example:
1 int foo() { return 42; };
2 int main() {
3int a = foo();
4switch(a) {
5case 1: {
6 static const int a = 1;
7 return a;
8}
9case 2: {
10 static const int a = 2;
11 return a;
12}
13}
14 }
Here are 3 'a' variables, all of them have function scope according to the
dwarfdump:
0x002a: DW_TAG_subprogram
DW_AT_low_pc (0x00401120)
DW_AT_high_pc (0x0040117a)
DW_AT_frame_base (DW_OP_reg6 RBP)
DW_AT_name ("main")
DW_AT_decl_file ("temp.cpp")
DW_AT_decl_line (3)
DW_AT_type (0x0081 "int")
DW_AT_external (true)
0x0043: DW_TAG_variable
DW_AT_name ("a")
DW_AT_type (0x007c "const int")
DW_AT_decl_file ("temp.cpp")
DW_AT_decl_line (7)
DW_AT_location (DW_OP_addr 0x402004)
0x0058: DW_TAG_variable
DW_AT_name ("a")
DW_AT_type (0x007c "const int")
DW_AT_decl_file ("temp.cpp")
DW_AT_decl_line (11)
DW_AT_location (DW_OP_addr 0x402008)
0x006d: DW_TAG_variable
DW_AT_location (DW_OP_fbreg -8)
DW_AT_name ("a")
DW_AT_decl_file ("temp.cpp")
DW_AT_decl_line (4)
DW_AT_type (0x0081 "int")
This confuses debuggers: gdb will print 1 for 'a' even on line 4.
Note: gcc-9.2 generates DW_TAG_lexical_block's for the bracketed blocks and
puts static 'a's there, so gdb prints 42 for 'a' on line 4 as expected.
--
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 44696] New: ClangdTests.exe/Hover.All fail on 32-bit windows
https://bugs.llvm.org/show_bug.cgi?id=44696
Bug ID: 44696
Summary: ClangdTests.exe/Hover.All fail on 32-bit windows
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: h...@chromium.org
CC: htmldevelo...@gmail.com,
kadircetinkaya.06...@gmail.com,
llvm-bugs@lists.llvm.org
Blocks: 44555
The problem is that member functions have __attribute__((thiscall)) in the AST
when targeting 32-bit Windows, and the test doesn't expect that.
I wasn't sure how to fix that. Alternatively, maybe the test could have a
target triple so that the AST doesn't vary between host platforms?
[2044/2045] Running the Clangd regression tests
llvm-lit.py: C:/src/llvm.monorepo/llvm\utils\lit\lit\llvm\config.py:342: note:
using clang: c:\src\llvm.monorepo\build.32_2019\bin\clang.exe
-- Testing: 724 tests, 32 workers --
Testing: 0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
FAIL: Clangd Unit Tests :: ./ClangdTests.exe/Hover.All (723 of 724)
TEST 'Clangd Unit Tests :: ./ClangdTests.exe/Hover.All'
FAILED
Note: Google Test filter = Hover.All
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from Hover
[ RUN ] Hover.All
C:\src\llvm.monorepo\clang-tools-extra\clangd\unittests\HoverTests.cpp(1628):
error: Expected: H->Type
Which is: int () __attribute__((thiscall))
To be equal to: Expected.Type
Which is: int ()
Google Test trace:
C:\src\llvm.monorepo\clang-tools-extra\clangd\unittests\HoverTests.cpp(1621):
instance-method x
→ int
// In Foo
int x()
C:\src\llvm.monorepo\clang-tools-extra\clangd\unittests\HoverTests.cpp(1604):
// Method call
struct Foo { int x(); };
int main() {
Foo bar;
bar.^[[x]]();
}
C:\src\llvm.monorepo\clang-tools-extra\clangd\unittests\HoverTests.cpp(1628):
error: Expected: H->Type
Which is: int () __attribute__((thiscall))
To be equal to: Expected.Type
Which is: int ()
Google Test trace:
C:\src\llvm.monorepo\clang-tools-extra\clangd\unittests\HoverTests.cpp(1621):
instance-method method
→ int
// In cls
int method()
C:\src\llvm.monorepo\clang-tools-extra\clangd\unittests\HoverTests.cpp(1604):
// should not crash.
template struct cls {
int method();
};
auto test = cls().[[m^ethod]]();
[ FAILED ] Hover.All (959 ms)
[--] 1 test from Hover (959 ms total)
[--] Global test environment tear-down
[==] 1 test from 1 test case ran. (959 ms total)
[ PASSED ] 0 tests.
[ FAILED ] 1 test, listed below:
[ FAILED ] Hover.All
1 FAILED TEST
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building first preamble for C:\clangd-test\TestTU.cpp
Built preamble of size 213704 for file C:\clangd-test\TestTU.cpp
Building
[llvm-bugs] [Bug 44697] New: CrashRecoveryTest fails when built with clang-cl on 32-bit windows
https://bugs.llvm.org/show_bug.cgi?id=44697 Bug ID: 44697 Summary: CrashRecoveryTest fails when built with clang-cl on 32-bit windows Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: h...@chromium.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 44555 C:\src\llvm.monorepo\build.32_2019_selfhost>set CC=c:\src\llvm.monorepo\build.32_2019\bin\clang-cl.exe C:\src\llvm.monorepo\build.32_2019_selfhost>set CXX=%CC% C:\src\llvm.monorepo\build.32_2019_selfhost>cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_PROJECTS="llvm" ..\llvm C:\src\llvm.monorepo\build.32_2019_selfhost>ninja SupportTests C:\src\llvm.monorepo\build.32_2019_selfhost>unittests\Support\SupportTests.exe --gtest_filter=CrashRecovery* Note: Google Test filter = CrashRecovery* [==] Running 5 tests from 1 test case. [--] Global test environment set-up. [--] 5 tests from CrashRecoveryTest [ RUN ] CrashRecoveryTest.Basic unknown file: error: SEH exception with code 0x3221225477 thrown in â─δë±Φ. [ FAILED ] CrashRecoveryTest.Basic (2 ms) [ RUN ] CrashRecoveryTest.Cleanup unknown file: error: SEH exception with code 0x3221225477 thrown in â─δë±Φ. [ FAILED ] CrashRecoveryTest.Cleanup (0 ms) [ RUN ] CrashRecoveryTest.DumpStackCleanup 0x011568E0 (0x01158560 0x011568E0 0x0001 0x023CF598) 0x014B2ED2 (0x01561420 0x045B50A0 0x0453F620 0x01158514) 0x0157D1C1 (0x045B50A0 0x01562380 0x015F46E5 0x01562380) 0x015622F5 (0x5E30635E 0x 0x0454D190 0x0453F620) 0x01563C35 (0x0156BD2C 0x005B1000 0x0454D190 0x) 0x0156B405 (0x00E56001 0x7FFF 0x015F4D63 0x023CF800) 0x0157D581 (0x0453F620 0x0156B170 0x015F4D7C 0x) unknown file: error: SEH exception with code 0x3221225477 thrown in â─δë±Φ. [ FAILED ] CrashRecoveryTest.DumpStackCleanup (32 ms) [ RUN ] CrashRecoveryTest.RaiseException unknown file: error: SEH exception with code 0x3221225477 thrown in â─δë±Φ. [ FAILED ] CrashRecoveryTest.RaiseException (0 ms) [ RUN ] CrashRecoveryTest.CallOutputDebugString [ OK ] CrashRecoveryTest.CallOutputDebugString (0 ms) [--] 5 tests from CrashRecoveryTest (41 ms total) [--] Global test environment tear-down [==] 5 tests from 1 test case ran. (48 ms total) [ PASSED ] 1 test. [ FAILED ] 4 tests, listed below: [ FAILED ] CrashRecoveryTest.Basic [ FAILED ] CrashRecoveryTest.Cleanup [ FAILED ] CrashRecoveryTest.DumpStackCleanup [ FAILED ] CrashRecoveryTest.RaiseException 4 FAILED TESTS I'm guessing this might be a problem with clang-cl's SEH support rather than with CrashRecovery, but maybe it was uncovered because of the new in-process-cc1 stuff. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=44555 [Bug 44555] [meta] 10.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 44698] New: Global initialization incompatibility with old objects
https://bugs.llvm.org/show_bug.cgi?id=44698 Bug ID: 44698 Summary: Global initialization incompatibility with old objects Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: dominik.stras...@onespin.com CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org Created attachment 23069 --> https://bugs.llvm.org/attachment.cgi?id=23069&action=edit tarball containing material to reproduce Linking running the attached project with lld produces a crashing object whereas using ld yields a working one. My suspicion is that lld does not pick up the global initialization function which lacks the _sub_ infix. 0288 t _GLOBAL__I_outFilePtr // from old g++, crashes with lld vs. 01af t _GLOBAL__sub_I_outFilePtr // from new g++, works with lld -- 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 44693] False positive on calling new(std::size_t, std::align_val_t)
https://bugs.llvm.org/show_bug.cgi?id=44693 Artem Dergachev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Artem Dergachev --- Closing because i couldn't reproduce on a newer release. Feel free to re-open or make a new ticket if it is still a problem! -- 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 44624] Cast from _Complex int to _Complex double causes crash
https://bugs.llvm.org/show_bug.cgi?id=44624 Aaron Ballman changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Aaron Ballman --- This should be fixed as of 554791928088d6139e0fb3480d79cd76ea59198f. -- 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 44699] New: Members of nested classes incorrectly shadow template parameters of member functions of the nested class
https://bugs.llvm.org/show_bug.cgi?id=44699
Bug ID: 44699
Summary: Members of nested classes incorrectly shadow template
parameters of member functions of the nested class
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: Luna+llvmbugs@baguette.management
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Example code:
class Outer {
class Inner {
int x;
template
void static check() {
static_assert(x < 10);
}
};
};
Produces the error
:7:27: error: invalid use of member 'x' in static member function
static_assert(x < 10);
^
(Compiler explorer: https://gcc.godbolt.org/z/pC_Mx8)
x in check() should refer to the template parameter but apparently refers to
the member variable of the same name. If class Inner is declared at global
scope (i.e. not nested in class Outer), x correctly refers to the template
parameter instead of the member variable.
--
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 44700] New: [ORC] Please merge 84217ad6611 into LLVM 10.
https://bugs.llvm.org/show_bug.cgi?id=44700 Bug ID: 44700 Summary: [ORC] Please merge 84217ad6611 into LLVM 10. Product: libraries Version: 10.0 Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: OrcJIT Assignee: unassignedb...@nondot.org Reporter: lha...@gmail.com CC: 1101.deb...@gmail.com, llvm-bugs@lists.llvm.org Commit 84217ad6611 fixes a serious bug blocking ORCv2 adoption on Windows (see http://llvm.org/PR40074 and http://llvm.org/PR44337). Could it be merged into LLVM 10? -- 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 44701] New: Merge ce2207abaf and follow-ups into the 10.0 branch : Fixes EmulatedTLS in ORCv2
https://bugs.llvm.org/show_bug.cgi?id=44701 Bug ID: 44701 Summary: Merge ce2207abaf and follow-ups into the 10.0 branch : Fixes EmulatedTLS in ORCv2 Product: libraries Version: 10.0 Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: OrcJIT Assignee: unassignedb...@nondot.org Reporter: lha...@gmail.com CC: 1101.deb...@gmail.com, llvm-bugs@lists.llvm.org The following commits fix a bug that prevents any use of TLS variables in ORCv2: ce2207abaf9a925b35f15ef92aaff6b301ba6d22 -- Fix EmulatedTLS support. e0a6093a744d16c90eafa62d7143ce41806b2466 -- Fix a missing move in original commit 98e55477558a823b1045b54d5a09681a3c0b819a -- Fix Kaleidoscope and Speculative examples b54aa053d3aeeab0cdaecb6286419138b7da5ef4 -- Fix clang-interpreter example 97d000da2e6025600c4709d611e853eb1d5d407c -- Fix LLJITWithObjectCache example Without this fix, any use of a TLS variable in ORCv2 will result in a JIT error. Impact: JIT only. Affects any JIT user who wants to use TLS. -- 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 20374 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: IsVector && "cannot get number of elements on scalar/aggregate"
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-01-29 Type: Bug New issue 20374 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: IsVector && "cannot get number of elements on scalar/aggregate" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20374 Detailed Report: https://oss-fuzz.com/testcase?key=5124193882734592 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--aarch64-gisel Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: IsVector && "cannot get number of elements on scalar/aggregate" llvm::MachineIRBuilder::buildSplatVector llvm::IRTranslator::translateGetElementPtr Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202001270531:202001280532 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5124193882734592 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 44683] file_magic identifies file with two leading null bytes as a COFF object
https://bugs.llvm.org/show_bug.cgi?id=44683 Sam Clegg changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |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] Issue 20395 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: Res.getLLTTy(*getMRI()).isScalar() == Op.getLLTTy(*getMRI()).isScalar()
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-01-29 Type: Bug New issue 20395 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: Res.getLLTTy(*getMRI()).isScalar() == Op.getLLTTy(*getMRI()).isScalar() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20395 Detailed Report: https://oss-fuzz.com/testcase?key=5718377509421056 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--aarch64-gisel Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: Res.getLLTTy(*getMRI()).isScalar() == Op.getLLTTy(*getMRI()).isScalar() llvm::MachineIRBuilder::buildExtOrTrunc llvm::IRTranslator::translateGetElementPtr Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=202001270531:202001280532 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5718377509421056 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
