http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028
--- Comment #7 from Manuel López-Ibáñez 2012-04-19
07:03:30 UTC ---
grep -F "pedantic-errors" testsuite/gcc.dg/*.c
Most of those testcases are duplicated or triplicated.
Another alternative could be if -pedantic warnings always were associated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53038
Bug #: 53038
Summary: cfi_restore for cr before cr is actually restored
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53038
Alan Modra changed:
What|Removed |Added
Target||powerpc-linux
Known to fail|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53035
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039
Bug #: 53039
Summary: [C++11]including breaks
std::is_convertible with template-pack expansion
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039
--- Comment #1 from Radics Péter 2012-04-19
07:59:06 UTC ---
Created attachment 27186
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27186
4.8.0 output
test run by sam of #c++ on freenode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039
--- Comment #2 from Radics Péter 2012-04-19
08:00:00 UTC ---
Created attachment 27187
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27187
4.7.0 output
test run on arch linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45088
Pawel Sikora changed:
What|Removed |Added
CC||pluto at agmk dot net
--- Comment #10 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52579
--- Comment #1 from gee 2012-04-19 08:23:39 UTC ---
i came into conclusion that we need to separate ffi_closure_raw_THISCALL from
ffi_closure_raw_SYSV(not using such as jmp .stubraw), because
ffi_closure_raw_THISCALL is not transparent by CFI so t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52878
--- Comment #13 from Eric Botcazou 2012-04-19
08:40:53 UTC ---
> One approach is to provide masks.opt to provide those masks without
> switch. masks.opt should be used when long-double-switch.opt isn't
> used.
How ugly. Please do something in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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=52790
Janne Blomqvist changed:
What|Removed |Added
Target||x86_64-w64-mingw32
Status|U
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=44688
Richard Guenther changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned
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=53031
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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=52283
chrbr at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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=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=37985
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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=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=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=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
Georg-Johann Lay changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
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=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
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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=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=27193
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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=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=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=37457
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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=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
--- 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=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
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #7
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
--- 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=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=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=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=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=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=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=53042
Richard Guenther changed:
What|Removed |Added
Target||powerpc-ibm-aix5.3
Version|
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
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=48438
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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=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=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=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=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=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=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
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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|ASSIGNED|RESOLVED
Resolution|
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=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=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=53038
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=53040
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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=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=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 #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=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 #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=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 #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
, -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 #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?
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=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 #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=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=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=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=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=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=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=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
--- 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
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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=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=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=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=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
1 - 100 of 110 matches
Mail list logo