[llvm-bugs] [Bug 44283] New: --dump-section run at wrong time
https://bugs.llvm.org/show_bug.cgi?id=44283 Bug ID: 44283 Summary: --dump-section run at wrong time Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llvm-objcopy/strip Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: alexander.v.shaposhni...@gmail.com, jake.h.ehrl...@gmail.com, jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org, ruppre...@google.com llvm-objcopy --dump-section is run after removing and adding of sections. This is incorrect, since GNU objcopy runs it before. The GNU behaviour also intuitively makes sense to me: to "extract" a section (i.e. dump and remove), it should be one operation. However, llvm-objcopy does not allow this: if an attempt is made to dump a section in the same invocation as it is removed, llvm-objcopy emits an error saying the section can't be found. Similarly, dumping a newly added section should not be allowed to match GNU (i.e. --dump-section .data=data.txt --add-section .data=from.txt should emit an error). -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44176] [C++] Regression in a29aa47106205ec95c12e0ebac4260c5de878a6a [OpenCL] Move addr space deduction to Sema.
https://bugs.llvm.org/show_bug.cgi?id=44176 David Rohr changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #2 from David Rohr --- I confirm the patch fixes the issue. Closing this. -- 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 44284] New: [regression] const llvm::MCExpr *llvm::MCSymbol::getVariableValue(bool) const: Assertion `isVariable() && "Invalid accessor!"' failed.
https://bugs.llvm.org/show_bug.cgi?id=44284
Bug ID: 44284
Summary: [regression] const llvm::MCExpr
*llvm::MCSymbol::getVariableValue(bool) const:
Assertion `isVariable() && "Invalid accessor!"'
failed.
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: arichardson@gmail.com
CC: llvm-bugs@lists.llvm.org, nemanja.i@gmail.com
It appears this bug was introduced by
https://github.com/llvm/llvm-project/commit/cd36a2857ea172d70a7a841f4b622a5f408944a9
[PPC64] Update LocalEntry from assigned symbols
The following reduced test case triggers the assertion:
// RUN: %clang_cc1 -triple=ppc64 -emit-obj %s
__asm__(".equ err, _err");
void err() {};
This was originally reported by Nathaniel Wesley Filardo as
https://github.com/CTSRD-CHERI/llvm-project/issues/350
--
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 43367] [ICE] Assertion failed: Invalid modifier for QualType argument
https://bugs.llvm.org/show_bug.cgi?id=43367 Trass3r changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Trass3r --- Yes looks like it has been fixed in the meantime. -- 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 44285] New: -Wdefaulted-function-deleted is not available from apt llvm
https://bugs.llvm.org/show_bug.cgi?id=44285 Bug ID: 44285 Summary: -Wdefaulted-function-deleted is not available from apt llvm Product: clang Version: 9.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: maxime.roussinbelan...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk I have installed clang-9 https://apt.llvm.org/ from there and I have built clang from source. Both are from the same commit `432bf48c08d`. I think that's 9-rc2. https://godbolt.org/z/H_dxee Built from source I get the same exact warnings. >From llvm apt, I don't get the `defaulted-function-deleted` error. Why there would be differences from source and apt packages in the available warnings? -- 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 44286] New: SLP vectorization failure
https://bugs.llvm.org/show_bug.cgi?id=44286
Bug ID: 44286
Summary: SLP vectorization failure
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
char src[512];
char dst[512];
#define WIDTH 32
void foo(int height, int a, int b, int c, int d, int dst_stride) {
char * ptr_src = src;
char * ptr_dst = dst;
for( int y = 0; y < height; y++ )
{
for( int x = 0; x < WIDTH; x++ )
{
char x1 = ((a + c) * ptr_src[x] ) >> 6;
char x2 = ((b + d) * ptr_src[x+1]) >> 6;
ptr_dst[x] = x1 + x2;
}
ptr_dst += dst_stride;
ptr_src += 32;
}
}
ICC and GCC can vectorize this loop, Clang does not.
https://godbolt.org/z/EsHdPg
--
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 44287] New: Redundant phi elimination
https://bugs.llvm.org/show_bug.cgi?id=44287
Bug ID: 44287
Summary: Redundant phi elimination
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
int comp(int max, int pos, unsigned char *cur)
{
unsigned char *p = cur + pos;
int len = 0;
while (++len != max)
if (p[len] != cur[len])
break;
return cur[len];
}
Clang 9
define dso_local i32 @comp(i32, i32, i8* nocapture readonly) local_unnamed_addr
#0 {
%4 = sext i32 %1 to i64
%5 = getelementptr inbounds i8, i8* %2, i64 %4
%6 = zext i32 %0 to i64
br label %7
7:; preds = %11, %3
%8 = phi i64 [ %9, %11 ], [ 0, %3 ]
%9 = add nuw nsw i64 %8, 1
%10 = icmp eq i64 %9, %6
br i1 %10, label %17, label %11
11: ; preds = %7
%12 = getelementptr inbounds i8, i8* %5, i64 %9
%13 = load i8, i8* %12, align 1, !tbaa !2
%14 = getelementptr inbounds i8, i8* %2, i64 %9
%15 = load i8, i8* %14, align 1, !tbaa !2
%16 = icmp eq i8 %13, %15
br i1 %16, label %7, label %17
17: ; preds = %11, %7
%18 = and i64 %9, 4294967295
%19 = getelementptr inbounds i8, i8* %2, i64 %18
%20 = load i8, i8* %19, align 1, !tbaa !2
%21 = zext i8 %20 to i32
ret i32 %21
}
Clang 10
define dso_local i32 @comp(i32 %0, i32 %1, i8* nocapture readonly %2)
local_unnamed_addr #0 {
%4 = sext i32 %1 to i64
%5 = getelementptr inbounds i8, i8* %2, i64 %4
%6 = zext i32 %0 to i64
br label %7
7:; preds = %11, %3
%8 = phi i64 [ %9, %11 ], [ 0, %3 ]
%9 = add nuw nsw i64 %8, 1
%10 = icmp eq i64 %9, %6
br i1 %10, label %19, label %11
11: ; preds = %7
%12 = getelementptr inbounds i8, i8* %5, i64 %9
%13 = load i8, i8* %12, align 1, !tbaa !2
%14 = getelementptr inbounds i8, i8* %2, i64 %9
%15 = load i8, i8* %14, align 1, !tbaa !2
%16 = icmp eq i8 %13, %15
br i1 %16, label %7, label %17
17: ; preds = %11
%18 = and i64 %9, 4294967295
br label %19
19: ; preds = %7, %17
%20 = phi i64 [ %18, %17 ], [ %6, %7 ]
%21 = getelementptr inbounds i8, i8* %2, i64 %20
%22 = load i8, i8* %21, align 1, !tbaa !2
%23 = zext i8 %22 to i32
ret i32 %23
}
See new phi "%20 = phi i64 [ %18, %17 ], [ %6, %7 ]".
Codegen is worse a bit:
Clang 9
comp: # @comp
movsxd rax, esi
mov r8d, edi
add rax, rdx
mov edi, 1
.LBB0_1:# =>This Inner Loop Header: Depth=1
mov rsi, rdi
cmp r8, rdi
je .LBB0_3
movzx ecx, byte ptr [rax + rsi]
lea rdi, [rsi + 1]
cmp cl, byte ptr [rdx + rsi]
je .LBB0_1
.LBB0_3:
mov eax, esi
movzx eax, byte ptr [rdx + rax]
ret
Clang 10
comp: # @comp
movsxd rax, esi
mov r8d, edi
lea r9, [rdx + 1]
lea rdi, [rdx + rax]
add rdi, 1
lea rax, [r8 - 1]
xor esi, esi
.LBB0_1:# =>This Inner Loop Header: Depth=1
cmp rax, rsi
je .LBB0_4
movzx ecx, byte ptr [rdi + rsi]
cmp cl, byte ptr [r9 + rsi]
lea rsi, [rsi + 1]
je .LBB0_1
mov r8d, esi
.LBB0_4:
movzx eax, byte ptr [rdx + r8]
ret
https://godbolt.org/z/2zMDVf
--
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 17548 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-O2: ASSERT: (VT.getVectorNumElements() + N2C->getZExtValue() <= N1.getValueType().getVectorN
Updates: Labels: Deadline-Approaching Comment #2 on issue 17548 by sheriff...@chromium.org: llvm:llvm-isel-fuzzer--aarch64-O2: ASSERT: (VT.getVectorNumElements() + N2C->getZExtValue() <= N1.getValueType().getVectorN https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17548#c2 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 34591] [meta] Reduce build time of llvm+clang
https://bugs.llvm.org/show_bug.cgi?id=34591 Bug 34591 depends on bug 34259, which changed state. Bug 34259 Summary: LLVM intrinsic emitter should split Intrinsics.gen to minimize project rebuilds on Intrinsics*.td file chanes https://bugs.llvm.org/show_bug.cgi?id=34259 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 34259] LLVM intrinsic emitter should split Intrinsics.gen to minimize project rebuilds on Intrinsics*.td file chanes
https://bugs.llvm.org/show_bug.cgi?id=34259 Reid Kleckner changed: What|Removed |Added CC||chris.biene...@gmail.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Reid Kleckner --- That patch landed, but there is more work that could be done to loosen the coupling between targets and intrinsics. Over the last year, the intrinsics tablegen files have changed 216 times: $ git log --since='1 year' --format=oneline ../llvm/include/llvm/IR/Intrinsics*.td | wc -l 216 41 of those are target independent intrinsics: $ git log --since='1 year' --date relative --format=format:'%ad %an' ../llvm/include/llvm/IR/Intrinsics.td | wc -l 41 It doesn't seem worth taking this further for now since it's easy to touch any other header and trigger a rebuild of LLVM, so I think I'll close this. -- 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 44272] [CLANG-CL] 64x inline assembler function call/jump miscompiled
https://bugs.llvm.org/show_bug.cgi?id=44272 Martynas Skirmantas changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #4 from Martynas Skirmantas --- Yeah, understood, doesn't look like this will go anywhere but would be great, I wouldn't say that its banned, there were recent posts of Microsoft claiming they are looking into it but there's still no response from them regarding that, intrinsics don't really cut it when you need absolute control without the function call overhead or some other reason? truly a bummer for someone that works with the system internals all the time. GCC/G++ (GNU) supports 64bit inline assembly which I have used in the past but moved on due the need to use windows libraries which has many problems when attempted to use with GNU. I've even managed to make a couple of kernel drivers with it, but that is not a option for someone that of focusing on only windows and needs to use very uncommon libraries. Well, thank you for taking the time at taking a look at the problem, I thought it may be worth reporting regardless so it wouldn't go unnoticed. -- 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 44288] New: Consider hiding __beginN / __endN / __rangeN range-based for variables from debug info
https://bugs.llvm.org/show_bug.cgi?id=44288 Bug ID: 44288 Summary: Consider hiding __beginN / __endN / __rangeN range-based for variables from debug info Product: clang Version: 8.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk I was debugging something in windbg and I saw this: 0:000> dx Debugger.Sessions[0].Processes[7704].Threads[13648].Stack.Frames[8].SwitchTo();dv /t /v Debugger.Sessions[0].Processes[7704].Threads[13648].Stack.Frames[8].SwitchTo() class lld::coff::`anonymous namespace'::PDBLinker * this = class lld::coff::ObjFile * file = struct lld::coff::CVIndexMap * externIndexMap = 007b`3e58bee0 struct lld::coff::CVIndexMap objectIndexMap = struct lld::coff::CVIndexMap 007b`3e58c2a0 class llvm::Expected indexMapResult = class llvm::Expected 007b`3e58bed0 struct lld::ScopedTimer t = struct lld::ScopedTimer 007b`3e58c190 class lld::coff::`anonymous namespace'::DebugSHandler dsh = class lld::coff::`anonymous namespace'::DebugSHandler class llvm::pdb::DbiStreamBuilder * dbiBuilder = class lld::coff::SectionChunk ** __end2 = class lld::coff::SectionChunk ** __begin2 = class llvm::ArrayRef * __range2 = class lld::coff::SectionChunk * debugChunk = class llvm::FixedStreamArray fpoRecords = class llvm::BinaryStreamReader reader = class llvm::ArrayRef relocatedDebugContents = unsigned int count = class llvm::FixedStreamArrayIterator __begin4 = class llvm::FixedStreamArrayIterator __end4 = class llvm::FixedStreamArray * __range4 = Some of these variables are compiler synthesized and therefore uninteresting. We should consider mot emitting debug info for them in the first place. Alternatively, we could try mixing in scopes in our optimized debug info output to hide some of these variables, which are not actually in scope at this point in the program. I am stopped at the mergeDebugT call here in LLD: https://github.com/llvm/llvm-project/blob/7081c922416b7b2348a1b10cd1d9528f3089f5fb/lld/COFF/PDB.cpp#L1172 -- 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 44289] New: Investigate `nan` returning random distributions in fuzzing tests.
https://bugs.llvm.org/show_bug.cgi?id=44289 Bug ID: 44289 Summary: Investigate `nan` returning random distributions in fuzzing tests. Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: e...@efcs.ca CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Some of the random distributions return NaN when being fuzzed. The likely cause is that the fuzzer is feeding in data that violates the pre-conditions, but we should figure out if libc++ can handle these precondition violations better. See `random_distribution_helper` in `libcxx/fuzzing/fuzzing.cpp`. -- 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 44272] [CLANG-CL] 64x inline assembler function call/jump miscompiled
https://bugs.llvm.org/show_bug.cgi?id=44272 Martynas Skirmantas changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED|REOPENED --- Comment #5 from Martynas Skirmantas --- Hold up, I have reopened the bug report, I did way more digging and I found many people stating that Clang support 64bit inline assembly and some people are using it by looking at stackoverflow questions, here is old post: http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html It states that chrome is using Clang-CL and they use 64 bit and 32 bit inline assembly to build a library. What is going on here? it just doesn't add up, there are many people that claim this if you google enough your self, surely a llvm blogging site wouldn't lie about such a thing. This is what it says: "Clang supports 64-bit inline assembly. For example, in Chrome we built libyuv (a video format conversion library) with Clang long before we built all of Chrome with it. libyuv had highly-tuned 64-bit inline assembly with performance not reachable with intrinsics, and we could just use that code on Windows." There are many uses for a inline assembler as statement by the blog, this bug should be fixed, which has been as confirmed by "Eric Astor" using godbolt compiler explorer. I would like to hear a official statement that this bug can't be fixed or 64bit inline assembly is NOT supported by Clang. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44290] New: Pointers defined by clang have default pointing values.
https://bugs.llvm.org/show_bug.cgi?id=44290
Bug ID: 44290
Summary: Pointers defined by clang have default pointing
values.
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: 1059252...@qq.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Hi,
when I used clang9.0 and the latest version to output the value that
NISLParameter0 points to, they both outputed 1. While other compilers, such as
gcc and intelc,reported Segmentation fault.
TestCase:
#include
int main(void)
{
int *NISLParameter0;
printf("%d\n", *NISLParameter0);
return 0;
}
Command:
./clang/version_latest/llvm-project/build/bin/clang testcase.c
./a.out
Version:
clang9.0.0 && clang10.0.0
Output:
1
Expected output:
Segmentation fault
Is this right for the clang complier? Looking forward to your reply.
--
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 44290] Pointers defined by clang have default pointing values.
https://bugs.llvm.org/show_bug.cgi?id=44290 David Blaikie changed: What|Removed |Added Status|NEW |RESOLVED CC||dblai...@gmail.com Resolution|--- |INVALID --- Comment #1 from David Blaikie --- Dereferencing an uninitialized pointer is undefined behavior - the program has no guarantees on how it should or will behave. (if you want a more precise diagnosis, compiling/running with -fsanitize=address should do the trick, I think?) -- 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 44037] Adding range which has a base that is less than the function's low PC
https://bugs.llvm.org/show_bug.cgi?id=44037 Omair Javaid changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Omair Javaid --- fixed after rev 6ce1a897b6a82e18059fd3b75b8d52ff12c2a605 -- 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
