search for: deadcod

...,-disable-opt -o output That should disable all LLVM optimizations. -- John T. > > 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, SPEC2k bzip2 has 79 functions, after these two steps, only > 61 functions are left. no other optimizations are used. > > 2) > I noticed that the inlining condition (in > Transforms/IPO/InlineSimple.cpp) is tested during llvm-gcc but not > during the...

...... 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, SPEC2k bzip2 has 79 functions, after these two steps, only 61 functions are left. no other optimizations are used. 2) I noticed that the inlining condition (in Transforms/IPO/InlineSimple.cpp) is tested during llvm-gcc but not during the opt phase ? Can anybody explain what hap...

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 @@

.... >> >> -- John T. >> >>> >>> 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, SPEC2k bzip2 has 79 functions, after these two steps, only >>> 61 functions are left. no other optimizations are used. >>> >>> 2) >>> I noticed that the inlining condition (in Transforms/IPO/InlineSimple.cpp) >>...

...ould disable all LLVM optimizations. > > -- John T. > >> >> 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, SPEC2k bzip2 has 79 functions, after these two steps, >> only 61 functions are left. no other optimizations are used. >> >> 2) >> I noticed that the inlining condition (in >> Transforms/IPO/InlineSimple.cpp) is tested during llvm-gcc...

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 Hemminger <stephen at networkplumber.org> Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/vhost.c | 2 +- 1 file changed...

...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 gmail.com> --- drivers/gpu/drm/nouveau/nvif/fifo.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvif/fifo.c b/drivers/gpu/drm/nouveau/nvif/fifo.c index a463289962b2..e96de14ce87e 1...

...n'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 gmail.com> > --- > drivers/gpu/drm/nouveau/nvif/fifo.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nvif/fifo.c b/drivers/gpu/drm/nouveau/nvif/fifo.c...

...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 gmail.com> >> --- >> drivers/gpu/drm/nouveau/nvif/fifo.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/nouveau/nvif/fifo.c b/drivers...

...files that the compiling process did are: llvm-2.8/Release/lib/libLLVMMSP430Info.a llvm-2.8/Release/lib/libLLVMMSP430AsmPrinter.a llvm-2.8/Release/lib/libLLVMMSP430CodeGen.a and none of them work. is It possible to load a backend as a new pass, for practicing I have worked on create passes like deadcode analysis and it is possible to load them with opt, but I don't know how to generate code for my new backend. Thank you. Best Regards Roberto 2011/5/10 Jim Grosbach <grosbach at apple.com> > Hi Roberto, > > The PIC24 family of devices share very little commonali...

...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 the result of the first infer_path in the second it is on the second call. The second bug is deadcode. The abs_dst variable has always been freed by the time the value is checked to call xfree before return. This patch fixes both bugs. This entire set of patches passed the regression tests on my system. Bug found by Coverity. Signed-off-by: Kylene Hall <kjhall at us.ibm.com> --- sftp....

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...

...ant 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 gmail.com> > > > --- > > > drivers/gpu/drm/nouveau/nvif/fifo.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/d...

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'

...gt; > try { > > x = a + b; > > maybe_throw(); > > return 0; > > } catch (int) { > > return x; > > } catch (float) { > > return x + 1; > > } > > } > > > > Do you need to worry that something like partial deadcode elimination > could want to move the definition of x down into the landing pad code (but > not all the way down into the catch handlers)? > > > > Or conversely, given something like > > > > int foo(int a, int b) { > > try { > > maybe_throw(); > &g...

...ug in getcifsacl.c. Signed-off-by: Jeff Layton <jlayton at samba.org> commit 930b724e784c28bd1b3024f7fc6ca24cdac82a4d Author: Jeff Layton <jlayton at samba.org> Date: Wed Oct 9 08:14:21 2013 -0400 getcifsacl: remove some dead code Coverity says: Error: DEADCODE (CWE-561): [#def5] cifs-utils-6.2/getcifsacl.c:101: assignment: Assigning: "mflags" = "false". cifs-utils-6.2/getcifsacl.c:109: const: At condition "mflags", the value of "mflags" must be equal to 0. cifs-utils-6.2/getcifsacl.c:109: dead_error_co...

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