similar to: [LLVMdev] Disabling assertions in llvm.org releases

On 06/20/2010 11:11 PM, Duncan Sands wrote: > Currently LLVM releases, as downloaded from llvm.org, have assertions enabled. > (I'm told Apple ships LLVM with assertions disabled, which is why I mention > llvm.org here). What do people think of disabling assertions? > > The advantage of disabling assertions is that LLVM runs faster. I don't know > how much faster. It

Hi Torok, > I am running with assertions enabled and it was very useful in finding > bugs on platforms I can't (or rarely) test on. > Had assertions been off I think bad/invalid code would have been > generated silently, resulting in a much harder to debug segfault. are you using the binaries supplied by llvm.org, or building yourself? There is a big difference between what is

Török Edwin schrieb: > Had assertions been off I think bad/invalid code would have been > generated silently, resulting in a much harder to debug segfault. Just a thought: how about distributing a "production build" with only the most important assertions active, and a "diagnostic build" that has all assertion checking on? In that case, if there's "funny

On 20 June 2010 22:03, Joachim Durchholz <jo at durchholz.org> wrote: > In that case, if there's "funny behaviour" in the generated code, people > can be instructed to try running their code through diagnostic build and > see whether it assertion checks. Userland don't tend to have source trees to build with diagnostic flags. Maybe if distributions had two

Hi Renato, > Btw, has anyone measured the delay of full assertions compared to no > assertions at all? We may be discussing over nothing... I measured the effect of turning assertions off when compiling a huge file (gcc.c from http://people.csail.mit.edu/smcc/projects/single-file-programs/) using dragonegg, and when using opt and llc on the unoptimized bitcode: * gcc-4.5+dragonegg -S

Hi Torok, I've used a hard-coded list on the input parameter and still got some output (slightly) scrambled between two different bots... INPUT = $(PROJ_SRC_DIR)/inputs/clam.cab \ $(PROJ_SRC_DIR)/inputs/clamdoc.tar.gz \ $(PROJ_SRC_DIR)/inputs/clam.exe \ $(PROJ_SRC_DIR)/inputs/clam.exe.bz2 \ $(PROJ_SRC_DIR)/inputs/clam-v2.rar \

On 04/03/2013 01:20 AM, Renato Golin wrote: > Hi Torok, > > I've used a hard-coded list on the input parameter and still got some output (slightly) scrambled between two different bots... > > I though the dbdir could be the culprit, but it has only one file. Attached is the output of both. > The version of ClamAV in the LLVM test-suite is quite old, and it first unpacks

On Wed, Apr 3, 2013 at 12:12 AM, Török Edwin <edwin+ml-debian at etorok.net> wrote: > On 04/03/2013 01:20 AM, Renato Golin wrote: >> Hi Torok, >> >> I've used a hard-coded list on the input parameter and still got some output (slightly) scrambled between two different bots... >> >> I though the dbdir could be the culprit, but it has only one file.

Very nice Torok! I applied most of the patch. A few comments: 1) What is your jni.h file? I can't compile the Jni.cpp file with your changes. 2) ISO C++ does not support %jd. x86_64 does not know about %lld? Thanks! Nicolas Török Edwin wrote: > Nicolas Geoffray wrote: > >> Hi everyone, >> >> I've just checked in a JVM and a CLI for LLVM (called JnJVM and N3).

Hi, This is true for release_34 and trunk. Disabling assertions makes the following tests pass: Unexpected Passing Tests (5): LLVM :: ExecutionEngine/2003-05-06-LivenessClobber.ll LLVM :: ExecutionEngine/2003-08-15-AllocaAssertion.ll LLVM :: ExecutionEngine/2003-08-23-RegisterAllocatePhysReg.ll LLVM :: ExecutionEngine/MCJIT/cross-module-sm-pic-a.ll LLVM ::

On 2009-09-24 22:34, hc2428 at columbia.edu wrote: > Dear developers, > When I try to map line numbers in source code back to LLVM > basicblocks, I meet some problems: there is a source file with 1500 > lines of code, but when I use BasicBlockPass to collect all > DbgStopPoint instructions in this file, I can only get 500 lines of code. > The source code and the collected

Nicolas Geoffray wrote: > Hi everyone, > > I've just checked in a JVM and a CLI for LLVM (called JnJVM and N3). > Both are placed in the vmkit svn directory. > You can find the source code here: > Very nice! > svn co http://llvm.org/svn/llvm-project/vmkit/trunk vmkit > > Its licensed under the U of I Open Source License, so now that's in svn, > you can

Hi Torok- > Could you also add a main() for each of these files, and do > a very simple test that the optimized functions actually work? Unfortunately, testing isolated C functions is much harder than just passing them random data! Consider this function: int foo (int x, int y) { return x+y; } The behavior of foo() is undefined when x+y overflows. If course it is trivial to come

Hi All, I recently learned that the RC binaries are built without assertions, the same way the actual releases are built. This seems like a serious bug to me. We should be looking for assertion failures during RC testing, not hiding them. So why are assertions disabled? I suggest we enable assertions in RC binaries right away. /Eric -------------- next part -------------- An HTML attachment was

On 04/02/2013 11:06 PM, Daniel Dunbar wrote: > On Tue, Apr 2, 2013 at 11:46 AM, Renato Golin <renato.golin at linaro.org <mailto:renato.golin at linaro.org>> wrote: > > On 2 April 2013 19:20, Daniel Dunbar <daniel at zuster.org <mailto:daniel at zuster.org>> wrote: > > What is it that makes the output of the program asynchronous? The output is

Hi Kenneth, > Well...strictly as LLVM IR I find externally visible incorrect behavior > unlikely, it's just a "different definition". For C and C++, I'd be > looking at more complicated variations of > > int main() > { > volatile int i = 1; > return 0; > } > > It's clear that the LLVM IR representation of i cannot be simply >

> I would argue that you should build the RC and the release the same way. I've had to fix bugs were someone had an assert with a side-effect, and the code with asserts turned off didn't work. OK, so it's clearly important to provide and test against RC's in the actual release configuration, especially since assertions can introduce bugs on their own. Arguably however

Hi folks, I've posted an updated code size comparison between LLVM, GCC, and others here: http://embed.cs.utah.edu/embarrassing/ New in this version: - much larger collection of harvested functions: more than 360,000 - bug fixes and UI improvements - added the x86 Open64 compiler John

I''m wondering what the accepted method for doing unit tests on STI models is. I tried to create a fixture for the class but Rails tries to load that data into the non-existent child table. I could create a fixture named for the real, parent table, but then it would be very difficult to test for the individual functionality and integrity of each sub-class. I saw this page

I''m trying to implement something in my app akin to 43things'' main page, where more active topics are bigger than the less active topics. The difference in my app is that I''m building a business-oriented app and want to have a list of clients, where clients with recent activity are larger than others. My perhaps too-clever way of going about this is by feeding each job