https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #22 from Joshua Kinard kumba at gentoo dot org ---
(In reply to Andrew Pinski from comment #21)
(In reply to Joshua Kinard from comment #20)
Created attachment 33166 [details]
Disassembly of the ASM from 'sln' compiled by a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63607
Bug ID: 63607
Summary: run fail with -flto -mfloat-abi=softfp for
armeb-linux-gnueabi-gcc
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63605
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63607
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63605
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55821
--- Comment #10 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
Author: fxcoudert
Date: Tue Oct 21 08:59:17 2014
New Revision: 216503
URL: https://gcc.gnu.org/viewcvs?rev=216503root=gccview=rev
Log:
PR libquadmath/55821
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #71 from Oleg Endo olegendo at gcc dot gnu.org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #72 from Oleg Endo olegendo at gcc dot gnu.org ---
(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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||law at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63594
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63223
--- Comment #8 from Georg-Johann Lay gjl at gcc dot gnu.org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
--- Comment #15 from Richard Biener rguenth at gcc dot gnu.org ---
(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 law
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
--- Comment #16 from Richard Biener rguenth at gcc dot gnu.org ---
Btw, why is it recording twice a temporary equivalence? Might be simpler even
with
/* Now invalidate all equivalencies we have to invalidate. */
unsigned i;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
--- Comment #17 from Richard Biener rguenth at gcc dot gnu.org ---
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 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
--- Comment #18 from Richard Biener rguenth at gcc dot gnu.org ---
Testing that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
--- Comment #19 from Richard Biener rguenth at gcc dot gnu.org ---
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 burnus at gcc dot gnu.org ---
(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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488
--- Comment #9 from Evgeniya Maenkova evgeniya.maenkova at gmail dot com ---
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 rguenth at gcc dot gnu.org ---
Created attachment 33766
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33766action=edit
non-working patch
Of course this still walks all SSA names (but only once per BB),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #73 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #74 from Oleg Endo olegendo at gcc dot gnu.org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
--- Comment #4 from rguenther at suse dot de 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 burnus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
--- Comment #21 from Richard Biener rguenth at gcc dot gnu.org ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63542
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63563
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Tue Oct 21 12:23:11 2014
New Revision: 216507
URL: https://gcc.gnu.org/viewcvs?rev=216507root=gccview=rev
Log:
PR tree-optimization/63563
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63563
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Tue Oct 21 12:27:25 2014
New Revision: 216508
URL: https://gcc.gnu.org/viewcvs?rev=216508root=gccview=rev
Log:
PR tree-optimization/63563
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63563
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63424
Renlin Li renlin.li at arm dot com changed:
What|Removed |Added
CC||renlin.li at arm dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63223
--- Comment #9 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63223
--- Comment #10 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org ---
Created attachment 33768
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33768action=edit
patch for dtor direction
I have this patch for fixing the direction of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #33 from Stupachenko Evgeny evstupac at gmail dot com ---
Created attachment 33769
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33769action=edit
patch includes 3 patches fixing darwin bootstrap
It looks like data constant LC0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #25 from Yury Gribov y.gribov at samsung dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #34 from Dominique d'Humieres dominiq at lps dot ens.fr ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503
--- Comment #10 from Wilco wdijkstr at arm dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503
--- Comment #11 from Andrew Pinski pinskia at gcc dot gnu.org ---
(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
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 vbraun at physics dot upenn.edu ---
Created attachment 33770
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33770action=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 vbraun at physics dot upenn.edu ---
Created attachment 33773
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33773action=edit
gdb log of the failing testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610
--- Comment #2 from Volker Braun vbraun at physics dot upenn.edu ---
Created attachment 33771
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33771action=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 Keith.S.Thompson at gmail dot com ---
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 e.menezes at samsung dot com ---
Created attachment 33774
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33774action=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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63611
Joseph S. Myers jsm28 at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
Joseph S. Myers jsm28 at gcc dot gnu.org changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org ---
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 PHHargrove at lbl dot gov ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #6 from Keith Thompson Keith.S.Thompson at gmail dot com ---
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;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #7 from joseph at codesourcery dot com 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612
--- Comment #3 from steveren q@rsn-tech.co.uk ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #8 from Keith Thompson Keith.S.Thompson at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #75 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63598
--- Comment #2 from John David Anglin danglin at gcc dot gnu.org ---
If I apply this change
Index: ipa-icf.c
===
--- ipa-icf.c(revision 216524)
+++ ipa-icf.c(working copy)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #9 from joseph at codesourcery dot com 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63595
--- Comment #4 from Pat Haugen pthaugen at gcc dot gnu.org ---
Created attachment 33775
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33775action=edit
unreduced bzip2 testcase
CPU2006 benchmark 447.dealII started segfaulting on PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #10 from Keith Thompson Keith.S.Thompson at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #27 from Daniel Richard G. skunk at iskunk dot org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213
Matheus Izvekov mizvekov at gmail dot com changed:
What|Removed |Added
CC||mizvekov at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213
--- Comment #19 from Matheus Izvekov mizvekov at gmail dot com ---
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.
68 matches
Mail list logo
