https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
janus at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #25 from Tobias Burnus 2011-01-09
12:34:08 UTC ---
(In reply to comment #24)
> r168610 contains the patch from comment #20 which fixes comment #19.
>
> Is there anything left to do here, or should we finally close this one?
I think
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #24 from janus at gcc dot gnu.org 2011-01-09 10:43:24 UTC ---
r168610 contains the patch from comment #20 which fixes comment #19.
Is there anything left to do here, or should we finally close this one?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #23 from janus at gcc dot gnu.org 2011-01-09 10:35:56 UTC ---
Author: janus
Date: Sun Jan 9 10:35:50 2011
New Revision: 168610
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168610
Log:
2011-01-09 Janus Weil
PR fortran/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #22 from Tobias Burnus 2011-01-07
13:41:17 UTC ---
(In reply to comment #20)
> This is easily fixed by putting the first letter of the derived type name in
> upper case:
[...]
(In reply to comment #21)
> even with the patch for PR 41
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #21 from Tobias Burnus 2011-01-07
13:25:56 UTC ---
(In reply to comment #19)
> (In reply to comment #18)
> class(two_three), allocatable :: a1
> class(three), allocatable :: a2
> In the dump you can see that we end up with one vtab f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #20 from janus at gcc dot gnu.org 2011-01-07 12:58:07 UTC ---
(In reply to comment #19)
> In the dump you can see that we end up with one vtab for both types.
This is easily fixed by putting the first letter of the derived type name in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #19 from janus at gcc dot gnu.org 2011-01-07 12:16:34 UTC ---
(In reply to comment #18)
> Is there any issue left to be fixed? I think there isn't.
> (Except for an accepts-invalid diagnostic for comment 7 [module "m" vs.
> subroutine "
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #18 from Tobias Burnus 2011-01-07
09:28:37 UTC ---
(In reply to comment #17)
[...]
> This has been implemented as a fix for PR46971.
Is there any issue left to be fixed? I think there isn't.
(Except for an accepts-invalid diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #17 from janus at gcc dot gnu.org 2011-01-02 19:28:33 UTC ---
(In reply to comment #15)
> Maybe it is really time to use hashed strings? One could void them for strings
> which are shorter and only hash for longer strings (starting with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #16 from Tobias Burnus 2010-12-16
08:37:16 UTC ---
Cf. also PR 46971
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #15 from Tobias Burnus 2010-11-09
18:42:52 UTC ---
(In reply to comment #14)
> However, GFC_MAX_SYMBOL_LEN is only:
>GFC_MAX_SYMBOL_LEN*2+4 = 63*2+4 = 130 characters
Sorry, GFC_MAX_SYMBOL_LEN is only 63 characters. The other was
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #14 from Steve Kargl
2010-11-09 18:27:49 UTC ---
On Tue, Nov 09, 2010 at 05:59:17PM +, janus at gcc dot gnu.org wrote:
>
> Index: gcc/fortran/class.c
> ===
> --- gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #13 from Tobias Burnus 2010-11-09
18:24:28 UTC ---
(In reply to comment #11)
> + char tmp[GFC_MAX_SYMBOL_LEN];
> + strcpy (&tmp[0], derived->name);
> + sprintf (string, "%s_%s", ns->proc_name->name, tmp);
> +
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #12 from Tobias Burnus 2010-11-09
18:16:06 UTC ---
I think one needs to add all names to the namespace:
___
___
etc. (Note: This can give extremely long variable names; I am not sure how
assemblers handle those.)
Note: I see a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #11 from janus at gcc dot gnu.org 2010-11-09 17:59:04 UTC ---
(In reply to comment #10)
> > One way to fix this is to use the top-level namespace (i.e. program or
> > module)
> > for the naming of the internal symbols, instead of the d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #10 from janus at gcc dot gnu.org 2010-11-09 17:07:24 UTC ---
(In reply to comment #9)
> One way to fix this is to use the top-level namespace (i.e. program or module)
> for the naming of the internal symbols, instead of the direct pare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #9 from janus at gcc dot gnu.org 2010-11-09 16:32:16 UTC ---
(In reply to comment #7)
> Here is an example code which still fails (analogous to comment #0):
One way to fix this is to use the top-level namespace (i.e. program or module)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #8 from Tobias Burnus 2010-11-09
13:51:39 UTC ---
For completeness: The issues reported in comment 0 were all [(a), (b), and (c)]
due to same problem: The internal class symbols only encoded the derived-type
name.
This has been fixed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
janus at gcc dot gnu.org changed:
What|Removed |Added
Summary|[OOP] OOP-ABI issue,|[OOP] class container
21 matches
Mail list logo
