[llvm-bugs] [Bug 45004] New: problems with soft-float
https://bugs.llvm.org/show_bug.cgi?id=45004
Bug ID: 45004
Summary: problems with soft-float
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: f...@frank-buss.de
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
When I compile this program:
#include
int main(int argc, char*argv[])
{
double x = 2.0;
double y = 3.0;
printf("%f\n", x * y);
return 0;
}
with "clang -msoft-float -mno-sse -O0 test.c", it prints 0 instead of 6.
Output of clang --version:
clang --version
clang version 7.0.1-8 (tags/RELEASE_701/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
I'm trying to use soft-float without any FPU or XMM registers, as it is e.g.
possible on ARM.
--
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 45005] New: Clang-CL's MSVC preprocessor emulation does not properly handle variadic arguments
https://bugs.llvm.org/show_bug.cgi?id=45005 Bug ID: 45005 Summary: Clang-CL's MSVC preprocessor emulation does not properly handle variadic arguments Product: clang Version: 9.0 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: balazs.czir...@nng.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Clang-CL's MSVC preprocessor emulation does not produce the exact same behavior as MSVC's preprocessor, which breaks certain libraries that are prepared to handle MSVC's preprocessor behavior. A minimal repro of the error that causes said libraries to break: https://godbolt.org/z/c5RndM (Clang-CL is not available on Godbolt, so the output of a local build was pasted into a comment.) The example macro `_NARG` counts the arguments it was provided up to three. Since MSVC's preprocessor has it's quirks, the `_NARG_MSVC` macro is what can produce the same behavior with that preprocessor. When given two empty arguments, Clang-CL's preprocessor does not properly handle the MSVC version, and produces an erroneous argument count of `1`. This breaks libraries such as: * GoogleMock: https://godbolt.org/z/noqbnj (The new `MOCK_METHOD` macro in 1.10) * Boost Preprocessor: https://godbolt.org/z/NL6BbA -- 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 45006] New: GHC calling convention: Function prologue frame pointer invalidates the %rbp register
https://bugs.llvm.org/show_bug.cgi?id=45006 Bug ID: 45006 Summary: GHC calling convention: Function prologue frame pointer invalidates the %rbp register Product: libraries Version: 9.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: m...@daniel-mendler.de CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com Created attachment 23165 --> https://bugs.llvm.org/attachment.cgi?id=23165&action=edit Includes avx/rt.bc, avx/rt.s, no-avx/rt.bc, no-avx/rt.s I am observing a bug on x86-64 using the GHC calling convention (cc 10), which only occurs if AVX is enabled. The register %rbp is reserved by the GHC calling convention, however LLVM creates a frame pointer in the prologue, invalidating the %rbp register if AVX is enabled. The %rbp register is only restored in the epilogue of the function. This bug has been observed previously in GHC. However it seems the bug was only triggered by GHC with LLVM 3.2. The bug is still present in LLVM 9, which I am using right now. Note that I am not using GHC for code generation, but another compiler, which produces similar code and relies on the GHC calling convention. See https://gitlab.haskell.org/ghc/ghc/issues/9391 for the original bug report on the GHC bugtracker. I am appending the following test files: avx/rt.bc avx/rt.s generated via llc-9 from avx/rt.bc no-avx/rt.bc no-avx/rt.s generated via llc-9 from avx/rt.bc The miscompiled function is interpInitModuleCont: ~~~ define internal ghccc i32 @interpInitModuleCont(%struct._ChiRegStore_* noalias, i64* noalias, i64* noalias, i64* noalias, i64, i64, i64, i64, i64, i64) ~~~ Compiled with AVX enabled: ~~~ interpInitModuleCont: pushq %rbp movq%rsp, %rbp <~~~ %rbp is invalidated ... movq%rbp, %rsp popq%rbp <~~~ %rbp is restored vzeroupper jmpq*%rax # TAILCALL ~~~ If AVX is disabled using -mno-avx in the frontend, the invalid prologue/epilogue is not generated, the %rbp register is not invalidated and things work as expected. The resulting program runs fine. I did not test other architectures supporting the GHC calling convention, but I suspect that the bug is x86 specific due the logic in X86FrameLowering::hasFP. $ llc-9 -version LLVM (http://llvm.org/): LLVM version 9.0.1 Optimized build. Default target: x86_64-pc-linux-gnu Host CPU: skylake -- 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 45007] New: wasm32: return_call_indirect type mismatch
https://bugs.llvm.org/show_bug.cgi?id=45007
Bug ID: 45007
Summary: wasm32: return_call_indirect type mismatch
Product: new-bugs
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: m...@daniel-mendler.de
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
$ clang-9 -O3 -ffreestanding -nostdinc -nostdlib --target=wasm32 -mtail-call
test.c -o test.wasm
Running the file test.wasm using `node --experimental-wasm-return_call`
produces a type mismatch error. Looking into the produced wasm code using
wabt-objdump there is indeed a mismatch `return_call_indirect 0 0` refers to
the type `() -> nil` instead of `() -> i32` as it should be.
---
// test.c
typedef int (*Fn)(void);
int g(void) {
return 0;
}
Fn p = g;
int f(void) {
return p();
}
void _start() {
f();
}
---
A variation of the program using attribute(noinline) also does not work:
---
// test.c
typedef int (*Fn)(void);
int g(void) {
return 0;
}
Fn p = g;
__attribute__((noinline)) int f(void) {
return p();
}
void _start() {
f();
}
---
--
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 45009] New: LLVM emits invalid entry values covering composite location descriptions
https://bugs.llvm.org/show_bug.cgi?id=45009 Bug ID: 45009 Summary: LLVM emits invalid entry values covering composite location descriptions Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: david.stenb...@ericsson.com CC: jdevliegh...@apple.com, keith.wal...@arm.com, llvm-bugs@lists.llvm.org, paul_robin...@playstation.sony.com When working on D67492 I made DwarfExpression emit a single DW_OP_entry_value operation covering the whole composite location description that is produced if a register does not have a valid DWARF number, and is instead composed of multiple sub-registers. Looking closer at the standard, I noticed that that is not valid DWARF. A DW_OP_entry_value operation's block can only be a DWARF expression or a register location description, so it is not valid to hold a composite location description like that. See DWARFv5 sec. 2.5.1.7: "The DW_OP_entry_value operation pushes the value that the described location held upon entering the current subprogram. It has two operands: an unsigned LEB128 length, followed by a block containing a DWARF expression or a register location description (see Section 2.6.1.1.3 on page 39)." Such a case can be seen in llvm/test/DebugInfo/Sparc/entry-value-complex-reg-expr.ll. Perhaps we instead want to emit expressions containing one DW_OP_entry_value operation per sub-register, e.g.: DW_OP_entry_value(DW_OP_regx D0), DW_OP_piece 0x8, DW_OP_entry_value(DW_OP_regx D1), DW_OP_piece 0x8, DW_OP_stack_value However, it is a bit unclear how the call site location should be for that; should we emit one entry per sub-register, or a single composite location and let the debugger figure out how the two expressions correlate? It is unclear to me if it is valid DWARF to have multiple entries per parameter. The latter should be valid DWARF, but AFAICT no debugger can understand such call site locations at the moment. GDB can only understand single DW_OP_reg or DW_OP_fbreg locations. -- 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 44555] [meta] 10.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=44555 Bug 44555 depends on bug 45001, which changed state. Bug 45001 Summary: Polly plugin not auto-loaded https://bugs.llvm.org/show_bug.cgi?id=45001 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 45001] Polly plugin not auto-loaded
https://bugs.llvm.org/show_bug.cgi?id=45001 Michael Kruse changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||6369b9bf311 Resolution|--- |FIXED --- Comment #2 from Michael Kruse --- Committed as 6369b9bf311 -- 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 38753] [DebugInfo@O2][Dexter]Stale debug variable value in optimised code
https://bugs.llvm.org/show_bug.cgi?id=38753 Tom Weaver changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Tom Weaver --- https://reviews.llvm.org/rG453dc4d7ec5a3c3d8f54fc358bc5673834516d48 -- 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 38768] [meta][DebugInfo] Umbrella bug for poor debug experiences
https://bugs.llvm.org/show_bug.cgi?id=38768 Bug 38768 depends on bug 38753, which changed state. Bug 38753 Summary: [DebugInfo@O2][Dexter]Stale debug variable value in optimised code https://bugs.llvm.org/show_bug.cgi?id=38753 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 44555] [meta] 10.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=44555 Bug 44555 depends on bug 45001, which changed state. Bug 45001 Summary: Polly plugin not auto-loaded https://bugs.llvm.org/show_bug.cgi?id=45001 What|Removed |Added Status|RESOLVED|REOPENED 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 45001] Polly plugin not auto-loaded
https://bugs.llvm.org/show_bug.cgi?id=45001 Michael Kruse changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- CC||h...@chromium.org --- Comment #3 from Michael Kruse --- Reopening because the issue is not solved yet for clang-10. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 20860 in oss-fuzz: llvm:clangd-fuzzer: Direct-leak in llvm::WritableMemoryBuffer::getNewUninitMemBuffer
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 Stability-Memory-LeakSanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-02-24 Type: Bug New issue 20860 by ClusterFuzz-External: llvm:clangd-fuzzer: Direct-leak in llvm::WritableMemoryBuffer::getNewUninitMemBuffer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20860 Detailed Report: https://oss-fuzz.com/testcase?key=6231185409966080 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clangd-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Direct-leak Crash Address: Crash State: llvm::WritableMemoryBuffer::getNewUninitMemBuffer llvm::MemoryBuffer::getMemBufferCopy clang::clangd::buildAST Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201908020315:201908030321 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6231185409966080 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45010] New: Assertion failed: !(isAtomic() && getAlignment() == 0) && "Alignment required for atomic load"
https://bugs.llvm.org/show_bug.cgi?id=45010
Bug ID: 45010
Summary: Assertion failed: !(isAtomic() && getAlignment() == 0)
&& "Alignment required for atomic load"
Product: clang
Version: 10.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: release blocker
Priority: P
Component: -New Bugs
Assignee: gchate...@google.com
Reporter: alexandre.ga...@ubisoft.com
CC: h...@chromium.org, htmldevelo...@gmail.com,
llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Blocks: 44555
When compiling Clang with assertions enabled, I'm seeing the assert I've
mentioned here: https://reviews.llvm.org/D71547#1824272
Repro:
// a.cpp
// Build with: clang-cl a.cpp /c /O1
#include
struct SP {
void WeakAddRef();
void WeakRelease();
};
template struct PtrBase {
T *volatile P;
~PtrBase() {
if (R)
R->WeakRelease();
}
PtrBase(const PtrBase &O) : R(O.R) {
if (R)
R->WeakAddRef();
}
SP *R;
bool IsValid() const { return P != nullptr; }
};
struct alignas(16) VectorSIMD4f {
float V;
};
unsigned __int64 countAF() {
class AF {
VectorSIMD4f B;
};
struct PD {
PtrBase P;
};
std::vector AFs;
unsigned __int64 C = 0;
for (auto A : AFs) {
if (A.P.IsValid())
++C;
}
return C;
}
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=44555
[Bug 44555] [meta] 10.0.0 Release Blockers
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 19216 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in processTypeAttrs
Updates: Labels: Deadline-Approaching Comment #1 on issue 19216 by sheriffbot: llvm:clang-fuzzer: Stack-overflow in processTypeAttrs https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19216#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] Issue 19209 in oss-fuzz: llvm:llvm-isel-fuzzer--wasm32-O2: Timeout in llvm-isel-fuzzer--wasm32-O2
Updates: Labels: Deadline-Approaching Comment #1 on issue 19209 by sheriffbot: llvm:llvm-isel-fuzzer--wasm32-O2: Timeout in llvm-isel-fuzzer--wasm32-O2 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19209#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] Issue 19203 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::APValue::swap
Updates: Labels: Deadline-Approaching Comment #1 on issue 19203 by sheriffbot: llvm:clang-fuzzer: Stack-overflow in clang::APValue::swap https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19203#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] Issue 19215 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in llvm::StringMapImpl::LookupBucketFor
Updates: Labels: Deadline-Approaching Comment #1 on issue 19215 by sheriffbot: llvm:clang-fuzzer: Stack-overflow in llvm::StringMapImpl::LookupBucketFor https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19215#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] Issue 19205 in oss-fuzz: llvm:clang-fuzzer: Segv on unknown address in clang::SourceManager::getFileIDLoaded
Updates: Labels: Deadline-Approaching Comment #1 on issue 19205 by sheriffbot: llvm:clang-fuzzer: Segv on unknown address in clang::SourceManager::getFileIDLoaded https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19205#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 45011] New: lldb can swallow some of the output when doing `p SM.dump(SourceLoc)`, or similar
https://bugs.llvm.org/show_bug.cgi?id=45011 Bug ID: 45011 Summary: lldb can swallow some of the output when doing `p SM.dump(SourceLoc)`, or similar Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: v...@apple.com CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org While debugging clang or llvm and calling 'dump' on various objects, lldb sometimes swallows part of the output. E.g.: ``` (lldb) p BV.dump() (lldb)1]} ``` or ``` (lldb) p SM.dump(SourceLoc) (lldb)ile.cpp:30:10 ``` Why does that happen? These dump methods are writing to dbgs(), which should just be stderr. -- 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 44982] Non-deterministic codegen in wasm backend
https://bugs.llvm.org/show_bug.cgi?id=44982 Heejin Ahn changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Heejin Ahn --- This was fixed in https://reviews.llvm.org/rG3648370a79235ddc7a26c2db5b968725c320f6aa. Thanks! -- 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 42803] incorrect vector codegen
https://bugs.llvm.org/show_bug.cgi?id=42803 Craig Topper changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||a5fa77888243beede98959ced17 ||596b380e8de59 Resolution|--- |FIXED --- Comment #22 from Craig Topper --- Maybe fixed after a5fa77888243beede98959ced17596b380e8de59. I only checked the output I didn't run anything. -- 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 44902] i386 EXTRACT_VECTOR_ELT of v4i1 produces wrong code
https://bugs.llvm.org/show_bug.cgi?id=44902 Craig Topper changed: What|Removed |Added Fixed By Commit(s)||a5fa77888243beede98959ced17 ||596b380e8de59 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Craig Topper --- Maybe fixed with a5fa77888243beede98959ced17596b380e8de59 -- 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 31265] [Meta] Load/Store/Bitcast Handling of bool vectors
https://bugs.llvm.org/show_bug.cgi?id=31265 Bug 31265 depends on bug 42803, which changed state. Bug 42803 Summary: incorrect vector codegen https://bugs.llvm.org/show_bug.cgi?id=42803 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 31265] [Meta] Load/Store/Bitcast Handling of bool vectors
https://bugs.llvm.org/show_bug.cgi?id=31265 Bug 31265 depends on bug 44902, which changed state. Bug 44902 Summary: i386 EXTRACT_VECTOR_ELT of v4i1 produces wrong code https://bugs.llvm.org/show_bug.cgi?id=44902 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 45012] New: clang accepts a call to an ambiguous inherited constructor in some cases
https://bugs.llvm.org/show_bug.cgi?id=45012
Bug ID: 45012
Summary: clang accepts a call to an ambiguous inherited
constructor in some cases
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: richard-l...@metafoo.co.uk
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Testcase:
struct A { A(int); };
struct B : virtual A { using A::A; };
struct C : A, B { using A::A; using B::B; };
C c(123);
Clang accepts and passes the 123 on to the constructors of both A base
subobjects. This code is ill-formed under [class.inhctor.init]p2:
> If the constructor was inherited from multiple base class subobjects of type
> B, the program is ill-formed.
--
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 45013] New: X86 JIT doesn't support Intel CET
https://bugs.llvm.org/show_bug.cgi?id=45013 Bug ID: 45013 Summary: X86 JIT doesn't support Intel CET 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: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org To support IBT and SHSTK in Intel CET, x86 JIT 1. For IBT, put ENDBR at all indirect branch targets. This has been done regardless if IBT is enabled or not since there is no easy way to check if IBT is active and ENDBR is a NOP on non-CET processors. At minimum, all entry points of jitted code should start with ENDBR, add NOTRACK prefix before indirect call and jmp within jitted code. 2. For SHSTK, unwind shadow stack when skipping stack frames on return. On CET machine with CET enabled Linux OS, I got control protection fault: (gdb) disass 0x7f0c40002000,+30 Dump of assembler code from 0x7f0c40002000 to 0x7f0c4000201e: => 0x7f0c40002000: push %rbp Missing ENDBR 0x7f0c40002001: mov%rsp,%rbp 0x7f0c40002004: push %r15 0x7f0c40002006: push %r14 0x7f0c40002008: push %r13 0x7f0c4000200a: push %r12 0x7f0c4000200c: push %rbx 0x7f0c4000200d: and$0xffe0,%rsp 0x7f0c40002011: sub$0x60,%rsp 0x7f0c40002015: mov0x30(%rbp),%r14 0x7f0c40002019: mov0x10(%rbp),%rax 0x7f0c4000201d: lea-0x1(%rcx),%ebx End of assembler dump. (gdb) bt #0 0x7f0c40002000 in () #1 0x7f0c69c8a106 in llvm_pipeline_generic.constprop () at /usr/lib64/dri/swrast_dri.so #2 0x7f0c69c8a613 in llvm_middle_end_linear_run () at /usr/lib64/dri/swrast_dri.so #3 0x7f0c69c1de3a in vsplit_run_linear () at /usr/lib64/dri/swrast_dri.so #4 0x7f0c69c17773 in draw_pt_arrays () at /usr/lib64/dri/swrast_dri.so #5 0x7f0c69c17c90 in draw_vbo () at /usr/lib64/dri/swrast_dri.so #6 0x7f0c693b06fb in llvmpipe_draw_vbo () at /usr/lib64/dri/swrast_dri.so #7 0x7f0c69c363ca in blitter_draw () at /usr/lib64/dri/swrast_dri.so #8 0x7f0c69c36733 in blitter_draw_tex () at /usr/lib64/dri/swrast_dri.so #9 0x7f0c69c36e5d in do_blits () at /usr/lib64/dri/swrast_dri.so #10 0x7f0c69c394e6 in util_blitter_blit_generic () at /usr/lib64/dri/swrast_dri.so #11 0x7f0c69c3a672 in util_blitter_blit () at /usr/lib64/dri/swrast_dri.so #12 0x7f0c693cf8e7 in lp_blit () at /usr/lib64/dri/swrast_dri.so #13 0x7f0c69c3c862 in util_gen_mipmap () at /usr/lib64/dri/swrast_dri.so #14 0x7f0c6979b887 in st_generate_mipmap () at /usr/lib64/dri/swrast_dri.so #15 0x7f0c69835e9b in generate_texture_mipmap_error () at /usr/lib64/dri/swrast_dri.so #16 0x7f0d7006f0f1 in _cogl_texture_gl_generate_mipmaps () at /usr/lib64/mutter-5/libmutter-cogl-5.so.0 #17 0x7f0d700a0e47 in _cogl_texture_2d_pre_paint () at /usr/lib64/mutter-5/libmutter-cogl-5.so.0 #18 0x7f0d700938f1 in _cogl_pipeline_layer_pre_paint () at /usr/lib64/mutter-5/libmutter-cogl-5.so.0 #19 0x7f0d70081faf in _cogl_rectangles_validate_layer_cb () at /usr/lib64/mutter-5/libmutter-cogl-5.so.0 #20 0x7f0d700904a9 in cogl_pipeline_foreach_layer () at /usr/lib64/mutter-5/libmutter-cogl-5.so.0 #21 0x7f0d700823d6 in _cogl_framebuffer_draw_multitextured_rectangles () at /usr/lib64/mutter-5/libmutter-cogl-5.so.0 #22 0x7f0d700acb66 in cogl_framebuffer_draw_textured_rectangle () at /usr/lib64/mutter-5/libmutter-cogl-5.so.0 #23 0x7f0d7061d60a in meta_background_get_texture () at /lib64/libmutter-5.so.0 #24 0x7f0d7061b1e9 in meta_background_actor_paint () at /lib64/libmutter-5.so.0 #25 0x7f0d707f2b7f in clutter_actor_continue_paint () at /usr/lib64/mutter-5/libmutter-clutter-5.so.0 #26 0x7f0d707f9d14 in clutter_actor_paint () at /usr/lib64/mutter-5/libmutter-clutter-5.so.0 #27 0x7f0d708578e2 in clutter_stage_paint () at /usr/lib64/mutter-5/libmutter-clutter-5.so.0 #28 0x7f0d70606981 in meta_stage_paint () at /lib64/libmutter-5.so.0 #29 0x7f0d707f2b7f in clutter_actor_continue_paint () at /usr/lib64/mutter-5/libmutter-clutter-5.so.0 #30 0x7f0d707f9d14 in clutter_actor_paint () at /usr/lib64/mutter-5/libmutter-clutter-5.so.0 #31 0x7f0d7085c985 in clutter_stage_do_paint_view () at /usr/lib64/mutter-5/libmutter-clutter-5.so.0 #32 0x7f0d70606884 in meta_stage_paint_view () at /lib64/libmutter-5.so.0 #33 0x7f0d70858cd0 in _clutter_stage_paint_view () at /usr/lib64/mutter-5/libmutter-clutter-5.so.0 #34 0x7f0d70890445 in paint_stage () at /usr/lib64/mutter-5/libmutter-clutter-5.so.0 #35 0x7f0d70890c87 in clutter_stage_cogl_redraw_view () at /usr/lib64/mutter-5/libmutter-clutter-5.so.0 #36 0x7f0d708918e3 in clutter_stag
[llvm-bugs] [Bug 45014] New: interception_type_test fails for Android API >= 24 32-bit
https://bugs.llvm.org/show_bug.cgi?id=45014 Bug ID: 45014 Summary: interception_type_test fails for Android API >= 24 32-bit Product: compiler-rt Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: smee...@fb.com CC: eugeni.stepa...@gmail.com, k...@google.com, llvm-bugs@lists.llvm.org, mitchphill...@outlook.com, pe...@pcc.me.uk https://github.com/llvm/llvm-project/blob/2c0edbf19c1b0115b944cd017201eaf1f6a832ee/llvm/cmake/modules/HandleLLVMOptions.cmake#L300 sets -D_FILE_OFFSET_BITS=64 for Android when targeting API level >= 24, which means we get a 64-bit off_t even on 32-bit targets. However, compiler-rt defines its OFF_T type for 32-bit Android as 32 bits in https://github.com/llvm/llvm-project/blob/2c0edbf19c1b0115b944cd017201eaf1f6a832ee/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h#L178. interception_type_test.cpp then unconditionally compares the sizes of off_t and OFF_T for Android in https://github.com/llvm/llvm-project/blob/2c0edbf19c1b0115b944cd017201eaf1f6a832ee/compiler-rt/lib/interception/interception_type_test.cpp#L36, which of course fails. Should we adjust OFF_T to be 64 bits on Android APIs >= 24? -- 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 45015] New: [X86][AVX] Failure to generate vaddsubps for pattern after 19b62b79
https://bugs.llvm.org/show_bug.cgi?id=45015
Bug ID: 45015
Summary: [X86][AVX] Failure to generate vaddsubps for pattern
after 19b62b79
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: douglas_y...@playstation.sony.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Consider the following code:
#include
__m128 haddsub0ps(__m128 a, __m128 b) {
return (__m128){ a[0] - b[0], a[1] + b[1], a[2] - b[2], a[3] + b[3] };
}
Prior to commit 19b62b79db1bb154b40e8baba9a28ab8aa935b6b, when compiled with
optimizations and avx (-O2 -mavx), the compiler would generate the following
assembly:
vaddsubps %xmm1, %xmm0, %xmm0
But now the compiler is instead generating the following assembly:
vsubss %xmm1, %xmm0, %xmm2
vaddps %xmm1, %xmm0, %xmm3
vblendps$1, %xmm2, %xmm3, %xmm2 # xmm2 = xmm2[0],xmm3[1,2,3]
vsubps %xmm1, %xmm0, %xmm0
vblendps$3, %xmm2, %xmm0, %xmm0 # xmm0 = xmm2[0,1],xmm0[2,3]
vblendps$8, %xmm3, %xmm0, %xmm0 # xmm0 = xmm0[0,1,2],xmm3[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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
