[llvm-bugs] [Bug 45594] New: lld resolves reloc to sym in discarded section to 0 if sym_name < originating_sym_name
https://bugs.llvm.org/show_bug.cgi?id=45594 Bug ID: 45594 Summary: lld resolves reloc to sym in discarded section to 0 if sym_name < originating_sym_name Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: rprich...@google.com CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com Created attachment 23386 --> https://bugs.llvm.org/attachment.cgi?id=23386&action=edit lld-comdat-missing-diag.sh If an object file has a relocation to a symbol from a discarded section, lld normally issues an error: ld.lld: error: relocation refers to a symbol in a discarded section: zzz I've found a case where ld.lld doesn't issue the error, though, and instead resolves the relocation to 0: - the object file is in an archive - the relocation target symbol's name comes before the name of the function containing the relocation (e.g. in ASCII order). e.g. If "mmm2" calls "aaa", there is no diagnostic, and the program crashes, but if it calls "zzz", there is an linker error. I tried ld.bfd and ld.gold, and both issue a linker error even when "mmm2" calls "aaa". The diagnostic is issued if the archive is surrounded with --whole-archive / --no-whole-archive on the linker command-line. I tried debugging it a little, and it seemed that the discarded symbol was not of kind Symbol::UndefinedKind but of kind Symbol::LazyArchiveKind. I originally noticed this problem in the Android platform, on 32-bit x86, where we have various copies of the __x86.get_pc_thunk.bx function floating around, some in .gnu.linkonce.t.__x86.get_pc_thunk.bx sections and others in .text.__x86.get_pc_thunk.bx sections. lld drops the .gnu.linkonce.* copy (which is fine) but then produces an executable without the function, with calls to address "0". I'd expect lld to either use the .text.* copy or issue an error. Either is OK -- Android should switch over to comdat. I opened http://b/154376560 in Google's tracker for that.) I'll attach scripts for reproducing: - the problem with comdat section groups - the problem with .gnu.linkonce.t.__x86.get_pc_thunk.bx -- 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 45595] New: wrong coverage for the function alloca() call statement
https://bugs.llvm.org/show_bug.cgi?id=45595
Bug ID: 45595
Summary: wrong coverage for the function alloca() call
statement
Product: Runtime Libraries
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: yangyib...@hust.edu.cn
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 9.0.1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/9.3.0
Found candidate GCC installation:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0
Found candidate GCC installation: /usr/lib64/gcc/x86_64-pc-linux-gnu/9.3.0
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.3.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
$ cat small.c
#include
#include
jmp_buf buf;
void sub (void)
{
longjmp (buf, 1);
}
int main ()
{
if (setjmp (buf)) {
exit (0);
}
int *q = (int *) alloca (10 * sizeof (int));
for (int i = 0; i < 10; i++)
q[i] = 0;
while (1)
sub ();
}
$ clang -O0 -fcoverage-mapping -fprofile-instr-generate=small.profraw small.c;
./a.out; llvm-profdata merge small.profraw -o small.profdata; llvm-cov show
a.out -instr-profile=small.profdata small.c > small.c.lcov; cat small.c.lcov
1| |#include
2| |#include
3| |
4| |jmp_buf buf;
5| |
6| |void sub (void)
7| 1|{
8| 1| longjmp (buf, 1);
9| 1|}
10| |
11| |int main ()
12| 1|{
13| 1| if (setjmp (buf)) {
14| 1|exit (0);
15| 1| }
16| 0|
17| 0| int *q = (int *) alloca (10 * sizeof (int));
18| 0|
19| 10| for (int i = 0; i < 10; i++)
20| 10|q[i] = 0;
21| 0|
22| 1| while (1)
23| 1|sub ();
24| 0|}
*
Line #17 is wrongly marked as not executed. The correct coverage should be
"1|".
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45572] Interleave failure in Loop Vectorizer
https://bugs.llvm.org/show_bug.cgi?id=45572 Florian Hahn changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||4ee45ab60f8639375296f8b7b96 ||e2eb5e8a2c9d3 Status|NEW |RESOLVED --- Comment #4 from Florian Hahn --- Thanks for the report and the reproducer! Should be fixed in 4ee45ab60f8639375296f8b7b96e2eb5e8a2c9d3 -- 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 45596] New: --cuda-noopt-device-debug doesn't define __CUDACC_DEBUG__
https://bugs.llvm.org/show_bug.cgi?id=45596 Bug ID: 45596 Summary: --cuda-noopt-device-debug doesn't define __CUDACC_DEBUG__ Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: CUDA Assignee: unassignedclangb...@nondot.org Reporter: r...@tambre.ee CC: llvm-bugs@lists.llvm.org NVCC defines __CUDACC_DEBUG__ if device debug code generation is enabled. It would probably be nice if Clang did the same. CMake has a test that checks for this define when using NVCC with device debug code generation. See https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4442/diffs#note_737556. -- 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 45237] Assertion failed: (!IsStrict && "Don't know how to expand for strict nodes."), function ExpandNode, file llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp, line 3638.
https://bugs.llvm.org/show_bug.cgi?id=45237
Piotr Kubaj changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED|REOPENED
--- Comment #3 from Piotr Kubaj ---
This issue wasn't completely fixed. babl builds on powerpc64 now, but I
discovered clang exiting with the same assert on powerpc, while building
x11/babl as well.
Reduced test case:
double a;
b() {
if (a)
;
}
Compile with:
/usr/bin/cc -cc1 -triple powerpc-unknown-freebsd13.0 -emit-obj
-ffp-exception-behavior=strict model-cmyk-61260b.c
Compiling the same test case for powerpc64 and powerpcspe also makes clang fail
on the same assertion.
--
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 45597] New: Frontend crash with -O1 and -sanitize=object-size
https://bugs.llvm.org/show_bug.cgi?id=45597 Bug ID: 45597 Summary: Frontend crash with -O1 and -sanitize=object-size Product: clang Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: j...@mcfarlane.name CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 23388 --> https://bugs.llvm.org/attachment.cgi?id=23388&action=edit run script, /tmp/integer-3770d0.sh When optimizer is enabled, this single UBSan check consistently causes a crash for some (larger) inputs. # Repro Two salient options seem to be -O1 and -sanitize=object-size. (-O2 and -O3 also cause crash; -O0 does not.) I've provided the simplest preprocessed input that is currently causing this for me. # Build LLVM built on Ubuntu 19.04 Desktop x86-64 at SHA 4c6e5899859. This also occurs on stock (apt) clang-9 but not on clang-8. # Output is: - - - - - - - - - - - - - - - - >8 - - - - - - - - - - - - - - - - clang version 10.0.0 (https://github.com/llvm/llvm-project.git 4c6e5899859651d5f0907fc4d5752e616c1598c3) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/9 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9 Candidate multilib: .;@m64 Selected multilib: .;@m64 (in-process) "/home/john/llvm/bin/clang-10" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name integer.cpp -mrelocation-model static -mthread-model posix -mframe-pointer=none -fmath-errno -fno-rounding-math -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info -fno-split-dwarf-inlining -debugger-tuning=gdb -v -resource-dir /home/john/llvm/lib/clang/10.0.0 -isystem /home/john/.conan/data/gtest/1.8.1/bincrafters/stable/package/def9bf6e03568b3736845f4591358d37ed3dd921/include -D CNL_BOOST_ENABLED -I /home/john/.conan/data/benchmark/1.5.0/johnmcfarlane/stable/package/66378947c01141014f9578e457a8467f8489a4e1/include -I /home/john/ws/rounding-overflow/cnl/test/unit -I /home/john/ws/rounding-overflow/cnl/include -D NDEBUG -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/backward -internal-isystem /usr/local/include -internal-isystem /home/john/llvm/lib/clang/10.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O1 -Wconversion -Wno-sign-conversion -fdeprecated-macro -fdebug-compilation-dir /home/john/ws/rounding-overflow/sanitize-clang/test/unit -ferror-limit 19 -ftemplate-backtrace-limit 0 -fmessage-length 0 -fsanitize=object-size -fsanitize-recover=object-size -fgnuc-version=4.2.1 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -faddrsig -o CMakeFiles/Test-scaled_integer-rounding-elastic-integer.dir/scaled_integer/rounding/elastic/integer.cpp.o -x c++ /home/john/ws/rounding-overflow/cnl/test/unit/scaled_integer/rounding/elastic/integer.cpp clang -cc1 version 10.0.0 based upon LLVM 10.0.0 default target x86_64-unknown-linux-gnu ignoring nonexistent directory "/include" ignoring duplicate directory "/usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9" #include "..." search starts here: #include <...> search starts here: /home/john/.conan/data/benchmark/1.5.0/johnmcfarlane/stable/package/66378947c01141014f9578e457a8467f8489a4e1/include /home/john/ws/rounding-overflow/cnl/test/unit /home/john/ws/rounding-overflow/cnl/include /home/john/.conan/data/gtest/1.8.1/bincrafters/stable/package/def9bf6e03568b3736845f4591358d37ed3dd921/include /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9 /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9 /usr/
[llvm-bugs] Issue 13112 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: castIsValid(op, S, Ty) && "Invalid cast!"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #4 on issue 13112 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: castIsValid(op, S, Ty) && "Invalid cast!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13112#c4 ClusterFuzz testcase 5066728655028224 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202004170300:202004180248 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 45573] Code gen for initial-exec TLS differs from gcc
https://bugs.llvm.org/show_bug.cgi?id=45573 Yuxuan Shui changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #2 from Yuxuan Shui --- After further investigation, this seems to be unrelated to the original problem I saw. Closing. -- 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 45598] New: TLS variables in inline assembly not considered TLS variables
https://bugs.llvm.org/show_bug.cgi?id=45598
Bug ID: 45598
Summary: TLS variables in inline assembly not considered TLS
variables
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: yshu...@gmail.com
CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com
Input file 1:
target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"
%struct._glapi_table = type opaque
@table_noop_array = external constant [0 x void ()*], align 8
@_glapi_tls_Dispatch = thread_local(initialexec) local_unnamed_addr global
%struct._glapi_table* bitcast ([0 x void ()*]* @table_noop_array to
%struct._glapi_table*), align 8
; Function Attrs: norecurse nounwind readonly sspstrong uwtable
define %struct._glapi_table* @_glapi_get_dispatch() local_unnamed_addr #2 {
%1 = load %struct._glapi_table*, %struct._glapi_table** @_glapi_tls_Dispatch,
align 8
ret %struct._glapi_table* %1
}
Input file 2:
target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"
module asm ".text"
module asm ".balign 32"
module asm "x86_64_entry_start:"
module asm ".hidden shared_dispatch_stub_0"
module asm ".globl shared_dispatch_stub_0"
module asm ".type shared_dispatch_stub_0, @function"
module asm ".balign 32"
module asm "shared_dispatch_stub_0:"
module asm "\09movq _glapi_tls_Dispatch@GOTTPOFF(%rip), %rax"
module asm "\09movq %fs:(%rax), %r11"
module asm "\09jmp *(8 * 0)(%r11)"
@x86_64_entry_start = external hidden global [0 x i8], align 1
lld complains:
ld.lld: error: TLS attribute mismatch: _glapi_tls_Dispatch
Looks like _glapi_tls_Dispatch in input file 2 is not considered a TLS
variable, presumably because it's defined in inline assembly.
--
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 21782 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-gvn: ASSERT: castIsValid(op, S, Ty) && "Invalid cast!"
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-04-18 Type: Bug New issue 21782 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-gvn: ASSERT: castIsValid(op, S, Ty) && "Invalid cast!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21782 Detailed Report: https://oss-fuzz.com/testcase?key=5649391824404480 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-gvn Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: castIsValid(op, S, Ty) && "Invalid cast!" llvm::CastInst::Create llvm::IRBuilderBase::CreateTruncOrBitCast Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201901010410:201901030410 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5649391824404480 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] Issue 9569 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: Abrt in llvm::report_bad_alloc_error
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #12 on issue 9569 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer: Abrt in llvm::report_bad_alloc_error https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9569#c12 ClusterFuzz testcase 5747225082200064 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202004170300:202004180248 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 45599] New: clang++ crashes and uses over 30GB memory
https://bugs.llvm.org/show_bug.cgi?id=45599 Bug ID: 45599 Summary: clang++ crashes and uses over 30GB memory Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++17 Assignee: unassignedclangb...@nondot.org Reporter: darrell.wri...@gmail.com CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Clang asked me to file this. This happens on at least clang 8, 9, 10, and trunk(Compiler Explorers). In addition latest apple 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] Issue 20329 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Parser::ConsumeAndStoreUntil
Updates: Labels: Deadline-Approaching Comment #1 on issue 20329 by sheriffbot: llvm:clang-fuzzer: Stack-overflow in clang::Parser::ConsumeAndStoreUntil https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20329#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 45600] New: Support TLS relocations referencing non STT_TLS symbols (e.g. STT_SECTION or STT_NOTYPE)
https://bugs.llvm.org/show_bug.cgi?id=45600
Bug ID: 45600
Summary: Support TLS relocations referencing non STT_TLS
symbols (e.g. STT_SECTION or STT_NOTYPE)
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: i...@maskray.me
CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com
Two weeks ago I was trying deleting a hack in MC (integrated assembler)
https://reviews.llvm.org/D77361 and I noticed I can't do that because lld does
not support a TLS relocation referencing a non-TLS symbol.
Related gABI discussion:
https://groups.google.com/forum/#!searchin/generic-abi/TLS%7Csort:date/generic-abi/dJ4_Y78aQ2M/WKggp9fKCgAJ
# a.o
movl %fs:.tdata+4@tpoff, %eax
movl %fs:a@tpoff, %eax
.section .tdata,"awT"
.long 0
a:
.long 0
# lld
movl%fs:2105868, %eax # a TLS relocation referencing a STT_SECTION
movl%fs:-4, %eax
# gold and GNU ld
movl%fs:-4, %eax
movl%fs:-4, %eax
Supporting this requires to fix
// Symbols.cpp:getSymVA
if (d.isTls() && !config->relocatable) {
// Use the address of the TLS segment's first section rather than the
// segment's address, because segment addresses aren't initialized until
// after sections are finalized. (e.g. Measuring the size of .rela.dyn
// for Android relocation packing requires knowing TLS symbol addresses
// during section finalization.)
if (!Out::tlsPhdr || !Out::tlsPhdr->firstSec)
fatal(toString(d.file) +
" has an STT_TLS symbol but doesn't have an SHF_TLS section");
return va - Out::tlsPhdr->firstSec->addr;
and
// Relocations.cpp isStaticLinkTimeConstant
// For the target and the relocation, we want to know if they are
// absolute or relative.
bool absVal = isAbsoluteValue(sym); // STT_SECTION/STT_NOTYPE can be used as
TLS as well
bool relE = isRelExpr(e);
if (absVal && !relE)
return true;
if (!absVal && relE)
return true;
if (!absVal && !relE)
return target->usesOnlyLowPageBits(type);
--
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 45602] New: [WebAssembly] wasm-opt strips symbol names when optimizing
https://bugs.llvm.org/show_bug.cgi?id=45602 Bug ID: 45602 Summary: [WebAssembly] wasm-opt strips symbol names when optimizing Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: jgrave...@google.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk If wasm-opt is present on PATH, it is automatically invoked after wasm-ld. It reuses the -Ox flag from clang to determine its optimization level. Anything other than -O0 leads to wasm-opt stripping the names section. This makes debugging an optimized build more awkward. `clang foo.cpp -g -O1 -o foo.wasm --target=wasm32 -v` does not have a names section `clang foo.cpp -g -O0 -o foo.wasm --target=wasm32 -v` does still have symbols -- 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 45526] LoopVectorization miscompile
https://bugs.llvm.org/show_bug.cgi?id=45526 ayal.z...@intel.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from ayal.z...@intel.com --- Fixed by rG8e0c5f720058: [LV] Mark first-order recurrences as allowed exits -- 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 45603] New: lldb wrongly stopped at a return statement within a for loop
https://bugs.llvm.org/show_bug.cgi?id=45603
Bug ID: 45603
Summary: lldb wrongly stopped at a return statement within a
for loop
Product: lldb
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: yangyib...@hust.edu.cn
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
$ lldb -v
lldb version 9.0.1
$ cat small.c
int main()
{
int j = 0, d = 0;
if (j>=0)
for (; d; d++)
return 0;
return 0;
}
$ clang -g small.c; lldb ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) b small.c:5
Breakpoint 1: where = a.out`main + 35 at small.c:5:5, address =
0x1143
(lldb) run
Process 877280 launched: '/home/yibiao/cv-gcov/a.out' (x86_64)
Process 877280 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x5143 a.out`main at small.c:5:5
2{
3 int j = 0, d = 0;
4 if (j>=0)
-> 5for (; d; d++)
6 return 0;
7 return 0;
8}
(lldb) fr v
(int) j = 0
(int) d = 0
(lldb) step
Process 877280 stopped
* thread #1, name = 'a.out', stop reason = step in
frame #0: 0x515e a.out`main at small.c:6:14
3 int j = 0, d = 0;
4 if (j>=0)
5for (; d; d++)
-> 6 return 0;
7 return 0;
8}
(lldb) step
Process 877280 stopped
* thread #1, name = 'a.out', stop reason = step in
frame #0: 0x5163 a.out`main at small.c:7:3
4 if (j>=0)
5for (; d; d++)
6 return 0;
-> 7 return 0;
8}
*
lldb is wrongly stopped at line 6. Before that, d is 0. Thus, the 6th statement
should be not executed.
--
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 45604] New: Wrong code generated for vector shuffle on x86_64-linux-gnu
https://bugs.llvm.org/show_bug.cgi?id=45604
Bug ID: 45604
Summary: Wrong code generated for vector shuffle on
x86_64-linux-gnu
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: k...@google.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
A recent patch:
https://github.com/llvm/llvm-project/commit/e30d29ebc12a29b2843d40e575809d642920b1a4
triggers causes the following testcase to produce an incorrect result:
// driver.cc
#include
extern "C" void foo(unsigned short* dst, unsigned short *src);
unsigned short src[8] __attribute__((aligned(16))) = {
0x0100, 0x0101, 0x0102, 0x0103, 0x0104, 0x0105, 0x0106, 0x0107,
};
unsigned short dst[32] __attribute__((aligned(16)));
int main() {
foo(dst, src);
for (int i = 0; i < 16; i++) printf("%04x ", dst[i]);
printf("\n");
for (int i = 0; i < 16; i++) printf("%04x ", dst[i + 16]);
printf("\n");
return 0;
}
; vec.ll
define void @foo(<32 x i16>* %dst, <8 x i16>* %src) {
%v1 = load <8 x i16>, <8 x i16>* %src, align 16
%v2 = shufflevector <8 x i16> %v1,
<8 x i16> zeroinitializer,
<16 x i32>
%v3 = shufflevector <16 x i16> %v2,
<16 x i16> ,
<32 x i32>
store <32 x i16> %v3, <32 x i16>* %dst, align 16
ret void
}
Build and run like so on x86_64:
$ path/to/clang -O2 driver.cc vec.ll
$ ./a.out
0100 0101 000b 0101 000b 0102 000b 0103 000b
0104 000b 0105 000b 0106 000b 0107 000b
Notice that the second number (immediately after 0100) should be , not
0101, because we are printing out:
%v3[0] %v3[1] ...
which comes from:
%v2[0] %v2[8] ...
which in turn comes from:
%v1[0] zeroinitializer[0] ...
If I revert Simon's patch, I get as expected.
The patch in question introduces code like so around
llvm/lib/Target/X86/X86ISelLowering.cpp:7466:
while (Scl.getOpcode() == ISD::TRUNCATE ||
Scl.getOpcode() == ISD::ANY_EXTEND ||
Scl.getOpcode() == ISD::ZERO_EXTEND)
Scl = Scl.getOperand(0);
The test case above reaches this "while" loop with the selection DAG nodes like
so:
t128: v4i32 = scalar_to_vector t127 <- N
t127: i32 = zero_extend t87 <- SCl (initially)
t87: i16 = truncate t86
t86: i32 = extract_vector_elt t85, Constant:i64<0> <- SrcExtract
t85: v4i32 = bitcast t7 <- SrcVec
Note that we extract an i32 value, truncate it down to i16, and zero-extend it
back to i32.
I haven't completely understood the code being patched, but here is my current
theory.
The author of the patch seems to want to express the nodes between
scalar_to_vector and extract_vector_elt, inclusive, as one shuffle instruction
on t85.
However, if we express the expression as a shuffle instruction on the bottom
lane of t85, we end up with 32 bits with the rest being 0. What we want is the
bottom 16 bits of t85 with the rest being 0 because we have truncation down to
i16.
If we want to strip ISD::TRUNCATE, we should probably determine the smallest
number of bits required from the source operand (16 bits from t85 in this
case). Then issue a shuffle on a v8i16 value sandwiched with bitcasts like so:
t??: v4i32 = bitcast t??
t??: v8i16 = shuffle t??
t??: v8i16 bitcast t85
--
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
