c++/1665: derived inner class template

c++/1665: derived inner class template

[sylvain.gommier]

>Number:         1665
>Category:       c++
>Synopsis:       derived inner class template
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 16 04:56:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     sylvain.gommier@m4x.org
>Release:        2.95.3 from gcc-c++-2.95.2-12mdk.i586.rpm
>Organization:
>Environment:
Mandrake Linux 7.2 (kernel 2.2.17, glibc 2.1.3)
>Description:
'internal compiler error' when declaring a class in a class template, when that inner class is itself deriving from another class
>How-To-Repeat:
g++ template.cpp -o template breaks on line 80
>Fix:
of course, move that inner class out of the template, but I think it is legal to write what I wrote ..?
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="template.cpp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="template.cpp"

Ly8gdGVtcGxhdGUuY3BwCi8vIHN5bHZhaW4uZ29tbWllckBtNHgub3JnCi8vIGRlcml2ZWQgaW5u
ZXIgY2xhc3MgYnVnIHRlbXBsYXRlCgovLyBnKystIC0tdmVyc2lvbj0yLjk1LjMgZnJvbSBnY2Mt
YysrLTIuOTUuMi0xMm1kay5pNTg2LnJwbQovLyBnKysgdGVtcGxhdGUuY3BwIC1vIHRlbXBsYXRl
Ci8vIE1hbmRyYWtlIExpbnV4IDcuMiAoa2VybmVsIDIuMi4xNywgZ2xpYmMgMi4xLjMpIG9uIEFN
RCBLNi0yCi8vICdpbnRlcm5hbCBjb21waWxlciBlcnJvcicgb24gbGluZSA4MCAoc2VhcmNoIGZv
ciAnQlVHJykKCiNpbmNsdWRlIDxpb3N0cmVhbS5oPgoKLy8gLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQov
LyBCQVNJQyBCQVNFIENMQVNTCgpjbGFzcyBCYXNlIHsKcHVibGljOgogIEJhc2UoKSB7fQp9OwoK
Ly8gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQovLyBERVJJVkVEIElOTkVSIENMQVNTIChOTyBCVUcpCgpj
bGFzcyBGb28gewpwdWJsaWM6CiAgRm9vKCkge30KCiAgY2xhc3MgU3ViOwp9OwoKLy8gaW1wbGVt
ZW50YXRpb24gb2YgdGhlIG5ldyBleGNlcHRpb24gYnkgaW5oZXJpdGFuY2UKY2xhc3MgRm9vOjpT
dWI6CiAgcHVibGljIEJhc2UgewoKcHVibGljOgogIFN1YigpOiBCYXNlKCkge30KfTsKCi8vIC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KLy8gU0FNRSBQTFVTIEEgTkFNRVNQQUNFIChOTyBCVUcpCgpjbGFz
cyBOYW1lc3BhY2UgewogIGNsYXNzIEJhcjsKfTsKCmNsYXNzIE5hbWVzcGFjZTo6QmFyIHsKcHVi
bGljOgogIEJhcigpIHt9CgogIGNsYXNzIFN1YjsKfTsKCmNsYXNzIE5hbWVzcGFjZTo6QmFyOjpT
dWI6CiAgcHVibGljIEJhc2UgewoKcHVibGljOgogIFN1YigpOiBCYXNlKCkge30KfTsKCi8vIC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KLy8gREVSSVZFRCBJTk5FUiBDTEFTUyBURU1QTEFURSAoSEVSRSBJ
VCBJUykKCnRlbXBsYXRlIDxjbGFzcyBUPgpjbGFzcyBGb29iYXIgewpwdWJsaWM6CiAgRm9vYmFy
KCkge30KCiAgY2xhc3MgU2ltcGxlOwogIGNsYXNzIFN1YjsKfTsKCnRlbXBsYXRlIDxjbGFzcyBU
PgpjbGFzcyBGb29iYXI8VD46OlNpbXBsZSB7CnB1YmxpYzoKICBTaW1wbGUoKTsKfTsKCi8vIEJV
RzogdGhlIGZvbGxvd2luZyBjbGFzcyBkZWNsYXJhdGlvbiBjYXVzZXMgYW4gJ2ludGVybmFsIGNv
bXBpbGVyIGVycm9yJwp0ZW1wbGF0ZSA8Y2xhc3MgVD4KY2xhc3MgRm9vYmFyPFQ+OjpTdWI6CiAg
cHVibGljIEJhc2UgewpwdWJsaWM6CiAgU3ViKCk6IEJhc2UoKSB7fQp9OwoKLy8gLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQppbnQgbWFpbigpIHsKICByZXR1cm4gMDsKfQo=
>From rth@redhat.com Sun Apr 01 00:00:00 2001
From: Richard Henderson <rth@redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c/1824: gcc accepts computed goto's + -fprofile-arcs, gcov barfs
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010201012601.13033.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00850.html
Content-length: 771

The following reply was made to PR c/1824; it has been noted by GNATS.

