[llvm-bugs] [Bug 28115] Sanitizer_common_interceptors_ioctl.inc:586 taking address of packed member
https://bugs.llvm.org/show_bug.cgi?id=28115 Aaron Ballman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Aaron Ballman --- The offending patch was reverted in r272653. -- 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 37780] New: lib/Transforms/Scalar/SCCP.cpp:1996: bool llvm::runIPSCCP(llvm::Module &, const llvm::DataLayout &, const llvm::TargetLibraryInfo *): Assertion `Folded && "Expect TermInst
https://bugs.llvm.org/show_bug.cgi?id=37780 Bug ID: 37780 Summary: lib/Transforms/Scalar/SCCP.cpp:1996: bool llvm::runIPSCCP(llvm::Module &, const llvm::DataLayout &, const llvm::TargetLibraryInfo *): Assertion `Folded && "Expect TermInst on constantint or blockaddress to be folded"' failed. with -ipsccp Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Running: opt -S -o - bbi-14632.ll -ipsccp yields opt: ../lib/Transforms/Scalar/SCCP.cpp:1978: bool llvm::runIPSCCP(llvm::Module &, const llvm::DataLayout &, const llvm::TargetLibraryInfo *): Assertion `Folded && "Expect TermInst on constantint or blockaddress to be folded"' failed. This is not new, I've found it in old binaries built from trunk in March 2017 and on older builds it crashed with another assert. -- 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 37777] New: internal llvm error while building libcxx_fuzzer_x86_64
https://bugs.llvm.org/show_bug.cgi?id=3 Bug ID: 3 Summary: internal llvm error while building libcxx_fuzzer_x86_64 Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: matthias.krue...@famsik.de CC: llvm-bugs@lists.llvm.org Hi, I'm using the monorepo @ 581445d4e6037de8587053c4b2030a01c7541fda When trying to build the second stage (make all) using previously compiled clang of the same repo commit, libcxx_fuzzer fails to compile due to a llvm error: CMake Deprecation Warning at CMakeLists.txt:14 (cmake_policy): The OLD behavior for policy CMP0051 will be removed from a future version of CMake. The cmake-policies(7) manual explains that the OLD behaviors of all policies are deprecated and that a policy should be set to OLD only under specific short-term circumstances. Projects should be ported to the NEW behavior and not rely on setting a policy to OLD. -- Native target architecture is X86 -- Threads enabled. -- Doxygen disabled. -- Go bindings enabled. -- Could NOT find OCaml (missing: OCAMLFIND OCAML_VERSION OCAML_STDLIB_PATH) -- Could NOT find OCaml (missing: OCAMLFIND OCAML_VERSION OCAML_STDLIB_PATH) -- OCaml bindings disabled. -- Found Python module pygments -- Found Python module pygments.lexers.c_cpp -- Could NOT find Python module yaml -- LLVM host triple: x86_64-unknown-linux-gnu -- LLVM default target triple: x86_64-unknown-linux-gnu -- Building with -fPIC -- Constructing LLVMBuild project information -- Linker detection: LLD -- Targeting X86 -- Linker detection: LLD -- Linker detection: LLD -- Compiler-RT supported architectures: x86_64;i386 -- Builtin supported architectures: i386;x86_64 -- Linker detection: LLD -- Linker detection: LLD -- Builtin supported architectures: i386;x86_64 -- ISL version: isl-0.19-185-g8e9f55ce -- PPCG version: ppcg-0.07 -- Clang version: 7.0.0 -- LLD version: 7.0.0 -- LLDB version: 7.0.0 -- Symbols (liblldb): exporting all symbols from the lldb namespace -- Configuring done -- Generating done -- Build files have been written to: /home/matthias/LLVM/LLVM_dev/stage_2/objects Building stage 2 [ 17%/590/6/3368,628.385] Performing build step for 'libcxx_fuzzer_x86_64' [ 0%/0/1/1,0.000] Re-running CMake... -- Configuring for standalone build. -- Linker detection: LLD -- Linker detection: LLD -- Linker detection: LLD -- Configuring done -- Generating done -- Build files have been written to: /home/matthias/LLVM/LLVM_dev/stage_2/objects/projects/compiler-rt/lib/fuzzer/libcxx_fuzzer_x86_64-bins [100%/175/1/175,3.961] Copying CXX header support/xlocale/__strtonum_fallback.h [ 17%/598/6/3368,634.175] Linking CXX static library lib/clang/7.0.0/lib/linux/libclang_rt.fuzzer_no_main-x86_64.a FAILED: lib/clang/7.0.0/lib/linux/libclang_rt.fuzzer_no_main-x86_64.a : && /usr/bin/cmake -E remove lib/clang/7.0.0/lib/linux/libclang_rt.fuzzer_no_main-x86_64.a && /home/matthias/LLVM/LLVM_dev/stage_1/build/bin/llvm-ar qc lib/clang/7.0.0/lib/linux/libclang_rt.fuzzer_no_main-x86_64.a projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerCrossOver.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerDataFlowTrace.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerDriver.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerExtFunctionsDlsym.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerExtFunctionsDlsymWin.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerExtFunctionsWeak.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerExtraCounters.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerIO.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerIOPosix.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerIOWindows.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerLoop.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerMerge.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerMutate.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerSHA1.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerShmemFuchsia.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerShmemPosix.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerShmemWindows.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerTracePC.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerUtil.cpp.o projects/compiler-rt/lib/fuzzer/CMakeFiles/RTfuzzer.x86_64.dir/FuzzerUtilDarwin.cpp.o
[llvm-bugs] [Bug 37776] New: Invalid optimization with `fmax` and `-inf`
https://bugs.llvm.org/show_bug.cgi?id=37776
Bug ID: 37776
Summary: Invalid optimization with `fmax` and `-inf`
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mped...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 20420
--> https://bugs.llvm.org/attachment.cgi?id=20420=edit
Preprocessed source file
My simple test program gives different results depending on whether I enable
optimization with -O. The program is as follows (preprocessed source
attached):
#include
#include
#include
bool example(double dub)
{
return fmax(((double)NAN), dub) < -1.0;
}
int main(void)
{
const bool result = example(-HUGE_VAL);
printf("example(-inf) = %s\n", result ? "true" : "false");
return result ? 0 : 1;
}
If I enable optimizations when compiling this program and run it, it prints
example(-inf) = false
and returns 1. If I don't enable optimizations, running it prints out
example(-inf) = true
and returns 0. This is the result I expect, since fmax(NAN, x) is defined to
be x, and in this case x = -HUGE_VAL (negative infinity) is less than -1.0.
If I inline the function example() into main() or I replace the call to fmax()
with a call to fmin(), the program behaves correctly whether or not
optimizations are enabled during compilation. If I invert signs by either
changing NAN to (-NAN) or changing -HUGE_VAL to HUGE_VAL, the program always
behaves correctly, printing "true" in the former case and "false" in the latter
case, since HUGE_VAL < -1.0 is false. The order of arguments to fmax() does
not affect the result of the program.
The attached file test.i is the preprocessed source file. The test program
compiles without errors or warnings and never triggers the undefined-behavior
sanitizer. I observe the same behavior with clang version 6.0.0-3+b1
(tags/RELEASE_600/final) but not with clang version 5.0.2-2
(tags/RELEASE_502/final).
The compiler invocation and complete output follows:
clang-7 -O -v -save-temps -Wall -Wextra -Werror -fsanitize=undefined
-fsanitize=address -fno-strict-aliasing -fwrapv -lm test.c -o test
clang version 7.0.0- (trunk)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
"/usr/lib/llvm-7/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -E
-save-temps=cwd -disable-free -disable-llvm-verifier -discard-value-names
-main-file-name test.c -mrelocation-model static -mthread-model posix
-relaxed-aliasing -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info
-debugger-tuning=gdb -momit-leaf-frame-pointer -v -resource-dir
/usr/lib/llvm-7/lib/clang/7.0.0 -internal-isystem /usr/local/include
-internal-isystem /usr/lib/llvm-7/lib/clang/7.0.0/include
-internal-externc-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/8/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O2
-Wall -Wextra -Werror -fdebug-compilation-dir /home/peddie/clang-bug
-ferror-limit 19 -fmessage-length 106
-fsanitize=address,alignment,array-bounds,bool,builtin,enum,float-cast-overflow,float-divide-by-zero,function,integer-divide-by-zero,nonnull-attribute,null,object-size,pointer-overflow,return,returns-nonnull-attribute,shift-base,shift-exponent,signed-integer-overflow,unreachable,vla-bound,vptr
[llvm-bugs] Issue 7048 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-earlycse: ASSERT: (!LastStore || ParseMemoryInst(LastStore, TTI).getPointerOperand() == MemInst.ge
Updates: Labels: Deadline-Approaching Comment #3 on issue 7048 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-earlycse: ASSERT: (!LastStore || ParseMemoryInst(LastStore, TTI).getPointerOperand() == MemInst.ge https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7048#c3 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] Issue 7044 in oss-fuzz: llvm/llvm-demangle-fuzzer: Stack-overflow in Db::parseName
Updates: Labels: Deadline-Approaching Comment #3 on issue 7044 by sheriff...@chromium.org: llvm/llvm-demangle-fuzzer: Stack-overflow in Db::parseName https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7044#c3 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] Issue 7040 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in AnalyzeImplicitConversions
Updates: Labels: Deadline-Approaching Comment #3 on issue 7040 by sheriff...@chromium.org: llvm/clang-fuzzer: Stack-overflow in AnalyzeImplicitConversions https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7040#c3 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 35343] [ASan/Win] lld-link doesn't link ASAN binaries
https://bugs.llvm.org/show_bug.cgi?id=35343 Reid Kleckner changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Reid Kleckner --- I think this comment describes the LLD wholearchive bug (https://llvm.org/pr37592): > I actually figured out the right way: Seemingly binaries need asan-x86_64 and > asan_cxx-x86_64 (and they need to be specified a second time with > -wholearchive:, which I could only do with MSVC's linker and not LLD, it > seems), We can close this in favor of that. Other than that, ASan works with LLD. Peter Hosek is working on the alternative multi-arch runtime library layout, and when we have that, this should address the other usability concern. *** This bug has been marked as a duplicate of bug 37592 *** -- 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 8861 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-strength_reduce: ASSERT: !BaseReg->isZero() && "Zero allocated in a base register!"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.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 Proj-llvm Reported-2018-06-13 Type: Bug New issue 8861 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-strength_reduce: ASSERT: !BaseReg->isZero() && "Zero allocated in a base register!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8861 Detailed report: https://oss-fuzz.com/testcase?key=6195708003614720 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-strength_reduce Fuzz target binary: llvm-opt-fuzzer--x86_64-strength_reduce Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !BaseReg->isZero() && "Zero allocated in a base register!" LSRInstance::InsertFormula LSRInstance::GenerateAllReuseFormulae Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201806110750:201806120754 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6195708003614720 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 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. -- 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 26428] LICM: Ignore loop exits which don't exit on first iteration when computing isGuaranteedToExecute
https://bugs.llvm.org/show_bug.cgi?id=26428 listm...@philipreames.com changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Assignee|ovm...@gmail.com|listm...@philipreames.com --- Comment #6 from listm...@philipreames.com --- Closing the bug as support was implemented a while back. There are some next steps which would be nice to pursue, let me summarize them: 1) pipe SCEV through LICM and down into MustExecute. This lets us handle much more complicated cases than the current Constants and SimplifyInstruction approach. 2) figure out a way to efficiently handle implicit control flow (i.e. handle cases where potentially faulting instructions only run on the second iteration down some rare path...) I'd been working on this, but have basically given up now and approached my original problem from a different angel. -- 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 8820 in oss-fuzz: llvm/clangd-fuzzer: Null-dereference READ in clang::clangd::runLanguageServerLoop
Updates: Labels: Fuzz-Blocker Comment #2 on issue 8820 by ClusterFuzz-External: llvm/clangd-fuzzer: Null-dereference READ in clang::clangd::runLanguageServerLoop https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8820#c2 This crash occurs very frequently on linux platform and is likely preventing the fuzzer clangd-fuzzer from making much progress. Fixing this will allow more bugs to be found. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37774] Incorrect result at self-comparison of uninitialized value
https://bugs.llvm.org/show_bug.cgi?id=37774 rtr...@google.com changed: What|Removed |Added Resolution|--- |INVALID CC||rtr...@google.com Status|NEW |RESOLVED --- Comment #1 from rtr...@google.com --- This is working as intended. A read from uninitialized memory has undefined behavior. When a program runs into undefined behavior, anything can happen. The optimizer detects that the condition is only evaluated after undefined behavior has happened. Because of that, it removes the if-branch and executes the else-branch unconditionally. -- 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 37784] New: clang does not define __GNUC_GNU_INLINE__
https://bugs.llvm.org/show_bug.cgi?id=37784 Bug ID: 37784 Summary: clang does not define __GNUC_GNU_INLINE__ Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: ndesaulni...@google.com CC: lloz...@chromium.org, llvm-bugs@lists.llvm.org, manojgu...@google.com, srhi...@google.com In the linux kernel, we prefer to use gnu89 semantics for extern inline functions. Writing a feature test for the attribute gnu_inline should be straightforward, except that gcc did not get __has_attribute until 5.1. Instead, older versions of gcc define __GNUC_GNU_INLINE__ if that attribute is supported. It seems that clang does not, which makes writing a feature test a little wonky: #ifdef __GNUC_GNU_INLINE__ #define __gnu_inline __attribute__((gnu_inline)) #else #define __gnu_inline #warning "No gnu inline" #endif produces a warning in clang. We can likely work around this via: #ifndef __has_attribute // Optional of course. #define __has_attribute(x) 0 // Compatibility with non-clang compilers. #endif #if defined(__GNUC_GNU_INLINE__) || __has_attribute(gnu_inline) #define __gnu_inline __attribute__(gnu_inline) #endif -- 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 37785] New: [MIPS][LLD] Debug Build Test Failures Due to Assert
https://bugs.llvm.org/show_bug.cgi?id=37785 Bug ID: 37785 Summary: [MIPS][LLD] Debug Build Test Failures Due to Assert Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: gbrey...@gmail.com CC: llvm-bugs@lists.llvm.org The following tests fail when testing a debug build, this appears to be due to an assert in std::stable_sort, raised due to an invalid comparator: lld :: ELF/mips-26-n32-n64.s lld :: ELF/mips-26.s lld :: ELF/mips-64-disp.s lld :: ELF/mips-64-got.s lld :: ELF/mips-dynamic.s lld :: ELF/mips-dynsym-sort.s lld :: ELF/mips-elf-flags.s lld :: ELF/mips-got-and-copy.s lld :: ELF/mips-got-extsym.s lld :: ELF/mips-got-weak.s lld :: ELF/mips-gp-disp-ver.s lld :: ELF/mips-hilo-gp-disp.s lld :: ELF/mips-lo16-not-relative.s lld :: ELF/mips-mgot.s lld :: ELF/mips-micro-got.s lld :: ELF/mips-micro-got64.s lld :: ELF/mips-micro-jal.s lld :: ELF/mips-micro-plt.s lld :: ELF/mips-options.s lld :: ELF/mips-plt-copy.s lld :: ELF/mips-plt-n32.s lld :: ELF/mips-plt-r6.s lld :: ELF/mips-reginfo.s lld :: ELF/mips-sto-plt.s lld :: ELF/mips-tls-64.s lld :: ELF/mips-tls.s lld :: ELF/mips64-eh-abs-reloc.s -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37784] clang does not define __GNUC_GNU_INLINE__
https://bugs.llvm.org/show_bug.cgi?id=37784 Nick Desaulniers changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID -- 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 37782] New: --discard-all is not supported with -r output
https://bugs.llvm.org/show_bug.cgi?id=37782 Bug ID: 37782 Summary: --discard-all is not supported with -r output Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org In normal links, the --discard* family of options throws away certain symbols, depending on the nature of the output and which exact switch is specified. We do not support this switch at all for relocatable output. At least for some situations, there is no reason not to, that I'm aware of. This seems to have been implemented as the fix to bug 31252, which prevents any discarding for relocatable output, to prevent discarding of certain temporary symbols. Whilst this behaviour should be the default, it shouldn't, in my opinion, be the behaviour when --discard* switches are explicitly specified. Note that ld.bfd follows a different approach: // test.s .local local local: ret .global global global: ret > clang -c test.s > ld.lld -r --discard-all test.o -o test.ro > llvm-objdump -t test.ro test.ro:file format ELF64-x86-64 SYMBOL TABLE: *UND* .text local ld .text .text ld .data .data ld .bss .bss 0001 .text global > ld.bfd -r --discard-all test.o -o test.ro > llvm-objdump -t test.ro test.ro:file format ELF64-x86-64 SYMBOL TABLE: *UND* ld .text .text ld .data .data ld .bss .bss 0001 .text global Note that "local" has not been discarded. -- 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 19808] Pointer-to-member conversion to bool considered indistinguishable from conversion to non-bool
https://bugs.llvm.org/show_bug.cgi?id=19808 Erich Keane changed: What|Removed |Added Fixed By Commit(s)||334503 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Erich Keane --- Fixed in 334503 -- 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 37781] New: Support output with many sections
https://bugs.llvm.org/show_bug.cgi?id=37781 Bug ID: 37781 Summary: Support output with many sections Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org LLD does not currently correctly support output when there are >= 0xff00 sections. The first problem I noticed was that the e_shstrndx field was corrupt (the index had been truncated). I didn't investigate any other issues. Although with a full link such output is very unlikely, relocatable (-r) output could easily result in many sections being present, e.g. due to -ffunction-sections output. Without fixing this issue, LLD and other binary tools cannot consume such an output. -- 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 37783] New: canTrackGlobalVariableInterprocedurally doesn't consider every kind of volatile user
https://bugs.llvm.org/show_bug.cgi?id=37783 Bug ID: 37783 Summary: canTrackGlobalVariableInterprocedurally doesn't consider every kind of volatile user Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Interprocedural Analyses Assignee: unassignedb...@nondot.org Reporter: matthew.arsena...@amd.com CC: llvm-bugs@lists.llvm.org This function is specifically looking for volatile loads and stores, but this ignores other possible volatile uses, such as atomicrmw, memcpy/memset or other target intrinsics -- 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
