http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #12 from Oleg Endo 2012-06-12
07:09:58 UTC ---
Author: olegendo
Date: Tue Jun 12 07:09:52 2012
New Revision: 188426
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188426
Log:
PR target/50749
* gcc.target/sh/pr50749-sf-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53639
--- Comment #1 from Jakub Jelinek 2012-06-12
07:40:26 UTC ---
Created attachment 27606
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27606
gcc48-pr53639.patch
The first problem is that combiner combines:
(insn 9 8 10 2 (parallel [
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53589
--- Comment #3 from Jakub Jelinek 2012-06-12
07:52:53 UTC ---
Author: jakub
Date: Tue Jun 12 07:52:47 2012
New Revision: 188428
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188428
Log:
PR rtl-optimization/53589
* cfgrtl.c (force
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53642
Bug #: 53642
Summary: Front-end optimization: Wrong string length for
deferred-length strings
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53643
Bug #: 53643
Summary: [OOP] ICE (segfault) with INTENT(OUT) CLASS array
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549
--- Comment #4 from Conrad 2012-06-12
08:59:54 UTC ---
Created attachment 27607
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27607
pre-processed source exposing the bug
bug confirmed on Fedora 17, using gcc version 4.7.0 20120507 (Red Hat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549
Richard Guenther changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50569
--- Comment #16 from Jiangning Liu 2012-06-12
09:24:21 UTC ---
Author: liujiangning
Date: Tue Jun 12 09:24:11 2012
New Revision: 188431
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188431
Log:
2011-06-12 Jiangning Liu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53640
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549
--- Comment #6 from Conrad 2012-06-12
09:42:08 UTC ---
bug not present when compiling with Clang 3.0
(I've found clang to often have more thorough/readable diagnostics than gcc)
output of clang -v:
clang version 3.0 (tags/RELEASE_30/final)
Targ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51070
--- Comment #10 from Jiangning Liu 2012-06-12
09:44:28 UTC ---
Author: liujiangning
Date: Tue Jun 12 09:44:24 2012
New Revision: 188432
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188432
Log:
2011-06-12 Jiangning Liu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53643
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51042
--- Comment #9 from Jiangning Liu 2012-06-12
09:53:57 UTC ---
Author: liujiangning
Date: Tue Jun 12 09:53:53 2012
New Revision: 188433
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188433
Log:
2011-06-12 Jiangning Liu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
Richard Guenther changed:
What|Removed |Added
Target||x86_64-*-*
Status|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #7 from Richard Guenther 2012-06-12
10:11:51 UTC ---
Btw, when I run the benchmark with the addition of -march=native (for me,
that's
-march=corei7) then GCC 4.7 performs better than 4.6:
4.6:
./t 10
test descrip
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #8 from Richard Guenther 2012-06-12
10:27:15 UTC ---
Small testcase:
int a[256];
int b[256];
void foo (void)
{
int i;
for (i = 0; i < 256; ++i)
{
b[i] = a[i] * 23;
}
}
you can see that we shuffle even the vector w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549
Jonathan Wakely changed:
What|Removed |Added
CC||fabien at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #9 from Richard Guenther 2012-06-12
10:39:19 UTC ---
And cprop fails to propagate
(reg:V4SI 85) := (const_vector:V4SI [
(const_int 23 [0x17])
(const_int 23 [0x17])
(const_int 23 [0x17])
(const_int 23
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549
--- Comment #8 from Jonathan Wakely 2012-06-12
10:39:20 UTC ---
Further reduced, a single example showing both errors:
template
struct C
{
int operator()();
template
struct F : C
{
using C::operator();
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53639
Jakub Jelinek changed:
What|Removed |Added
Attachment #27606|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53604
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572
Richard Guenther changed:
What|Removed |Added
CC||paul.scruby at ghco dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613
--- Comment #8 from Jonathan Wakely 2012-06-12
10:47:58 UTC ---
I think it compiles with 4.4 because __cook::~__cook is not noexcept, because
4.4 doesn't infer an empty throw spec for a trivial destructor.
If you add throw() to ~__cook you get t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
Richard Guenther changed:
What|Removed |Added
CC||stevenb.gcc at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549
--- Comment #9 from Jakub Jelinek 2012-06-12
12:17:37 UTC ---
This started to be rejected with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53639
--- Comment #3 from Uros Bizjak 2012-06-12 12:21:07
UTC ---
(In reply to comment #2)
> Unfortunately that patch regressed pr49095.c testcase. So, either we limit
> the
> splitter to the paradoxical subreg that is created by the combiner when s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53616
Richard Guenther changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #4 from Richard Gu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53643
--- Comment #2 from Tobias Burnus 2012-06-12
12:33:34 UTC ---
I am not sure whether the following (in trans-decl.c) is the proper fix or an
ugly work around, but it seems to work. -- Maybe, a proper fix would be to
modify the following "if" block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53644
Bug #: 53644
Summary: ICE in force_move_args_size_note, at
combine-stack-adj.c:419
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53645
Bug #: 53645
Summary: Missed optimization for division of vector types
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53599
Richard Guenther changed:
What|Removed |Added
Priority|P3 |P1
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53644
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53616
H.J. Lu changed:
What|Removed |Added
Status|WAITING |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53616
--- Comment #5 from H.J. Lu 2012-06-12 13:03:57
UTC ---
Created attachment 27610
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27610
alt.src for 416.games
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
Bug #: 53646
Summary: Surprising effects of cxx11 vs cxx98 ABI compatibility
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621
--- Comment #8 from chrbr at gcc dot gnu.org 2012-06-12 13:26:42 UTC ---
Created attachment 27612
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27612
fix
All the suspicious flags reviewed and looked OK excepted maybe
-maccumulate-outgoing-ar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53645
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53645
Richard Guenther changed:
What|Removed |Added
Keywords||missed-optimization
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #1 from Jonathan Wakely 2012-06-12
13:38:01 UTC ---
(In reply to comment #0)
> In this specific case the problem is the Rb_tree::equal_range function,
> which returns a pair, under cxx98 that's POD (returned via registers), under
> c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53644
Matthias Klose changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53602
Matthias Klose changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621
--- Comment #9 from Kazumoto Kojima 2012-06-12
13:56:37 UTC ---
The patch is pre-approved. Thanks for looking into the issue
thoroughly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53616
--- Comment #6 from Richard Guenther 2012-06-12
14:06:18 UTC ---
Ok, that doesn't apply for me (I'm stuck on v1.0). I can reproduce it with
-fno-tree-vrp without LTO but only with reference input (thus bisecting
to a single file will take _quite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #2 from Jonathan Wakely 2012-06-12
14:19:33 UTC ---
N.B. std::pair is not a POD in c++98 or c++11, so I don't know what libstdc++
could have done to cause the FE to change how it returns a std::pair.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #3 from Jonathan Wakely 2012-06-12
14:27:58 UTC ---
I don't think this is a libstdc++ issue, precompiling the code with 4.7 and
then compiling with 4.8 still segfaults, so it's a FE change not a libstdc++
change.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #4 from Jonathan Wakely 2012-06-12
14:29:03 UTC ---
(In reply to comment #3)
> I don't think this is a libstdc++ issue, precompiling ...
Sorry, brainfart, I meant preprocessing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137
--- Comment #6 from Jason Merrill 2012-06-12
15:01:31 UTC ---
Author: jason
Date: Tue Jun 12 15:01:17 2012
New Revision: 188460
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188460
Log:
PR c++/53599
Revert:
PR c++/53137
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53599
--- Comment #9 from Jason Merrill 2012-06-12
15:01:29 UTC ---
Author: jason
Date: Tue Jun 12 15:01:17 2012
New Revision: 188460
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188460
Log:
PR c++/53599
Revert:
PR c++/53137
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137
Jason Merrill changed:
What|Removed |Added
Target Milestone|4.7.1 |4.7.2
--- Comment #7 from Jason Merrill
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #5 from Michael Matz 2012-06-12 15:36:01
UTC ---
(In reply to comment #2)
> N.B. std::pair is not a POD in c++98 or c++11, so I don't know what libstdc++
> could have done to cause the FE to change how it returns a std::pair.
I don't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #6 from Michael Matz 2012-06-12 15:41:49
UTC ---
FWIW, it's finish_struct_bits setting TREE_ADDRESSABLE, because
type_has_nontrivial_copy_init returns true for pair with that ctor.
I think this indeed makes pair non-POD.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
Bug #: 53647
Summary: [4.8 Regression] gcc.c-torture/compile/20011229-1.c
and gcc.c-torture/compile/pr25311.c
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #7 from Jonathan Wakely 2012-06-12
15:50:05 UTC ---
Trivially copyable is just one small part of the POD requirements. std::pair
has always been non-POD, even in c++98, but in c++98 it is trivially copyable,
in c++11 that move constru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53642
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
Jonathan Wakely changed:
What|Removed |Added
CC||paolo.carlini at oracle dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #9 from Jonathan Wakely 2012-06-12
15:57:16 UTC ---
Defaulting that move-ctor fixes the issue referred to in comment 1 too.
I think we need to find out if that comment is still relevant and fix it if it
is, so we can default the move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #10 from Michael Matz 2012-06-12 16:02:28
UTC ---
Yep, defaulting that ctor changes the ABI back to register passing.
If we could change that in libstdc++, all the better, but I still think the
issue is larger than just this specific
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #11 from Paolo Carlini 2012-06-12
16:04:58 UTC ---
Daniel should have all the details. It might be possible to do the change
*together* with changing the constraining in the various container::insert to
use is_constructible instead of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #12 from Paolo Carlini 2012-06-12
16:12:55 UTC ---
If I remember correctly, the last time I tried, default + is_constructible
worked pretty well modulo testcases sensitive to access control under sfinae.
But the latter we are going to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53592
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
Bug #: 53648
Summary: nested empty tuple
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53590
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|2012-06-11 00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
--- Comment #2 from chesstr at hotmail dot com 2012-06-12 17:13:33 UTC ---
(In reply to comment #1)
> I have a fix for this already, IIRC it's simply a case of not using the EBO
> for
> a tuple that contains std::tuple<>
Yes, an easy fix in tuple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
William J. Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
--- Comment #3 from Jonathan Wakely 2012-06-12
17:27:50 UTC ---
There are other cases involving non-empty tuples that will still result in an
ambiguity e.g.
struct A { };
auto d = tuple, A>, A>{};
My solution avoids using the EBO for some condi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
--- Comment #2 from H.J. Lu 2012-06-12 17:45:40
UTC ---
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -fno-diagnostics-show-caret
-Os -w -c -o pr25311.o
/export/gnu/import/git/gcc/gcc/te
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
H.J. Lu changed:
What|Removed |Added
CC||ubizjak at gmail dot com
--- Comment #3 from H.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
--- Comment #4 from chesstr at hotmail dot com 2012-06-12 18:03:56 UTC ---
(In reply to comment #3)
> There are other cases involving non-empty tuples that will still result in an
> ambiguity e.g.
>
> struct A { };
> auto d = tuple, A>, A>{};
>
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511
--- Comment #13 from Oleg Endo 2012-06-12
18:25:46 UTC ---
Author: olegendo
Date: Tue Jun 12 18:25:40 2012
New Revision: 188471
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188471
Log:
PR target/53511
* gcc.target/sh/pr51340-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #11 from Matt Hargett 2012-06-12 18:25:25 UTC
---
Richard,
Thanks for the quick analysis! Sounds like a perfect storm of sorts :/
re: cprop failure: this may be indicated by another major regression in their
suite for the "simple co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53599
--- Comment #10 from Jason Merrill 2012-06-12
18:32:10 UTC ---
Author: jason
Date: Tue Jun 12 18:32:04 2012
New Revision: 188473
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188473
Log:
PR c++/53599
* name-lookup.c (pushtag_1):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53645
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #12 from Richard Henderson 2012-06-12
18:54:24 UTC ---
(In reply to comment #10)
> But maybe allowing const_vector in (some of) the define_insn_and_split would
> be the way to go ...
Maybe. It certainly would ease some of the simpli
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
William J. Schmidt changed:
What|Removed |Added
Component|middle-end |target
--- Comment #4 from William J
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
--- Comment #5 from William J. Schmidt 2012-06-12
19:09:48 UTC ---
If this is incorrect, and zero is supposed to indicate a cacheless memory (do
they exist anymore?), then I can disable the adjacent-loads hoisting
optimization for that case. Som
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
--- Comment #6 from H.J. Lu 2012-06-12 19:26:12
UTC ---
We should update i386.c to have reasonable values for
size of l1 cache, size of l2 cache, size of prefetch block
and number of parallel prefetches, instead of 0s.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
--- Comment #7 from Uros Bizjak 2012-06-12 19:40:21
UTC ---
Perhaps simply:
--cut here--
Index: tree-ssa-phiopt.c
===
--- tree-ssa-phiopt.c (revision 188475)
+++ tree-ssa-phiopt.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
--- Comment #8 from Uros Bizjak 2012-06-12 19:45:56
UTC ---
Alternative patch with the same functionality:
--cut here--
Index: tree-ssa-phiopt.c
===
--- tree-ssa-phiopt.c (revisio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
--- Comment #8 from Uros Bizjak 2012-06-12 19:45:56
UTC ---
Alternative patch with the same functionality:
--cut here--
Index: tree-ssa-phiopt.c
===
--- tree-ssa-phiopt.c (revisio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
William J. Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17958
Andrew Pinski changed:
What|Removed |Added
AssignedTo|roger at eyesopen dot com |dtemirbulatov at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53645
Andrew Pinski changed:
What|Removed |Added
Depends on||51581
--- Comment #3 from Andrew Pinski
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53196
--- Comment #8 from Jakub Jelinek 2012-06-12
21:16:24 UTC ---
Author: jakub
Date: Tue Jun 12 21:16:20 2012
New Revision: 188483
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188483
Log:
PR c/53532
PR c/51034
PR c/53196
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51034
--- Comment #4 from Jakub Jelinek 2012-06-12
21:16:24 UTC ---
Author: jakub
Date: Tue Jun 12 21:16:20 2012
New Revision: 188483
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188483
Log:
PR c/53532
PR c/51034
PR c/53196
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53532
--- Comment #3 from Jakub Jelinek 2012-06-12
21:16:24 UTC ---
Author: jakub
Date: Tue Jun 12 21:16:20 2012
New Revision: 188483
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188483
Log:
PR c/53532
PR c/51034
PR c/53196
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53649
Bug #: 53649
Summary: ICE when using 'C' x86 asm constraint
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: trivial
Priority: P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51997
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53650
Bug #: 53650
Summary: large array causes huge memory use
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53651
Bug #: 53651
Summary: seg fault when specifying using decltype(...)::method
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50043
--- Comment #13 from Kirby Zhou 2012-06-13 03:48:34
UTC ---
How about back port this patch to 4.7 branch?
It cause a lot of compile error which easily confuse programmers.
(In reply to comment #9)
> Author: paolo
> Date: Mon Apr 2 00:13:30 201
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53650
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621
--- Comment #10 from chrbr at gcc dot gnu.org 2012-06-13 05:59:16 UTC ---
currently analyzing a regression
gcc.dg/stack-usage-1.c scan-file foo\t(256|264)\tstatic
Don't know yet if it's a problem with the test or a side effect. But this
delays th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53652
Bug #: 53652
Summary: *andn* isn't used for vectorization
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621
--- Comment #11 from Kazumoto Kojima 2012-06-13
06:52:20 UTC ---
Looks a problem with the test. It should be tweaked with adding
#elif defined (__sh__)
# define SIZE 252
for frame pointer save area.
96 matches
Mail list logo
