https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Mon Feb 1 08:47:27 2016
New Revision: 233033
URL: https://gcc.gnu.org/viewcvs?rev=233033&root=gcc&view=rev
Log:
PR rtl-optimization/69570
* ifcvt.c (bb_ok_for_noce_conver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69574
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69556
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69579
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69588
Bug ID: 69588
Summary: ICE: tree check: expected ssa_name, have var_decl in
unlink_stmt_vdef, at tree-ssa-operands.c:1314
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69580
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69578
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69586
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69582
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69038
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|ebotcazou at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564
Richard Biener changed:
What|Removed |Added
Keywords||lto, missed-optimization
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564
--- Comment #2 from Richard Biener ---
It looks like we get different BB order out of C++ than C but otherwise no real
code-differences as far as I can see.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564
--- Comment #3 from vincenzo Innocente ---
> Any reason you are using the c++ driver here?
Because I am interested in C++ performance
never imagined that the c++ front-end could make a difference on such a code...
>From my point of view it is eve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69589
Bug ID: 69589
Summary: [6 Regression] ICE in initialize_node_lattices, at
ipa-cp.c:971
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69574
Richard Biener changed:
What|Removed |Added
CC||spop at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
Wilco changed:
What|Removed |Added
CC||wdijkstr at arm dot com
--- Comment #2 from Wilc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target|powerpc*-*-*|powerpc*-*-*, aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69589
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69590
Bug ID: 69590
Summary: Test script tries to compile source code with
"-mthumb" option when running test gcc.dg/binop-xor1.c
for powerpc64
Product: gcc
Version: 4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69588
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69588
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564
--- Comment #5 from vincenzo Innocente ---
it is a regression
gcc version 4.9.3 (GCC)
c++ -Ofast *.c; ./a.out
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69589
--- Comment #1 from Martin Liška ---
I fixed my reduction script, now reducing about ~14MB of pre-processed source
files.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69184
--- Comment #2 from ktkachov at gcc dot gnu.org ---
Smaller testcase for -Ofast -floop-interchange on aarch64:
int a, b, c, e, f, g;
int d[1];
static int *h = &c;
long i;
int
fn1 (short p1)
{
return p1 + a;
}
void
fn2 ()
{
for (; f; f++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69588
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67396
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69579
--- Comment #4 from Jakub Jelinek ---
Cleaned up testcase:
extern int __sigsetjmp (void *);
int
foo (int *x, void *y)
{
int i = 1;
__sigsetjmp (y);
while (i)
{
for (i = 0; i < (x ? *x : 1); i++)
foo (x, y);
}
retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69579
--- Comment #5 from rguenther at suse dot de ---
On Mon, 1 Feb 2016, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69579
>
> --- Comment #4 from Jakub Jelinek ---
> Cleaned up testcase:
>
> extern int __sigset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581
--- Comment #6 from Jonathan Wakely ---
Author: redi
Date: Mon Feb 1 11:13:40 2016
New Revision: 233035
URL: https://gcc.gnu.org/viewcvs?rev=233035&root=gcc&view=rev
Log:
Don't define guard macros when doing #include_next in math.h and stdlib.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564
Richard Biener changed:
What|Removed |Added
Known to work||4.9.3
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564
--- Comment #6 from Richard Biener ---
Looks like since GCC 5 we wrap all loops in a while (1). Eventually this just
confuses GCCs static prediction machinery but who knows.
Old (not the problematic function!):
{
int i;
int j;
<;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581
--- Comment #7 from Bernd Edlinger ---
Thanks. Now about reversing the comments at the bottom of math.h ?
Index: libstdc++-v3/include/c_compatibility/math.h
===
--- libstdc++-v3/in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581
--- Comment #9 from Jonathan Wakely ---
(In reply to Bernd Edlinger from comment #7)
> Thanks. Now about reversing the comments at the bottom of math.h ?
I don't understand the question. I already fixed the order of the comments in
the commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581
--- Comment #10 from Bernd Edlinger ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Bernd Edlinger from comment #7)
> > Thanks. Now about reversing the comments at the bottom of math.h ?
>
> I don't understand the question. I a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69089
--- Comment #5 from Dominik Vogt ---
No, up to now you're the only one who commented on it. I keep pinging it once
in a while.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
Dominique d'Humieres changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58233
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #10 from Dominique d'Humieres ---
Related to pr50410.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410
--- Comment #20 from Dominique d'Humieres ---
The test in comment 2 is a duplicate of pr49278.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
Jakub Jelinek changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
--- Comment #20 from Jakub Jelinek ---
Does the http://gcc.gnu.org/ml/gcc-patches/2016-01/msg02347.html workaround
help here in any way?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
--- Comment #21 from Jakub Jelinek ---
In any case, we need much better testsuite coverage for the cases that the
various projects use (glib2, LO, ...), so that we don't regress on those
without knowing about it months later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69068
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67451
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #4 from ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69556
--- Comment #8 from Richard Biener ---
Testcase that we'd break with removing the canonicalization for the
non-single-use case:
int bar (double, double);
int
foo (double a)
{
double x = 2./a;
double y = 4./a;
return x * 2. == y || bar (x,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #5 from Wilco ---
This still fails on AArch64 in exactly the same way with latest trunk - can
someone reopen this? I don't seem to have the right permissions...
(In reply to Richard Biener from comment #4)
> So - can you please bisect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69068
--- Comment #2 from Arseny Solokha ---
(In reply to ktkachov from comment #1)
> I also see this ICE on this testcase on aarch64:
> int a, b, c, e;
> int d[1];
> void
> fn1 ()
> {
> for (; b;)
> for (; c; c++)
> {
> a = 0;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69579
--- Comment #6 from Richard Biener ---
Author: rguenth
Date: Mon Feb 1 12:39:04 2016
New Revision: 233036
URL: https://gcc.gnu.org/viewcvs?rev=233036&root=gcc&view=rev
Log:
2016-02-01 Richard Biener
PR tree-optimization/69579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69579
Richard Biener changed:
What|Removed |Added
Known to work||6.0
Summary|[4.9/5/6 Regress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69296
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
--- Comment #11 from Thomas Koenig ---
(In reply to Manuel López-Ibáñez from comment #7)
> Please take this as a humble general suggestion: Fortran maintainers should
> enforce during patch review that any new diagnostic has a corresponding
> tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
--- Comment #22 from Stephan Bergmann ---
(In reply to Jakub Jelinek from comment #20)
> Does the http://gcc.gnu.org/ml/gcc-patches/2016-01/msg02347.html workaround
> help here in any way?
No, unfortunately not. Doesn't change the behaviour in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69591
Bug ID: 69591
Summary: gcc.dg/and-1.c scan-assembler-not nand fails on
powerpc64-linux-gnu
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
--- Comment #23 from Manuel López-Ibáñez ---
(In reply to Stephan Bergmann from comment #18)
> (Also, the problem
> only happens with -O or higher.)
That is weird. If you use "GCC diagnostic warning" instead of "ignored", you
should be able to s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69479
Tiago Brusamarello changed:
What|Removed |Added
CC||tiago.brusamarello@datacom.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69591
Tiago Brusamarello changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
--- Comment #12 from Manuel López-Ibáñez ---
(In reply to Thomas Koenig from comment #11)
> (In reply to Manuel López-Ibáñez from comment #7)
> > Please take this as a humble general suggestion: Fortran maintainers should
> > enforce during patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69577
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
--- Comment #24 from Stephan Bergmann ---
(In reply to Manuel López-Ibáñez from comment #23)
> That is weird. If you use "GCC diagnostic warning" instead of "ignored", you
> should be able to see some changes in locations between -O0 and -O1 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69592
Bug ID: 69592
Summary: [6 Regression] Compile-time and memory-use hog in
combine
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: compile-time-hog, memor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69592
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69592
--- Comment #1 from Richard Biener ---
In SHA512_Compress, -O2 is enough, unoptimized checking GCC 5 branch builds it
in 5s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69590
Yvan Roux changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69592
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69593
Bug ID: 69593
Summary: static thread_local in a structure within a function
template causes segfault
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69594
Bug ID: 69594
Summary: ICE in discriminator_for_local_entity
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69589
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69592
--- Comment #3 from Richard Biener ---
Created attachment 37540
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37540&action=edit
reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68740
--- Comment #1 from John David Anglin ---
We need to add the following to test:
-bash-4.3$ svn diff testsuite/experimental/type_erased_allocator/1.cc
Index: testsuite/experimental/type_erased_allocator/1.cc
==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #6 from Wilco ---
This still fails on AArch64 in exactly the same way with latest trunk - can
someone reopen this? I don't seem to have the right permissions...
(In reply to Richard Biener from comment #4)
> So - can you please bisect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69594
vries at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69595
Bug ID: 69595
Summary: [6 Regression] Bogus -Warray-bound warning due to
missed optimization
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: diagnostic,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69596
Bug ID: 69596
Summary: vzeroupper is generated in interrupt handler
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69595
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69593
Jonathan Wakely changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68740
--- Comment #2 from Jonathan Wakely ---
(In reply to John David Anglin from comment #1)
> On hpux, we need -L and -B options for directory
> /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libatomic/.libs.
OK, we can probably just add that unconditio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69597
Bug ID: 69597
Summary: execution failure for
libgomp.oacc-c-c++-common/atomic_capture-1.c with
-flto
Product: gcc
Version: 6.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #7 from rguenther at suse dot de ---
On Mon, 1 Feb 2016, wdijkstr at arm dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
>
> --- Comment #6 from Wilco ---
> This still fails on AArch64 in exactly the same way wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68740
--- Comment #3 from dave.anglin at bell dot net ---
On 2016-02-01 10:07 AM, redi at gcc dot gnu.org wrote:
> OK, we can probably just add that unconditionally, but I'll investigate.
> Thanks
> for the details.
Fortran has this worked out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69595
--- Comment #2 from Richard Biener ---
We want to improve extract_range_from_comparison to build a symbolic range
instead of varying here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69595
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69577
--- Comment #4 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #3)
> This looks like a RA issue or backend bug, perhaps the r215450 change needs
> to be narrowed down?
>
> In *.ira we have:
> (insn 3 2 4 2 (set (reg/v:V2TI 102
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69574
Richard Biener changed:
What|Removed |Added
Known to work||6.0
Summary|[4.9/5/6 Regress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69574
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Mon Feb 1 15:38:08 2016
New Revision: 233039
URL: https://gcc.gnu.org/viewcvs?rev=233039&root=gcc&view=rev
Log:
2016-02-01 Richard Biener
PR tree-optimization/69574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69556
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69598
Bug ID: 69598
Summary: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp1
"[xy][^ ]* !=" 0 fails for powerpc64-linux-gnu
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69556
--- Comment #10 from Richard Biener ---
Author: rguenth
Date: Mon Feb 1 15:40:23 2016
New Revision: 233040
URL: https://gcc.gnu.org/viewcvs?rev=233040&root=gcc&view=rev
Log:
2016-02-01 Richard Biener
PR middle-end/69556
* ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69592
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #8 from Wilco ---
In a few functions GCC decides that the assignments in loops are redundant. The
loops still execute but have their loads and stores removed. Eg. the first DO
loop in MP2NRG should be:
.L1027:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57365
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from Domin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69577
--- Comment #5 from Uroš Bizjak ---
(In reply to Vladimir Makarov from comment #4)
> I believe machine-dependent code is more responsible for it. I remember
> some discussion of it. LRA follows RTL semantics where insn
>
> (set (subreg reg 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69098
--- Comment #6 from Patrick Palka ---
This fixes it:
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index ef79b59..264c8aa 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -13735,7 +13735,19 @@ tsubst_qualified_id (tree qualified_id, tree args,
}
1 - 100 of 191 matches
Mail list logo
