https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302
--- Comment #14 from Zhenqiang Chen zhenqiang.chen at arm dot com ---
Created attachment 33608
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33608action=edit
patch
After investigation, I found I mis-use tree_log2.
Please try the attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #20 from rguenther at suse dot de rguenther at suse dot de ---
On Fri, 26 Sep 2014, law at redhat dot com wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #14 from Jeffrey A. Law law at redhat dot com ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47413
--- Comment #3 from rguenther at suse dot de rguenther at suse dot de ---
On Fri, 26 Sep 2014, hubicka at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47413
Jan Hubicka hubicka at gcc dot gnu.org changed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37173
--- Comment #5 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #3)
We still might add a -std=f2008 check there.
I find the same wording in my local copy of F2003, actually:
If variable and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37173
Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36534
Bug 36534 depends on bug 37173, which changed state.
Bug 37173 Summary: Check whether intrinsic assignment between character kind=1
/ 4 is allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37173
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Piotr Dziwinski from comment #1)
I would also second the proposal to fix this issue by implementing flat
version of std::tuple. Perhaps the existing std::tr1::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51385
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
This is fixed in 4.9.0, I'm adding the testcase and closing the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405
Bug ID: 63405
Summary: Internal compiler error when building OpenAxiom on
linux/amd64
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51385
--- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org ---
Author: paolo
Date: Mon Sep 29 09:06:31 2014
New Revision: 215680
URL: https://gcc.gnu.org/viewcvs?rev=215680root=gccview=rev
Log:
2014-09-29 Paolo Carlini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51385
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307
--- Comment #1 from Igor Zamyatin izamyatin at gmail dot com ---
Would like to ask here first - will something like following be ok:
diff --git a/gcc/c-family/cilk.c b/gcc/c-family/cilk.c
index bf549ad..f453bc5 100644
--- a/gcc/c-family/cilk.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Target||mingw-w64
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Igor Zamyatin from comment #1)
Would like to ask here first - will something like following be ok:
+typedef struct
+{
+ tree parm;
+ tree arg;
+} decl_pair;
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63406
Bug ID: 63406
Summary: -Warray-bounds false positive with -O3
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655
Julian Taylor jtaylor.debian at googlemail dot com changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #21 from rguenther at suse dot de rguenther at suse dot de ---
nOn Sat, 27 Sep 2014, hubicka at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
Jan Hubicka hubicka at gcc dot gnu.org changed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32629
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
We could also make $0 a not legitimate constant on x86... (and undo that late
with a peephole2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61605
vries at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Andi Kleen from comment #9)
Any progress on fixing the test case, so that this can be finally fixed?
I have no idea how to do that without making the testcase test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63383
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||i?86-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
--- Comment #4 from Jiong Wang jiwang at gcc dot gnu.org ---
sorry for causing the trouble.
the reason might be the flag is an implified register while it's not take
into account in current shrink-wrap reg read/write analysis.
I will revert my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63386
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
Please provide preprocessed source of the file crashing the compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395
--- Comment #12 from Richard Biener rguenth at gcc dot gnu.org ---
You can also try -fexcess-precision=standard on Cygwin, -mpc64 might not be
implemented there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63403
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63406
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
I think we have similar dups elsewhere (warning for last unrolled iteration
which is never executed).
My previous naiive attempts dropped warnings from VRP2 and only warn from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63406
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
I'd say it would still be worthwhile, if it was just a matter of XFAILing a few
testcases, because the number of false positives is more important, if the
warning is too unreliable,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
--- Comment #5 from Jiong Wang jiwang at gcc dot gnu.org ---
we need to check the following
else if (GET_CODE == CLOBBER
|| GET_CODE (x) == USE
|| GET_CODE (x) == ASM_INPUT)
I will post the fix after pass x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34117
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61605
--- Comment #5 from vries at gcc dot gnu.org ---
Created attachment 33610
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33610action=edit
proof-of-concept patch
Using this proof-of-concept patch, we manage to get the desired code. The patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63262
Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302
--- Comment #15 from dave.anglin at bell dot net ---
On 29-Sep-14, at 2:43 AM, zhenqiang.chen at arm dot com wrote:
Please try the attached patch. If it works, I will run all tests and
send it
for community review.
The patch appears to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62164
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot
20140929 (prerelease) [gcc-4_9-branch revision
215679] (Gentoo 4.9.2_alpha20140928)
C(XX)FLAGS -flto=4 -fuse-linker-plugin -O2 -g -pipe -march=core2 -mtune=core2
I am going to try version 5 from svn.
Should I post disassemble diff output or how to continue please? I not enabled
static libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #11 from boger at us dot ibm.com ---
On ppc64 BE, the call to make_code_func_reference returns the function pointer
in the .opd and not the actual address of the function. That is what causes
the failures with this patch
-lto --with-cloog
--disable-isl-version-check
Thread model: posix
gcc version 4.10.0-alpha20140928 20140929 (experimental) [trunk revision
215679] (Gentoo 4.10.0_alpha20140928)
fails the same way:
terminate called after throwing an instance of 'Cult::MM::Absent'
what(): N4Cult2MM6AbsentE
/bin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407
--- Comment #2 from David Kredba nheghathivhistha at gmail dot com ---
Created attachment 33611
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33611action=edit
xsd files with folder structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407
--- Comment #3 from David Kredba nheghathivhistha at gmail dot com ---
objdump -d produced 24 and 30 MiB files and diff -u is 50 MiB, diff 55 MiB.
Even 7z can compress it to uploadable size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056
--- Comment #3 from Piotr Dziwinski piotrdz at gmail dot com ---
(In reply to Jonathan Wakely from comment #2)
(In reply to Piotr Dziwinski from comment #1)
I would also second the proposal to fix this issue by implementing flat
version of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
--- Comment #23 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jason Merrill from comment #22)
It could be done specifically for uses in mem-initializers by walking the
initializer in perform_mem_init to look for any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
tr1::tuple doesn't support perfect-forwarding or move semantics
tr1::tuple doesn't support uses-allocator construction
tr1::tuple doesn't support 'final' classes
tr1::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenth at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408
Bug ID: 63408
Summary: GCC emits incorrect FMA instruction
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63342
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63340
rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63285
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Vlad, do you plan to apply this to 4.9 and 4.8 branches too?
For 4.9, I've bootstrapped/regtested it on {x86_64,i686,armv7hl,aarch64}-linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407
--- Comment #4 from David Kredba nheghathivhistha at gmail dot com ---
Created attachment 33613
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33613action=edit
all ii files compressed by 7zip
tar.bz2 file size was 8.2 MiB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407
--- Comment #5 from David Kredba nheghathivhistha at gmail dot com ---
Link command to produce a binary, Boost is 1.56:
x86_64-pc-linux-gnu-g++ -flto=4 -fuse-linker-plugin -O2 -g -save-temps
-march=core2 -mtune=core2 -Wl,-flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62061
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409
Bug ID: 63409
Summary: [5 Regression] FAIL: g++.dg/lto/pr63270
cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2
-Wno-odr -fno-linker-plugin
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63306
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63270
--- Comment #6 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to marxin from comment #5)
Author: marxin
Date: Mon Sep 22 09:39:20 2014
New Revision: 215451
URL: https://gcc.gnu.org/viewcvs?rev=215451root=gccview=rev
Log:
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #2 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
Which of macros are defined on mingw-w64?
Preprocessing this should tell you
#include chrono
#ifdef _GLIBCXX_USE_CLOCK_REALTIME
#ifdef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #22 from Jan Hubicka hubicka at ucw dot cz ---
Doing it at same approximately the same place as loop header copying seems
to
make most sense to me. It benefits from early cleanups and DCE definitly
and
it should enable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32629
--- Comment #6 from Jan Hubicka hubicka at ucw dot cz ---
We could also make $0 a not legitimate constant on x86... (and undo that late
with a peephole2)
I tried that in 90's. At that time it increased register pressure and was not
win...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423
--- Comment #33 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Mon Sep 29 16:47:31 2014
New Revision: 215685
URL: https://gcc.gnu.org/viewcvs?rev=215685root=gccview=rev
Log:
2014-09-29 Charles Baylis charles.bay...@linaro.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423
--- Comment #34 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Mon Sep 29 17:07:47 2014
New Revision: 215686
URL: https://gcc.gnu.org/viewcvs?rev=215686root=gccview=rev
Log:
2014-09-29 Charles Baylis charles.bay...@linaro.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
What libstdc++ is doing is sensible, why is the realtime clock so much coarser
than the monotonic clock on mingw-w64?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423
cbaylis at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63410
Bug ID: 63410
Summary: [Regression] pass_instances.def is not installed
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
Are you sure 1120403456 does not encode -100.0 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #41 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
Author: fxcoudert
Date: Mon Sep 29 18:40:57 2014
New Revision: 215690
URL: https://gcc.gnu.org/viewcvs?rev=215690root=gccview=rev
Log:
PR target/61407
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
Pat Haugen pthaugen at gcc dot gnu.org changed:
What|Removed |Added
CC||pthaugen at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
--- Comment #7 from Jiong Wang jiwang at gcc dot gnu.org ---
(In reply to Pat Haugen from comment #6)
(In reply to Jiong Wang from comment #5)
we need to check the following
r215563 also introduced a miscompare on PowerPC for cpu2000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
--- Comment #8 from Jiong Wang jiwang at gcc dot gnu.org ---
(In reply to Pat Haugen from comment #6)
(In reply to Jiong Wang from comment #5)
we need to check the following
else if (GET_CODE == CLOBBER
|| GET_CODE (x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38716
Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408
--- Comment #2 from Itay Perl itay at phobotic dot com ---
Yes, I am certain.
1. Replacing the minus sign with a plus sign results in the same code
(including the constant)
2.
struct.unpack('I', struct.pack('f', 100))[0]
1120403456
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #23 from davidxl xinliangli at gmail dot com ---
(In reply to Jan Hubicka from comment #22)
Doing it at same approximately the same place as loop header copying
seems to
make most sense to me. It benefits from early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144
--- Comment #2 from Brooks Moses brooks at gcc dot gnu.org ---
Ping? Any updates on this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #4 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #3)
What libstdc++ is doing is sensible, why is the realtime clock so much
coarser than the monotonic clock on mingw-w64?
It is not always true that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
--- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr ---
For the record the test gfortran.dg/typebound_operator_3.f03 also failed with
-O1 and -m64 (see https://gcc.gnu.org/ml/gcc-regression/2014-09/msg00226.html).
This is fixed by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #5 from frankhb1989 at gmail dot com ---
BTW, what if the clock_gettime call failed? The current implementation does
nothing about error handling... (Though for QPC on Windows it should rarely
fail for machines within a decade.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #12 from François Dumont fdumont at gcc dot gnu.org ---
Author: fdumont
Date: Mon Sep 29 21:22:17 2014
New Revision: 215693
URL: https://gcc.gnu.org/viewcvs?rev=215693root=gccview=rev
Log:
2014-09-29 François Dumont
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
François Dumont fdumont at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
, .-_test2
.ident GCC: (GNU) 4.9.2 20140929 (prerelease)
Disabling ivopt with '-fno-ivopts' produces correct code:
_test2:
tst r4,r4
bt .L12
mov #0,r2
mov.l .L14,r3
.align 2
.L4:
mov r2,r1
shll2 r1
add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63411
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
CC||amker.cheng at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53025
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #46 from Oleg Endo olegendo at gcc dot gnu.org ---
newlib 1.2.0 now builds without errors here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #47 from Oleg Endo olegendo at gcc dot gnu.org ---
Created attachment 33615
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33615action=edit
reduced CSiBE /libpng-1.2.5 test
I've tried compiling CSiBE (-m4 -ml). This is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61160
Sandra Loosemore sandra at codesourcery dot com changed:
What|Removed |Added
CC||sandra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #48 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #47)
Created attachment 33615 [details]
reduced CSiBE /libpng-1.2.5 test
I've tried compiling CSiBE (-m4 -ml). This is a stripped down
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63412
Bug ID: 63412
Summary: aliasing issue exposed by inlining
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63412
--- Comment #1 from Doug Gilmore doug.gilmore at imgtec dot com ---
Created attachment 33617
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33617action=edit
Modified version where type casts are modified.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63412
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #4 from thopre01 at gcc dot gnu.org ---
I detect no noticeable difference when bootstrapping gcc with or without the
patch so I think we're in for a fix. :-)
89 matches
Mail list logo
