This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Thinking about libgccjit SONAME bump for gcc 5.2 (was Re: Four jit backports to gcc 5 branch)

On Mon, 2015-06-29 at 21:57 +0100, Dibyendu Majumdar wrote:
> On 29 June 2015 at 16:44, David Malcolm <> wrote:
> > I've gone over the changes to the gcc/jit and gcc/testsuite/jit.dg
> > directories in trunk since gcc 5 and backported the following 4 changes
> > from trunk to the gcc-5-branch:
> >
> > gcc-5-branch's r225123:
> >   * trunk's r222863 (8120405bda9bf222228b004e09b23e74eda57ae1, addition
> > of test-benchmark.c):
> >
> >
> >
> > gcc-5-branch's r225125:
> >   * trunk's r224531 (8154a3514d5fc8067a6928531d5f61cd768bd62c
> > along with trunk's r224535 (1828cd755cf5e4a34d5638f543a059f3562ad957,
> > "PR jit/66539: Add parentheses as needed to
> > gcc_jit_object_get_debug_string"):
> >
> >
> >
> > gcc-5-branch's r225127:
> >   * trunk's r224536 (3052eeefc4607a7147fdc55af6d86845890eb281, "jit: Add
> > a test for compound assignment"):
> >
> >
> >
> > gcc-5-branch's r225129:
> >   * trunk's r224565 (6689f47f53079d76bbb051d3b5da9018c2e0161a,
> > "jit: Add missing type-checking to gcc_jit_{l|r}value_access_field")
> >
> >
> >
> Hi Dave - is this what will go into 5.2?

No, it's just the things that I've backported so far.

> If so, is the option to
> disable "unreachable" block validation going to be available?

I'm working on that, I know that it's important to Ravi (the deadline
for gcc-5.2 is Friday; 2015-07-03).

There's no good way to track enums in binary metadata, so I'm currently
thinking of this approach for the new options:

 extern void
 gcc_jit_context_set_bool_allow_unreachable_blocks (gcc_jit_context *ctxt,
                                                    int bool_value);

tagging it within the linker mapfile as being a new API.

I'm looking at ways to manage libgccjit API/ABI as per this thread:
by transitioning to using symbol versioning, so that the linker can tag
subsets of libgccjit symbols in both libgccjit and in client binaries.

Adding symbol versioning will involve a SONAME bump (from
to, thus requiring anyone using libgccjit to recompile
for this one change (the transition to versioned symbols, that is);
hopefully we never need to bump the SONAME again.

Given that this is needed by Ravi I feel that this break is worth
backporting to gcc 5.2 (I'd rather do this one-time ABI break for the
benefit of specific users, than not do it out of concern for
hypothetical ones).

Hope this sounds sane.

As mentioned in that other thread, I'm wondering if linker experts could
advise on the sanity of using a feature-based naming scheme for symbol
map tags, rather than pure numbers?
etc (how long can they be, and is there a cost? can they include lower


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]