[llvm-bugs] [Bug 34664] New: variant uses "unsigned int" to store index, making it bigger than necessary
https://bugs.llvm.org/show_bug.cgi?id=34664 Bug ID: 34664 Summary: variant uses "unsigned int" to store index, making it bigger than necessary Product: libc++ Version: 5.0 Hardware: Macintosh OS: MacOS X Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: jonathan.sa...@gmx.de CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com In the following program, the size of "v" could be 2 (1 byte for the char, 1 byte for the index). Instead it is 8: #include using v = std::variant; static_assert(sizeof(v) == 8); This is because currently variant stores its index as an unsigned int even when a smaller type would suffice, wasting a fair amount of memory. variant should use the smallest possible integer type to store its index. -- 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 34001] One-line if statement problem
https://bugs.llvm.org/show_bug.cgi?id=34001 Adam Cieszkiel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Adam Cieszkiel --- Fixed with: https://reviews.llvm.org/rL312904 -- 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 34045] Regression(r309923): clang crashes compiling chrome/android
https://bugs.llvm.org/show_bug.cgi?id=34045 Roger Ferrer Ibanez changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #13 from Roger Ferrer Ibanez --- Should be fixed in r313618 -- 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 34512] ld.lld crash (SEGV) with --emit-relocs + --gc-sections
https://bugs.llvm.org/show_bug.cgi?id=34512 George Rimar changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from George Rimar --- r313620 -- 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 34506] lld -r corrupts comdat groups
https://bugs.llvm.org/show_bug.cgi?id=34506 George Rimar changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from George Rimar --- r313621 -- 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 34657] [skx][debug] debug clang fails with assertion on "X86 DAG->DAG Instruction Selection" after Loop Vectorization
https://bugs.llvm.org/show_bug.cgi?id=34657 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Simon Pilgrim --- *** This bug has been marked as a duplicate of bug 34653 *** -- 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 34665] New: [AVX] wrong answer after SLP Vectorizer
https://bugs.llvm.org/show_bug.cgi?id=34665
Bug ID: 34665
Summary: [AVX] wrong answer after SLP Vectorizer
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ilia.tara...@intel.com
CC: llvm-bugs@lists.llvm.org
This test gives wrong answer after SLP Vectorizer:
= nice.c ==
void init (unsigned int a [], unsigned int n)
{
unsigned int j = 0;
for (j = 0; j < n; j++)
a[j] = (45 + j);
}
int main ()
{
unsigned int i = 0, k = 0, j = 0, res = 0;
unsigned int z [64] = {0}, x [64] = {0};
init((unsigned int * )x, 64);
scanf(0);
for (i = 1; i < 6; ++i)
{
for (k = 9; k > 1; --k)
x[k] -= k;
for (j = 2; j < 10; ++j)
z[j] = x[j];
}
printf("res = %u\n", z[8]);
return 0;
}
>>> clang -v
clang version 6.0.0 (trunk 313612)
Target: x86_64-unknown-linux-gnu
Thread model: posix
...
>>> clang -march=skylake -O0 -o nice.exe nice.c
>>> ./nice.exe
res = 13
>>> clang -march=skylake -O2 -o nice.exe nice.c
>>> ./nice.exe
res = 5
If we look at generated asm, we'll see that after SLP vectorization
storage to ymm2 register is in wrong place, so it result gets an additional
subtraction:
= nice.s ==
...
callq scanf
vmovdqu 8(%rsp), %xmm0 # $rsp = [45, 46, 47, 48, 49, 50, 51,
52, 53, 54, ...]
vmovdqu 24(%rsp), %xmm1
vpextrd $3, %xmm1, %r8d
leal-9(%r8), %ecx
movl%ecx, 36(%rsp)
vpextrd $2, %xmm1, %r9d
leal-8(%r9), %edx
movl%edx, 32(%rsp)
vpextrd $1, %xmm1, %esi
leal-7(%rsi), %edx
movl%edx, 28(%rsp)
vpextrd $3, %xmm0, %edi
leal-5(%rdi), %edx
vmovdqu 8(%rsp), %ymm2 # $ymm2 = [47, 48, 49, 50, 51, 45, 45, 45]
...
vpaddd .LCPI1_12(%rip), %ymm2, %ymm0 # .LCPI1_12(%rip) =
[-10, -15, -20, -25, -30, -35, -40, -45]
vmovdqu %ymm0, 8(%rsp)# $rsp = [37, 33, 29, 25, 21,
10, 5, 0] - wrong answer
vmovups 8(%rsp), %ymm0 # right answer is [37, 33,
29, 25, 21, 17, 13, 9]
...
===
--
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 34666] New: improvement for several broadcast
https://bugs.llvm.org/show_bug.cgi?id=34666
Bug ID: 34666
Summary: improvement for several broadcast
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: jina.nah...@intel.com
CC: llvm-bugs@lists.llvm.org
for the following c example:
__m512i foo(__m512i __O, __mmask64 __M, char __A){
__m512i res= _mm512_mask_set1_epi8(__O, -1, __A);
__m512i res1= _mm512_mask_set1_epi8(__O, __M, __A);
__m512i res2= _mm512_maskz_set1_epi8( __M, __A);
__m512i res3= res+res1+res2;
return res3;
}
LLVM currently generates the following IR:
define <8 x i64> @foo(<8 x i64> %__O, i64 %__M, i8 signext %__A) {
%vecinit.i.i = insertelement <64 x i8> undef, i8 %__A, i32 0
%vecinit63.i.i = shufflevector <64 x i8> %vecinit.i.i, <64 x i8> undef, <64 x
i32> zeroinitializer
%0 = bitcast <64 x i8> %vecinit63.i.i to <8 x i64>
%1 = bitcast <8 x i64> %__O to <64 x i8>
%2 = bitcast i64 %__M to <64 x i1>
%3 = select <64 x i1> %2, <64 x i8> %vecinit63.i.i, <64 x i8> %1
%4 = bitcast <64 x i8> %3 to <8 x i64>
%5 = select <64 x i1> %2, <64 x i8> %vecinit63.i.i, <64 x i8> zeroinitializer
%6 = bitcast <64 x i8> %5 to <8 x i64>
%add = add <8 x i64> %4, %0
%add3 = add <8 x i64> %add, %6
ret <8 x i64> %add3
}
which gets translated to this assembly:
vpbroadcastb%esi, %zmm1
kmovq %rdi, %k1
vpbroadcastb%esi, %zmm0 {%k1}
vpaddq %zmm1, %zmm0, %zmm0
vpbroadcastb%esi, %zmm1 {%k1} {z}
vpaddq %zmm1, %zmm0, %zmm0
retq
if we could generate the following IR:
define <64 x i8> @foo(i8 %a, <64 x i8> %passthru, i64 %mask) {
%m = bitcast i64 %mask to <64 x i1>
%add0 = add i8 %a, %a
%add1 = add i8 %add0, %add0
%v0 = insertelement <64 x i8> undef, i8 %add1, i32 0
%v1 = shufflevector <64 x i8> %v0, <64 x i8> undef, <64 x i32>
zeroinitializer
%w0 = insertelement <64 x i8> undef, i8 %a, i32 0
%w1 = shufflevector <64 x i8> %w0, <64 x i8> undef, <64 x i32>
zeroinitializer
%add2 = add <64 x i8> %w1, %passthru
%v2 = select <64 x i1> %m, <64 x i8> %v1, <64 x i8> %add2
ret <64 x i8> %v2
}
we'll get this assembly:
kmovq %rsi, %k1
vpbroadcastb%edi, %zmm1
shlb$2, %dil
vpaddb %zmm0, %zmm1, %zmm0
vpbroadcastb%edi, %zmm0 {%k1}
which saves broadcast instructions
--
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 34667] New: clang-format crashes with blank assume-filename
https://bugs.llvm.org/show_bug.cgi?id=34667 Bug ID: 34667 Summary: clang-format crashes with blank assume-filename Product: clang Version: 4.0 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: mi...@werbitt.net CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Overview clang-format crashes when the assume-filename is given a blank string Steps to Reproduce clang-format -output-replacements-xml -assume-filename '' -offset 0 -length 10 -cursor 5 <<< ' = 1234;' Actual Results clang-format -output-replacements-xml -assume-filename '' -offset 0 -length 10 -cursor 5 <<< ' = 1234;' 0 clang-format 0x000106ba765b llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40 1 clang-format 0x000106ba6f93 llvm::sys::RunSignalHandlers() + 83 2 clang-format 0x000106ba7aaa SignalHandler(int) + 195 3 libsystem_platform.dylib 0x7fff8d04452a _sigtramp + 26 4 libsystem_platform.dylib 0x7fff59089ea0 _sigtramp + 3422837136 5 clang-format 0x000106bde825 clang::format::Environment::CreateVirtualEnvironment(llvm::StringRef, llvm::StringRef, llvm::ArrayRef) + 661 6 clang-format 0x000106bcc115 clang::format::reformat(clang::format::FormatStyle const&, llvm::StringRef, llvm::ArrayRef, llvm::StringRef, bool*) + 221 7 clang-format 0x000106b75892 clang::format::format(llvm::StringRef) + 3655 8 clang-format 0x000106b74880 main + 671 9 libdyld.dylib0x7fff93d4a5ad start + 1 zsh: segmentation fault clang-format -output-replacements-xml -assume-filename '' -offset 0 -length 1 Expected Results Should exit with error: No such file or directory Clang Format Version clang-format version 4.0.1 (tags/RELEASE_401/final) -- 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 34668] New: P0704R1 implementation is too permissive
https://bugs.llvm.org/show_bug.cgi?id=34668
Bug ID: 34668
Summary: P0704R1 implementation is too permissive
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: rs2...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
P0704R1 only permits pointers to const & member functions to be used with
rvalues (i.e., the cv-qualifier-seq must be exactly const). const volatile &
member functions aren't included, as only lvalue reference to non-volatile
const types can bind to rvalues.
Clang's current implementation only checks for the presence of const:
struct F {
void y() const volatile &;
};
using t = decltype((F().*&F::y)());
This shouldn't compile but does on Clang trunk.
--
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 34669] New: Provide -f-no-alias, opposite of -fno-strict-alias
https://bugs.llvm.org/show_bug.cgi?id=34669 Bug ID: 34669 Summary: Provide -f-no-alias, opposite of -fno-strict-alias Product: clang Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: a...@arvid.io CC: llvm-bugs@lists.llvm.org The '-fno-strict-alias' flag disables all alias semantics, which is useful for some applications where these would be violated. The opposite of this would be a useful addition, which would basically provide FORTRAN like aliasing semantics for C / C++, by adding an implicit 'restrict' to every pointer. -- 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 34670] New: -fsplit-stack omits .note.GNU-split-stack section marker
https://bugs.llvm.org/show_bug.cgi?id=34670
Bug ID: 34670
Summary: -fsplit-stack omits .note.GNU-split-stack section
marker
Product: libraries
Version: trunk
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: th...@google.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19172
--> https://bugs.llvm.org/attachment.cgi?id=19172&action=edit
tar file with repro sources
The implementation of "-fsplit-stack" in LLVM is missing a piece, specifically
marker/note section indicating whether the generated object file has been
compiled with -fsplit-stack. This marker is consumed by the gold linker, which
uses it to handle cases where there is call from a split-stack routine to a
non-split-stack routine. See https://gcc.gnu.org/wiki/SplitStacks in the
section on "Backward compatibility".
Example with gcc:
% gcc -fPIC -g -m64 -c mod1.c
% objdump -h mod1.o | fgrep split
% gcc -fPIC -g -m64 -c mod1.c -fsplit-stack
% objdump -h mod1.o | fgrep split 3 .note.GNU-split-stack
010d 2**0
%
Example with clang:
% clang -fPIC -g -m64 -c mod1.c
% objdump -h mod1.o | fgrep split
% clang -fPIC -g -m64 -c mod1.c -fsplit-stack
% objdump -h mod1.o | fgrep split
%
Programs built with "clang -fsplit-stack" will probably work in some cases, but
if there is a call from a split-stack routine to a non-split-stack routine (say
in a third party library), the callee will inherit the (smaller) stack segment
from the caller, meaning that it may wind up running out of stack space in that
scenario. With the marker present, the Gold linker will fix up the caller to
insure that it passes in a larger stack segment.
I'm attaching a zip file with a test case that illustrates. In this test there
is a main "test" program and two shared libraries, "mod1.so" and "mod2.so".
Functions in "mod1.so" are built with -fsplit-stack, whereas functions in
mod2.so are not compiled with that option. There is a call from mod1.so into
the function "mod2" in mod2.so, where 'mod2' winds up using ~50k worth of stack
space, which causes it to crash.
Reproduction instructions:
1. unpack tar file (contains main.c makefile mod1.c mod2.c mod.h).
2. run "make clean run CC=", inspect output.
Example run (amd64 linux) with clang:
% make clean run CC=clang
rm -f *.asm *.so *.o test
clang -fPIC -fsplit-stack -g -m64 -c mod1.c -o mod1.o
clang -fPIC -g -m64 -c mod2.c -o mod2.o
clang -shared -g -m64 mod2.o -o mod2.so
clang -shared -g -m64 mod1.o -o mod1.so mod2.so
clang -g -m64 -c main.c -o main.o
clang -fsplit-stack -g -m64 main.o mod1.so mod2.so -o test
LD_LIBRARY_PATH=`pwd` ./test 11
10 0 249
est space: 5984
make: *** [run] Segmentation fault (core dumped)
LD_LIBRARY_PATH=`pwd` ./test 101
make: *** [run] Segmentation fault (core dumped)
%
Example run (amd64 linux) with gcc:
% make clean run CC=gcc
rm -f *.asm *.so *.o test
gcc -fPIC -fsplit-stack -g -m64 -c mod1.c -o mod1.o
gcc -fPIC -g -m64 -c mod2.c -o mod2.o
gcc -shared -g -m64 mod2.o -o mod2.so
gcc -shared -g -m64 mod1.o -o mod1.so mod2.so
gcc -g -m64 -c main.c -o main.o
gcc -fsplit-stack -g -m64 main.o mod1.so mod2.so -o test
LD_LIBRARY_PATH=`pwd` ./test 11
10 0 249
est space: 5808
LD_LIBRARY_PATH=`pwd` ./test 101
100 90 80 70 60 50 40 30 20 10 0 147
est space: 53328
Note: the expectation is that the version of "ld" in $PATH points to the Gold
linker, not the BFD linker (since Gold has support for fixing up split to
nonsplit calls).
--
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 34217] [AVX] Compiler not folding per-element stores for 256-bit vectors into vmovups
https://bugs.llvm.org/show_bug.cgi?id=34217 Sanjay Patel changed: What|Removed |Added Fixed By Commit(s)||313564 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Sanjay Patel --- There's been a lot of bot chaos over the last day, but I'm assuming this change is ok (since it's really just restoring behavior that used to exist). So marking as resolved with: https://reviews.llvm.org/rL313564 -- 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 34671] New: Triple-prefixed clang symlink ignores -target flag
https://bugs.llvm.org/show_bug.cgi?id=34671 Bug ID: 34671 Summary: Triple-prefixed clang symlink ignores -target flag Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: arichardson@gmail.com CC: llvm-bugs@lists.llvm.org I recently merged the latest upstream changes into our fork of clang and noticed that clang now ignores the -target flag if it is invoked as *-*-*-clang: ./mips64-unknown-freebsd-clang -target x86_64-unknown-freebsd -### foo.c clang version 6.0.0 (https://github.com/llvm-mirror/clang.git e7476fadc94b87293e7192c419125cf446d454ce) (https://github.com/llvm-mirror/llvm.git f4b98addfb8646cf3aee4d3f6f498febbc54d99d) Target: mips64-unknown-freebsd Thread model: posix InstalledDir: /local/scratch/alr48/cheri/build/upstream-llvm-build/bin/. "/local/scratch/alr48/cheri/build/upstream-llvm-build/bin/clang-6.0" "-cc1" "-triple" "mips64-unknown-freebsd" "-S" "-disable-free" "-main-file-name" "foo.c" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim" "-no-integrated-as" "-mconstructor-aliases" "-target-cpu" "mips64r2" "-target-feature" "-noabicalls" "-target-abi" "n64" "-mfloat-abi" "hard" "-dwarf-column-info" "-debugger-tuning=gdb" "-resource-dir" "/local/scratch/alr48/cheri/build/upstream-llvm-build/lib/clang/6.0.0" "-fno-dwarf-directory-asm" "-fdebug-compilation-dir" "/local/scratch/alr48/cheri/build/upstream-llvm-build/bin" "-ferror-limit" "19" "-fmessage-length" "105" "-fobjc-runtime=gnustep" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "/tmp/foo-2eb666.s" "-x" "c" "foo.c" "/usr/bin/as" "-march" "mips64r2" "-mabi" "64" "-EB" "-KPIC" "-o" "/tmp/foo-740c51.o" "/tmp/foo-2eb666.s" "/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "--enable-new-dtags" "-o" "a.out" "crt1.o" "crti.o" "crtbegin.o" "-L/usr/lib" "/tmp/foo-740c51.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "crtend.o" "crtn.o" I would expect this to target x86_64 and not mips64. -- 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 34672] New: Verifier accepts broken DIGlobalVariable
https://bugs.llvm.org/show_bug.cgi?id=34672
Bug ID: 34672
Summary: Verifier accepts broken DIGlobalVariable
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: apra...@apple.com
CC: llvm-bugs@lists.llvm.org
The Verifier accepts the following IR because we only visit DIGlobalVariables
when they are listed in the DICompileUnit, and never from a
DIGlobalVariableExpression.
@global = common global i32 0, align 4, !dbg !2
!llvm.dbg.cu = !{!0}
!llvm.module.flags = !{!5, !6}
!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer:
"adrian", emissionKind: FullDebug)
!1 = !DIFile(filename: "broken.c", directory: "/")
!2 = !DIGlobalVariableExpression(var: !3, expr: !DIExpression())
!3 = !DIGlobalVariable(name: "g", scope: !0, file: !1, line: 1, type: !1,
isLocal: false, isDefinition: true)
; ERROR
!5 = !{i32 2, !"Dwarf Version", i32 4}
!6 = !{i32 1, !"Debug Info Version", i32 3}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34057] LLD inserts global symbols into dynamic symbol table for executable
https://bugs.llvm.org/show_bug.cgi?id=34057 Rafael Ávila de Espíndola changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #7 from Rafael Ávila de Espíndola --- OK, lets leave the current behavior as is and see if anyone is depending on --dynamic-list having a different meaning for executables. -- 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 34637] Correctly output file checksums in hex form
https://bugs.llvm.org/show_bug.cgi?id=34637 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Reid Kleckner --- Re-landed with a fix in r313657 -- 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 34673] New: function creation crash in getContext()
https://bugs.llvm.org/show_bug.cgi?id=34673
Bug ID: 34673
Summary: function creation crash in getContext()
Product: libraries
Version: 5.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Core LLVM classes
Assignee: unassignedb...@nondot.org
Reporter: guilla...@morinfr.org
CC: llvm-bugs@lists.llvm.org
Created attachment 19174
--> https://bugs.llvm.org/attachment.cgi?id=19174&action=edit
testcase
This simple code worked just fine with llvm 4.0. It crashes with llvm 5.0. I
am really sorry if this is an issue with the code but can't see anything wrong:
$ cat llvm5_bug.cpp
#include
#include
#include
#include
#include
int main(void)
{
llvm::LLVMContext globalCtx;
std::unique_ptr module(new llvm::Module("m", globalCtx));
llvm::Type* argType = llvm::IntegerType::get(globalCtx, 8 * sizeof(short));
llvm::Type* retType = llvm::IntegerType::get(globalCtx, 8 * sizeof(long));
std::string name("funcName");
llvm::Constant* c = module->getOrInsertFunction(name, retType, argType,
nullptr);
llvm::Function* func = llvm::cast(c);
func->arg_begin(); // crashes in here with llvm 5.0
return 0;
}
$ g++-7 -Wall $(llvm-config-5.0 --libs --cflags) -o c llvm5_bug.cpp
$ ./c
Segmentation fault (core dumped)
Backtrace:
0x751408b3 in llvm::Value::getContext() const () at
/build/llvm-toolchain-5.0-5.0/lib/IR/Value.cpp:697
697 /build/llvm-toolchain-5.0-5.0/lib/IR/Value.cpp: No such file or
directory.
(gdb) bt
#0 0x751408b3 in llvm::Value::getContext() const () at
/build/llvm-toolchain-5.0-5.0/lib/IR/Value.cpp:697
#1 0x7514112c in llvm::Value::setNameImpl(llvm::Twine const&) () at
/build/llvm-toolchain-5.0-5.0/lib/IR/Value.cpp:229
#2 0x751413a9 in llvm::Value::setName(llvm::Twine const&) () at
/build/llvm-toolchain-5.0-5.0/lib/IR/Value.cpp:285
#3 0x750c91ea in llvm::Function::BuildLazyArguments() const () at
/build/llvm-toolchain-5.0-5.0/lib/IR/Function.cpp:257
#4 0x00400d55 in llvm::Function::CheckLazyArguments (this=) at /usr/lib/llvm-5.0/include/llvm/IR/Function.h:109
#5 llvm::Function::arg_begin (this=) at
/usr/lib/llvm-5.0/include/llvm/IR/Function.h:596
#6 main () at llvm5_bug.cpp:20
--
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 34674] New: aarch64 codegen emits add x28, xzr, #1 not accepted by gnu assembler
https://bugs.llvm.org/show_bug.cgi?id=34674
Bug ID: 34674
Summary: aarch64 codegen emits add x28,xzr,#1 not accepted by
gnu assembler
Product: clang
Version: 5.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: raj.k...@gmail.com
CC: llvm-bugs@lists.llvm.org
I have a testcase https://uclibc.org/~kraj/a.cpp
Which fails to compile/assemble when using -no-integrated-as on aarch64, but it
works
ok when using -integrated-as
clang -target aarch64-linux-gnu a.cpp -O2 -c -std=gnu++11
works
but
clang -target aarch64-linux-gnu a.cpp -O2 -c -std=gnu++11 -no-integrated-as
throws
/tmp/tmp.ZfaD5q6lwY/a-8fa1ba.s:25688: Error: integer register expected in the
extended/shifted operand register at operand 3 -- `add x28,xzr,#1'
/tmp/tmp.ZfaD5q6lwY/a-8fa1ba.s:25717: Error: integer register expected in the
extended/shifted operand register at operand 3 -- `add x1,xzr,#1'
/tmp/tmp.ZfaD5q6lwY/a-8fa1ba.s:25718: Error: integer register expected in the
extended/shifted operand register at operand 3 -- `add x2,xzr,#1'
I then created .s file output with and without integrated-as and in both cases
I do see above instructions in assmebly file.
I thought it might be a problem only with GNU as so I created a small test case
like this
int foo() {
asm("add x28,xzr,#1") ;
return 0;
}
and now when I compile it, I get errors with both GNU and internal asm
So it does seem that instruction is not accepted by both assemblers but when
using internal assembler and not generating .s files these instructions might
be getting optimized out ?
I think some aarch64 expertise help is needed.
--
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 34675] New: Crash in TwoAddressInstructions
https://bugs.llvm.org/show_bug.cgi?id=34675
Bug ID: 34675
Summary: Crash in TwoAddressInstructions
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: dav...@freebsd.org
CC: dmitry.miku...@sony.com, llvm-bugs@lists.llvm.org,
simon.f.whitta...@gmail.com
$ cat rel.ll
target triple = "aarch64--linux-gnu"
%class.b = type { [0 x %"struct.b::B"] }
%"struct.b::B" = type { i32 }
define void @_ZN1b1jEv(%class.b* %this) local_unnamed_addr #0 align 2 {
%a.sroa.0.0..sroa_idx = getelementptr inbounds %class.b, %class.b* %this, i64
0, i32 0, i64 0, i32 0
%a.sroa.0.0.copyload = load i32, i32* %a.sroa.0.0..sroa_idx, align 4
%call = tail call i32 @_ZN1b1eEv(%class.b* %this)
%conv = sext i32 %a.sroa.0.0.copyload to i64
%patatino = inttoptr i64 %conv to i8*
tail call void @llvm.memset.p0i8.i64(i8* %patatino, i8 0, i64 16, i32 4, i1
false)
%meh = inttoptr i64 %conv to i64*
%bf.load = load i64, i64* %meh, align 4
%bf.clear = and i64 %bf.load, -17592186044416
%bf.set = or i64 %bf.clear, 86
store i64 %bf.set, i64* %meh, align 4
ret void
}
declare i32 @_ZN1b1eEv(%class.b*) local_unnamed_addr #1
declare void @llvm.memset.p0i8.i64(i8* nocapture writeonly, i8, i64, i32, i1)
#2
$ ./llc rel.ll
llc: ../lib/CodeGen/TwoAddressInstructionPass.cpp:1244: bool
{anonymous}::TwoAddressInstructionPass::tryInstructionTransform(llvm::MachineBasicBlock::iterator&,
llvm::MachineBasicBlock::iterator&, unsigned int, unsigned int, unsigned int,
bool): Assertion `TargetRegisterInfo::isVirtualRegister(regB) && "cannot make
instruction into two-address form"' failed.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34676] New: check-lldb target fails on Windows due to incomplete compiler path
https://bugs.llvm.org/show_bug.cgi?id=34676 Bug ID: 34676 Summary: check-lldb target fails on Windows due to incomplete compiler path Product: lldb Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: amcca...@google.com CC: llvm-bugs@lists.llvm.org `ninja check-lldb` fails when it attempts this command: ``` cmd.exe /C "cd /D D:\src\llvm\build\mono\tools\lldb\test && C:\python_35\python_d.exe D:/src/llvm/mono/llvm-project/lldb/test/dotest.py --no-multiprocess --arch=i686 --executable D:/src/llvm/build/mono/bin/lldb.exe -s D:/src/llvm/build/mono/lldb-test-traces -S nm -u CXXFLAGS -u CFLAGS -C D:\src\llvm\build\ninja_release\bin --rerun-all-issues --enable-crash-dialog" ``` The problem is that the `-C` option is specifying a directory rather than a full path to the clang executable. -- 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 34677] New: assembly: unrecognized token in .rept directive
https://bugs.llvm.org/show_bug.cgi?id=34677 Bug ID: 34677 Summary: assembly: unrecognized token in .rept directive Product: clang Version: 5.0 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: ndesaulni...@google.com CC: kristof.be...@gmail.com, llvm-bugs@lists.llvm.org, pir...@google.com, srhi...@google.com Created attachment 19175 --> https://bugs.llvm.org/attachment.cgi?id=19175&action=edit test case Clang's assembler seems to have an issue with the use of `b` suffixes on labels (at least that's what I think they are). Attached is a paired down test case that seems to reproduce the issue. The full code I'm trying to assemble is the Linux kernel. The source file affected is: http://elixir.free-electrons.com/linux/latest/source/arch/arm64/include/asm/alternative.h -- 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 34678] New: #include sorting should have a case-insensitive option
https://bugs.llvm.org/show_bug.cgi?id=34678 Bug ID: 34678 Summary: #include sorting should have a case-insensitive option Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: jordan_r...@apple.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org The Swift project has headers in folders called "SIL" and "Sema". clang-format currently sorts these includes as #include "swift/SIL/SILModule.h" #include "swift/Sema/IDETypeChecking.h" But we'd prefer a case-insensitive sort. -- 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 34679] New: Option to sort #includes with fewer components before those with more
https://bugs.llvm.org/show_bug.cgi?id=34679 Bug ID: 34679 Summary: Option to sort #includes with fewer components before those with more Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: jordan_r...@apple.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Some projects have "top-level" headers and "detail" headers, and in these cases it usually makes sense to sort the top-level headers first, rather than mixing them in with the other headers: #include "swift/Subsystems.h" #include "swift/AST/Decl.h" #include "swift/Syntax/Format.h" The rule here is to sort headers with fewer components before those with more, though possibly with an exception for headers with *zero* directory components. -- 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 32352] Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled
https://bugs.llvm.org/show_bug.cgi?id=32352 Adam Nemet changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Adam Nemet --- Vivek fixed this in r313382. Thanks Vivek! -- 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 3434 in oss-fuzz: llvm: Heap-buffer-overflow in llvm::DataExtractor::getUnsigned
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2017-09-20 New issue 3434 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm: Heap-buffer-overflow in llvm::DataExtractor::getUnsigned https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3434 Detailed report: https://oss-fuzz.com/testcase?key=476053592832 Project: llvm Fuzzer: libFuzzer_llvm_llvm-dwarfdump-fuzzer Fuzz target binary: llvm-dwarfdump-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Heap-buffer-overflow READ 4 Crash Address: 0x610002f6 Crash State: llvm::DataExtractor::getUnsigned llvm::FrameEntry::parseInstructions llvm::DWARFDebugFrame::parse Sanitizer: address (ASAN) Recommended Security Severity: Medium Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201708280446:201708291805 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=476053592832 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
[llvm-bugs] [Bug 34680] New: clang crashes at -Os with polly: Use still stuck around after Def is destroyed.
https://bugs.llvm.org/show_bug.cgi?id=34680 Bug ID: 34680 Summary: clang crashes at -Os with polly: Use still stuck around after Def is destroyed. Product: Polly Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Optimizer Assignee: polly-...@googlegroups.com Reporter: helloqi...@gmail.com CC: llvm-bugs@lists.llvm.org $ clang-trunk -v clang version 6.0.0 (trunk 313617) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/bin $ clang-trunk -mllvm -polly abc.c -m32 -Os While deleting: i16 %bf.clear Use still stuck around after Def is destroyed: store i16 %bf.clear, i16* getelementptr inbounds (%struct.anon, %struct.anon* @b, i32 0, i32 0), align 4 clang-6.0: /home/absozero/trunk/llvm/lib/IR/Value.cpp:86: llvm::Value::~Value(): Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed. #0 0x0201f67a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x201f67a) #1 0x0201d51e llvm::sys::RunSignalHandlers() (/home/absozero/trunk/root-clang/bin/clang-6.0+0x201d51e) #2 0x0201d672 SignalHandler(int) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x201d672) #3 0x7fd45ad4c330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #4 0x7fd4598c9c37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7fd4598cd028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7fd4598c2bf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 #7 0x7fd4598c2ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #8 0x01bad5db (/home/absozero/trunk/root-clang/bin/clang-6.0+0x1bad5db) #9 0x01bad630 llvm::Value::deleteValue() (/home/absozero/trunk/root-clang/bin/clang-6.0+0x1bad630) #10 0x01abcaec llvm::BasicBlock::~BasicBlock() (/home/absozero/trunk/root-clang/bin/clang-6.0+0x1abcaec) #11 0x0208b863 llvm::removeUnreachableBlocks(llvm::Function&, llvm::LazyValueInfo*) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x208b863) #12 0x01f7a70b (anonymous namespace)::BaseCFGSimplifyPass::runOnFunction(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x1f7a70b) #13 0x01b713f3 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x1b713f3) #14 0x01b71589 llvm::legacy::FunctionPassManagerImpl::run(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x1b71589) #15 0x01b71cdf llvm::legacy::FunctionPassManager::run(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x1b71cdf) #16 0x01b713f3 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x1b713f3) #17 0x01b714bc llvm::FPPassManager::runOnModule(llvm::Module&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x1b714bc) #18 0x01b70f8d llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x1b70f8d) #19 0x021c8c86 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x21c8c86) #20 0x029d0d27 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x29d0d27) #21 0x02baca18 clang::ParseAST(clang::Sema&, bool, bool) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x2baca18) #22 0x029d00dc clang::CodeGenAction::ExecuteAction() (/home/absozero/trunk/root-clang/bin/clang-6.0+0x29d00dc) #23 0x0257354e clang::FrontendAction::Execute() (/home/absozero/trunk/root-clang/bin/clang-6.0+0x257354e) #24 0x02542d06 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x2542d06) #25 0x02605cf3 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x2605cf3) #26 0x00a3bb48 cc1_main(llvm::ArrayRef, char const*, void*) (/home/absozero/trunk/root-clang/bin/clang-6.0+0xa3bb48) #27 0x009bb811 main (/home/absozero/trunk/root-clang/bin/clang-6.0+0x9bb811) #28 0x7fd4598b4f45 __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:321:0 #29 0x00a38059 _start (/home/absozero/trunk/root-clang/bin/clang-6.0+0xa38059) Stack dump: 0. Program arguments: /home/absozero/trunk/root-clang/bin/clang-6.0 -cc1 -triple i386-unknown-linux-gnu -emit-obj -disable-free -main-file-name abc.c -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbos
[llvm-bugs] [Bug 34681] New: [LV/LAA] Vectorizer creates a dead vectorized loop body when specializing for stride=1
https://bugs.llvm.org/show_bug.cgi?id=34681
Bug ID: 34681
Summary: [LV/LAA] Vectorizer creates a dead vectorized loop
body when specializing for stride=1
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: dorit.nuz...@intel.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19177
--> https://bugs.llvm.org/attachment.cgi?id=19177&action=edit
patch for a fix
Consider the following testcase:
void matmul(unsigned int N, int *C, int *A, int *B) {
unsigned int i,j,k;
for (i=0; i=
VF, that is if N > 1.
The two conditions cannot co-exist, so the vectorized loop body becomes dead
code. (Eventually this dead code is identified and gets removed).
It would have been better to avoid specialization for the stride if we know
that the stride==1 predicate is going to contradict the
loop-minimum-iteration-count guard.
The attached patch does that, and works for the simple case at hand.
I'll upload for review after further testing. Hopefully it's of interest...
(haven't seen any performance gains with it so far).
--
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
