http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039
--- Comment #7 from Daniel Krügler
2012-04-20 06:48:39 UTC ---
I'm pretty sure that this is not related with , but instead with
some interaction between the header and std::is_convertible. The
following variant still demonstrates the problem (I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53051
Bug #: 53051
Summary: I/O: Support reading floating-point numbers which use
"Q" for the exponent
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51314
--- Comment #2 from Marc Glisse 2012-04-19
21:19:23 UTC ---
Created attachment 27200
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27200
patch
s.cc: In function 'void f(U ...)':
s.cc:3:18: error: 'sizeof...' argument must be surrounded by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #16 from H.J. Lu 2012-04-19 21:06:49
UTC ---
Created attachment 27199
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27199
A smaller patch
There is no point to support
struct foo
{
int i1;
long long i2 __attribute__((align
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #15 from H.J. Lu 2012-04-19 20:41:47
UTC ---
(In reply to comment #14)
> Are the last two warnings in bits (as opposed to bytes)? It looks a little
> confusing...
It is fixed by the updated patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #14 from H. Peter Anvin 2012-04-19 20:24:25
UTC ---
Are the last two warnings in bits (as opposed to bytes)? It looks a little
confusing...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
H.J. Lu changed:
What|Removed |Added
Attachment #27197|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #12 from H.J. Lu 2012-04-19 20:15:55
UTC ---
Created attachment 27197
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27197
A patch
I got
[hjl@gnu-6 pr53037]$ cat x.i
typedef unsigned long long __u64
__attribute__((aligned(4),wa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53050
--- Comment #1 from dcb 2012-04-19 20:02:12 UTC ---
Created attachment 27196
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27196
gzipped C++ source code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53050
Bug #: 53050
Summary: ssa_forward_propagate_and_combine: segmentation fault
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53049
--- Comment #4 from Georg-Johann Lay 2012-04-19
19:31:12 UTC ---
In tree-ssa-ter.c:is_replaceable_p() there is:
/* Leave any stmt with volatile operands alone as well. */
if (gimple_has_volatile_ops (stmt))
return false;
and in tree-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53049
--- Comment #3 from Andrew Pinski 2012-04-19
19:18:37 UTC ---
I think there is an already closed bug about this issue and we decided last
time, it is not something which we want to implement an unspec volatile or an
volatile inline-asm as a full
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45088
--- Comment #11 from Jason Merrill 2012-04-19
19:09:14 UTC ---
(In reply to comment #10)
> what about 4.7 branch?
The fix was on the trunk before 4.7 branched, so yes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53042
--- Comment #4 from David Edelsohn 2012-04-19 18:57:38
UTC ---
Both Richi and Honza's patches independently progress past the failure point.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53049
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53049
--- Comment #2 from Georg-Johann Lay 2012-04-19
18:34:38 UTC ---
Created attachment 27195
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27195
.150r.expand dump
Notice the
Replacing Expressions
val_2 replace with --> val_2 = 65535 / val_1(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53049
--- Comment #1 from Georg-Johann Lay 2012-04-19
18:32:37 UTC ---
Created attachment 27194
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27194
C source code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53049
Bug #: 53049
Summary: expand/TER unappropriate moving unspec volatile
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #11 from H. Peter Anvin 2012-04-19 17:42:28
UTC ---
Sorry, that should be sufficient. I'm not awake today, it seems.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52880
--- Comment #2 from Jakub Jelinek 2012-04-19
17:42:01 UTC ---
Created attachment 27193
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27193
gcc48-pr52880.patch
This patch works for me on this testcase, not sure if it is the right fix
though
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53048
Bug #: 53048
Summary: [4.8 Regression] 256.bzip2 in SPEC CPU 2000 failed to
build
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53047
Bug #: 53047
Summary: [4.8 Regression] 482.sphinx3 in SPEC CPU 2006
miscompiled
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046
Bug #: 53046
Summary: [4.8 Regression] New libstdc++ test failures
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #10 from H.J. Lu 2012-04-19 17:20:42
UTC ---
Isn't checking alignment of x in:
typedef unsigned long long __u64
__attribute__((aligned(4),warn_if_not_aligned(8)));
struct foo
{
int i1;
int i2;
int i3;
__u64 x;
};
sufficien
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52878
H.J. Lu changed:
What|Removed |Added
Attachment #27184|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #9 from H. Peter Anvin 2012-04-19 17:11:00
UTC ---
Yes.
The point is: WE WANT TO MIGRATE THE SYSTEM CALL INTERFACE TO AN ALIGNED
__[us]64 INTERFACE, mostly so that new interfaces are properly aligned from the
start.
In order to do t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #8 from H.J. Lu 2012-04-19 17:07:20
UTC ---
Shouldn't
typedef unsigned long long __u64 __attribute__((aligned(4)));
only be used in system call interface?
, -8.394, -93.3, 7.9, 84.94 };
int i;
for (i = 0; i < 8; i++)
foo0.d[i] = bar[i].d;
return 0;
}
-- cut here--
segfaults when compiled with -O2,
xgcc (GCC) 4.8.0 20120419 (experimental) [trunk revision 186596]
Loop termination is missing from asm dump:
.L2:
movsd %xmm0, foo0(%
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #7 from H. Peter Anvin 2012-04-19 16:57:14
UTC ---
The __u64/__s64 types are used for interfaces only. The kernel itself is
x86-64 and uses aligned types for internal uses.
The mismatch between i386 and x86-64 alignment has a tenden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #6 from H.J. Lu 2012-04-19 16:53:18
UTC ---
For a global or local 64bit variable, x, inside kernel,
why should it be 4 byte aligned if it isn't part of system
call interface?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #5 from H. Peter Anvin 2012-04-19 16:05:29
UTC ---
On 04/19/2012 09:00 AM, hjl.tools at gmail dot com wrote:
>
>> request is that we flag the currently misaligned __[su]64's as
>> __compat_[su]64
>> and make __[su]64 aligned, so at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53042
--- Comment #3 from Jan Hubicka 2012-04-19 16:03:09 UTC
---
Thanks for working on this. The patch is pre-approved if it passes testing.
The new symtab verifier is just old cgraph verifier and only change is that
we now do same testing for varia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #4 from H.J. Lu 2012-04-19 16:00:41
UTC ---
(In reply to comment #3)
> Logically, about half of u64's will be properly aligned at the moment...
> Linus'
No necessarily. For
u64 x;
int y;
u64 z;
both x and z may be 4 byte aligned.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039
Paolo Carlini changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #6 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #3 from H. Peter Anvin 2012-04-19 15:51:35
UTC ---
Logically, about half of u64's will be properly aligned at the moment... Linus'
request is that we flag the currently misaligned __[su]64's as __compat_[su]64
and make __[su]64 aligne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #2 from H.J. Lu 2012-04-19 15:47:14
UTC ---
Given
typedef unsigned long long __u64 __attribute__((aligned(4)));
all most all __u64 will be aligned at 4. The only case we may
do something about is
typedef unsigned long long __u64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53040
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927
--- Comment #9 from Jonatan GOebel
2012-04-19 15:14:27 UTC ---
Hi.
The problem actually happen when using -Os and -frename-registers.
Also the source code may note help, because it randomly happens on different
parts of the code depending on co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53038
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53038
--- Comment #2 from Alan Modra 2012-04-19 15:27:47
UTC ---
testing a fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53040
--- Comment #1 from Alan Modra 2012-04-19 15:24:30
UTC ---
Created attachment 27191
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27191
obvious fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44214
William J. Schmidt changed:
What|Removed |Added
CC||bergner at vnet dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53043
Steven Bosscher changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #95 from Jan Hubicka 2012-04-19 15:07:27
UTC ---
> It is misleading to think that the linker accumulates code in translation unit
> order for a C++ program. E.g., that is not what happens for template code or
> string constants. And
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53043
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51834
--- Comment #4 from Vincent Lefèvre 2012-04-19
15:06:58 UTC ---
(In reply to comment #3)
> (i++, i) + i is undefined. The sequence point only orders i++ and i inside
> the
> parens, but not the operands of +. The third example is not undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53043
--- Comment #1 from H.J. Lu 2012-04-19 14:55:54
UTC ---
It may be caused by revision 186576:
http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00527.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039
--- Comment #5 from H.J. Lu 2012-04-19 14:49:32
UTC ---
(In reply to comment #4)
> HJ, can you help with the search? (mind the -std=c++11)
My regression hunt machine is down. It will take a while to
get it back.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53044
Bug #: 53044
Summary: completely peel loops that do not run a constant time
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #22 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53043
Bug #: 53043
Summary: [4.8 Regression] gcc.target/i386/pr45830.c
scan-tree-dump switchconv "Expanding as bit test is
preferable"
Classification: Unclassified
Product: gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52997
Bernd Schmidt changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |bernds at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48438
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53042
--- Comment #2 from Richard Guenther 2012-04-19
14:09:20 UTC ---
Patch:
Index: gcc/symtab.c
===
--- gcc/symtab.c(revision 186594)
+++ gcc/symtab.c(working copy)
@@ -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53042
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53031
Richard Guenther changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53042
Richard Guenther changed:
What|Removed |Added
Target||powerpc-ibm-aix5.3
Version|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521
--- Comment #10 from janus at gcc dot gnu.org 2012-04-19 13:36:46 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > "Two dummy arguments are distinguishable if
> > - one is a procedure and the other is a data object,
>
> Here is a te
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521
--- Comment #9 from wangmianzhi 2012-04-19
13:22:24 UTC ---
if replace the input argument for test2() with pr, the program will compile but
gives seg fault at run time.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52977
--- Comment #6 from Michael Matz 2012-04-19 13:29:34
UTC ---
Author: matz
Date: Thu Apr 19 13:29:29 2012
New Revision: 186593
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186593
Log:
PR middle-end/52977
* tree.h (VECTOR_CST_NELT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53042
Bug #: 53042
Summary: AIX bootstrap: cgraph symbol table error
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52738
--- Comment #2 from Mateusz Kielar 2012-04-19
13:23:17 UTC ---
The only way I see to resolve this issue is to check if pthread_getspecific
returns null in gomp_thread and if yes then allocate new thread struct and use
pthread_setspecific to store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53031
--- Comment #2 from Richard Guenther 2012-04-19
13:21:50 UTC ---
Author: rguenth
Date: Thu Apr 19 13:21:44 2012
New Revision: 186592
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186592
Log:
2012-04-19 Richard Guenther
PR tree-op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521
--- Comment #8 from wangmianzhi 2012-04-19
13:20:57 UTC ---
if replace the input argument for test2() with pr, the program will
compile but gives seg fault at run time.
于 2012年04月19日 09:04, janus at gcc dot gnu.org 写道:
> http://gcc.gnu.org/bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272
--- Comment #11 from Igor Zamyatin 2012-04-19
13:09:25 UTC ---
Another version of the experimental patch is here -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52868
It fixes bwaves regression on x86 and might not trigger performance on other
pla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52868
--- Comment #1 from Igor Zamyatin 2012-04-19
13:09:07 UTC ---
Experimental patch that fixes the regression:
diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c
index 3c11c0e..9c04516 100644
--- a/gcc/tree-ssa-loop-ivopts.c
+++ b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521
--- Comment #6 from janus at gcc dot gnu.org 2012-04-19 13:04:18 UTC ---
(In reply to comment #5)
> "Two dummy arguments are distinguishable if
> - one is a procedure and the other is a data object,
Here is a test case for this item:
module m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521
--- Comment #5 from janus at gcc dot gnu.org 2012-04-19 12:53:05 UTC ---
(In reply to comment #4)
> Here is a preliminary patch which makes gfortran accept the code in comment
> #2:
Of course we need to do more. As quoted in comment #0:
"Two dum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37457
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53036
Paolo Carlini changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53036
--- Comment #3 from Daniel Krügler
2012-04-19 12:24:12 UTC ---
(In reply to comment #2)
> Sadly, on this case:
> struct A {
> A()=default;
> A(int=2);
> };
> it says A is trivial whereas I guess the ambiguity makes it non-trivial.
I agree. T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28525
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27193
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53036
--- Comment #2 from Marc Glisse 2012-04-19
12:14:04 UTC ---
Created attachment 27189
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27189
basic patch
The patch detects D as trivial.
Sadly, on this case:
struct A {
A()=default;
A(int=2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53015
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53041
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53041
--- Comment #1 from Jonathan Wakely 2012-04-19
12:06:13 UTC ---
This is not a proper bug report, please read http://gcc.gnu.org/bugs/
What are you claiming is a bug in GCC?
Your program is dangerous and has undefined behaviour if more than one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53041
Bug #: 53041
Summary: Changing of array is leading to changing of another
variable
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53033
Georg-Johann Lay changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53033
--- Comment #4 from Georg-Johann Lay 2012-04-19
11:33:08 UTC ---
Author: gjl
Date: Thu Apr 19 11:33:01 2012
New Revision: 186589
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186589
Log:
Backport from 2012-04-19 mainline r186588.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53033
--- Comment #3 from Georg-Johann Lay 2012-04-19
11:29:20 UTC ---
Author: gjl
Date: Thu Apr 19 11:29:13 2012
New Revision: 186588
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186588
Log:
PR target/53033
* config/avr/avr.c (avr_ou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53040
Bug #: 53040
Summary: nested functions may trash floating point registers
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039
Paolo Carlini changed:
What|Removed |Added
CC|mitchnull+gcc at gmail dot |hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37985
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #28 from Oleg Endo 2012-04-19
09:29:41 UTC ---
The prophecy in comment #3 finally came true (again) while I was testing the
patch for PR 52941 ;)
The problem is that when reload tries to swap regs from/to stack, it will try
to use the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52831
Aurelien Buhrig changed:
What|Removed |Added
Version|4.8.0 |4.6.3
--- Comment #2 from Aurelien Buhr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283
chrbr at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53035
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53031
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53030
Richard Guenther changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688
Richard Guenther changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53032
Richard Guenther changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52790
Janne Blomqvist changed:
What|Removed |Added
Target||x86_64-w64-mingw32
Status|U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688
--- Comment #10 from Richard Guenther 2012-04-19
08:53:37 UTC ---
There are still other prologue/epilogue loops that would need similar handling
on their generation. The vectorizer needs to be re-organized to better
separate those loop versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688
--- Comment #9 from Richard Guenther 2012-04-19
08:51:57 UTC ---
Author: rguenth
Date: Thu Apr 19 08:51:50 2012
New Revision: 186585
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186585
Log:
2012-04-19 Richard Guenther
PR rtl-opt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
1 - 100 of 110 matches
Mail list logo
