[llvm-bugs] [Bug 44397] MC produces a R_X86_64_PC32, gas produces a R_X86_64_PLT32
https://bugs.llvm.org/show_bug.cgi?id=44397 George Rimar changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from George Rimar --- Committed as https://reviews.llvm.org/rG11e8e324441a875f1346972384be8b5609aa10c8. Regarding the block against the 10.0 release - I don't know either. -- 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 44594] New: clang++ cannot compile an executable with -fPIE because of possibly incorrect linking of
https://bugs.llvm.org/show_bug.cgi?id=44594 Bug ID: 44594 Summary: clang++ cannot compile an executable with -fPIE because of possibly incorrect linking of Product: clang Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: kola...@mail.ru CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk ``` clang++-10 ./hw.cpp -o hw -fPIE -Wl,-pie -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-z,shstk -Wl,-z,notext -Wl,--verbose GNU ld (GNU Binutils for Ubuntu) 2.33 ... /usr/bin/ld: mode elf_x86_64 attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtbegin.o succeeded /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtbegin.o . /usr/bin/ld: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtbegin.o: relocation R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when making a PIE object /usr/bin/ld: final link failed: nonrepresentable section on output clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` ``` clang++-10 ./hw.cpp -o hw -fPIE -Wl,-pie -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-z,shstk -Wl,-z,notext -fuse-ld=lld -Wl,--verbose ... ld.lld: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtbegin.o ld.lld: error: cannot preempt symbol: __TMC_END__ >>> defined in /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtend.o >>> referenced by crtstuff.c >>> /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtbegin.o:(.text+0x1) ld.lld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC >>> defined in /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtbegin.o >>> referenced by crtstuff.c >>> /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtbegin.o:(.text+0x7) ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC >>> defined in /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtbegin.o >>> referenced by crtstuff.c >>> /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtbegin.o:(.text+0x18) ld.lld: error: cannot preempt symbol: __TMC_END__ >>> defined in /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtend.o >>> referenced by crtstuff.c >>> /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtbegin.o:(.text+0x31) ld.lld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC >>> defined in /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtbegin.o >>> referenced by crtstuff.c >>> /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtbegin.o:(.text+0x38) ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC >>> defined in /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtbegin.o >>> referenced by crtstuff.c >>> /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtbegin.o:(.text+0x5A) clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` ``` g++-9 ./hw.cpp -o hw -fPIE -Wl,-pic -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-flto -Wl,-z,relro -Wl,-z,now -Wl,-z,ibtplt -Wl,-z,ibt -Wl,-z,shstk -Wl,--verbose GNU ld (GNU Binutils for Ubuntu) 2.33 /usr/bin/ld: mode elf_x86_64 attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o succeeded /usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o ``` compiles and links OK https://dev.gentoo.org/~vapier/crt.txt says: >crtbegin.o > GCC uses this to find the start of the constructors. >crtbeginS.o > Used in place of crtbegin.o when generating shared objects/PIEs. >crtend.o > GCC uses this to find the start of the destructors. >crtendS.o > Used in place of crtend.o when generating shared objects/PIEs. -- 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 44596] New: Better block placement - avoid jmp at entry block
https://bugs.llvm.org/show_bug.cgi?id=44596 Bug ID: 44596 Summary: Better block placement - avoid jmp at entry block Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: david.bolvan...@gmail.com CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com Function: https://github.com/microsoft/test-suite/blob/master/MultiSource/Benchmarks/mediabench/g721/g721encode/g711.c#L149 Current ASM: https://godbolt.org/z/qYf5tP alaw2linear(unsigned char): mov eax, edi xor al, 85 movzx eax, al mov ecx, eax shl ecx, 4 movzx ecx, cl shr eax, 4 and eax, 7 cmp eax, 1 je .LBB0_3 testeax, eax jne .LBB0_4 or ecx, 8 jmp .LBB0_5 .LBB0_3: or ecx, 264 jmp .LBB0_5 .LBB0_4: or ecx, 264 dec al shlxecx, ecx, eax .LBB0_5: mov eax, ecx neg eax testdil, dil cmovs eax, ecx ret Better block placement for standard codegen?: alaw2linear(unsigned char): # @alaw2linear(unsigned char) mov eax, edi xor al, 85 movzx eax, al mov ecx, eax shl ecx, 4 movzx ecx, cl shr eax, 4 and eax, 7 cmp eax, 1 je .LBB0_3 testeax, eax jne .LBB0_4 or ecx, 8 .LBB0_5: mov eax, ecx neg eax testdil, dil cmovs eax, ecx ret .LBB0_3: or ecx, 264 jmp .LBB0_5 .LBB0_4: or ecx, 264 dec al shlxecx, ecx, eax jmp .LBB0_5 For this specific case, we have an cmov opportunity too - GCC produces: alaw2linear(unsigned char): xor edi, 85 mov ecx, edi sal ecx, 4 mov edx, edi and ecx, 240 shr dl, 4 lea eax, [rcx+8] and edx, 7 je .L5 lea eax, [rcx+264] movzx ecx, dl mov esi, eax dec ecx cmp dl, 1 shlxeax, eax, ecx cmove eax, esi .L5: mov edx, eax neg edx testdil, dil cmovns eax, edx ret -- 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 44597] New: Undefined behavior in undefined behavior santizer for shifts
https://bugs.llvm.org/show_bug.cgi?id=44597
Bug ID: 44597
Summary: Undefined behavior in undefined behavior santizer for
shifts
Product: compiler-rt
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: ubsan
Assignee: unassignedb...@nondot.org
Reporter: cullm...@absint.de
CC: llvm-bugs@lists.llvm.org
Hi,
we did some experiments with the shift sanitizer.
For the following code:
int main() {
signed char c = -2;
c = c << 4; // Okay integer promotion, sanitizer datastructure says 32-bit
wide operand
c = -2;
c <<= 4; // Integer promotion is done, but sanitizer datastructure says 8-bit
wide operand
// Consequence -> This eventually causes undefined behaviour in
getSIntValue() [Sanitizer Handler Library] since shifting a negative 32-bit
value by (128-8) bits to the left.
return 0;
}
the second call to the shift sanitizer routine will get a sext32 extended value
but has a getIntegerBitWidth of 8 internally in its data structures.
That will lead to "shift overflow" for the signed shift in:
SIntMax Value::getSIntValue() const {
CHECK(getType().isSignedIntegerTy());
if (isInlineInt()) {
// Val was zero-extended to ValueHandle. Sign-extend from original width
// to SIntMax.
const unsigned ExtraBits =
sizeof(SIntMax) * 8 - getType().getIntegerBitWidth();
return SIntMax(Val) << ExtraBits >> ExtraBits;
}
I would propose to change this
return SIntMax(Val) << ExtraBits >> ExtraBits;
to
return SIntMax(UIntMax(Val) << ExtraBits) >> ExtraBits;
to avoid the undefined left shift on a signed value that shifts some bits out.
Or are we confused here?
--
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 44153] copysign folding
https://bugs.llvm.org/show_bug.cgi?id=44153 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||7bee94410ce2 Resolution|--- |FIXED --- Comment #11 from Sanjay Patel --- There may still be a few more possible enhancements, but we should get the motivating problem after: https://reviews.llvm.org/rG7bee94410ce2 -- 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 44578] 'omp target' directive segfaults Clang with std=c++11
https://bugs.llvm.org/show_bug.cgi?id=44578 Alexey Bataev changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||366356361cf3abf97fbcfe9a046 ||7b1ed1610401f -- 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 44586] MSAN complains about uninitialized value in __cxxabiv1::__getExceptionClass
https://bugs.llvm.org/show_bug.cgi?id=44586 Kyle Edwards changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #14 from Kyle Edwards --- So, I haven't been able to get a completely libgcc-free build. However, I was able to build with -DLIBCXX_USE_LLVM_UNWINDER=ON, which seems to have fixed the issue I've been having. So, I will close this as "invalid" due to user error. -- 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 43895] clang crash
https://bugs.llvm.org/show_bug.cgi?id=43895 Alexander Lanin changed: 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 44586] MSAN complains about uninitialized value in __cxxabiv1::__getExceptionClass
https://bugs.llvm.org/show_bug.cgi?id=44586 Eric Fiselier changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|REOPENED --- Comment #15 from Eric Fiselier --- I wouldn't say this is user error. At minimum this needs to be documented better. But I think some further investigating is warranted. I'll bring this to the attention of the sanitizer folks later this week. -- 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 44599] New: Missed unused variable
https://bugs.llvm.org/show_bug.cgi?id=44599 Bug ID: 44599 Summary: Missed unused variable Product: clang Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: y...@tsoft.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 23036 --> https://bugs.llvm.org/attachment.cgi?id=23036&action=edit testcase.c The local variable "v" is only assigned to, but is never used. clang 80 and 90 miss that. gcc doesn't miss that. -- 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 16589] Support for -W[no-]unused-but-set-{variable, parameter}
https://bugs.llvm.org/show_bug.cgi?id=16589 David Blaikie changed: What|Removed |Added CC||dblai...@gmail.com Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from David Blaikie --- *** This bug has been marked as a duplicate of bug 9824 *** -- 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 44599] Missed unused variable
https://bugs.llvm.org/show_bug.cgi?id=44599 David Blaikie changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||dblai...@gmail.com --- Comment #1 from David Blaikie --- *** This bug has been marked as a duplicate of bug 9824 *** -- 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 40222] StaticAnalyzer/Core/Z3ConstraintManager.cpp uses outdated interface to Z3
https://bugs.llvm.org/show_bug.cgi?id=40222 Mikhail changed: What|Removed |Added CC||mikhail.rama...@gmail.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Mikhail --- The latest version of the Z3 backend uses Z3_get_error_msg, as Z3_get_error_msg_ex was deprecated. -- 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 40128] Trunk doesn't build with libz3-dev of ubuntu 18.04
https://bugs.llvm.org/show_bug.cgi?id=40128 Mikhail 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 44600] New: [AArch64][ARM] experimental.vector.reduce without FMF asserts
https://bugs.llvm.org/show_bug.cgi?id=44600
Bug ID: 44600
Summary: [AArch64][ARM] experimental.vector.reduce without FMF
asserts
Product: libraries
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: nikita@gmail.com
CC: arnaud.degrandmai...@arm.com,
llvm-bugs@lists.llvm.org, peter.sm...@linaro.org,
ties.st...@arm.com
define float @test_fadd_ordered(<3 x float> %v) {
%res = call float @llvm.experimental.vector.reduce.v2.fadd.f32.v3f32(float
0.0, <3 x float> %v)
ret float %res
}
define float @test_fmax_unordered_nan(<4 x float> %v) {
%res = call reassoc float @llvm.experimental.vector.reduce.fmax.v4f32(<4 x
float> %v)
ret float %res
}
declare float @llvm.experimental.vector.reduce.v2.fadd.f32.v3f32(float
%start_value, <3 x float> %a)
declare float @llvm.experimental.vector.reduce.fmax.v4f32(<4 x float> %a)
The first case asserts on both AArch64 and ARM because there is no support for
legalizing VECREDUCE_STRICT. The second one asserts on AArch64 because it
requires fmax reductions to be nnan.
--
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 10276] fread() with _FORTIFY_SOURCE may compile to an infinite loop (was: Problems with zlib)
https://bugs.llvm.org/show_bug.cgi?id=10276 Christoph Cullmann changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WORKSFORME --- Comment #14 from Christoph Cullmann --- I consider this fixed, at least my zlib issues are resolved since long. -- 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 44347] Hexagon cmplt instruction have incorrect assembly syntax
https://bugs.llvm.org/show_bug.cgi?id=44347 Krzysztof Parzyszek changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Krzysztof Parzyszek --- The C4 instructions negate the result of the comparison (Pd = !cmp(...)). The J4_cmpOP_C_jumpnv instructions do: if (R.new OP other-val) == C then jump ... For example, J4_cmplt_f_jumpnv_nt will branch if (Ns8.new < Rt32) is false, or, if (Rt32 > Ns8.new) is false, i.e. if !cmp.gt(Rt32, Ns8.new). -- 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 19870 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Token::getIdentifierInfo
Updates: Status: WontFix Comment #3 on issue 19870 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Token::getIdentifierInfo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19870#c3 ClusterFuzz testcase 5669417644195840 is flaky and no longer crashes, so closing issue. 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 20256 in oss-fuzz: llvm:clang-objc-fuzzer: Segv on unknown address in clang::Expr::EvaluateKnownConstInt
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 Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Security_Severity-High Reported-2020-01-21 Type: Bug-Security New issue 20256 by ClusterFuzz-External: llvm:clang-objc-fuzzer: Segv on unknown address in clang::Expr::EvaluateKnownConstInt https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20256 Detailed Report: https://oss-fuzz.com/testcase?key=5105673205710848 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-objc-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Segv on unknown address Crash Address: Crash State: clang::Expr::EvaluateKnownConstInt clang::FieldDecl::getBitWidthValue clang::FieldDecl::isZeroLengthBitField Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=201911200438:201911230451 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5105673205710848 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
