[llvm-bugs] [Bug 42962] New: foldICmpBinOp => Assertion `isa(Val) && "cast() argument of incompatible type!"
https://bugs.llvm.org/show_bug.cgi?id=42962
Bug ID: 42962
Summary: foldICmpBinOp => Assertion `isa(Val) && "cast()
argument of incompatible type!"
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: bjorn.a.petters...@ericsson.com
CC: lebedev...@gmail.com, llvm-bugs@lists.llvm.org
Given this IR (foo.ll):
;
@f.a = internal global i16 0
define dso_local void @f() local_unnamed_addr {
entry:
%0 = load i16, i16* @f.a
%shr = ashr i16 %0, 1
%shr1 = ashr i16 %shr, zext (i1 icmp ne (i16 ptrtoint (i16* @f.a to i16), i16
1) to i16)
%and = and i16 %shr1, 1
%tobool = icmp ne i16 %and, 0
br i1 %tobool, label %land.rhs, label %land.end
land.rhs:
br label %land.end
land.end:
ret void
}
;
we hit an assertion when running instcombine.
> opt -instcombine -o - foo.ll -S
opt: ../include/llvm/Support/Casting.h:264: typename cast_retty::ret_type llvm::cast(Y *) [X = llvm::BinaryOperator, Y = llvm::Value]:
Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.
Stack dump:
0. Program arguments: opt -instcombine -o - foo.ll -S
1. Running pass 'Function Pass Manager' on module 'foo.ll'.
2. Running pass 'Combine redundant instructions' on function '@f'
#0 0x025455a4 PrintStackTraceSignalHandler(void*) (opt+0x25455a4)
#1 0x0254330e llvm::sys::RunSignalHandlers() (opt+0x254330e)
#2 0x025459a8 SignalHandler(int) (opt+0x25459a8)
#3 0x003ba280f7e0 __restore_rt (/lib64/libpthread.so.0+0x3ba280f7e0)
#4 0x003ba24324f5 raise (/lib64/libc.so.6+0x3ba24324f5)
#5 0x003ba2433cd5 abort (/lib64/libc.so.6+0x3ba2433cd5)
#6 0x003ba242b66e __assert_fail_base (/lib64/libc.so.6+0x3ba242b66e)
#7 0x003ba242b730 __assert_perror_fail (/lib64/libc.so.6+0x3ba242b730)
#8 0x020d3647 llvm::InstCombiner::foldICmpBinOp(llvm::ICmpInst&)
(opt+0x20d3647)
#9 0x020d9f3b llvm::InstCombiner::visitICmpInst(llvm::ICmpInst&)
(opt+0x20d9f3b)
#10 0x020640af llvm::InstCombiner::run() (opt+0x20640af)
#11 0x02066491 combineInstructionsOverFunction(llvm::Function&,
llvm::InstCombineWorklist&, llvm::AAResults*, llvm::AssumptionCache&,
llvm::TargetLibraryInfo&, llvm::DominatorTree&, llvm::TargetTransformInfo
const&, llvm::OptimizationRemarkEmitter&, llvm::BlockFrequencyInfo*,
llvm::ProfileSummaryInfo*, bool, llvm::LoopInfo*) (opt+0x2066491)
#12 0x02066cee
llvm::InstructionCombiningPass::runOnFunction(llvm::Function&) (opt+0x2066cee)
#13 0x01edf873 llvm::FPPassManager::runOnFunction(llvm::Function&)
(opt+0x1edf873)
#14 0x01edfb83 llvm::FPPassManager::runOnModule(llvm::Module&)
(opt+0x1edfb83)
#15 0x01ee01ed llvm::legacy::PassManagerImpl::run(llvm::Module&)
(opt+0x1ee01ed)
#16 0x0080e9b7 main (opt+0x80e9b7)
#17 0x003ba241ed20 __libc_start_main (/lib64/libc.so.6+0x3ba241ed20)
#18 0x007f5ff9 _start (opt+0x7f5ff9)
Abort (core dumped)
Afaict it started to happen after:
commit 72b8d41ce811fa1a20711e0619d4a5307a754e57
Author: Roman Lebedev
Date: Mon Jul 1 15:55:15 2019 +
[InstCombine] Shift amount reassociation in bittest (PR42399)
Summary:
Given pattern:
`icmp eq/ne (and ((x shift Q), (y oppositeshift K))), 0`
we should move shifts to the same hand of 'and', i.e. rewrite as
`icmp eq/ne (and (x shift (Q+K)), y), 0` iff `(Q+K) u< bitwidth(x)`
It might be tempting to not restrict this to situations where we know
we'd fold two shifts together, but i'm not sure what rules should there be
to avoid endless combine loops.
We pick the same shift that was originally used to shift the variable we
picked to shift:
https://rise4fun.com/Alive/6x1v
Should fix [[ https://bugs.llvm.org/show_bug.cgi?id=42399 | PR42399]].
Reviewers: spatel, nikic, RKSimon
Reviewed By: spatel
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63829
llvm-svn: 364791
--
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 42963] New: Fix nested segment algorithm for segments with different alignments
https://bugs.llvm.org/show_bug.cgi?id=42963
Bug ID: 42963
Summary: Fix nested segment algorithm for segments with
different alignments
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
The llvm-objcopy (and llvm-strip) segment layout algorithm follows the rough
approach of:
1) If segment1 offset starts before segment2's, and it's end ends after the
start of segment2, segment1 is a parent of segment2.
2) If two segments start at the same offset, the larger one is considered the
parent.
3) If two segments have the same size and offset, the first one in the program
header table is considered the parent.
I think we need to add another condition before 3), namely that if two segments
have the same size and offset, the one with the larger alignment should be
considered the parent.
I have a lit test illustrating the issue:
---
## This test shows that llvm-objcopy and llvm-strip work correctly when two
## segments have the same offset and size, but the first one in the table has a
## lower alignment. In this case, the parent should be the one with the higher
## alignment.
# RUN: yaml2obj %s -o %t
# RUN: llvm-objcopy %t %t2
# RUN: llvm-readobj --program-headers %t2 | FileCheck %s
# RUN: llvm-strip --no-strip-all %t -o %t3
# RUN: cmp %t2 %t3
# CHECK: ProgramHeaders [
# CHECK-NEXT: ProgramHeader {
# CHECK-NEXT: Type: PT_TLS (0x7)
# CHECK-NEXT: Offset: 0x200
# CHECK:ProgramHeader {
# CHECK-NEXT: Type: PT_LOAD (0x1)
# CHECK-NEXT: Offset: 0x200
--- !ELF
FileHeader:
Class: ELFCLASS64
Data:ELFDATA2LSB
Type:ET_EXEC
Machine: EM_X86_64
Sections:
- Name: padding
Type: SHT_PROGBITS
AddressAlign: 0x800
ProgramHeaders:
- Type: PT_TLS
Offset: 0x400
FileSize: 0x10
MemSize: 0x10
VAddr:0x200
Align:0x1
- Type: PT_LOAD
Offset: 0x400
FileSize: 0x10
MemSize: 0x10
VAddr:0x200
Align:0x200
---
Note that in this test, there are two segments with the same size and offset,
but the first segment has a lower alignment. As things stand, this test will
fail because the segments are moved to immediately after the end of the program
header table, i.e. offset 0xB0, which violates the alignment requirements of
the PT_LOAD segment.
For reference, there is nothing in the gABI mandating that segments appear in a
specific order, except that PT_INTERP and PT_PHDR must appear before loadable
segments and loadable segments must appear in ascending address order.
Arguably, there is a wider issue here, namely that child segment alignments are
ignored. I'm not sure what the right behaviour is in cases where a clear child
segment has higher alignment requirements than the parent, so this is probably
a separate issue.
Aside: I couldn't get GNU objcopy to do something sensible with similar input
to the above. This might be a GNU objcopy bug though.
--
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 15623 in oss-fuzz: llvm: Build failure
Comment #13 on issue 15623 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15623#c13 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-33383357-e28d-4afc-a98f-31168968b419.txt -- 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 42964] New: Allow "-" as an alias for "-n integer"
https://bugs.llvm.org/show_bug.cgi?id=42964 Bug ID: 42964 Summary: Allow "-" as an alias for "-n integer" Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-strings Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org llvm-strings doesn't allow "-1", "-2" etc as aliases for "-n 1", "-n 2" etc, unlike GNU strings. We should add those aliases. Once this is fixed, we should show that cases like "-n -1" produce sensible behaviour. In this case, it should probably be rejected as -1 isn't a valid argument for -n, or because -n is missing an argument. -- 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 32939] [DAGCombine] Missed A + -2.0*B*C -> A - (B+B)*C
https://bugs.llvm.org/show_bug.cgi?id=32939 Sanjay Patel changed: What|Removed |Added Fixed By Commit(s)||r368490, r368512 Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Sanjay Patel --- This case should be fixed with: https://reviews.llvm.org/rL368490 https://reviews.llvm.org/rL368512 There are still holes in our reassociation strategy/implementation, so we may find examples similar to this that are not optimal yet. -- 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 42965] New: ExitValue rewrite in IndVarSimplify may introduce extra spills and instructions at no benefit
https://bugs.llvm.org/show_bug.cgi?id=42965 Bug ID: 42965 Summary: ExitValue rewrite in IndVarSimplify may introduce extra spills and instructions at no benefit Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: d.malju...@yandex.ru CC: llvm-bugs@lists.llvm.org Created attachment 22369 --> https://bugs.llvm.org/attachment.cgi?id=22369&action=edit C code showing the issue When there is a chain of calculations on some variable in a loop which is then used outside, IndVarSimplify may rewrite its exit value to be independent from loop adding index computations to the loop header. When the loop body is big enough (e.g. due to unswitching of nested loops), this increases register pressure and may lead to spills/reloads. The example can be seen here: https://godbolt.org/z/_wxzut (the code can also be found in the attachments). -- 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 42966] New: Regression(r365860) New fomit-frame-pointer / momit-leaf-frame-pointer handling leads to unfriendly diagnostics
https://bugs.llvm.org/show_bug.cgi?id=42966 Bug ID: 42966 Summary: Regression(r365860) New fomit-frame-pointer / momit-leaf-frame-pointer handling leads to unfriendly diagnostics Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: C Assignee: unassignedclangb...@nondot.org Reporter: nicolaswe...@gmx.de CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Say you want frame pointers but no leaf frame pointers (because you want to unwind, but including leaf frame pointers makes llvm run out of registers -- cf PR15798). So you pass -fno-omit-frame-pointer -momit-leaf-frame-pointer to all compiles. Some specific translation unit wants to omit frame pointers for some reason though, so it tacks on fomit-frame-pointer. Previously that worked fine. Now it results in clang: warning: argument unused during compilation: '-momit-leaf-frame-pointer' [-Wunused-command-line-argument] That's true, but it's also not helpful. There's no good way in practice to fix this warning if it arises in a situation like this. We should probably manually claim the momit flags if the fomit flags are seen. -- 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 16395 in oss-fuzz: llvm:llvm-isel-fuzzer--wasm32-O2: Unexpected-exit in llvm::LLVMContext::diagnose
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-08-12 Type: Bug New issue 16395 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--wasm32-O2: Unexpected-exit in llvm::LLVMContext::diagnose https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16395 Detailed report: https://oss-fuzz.com/testcase?key=5184059369586688 Project: llvm Fuzzing engine: libFuzzer Fuzz target: llvm-isel-fuzzer--wasm32-O2 Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Unexpected-exit Crash Address: Crash State: llvm::LLVMContext::diagnose llvm::WebAssemblyTargetLowering::LowerOperation SelectionDAGLegalize::LegalizeOp Sanitizer: memory (MSAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5184059369586688 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. -- 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 42967] New: sysv format does not print blank line between archive members
https://bugs.llvm.org/show_bug.cgi?id=42967 Bug ID: 42967 Summary: sysv format does not print blank line between archive members Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llvm-size Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: bigchees...@gmail.com, llvm-bugs@lists.llvm.org If llvm-size is used to print an archive, it does not print a blank line between archive members, unlike GNU size and also unlike its multiple input case: c:\llvm\build\debug\bin\llvm-size.exe -A archive.a archive.test.tmp1 (ex archive.a): section size addr .text 1 0 .data 2 0 .bss 4 0 Total 7 <--- Blank line should appear after here archive.test.tmp2 (ex archive.a): section size addr .text 8 0 .data 16 0 .bss 32 0 Total 56 -- 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 42968] New: Missed inlining causes significat slowdown (C-ray case study)
https://bugs.llvm.org/show_bug.cgi?id=42968 Bug ID: 42968 Summary: Missed inlining causes significat slowdown (C-ray case study) Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Interprocedural Optimizations Assignee: unassignedb...@nondot.org Reporter: david.bolvan...@gmail.com CC: llvm-bugs@lists.llvm.org This is case study for C-ray benchmark, but it is not so unrealistic for other real word code. In C-ray's hot loop there is a call to a quite big function 'ray_sphere'. Clang does not inline it, GCC does. GCC's code is much faster (see below). So in this case, Inliner should be enhanced with some sort of heuristic so it will realise that inlining of 'ray_sphere' is profitable since most of the calculations on ray are loop invariant and will be hoisted. Tested on Intel Haswell. 'make' - GCC 9 ./c-ray-mt -t 8 -s 800x400 -r 1 -i sphfract -o output.ppm c-ray-mt v1.1 Rendering took: 0 seconds (518 milliseconds) 'make' - Clang 9 ./c-ray-mt -t 8 -s 800x400 -r 1 -i sphfract -o output.ppm c-ray-mt v1.1 Rendering took: 0 seconds (609 milliseconds) Added __attribute((always_inline)) to ray_sphere: GCC 9: ./c-ray-mt -t 8 -s 800x400 -r 1 -i sphfract -o output.ppm c-ray-mt v1.1 Rendering took: 0 seconds (514 milliseconds) ./c-ray-mt -t 8 -s 800x400 -r 1 -i sphfract -o output.ppm c-ray-mt v1.1 Rendering took: 0 seconds (413 milliseconds) As we can see, a significant win: 609 -> 413 milliseconds There is also some haswell codegen issue, since with -march=haswell: Clang 9 ./c-ray-mt -t 8 -s 800x400 -r 1 -i sphfract -o output.ppm c-ray-mt v1.1 Rendering took: 0 seconds (403 milliseconds) GCC 9 ./c-ray-mt -t 8 -s 800x400 -r 1 -i sphfract -o output.ppm c-ray-mt v1.1 Rendering took: 0 seconds (371 milliseconds) -- 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 42969] New: LICM miscompiles simple loop nest (because of bad AA caching?)
https://bugs.llvm.org/show_bug.cgi?id=42969
Bug ID: 42969
Summary: LICM miscompiles simple loop nest (because of bad AA
caching?)
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: mattias.v.eriks...@ericsson.com
CC: llvm-bugs@lists.llvm.org
This program has a load and a store which may alias in the inner loop. foo.c:
#include
int a = 0;
int *b = &a;
int main() {
for (int i = 0; i < 19; ++i) {
for (int j = 0; j < 297; ++j) {
a = *b + 1;
}
}
printf("a = %d\n", a);
}
$ clang foo.c -O2 --target=i686-unknown-linux-gnu && ./a.out
a = 1
The correct value for a is 5643.
Using -opt-bisect-limit points to LICM:
clang foo.c -O2 --target=i686-unknown-linux-gnu -mllvm -opt-bisect-limit=84 &&
./a.out
...
BISECT: running pass (84) Loop Invariant Code Motion on loop
BISECT: NOT running pass (85) Loop Invariant Code Motion on loop
...
a = 5643
-print-after-all shows that the store to @a is moved out of the loop in LICM,
but the load via %0 remains inside (they may alias):
BEFORE:
for.body4:; preds =
%for.body4.preheader, %for.body4
%j.012 = phi i32 [ %inc, %for.body4 ], [ %j.012.ph, %for.body4.preheader ]
%5 = load i32, i32* %0, align 4, !tbaa !7
%add = add nsw i32 %5, 1
store i32 %add, i32* @a, align 4, !tbaa !7
%inc = add nuw nsw i32 %j.012, 1
%exitcond = icmp eq i32 %inc, 297
br i1 %exitcond, label %for.cond.cleanup3, label %for.body4, !llvm.loop !18
}
LICM: Promoting value stored to in loop: @a = dso_local global i32 0, align 4
AFTER:
for.body4:; preds =
%for.body4.preheader, %for.body4
%j.012 = phi i32 [ %inc, %for.body4 ], [ %j.012.ph, %for.body4.preheader ]
%5 = load i32, i32* %0, align 4, !tbaa !7
%add = add nsw i32 %5, 1
%inc = add nuw nsw i32 %j.012, 1
%exitcond = icmp eq i32 %inc, 297
br i1 %exitcond, label %for.cond.cleanup3, label %for.body4, !llvm.loop !16
for.cond.cleanup3:; preds = %for.body4
%add.lcssa17 = phi i32 [ %add, %for.body4 ]
%add.lcssa = phi i32 [ %add, %for.body4 ]
%inc6 = add nuw nsw i32 %i.013, 1
%exitcond14 = icmp eq i32 %inc6, 19
br i1 %exitcond14, label %for.cond.cleanup, label %vector.memcheck
; Exit blocks
for.cond.cleanup: ; preds = %for.cond.cleanup3
%add.lcssa16 = phi i32 [ %add.lcssa17, %for.cond.cleanup3 ]
%add.lcssa.lcssa = phi i32 [ %add.lcssa, %for.cond.cleanup3 ]
store i32 %add.lcssa16, i32* @a, align 4, !tbaa !7
%call = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([8 x
i8], [8 x i8]* @.str, i32 0, i32 0), i32 %add.lcssa.lcssa)
ret i32 0
I can't make a standalone run of "opt -licm" which does the faulty
transformation which makes me suspect that there is a bug in the caching in
Alias Set Tracker.
I experimented with using Memory SSA and this removes the problem:
$ clang -O2 foo.c --target=i686-unknown-linux-gnu -mllvm
-enable-mssa-loop-dependency=1 && ./a.out
a = 5643
Here is a Godbolt link: https://godbolt.org/z/0dYMZu
On Godbolt it miscompiles both on trunk and 8.0.0. Clang-7 works.
--
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 42968] Missed inlining causes significat slowdown (C-ray case study)
https://bugs.llvm.org/show_bug.cgi?id=42968 David Bolvansky changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from David Bolvansky --- *** This bug has been marked as a duplicate of bug 22657 *** -- 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 16385 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-O2: Container-overflow in MachineBlockPlacement::runOnMachineFunction
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 16385 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-O2: Container-overflow in MachineBlockPlacement::runOnMachineFunction https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16385#c1 ClusterFuzz testcase 5751823645802496 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201908110313:201908120313 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42970] New: Tidy up llvm-size's error messages
https://bugs.llvm.org/show_bug.cgi?id=42970 Bug ID: 42970 Summary: Tidy up llvm-size's error messages 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 A number of llvm-size's error messages leave a bit to be desired. For example, if you feed it an unrecognized binary, you get: c:\llvm\build\debug\bin\llvm-size.exe: C:\llvm\llvm\test\tools\llvm-size\invalid-input.test The file was not recognized as a valid object file If the input file does not exist: C:\llvm\build\Debug\bin\llvm-size.exe: blah.a no such file or directory Note that in both these cases, the file name is neither quoted nor separated from the error message body in any way, which makes the error message hard to read: C:\llvm\build\Debug\bin\llvm-size.exe: this file does not exist no such file or directory On a related note, llvm-size has a small block of code that looks to be reporting an error message for an unrecognized file: errs() << ToolName << ": " << file << ": " << "Unrecognized file type.\n"; However, in the first example above, it does not match the error message that comes out for this case. Probably better would be to say "unsupported file type" (an unrecognised one is one that the createBinary method doesn't know about, whilst an unsupported one is one it does know about, but llvm-size doesn't understand, e.g. minidumps). -- 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 42971] New: Missing file name for darwin output format with non-Mach-O
https://bugs.llvm.org/show_bug.cgi?id=42971 Bug ID: 42971 Summary: Missing file name for darwin output format with non-Mach-O Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llvm-size Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: bigchees...@gmail.com, llvm-bugs@lists.llvm.org llvm-size falls back to printing in Berkeley format, if --format=darwin is specified and a non-Mach-O object has been provided. However, it does not print the input filename when it should: Goid: C:\Work> C:\llvm\build\Debug\bin\llvm-size test.tmp textdata bss dec hex filename 1 2 4 7 7 test.tmp Bad: C:\Work> C:\llvm\build\Debug\bin\llvm-size test.tmp --format=darwin textdata bss dec hex filename 1 2 4 7 7 -- 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 42972] New: Declaration conflict between __clang_cuda_math_forward_declares.h and libstdc++
https://bugs.llvm.org/show_bug.cgi?id=42972 Bug ID: 42972 Summary: Declaration conflict between __clang_cuda_math_forward_declares.h and libstdc++ Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: CUDA Assignee: unassignedclangb...@nondot.org Reporter: jonathanchesterfi...@gmail.com CC: llvm-bugs@lists.llvm.org Tagged as cuda, but the problem may only reproduce from openmp. The abs definition introduced in https://reviews.llvm.org/D62046 breaks and when mixed with libstdc++ 7.4 and openmp, e.g. test.cpp: `#include ` ~/llvm-install/bin/clang++ -std=c++11 -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda -Xopenmp-target=nvptx64-nvidia-cuda -march=sm_50 -nocudalib -o test.x test.cpp abs returning a const value seems a bit weird, I don't follow the reasoning in the diff that makes this necessary. ``` In file included from /usr/lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/c++/7.4.0/algorithm:62: In file included from /usr/lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/c++/7.4.0/bits/stl_algo.h:59: In file included from /usr/lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/c++/7.4.0/cstdlib:77: /usr/lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/c++/7.4.0/bits/std_abs.h:70:3: error: declaration conflicts with target of using declaration already in scope abs(double __x) ^ /home/jon/llvm-install/lib/clang/10.0.0/include/__clang_cuda_math_forward_declares.h:50:25: note: target of using declaration __DEVICE__ const double abs(const double); ^ /usr/lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/c++/7.4.0/bits/std_abs.h:52:11: note: using declaration using ::abs; ^ /usr/lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/c++/7.4.0/bits/std_abs.h:74:3: error: declaration conflicts with target of using declaration already in scope abs(float __x) ^ /home/jon/llvm-install/lib/clang/10.0.0/include/__clang_cuda_math_forward_declares.h:51:24: note: target of using declaration __DEVICE__ const float abs(const float); ^ /usr/lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/c++/7.4.0/bits/std_abs.h:52:11: note: using declaration using ::abs; ^ 2 errors generated. ``` -- 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 42973] New: [WebAssembly] SIMD bit-shifts can remove unroll thanks to V8 fixes
https://bugs.llvm.org/show_bug.cgi?id=42973 Bug ID: 42973 Summary: [WebAssembly] SIMD bit-shifts can remove unroll thanks to V8 fixes Product: new-bugs Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: bvib...@wikimedia.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 22370 --> https://bugs.llvm.org/attachment.cgi?id=22370&action=edit Patch that removes this This bit in WebAssemblyTargetLowering::LowerShift - // Expand all vector shifts until V8 fixes its implementation - // TODO: remove this once V8 is fixed - if (!Subtarget->hasUnimplementedSIMD128()) -return unrollVectorShift(Op, DAG); can be removed since https://chromium-review.googlesource.com/c/v8/v8/+/1722198 fixed non-constant SIMD bit-shifts. This gives me a speedup of several percent in dav1d AV1 decoder on my WebAssembly SIMD branch running in Chrome Canary. Attached patch reapplies https://reviews.llvm.org/D58800 which was accidentally merged early a few months ago, then reverted. -- 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 42974] New: implement -ffixed-* for q* registers
https://bugs.llvm.org/show_bug.cgi?id=42974 Bug ID: 42974 Summary: implement -ffixed-* for q* registers Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: ndesaulni...@google.com CC: arnaud.degrandmai...@arm.com, llvm-bugs@lists.llvm.org, peter.sm...@linaro.org, ties.st...@arm.com For the aarch64 Linux kernel, we recently considered the use of -ffixed-* for q* (NEON SIMD) registers. [0] Currently, LLVM and Clang support -ffixed- for most x* registers [1], but not any q* registers. It's probably not too much work to implement this now in a similar fashion to the x* registers, especially now with the monorepo. [0] https://www.spinics.net/lists/linux-crypto/msg41373.html [1] see r342100 -- 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 41713] When using --format=sysv do not print blank types for unknown, processor-specific and OS-specific symbol types
https://bugs.llvm.org/show_bug.cgi?id=41713 Sunil Srivastava changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Sunil Srivastava --- The above patch was submitted as https://reviews.llvm.org/rL368451 -- 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 42936] SegFault with __builtin_bit_cast to templated type and auto return type
https://bugs.llvm.org/show_bug.cgi?id=42936 Erik Pilkington changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||r368600 Resolution|--- |FIXED --- Comment #2 from Erik Pilkington --- Fixed in 368600. -- 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 42976] New: Risc-V clang does not recognize floating point registers in inline asm
https://bugs.llvm.org/show_bug.cgi?id=42976 Bug ID: 42976 Summary: Risc-V clang does not recognize floating point registers in inline asm Product: new-bugs Version: 9.0 Hardware: Other OS: other Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: grog...@micron.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org clang/clang++ need to recognize floating point registers in inline asm's. -- 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 42977] New: Please warn on if constexpr (std::is_constant_evaluated())
https://bugs.llvm.org/show_bug.cgi?id=42977
Bug ID: 42977
Summary: Please warn on if constexpr
(std::is_constant_evaluated())
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: barry.rev...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
A very common user error with std::is_constant_evaluated is to write this:
#include
constexpr int foo(int i) {
if constexpr (std::is_constant_evaluated()) {
return 42;
} else {
return i;
}
}
That is, check if we're in the middle of constant evaluation with "if
constexpr" instead of plain "if". This is the intuitive check to do, but
unfortunately, since the condition here is manifestly constant evaluated, the
result of check is unconditionally true. clang implements this correctly - the
above function is exactly equivalent to "return 42;" - but that's unlikely to
be what the user intended the program to do. They likely intended to write:
constexpr int foo(int i) {
if (std::is_constant_evaluated()) {
return 42;
} else {
return i;
}
}
Can you please provide a warning for this erroneous usage?
(I filed the same bug report for gcc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428)
--
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 42978] New: Merge r368516 into 9.0
https://bugs.llvm.org/show_bug.cgi?id=42978
Bug ID: 42978
Summary: Merge r368516 into 9.0
Product: new-bugs
Version: 9.0
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: release blocker
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dimi...@andric.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Please merge https://reviews.llvm.org/rCRT368516 ("Add support for FreeBSD's
LD_32_LIBRARY_PATH") into the 9.0 branch. This ensures the 32-bit sanitizer
tests run correctly on 64-bit FreeBSD hosts.
--
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 42979] New: clang/test/Driver/modules.cpp fails when build directory contains '.s' in its name
https://bugs.llvm.org/show_bug.cgi?id=42979
Bug ID: 42979
Summary: clang/test/Driver/modules.cpp fails when build
directory contains '.s' in its name
Product: clang
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: tstel...@redhat.com
CC: douglas_y...@playstation.sony.com,
llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Blocks: 42474
For example, this check line:
// CHECK-COMPILE-SAME: -o {{.*}}.{{pcm.o|s}}
Will match:
-o
/builddir/build/BUILD/cfe-9.0.0rc1.src/_build/test/Driver/Output/modules.cpp.tmp/module.pcm.o
-x pcm /builddir/build/BUILD/cfe-9.0.0rc1.s
Which include the text that is supposed to match from the next check line:
// CHECK-COMPILE-SAME: -x pcm
So '-x pcm' never gets matched and the test fails.
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=42474
[Bug 42474] [meta] 9.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] [Bug 42980] New: Conditional explicit not respected with out-of-line definition
https://bugs.llvm.org/show_bug.cgi?id=42980
Bug ID: 42980
Summary: Conditional explicit not respected with out-of-line
definition
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: barry.rev...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Reduced from StackOverflow (https://stackoverflow.com/q/57467490/2069064):
using size_t = decltype(sizeof(0));
struct Str {
template
explicit(N > 7) Str(char const (&str)[N]);
};
#ifdef OUT_OF_LINE
template
Str::Str(char const(&str)[N]) { }
#endif
Str a = "short";
Str b = "not so short";
As-is, clang correctly rejects the construction of b (since that constructor is
explicit). But with -DOUT_OF_LINE, clang accepts.
--
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 42949] __builtin_constant_p lowering is inconsistent, producing false-negatives
https://bugs.llvm.org/show_bug.cgi?id=42949 George Burgess changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #2 from George Burgess --- So a huge hint at the reason we aren't doing better was sitting right in front of me when I was looking at r359844, yet I didn't see it. :) I agree that it's very likely that we don't want to do interprocedural analysis in the frontend to (partially) support this, so I'm marking this as WAI. Thank you! -- 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
