https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81389
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81390
Bug ID: 81390
Summary: ICE in to_reg_br_prob_base while compiling kernel
Product: gcc
Version: 8.0
Status: WAITING
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
--- Comment #7 from Yuri Gribov ---
(In reply to Martin Liška from comment #5)
> Apart from that I added code that preserves
> that probability in combine_predictions_for_bb.
Yes, I did pretty much the same locally)
> But still there's a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45708
--- Comment #4 from Jonathan Wakely ---
(In reply to David Krauss from comment #0)
> basic_filebuf (and therefore fstream) does not allow you to put a write
> operation directly after a read operation, or vice versa. Instead, the write
> and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81387
--- Comment #2 from Martin Liška ---
Just for curiosity, I tried to use clang++ 4.0.0 and clang++ pr81387.ii -c -O2
-fsanitize=undefined took me about 180s and memory was ~2.5GB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81391
Bug ID: 81391
Summary: Use of parenthesis disables warning about incorrect
size parameter
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81364
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
--- Comment #6 from Martin Liška ---
Created attachment 41713
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41713=edit
Semi-working patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
--- Comment #5 from Martin Liška ---
Ok, your patch is definitely needed to properly propagate the builtin
probability to a proper edge. Apart from that I added code that preserves that
probability incombine_predictions_for_bb. Having that we're
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81381
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81381
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81387
--- Comment #1 from Jakub Jelinek ---
I'm afraid it is unfixable, if you want smaller memory consumption, you either
need smaller routines, or use -fno-sanitize-recover=all, or do multiple builds
with selected subsets of -fsanitize=undefined, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81362
--- Comment #5 from rdapp at linux dot vnet.ibm.com ---
Ah, npeel is set by vect_peeling_hash_get_lowest_cost although the
corresponding dr is not used afterwards. It should be save to get rid of the
npeel parameter since we use the returned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80855
--- Comment #4 from Tom de Vries ---
Author: vries
Date: Tue Jul 11 07:20:34 2017
New Revision: 250118
URL: https://gcc.gnu.org/viewcvs?rev=250118=gcc=rev
Log:
Backport: Add "sorry, target cannot support label values" for nvptx
2017-07-11 Tom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79939
--- Comment #4 from Tom de Vries ---
Author: vries
Date: Tue Jul 11 07:20:47 2017
New Revision: 250119
URL: https://gcc.gnu.org/viewcvs?rev=250119=gcc=rev
Log:
Backport "Disable constant pool for nvptx"
2017-07-11 Tom de Vries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81388
--- Comment #4 from Nick Terrell ---
Good point Marc.
The generated assembly is wrong because the loop should be run once, but it is
run 2^63 times. Changing the amount dst is incremented by to 4 makes it run
2^62 times, and changing it to 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81388
--- Comment #3 from Marc Glisse ---
(it helps to describe in what way the code is wrong, for instance in a way that
makes the testcase abort)
Apparently ivcanon thinks the number of iterations is constant, as it would be
for the condition dst !=
101 - 118 of 118 matches
Mail list logo
