Mark Mitchell wrote:
1. Move the ChangeLog entries on the 4.0 branch to accurately reflect
the released bits.
2. Modify Bugzilla to reset the target milestone for the three PRs in
question.
3. Modify gcc_release to prevent this situation in future.
These steps have now been taken.
--
Dear Amazon member,
Due to concerns we have for the safety and integrity of the Amazon community we
have issued this warning.
Per the User Agreement, Section 9, we may immediately issue a warning,
temporarily suspend, indefinitely suspend or terminate your membership and
refuse to provide
Eric Botcazou wrote:
Agreed. But I'm requesting a caveat note about the Solaris regression here:
http://gcc.gnu.org/gcc-4.0/changes.html#4.0.2
mentioning the workaround (g++ -pthreads) and the link:
http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00984.html
Done.
Thanks,
--
Mark Mitchell
Done.
Thank you very much.
--
Eric Botcazou
Hello,
I am an embedded software developer and I am interested in using GCC as a
cross-compiler on the Cygwin/Windows platform. I would like to know which
lists I should subscribe to in order to discuss this effort.
Thank you,
--
Brian
On 10/1/05, Brian Rose [EMAIL PROTECTED] wrote:
Hello,
I am an embedded software developer and I am interested in using GCC as a
cross-compiler on the Cygwin/Windows platform. I would like to know which
lists I should subscribe to in order to discuss this effort.
you might want to have a
Laurent GUERBY wrote:
However I see no reason why Osint body elaboration must be done
before Osint.M body elaboration, it seems to me that the
binder could perfectly choose to elaborate Osint.M body
before Osint body, and this would leave Running_Program
with the wrong value Rainer observes
(I indeed forgot about the static model which is the default for GNAT)
On Sat, 2005-10-01 at 08:37 -0400, Robert Dewar wrote:
[...] You can of course check the order of elaboration by
looking at it. I would be surprised if there were a
bug in the statid elab model for such a simple case,
and
To recap the current state as far as I know it:
The disclaimers I sent in for both Asher Langton and myself
were the same wording as the one from Christoper Michael Chambreau.
We did that to make it easier to get the GNU Assignment. :-)
Secondly, the letter I sent to the copyright clerk
On Monday 26 September 2005 10:38, Paolo Bonzini wrote:
Right now, I am thinking more
about shuffling the pass order. One possibility that comes to mind is
GCSE+fwprop+CSE, where GCSE could work out the common code for loading
the address, and fwprop/CSE could do the addressing mode selection
On Fri, Sep 30, 2005 at 04:31:59PM -0700, Dale Johannesen wrote:
No, there isn't, but it might be a smaller change to add a new
constraint
having constraints tied to specific constants is pretty ugly, and so is
having (if (constant value==0)) in a lot of patterns..,,
That's why
Richard Guenther [EMAIL PROTECTED] writes:
Hi!
On current mainline-gcc install-pkglibLTLIBRARIES fails re-linking
libjawtgnu:
make[5]: Entering directory
`/usr/src/packages/BUILD/gcc-4.1.0-20050929/obj-i586-suse-linux/i586-suse-linux/libjava/classpath/native/jawt'
test -z
Laurent GUERBY wrote:
If I'm reading it correctly, osint body is elaborated after osint.m one,
so there seem to be a bug.
I agree, looks like a bug
May be it doesn't trigger because in some
condition/platform no code is needed at runtime for the default
initialization of integer variables
On Sep 30, 2005, Benjamin Redelings [EMAIL PROTECTED] wrote:
Recently I've been getting strange errors on ill-formed code. It looks
as if the compiler is not stopping after an error, but running the
assembler anyway:
Are you compiling with -pipe, by any chance?
--
Alexandre Oliva
int f(int *);
int verbosity;
int *arr;
int last;
void g ()
{
int i;
if (last 4000) {
if (verbosity = 4) f(verbosity);
for (i = 0; i = last; i++) arr[i] = i;
}
}
If last != 0, arr+i cannot point to last for any i,
as last is not part of
Snapshot gcc-4.1-20051001 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20051001/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 CVS branch
with the following options: -D2005-10-01 17:43 UTC
You'll find
Andreas == Andreas Jaeger [EMAIL PROTECTED] writes:
Andreas So, the problem should be reproducable in the following cases: Using
Andreas DESTDIR and having no libgtkpeer installed in a standard path. Tom,
Andreas this still appears with todays sources and worked before the classpath
Andreas
This used to always be off, but the email preferences code in the new
bugzilla actually works properly, so i let it take care of it.
To disable getting emails about this, uncheck the boxes for
Any field not mentioned above changes in your email preferences.
Andreas Jaeger [EMAIL PROTECTED] writes:
Looking closer at this, it seems to be a problem with DESTDIR that you
use. libgtkpeer is installed - but it's installed in
/var/tmp/gcc-mainline-4.1.0_20050929-build/usr/lib/classpath/ - and
that path is not added to the Link line.
That's due to the
In C++, when we have an automatic array with variable initializers:
void bar(char[4]);
void foo(char a, char b, char c, char d) {
char x[4] = { a, b, c, d };
bar(x);
}
the C++ FE generates 32-bit store(s) of 0 for the entire array,
followed by stores
of the individual elements. In the
George White wrote:
Frankly, I don't care what standards say is no longer acceptable
syntax.
The standards have existed for quite some time, giving you plenty of
time to get acquainted with the rules. Standards exist for a reason, and
if you choose not to follow them, it is not the fault of
On Oct 1, 2005, at 5:54 PM, Dale Johannesen wrote:
In C++, when we have an automatic array with variable initializers:
void bar(char[4]);
void foo(char a, char b, char c, char d) {
char x[4] = { a, b, c, d };
bar(x);
}
Testsuite passes with this but I can believe improvements are
C++ would be a better language if the boolean type did not implicitly
convert from int. For example, many novice programmers make the
mistake.
if (i = j) dosomething(); // Should be i == j
If conversion to boolean required explicit this would all be solved. It
would mean all the old code with
C++ would be a better language if the boolean type did not implicitly
convert from int. For example, many novice programmers make the
mistake.
if (i = j) dosomething(); // Should be i == j
If conversion to boolean required explicit this would all be solved. It
would mean all the old
On Oct 1, 2005, at 7:29 PM, Andrew Pinski wrote:
I don't think this will work for the following code:
void foo(char a, char b) {
char x[4] = { a, b } ;
if (x[3] != 0)
abort ();
}
Duh. I thought that was too easy.
But better fix would be not call split_nonconstant_init_1 for
local
Andrew Pinski wrote:
But any thing else would just be a violation of the C and C++ standards.
I don't see that at all, optional switches/pragmas/directives that
subset the language are in no ways violation of the standards. THe
standard only requires that you have a mode in which the standard
Hi Andrew,
I was hoping was that we could at least have a compile option. So we could
turn it on if required. I would definitely mandate it in our organization
at least. I am sure others would too.
We have a prepared list of common errors C++ novices make and the
accidental boolean is
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-10-01
06:20 ---
Subject: Bug 23891
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-01 06:20:39
Modified files:
libjava:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-10-01
06:49 ---
Subject: Bug 21418
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-01 06:49:23
Modified files:
gcc/java :
--- Additional Comments From mckinlay at redhat dot com 2005-10-01 06:58
---
Fixed on both HEAD and 4.0 branch.
--
What|Removed |Added
Status|ASSIGNED
--
Bug 24018 depends on bug 23891, which changed state.
Bug 23891 Summary: [4.0 Regression] Problem folding static fields across
packages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23891
What|Old Value |New Value
I found by pure accident that g++ allows the RHS of an initialization to be the
very variable that is being initialized. Two minimalist examples are given
below. The same behavior is present under gcc 2.95.2, 3.3.3, and 3.4.1.
I'm suprised that the new variable is even considered to be defined
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-10-01
07:39 ---
Subject: Bug 20835
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-01 07:39:08
Modified files:
gcc/fortran: ChangeLog gfortran.h match.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-10-01
07:39 ---
Subject: Bug 20890
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-01 07:39:08
Modified files:
gcc/fortran: ChangeLog gfortran.h match.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-10-01
07:39 ---
Subject: Bug 20901
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-01 07:39:08
Modified files:
gcc/fortran: ChangeLog gfortran.h match.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-10-01
07:39 ---
Subject: Bug 20902
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-01 07:39:08
Modified files:
gcc/fortran: ChangeLog gfortran.h match.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-10-01
07:39 ---
Subject: Bug 20900
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-01 07:39:08
Modified files:
gcc/fortran: ChangeLog gfortran.h match.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-10-01
07:39 ---
Subject: Bug 20899
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-01 07:39:08
Modified files:
gcc/fortran: ChangeLog gfortran.h match.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-10-01
07:39 ---
Subject: Bug 16404
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-01 07:39:08
Modified files:
gcc/fortran: ChangeLog gfortran.h match.c
[EMAIL PROTECTED] mytests]# cat snafu.f90
module snafu
type :: a
type(b):: i
end type a
type :: b
type(c):: i
end type b
type :: c
type(a):: i
end type c
type (a) :: foo
end module snafu
[EMAIL PROTECTED] mytests]#
--- Additional Comments From mark at gcc dot gnu dot org 2005-10-01 08:44
---
Confirmed. I am also seeing this on my old PPC box which has just 192MB real
memory. Since it has enough swap it does finish after a couple of hours of
swapping like mad.
--
What|Removed
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-10-01
08:53 ---
I'm confused about the status of this bug. I believe it is fixed on the 4.0
branch (originally for 4.0.2, but due to the release both, actually for 4.0.3).
However, this bug is still marked as New. If
--- Additional Comments From tilo at pruetz dot net 2005-10-01 09:01
---
Is there any hope that this bug will be fixed in a GCC release?
It really sucks to have to patch every new installed release.
What can I do to make the fix do it's way into a GCC release?
--
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-10-01
09:02 ---
I'm confused about the status of this bug. I believe it is fixed on the 4.0
branch (originally for 4.0.2, but due to the release both, actually for
4.0.3).
However, this bug is still marked as New.
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-10-01
09:17 ---
OK, I have unset the target milestone.
Thanks,
-- Mark
--
What|Removed |Added
Target
--- Additional Comments From pault at gcc dot gnu dot org 2005-10-01 09:40
---
Sorry, I meant to say that the recursiveness is not being resolved.
I have a fix in the pipeline.
--
What|Removed |Added
gcc version 3.4.4 build fails with the following type of errors :
ld: fatal: relocation error: R_SPARC_DISP32: file .libs/allocator.o: symbol
unknown: offset 0x74cce9e1 is non-aligned
ld: fatal: relocation error: R_SPARC_DISP32: file .libs/codecvt.o: symbol
unknown: offset
--- Additional Comments From biswadip at cal dot interrasystems dot com
2005-10-01 10:44 ---
Created an attachment (id=9854)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9854action=view)
Outfile error in the file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24159
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-10-01 11:00 ---
Subject: Re: [4.0/4.1 Regression] gcc.dg/asm-1.c (test
for excess errors) fails
pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-10-01
11:07 ---
This path is OK, without the spurious addition of the blank line.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
The example (attached below), when compiled by following gcc
---
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../../gcc-CVS-20050930/gcc-CVS-20050930/configure
--host=i686-pc-linux-gnu --prefix=/usr/local/opt/gcc-4.1
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz
2005-10-01 12:57 ---
Created an attachment (id=9855)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9855action=view)
This triggers the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24160
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz
2005-10-01 13:05 ---
(In reply to comment #0)
...
---
gcc -c -O3 -finline-limit=1024 -ftree-vectorize -ftracer -o minilzo.o
minilzo.c
---
It works when you either remove any of the
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-10-01
13:31 ---
Subject: Bug 23985
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-10-01 13:31:39
Modified files:
gcc:
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-10-01
13:33 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-10-01
13:57 ---
Subject: Bug 23604
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-01 13:57:30
Modified files:
gcc/testsuite : ChangeLog
gcc:
// A template class.
template typename, typename struct f {};
// A template function that calls a member template function.
template typename T
void call_f( T t )
{
t.template f int ();
// t.T::template f int (); // this line works
}
struct F {
template typename void f() {}
};
int
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-10-01
14:00 ---
Subject: Bug 24141
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-01 14:00:09
Modified files:
gcc: ChangeLog tree-vrp.c
--- Additional Comments From redi at gcc dot gnu dot org 2005-10-01 14:18
---
Matthew has a point about Hiddenint being confusing in the diagnostic, as
Hidden is not a template.
I notice if you define the Hidden constructor inline in the Hideint::Hidden
class body then it works (with
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-10-01
14:19 ---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00020.html
--
What|Removed |Added
--
Bug 23603 depends on bug 23604, which changed state.
Bug 23604 Summary: [4.1 Regression] wrong code due to VRP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23604
What|Old Value |New Value
--
Bug 23968 depends on bug 23604, which changed state.
Bug 23604 Summary: [4.1 Regression] wrong code due to VRP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23604
What|Old Value |New Value
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-10-01
14:20 ---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00021.html
--
What|Removed |Added
--
Bug 23968 depends on bug 24141, which changed state.
Bug 24141 Summary: [4.1 regression] VRP ICE in compare_name_with_value, at
tree-vrp.c:2965
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24141
What|Old Value |New Value
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-10-01 14:36 ---
// Confirmed, reduced testcase (compile with -O1 -ftree-vectorize -msse):
void foo (char **p)
{
int i;
char q [1024], *r;
r = q + unsigned long) q + 3) / 4) * 4) - (unsigned long) q;
--- Additional Comments From redi at gcc dot gnu dot org 2005-10-01 14:41
---
14.7.3/5
Definitions of members of an explicitly specialized class are defined in the
same manner as member of normal classes, and not using the explicit
specialization syntax.
--
--- Additional Comments From redi at gcc dot gnu dot org 2005-10-01 14:52
---
This is a revised version, which should compile but doesn't:
#include iostream
using namespace std;
templatetypename T
class Hide {
public:
Hide();
class Hidden;
private:
Hidden *a;
};
template
--
What|Removed |Added
CC||redi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23885
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-10-01 15:24 ---
(In reply to comment #3)
I'm not so sure that this is a dup. Bug 24141 is a wrong-code problem,
and this is an ICE. Just the fact that the same test case triggers both
bugs doesn't mean
--
Bug 23968 depends on bug 24142, which changed state.
Bug 24142 Summary: [4.1 regression] VRP miscompiles unzip inflate.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24142
What|Old Value |New Value
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-10-01 15:26 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|NEW
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
GCC host
I got the following error output when trying to compile a jar file from the
limewire project (http://www.limewire.org/):
gcj -v -save-temps core.jar
Using built-in specs.
Reading specs from /usr/lib/gcc/i486-linux-gnu/4.0.2/../../../libgcj.spec
rename spec lib to liborig
Target:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-10-01
15:38 ---
Confirmed. This is invalid code unless they used POINTER correct?
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-10-01
15:40 ---
for:
int i = i;
The code is valid but undefined.
You have to use -Winit-self.
*** This bug has been marked as a duplicate of 5582 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-10-01
15:40 ---
*** Bug 24157 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-10-01
15:43 ---
What as version are you using?
--
What|Removed |Added
Component|libstdc++
--- Additional Comments From hubicka at gcc dot gnu dot org 2005-10-01
15:45 ---
Well, if the exception is never raised, the difference in EH code generation is
probably not an issue.
Reverting the patch is definitly possible (there is nothing dependent on it and
except for one or two
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-10-01
15:49 ---
Confirmed, 3.3 accepted the code.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-10-01
15:56 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-10-01
15:56 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-10-01
15:56 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--
Bug 20405 depends on bug 20890, which changed state.
Bug 20890 Summary: initializing two equivalenced variabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20890
What|Old Value |New Value
--
Bug 20405 depends on bug 20901, which changed state.
Bug 20901 Summary: different intrinsic types in equivalence not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20901
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-10-01
15:57 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-10-01
15:57 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-10-01
15:57 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--
Bug 20405 depends on bug 20900, which changed state.
Bug 20900 Summary: use-associated variable may not be equivalenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20900
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-10-01
15:57 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--
Bug 20405 depends on bug 20899, which changed state.
Bug 20899 Summary: pure function may not modify common variable through
equivalence
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20899
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-10-01
15:58 ---
Fixed now.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From dje at gcc dot gnu dot org 2005-10-01 16:00
---
Either GCC is installed or not. If it's installed, you should not need any -B
options.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24119
--- Additional Comments From laurent at guerby dot net 2005-10-01 16:04
---
Ok, no need to revert it right now. I'm trying to reduce it to something
standalone that doesn't call the Ada runtime.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
(I first posted this code to PR5660 but it's apparently a separate issue)
template typename T
struct A
{
typedef T Type;
void f(Type) {}
};
template typename T
struct B : AT
{
typedef typename AT::Type Type;
void ff(Type t) {
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-10-01
16:28 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From ams at gnu dot org 2005-10-01 16:46 ---
You also have access to a GNU system, GNU/Linux. It is easily testable there.
Could you revert the fix? It is better that fails loudly than having a
arbitrary limit.
I'll see about submiting a proper patch.
--
--- Additional Comments From redi at gcc dot gnu dot org 2005-10-01 16:48
---
Adding ... in template to end of title.
--
What|Removed |Added
Summary|Base class
--- Additional Comments From ams at gnu dot org 2005-10-01 16:58 ---
Could someone go over these bugs and commit the pending patches?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824
1 - 100 of 127 matches
Mail list logo
