http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55907
--- Comment #12 from janus at gcc dot gnu.org ---
Author: janus
Date: Thu Feb 20 08:00:48 2014
New Revision: 207935
URL: http://gcc.gnu.org/viewcvs?rev=207935&root=gcc&view=rev
Log:
2014-02-20 Janus Weil
Backport from mainline
2014-02-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55907
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60281
Bug ID: 60281
Summary: Address Sanitizer triggers alignment fault in ARM
machines
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60281
--- Comment #1 from linzj ---
I have summit a patch for this bug,and tested in my Nexus 4.It works fine.Check
gcc-patches at gcc dot gnu dot org for that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60282
Bug ID: 60282
Summary: memory leak - Double from string, _Jv_Balloc
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60283
Bug ID: 60283
Summary: Wrong code: decode_omp_directive: implicit_pure not
correctly unset
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261
--- Comment #8 from Richard Biener ---
Author: rguenth
Date: Thu Feb 20 08:43:04 2014
New Revision: 207936
URL: http://gcc.gnu.org/viewcvs?rev=207936&root=gcc&view=rev
Log:
2014-02-20 Richard Biener
PR libjava/60261
* configure.ac (db
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
David Krauss changed:
What|Removed |Added
CC||potswa at mac dot com
--- Comment #17 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60285
Bug ID: 60285
Summary: std::list::insert(position, x) does not accept
const_iterator position
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284
Bug ID: 60284
Summary: Default-initialization without user-provided
constructor allowed
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60285
--- Comment #1 from Petr Kmoch ---
Created attachment 32177
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32177&action=edit
gcc -v output when building test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60046
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60286
Bug ID: 60286
Summary: INQUIRE reports STDOUT as not writable
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60221
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Thu Feb 20 09:00:23 2014
New Revision: 207937
URL: http://gcc.gnu.org/viewcvs?rev=207937&root=gcc&view=rev
Log:
2014-02-20 Richard Biener
PR middle-end/60221
* tree-eh.c (ex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60287
Bug ID: 60287
Summary: Various issues on -Wformat=
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #14 from Uroš Bizjak ---
I have found where corruption of const_int_rtx array happens.
1. Put breakpoint on gen_rtx_CONST_INT to determine address of
const_int_rtx[24], a.k.a (const_int -40) and put HW watchpoint on its address:
Brea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #15 from Jakub Jelinek ---
I'll have a look (unless you want to continue poking).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60285
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60288
Bug ID: 60288
Summary: gccgo crashes compiling '*func_ptr(0)'
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #16 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #15)
> I'll have a look (unless you want to continue poking).
According to ChangeLogs, you have much more experience in this part, so I would
be much grateful if you can
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60286
--- Comment #1 from Alexander Vogt ---
I just found out that the same holds true for STDERR...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #17 from Uroš Bizjak ---
Somehow we get old_size = 0 in gen_reg_rtx. It is calculated as:
int old_size = crtl->emit.regno_pointer_align_length;
Trivial patch that prevents this situation and fixes the problem. However, it
is no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60287
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
--- Comment #13 from rguenther at suse dot de ---
On Wed, 19 Feb 2014, steven at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
>
> Steven Bosscher changed:
>
>What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60286
Tobias Burnus changed:
What|Removed |Added
Keywords||wrong-code
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #18 from Uroš Bizjak ---
And finally, it looks that expand_vector_operations doesn't call init_emit ().
Backtrace:
Breakpoint 1, gen_reg_rtx (mode=V4SImode) at
../../gcc-svn/branches/gcc-4_8-branch/gcc/emit-rtl.c:864
864 unsign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60280
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone|-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
Jakub Jelinek changed:
What|Removed |Added
Component|middle-end |target
--- Comment #19 from Jakub Jelinek
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #20 from Jakub Jelinek ---
So, from quick skim of relevant routines that do gen_reg_rtx, I see:
gen_reg_rtx called only after if (d->testing_p) return true;, thus ok:
expand_vec_perm_blend
expand_vec_perm_pshufb
expand_vec_perm_palign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #21 from Uroš Bizjak ---
--cut here--
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 207935)
+++ config/i386/i386.c (working copy)
@@ -40666,9 +40666,9 @
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60280
--- Comment #3 from bin.cheng ---
I think 4_8 is ok for this case. At least it doesn't have
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01530.html committed if I was
right.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60289
Bug ID: 60289
Summary: allocating class(*) pointer as character gives
type-spec requires the same character-length parameter
Product: gcc
Version: 4.9.0
Status: UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60288
--- Comment #1 from Dominik Vogt ---
> So it looks like gccgo reads the expression as
>
> (*pg)(0)
I meant
-> (*(&g))(0)
> while golang reads it as
>
> *(pg(0))
-> *(&(g(0)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #22 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #21)
> --- config/i386/i386.c (revision 207935)
> +++ config/i386/i386.c (working copy)
> @@ -40666,9 +40666,9 @@ ix86_vectorize_vec_perm_const_ok (enum machine_mod
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #23 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #22)
> IMHO that is way too expensive.
Agreed.
Anyway, it looks you got this problem under control ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60236
--- Comment #7 from Dominique d'Humieres ---
> This patch tries to solve the problem in a more general way.
> I wonder if one of you could try this patch on PowerPC?
Sorry for the late answer, but my G5 was buzzy regtesting. With the patch in
com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
Uroš Bizjak changed:
What|Removed |Added
Target||x86
Target Milestone|4.8.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60289
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
Statu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #25 from Jakub Jelinek ---
Created attachment 32180
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32180&action=edit
gcc48-pr57896.patch
So like this (4.8 version, untested)? Uros, can you please double-check it?
The point is, i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Known to work|4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60268
--- Comment #4 from Andrey Belevantsev ---
(In reply to Jakub Jelinek from comment #2)
I forgot the single block regions case, so the nr_regions_initial init should
be moved to the bottom of sched_rgn_init.
The check before free_global_sched_pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60289
--- Comment #2 from janus at gcc dot gnu.org ---
The error can easily be silenced with this patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 207896)
+++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276
--- Comment #4 from Richard Biener ---
extern void abort (void);
static void
foo (short *out, const short *lp, const short *hp, unsigned samples)
{
int x, target;
for (x = 0, target = 0; x < (int)samples; x += 2, target++)
{
out[x +
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #26 from Jakub Jelinek ---
Created attachment 32181
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32181&action=edit
gcc49-pr57896.patch
Corresponding 4.9 version, which is somewhat different due to my? changes not
to emit subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60287
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
Manuel López-Ibáñez changed:
What|Removed |Added
CC||chengniansun at gmail dot com
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from Dominique d'Humieres ---
>> What should we do about this test? Having it fail everywhere a current
>> binutils
>> version is used causes lots of noise in testsuit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #27 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #25)
> Created attachment 32180 [details]
> gcc48-pr57896.patch
>
> So like this (4.8 version, untested)? Uros, can you please double-check it?
> The point is, if d->te
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276
--- Comment #5 from Richard Biener ---
And with less convoluted vectorized code but still broken (avoids integer
promotions):
extern void abort (void);
static void
foo (int *out, const int *lp, const int *hp, unsigned samples)
{
int x, target;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276
--- Comment #6 from Richard Biener ---
But you can clearly see that this isn't valid vectorization because of the
read-after-write dependence of out[x].
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60290
Bug ID: 60290
Summary: 32-bit g++.dg/cilk-plus/CK/catch_exc.cc FAILs on
Solaris/x86
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60290
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276
--- Comment #7 from Richard Biener ---
(In reply to Richard Biener from comment #6)
> But you can clearly see that this isn't valid vectorization because of the
> read-after-write dependence of out[x].
Well, only after unrolling which happens her
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #28 from Jakub Jelinek ---
Perhaps just make it gcc_checking_assert?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276
--- Comment #8 from Marek Polacek ---
Note that in r196871 this was broken, but r196872 is fine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #29 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #28)
> Perhaps just make it gcc_checking_assert?
On release branches perhaps, but the consequences of
crtl->emit.regno_pointer_align_length == 0 warrant ICE even in the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60268
--- Comment #5 from Jakub Jelinek ---
If this works, fine with me, but I'll defer the review to Vladimir.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60290
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60204
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60290
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jakub Jelinek ---
> Even with the r207623 fix?
Yes, this is from the latest r207783 bootstraps.
Rainer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55260
--- Comment #14 from Martin Jambor ---
Author: jamborm
Date: Thu Feb 20 13:28:34 2014
New Revision: 207941
URL: http://gcc.gnu.org/viewcvs?rev=207941&root=gcc&view=rev
Log:
2014-02-20 Martin Jambor
PR ipa/55260
* ipa-cp.c (cgraph_edge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59431
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Ian Lance Taylor ---
> Yeah, I didn't think that would fix this problem, I was just hoping for more
> consistent error messages--e.g., "out of memory" rather than "c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60291
Bug ID: 60291
Summary: slow compile times for any mode (-O0/-O1/-O2) on large
.c source file (30MBs)
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637
--- Comment #15 from Rainer Orth ---
Author: ro
Date: Thu Feb 20 14:04:53 2014
New Revision: 207951
URL: http://gcc.gnu.org/viewcvs?rev=207951&root=gcc&view=rev
Log:
XFAIL sourcelocation (PR libgcj/55637)
PR libgcj/55637
* testsuite/libj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60291
--- Comment #1 from Sergei Trofimovich ---
For -ftime-report -O1 most highlighting lines are:
phase opt and generate : 175.81 (98%) usr 4.61 (51%) sys 180.95 (95%) wall
1833542 kB (86%) ggc
expand : 20.05 (11%) usr 0.71 (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58835
--- Comment #1 from Kai Tietz ---
Author: ktietz
Date: Thu Feb 20 14:28:16 2014
New Revision: 207955
URL: http://gcc.gnu.org/viewcvs?rev=207955&root=gcc&view=rev
Log:
PR c++/58835
* semantics.c (finish_fname): Handle error_mark_node.
Mo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58835
--- Comment #2 from Kai Tietz ---
Author: ktietz
Date: Thu Feb 20 14:29:55 2014
New Revision: 207956
URL: http://gcc.gnu.org/viewcvs?rev=207956&root=gcc&view=rev
Log:
PR c++/58835
* semantics.c (finish_fname): Handle error_mark_node.
Mo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60291
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58835
--- Comment #3 from Kai Tietz ---
Author: ktietz
Date: Thu Feb 20 14:31:01 2014
New Revision: 207957
URL: http://gcc.gnu.org/viewcvs?rev=207957&root=gcc&view=rev
Log:
PR c++/58835
* semantics.c (finish_fname): Handle error_mark_node.
Mo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58835
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60271
--- Comment #1 from Marc Glisse ---
In my opinion, the sensible thing to do is add constexpr to max_element (and
the __ops helpers) once the front-end supports it, not duplicate the code in
max(initializer_list). Well, since max_element is just on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60271
--- Comment #2 from Jonathan Wakely ---
The same thought occurred to me, but I didn't file an issue.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #26 from Kai Tietz ---
ICE was resolved for x86_64.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60288
--- Comment #2 from Ian Lance Taylor ---
I don't think there is any parsing issue with the omitted error on line 5.
It's just that gccgo converts *&x to x for any x, and forgets to test that x
must be addressable.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60291
--- Comment #3 from Markus Trippelsdorf ---
Perf shows:
24.26% cc1 cc1 [.] bitmap_set_bit(bitmap_head*, int)
20.88% cc1 cc1 [.] mark_all_vars_used_1(tree_node**, int*, void*)
14.18% cc1 cc1 [.] operand_equal_p(tree_node const*, tree_n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60271
--- Comment #3 from Jonathan Wakely ---
Even if max_element() isn't made constexpr, we can make __max_element constexpr
(once the FE supports it) and use it directly in max.
It's certainly solvable, I just wanted to create this PR so we don't for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276
--- Comment #9 from Richard Biener ---
Created attachment 32183
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32183&action=edit
patch
Patch I am testing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60288
--- Comment #3 from ian at gcc dot gnu.org ---
Author: ian
Date: Thu Feb 20 15:20:26 2014
New Revision: 207960
URL: http://gcc.gnu.org/viewcvs?rev=207960&root=gcc&view=rev
Log:
PR go/60288
compiler: Avoid crash, give error for *&x when x is n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60288
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60291
Richard Biener changed:
What|Removed |Added
Keywords||compile-time-hog
Status|UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55260
Markus Trippelsdorf changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60291
--- Comment #5 from Richard Biener ---
remove_unused_locals is called from at least cfgcleanup-post-optimizing at -O0.
At -O0 I have (trunk)
expand : 481.98 (94%) usr 1.15 (17%) sys 481.94 (93%) wall
293891 kB (15%) ggc
TOT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55260
--- Comment #16 from Martin Jambor ---
Not yet on the 4.8 branch, but I'm re-running the tests there now and hopefully
will commit it also there today or tomorrow.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55260
--- Comment #17 from Markus Trippelsdorf ---
(In reply to Martin Jambor from comment #16)
> Not yet on the 4.8 branch, but I'm re-running the tests there now and
> hopefully will commit it also there today or tomorrow.
Ah, sorry.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60291
--- Comment #6 from Richard Biener ---
For reference (in testing)
Index: gcc/tree-ssa-live.c
===
--- gcc/tree-ssa-live.c (revision 207960)
+++ gcc/tree-ssa-live.c (working copy)
@@ -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58873
--- Comment #3 from Kai Tietz ---
Author: ktietz
Date: Thu Feb 20 16:02:24 2014
New Revision: 207961
URL: http://gcc.gnu.org/viewcvs?rev=207961&root=gcc&view=rev
Log:
PR c++/58873
* parser.c (cp_parser_functional_cast): Treat NULL_TREE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58873
--- Comment #4 from Kai Tietz ---
Author: ktietz
Date: Thu Feb 20 16:03:38 2014
New Revision: 207962
URL: http://gcc.gnu.org/viewcvs?rev=207962&root=gcc&view=rev
Log:
PR c++/58873
* parser.c (cp_parser_functional_cast): Treat NULL_TREE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58873
--- Comment #5 from Kai Tietz ---
Author: ktietz
Date: Thu Feb 20 16:04:37 2014
New Revision: 207963
URL: http://gcc.gnu.org/viewcvs?rev=207963&root=gcc&view=rev
Log:
PR c++/58873
* parser.c (cp_parser_functional_cast): Treat NULL_TREE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58873
Kai Tietz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60271
--- Comment #4 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #2)
> The same thought occurred to me, but I didn't file an issue.
Should I do it, or are you going to?
(In reply to Jonathan Wakely from comment #3)
> It's certainly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60291
--- Comment #7 from Markus Trippelsdorf ---
(In reply to Richard Biener from comment #6)
> For reference (in testing)
Looks promising:
Without LTO: 2:27.39 total
WithLTO: 35.485 total (60% faster than clang)
> throwing that to callgrind n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56490
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #30 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #25)
> Created attachment 32180 [details]
> gcc48-pr57896.patch
>
> So like this (4.8 version, untested)? Uros, can you please double-check it?
> The point is, if d->te
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60292
Bug ID: 60292
Summary: [4.9 Regression] ICE: in fill_vec_av_set, at
sel-sched.c:3863 with -m64 after r206174 on
powerpc-apple-darwin9.8.0
Product: gcc
Version: 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60272
--- Comment #4 from Richard Henderson ---
Author: rth
Date: Thu Feb 20 17:43:53 2014
New Revision: 207966
URL: http://gcc.gnu.org/viewcvs?rev=207966&root=gcc&view=rev
Log:
PR c++/60272
gcc/
* builtins.c (expand_builtin_atomic_compare_exchang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60271
--- Comment #5 from Jonathan Wakely ---
(In reply to Marc Glisse from comment #4)
> (In reply to Jonathan Wakely from comment #2)
> > The same thought occurred to me, but I didn't file an issue.
>
> Should I do it, or are you going to?
Please go
1 - 100 of 147 matches
Mail list logo
