[llvm-bugs] [Bug 46759] [PowerPC] frame_layout in test-suite fails if compiled with -fstack-clash-protection on powerpc64le machine
https://bugs.llvm.org/show_bug.cgi?id=46759 Kai Luo changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Kai Luo --- Hi Hans, could you help merge ``` commit 8912252252c87d8ef6623ecf9fdde444560ee4b9 Author: Kai Luo Date: Wed Jul 22 04:13:18 2020 + [PowerPC] Fix wrong codegen when stack pointer has to realign in prologue ``` and ``` commit c3f9697f1f227296818fbaf1a770a29842ea454c Author: Kai Luo Date: Wed Jul 22 04:16:20 2020 + [PowerPC] Fix wrong codegen when stack pointer has to realign performing dynalloc ``` into release/11.x, 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 46759, which changed state. Bug 46759 Summary: [PowerPC] frame_layout in test-suite fails if compiled with -fstack-clash-protection on powerpc64le machine https://bugs.llvm.org/show_bug.cgi?id=46759 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46804] New: llvm-dwarfdump cannot handle .debug_ranges/.debug_loc empty relocated range in ET_REL object
https://bugs.llvm.org/show_bug.cgi?id=46804 Bug ID: 46804 Summary: llvm-dwarfdump cannot handle .debug_ranges/.debug_loc empty relocated range in ET_REL object Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llvm-dwarfdump Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org See http://lists.llvm.org/pipermail/llvm-dev/2020-July/143575.html for full context. A .debug_ranges/.debug_loc sequence ends with an entry containing 0 for the two addresses. In a fully-linked object, llvm-dwarfdump handles this fine. However, in an ET_REL file, there might be relocations patching an apparent 0, 0 entry. The parsing code does resolve relocations before determining if an address is zero. However, if the relocations happen to be section-relative (or symbol-relative, where the symbol is at a section start), the resultant address will be the relocation addend, which could be 0 in both cases. Simple example: .section .foo,"a",@progbits nop .section .debug_ranges,"",@progbits: .quad foo .quad foo .quad 0, 0 # actual terminator This is a particular problem in .debug_loc, where the entry might have some data afterwards, so a premature termination will cause parsing to completely fail. The solution is to not treat an address patched by a relocation as 0, for the purpose of termination. -- 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 46805] New: Regression in handling 0-length address range entries
https://bugs.llvm.org/show_bug.cgi?id=46805 Bug ID: 46805 Summary: Regression in handling 0-length address range entries Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llvm-dwarfdump Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org This regression was introduced in https://reviews.llvm.org/rGed9851a0a682d1ff288ed749287fbc7682ed1514 (see https://reviews.llvm.org/D71932 for the review). A .debug_aranges table might contain an entry for a zero-length function or data. This is not forbidden by the standard, and can happen in practice. In such a case, it should not be an error. In up to at least LLVM version 9, this worked fine, but the cited change caused an error to start occurring. Example: PS C:\Work\TempWork> llvm-dwarfdump.exe --debug-aranges bar.elf bar.elf:file format elf64-x86-64 .debug_aranges contents: error: address range table at offset 0x0 has an invalid tuple (length = 0) at offset 0x10 A trivial asm input might look like: foo: .secton .debug_aranges,"",@progbits ... # Some data for the header .quad foo .quad 0 # 0 length .quad 0 # The .debug_aranges terminator .quad 0 Note that simply removing the error message is not quite the right fix - we still want to emit an error if a terminator is detected before the claimed end of the file, but beware a similar issue to bug 46804, where in an ET_REL file, the address might appear to be zero, but it is relocated. -- 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 46806] New: Backport PCH handling commits to 11.0
https://bugs.llvm.org/show_bug.cgi?id=46806 Bug ID: 46806 Summary: Backport PCH handling commits to 11.0 Product: clang Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: l.lu...@centrum.cz CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Please backport commits 3895466e2c336c0797710ae35150ba1ce6bc0b96 and 54eea6127c4d77db03787b7c55765632fb9a6f1c to 11.0 . They are meant to accompany 31b05692cd33b6dcc39402169b36d895e1aa87f4, which made it in before the 11.0 branch-off, and they clean up command-line handling for it, as discussed in D83623. Strictly speaking the commits are not bugfixes, but they should be simple/safe enough, the feature is opt-in, and if not backported then only Clang12 would have the proper/recommended way for handling a feature that's already new in Clang11. The commits also include release notes documentation. -- 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 46616] ARMDisassembler.cpp: DecodeThumbTableBranch improperly marks "tbb/w [pc, rx]" as SoftFailure
https://bugs.llvm.org/show_bug.cgi?id=46616 David Spickett changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 46786, which changed state. Bug 46786 Summary: ScalarEvolution::getGEPExpr assertion failure "GEP should not change type mid-flight." https://bugs.llvm.org/show_bug.cgi?id=46786 What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46786] ScalarEvolution::getGEPExpr assertion failure "GEP should not change type mid-flight."
https://bugs.llvm.org/show_bug.cgi?id=46786 Max Kazantsev changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #15 from Max Kazantsev --- Assert disabled by: commit b96114c1e1fc4448ea966bce013706359aee3fa9 Author: Max Kazantsev Date: Wed Jul 22 15:32:13 2020 +0700 [SCEV] Remove premature assert. PR46786 This assert was added to verify assumption that GEP's SCEV will be of pointer type, basing on fact that it should be a SCEVAddExpr with (at least) last operand being pointer. Two notes: - GEP's SCEV does not have to be a SCEVAddExpr after all simplifications; - In current state, GEP's SCEV does not have to have at least one pointer operands (all of them can become int during the transforms). However, we might want to be at a point where it is true. We are currently removing this assert and will try to enumerate the cases where "is pointer" notion might be lost during the transforms. When all of them are fixed, we can return it. Differential Revision: https://reviews.llvm.org/D84294 Reviewed By: lebedev.ri I'll try to help to find cases that we are still missing to have this assert, because generally preserving a notion of something being a pointer seems useful. Unfortunately, we are not yet in point to say we preserve it. -- 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 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 46786, which changed state. Bug 46786 Summary: ScalarEvolution::getGEPExpr assertion failure "GEP should not change type mid-flight." https://bugs.llvm.org/show_bug.cgi?id=46786 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46786] ScalarEvolution::getGEPExpr assertion failure "GEP should not change type mid-flight."
https://bugs.llvm.org/show_bug.cgi?id=46786 Roman Lebedev changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #16 from Roman Lebedev --- (still needs to be cherry-picked) -- 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 46807] New: Merge 5b5dc2442ac7 into 11.0 release branch
https://bugs.llvm.org/show_bug.cgi?id=46807 Bug ID: 46807 Summary: Merge 5b5dc2442ac7 into 11.0 release branch Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com Blocks: 46725 Based off an investigation into a test case provided by Craig, we need to avoid traversing the DAG inside getTargetShuffleMask - I investigated hasOneUse() wrappers but this approach is safer and we have other shuffle decode/combines that can handle more complex broadcast shuffle folds. Craig - are you OK with this getting merged? https://reviews.llvm.org/rG5b5dc2442ac7 [X86][AVX] getTargetShuffleMask - don't decode VBROADCAST(EXTRACT_SUBVECTOR(X,0)) patterns. getTargetShuffleMask is used by the various "SimplifyDemanded" folds so we can't assume that the bypassed extract_subvector can be safely simplified - getFauxShuffleMask performs a more general decode that allows us to more safely catch many of these cases so the impact is minimal. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=46725 [Bug 46725] [meta] 11.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 46794] Backport 3a108ab256dba7b5a7304f0e83818673d334405f to 11.x
https://bugs.llvm.org/show_bug.cgi?id=46794 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Hans Wennborg --- Pushed as 764e28231e4b3b04748ac1c85576402bb76919de. Please let me know if there are any follow-ups or other 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 46794, which changed state. Bug 46794 Summary: Backport 3a108ab256dba7b5a7304f0e83818673d334405f to 11.x https://bugs.llvm.org/show_bug.cgi?id=46794 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 24327 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: isByVal() && !isByRef()
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.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 Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-07-22 Type: Bug New issue 24327 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: isByVal() && !isByRef() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24327 Detailed Report: https://oss-fuzz.com/testcase?key=5745374153932800 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--aarch64-gisel Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: isByVal() && !isByRef() void llvm::CallLowering::setArgFlags llvm::CallLowering::lowerCall Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=202007210155:202007220207 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5745374153932800 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. 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 need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 46808] New: RDF Live Variables Analysis may cause ballooning compile times
https://bugs.llvm.org/show_bug.cgi?id=46808 Bug ID: 46808 Summary: RDF Live Variables Analysis may cause ballooning compile times Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: scott.d.consta...@intel.com CC: llvm-bugs@lists.llvm.org The RDF live variables analysis probably has high asymptotic complexity than what is actually necessary. In particular: https://github.com/llvm/llvm-project/blob/b5be1c5419e2a38eb60fc7e785567b54b6d9e0e0/llvm/lib/CodeGen/RDFLiveness.cpp#L208 This may be causing substantial compilation overhead for some users who enable passes that depend on RDF live variable analysis, e.g., https://github.com/rust-lang/rust/issues/74632. Related discussion on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2020-April/141332.html. -- 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 46809] New: Missed optimization to use the carry flag after subtracting
https://bugs.llvm.org/show_bug.cgi?id=46809
Bug ID: 46809
Summary: Missed optimization to use the carry flag after
subtracting
Product: libraries
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: josephcsi...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
Consider these two C functions:
unsigned f1(unsigned x, unsigned y) {
unsigned z = x - y;
if (x < y) {
z += 100;
}
return z;
}
unsigned f2(unsigned x, unsigned y) {
unsigned z;
if (__builtin_usub_overflow(x, y, &z)) {
z += 100;
}
return z;
}
At -O3 or -Os, they both generate the same assembly:
movl%edi, %eax
movl%edi, %ecx
subl%esi, %ecx
addl$100, %ecx
subl%esi, %eax
cmovbl %ecx, %eax
retq
https://godbolt.org/z/MevEM9
That's suboptimal. They should have instead used lea to save a move, save a
duplicate subtraction, and avoid clobbering the carry flag, like this:
subl%esi, %edi
leal100(%rdi), %eax
cmovael %edi, %eax
retq
--
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 43417] After r357222, Assertion failed: (A->getParent() == B->getParent() && "Instructions must be in the same basic block!"), function dominates, file lib/Analysis/OrderedBasicBlock.
https://bugs.llvm.org/show_bug.cgi?id=43417 Dimitry Andric changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Dimitry Andric --- This got fixed by https://github.com/llvm/llvm-project/commit/369a9195144. -- 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 46810] New: Missing inexact FP exception on cast
https://bugs.llvm.org/show_bug.cgi?id=46810
Bug ID: 46810
Summary: Missing inexact FP exception on cast
Product: clang
Version: 10.0
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: tyde...@tybor.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
This code shows that the cast operator is not raising the floating point
inexact exception (perhaps because the cast was done at translation time). I
am using as many options as I can find to get IEEE-754 and C standard
conformance. This is on ARM CPU.
/*
* Missing inexact FP exception on cast.
*/
#include
#include
#include
int main(void){
int ex;
feclearexcept( FE_ALL_EXCEPT );
if( 0.1F == (float)0.1 ){ /* inexact on cast */
(void)printf("equal\n");
}else{
(void)printf("not equal\n");
}
ex = fetestexcept( FE_ALL_EXCEPT );
if( FE_INEXACT != ex ){
(void)printf("bug: ex = %#x, FE_INEXACT=%#x\n", ex, FE_INEXACT);
}
(void)printf("FLT_EVAL_METHOD=%i\n", FLT_EVAL_METHOD);
return 0;
}
# flags for compiler
export CFLAGS="-H -std=c2x -pedantic -pedantic-errors -O0 -m64 -march=armv8-a
-mcpu=cortex-a72 \
-ffp-model=strict \
-ffp-exception-behavior=strict \
-fhonor-infinities \
-fhonor-nans \
-fmath-errno \
-fno-associative-math \
-fno-builtin \
-fno-finite-math-only \
-fno-reciprocal-math \
-fno-unsafe-math-optimizations \
-frounding-math \
-fsigned-zeros \
-fstrict-float-cast-overflow \
-ftrapping-math \
-Xclang -disable-llvm-optzns \
${INCS}"
--
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 46810] Missing inexact FP exception on cast
https://bugs.llvm.org/show_bug.cgi?id=46810 Richard Smith changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Richard Smith --- As noted on PR46799, we do not support FENV_ACCESS on armv8 yet. Clang trunk warns: warning: overriding currently unsupported use of floating point exceptions on this target [-Wunsupported-floating-point-opt] *** This bug has been marked as a duplicate of bug 46799 *** -- 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 46802] ARM long double arithmetic done wrong
https://bugs.llvm.org/show_bug.cgi?id=46802 Richard Smith changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Richard Smith --- As noted on PR46799, we do not support FENV_ACCESS on armv8 yet. Clang trunk warns: warning: overriding currently unsupported rounding mode on this target [-Wunsupported-floating-point-opt] *** This bug has been marked as a duplicate of bug 46799 *** -- 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 46799] no support for FENV_ACCESS on armv8
https://bugs.llvm.org/show_bug.cgi?id=46799 Richard Smith changed: What|Removed |Added Version|10.0|trunk Product|clang |libraries Assignee|unassignedclangbugs@nondot. |unassignedb...@nondot.org |org | Resolution|DUPLICATE |--- Component|C |Backend: ARM Summary|FP flags differ on same |no support for FENV_ACCESS |operation (<) in different |on armv8 |contexts| CC||smithp...@googlemail.com, ||ties.st...@arm.com Status|RESOLVED|REOPENED --- Comment #6 from Richard Smith --- Let's split this out of PR8100 to specifically track ARMv8 support for constrained floating point. -- 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 46811] New: ARM isnormal(long double NaN) raises invalid
https://bugs.llvm.org/show_bug.cgi?id=46811
Bug ID: 46811
Summary: ARM isnormal(long double NaN) raises invalid
Product: clang
Version: 10.0
Hardware: Other
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: tyde...@tybor.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
/*
* isnormal(long double NaN) raises invalid; it should not.
*/
#include
#include
#include
#include
int main(void){
long double ldnan = NAN;
long double ldinf = INFINITY;
int ex;
feclearexcept( FE_ALL_EXCEPT );
if( isnormal(ldnan) ){
(void)printf("bug 1: NAN is not normal\n");
}
ex = fetestexcept( FE_ALL_EXCEPT );
if( 0 != ex ){
(void)printf("bug 2: ex=%#x, FE_INVALID=%#x, ldnan=%Lg\n", ex, FE_INVALID,
ldnan);
}
feclearexcept( FE_ALL_EXCEPT );
if( isnormal(ldinf) ){
(void)printf("bug 3: INFINITY is not normal\n");
}
ex = fetestexcept( FE_ALL_EXCEPT );
if( 0 != ex ){
(void)printf("bug 4: ex=%#x, FE_INVALID=%#x, ldinf=%Lg\n", ex, FE_INVALID,
ldinf);
}
return 0;
}
I am not sure if this is a compiler built-in or part of the math library.
--
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 46812] New: WebAssembly: non-simd128 functions aren't inlined into simd128 functions
https://bugs.llvm.org/show_bug.cgi?id=46812
Bug ID: 46812
Summary: WebAssembly: non-simd128 functions aren't inlined into
simd128 functions
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: a...@crichton.co
CC: llvm-bugs@lists.llvm.org, tliv...@google.com
This issue was discovered when working with the simd128 feature of WebAssembly
and LLVM, but the following IR:
target triple = "wasm32-unknown-unknown"
define void @bar() #0 {
start:
tail call fastcc void @inline_me()
ret void
}
define internal void @inline_me() {
start:
tail call void @foo()
ret void
}
declare void @foo()
attributes #0 = { "target-features"="+simd128" }
when optimized with `opt -O2` won't actually inline the `inline_me` function.
This looks to be due to a conservative default of not inlining when target
features differ, but WebAssembly can probably inline regardless of target
features due to how the entire binary validates as a whole or doesn't.
--
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 46813] New: Wrong compact unwind information for functions using stack probes
https://bugs.llvm.org/show_bug.cgi?id=46813
Bug ID: 46813
Summary: Wrong compact unwind information for functions using
stack probes
Product: libraries
Version: trunk
Hardware: PC
OS: MacOS X
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: a...@crichton.co
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
In rust-lang/rust we've for the longest time enabled frame pointers on our
macOS targets, but we're looking at that again recently and trying to figure
out why we're still doing this. An attempt to disable frame pointers, however,
led to segfaults during unwinding. We investigated this a bit and came up on
this issue.
The issue here we found is that the compact unwind information for a function
with a large stack frame is incorrect if the "probe-stack" attribute is used.
Namely this IR:
target triple = "x86_64-apple-macosx10.7.0"
define void @foo() #0 {
start:
%_huge_stack = alloca [1024 x i64], align 8
call void @bar()
ret void
}
declare void @bar()
attributes #0 = { uwtable "probe-stack"="__probestack" }
when compiled yields:
$ llc unwind.ll -o foo.o -filetype=obj
$ llvm-objdump foo.o -uS
foo.o: file format mach-o 64-bit x86-64
Disassembly of section __TEXT,__text:
<_foo>:
./build/bin/llvm-objdump: warning: 'foo.o': failed to parse debug
information for foo.o
0: b8 08 20 00 00movl$8200, %eax
5: e8 00 00 00 00callq 0xa <_foo+0xa>
a: 48 29 c4 subq%rax, %rsp
d: e8 00 00 00 00callq 0x12 <_foo+0x12>
12: 48 81 c4 08 20 00 00 addq$8200, %rsp
19: c3retq
Unwind info:
Contents of __compact_unwind section:
Entry at offset 0x0:
start:0x0 _foo
length: 0x1a
compact encoding: 0x03032000
Here the compact unwind information for `foo` is 0x03032000, where the tag
(0x300) indicates `UNWIND_X86_64_MODE_STACK_IND`, which according to online
documentation says:
// UNWIND_X86_64_MODE_STACK_IND:
//A "frameless" (RBP not used as frame pointer) function large constant
//stack size. This case is like the previous, except the stack size is too
//large to encode in the compact unwind encoding. Instead it requires that
//the function contains "subq $,RSP" in its prolog. The compact
//encoding contains the offset to the value in the function in
//UNWIND_X86_64_FRAMELESS_STACK_SIZE.
For this function, however, the `subq` instruction doesn't exist with a
constant, but rather `%rax` which comes from `__probestack`
--
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 46800] CMPLXL() missing for c2x
https://bugs.llvm.org/show_bug.cgi?id=46800 Richard Smith changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||6c18f7db73a08f1ae39a76a86b4 ||14c5b0c24ee86 Status|NEW |RESOLVED --- Comment #3 from Richard Smith --- As of commit 6c18f7db73a08f1ae39a76a86b414c5b0c24ee86 Clang now implements __builtin_complex, and Clang + glibc now accept this example when using -fgnuc-version=4.7 or higher. I'm marking this as fixed, even though we will still reject the given valid code when compiling with glibc in our default mode; while that is a bug, I don't think any further part of it is *our* bug. I've filed a glibc bug for the rest: https://sourceware.org/bugzilla/show_bug.cgi?id=26287 -- 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 46814] New: ipscpp crash
https://bugs.llvm.org/show_bug.cgi?id=46814 Bug ID: 46814 Summary: ipscpp crash Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: shlomocho...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org -- 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] Declaration conflict between __clang_cuda_math_forward_declares.h and libstdc++
https://bugs.llvm.org/show_bug.cgi?id=42972 Jon Chesterfield changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jon Chesterfield --- This is fixed on trunk. I suspect the problem was that glibc defines these functions as constexpr (for some c++ versions) and __clang_cuda_math_forward_declares.h did not. Clang 10.0 did not include constexpr in the definition of __DEVICE__, I haven't checked what the status was for trunk as of when this bug was opened. On trunk, the functions are now defined as constexpr, and the failure mode reported here no longer reproduces. -- 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 46811] ARM isnormal(long double NaN) raises invalid
https://bugs.llvm.org/show_bug.cgi?id=46811 Richard Smith changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Richard Smith --- OK, I see the same thing if I use __builtin_isnormal instead: https://godbolt.org/z/37M8PG -- in particular, the `fcmp`s we generate can set FE_INVALID on NaN. On x86_64, those `fcmp`s are replaced by constrained FP intrinsics: https://godbolt.org/z/GK9Ejh So this is another duplicate of 46799: this code was compiled assuming the default floating point environment and that FP exceptions would not be inspected. Use of facilities from that environment is undefined, and in this case that's manifesting as isnormal setting a floating point exception. *** This bug has been marked as a duplicate of bug 46799 *** -- 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 46418] New: Sanitizers don't work with ThinLTO and new pass manager at opt level > 0
https://bugs.llvm.org/show_bug.cgi?id=46418
Bug ID: 46418
Summary: Sanitizers don't work with ThinLTO and new pass
manager at opt level > 0
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: tomasz.mia...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
yuanfang.c...@sony.com
CC: yuanfang.c...@sony.com
When using ThinLTO and -fexperimental-new-pass-manager at optimization
level > 0, sanitizer passes are registered using
registerOptimizerLastEPCallback
but the pre-link pipeline constructed with buildThinLTOPreLinkDefaultPipeline
doesn't include optimization pipeline and those callbacks are never invoked.
Thus the sanitizer instrumentation is not performed at all.
Example:
$ cat a.cpp
#include
int main(int argc, char **argv) {
char x[10];
memset(x, 0, 10);
int res = x[argc * 10];
return res;
}
$ clang -fexperimental-new-pass-manager -flto=thin -fsanitize=address -O1 a.cpp
$ ./a.out
$ # No error report.
--
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 24340 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in llvm::BumpPtrAllocatorImpl::Alloca
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.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 Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-07-23 Type: Bug New issue 24340 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in llvm::BumpPtrAllocatorImpl::Alloca https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24340 Detailed Report: https://oss-fuzz.com/testcase?key=5646016930643968 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fff76f34ff8 Crash State: llvm::BumpPtrAllocatorImpl::Alloca clang::IntegerLiteral::Create clang::Sema::ActOnIntegerConstant Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202007210155:202007220207 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5646016930643968 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. 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 need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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
