search for: deadcodes

Long Fei wrote: > > I am investigating some inlining issue, so I did > > llvm-gcc aaa.c bbb.c ... nnn.c -o output > opt -inline -inline-threshold=xxx < output.bc | llc -march=c > > output_inline.c I am unsure of whether the LLVM GCC frontend does any inlining. However, I do know that your methods above run the LLVM inlining pass, albeit indirectly. If you use

I am investigating some inlining issue, so I did llvm-gcc aaa.c bbb.c ... nnn.c -o output opt -inline -inline-threshold=xxx < output.bc | llc -march=c > output_inline.c 1) I noticed that even if I set xxx to 0 or even a very small negative number, many functions are eliminated. I am wondering if these functions are inlined by the frontend, or identified as deadcode. For instance,

Hello, we've run a coverity scan on the openssh sources and it found several issues. Although the scan was run on patched rhel sources, some results are applicable to vanilla sources too. * servconf.c:1458:dead_error_line ? Execution cannot reach this statement "*intptr = *intptr + 1;" --- a/servconf.c +++ b/servconf.c @@ -1451,12 +1451,8 @@

On Mon, 11 Jul 2005, Long Fei wrote: > > This didn't work as I tried with 197.parser. it works without > "-Wl,-disable-opt" switch though. > > [197.parser]$ llvm-gcc analyze-linkage.c and.c build-disjuncts.c > extract-links.c fast-match.c idiom.c main.c massage.c parse.c post-process.c > print.c prune.c read-dict.c utilities.c xalloc.c word-file.c

This didn't work as I tried with 197.parser. it works without "-Wl,-disable-opt" switch though. [197.parser]$ llvm-gcc analyze-linkage.c and.c build-disjuncts.c extract-links.c fast-match.c idiom.c main.c massage.c parse.c post-process.c print.c prune.c read-dict.c utilities.c xalloc.c word-file.c strncasecmp.c -Wa,-disable-opt -Wl,-disable-opt -lm -o llvm_parser [197.parser]$

When fail, translate_desc() returns negative value, otherwise the number of iovs. So we should fail when the return value is negative instead of a blindly check against zero. Detected by CoverityScan, CID# 1442593: Control flow issues (DEADCODE) Fixes: cc5e71075947 ("vhost: log dirty page correctly") Acked-by: Michael S. Tsirkin <mst at redhat.com> Reported-by: Stephen

The variable ret is being assigned a value but it isn't being read afterwards. The assignment is redundant and so ret can be removed. Cleans up clang scan build warning: warning: Although the value stored to 'ret' is used in the enclosing expression, the value is never actually read from 'ret' [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king at

On Tue, Jan 16, 2024 at 11:16:09AM +0000, Colin Ian King wrote: > The variable ret is being assigned a value but it isn't being > read afterwards. The assignment is redundant and so ret can be > removed. > > Cleans up clang scan build warning: > warning: Although the value stored to 'ret' is used in the enclosing > expression, the value is never actually read from

On 1/16/24 13:31, Dan Carpenter wrote: > On Tue, Jan 16, 2024 at 11:16:09AM +0000, Colin Ian King wrote: >> The variable ret is being assigned a value but it isn't being >> read afterwards. The assignment is redundant and so ret can be >> removed. >> >> Cleans up clang scan build warning: >> warning: Although the value stored to 'ret' is used in

Hi, I think this is a very ashamed question I have modified the version of the MSP430, after many problems it compiled, now I want to see is the changes generate what I want, but I don't know how for example with llc -march msp430 foo.ll -o newfoo.ll generates a file for the msp430 and actually did it. but I want to load my changes the --load option is supposed to do that, but the only new

There are several memory management bugs here. First, the variable tmp is allocated by infer_path. In one path this allocating function is called again on the same variable without freeing the first instance. In another path the variable is just not freed. The fix is to add the xfree before the second call to infer_path and to move the existing xfree to cover both paths (in one case this is on

On Thu, 7 Jul 2005, Henrik Bach wrote: > The 'pthread_once' is located in the native library binary file: > /usr/lib/libpthread.a. I've also included the path to the library in > LLVM_LIB_SEARCH_PATH environment variable. If libpthread.a is a static library, lli won't be successful loading it. Try relinking lli, but add this to its tools/lli/Makefile: TOOLLINKOPTS :=

+Aaron because i think he uses scan-build on Windows more or less successfully. I won't have time for setting up a Windows machine for myself in the nearest future. Could you tell us exactly what you're doing and what exactly does it print to console, more in the spirit of http://www.catb.org/~esr/faqs/smart-questions.html ? > scan-build: Not supported for windows. Exiting...

On Tue, Jan 23, 2024 at 12:04:23AM +0100, Danilo Krummrich wrote: > On 1/16/24 13:31, Dan Carpenter wrote: > > On Tue, Jan 16, 2024 at 11:16:09AM +0000, Colin Ian King wrote: > > > The variable ret is being assigned a value but it isn't being > > > read afterwards. The assignment is redundant and so ret can be > > > removed. > > > > > >

Hi LLVM'ers, I'm trying to build the DotGNU project with the LLVM-tools. After minor modifications of source and build code and some configure housekeeping, it seems that I've managed so far to build all the DotGNU tools. However, when extensively using the DotGNU tools I get this error message: make[1]: Entering directory `/home/hb/projects/build/LLVM/pnet-1-1/samples'

These are exactly the sorts of code transformations we want to allow by delaying the outlining until later. By keeping such code inlined in the parent function until after optimization, we enable a lot of core optimizations like SROA. For example, we should be able to completely eliminate wrappers like unique_ptr that would otherwise stay around due to the pointer escaped to the destructor call

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Time for a new cifs-utils release! The big bullet point in this release is a new pam_cifscreds module that has been added by Orion Poplawski. This release also cleans some unused cruft out of some of the binaries so they're quite a bit smaller now and fixes a few bugs that Coverity turned up. Go forth and download! webpage:

Hi Roberto, The PIC24 family of devices share very little commonality with PIC16 beyond the naming convention. They're a register-based 16-bit architecture, unlike the PIC16. That said, that does mean that LLVM is a much more reasonable fit to target the PIC24 (and dsPIC) than it is for PIC16. Modeling your target files after the MSP430 or Blackfin backend is likely your best bet to get up

I have been analyzing the implementation for some backend (PIC16, MIPS, SPARC and MSP430) my main problem is that they are so much different, I mean obviously they are describing different architectures, but the file structure is not the same. So it is difficult to get a pattern. I have checked the available documentation files, also the video from Cardoso about how to write a backend for the

Hi Reid, I’ve worked through a few scenarios, and I think this is converging. I’m attaching a new example, which extends the one we’ve been working through to handle a few more cases. I wasn’t sure what you intended the first i32 argument in an llvm.eh.actions entry to be. I’ve been using it as a place to store the eh state that I’m associating with the action, but that’s kind of circular