I've committed this to dmalcolm/jit:
gcc/jit/
* TODO.rst: Update.
---
gcc/jit/ChangeLog.jit | 4 ++
gcc/jit/TODO.rst | 116 ++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 117 insertions(+), 3 deletions(-)
diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 54953b6..162c3de 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,7 @@
+2013-10-17 David Malcolm <dmalc...@redhat.com>
+
+ * TODO.rst: Update.
+
2013-10-16 David Malcolm <dmalc...@redhat.com>
* TODO.rst (gcc_jit_context_new_local): Remove completed item.
diff --git a/gcc/jit/TODO.rst b/gcc/jit/TODO.rst
index d750b2a..f126fcc 100644
--- a/gcc/jit/TODO.rst
+++ b/gcc/jit/TODO.rst
@@ -1,25 +1,135 @@
-TODOs:
+TODOs
+-----
+Initial Release
+===============
* error-handling:
* have a client-provided error-handling callback for the context, and
call it, rather than asserting/crashing etc, to make the API resilient
and helpful
+* segfault seen in libbacktrace, when an ICE occurs
+
+* probably should turn off signal handlers and backtracing, leaving that to
+ the client code
+
+* enums and ABI: give enums specific numbers, in ranges, to make it
+ possible to maintain a logical ordering whilst preserving ABI.
+
* more language features:
* more types:
* unions
* function ptrs
+* how do you encode "x[5]=y;"? should gcc_jit_context_new_array_lookup()
+ return an lvalue rather than an rvalue?
+
+* separate out "x->field" from "x.field":
+ (x.field) = ...; : (lvalue, str) -> lvalue
+ ... = (x.field); : (rvalue, str) -> rvalue
+ (x->field) = ...; : (lvalue, str) -> lvalue
+ ... = (x->field); : (rvalue, str) -> rvalue
+
+* explicit dereferencing::
+
+ extern gcc_jit_lvalue *
+ gcc_jit_rvalue_dereference (gcc_jit_rvalue *);
+
+ for e.g. *ptr = 42;
+
+* explicit casts::
+
+ extern gcc_jit_rvalue *
+ gcc_jit_rvalue_cast (gcc_jit_rvalue *, gcc_jit_type *);
+
+ e.g. (void*) to (struct foo*)
+
+* access to more primitive types::
+
+ enum gcc_jit_types {
+ GCC_JIT_TYPE_SIGNED_INT,
+ // etc
+ };
+
+ extern gcc_jit_type *
+ gcc_jit_context_get_type (gcc_jit_context *,
+ enum gcc_jit_types type);
+
+* support more arithmetic ops and comparison modes
+
+* access to a function by address::
+
+ extern gcc_jit_function *
+ gcc_jit_context_get_function (ctxt,
+ void *); /* need type information */
+
+ so you can access "static" fns in your code.
+
+* ability to call an rvalue function pointer, perhaps keeping the
+ existing API to avoid needing to build a function ptr from a
+ function.
+
+* ability to turn a function into a function pointer::
+
+ gcc_jit_function_as_rvalue ()
+
+* clarify gcc_jit_function_add_eval()::
+
+ (void)expression;
+
+ and, indeed, clarify all of the other operations.
+
+* the C unary prefix "&" operator::
+
+ extern gcc_jit_rvalue *
+ gcc_jit_lvalue_get_address (gcc_jit_lvalue *lvalue);
+
+* array types, in case they're needed for structs::
+
+ extern gcc_jit_type *
+ gcc_jit_context_new_array_type (gcc_jit_context *ctxt,
+ gcc_jit_type *type,
+ int num_elements);
+
+* expressing branch probabilies (like __builtin_expect)::
+
+ extern gcc_jit_rvalue *
+ gcc_jit_rvalue_likely (gcc_jit_rvalue *rvalue,
+ int is_likely);
+
+ though would:
+
+ extern void
+ gcc_jit_function_set_likelihood (gcc_jit_function *func,
+ int hotness);
+
+ be better? (for expressing how hot the current location is)
+
+* can we call into GCC builtins? What might people need?
+
* docs
* fixing all the state issues
* make the dirty dirty hacks less egregious...
-* try porting llvmpipe to gcc
-
* pkgconfig .pc file
* add a SONAME to the library (and potentially version the symbols?)
+* add myself as maintainer
+
+* valgrind; fix memory leaks
+
+
+Future milestones
+=================
+* try porting llvmpipe to gcc
+
+* fuzz testing
+
+* inline assembler?
+
+* measure code coverage in testing of libgccjit.so
+
etc etc
--
1.7.11.7
