On Fri, 2024-02-23 at 09:55 -0500, Antoni Boucher wrote: > I had forgotten to add the doc since there is now a new API. > Here it is.
Sorry for the delay; the updated patch looks good to me (but may need usual ABI tag changes when pushing). Thanks Dave > > On Wed, 2024-02-21 at 19:45 -0500, Antoni Boucher wrote: > > Thanks for the review. > > > > Here's the updated patch. > > > > On Thu, 2023-12-07 at 20:04 -0500, David Malcolm wrote: > > > On Thu, 2023-12-07 at 17:29 -0500, Antoni Boucher wrote: > > > > Hi. > > > > This patches update gcc_jit_context_new_array_type to take the > > > > size > > > > as > > > > an unsigned long instead of a int, to allow creating bigger > > > > array > > > > types. > > > > > > > > I haven't written the ChangeLog yet because I wasn't sure it's > > > > allowed > > > > to change the type of a function like that. > > > > If it isn't, what would you suggest? > > > > > > We've kept ABI compatibility all the way back to the version in > > > GCC > > > 5, > > > so it seems a shame to break ABI. > > > > > > How about a new API entrypoint: > > > gcc_jit_context_new_array_type_unsigned_long > > > whilst keeping the old one. > > > > > > Then everything internally can use "unsigned long"; we just keep > > > the > > > old entrypoint accepting int (which internally promotes the arg > > > to > > > unsigned long, if positive, sharing all the implementation). > > > > > > Alternatively, I think there may be a way to do this with symbol > > > versioning: > > > https://gcc.gnu.org/wiki/SymbolVersioning > > > see e.g. Section 3.7 of Ulrich Drepper's "How To Write Shared > > > Libraries", but I'm a bit wary of cross-platform compatibility > > > with > > > that. > > > > > > Dave > > > > > > > > >
