* [Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
2009-09-02 14:26 [Bug fortran/41227] New: COMMON block, BIND(C) and LTO interoperability issues burnus at gcc dot gnu dot org
@ 2009-09-14 21:05 ` burnus at gcc dot gnu dot org
2009-09-28 19:59 ` tobi at gcc dot gnu dot org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: burnus at gcc dot gnu dot org @ 2009-09-14 21:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from burnus at gcc dot gnu dot org 2009-09-14 21:05 -------
In any case gcc/dwarf2out.c needs to be modified. It currently has:
fortran_common (tree decl, HOST_WIDE_INT *value)
{ [...]
if (TREE_CODE (val_expr) != COMPONENT_REF)
return NULL_TREE;
However, one needs to create a DW_TAG_common_block which contains a
DW_TAG_variable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
2009-09-02 14:26 [Bug fortran/41227] New: COMMON block, BIND(C) and LTO interoperability issues burnus at gcc dot gnu dot org
2009-09-14 21:05 ` [Bug fortran/41227] " burnus at gcc dot gnu dot org
@ 2009-09-28 19:59 ` tobi at gcc dot gnu dot org
2010-01-29 17:46 ` burnus at gcc dot gnu dot org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: tobi at gcc dot gnu dot org @ 2009-09-28 19:59 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from tobi at gcc dot gnu dot org 2009-09-28 19:58 -------
The way usually recommended is to use a struct for interoperability with
Fortran common blocks, say http://support.microsoft.com/kb/51614
Unfortunately, the idiom "use a single variable common block, say common/x/y,
access it via the name of the common block, followed by an underscore, say x_"
is also common. At least in my workplace it's the way everybody uses.
In other words, we can't afford to break either way.
--
tobi at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tobi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
2009-09-02 14:26 [Bug fortran/41227] New: COMMON block, BIND(C) and LTO interoperability issues burnus at gcc dot gnu dot org
2009-09-14 21:05 ` [Bug fortran/41227] " burnus at gcc dot gnu dot org
2009-09-28 19:59 ` tobi at gcc dot gnu dot org
@ 2010-01-29 17:46 ` burnus at gcc dot gnu dot org
2010-02-02 10:29 ` burnus at gcc dot gnu dot org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: burnus at gcc dot gnu dot org @ 2010-01-29 17:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from burnus at gcc dot gnu dot org 2010-01-29 17:45 -------
I have now asked at comp.lang.fortran:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c00efc5679b6a879
(In reply to comment #2)
> The way usually recommended is to use a struct for interoperability with
> Fortran common blocks, say http://support.microsoft.com/kb/51614
That matches - for multiple variables in the block - the Fortran 2003 standard.
> Unfortunately, the idiom "use a single variable common block, say common/x/y,
> access it via the name of the common block, followed by an underscore, say x_"
> is also common. At least in my workplace it's the way everybody uses.
That matches what Fortran 2003 says about a single variable.
> In other words, we can't afford to break either way.
Well, as long as you do not use LTO it does not seem to matter. And if LTO you
have to decide for "struct" or against "struct". (And as a user, use BIND(C) -
either with COMMON or with TYPE - and you get a well-defined result.)
I am leaning towards using a "struct" only when there are multiple variables,
which makes BIND(C) and non-BIND(C) behave identical. If the overwhelming
opinion is differently, one can still add a "&& attr->is_bind_c".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
2009-09-02 14:26 [Bug fortran/41227] New: COMMON block, BIND(C) and LTO interoperability issues burnus at gcc dot gnu dot org
` (2 preceding siblings ...)
2010-01-29 17:46 ` burnus at gcc dot gnu dot org
@ 2010-02-02 10:29 ` burnus at gcc dot gnu dot org
2010-02-11 16:29 ` burnus at gcc dot gnu dot org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: burnus at gcc dot gnu dot org @ 2010-02-02 10:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from burnus at gcc dot gnu dot org 2010-02-02 10:28 -------
Test case:
gfortran -flto bind_c_coms_driver.c bind_c_coms.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
2009-09-02 14:26 [Bug fortran/41227] New: COMMON block, BIND(C) and LTO interoperability issues burnus at gcc dot gnu dot org
` (3 preceding siblings ...)
2010-02-02 10:29 ` burnus at gcc dot gnu dot org
@ 2010-02-11 16:29 ` burnus at gcc dot gnu dot org
2010-02-23 9:08 ` burnus at gcc dot gnu dot org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: burnus at gcc dot gnu dot org @ 2010-02-11 16:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from burnus at gcc dot gnu dot org 2010-02-11 16:29 -------
Also asked at:
http://gcc.gnu.org/ml/fortran/2010-02/msg00010.html
a) The derived-type issue (cf. PR 41664) is now fixed.
b) Regarding COMMON w/ single item in the named COMMON (F2003, 15.3); unclear
whether it is supposed to interoperate with both the single C variable and the
struct or only with the former. I have now asked at
http://j3-fortran.org/pipermail/j3/2010-February/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
2009-09-02 14:26 [Bug fortran/41227] New: COMMON block, BIND(C) and LTO interoperability issues burnus at gcc dot gnu dot org
` (4 preceding siblings ...)
2010-02-11 16:29 ` burnus at gcc dot gnu dot org
@ 2010-02-23 9:08 ` burnus at gcc dot gnu dot org
2010-02-23 9:33 ` rguenther at suse dot de
2010-06-03 13:49 ` rguenth at gcc dot gnu dot org
7 siblings, 0 replies; 9+ messages in thread
From: burnus at gcc dot gnu dot org @ 2010-02-23 9:08 UTC (permalink / raw)
To: gcc-bugs
------- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
2009-09-02 14:26 [Bug fortran/41227] New: COMMON block, BIND(C) and LTO interoperability issues burnus at gcc dot gnu dot org
` (5 preceding siblings ...)
2010-02-23 9:08 ` burnus at gcc dot gnu dot org
@ 2010-02-23 9:33 ` rguenther at suse dot de
2010-06-03 13:49 ` rguenth at gcc dot gnu dot org
7 siblings, 0 replies; 9+ messages in thread
From: rguenther at suse dot de @ 2010-02-23 9:33 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
2009-09-02 14:26 [Bug fortran/41227] New: COMMON block, BIND(C) and LTO interoperability issues burnus at gcc dot gnu dot org
` (6 preceding siblings ...)
2010-02-23 9:33 ` rguenther at suse dot de
@ 2010-06-03 13:49 ` rguenth at gcc dot gnu dot org
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-06-03 13:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from rguenth at gcc dot gnu dot org 2010-06-03 13:48 -------
Mine. See http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02424.html for an
outline for a possible fix.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2010-06-03 13:48:44
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
^ permalink raw reply [flat|nested] 9+ messages in thread