On Fri, 2015-06-26 at 13:57 -0400, David Malcolm wrote:
> On Thu, 2015-06-25 at 13:16 -0600, Jeff Law wrote:
> > On 06/25/2015 01:13 PM, David Malcolm wrote:
> > >
> > >* It extends the libgccjit API. It's not clear to me yet how to
> > > manage extensions of the libgccjit API: should I u
On Thu, 2015-06-25 at 13:16 -0600, Jeff Law wrote:
> On 06/25/2015 01:13 PM, David Malcolm wrote:
> >
> >* It extends the libgccjit API. It's not clear to me yet how to
> > manage extensions of the libgccjit API: should I use symbol maps
> > and versioning, or bump the SONAME? I'm t
On Thu, 2015-06-25 at 21:47 +0200, Basile Starynkevitch wrote:
> On 06/25/2015 09:13 PM, David Malcolm wrote:
> > Some interpreters/VMs support a switch statement (for example the JVM
> > has opcodes "lookupswitch" and "tableswitch"). GCC has a set of
> > optimizations for efficiently handling swi
On 06/25/2015 09:13 PM, David Malcolm wrote:
Some interpreters/VMs support a switch statement (for example the JVM
has opcodes "lookupswitch" and "tableswitch"). GCC has a set of
optimizations for efficiently handling switch statements, so it makes
sense to directly expose switch statements in t
On 06/25/2015 01:13 PM, David Malcolm wrote:
* It extends the libgccjit API. It's not clear to me yet how to
manage extensions of the libgccjit API: should I use symbol maps
and versioning, or bump the SONAME? I'm thinking of providing
precanned feature macros within libgccji
Some interpreters/VMs support a switch statement (for example the JVM
has opcodes "lookupswitch" and "tableswitch"). GCC has a set of
optimizations for efficiently handling switch statements, so it makes
sense to directly expose switch statements in the libgccjit API.
This patch implements a swit
