https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65036
Bug ID: 65036
Summary: [5 Regression] ICE (RTL flag check) on
arm-linux-gnueabihf
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55342
Jeffrey A. Law changed:
What|Removed |Added
Summary|[4.8/4.9/5 Regression] |[4.8/4.9 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65033
--- Comment #1 from Andrew Pinski ---
Aren't pointers in this case lock free?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65035
Bug ID: 65035
Summary: [5 Regression] ICE (segfault) on arm-linux-gnueabihf
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #10 from Dominik Vogt ---
As far as I understand, the code in libbacktrace was originally only intended
for handling exceptions, not for generating stack traces? For the former, the
code is fine. But given a function's return addres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65016
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65034
Bug ID: 65034
Summary: [5 Regression] ICE (segfault) on arm-linux-gnueabihf
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65033
Bug ID: 65033
Summary: C++11 atomics: is_lock_free result does not always
match the real lock-free property
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
Andrew Pinski changed:
What|Removed |Added
CC||msebor at gmail dot com
--- Comment #9 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65029
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
Jeffrey A. Law changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65032
Bug ID: 65032
Summary: [5 Regression] ICE in reload_combine_note_use, at
postreload.c:1556 on i686-linux-gnu
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Sever
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
build failure in openjade, with 20150205 and 20150211, configured
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
$ g++ -g -fpermissive -O2 -c -fPIC GroveBuilder.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57822
--- Comment #11 from Jerry DeLisle ---
Author: jvdelisle
Date: Thu Feb 12 03:52:45 2015
New Revision: 220637
URL: https://gcc.gnu.org/viewcvs?rev=220637&root=gcc&view=rev
Log:
2015-02-11 Jerry DeLisle
PR libgfortran/57822
* gfortran/
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
build failure in libffado, seen with 20150205 and 20150211 on
arm-linux-gnueabihf, configured --with-arch=armv7-a --with-fpu=vfpv3-d16
--with-float=hard --with-mode=thumb
g++ -c -g -O2 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65029
Bug ID: 65029
Summary: aggregate copy invokes memcpy on overlapping regions
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63492
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63492
--- Comment #4 from baoshan ---
This bug was filed by mistake, please help to close it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65025
--- Comment #5 from Fred Krogh ---
I realize (now) that this is not a valid Fortran code. I was trying to hard to
make it work like it works in C. Removing the apostrophes around the s, d, and
q, in both the code and on the command line, and al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61628
--- Comment #22 from Jerry DeLisle ---
Arjen, any further results or information on this bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64930
--- Comment #9 from Alan Modra ---
My point was that if you write a testcase that specifically tests for consume
and get acquire code then that is a fail. The code generated is using a bigger
hammer than necessary. Imagine for a moment if gcc p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35406
Jerry DeLisle changed:
What|Removed |Added
Status|REOPENED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
--- Comment #15 from Jeffrey A. Law ---
Author: law
Date: Wed Feb 11 23:29:11 2015
New Revision: 220632
URL: https://gcc.gnu.org/viewcvs?rev=220632&root=gcc&view=rev
Log:
PR target/63347
* haifa-sched.c (prune_ready_list): If we have a S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65025
--- Comment #4 from Fred Krogh ---
In collapsing a big code to the small example, I left out a line that should be
there. Add below the first line
use ISO_C_BINDING, only: C_DOUBLE, C_FLOAT, C_LONG_DOUBLE
This has no effect however on the in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64930
--- Comment #8 from Jakub Jelinek ---
Well, it does support it, but as an alias to acquire.
Keeping the test FAILing is just wrong, and if the promotion of consume to
acquire is going to be permanent or at least for a couple of years, xfail
doesn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64930
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64930
--- Comment #6 from Jakub Jelinek ---
Plus xfailing the isync count test would mean we don't test isync count at all,
even for all the other constructs in the testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60563
--- Comment #11 from howarth at bromo dot med.uc.edu ---
(In reply to howarth from comment #10)
> (In reply to Iain Sandoe from comment #9)
> > sadly, this seems to be a ld64 bug - present when using uncompressed EH
> > (which is the default for G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65020
Jiong Wang changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65024
--- Comment #3 from homgran ---
Interesting... I've just tested Janus' reduced/modified version with "GNU
Fortran (GCC) 4.8.1 20130404 (prerelease)", and it does indeed compile cleanly.
However, my sample code ('test.f90', attached to the origina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64927
--- Comment #9 from Harald Anlauf ---
(In reply to Steve Kargl from comment #7)
> On Wed, Feb 11, 2015 at 07:31:50PM +, anlauf at gmx dot de wrote:
> >
> > IMO it is not fixed on 4.8. If there is no easy solution, I'd rather
> > prefer to m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
Jan Hubicka changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968
--- Comment #7 from Frédéric Buclin ---
Created attachment 34736
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34736&action=edit
GCC extension for 5.0, v1
This is exactly the same GCC extension as for 4.4.5. So far, it seems to work
fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968
--- Comment #6 from Frédéric Buclin ---
Created attachment 34735
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34735&action=edit
GCC patch for 5.0, v1
No code changes compared to 4.4, but the patch for 4.4 didn't apply cleanly to
5.0 due
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64927
--- Comment #8 from Harald Anlauf ---
(In reply to Dominique d'Humieres from comment #6)
> > The revision numbers you refer to belong to the 4.9-branch.
>
> Indeed -> I was trying to find the commit that fixed the problem (without
> success).
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65006
H.J. Lu changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
Bug ID: 65028
Summary: [5 Regression] 450.soplex in SPEC CPU 2006 is
miscompiled
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64930
--- Comment #5 from torvald at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 34731 [details]
> gcc5-pr64930.patch
>
> Thus I'm proposing this untested patch.
I think expecting the consume-to-acquire promoti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65024
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64927
--- Comment #7 from Steve Kargl ---
On Wed, Feb 11, 2015 at 07:31:50PM +, anlauf at gmx dot de wrote:
>
> IMO it is not fixed on 4.8. If there is no easy solution, I'd rather
> prefer to mark it in an appropriate way (wontfix?), so that oth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553
--- Comment #7 from paul.richard.thomas at gmail dot com ---
For sure. Please do.
Thanks
Paul
On 11 February 2015 at 18:25, dominiq at lps dot ens.fr
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553
>
> Dominique d'Humieres change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65027
Bug ID: 65027
Summary: failure to emit diagnostic when optimizing using
undefined behaviour
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65025
--- Comment #3 from Dominique d'Humieres ---
> Maybe this time the code will get there?
The code was there in this PR, but not in 65026.
#if plet_=='s'
#define ckind__ C_FLOAT
#elif plet_=='q'
#define ckind__ C_LONG_DOUBLE
#elif plet_=='d'
#d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64927
--- Comment #6 from Dominique d'Humieres ---
> The revision numbers you refer to belong to the 4.9-branch.
Indeed -> I was trying to find the commit that fixed the problem (without
success).
> IMO it is not fixed on 4.8. If there is no easy sol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57822
--- Comment #10 from Jerry DeLisle ---
(In reply to Dominique d'Humieres from comment #9)
> > I am afraid that the test will fail on targets without REAL(10).
>
> see https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00698.html and e.g.,
> https://g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64927
--- Comment #5 from Harald Anlauf ---
(In reply to Dominique d'Humieres from comment #4)
> This PR has been fixed between r197969 (2013-04-15, warning) and r198189
> (2013-04-23, no warning). I did not find any obvious commit for the change.
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65006
--- Comment #9 from H.J. Lu ---
(In reply to Jan Hubicka from comment #8)
> EON seems fine now.
> https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01280.html
> I do ont see the sphinx failure in the ML. Is it fixed?
This run doesn't use LTO. L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65025
--- Comment #2 from Fred Krogh ---
Created attachment 34734
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34734&action=edit
The small test program that shows the error.
Maybe this time the code will get there?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65006
Jan Hubicka changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #8 from Jan Hubicka -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
Jeffrey A. Law changed:
What|Removed |Added
Assignee|bernds at codesourcery dot com |law at redhat dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65025
--- Comment #1 from Dominique d'Humieres ---
*** Bug 65026 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65026
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65026
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64930
James Greenhalgh changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65026
--- Comment #1 from Fred Krogh ---
The first test.F90 I attached had some extra '=' signs in the #defines. I have
tried to replace that test.F90 with a corrected version which gets the same
error. I'm not clear if this replacement was successfu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65026
Bug ID: 65026
Summary: Internal compiler error with preprocessor in gfortran
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65024
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65025
Bug ID: 65025
Summary: Internal compiler error with preprocessor in gfortran
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65024
Bug ID: 65024
Summary: Internal compiler error (gfortran) concerning
unlimited polymorphic pointer
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #9 from Ian Lance Taylor ---
I think that libbacktrace is doing more or less the right thing. If we don't
subtract one from pc there, we have no way to convey signal handler frames
correctly. Also, the resulting PC value is in the i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64930
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65006
--- Comment #7 from Jan Hubicka ---
What is the status of those ices after fix to PR65006?
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65022
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65022
Jonathan Wakely changed:
What|Removed |Added
Severity|critical|normal
--- Comment #1 from Jonathan Wa
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Created attachment 34730
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34730&action=edit
C source code
The attached code does the following with trunk dated 20150211 with
flag -O2
$ valgrind --suppr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62298
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64930
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65000
Richard Henderson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Domin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65022
Bug ID: 65022
Summary: basic_string operator
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: libstdc++
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64692
--- Comment #5 from Dominique d'Humieres ---
> ... we are expecting to see:
>
> array 1 3.4.
> array 2 3.4.
>
> right?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65000
--- Comment #12 from Richard Henderson ---
Author: rth
Date: Wed Feb 11 17:04:38 2015
New Revision: 220626
URL: https://gcc.gnu.org/viewcvs?rev=220626&root=gcc&view=rev
Log:
PR sanitize/65000
* tree-eh.c (mark_reachable_handlers): Mark source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64692
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60289
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65017
--- Comment #6 from David Binderman ---
(In reply to Richard Biener from comment #5)
> Can't reproduce when building GCC with clang 3.3 like you specified above.
I removed clang from the configure of gcc, rebuilt gcc, tried again
and the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #34 from Zack Weinberg ---
> As I tried to explain, it is currently design decision to have one declaration
> and one symtam node for one symbol. The one decl rule was introduced by
> Codesourcery (Zack) in 2003-4. He updated fronten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65019
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |5.0
Summary|Compare debug fai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968
--- Comment #5 from Frank Ch. Eigler ---
The current .git repos are there as a backup.
I'll move them out of the way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64835
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65019
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64837
--- Comment #18 from Markus Trippelsdorf ---
(In reply to H.J. Lu from comment #17)
> (In reply to Markus Trippelsdorf from comment #16)
> > (In reply to H.J. Lu from comment #15)
> > > (In reply to Markus Trippelsdorf from comment #14)
> > > > W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64837
--- Comment #17 from H.J. Lu ---
(In reply to Markus Trippelsdorf from comment #16)
> (In reply to H.J. Lu from comment #15)
> > (In reply to Markus Trippelsdorf from comment #14)
> > > Well, at least your patch survives a Firefox LTO build using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64837
--- Comment #16 from Markus Trippelsdorf ---
(In reply to H.J. Lu from comment #15)
> (In reply to Markus Trippelsdorf from comment #14)
> > Well, at least your patch survives a Firefox LTO build using gold
> > on a ppc64 test machine.
>
> Does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64837
--- Comment #15 from H.J. Lu ---
(In reply to Markus Trippelsdorf from comment #14)
> Well, at least your patch survives a Firefox LTO build using gold
> on a ppc64 test machine.
Does it build without my patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64837
--- Comment #14 from Markus Trippelsdorf ---
Well, at least your patch survives a Firefox LTO build using gold
on a ppc64 test machine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65021
Bug ID: 65021
Summary: nvptx mkoffload doesn't clean up its temporary files
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: openacc, openmp
Severity: major
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65003
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65003
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Wed Feb 11 15:09:48 2015
New Revision: 220625
URL: https://gcc.gnu.org/viewcvs?rev=220625&root=gcc&view=rev
Log:
PR middle-end/65003
* varasm.c (place_block_symbol): Assert that D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65017
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #5 from Richard Bie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718
Bernd Edlinger changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64824
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Wed Feb 11 14:48:41 2015
New Revision: 220624
URL: https://gcc.gnu.org/viewcvs?rev=220624&root=gcc&view=rev
Log:
PR c/64824
* c-parser.c (c_parser_binary_expression): Fix OpenMP s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #23 from Domi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65020
--- Comment #2 from Jiong Wang ---
(In reply to Maxim Kuvyrkov from comment #1)
> Do you have 770c9167327b3c20b718dae5062d57a052316a78 / 220316 applied?
>
> That patch is not a complete fix (see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64979
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Wed Feb 11 14:45:26 2015
New Revision: 220623
URL: https://gcc.gnu.org/viewcvs?rev=220623&root=gcc&view=rev
Log:
Backported from mainline
2015-02-09 Jakub Jelinek
PR targe
1 - 100 of 181 matches
Mail list logo
