--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-04
07:34 ---
Got it.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lerdsuwa at
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-04
07:06 ---
Fixed in 3.4 branch and mainline.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-04
07:06 ---
Fixed in 3.4 branch and mainline.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-04
06:55 ---
Subject: Bug 17011
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2004-12-04 06:55:00
Modified files:
gcc/cp : Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-04
06:45 ---
Subject: Bug 17011
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-04 06:45:14
Modified files:
gcc/cp : ChangeLog pt.c semantics.c
g
--
Bug 18697 depends on bug 18699, which changed state.
Bug 18699 Summary: [4.0 Regression] SIGSEGV in GC_local_gcj_malloc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18699
What|Old Value |New Value
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-04
04:04 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From roger at eyesopen dot com 2004-12-04 03:44
---
Hi P.J.,
Thanks for removing the i686 version of the attachment. But it looks like the
390x-ibm-tpf version of digit.i (attachment #1), also reveals that the isdigit
call is being expanded as a macro in native
--- Additional Comments From zack at gcc dot gnu dot org 2004-12-04 03:38
---
The question is then why -fvisibility=hidden -Werror does not cause the compiler
to exit unsuccessfully. libgcc.mk uses that incantation to determine whether
.hidden is supported.
--
http://gcc.gnu.org/bu
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-04
03:27 ---
Can you attach the preprocessed source?
Read http://gcc.gnu.org/bugs.html.
--
What|Removed |Added
---
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dpatel at apple dot com
|dot org |
Status|UNCONFIRMED
Hi, I'm running debian @ kernel 2.4.26 testing, gcc 3.3.4 (Debian 1:3.3.4-13). I
compiled kernel long time ago for my Pentium 90 and it worked perfectly. Now I
changed proc. to P200MMX and tried to recompile kernel for it and I got this
message:
gcc -D__KERNEL__ -I/usr/src/kernel-source-2.4.26/in
--- Additional Comments From dpatel at apple dot com 2004-12-04 03:23
---
Indeed. Lack of exit edge is causing this. Please assign this PR to me. Thank
you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18815
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2004-12-04 03:15 ---
Subject: Re: [4.0 Regression] lib2funcs.vis:1: Error: un
> Does -fvisibility=hidden work on hppa-hpux?
No.
With 3.4.3:
-bash-2.05b$ gcc -fvisibility=hidden -S main.c
cc1: error: unrecognized comm
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-04
03:06 ---
Does -fvisibility=hidden work on hppa-hpux?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18804
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-04
02:16 ---
Confirmed, then.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2004-12-04 02:13 ---
Subject: Re: [4.0 Regression] lib2funcs.vis:1: Error: un
> > Sounds like libgcc/./lib2funcs.vis is wrong and should not have .hidden in
> > it.
>
> Yup:
>
> -bash-2.05b$ less libgcc/./lib2funcs.v
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2004-12-04 02:01 ---
Subject: Re: [4.0 Regression] lib2funcs.vis:1: Error: un
> --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
> 03:35 ---
> Sounds like libgcc/./lib2funcs.vis is wrong
--- Additional Comments From gccbugzilla at spamit dot net 2004-12-04
01:20 ---
Installed Red Hat Advanced Server 3.0, update 1
Dell PowerEdge 1750: Intel Xeon 2.4GHz
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/
--- Additional Comments From janis187 at us dot ibm dot com 2004-12-04
01:19 ---
Current mainline g++ ICEs in the same place (now dwarf2out.c:11210) when
compiling 252.eon with -g on powerpc64-unknown-linux-gnu with either -m32
or -m64. Here's a testcase extracted from the eon code:
do
I'd like to get a warning for code like this:
#include
using namespace std;
int main()
{
unsigned long four = 40;
unsigned short two;
two = four;
cout << two << endl;
}
/home/enadler/test/compilerwarnings $ g++ -Werror -Wall -Wconversion -ansi
gccbugreport.cc && a.out
6784
I th
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18796
--
What|Removed |Added
Target Milestone|3.4.3 |3.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17503
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-04
00:37 ---
Subject: Bug 17503
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_3-branch
Changes by: [EMAIL PROTECTED] 2004-12-04 00:36:41
Modified files:
gcc: Change
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-04
00:28 ---
I looked into this today.
When compiling to .o (or with --syntax-only), the
"System.out" reference is wrapped in a compound_expr
whose LHS initializes the System class.
I'm working on this.
--
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-04
00:22 ---
> It fails building libgfortran as of "make install". Could it be that there's
> a
> valid libgfortran on the system?
Sorry, I don't understand: does your problem have anything to do with this bug?
If n
--- Additional Comments From evandro at yahoo dot com 2004-12-04 00:13
---
(In reply to comment #14)
> > The patch? If so, this would seem surprising:
> > http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00028.html
>
> It fails building libgfortran as of "make install". Could it be th
--- Additional Comments From evandro at yahoo dot com 2004-12-04 00:09
---
> The patch? If so, this would seem surprising:
> http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00028.html
It fails building libgfortran as of "make install". Could it be that there's a
valid libgfortran on
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-04 00:09
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From amodra at bigpond dot net dot au 2004-12-03
23:55 ---
Um, middle-end spelled wrongly in the log, so adding this by hand
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-03 23:02:33
Modified files:
gcc
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-03
23:34 ---
> It now causes building natively on AMD64 to fail...
The patch? If so, this would seem surprising:
http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00028.html
--
http://gcc.gnu.org/bugzilla/show_bu
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-03
23:33 ---
Andrew fixed this.
--
What|Removed |Added
Status|ASSIGNED|RE
--- 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 |
Stat
--- 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 local_supe
--- 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 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 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 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 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
--
http://gcc.gnu.org/bugzilla/s
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 req
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 -
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
--- 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
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 -
discriminant-depend
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 poin
--
What|Removed |Added
Component|other |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18788
--- 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});
> s
--- 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.
I
--- 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 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;
}
--
http://gcc.gnu.org/bug
--
What|Removed |Added
CC||dpatel at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18815
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 [1
--
What|Removed |Added
Known to fail|3.4.0 4.0.0 |3.4.0
Known to work||4.0.0
Target Milestone|--- |4.
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-03
19:33 ---
Fix checked in
--
What|Removed |Added
Status|NEW |RESOLV
--- 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 message:
--- 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. Th
--- 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 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 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 pin
--- 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
18:52 ---
And it says it always return 1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18814
--- 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: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.
--
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.
#i
--- 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
--- Additional Comments From aph at gcc dot gnu dot org 2004-12-03 18:24
---
So? I fixed it.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVE
--
What|Removed |Added
Keywords||rejects-valid
Summary|rhug build problem, |[4.0 Regression] rhug build
|r
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
18:17 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
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
--
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.
--- 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:
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
Severity
--- 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:
--- 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 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 z
--- 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
--- 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: ChangeL
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 LD_LIBRARY_PATH=$INSTAL
--- 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 b
--- 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 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
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
/Users/ed/gcc-4.0.0/lib/gcc/
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 o
--- 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
--- 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 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 b
--- 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 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 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 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: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
12:51 ---
But not argument passing ABI sorry.
--
What|Removed |Added
Status|UNCONFIRMED
--- 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 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 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 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: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 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 t
--- 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?
--
http:/
--- 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
1 - 100 of 131 matches
Mail list logo
