http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58096
Yufeng Zhang changed:
What|Removed |Added
CC||yufeng at gcc dot gnu.org
--- Comment #3 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58134
Bug ID: 58134
Summary: -ftree-vectorizer-verbose= shows vectroiyed loops
only for N== 1 and N >2 but not for N==2
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #3 from Thomas Koenig ---
Files modified in the GCC repository. Log entry:
2013-08-12 Thomas Koenig
* gcc-4.9/changes.html: Document -Wzerotrip.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58125
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58131
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #10 from Marek Polacek ---
*** Bug 58131 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58133
Bug ID: 58133
Summary: GCC should emit arm assembly following the unified
syntax
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42947
--- Comment #3 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #2)
> Kaz, maybe you have an idea whether/how this could be improved?
I'm also using symbolic links for those issues and have no good
idea for multilibs handling itself.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58132
Bug ID: 58132
Summary: x86-64 gcc generate wrong movabs code for intel syntax
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 53349, which changed state.
Bug 53349 Summary: Internal compiler error with constexpr and recursive data
type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53349
What|Removed |Added
-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53349
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52464
Paolo Carlini changed:
What|Removed |Added
Status|WAITING |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58130
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53349
Paolo Carlini changed:
What|Removed |Added
Target Milestone|--- |4.9.0
--- Comment #3 from Paolo Carlini
regression from
4.8.x.
$ gcc-trunk -v
gcc version 4.9.0 20130811 (experimental) [trunk revision 201651] (GCC)
$ gcc-trunk -O2 -c small.c
$ gcc-4.8 -O3 -c small.c
$ gcc-trunk -O3 -c small.c
small.c: In function ‘foo’:
small.c:5:6: internal compiler error: Segmentation fault
void foo ()
^
0x7e02bf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58130
--- Comment #1 from Vittorio Romeo ---
Isn't
decltype(items)
equivalent to
std::vector>
?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58130
Bug ID: 58130
Summary: [C++11] Compilation fails using "const decltype(...)&
getter() const {...}"
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: majo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58129
Bug ID: 58129
Summary: [C++11] Lack of access control checking using auto
type deduction
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58128
Bug ID: 58128
Summary: Problem using NAME (STANDARD_INPUT) in gcc-4.7.2
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44978
Mikael Morin changed:
What|Removed |Added
Attachment #30630|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58122
--- Comment #3 from Oleg Endo ---
Looking at the tree dump (-fdump-tree-all -fdump-tree-all-details), it seems
that this is related to loop unrolling (dump file *t.cunroll) and induction
variable optimization.
If the number of iterations is small
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44978
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|janus at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58127
Bug ID: 58127
Summary: [4.9 Regression] 37 failures in gcc.dg/tree-prof/ for
x86_64-apple-darwin10
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: norm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #19 from Dominique d'Humieres ---
Note that the patch in comment #10 no longer applies cleanly due to revision
197053:
@@ -6013,7 +5786,7 @@
gfc_add_expr_to_block (&block, tmp);
}
}
- else if (expr->ts.type == BT_DER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58122
Anthony Foiani changed:
What|Removed |Added
CC||anthony.foiani at gmail dot com
--- Comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58126
Bug ID: 58126
Summary: No diagnostic when inheriting an uninitialized const
or reference member
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58058
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58058
--- Comment #6 from janus at gcc dot gnu.org ---
Fixed on 4.7 with:
Author: janus
Date: Sun Aug 11 14:08:12 2013
New Revision: 201653
URL: http://gcc.gnu.org/viewcvs?rev=201653&root=gcc&view=rev
Log:
2013-08-11 Janus Weil
Backport from t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58125
Bug ID: 58125
Summary: [4.9 Regression] ICE: in operator[], at vec.h:827 with
-fno-inline-small-functions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44978
--- Comment #14 from Mikael Morin ---
(In reply to janus from comment #13)
> > > Well, the advantage of my original patch is obviously that it not only
> > > avoids the double errors, but it also prevents us from doing double the
> > > work
> > >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58058
--- Comment #5 from janus at gcc dot gnu.org ---
Fixed on 4.8 with:
Author: janus
Date: Sun Aug 11 11:31:41 2013
New Revision: 201652
URL: http://gcc.gnu.org/viewcvs?rev=201652&root=gcc&view=rev
Log:
2013-08-11 Janus Weil
Backport from tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58122
--- Comment #1 from Oleg Endo ---
(In reply to Oleg Endo from comment #0)
>
> I've checked this with an SH cross compiler setup, but I don't think it
> matters.
> The loops do get eliminated if the number of loop iterations is max. 17, for
> both
all
FAIL: g++ (GCC) 4.8.2 20130811 (prerelease)
FAIL: g++ (GCC) 4.9.0 20130811 (experimental)
class C {
public:
C() {}
~C() {}
int m() { return 0; }
};
/* 7 */ int main() {
/* 8 */ C a;
/* 9 */ C b;
/* 10 */ C c;
/* 11 */ return a.m() + b.m() + c.m();
/* 12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58122
Bug ID: 58122
Summary: loops are not evaluated at compile time if loop count
> 17
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51488
Paolo Carlini changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #2 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42947
Oleg Endo changed:
What|Removed |Added
CC||kkojima at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44978
--- Comment #13 from janus at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #12)
> > IMHO it is probably not worth the hassle. I wouldn't like to do this without
> > having a concrete reason for it (and with a clean testsuite I don't s
38 matches
Mail list logo
