https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
--- Comment #13 from Segher Boessenkool ---
Fixed on trunk. The comment 9 and comment 10 patches probably should be
backported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85755
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85755
--- Comment #2 from Segher Boessenkool ---
That is, that GCC 8 did not do pre-increment, but it did no silliness
with float registers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85755
--- Comment #3 from Segher Boessenkool ---
Sigh, i forgot -mcpu=power8 on that last test.
GCC 7 was just fine, stdu, everything.
GCC 8 was bad already.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85755
Segher Boessenkool changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85755
--- Comment #8 from Segher Boessenkool ---
Author: segher
Date: Mon Jun 11 15:48:48 2018
New Revision: 261435
URL: https://gcc.gnu.org/viewcvs?rev=261435&root=gcc&view=rev
Log:
rs6000: Put constraints on the correct operand in movdi (PR85755)
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85755
--- Comment #9 from Segher Boessenkool ---
Author: segher
Date: Mon Jun 11 16:06:49 2018
New Revision: 261436
URL: https://gcc.gnu.org/viewcvs?rev=261436&root=gcc&view=rev
Log:
Backport from trunk
2018-06-11 Segher Boessenkool
||2018-06-18
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Segher Boessenkool ---
Confirmed. Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86197
--- Comment #3 from Segher Boessenkool ---
Author: segher
Date: Tue Jun 19 10:52:39 2018
New Revision: 261738
URL: https://gcc.gnu.org/viewcvs?rev=261738&root=gcc&view=rev
Log:
rs6000: Fix vector homogeneous aggregates (PR86197)
The existing co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86197
--- Comment #4 from Segher Boessenkool ---
Author: segher
Date: Mon Jun 25 11:31:45 2018
New Revision: 262010
URL: https://gcc.gnu.org/viewcvs?rev=262010&root=gcc&view=rev
Log:
rs6000: Fix vector homogeneous aggregates (PR86197)
The existing co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82625
--- Comment #3 from Segher Boessenkool ---
Author: segher
Date: Tue Jun 26 15:16:58 2018
New Revision: 262152
URL: https://gcc.gnu.org/viewcvs?rev=262152&root=gcc&view=rev
Log:
rs6000: Set up ieee128_float_type_node correctly (PR82625)
We shoul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
--- Comment #14 from Segher Boessenkool ---
Author: segher
Date: Tue Jun 26 15:36:21 2018
New Revision: 262154
URL: https://gcc.gnu.org/viewcvs?rev=262154&root=gcc&view=rev
Log:
regcprop: Avoid REG_CFA_REGISTER notes (PR85645)
Changing a SET th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
--- Comment #15 from Segher Boessenkool ---
Author: segher
Date: Tue Jun 26 15:39:02 2018
New Revision: 262155
URL: https://gcc.gnu.org/viewcvs?rev=262155&root=gcc&view=rev
Log:
regrename: Don't rename the dest of a REG_CFA_REGISTER (PR85645)
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86285
--- Comment #3 from Segher Boessenkool ---
Author: segher
Date: Tue Jun 26 16:08:30 2018
New Revision: 262156
URL: https://gcc.gnu.org/viewcvs?rev=262156&root=gcc&view=rev
Log:
I typoed the PR numnber, correct is:
PR target/86285
||2018-06-26
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Target Milestone|--- |8.2
Ever confirmed|0 |1
--- Comment #4 from Segher Boessenkool ---
Fixed on trunk; needs a backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82625
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367
--- Comment #6 from Segher Boessenkool ---
The values created for the four NaNs are
7fff8001
7fff8002ab3c
7fff8001
7fff8002ab3c
with -mabi=ieeelongdouble
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367
--- Comment #9 from Segher Boessenkool ---
(In reply to Bill Schmidt from comment #8)
> That makes sense -- we already have a NaN rather than an SNaN by the time we
> hit the Ealias pass.
It's already a QNaN in 004t.original (the very first dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497
--- Comment #12 from Segher Boessenkool ---
It still does some weird register moves (the xxlor and the fmr), but
those are totally different problems ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148
--- Comment #9 from Segher Boessenkool ---
Let me put it differently, then:
Such warnings should not be enabled by default before most it warns about
has been fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148
--- Comment #10 from Segher Boessenkool ---
And yes, that means a lot of work for whoever wants to make the warning
default (during GCC builds or otherwise).
The alternative is a lot of work for other people. That is not a good
alternative.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050
--- Comment #13 from Segher Boessenkool ---
Author: segher
Date: Mon Jul 15 20:57:53 2019
New Revision: 273498
URL: https://gcc.gnu.org/viewcvs?rev=273498&root=gcc&view=rev
Log:
rs6000: Always output .machine
We now can always output .machine (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53652
--- Comment #5 from Segher Boessenkool ---
It might work a lot better if it didn't have to load that all-ones vector
in a separate insn. Because it does, you need to do a 3->3 combination
(which we do not currently support) if you need to do the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
--- Comment #17 from Segher Boessenkool ---
Yup, those testcases work fine for powerpc, too; and the signed versions of
those
do as well. (I couldn't find vector-types.h; I did "#define VECTOR_SIZE 16").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88233
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89746
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88962
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
||segher at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #2 from Segher Boessenkool ---
This is another instance of PR58684.
*** This bug has been marked as a duplicate of bug 58684 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684
--- Comment #10 from Segher Boessenkool ---
*** Bug 91331 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
onent: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
Take this example:
===
#include
_Bool lt(double a, double b) { return isless(a, b); }
_Bool lo(double a, double b) { return a < b; }
_Bool ll(double a,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #3 from Segher Boessenkool ---
There are quite many different cases to test, and many *more* do not currently
generate the wanted code because it isn't optimised properly on gimple level,
and that makes it hard to test the RTL / targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #4 from Segher Boessenkool ---
(In reply to Richard Biener from comment #1)
> where we end up with
>
>[local count: 1073741824]:
> if (a_3(D) < b_4(D))
> goto ; [50.00%]
> else
> goto ; [50.00%]
>
>[local count:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #6 from Segher Boessenkool ---
Maybe we should make "is this an ordered comparison" separate from the
actual comparison code.
That would make things quite a bit simpler as well. Maybe we can pull
that through to RTL, as well?
||2019-08-21
CC||segher at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #5 from Segher Boessenkool ---
The various
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #6 from Segher Boessenkool ---
Author: segher
Date: Thu Aug 22 19:36:21 2019
New Revision: 274835
URL: https://gcc.gnu.org/viewcvs?rev=274835&root=gcc&view=rev
Log:
rs6000: Use unspec_volatile for darn (PR91481)
Every call to darn s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #7 from Segher Boessenkool ---
Author: segher
Date: Fri Aug 23 22:19:40 2019
New Revision: 274889
URL: https://gcc.gnu.org/viewcvs?rev=274889&root=gcc&view=rev
Log:
rs6000: New darn testcase (PR91481)
We used to implement darn with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #8 from Segher Boessenkool ---
Author: segher
Date: Fri Aug 30 13:51:26 2019
New Revision: 275175
URL: https://gcc.gnu.org/viewcvs?rev=275175&root=gcc&view=rev
Log:
Backport from trunk
2019-08-22 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #9 from Segher Boessenkool ---
Author: segher
Date: Fri Aug 30 13:53:11 2019
New Revision: 275176
URL: https://gcc.gnu.org/viewcvs?rev=275176&root=gcc&view=rev
Log:
Backport from trunk
2019-08-23 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #10 from Segher Boessenkool ---
Author: segher
Date: Fri Aug 30 14:15:39 2019
New Revision: 275181
URL: https://gcc.gnu.org/viewcvs?rev=275181&root=gcc&view=rev
Log:
Backport from trunk
2019-08-22 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #11 from Segher Boessenkool ---
Author: segher
Date: Fri Aug 30 14:17:20 2019
New Revision: 275182
URL: https://gcc.gnu.org/viewcvs?rev=275182&root=gcc&view=rev
Log:
Backport from trunk
2019-08-23 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #12 from Segher Boessenkool ---
Author: segher
Date: Fri Aug 30 14:23:55 2019
New Revision: 275185
URL: https://gcc.gnu.org/viewcvs?rev=275185&root=gcc&view=rev
Log:
Backport from trunk
2019-08-22 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #13 from Segher Boessenkool ---
Author: segher
Date: Fri Aug 30 14:25:36 2019
New Revision: 275186
URL: https://gcc.gnu.org/viewcvs?rev=275186&root=gcc&view=rev
Log:
Backport from trunk
2019-08-23 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #16 from Segher Boessenkool ---
Author: segher
Date: Sat Aug 31 18:58:04 2019
New Revision: 275244
URL: https://gcc.gnu.org/viewcvs?rev=275244&root=gcc&view=rev
Log:
rs6000: Fix darn-3.c for GCC 8 and GCC 7
Apparently I didn't prope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #17 from Segher Boessenkool ---
Author: segher
Date: Sat Aug 31 19:01:52 2019
New Revision: 275245
URL: https://gcc.gnu.org/viewcvs?rev=275245&root=gcc&view=rev
Log:
rs6000: Fix darn-3.c for GCC 8 and GCC 7
Apparently I didn't prope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738
Bug 82738 depends on bug 89794, which changed state.
Bug 89794 Summary: combine incorrectly forwards register value through auto-inc
operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89794
What|Removed |Ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89794
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
The -mlong-double-64 and -mlong-double-128 command line options aren't
documented.
The -Q --help=target output shows
-mlong-double-[64,128]127
whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
--- Comment #14 from Segher Boessenkool ---
(In reply to Wilco from comment #12)
> > but we should really handle this with some non-signaling insns, not punt
> > it to libm to do.
>
> Well we should simply commit Tamar's patch again since it wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
--- Comment #15 from Segher Boessenkool ---
(In reply to jos...@codesourcery.com from comment #13)
> These functions have to be expanded inline, unconditionally; there are no
> library functions they can reliably fall back on in general.
Ugh, y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
--- Comment #17 from Segher Boessenkool ---
(In reply to Tamar Christina from comment #16)
> > Do you have a link to those problems? And no, please don't regress us for
> > no
> > reason at all, it's really easy to *not* regress this on double-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635
--- Comment #23 from Segher Boessenkool ---
If a splitter wants a new register during combine, it should do a match_scratch
for that. This is documented.
You do not normally get new registers during combine. combine cannot really
handle those.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635
--- Comment #24 from Segher Boessenkool ---
(clobber of a match_operand I mean, sigh).
|UNCONFIRMED |NEW
Last reconfirmed||2019-09-07
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Segher Boessenkool ---
Confirmed. Any target. Needs -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
Segher Boessenkool changed:
What|Removed |Added
Known to work||4.8.5
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
--- Comment #5 from Segher Boessenkool ---
(BTW, using addic here is wrong: addic clobbers CA, which may not be free).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
||segher at gcc dot gnu.org
Host|ppc64le |
--- Comment #2 from Segher Boessenkool ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91275
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91275
Segher Boessenkool changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65640
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
||segher at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #10 from Segher Boessenkool ---
The new testcases pr91656-[12].c fail on all BE systems as written (the
memmove copies the MSB, not the LSB as intended).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #9 from Segher Boessenkool ---
So when was the array reallocated? combine does in general rely on all
rtxen to stay in place, etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #10 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #9)
> So when was the array reallocated? combine does in general rely on all
> rtxen to stay in place, etc.
Ah pretty much directly from gen_reg_rtx. Bah.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #11 from Segher Boessenkool ---
Oh lol, I finally wake up. It is called from the splitter. That isn't
really a valid thing to do.
We have some limited support for that since a while, but it seems this
cannot ever really work?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #13 from Segher Boessenkool ---
1) Yes, you'll be better of without calling gen_reg_rtx, certainly.
2) I don't see how you can make the undo scheme support this, without
big cost and/or big restructuring.
If we can replace this sche
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91720
--- Comment #2 from Segher Boessenkool ---
Isn't this *exactly* what WORD_REGISTER_OPERATIONS says is okay to do?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
--- Comment #9 from Segher Boessenkool ---
My patch do not clobber r11, that's the point of it :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
--- Comment #10 from Segher Boessenkool ---
The prologue is not necessarily inserted as the first bb, so it's not clear
to me that CA is never live there.
The code copying r11 to r0, and back, is removed by the usual optimisations
btw, in all no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
--- Comment #12 from Segher Boessenkool ---
Thanks for testing!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #17 from Segher Boessenkool ---
I'll do a patch to prohibit gen_reg_rtx inside combine, btw... Let's see
how far that goes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #19 from Segher Boessenkool ---
> Anyway, fixing it properly likely requires quite some work.
Combine should not change any insns in place. It should create *new*
insns. It can always keep those in some temporary place, only actual
|segher at gcc dot
gnu.org
Ever confirmed|0 |1
Build|powerpc64le-unknown-linux-g |
|nu |
--- Comment #2 from Segher Boessenkool ---
Confirmed. Only happens on LE. I'll have a look.
||2019-09-19
Host|powerpc64le-unknown-linux-g |
|nu |
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
Build|powerpc64le
||2019-09-19
Host|powerpc64le-unknown-linux-g |
|nu |
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
Build|powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #24 from Segher Boessenkool ---
On some (many?) targets it would be good to unroll all loops with a small body
(not containing calls etc.) at -O2 already, some small number of times (2 or 4
maybe).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91905
--- Comment #5 from Segher Boessenkool ---
Does -mno-vsx make it work? How about -mcpu=power7?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #26 from Segher Boessenkool ---
Yeah, and it probably should be a param (that different targets can default
differently, per CPU probably). On most Power CPUs all loops take a minimum
number of cycles per iteration (say, three), but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91275
--- Comment #8 from Segher Boessenkool ---
(In reply to Lauri Kasanen from comment #7)
> Are you sure about the smaller ones? To me they should not care about 64-bit
> swaps,
"swappable" here means you can swap the low and high half on all input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91981
--- Comment #2 from Segher Boessenkool ---
I didn't have an x86 C++ compiler handy, so I tried on powerpc. This
isn't a big problem there, since we do separate shrink-wrapping by
default on powerpc; disabling that makes this pretty bad here, too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91981
--- Comment #3 from Segher Boessenkool ---
So this works just fine with a compiler from a year ago.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91981
--- Comment #5 from Segher Boessenkool ---
Okay, I can reproduce it now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91981
--- Comment #6 from Segher Boessenkool ---
Attempting shrink-wrapping optimization.
Block 2 needs the prologue.
(That's the entry block, already). And in fact it does need the prologue,
it has
movq%rdi, %rbx # 2 [c=4 l=3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #31 from Segher Boessenkool ---
Gimple passes know a lot about machine details, too.
Irrespective of if this is "low-level" or "high-level", it should be done
earlier than it is now. It should either be done right after expand, or
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308
Segher Boessenkool changed:
What|Removed |Added
Status|SUSPENDED |NEW
--- Comment #10 from Segher Boe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #37 from Segher Boessenkool ---
-- If it is done in RTL it should really be done earlier, it doesn't get all
optimisations it should right now.
-- Unrolling small loops more aggressively (at -O2 even) perhaps needs to be
done at a di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #4 from Segher Boessenkool ---
Well it should at least be renamed then ;-)
But is that good anyway? We then do not have a jump pass after reload
(and before split2 and pro/epi, i.e. shrink-wrapping) any more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #8 from Segher Boessenkool ---
The current two jump passes we have after reload are there for a reason.
Some targets will be very unhappy if you delete them.
Like Jakub says, you need to avoid doing stuff with crossing edges in
many
||2019-10-14
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Segher Boessenkool ---
Does it need a new attribute at all?
If not, an optimisation like this is obviously beneficial: it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92086
--- Comment #5 from Segher Boessenkool ---
A new attribute is not very enticing. First, it is yet another special-purpose
attribute, which can also be surprisingly hard to define what it should do.
Because it is a special attribute, the feature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #9 from Segher Boessenkool ---
(In reply to Ilya Leoshkevich from comment #7)
> Having eliminated bb 5, we cannot avoid making bb 6 cold, since this
> would violate CFG integrity: as far as I understand, it's important to
> maintain t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92107
--- Comment #2 from Segher Boessenkool ---
Author: segher
Date: Tue Oct 15 23:47:47 2019
New Revision: 277023
URL: https://gcc.gnu.org/viewcvs?rev=277023&root=gcc&view=rev
Log:
genattrtab: Parenthesize expressions correctly (PR92107)
As PR92107
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #11 from Segher Boessenkool ---
Well, it apparently has found new jump threading opportunities after
partition_blocks. Are such changes useful? Does it happen often?
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
Since r254899 libquadmath isn't built for the default powerpc64-linux
configuration any more, causing all fortran run tests for -m32 to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83341
--- Comment #1 from Segher Boessenkool ---
Actually, I'm blaming the wrong patch there. Sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83361
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
601 - 700 of 3228 matches
Mail list logo
