--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-29 08:01 ---
I thought if we know that we are looking at the loop header copy condition that
we _know_ that the loop runs at least once, so we can avoid trying to prove
that again using fold.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-03-29 08:05 ---
I'm unable to produce a testcase where we "regress" from 4.0 or earlier, so
closing as fixed in 4.2.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from zerocool at modemsoft dot it 2006-03-29 08:17 ---
Premising that I have unloaded the last available snapshots on the site and
that is:
gcc-4.2-20060325.tar.bz2,gcc-4.1-20060324.tar.bz2,gcc-4.0-20060323.tar.bz2
Well i make two test yesterday with this result :
First r
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-03-29 09:01 ---
Subject: Re: Number of iterations not know for simple loop
> I thought if we know that we are looking at the loop header copy condition
> that
> we _know_ that the loop runs at least once, so
I get a ICE in g++ for the following code when compiled with -fopenmp and -O2:
#include
int foo()
{
int x1;
#pragma omp parallel
{
for (int i = 0; i < 5; ++i) {
std::string xxx;
}
}
return 0;
}
Note that thi
--- Comment #7 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-03-29 09:11 ---
Subject: Re: Number of iterations not know for simple loop
> > I thought if we know that we are looking at the loop header copy condition
> > that
> > we _know_ that the loop runs at least on
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-29 09:32 ---
Confirmed.
struct Foo {
template int func() ;
};
class Bar {
friend int Foo::func() const ; // line 6
};
is also invalidly accepted.
--
rguenth at gcc dot gnu dot org changed:
What|Remove
--- Comment #4 from rmathew at gcc dot gnu dot org 2006-03-29 10:06 ---
It would be difficult for those of us without alpha-linux boxes to track
this problem down. If you're willing, you can try to track the failure
to a certain bit yourself.
Let's stick with the GCC 4.2 snapshot as tha
flags: -O2 -ffast-math -march=i686 -fomit-frame-pointer
double signum_dbl_gcc( double x )
{
if ( x < 0.0 )
return -1.0;
if ( x > 0.0 )
return 1.0;
return 0.0;
}
.LC1: .long 3212836864
signum_dbl_gcc:
fldz
fldl4(%esp)
fcomip %st(1), %st
--- Comment #5 from zerocool at modemsoft dot it 2006-03-29 10:30 ---
(In reply to comment #4)
OK now i try this and after i tell you the resul, hoping in the lucky :-)
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
double minus1() { return -1.0; }
.LC0:.long 3212836864
minus1: flds.LC0
ret
for -Os gcc should use `fld1;fchs'.
--
Summary: missed optimization / returning -1.0
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity:
It seems that template function overloading/argument dependent lookup now
depends on declaration order. If this is right or not I don't know yet, but it
changed without notice. consider this small piece of code:
#include
#include
#include
template void add_field(T const & value) {
static in
Compiling a valid C++ file with -frepo and then editing the file
introducing bugs and then recompiling the file causes trouble:
For example:
Create the file "bug.cc" with the contents
===
int i;
===
Compile this file with "g++ -frepo -c bug.cc".
Then change the file to
=
The following piece of code causes an ICE at ipa-inline.c:106 as soon as
optimization is turned on. I can reproduce it using BOOST 1.32.0 and 1.33.1. It
used to work previously (at least as of GCC 3.4.3).
#include
#include
#include "boost/lambda/lambda.hpp"
#include "boost/lambda/bind.hpp"
str
When I try to build a program using static libraries, I get errors -
[dranta:~/tests] dir% gfortran -o print print.f
[dranta:~/tests] dir% gfortran -o print print.f -Wl,-static
/usr/bin/ld: only one of -static or -dynamic can be specified
[dranta:~/tests] dir% gfortran -static -o print print.f
/us
--- Comment #12 from uros at kss-loka dot si 2006-03-29 14:08 ---
(In reply to comment #11)
> it looks like 4.1.1 and 4.2.0 still produce unoptimal code.
> test: pushl %ebp
> movl%esp, %ebp
> fldl8(%ebp)
> fldz
> fcomip %st(1), %st
>
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-29 14:13 ---
Can you attach preprocessed source please?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-29 14:19 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
When compiled under Linux, at least, gcc 3.2.3 appears to pass a long long bit
field to a variadic function as a long. In particular, if you say "printf
("%lld", s.a)", where s.a is a long long bit field, s.a appears to only pass a
long.
The resulting assembly reads (for a 3 bit long long field):
--- Comment #1 from bugzilla at hburch dot com 2006-03-29 14:54 ---
Created an attachment (id=11150)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11150&action=view)
Bundle for Linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26921
--- Comment #2 from bugzilla at hburch dot com 2006-03-29 14:54 ---
Created an attachment (id=11151)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11151&action=view)
Bundle for Mac OS X
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26921
--- Comment #3 from bugzilla at hburch dot com 2006-03-29 14:59 ---
#include
struct s {
long long int a : 33;
};
struct s foo = {0};
int main(void) {
printf ("%lld\n", foo.a);
return 0;
}
produces the following output using "gcc -Wall -o a a.c" for same syste
--- Comment #9 from tromey at gcc dot gnu dot org 2006-03-29 15:12 ---
The first time we lay out the type, we have the fields reversed.
See parse.y:java_reorder_fields. I don't know why this happens.
(We construct the field list in reverse order, presumably for
efficiency. What is uncl
--- Comment #9 from pbrook at gcc dot gnu dot org 2006-03-29 15:21 ---
Subject: Bug 23623
Author: pbrook
Date: Wed Mar 29 15:21:13 2006
New Revision: 112493
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112493
Log:
2006-03-29 Paul Brook <[EMAIL PROTECTED]>
PR middle-
Executable fails to compile with -frepo using g++ 4.1
g++ (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--- Comment #2 from kreckel at ginac dot de 2006-03-29 15:36 ---
Created an attachment (id=11152)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11152&action=view)
program causing ICE preprocessed with -P -E
I now see that this is not vanilla boost 1.33.1 but one which contains an
--- Comment #1 from rankincj at yahoo dot com 2006-03-29 15:36 ---
Created an attachment (id=11153)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11153&action=view)
Source code to demonstrate -frepo failure.
My host machine is a i686-pc-linux-gnu machine; g++-3.4.4 compiles this j
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-03-29 15:44
---
Confirmed.
Reduced testcase (compile with "g++ -fopenmp"):
===
struct A
{
~A() throw();
};
void foo(A);
A bar() throw();
void baz()
{
#pragma omp parallel
{ A a; foo(ba
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-03-29 15:45 ---
Created an attachment (id=11154)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11154&action=view)
patch
I have a simple patch for # iterations analysis to check whether either cond1
follows from cond2 or !cond
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-03-29 16:05
---
Reducing.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #10 from tromey at gcc dot gnu dot org 2006-03-29 16:32 ---
Subject: Bug 26390
Author: tromey
Date: Wed Mar 29 16:31:53 2006
New Revision: 112499
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112499
Log:
gcc/java
PR java/26390:
* parse.y (find_most_s
A peace of my code uses the two next macros (SWAP and InvSwap) to swap bytes,
it worked for a long time under gcc-3.3 but not under gcc-4.0.3
under gcc-3.3:
InvWord(0xABCD) = 0xCDAB
under gcc-4-0.3:
InvWord(0xABCD) = 0xCD00
FILE STARTS HERE ##
#define SWAP(x
--- Comment #11 from tromey at gcc dot gnu dot org 2006-03-29 16:36 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|N
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-29 16:44 ---
Note that we need more mauve tests in this area before fixing the problem.
The current tests don't catch the bug(s).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26910
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-03-29 17:03
---
Created an attachment (id=11155)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11155&action=view)
Smaller testcase
Will continue reducing if nobody beats me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #4 from janis at gcc dot gnu dot org 2006-03-29 17:12 ---
The gfortran torture tests also need to support dg- options, starting with
dg-final to allow cleaning up module files from the testsuite temporary
directory.
--
janis at gcc dot gnu dot org changed:
Wha
--- Comment #10 from spop at gcc dot gnu dot org 2006-03-29 17:20 ---
Subject: Bug 26859
Author: spop
Date: Wed Mar 29 17:20:24 2006
New Revision: 112502
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112502
Log:
PR tree-optimization/26859
* tree-ssa-loop-niter.c
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-03-29 17:40 ---
Excellent job Paolo! Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26733
--- Comment #10 from pbrook at gcc dot gnu dot org 2006-03-29 17:44 ---
Should be fixed now.
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-29 17:52 ---
I now agree with comment #4.
I don't think this is a bug.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-29 18:12 ---
Things look even worse with svn head (4.2 atm)...
either with gij or precompiled, the test case shows
invocations about an order of magnitude slower than the JDK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #6 from mark at gcc dot gnu dot org 2006-03-29 18:14 ---
TYhis bug is now closed but I wanted to add the following link for the
archives. A couple of these denial of service attacks by taking locks were in
the examples of Sascha's GNU Classpath Security talk at Fosdem 2004:
h
While working on the long double 128 bits with Jakub, it was pointed out that
some of the libmath work in libstdc++ is incorrect.
In particular, platforms like ppc32 are doing some bogus exports. Mostly, this
is because on certain platforms,
sizeof(double) == sizeof(long double)
and so, there
--- Comment #3 from quanah at stanford dot edu 2006-03-29 18:45 ---
Actually, the problem has nothing to do with using /bin/sh, because I get the
same failure using /bin/ksh, too:
/bin/ksh ../../../../gcc-4.1.0/libgfortran/mk-srk-inc.sh
'/afs/ir.stanford.edu/src/pubsw/languages/gcc-buil
--- Comment #1 from pluto at agmk dot net 2006-03-29 18:51 ---
It's not a gcc bug. The code relies on the results of intermediate
subexpressions. According to Stroustrup, The C++ Programming Language, section
6.2.2, "The order of evaluation of subexpressions within
an expression is unde
Most likely this bug was reported before; but I couldn't seem to find it in
this database. So, just in case. The bug is with gcc 3.3.5; I know 3.4.4 works
fine.
=== test
#include
#include
int main() {
int g_size = 8;
int dim;
double dd;
dd = log2(g_siz
--- Comment #7 from mckinlay at redhat dot com 2006-03-29 18:59 ---
With a public call, as in the current test case, it is "only" about 2.5X slower
than HotSpot for me:
$ ./a.out
public call: 499 ms
private call: 7344 ms
$ java RefTest3
public call: 182 ms
private call: 808 ms
Private
--- Comment #8 from mckinlay at redhat dot com 2006-03-29 19:00 ---
Created an attachment (id=11156)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11156&action=view)
Test Case
New version of the test case, which tests both public and private method
invocation.
--
http://gcc.g
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-29 19:15 ---
This is correct behavior.
The template is the only thing the first template sees when it calls add_field
as there are no dependent arguments.
--
pinskia at gcc dot gnu dot org changed:
What|Remov
gcc-4.2.0-20060323 / rev.112317
$ testcase:
void test(double x) { if (x > 0.0); }
$ ./xgcc -B. bug.c -c -m32 -march=i686
bug.c: In function 'test':
bug.c:7: internal compiler error: in bsi_last, at tree-flow-inline.h:760
it works with 4.1.1.
--
Summary: ICE in in bsi_last, at tree
--- Comment #1 from pluto at agmk dot net 2006-03-29 19:23 ---
...and the current 4.2.0 ICEs on this testcase:
$ ./xgcc -B. 26915.c -m32 -march=i686
26915.c: In function ‘minus1’:
26915.c:1: error: bb_for_stmt (stmt) is set to a wrong basic block
26915.c:1: error: bb_for_stmt (stmt) is
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-29 19:25 ---
The warning mess has been corrected:
t.c: In function 'main':
t.c:10: warning: format '%lld' expects type 'long long int', but argument 2 has
type 'long long int:33'
This is not a bug, GCC is correct in warning.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-29 19:26 ---
*** This bug has been marked as a duplicate of 11751 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #66 from pinskia at gcc dot gnu dot org 2006-03-29 19:26
---
*** Bug 26923 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from tkoenig at gcc dot gnu dot org 2006-03-29 19:29 ---
Fixed on 4.1. Closing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20935
--- Comment #10 from tkoenig at gcc dot gnu dot org 2006-03-29 19:30
---
Really closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-03-29 19:31 ---
Fixed on 4.1. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-29 19:34 ---
t.c:9: warning: implicit declaration of function 'log2'
t.c:9: warning: incompatible implicit declaration of built-in function 'log2'
Please next time use -W -Wall before reporting a bug report as requested by:
http
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-29 19:35 ---
It also works with "4.2.0 20060321".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26928
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-03-29 19:37
---
Confirmed.
The testcase still involves long template parameter lists, but that seems
to be part of the problem: I removed some of them, but then the testcase
compiles.
--
reichelt at gcc dot gnu dot org change
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-03-29 19:38
---
Created an attachment (id=11157)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11157&action=view)
Reduced testcase
Reduced testcase.
--
reichelt at gcc dot gnu dot org changed:
What|Remov
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-03-29 19:39
---
Btw, the testcase crashes when compiles with "g++ -O":
PR26919.cc:119: internal compiler error: in
cgraph_estimate_size_after_inlining, at ipa-inline.c:106
Please submit a full bug report, [etc.]
--
http://gc
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-29 19:43 ---
There are 2 parts to this bug.
First, there's no reason to build tools.zip in the gcj build (yet).
Second, upstream classpath should pass an explicit -encoding when
invoking the java compiler.
I'm working on these.
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-03-29
19:53 ---
Subject: Re:
../../../../../gcc/libjava/classpath/tools/gnu/classpath/tools/AbstractMethodGenerator.java:1:
fatal error
> There are 2 parts to this bug.
>
> First, there's no reason to build tools.zip in
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-29 20:22 ---
In order to do this we should avoid building tools.zip
and instead directly build executables.
(If we need a java archive for some reason, it should be a
jar, anyway.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #3 from cvs-commit at developer dot classpath dot org
2006-03-29 20:28 ---
Subject: Bug 26901
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Tom Tromey <[EMAIL PROTECTED]>06/03/29 20:24:37
Modified files:
.
--- Comment #3 from sebastian dot pop at cri dot ensmp dot fr 2006-03-29
20:39 ---
Fixed by the recent changes.
--
sebastian dot pop at cri dot ensmp dot fr changed:
What|Removed |Added
-
--- Comment #3 from sebastian dot pop at cri dot ensmp dot fr 2006-03-29
20:40 ---
Fixed on autovect.
--
sebastian dot pop at cri dot ensmp dot fr changed:
What|Removed |Added
---
--- Comment #2 from sebastian dot pop at cri dot ensmp dot fr 2006-03-29
20:42 ---
Fixed on autovect.
--
sebastian dot pop at cri dot ensmp dot fr changed:
What|Removed |Added
---
--- Comment #2 from rankincj at yahoo dot com 2006-03-29 21:10 ---
The sample code works OK with the following compilers:
$ g++ -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--enable-share
This actually occurs on 3.3.3 and 4.0.3 (haven't tried others).
When a structure contains a 32 bit int, and because of alignement, it is not
located on a 64 bit boundary *and* (apparently) the compiler aligns a bitfield
int on the first fullword, operations on that bitfield implicitly access the
v
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-03-29 21:14
---
> Actually, the problem has nothing to do with using /bin/sh, because I get the
> same failure using /bin/ksh, too:
OK, but given that you're the first who reports that kind of problems, we're
pretty much in the
--- Comment #14 from bsdfan3 at users dot sourceforge dot net 2006-03-29
21:14 ---
GCC 3.4.4 on Cygwin actually breaks. The .ii file looks normal, however, it
seems to be segfaulting...I'll try the testcase with mainline shortly.
$ gcc --version
gcc (GCC) 3.4.4 (cygming special) (gdc
--- Comment #1 from ivan at vmfacility dot fr 2006-03-29 21:18 ---
Created an attachment (id=11158)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11158&action=view)
Runnable program demonstrating the problem
This program, once compiled for powerpc64 and run on powerpc64 demonstrat
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-29 21:33 ---
Subject: Bug 26901
Author: tromey
Date: Wed Mar 29 21:33:08 2006
New Revision: 112510
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112510
Log:
PR gcc/26901:
* Makefile.in: Rebuilt.
*
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-29 21:42 ---
Fix checked in, please give it a try.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from tromey at gcc dot gnu dot org 2006-03-29 21:45 ---
This was fixed by the patch for PR 26901.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-29 21:48 ---
Really mark as fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #5 from quanah at stanford dot edu 2006-03-29 21:49 ---
Yep. That's how f951 was getting linked to gmp. I'm going to make gmp only be
static, however, and see if that changes things.
I'm going to have to defer further work on both these bugs until next week. I
had a very
--- Comment #28 from quanah at stanford dot edu 2006-03-29 22:12 ---
Created an attachment (id=11160)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11160&action=view)
selected_int_kind.inc
Here's the selected_int_kind.inc file generated on Solaris 8 with gcc 4.0.3.
--
http://
--- Comment #11 from malitzke at metronets dot com 2006-03-29 22:24 ---
Maybe I should keep my mouth shut.
However, gcc-4.2.0 2006329 again compiles pari-2.1.7 OK. 2nd However,
pari-2.2.12.beta uses a different approch, which does not give any problems
with various gcc-4.2.0. At least th
--- Comment #8 from tromey at gcc dot gnu dot org 2006-03-29 22:39 ---
I tried this today with svn head.
The test program still prints 'false' no matter how I run it:
gij, compiled, or compiled with the BC ABI.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20044
build/genpeep ../../gcc-4.2.0/gcc/config/rs6000/rs6000.md \
insn-conditions.md > tmp-peep.c
../../gcc-4.2.0/gcc/config/rs6000/altivec.md:173: error: undefined
machine-specific constraint at this point: "W"
../../gcc-4.2.0/gcc/config/rs6000/altivec.md:173: note: in operand 1
..previous 2
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||dje at gcc dot gnu dot org
GCC build triplet|powerpc-slackware-linux
--- Comment #1 from dje at gcc dot gnu dot org 2006-03-29 23:15 ---
in progress
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-29 23:22 ---
Can you try a GCC which was released by the FSF and not a redhat modified one?
If it works there, please report this to Redhat. Note this should have been
reported first to redhat and not here since you are using a
--- Comment #4 from rankincj at yahoo dot com 2006-03-29 23:44 ---
Subject: Re: Compile/link failure with -frepo and g++ 4.1
--- pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote:
> Can you try a GCC which was released by the FSF and not a redhat modified one?
> If it works ther
werpc-slackware-linux-gnu --target=powerpc-slackware-linux-gnu
--build=powerpc-slackware-linux-gnu --enable-languages=c,c++,fortran,java
--with-cpu=7450 --enable-clocale=gnu
Thread model: posix
gcc version 4.1.1 20060329 (prerelease)
/usr/libexec/gcc/powerpc-slackware-linux-gnu/4.1.1/collect2 --eh-fram
--- Comment #7 from janis at gcc dot gnu dot org 2006-03-30 01:06 ---
The patch that Lee checked in removed checks for extra_warnings before the
calls to warnings with OPT_Wextra in typeck.c and class.c. If those checks are
restored then the five test cases listed in this PR and in 2611
--- Comment #3 from malitzke at metronets dot com 2006-03-30 01:07 ---
Using an older version of gcc-4.2.0 gave essentially the same error message as
in the original description.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26935
--- Comment #6 from janis at gcc dot gnu dot org 2006-03-30 01:07 ---
The patch that Lee checked in removed checks for extra_warnings before the
calls to warnings with OPT_Wextra in typeck.c and class.c. If those checks are
restored then the five test cases listed in this PR and in 2611
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-30 01:10 ---
I just was able to build this without any troubles ;).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26935
--- Comment #1 from sayle at gcc dot gnu dot org 2006-03-30 01:35 ---
Subject: Bug 22494
Author: sayle
Date: Thu Mar 30 01:35:22 2006
New Revision: 112529
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112529
Log:
PR c++/22494
* init.c (build_vec_delete_1): Conv
--- Comment #5 from malitzke at metronets dot com 2006-03-30 03:48 ---
I just did an svn update and there is an rs6000/constraints.md updated. So, let
us keep our fingers crossed while I do new bootstrap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26935
--- Comment #6 from malitzke at metronets dot com 2006-03-30 03:54 ---
Yep, it just passed that stage and seems to be well on its way. Thanks, you do
the paperwork.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26935
--- Comment #29 from ebotcazou at gcc dot gnu dot org 2006-03-30 06:20
---
> Here's the selected_int_kind.inc file generated on Solaris 8 with gcc 4.0.3.
Thanks. Victory, at last something obviously broken. :-) The file reads:
integer, parameter :: c = 0
type (int_info), paramet
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-03-30 06:39
---
Jeff, please put PR numbers in your ChangeLog entries, thanks.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #30 from mckinlay at redhat dot com 2006-03-30 07:00 ---
Created an attachment (id=11161)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11161&action=view)
patch implementing GC_register_my_thread
Here's a patch that fixes this by adding functions to the GC that allow t
On bootstrapping, fix-header segfaults while processing
/usr/include/bits/stdio-ldbl.h which is from glibc-2.4.
This problem does not appear on i386-linux host because 'use_fixproto' is set
to 'no' in gcc/config.gcc.
Reduced problematic header contents:
f()
Reproduce:
cd /gcc
make stmp-f
1 - 100 of 101 matches
Mail list logo
