search for: nontermin

...ogic programming interpreter in R as done in LISP by G.F.Luger in his book or by Abelson & Sussman in "Structure and Interpreation of Computer Program". Thank you, Gabriel ### ### Examples ### > fib<-fibonacci.stream(0,1) Note that the fibonacci.stream() function is a nonterminating recursive function. It works only because of the delayed evaluation introduced by the delay() function in cons.stream() . It would not work if I implemented streams as simple list (see example at the very end of this posting). > head.stream(fib) # get the first element [1] 1 > ta...

# xl cpupool-create ''name="pool2" sched="credit2"'' command line:2: config parsing error near `sched'': syntax error, unexpected IDENT, expecting NEWLINE or '';'' Failed to parse config file: Invalid argument *** glibc detected *** xl: free(): invalid pointer: 0x0000000001a79a10 *** Segmentation fault (core dumped) Looking at the code

...t. > > this sounds like a manifestation of bug 965, see http://llvm.org/PR965 ah, you are quite right! I'd searched "recursion" to look for bugs, but the problem (as described in #965) is more general than that. (I'm quite familiar with Haskell, in which termination vs. nontermination is discussed much more than it is in C.) The optimization and the "willreturn" suggestion make sense to me. (Is it worth commenting on the bug-report? I guess not, since I don't actually have anything to add: it's already a clear bug with a clear solution: though perhap...

Hi I had observed the following problem in R (also C, Matlab, and Python). sprintf('%1.2g\n', 3.15) give 3.1 instead of 3.2 whereas an input of 3.75 gives 3.8. Java's System.out.printf is ok though. > round(3.75,1) [1] 3.8 > round(3.15,1) [1] 3.1 Similar outcome with sprintf in R. However, the right answer should be 3.2 Regards Teckpor [[alternative HTML version

Hi Isaac, > For fun, I made a recursive function, but LLVM optimized it wrong (if > I'm understanding C standards correctly). > > "void f() { f(); }"[see llvm-code in footnote 1] > was optimized to be equivalent to "void f() {}"[also 1]. I believe it > should either be equivalent in effect to "void f() { while(1){} }"[2], > which produces an

...mple:361: warning: implicit declaration of function `free' llvm[2]: Compiling item.c for Release build llvm[2]: Compiling lex.c for Release build llvm[2]: Compiling list.c for Release build llvm[2]: Compiling main.c for Release build llvm[2]: Compiling map.c for Release build llvm[2]: Compiling nonterminal.c for Release build llvm[2]: Compiling operator.c for Release build llvm[2]: Compiling pattern.c for Release build llvm[2]: Compiling plank.c for Release build llvm[2]: Compiling queue.c for Release build llvm[2]: Compiling rule.c for Release build llvm[2]: Compiling string.c for Release build ll...

...@@ union yyalloc #endif /* YYFINAL -- State number of the termination state. */ -#define YYFINAL 2 +#define YYFINAL 3 /* YYLAST -- Last index in YYTABLE. */ -#define YYLAST 23 +#define YYLAST 24 /* YYNTOKENS -- Number of terminals. */ #define YYNTOKENS 12 /* YYNNTS -- Number of nonterminals. */ -#define YYNNTS 9 +#define YYNNTS 11 /* YYNRULES -- Number of rules. */ -#define YYNRULES 19 +#define YYNRULES 22 /* YYNRULES -- Number of states. */ -#define YYNSTATES 28 +#define YYNSTATES 30 /* YYTRANSLATE(YYLEX) -- Bison symbol number corresponding to YYLEX. */ #define YY...

...s/Burg/b.h Index: utils/Burg/be.c Index: utils/Burg/burs.c Index: utils/Burg/closure.c Index: utils/Burg/delta.c Index: utils/Burg/fe.c Index: utils/Burg/fe.h Index: utils/Burg/item.c Index: utils/Burg/lex.c Index: utils/Burg/list.c Index: utils/Burg/main.c Index: utils/Burg/map.c Index: utils/Burg/nonterminal.c Index: utils/Burg/operator.c Index: utils/Burg/pattern.c Index: utils/Burg/plank.c Index: utils/Burg/queue.c Index: utils/Burg/rule.c Index: utils/Burg/string.c Index: utils/Burg/symtab.c Index: utils/Burg/table.c Index: utils/Burg/trim.c Index: utils/Burg/zalloc.c Index: utils/TableGen/Record....

I tried the LLVM demo with unmodified settings http://llvm.org/demo/index.cgi (same results from llvm 2.6 with clang, `clang-cc -emit-llvm -O2 test.c`, on my Linux x86_64) For fun, I made a recursive function, but LLVM optimized it wrong (if I'm understanding C standards correctly). "void f() { f(); }"[see llvm-code in footnote 1] was optimized to be equivalent to "void f()

...= 258, + YYWORD = 258, WILD_STR = 259, LOW = 260, OR = 261, @@ -67,7 +67,7 @@ }; #endif /* Tokens. */ -#define WORD 258 +#define YYWORD 258 #define WILD_STR 259 #define LOW 260 #define OR 261 @@ -437,7 +437,7 @@ First, the terminals, then, starting at YYNTOKENS, nonterminals. */ static const char *const yytname[] = { - "$end", "error", "$undefined", "WORD", "WILD_STR", "LOW", "OR", "AND", + "$end", "error", "$undefined", "YYWORD", "WILD_ST...

Hi Stepan, Sorry for the delay. It's great that you are working on MergeFunctions as well and I agree, we should definitely try to combine our efforts to improve MergeFunctions. Just to give you some context, the pass (with the similar function merging patch) is already being used in a production setting. From my point of view, it would be better if we focus on improving its capability

...340 0 0.02 88314 0 0.01 88314 newbh.ll 30 205828 0 0.02 205810 0 0.02 205810 newmdct.ll 5 165314 0 0.02 165283 0 0.03 165283 neworient.ll 1 18392 0 0.01 18359 0 0.01 18359 newton.ll 1 5663 0 0.01 5634 0 0.01 5634 newvor.ll 32 132156 0 0.02 132133 0 0.02 131127 node.ll 2 6852 0 0.01 6829 0 0.01 6829 nonterminal.ll 3 8374 0 0.01 8358 0 0.01 8358 NP.ll 8 8046 0 0.01 8019 0 0.01 8019 nsieve-bits.ll 1 8138 0 0.01 8114 0 0.01 8114 nullable.ll 2 19056 0 0.01 19030 0 0.01 19030 number.ll 24 189849 0 0.03 189829 0 0.03 189829 object.ll 26 138839 0 0.02 138816 0 0.02 126097 objects.ll 42 87564 0 0.02 87532 0 0.0...