Hi,
the following code does not link:
program gfcbug55
integer(kind=1) :: i1(4) = 1
integer(kind=2) :: i2(4) = 1
print *, minloc(i1), minloc(i2) ! These are missing
print *, maxloc(i1), maxloc(i2) ! from libgfortran
end program gfcbug55
Cheers,
-ha
--
Summary:
--- Comment #2 from pault at gcc dot gnu dot org 2007-01-09 08:59 ---
I am just about to submit a patch.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from patchapp at dberlin dot org 2007-01-09 09:10 ---
Subject: Bug number PR30410
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00647.html
--
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #9 from patchapp at dberlin dot org 2007-01-09 09:35 ---
Subject: Bug number PR29145
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00648.html
--
--- Comment #7 from pault at gcc dot gnu dot org 2007-01-09 09:41 ---
Kaveh,
I haven't the slightest idea what is happening. These cases test fine on
IA64/FC5 with gcc-4.1.2-20061101.
The worst of it is, to judge by your gdb output, that they are not obviously
faults that would come
--- Comment #2 from rearnsha at gcc dot gnu dot org 2007-01-09 10:09
---
Subject: Bug 30173
Author: rearnsha
Date: Tue Jan 9 10:08:49 2007
New Revision: 120613
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120613
Log:
2007-01-09 Nicolas Pitre [EMAIL PROTECTED]
PR
--- Comment #3 from rearnsha at gcc dot gnu dot org 2007-01-09 10:12
---
Subject: Bug 30173
Author: rearnsha
Date: Tue Jan 9 10:11:53 2007
New Revision: 120614
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120614
Log:
2007-01-09 Nicolas Pitre [EMAIL PROTECTED]
PR
--- Comment #4 from rearnsha at gcc dot gnu dot org 2007-01-09 10:15
---
Subject: Bug 30173
Author: rearnsha
Date: Tue Jan 9 10:14:54 2007
New Revision: 120615
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120615
Log:
2007-01-09 Nicolas Pitre [EMAIL PROTECTED]
PR
--- Comment #5 from rearnsha at gcc dot gnu dot org 2007-01-09 10:17
---
Subject: Bug 30173
Author: rearnsha
Date: Tue Jan 9 10:17:02 2007
New Revision: 120616
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120616
Log:
2007-01-09 Nicolas Pitre [EMAIL PROTECTED]
PR
--- Comment #6 from rearnsha at gcc dot gnu dot org 2007-01-09 10:20
---
Fixed on trunk and all active release branches
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rearnsha at gcc dot gnu dot org 2007-01-09 11:01
---
It's worse than that. compute_init_costs makes a number of broken assumptions.
Not least of which is that it assumes that gen_... functions in machine
description files will return the pattern of a single insn.
--- Comment #6 from rearnsha at gcc dot gnu dot org 2007-01-09 11:10
---
(In reply to comment #4)
I see:
ldrdr2, [r1], #328
Which isn't a valid instruction (the offset is too large).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29983
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-01-09 11:11 ---
In the middle-end this somewhat is related to PR26387. Of course this is a
place
where frontend optimization is probably easier to do.
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-01-09 11:55
---
Remove the patch keyword, change component to bootstrap as it now isn't
Fortran-specific anymore.
From my proposal (one year ago, see comment #4) to have the build machinery
adjust LD_LIBRARY_PATH (or similar
--- Comment #31 from fxcoudert at gcc dot gnu dot org 2007-01-09 11:59
---
Patch proposed here: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00659.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #49 from rguenth at gcc dot gnu dot org 2007-01-09 12:55
---
This is fixed on the mainline. It is maybe worth backporting as it cannot be
worked around.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.0 4.2.0
Last reconfirmed|2006-10-19 22:24:34
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-01-09 13:14
---
Do we know why this only fails on darwin? If it is a VRP bug we should be able
to produce a generic testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from Bil dot Kleb at NASA dot gov 2007-01-09 13:15 ---
No warnings with -Wall -- we've been busy cleaning the last few months.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30367
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-01-09 13:33
---
The problem is definitely the following overflowing mutliplication
which is introduced by ivopts (I'm looking at Tobias dump files):
D.27347_74 = (union tree_node * *) n_30;
D.27348_76 = D.27347_74 *
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-01-09 13:42
---
(which gcc version are the dumps created with?)
First IVOPTs should not create pointer multiplication. Really. Second, the
problem is probably in tree-vrp.c:adjust_range_with_scev () or SCEV itself -
I guess
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-09 14:06 ---
This should have been fixed by:
2007-01-08 Jan Hubicka [EMAIL PROTECTED]
* tree-vectorizer.c (gate_increase_alignment): Fix return type.
* ipa.c (function_and_variable_visibility): Fix return
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-01-09
14:08 ---
Subject: Re: [hppa64-hp-hpux11.11] libstdc++-v3 fails to build with HP
assembler
--- Comment #8 from jbuck at gcc dot gnu dot org 2007-01-09 05:18 ---
OK, I'm going to artificially flag this
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-09 14:19 ---
What name do you want for the warning? Wenum-mismatch ?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-09 14:24 ---
I could also add it to the new -Wconversion option. I think it is appropriate.
Yet that would change default behaviour, since this warning is unconditional
and -Wconversion must be explicitly enabled and it is not
--- Comment #12 from manu at gcc dot gnu dot org 2007-01-09 14:36 ---
This seems similar to PR 12963. I am preparing a patch for this
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from tobi at gcc dot gnu dot org 2007-01-09 14:37 ---
(In reply to comment #14)
(which gcc version are the dumps created with?)
Should be the trunk from 2006-11-25. Thanks for looking into this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-09 14:43 ---
I think you should bring the issue in the GCC mailing list to check out what
people think. Also, if you could propose a name and testcases (for warning and
for not warning), it would help whoever takes the burden of
--- Comment #11 from manu at gcc dot gnu dot org 2007-01-09 14:50 ---
There is an unreviewed patch to name this warning in the patch queue:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00520.html
I guess it doesn't solve all the inconsistencies mentioned here but at least it
can be
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-09 14:57 ---
Another Wsequence-point bug is PR 17880.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-09 15:02 ---
Have you tried compiling with -pedantic -Wall -Wextra ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21917
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-09 15:06 ---
Is the warning a good idea because it is a function call, so it may be a
confused call to quak, or simply because it is unsigned converted to enum ?
--
manu at gcc dot gnu dot org changed:
What
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-09 15:09 ---
(In reply to comment #0)
Is this a bug either in GCC or a bug in documentation?
It is a bug in the documentation. As today in GCC 4.3 there is not a single
Wextra warning that has anything to do with
--- Comment #50 from hjl at lucon dot org 2007-01-09 15:11 ---
The (In reply to comment #49)
This is fixed on the mainline. It is maybe worth backporting as it cannot be
worked around.
The backported patches for gcc 4.1/4.2 are at
--- Comment #8 from ghazi at gcc dot gnu dot org 2007-01-09 15:13 ---
(In reply to comment #7)
Kaveh,
I haven't the slightest idea what is happening. These cases test fine on
IA64/FC5 with gcc-4.1.2-20061101.
The worst of it is, to judge by your gdb output, that they are not
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-09 15:15 ---
Maybe we shouldn't show any warning when converting NULL to boolean. Perhaps in
time for the new Wconversion option...
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-09 15:21 ---
Wextra warns for this, what is the bug?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ghazi at gcc dot gnu dot org 2007-01-09 15:23 ---
Assigned so that Paul gets replies.
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30399#c8
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rakdver at gcc dot gnu dot org 2007-01-09 15:30 ---
(In reply to comment #6)
It seems to be IVOPTs rewriting introduces the trees. Testcase:
Which happens because fold causes the number of iterations of the loop to be
something like e + ~f, and then is not able to
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-09 15:30 ---
(convert_like_real gives me the creeps.)
I must check whether this warning has been taken by the new Wconversion, which
is not currently enabled by Wall.
--
manu at gcc dot gnu dot org changed:
What
--- Comment #9 from rearnsha at gcc dot gnu dot org 2007-01-09 15:48
---
gdb's configure uses AC_LIB_HAVE_LINKFLAGS to test for expat. This correctly
sets up the right link flags so that applications will find the shared library.
Is there any reason we can't use that for GMP/MPFR?
--- Comment #10 from manu at gcc dot gnu dot org 2007-01-09 16:03 ---
Fixed in GCC 4.3
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-01-09 16:05
---
Works for me on i386-darwin with gfortran 4.3.0 20070109 (experimental).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from kargl at gcc dot gnu dot org 2007-01-09 16:08 ---
Note, above the first FORALL statement one needs to add
the following 2 lines of code
xmin = 0.
xmax = 1.
As a side note, both Pathscale and Intel in the c.l.f thread have
acknowledged that their compilers also
--- Comment #5 from bonzini at gnu dot org 2007-01-09 16:08 ---
I'll take a look.
--
bonzini at gnu dot org changed:
What|Removed |Added
CC|
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-01-09 16:13
---
Confirmed on MacOS 10.4.8, using gfortran 4.3.0 20070102 (experimental). Cannot
do more at the moment.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from igodard at pacbell dot net 2007-01-09 16:36 ---
No message on 4.1.1 despite -pedantic -Wall -Wextra
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21917
--- Comment #7 from rearnsha at gcc dot gnu dot org 2007-01-09 17:01
---
Confirmed. This is iwmmxt-specific and occurs because the co-processor
load-double-word instructions have a larger offset than LDRD.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from gary at intrepid dot com 2007-01-09 17:40 ---
http://sourceware.org/ml/gdb/2007-01/msg00147.html
From: Gary Funck gary at intrepid dot com
To: gdb at sourceware dot org
Date: Tue, 9 Jan 2007 09:01:38 -0800
Subject: RE: how to support C type qualifiers
--- Comment #16 from tobi at gcc dot gnu dot org 2007-01-09 18:21 ---
Dumps from today's mainline (r120620) are at
http://www.cip.physik.uni-muenchen.de/~tobias.schlueter/dump2.tar.bz2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
--- Comment #4 from gdr at integrable-solutions dot net 2007-01-09 18:41
---
Subject: Re: missed warnings about comparisons which are always true/false.
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Wextra warns for this, what is the bug?
I believe pluto wants
--- Comment #5 from gdr at integrable-solutions dot net 2007-01-09 18:43
---
Subject: Re: warning for comparison of different enum types impossible to
control/is undocumented
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| What name do you want for the warning?
--- Comment #6 from gdr at integrable-solutions dot net 2007-01-09 18:44
---
Subject: Re: warning for comparison of different enum types impossible to
control/is undocumented
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| I could also add it to the new -Wconversion option.
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 18:46 ---
We already only support 'extern Java' classes where the body of the
class is written in Java and compiled with gcj. The reason for this is
that a Java class has a lot of required metadata which g++ does not know
how
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-09 19:25 ---
Janis,
Can you do a regression hunt on this bug?
Thanks, Andrew
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from mrs at apple dot com 2007-01-09 20:11 ---
Thanks delta:
$ ./xgcc -B./ -c -O t.i -fdump-tree-all grep ' * 4294967292B;'
*.087t.ivopts
D.2035_3 = D.2034_2 * 4294967292B;
$ cat t.i
typedef struct gfc_se { int pre; } gfc_se;
typedef struct gfc_ss_info { int dim[7];
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-09 20:28 ---
(In reply to comment #4)
Subject: Re: missed warnings about comparisons which are always true/false.
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Wextra warns for this, what is the bug?
I believe
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-01-09 20:32
---
So what else is special about darwin? I built a --enable-targets=all compiler
and am using
./cc1 -quiet -O2 t.i -fdump-tree-ivopts -march=nocona -mtune=generic
can you report how you configured gcc and how you
--- Comment #2 from pault at gcc dot gnu dot org 2007-01-09 20:36 ---
(In reply to comment #1)
A look into resolve.c's resolve_where, shows that only EXEC_ASSIGN and not
EXEC_ASSIGN_CALL exists in switch (cnext-op).
Expected: As elemental procedures are also allowed, a case
--- Comment #6 from tromey at gcc dot gnu dot org 2007-01-09 20:37 ---
Andrew's fix for this went in with the merge.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tromey at gcc dot gnu dot org 2007-01-09 20:43 ---
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:43 ---
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:43 ---
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 #10 from tromey at gcc dot gnu dot org 2007-01-09 20:43 ---
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 #4 from tromey at gcc dot gnu dot org 2007-01-09 20:43 ---
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 #5 from tromey at gcc dot gnu dot org 2007-01-09 20:43 ---
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 #4 from tromey at gcc dot gnu dot org 2007-01-09 20:43 ---
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:43 ---
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 #5 from tromey at gcc dot gnu dot org 2007-01-09 20:43 ---
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 #5 from tromey at gcc dot gnu dot org 2007-01-09 20:43 ---
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 #9 from tromey at gcc dot gnu dot org 2007-01-09 20:44 ---
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 #10 from tromey at gcc dot gnu dot org 2007-01-09 20:43 ---
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 #2 from tromey at gcc dot gnu dot org 2007-01-09 20:44 ---
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 #6 from tromey at gcc dot gnu dot org 2007-01-09 20:44 ---
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 #4 from tromey at gcc dot gnu dot org 2007-01-09 20:44 ---
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 #2 from tromey at gcc dot gnu dot org 2007-01-09 20:44 ---
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 #4 from tromey at gcc dot gnu dot org 2007-01-09 20:44 ---
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:44 ---
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:44 ---
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 #11 from tromey at gcc dot gnu dot org 2007-01-09 20:44 ---
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 #1 from tkoenig at gcc dot gnu dot org 2007-01-09 20:44 ---
Yep.
I'll have a look.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-09 20:44 ---
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 #7 from tromey at gcc dot gnu dot org 2007-01-09 20:44 ---
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 #4 from tromey at gcc dot gnu dot org 2007-01-09 20:45 ---
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:45 ---
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 #10 from tromey at gcc dot gnu dot org 2007-01-09 20:45 ---
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 #19 from rakdver at gcc dot gnu dot org 2007-01-09 20:45
---
(In reply to comment #14)
(which gcc version are the dumps created with?)
First IVOPTs should not create pointer multiplication. Really. Second, the
problem is probably in tree-vrp.c:adjust_range_with_scev
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-09 20:44 ---
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 #6 from tromey at gcc dot gnu dot org 2007-01-09 20:44 ---
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 #8 from tromey at gcc dot gnu dot org 2007-01-09 20:45 ---
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 #4 from tromey at gcc dot gnu dot org 2007-01-09 20:45 ---
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 #7 from tromey at gcc dot gnu dot org 2007-01-09 20:44 ---
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 #6 from tromey at gcc dot gnu dot org 2007-01-09 20:45 ---
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 #2 from tromey at gcc dot gnu dot org 2007-01-09 20:45 ---
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 #4 from tromey at gcc dot gnu dot org 2007-01-09 20:45 ---
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:45 ---
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 #2 from tromey at gcc dot gnu dot org 2007-01-09 20:45 ---
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 #2 from tromey at gcc dot gnu dot org 2007-01-09 20:46 ---
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:46 ---
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
