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 #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=gccview=revrev=168610
Log:
2011-01-09 Janus Weil ja...@gcc.gnu.org
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 #25 from Tobias Burnus burnus at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #18 from Tobias Burnus burnus at gcc dot gnu.org 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
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 m,
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 #21 from Tobias Burnus burnus at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #22 from Tobias Burnus burnus at gcc dot gnu.org 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
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 burnus at gcc dot gnu.org 2010-12-16
08:37:16 UTC ---
Cf. also PR 46971
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 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
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 #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
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 direct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-09
18:16:06 UTC ---
I think one needs to add all names to the namespace:
module_subroutine_internal-sub_type
module_submodule-1_submodule-2_type
etc. (Note: This can give
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org 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,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #14 from Steve Kargl sgk at troutmask dot apl.washington.edu
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org 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
21 matches
Mail list logo
