[llvm-bugs] [Bug 38172] Building of LLVM with expensive checks fails with libstdc++-8-dev:amd64 8.1.0-10
https://bugs.llvm.org/show_bug.cgi?id=38172 Andrew V. Tischenko changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||andrew.v.tische...@gmail.co ||m --- Comment #4 from Andrew V. Tischenko --- *** This bug has been marked as a duplicate of bug 37652 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38190] New: -fdebug-types-section unusable on macos
https://bugs.llvm.org/show_bug.cgi?id=38190
Bug ID: 38190
Summary: -fdebug-types-section unusable on macos
Product: libraries
Version: trunk
Hardware: PC
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: DebugInfo
Assignee: jdevliegh...@apple.com
Reporter: lab...@google.com
CC: llvm-bugs@lists.llvm.org
labath4 ~/ll/build/opt $ bin/clang -fdebug-types-section -target
x86_64-pc-linux -x c++ - -o /dev/null -c -g <<<"struct A{}; void f(A a) { }"
labath4 ~/ll/build/opt $ bin/clang -target x86_64-apple-macosx -x c++ - -o
/dev/null -c -g <<<"struct A{}; void f(A a) { }"
warning: include path for stdlibc++ headers not found; pass '-std=libc++' on
the command line to use the
libc++ standard library instead [-Wstdlibcxx-not-found]
1 warning generated.
labath4 ~/ll/build/opt $ bin/clang -fdebug-types-section -target
x86_64-apple-macosx -x c++ - -o /dev/null -c -g <<<"struct A{}; void f(A a) {
}"
warning: include path for stdlibc++ headers not found; pass '-std=libc++' on
the command line to use the
libc++ standard library instead [-Wstdlibcxx-not-found]
Stack dump:
0. Program arguments:
/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0 -cc1 -triple
x86_64-apple-macosx10.4.0 -Wdeprecated-objc-isa-usage
-Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -discard-value-names -main-file-name -
-mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim
-masm-verbose -munwind-tables -faligned-alloc-unavailable -target-cpu core2
-dwarf-column-info -debug-info-kind=standalone -dwarf-version=2
-debugger-tuning=lldb -mllvm -generate-type-units -coverage-notes-file
/dev/null.gcno -resource-dir
/usr/local/google/home/labath/ll/build/opt/lib/clang/7.0.0 -fdeprecated-macro
-fdebug-compilation-dir /usr/local/google/home/labath/ll/build/opt
-ferror-limit 19 -fmessage-length 105 -fblocks -fblocks-runtime-optional
-fencode-extended-block-signature -fregister-global-dtors-with-atexit
-fobjc-runtime=macosx-10.4.0 -fobjc-dispatch-method=non-legacy -fcxx-exceptions
-fexceptions -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics
-o /dev/null -x c++ -
1. parser at end of file
2. Code generation
#0 0x0166a994 PrintStackTraceSignalHandler(void*)
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x166a994)
#1 0x01668ab0 llvm::sys::RunSignalHandlers()
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x1668ab0)
#2 0x0166ab42 SignalHandler(int)
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x166ab42)
#3 0x7fb27f9a50c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
#4 0x01438860 llvm::MCExpr::findAssociatedFragment() const
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x1438860)
#5 0x01c75674 llvm::AsmPrinter::emitDwarfSymbolReference(llvm::MCSymbol
const*, bool) const
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x1c75674)
#6 0x01c99af2 llvm::DwarfUnit::emitCommonHeader(bool,
llvm::dwarf::UnitType)
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x1c99af2)
#7 0x01c99b7b llvm::DwarfTypeUnit::emitHeader(bool)
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x1c99b7b)
#8 0x01c90baa llvm::DwarfFile::emitUnit(llvm::DwarfUnit*, bool)
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x1c90baa)
#9 0x01c85410
llvm::DwarfDebug::addDwarfTypeUnitType(llvm::DwarfCompileUnit&,
llvm::StringRef, llvm::DIE&, llvm::DICompositeType const*)
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x1c85410)
#10 0x01c94ef1 llvm::DwarfUnit::getOrCreateTypeDIE(llvm::MDNode const*)
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x1c94ef1)
#11 0x01c94c2c llvm::DwarfUnit::addType(llvm::DIE&, llvm::DIType
const*, llvm::dwarf::Attribute)
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x1c94c2c)
#12 0x01cc397f
llvm::DwarfCompileUnit::applyVariableAttributes(llvm::DbgVariable const&,
llvm::DIE&)
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x1cc397f)
#13 0x01c7e33a llvm::DwarfDebug::finalizeModuleInfo()
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x1c7e33a)
#14 0x01c7e778 llvm::DwarfDebug::endModule()
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x1c7e778)
#15 0x01c6d518 llvm::AsmPrinter::doFinalization(llvm::Module&)
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x1c6d518)
#16 0x012a5353 llvm::FPPassManager::doFinalization(llvm::Module&)
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x12a5353)
#17 0x012a5774 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/usr/local/google/home/labath/ll/build/opt/bin/clang-5.0+0x12a5774)
#18 0x017ddb55 clang::EmitBackendOutput(clang::Diagnost
[llvm-bugs] [Bug 38191] New: Assert in TTI::getMinMaxReductionCost
https://bugs.llvm.org/show_bug.cgi?id=38191 Bug ID: 38191 Summary: Assert in TTI::getMinMaxReductionCost Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: jo...@netbsd.org CC: llvm-bugs@lists.llvm.org Created attachment 20562 --> https://bugs.llvm.org/attachment.cgi?id=20562&action=edit Test case Build the attached source with -O2 with assert-enabled 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38192] New: [PowerPC] Clang biases __builtin_xxpermdi differently from GCC on LE
https://bugs.llvm.org/show_bug.cgi?id=38192
Bug ID: 38192
Summary: [PowerPC] Clang biases __builtin_xxpermdi differently
from GCC on LE
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: nemanja.i@gmail.com
CC: llvm-bugs@lists.llvm.org
Calls to these builtins produce different results with the two compilers. Clang
needs to change to apply the same bias as GCC does.
vector short test0(vector short a, vector short b) {
return vec_xxpermdi(a, b, 0);
}
vector short test1(vector short a, vector short b) {
return vec_xxpermdi(a, b, 1);
}
vector short test2(vector short a, vector short b) {
return vec_xxpermdi(a, b, 2);
}
vector short test3(vector short a, vector short b) {
return vec_xxpermdi(a, b, 3);
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38193] New: Assertion during EmitStoreofScalar
https://bugs.llvm.org/show_bug.cgi?id=38193 Bug ID: 38193 Summary: Assertion during EmitStoreofScalar Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: jo...@netbsd.org CC: llvm-bugs@lists.llvm.org Created attachment 20563 --> https://bugs.llvm.org/attachment.cgi?id=20563&action=edit Test case Build the attached Objective C code, observe: .../llvm/lib/IR/Instructions.cpp:1202: void llvm::StoreInst::AssertOK(): Assertion `getOperand(0)->getType() == cast(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"' failed. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38191] Assert in TTI::getMinMaxReductionCost
https://bugs.llvm.org/show_bug.cgi?id=38191 Simon Pilgrim changed: What|Removed |Added Fixed By Commit(s)||337280 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Simon Pilgrim --- Fixed in rL337280 - we might want to support reduction of pointers some day (and I've added a test ready for it), but for now we just early-out if we're not reducing float/integer vector types. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37808] llvm/lib/Analysis/MemorySSAUpdater.cpp:366: void llvm::MemorySSAUpdater::fixupDefs(const llvm::SmallVectorImpl&): Assertion `MSSA->dominates(NewDef, FirstD
https://bugs.llvm.org/show_bug.cgi?id=37808 Alexandros Lamprineas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Alexandros Lamprineas --- Fixed by rL337149. Resolving. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36251] Crash in "intern-state" thread after removing breakpoints and continue
https://bugs.llvm.org/show_bug.cgi?id=36251 lab...@google.com changed: What|Removed |Added Resolution|--- |FIXED CC||lab...@google.com Status|NEW |RESOLVED --- Comment #1 from lab...@google.com --- I believe this was fixed by r330163. Please reopen if the problem persists. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 23287] lldb crashes when displaying information for an array of structs and inside of struct there is a long double member field
https://bugs.llvm.org/show_bug.cgi?id=23287 lab...@google.com changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||lab...@google.com --- Comment #1 from lab...@google.com --- I believe this was fixed by r331884 (i.e., this was a duplicate of bug 35860). Please reopen if you still see the problem. *** This bug has been marked as a duplicate of bug 35860 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 8008 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in Evaluate
Updates: Labels: Deadline-Approaching Comment #3 on issue 8008 by sheriff...@chromium.org: llvm/clang-fuzzer: Stack-overflow in Evaluate https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8008#c3 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38016] clang-cl shouldn't emit Wmsvc-not-found if -fuse-ld=lld is passed
https://bugs.llvm.org/show_bug.cgi?id=38016 Nico Weber changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nico Weber --- r337290. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27237] Cannot link lldb-server on a i386 system
https://bugs.llvm.org/show_bug.cgi?id=27237 lab...@google.com changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED CC||lab...@google.com --- Comment #4 from lab...@google.com --- I don't think there is a real solution to this and -gsplit-dwarf is a viable workaround. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25632] LLDB does not use the .debug_frame section to read the CFI
https://bugs.llvm.org/show_bug.cgi?id=25632 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||lab...@google.com --- Comment #3 from lab...@google.com --- debug_frame sections is now supported. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38194] New: [regression] shuffle sequence in _mm256_blend_pd does not lower to vblendpd anymore
https://bugs.llvm.org/show_bug.cgi?id=38194
Bug ID: 38194
Summary: [regression] shuffle sequence in _mm256_blend_pd does
not lower to vblendpd anymore
Product: new-bugs
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: release blocker
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: gonzalob...@gmail.com
CC: llvm-bugs@lists.llvm.org
The regression was found after updating Rust to LLVM7-trunk from LLVM6.
This Rust code (https://godbolt.org/g/mrCRcd):
#![feature(repr_simd, platform_intrinsics)]
#![allow(non_camel_case_types)]
extern "platform-intrinsic" {
pub fn simd_shuffle4(x: T, y: T, idx: [u32; 4]) -> U;
}
#[repr(simd)]
pub struct __m256d(f64, f64, f64, f64);
#[inline]
#[target_feature(enable = "avx")]
unsafe fn _mm256_blend_pd(a: __m256d, b: __m256d, imm8: i32) -> __m256d {
let imm8 = (imm8 & 0xFF) as u8;
macro_rules! blend4 {
($a:expr, $b:expr, $c:expr, $d:expr) => {
simd_shuffle4(a, b, [$a, $b, $c, $d]);
};
}
macro_rules! blend3 {
($a:expr, $b:expr, $c:expr) => {
match imm8 & 0x8 {
0 => blend4!($a, $b, $c, 3),
_ => blend4!($a, $b, $c, 7),
}
};
}
macro_rules! blend2 {
($a:expr, $b:expr) => {
match imm8 & 0x4 {
0 => blend3!($a, $b, 2),
_ => blend3!($a, $b, 6),
}
};
}
macro_rules! blend1 {
($a:expr) => {
match imm8 & 0x2 {
0 => blend2!($a, 1),
_ => blend2!($a, 5),
}
};
}
match imm8 & 0x1 {
0 => blend1!(0),
_ => blend1!(4),
}
}
#[target_feature(enable = "avx")]
pub unsafe fn foo(a: __m256d, b: __m256d) -> __m256d {
_mm256_blend_pd(a, b, 9)
}
Used to lower to a vblendpd instruction, but now it lowers to:
example::foo:
vmovaps ymm0, ymmword ptr [rsi]
vblendps ymm0, ymm0, ymmword ptr [rdx], 195
vmovaps ymmword ptr [rdi], ymm0
mov rax, rdi
vzeroupper
ret
The LLVM-IR emitted without optimizations is (https://godbolt.org/g/xsWfr8):
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define internal void @_ZN7example15_mm256_blend_pd17h932ae730d6cb84edE(<4 x
double>* noalias nocapture sret dereferenceable(32), <4 x double>* noalias
nocapture dereferenceable(32) %a, <4 x double>* noalias nocapture
dereferenceable(32) %b, i32 %imm8) unnamed_addr #0 {
%_77 = alloca i8, align 1
%_70 = alloca i8, align 1
%_67 = alloca i8, align 1
%_60 = alloca i8, align 1
%_53 = alloca i8, align 1
%_50 = alloca i8, align 1
%_47 = alloca i8, align 1
%_40 = alloca i8, align 1
%_33 = alloca i8, align 1
%_30 = alloca i8, align 1
%_23 = alloca i8, align 1
%_16 = alloca i8, align 1
%_13 = alloca i8, align 1
%_10 = alloca i8, align 1
%_7 = alloca i8, align 1
%1 = and i32 %imm8, 255
%2 = icmp ule i32 %1, -1
call void @llvm.assume(i1 %2)
%3 = trunc i32 %1 to i8
%4 = and i8 %3, 1
store i8 %4, i8* %_7, align 1
%5 = load i8, i8* %_7, align 1
%6 = icmp eq i8 %5, 0
br i1 %6, label %bb1, label %bb2
bb1: ; preds = %start
%7 = and i8 %3, 2
store i8 %7, i8* %_10, align 1
%8 = load i8, i8* %_10, align 1
%9 = icmp eq i8 %8, 0
br i1 %9, label %bb4, label %bb5
bb2: ; preds = %start
%10 = and i8 %3, 2
store i8 %10, i8* %_47, align 1
%11 = load i8, i8* %_47, align 1
%12 = icmp eq i8 %11, 0
br i1 %12, label %bb33, label %bb34
bb3: ; preds = %bb6, %bb35
ret void
bb4: ; preds = %bb1
%13 = and i8 %3, 4
store i8 %13, i8* %_13, align 1
%14 = load i8, i8* %_13, align 1
%15 = icmp eq i8 %14, 0
br i1 %15, label %bb7, label %bb8
bb5: ; preds = %bb1
%16 = and i8 %3, 4
store i8 %16, i8* %_30, align 1
%17 = load i8, i8* %_30, align 1
%18 = icmp eq i8 %17, 0
br i1 %18, label %bb20, label %bb21
bb6: ; preds = %bb9, %bb22
br label %bb3
bb7: ; preds = %bb4
%19 = and i8 %3, 8
store i8 %19, i8* %_16, align 1
%20 = load i8, i8* %_16, align 1
%21 = icmp eq i8 %20, 0
br i1 %21, label %bb10, label %bb11
bb8: ; preds = %bb4
%22 = and i8 %3, 8
store i8 %22, i8* %_23, align 1
%23 = load i8, i8* %_23, align 1
%24 = icmp eq i8 %23, 0
br i1 %24, label %bb15, label %bb16
bb9: ; preds = %bb12, %bb17
br label %bb6
bb10: ; preds = %bb7
%25 = load <4 x double>, <4 x double>* %a, align 32
%26 = load <4 x double>, <4 x double>* %b, align 32
%27 = shufflevector <4 x double> %25, <4 x double> %26, <4 x i32>
store <4 x double> %27, <4 x double>* %0, align 32
br label %bb13
bb11: ; preds = %bb7
%28 = load <4 x double>, <4 x double>* %a, align 32
%29 = load <4 x double>, <4 x double>* %b, align 32
%30 = shufflevector <4 x double> %28, <4 x double> %29, <4 x i32>
store
[llvm-bugs] [Bug 37317] ModuleList::FindGlobalVariables fails with append=false
https://bugs.llvm.org/show_bug.cgi?id=37317 Tom Tromey changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Tom Tromey --- The fix went in a while ago. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38195] New: [regression] _mm_blend_epi16 does not lower to pblendw anymore
https://bugs.llvm.org/show_bug.cgi?id=38195
Bug ID: 38195
Summary: [regression] _mm_blend_epi16 does not lower to pblendw
anymore
Product: new-bugs
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: release blocker
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: gonzalob...@gmail.com
CC: llvm-bugs@lists.llvm.org
This regression was discovered while updating Rust from LLVM6 to LLVM7-trunk.
The following Rust code
(https://rust.godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAKxACZSAbAQwDtRiBXAZwNK9Q7FkmEAHIApLQDMYMOICsAIQBmmJgUGYIxTAAdiAfS54AtulIBqBnhYBrAwwYA3EwZsFiN48i6XjZg2VlPABKBQARcQAGAEFJGTklJkdUAHcIFlQWA2QmE0wGHKYuTAMCAE9dTC4w%2BUjY6JjuTAsedBAQfJNxKUVGxpMmZGJUA04GatkLNBYePGVytxMTAA4LcQB2PtiLXYsIABJTVZBMAA99SwPz3VZ2vCwWAhD1qUipbHWtxr3f9ekFIpkgw0hBUE5MMRlCDUjZgA5CJDkjUIj8/rtBgRkAh9kdlisXpIAGwWKIAIwAjFSKQZqRSvtsYuj0VFXu9PtcLndZBAoiFSGjmXt6T12RZObcWOgeRT%2BYKhRZaGyehybtzILQ5TsFbspMqPuK1VKeVItUydRYACz61Vc42QS1mi0WeQ2w126WQeROi0k0Uq92Sz0QIk%2BnUbN0S9UQDZhhVrf0GqP2iAEgXanUATkjRuDmbjQoprMTtqDMr56fNOqpOY9MtlledFKVJcD0ebBeZFL1reTwe7nfRFOtvdzMsdjYtFNdo7rkGng7%2BFL9bwDfZlocn1Yjs7L89jW4VFITq6TY/naflhezu/b%2BcPQtoxdPpejT8Xv1oIpfbZTX4/ey0C2P7rhqmoPsy0i1nuEDSABuy0COIHnrBE5XpBM7IXOsHehB6K0CuYqgbBm7ofhO5YTBtAHmRfy0CeREofR8GKjelFvvetG/FIz6MdhPEsVI358TBQmCcBInRlI4FcXsUg9uxKbyYJSGSUpaEZgqUiYWpwbaYJhFrihUikZpQpSBRukmjRZnMlIDFGfxl62eiUhsVZkBuSxlq8Y5ME%2Bd5wl%2BdGloNrJuyWhJwUppF3kKR5ECWqaeF/JaqnRcGaXeTpGU8pauHhVahlnthlqmVWCqWpZuUOjZFVCpaDklf5zn1cylruTViWcS5fzyL5zXRv1LHyEFg0pqNI1ReNwbyDJvW/PI8VdUtI3pTNPLyBpbXovIOUbV6BULXs8jFa%2BE3lc68jVQdEDXSNTXnbNrVXZ1t3yD1O1/ESA1PTyP0sUSY1/ZAQOA9NIMhvNX2/ESy23XDgPrZDRLbc6RL7SjR0w3sRJnb%2BwZ44DN0o3V6OPQT/0vb6b0o59zobL9lOQIzLEbMDzMxmFx27BsEOc3zbPw5DGzJYVGzIwLaMWhsmMC9jDP48RGyXTLJMC2TMsU8r1PhrTAv0xaKxM8RxssSsHOm9zOO7Cs/Om9DzorMLnPO%2Bbkum9LOorHLpsK0bSsoSsqve%2Brpua972tB7r8b66bhtZibKGZhWhWZpbyfW86mb28njsWpmLvEYXLGZh7ydewqma%2B8n/tZoH2GZiHVdh8nEdV1Hjcx0KmZx8nCdHlESfYUWqc8xYRYZyPURZ1OUS59P%2BfVlERcoUWYvj0W5fT5XhZRDX0914PDcwUWzd7630/t3vnen1E3ddlEffTwPhZFtB7ZFix1Ifym1Lf82X%2B/YOwpV%2BFSVeI8BygOFMOIB9Zd5dmnHA%2BcC5oG7CpCfT%2B59EGX1PhSa%2BiDb6fwfkOCkz88Gvy7E%2BZBEBmxjxthPL8NDmyz2rEBZhQFv5QVvH/OCaDGHb1PohLhB8hFH0LARDh2ChzUQ4QQmRRDeEkKXLQch7ZVHfx4swgS/DuxT1PmJXR0ltFLyPPJbRG8GHdkEe2KQCChzaW0eIrsJltHSKXBZbR8iPGKP7PZTRai/5eV0T5ZhAUQn6PbKFb%2BkUwmmMLElMJlimxpTCfYpc%2BUwnOKHGVMJ7iwFVTCd4gpvjxzKIKYE/sHVv79WYcNXRo06msKPHNOp8SuxLTqckqcW06npLAXtOp2SlynTqfk4U106nFImaU%2Bc8hykTMqTKD638frMIBrooG6zmmFiJAvU%2BezVkQIOd06sqN1n9OFBjdZwywF43WeM9BRJcHtmeas2ZtCiQLKeUs%2BcRJKFDkZsw1muj2bAp2V2PmwL2mAuOe2UW38JbAsueg2WwLbnChVsCx5E8NgvL/nixFHz8HfNxb82hGwAVLmNsws2uiLa0ohUOO2tKYXUrhX/N29KbGcpRRPH2tKMXoODrSnFx58X9hWNM4VxKVikuPOShV38U7MJTsqyJf907Kv2XeNlYDC6qtOUeMuqq%2BVkNEXeIVE8m6qrFZmCVMp7XKuJZmeVvdVVUs/EPGhT56HOifBq4MAaWJPh1X%2BeeIaV4%2BpXpGnlQaoh8qfBa8NVqnyYPDTip8DqNRRGlYqe%2B0bSVPnJcWkN78eFBq/vwr8gaeQ1rLWGyterALdh9VAwqX4411uHGW5NlbU3LjbZm/Bba81fg%2BeOstJayEhuoRWut75q1MPnWBJldF2ErtgpwpdHKg18I7YhH1wil19oXamyRm6gKZtkZe6is6J3MSXSWjR1atGXp0R2oSPrDGfsbXW6SIbzHvqNY%2BOx37E2OPfam1x77M2ePfWO%2By36i1uW/Z6wCoTL3hI7aFH10Tq2xKw82hCiSsMgcgqkrDibMlYdTbkrDmbClYbHY1PDRaOp4fQwhWpl76kdsabxtdn5Wm8eI4qTpvHyP4V6bxvlBgfV7UXJseoFVlM9EZGphoWm4gNABEkFI6RTD6FQFUQwyAKhVBRHURo5wCCQhYP8WgABhSQLZviaXiICawdgDAsDyC0UUjnHAuAAHRnGDiFrgJRQohd0GSCYUpUiudRJpZQDm4sJfQOkJgIALB4GXOFywZJcv5aJIVvL%2BJcscAJBYAAtAGUr4X1P9A2Cp/oenFA6H0BAfw6Bagqd0BwMkrQPAcHMxYAwBgTDNhWHgCAeBUaWAW46Zr2nPNKC68QHrpg%2BspZiIN4bPBODjcayseby4lsXby1d0rl2iR3Ye9d0Mq2dNxA6zYbzmA9vrcUAQJgxBgCYAIIENQGgdAQEwH5%2BLAW3iOai5gS0IWKSuf640AA9Gj/4UhATIGUPCdQHgIB2Z4JYYoJRiDA68ITjLkOstLfxGyUkZwABifJUexAOxYDgswmCqAsGlibywDDQ6lAYPQpWIA5Ym1NmbeAiu5cm9N%2BicuKsnDywBurAZFey4ZPKCYBALBS9O4zroHQPCsC4CYDgdnJdhF6OsTS%2BuLDFae%2BFk3mATBm%2BIBbq3NuyR28UA7iqgxhijHGJMMA0xgS696ocY4KxTgXGIISH8mxGTOhp4lyXRWrjx7CL1NTvR5SaeDx7r3PvrdaBmHMBYSxVg8nj5YXIjgQj57iK1/ounsdKD%2BwDoHIP1CaAh1DiYjPXNMCcGcFHe3Ofc64LzloAvlCoFQJLhXMvlfy%2Bl0r2bLx6sGm18rmPFUpuuBF%2BgMXugJdMBz0z1nbeS%2Bd5iKIfkDAxDyFEKQFgYgoif9QGIAAJW4AN34EEGECx1oE/wIB/xf35AQDUCwGIEoH5FsBAHkhC1OmeSbhMmdjmhWEYDEEtE/091Hi/xgNIH/1EE/y4BACiFIGgNEF/35DgFgCQDQBMCvwmDIAoAgHYM4MhBABYDwGAAQAIAYHKFIGCAYDs2IBoIgGK0YM/zJBsH%2B3KDEApE/3YPyCeAAHkWBxDyCsBBg2AJhDC8AdBzM8AIQaDFDSBzhMBkBK91DP93AChyCPBTAYDX9WB2BgDGA8AyQaDIB%2BQTMCA8AsgbDasnMLBQjasJgIQGBRQ9QoiLBJQ8BkBRQmAyQSADcUje9AcCBatkBBtRRcgWBMh9CmBbAWgUjpDUBRRlB1A6toisAyQOBgAbBl9RRWQUi0AsBAcWBatudCAuBRQNC%2BABAhARBwI39RAP8yDbDKDOAeBkALAhCRCxDyh9hcBCASAIDLAnNUAOC8AuCsdZQLAgCeAoCvC4CECBCIAUC0CpAQsn5XVGZVFnZuwVhMwCDRAiCFjf8KCxBqDaD6CvDSAWDEAQABACBBteAeC%2BCTiBCKQ7D8AiAkD6BUhvddBnDX939P9v9FixB4h6RYQCAcRlisQ1jhDRDxDrjFDW9SBUD0D5JWS2T2Tfj/jCTATKCQS6CGCmC8TRBICAS/9gSwSGT%2BQIRZDwjv9LQgA%3D%3D%3D):
#![feature(repr_simd, link_llvm_intrinsics, simd_ffi)]
#![allow(non_camel_case_types)]
use std::mem;
macro_rules! constify_imm8 {
($imm8:ex
[llvm-bugs] [Bug 27257] Integer division expression not correctly evaluated
https://bugs.llvm.org/show_bug.cgi?id=27257 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #4 from lab...@google.com --- The example in the bug report is working correctly now, so I guess this was fixed at some point. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38196] New: [regression] _mm_blend_pd_blendpd does not emit blendpd anymore but emits blendps instead
https://bugs.llvm.org/show_bug.cgi?id=38196 Bug ID: 38196 Summary: [regression] _mm_blend_pd_blendpd does not emit blendpd anymore but emits blendps instead Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: gonzalob...@gmail.com CC: llvm-bugs@lists.llvm.org Sorry, the godbolt link had an error, here is the correct one: https://rust.godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAKxACZSAbAQwDtRiBXAZwNK9Q7FkmEAHIApLQDMYMOICsAIQBmmJgUGYIxTAAdiAfS54AtulIBqBnhYBrAwwYA3EwZsFiN48i6XjZg2VlPABKBQARcQAGAEFJGTklJkdUAHcIFlQWA2QmE0wGHKYuTAMCAE9dTC4w%2BUjY6JjuTAsedBAQfJNxKUVGxpMmZGJUA04GatkLNBYePGVytxMTAA4LcQB2PtiLXYsIABJTVZBMAA99SwPz3VZ2vCwWAhD1qUipbHWtxr3f9ekFIpkgw0hBUE5MMRlCDUjZgA5CJDkjUIj8/rtBgRkAh9kdlisXpIAGwWKIAIwAjFSKQZqRSvtsYuj0VFXu9PtcLndZBAoiFSGjmXt6T12RZObcWOgeRT%2BYKhRZaGyehybtzILQ5TsFbspMqPuK1VKeVItUydRYACz61Vc42QS1mi0WeQ2w126WQeROi0k0Uq92Sz0QIk%2BnUbN0S9UQDZhhVrf0GqP2iAEgXanUATkjRuDmbjQoprMTtqDMr56fNOqpOY9MtlledFKVJcD0ebBeZFL1reTwe7nfRFOtvdzMsdjYtFNdo7rkGng7%2BFL9bwDfZlocn1Yjs7L89jW4VFITq6TY/naflhezu/b%2BcPQtoxdPpejT8Xv1oIpfbZTX4/ey0C2P7rhqmoPsy0i1nuEDSABuy0COIHnrBE5XpBM7IXOsHehB6K0CuYqgbBm7ofhO5YTBtAHmRfy0CeREofR8GKjelFvvetG/FIz6MdhPEsVI358TBQmCcBInRlI4FcXsUg9uxKbyYJSGSUpaEZgqUiYWpwbaYJhFrihUikZpQpSBRukmjRZnMlIDFGfxl62eiUhsVZkBuSxlq8Y5ME%2Bd5wl%2BdGloNrJuyWhJwUppF3kKR5ECWqaeF/JaqnRcGaXeTpGU8pauHhVahlnthlqmVWCqWpZuUOjZFVCpaDklf5zn1cylruTViWcS5fzyL5zXRv1LHyEFg0pqNI1ReNwbyDJvW/PI8VdUtI3pTNPLyBpbXovIOUbV6BULXs8jFa%2BE3lc68jVQdEDXSNTXnbNrVXZ1t3yD1O1/ESA1PTyP0sUSY1/ZAQOA9NIMhvNX2/ESy23XDgPrZDRLbc6RL7SjR0w3sRJnb%2BwZ44DN0o3V6OPQT/0vb6b0o59zobL9lOQIzLEbMDzMxmFx27BsEOc3zbPw5DGzJYVGzIwLaMWhsmMC9jDP48RGyXTLJMC2TMsU8r1PhrTAv0xaKxM8RxssSsHOm9zOO7Cs/Om9DzorMLnPO%2Bbkum9LOorHLpsK0bSsoSsqve%2Brpua972tB7r8b66bhtZibKGZhWhWZpbyfW86mb28njsWpmLvEYXLGZh7ydewqma%2B8n/tZoH2GZiHVdh8nEdV1Hjcx0KmZx8nCdHlESfYUWqc8xYRYZyPURZ1OUS59P%2BfVlERcoUWYvj0W5fT5XhZRDX0914PDcwUWzd7630/t3vnen1E3ddlEffTwPhZFtB7ZFix1Ifym1Lf82X%2B/YOwpV%2BFSVeI8BygOFMOIB9Zd5dmnHA%2BcC5oG7CpCfT%2B59EGX1PhSa%2BiDb6fwfkOCkz88Gvy7E%2BZBEBmxjxthPL8NDmyz2rEBZhQFv5QVvH/OCaDGHb1PohLhB8hFH0LARDh2ChzUQ4QQmRRDeEkKXLQch7ZVHfx4swgS/DuxT1PmJXR0ltFLyPPJbRG8GHdkEe2KQCChzaW0eIrsJltHSKXBZbR8iPGKP7PZTRai/5eV0T5ZhAUQn6PbKFb%2BkUwmmMLElMJlimxpTCfYpc%2BUwnOKHGVMJ7iwFVTCd4gpvjxzKIKYE/sHVv79WYcNXRo06msKPHNOp8SuxLTqckqcW06npLAXtOp2SlynTqfk4U106nFImaU%2Bc8hykTMqTKD638frMIBrooG6zmmFiJAvU%2BezVkQIOd06sqN1n9OFBjdZwywF43WeM9BRJcHtmeas2ZtCiQLKeUs%2BcRJKFDkZsw1muj2bAp2V2PmwL2mAuOe2UW38JbAsueg2WwLbnChVsCx5E8NgvL/nixFHz8HfNxb82hGwAVLmNsws2uiLa0ohUOO2tKYXUrhX/N29KbGcpRRPH2tKMXoODrSnFx58X9hWNM4VxKVikuPOShV38U7MJTsqyJf907Kv2XeNlYDC6qtOUeMuqq%2BVkNEXeIVE8m6qrFZmCVMp7XKuJZmeVvdVVUs/EPGhT56HOifBq4MAaWJPh1X%2BeeIaV4%2BpXpGnlQaoh8qfBa8NVqnyYPDTip8DqNRRGlYqe%2B0bSVPnJcWkN78eFBq/vwr8gaeQ1rLWGyterALdh9VAwqX4411uHGW5NlbU3LjbZm/Bba81fg%2BeOstJayEhuoRWut75q1MPnWBJldF2ErtgpwpdHKg18I7YhH1wil19oXamyRm6gKZtkZe6is6J3MSXSWjR1atGXp0R2oSPrDGfsbXW6SIbzHvqNY%2BOx37E2OPfam1x77M2ePfWO%2By36i1uW/Z6wCoTL3hI7aFH10Tq2xKw82hCiSsMgcgqkrDibMlYdTbkrDmbClYbHY1PDRaOp4fQwhWpl76kdsabxtdn5Wm8eI4qTpvHyP4V6bxvlBgfV7UXJseoFVlM9EZGphoWm4gNABEkFI6RTD6FQFUQwyAKhVBRHURo5wCCQhYP8WgABhSQLZviaXiICawdgDAsDyC0UUjnHAuAAHRnGDiFrgJRQohd0GSCYUpUiudRJpZQDm4sJfQOkJgIALB4GXOFywZJcv5aJIVvL%2BJcscAJBYAAtAGUr4X1P9A2Cp/oenFA6H0BAfw6Bagqd0BwMkrQPAcHMxYAwBgTDNhWHgCAeBUaWAW46Zr2nPNKC68QHrpg%2BspZiIN4bPBODjcayseby4lsXby1d0rl2iR3Ye9d0Mq2dNxA6zYbzmA9vrcUAQJgxBgCYAIIENQGgdAQEwH5%2BLAW3iOai5gS0IWKSuf640AA9Gj/4UhATIGUPCdQHgIB2Z4JYYoJRiDA68ITjLkOstLfxGyUkZwABifJUexAOxYDgswmCqAsGlibywDDQ6lAYPQpWIA5Ym1NmbeAiu5cm9N%2BicuKsnDywBurAZFey4ZPKCYBALBS9O4zroHQPCsC4CYDgdnJdhF6OsTS%2BuLDFae%2BFk3mATBm%2BIBbq3NuyR28UA7iqgxhijHGJMMA0xgS696ocY4KxTgXGIISH8mxGTOhp4lyXRWrjx7CL1NTvR5SaeDx7r3PvrdaBmHMBYSxVg8nj5YXIjgQj57iK1/ounsdKD%2BwDoHIP1CaAh1DiYjPXPw8R8jzhe3Ofc64LzloAvlCoFQJLhXMvlfy%2Bl0r2bLx6sGm18rmPFUpuuBF%2BgMXugJdMBz0z1nbeS%2Bd5iKIfkDAxDyFEKQFgYgoif9QGIAAJW4AN34EEGECx1oE/wIB/xf35AQDUCwGIEoH5FsBAHkhC1OmeSbhMmdjmhWEYDEEtE/091Hi/xgNIH/1EE/y4BACiFIGgNEF/35DgFgCQDQBMCvwmDIAoAgHYM4MhBABYDwGAAQAIAYHKFIGCAYDs2IBoIgGK0YM/zJBsH%2B3KDEApE/3YPyCeAAHkWBxDyCsBBg2AJhDC8AdBzM8AIQaDFDSBzhMBkBK91DP93AChyCPBTAYDX9WB2BgDGA8AyQaDIB%2BQTMCA8AsgbDasnMLBQjasJgIQGBRQ9QoiLBJQ8BkBRQmAyQSADcUje9AcCBatkBBtRRcgWBMh9CmBbAWgUjpDUBRRlB1A6toisAyQOBgAbBl9RRWQUi0AsBAcWBatudCAuBRQNC%2BABAhARBwI39RAP8yDbDKDOAeBkALAhCRCxDyh9hcBCASAIDLAnNUAOC8AuCsdZQLAgCeAoCvC4CECBCIAUC0CpAQsn5XVGZVFnZuwVhMwCDRAiCFjf8KCxBqDaD6CvDSAWDEAQABACBBteAeC%2BCTiBCKQ7D8AiAkD6BUhvddBnDX939P9v9FixB4h6RYQCAcRlisQ1jhDRDxDrjFDW9SBUD0D5JWS2T2Tfj/jCTATKCQS6CGCmC8TRBICAS/9gSwSGT%2BQIRZDwjv9LQgA%3D%3D%3D -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llv
[llvm-bugs] [Bug 38196] [regression] _mm_blend_pd_blendpd does not emit blendpd anymore but emits blendps instead
https://bugs.llvm.org/show_bug.cgi?id=38196 Gonzalo BG changed: What|Removed |Added Resolution|--- |INVALID 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26248] Disassembly incorrect for x64 RIP-relative
https://bugs.llvm.org/show_bug.cgi?id=26248 lab...@google.com changed: What|Removed |Added CC||lab...@google.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from lab...@google.com --- Marking as fixed per #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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27326] Provide a way to exit lldb with a non-zero exit status
https://bugs.llvm.org/show_bug.cgi?id=27326 lab...@google.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||lab...@google.com --- Comment #1 from lab...@google.com --- This was implemented in r336824. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25086] lldb should use unix socket for communication with server on linux
https://bugs.llvm.org/show_bug.cgi?id=25086 lab...@google.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from lab...@google.com --- lldb now uses socketpair for local communication with lldb-server. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24497] Single stepping over an instruction that jumps to invalid memory fails on Android arm
https://bugs.llvm.org/show_bug.cgi?id=24497 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- This was fixed r285187. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30887] lldb fails to build because of library interdependencies
https://bugs.llvm.org/show_bug.cgi?id=30887 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #7 from lab...@google.com --- Something equivalent to what's proposed here (disabling BUILD_SHARED_LIBS for lldb) has already been implemented. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30928] check-lldb-unit fails on r286085, TestArm64InstEmulation.TestSimpleDarwinFunction failed
https://bugs.llvm.org/show_bug.cgi?id=30928 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||lab...@google.com --- Comment #2 from lab...@google.com --- Something similar to #1 has already been implemented. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27384] Can't get a modulo (%)
https://bugs.llvm.org/show_bug.cgi?id=27384 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- The example in the report seems to be working fine now. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27516] test suite: add a skipUnless-style decorator for skipping unless libc++ is available
https://bugs.llvm.org/show_bug.cgi?id=27516 lab...@google.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||lab...@google.com --- Comment #1 from lab...@google.com --- we now have a libc++ test category which is automatically skipped if libc++ is not available. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24553] pro hand does not handle all SIGSEGV/SIGBUS signals
https://bugs.llvm.org/show_bug.cgi?id=24553 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- This should be fixed now. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37047] libFuzzer: options leak into auto-dictionary
https://bugs.llvm.org/show_bug.cgi?id=37047 pdknsk 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38197] New: Compiler producing suboptimal code for vector packed fp operation followed by a vector insert
https://bugs.llvm.org/show_bug.cgi?id=38197
Bug ID: 38197
Summary: Compiler producing suboptimal code for vector packed
fp operation followed by a vector insert
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: douglas_y...@playstation.sony.com
CC: llvm-bugs@lists.llvm.org
Change r336971 caused a regression in the codegen for a certain pattern that
was fixed previously in r197145.
Consider the following code:
/* test.c */
#include
__m128 foo(__m128 a, __m128 b) {
__m128 c = a + b;
return (__m128) { c[0], a[1], a[2], a[3] };
}
Prior to upstream r197145, the compiler would generate the following code for
foo() when compiled with optimizations (-O2):
addps %xmm0, %xmm1
movss %xmm1, %xmm0
After the fix in r197145, the compiler generated the more optimal:
addss %xmm1, %xmm0
But now after r336971, we are no longer generating the optimal code and are now
generating the original code
addps %xmm0, %xmm1
movss %xmm1, %xmm0
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38198] New: X86 calling convention issue
https://bugs.llvm.org/show_bug.cgi?id=38198
Bug ID: 38198
Summary: X86 calling convention issue
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: eric.schwe...@pgroup.com
CC: llvm-bugs@lists.llvm.org
First, it's not clear if this is a bug or some design choice. We're seeking
some clarity on the issue.
We have a pure function that we'd like to add to LLVM as a vectorizable
intrinsic. The operation has a signature of
double opn(double, i32);
The LLVM vectorizer then creates an operation with a signature of
<2 x double> opnv(<2 x double>, <2 x i32>);
which we've added to the tables supporting the -fveclib option, etc. So far,
so good.
In GCC, one might write this vector code rather directly as (See below for a
more complete example.)
typedef double v2f64 __attribute__((vector_size (16)));
typedef int v2i32 __attribute__((vector_size (8)));
v2f64 opnv(v2f64 d, v2i32 i);
In clang (and gcc), we observe that the second argument i on x86 is declared as
"double" (as can be seen in the LLVM IR dump).
declare <2 x double> @opnv(<2 x double>, double);
The vector of 2 i32 values are coerced to double, passed in half of the xmm
register. e.g.,
xmm =
However, the vectorizer prefers the signature (as shown above)
declare <2 x double> opnv(<2 x double>, <2 x i32>)
In this case, depending on the -mcpu target, etc. we can get a PSHUFD or
VPSHUFD instruction to coerce the <2 x i32> to a <2 x i64>, it seems. In these
cases we may see either of the following lane assignments.
xmm =
xmm =
In the first case, the lane assignments are compatible with the clang code for
the argument i. Unfortunately, in the latter case, it appears the <2 x i32>
vector is promoted to <2 x i64> and the called routine can access the wrong
lane for the 2nd i32 value.
Here is a simple LLVM IR to reproduce the code gen.
---
target datalayout = "e-p:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
@a = global <2 x double>
@b = global <2 x i32>
define void @fun() {
L.entry:
%a = load <2 x double>, <2 x double>* @a, align 8
%b = load <2 x i32> , <2 x i32>* @b, align 8
%c = call <2 x double> @whatever (<2 x double> %a, <2 x i32> %b)
ret void
}
declare <2 x double> @whatever(<2 x double>, <2 x i32>)
---
% llc -mcpu=prescott -O2 veci32.ll
% grep xmm1 veci32.s
movqb(%rip), %xmm1 # xmm1 = mem[0],zero
pshufd $212, %xmm1, %xmm1 # xmm1 = xmm1[0,1,1,3]
% llc -mcpu=sandybridge -O2 veci32.ll
% grep xmm1 veci32.s
vpmovzxdq b(%rip), %xmm1 # xmm1 = mem[0],zero,mem[1],zero
And lastly, here is a C example using the GCC vector extension to pass a <2 x
i32>.
---
typedef int v2si __attribute__ ((vector_size (8)));
typedef double v2d __attribute__ ((vector_size (16)));
v2d do_op(v2si i);
v2d test(v2si e) {
return do_op(e);
}
---
% clang -O2 -emit-llvm -S gccvecext.c
% grep do_op gccvecext.ll
%call = tail call <2 x double> @do_op(double %e.coerce) #2
declare dso_local <2 x double> @do_op(double) local_unnamed_addr #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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38199] New: false positive null pointer analysis due to not inlined list operator == and !=
https://bugs.llvm.org/show_bug.cgi?id=38199
Bug ID: 38199
Summary: false positive null pointer analysis due to not
inlined list operator == and !=
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: c...@google.com
CC: llvm-bugs@lists.llvm.org
To reproduce:
$ cat /tmp/null.cpp
#include
typedef std::list MyList;
extern MyList &mylist;
struct A {
A();
void f0();
};
extern void f1(), f2();
void foo()
{
A *p = nullptr;
MyList::iterator begin = mylist.begin();
MyList::iterator end = mylist.end();
if (begin != end) {
f1();
p = new A();
}
if (!(begin != end)) {
f2();
if (p != nullptr) delete p;
p = new A();
}
p->f0();
delete p;
}
$ clang-tidy -checks=-*,clang-analy* /tmp/null.cpp -- -std=c++11 -O2
/tmp/null.cpp:23:3: warning: Called C++ object pointer is null
[clang-analyzer-core.CallAndMessage]
p->f0();
^
/tmp/null.cpp:11:3: note: 'p' initialized to a null pointer value
A *p = nullptr;
^
/tmp/null.cpp:14:7: note: Assuming the condition is false
if (begin != end) {
^
/tmp/null.cpp:14:3: note: Taking false branch
if (begin != end) {
^
/tmp/null.cpp:18:7: note: Assuming the condition is false
if (!(begin != end)) {
^
/tmp/null.cpp:18:3: note: Taking false branch
if (!(begin != end)) {
^
/tmp/null.cpp:23:3: note: Called C++ object pointer is null
p->f0();
^
If compiled with clang -O2, we can see that all calls to the list and iterator
functions can be inlined and it is impossible to have both !(begin != end) and
!!(begin != end)
The clang static analyzer does not seem be inlining the != and == operators of
the list::iterator.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38200] New: Linking error: error: relocation R_X86_64_PC32 cannot refer to absolute symbol: __typeid__ZTSFvvE.generalized_align
https://bugs.llvm.org/show_bug.cgi?id=38200
Bug ID: 38200
Summary: Linking error: error: relocation R_X86_64_PC32 cannot
refer to absolute symbol:
__typeid__ZTSFvvE.generalized_align
Product: lld
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: t...@ritter.vg
CC: llvm-bugs@lists.llvm.org
> clang version 7.0.0 (trunk) (llvm/trunk 337005)
> Target: x86_64-unknown-linux-gnu
The following code was compiled into a .o :
>
> if (aType & nsCFIType::ICALL_INVALID_ENTRY_POINT) {
>
>int val = setjmp(env);
>
>if (val == 0) {
> fn_ptr slide_to_the_left = (fn_ptr)((uintptr_t)(not_entry_point) + 0x20);
> slide_to_the_left(); // Line 690
>}
>
>return NS_OK;
> }
>
>
> if (aType & nsCFIType::ICALL_INVALID_SIGNATURE) {
>int_arg_fn get_down_now_yall = (int_arg_fn)int_arg;
>
>int ret = get_down_now_yall(5); // Line 709
>
>get_down_now_yall = (int_arg_fn)float_arg;
>ret = get_down_now_yall(5); // Line 713
>
>return NS_OK;
> }
And then linked with the following command:
> ../../../../../../../../clang++ \
> -fuse-ld=lld \
> -flto=thin \
> -fsanitize=cfi-icall \
> -pipe \
> -g \
> -fPIC \
> -shared \
> -o \
> libxul.so \
> trimmed_tmp.list \
> -fcolor-diagnostics \
> -Wl,--error-limit,0
It yields the following errors:
> /home/tom/Documents/moz/mozilla-unified-cfi-icall/reproduce-bug/xul-repro/home/tom/Documents/moz/mozilla-unified-cfi-icall/obj-x86_64-pc-linux-gnu/toolkit/library/../../../../../../../../ld.lld:
> error: relocation R_X86_64_PC32 cannot refer to absolute symbol:
> __typeid__ZTSFvvE.generalized_align
> >>> defined in lto.tmp
> >>> referenced by nsDebugImpl.cpp:0
> >>> (/home/tom/Documents/moz/mozilla-unified-cfi-icall/xpcom/base/nsDebugImpl.cpp:0)
> >>> lto.tmp:(nsDebugImpl::CfiCrash(int))
> /home/tom/Documents/moz/mozilla-unified-cfi-icall/reproduce-bug/xul-repro/home/tom/Documents/moz/mozilla-unified-cfi-icall/obj-x86_64-pc-linux-gnu/toolkit/library/../../../../../../../../ld.lld:
> error: relocation R_X86_64_PC32 cannot refer to absolute symbol:
> __typeid__ZTSFvvE.generalized_size_m1
> >>> defined in lto.tmp
> >>> referenced by nsDebugImpl.cpp:690
> >>> (/home/tom/Documents/moz/mozilla-unified-cfi-icall/xpcom/base/nsDebugImpl.cpp:690)
> >>> lto.tmp:(nsDebugImpl::CfiCrash(int))
> /home/tom/Documents/moz/mozilla-unified-cfi-icall/reproduce-bug/xul-repro/home/tom/Documents/moz/mozilla-unified-cfi-icall/obj-x86_64-pc-linux-gnu/toolkit/library/../../../../../../../../ld.lld:
> error: relocation R_X86_64_PC32 cannot refer to absolute symbol:
> __typeid__ZTSFiiE.generalized_align
> >>> defined in lto.tmp
> >>> referenced by nsDebugImpl.cpp:0
> >>> (/home/tom/Documents/moz/mozilla-unified-cfi-icall/xpcom/base/nsDebugImpl.cpp:0)
> >>> lto.tmp:(nsDebugImpl::CfiCrash(int))
> /home/tom/Documents/moz/mozilla-unified-cfi-icall/reproduce-bug/xul-repro/home/tom/Documents/moz/mozilla-unified-cfi-icall/obj-x86_64-pc-linux-gnu/toolkit/library/../../../../../../../../ld.lld:
> error: relocation R_X86_64_PC32 cannot refer to absolute symbol:
> __typeid__ZTSFiiE.generalized_size_m1
> >>> defined in lto.tmp
> >>> referenced by nsDebugImpl.cpp:709
> >>> (/home/tom/Documents/moz/mozilla-unified-cfi-icall/xpcom/base/nsDebugImpl.cpp:709)
> >>> lto.tmp:(nsDebugImpl::CfiCrash(int))
> /home/tom/Documents/moz/mozilla-unified-cfi-icall/reproduce-bug/xul-repro/home/tom/Documents/moz/mozilla-unified-cfi-icall/obj-x86_64-pc-linux-gnu/toolkit/library/../../../../../../../../ld.lld:
> error: relocation R_X86_64_PC32 cannot refer to absolute symbol:
> __typeid__ZTSFiiE.generalized_align
> >>> defined in lto.tmp
> >>> referenced by nsDebugImpl.cpp:0
> >>> (/home/tom/Documents/moz/mozilla-unified-cfi-icall/xpcom/base/nsDebugImpl.cpp:0)
> >>> lto.tmp:(nsDebugImpl::CfiCrash(int))
> /home/tom/Documents/moz/mozilla-unified-cfi-icall/reproduce-bug/xul-repro/home/tom/Documents/moz/mozilla-unified-cfi-icall/obj-x86_64-pc-linux-gnu/toolkit/library/../../../../../../../../ld.lld:
> error: relocation R_X86_64_PC32 cannot refer to absolute symbol:
> __typeid__ZTSFiiE.generalized_size_m1
> >>> defined in lto.tmp
> >>> referenced by nsDebugImpl.cpp:713
> >>> (/home/tom/Documents/moz/mozilla-unified-cfi-icall/xpcom/base/nsDebugImpl.cpp:713)
> >>> lto.tmp:(nsDebugImpl::CfiCrash(int))
The reproduction steps are:
> wget https://ritter.vg/misc/transient/R_X86_64_PC32.tgz
> tar xf R_X86_64_PC32.tgz
> cd
> xul-repro/home/tom/Documents/moz/mozilla-unified-cfi-icall/obj-x86_64-pc-linux-gnu/toolkit/library
> # Clear your terminal
> # Run the above compile command; search for R_X86_64_PC32
I tried to reproduce the compil
[llvm-bugs] [Bug 38201] New: incorrect reinterpret_cast from integer to pointer error on invalid constexpr initialization
https://bugs.llvm.org/show_bug.cgi?id=38201
Bug ID: 38201
Summary: incorrect reinterpret_cast from integer to pointer
error on invalid constexpr initialization
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
The code is as follow:
struct S { int a, b; } s;
constexpr S *p = (S*)0;
constexpr const int *q = &p->b;
The code is invalid not because of a cast (there is none) but because it
attempts to use a null pointer to form the address of a member of an object.
clang++ accepts it. I checked g++. It rejects the code:
error: dereferencing a null pointer in '*0'
constexpr const int *q = &p->b;
^
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38202] New: inaccessible types allowed as template argument in nested-name-specifier
https://bugs.llvm.org/show_bug.cgi?id=38202
Bug ID: 38202
Summary: inaccessible types allowed as template argument in
nested-name-specifier
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
The code is as follow:
template
struct list
{
struct nested { };
};
class F
{
struct R { };
class Q
{
friend void f(const Q &q) { list::nested n; }
};
};
clang++ accepts it, but g++ rejects it:
error: 'struct F::R' is private within this context
friend void f(const Q &q) { list::nested n; }
^
code1.c.cpp:10:9: note: declared private here
struct R { };
^
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38203] New: use of deleted function
https://bugs.llvm.org/show_bug.cgi?id=38203
Bug ID: 38203
Summary: use of deleted function
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
The code is as follow:
struct Z { };
struct A {
operator Z &&() const = delete; // It is deleted.
operator Z();
};
void zip() {
Z &&x = A();
}
clang++ accepts the code, but g++ rejects it:
error: use of deleted function 'A::operator Z&&() const'
Z &&x = A();
^
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38204] New: r337190 broke chromium build
https://bugs.llvm.org/show_bug.cgi?id=38204 Bug ID: 38204 Summary: r337190 broke chromium build Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: l...@inglorion.net CC: llvm-bugs@lists.llvm.org See https://crbug.com/864832. This causes a chromium build step to fail due to what I think is a miscompiled zucchini binary. I'll revert r337190 while I investigate further. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38205] New: type mismatch in explicit template instantiate not detected
https://bugs.llvm.org/show_bug.cgi?id=38205
Bug ID: 38205
Summary: type mismatch in explicit template instantiate not
detected
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
The code is as follow:
template
class A
{
static T a;
};
template
T A::a;
class B
{ };
template
int A::a; // type mismatch
clang++ accepts the code. The code should produce an error for the explicit
template instantiation, because the type given for the static variable
doesn't match the one in the class template. Please note that g++ rejects the
code:
error: type 'B' for explicit instantiation 'A::a' does not match declared
type 'int'
int A::a; // type mismatch
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38206] New: use of local variable with automatic storage from containing function
https://bugs.llvm.org/show_bug.cgi?id=38206
Bug ID: 38206
Summary: use of local variable with automatic storage from
containing function
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
The code is as follow:
template
int f(void)
{
int i;
struct f1
{
int f(void){return i;}
};
}
Clang++ accepts the code, but g++ rejects it:
code0.cpp: In member function 'int f()::f1::f()':
code0.cpp:7:21: error: use of local variable with automatic storage from
containing function
int f(void){return i;}
^
code0.cpp:4:6: note: 'int i' declared here
int i;
^
code0.cpp: In function 'int f()':
code0.cpp:9:1: warning: no return statement in function returning non-void
[-Wreturn-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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38203] use of deleted function
https://bugs.llvm.org/show_bug.cgi?id=38203 Richard Smith changed: What|Removed |Added CC||richard-l...@metafoo.co.uk Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Smith --- This appears to be a GCC bug. Both conversion functions are candidates for the initialization; the non-deleted one is selected because it has a better conversion for its implicit object parameter, by [over.match.best]/1.3, so we never reach [over.match.best]/1.5 which would select the deleted function. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38207] New: Need indirect_return function attribute
https://bugs.llvm.org/show_bug.cgi?id=38207
Bug ID: 38207
Summary: Need indirect_return function attribute
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: hjl.to...@gmail.com
CC: llvm-bugs@lists.llvm.org
On x86, swapcontext may return via indirect branch when shadow stack
is enabled. To support code instrumentation of control-flow transfers
with -fcf-protection, add indirect_return function attribute to inform
compiler that a function may return via indirect branch.
Note: Unlike setjmp, swapcontext only returns once. Mark it return
twice will unnecessarily disable compiler optimization as shown in
the testcase here.
This has been implemented in GCC 9:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d4d9fba553cd199f422fbd10cf3de72a9b0eafa8
We need a way to generate ENDBR in compiler-rt:
INTERCEPTOR(int, swapcontext, struct ucontext_t *oucp,
struct ucontext_t *ucp) {
static bool reported_warning = false;
if (!reported_warning) {
Report("WARNING: ASan doesn't fully support makecontext/swapcontext "
"functions and may produce false positives in some cases!\n");
reported_warning = true;
}
// Clear shadow memory for new context (it may share stack
// with current context).
uptr stack, ssize;
ReadContextStack(ucp, &stack, &ssize);
ClearShadowMemoryForContextStack(stack, ssize);
int res = REAL(swapcontext)(oucp, ucp);
Need ENDBR here.
// swapcontext technically does not return, but program may swap context to
// "oucp" later, that would look as if swapcontext() returned 0.
// We need to clear shadow for ucp once again, as it may be in arbitrary
// state.
ClearShadowMemoryForContextStack(stack, ssize);
return res;
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
