public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: java/4775
@ 2001-11-21 2:56 Bryce McKinlay
0 siblings, 0 replies; 3+ messages in thread
From: Bryce McKinlay @ 2001-11-21 2:56 UTC (permalink / raw)
To: apbianco; +Cc: gcc-prs
The following reply was made to PR java/4775; it has been noted by GNATS.
From: Bryce McKinlay <bryce@waitaki.otago.ac.nz>
To: apbianco@cygnus.com
Cc: gcc-gnats@gcc.gnu.org, mlhartme@mlhartme.de, gcc-bugs@gcc.gnu.org
Subject: Re: java/4775
Date: Tue, 27 Nov 2001 16:25:08 +1300
Alexandre Petit-Bianco wrote:
>>I'm curious why the second part of this patch is neccessary
>>
>
>Last time I checked (some time ago, I'd have to re-check,) proper
>finals initialization is carried out by checking that at least a ctor
>in the chain of call will initialize a final properly. So it's faster
>and prevents things from breaking when regular non static methods are
>being found invoked in ctor bodies...
>
But regular method calls can just be ignored, right? They are not
allowed to initialize finals anyway. I don't see why TREE_CODE (decl) !=
FUNCTION_DECL needs to be an error condition.
Also it seems fragile to check explicitly the tree structure of the call
(eg the NOP_EXPR etc), because that could change, so why not just do this?
@@ -12670,8 +12665,10 @@
if (TREE_CODE (decl) != FUNCTION_DECL)
decl = TREE_OPERAND (TREE_OPERAND (decl, 0), 0);
- if (TREE_CODE (decl) != FUNCTION_DECL)
- abort ();
+ /* Skip something that isn't a call to a ctor */
+ if ((TREE_CODE (decl) == FUNCTION_DECL && !DECL_CONSTRUCTOR_P
(decl))
+ || TREE_CODE (decl) != FUNCTION_DECL)
+ return -1;
if (DECL_FUNCTION_ALL_FINAL_INITIALIZED (decl))
return 1;
if (DECL_FINIT_P (decl) || DECL_CONTEXT (decl) != current_class)
regards
Bryce.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: java/4775
@ 2001-11-21 2:53 Alexandre Petit-Bianco
0 siblings, 0 replies; 3+ messages in thread
From: Alexandre Petit-Bianco @ 2001-11-21 2:53 UTC (permalink / raw)
To: apbianco; +Cc: gcc-prs
The following reply was made to PR java/4775; it has been noted by GNATS.
From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: Bryce McKinlay <bryce@waitaki.otago.ac.nz>
Cc: apbianco@gcc.gnu.org, gcc-gnats@gcc.gnu.org, mlhartme@mlhartme.de,
gcc-bugs@gcc.gnu.org
Subject: Re: java/4775
Date: Mon, 26 Nov 2001 18:44:19 -0800 (PST)
Bryce McKinlay writes:
> I'm curious why the second part of this patch is neccessary
Last time I checked (some time ago, I'd have to re-check,) proper
finals initialization is carried out by checking that at least a ctor
in the chain of call will initialize a final properly. So it's faster
and prevents things from breaking when regular non static methods are
being found invoked in ctor bodies...
./A
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: java/4775
@ 2001-11-21 2:49 Bryce McKinlay
0 siblings, 0 replies; 3+ messages in thread
From: Bryce McKinlay @ 2001-11-21 2:49 UTC (permalink / raw)
To: apbianco; +Cc: gcc-prs
The following reply was made to PR java/4775; it has been noted by GNATS.
From: Bryce McKinlay <bryce@waitaki.otago.ac.nz>
To: apbianco@gcc.gnu.org, gcc-gnats@gcc.gnu.org, mlhartme@mlhartme.de,
gcc-bugs@gcc.gnu.org
Cc:
Subject: Re: java/4775
Date: Tue, 27 Nov 2001 15:10:20 +1300
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=4775&database=gcc
I'm curious why the second part of this patch is neccessary, but in any
case, it would be nice to get this checked in, since re-merging with the
latest collections code from classpath depends on it.
regards
Bryce.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-11-27 3:26 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-11-21 2:56 java/4775 Bryce McKinlay
-- strict thread matches above, loose matches on Subject: below --
2001-11-21 2:53 java/4775 Alexandre Petit-Bianco
2001-11-21 2:49 java/4775 Bryce McKinlay
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).