This is the mail archive of the gcc@gcc.gnu.org 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]

Re: How to grow the Fortran I/O parameter struct and keep ABI compatibility


On Nov 7, 2006, at 1:59 AM, FX Coudert wrote:
The idea is that common.flags has a bit for every possible member such as rec, to indicated whether it's present or not. The question is that we sometimes need to add another struct member (like rec) in this structure, to implement new features. I think we can add it at the end, since when code generated by older compilers calls the library, the flag for that new member is not set, and the struct member is never accessed.

Almost sounds reasonable.


Now, we also sometimes want to increase the size of the private stuff, and I don't see how we can do that in a way that keeps ABI compatibility, because the bits in the private stuff are always used by the library. So, I am missing something here or is there actually no way to keep that scheme and have ABI compatibility?

A layer of indirection can solve almost any problem:


st_parameter_dt *parm = __gfortran_st_parameter_dt_factory ();

The idea is that the only thing that constructs one, calls out to the library to construct it. If the library is updated, it can be updated for a new size to allocate as well. See the factory pattern. Also, this way, you don't need to pad it, nothing should know the size except for the library. If you shift fields around, just add accessors for the fields in the library. As the fields move around, the accessor code changes, but since it is in the library, hidden behind stable interfaces, it continues to work.

Note, once you add an interface, you're stuck with it forever. One you define an interface type, you're stuck with it forever.

Imagine LTO knowing the type, layout and size from a header file, squirreling that away in the filesystem, you update fortran compilers, the private stuff changes, LTO kicks in, the question is asked, is this the same type or different type, some optimizer person says, obviously different, the stuff in p (the private structure) are different, so now we generate bad code. :-( Either, the user can't use LTO that way, or you can't even change the private details that are exposed by headers.

I'd like to think that google can find a comprehensive set of rules for you to follow, does seem like we should have a pointer to such a page from our documentation. Maybe a glibc type can furnish such a pointer.


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