[llvm-bugs] [Bug 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 35698, which changed state. Bug 35698 Summary: include/istream causes test failures on x86 due to -Werror,-Wtautological-constant-compare https://bugs.llvm.org/show_bug.cgi?id=35698 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35698] include/istream causes test failures on x86 due to -Werror, -Wtautological-constant-compare
https://bugs.llvm.org/show_bug.cgi?id=35698 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Hans Wennborg --- The warning has been moved out off -Wextra in r322901, which was also merged to 6.0 in r322931. -- 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 28573] [X86] AMD Jaguar scheduler doesn't correctly model 256-bit AVX instructions
https://bugs.llvm.org/show_bug.cgi?id=28573 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Simon Pilgrim --- Resolving this, all btver2 AVX ymm instructions now show the 'double pumping' half throughput of their xmm equivalents. -- 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 32325] [META][X86] Improve implementation and use of X86 scheduler models
https://bugs.llvm.org/show_bug.cgi?id=32325 Bug 32325 depends on bug 28573, which changed state. Bug 28573 Summary: [X86] AMD Jaguar scheduler doesn't correctly model 256-bit AVX instructions https://bugs.llvm.org/show_bug.cgi?id=28573 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36013] New: LLDB: StandardStartupTest.TestStopReplyContainsThreadPcs fails on (32-bit) x86
https://bugs.llvm.org/show_bug.cgi?id=36013 Bug ID: 36013 Summary: LLDB: StandardStartupTest.TestStopReplyContainsThreadPcs fails on (32-bit) x86 Product: lldb Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: mgo...@gentoo.org CC: llvm-bugs@lists.llvm.org Blocks: 35804 This one seems specific to 32-bit x86 (it fails in my 32-bit chroot, and passes in 64-bit). I need to check if it's regression though. FAIL: lldb-Unit :: tools/lldb-server/tests/./LLDBServerTests/StandardStartupTest.TestStopReplyContainsThreadPcs (313 of 315) TEST 'lldb-Unit :: tools/lldb-server/tests/./LLDBServerTests/StandardStartupTest.TestStopReplyContainsThreadPcs' FAILED Note: Google Test filter = StandardStartupTest.TestStopReplyContainsThreadPcs [==] Running 1 test from 1 test case. [--] Global test environment set-up. [--] 1 test from StandardStartupTest [ RUN ] StandardStartupTest.TestStopReplyContainsThreadPcs /var/tmp/portage/dev-util/lldb-6.0./work/lldb-6.0./unittests/tools/lldb-server/tests/ThreadIdsInJstopinfoTest.cpp:47: Failure Expected: stop_reply_pcs[tid] Which is: 4160396025 To be equal to: *pc_value Which is: 17868764865783398400 Mismatched PC for thread: 25287 [ FAILED ] StandardStartupTest.TestStopReplyContainsThreadPcs (207 ms) [--] 1 test from StandardStartupTest (207 ms total) Full build & test log attached. This is on release_60 branch with stand-alone build on Gentoo. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=35804 [Bug 35804] [meta] 6.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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36014] New: Assertion `MI && "No instruction at index"' with unallocatable inline assembly
https://bugs.llvm.org/show_bug.cgi?id=36014 Bug ID: 36014 Summary: Assertion `MI && "No instruction at index"' with unallocatable inline assembly Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: pablo.bar...@arm.com CC: llvm-bugs@lists.llvm.org Created attachment 19709 --> https://bugs.llvm.org/attachment.cgi?id=19709&action=edit Inline assembly using too many registers The attached code features some inline assembly code that tries to use more registers than available. This code tries to use a subset of the GPRs for the allocation of the first register via constraint 'h' (higher subset of the GPRs), hitting an assertion in the register allocator: llvm/lib/CodeGen/SplitKit.cpp:772: llvm::SlotIndex llvm::SplitEditor::leaveIntvAfter(llvm::SlotIndex): Assertion `MI && "No instruction at index"' failed. Using constraint 'r' instead (i.e. general-purpose register) for all the registers results in the following message shown several times: error: inline assembly requires more registers than available which is the correct behaviour. I was able to track down why allocating to the all-GPRs class gives a reasonable error message, while high/low GPRs crash the compiler. Function RAGreedy::tryInstructionSplit() bails out at the beginning if the register class being used for the allocation is not a "proper subclass": if (!RegClassInfo.isProperSubClass(CurRC)) return 0; If I understood correctly, proper subclasses have a parent class with a bigger number of available allocatable registers. The Arm GPR class is not a proper subclass, while the "low regs GPR" class is (with GPR being its parent class with a bigger number of regs). Therefore, GPRs don't hit the bug later in that function, whereas subclasses do. The following command can be used to build the example: clang --target=thumb-arm-none-eabi -march=armv8-m.main -O2 test.c I have been able to reproduce with Arm, but I believe this bug will affect any architecture with constraints that select register classes with parent classes. -- 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 36015] New: Regression in StructurizeCFG, r321751: complex loop structure turned into infinite loop
https://bugs.llvm.org/show_bug.cgi?id=36015
Bug ID: 36015
Summary: Regression in StructurizeCFG, r321751: complex loop
structure turned into infinite loop
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: nhaeh...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19710
--> https://bugs.llvm.org/attachment.cgi?id=19710&action=edit
Reduced test case
I'm attaching a reduced test case, plus the output of `opt -structurizecfg`.
Change r321751 ("StructurizeCFG: Fix broken backedge detection") breaks this
test case, in the following way:
The original code has edges from both %if and %else into the %exit block. In
the resulting code, the edge from %if to %exit disappears: if the exit
condition is met (%cond.if = false), the control will follow %if -> %Flow1 ->
%Flow2 -> %loop.outer instead of %if -> %Flow1 -> %Flow2 -> %exit.
This bug regresses various OpenGL test suites, for example
dEQP-GLES3.functional.shaders.loops.do_while_dynamic_iterations.conditional_continue_vertex.
--
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 35909] static_cast(this) does not propagate non-null invariant of 'this'
https://bugs.llvm.org/show_bug.cgi?id=35909 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Sanjay Patel --- Should be fixed with: https://reviews.llvm.org/rL322950 With that change, everything proceeds as before until after inlining. When we run instcombine after that, we kill the null check because the GEP is now known to be inbounds: IC: Visiting: %sub.ptr2.i = getelementptr inbounds %class.B, %class.B* %b, i64 -1 IC: Visiting: %1 = bitcast %class.B* %sub.ptr2.i to %class.A* IC: Visiting: %tobool1 = icmp eq %class.A* %1, null IC: Replacing %tobool1 = icmp eq %class.A* %1, null with i1 false -- 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 36016] New: GlobalOpt emits debug fragments with wrong offsets for padded fields
https://bugs.llvm.org/show_bug.cgi?id=36016
Bug ID: 36016
Summary: GlobalOpt emits debug fragments with wrong offsets for
padded fields
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: david.stenb...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19712
--> https://bugs.llvm.org/attachment.cgi?id=19712&action=edit
IR reproducer.
LLVM commit used: r322927.
When running:
opt -globalopt -S foo.ll -o -
on the attached reproducer, a fragment expression with an offset of 32 bits is
created for the second field in the struct:
!14 = !DIGlobalVariableExpression(var: !7, expr:
!DIExpression(DW_OP_LLVM_fragment, 32, 64))
However, as the field is padded up to 64 bits:
!12 = !DIDerivedType(tag: DW_TAG_member, name: "bar_p", scope: !8, file: !3,
line: 3, baseType: !13, size: 64, offset: 64)
that fragment offset is incorrect.
The reproducer was created by compiling the following program, foo.c:
struct {
int foo;
int *bar_p;
} static var;
int *ptr;
int main() {
if (var.foo == 0)
var.bar_p = ptr;
return 0;
}
using:
clang -march=x86-64 -O0 -g2 -S -emit-llvm foo.c -o foo.ll
--
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 32164] Inner product of two vectors gives inefficient code
https://bugs.llvm.org/show_bug.cgi?id=32164 Simon Pilgrim changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||322579 Status|NEW |RESOLVED --- Comment #6 from Simon Pilgrim --- Fixed in rL322579 -- 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 36017] New: lld ignoring LMA for some sections
https://bugs.llvm.org/show_bug.cgi?id=36017 Bug ID: 36017 Summary: lld ignoring LMA for some sections Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: roy...@freebsd.org CC: llvm-bugs@lists.llvm.org Created attachment 19713 --> https://bugs.llvm.org/attachment.cgi?id=19713&action=edit FreeBSD amd64 linker script Hello, When linking the FreeBSD amd64 kernel with lld it seems the LMA of some sections is not correctly set, this is the output: # readelf -l /boot/kernel/kernel Elf file type is EXEC (Executable file) Entry point 0x80331000 There are 10 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSizMemSiz FlgAlign PHDR 0x0040 0x80200040 0x80200040 0x0230 0x0230 R 0x8 INTERP 0x0270 0x80200270 0x00200270 0x000d 0x000d R 0x1 [Requesting program interpreter: /red/herring] LOAD 0x 0x8020 0x8020 0x0270 0x0270 R E0x1000 LOAD 0x0270 0x80200270 0x00200270 0x01576478 0x01576d90 R E0x1000 LOAD 0x01577000 0x81777000 0x01777000 0x00155888 0x00681a40 RW 0x1000 DYNAMIC0x01577000 0x81777000 0x01777000 0x00f0 0x00f0 RW 0x8 GNU_RELRO 0x01577000 0x81777000 0x01777000 0x00f0 0x00f0 R 0x1 GNU_STACK 0x 0x 0x 0x 0x RW 0 NOTE 0x015766c4 0x817766c4 0x017766c4 0x0024 0x0024 R 0x4 NOTE 0x086607e0 0x 0x8000 0x 0x R 0x4 Section to Segment mapping: Segment Sections... 00 01 .interp 02 03 .interp .hash .gnu.hash .dynsym .dynstr .text .rodata .eh_frame set_sysctl_set set_sysinit_set set_sysuninit_set set_modmetadata_set set_cam_xpt_xport_set set_cam_xpt_proto_set set_kdb_dbbe_set set_ah_chips set_ah_rfs set_kbddriver_set set_sdt_providers_set set_sdt_probes_set set_sdt_argtypes_set set_cons_set set_gdb_dbgport_set usb_host_id set_vt_drv_set set_ratectl_set set_crypto_set set_ieee80211_ioctl_getset set_ieee80211_ioctl_setset set_scanner_set set_videodriver_set set_scterm_set set_scrndr_set set_vga_set kern_conf .note.gnu.build-id .preinit_array .init_array .fini_array .data.rel.ro 04 .preinit_array .init_array .fini_array .data.rel.ro .dynamic .data.read_frequently .data.read_mostly .data.exclusive_cache_line .data set_pcpu set_vnet .bss .ldata 05 .preinit_array .init_array .fini_array .data.rel.ro .dynamic 06 .preinit_array .init_array .fini_array .data.rel.ro .dynamic 07 __xen_guest 08 .note.gnu.build-id 09 __xen_guest Note that the first and the third program headers have a wrong physical address. The linker script used is attached to this ticket. -- 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 36018] New: [GlobalISel][AArch64] Two load instructions generated for single volatile load
https://bugs.llvm.org/show_bug.cgi?id=36018
Bug ID: 36018
Summary: [GlobalISel][AArch64] Two load instructions generated
for single volatile load
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: GlobalISel
Assignee: unassignedb...@nondot.org
Reporter: john.brawn@gmail.com
CC: llvm-bugs@lists.llvm.org
For the following IR:
@g = global i16 0, align 2
declare void @bar(i32)
define hidden void @foo() {
%1 = load volatile i16, i16* @g, align 2
%2 = sext i16 %1 to i32
call void @bar(i32 %2)
ret void
}
llc -mtriple=aarch64 -global-isel generates for the load followed by sext:
adrp x8, g
add x8, x8, :lo12:g
ldrh wzr, [x8]
ldrsh w0, [x8]
g is loaded twice, once with a zero-extending load which is discarded, and
second with a sign-extending load. For a volatile load we should be generating
only a single load instruction.
--
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 36019] New: Extend IndentPPDirectives with a BeforeHash option
https://bugs.llvm.org/show_bug.cgi?id=36019 Bug ID: 36019 Summary: Extend IndentPPDirectives with a BeforeHash option Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: aardap...@gmail.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Currently IndentPPDirectives can have values None: > #ifdef FOO > #define BAR > #endif or AfterHash: > #ifdef FOO > #define BAR > #endif I am suggesting to also add BeforeHash: > #ifdef FOO > #define BAR > #endif -- 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 36020] New: Add option to IndentPPDirectives to respect indentation of context
https://bugs.llvm.org/show_bug.cgi?id=36020
Bug ID: 36020
Summary: Add option to IndentPPDirectives to respect
indentation of context
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: aardap...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
With IndentPPDirectives: AfterHash, preprocessor directives are indented, but
only relative to other preprocessor directives, not to the surrounding code. So
code that is intended to look like:
> void foo() {
> if (bar) {
> A;
> # ifdef D
> # define E
> B;
> # endif
> C;
> }
> }
is clang-formatted to:
> void foo() {
> if (bar) {
> A;
> #ifdef D
> #define E
> B;
> #endif
> C;
> }
> }
This is a follow-up from bug https://bugs.llvm.org/show_bug.cgi?id=17362
Related feature: https://bugs.llvm.org/show_bug.cgi?id=36019
--
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 35907] Overeager side effect propagation generates suboptimal backend code
https://bugs.llvm.org/show_bug.cgi?id=35907 Sanjay Patel changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Sanjay Patel --- Should be fixed via the backend (for x86 only) after: https://reviews.llvm.org/rL322957 Craig has a related improvement proposed in: https://reviews.llvm.org/D42265 The description mentions other targets that may also benefit from these kinds of changes. If you have an example for a different target, please file another bug. 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35969] clang crashes at -O1 and above: : Assertion `SuccTN && "Unreachable successor found at reachable insertion"' failed.
https://bugs.llvm.org/show_bug.cgi?id=35969 Jakub Kuderski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Jakub Kuderski --- This should be fixed by r322993. -- 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 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 35891, which changed state. Bug 35891 Summary: Merge r322200 into the 6.0 branch https://bugs.llvm.org/show_bug.cgi?id=35891 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- 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 35891] Merge r322200 into the 6.0 branch
https://bugs.llvm.org/show_bug.cgi?id=35891 Matthias Braun changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Matthias Braun --- The verifier fixes have landed in r322917, however it's not a fix I'd like to bring into the release branch. So maybe it's best if we leave r322200/r322919 out of the 6.0 release as well. -- 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 5303 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: BaseReg == nullptr
Comment #2 on issue 5303 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: BaseReg == nullptr https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5303#c2 ClusterFuzz has detected this issue as fixed in range 201801180725:201801190723. Detailed report: https://oss-fuzz.com/testcase?key=4575078260932608 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--x86_64-O2 Fuzz target binary: llvm-isel-fuzzer--x86_64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: BaseReg == nullptr CodeGenPrepare::optimizeMemoryInst CodeGenPrepare::optimizeInst Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801120612:201801130619 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801180725:201801190723 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4575078260932608 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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] Issue 5303 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: BaseReg == nullptr
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 5303 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: BaseReg == nullptr https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5303#c3 ClusterFuzz testcase 4575078260932608 is verified as fixed, so closing issue as verified. 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36021] New: [feature request] nop intrinsic
https://bugs.llvm.org/show_bug.cgi?id=36021
Bug ID: 36021
Summary: [feature request] nop intrinsic
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: jgo...@google.com
CC: llvm-bugs@lists.llvm.org
I need to align a function to a 16-byte boundary which is NOT 32-byte aligned.
That is, something like:
void my_function() __attribute__((aligned(32))) {
asm("[16-byte nop]");
... my_function code goes here...
}
It would be nice to have a __builtin_nop(n) intrinsic that generated n-byte
nops.
--
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 35906] Comparisons against last enum are optimizable (found via LLVM classof() analysis)
https://bugs.llvm.org/show_bug.cgi?id=35906 David Zarzycki 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 36022] New: MSAN use-after-dtor in IR/User.cpp
https://bugs.llvm.org/show_bug.cgi?id=36022 Bug ID: 36022 Summary: MSAN use-after-dtor in IR/User.cpp Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: st...@obrien.cc CC: llvm-bugs@lists.llvm.org Created attachment 19714 --> https://bugs.llvm.org/attachment.cgi?id=19714&action=edit MSAN report This might be a dupe of #24578 (Aug 2015), not sure. I found this while running Clang, not during a unit test, so this might be different code or a different path. -- 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 5512 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: InIdx < NumElts && "Illegal insertion index"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-01-20 Type: Bug New issue 5512 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: InIdx < NumElts && "Illegal insertion index" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5512 Detailed report: https://oss-fuzz.com/testcase?key=5810538689855488 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--x86_64-O2 Fuzz target binary: llvm-isel-fuzzer--x86_64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: InIdx < NumElts && "Illegal insertion index" resolveTargetShuffleInputs combineX86ShufflesRecursively Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710160455:201710190451 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5810538689855488 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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 have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- 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
