https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78161
--- Comment #2 from Damian Rouson ---
I could close this because it turned out the failures were my error (I was
using a modified version of the script but thinking I was using the downloaded
version of the script). If it's ok, I'll keep it open
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71902
--- Comment #11 from Thomas Koenig ---
Author: tkoenig
Date: Tue Nov 1 08:12:00 2016
New Revision: 241732
URL: https://gcc.gnu.org/viewcvs?rev=241732&root=gcc&view=rev
Log:
2016-10-31 Thomas Koenig
Backport from trunk
PR for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71902
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70959
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #33 from Richard Earnshaw ---
(In reply to Wilco from comment #32)
> (In reply to Bernd Edlinger from comment #31)
> > Furthermore, if I want to do -Os the third condition is FALSE too.
> > But one ldrd must be shorter than two ldr ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78038
--- Comment #11 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Nov 1 10:29:40 2016
New Revision: 241735
URL: https://gcc.gnu.org/viewcvs?rev=241735&root=gcc&view=rev
Log:
[ree] PR rtl-optimization/78038: Handle global register d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #34 from Bernd Edlinger ---
(In reply to Richard Earnshaw from comment #33)
> (In reply to Wilco from comment #32)
> > (In reply to Bernd Edlinger from comment #31)
> > > Furthermore, if I want to do -Os the third condition is FALSE t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58750
--- Comment #11 from Adam Hirst ---
It's been almost another year, and I just wanted to confirm that this bug is
still present in the following version:
GNU Fortran (GCC) 6.2.1 20160830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58861
--- Comment #5 from Adam Hirst ---
It's been over a year, and I can confirm that this bug is present for all 3
examples in this thread, in the following version:
gcc (GCC) 6.2.1 20160830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #35 from wilco at gcc dot gnu.org ---
(In reply to Richard Earnshaw from comment #30)
> (In reply to wilco from comment #29)
> > Combine could help with
> > merging 2 loads/stores into a single instruction.
>
> No, combine works stri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298
--- Comment #7 from Adam Hirst ---
It's been almost a year, and I wanted to confirm that this bug is still present
for the test case I attached to the thread, and for Janus' reduced example.
Also relevant might be that my comment at 2014-11-12 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #36 from wilco at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #34)
> (In reply to Richard Earnshaw from comment #33)
> > (In reply to Wilco from comment #32)
> > > (In reply to Bernd Edlinger from comment #31)
> > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #37 from Richard Earnshaw ---
(In reply to Bernd Edlinger from comment #34)
> (In reply to Richard Earnshaw from comment #33)
> > The logic is certainly strange. Some cores run LDRD less quickly than they
> > can do LDM, or even two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77933
Thomas Preud'homme changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
Bug ID: 78176
Summary: [MIPS] miscompiles ldxc1 with large pointers on
32-bits
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
James Cowgill changed:
What|Removed |Added
Attachment #39937|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78145
--- Comment #2 from ian at gcc dot gnu.org ---
Author: ian
Date: Tue Nov 1 13:46:10 2016
New Revision: 241740
URL: https://gcc.gnu.org/viewcvs?rev=241740&root=gcc&view=rev
Log:
PR go/78145
compiler: don't put print/println constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78145
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78174
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
Bernd Edlinger changed:
What|Removed |Added
Attachment #39898|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70696
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from Domin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
Bernd Edlinger changed:
What|Removed |Added
Attachment #39939|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #40 from Bernd Edlinger ---
BTW: I found something strange in this pattern in neon.md:
(define_insn_and_split "orndi3_neon"
[(set (match_operand:DI 0 "s_register_operand" "=w,?&r,?&r,?&r")
(ior:DI (not:DI (match_operand:DI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64933
--- Comment #4 from Paul Thomas ---
Created attachment 39941
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39941&action=edit
Draft Patch for the PR
Bootstraps and regtests on FC21/x86_64. This testcase runs fine:
program test_this
impl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #2 from Andrew Pinski ---
I think this code is undefined if you have wrapping pointers. No pointer should
ever be above INT_MAX in user space on mips32 due to the memory layout on
MIPS32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78177
Bug ID: 78177
Summary: adding -flto flags causes linker error "undefined
reference to vtable"
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #3 from James Cowgill ---
As far as I can tell, all the pointers in the original C code are valid and do
not wrap. Some of the registers wrap, but they're not pointers (until added
with other registers).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #41 from wilco at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #40)
> BTW: I found something strange in this pattern in neon.md:
>
> (define_insn_and_split "orndi3_neon"
> [(set (match_operand:DI 0 "s_register_operan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #42 from wilco at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #40)
> BTW: I found something strange in this pattern in neon.md:
>
> (define_insn_and_split "orndi3_neon"
> [(set (match_operand:DI 0 "s_register_operan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78177
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #43 from Bernd Edlinger ---
(In reply to wilco from comment #41)
>
> ARM only uses the 2nd alternative (set_attr "arch" "any,a,t2,t2"), so this
> is correct. There is no need to support this pattern for ARM as ARM doesn't
> have ORN,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69544
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Tue Nov 1 16:18:18 2016
New Revision: 241745
URL: https://gcc.gnu.org/viewcvs?rev=241745&root=gcc&view=rev
Log:
2016-11-01 Thomas Koenig
PR fortran/69544
* match.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78174
--- Comment #6 from Martin Sebor ---
(In reply to Jakub Jelinek from comment #5)
Do you have an explanation of why it's "just incorrect?" or an example where it
results in warning on valid code?
I have found another compiler that issues a warni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69544
--- Comment #6 from Dominique d'Humieres ---
You did not read https://gcc.gnu.org/ml/fortran/2016-11/msg2.html!-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #44 from wilco at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #38)
> Created attachment 39939 [details]
> proposed patch, v2
>
> Unlike the previous patch, thumb1 stack usage stays at 1588 bytes,
> because thumb1 can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71796
--- Comment #4 from Dominique d'Humieres ---
> If you want a test case that exhibits no run time error upon successful
> compilation and linking, then replace the entire main program with an
> END statement.
I am using that for years and was not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78174
--- Comment #7 from Jakub Jelinek ---
(In reply to Martin Sebor from comment #6)
> (In reply to Jakub Jelinek from comment #5)
>
> Do you have an explanation of why it's "just incorrect?" or an example where
> it results in warning on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #46 from Richard Earnshaw ---
(In reply to wilco from comment #44)
> (In reply to Bernd Edlinger from comment #38)
> > Created attachment 39939 [details]
> > proposed patch, v2
> >
>
> > Unlike the previous patch, thumb1 stack usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #45 from Bernd Edlinger ---
(In reply to wilco from comment #44)
> (In reply to Bernd Edlinger from comment #38)
> > Created attachment 39939 [details]
> > proposed patch, v2
> >
>
> > Unlike the previous patch, thumb1 stack usage s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78178
Bug ID: 78178
Summary: ICE in WHERE statement with diagnostic
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78118
--- Comment #4 from jcmvbkbc at gcc dot gnu.org ---
Author: jcmvbkbc
Date: Tue Nov 1 17:16:33 2016
New Revision: 241748
URL: https://gcc.gnu.org/viewcvs?rev=241748&root=gcc&view=rev
Log:
xtensa: Fix PR target/78118
It started failing after the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #47 from wilco at gcc dot gnu.org ---
(In reply to Richard Earnshaw from comment #46)
> (In reply to wilco from comment #44)
> > (In reply to Bernd Edlinger from comment #38)
> > > Created attachment 39939 [details]
> > > proposed patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78166
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78166
--- Comment #6 from dave.anglin at bell dot net ---
On 2016-11-01, at 1:22 PM, law at redhat dot com wrote:
> #1 is easy and John has a patch for that. I've prototyped #3, but don't
> really
> like it. I think going with #1 on the trunk and ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319
--- Comment #10 from Tim Rentsch ---
I would like to add a few comments to the discussion.
One: C and C++ are different in how they treat unions. My comments
here are about C. I believe they apply to C++ as well, but I am not
as familiar with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78178
--- Comment #1 from Thomas Koenig ---
> What on earth is going on there I don't know. I think I will
> build from a clean tree and retry, and in the meantime fix
That should be PR 69544, of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78118
jcmvbkbc at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78166
--- Comment #7 from John David Anglin ---
Author: danglin
Date: Tue Nov 1 18:15:57 2016
New Revision: 241749
URL: https://gcc.gnu.org/viewcvs?rev=241749&root=gcc&view=rev
Log:
PR target/78166
* config/pa/pa.md: Add new shift/add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
Tim Rentsch changed:
What|Removed |Added
CC||txr at alumni dot caltech.edu
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78166
--- Comment #8 from John David Anglin ---
Author: danglin
Date: Tue Nov 1 18:17:58 2016
New Revision: 241750
URL: https://gcc.gnu.org/viewcvs?rev=241750&root=gcc&view=rev
Log:
PR target/78166
* config/pa/pa.md: Add new shift/add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78166
John David Anglin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78179
Bug ID: 78179
Summary: FAIL: 26_numerics/headers/cmath/hypot.cc execution
test
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #19 from joseph at codesourcery dot com ---
On Tue, 1 Nov 2016, txr at alumni dot caltech.edu wrote:
> Five: The answer to the question is clearly No. The example code
> is very much on point to the "one special guarantee" clause,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #20 from rguenther at suse dot de ---
On November 1, 2016 7:16:06 PM GMT+01:00, "txr at alumni dot caltech.edu"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
>
>Tim Rentsch changed:
>
> What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #6 from Andres Freund ---
Hi,
Can confirm this patch fixes the specific code generation issue I
complained about, leading to an overall 1.9% improvement in TPC-H
performance. There's still some counterproductive jumps, but they're
u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #7 from Markus Trippelsdorf ---
BTW Firefox trunk fails to build for me:
ld: error: /tmp/ccsbLieS.ltrans29.ltrans.o: requires dynamic R_X86_64_PC32
reloc against '_ZN2js3jitL2R0E' which may overflow at runtime; recompile with
-fPIC
l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78152
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78152
--- Comment #5 from Steve Kargl ---
On Tue, Nov 01, 2016 at 08:32:46PM +, pault at gcc dot gnu.org wrote:
> >
> > Someone needs to submit an interpretation request to J3.
>
>
> If you bypass the error for associate names, does such code ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78180
Bug ID: 78180
Summary: Poor optimization of std::array on gcc 4.8/5.4/6.2 as
compared to simple raw array
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69544
--- Comment #7 from Thomas Koenig ---
Author: tkoenig
Date: Tue Nov 1 21:16:46 2016
New Revision: 241756
URL: https://gcc.gnu.org/viewcvs?rev=241756&root=gcc&view=rev
Log:
2016-11-01 Thomas Koenig
PR fortran/78178
* match.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78178
--- Comment #2 from Thomas Koenig ---
Author: tkoenig
Date: Tue Nov 1 21:16:46 2016
New Revision: 241756
URL: https://gcc.gnu.org/viewcvs?rev=241756&root=gcc&view=rev
Log:
2016-11-01 Thomas Koenig
PR fortran/78178
* match.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78180
--- Comment #1 from Barry Revzin ---
Upon further investigation, all of the difference is in benchmark comes from
the initialization of the raw array versus std::array. For some reason, in the
two examples, the two containers are initialized diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69332
John David Anglin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68735
--- Comment #1 from John David Anglin ---
*** Bug 69332 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78152
--- Comment #6 from jvdelisle at charter dot net ---
On 11/01/2016 01:45 PM, sgk at troutmask dot apl.washington.edu wrote:
--- snip ---
> Fortunately, I use FreeBSD as my operating system, which
> unfortunately limits me to gfortran. I posted t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78152
--- Comment #7 from Steve Kargl ---
On Tue, Nov 01, 2016 at 11:06:30PM +, jvdelisle at charter dot net wrote:
>
> I had a meeting with Damian Rousan today and we briefly talked about
> OpenCoarrays. He has mentioned on the gfortran list ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69288
Casey Carter changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78174
--- Comment #8 from Martin Sebor ---
Okay, thanks. Your comments seem to be focused on my patch and not so much on
this problem that was exposed by it. I realize I invited those comments with
my response and do want to continue to have that dis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168
--- Comment #11 from Sebastian Huber ---
(In reply to Segher Boessenkool from comment #10)
> Doesn't fail with powerpc-rtems4.12 either. Are you sure you built trunk?
> A clean build?
I tested again today using:
commit 89bcfdabe78607bf83aa58e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70696
--- Comment #5 from Damian Rouson ---
Hmm... I wouldn't be surprised if the root cause is the same or closely
related, but given that lock_type and event_type are not the same, I don't see
one as the duplicate of the other.
71 matches
Mail list logo
