-v
Using built-in specs.
Target: powerpc-apple-darwin8.8.0
Configured with: ../trunk/configure --prefix=/Users/fx/gfortran/devel/irun
--enable-languages=c,fortran --with-gmp=/Users/fx/gfortran/gfortran_libs/macosx
--disable-bootstrap
Thread model: posix
gcc version 4.3.0 20070109 (experimental)
--- Comment #3 from brooks at gcc dot gnu dot org 2007-01-10 05:58 ---
Fixed on 4.3, as per above commit.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from brooks at gcc dot gnu dot org 2007-01-10 05:57 ---
Fixed on 4.3, as per above commit.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from sebor at roguewave dot com 2007-01-10 05:55 ---
Even if the spec did permit undefined behavior it would make sense to implement
something reasonable if it's easy (as Paolo suggests it might be) and if the
cost
is acceptable. But just to put your mind at ease I'll writ
--- Comment #2 from brooks at gcc dot gnu dot org 2007-01-10 05:46 ---
Subject: Bug 30381
Author: brooks
Date: Wed Jan 10 05:46:13 2007
New Revision: 120634
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120634
Log:
PR 30381
PR 30420
* fortran/simplify.c (convert_mpz_to_unsigned
--- Comment #1 from brooks at gcc dot gnu dot org 2007-01-10 05:46 ---
Subject: Bug 30420
Author: brooks
Date: Wed Jan 10 05:46:13 2007
New Revision: 120634
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120634
Log:
PR 30381
PR 30420
* fortran/simplify.c (convert_mpz_to_unsigned
--- Comment #3 from hjl at lucon dot org 2007-01-10 05:12 ---
One of failed commands is
/export/build/gnu/gcc/build-x86_64-linux/gcc/gcj
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava/
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -ffloat-store
-fomit-f
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30408
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-01-10 04:34
---
Subject: Bug 30408
Author: jvdelisle
Date: Wed Jan 10 04:34:34 2007
New Revision: 120632
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120632
Log:
2007-01-09 Paul Thomas <[EMAIL PROTECTED]>
PR
--- Comment #8 from gdr at integrable-solutions dot net 2007-01-10 03:37
---
Subject: Re: SIGSEGV in valarray::cshift(n) on empty array
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| Well, IMHO, avoiding this SIGSEGV is so easy, I would change anyway both
shift
| and cshift
--- Comment #7 from gdr at integrable-solutions dot net 2007-01-10 03:33
---
Subject: Re: SIGSEGV in valarray::cshift(n) on empty array
"sebor at roguewave dot com" <[EMAIL PROTECTED]> writes:
| (In reply to comment #3)
| > The standard refers to "(l+n)%size()", so if size()=0, that
--- Comment #6 from gdr at integrable-solutions dot net 2007-01-10 03:32
---
Subject: Re: SIGSEGV in valarray::cshift(n) on empty array
"chris at bubblescope dot net" <[EMAIL PROTECTED]> writes:
| The standard refers to "(l+n)%size()", so if size()=0, that seems to be
| undefined. On
--- Comment #2 from kuba at et dot pl 2007-01-10 03:08 ---
Ok, I've found that my patch doesn't work when we also you schedule clause :>
I'll try to correct that, but I would like to know if my first patch is
correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30421
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |normal
Keywords||diagnostic
h
--- Comment #30 from mrs at apple dot com 2007-01-10 02:51 ---
Testing looks good:
http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00414.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
--- Comment #1 from kuba at et dot pl 2007-01-10 02:49 ---
Created an attachment (id=12877)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12877&action=view)
in 'expand_omp_for_static_nochunk' iterator is set before first condition.
This is my first patch for GCC. Please be lenien
Compiling the following code with "gcc -fopenmp -Wuninitialized -O",
I get a warning: 'i' may be used uninitialized in this function
--
int main() {
int a = 0;
int i;
#pragma omp parallel for firstprivate(a) lastprivate(a)
for(i = 0; i < 10; i++) {
a += i;
--- Comment #2 from hjl at lucon dot org 2007-01-10 02:22 ---
I configured gcc with
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
\
\
--enable-shared \
--enable-threads=posix \
--enable-hai
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
CC||brooks at gcc dot gnu dot
|
Consider the following program:
program ibclr_test
write(*,*) ibclr(-1_1, 7)
end
This gives an error of:
write(*,*) ibclr(-1_1, 7)
1
Error: Result of IBCLR overflows its kind at (1)
The problem is that in the mpz_t representation, -1_1 is represented as a
string of 1 bits, a
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-10 01:43 ---
How did you configure?
Did you use 'make -j'?
Is there anything else we should know?
There's not enough info in this report to do anything useful, I'm afraid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30419
--- Comment #12 from gnb at melbourne dot sgi dot com 2007-01-10 01:25
---
Today I received a notification from the copyright-clerk:
> Hello Greg,
>
>
With gcc version 4.3.0 20070109 (experimental) [trunk revision 120621], I
got
/creating gcj-dbtool
tmp/ccPLaSUv.o: In function `main':
/tmp/ccDIVwvV.i:11: undefined reference to
`gnu::classpath::tools::rmiregistry::Main::class$$'
collect2: ld returned 1 exit status
make[7]: *** [gr
--- Comment #29 from rakdver at gcc dot gnu dot org 2007-01-10 00:55
---
Created an attachment (id=12876)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12876&action=view)
A fixed patch.
Not quite, I forgot to rewrite several occurences of addr to addr_off in the
function. Here i
--- Comment #28 from mrs at apple dot com 2007-01-10 00:48 ---
Testing with:
--- tree-ssa-address.c.~2~ 2007-01-09 16:26:28.0 -0800
+++ tree-ssa-address.c 2007-01-09 16:34:10.0 -0800
@@ -244,7 +244,7 @@
tree
tree_mem_ref_addr (tree type, tree mem_ref)
{
- tree
--- Comment #2 from danglin at gcc dot gnu dot org 2007-01-10 00:44 ---
Still see this in 4.0.4. Gdb is now working somewhat better. Here's
a better backtrace:
Program received signal SIGSEGV, Segmentation fault.
_Unwind_SjLj_RaiseException (exc=0x40012808) at ../../gcc/gcc/unwind-sjl
--- Comment #8 from rakdver at gcc dot gnu dot org 2007-01-10 00:44 ---
Subject: Bug 30322
Author: rakdver
Date: Wed Jan 10 00:44:26 2007
New Revision: 120630
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120630
Log:
PR tree-optimization/30322
* tree-ssa-loop-iv
--- Comment #27 from mrs at apple dot com 2007-01-10 00:30 ---
Breaks the build:
../../gcc/gcc/tree-ssa-address.c: In function 'tree_mem_ref_addr':
../../gcc/gcc/tree-ssa-address.c:272: warning: 'addr' is used uninitialized in
this function
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #26 from mrs at apple dot com 2007-01-10 00:19 ---
Spinng a testsuite run now of Zdenek's patch...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
--- Comment #25 from pinskia at gcc dot gnu dot org 2007-01-10 00:08
---
For -fPIC testcases, you should do:
/* { dg-do compile { target fpic } } */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
--- Comment #24 from rakdver at gcc dot gnu dot org 2007-01-10 00:04
---
Created an attachment (id=12875)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12875&action=view)
A patch
I am testing the attached patch. It would be great if someone could test it on
i386-apple-darwin.
--- Comment #10 from danglin at gcc dot gnu dot org 2007-01-10 00:03
---
I see this on hppa2.0w-hp-hpux11.11 with 4.0.4.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from danglin at gcc dot gnu dot org 2007-01-09 23:59 ---
I still see this with 4.0.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24107
--- Comment #23 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-01-09 23:49 ---
Subject: Re: gfortran miscompiled
> So I'm wondering, does:
>
> Doing diffs in .:
> --- ./tree-ssa-address.c.~1~2006-12-22 21:07:11.0 -0800
> +++ ./tree-ssa-address.c2007
--- Comment #22 from mrs at apple dot com 2007-01-09 23:34 ---
So I'm wondering, does:
Doing diffs in .:
--- ./tree-ssa-address.c.~1~2006-12-22 21:07:11.0 -0800
+++ ./tree-ssa-address.c2007-01-09 15:30:42.0 -0800
@@ -483,7 +483,7 @@ addr_to_parts (aff_tree *a
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-09 23:20 ---
Maybe fold_convert_const_int_from_int should not set TREE_OVERFLOW on
conversions
that conform to implementation defined behavior. Dunno. Or I should not
assert here. Or we should clear those flags at some point.
--- Comment #5 from pcarlini at suse dot de 2007-01-09 23:17 ---
Well, IMHO, avoiding this SIGSEGV is so easy, I would change anyway both shift
and cshift (i.e., wrap everything in a check that size() > 0), and be done with
it, if nobody strongly disagree... While we are at it, quickly l
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-01-09 23:13 ---
Subject: Bug 30321
Author: tkoenig
Date: Tue Jan 9 23:13:42 2007
New Revision: 120623
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120623
Log:
2007-01-08 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-09 23:01 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #2 from lucier at math dot purdue dot edu 2007-01-09 22:58
---
Subject: Re: Bootstrap failure: ICE in function '__enable_execute_stack':
libgcc2.c:2024 bus error
Absolutely correct (the very next checkin ;-). I just sent in "Make
check" results.
For some reason I'm hav
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-09 22:44 ---
The same happens in 4.2, so it's not because of my patches. *phew*
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30418
--- Comment #4 from sebor at roguewave dot com 2007-01-09 22:34 ---
(In reply to comment #3)
> The standard refers to "(l+n)%size()", so if size()=0, that seems to be
> undefined. On the other hand, it seems fairly obvious what should happen in
> this case (ie nothing).
The requirement
Reduced from libiberty:
char ada_demangle (const char *mangled, int len0)
{
int i;
for (i = len0 - 2; i >= 0 && mangled[i]; i -= 1)
;
return mangled[i];
}
in tree-ssa-loop-ivopts.c:
static void
rewrite_use_compare (struct ivopts_data *data,
struct iv_use *use, stru
--- Comment #3 from chris at bubblescope dot net 2007-01-09 22:21 ---
The standard refers to "(l+n)%size()", so if size()=0, that seems to be
undefined. On the other hand, it seems fairly obvious what should happen in
this case (ie nothing).
On an unrelated note, isn't there a another b
--- Comment #12 from dominiq at lps dot ens dot fr 2007-01-09 22:10 ---
Subject: Re: ICE in LOGICAL(8) functions
> In C (and C++) Boolean types only have one size ...
Too bad!-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406
--- Comment #1 from e9fritte at etek dot chalmers dot se 2007-01-09 22:09
---
Adding me to CC list.
--
e9fritte at etek dot chalmers dot se changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-01-09 22:08
---
(In reply to comment #10)
> Second, what is the C equivalent of logical(8)? I am wondering
> if the same ICE occurs in the equivalent C code.
In C (and C++) Boolean types only have one size, on ppc-darwin that siz
--- Comment #10 from dominiq at lps dot ens dot fr 2007-01-09 22:06 ---
Subject: Re: ICE in LOGICAL(8) functions
First, the crash report I have posted yesterday has nothing to do
with this bug that is really an internal compiler error (caught
within the compiler) and not a crash.
Seco
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 22:05 ---
We no longer run jacks on svn trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from gdr at integrable-solutions dot net 2007-01-09 22:05
---
Subject: Re: New: SIGSEGV in valarray::cshift(n) on empty array
"sebor at roguewave dot com" <[EMAIL PROTECTED]> writes:
| AFAIK, the program below should have well-defined behavior but it abends with
| gcc
When linking for the AVR ATMega88 the gcc driver adds an option -Tdata=0x800100
to ld that makes it impossible to move the .data section to a different
location. For example, trying to reserve some SRAM for a bootloader with
avr-gcc -g -Wall -Os -mcall-prologues -mmcu=atmega88
-Wl,-Map,main.map,-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-09 22:02 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
AFAIK, the program below should have well-defined behavior but it abends with
gcc 4.1.0 on Solaris 9.
$ cat t.cpp && g++ -g t.cpp -static && gdb ./a.out
#include
int main ()
{
const std::valarray a;
a.cshift (1);
}
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is fr
--- Comment #17 from dberlin at gcc dot gnu dot org 2007-01-09 21:42
---
Subject: Re: Compiling FreeFem3d uses unreasonable amount of time and memory
Try the attached, let me know how it goes.
On 9 Jan 2007 21:17:05 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
Try the attached, let me know how it goes.
On 9 Jan 2007 21:17:05 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-01-09 21:17
---
Pling!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
--- gcc/tree
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-01-09 21:33
---
Closing, please reopen when you have more info.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-01-09 21:30 ---
Created an attachment (id=12873)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12873&action=view)
patch (currently regtesting)
This fixes the test case. It's currently in regression test.
Thomas
--
http
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-01-09 21:17
---
Pling!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-01-09 20:52
---
Ok, a cross-compiler to i386-apple-darwin8.8.1 and -O -ftree-vrp -fPIC
reproduces the bug. Defering to Zdenek for a fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
--
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 #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #13 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #8 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #6 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #8 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #6 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
t
--- Comment #21 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.
--
1 - 100 of 230 matches
Mail list logo
