[llvm-bugs] [Bug 42023] [X86] Failure to use HADD for reduction add patterns
https://bugs.llvm.org/show_bug.cgi?id=42023 Simon Pilgrim changed: What|Removed |Added Fixed By Commit(s)|r366268 |r366268,r366933 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Simon Pilgrim --- (In reply to Simon Pilgrim from comment #5) > https://reviews.llvm.org/D65047 should handle the partial reduction cases Committed rL366933 -- 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 33758] AVX-512: Horizontal add pattern match does not work on <16 x i32> vectors
https://bugs.llvm.org/show_bug.cgi?id=33758 Simon Pilgrim changed: What|Removed |Added Fixed By Commit(s)||r366933 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Simon Pilgrim --- (In reply to Simon Pilgrim from comment #13) > (In reply to Simon Pilgrim from comment #12) > > There's a tiny bit more we can do to improve optsize builds (which is the > > same as fast-horiz but more likely to be requested) code: > > > > https://godbolt.org/z/yP5CgS > > https://reviews.llvm.org/D65047 should handle the partial reduction cases Committed rL366933 -- 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 42752] New: clangd CLI usability improvements
https://bugs.llvm.org/show_bug.cgi?id=42752 Bug ID: 42752 Summary: clangd CLI usability improvements Product: clang-tools-extra Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: clangd Assignee: unassignedclangb...@nondot.org Reporter: sammcc...@google.com CC: llvm-bugs@lists.llvm.org Some unintrusive changes to ClangdMain.cpp to improve usability. Would be great to slip these into the llvm-9 release. 366811 - Log version, cwd, args, and transport on startup. NFC 366880 - Reformat use of cl::opt: use unqualified name and don't bin-pack attributes. NFC (needed to avoid merge conflicts on next patch) 366900 - Add categories to help options, and only show clangd options. 366991 - Also accept flags from CLANGD_FLAGS variable. 366992 - Provide help text to users who run `clangd` in a terminal. -- 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 42753] New: 44: bool clang::APValue::isNullPointer() const: Assertion `isLValue() && "Invali d usage"' failed.
https://bugs.llvm.org/show_bug.cgi?id=42753 Bug ID: 42753 Summary: 44: bool clang::APValue::isNullPointer() const: Assertion `isLValue() && "Invali d usage"' failed. Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: dyre.tjeldv...@oracle.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk [1775/2160] Building CXX object router...ng_view.dir/test_stdx_string_view.cc.o FAILED: router/src/harness/tests/CMakeFiles/routertest_harness_stdx_string_view.dir/test_stdx_string_view.cc.o /export/home/tmp/usr/bin/clang++ -DHAVE_CONFIG_H -DHAVE_LIBEVENT2 -DHAVE_OPENSSL -DHAVE_TLSv13 -DLZ4_DISABLE_DEPRECATE_WARNINGS -DRAPIDJSON_NO_SIZETYPEDEFINE -DRAPIDJSON_SCHEMA_USE_INTERNALREGEX=0 -DRAPIDJSON_SCHEMA_USE_STDREGEX=1 -DUNISTR_FROM_CHAR_EXPLICIT=explicit -DUNISTR_FROM_STRING_EXPLICIT=explicit -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_USE_MATH_DEFINES -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -Iinclude -I/export/home/tmp/clones/_bug_30041367 -I/export/home/tmp/clones/_bug_30041367/include -Irouter -Irouter/include -I/export/home/tmp/clones/_bug_30041367/router/src/harness/include -I/export/home/tmp/clones/_bug_30041367/router/src/harness/src/../include -Irouter/src/harness/src/src_SHARED -I/export/home/tmp/clones/_bug_30041367/router/src/router/src/../include -I/export/home/tmp/clones/_bug_30041367/router/src/rest_api/src/../include -I/export/home/tmp/clones/_bug_30041367/router/src/http/src -I/export/home/tmp/clones/_bug_30041367/router/src/http/src/../include -Irouter/src/http/src/../include -I/export/home/tmp/clones/_bug_30041367/router/src/mock_server/include -I/export/home/tmp/clones/_bug_30041367/router/src/http/include -isystem /export/home/tmp/clones/_bug_30041367/extra/rapidjson/include -isystem /export/home/tmp/clones/_bug_30041367/extra/lz4 -isystem /export/home/tmp/clones/_bug_30041367/extra/libedit/editline -isystem /export/home/tmp/clones/_bug_30041367/extra/zstd/lib -isystem extra/zlib -isystem /export/home/tmp/clones/_bug_30041367/extra/zlib -isystem /usr/global/share/googletest-release-1.8.0/googlemock -isystem /usr/global/share/googletest-release-1.8.0/googlemock/include -isystem /usr/global/share/googletest-release-1.8.0/googletest -isystem /usr/global/share/googletest-release-1.8.0/googletest/include -std=c++14 -fno-omit-frame-pointer -fsanitize=thread -O1 -fno-inline -Wall -Wextra -Wformat-security -Wvla -Wundef -Wmissing-format-attribute -Woverloaded-virtual -Wcast-qual -Wno-null-conversion -Wno-unused-private-field -Wconditional-uninitialized -Wdeprecated -Wextra-semi -Wheader-hygiene -Wnon-virtual-dtor -Wundefined-reinterpret-cast -Winconsistent-missing-destructor-override -Wshadow-field -DSAFE_MUTEX -DENABLED_DEBUG_SYNC -g -fPIE -MD -MT router/src/harness/tests/CMakeFiles/routertest_harness_stdx_string_view.dir/test_stdx_string_view.cc.o -MF router/src/harness/tests/CMakeFiles/routertest_harness_stdx_string_view.dir/test_stdx_string_view.cc.o.d -o router/src/harness/tests/CMakeFiles/routertest_harness_stdx_string_view.dir/test_stdx_string_view.cc.o -c /export/home/tmp/clones/_bug_30041367/router/src/harness/tests/test_stdx_string_view.cc clang-10: /export/home/tmp/tools/llvm.git/llvm/tools/clang/lib/AST/APValue.cpp:744: bool clang::APValue::isNullPointer() const: Assertion `isLValue() && "Invalid usage"' failed. Stack dump: 0. Program arguments: /export/home/tmp/usr/bin/clang-10 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name test_stdx_string_view.cc -mrelocation-model pic -pic-level 2 -pic-is-pie -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -coverage-notes-file /export/home/tmp/build/_bug_30041367__clangT/router/src/harness/tests/CMakeFiles/routertest_harness_stdx_string_view.dir/test_stdx_string_view.cc.gcno -resource-dir /export/home/tmp/usr/lib/clang/10.0.0 -dependency-file router/src/harness/tests/CMakeFiles/routertest_harness_stdx_string_view.dir/test_stdx_string_view.cc.o.d -sys-header-deps -MT router/src/harness/tests/CMakeFiles/routertest_harness_stdx_string_view.dir/test_stdx_string_view.cc.o -isystem /export/home/tmp/clones/_bug_30041367/extra/rapidjson/include -isystem /export/home/tmp/clones/_bug_30041367/extra/lz4 -isystem /export/home/tmp/clones/_bug_30041367/extra/libedit/editline -isystem /export/home/tmp/clones/_bug_30041367/extra/zstd/lib -isystem extra/zlib -isystem /export/home/tmp/clones/_bug_30041367/extra/zlib -isystem /usr/global/share/googletest-release-1.8.0/googlemock -isystem /usr/global/share/googletest-release-1.8.0/google
[llvm-bugs] [Bug 42754] New: llvm-addr2line does not exit when passed a non-existent file
https://bugs.llvm.org/show_bug.cgi?id=42754 Bug ID: 42754 Summary: llvm-addr2line does not exit when passed a non-existent file Product: tools Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: llvm-symbolizer Assignee: unassignedb...@nondot.org Reporter: arichardson@gmail.com CC: llvm-bugs@lists.llvm.org GNU addr2line and FreeBSD addr2line exit immediately when passed an invalid file with -e: $ addr2line -fi -e /bad/file addr2line: /bad/file: No such file or directory However, llvm-addr2line does not exit and waits for input on stdin. This causes compiler-rt/test/asan/TestCases/Posix/asan-symbolize-bad-path.cc to block forever if -DLLVM_INSTALL_BINUTILS_SYMLINKS=ON is enabled. In that case the addr2line found in the path will be llvm-addr2line and then the test waits forever. I wonder if we want to change llvm-addr2line (and possibly also llvm-symbolizer) to behave in the same way as GNU? -- 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 27427] Segmentation fault during semantic analysis of a nested class that inherits from a template type parameter
https://bugs.llvm.org/show_bug.cgi?id=27427 David Stone changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||da...@doublewise.net --- Comment #1 from David Stone --- Fixed in clang 7.0.0 -- 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 40825] [x86-64] Suboptimal codegen on uint128 negation
https://bugs.llvm.org/show_bug.cgi?id=40825 Simon Pilgrim changed: What|Removed |Added See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=40483 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Simon Pilgrim --- This is fixed in trunk, I think from the work on [Bug #40483] trunk / 9.0: wider_tests::Tests::neg(unsigned __int128*): xorl %eax, %eax negq (%rdi) sbbq 8(%rdi), %rax movq %rax, 8(%rdi) retq wider_tests::Tests >::neg(Wider*): xorl %eax, %eax negq (%rdi) sbbq 8(%rdi), %rax movq %rax, 8(%rdi) retq vs 8.0: wider_tests::Tests::neg(unsigned __int128*): xorl %eax, %eax xorl %ecx, %ecx subq (%rdi), %rcx sbbq 8(%rdi), %rax movq %rcx, (%rdi) movq %rax, 8(%rdi) retq wider_tests::Tests >::neg(Wider*): movq (%rdi), %rax testq %rax, %rax setne %cl negq %rax xorl %edx, %edx addb $-1, %cl sbbq 8(%rdi), %rdx movq %rax, (%rdi) movq %rdx, 8(%rdi) 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] Issue 8694 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::object::ELFObjectFile
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #9 on issue 8694 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::object::ELFObjectFile https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8694#c9 ClusterFuzz testcase 4897850281426944 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201907240313:201907250316 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 42755] New: [SLPVectorizer] Failure to use vectorize integer minimum loop
https://bugs.llvm.org/show_bug.cgi?id=42755
Bug ID: 42755
Summary: [SLPVectorizer] Failure to use vectorize integer
minimum loop
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: llvm-bugs@lists.llvm.org
Current codegen: https://gcc.godbolt.org/z/smAJKe
#include
auto minmaxi(__v4si x, __v4si min) {
for (int i = 0; i != 4; ++i)
if (x[i] < min[i])
min[i] = x[i];
return min;
}
_Z7minmaxiDv4_iS_:
vmovd %xmm0, %eax
vmovd %xmm1, %ecx
cmpl%ecx, %eax
jl .LBB0_1
vpextrd $1, %xmm0, %eax
vpextrd $1, %xmm1, %ecx
cmpl%ecx, %eax
jl .LBB0_3
.LBB0_4:
vpextrd $2, %xmm0, %eax
vpextrd $2, %xmm1, %ecx
cmpl%ecx, %eax
jl .LBB0_5
.LBB0_6:
vpextrd $3, %xmm0, %eax
vpextrd $3, %xmm1, %ecx
cmpl%ecx, %eax
jl .LBB0_7
.LBB0_8:
vmovdqa %xmm1, %xmm0
retq
.LBB0_1:
vpblendw$3, %xmm0, %xmm1, %xmm1 # xmm1 =
xmm0[0,1],xmm1[2,3,4,5,6,7]
vpextrd $1, %xmm0, %eax
vpextrd $1, %xmm1, %ecx
cmpl%ecx, %eax
jge .LBB0_4
.LBB0_3:
vpblendw$12, %xmm0, %xmm1, %xmm1 # xmm1 =
xmm1[0,1],xmm0[2,3],xmm1[4,5,6,7]
vpextrd $2, %xmm0, %eax
vpextrd $2, %xmm1, %ecx
cmpl%ecx, %eax
jge .LBB0_6
.LBB0_5:
vpblendw$48, %xmm0, %xmm1, %xmm1 # xmm1 =
xmm1[0,1,2,3],xmm0[4,5],xmm1[6,7]
vpextrd $3, %xmm0, %eax
vpextrd $3, %xmm1, %ecx
cmpl%ecx, %eax
jge .LBB0_8
.LBB0_7:
vpblendw$192, %xmm0, %xmm1, %xmm1 # xmm1 =
xmm1[0,1,2,3,4,5],xmm0[6,7]
vmovdqa %xmm1, %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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 12058 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::object::ELFObjectFile
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #4 on issue 12058 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::object::ELFObjectFile https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12058#c4 ClusterFuzz testcase 5650578005295104 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201907240313:201907250316 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 15948 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: (ResTy == Op0Ty && ResTy == Op1Ty) && "type mismatch"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 15948 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: (ResTy == Op0Ty && ResTy == Op1Ty) && "type mismatch" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15948#c1 ClusterFuzz testcase 5682819033989120 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201907240313:201907250316 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 42752] clangd CLI usability improvements
https://bugs.llvm.org/show_bug.cgi?id=42752 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Hans Wennborg --- Merged them all in r367025. -- 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 42474] [meta] 9.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=42474 Bug 42474 depends on bug 42752, which changed state. Bug 42752 Summary: clangd CLI usability improvements https://bugs.llvm.org/show_bug.cgi?id=42752 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 42737] simplifycfg crashes: Assertion `PN->use_empty() && "There shouldn't be any uses here!"' failed.
https://bugs.llvm.org/show_bug.cgi?id=42737 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED CC||spatel+l...@rotateright.com Fixed By Commit(s)||r367037 Resolution|--- |FIXED --- Comment #1 from Sanjay Patel --- https://reviews.llvm.org/rL367037 -- 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 42756] New: Crash after explicit call to a base constructor with virtual base
https://bugs.llvm.org/show_bug.cgi?id=42756
Bug ID: 42756
Summary: Crash after explicit call to a base constructor with
virtual base
Product: clang
Version: 8.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: securesneak...@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 22289
--> https://bugs.llvm.org/attachment.cgi?id=22289&action=edit
Minimal example that reproduces the issue
The code below crashes Windows:
struct interface { };
struct base1_if : virtual interface { };
struct base2_if : virtual interface { };
struct base_if : base1_if, base2_if { };
struct derived : base_if {
derived()
: base_if()
{ }
};
int main() { derived d; }
Command line:
$ clang-cl -v
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
$ clang-cl main.cpp
$ main.exe
Few notes:
- Removing explicit call to "base_if" avoids the issue.
- Generated assembly contains "memset(addr, 0, r8,0FFF8h)":
7FF7482310A9 mov r8,0FFF8h
7FF7482310B0 mov dword ptr [rsp+2Ch],eax
7FF7482310B4 callmemset (07FF748232FE0h)
--
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 42757] New: Template deduction fails with defaulted argument that's an index_sequence
https://bugs.llvm.org/show_bug.cgi?id=42757
Bug ID: 42757
Summary: Template deduction fails with defaulted argument
that's an index_sequence
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: barry.rev...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Reduced from StackOverflow (https://stackoverflow.com/q/57206006/2069064):
#include
#include
template >
struct FooList;
template
struct FooList> { };
template
void foobar(FooList) { }
void test() {
foobar(FooList<5>{});
}
This fails to compile on clang, the candidate is rejected with the note:
candidate template ignored: could not match '__make_integer_seq' against
'integer_sequence'
Even though these are the same type. This compiles on gcc.
--
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 42758] New: Assertion failure with fold expression in type-deduced member variable template of variadic class template
https://bugs.llvm.org/show_bug.cgi?id=42758
Bug ID: 42758
Summary: Assertion failure with fold expression in type-deduced
member variable template of variadic class template
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++17
Assignee: unassignedclangb...@nondot.org
Reporter: da...@doublewise.net
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
The following translation unit causes an assertion failure on master:
template
struct s {
template
static inline auto fold = (... and xs);
void f() {
fold;
}
};
With the following error message:
Stack dump:
0. Program arguments: /opt/wandbox/clang-head/bin/clang-9 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -discard-value-names -main-file-name prog.cc
-mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno
-masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array
-target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -nostdinc++
-resource-dir /opt/wandbox/clang-head/lib/clang/9.0.0 -I
/opt/wandbox/clang-head/include/c++/v1 -I /opt/wandbox/boost-sml/include -I
/opt/wandbox/boost-di/include -I /opt/wandbox/range-v3/include -I
/opt/wandbox/nlohmann-json/src -I /opt/wandbox/cmcstl2/include -I
/opt/wandbox/te/include -I /opt/wandbox/boost-1.70.0/clang-head/include
-internal-isystem /usr/local/include -internal-isystem
/opt/wandbox/clang-head/lib/clang/9.0.0/include -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include
-internal-externc-isystem /usr/include -Wall -Wextra -pedantic -std=c++2a
-fdeprecated-macro -fdebug-compilation-dir /home/jail -ferror-limit 19
-fmessage-length 0 -fno-implicit-modules -fobjc-runtime=gcc -fcxx-exceptions
-fexceptions -fdiagnostics-show-option -fcolor-diagnostics -fansi-escape-codes
-faddrsig -o /tmp/prog-512617.o -x c++ prog.cc
1. prog.cc:7:12: current parser token ';'
2. prog.cc:2:1: parsing struct/union/class body 's'
3. prog.cc:6:11: parsing function body 's::f'
4. prog.cc:6:11: in compound statement ('{}')
#0 0x02045464 PrintStackTraceSignalHandler(void*)
(/opt/wandbox/clang-head/bin/clang-9+0x2045464)
#1 0x020433b0 llvm::sys::RunSignalHandlers()
(/opt/wandbox/clang-head/bin/clang-9+0x20433b0)
#2 0x02045868 SignalHandler(int)
(/opt/wandbox/clang-head/bin/clang-9+0x2045868)
#3 0x7f7137918390 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#4 0x039b37d7
clang::Sema::BuildExpressionFromIntegralTemplateArgument(clang::TemplateArgument
const&, clang::SourceLocation) (/opt/wandbox/clang-head/bin/clang-9+0x39b37d7)
#5 0x03a6551a (anonymous
namespace)::TemplateInstantiator::transformNonTypeTemplateParmRef(clang::NonTypeTemplateParmDecl*,
clang::SourceLocation, clang::TemplateArgument)
(/opt/wandbox/clang-head/bin/clang-9+0x3a6551a)
#6 0x03a64f42 (anonymous
namespace)::TemplateInstantiator::TransformTemplateParmRefExpr(clang::DeclRefExpr*,
clang::NonTypeTemplateParmDecl*)
(/opt/wandbox/clang-head/bin/clang-9+0x3a64f42)
#7 0x03a59c67 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCXXFoldExpr(clang::CXXFoldExpr*)
(/opt/wandbox/clang-head/bin/clang-9+0x3a59c67)
#8 0x03a5293d clang::Sema::SubstInitializer(clang::Expr*,
clang::MultiLevelTemplateArgumentList const&, bool)
(/opt/wandbox/clang-head/bin/clang-9+0x3a5293d)
#9 0x03a8838e
clang::Sema::InstantiateVariableInitializer(clang::VarDecl*, clang::VarDecl*,
clang::MultiLevelTemplateArgumentList const&)
(/opt/wandbox/clang-head/bin/clang-9+0x3a8838e)
#10 0x03a79f0a clang::Sema::BuildVariableInstantiation(clang::VarDecl*,
clang::VarDecl*, clang::MultiLevelTemplateArgumentList const&,
llvm::SmallVector*,
clang::DeclContext*, clang::LocalInstantiationScope*, bool,
clang::VarTemplateSpecializationDecl*)
(/opt/wandbox/clang-head/bin/clang-9+0x3a79f0a)
#11 0x03a856c0
clang::TemplateDeclInstantiator::VisitVarTemplateSpecializationDecl(clang::VarTemplateDecl*,
clang::VarDecl*, void*, clang::TemplateArgumentListInfo const&,
llvm::ArrayRef, clang::VarTemplateSpecializationDecl*)
(/opt/wandbox/clang-head/bin/clang-9+0x3a856c0)
#12 0x03a88128
clang::Sema::BuildVarTemplateInstantiation(clang::VarTemplateDecl*,
clang::VarDecl*, clang::TemplateArgumentList const&,
clang::TemplateArgumentListInfo const&,
llvm::SmallVectorImpl&, clang::SourceLocation, void*,
llvm::SmallVector*,
clang::LocalInstantiationScope*)
(/opt/wandbox/clang-head/bin/clang-9+0x3a88128)
#13 0x039aab82 clang::Sema::CheckVarTemplateId(clang::VarTemplateDecl*,
clang::SourceLocatio
[llvm-bugs] [Bug 10750] clang crashes from gcc torture test limits-fndefn.c
https://bugs.llvm.org/show_bug.cgi?id=10750 Mark de Wever changed: What|Removed |Added Resolution|--- |DUPLICATE CC||ko...@xs4all.nl Status|NEW |RESOLVED --- Comment #2 from Mark de Wever --- The report contains the same test case as https://bugs.llvm.org/show_bug.cgi?id=31968 *** This bug has been marked as a duplicate of bug 19607 *** -- 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 42759] New: [PowerPC64] lld incorrectly optimizes ifunc TOC relocations
https://bugs.llvm.org/show_bug.cgi?id=42759 Bug ID: 42759 Summary: [PowerPC64] lld incorrectly optimizes ifunc TOC relocations Product: lld Version: unspecified Hardware: Other OS: FreeBSD Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: lup...@freebsd.org CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org Consider the following C fragment: void (*funcptr)(void) = my_ifunc; (*funcptr)(); Where my_ifunc is an ifunc. When built with clang and linked with lld, the program will call the ifunc resolver, instead of the function returned by it. Inspecting the .o file, it can be seen that clang emits code to load the pointer to my_ifunc from the TOC, which is patched by the dynamic linker or C startup code (for static binaries). The problem is that lld is optimizing this load from TOC, replacing it by an addis/addi pair to get the function address. This is valid for regular functions, but not for ifuncs. The issue doesn't happen if --no-toc-optimize is passed to lld, or if the program is linked with bfd. It also doesn't happen if the ifunc is defined in a separate .so file. I have a reproduce tar file, but it has 2.5 MB when compressed with xz, which is over the 1000 KB attachment limit. -- 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 42760] New: [ARM] Invalid symbol redefinition at -O3 with jump tables
https://bugs.llvm.org/show_bug.cgi?id=42760 Bug ID: 42760 Summary: [ARM] Invalid symbol redefinition at -O3 with jump tables Product: libraries Version: 9.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: nikita@gmail.com CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org, ties.st...@arm.com The IR in https://gist.github.com/nikic/1fa40bc972e815f9606518c5b2218699 run through "llc -O3" causes "LLVM ERROR: invalid symbol redefinition". The error does not occur at -O2. -- 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 42761] New: unordered_map and unordered_set operator== double key comparison causes exponential behavior
https://bugs.llvm.org/show_bug.cgi?id=42761
Bug ID: 42761
Summary: unordered_map and unordered_set operator== double key
comparison causes exponential behavior
Product: libc++
Version: 9.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: terre...@fb.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
When unordered_map or unordered_set has a nested unordered_{map,set} as a key,
operator== becomes exponential in the depth of the nesting. This is because
unordered_{map,set}::operator== does two key comparisons, one in find() using
key_eq() and one when comparing the key-value pairs using the key’s operator==.
These two comparisons can theoretically be different but are almost always the
same in practice. unordered_{map,set} should only do one key comparison in
operator== to avoid this. It is also generally more efficient even in the
non-nesting cases.
Nathan Bronson helped create a minimal repro below that demonstrates this
exponential behavior.
#include
#include
#include
struct Nested;
struct NestedHash {
std::size_t operator()(Nested const& n) const;
};
struct Nested {
std::unique_ptr> set;
explicit Nested(int depth)
: set(std::make_unique>()) {
if (depth > 0) {
set->emplace(depth - 1);
}
}
};
std::size_t NestedHash::operator()(Nested const& n) const {
std::size_t rv = 1;
for (auto& k : *n.set) {
rv += operator()(k);
}
return rv;
}
bool operator==(Nested const& lhs, Nested const& rhs) {
return *lhs.set == *rhs.set;
}
bool operator!=(Nested const& lhs, Nested const& rhs) {
return !(lhs == rhs);
}
void testNestedSetEquality() {
auto n1 = Nested(100);
auto n2 = Nested(100);
auto n3 = Nested(99);
assert(n1 == n1);
assert(n1 == n2);
assert(n1 != n3);
}
This is a contrived example, but this shows up in practice in
folly::dynamic::operator== [1] as a worst case exponential algorithm. No one
will create objects like this intentionally, but they can be produced with
folly::parseJson() [2] when non-string keys are allowed. If an attacker
controlled the input to parseJson() they could easily DDOS the machine with a
payload like "{0:0}:0}:0}:0}:0}" but nested 100 layers deep instead of 5.
unordered_map and unordered_set should only do one key comparison per item in
operator==. This is possible [3] because it is undefined behavior to call the
containers operator== if the key’s operator== isn’t a refinement of key_eq().
Fixing this bug in unordered_map and unordered_set avoids the exponential
behavior with nested keys, and it is generally more efficient even in the
non-nesting cases. An implementation of set and map equality with only one key
comparison is included below, thanks to Nathan Bronson.
template
bool eqSet(S const& lhs, S const& rhs) {
if (lhs.size() != rhs.size()) {
return false;
}
for (auto& v : lhs) {
auto slot = rhs.bucket(v);
auto b = rhs.begin(slot);
auto e = rhs.end(slot);
while (b != e && !(*b == v)) {
++b;
}
if (b == e) {
return false;
}
}
return true;
}
template
bool eqMap(M const& lhs, M const& rhs) {
if (lhs.size() != rhs.size()) {
return false;
}
for (auto& v : lhs) {
auto slot = rhs.bucket(v.first);
auto b = rhs.begin(slot);
auto e = rhs.end(slot);
while (b != e && !(b->first == v.first)) {
++b;
}
if (b == e || !(b->second == v.second)) {
return false;
}
}
return true;
}
[1] https://github.com/facebook/folly/blob/master/folly/dynamic.cpp#L113
[2] https://github.com/facebook/folly/blob/master/folly/json.h#L194
[3]
https://github.com/facebook/folly/commit/11855c21b21fb46fe1004de8c0412dd94eb5c45f
--
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 42762] New: unexpected codegen for inline asm
https://bugs.llvm.org/show_bug.cgi?id=42762
Bug ID: 42762
Summary: unexpected codegen for inline asm
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: ndesaulni...@google.com
CC: hfin...@anl.gov, kit.bar...@gmail.com,
llvm-bugs@lists.llvm.org, nemanja.i@gmail.com
Blocks: 4068
The powerpc (32b) Linux kernel started panicing at runtime recently when built
with LLVM due to a change in the kernel sources. We narrowed it down to
commit, and a single call site of a static inline function containing extended
inline assembly with constraints.
I think this concise test case distills this issue:
https://godbolt.org/z/E4f1Us
Basically, we had:
// from arch/powerpc/include/asm/cache.h
// pre-commit 6c5875843b87 ("powerpc: slightly improve cache helpers")
void dcbz_old(void* addr)
{
asm volatile ("dcbz 0, %0" : : "r"(addr) : "memory");
}
then moved to:
// from arch/powerpc/include/asm/cache.h
// post-commit 6c5875843b87 ("powerpc: slightly improve cache helpers")
void dcbz_current(void* addr)
{
asm volatile ("dcbz %y0" :: "Z"(*(unsigned char*)addr) : "memory");
}
It seems that GCC generates the same code for both cases, and LLVM matches GCC
for the first case. In the second case, the codegen is wildly different, which
seems like what's leading to our panic at runtime.
I'm not super familiar with the "Z" constraint and "%y" output format, but they
might be related?
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=4068
[Bug 4068] [Meta] Compiling the Linux kernel with clang
--
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 42763] New: r358919 causing boot failures for MIPS Linux kernel
https://bugs.llvm.org/show_bug.cgi?id=42763
Bug ID: 42763
Summary: r358919 causing boot failures for MIPS Linux kernel
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: MIPS
Assignee: unassignedb...@nondot.org
Reporter: ndesaulni...@google.com
CC: listm...@philipreames.com, llvm-bugs@lists.llvm.org,
natechancel...@gmail.com, tstel...@redhat.com
Blocks: 4068
Reported via:
https://github.com/ClangBuiltLinux/linux/issues/610#issuecomment-515197978
It seems that with clang-8, we can boot a working MIPS linux kernel.
It fails to boot with clang-9, seemingly due to r358919 commit d748689c7f71
("[InstCombine] Eliminate stores to constant memory").
The particular optimization sounds like it may be potentially dangerous; maybe
the kernel is exercising such an unconsidered case?
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=4068
[Bug 4068] [Meta] Compiling the Linux kernel with clang
--
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 42764] New: Document the scope of -fstack-protector
https://bugs.llvm.org/show_bug.cgi?id=42764 Bug ID: 42764 Summary: Document the scope of -fstack-protector Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: franci...@yahoo.com CC: llvm-bugs@lists.llvm.org During https://reviews.llvm.org/D64759, we realized that we don't have specific documentation for what attacks we expect stack protectors to stop. We need to provide such documentation to know what is expected of the mitigation in order to evaluate potential improvements. -- 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 42765] New: Avoid spilling the address of the saved stack guard with -fstack-protector
https://bugs.llvm.org/show_bug.cgi?id=42765 Bug ID: 42765 Summary: Avoid spilling the address of the saved stack guard with -fstack-protector Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: franci...@yahoo.com CC: llvm-bugs@lists.llvm.org In https://reviews.llvm.org/D64759, we avoid using a different register to address the slot of the stack guard to be loaded before we compare it with the original guard. There are cases where this could still be spilled, potentially by the reg scavenger. A few things we could do to make this better: * Eli Friedman suggested to make the reg scavenger aware of particularly sensitive registers and force it to choose other registers to spill. * Sander de Smalen suggested to always enable FP when using stack guards. -- 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 42766] New: Rejects valid code claiming "pack expansion does not contain any unexpanded parameter packs"
https://bugs.llvm.org/show_bug.cgi?id=42766
Bug ID: 42766
Summary: Rejects valid code claiming "pack expansion does not
contain any unexpanded parameter packs"
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++17
Assignee: unassignedclangb...@nondot.org
Reporter: da...@doublewise.net
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
The following well-formed translation unit is rejected by clang as invalid.
template
bool false_ = false;
struct outer_traits {
using type = int;
};
template
struct s {
template
using traits = outer_traits;
static bool any = (... or false_::type>);
};
clang (all versions that have a -std=c++17 flag) outputs:
:13:21: error: pack expansion does not contain any unexpanded parameter
packs
static bool any = (... or false_::type>);
^ ~
1 error generated.
Compiler returned: 1
See it live: https://godbolt.org/z/L84t58
--
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 42767] New: add newline between include and namespace
https://bugs.llvm.org/show_bug.cgi?id=42767
Bug ID: 42767
Summary: add newline between include and namespace
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: janwilm...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
We have options to remove duplicate white-space lines, however, it would also
be good for readability to be able to require at least one empty line:
* _before_ and _after_ and #include block
* _before_ and _after_ a namespace
//
// License
//
#include
#include
namespace {
}
convert to:
//
// License
//
<<-- added empty line
#include
#include
<<-- added empty line
namespace Bar {
class Foo {
};
} // Bar
--
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 42768] New: recognize aligned case statements
https://bugs.llvm.org/show_bug.cgi?id=42768
Bug ID: 42768
Summary: recognize aligned case statements
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: janwilm...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Formatting this function currently does not make it more readable, as the
alignment of statements is lost.
Would it be possible to have an option to detect and ignore aligned cases ?
when inside a switch {
detect the:
case<.*>:
pattern, maybe ?
// SEH (Structured Exception Handling) return codes are in the
0xC00-0xf00 range
std::wstring GetSEHcodeDescription(DWORD code)
{
switch (code) {
case EXCEPTION_ACCESS_VIOLATION: return
L"EXCEPTION_ACCESS_VIOLATION";
case EXCEPTION_ARRAY_BOUNDS_EXCEEDED:return
L"EXCEPTION_ARRAY_BOUNDS_EXCEEDED";
case EXCEPTION_BREAKPOINT: return L"EXCEPTION_BREAKPOINT";
case EXCEPTION_DATATYPE_MISALIGNMENT:return
L"EXCEPTION_DATATYPE_MISALIGNMENT";
case EXCEPTION_FLT_DENORMAL_OPERAND: return
L"EXCEPTION_FLT_DENORMAL_OPERAND";
case EXCEPTION_FLT_DIVIDE_BY_ZERO: return
L"EXCEPTION_FLT_DIVIDE_BY_ZERO";
case EXCEPTION_FLT_INEXACT_RESULT: return
L"EXCEPTION_FLT_INEXACT_RESULT";
case EXCEPTION_FLT_INVALID_OPERATION:return
L"EXCEPTION_FLT_INVALID_OPERATION";
case EXCEPTION_FLT_OVERFLOW: return L"EXCEPTION_FLT_OVERFLOW";
case EXCEPTION_FLT_STACK_CHECK: return
L"EXCEPTION_FLT_STACK_CHECK";
case EXCEPTION_FLT_UNDERFLOW:return L"EXCEPTION_FLT_UNDERFLOW";
case EXCEPTION_ILLEGAL_INSTRUCTION: return
L"EXCEPTION_ILLEGAL_INSTRUCTION";
case EXCEPTION_IN_PAGE_ERROR:return L"EXCEPTION_IN_PAGE_ERROR";
case EXCEPTION_INT_DIVIDE_BY_ZERO: return
L"EXCEPTION_INT_DIVIDE_BY_ZERO";
case EXCEPTION_INT_OVERFLOW: return L"EXCEPTION_INT_OVERFLOW";
case EXCEPTION_INVALID_DISPOSITION: return
L"EXCEPTION_INVALID_DISPOSITION";
case EXCEPTION_NONCONTINUABLE_EXCEPTION: return
L"EXCEPTION_NONCONTINUABLE_EXCEPTION";
case EXCEPTION_PRIV_INSTRUCTION: return
L"EXCEPTION_PRIV_INSTRUCTION";
case EXCEPTION_SINGLE_STEP: return L"EXCEPTION_SINGLE_STEP";
case EXCEPTION_STACK_OVERFLOW: return
L"EXCEPTION_STACK_OVERFLOW";
// undocumented? but regularly seen codes
case 0xC142: return L"DllMain returned false";
case 0xC022: return L"executable or one of the
dependant dlls do not have execute rights";
default: return L"UNKNOWN EXCEPTION";
}
}
--
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 23214] [META] Using LLD as FreeBSD's system linker
https://bugs.llvm.org/show_bug.cgi?id=23214 Bug 23214 depends on bug 30415, which changed state. Bug 30415 Summary: lld has different section attribute merging vs ld.bfd https://bugs.llvm.org/show_bug.cgi?id=30415 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 30415] lld has different section attribute merging vs ld.bfd
https://bugs.llvm.org/show_bug.cgi?id=30415 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||i...@maskray.me --- Comment #8 from Fangrui Song --- lld doesn't create one single RWX PT_LOAD now. Closing because the issue has been fixed for a while. # I test on a Linux machine, but the FreeBSD case is similar. % clang -fuse-ld=lld -m32 a.c a.x -o a # 5008 bytes Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x34 0x08048034 0x08048034 0x00140 0x00140 R 0x4 INTERP 0x000174 0x08048174 0x08048174 0x00013 0x00013 R 0x1 [Requesting program interpreter: /lib/ld-linux.so.2] LOAD 0x00 0x08048000 0x08048000 0x00730 0x00730 R E 0x1000 LOAD 0x000730 0x08048730 0x08048730 0x000d8 0x000d8 RW 0x1000 LOAD 0x000808 0x08048808 0x08048808 0x00020 0x00021 RW 0x1000 DYNAMIC0x000738 0x08048738 0x08048738 0x000c8 0x000c8 RW 0x4 GNU_RELRO 0x000730 0x08048730 0x08048730 0x000d8 0x01000 R 0x1 GNU_EH_FRAME 0x000378 0x08048378 0x08048378 0x00044 0x00044 R 0x4 GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0 NOTE 0x000188 0x08048188 0x08048188 0x00020 0x00020 R 0x4 After D64903 and D64906 are merged, the non-linker script case will look similar to this layout. % clang -fuse-ld=bfd -m32 a.c a.x -o a.bfd # 7148 bytes % readelf -l a.bfd ... Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x34 0x08048034 0x08048034 0x00120 0x00120 R 0x4 INTERP 0x000154 0x08048154 0x08048154 0x00013 0x00013 R 0x1 [Requesting program interpreter: /lib/ld-linux.so.2] LOAD 0x00 0x08048000 0x08048000 0x005dc 0x005dc R E 0x1000 LOAD 0x000f04 0x08049f04 0x08049f04 0x00118 0x0011c RW 0x1000 DYNAMIC0x000f0c 0x08049f0c 0x08049f0c 0x000f0 0x000f0 RW 0x4 NOTE 0x000168 0x08048168 0x08048168 0x00020 0x00020 R 0x4 GNU_EH_FRAME 0x0004c8 0x080484c8 0x080484c8 0x00034 0x00034 R 0x4 GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0x10 GNU_RELRO 0x000f04 0x08049f04 0x08049f04 0x000fc 0x000fc R 0x1 > Note that given that we already support putting ro and rx together because of > linker scripts, supporting the original feature might not be a big problem. After https://reviews.llvm.org/rLLD281978, we place R and RX sections in the RX PT_LOAD (`singleRoRx = true;` in ScriptParser.cpp). I actually want to flip this, to improve consistency with the non-linker script case, and to fix issues like https://bugs.llvm.org/show_bug.cgi?id=38784 People who want separate R PT_LOAD and RX PT_LOAD in linker script cases can enable --no-rosegment. -- 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 42769] New: Please cherry-pick r366985 into the 9.0 branch
https://bugs.llvm.org/show_bug.cgi?id=42769 Bug ID: 42769 Summary: Please cherry-pick r366985 into the 9.0 branch Product: lldb Version: 9.0 Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: All Bugs Assignee: h...@chromium.org Reporter: lab...@google.com CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org Blocks: 42474 Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=42474 [Bug 42474] [meta] 9.0.0 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
