[llvm-bugs] [Bug 37468] New: infinite loop on newest clang when running scan-build on FreeBSD
https://bugs.llvm.org/show_bug.cgi?id=37468 Bug ID: 37468 Summary: infinite loop on newest clang when running scan-build on FreeBSD Product: clang Version: trunk Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: dcough...@apple.com Reporter: uspoerl...@gmail.com CC: llvm-bugs@lists.llvm.org Hey, I'm doing weekly runs of trunk clang's scan-build against HEAD FreeBSD src tree, and as of a few weeks ago, these runs overrun, because one clang instance is apparently entering an infinite loop and spinning at 100% cpu. It's hard to tell from my logs, but it seems that this regression was introduced between 2018-04-08 and 2018-04-15 (the former finished in 8h, the latter got killed after 1 week) environment: % ps auxwwe `pgrep clang` USER PID %CPU %MEMVSZ RSS TT STAT STARTED TIME COMMAND uqs 66188 100.0 0.2 134320 70916 - R22:56 665:43.33 LINKER_FEATURES.6b3066d4= build-id ifunc filter retpoline _REVISION=12.0 OSRELDATE=1101001 X_COMPILER_TYPE.1112b595=clang CPP=/usr/obj/data/src/freebsd-head/amd64.amd64/tmp/usr/bin/cpp -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/data/src/freebsd-head/amd64.amd64/tmp -B/usr/obj/data/src/freebsd-head/amd64.amd64/tmp/usr/bin LOGNAME=uqs CCC_ANALYZER_OUTPUT_FORMAT=html COMPILER_FREEBSD_VERSION.fa77c583=1200014 LINKER_FEATURES.f0066807= filter COMPILER_VERSION.62dd7b6f=6 CCC_CC=/usr/obj/data/src/freebsd-head/amd64.amd64/tmp/usr/bin/cc MAKELEVEL=3 COMPILER_TYPE.f71a526c=clang CLANG_CXX=/data/src/llvm_build/bin/clang++ CC=/data/src/llvm_build/bin/../libexec/ccc-analyzer CROSS_COMPILER_PREFIX=/usr/obj/data/src/freebsd-head/amd64.amd64/tmp/usr/bin/ KERNEL=kernel RANLIB=ranlib SRCTOP=/data/src/freebsd-head META_MODE=normal MACHINE=amd64 LINKER_TYPE.6b3066d4=lld MAKEFLAGS= -j 8 -m /data/src/freebsd-head/share/mk -D WITHOUT_PROFILE -D MODULES_WITH_WORLD -D WITHOUT_CLANG -D WITHOUT_LLVM -D NO_MODULES -D NO_CLEAN -k -i -J 15,16 -m /data/src/freebsd-head/share/mk -j 8 -m /data/src/freebsd-head/share/mk -D WITHOUT_PROFILE -D MODULES_WITH_WORLD -D WITHOUT_CLANG -D WITHOUT_LLVM -D NO_MODULES -D NO_CLEAN -k -i -J 15,16 -m /data/src/freebsd-head/share/mk -D NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL CC=/data/src/llvm_build/bin/../libexec/ccc-analyzer COMPILER_TYPE=clang CROSS_COMPILER_PREFIX=/usr/obj/data/src/freebsd-head/amd64.amd64/tmp/usr/bin/ CXX=/data/src/llvm_build/bin/../libexec/c++-analyzer KERNCONF=LINT KERNEL=kernel TARGET=amd64 TARGET_ARCH=amd64 X_COMPILER_TYPE=clang __MAKE_CONF=/dev/null PATH=/usr/obj/data/src/freebsd-head/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/data/src/freebsd-head/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/data/src/freebsd-head/amd64.amd64/tmp/legacy/bin:/usr/obj/data/src/freebsd-head/amd64.amd64/tmp/usr/sbin:/usr/obj/data/src/freebsd-head/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin X_COMPILER_FREEBSD_VERSION.1112b595=unknown MAKE_CMD=make OBJROOT=/usr/obj/data/src/freebsd-head/ _B argv: % ps auxww `pgrep clang` USER PID %CPU %MEMVSZ RSS TT STAT STARTED TIME COMMAND uqs 66188 100.0 0.2 134320 70916 - R22:56 666:02.00 /data/src/llvm_build/bin/clang-6.0 -cc1 -triple x86_64-unknown-freebsd11.1 -analyze -disable-free -disable-llvm-verifier -discard-value-names -main-file-name vxgehal-mgmtaux.c -analyzer-store=region -analyzer-opt-analyze-nested-blocks -analyzer-eagerly-assume -analyzer-checker=core -analyzer-checker=apiModeling -analyzer-checker=unix -analyzer-checker=deadcode -analyzer-checker=security.insecureAPI.UncheckedReturn -analyzer-checker=security.insecureAPI.getpw -analyzer-checker=security.insecureAPI.gets -analyzer-checker=security.insecureAPI.mktemp -analyzer-checker=security.insecureAPI.mkstemp -analyzer-checker=security.insecureAPI.vfork -analyzer-checker=nullability.NullPassedToNonnull -analyzer-checker=nullability.NullReturnedFromNonnull -analyzer-output plist -w -mrelocation-model static -mthread-model posix -mdisable-fp-elim -relaxed-aliasing -masm-verbose -mconstructor-aliases -ffreestanding -mcode-model kernel -target-cpu x86-64 -target-feature -mmx -target-feature -sse -target-feature -aes -target-feature -avx -disable-red-zone -no-implicit-float -dwarf-column-info -debugger-tuning=gdb -nostdsysteminc -nobuiltininc -resource-dir /data/src/llvm_build/lib/clang/7.0.0 -include opt_global.h -I . -I /data/src/freebsd-head/sys -I /data/src/freebsd-head/sys/contrib/ck/include -I /data/src/freebsd-head/sys/contrib/libfdt -D _KERNEL -D HAVE_KERNEL_OPTION_HEADERS -D GPROF -D GPROF4 -D GUPROF -O2 -Wno-pointer-sign -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -fdebug-compilation-dir /usr/obj/data/src/freebsd-head/amd64.amd64/sys/LINT -ferr
[llvm-bugs] [Bug 37469] New: A miscompilation bug with unsigned char
https://bugs.llvm.org/show_bug.cgi?id=37469
Bug ID: 37469
Summary: A miscompilation bug with unsigned char
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: juneyoung@sf.snu.ac.kr
CC: llvm-bugs@lists.llvm.org
Created attachment 20304
--> https://bugs.llvm.org/attachment.cgi?id=20304&action=edit
A source file that raises the bug.
```
$ cat test-main.c
#include
#include
#include
// If f(A, B + 4) is given, and integer representation of A and B + 4
// are the same, c1 == c2 in the loop becomes true,
// so arr3 = arr1. Hence r = A, and *A should be 10.
// However, if compiled with -O3, *A is still 1.
void store_10_to_p(int *p, int *q) {
unsigned char arr1[8];
unsigned char arr2[8];
unsigned char arr3[8];
// Type punning with char* is allowed.
memcpy((unsigned char*)arr1, (unsigned char *)&p, sizeof(p));
memcpy((unsigned char*)arr2, (unsigned char *)&q, sizeof(q));
// Now arr1 is p, arr2 is q.
for (int i = 0; i < sizeof(q); i++) {
int c1 = (int)arr1[i], c2 = (int)arr2[i];
// Note that c1 == c2 is a comparison between _integers_ (not pointers).
if (c1 == c2)
// Always true if p and q have same integer representation.
arr3[i] = arr1[i];
else
arr3[i] = arr2[i];
}
// Now arr3 is equivalent to arr1, which is p.
int *r;
memcpy(&r, (unsigned char *)arr3, sizeof(r));
// Now r is p.
*p = 1;
*r = 10;
}
int main() {
int A[4], B[4];
printf("%p %p\n", A, &B[4]);
if ((uintptr_t)A == (uintptr_t)&B[4]) {
store_10_to_p(A, &B[4]);
printf("%d\n", A[0]);
}
return 0;
}
$ clang -O3 -o test-main test-main.c
$ ./test-main
0x7fffe580 0x7fffe580
1
$ clang -O0 -o test-main test-main.c
$ ./test-main
0x7fffe580 0x7fffe580
10
```
This is what is happening inside LLVM:
(1) Instcombine changes the loop body to "arr3[i] = arr2[i];"
(2) Loop idiom recognizer replaces the loop with a "memcpy(arr3, arr2, 8)"
(3) Instcombine does the store forwarding from the memcpy to the load
I think this is related with lowering 'unsigned char' in C into 'i8' in LLVM.
There are two choices:
(1) Lowering 'unsigned char' into 'i8' is correct.
(2) Lowering 'unsigned char' into 'i8' is incorrect.
If (1) is right, then one of the optimizations happening in this example should
be disabled, to stop the miscompilation.
If (2) is right, then it is clang which miscompiles this example. 'unsigned
char' should be lowered into something else.
--
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 37470] New: DW_AT_name for DW_TAG_label removes one leading underscore from the symbol name
https://bugs.llvm.org/show_bug.cgi?id=37470 Bug ID: 37470 Summary: DW_AT_name for DW_TAG_label removes one leading underscore from the symbol name Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: MC Assignee: unassignedb...@nondot.org Reporter: dimi...@google.com CC: llvm-bugs@lists.llvm.org This is kind of confusing because there is no way to say when it was removed. Also I was trying to find if it should be removed and it does not seem there is anything saying that. Here is the resulted dwarf for bionic _exit.S file: $ readelf -wai out/soong/.intermediates/bionic/libc/libc_syscalls/android_arm_armv8-a_cortex-a73_core_static/obj/bionic/libc/arch-arm/syscalls/_exit.o Contents of the .debug_info section: Compilation Unit @ offset 0x0: Length:0x168 (32-bit) Version: 4 Abbrev Offset: 0x0 Pointer Size: 4 <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : 0x0 <10> DW_AT_low_pc : 0x0 <14> DW_AT_high_pc : 0x20 <18> DW_AT_name: bionic/libc/arch-arm/syscalls/_exit.S <3e> DW_AT_comp_dir: /proc/self/cwd <4d> DW_AT_producer: Android (4679922 based on r326829) clang version 7.0.1 (https://android.googlesource.com/toolchain/clang 32fb8450f65708b63c9a35046b2d1ee775e08733) (https://android.googlesource.com/toolchain/llvm 67f3e6a51d93777841e0fb6d07f71fdf343df239) (based on LLVM 7.0.1svn) <154> DW_AT_language: 32769 (MIPS assembler) <1><156>: Abbrev Number: 2 (DW_TAG_label) <157> DW_AT_name: exit <15c> DW_AT_decl_file : 0x1 <160> DW_AT_decl_line : 0x14 <164> DW_AT_low_pc : 0x0 <168> DW_AT_prototyped : 0 <2><169>: Abbrev Number: 3 (DW_TAG_unspecified_parameters) <2><16a>: Abbrev Number: 0 <1><16b>: Abbrev Number: 0 Contents of the .debug_abbrev section: Number TAG (0x0) 1 DW_TAG_compile_unit[has children] DW_AT_stmt_listDW_FORM_sec_offset DW_AT_low_pc DW_FORM_addr DW_AT_high_pc DW_FORM_addr DW_AT_name DW_FORM_string DW_AT_comp_dir DW_FORM_string DW_AT_producer DW_FORM_string DW_AT_language DW_FORM_data2 DW_AT value: 0 DW_FORM value: 0 2 DW_TAG_label[has children] DW_AT_name DW_FORM_string DW_AT_decl_fileDW_FORM_data4 DW_AT_decl_lineDW_FORM_data4 DW_AT_low_pc DW_FORM_addr DW_AT_prototyped DW_FORM_flag DW_AT value: 0 DW_FORM value: 0 3 DW_TAG_unspecified_parameters[no children] DW_AT value: 0 DW_FORM value: 0 The expected DW_AT_name here is "_exit" because this is the name used for the exported symbol. -- 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 6490 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_predication: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-loop_predication
Updates: Labels: Deadline-Approaching Comment #2 on issue 6490 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-loop_predication: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-loop_predication https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6490#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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37471] New: Merge r332342 into the 6.0 branch : [MergeFunctions] Fix merging of small weak functions
https://bugs.llvm.org/show_bug.cgi?id=37471 Bug ID: 37471 Summary: Merge r332342 into the 6.0 branch : [MergeFunctions] Fix merging of small weak functions Product: new-bugs Version: 6.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tstel...@redhat.com CC: llvm-bugs@lists.llvm.org Blocks: 36649 Is it OK to merge the following revision(s) to the 6.0 branch? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=36649 [Bug 36649] [meta] 6.0.1 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37394] clang produces duplicate symbols when enabling Control Flow Integrity (icall)
https://bugs.llvm.org/show_bug.cgi?id=37394 Tom Ritter changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Tom Ritter --- Yup, this seems to be fixed in trunk; thanks. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37472] New: Shrink wrapping on AArch64 violates AAPCS (access below SP)
https://bugs.llvm.org/show_bug.cgi?id=37472
Bug ID: 37472
Summary: Shrink wrapping on AArch64 violates AAPCS (access
below SP)
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: eugeni.stepa...@gmail.com
CC: llvm-bugs@lists.llvm.org
AAPCS says,
A process may only access (for reading or writing) the closed interval of the
entire stack delimited by [SP, stack-base – 1].
Shrink wrapping analysis only cares that FI operands are post-dominated by
epilogue. It is possible for an address of a stack variable to be computed
before epilogue, but for the actual access to be done after it, violating the
condition above.
# cat 1.c
typedef struct {
int a, b;
} S;
int f(S *s, unsigned z)
{
if (z > 4)
return 1;
volatile unsigned char arr[4] = {1, 2, 3, 4};
s->a = arr[z];
if (z < 3) {
s->b = arr[z];
}
return 0;
}
$ bin/clang 1.c -O3 -target aarch64-linux-gnueabi -c && bin/llvm-objdump -d
-no-show-raw-insn 1.o
1.o:file format ELF64-aarch64-little
Disassembly of section .text:
f:
0: cmp w1, #4
4: b.ls#12
8: orr w0, wzr, #0x1
c: ret
10: sub sp, sp, #16
14: mov w9, #513
18: movkw9, #1027, lsl #16
1c: mov w8, w1
20: str w9, [sp, #12]
24: add x9, sp, #12 <-- address computation
28: ldrbw10, [x9, x8]
2c: cmp w1, #2
30: str w10, [x0]
34: add sp, sp, #16 <-- epilogue
38: b.hi#12
3c: ldrbw8, [x9, x8]<-- stack frame access
40: str w8, [x0, #4]
44: mov w0, wzr
48: ret
This is LLVM r331830. I'm not aware of this causing any practical issues.
--
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 37473] New: objcopy and strip get rid of the GNU_RELRO program header for binaries produced by lld
https://bugs.llvm.org/show_bug.cgi?id=37473 Bug ID: 37473 Summary: objcopy and strip get rid of the GNU_RELRO program header for binaries produced by lld Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: ppadev...@gmail.com CC: llvm-bugs@lists.llvm.org Suppose I have 3 files - f.h, f.cpp and main.cpp. I can add the contents if necessary. I want to use full RELRO. checkrelro.sh comes from here http://www.trapkit.de/tools/checkrelro.sh >mkdir -p build > >./c++ -o build/main.o -c -g -fPIC main.cpp >./c++ -o build/foo.o -c -g -fPIC foo.cpp >./c++ -o build/libfoo.so -Wl,--hash-style=gnu -Wl,-O2 -Wl,-z,relro -Wl,-z,now >-shared build/foo.o >./c++ -o build/a.out -pie -Wl,--hash-style=gnu -Wl,-O2 -Wl,-z,relro -Wl,-z,now >build/main.o -Lbuild -lfoo > > >./checkrelro.sh --file build/libfoo.so > >echo 'objcopy --only-keep-debug' >objcopy --only-keep-debug build/libfoo.so build/libfoo.so.debug >./checkrelro.sh --file build/libfoo.so > >echo 'objcopy -R .gnu_debuglink' >objcopy -R .gnu_debuglink --add-gnu-debuglink=build/libfoo.so.debug >build/libfoo.so >./checkrelro.sh --file build/libfoo.so > >echo 'strip' >strip build/libfoo.so -o build/libfoo.so.stripped >./checkrelro.sh --file build/libfoo.so >./checkrelro.sh --file build/libfoo.so.stripped > > >./checkrelro.sh --file build/a.out > >echo 'objcopy --only-keep-debug' >objcopy --only-keep-debug build/a.out build/a.out.debug >./checkrelro.sh --file build/a.out > >echo 'objcopy -R .gnu_debuglink' >objcopy -R .gnu_debuglink --add-gnu-debuglink=build/a.out.debug build/a.out >./checkrelro.sh --file build/a.out > >echo 'strip' >strip build/a.out -o build/a.out.stripped >./checkrelro.sh --file build/a.out >./checkrelro.sh --file build/a.out.stripped With gcc 6.4 and ld.bfd I get > build/libfoo.so - full RELRO > objcopy --only-keep-debug > build/libfoo.so - full RELRO > objcopy -R .gnu_debuglink > build/libfoo.so - full RELRO > strip > build/libfoo.so - full RELRO > build/libfoo.so.stripped - full RELRO > build/a.out - full RELRO > objcopy --only-keep-debug > build/a.out - full RELRO > objcopy -R .gnu_debuglink > build/a.out - full RELRO > strip > build/a.out - full RELRO > build/a.out.stripped - full RELRO With gcc 6.4 and ld.lld I get > build/libfoo.so - full RELRO > objcopy --only-keep-debug > build/libfoo.so - full RELRO > objcopy -R .gnu_debuglink > build/libfoo.so - no RELRO > strip > build/libfoo.so - no RELRO > build/libfoo.so.stripped - no RELRO > build/a.out - full RELRO > objcopy --only-keep-debug > build/a.out - full RELRO > objcopy -R .gnu_debuglink > build/a.out - no RELRO > strip > build/a.out - no RELRO > build/a.out.stripped - no RELRO It seems that both objcopy and strip get rid of the GNU_RELRO program header which is very very unfortunate. Is there a remedy for that? -- 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 34237] llvm-cov: Wrong coverage with partially uncovered nested macros
https://bugs.llvm.org/show_bug.cgi?id=34237 Vedant Kumar changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Vedant Kumar --- Yes, this was fixed in r312818. PR36086 is unrelated; it's an issue in clang. The clang frontend is able to constant-fold away some expressions and when this happens, the effect of the expression is not always reflected in the coverage mapping. In some cases this can be fixed by emitting counter updates even when an expression is constant-folded. I'm not sure what would be required to support constexpr. -- 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 37474] New: -fsanitize=cfi-icall inhibits dead code stripping for mixed ThinLTO/native builds
https://bugs.llvm.org/show_bug.cgi?id=37474
Bug ID: 37474
Summary: -fsanitize=cfi-icall inhibits dead code stripping for
mixed ThinLTO/native builds
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Interprocedural Optimizations
Assignee: v...@tsyrklevich.net
Reporter: v...@tsyrklevich.net
CC: k...@google.com, llvm-bugs@lists.llvm.org,
pe...@pcc.me.uk
This issue is causing the size regression noted in
https://bugs.chromium.org/p/chromium/issues/detail?id=841916 when enabling
-fsanitize=cfi-icall. This regression is caused by 1. nacl_helper pulling in
lots of code it doesn't seem to use and later strips (e.g. ffmpeg), 2. ThinLTO
not being able to determine what is live outside of ThinLTO compiled bitcode
(e.g. in native object files generated from assembly), and 3. LowerTypeTests
emitting references to dead address-taken functions in those native object
files. Normally the dead functions would be removed by -Wl,-gc-sections but
because CFI jumptables can be reached in the liveness analysis the dead
functions referenced by that jumptable are now live.
Here's a simplified example where just having a dead function in a ThinLTO
build address-take a dead function in a native object file will cause the
native object's dead function to be retained:
$ cat bitcode.c
#include
void native_dead(void *);
void* bitcode_dead(void) { return &native_dead; }
// Has the same type signature as native_dead
void addr_taken(void *ptr) { }
int main() {
void *fptr = &addr_taken;
((void(*)(void*))fptr)(NULL);
}
$ cat native.c
void native_dead() { }
$ clang -c -o native.o native.c
$ clang -flto=thin -fvisibility=hidden -fsanitize=cfi-icall -c -o bitcode.o
bitcode.c
$ clang -flto=thin -fvisibility=hidden -fsanitize=cfi-icall -fuse-ld=lld
-Wl,-gc-sections -o exe.icall bitcode.o native.o
$ nm exe.icall | grep dead
002010e0 T native_dead
00201178 t native_dead.cfi_jt
$ clang -flto=thin -fvisibility=hidden -c -o bitcode.o bitcode.c
$ clang -flto=thin -fvisibility=hidden -fuse-ld=lld -Wl,-gc-sections -o
exe.no-icall bitcode.o native.o
$ nm exe.no-icall | grep dead
$
This occurs because even though bitcode_dead is stripped, native_dead is not
removed from CfiFunctionDecls and a CFI jumptable entry is created for it. The
nacl_helper example is more complicated because there can be multiple
references from bitcode objects to native objects that reference bitcode
objects and back that cause multiple native symbols to be retained.
I spoke with Peter and the idea to fix this is to 1. change the ThinLTO summary
information to mark CfiFunctionDecls/CfiFunctionDefs with the function the
reference was created from, 2. change lld to perform a global liveness analysis
before LTO runs using ThinLTO summary information and looking at native objects
and mark dead objects non-prevailing (right now the analysis is local to just
the LTO bitcode objects), and 3. ignore CfiFunctionDecl/CfiFunctionDefs that
come from functions that will be ThinLTO dead stripped (e.g. non-prevailing.)
Implementing #1 and #3 alone should fix the example above, with #2 required to
handle bitcode->native->bitcode->native reference chains.
--
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 37475] New: Extern Module Include Causes Different Language Linkage
https://bugs.llvm.org/show_bug.cgi?id=37475 Bug ID: 37475 Summary: Extern Module Include Causes Different Language Linkage Product: clang Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: as...@strong.ai CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Created attachment 20306 --> https://bugs.llvm.org/attachment.cgi?id=20306&action=edit Reproduce error using command similar to that provided in comments. "Different Language Linkage" results when using modules and including posix headers. See attached example and build command. -- 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 37431] clang crashes with "-mllvm -enable-newgvn": error in backend: No support for lowering a copy into EFLAGS when used by this instruction!
https://bugs.llvm.org/show_bug.cgi?id=37431 Chandler Carruth changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Chandler Carruth --- After some iteration, landed fix in r332389. Verified that both the reduced test case in that commit and the full C test case here pass afterward. Thanks again for the test case! -- 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 37476] New: __builin_expect doesn't propagate through inlined functions
https://bugs.llvm.org/show_bug.cgi?id=37476
Bug ID: 37476
Summary: __builin_expect doesn't propagate through inlined
functions
Product: clang
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: redbeard0...@gmail.com
CC: llvm-bugs@lists.llvm.org
It seems like __builtin_expect doesn't propagate to conditions when inlined.
This is unfortunate because in some cases it would be nice to be able to put
the expectation into methods so that every user doesn't need to do their own
hinting. Currently we need to use macros to achieve this.
See https://godbolt.org/g/MuPM77 for full example
inline bool expect_false(bool b) {
return __builtin_expect(b, false);
}
void inline_func_hint(bool b) {
if (expect_false(b)) {
unlikely(); // treated as more likely!!!
} else {
likely();
}
}
inline_func_hint(bool): # @inline_func_hint(bool)
test edi, edi
je .LBB3_2
jmp unlikely() # TAILCALL
.LBB3_2:
jmp likely() # TAILCALL
GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799
--
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 37477] New: Assertion "!is_error()" failed at polly/lib/External/isl/include/isl/isl-noexceptions.h:66
https://bugs.llvm.org/show_bug.cgi?id=37477 Bug ID: 37477 Summary: Assertion "!is_error()" failed at polly/lib/External/isl/include/isl/isl-noexceptions.h: 66 Product: Polly Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Optimizer Assignee: polly-...@googlegroups.com Reporter: pzh...@codeaurora.org CC: llvm-bugs@lists.llvm.org AOSP buildbot started failing recently with the following error (http://lab.llvm.org:8011/builders/aosp-O3-polly-before-vectorizer-unprofitable/builds/518/steps/build-aosp/logs/stdio): Assertion "!is_error()" failed at /var/lib/buildbot/slaves/hexagon-build-03/aosp/llvm.src/tools/polly/lib/External/isl/include/isl/isl-noexceptions.h:66 IMPLEMENTATION ERROR: Unhandled error state Stack dump: 0. Program arguments: llvm.inst/bin/clang++ -cc1 -triple thumbv7--linux-android -emit-obj -mnoexecstack -disable-free -main-file-name double.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -relaxed-aliasing -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu cortex-a7 -target-feature +soft-float-abi -target-feature -crc -target-feature +dsp -target-feature -ras -target-feature -dotprod -target-feature +hwdiv-arm -target-feature +hwdiv -target-feature -fp-only-sp -target-feature -d16 -target-feature +vfp3 -target-feature -fp16 -target-feature -vfp4 -target-feature -fp-armv8 -target-feature +neon -target-feature -crypto -target-abi aapcs-linux -mfloat-abi soft -fallow-half-arguments-and-returns -dwarf-column-info -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -ffunction-sections -fdata-sections -coverage-notes-file /var/lib/buildbot/slaves/hexagon-build-03/aosp/out/target/product/angler/obj_arm/STATIC_LIBRARIES/libF77blas_intermediates/double.gcno -nostdsysteminc -resource-dir llvm.inst/lib/clang/7.0.0 -dependency-file out/target/product/angler/obj_arm/STATIC_LIBRARIES/libF77blas_intermediates/double.d -MT out/target/product/angler/obj_arm/STATIC_LIBRARIES/libF77blas_intermediates/double.o -sys-header-deps -isystem frameworks/av/include -isystem out/target/product/angler/obj/include -isystem device/huawei/angler/kernel-headers -isystem hardware/qcom/msm8994/kernel-headers -isystem bionic/libc/arch-arm/include -isystem bionic/libc/include -isystem bionic/libc/kernel/uapi -isystem bionic/libc/kernel/uapi/asm-arm -isystem bionic/libc/kernel/android/uapi -I external/eigen/ -I external/eigen/blas -I out/target/product/angler/obj_arm/STATIC_LIBRARIES/libF77blas_intermediates -I out/target/product/angler/gen/STATIC_LIBRARIES/libF77blas_intermediates -I libnativehelper/include/nativehelper -I external/libcxx/include -I external/libcxxabi/include -I system/core/include -I system/media/audio/include -I hardware/libhardware/include -I hardware/libhardware_legacy/include -I hardware/ril/include -I libnativehelper/include -I frameworks/native/include -I frameworks/native/opengl/include -D _FORTIFY_SOURCE=2 -D NDEBUG -D ANDROID -D NDEBUG -U DEBUG -D __compiler_offsetof=__builtin_offsetof -D __ARM_FEATURE_LPAE=1 -D EIGEN_ANDROID_SSE_WR -D _USING_LIBCXX -internal-isystem llvm.inst/lib/clang/7.0.0/include -O3 -Wno-multichar -Werror=format-security -Wstrict-aliasing=2 -W -Wall -Wno-unused -Winit-self -Wpointer-arith -Werror=int-conversion -Wno-reserved-id-macro -Wno-format-pedantic -Wno-unused-command-line-argument -Wno-expansion-to-defined -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Werror=date-time -Wsign-promo -Wno-inconsistent-missing-override -Wno-null-dereference -Wno-unused-parameter -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -Werror=address-of-temporary -Werror=return-type -Wno-error -std=gnu++14 -fdeprecated-macro -fdebug-compilation-dir /var/lib/buildbot/slaves/hexagon-build-03/aosp -fdebug-prefix-map=/proc/self/cwd= -ferror-limit 19 -fmessage-length 0 -fvisibility-inlines-hidden -stack-protector 2 -fno-rtti -fno-signed-char -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -mllvm -polly -mllvm -polly-position=before-vectorizer -mllvm -polly-process-unprofitable -o out/target/product/angler/obj_arm/STATIC_LIBRARIES/libF77blas_intermediates/double.o -x c++ external/eigen/blas/double.cpp 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'Function Pass Manager' on module 'external/eigen/blas/double.cpp'. 4. Running pass 'Region Pass Manager' on function '@_ZN5Eigen8internal33selfadjoint_matrix_vector_productIdiLi0ELi1ELb0ELb0ELi0EE3runEiPKdiS4_iPdd' 5. Running pass 'Polly - DeLICM/DePRE' on basic block '%if.end' #0 0x01621f54 PrintStackTraceSignalHandler(void*) (llvm.inst/bin/clang+++0x1621f54) #1 0x01622266 SignalHandler(int)
[llvm-bugs] [Bug 37478] New: Output not deterministic when run with a multi-line comment on a single line
https://bugs.llvm.org/show_bug.cgi?id=37478
Bug ID: 37478
Summary: Output not deterministic when run with a multi-line
comment on a single line
Product: clang
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: aindu...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Running clang-format on its own output results in a different output for
the following example. Is this expected behavior? The example has a
multi-line comment on a single line of a function body.
$ clang-format -version
clang-format version 7.0.0 (tags/google/stable/2018-01-11)
$ cat foo.c
void foo() {
/* THIS IS A COMMENT */
}
$ clang-format foo.c > foo2.c
$ cat foo2.c
void foo() { /* THIS IS A COMMENT */ }
$ clang-format foo2.c > foo3.c
$ cat foo3.c
void foo() { /* THIS IS A COMMENT */
}
Thank You,
Akhil Indurti
--
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 37479] New: LoopIdiomRecognize can turn infinite loops into countable loop using ctlz
https://bugs.llvm.org/show_bug.cgi?id=37479
Bug ID: 37479
Summary: LoopIdiomRecognize can turn infinite loops into
countable loop using ctlz
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: craig.top...@gmail.com
CC: llvm-bugs@lists.llvm.org
On targets that support ctlz, loop idiom recognize can transform code like this
int foo(int x) {
int cnt = 0;
while (x) {
x >>= 1;
++cnt;
}
return cnt;
}
Into just returning (32 - ctlz(x)). Or if the loop contains other code it will
create a loop that runs (32 - ctlz(x)) times.
But if x was negative the original code would have been an infinite loop since
the shift would just keep copying the sign bit preventing x from ever being 0.
This transform was added by D32605 and the motivating case cited there looks
pretty much like above with an additional "if (x < 0) x = -x;" before the loop.
Ideally I'd like to not lose the optimization. Are there any things we can
exploit to ensure this is safe for that motivating case.
--
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 37312] Assertion failure in create_call_once_funcptr_call()
https://bugs.llvm.org/show_bug.cgi?id=37312 George Karpenkov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from George Karpenkov --- Fixed in 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 37480] New: Merge rr328408 into the 6.0 branch : Add REQUIRES lines for the targets being checked in this test.
https://bugs.llvm.org/show_bug.cgi?id=37480 Bug ID: 37480 Summary: Merge rr328408 into the 6.0 branch : Add REQUIRES lines for the targets being checked in this test. Product: new-bugs Version: 6.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tstel...@redhat.com CC: llvm-bugs@lists.llvm.org Blocks: 36649 Is it OK to merge the following revision(s) to the 6.0 branch? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=36649 [Bug 36649] [meta] 6.0.1 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
