Re: A config patch

Re: A config patch

[Jason Merrill]

>>>>> Ian Lance Taylor <ian@cygnus.com> writes:

> I don't understand why it is important for [ -z "$PICFLAG" ] to
> succeed.  Irix 5 doesn't set PICFLAG, but I believe --enable-shared
> works nevertheless.

Yep, works for me.  It works on OSF/1, too.

Jason

Re: A vtable thunks bug.

[Jason Merrill]

>>>>> Mike Stump <mrs@wrs.com> writes:

>> From: Jason Merrill <jason@cygnus.com>
>> Date: 28 Aug 1997 17:42:41 -0700

>> In the -fno-vtable-thunks case, we build up a temporary vtable on the stack
>> and use that in the constructor.  We should be able to do the same thing
>> for -fvtable-thunks; looking at the current code, it seems unnecessarily
>> slow; as far as I can tell, all the values can be computed at compile time,
>> but g++ is computing them in the constructor.  Mike, am I missing anything?

> With the current codegen scheme, no the offsets can't be known at
> compile time.  If you introduce a binary incompatibility as in the
> below, then you can avoid the problem.

Yep, I realized that after I posted the above.  I imagine it would work to
decide on all the vtables in the most derived class and pass them down,
but that may not be very reasonable.

> If someone wants to do this, do vtable-thunks, normal vtables, and
> then the scheme used by other vendor's compilers.  Comparing against
> Sun's 4.x line, HP's newer compiler, Dec's, VC++ would give us a
> pretty good idea of what scheme is best.

I just tried to look at what HP does, and quickly decided not to bother
right now.  I've never found PA assembly particularly readable...

Jason

error in g++ error report

[Gabriel Dos Reis]

	Does egcs plan to fix this type of bug in g++-error-report ?

class A {
public:
    A() {}
    A(A&) {}
};

int main()
{
    const A a;
    A b = a;
}

% g++ toto.C
toto.C: In function `int main()':
toto.C:10: no matching function for call to `A::A (A)'
toto.C:3: candidates are: A::A()
toto.C:4:                 A::A(A &)
toto.C:10: in base initialization for class `A'


A::A(A) is not a constructor and one cannot declare such a function. So
why is g++ trying to call A::A(A) ?


Best,
-- Gaby

Re: a g++ bug in namespace code

[Jason Merrill]

>>>>> Kriang Lerdsuwanakij <lerdsuwa@scf-fs.usc.edu> writes:

> I looked at namespace codes in g++ and found a bug in unnamed namespace.

The current namespace code is not useful, and should be replaced, not
patched.

Jason

Re: error in g++ error report

[Gabriel Dos Reis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

>>>>> «Nelson», Nelson Jose dos Santos Ferreira <Nelson.Ferreira@inesc.pt> wrote:

Nelson> On Fri, 29 Aug 1997 10:00:36 +0200 (MET DST), Gabriel Dos Reis (aka "Gabriel"),
Nelson> regarding 'error in g++ error report', said: 

[...]

Gabriel> A::A(A) is not a constructor and one cannot declare such a function. So
Gabriel> why is g++ trying to call A::A(A) ?

Nelson> You should have declared the copy constructor as:

Nelson> A( const A& ) {}


	The omission was delibarate. The intent was to prevent
initialization with const object. And g++ fails to correctly handle
this code. It should have reported that the constructor A(const A&)
was unreachable.


Nelson> Since you didn't the const A a will prevent from calling your "copy
Nelson> constructor". The matching rules of C++ say that a const object may be passed
Nelson> to a function by value (taking a temporary object). 


	They also said that copy constructors always take a reference (not
a value), so g++ should not even attempt to call  A::A(A) which is not
a copy constructor.


-- Gaby

Re: error in g++ error report

[Gabriel Dos Reis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

>>>>> «Nelson», Nelson Jose dos Santos Ferreira <Nelson.Ferreira@inesc.pt> écrit :

Nelson> On Tue, 2 Sep 1997 11:47:10 +0200 (MET DST), Gabriel Dos Reis (aka "Gabriel"),
Nelson> regarding 'Re: error in g++ error report', said: 

Nelson> You should have declared A(A&) then.
Gabriel> Did you read the code I included ?

Nelson> Not on my second reply.


	Here it is:


class A {
public:
    A() {}
    A(A&) {}
};

int main()
{
    const A a;
    A b = a;
}


Gabriel> The draft is clear. If you do not declare a copy constructor
Gabriel> then the compiler generate one with bitwise copy semantic, whose
Gabriel> signature is:

Gabriel> A(const A&)

Gabriel> If at least one copy constructor is declared then it overrides the
Gabriel> default one unless it is defined. I am afraid you didn't get the
Gabriel> purpose of the code. Please read Alexandre Oliva's reply.

Nelson> How does this conflict with my answer ? I only said one answer would be for
Nelson> you to declare the copy constructor as private. Then the compiler will not
Nelson> generate the bitwise copy constructor!


	You 're right in saying that, but the compiler is wrong in
attempting to generate a copy constructor since there is already one!
If it is not suitable then it must give up with an appropriate
error-message. Take a look at the CD2 section 12.8.


Nelson> Probably I didn't get the purpose.

	My purpose was to see how g++ does handles this case. If I
want to initialize with non-const objects (but not with const objects)
then I can define only A(A&) and live A(const A&) not delcared. I do
not have to declare A(const A&) private. I should to so if no copy
constructor were declared

Best,

-- Gaby

a g++ bug in namespace code

[Kriang Lerdsuwanakij]

Hi,

I looked at namespace codes in g++ and found a bug in unnamed namespace.
The 'get_unique_name' function in 'cp/decl.c' starts replacing special
symbols with '_' at the 12th byte of the allocated buffer but the buffer
may be smaller than that.  It causes internal compiler error in my
system.  The following patch fixs the bug.

Kriang


* decl.c (get_unique_name): Prevent reading/writing outside the 
unique string when replacing chars to `_'.

--- decl.c.orig	Thu Aug 28 20:17:36 1997
+++ decl.c	Thu Aug 28 20:18:04 1997
@@ -1694,7 +1694,7 @@
   /* Don't need to pull weird characters out of global names.  */
   if (p != first_global_object_name)
     {
-      for (p = buf+11; *p; p++)
+      for (p = buf+2; *p; p++)
 	if (! ((*p >= '0' && *p <= '9')
 #ifndef NO_DOLLAR_IN_LABEL	/* this for `$'; unlikely, but... -- kr */
 	       || *p == '$'