http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46875
--- Comment #5 from Andrey Belevantsev 2011-04-07
07:00:15 UTC ---
Author: abel
Date: Thu Apr 7 07:00:10 2011
New Revision: 172085
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172085
Log:
Backport from mainline
2010-12-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46649
--- Comment #10 from Andrey Belevantsev 2011-04-07
07:01:30 UTC ---
Author: abel
Date: Thu Apr 7 07:01:25 2011
New Revision: 172086
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172086
Log:
Backport from mainline
2010-12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47036
--- Comment #4 from Andrey Belevantsev 2011-04-07
07:02:40 UTC ---
Author: abel
Date: Thu Apr 7 07:02:34 2011
New Revision: 172087
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172087
Log:
Backport from mainline
2010-12-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46521
--- Comment #5 from Andrey Belevantsev 2011-04-07
07:04:10 UTC ---
Author: abel
Date: Thu Apr 7 07:04:02 2011
New Revision: 172088
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172088
Log:
Backport from mainline
2011-01-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46522
--- Comment #6 from Andrey Belevantsev 2011-04-07
07:04:10 UTC ---
Author: abel
Date: Thu Apr 7 07:04:02 2011
New Revision: 172088
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172088
Log:
Backport from mainline
2011-01-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45352
--- Comment #29 from Andrey Belevantsev 2011-04-07
07:04:09 UTC ---
Author: abel
Date: Thu Apr 7 07:04:02 2011
New Revision: 172088
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172088
Log:
Backport from mainline
2011-01
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48144
--- Comment #6 from Andrey Belevantsev 2011-04-07
07:05:19 UTC ---
Author: abel
Date: Thu Apr 7 07:05:16 2011
New Revision: 172089
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172089
Log:
Backport from mainline
2011-03-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603
Andrey Belevantsev changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48215
Andrey Belevantsev changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48442
Andrey Belevantsev changed:
What|Removed |Added
CC||abel at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48273
Andrey Belevantsev changed:
What|Removed |Added
CC||abel at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
Jakub Jelinek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48374
Andrey Belevantsev changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
--- Comment #18 from Michael Haubenwallner 2011-04-07 07:59:00 UTC ---
(In reply to comment #15)
> ld: 0711-596 SEVERE ERROR: Object expand.o
> An RLD for section 2 (.data) refers to symbol 852,
> but the storage class of the symbo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
Ira Rosen changed:
What|Removed |Added
CC||irar at il dot ibm.com
--- Comment #13 from I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48273
--- Comment #7 from Andrey Belevantsev 2011-04-07
08:00:28 UTC ---
And some of our sel-sched-ir.h helpers can be moved to cfgloop.c as well (e.g.
get_loop_exit_edges_unique_dests).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43920
--- Comment #10 from vries at gcc dot gnu.org 2011-04-07 08:10:38 UTC ---
Author: vries
Date: Thu Apr 7 08:10:34 2011
New Revision: 172090
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172090
Log:
2011-04-07 Tom de Vries
PR target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #14 from Jakub Jelinek 2011-04-07
08:20:30 UTC ---
Sure, but for types with user alignment smaller than their size, loop peeling
may often never be able to align it.
This regressed with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48488
Summary: Wrong default format for real numbers
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48446
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43920
--- Comment #11 from vries at gcc dot gnu.org 2011-04-07 08:35:27 UTC ---
Author: vries
Date: Thu Apr 7 08:35:23 2011
New Revision: 172091
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172091
Log:
2011-04-07 Tom de Vries
PR target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48446
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #5 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48272
Andrey Belevantsev changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48446
--- Comment #6 from Jakub Jelinek 2011-04-07
08:55:37 UTC ---
Actually now verified that it is r128979.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #15 from Ira Rosen 2011-04-07 09:00:43 UTC
---
(In reply to comment #14)
> Sure, but for types with user alignment smaller than their size, loop peeling
> may often never be able to align it.
>
> This regressed with http://gcc.gnu.or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48488
--- Comment #1 from Dominique d'Humieres 2011-04-07
09:08:01 UTC ---
> In write.c the intended default format for real numbers is documented as:
>
> /* Output a real number with default format.
>This is 1PG14.7E2 for REAL(4), 1PG23.15E3 for R
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48484
Richard Guenther changed:
What|Removed |Added
CC||xinliangli at gmail dot com
Target M
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48485
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43920
--- Comment #12 from vries at gcc dot gnu.org 2011-04-07 09:28:15 UTC ---
Author: vries
Date: Thu Apr 7 09:28:11 2011
New Revision: 172093
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172093
Log:
2011-04-07 Tom de Vries
PR target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #16 from Jakub Jelinek 2011-04-07
09:34:36 UTC ---
So perhaps:
bool
default_builtin_vector_alignment_reachable (const_tree type, bool is_packed)
{
- if (is_packed)
+ if (is_packed || (TYPE_USER_ALIGN (type) && compare_tree_int (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
Richard Guenther changed:
What|Removed |Added
Keywords||wrong-code
Status|REOPENED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #18 from Richard Guenther 2011-04-07
09:39:13 UTC ---
(In reply to comment #16)
> So perhaps:
>
> bool
> default_builtin_vector_alignment_reachable (const_tree type, bool is_packed)
> {
> - if (is_packed)
> + if (is_packed || (T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #9 from Jonathan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43920
--- Comment #13 from vries at gcc dot gnu.org 2011-04-07 09:48:42 UTC ---
Author: vries
Date: Thu Apr 7 09:48:39 2011
New Revision: 172094
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172094
Log:
2011-04-07 Tom de Vries
PR target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #19 from Ira Rosen 2011-04-07 09:55:44 UTC
---
(In reply to comment #18)
> I think rather tree-vect-data-refs.c:vector_alignment_reachable_p should
> be adjusted. These "packed" checks in the target hooks don't make any
> sense to me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48485
--- Comment #2 from konst 2011-04-07 10:04:07 UTC ---
Created attachment 23907
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23907
main.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48485
--- Comment #3 from konst 2011-04-07 10:08:59 UTC ---
gcc -fmudflap main.c -lmudflap -o main && ./main
and nothing, but if I do 'a[-2]=c;' in main.c and compile it then the mistake
is discovered by following output:
***
mudflap violation 1 (c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #20 from rguenther at suse dot de
2011-04-07 10:24:45 UTC ---
On Thu, 7 Apr 2011, irar at il dot ibm.com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
>
> --- Comment #19 from Ira Rosen 2011-04-07 09:55:44
> UTC ---
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48485
--- Comment #4 from Richard Guenther 2011-04-07
10:50:10 UTC ---
It works for me.
/tmp> /space/rguenther/install/gcc-4.5.2/bin/gcc -fmudflap t.c -lmudflap -o t
/tmp> ./t
***
mudflap violation 1 (check/write): time=1302173318.008878 ptr=0x7ff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48485
--- Comment #5 from konst 2011-04-07 11:01:30 UTC ---
> Note that openSUSE has libmudflap disabled, so I wonder how it even compiles
> and links for you ;)
Yes, I downloaded src.rpm, compiled it (gcc and mudflap) and "make install"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48488
--- Comment #2 from Thomas Henlich
2011-04-07 11:22:49 UTC ---
Ok, now I found that this was changed in
http://gcc.gnu.org/viewcvs?view=revision&revision=128967
The testcase says:
> ! This tests that the default formats for formatted I/O of rea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #21 from Ira Rosen 2011-04-07 11:37:29 UTC
---
(In reply to comment #20)
> I saw them, but I can't see what the difference is between
> "aligned" and "aligned" ;) Either the targets have aligned loads
> or they don't. We can target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612
--- Comment #11 from Joel Sherrill 2011-04-07
11:44:54 UTC ---
In both cases, I built gcc + newlib multilib + rtems multilib to ensure the
entire software base was built with and without the patch.
$ m68k-rtems4.11-gcc --version
m68k-rtems4.11-g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #22 from Jakub Jelinek 2011-04-07
11:45:57 UTC ---
When would
compare_tree_int (TYPE_SIZE (type), TYPE_ALIGN (type)) <= 0
give not what you are looking for?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48489
Summary: Invalid error message 'has no member named' when
referring directly to the base class
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: minor
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #23 from Ira Rosen 2011-04-07 12:02:46 UTC
---
Well, it's hard to accept such an easy solution when the original patch has
hundreds of rows ;)
So, you think that
Index: tree-vect-data-refs.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612
Bernd Schmidt changed:
What|Removed |Added
Attachment #23890|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48144
--- Comment #7 from Andrey Belevantsev 2011-04-07
12:07:29 UTC ---
Author: abel
Date: Thu Apr 7 12:07:24 2011
New Revision: 172097
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172097
Log:
Backport from mainline
2011-03-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48144
Andrey Belevantsev changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48481
--- Comment #3 from Jakub Jelinek 2011-04-07
12:16:23 UTC ---
Haven't bootstrapped/regtested it, but it is definitely improvement.
With N=1000 and N=2000 the generated assembly is identical, for N=1000
reported TOTAL went down from 432768 kB to 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48490
Summary: "delete" with template convertion operator does
overload resolution for class operands, but shouldn't.
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: nor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48491
Summary: ICE in "delete" with template convertion operator
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #24 from Richard Guenther 2011-04-07
12:42:48 UTC ---
(In reply to comment #23)
> Well, it's hard to accept such an easy solution when the original patch has
> hundreds of rows ;)
>
> So, you think that
>
> Index: tree-vect-data-re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #25 from Richard Guenther 2011-04-07
12:44:35 UTC ---
(In reply to comment #24)
> (In reply to comment #23)
> > Well, it's hard to accept such an easy solution when the original patch has
> > hundreds of rows ;)
> >
> > So, you think
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #26 from Jakub Jelinek 2011-04-07
12:48:12 UTC ---
int a = __alignof__ (double);
struct A { int b; double c; int d; } e;
int f = __alignof__ (e.c);
double *p;
int g = __alignof__ (*p);
int a2 = __alignof__ (long long);
struct A2 { int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
--- Comment #19 from Perry Smith 2011-04-07 12:55:19
UTC ---
Yes. Thats the one.
Dave,
First, I believe this link is a public facing interface to "Fix Central"
http://www.ibm.com/support/fixcentral/
(it came from google). If not, post back,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #27 from Richard Guenther 2011-04-07
12:56:34 UTC ---
(In reply to comment #26)
> int a = __alignof__ (double);
> struct A { int b; double c; int d; } e;
> int f = __alignof__ (e.c);
> double *p;
> int g = __alignof__ (*p);
> int a2 =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48492
Summary: [4.7 Regression] LTO bootstrap failure in
copy_constant
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48489
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493
Summary: [ICE] in expand_expr_addr_expr_1, at expr.c
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48492
Richard Guenther changed:
What|Removed |Added
CC||ebotcazou at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #28 from Jakub Jelinek 2011-04-07
13:16:13 UTC ---
I mean a and g are 8 with -m64 -malign-power, but f is 4. If you do:
extern void abort (void);
struct S { long long x; int a; double b[1]; int c; } s;
double *p = &s.b[0];
int
ma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483
--- Comment #10 from Lisp2D 2011-04-07 13:19:16 UTC
---
(In reply to comment #9)
> No, the variable is in scope after its identifier, so it can be used in the
> initializer expression, e.g.
>
> int i = sizeof(i); // ok
> int i = i+1; // not o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #29 from rguenther at suse dot de
2011-04-07 13:21:20 UTC ---
On Thu, 7 Apr 2011, jakub at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
>
> --- Comment #28 from Jakub Jelinek 2011-04-07
> 13:16:13 UTC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483
--- Comment #11 from Jonathan Wakely 2011-04-07
13:26:16 UTC ---
(In reply to comment #10)
> The answer of question gives the C++ standard. Show me this document.
3.3.1 Point of declaration [basic.scope.decl]
1 The point of declaration for a na
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #30 from Jakub Jelinek 2011-04-07
13:29:15 UTC ---
This is certainly a valid testcase:
struct S { long long x; int a; double b[1]; int c; } s;
double *p = &s.b[0];
int
foo (double *q)
{
int i, j = 0;
for (i = 0; i < 1; i+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483
--- Comment #12 from Jonathan Wakely 2011-04-07
13:29:43 UTC ---
For the example in comment 2 G++, EDG and Clang++ all accept it without
warning.
MSVC rejects it, but is wrong to do so.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48335
Yufeng Zhang changed:
What|Removed |Added
CC||yufeng at gcc dot gnu.org
--- Comment #10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #31 from Richard Guenther 2011-04-07
13:35:04 UTC ---
(In reply to comment #30)
> This is certainly a valid testcase:
>
> struct S { long long x; int a; double b[1]; int c; } s;
> double *p = &s.b[0];
> int
> foo (double *q)
> {
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483
--- Comment #13 from Jonathan Wakely 2011-04-07
13:38:11 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
>
> > No, the variable is in scope after its identifier, so it can be used in the
> > initializer expression, e.g.
> >
> > int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483
--- Comment #14 from Jonathan Wakely 2011-04-07
13:39:45 UTC ---
(In reply to comment #13)
> (In reply to comment #10)
> > (In reply to comment #9)
> >
> > > No, the variable is in scope after its identifier, so it can be used in
> > > the
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #32 from Jakub Jelinek 2011-04-07
13:43:47 UTC ---
Given that without vectorization that code surely works well on all the weird
ABIs, such ADJUST_FIELD_ALIGN is used only on targets that either aren't strict
alignment targets, or are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #33 from rguenther at suse dot de
2011-04-07 13:57:09 UTC ---
On Thu, 7 Apr 2011, jakub at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
>
> --- Comment #32 from Jakub Jelinek 2011-04-07
> 13:43:47 UTC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483
--- Comment #15 from Lisp2D 2011-04-07 13:58:38 UTC
---
(In reply to comment #12)
> For the example in comment 2 G++, EDG and Clang++ all accept it without
> warning.
> MSVC rejects it, but is wrong to do so.
The answer is good. Let's talk about
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48494
Summary: FAIL: boehm-gc.c/gctest.c -O2 (test for excess errors)
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: boehm-gc
Assi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48435
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48495
Summary: ICE in in reload_cse_simplify_operands
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389
--- Comment #6 from Jeffrey A. Law 2011-04-07 15:04:49
UTC ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/06/11 17:00, steven at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389
>
> --- Comment #5 from Steven
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #56 from Dave Korn 2011-04-07 15:15:14
UTC ---
What works for me on Cygwin, and so may well also work for anyone using MSYS,
is setting the heap_chunk_in_mb registry parameter to some value in the range
1024 - 1536. I use 1024 myself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
Summary: [4.7 Regression] 'asm' operand requires impossible
reload in libffi/src/ia64/ffi.c
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612
--- Comment #13 from Joel Sherrill 2011-04-07
15:28:39 UTC ---
Not a problem to redo.. just CPU time and if you don't use it, you lose it. :-D
I am repeating some information so it is all in one post.
In both cases, I built gcc + newlib multilib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612
--- Comment #14 from Bernd Schmidt 2011-04-07
15:35:34 UTC ---
>From the test results you posted, it appears to have been
+WARNING: program timed out.
+FAIL: gcc.dg/torture/fp-int-convert-double.c -O2 -flto execution test
Probably unrelated.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #7 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
Richard Guenther changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612
--- Comment #15 from Joel Sherrill 2011-04-07
15:44:16 UTC ---
(In reply to comment #14)
> From the test results you posted, it appears to have been
>
> +WARNING: program timed out.
> +FAIL: gcc.dg/torture/fp-int-convert-double.c -O2 -flto exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447
--- Comment #5 from Dave Korn 2011-04-07 15:49:29
UTC ---
Well, this is basically a weakness in the pass-through solution implemented for
PR 42690; it only knows about the compilers stdlibs, and doesn't process any
user-specified libs on the comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447
--- Comment #6 from Dave Korn 2011-04-07 15:51:30
UTC ---
Created attachment 23913
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23913
WIP patch
Work in progress: see comment at start of do_rescan_work() re DT_NEEDED libs,
but should be wo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #57 from Dongsheng Song
2011-04-07 15:53:38 UTC ---
(In reply to comment #56)
> What works for me on Cygwin, and so may well also work for anyone using MSYS,
> is setting the heap_chunk_in_mb registry parameter to some value in the ra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48455
--- Comment #4 from Richard Earnshaw 2011-04-07
16:00:04 UTC ---
Created attachment 23914
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23914
first testcase
Compile with -Os -mcpu=arm7tdmi -marm -fno-short-enums -fno-builtin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #34 from Jakub Jelinek 2011-04-07
16:36:04 UTC ---
While for 4.7 we can certainly do bigger changes, for 4.6 I think a safe fix
would be:
--- gcc/tree-vect-data-refs.c2011-03-31 08:51:03.0 +0200
+++ gcc/tree-vect-data-ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
--- Comment #20 from Dr. David Kirkby
2011-04-07 17:15:07 UTC ---
(In reply to comment #18)
> > IBM is aware of the issue (via me and others). The last tidbit I have is
> > that
> > it appears as if it is another assembler bug but that is not c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48497
Summary: gfortran.dg/graphite/vect-pr40979.f90 FAILs without
-march=pentium4
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48498
Summary: Several gcc.dg/vect tests XPASS on SPARC
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48498
--- Comment #1 from Rainer Orth 2011-04-07 17:38:05 UTC
---
Created attachment 23916
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23916
no-vfa-pr29145.c -fdump-tree-vect-details output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48499
Summary: [4.7 regression] ICE compiling 64-bit
gcc.dg/vect/{slp-21.c, no-vfa-pr29145.c} on SPARC
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48500
Summary: Regression: Failing to convert template argument to
concrete type, in C++0x mode.
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48499
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48501
Summary: 64bit-out.go, select5-out.go, tmp.go compilation times
out
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48343
--- Comment #9 from Jakub Jelinek 2011-04-07
17:57:29 UTC ---
Author: jakub
Date: Thu Apr 7 17:57:26 2011
New Revision: 172108
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172108
Log:
PR debug/48343
* combine.c (combine_instruc
1 - 100 of 180 matches
Mail list logo
