------- Comment #7 from rguenther at suse dot de 2010-02-23 09:33 ------- Subject: Re: COMMON block, BIND(C) and LTO interoperability issues
On Tue, 23 Feb 2010, burnus at gcc dot gnu dot org wrote: > ------- Comment #6 from burnus at gcc dot gnu dot org 2010-02-23 09:08 > ------- > Regarding my question, Toon ask this question to Bill Long @ Cray and Jim Xia > @ > IBM at the Las Vegas meeting of J3/WG5 - they came to different conclusions > ;-) > > Bill Long stated what he also wrote at > http://j3-fortran.org/pipermail/j3/2010-February/003358.html > > Namely: The "OR" is to be read as exclusive "OR": > > > Does a common block containing a single variable (e.g. of type > > > "integer(c_int)") need to be interoperable with the C variable ("int") > > > only [i.e. only (2)] > > > > Yes, this is my interpretation. > > Toon agreed more with Bill and commented: "I think this is due to the fact > that > - as every 'vendor' knows - the C compiler being the 'companion processor' (C > interoperability terminology) to its Fortran processor, it can allow > additional > interoperability (for instance, allow COMMON /blah/ I interoperate with struct > {int i;} blah;)." > > Thus, from the standard in a three-to-two-reading*, one only needs to > interoperate with the single variable and not with the struct. (* My reading, > Toon's, Bill's vs. Nick's (fort...@gcc) and Jim's.) -- Note: I have not > submitted an official interpretation request, for which all J3/WG5 members > have > to vote. > > I really wonder whether supporting both in LTO would be the better option > compared with changing it to a single variable in the frontend. That's certainly possible (though possibly not trivial - in fact part of it is already implemented, as in LTO doesn't complain about this inter-operation but later the optimizers might break things if you do not build with -fno-strict-aliasing). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
