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

Re: error in g++ error report

[Jason Merrill]

>>>>> Gabriel Dos Reis <Gabriel.Dos-Reis@dptmaths.ens-cachan.fr> writes:

> PS: should this be a warning or an error ?

It's a pedwarn; if you use -pedantic-errors, it will be an error.

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: 473 bytes --]

>>>>> «Jason», Jason Merrill <jason@cygnus.com> wrote:


Jason> Funny, I get

Jason> wa.C: In function `int main()':
Jason> wa.C:10: warning: conversion from `const A' to `A &' discards const
Jason> wa.C:4: warning: in passing argument 1 of `A::A(A &)'

Jason> What version are you using?

Jason> Jason

	I used g++-2.7.2.2. I got the same warning with 

	egcs-2.90.03 970828 (gcc2-970802 experimental)

Good news.

-- Gaby
PS: should this be a warning or an error ?

Re: error in g++ error report

[Jason Merrill]

>>>>> Gabriel Dos Reis <Gabriel.Dos-Reis@dptmaths.ens-cachan.fr> writes:

> 	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'

Funny, I get

wa.C: In function `int main()':
wa.C:10: warning: conversion from `const A' to `A &' discards const
wa.C:4: warning: in passing argument 1 of `A::A(A &)'

What version are you using?

Jason

Re: error in g++ error report

[Alexandre Oliva]

Gabriel Dos Reis writes:

> % 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) ?

I don't think this is the serious part of this bug.  First of all, it
has nothing to do with base initialization, as the last line says, and
it should say that it is trying to match a `const A' with one of the
available constructors.  Maybe a special case should be created for
copy-constructors, though.  I'll take a look into this problem.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil