http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238
--- Comment #10 from Daniel Richard G. 2012-05-12
05:36:16 UTC ---
(In reply to comment #9)
> I won't be able to work on that until I'm back from holiday in two weeks, in
> the meanwhile --disable-libstdcxx-threads should allow you to bootstrap,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887
--- Comment #8 from Daniel Richard G. 2012-05-12
05:09:15 UTC ---
(In reply to comment #7)
> Looks as though it also needs
> template class function;
I added that, and with the two instantiations, bootstrap completes
successfully.
(I don't supp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009
--- Comment #3 from Daniel Richard G. 2012-05-12
04:33:41 UTC ---
Created attachment 27384
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27384
/usr/include/stdlib.h from AIX 4.3
Attaching the relevant header file, to aid in development of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009
Daniel Richard G. changed:
What|Removed |Added
Version|4.5.2 |4.7.0
--- Comment #2 from Daniel Rich
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53289
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53310
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53310
--- Comment #6 from Tobias Burnus 2012-05-11
23:09:35 UTC ---
Author: burnus
Date: Fri May 11 23:09:30 2012
New Revision: 187419
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187419
Log:
2012-05-12 Tobias Burnus
PR fortran/53
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52054
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #10 from phpbbaid at gmail dot com 2012-05-11 23:02:22 UTC ---
please unsubscribe
-Original Message-
From: andi-gcc at firstfloor dot org
Sent: Friday, May 11, 2012 11:35 PM
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/5331
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46820
--- Comment #13 from Jan Hubicka 2012-05-11
22:38:23 UTC ---
Updated description to match reality. Here it should really be user defined
alias with weak visibility.
void __f () { /* Do something. */; }
void f () __attribute__ ((weak, alias ("__f"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53310
--- Comment #5 from Tobias Burnus 2012-05-11
22:33:30 UTC ---
Author: burnus
Date: Fri May 11 22:33:21 2012
New Revision: 187418
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187418
Log:
2012-05-12 Tobias Burnus
PR fortran/53
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46820
Jan Hubicka changed:
What|Removed |Added
Summary|Undefined reference errors |toplevel ASM statements
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53310
--- Comment #4 from Tobias Burnus 2012-05-11
22:32:36 UTC ---
Author: burnus
Date: Fri May 11 22:32:27 2012
New Revision: 187417
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187417
Log:
2012-05-12 Tobias Burnus
PR fortran/53
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53312
--- Comment #2 from philippe.waroquiers at skynet dot be 2012-05-11 22:16:25
UTC ---
(In reply to comment #1)
> This looks like PR53214 - unable to verify without a testcase though. Thus,
> please try a recent GCC 4.7 snapshot instead. You can a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53328
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #9 from Andi Kleen 2012-05-11
21:35:47 UTC ---
Sorry I was wrong earlier. Retested now fully with a full test case and HJs
patch and i always get aborts
The xbegin gets miscompiled now, the in transaction branch disappears.
400460
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53328
Bug #: 53328
Summary: [OOP] Ambiguous check for type-bound GENERIC shall
ignore PASSed arguments
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53029
Manfred Schwarb changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53029
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51564
--- Comment #7 from Matt Hargett 2012-05-11 20:19:01 UTC
---
Applying the patch does allow DWARF serialization to get further, but now it
dies here:
internal compiler error: in add_AT_specification, at dwarf2out.c:7536
It looks like this problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263
--- Comment #11 from François Dumont 2012-05-11
19:21:38 UTC ---
Author: fdumont
Date: Fri May 11 19:21:31 2012
New Revision: 187414
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187414
Log:
2012-05-11 François Dumont
PR libstdc+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37122
--- Comment #6 from Daniel Richard G. 2012-05-11
19:16:50 UTC ---
Created attachment 27383
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27383
updated patch for 4.7.0
I got bitten by this recently. Bootstrapping GCC 4.7.0 on Solaris 8:
[.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537
--- Comment #7 from Thomas Koenig 2012-05-11
19:16:08 UTC ---
Does this fix the problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #129 from Jan Hubicka 2012-05-11
19:05:19 UTC ---
OK, the slow part of uniuqify_nodes is:
/* Remove us from our main variant list if we are not the
variant leader. */
if (TYPE_MAIN_VARIANT (t) != t)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537
--- Comment #6 from Thomas Koenig 2012-05-11
18:50:27 UTC ---
Author: tkoenig
Date: Fri May 11 18:50:14 2012
New Revision: 187413
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187413
Log:
2012-05-11 Thomas Koenig
PR fortran/52537
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11198
michael777 changed:
What|Removed |Added
CC||bestvideos2011 at live dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8564
michael777 changed:
What|Removed |Added
CC||bestvideos2011 at live dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887
--- Comment #7 from Jonathan Wakely 2012-05-11
18:34:59 UTC ---
Looks as though it also needs
template class function;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53327
--- Comment #2 from The Written Word
2012-05-11 18:31:55 UTC ---
Created attachment 27382
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27382
Assembler file from -save-temps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53327
--- Comment #1 from The Written Word
2012-05-11 18:30:02 UTC ---
Created attachment 27381
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27381
a.c from -save-temps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53327
Bug #: 53327
Summary: Invalid ASM being generated
Classification: Unclassified
Product: gcc
Version: 4.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321
--- Comment #4 from Jan Hubicka 2012-05-11
18:25:06 UTC ---
was comitted as revision 187382. I am trying profiledbootstrap now.
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #8 from Andi Kleen 2012-05-11
18:02:43 UTC ---
I tested HJs fix on the test case and also on a more complex program and it all
works as expected. Please commit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49797
--- Comment #5 from Matt Hargett 2012-05-11 17:58:27 UTC
---
It's not an IRIX-specific thing AFAICS, but rather that newer versions of
cloog/ppl renamed the macro to avoid conflicts on IRIX. 4.6 still checks for
the old macro name, which is no lo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53326
--- Comment #1 from Arnaud Desitter
2012-05-11 17:31:12 UTC ---
Consider:
>cat UIN15-int.f
!! check whether uninitialised variables are detected
!! for INTENT(OUT) arrays
program uin
integer x(10)
x = 2
call sub2(x,size(x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324
--- Comment #2 from Jonathan Wakely 2012-05-11
17:20:13 UTC ---
N.B. this is basically the same scenario as if you compiled x.C, then changed
XX::getme to return a std::list instead of std::deque, then compiled y.C -- it
would link, but crash at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53326
Bug #: 53326
Summary: -finit-integer, -finit-real and INTENT(OUT)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324
--- Comment #1 from Jonathan Wakely 2012-05-11
17:09:26 UTC ---
Even if it wasn't assignable your program would crash, C++ name mangling
doesn't include the return type so the symbol _ZN2XX5getmeEv defined in x.o
reolves the undefined reference i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887
--- Comment #6 from Daniel Richard G. 2012-05-11
17:05:57 UTC ---
With the new build, I now see one missing symbol instead of two. (Not sure why
the earlier hacked build went through):
gmake[3]: Entering directory `/tmp/gcc-4.7.0/_build/gcc'
/tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321
--- Comment #3 from H.J. Lu 2012-05-11 15:52:38
UTC ---
(In reply to comment #2)
> I fixed identically looking ICE seen on Mozilla build yesterday. Hopefully the
> boostrap is fixed now, too.
>
It still fails with the same error as of revision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316
--- Comment #9 from David Stone 2012-05-11
15:48:53 UTC ---
I suppose this is a much better way to phrase the suggestion as a starting
point. First get -Odebug and then see where we go from there.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321
--- Comment #2 from Jan Hubicka 2012-05-11
15:48:32 UTC ---
I fixed identically looking ICE seen on Mozilla build yesterday. Hopefully the
boostrap is fixed now, too.
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53300
--- Comment #17 from David Edelsohn 2012-05-11
15:44:44 UTC ---
A minimal testcase:
enum lc_reason
{
LC_ENTER = 0,
LC_LEAVE,
LC_RENAME,
LC_RENAME_VERBATIM,
LC_ENTER_MACRO
};
const char *
foo (enum lc_reason reason)
{
const char *lc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53300
--- Comment #16 from David Edelsohn 2012-05-11
15:11:59 UTC ---
The mis-compiled file is libcpp/line-map.c. I have attached the pre-processed
output for line-map.c on AIX. I also have attached assembly files showing the
correct and incorrect out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53300
--- Comment #14 from David Edelsohn 2012-05-11
15:08:29 UTC ---
Created attachment 27378
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27378
Correct assembly output for line-map.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53300
--- Comment #15 from David Edelsohn 2012-05-11
15:09:09 UTC ---
Created attachment 27379
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27379
Wrong assembly output for line-map.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53300
--- Comment #13 from David Edelsohn 2012-05-11
15:07:46 UTC ---
Created attachment 27377
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27377
Pre-processed source for libcpp/line-map.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325
--- Comment #3 from Joel Sherrill 2012-05-11 14:55:02
UTC ---
Created attachment 27376
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27376
GCC Patch for 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325
--- Comment #2 from Joel Sherrill 2012-05-11 14:54:35
UTC ---
Created attachment 27375
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27375
GCC Patch for 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325
--- Comment #1 from Joel Sherrill 2012-05-11 14:54:08
UTC ---
Created attachment 27374
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27374
GCC Patch for 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325
Bug #: 53325
Summary: arm-rtems switch default target to EABI
Classification: Unclassified
Product: gcc
Version: 4.6.4
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324
Bug #: 53324
Summary: Crash when mixing _GLIBCXX_DEBUG and
non-_GLIBCXX_DEBUG std::deque
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51055
--- Comment #4 from Tobias Burnus 2012-05-11
14:31:26 UTC ---
See http://gcc.gnu.org/ml/fortran/2012-05/msg00054.html
The problem is that the character length is used for reallocation before it is
set.
The following should work. The only quest
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53209
--- Comment #14 from Richard Guenther 2012-05-11
14:16:00 UTC ---
What about the branch?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537
--- Comment #5 from Thomas Koenig 2012-05-11
13:56:16 UTC ---
Author: tkoenig
Date: Fri May 11 13:56:06 2012
New Revision: 187406
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187406
Log:
2012-05-11 Thomas Koenig
PR fortran/52537
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53209
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53209
--- Comment #12 from Alexandre Oliva 2012-05-11
13:52:00 UTC ---
Fixed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53297
--- Comment #7 from Jonathan Wakely 2012-05-11
13:32:52 UTC ---
You haven't even provided the command that produces the error. Noone can
suggest a solution if you don't properly describe the problem.
Other people use GCC on Solaris without prob
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53209
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53209
--- Comment #11 from Alexandre Oliva 2012-05-11
13:27:15 UTC ---
Author: aoliva
Date: Fri May 11 13:27:03 2012
New Revision: 187404
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187404
Log:
PR c++/53209
* pt.c (tsubst_decl): Bail out if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53323
Bug #: 53323
Summary: Compiler bomb with indefinite array of controlled
objects and storage pools
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53311
chesstr at hotmail dot com changed:
What|Removed |Added
Attachment #27368|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53322
Manuel López-Ibáñez changed:
What|Removed |Added
CC||dodji at gcc dot gnu.org
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53322
Bug #: 53322
Summary: Wunused-local-typedefs is not enabled by Wall or
Wunused
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53063
--- Comment #1 from Manuel López-Ibáñez 2012-05-11
12:24:00 UTC ---
Author: manu
Date: Fri May 11 12:23:50 2012
New Revision: 187403
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187403
Log:
2012-05-11 Manuel López-Ibáñez
PR 5306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53295
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53295
--- Comment #2 from Richard Guenther 2012-05-11
12:03:19 UTC ---
Author: rguenth
Date: Fri May 11 12:03:10 2012
New Revision: 187402
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187402
Log:
2012-05-11 Richard Guenther
PR tre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321
H.J. Lu changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Target Milestone|-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321
Bug #: 53321
Summary: [4.8 Regression] LTO bootstrap failed with
bootstrap-profiled
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53297
--- Comment #6 from Paolo Carlini 2012-05-11
11:14:25 UTC ---
Incidentally, also note that the 4.4.x series is not maintained anymore, thus
it doesn't make much sense to file reports against it and older release series.
But this is just a digress
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53297
Paolo Carlini changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53275
--- Comment #7 from Paolo Carlini 2012-05-11
11:05:51 UTC ---
*** Bug 53297 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53297
birender.singh at hotmail dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53300
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-05-11 10:08:11 UTC ---
> --- Comment #5 from Jan Hubicka 2012-05-10
> 17:59:46 UTC ---
[...]
> Does the following hack avoid the problem? Perhaps during the years when
> varpool
> was
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53161
--- Comment #7 from Igor Zamyatin 2012-05-11
10:07:07 UTC ---
Error message for x86 compilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53161
Igor Zamyatin changed:
What|Removed |Added
CC||izamyatin at gmail dot com
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
Uros Bizjak changed:
What|Removed |Added
Keywords||patch
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53291
Uros Bizjak changed:
What|Removed |Added
Status|WAITING |RESOLVED
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #6 from Uros Bizjak 2012-05-11 09:41:15
UTC ---
(In reply to comment #5)
> Created attachment 27370 [details]
> A patch
Patch looks OK to me, but please let Andi play with this a bit, so we are sure
we won't hit some other reload lim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52054
--- Comment #3 from Richard Guenther 2012-05-11
09:34:40 UTC ---
PR53125 has a testcase where we spend time in redundant store removal in
eliminate() which does vn_reference_lookup with VN_WALK (which it should not
need).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125
--- Comment #8 from Richard Guenther 2012-05-11
09:33:19 UTC ---
The alias stmt walking time is because of the redundant store removal code
and because of PR52054 it has to re-do the walks (there are 7200 stores in
the function).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53320
Bug #: 53320
Summary: -fcheck=pointer should diagnose pointer-assignment of
a noncontiguous tgt to a CONTIGUOUS ptr
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125
Steven Bosscher changed:
What|Removed |Added
Keywords||alias
Summary|Very slow regi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #128 from Jan Hubicka 2012-05-11 08:52:50
UTC ---
> Well - the obvious possibly "slow" part of uniquify nodes is that it walks
> all fields of record/union types. So - do you have a more detailed profile
> of uniquify_nodes?
No, I w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316
--- Comment #8 from Richard Guenther 2012-05-11
08:58:23 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > A big question for -Odebug is e.g. if we should enable var-tracking for it
> > or
> > not. While it is time consuming, it s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316
--- Comment #7 from Richard Guenther 2012-05-11
08:56:41 UTC ---
(In reply to comment #6)
> A big question for -Odebug is e.g. if we should enable var-tracking for it or
> not. While it is time consuming, it should improve the debug experience,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #127 from Mike Hommey 2012-05-11
08:52:24 UTC ---
(In reply to comment #126)
> (In reply to comment #124)
> > > Just for comparison, clang with -O4 runs only single threaded and does
> > > everything in memory (no streaming out). It u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316
--- Comment #6 from Jakub Jelinek 2012-05-11
08:52:51 UTC ---
A big question for -Odebug is e.g. if we should enable var-tracking for it or
not. While it is time consuming, it should improve the debug experience, there
are various cases where -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53312
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #126 from Markus Trippelsdorf
2012-05-11 08:46:39 UTC ---
(In reply to comment #124)
> > Just for comparison, clang with -O4 runs only single threaded and does
> > everything in memory (no streaming out). It uses 3.5GB of memory (peak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #125 from Richard Guenther 2012-05-11
08:44:51 UTC ---
(In reply to comment #122)
> oprofile shows:
> 139188 15.6963 lto1 lto1
> uniquify_nodes
> 66390 7.4868 lto1 lt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53300
--- Comment #11 from Jan Hubicka 2012-05-11
08:40:25 UTC ---
Author: hubicka
Date: Fri May 11 08:40:15 2012
New Revision: 187397
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187397
Log:
PR bootstrap/53300
* varpool.c (varpool_a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53317
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #124 from Jan Hubicka 2012-05-11 08:34:17
UTC ---
> Just for comparison, clang with -O4 runs only single threaded and does
> everything in memory (no streaming out). It uses 3.5GB of memory (peak) and
> takes 19 minutes to finish...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53318
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Richard Guenther changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53319
Richard Guenther changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53305
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53305
--- Comment #3 from paolo at gcc dot gnu.org
2012-05-11 08:22:39 UTC ---
Author: paolo
Date: Fri May 11 08:22:16 2012
New Revision: 187396
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187396
Log:
/cp
2012-05-11 Paolo Carlini
PR
1 - 100 of 101 matches
Mail list logo
