Infinitely long compilation

Infinitely long compilation

[Martin Kahlert]

Hi!
With gcc-20020325 my application cannot be compiled any more.
gcj seems to loop forever for a quite standard input file.
This only happens on Solaris 2.7, not on my Linux box.

Has anybody else seen such an error? I could try to debug it,
but i do not want to spend a lot of time when such an error
has been fixed already.

Thanks,
Martin.

-- 
The early bird catches the worm. If you want something else for       
breakfast, get up later.

Re: Infinitely long compilation

[Bryce McKinlay]

Martin Kahlert wrote:

>With gcc-20020325 my application cannot be compiled any more.
>gcj seems to loop forever for a quite standard input file.
>This only happens on Solaris 2.7, not on my Linux box.
>
>Has anybody else seen such an error? I could try to debug it,
>but i do not want to spend a lot of time when such an error
>has been fixed already.
>

I saw a PR which mentions something similar, also on Solaris but on GCJ 
3.0.1. Is this the same issue?

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6071&return_url=http%3A%2F%2Fgcc.gnu.org%2Fcgi-bin%2Fgnatsweb.pl%3Fdatabase%3Dgcc%26cmd%3Dsubmit%2520query%26category%3Djava%26severity%3Dall%26priority%3Dall%26responsible%3Dall%26submitter_id%3Dall%26state%3Dall%26ignoreclosed%3DIgnore%2520Closed%26class%3Dall%26synopsis%3D%26multitext%3D%26columns%3Dcategory%26columns%3Dstate%26columns%3Dclass%26columns%3Dresponsible%26columns%3Dsynopsis%26displaydate%3DDisplay%2520Current%2520Date%26sortby%3DResponsible%26.cgifields%3Dcolumns%26.cgifields%3Doriginatedbyme%26.cgifields%3Ddisplaydate%26.cgifields%3Dignoreclosed

regards

Bryce.

Re: Infinitely long compilation

[Martin Kahlert]

Hi Bryce,
thanks for your reply,

On Thu, Mar 28, 2002 at 07:12:33PM +1200, Bryce McKinlay wrote:
> Martin Kahlert wrote:
> 
> >With gcc-20020325 my application cannot be compiled any more.
> >gcj seems to loop forever for a quite standard input file.
> >This only happens on Solaris 2.7, not on my Linux box.
> >
> >Has anybody else seen such an error? I could try to debug it,
> >but i do not want to spend a lot of time when such an error
> >has been fixed already.
> >
> 
> I saw a PR which mentions something similar, also on Solaris but on GCJ 
> 3.0.1. Is this the same issue?
> 
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6071&return_url=http%3A%2F%2Fgcc.gnu.org%2Fcgi-bin%2Fgnatsweb.pl%3Fdatabase%3Dgcc%26cmd%3Dsubmit%2520query%26category%3Djava%26severity%3Dall%26priority%3Dall%26responsible%3Dall%26submitter_id%3Dall%26state%3Dall%26ignoreclosed%3DIgnore%2520Closed%26class%3Dall%26synopsis%3D%26multitext%3D%26columns%3Dcategory%26columns%3Dstate%26columns%3Dclass%26columns%3Dresponsible%26columns%3Dsynopsis%26displaydate%3DDisplay%2520Current%2520Date%26sortby%3DResponsible%26.cgifields%3Dcolumns%26.cgifields%3Doriginatedbyme%26.cgifields%3Ddisplaydate%26.cgifields%3Dignoreclosed

Looks very different to me.

I look into it a bit deeper, now, seems to be something inside parse.y(do_resolve_class).

Regards,
Martin.

-- 
The early bird catches the worm. If you want something else for       
breakfast, get up later.

Re: Infinitely long compilation

[Bryce McKinlay]

Martin Kahlert wrote:

>Looks very different to me.
>
>I look into it a bit deeper, now, seems to be something inside parse.y(do_resolve_class).
>

Hmm, if this is a recent regression, can you try this fix for a bug in 
my last patch, which I'm about to check in:

Index: parse.y
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/parse.y,v
retrieving revision 1.366
diff -u -r1.366 parse.y
--- parse.y     2002/03/28 04:28:22     1.366
+++ parse.y     2002/03/28 07:33:51
@@ -7034,7 +7034,8 @@
 resolve_package (pkg, next, type_name)
      tree pkg, *next, *type_name;
 {
-  tree current, decl;
+  tree current;
+  tree decl = NULL_TREE;
   *type_name = NULL_TREE;
 
   /* The trick is to determine when the package name stops and were


regards

Bryce.

Re: Infinitely long compilation

[Martin Kahlert]

Hi Bryce,
turned out that the problem was fast to find out.
I do not know, how to make this patch correct in the gcc-way,
but it works for me. The problem is this:

If you have a name foo.bar you replace it by foo@bar,
try that for an identifier and then change the name back to foo.bar.
If it was not an identifier, do the same again....

Perhaps the line
*separator = c;
could simply be left out, but i do not know, whether the original name
will be used later. So i made the changes on a private copy.

Thanks for your help,
Martin.


PS: The patch is against gcc-20020325.

2002-03-28  Martin Kahlert  <martin.kahlert@infineon.com>

	* parse.y (do_resolve_class): Fix infinite recursion

--- parse.y.old	Thu Mar 28 08:33:56 2002
+++ parse.y	Thu Mar 28 08:50:42 2002
@@ -5852,18 +5852,22 @@
      applicable and use the matching DECL instead. */
   if (!decl_result && QUALIFIED_P (TYPE_NAME (class_type)))
     {
+      char *namebuffer;
+
       tree name = TYPE_NAME (class_type);
+
+      namebuffer = alloca(strlen(IDENTIFIER_POINTER (name))+1);
+      strcpy(namebuffer, IDENTIFIER_POINTER (name));
+
       char *separator;
       do {
 
        /* Reach the last '.', and if applicable, replace it by a `$' and
           see if this exists as a type. */
-       if ((separator = strrchr (IDENTIFIER_POINTER (name), '.')))
+       if ((separator = strrchr (namebuffer, '.')))
          {
-           int c = *separator;
            *separator = '$';
-           name = get_identifier (IDENTIFIER_POINTER (name));
-           *separator = c;
+           name = get_identifier (namebuffer);
            decl_result = IDENTIFIER_CLASS_VALUE (name);
          }
       } while (!decl_result && separator);

-- 
The early bird catches the worm. If you want something else for       
breakfast, get up later.

Re: Infinitely long compilation

[Martin Kahlert]

Hi Bryce,


On Thu, Mar 28, 2002 at 07:34:57PM +1200, Bryce McKinlay wrote:
> Martin Kahlert wrote:
> 
> >Looks very different to me.
> >
> >I look into it a bit deeper, now, seems to be something inside parse.y(do_resolve_class).
> >
> 
> Hmm, if this is a recent regression, can you try this fix for a bug in 
> my last patch, which I'm about to check in:
> 
> Index: parse.y
> ===================================================================
> RCS file: /cvs/gcc/egcs/gcc/java/parse.y,v
> retrieving revision 1.366
> diff -u -r1.366 parse.y
> --- parse.y     2002/03/28 04:28:22     1.366
> +++ parse.y     2002/03/28 07:33:51
> @@ -7034,7 +7034,8 @@
>  resolve_package (pkg, next, type_name)
>       tree pkg, *next, *type_name;
>  {
> -  tree current, decl;
> +  tree current;
> +  tree decl = NULL_TREE;
>    *type_name = NULL_TREE;
>  
>    /* The trick is to determine when the package name stops and were

Sorry, but the code in gcc-20020325 looks different:
  tree current, acc;
  tree type_name = NULL_TREE;
  const char *name = IDENTIFIER_POINTER (EXPR_WFL_NODE (pkg));

...

Perhaps your bug is younger than that.

Thanks anyway,
Martin.

PS: I do not have any clue, why the bug only shows on Solaris.

-- 
The early bird catches the worm. If you want something else for       
breakfast, get up later.

Re: Infinitely long compilation

[Alexandre Petit-Bianco]

Martin Kahlert writes:

> Perhaps the line *separator = c; could simply be left out,

Yes it should, as we're progressively changing the name.

I just re-organized your patch to what's below, gave it a try and I'm
now going to check it in.

Thanks,

2002-03-29  Martin Kahlert  <martin.kahlert@infineon.com>

       * parse.y (do_resolve_class): Fix infinite recursion

Index: parse.y
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/parse.y,v
retrieving revision 1.368
diff -u -p -r1.368 parse.y
--- parse.y     2002/03/29 21:58:49     1.368
+++ parse.y     2002/03/29 22:10:21
@@ -5868,18 +5868,20 @@ do_resolve_class (enclosing, class_type,
      applicable and use the matching DECL instead. */
   if (!decl_result && QUALIFIED_P (TYPE_NAME (class_type)))
     {
-      tree name = TYPE_NAME (class_type);
       char *separator;
+      tree name = TYPE_NAME (class_type);
+      char *namebuffer = alloca (IDENTIFIER_LENGTH (name) + 1);
+
+      strcpy (namebuffer, IDENTIFIER_POINTER (name));
+
       do {
 
        /* Reach the last '.', and if applicable, replace it by a `$' and
           see if this exists as a type. */
-       if ((separator = strrchr (IDENTIFIER_POINTER (name), '.')))
+       if ((separator = strrchr (namebuffer, '.')))
          {
-           int c = *separator;
            *separator = '$';
-           name = get_identifier (IDENTIFIER_POINTER (name));
-           *separator = c;
+           name = get_identifier (namebuffer);
            decl_result = IDENTIFIER_CLASS_VALUE (name);
          }
       } while (!decl_result && separator);