http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46776
Summary: gogo-tree.cc uses TRAMPOLINE_ALIGNMENT and
TRAMPOLINE_SIZE
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768
--- Comment #4 from Jack Howarth 2010-12-03
04:25:53 UTC ---
On x86_64-apple-darwin10 at r167400, we are still failing...
FAIL: gcc.target/i386/sse2-init-v2di-2.c scan-assembler movq
at -m64.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46667
--- Comment #10 from Jie Zhang 2010-12-03 04:22:48
UTC ---
Chung-Lin Tang told me he had a patch for this:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00137.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46667
Jie Zhang changed:
What|Removed |Added
CC||jiez at gcc dot gnu.org
--- Comment #9 from J
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888
--- Comment #20 from Jorn Wolfgang Rennecke
2010-12-03 00:46:12 UTC ---
(In reply to comment #19)
> Please install the "file" utility. It should be able to identify if a file has
> CR or CRLF line terminators.
With od, we can see exactly, byte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46774
Andrew John Hughes changed:
What|Removed |Added
Blocks||46773
--- Comment #1 from Andrew Joh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46774
Summary: [gcj] Calling Policy.setPolicy with a new Policy
object has no effect on the DefaultSecurityManager
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
m...@gcc.gnu.org changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org
--- Comment #24
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888
--- Comment #19 from Cesar Strauss 2010-12-02
23:38:39 UTC ---
(In reply to comment #18)
> (In reply to comment #17)
> > * anhvofrcaus at gmail dot com wrote on Tue, Nov 30, 2010 at 01:25:49AM CET:
> > > It is interesting that this fix worked for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #3 from H.J. Lu 2010-12-02 23:01:14
UTC ---
(In reply to comment #2)
> Hmm, is it possible to do the change without breaking ABI (i.e. preserving the
> proper relative order for binary built with init_arra/fini_array linked with
> cto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46771
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46767
Uros Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768
Uros Bizjak changed:
What|Removed |Added
CC||howarth at nitro dot
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768
--- Comment #2 from hjl at gcc dot gnu.org 2010-12-02
22:50:49 UTC ---
Author: hjl
Date: Thu Dec 2 22:50:44 2010
New Revision: 167398
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167398
Log:
Turn on X86_TUNE_INTER_UNIT_MOVES for Core 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
--- Comment #12 from Eric Botcazou 2010-12-02
22:33:24 UTC ---
Author: ebotcazou
Date: Thu Dec 2 22:33:16 2010
New Revision: 167395
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167395
Log:
PR target/46685
* config/sparc/sparc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751
m...@gcc.gnu.org changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org
--- Comment #8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #2 from Jan Hubicka 2010-12-02
22:22:17 UTC ---
Hmm, is it possible to do the change without breaking ABI (i.e. preserving the
proper relative order for binary built with init_arra/fini_array linked with
ctors/dtors library and vice v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46772
Summary: libquadmath: Build failure - strtod: static
declaration of 'strtod' follows non-static
declaration
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46771
Summary: [4.6 Regression] -fcompare-debug failure (length) with
-O -ftree-vectorize
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45297
Sebastian Pop changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45297
--- Comment #13 from Sebastian Pop 2010-12-02
20:13:16 UTC ---
Author: spop
Date: Thu Dec 2 20:13:11 2010
New Revision: 167390
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167390
Log:
Fix PR45297: handle ADDR_EXPR in interpret_rhs_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46759
--- Comment #3 from rwgk at yahoo dot com 2010-12-02 19:47:29 UTC ---
Created attachment 22606
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22606
reproducer with additional tests
I changed the original reproducer to return 0 through 4 inste
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46752
Tobias Burnus changed:
What|Removed |Added
Status|RESOLVED|WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #1 from Mike Hommey 2010-12-02
19:24:44 UTC ---
Using .init_array/.fini_array instead of .ctors/.dtors removes the need for the
associated (relative) relocations, and avoids the backwards disk seeks on
startup (since while .ctors are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
Summary: Replace .ctors/.dtors with .init_array/.fini_array on
targets supporting them
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45948
--- Comment #5 from Sebastian Pop 2010-12-02 19:19:46
UTC ---
First patch here: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00216.html
However, I am not fully happy with this fix that tweaks scev const prop to work
around this bug...
The other
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768
--- Comment #1 from H.J. Lu 2010-12-02 19:11:26
UTC ---
On Intel64, I got
FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 2
FAIL: gcc.target/i386/pr37434-2.c scan-assembler pinsrw
FAIL: gcc.target/i386/pr37434-2.c scan-assembler pinsrw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46769
Summary: LTO failed to build gold
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46645
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46752
--- Comment #5 from Bill Long 2010-12-02 18:42:53 UTC
---
Reply from James:
Version 3.1 of the OpenMP specification removes the offending bullet: " A
variable that appears in a firstprivate clause must be definable." When the
new spec is releas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45948
--- Comment #4 from Sebastian Pop 2010-12-02 18:39:23
UTC ---
For this case, we end up generating two memset (0) for the first loop,
and we completely remove that loop:
void
foo (int i, int n)
{
int a[30];
int b[30];
for (; i < n; i++)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768
Summary: [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assigne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45062
Nathan Froyd changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45062
--- Comment #7 from Nathan Froyd 2010-12-02
18:00:26 UTC ---
Author: froydnj
Date: Thu Dec 2 18:00:21 2010
New Revision: 167381
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167381
Log:
PR c/45062
* c-decl.c (grokparms): Set arg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46752
--- Comment #4 from Tobias Burnus 2010-12-02
17:55:56 UTC ---
(In reply to comment #3)
> This usage is not specifically prohibited in the API.
Sound like a paraphrase for "implementation defined"/"processor dependent" to
me.
> James Beyer says
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46667
--- Comment #8 from Ramana Radhakrishnan 2010-12-02
17:54:22 UTC ---
Created attachment 22605
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22605
Testcase for ARM
Backtrace shown in previous comment from the following debugging arguments.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46667
--- Comment #7 from Ramana Radhakrishnan 2010-12-02
17:52:38 UTC ---
Here's the backtrace I see for arm-eabi.
#0 error (gmsgid=0xf323c8 "%+D causes a section type conflict") at
../../combined/gcc/diagnostic.c:747
#1 0x00affd0d in get_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46767
Summary: r167374 introduce gcc.target/i386 regressions
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46752
--- Comment #3 from Bill Long 2010-12-02 17:22:48 UTC
---
Conflicting commentary from the OpenMP testers and James Beyer of the OpenMP
committee:
This test case is derived from OpenMP test omp3f/F03_2_9_3_4_5c.f90 .
The case involves an allocata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
--- Comment #32 from H.J. Lu 2010-12-02 17:15:52
UTC ---
Another testcase:
[...@gnu-6 pr12245-6]$ cat y.c
#include
#include
#include
int
main (int argc, char **argv)
{
int d = atoi (argv[1]);
printf ("%f\n", sin (d));
return 0;
}
[...@
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46766
--- Comment #5 from Andreas Schwab 2010-12-02 17:10:15
UTC ---
If you want the standard to be changed then this is the wrong place.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
--- Comment #8 from rguenther at suse dot de
2010-12-02 17:01:08 UTC ---
On Thu, 2 Dec 2010, mkuvyrkov at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
>
> --- Comment #7 from Maxim Kuvyrkov 2010-12-02
> 16:42:40
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43651
Joseph S. Myers changed:
What|Removed |Added
CC||fredrik.hederstie...@securi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46765
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45199
Sebastian Pop changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45199
--- Comment #5 from Sebastian Pop 2010-12-02 16:53:21
UTC ---
Author: spop
Date: Thu Dec 2 16:53:16 2010
New Revision: 167380
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167380
Log:
Fix PR45199: do not aggregate memory accesses to the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
--- Comment #7 from Maxim Kuvyrkov 2010-12-02
16:42:40 UTC ---
(In reply to comment #6)
...
< , as an example look at the types the C frontend
> generates for struct X __attribute__((packed)) { int x; };
> void foo (struct X *p, int *q) { memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723
Richard Guenther changed:
What|Removed |Added
Priority|P3 |P2
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723
--- Comment #10 from Richard Guenther 2010-12-02
16:23:26 UTC ---
Author: rguenth
Date: Thu Dec 2 16:23:20 2010
New Revision: 167377
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167377
Log:
2010-12-02 Richard Guenther
PR tree-o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760
--- Comment #9 from Jan Hubicka 2010-12-02
15:57:00 UTC ---
Created attachment 22604
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22604
Patch I am testing to allow profile merging
This patch should allow merging of LTO units with differen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46766
--- Comment #4 from Fredrik Hederstierna
2010-12-02 15:55:05 UTC ---
Yes, I agree its EURGH.
I guess its not preferred to make C++ template-alike code in C.
I think its worth avoid stuff like:
#ifdef BLAH_BLAH_BLAH
#define RETURN_TYPE_C_TEMPLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #16 from Jan Hubicka 2010-12-02 15:34:48
UTC ---
> It's valid I think and we try to work out fPIC ourselves in the funny
> LTO option handling code (but the options are not re-applied at ltrans
> stage I think, so it doesn't work at a
> It's valid I think and we try to work out fPIC ourselves in the funny
> LTO option handling code (but the options are not re-applied at ltrans
> stage I think, so it doesn't work at all with WHOPR).
Hmm, the link command above is LTO, not WHOPR. I wonder why we don't work out
-fPIC
ourselves t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46542
Jeffrey A. Law changed:
What|Removed |Added
Attachment #22447|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46766
--- Comment #3 from Jonathan Wakely 2010-12-02
15:14:14 UTC ---
(In reply to comment #0)
>
> void f1(void)
> {
> return (void)0; //OK
This is valid in C++ but allowing it in C is a GCC extension.
> void f2(void)
> {
> return f1(); //OK
T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46766
--- Comment #2 from Fredrik Hederstierna
2010-12-02 14:42:35 UTC ---
Ok, but also f1() declares that it does not return any parameters, still it can
return (void)0;
I'm not saying either is wrong, I just though it should be consistent.
If its o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46753
--- Comment #2 from Jakub Jelinek 2010-12-02
14:37:25 UTC ---
Author: jakub
Date: Thu Dec 2 14:37:20 2010
New Revision: 167372
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167372
Log:
PR fortran/46753
* trans-openmp.c (gfc_tran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
--- Comment #27 from Jakub Jelinek 2010-12-02
14:31:31 UTC ---
Author: jakub
Date: Thu Dec 2 14:31:27 2010
New Revision: 167371
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167371
Log:
PR libgomp/43706
* env.c (initialize_env):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45240
--- Comment #1 from Jakub Jelinek 2010-12-02
14:30:41 UTC ---
Author: jakub
Date: Thu Dec 2 14:30:37 2010
New Revision: 167370
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167370
Log:
PR libgomp/45240
* parallel.c (GOMP_paralle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46766
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46766
Summary: Type 'void' is treated differently if used as return
value or as parameter
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46764
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46764
--- Comment #1 from Jonathan Wakely 2010-12-02
13:43:27 UTC ---
changing typeof to decltype or __typeof__ causes it to work
looks as though 'typeof' simply isn't recognised in C++0x mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46765
--- Comment #1 from Fredrik Hederstierna
2010-12-02 13:34:26 UTC ---
Created attachment 22602
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22602
example file for const.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46765
Summary: Superfluous 'const' declaration does not generate
error or warning
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
--- Comment #13 from paul.richard.thomas at gmail dot com 2010-12-02 13:33:38 UTC ---
Semms to me that Jerry should do the honours :-)
Paul
On Thu, Dec 2, 2010 at 1:45 PM, burnus at gcc dot gnu.org
wrote:
> http://gcc.gnu.org/bugzilla/show_bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46763
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
Kai Tietz changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
--- Comment #15 from Kai Tietz 2010-12-02 13:15:18
UTC ---
Author: ktietz
Date: Thu Dec 2 13:15:10 2010
New Revision: 167369
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167369
Log:
2010-12-02 Kai Tietz
PR libstdc++/43738
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46764
Summary: std=c++0x causes compilation failure on SFINAE test
for methods
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46268
Laurynas Biveinis changed:
What|Removed |Added
Status|ASSIGNED|SUSPENDED
--- Comment #2 from Lauryna
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
--- Comment #12 from Tobias Burnus 2010-12-02
12:44:57 UTC ---
I think we can close this PR - can't we?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871
Richard Guenther changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871
--- Comment #15 from Richard Guenther 2010-12-02
12:24:50 UTC ---
Author: rguenth
Date: Thu Dec 2 12:24:46 2010
New Revision: 167367
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167367
Log:
2010-12-02 Richard Guenther
PR lto/44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751
--- Comment #7 from Iain Sandoe 2010-12-02 11:49:41
UTC ---
proposed work-around for 4.6
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00145.html
Note the following web-page describes the intended usage/behavior of dsymutil
http://wiki.dwarfst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46663
--- Comment #1 from irar at gcc dot gnu.org 2010-12-02 11:47:15 UTC ---
Author: irar
Date: Thu Dec 2 11:47:12 2010
New Revision: 167366
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167366
Log:
PR tree-optimization/46663
* tree-v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
--- Comment #11 from Eric Botcazou 2010-12-02
11:30:54 UTC ---
> Alternatively, we could do something like:
> --- gcc/config/sparc/sparc.c.jj2010-11-26 18:39:04.0 +0100
> +++ gcc/config/sparc/sparc.c2010-11-29 15:35:00.727219374 +
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46763
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46720
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
Sever
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46720
Thomas Koenig changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Thomas Ko
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46753
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
--- Comment #23 from Iain Sandoe 2010-12-02 10:14:22
UTC ---
(In reply to comment #22)
> At install-time dsymutil is run and the relevant xxx.dSYM is installed along
> with the objects, where required.
s/objects/exes/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
--- Comment #22 from Iain Sandoe 2010-12-02 10:10:06
UTC ---
(In reply to comment #21)
> On Thu, 2 Dec 2010, iains at gcc dot gnu.org wrote:
>
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
> >
> > --- Comment #20 from Iain Sandoe 2010-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46763
Summary: gcc 4.5: missed optimization: copy global to local,
prefetch
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
--- Comment #2 from Andreas Krebbel 2010-12-02
09:51:17 UTC ---
Marked as 4.6 regression. The behavior of 4.5.2 isn't helpful either but it
doesn't return a wrong value as with 4.6.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
--- Comment #21 from rguenther at suse dot de
2010-12-02 09:50:48 UTC ---
On Thu, 2 Dec 2010, iains at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
>
> --- Comment #20 from Iain Sandoe 2010-12-02
> 09:09:49 UTC -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46752
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46758
Richard Guenther changed:
What|Removed |Added
Target Milestone|--- |4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35258
Andreas Krebbel changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #15 from Richard Guenther 2010-12-02
09:41:58 UTC ---
(In reply to comment #10)
> I am just trying to get Mozilla building with GNU ld instead of gold. First
> problem is that Mozilla links some of libraries as:
>
> /abuild/jh/trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46762
Summary: gcc crosscompiled for arm optimises away volatile
struct member access when -Os
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: major
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760
--- Comment #8 from Jan Hubicka 2010-12-02 09:22:38 UTC
---
Hi,
you can still test bootstrap with simply commenting out that sorry. It should
give, sort-of, sane results.
I will implement counter rescaling once I get some time for it - it is not
Hi,
you can still test bootstrap with simply commenting out that sorry. It should
give, sort-of, sane results.
I will implement counter rescaling once I get some time for it - it is not too
hard.
Also not too many setups actually train library built into multiple binaries,
so it is not that cri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
--- Comment #20 from Iain Sandoe 2010-12-02 09:09:49
UTC ---
(In reply to comment #19)
> On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote:
> > yeah - it's on my TODO (pr43751).
> > FWIW, some time ago, I did enquire about the difficulty of add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760
Dave Korn changed:
What|Removed |Added
Depends on||42690
AssignedTo|davek at gcc dot gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46679
Jay changed:
What|Removed |Added
Version|4.5.1 |4.6.0
--- Comment #1 from Jay 2010-12-02 09:08:49
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723
--- Comment #9 from rguenther at suse dot de
2010-12-02 09:03:35 UTC ---
On Thu, 2 Dec 2010, irar at il dot ibm.com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723
>
> Ira Rosen changed:
>
>What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760
--- Comment #6 from Jan Hubicka 2010-12-02 09:00:51 UTC
---
Hi,
at one point I tried profiledbootstrap and problem is that we can not merge
multiple LTO files
that has been profiled different amount of times. This happens during our
build becaus
1 - 100 of 108 matches
Mail list logo
