https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rguenth at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #22 from Tobias Burnus ---
(In reply to rguent...@suse.de from comment #19)
> > Well, Bill Long of Cray seems to agree with my interpretation, cf.
> > http://mailman.j3-fortran.org/pipermail/j3/2010-February/003358.html
>
> But that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #21 from Francois-Xavier Coudert ---
(In reply to Tobias Burnus from comment #18)
> By your argument,
> int i;
> and
> struct { int i; } a;
> are interoperable.
No. The standard only defines interoperability as a one-to-one mappi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #20 from Tobias Schlüter ---
Let's please not invent new semantics. There are two things to distinguish:
1) legacy code, where no interoperability semantics were defined
2) new code, where the semantics are defined
I don't know much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #19 from rguenther at suse dot de ---
On Mon, 14 Jul 2014, burnus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
>
> --- Comment #17 from Tobias Burnus ---
> (In reply to Francois-Xavier Coudert from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #18 from Tobias Burnus ---
(In reply to Francois-Xavier Coudert from comment #14)
> (In reply to rguent...@suse.de from comment #13)
> > Does it need to inter-operate with
> > extern struct { struct { int i; } a; } a;
> No, I don't re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #17 from Tobias Burnus ---
(In reply to Francois-Xavier Coudert from comment #12)
> I disagree with Tobias' reading: it seems to me that the single-variable
> common block should be interoperable with both the single-common C struct
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #16 from Francois-Xavier Coudert ---
(In reply to Richard Biener from comment #15)
> Btw, what kind of single-elements can I expect? I suppose they can
> be arbitrary (so aggregate as well)?
>From the Fortran/C interop side, we can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #15 from Richard Biener ---
Ok, the warning is implemented with checking gimple type compatibility in
lto/lto-symtab.c:
if (!types_compatible_p (TREE_TYPE (prevailing->decl),
TREE_TYPE (decl)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #14 from Francois-Xavier Coudert ---
(In reply to rguent...@suse.de from comment #13)
> Does it need to inter-operate with
> extern struct { struct { int i; } a; } a;
No, I don't read anything in the standard that would allow this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #13 from rguenther at suse dot de ---
On Mon, 14 Jul 2014, fxcoudert at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
>
> --- Comment #12 from Francois-Xavier Coudert
> ---
> I disagree with Tobias' r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #12 from Francois-Xavier Coudert ---
I disagree with Tobias' reading: it seems to me that the single-variable common
block should be interoperable with both the single-common C struct and C
variable.
The Intel compiler makes both cas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #11 from Richard Biener ---
I think there is no good way apart from treating single-element structs equal
to its single element in LTO with regarding to TYPE_CANONICAL. At least not if
you want to inter-operate with both int i; and s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #9 from Richard Guenther 2012-01-05
13:37:09 UTC ---
This is still not fixed (at least by design -
bind_c_coms.f90/bind_c_coms_driver.c
passes with -flto now). Can somebody produce a reduced testcase pair that
just has a bind-C named
--- 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
---
--- 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
> ---
> Regard
--- 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-fortr
--- 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
--- 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
--- 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 interoperab
--- 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,
ac
--- 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 c
24 matches
Mail list logo
