--- Additional Comments From lts-rudolph at gmx dot de 2004-12-03 08:39
---
I think you are not right :-)
The gcc docs say that it is possible to overwrite the abi with ffixed-reg!
It is also an example given (qsort) which comes from external library. The
examples says that you have
--- Additional Comments From falk at debian dot org 2004-12-03 09:13
---
Confirmed. I think we should even warn about this unconditionally and not
only with -pedantic.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-03
09:51 ---
Subject: Bug 18318
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-03 09:51:39
Modified files:
gcc/cp : ChangeLog init.c parser.c
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-03
09:52 ---
2004-12-02 Nathan Sidwell [EMAIL PROTECTED]
PR c++/18318
* parser.c (cp_parser_new_type_id): Move array size expression
checks from here ...
* init.c (build_new): ... to
The C++ FE holds class members in two vectors, a vector of overloaded methods
and a vector of fields and other stuff. This is bad
1) These vectors are unsorted until the class is complete
2) When sorted they have O(log N) performance, and N can get resonably big these
days
3) You have to look in
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-03
10:18 ---
Richard backported his fix for PR15289 (mentioned in comment #20)
to the 3.4 branch. This also fixed the problem when compiling
the testcase in comment #18 with -msse.
The problem compiling the testcase
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-03
10:24 ---
Patch submitted:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00255.html
--
What|Removed |Added
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-03
10:25 ---
Patch submitted:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00255.html
--
What|Removed |Added
--
What|Removed |Added
OtherBugsDependingO||17154
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18805
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-03
10:51 ---
2004-12-03 Nathan Sidwell [EMAIL PROTECTED]
PR c++/18782
* decl.c (grokdeclarator): Make sure class in pointer to member is
not a namespace.
--
What|Removed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-03
10:52 ---
Subject: Bug 18782
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-03 10:51:20
Modified files:
gcc/cp : ChangeLog decl.c
--
What|Removed |Added
AssignedTo|nathan at gcc dot gnu dot |unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED
compiling the following fragment:
typedef struct pseudoheader /* pseudo header for TCP checksum
calculations */
{
unsigned int sip, dip;
unsigned char zero;
unsigned char protocol;
unsigned short tcplen;
} ph_struct;
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-03
11:11 ---
Conisdering this not compiling Fortran at this point but C so I learning
towards miscompiling of the middle-end.
Oops! You're right, this is C. And it turns out this is not a miscompilation,
but a
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-03
11:15 ---
Subject: Bug 7305
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-03 11:15:25
Modified files:
libjava: ChangeLog Makefile.am Makefile.in
In a multithreaded application if I use a std::string in the thread I get a
coredump, but the coredump doesn't occur every time. The OS is Compaq Tru64
UNIX V5.1A.
BEGIN CODE
#include pthread.h
#include unistd.h
#include iostream
#include exception
#define NUMBER_OF_THREADS 1000
void *
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03
11:19 ---
Are we supposed to guess the actual problem here or what??
--
What|Removed |Added
--- Additional Comments From mpinto at brturbo dot com 2004-12-03 11:22
---
Created an attachment (id=7668)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7668action=view)
the ii file generated by the compilation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18807
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03
11:24 ---
BTW Where is this coming from?
/home/eric/cvs/gcc/libgfortran/libgfortran.h: In function 'isfinite':
/home/eric/cvs/gcc/libgfortran/libgfortran.h:96: warning: implicit declaration
My 'man finite' says that
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03
11:26 ---
So is this another problem with RTH's complex patches?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18776
--
Bug 11147 depends on bug 7305, which changed state.
Bug 7305 Summary: Install path for libgcj header files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7305
What|Old Value |New Value
--- Additional Comments From rsandifo at gcc dot gnu dot org 2004-12-03
11:30 ---
Fixed in 4.0
--
What|Removed |Added
Status|ASSIGNED
--
Bug 346 depends on bug 7305, which changed state.
Bug 7305 Summary: Install path for libgcj header files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7305
What|Old Value |New Value
--- Additional Comments From rsandifo at gcc dot gnu dot org 2004-12-03
11:33 ---
The libgcj thing should be fixed now. Are there any other
problems that would stop us closing this PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=346
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-03
11:38 ---
BTW Where is this coming from?
/home/eric/cvs/gcc/libgfortran/libgfortran.h: In function 'isfinite':
/home/eric/cvs/gcc/libgfortran/libgfortran.h:96: warning: implicit declaration
My 'man finite'
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03
11:42 ---
The same problem exists in sched-ebb.c, see
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00260.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18718
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-03
11:50 ---
The regression was introduced by Geoff's patch
http://gcc.gnu.org/ml/gcc-cvs/2004-01/msg00195.html
(before the 3.4 branch)
This was fixed on mainline by Jan's patch
Hello,
using gcc3.4.2, following code compiles well:
1
2 #include cctype
3 #include string
4 #include algorithm
5 //#include iostream
6
7 using namespace std;
8
9 int
10 main() {
11 string s=HeLLO;
12
--- Additional Comments From kgardas at objectsecurity dot com 2004-12-03
12:15 ---
GCC 4.0.0 20041126 also complains about this code:
$ /mnt/karel/gcc-main-20041126/bin/c++ str.cc
str.cc: In function 'int main()':
str.cc:12: error: no matching function for call to
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03
12:17 ---
A little update on the original list of undocumented macros:
ASM_OUTPUT_DWARF_PCREL - documented
ASM_SIMPLIFY_DWARF_ADDR - removed and poisoned
BUILD_VA_LIST_TYPE - removed and poisoned
CONST_SECTION_ASM_OP
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03
12:20 ---
I believe this is not fixable for GCC 4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14638
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03
12:25 ---
Is the remaining bug a regression? In fact, is this a regression at all
or merely a bug that was latent and somehow got exposed now? Andreas,
are you going to post your patch from comment #5?
--
--- Additional Comments From joseph at codesourcery dot com 2004-12-03
12:37 ---
Subject: Re: [3.3/3.4/4.0 Regression] Undocumented target
macros in 3.0
On Fri, 3 Dec 2004, steven at gcc dot gnu dot org wrote:
BUILD_VA_LIST_TYPE - removed and poisoned
I noted in comment #14 that
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
12:41 ---
with 3.3.2 I get:
L9:
stw r0,0(r9)
addi r9,r9,4
bdnz L9
With the mainline I get:
L2:
slwi r0,r2,2
addi r2,r2,1
stwx r9,r11,r0
bdnz L2
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
12:42 ---
Can you try a new GCC, libstdc++ has impoved a lot since 3.0.2. Try 3.3.x or
3.4.x?
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
12:49 ---
12944 is for generic namelookup problems.
--
What|Removed |Added
OtherBugsDependingO|
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03
12:50 ---
Not a regression says the RM.
gfortran should move to the generic GCC diagnostics machinery anyway,
hopefully for GCC 4.1.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03
12:51 ---
Right, so we should perhaps add a check for ieeefp.h in the
configure machinery, and include it when it's there. Hmm...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18776
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
12:51 ---
But not argument passing ABI sorry.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
13:00 ---
Actually there was some discussion about this in the standard comittee
recently. Right now it is not
clear what should happen.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
13:02 ---
This might be a real C++ front-end bug.
The problem is related to tolower and overloads. There might be a dup of this
bug.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
13:05 ---
Also you did not configure your compiler so in conjuction libstdc++ for threads:
Thread model: single
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2004-12-03 13:12
---
No, no, it's a well known INVALID (see 11108, 5133, 13188...)
*** This bug has been marked as a duplicate of 5133 ***
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2004-12-03 13:12
---
*** Bug 18808 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From mpinto at brturbo dot com 2004-12-03 13:31
---
I tryed with gcc 3.3 in another machine and it didn't coredumped, but since it
isn't a problem that shows every time I can't tell if it was corrected or if I
was (un)lucky.
How do I configure the compiler to
--- Additional Comments From pcarlini at suse dot de 2004-12-03 13:35
---
http://gcc.gnu.org/install/configure.html
Paolo.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18807
--- Additional Comments From dberlin at gcc dot gnu dot org 2004-12-03
13:47 ---
Actually, this is related to the aliasing stuff described in the non-bugs.
If you look, in the first instance, you are casting a structure to an unsigned
short *, and treating it like an array.
In fact,
I tried to compile rs6000.c outside of the gcc objdir just for checking on a
flag but I found we produced
an ICE after some errors.
Reduced to:
static int b (enum a mode) {}
static void c (void) { b (2); }
new.c:1: warning: 'enum a' declared inside parameter list
new.c:1: warning: its scope is
I did a make bootstrap with the latest CVS and everything went fine.
This was right after I did a cvs update. The configure was rerun. Everything
built just fine.
Here are the setup particulars:
MacOSX:~/obj-4.0.0 ed$ ../gcc-4.0.0/bin/gfortran -v
Reading specs from
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
14:27 ---
Something must be wrong with OS or machine because I have a /dev/null:
crw-rw-rw- 1 root wheel3, 2 3 Dec 09:26 /dev/null
Darwin zhivago.erc-wireless.uc.edu 7.6.0 Darwin Kernel Version 7.6.0: Sun
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
14:29 ---
See my previous comment, this works for me on an almost clean Mac OS X 10.3.6
install. The only
thing I installed after that was the cctools.
--
What|Removed |Added
--- Additional Comments From paulthomas2 at wanadoo dot fr 2004-12-03
15:08 ---
The problem lies with the character pointer in the derived type. Remove the
assignement to null and this example compiles. Try to allocate pd and it fails
again. Change to to fixed length, it is OK, but
I just noticed that building rhug from cvs fails with the current gcc from cvs.
I'm reporting this here because gcc 3.4.2 seems to build the problematic file so
this might be regression.
$ CVS_RSH=ssh cvs -d:pserver:[EMAIL PROTECTED]:/cvs/rhug -z9 co rhug
$ cd rhug
$ export
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-03
16:45 ---
Subject: Bug 9908
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_3-branch
Changes by: [EMAIL PROTECTED] 2004-12-03 16:45:44
Modified files:
gcc:
--- Additional Comments From mark at codesourcery dot com 2004-12-03 17:31
---
Subject: Re: [3.3/3.4/4.0 Regression] Undocumented target
macros in 3.0
steven at gcc dot gnu dot org wrote:
CRT_GET_RFIB_DATA
EXPAND_BUILTIN_VA_START
IDENT_ASM_OP
Just to get it over with, I'll see
--- Additional Comments From htanabe at edu dot gunma-u dot ac dot jp
2004-12-03 17:37 ---
(In reply to comment #1)
On Mac OSX 10.3.6
Something must be wrong with OS or machine because I have a /dev/null:
crw-rw-rw- 1 root wheel3, 2 3 Dec 09:26 /dev/null
Darwin
--- Additional Comments From hjl at lucon dot org 2004-12-03 17:51 ---
An updated patch for gcc 3.4 is posted at
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00276.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16276
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-03
18:02 ---
Subject: Bug 18697
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-03 18:02:01
Modified files:
gcc/java : ChangeLog class.c
Log message:
gcj crashes with a SEGV when compiling this file.
All previous gcj releases were fine.
--
Summary: [4.0 Regression] ICE in catalina/common/lib/naming-
resources.jar
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-03
18:11 ---
Subject: Bug 18812
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-03 18:11:22
Modified files:
gcc/java : ChangeLog except.c
Log message:
--
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|--- |4.0.0
We cannot vectorize the following loop because the number of iterations cannot
be computed.
int f(int *s, int *e)
{
while ( s e ) *s++ = 0;
}
This acutally shows up in SPEC (gap).
--
Summary: not vectorizing obvious loop
Product: gcc
Version: 4.0.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
18:17 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--
What|Removed |Added
Keywords||rejects-valid
Summary|rhug build problem, |[4.0 Regression] rhug build
--- Additional Comments From aph at gcc dot gnu dot org 2004-12-03 18:24
---
So? I fixed it.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From aph at gcc dot gnu dot org 2004-12-03 18:28
---
Is junit.runner.Sorter$Swapper in the path?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18811
According to the ISO C standard, compound literals in functions are objects
with automatic storage
duration. The following test case modified such an object, so in this test
case the value should be 1 the
first time through the loop and 77 the second time. Instead we see 1 the first
time.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
18:50 ---
But reading 6.5.2.5 P 16 seems to say something different.
What it seems to say is:
p = ((int) {1});
is to set the int to be one and then take the address. We still point to the
same int as before.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
18:51 ---
Just for reference this is the example from the text:
struct s { int i; };
int f (void)
{
struct s *p = 0, *q;
int j = 0;
again:
q=p,p=((struct s){ j++ });
if (j 2) goto again;
return p == q
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
18:52 ---
And it says it always return 1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18814
--- Additional Comments From austern at apple dot com 2004-12-03 18:59
---
Subject: Re: Incorrect reinitialization of compound literal
On Dec 3, 2004, at 10:50 AM, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org
2004-12-03
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
19:15 ---
(In reply to comment #4)
Subject: Re: Incorrect reinitialization of compound literal
On Dec 3, 2004, at 10:50 AM, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
19:24 ---
Can you please attach the preprocessed source?
--
What|Removed |Added
CC|
--- Additional Comments From austern at apple dot com 2004-12-03 19:27
---
Subject: Re: Incorrect reinitialization of compound literal
On Dec 3, 2004, at 11:15 AM, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org
2004-12-03
--- Additional Comments From joseph at codesourcery dot com 2004-12-03
19:28 ---
Subject: Re: Incorrect reinitialization of compound literal
On Fri, 3 Dec 2004, austern at apple dot com wrote:
Not exactly. We still point to the same (one-element) array of ints we
did before. The
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-03
19:32 ---
Subject: Bug 14614
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-03 19:32:39
Modified files:
gcc/java : ChangeLog Make-lang.in
Log
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-03
19:33 ---
Fix checked in
--
What|Removed |Added
Status|NEW
--
What|Removed |Added
Known to fail|3.4.0 4.0.0 |3.4.0
Known to work||4.0.0
Target Milestone|---
On gcc.dg/pr17635.c, tree-if-conversion badly screws up the cfg (we just don't
notice because we aren't doing enough verification)
Before if-convresion:
(gdb) p debug_tree_bb (basic_block_info[0].data.bb[2])
;; basic block 2, loop depth 1, count 0
;; prev block 1, next block 3
;; pred: 1
--
What|Removed |Added
CC||dpatel at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18815
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
19:51 ---
Oh, the problem is we don't handle non one increment.
Another example:
int f(unsigned s1, unsigned s2, int *s, int *e)
{
unsigned i;
for (i = s1; i s2; i+=4)
*s++ = 0;
}
--
--- Additional Comments From maryburak11 at aol dot com 2004-12-03 19:58
---
Any fix for this? I'm getting the same error.
I tried to build glibc 2.3.3 on RedHat Linux Advanced Serer 2.1
(kernel 2.4.9-e.24), but ran into an error saying compiler support for
__threads is required, so I
--- Additional Comments From austern at apple dot com 2004-12-03 20:22
---
I don't think this is the most natural interpretation. The line
p = ((int) {1});
sets p to the address of the literal, and at the point we reach it for the
second time the literal itself has
been changed.
--- Additional Comments From joseph at codesourcery dot com 2004-12-03
20:52 ---
Subject: Re: Incorrect reinitialization of compound literal
On Fri, 3 Dec 2004, austern at apple dot com wrote:
I don't think this is the most natural interpretation. The line
p = ((int) {1});
sets
--
What|Removed |Added
Component|other |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18788
Happens on both x86 and x86_64, Geert is working on the issue:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02379.html
,.,. C460007 ACATS 2.5 04-12-03 22:18:14
C460007 Rounding for type conversions of real operand to integer
target.
* C460007 Wrong result for floating
No analysis yet, fails on both x86 and x86_64.
,.,. C380004 ACATS 2.5 04-12-03 22:14:45
C380004 Check evaluation of discriminant expressions when the
constraint depends on a discriminant, and the
discriminants have defaults -
--- Additional Comments From laurent at guerby dot net 2004-12-03 22:16
---
From my old notes, this one started failing between
LAST_UPDATED: Fri Sep 17 22:17:43 UTC 2004
LAST_UPDATED: Sat Sep 18 07:45:31 UTC 2004
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18727
Fails on x86 and x86_64, no analysis yet. From my old notes, started failing
between:
LAST_UPDATED: Fri Sep 17 17:12:56 UTC 2004
LAST_UPDATED: Fri Sep 17 22:17:43 UTC 2004
,.,. CD10002 ACATS 2.5 04-12-03 22:30:27
CD10002 Check that operational items are allowed in some contexts
Happens both on x86 and x86_64, no analysis yet.
,.,. CDD2A02 ACATS 2.5 04-12-03 22:31:47
CDD2A02 Check that the Read, Write, Input, and Output attributes
are inherited for untagged derived types.
* CDD2A02 Inherited Input and Output are not inverses of each other -
The tests pass on x86_64 but fail on x86, no analysis yet.
,.,. C953003 ACATS 2.5 04-12-03 22:26:09
C953003 Check that the servicing of entry queues handles all open
entries as part of a single protected operation,
including those resulting from an internal
--- Additional Comments From laurent at guerby dot net 2004-12-03 22:42
---
Forgot the error message:
c432003.adb:134:21: too few discriminants given in constraint
compilation abandoned due to previous error
gnatmake: c432003.adb compilation error
--
--- Additional Comments From laurent at guerby dot net 2004-12-03 22:53
---
c953002 hangs on x86 and x86_64, probably the same cause as the two
others (add it to testsuite/ada/acats/norun.lst to be safe).
,.,. C953002 ACATS 2.5 04-11-09 00:00:31
C953002 Check that the servicing of
--- Additional Comments From amodra at bigpond dot net dot au 2004-12-03
23:05 ---
Fixed both sched-ebb.c and sched-rgn.c
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From evandro at yahoo dot com 2004-12-03 23:15
---
It now causes building natively on AMD64 to fail...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16135
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-03 23:20
---
I'm not actively working on this, or planning to in the near future.
--
What|Removed |Added
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-03
23:25 ---
I've looked into this a little.
Apparently we are getting to this line in
resolve_inner_class:
local_super = do_resolve_class (NULL, local_super, NULL, NULL);
with local_super:
(gdb) pt
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-03 23:26
---
Fixed.
--
What|Removed |Added
CC|rth at gcc dot gnu dot org |
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-03
23:33 ---
Andrew fixed this.
--
What|Removed |Added
Status|ASSIGNED
1 - 100 of 130 matches
Mail list logo
