https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63605
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63607
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63605
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55821
--- Comment #10 from Francois-Xavier Coudert ---
Author: fxcoudert
Date: Tue Oct 21 08:59:17 2014
New Revision: 216503
URL: https://gcc.gnu.org/viewcvs?rev=216503&root=gcc&view=rev
Log:
PR libquadmath/55821
* Makefile.am: Unconditionally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #71 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #69)
> the code size regression for CSiBE from non LRA is reduced to 0.59%.
> Looking at the improved cases, the extra save/restore insns to/from
> stack disappear. I g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #72 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #70)
> I'd like to apply the revised patches below to sh-lra branch for
> looking at the problems easily. Oleg, is it OK for you?
Sure. However, maybe it's better to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
Richard Biener changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63594
--- Comment #7 from Jakub Jelinek ---
Note that this bug shows up in quite a lot of regressions on the trunk, both
x86_64 and i686:
+FAIL: gcc.target/i386/avx-1.c (internal compiler error)
+FAIL: gcc.target/i386/avx-1.c (test for excess errors)
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63223
--- Comment #8 from Georg-Johann Lay ---
(In reply to Jorn Wolfgang Rennecke from comment #4)
> (In reply to Georg-Johann Lay from comment #1)
> do_global_dtors is supposed to start at the start and increment from there.
> I see it used to be hal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
--- Comment #15 from Richard Biener ---
(In reply to rguent...@suse.de from comment #13)
> On Tue, 17 Jun 2014, law at redhat dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
> >
> > Jeffrey A. Law changed:
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63608
Bug ID: 63608
Summary: [4.8 Regression]error: type mismatch in binary
expression
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: critical
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
--- Comment #16 from Richard Biener ---
Btw, why is it recording twice a temporary equivalence? Might be simpler even
with
/* Now invalidate all equivalencies we have to invalidate. */
unsigned i;
sbitmap_iterator bi;
EXECUTE_IF_SET_IN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
Tobias Burnus changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Tobias Burnus -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
--- Comment #17 from Richard Biener ---
Oops, that's not 100% the same. But
/* Now invalidate all equivalencies we have to invalidate. */
for (unsigned int i = 1; i < num_ssa_names; ++i)
{
tree name = ssa_name (i);
if (!nam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
--- Comment #18 from Richard Biener ---
Testing that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
--- Comment #19 from Richard Biener ---
Btw, are you sure all temporary equivalences are to SSA names only? ISTR
we have memory equivalencies as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
--- Comment #3 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #2)
> COLLECT_GCC_OPTIONS='-v' '-fno-use-linker-plugin' '-fno-lto'
> '-mtune=generic' '-march=x86-64'
> [...]/collect2 [...]
I haven't shown it, but the collect2 argum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488
--- Comment #9 from Evgeniya Maenkova ---
I use 32bit Linux, perhaps, that gives the difference.
Regarding checking and O2 - I will read about this. Thanks for your note.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
--- Comment #20 from Richard Biener ---
Created attachment 33766
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33766&action=edit
non-working patch
Of course this still walks all SSA names (but only once per BB), so it isn't
really removin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #73 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #71)
> I don't know the details and maybe I'm totally off here ... LRA is being
> used for ARM and there are almost the same amount of GP registers available
> on ARM th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #74 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #73)
> I'm not sure about ARM. The problematic cases I've looked at are
> high R0 pressure cases and IRA decided to allocate equiv value
> registers to memory as most p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
--- Comment #4 from rguenther at suse dot de ---
On Tue, 21 Oct 2014, burnus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
>
> --- Comment #3 from Tobias Burnus ---
> (In reply to Tobias Burnus from comment #2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
--- Comment #21 from Richard Biener ---
So to recap - apart from really fixing the quadraticness - it would be nice
if we can just disable threading over backedges at -O1, thus for
!flag_expensive_optimizations. Especially on the 4.9 branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63542
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63563
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Tue Oct 21 12:23:11 2014
New Revision: 216507
URL: https://gcc.gnu.org/viewcvs?rev=216507&root=gcc&view=rev
Log:
PR tree-optimization/63563
* tree-vect-data-refs.c (vect_analyze_d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63563
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Tue Oct 21 12:27:25 2014
New Revision: 216508
URL: https://gcc.gnu.org/viewcvs?rev=216508&root=gcc&view=rev
Log:
PR tree-optimization/63563
* tree-vect-data-refs.c (vect_analyze_d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63563
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63424
Renlin Li changed:
What|Removed |Added
CC||renlin.li at arm dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63223
--- Comment #9 from Jorn Wolfgang Rennecke ---
(In reply to Georg-Johann Lay from comment #8)
> (In reply to Jorn Wolfgang Rennecke from comment #4)
> > (In reply to Georg-Johann Lay from comment #1)
> > do_global_dtors is supposed to start at th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63223
--- Comment #10 from Jorn Wolfgang Rennecke ---
Created attachment 33768
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33768&action=edit
patch for dtor direction
I have this patch for fixing the direction of the dtor execution,
but I got
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #33 from Stupachenko Evgeny ---
Created attachment 33769
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33769&action=edit
patch includes 3 patches fixing darwin bootstrap
It looks like data constant LC0 generated from pushtf no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #25 from Yury Gribov ---
Can we close this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63609
Bug ID: 63609
Summary: incompatibility with C++11 standard on 14.5.6.2
Partial ordering of function templates
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #34 from Dominique d'Humieres ---
Bootstrap completed with the patch in comment 33 applied on top of r216304 and
configured with:
../p_work/configure --prefix=/opt/gcc/gcc4.10p-216304p1
--enable-languages=c,c++,lto,fortran,ada,objc,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503
--- Comment #10 from Wilco ---
The loops shown are not the correct inner loops for those options - with
-ffast-math they are vectorized. LLVM unrolls 2x but GCC doesn't. So the
question is why GCC doesn't unroll vectorized loops like LLVM?
GCC:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503
--- Comment #11 from Andrew Pinski ---
(In reply to Wilco from comment #10)
> The loops shown are not the correct inner loops for those options - with
> -ffast-math they are vectorized. LLVM unrolls 2x but GCC doesn't. So the
> question is why GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610
Bug ID: 63610
Summary: OSX 10.10 (Yosemite) segfault in MPIR testsuite with
-O0 or -O1
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610
--- Comment #1 from Volker Braun ---
Created attachment 33770
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33770&action=edit
Log of the MPIR compilation ending in the testsuite failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610
--- Comment #3 from Volker Braun ---
Created attachment 33773
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33773&action=edit
gdb log of the failing testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610
--- Comment #2 from Volker Braun ---
Created attachment 33771
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33771&action=edit
gcc -v output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63611
Bug ID: 63611
Summary: Invalid optimization for "==" on pointers
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63611
--- Comment #1 from Keith Thompson ---
A bug report for a similar issue with clang is here:
http://llvm.org/bugs/show_bug.cgi?id=21327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503
--- Comment #12 from Evandro Menezes ---
Created attachment 33774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33774&action=edit
Simple test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612
Bug ID: 63612
Summary: #pragma breaks if...else
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63611
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
Joseph S. Myers changed:
What|Removed |Added
CC||Keith.S.Thompson at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612
--- Comment #2 from Andrew Pinski ---
I should say some of the pragma's are considered statements while others are
not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #26 from Paul H. Hargrove ---
(In reply to Yury Gribov from comment #25)
> Can we close this?
Just tried to build the released 4.8.3 and still see the original problem (see
error messages below). Same is true at the tip of the gcc-4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #6 from Keith Thompson ---
In the test case for Bug 63611 (marked as a duplicate of this one)
we have:
element x[1];
element y[1];
element *const x0 = x;
element *const x1 = x0 + 1;
element *const y0 = y;
When th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #7 from joseph at codesourcery dot com ---
On Tue, 21 Oct 2014, Keith.S.Thompson at gmail dot com wrote:
> their last-stored values. Furthermore, even if relocating objects so
> they're no long adjacent is permitted by the language,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612
--- Comment #3 from steveren ---
That seems strange and counterintuitive to say the least.
FWIW, three other compilers I've got to hand - clang on Linux, Visual C++ and
an old Borland compiler on Windows - all do exactly as I'd expect, printing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #4 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326
Andrew Pinski changed:
What|Removed |Added
CC||q@rsn-tech.co.uk
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #8 from Keith Thompson ---
I'm not (deliberately) considering anything other than the requirements
of the C standard.
The standard talks about an array object immediately following another
array object in the address space. Since tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #75 from Kazumoto Kojima ---
FYI, merge from trunk revision 216447 as r216529.
I've fixed c#55, c#59, c#61 and c#66 so to match this merge and committed
them on sh-lra as r216532, r216533, r216533 and r216535, respectively.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63598
--- Comment #2 from John David Anglin ---
If I apply this change
Index: ipa-icf.c
===
--- ipa-icf.c(revision 216524)
+++ ipa-icf.c(working copy)
@@ -584,8 +584,12 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #9 from joseph at codesourcery dot com ---
On Tue, 21 Oct 2014, Keith.S.Thompson at gmail dot com wrote:
> Are you saying it's possible that y immediately follows x in the
> address space when that line of output is printed, and that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63595
--- Comment #4 from Pat Haugen ---
Created attachment 33775
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33775&action=edit
unreduced bzip2 testcase
CPU2006 benchmark 447.dealII started segfaulting on PowerPC with revision
216305. Sorry f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #10 from Keith Thompson ---
I strongly disagree with your interpretation.
Do you believe that the authors of the standard meant it the way you do?
I suggest that the footnote:
> Two objects may be adjacent in memory because they ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #27 from Daniel Richard G. ---
Likewise confirmed on the same Woody system from comment #5: 4.9.1 bootstraps
fine, 4.8.3 still has the bug.
(Oddly enough, the first configure run in the 4.9.1 bootstrap has the message
"checking for l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213
Matheus Izvekov changed:
What|Removed |Added
CC||mizvekov at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213
--- Comment #19 from Matheus Izvekov ---
CWG 1170 is still not correctly implemented as of gcc 4.9.1
The attached test shows just this.
Compile it with
"g++ -std=c++11 -DPUB=0 test.cc" and
"g++ -std=c++11 -DPUB=1 test.cc".
The one with PUB=0 s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612
--- Comment #5 from Dietmar Schindler ---
(In reply to steveren from comment #3)
> Is there any public discussion of the rationale behind this design decision?
In news:comp.std.c there is a thread "#pragma are considered statements" -
https://gr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63574
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63542
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Wed Oct 22 06:56:36 2014
New Revision: 216540
URL: https://gcc.gnu.org/viewcvs?rev=216540&root=gcc&view=rev
Log:
PR target/63542
* config/i386/i386.c (ix86_pic_register_p): Also r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63594
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Wed Oct 22 06:58:57 2014
New Revision: 216541
URL: https://gcc.gnu.org/viewcvs?rev=216541&root=gcc&view=rev
Log:
PR target/63594
* config/i386/i386.c (ix86_expand_vector_init_dupl
70 matches
Mail list logo
