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

[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues



------- 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 (fortran@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


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