similar to: [LLVMdev] Clang plugin for forward declaration warnings

Hi Apelete, Thanks for trying to help cleanup the LLVM codebase of Clang Static Analyzer warnings. But it seems a lot of the fixes that are being proposed are somewhat mechanical and may be doing the wrong thing in a few ways. * Initializing variables that are only used when initialized through some existing codepath - this can make tools like Memory Sanitizer less useful, because now the value

On Fri, May 6, 2016 at 3:09 AM, Apelete Seketeli <apelete at seketeli.net> wrote: > Hi David, > > On Thu, May-05-2016 at 11:20:06 AM -0700, David Blaikie wrote: > > Hi Apelete, > > > > Thanks for trying to help cleanup the LLVM codebase of Clang Static > > Analyzer warnings. > > > > But it seems a lot of the fixes that are being proposed are

Hi, Just for fun, I decided to run the svn r159506 llvm/clang/c++-analyzer on svn r159506 llvm-clang. I just thought that it might be interesting to run the analyzer on the llvm-clang codebase itself. I guess that most people on this list will probably have at least some knowledge of the llvm codebase, and be able to determine any false positives relatively easily ?. And for the truly

Commit-ID: 31ef3f49d4fd96b67b0e578c5f672fe428430b14 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=31ef3f49d4fd96b67b0e578c5f672fe428430b14 Author: Antonio Ospite <ao2 at ao2.it> AuthorDate: Sat, 15 Dec 2018 18:49:32 +0100 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 16:20:40 +0000 [klibc] dash: output: Fix clang warnings

Hey all, IWYU maintainer here. I wanted to make a small observation. Surprisingly, IWYU will most often *add* includes to a reasonably well-factored codebase, and this ties into Chris' comment: > Beyond that though, this seems like obvious > goodness to reduce coupling in the codebase. Just blindly removing includes will probably increase coupling, not reduce it, because it optimizes

Hi guys, Is the current setting of `AlwaysBreakTemplateDeclarations: false` for LLVMStyle intentional? What was the rationale? Some rough counts on the LLVM codebase: same-line: $ git grep -E 'template.*(class|struct).*{' -- '*.h' '*.cpp' | wc -l 214 (most of them are tiny traits classes, like isPodLike or DenseMapInfo) not-same-line: $ git grep -A1 -h

> To find which header files could be removed it scanned the file for "#include" lines and tried to remove them one by one (checking if the file still compiles after the removal). When there were no more include lines to remove, we verified the change with ninja+ninja check. It looks like this makes us rely heavily on transitive header includes -- is that right? Specifically what I

I am attempting to bring R-3.0.2 functionality into a project with a very large C++ codebase. The existing codebase already has a LENGTH function defined. R also defines a LENGTH function. I first compiled R as a shared library and linked it into this existing codebase, along with RInside. When I run a parseEvalQ with a linear model command it will stack dump. Looking at the backtrace, what is

> On Dec 29, 2016, at 11:20 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Dec 29, 2016 at 10:04 AM Mehdi Amini via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: >> On Dec 29, 2016, at 5:54 AM, Daniel Berlin <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> wrote: >> >>

I'm a bit confused by this whole discussion. clang-format is neither mandated (by documentation) nor enforced (by any infrastructure/automation) for use in the LLVM project that I know of. It's convenient, and in review people may reasonably ask authors to consider running it, etc - but we have no system that requires or checks for that. Might be nice, might not be. It sounds like even

I can confirm that the issue has been caused by NDEBUG flag. On Mon, Jul 13, 2015 at 6:29 PM Reid Kleckner <rnk at google.com> wrote: > The layout of AssertingVH has depended on NDEBUG since 2009, which > predates any of our efforts to make LLVM's ABI resilient to mismatched > NDEBUG definitions between LLVM and its users. > > For now, make sure your definition of NDEBUG

Dear Developers, I compile a OpenCL kernel, FFT, in AMDAPP SDK v2.5 using clang 3.8 + libclc and assembling the code with lld (The LLVM linker). The assembly code contains the following assembly codes (and lots of other similar format assembly) that fails to be parsed by AMDGPUAsmParser. It seems to me that both are valid instructions after looking at the SI instruction spec. s_mov_b32 s0,

I'm implementing this ability to switch between mips16 and mips32 on a per function basis. One issue that I've run into is regarding the DAGToDAGIsel pass. We have a different subclass for mips16 and non mips16 ( conceivably later there could be a separate one for micromips). I need to run a different pass depending on whether it's mips16 or mips32. My initial plan was to create

John, Thanks for making the results of the analyzer available. Ted has recently added IPA support for C++, so the number of bugs reported increased dramatically. In some cases our diagnostic clarity is still lagging behind for C++ bugs that span multiple functions (it's WIP). Cheers, Anna. On Jul 3, 2012, at 10:06 AM, John Smith wrote: > Hi, > > > Just for fun, I decided to

Hi, This is a tricky problem to search for on the llvmdev list as all the ways I can think of describing this seem to use pretty common keywords, so this may have been asked before. I'm looking for a way of importing or including existing function declarations or global variables into LLVM IR that I'm building manually using the API. These declarations are written in C++, so I guess

What are people are doing when they need to deploy a new code base? You can''t just restart backgroundrb, because then you lose any long-running backgroundrb processes. But then you''d conceivably have to wait several hours for all your procs to complete before pushing out the new code base. I was originally thinking that during code deploys, we''d start up a second

Hi, I am writing tool to simplify automated refactorings. One of prerequisites is have clean codebase, so a refactorer can be simple and created formatting inconsistencies can be eliminated by formatter. My plan to keep codebase clean is first run a cleanup systemwide, then keep it by hook/ periodicaly rerunning cleanup. I put it for now here. https://github.com/neleai/stylepp I ran a scripts

Hi All, After the initial learning curve, we're excited to have put together a completely gcc/binutils-free toolchain based on LLVM. Now that we have things working, we desperately need to optimize the resulting binaries. Our bin files are up to 10x their fully optimized gcc equivalent (1.5k vs 16k). This is for a bare metal ARM based system so this is significant. We're using lld for

Hi all, We somewhat recently created/updated element-wise unordered-atomic versions of the memcpy, memmove, and memset memory intrinsics: Memcpy: https://reviews.llvm.org/rL305558 Memmove: https://reviews.llvm.org/rL307796 Memset: https://reviews.llvm.org/rL307854 These intrinsics are semantically similar to the regular versions. The main difference is that the underlying operation is performed

Hello, interesting to hear. What version of NUT, what way of installation on Windows, what sort of UPS (USB or some other)? Asking because this info is lacking and currently there are a few variants to consider: * an MSI package based on NUT v2.6.5 (last released about 9 years ago as "2.6.5-6"), * results of re-integration of that codebase into current NUT master (some months after