similar to: [LLVMdev] [icFuzz] Help needed with analyzing randomly generated tests that fail on clang 3.4 trunk

On 24 June 2013 16:10, Haghighat, Mohammad R <mohammad.r.haghighat at intel.com > wrote: > Hi,**** > > ** ** > > I just submitted a bug report with a package containing 107 small test > cases that fail on the latest LLVM/clang 3.4 main trunk (184563). Included > are test sources, compilation commands, test input files, and results at > –O0 and –O2 when

Hi, I just submitted a bug report with a package containing 107 small test cases that fail on the latest LLVM/clang 3.4 main trunk (184563). Included are test sources, compilation commands, test input files, and results at -O0 and -O2 when applicable. http://llvm.org/bugs/show_bug.cgi?id=16431 These tests have been automatically generated by an internal tool at Intel, the Intel Compiler

Hi, I just submitted a bug report with a package containing 107 small test cases that fail on the latest LLVM/clang 3.4 main trunk (184563). Included are test sources, compilation commands, test input files, and results at –O0 and –O2 when applicable. http://llvm.org/bugs/show_bug.cgi?id=16431 These tests have been automatically generated by an internal tool at Intel, the Intel Compiler

Hi Moh, Thanks for this. I’m really glad to see the work you’re doing in this area and believe it will be extremely helpful in improving the quality of the compiler. -Jim On Jun 24, 2013, at 4:10 PM, Haghighat, Mohammad R <mohammad.r.haghighat at intel.com> wrote: > Hi, > > I just submitted a bug report with a package containing 107 small test cases that fail on the latest

Great job, Hal! Sure. I'd be happy to run icFuzz and report the fails once these bugs are fixed and thereafter whenever people want new runs. Obviously, this can be automated, but the problem is that icFuzz is not currently open sourced. Once there's a bug in the compiler, there's really no limit in the number of failing tests that can be generated, so it's more productive to run

Hi, I just submitted a bug report with a package containing 107 small test cases that fail on the latest LLVM/clang 3.4 main trunk (184563). Included are test sources, compilation commands, test input files, and results at -O0 and -O2 when applicable. http://llvm.org/bugs/show_bug.cgi?id=16431 These tests have been automatically generated by an internal tool at Intel, the Intel Compiler

The tests by design are syntactically correct, semantically correct, and have deterministic output. -moh From: Nick Lewycky [mailto:nlewycky at google.com] Sent: Monday, June 24, 2013 4:14 PM To: Haghighat, Mohammad R Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [icFuzz] Help needed with analyzing randomly generated tests that fail on clang 3.4 trunk On 24 June 2013 16:10, Haghighat,

----- Original Message ----- > > Hi Moh, > > > Thanks for this. I’m really glad to see the work you’re doing in this > area and believe it will be extremely helpful in improving the > quality of the compiler. > > > -Jim > > > > On Jun 24, 2013, at 4:10 PM, Haghighat, Mohammad R < > mohammad.r.haghighat at intel.com > wrote: > >

----- Original Message ----- > ----- Original Message ----- > > Great job, Hal! > > > > Sure. I'd be happy to run icFuzz and report the fails once these > > bugs > > are fixed and thereafter whenever people want new runs. Obviously, > > this can be automated, but the problem is that icFuzz is not > > currently open sourced. > > I would be

Hal, Just posted a package containing 214 small tests showing bugs in the latest Clang (3.4 trunk 187225) on MacOS X when compiled at -O2. http://llvm.org/bugs/show_bug.cgi?id=16431 These are new tests different from the previously posted ones, but their root causes could be the same as before or could actually be new bugs. Cheers, -moh -----Original Message----- From: llvmdev-bounces at

Hal, I ran the failing tests in the attachment to the bug 16431 on the latest clang trunk (version 3.4 trunk 187225). http://llvm.org/bugs/show_bug.cgi?id=16431 The following tests still fail: Tests in diff: t10236 t12206 t2581 t6734 t7788 t7820 t8069 t9982 All tests in InfLoopInClang: t19193 t22300 t25903 t27872 t33143 t8543 Meanwhile, I'll launch a new run

----- Original Message ----- > Hal, > > Just posted a package containing 214 small tests showing bugs in the > latest Clang (3.4 trunk 187225) on MacOS X when compiled at -O2. > http://llvm.org/bugs/show_bug.cgi?id=16431 > > These are new tests different from the previously posted ones, but > their root causes could be the same as before or could actually be > new

----- Original Message ----- > Great job, Hal! > > Sure. I'd be happy to run icFuzz and report the fails once these bugs > are fixed and thereafter whenever people want new runs. Obviously, > this can be automated, but the problem is that icFuzz is not > currently open sourced. I would be happy to see this open sourced, but I think that we can work something out regardless.

Hi Hal, Just submitted 27 failing tests on clang version 3.5, trunk 199158. http://llvm.org/bugs/show_bug.cgi?id=16431 I expect that these failures correspond to 2+ unique bugs. Cheers, -moh -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Thursday, January 09, 2014 6:01 AM To: Haghighat, Mohammad R Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [icFuzz] Help

Hi Karen, Thanks much for your comment and for sharing of your experience. icFuzz has a core that is "really" random, but does not cover the entire C space. The tool was designed from scratch to be extensible, and comes with a couple of extensions that target some of compiler optimizations optimizing compilers typically do: CSE, loop interchange, vectorization, etc. But even in the case

On Mon, Jun 24, 2013 at 11:20:09PM +0000, Haghighat, Mohammad R wrote: > The tests by design are syntactically correct, semantically correct, and have deterministic output. > > -moh Hi, I wanted to believe you had a randomized code generator that could cover the entire valid input space. (smiles ;) But the test cited was not generated by a randomized code generator. It is way too

I meant "yes", the tests are non-floating-point.

A small example before I begin my query: > educ <- read.table(efile, header=TRUE) > educ Education Age_Group Count 1 IncompleteHS 25-34 5416 2 IncompleteHS 35-44 5030 3 IncompleteHS 45-54 5777 4 IncompleteHS 55-64 7606 5 IncompleteHS >64 13746 6 CompletedHS 25-34 16431 7 CompletedHS 35-44 1855 8 CompletedHS 45-54 9435 9

Hey everybody! I have to use R's tm package to do some text analysis, first thing would be to create a term frequency matrix. Digging in tm's source code it seems like it uses some logic like this to create term frequencies: data("crude") (txt <- Content(crude[[1]])) (tokTxt <- unlist(strsplit(gsub("[^[:alnum:]]+", " ", txt), " ", fixed =

Hello All, I''d like to know if there is an utility like `Filefrag'' shipped with e2fsprogs on linux, which is used to fetch the extents mapping info of a file(especially a sparse file) located on ZFS? I am working on efficient sparse file detection and backup through lseek(SEEK_DATA/SEEK_HOLE) on ZFS, and I need to verify the result by comparing the original sparse file and