From: Richard Henderson <rth@redhat.com>
To: lucier@math.purdue.edu
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c/1824: gcc accepts computed goto's + -fprofile-arcs, gcov barfs
Date: Wed, 31 Jan 2001 17:21:29 -0800

 On Wed, Jan 31, 2001 at 10:00:17PM -0000, lucier@math.purdue.edu wrote:
 > So what gives?  Has this error been removed by mistake?
 > Does gcov now support computed gotos, and is this a bug?
 
 Almost certainly what happened is when the profile-arcs support in the
 compiler was rewritten, it was updated to handle computed gotos.  Or
 rather, by using the provided CFG information rather than creating its
 own, it Just Worked.
 
 On the other hand, gcov hasn't been touched...
 
 
 r~
>From paul@dawa.demon.co.uk Sun Apr 01 00:00:00 2001
From: paul@dawa.demon.co.uk
To: gcc-gnats@gcc.gnu.org
Subject: java/1828: error if function arg list erronously followed by a semi-colon
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010201134623.9408.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00854.html
Content-length: 1240

>Number:         1828
>Category:       java
>Synopsis:       error if function arg list erronously followed by a semi-colon
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          ice-on-illegal-code
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 01 05:56:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     paul@dawa.demon.co.uk
>Release:        unknown-1.0
>Organization:
>Environment:
linux
>Description:
Given the code below gcj gives an incomprehensable error
message and a compiler error eg

$ gcj -c ~/Test.java 
/home/paul/Test.java:6: Tree check: expected class 'e', have 'x' (identifier_node)
/home/paul/Test.java:6: Internal compiler error in finish_method_declaration, at parse.y:4589
Please submit a full bug report, with preprocessed source if appropriate.
See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.

Note the "extra" semi-colon after the getString method,
this is quite common when cut-n-pasting definitions
from interfaces

public class Test 
{
    public Test() {
    }

    public String getString();
    {
	return "";
    }
}
>How-To-Repeat:
as above
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
>From Franz.Sirl-kernel@lauterbach.com Sun Apr 01 00:00:00 2001
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c/2100: -fstrength-reduce (is active with -O2) produces wrong code
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010228001601.1440.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01807.html
Content-length: 2901

The following reply was made to PR optimization/2100; it has been noted by GNATS.

From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: dllorens@inf.uji.es
Cc: gcc-gnats@gcc.gnu.org,gcc-bugs@gcc.gnu.org
Subject: Re: c/2100: -fstrength-reduce (is active with -O2) produces
  wrong code
Date: Wed, 28 Feb 2001 01:12:33 +0100

 At 17:29 26.02.2001, dllorens@inf.uji.es wrote:
 
 > >Number:         2100
 > >Category:       c
 > >Synopsis:       -fstrength-reduce (is active with -O2) produces wrong code
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    unassigned
 > >State:          open
 > >Class:          wrong-code
 > >Submitter-Id:   net
 > >Arrival-Date:   Mon Feb 26 08:36:03 PST 2001
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     David Llorens
 > >Release:        gcc version 2.95.2 19991024 (release)
 > >Organization:
 > >Environment:
 >Linux 2.2.16-3smp
 > >Description:
 >The -fstrength-reduce optimization flag (which is active
 >with the common -O2 option), produces wrong code.
 >
 >I have tested two gcc versions, both fail:
 >  - gcc version 2.95.2 19991024 (release)
 >  - egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
 
 Wow, this seems to be a long-standing bug in check_final_value()/loop.c, 
 the testcase shows it nicely on x86-linux. Look at this check in 
 check_final_value():
 
    if ((final_value = final_giv_value (loop, v))
        && (v->always_computable || last_use_this_basic_block (v->dest_reg, 
 v->insn)))
      {
 
 We reach here with this GIV for posGreatest:
 
 (gdb) p *v
 $8 = {insn = 0x8271228, new_reg = 0x0, src_reg = 0x82704dc, giv_type = 
 DEST_REG, dest_reg = 0x827054c, location = 0x0,
    mode = SImode, mem_mode = 135364066, mult_val = 0x822b6a8, add_val = 
 0x822b6a0, benefit = 1, final_value = 0x0,
    combined_with = 0, replaceable = 0, not_replaceable = 0, ignore = 0, 
 always_computable = 0, always_executed = 0,
    maybe_multiple = 0, cant_derive = 1, maybe_dead = 0, auto_inc_opt = 0, 
 unrolled = 0, shared = 0, no_const_addval = 1,
    lifetime = 38, derive_adjustment = 0x0, next_iv = 0x8274bac, same = 0x0, 
 derived_from = 0x0, const_adjust = -1073747912,
    ix = 0, same_insn = 0x0, last_use = 0x0}
 
 That means last_use_this_basic_block() gets called and correctly detects 
 that this is the last use of the GIV until the next CODE_LABEL. But this 
 check is apparently not strong enough :-( for this kind of loop. Because 
 check_final_value() returns TRUE for this GIV, posGreatest is _always_ 
 assigned the final value of the loop minus 1 after the loop, which in this 
 case breaks the surrounding loop.
 
 Possible fixes:
 - don't check last_use_this_basic_block() at all in check_final_value()
 - don't call last_use_this_basic_block() for GIVs of type DEST_REG (hmm?)
 - check the surrounding loop (if any) for uses of the GIV too?
 
 Opinions?
 
 Franz.