Re: A patch for g++

Re: A patch for g++

[Andrew Macleod]

>> Hi,
>> 
>> Your change:
>> 
>> Tue May  5 18:24:13 EDT 1998  Andrew MacLeod  <amacleod@cygnus.com>
>>  
>> 	* method.c: Add a call to build_type_variant to get the right type.
>> 
>> breaks c++. A testcase is enclosed here. The patch below seems to fix
>> the bug for me. Can you take a look at it?

It was already broken.. this fixed some of it, but apparently not all, and
caused other things to break. Figures :-)

Thanks for the testcase and the patch. I elected to change the area where
the other TREE_USED flags are zeroed out instead, so its all done in
one place. I have applied the patch to egcs.

Andrew


>> BTW, is_java_type () is not declared anywhere.
>> 

It should be defined on line 1142 of method.c:

int
is_java_type (type)
     tree type;
{
...



(btw I applied the following:)
Index: method.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/cp/method.c,v
retrieving revision 1.190
diff -c -p -r1.190 method.c
*** method.c    1998/05/05 22:31:48     1.190
--- method.c    1998/05/07 21:24:26
*************** build_decl_overload_real (dname, parms,
*** 1620,1626 ****
            typevec = NULL;
            while (t)
              {
!               TREE_USED (TREE_VALUE (t)) = 0;
                t = TREE_CHAIN (t);
              }
          }
--- 1620,1631 ----
            typevec = NULL;
            while (t)
              {
!               tree temp = TREE_VALUE (t);
!               TREE_USED (temp) = 0;
!               /* clear out the type variant in case we used it */
!               temp = build_type_variant (TYPE_MAIN_VARIANT (temp),
!                     TYPE_READONLY (temp), TYPE_VOLATILE (temp));
!               TREE_USED (temp) = 0;
                t = TREE_CHAIN (t);
              }
          }

No prototype for is_java_type

[H.J. Lu]

> 
> 
> >> BTW, is_java_type () is not declared anywhere.
> >> 
> 
> It should be defined on line 1142 of method.c:
> 

But there is no prototype for is_java_type.


H.J.

Re: No prototype for is_java_type

[Jeffrey A Law]

  In message < m0yXfFm-000268C@ocean.lucon.org >you write:
  > > 
  > > 
  > > >> BTW, is_java_type () is not declared anywhere.
  > > >> 
  > > 
  > > It should be defined on line 1142 of method.c:
  > > 
  > 
  > But there is no prototype for is_java_type.
There are lots of prototypes missing.  Why don't you submit a patch
to fix some of them?

And please, don't resubmit the "mega patch" you did 8 months ago :-)

jeff

Re: No prototype for is_java_type

[H.J. Lu]

> There are lots of prototypes missing.  Why don't you submit a patch
> to fix some of them?
> 
> And please, don't resubmit the "mega patch" you did 8 months ago :-)
> 

Yes, I do have many prototype patches. Yes, I can send them one by
one. But I am not sure anyone has time to look at them. I don't want
to waste my time again. If anyone is interested in my prototype
patches, please let me know.

-- 
H.J. Lu (hjl@gnu.org)

Re: No prototype for is_java_type

[Jeffrey A Law]

  In message < m0yXoYo-000268C@ocean.lucon.org >you write:
  > > There are lots of prototypes missing.  Why don't you submit a patch
  > > to fix some of them?
  > > 
  > > And please, don't resubmit the "mega patch" you did 8 months ago :-)
  > > 
  > 
  > Yes, I do have many prototype patches. Yes, I can send them one by
  > one. But I am not sure anyone has time to look at them. I don't want
  > to waste my time again. If anyone is interested in my prototype
  > patches, please let me know.
If you'd take a look the one patch that you "un-megaized" did go in after
I fixed several problems with it (rtl.h prototyping).

jeff

Re: No prototype for is_java_type

[H.J. Lu]

> If you'd take a look the one patch that you "un-megaized" did go in after
> I fixed several problems with it (rtl.h prototyping).
> 

Before I send in many patches, what about the format of prototype?
I have seen many different ones for the new prototypes:

extern int foo PROTO((void));
extern int foo PROTO ((void));
extern int foo		PROTO ((void));
extern int foo		PROTO((void));

Does that mean any of above is ok now?

-- 
H.J. Lu (hjl@gnu.org)

Re: No prototype for is_java_type

[Jeffrey A Law]

  In message < m0yXq1l-000268C@ocean.lucon.org >you write:
  > > If you'd take a look the one patch that you "un-megaized" did go in after
  > > I fixed several problems with it (rtl.h prototyping).
  > > 
  > 
  > Before I send in many patches, what about the format of prototype?
  > I have seen many different ones for the new prototypes:
  > 
  > extern int foo PROTO((void));
  > extern int foo PROTO ((void));
  > extern int foo		PROTO ((void));
  > extern int foo		PROTO((void));
Either the second or third is the preferred format.  I personally
prefer the 3rd since it makes it much easier to read (IMHO).

It is also acceptable to format a prototype in a format identical to
those around it.  This is strictly a readability issue -- it does
not make much sense to have 20 consecutive prototypes of one format,
then one outlier of a different format.


jeff

A patch for g++

[H.J. Lu]

Hi,

Your change:

Tue May  5 18:24:13 EDT 1998  Andrew MacLeod  <amacleod@cygnus.com>
 
	* method.c: Add a call to build_type_variant to get the right type.

breaks c++. A testcase is enclosed here. The patch below seems to fix
the bug for me. Can you take a look at it?

BTW, is_java_type () is not declared anywhere.

Thanks.

-- 
H.J. Lu (hjl@gnu.org)
---
Thu May  7 07:36:26 1998  H.J. Lu  (hjl@gnu.org)

	* method.c (build_mangled_name): Clear the TREE_USED bit when
	it is used for the first time for the current function.

Index: method.c
===================================================================
RCS file: /home/work/cvs/gnu/egcs/gcc/cp/method.c,v
retrieving revision 1.1.1.26
diff -u -p -r1.1.1.26 method.c
--- method.c	1998/05/06 21:01:08	1.1.1.26
+++ method.c	1998/05/07 18:32:47
@@ -1051,6 +1051,17 @@ build_mangled_name (parmtypes, begin, en
         else 
           if (!nofold && typevec)
             {
+	      int i;
+
+	      /* Since we use build_type_variant () to get parmtype now,
+		 we may use an old one. We have to clear the TREE_USED
+		 bit when we first use it for this function. */
+	      for (i = 0; i < maxtype; i++)
+		if (typevec[i] == parmtype)
+		  break;
+	      if (i == maxtype)
+		TREE_USED (parmtype) = 0;
+
               /* Every argument gets counted.  */
               typevec[maxtype++] = parmtype;
 
--foo.cc---
typedef void (*Fix16_peh)(short&);
typedef void (*Fix24_peh)(int&);
typedef void (*Fix48_peh)(char&);
extern Fix16_peh set_Fix16_overflow_handler(Fix16_peh);
extern Fix24_peh set_Fix24_overflow_handler(Fix24_peh);
extern Fix48_peh set_Fix48_overflow_handler(Fix48_peh);

void
set_overflow_handler (Fix16_peh handler16, Fix24_peh handler24)
{
}

void
set_overflow_handler (Fix24_peh handler24, Fix48_peh handler48)
{
}