https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055
--- Comment #6 from Segher Boessenkool ---
*** Bug 88618 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88640
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88640
--- Comment #3 from Segher Boessenkool ---
It looks like a generic problem to me, fwiw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88599
--- Comment #1 from Segher Boessenkool ---
I cannot reproduce this. Either you need more flags, a more specific target,
some specific libc version (etc.), and/or some non-default configure arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939
--- Comment #9 from Segher Boessenkool ---
I think we should declare one of the forms canonical, and make simplify
use that one, if possible. If we really want one form in some cases and
another in other cases something like change_zero_ext will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939
--- Comment #11 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #10)
> even if that means introducing of "fake" larger vector modes.
That would be a good reason to not do this, except many targets already
do need double-l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88606
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #2 from Segher Boessenkool ---
Or, do we have any machine in the compile farm on which this can be reproduced?
If so, could you give instructions for that please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #18 from Segher Boessenkool ---
Well, it is always possible to generate code with the opposite endianness to
what the hardware "wants". It just won't be very fast code.
BITS_BIG_ENDIAN is just a convenience to the target code writer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88765
--- Comment #1 from Segher Boessenkool ---
So in the first example, why is the branch not forwarded already?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88765
--- Comment #2 from Segher Boessenkool ---
What exact options are needed here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88765
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc64le-linux-gnu |powerpc*-*-*
Status|UNC
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
-Wmisleading-indentation does not warn for
===
void f(void)
{
}
}
===
(as Daniel (on cc:) found), but not even for
===
void f(void)
{
}
===
Is there a reason for that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88790
--- Comment #1 from Segher Boessenkool ---
(I couldn't add that cc:, Daniel doesn't have a bugzilla account yet).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86683
Segher Boessenkool changed:
What|Removed |Added
Resolution|WORKSFORME |FIXED
--- Comment #6 from Segher Bo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055
--- Comment #7 from Segher Boessenkool ---
*** Bug 88863 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88863
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #17 from Segher Boessenkool ---
It's not obvious to me what machine code is wrong here. Maybe it is obvious
to someone who is better at Arm code than I am?
Does it all work if you use -fno-if-conversion2 though? Or, what other
late
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88861
--- Comment #5 from Segher Boessenkool ---
Cool, thanks! Is the plan to simply not allow something that can throw to be
recognised as noop move?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #6 from Segher Boessenkool ---
Sure, with 32-bit ABIs the registers are just 32 bits, for all intents and
purposes.
But we have -m64 here. (see also the "lwa" insn).
I think that because __floatunsidf has no prototype all its args a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #8 from Segher Boessenkool ---
There is no bug, so we don't have to do anything.
To make slightly better code we could make the soft float routines be
prototyped?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88845
--- Comment #3 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #2)
> Thinking about this, insn 14 doesn't look legal to me for ppc, since FP
> values in our FP regs are actually stored as 64-bit quantities, even for
> SFmode,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc64le-redhat-linux-gn |powerpc64*-*-*
|u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #8 from Segher Boessenkool ---
So we should use the current rounding mode for any float_trunc? So we can use
float store instructions for it only with some fast-math option?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #11 from Segher Boessenkool ---
Good point. So we cannot use stfs (etc.) as float_truncate+store ever, not
even with full fast math options.
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #12 from Segher Boessenkool ---
Okay, mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064
--- Comment #12 from Segher Boessenkool ---
Yes, I think so (just the vec_select arg?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #13 from Segher Boessenkool ---
Author: segher
Date: Fri Jan 18 18:01:56 2019
New Revision: 268083
URL: https://gcc.gnu.org/viewcvs?rev=268083&root=gcc&view=rev
Log:
rs6000: Fix *movsi_from_df (PR88892)
The memory store instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88423
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #16 from Segher Boessenkool ---
Is anything broken though?
If the libcall routines know they are called this way, all is fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #12 from Segher Boessenkool ---
Before the change combine forwarded all argument (etc.) hard registers wherever
it could, doing part of RA's job (and doing a lousy job of it). If after the
change it no longer two ranges, than a) that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #16 from Segher Boessenkool ---
(In reply to Wilco from comment #13)
> (In reply to Segher Boessenkool from comment #12)
> > Before the change combine forwarded all argument (etc.) hard registers
> > wherever
> > it could, doing part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #18 from Segher Boessenkool ---
https://gcc.gnu.org/ml/gcc/2019-01/msg00112.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064
--- Comment #19 from Segher Boessenkool ---
The pattern makes no sense at all for LE.
If LE,
(vec_concat:V2DF
(vec_select:DF
(match_operand:V2DF 1 "vfloat_operand" "wd,wa,wd,wa")
(parallel [(const_int 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #20 from Segher Boessenkool ---
(In reply to Wilco from comment #19)
> (In reply to Segher Boessenkool from comment #18)
> > https://gcc.gnu.org/ml/gcc/2019-01/msg00112.html
>
> Thanks, I hadn't noticed that yet... I need to look at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #18 from Segher Boessenkool ---
(In reply to Alan Modra from comment #17)
> > Is anything broken though?
>
> Yes, as demonstrated by the testcase.
I couldn't get the testcase to link, I don't think I have an __floatunsidf
anywhere,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
--- Comment #6 from Segher Boessenkool ---
That patch looks good, and is pre-approved. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #31 from Segher Boessenkool ---
Please use -fdump-rtl-combine-all if you want to see the whole story.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #19 from Segher Boessenkool ---
As far as I can see no powerpc64 libgcc has __floatunsidf at all (or any other
soft float routines). Where do you get those routines from?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89049
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
--- Comment #21 from Segher Boessenkool ---
Before the holidays I did this patch:
===
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index fa5f032..2ffe7d9 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #15 from Segher Boessenkool ---
Not in 8.2, no, that was released half a year ago already. But 8.3, yes, it is
lined up for that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89162
Segher Boessenkool changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
Assignee: ian at airs dot com
Reporter: segher at gcc dot gnu.org
CC: cmang at google dot com
Target Milestone: ---
libtool: compile: /home/segher/build/tot-master/./gcc/xgcc
-B/home/segher/build/tot-master/./gcc/
-B/home/segher/tot/powerpc64-unknown-linux-gnu/bin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89162
--- Comment #2 from Segher Boessenkool ---
Ha, my last build was r268452 :-)
Thanks for the fix, and sorry for the noise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89154
--- Comment #1 from Segher Boessenkool ---
The new version needs to save r4 because it reuses the reg for storing r7+r8.
And we still don't wrap CR separately, sigh.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89112
--- Comment #6 from Segher Boessenkool ---
The patch in #c5 is pre-approved everywhere. Thanks!
#c4... Do you *want* to keep it together? Is it in fact cold? If it is not,
maybe you can improve the execution estimate for it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
--- Comment #25 from Segher Boessenkool ---
I don't see that; I get
f1:
.LFB0:
.cfi_startproc
b foo@plt
.cfi_endproc
.LFE0:
What extra options do I need? Or, what other target (you didn't say, I used
powerpc-linux).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
--- Comment #28 from Segher Boessenkool ---
(In reply to Alan Modra from comment #27)
> And possibly -msecure-plt
Yeah that does the trick, thanks :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
--- Comment #29 from Segher Boessenkool ---
This:
===
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 401e719..f0adef7 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -37988,7 +37988,10 @@ r
ponent: go
Assignee: ian at airs dot com
Reporter: segher at gcc dot gnu.org
CC: cmang at google dot com
Target Milestone: ---
A lot of stuff this time, unlike last year's PR81548.
(I tested on powerpc*-linux, if that matters).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
--- Comment #3 from Segher Boessenkool ---
(In reply to Wilco from comment #1)
> len is unsigned HOST_WIDE_INT, so bits_to_bytes_round_down does an unsigned
> division...
That shouldn't make a difference though, both dividend and divisor should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
--- Comment #6 from Segher Boessenkool ---
pos should be always non-negative. pos is the offset (in bits, counted from
the right) in the *field*.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
--- Comment #9 from Segher Boessenkool ---
That patch is pre-approved if it regchecks fine (on more than just x86).
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532
--- Comment #8 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #6)
> Note IIRC vec_extract came from the Cell BE C/C++ extension guide. I can't
> seem to find that guide any more either :(.
Try googling for "Language_Extensi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89154
--- Comment #4 from Segher Boessenkool ---
The r1 adjustment is establishing the stack frame. It needs to precede all
stack accesses (not just those by the prologue saves!) We could separately
wrap it, if that would help? You can then get mult
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213
--- Comment #4 from Segher Boessenkool ---
You could just do
xxspltib xx,sh
vsrad 2,2,xx
(only the low 6 bits of the shift count are looked at, for 64-bit shifts,
in all vector insns).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213
--- Comment #6 from Segher Boessenkool ---
For 32-bit or smaller shifts you can use vspltisb always, or vspltis[hw] if
you prefer.
If generating code for ISA 2.07 (Power8) you don't have xxspltib but you do
have vsld/vsrd/vsrad/vrld, hrm. You s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89234
Segher Boessenkool changed:
What|Removed |Added
Target|ppc64le-linux-gnu, |powerpc*-*-*
|ppc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89234
--- Comment #2 from Segher Boessenkool ---
"Works fine for C"... With the error
error: can't mix operands of decimal float and other float types
that is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #28 from Segher Boessenkool ---
But what version of GCC is this graph, with what exact configuration?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85287
--- Comment #4 from Segher Boessenkool ---
Nope, different issue, this one in rs6000 target code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85291
--- Comment #1 from Segher Boessenkool ---
I cannot reproduce this. What is the failing insn?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85291
Segher Boessenkool changed:
What|Removed |Added
Target|ppc64le-linux-gnu |powerpc*-*-*
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85293
Segher Boessenkool changed:
What|Removed |Added
Target|ppc64le-linux-gnu |powerpc64*-*-*
--- Comment #1 from
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #5 from Segher Boessenkool ---
I'll handle it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85300
--- Comment #4 from Segher Boessenkool ---
I suppose the only way in which they are different is that those are the
only cases that anyone ran into so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85300
--- Comment #5 from Segher Boessenkool ---
There also is
/* We don't have to handle SIGN_EXTEND here, because even in the
case of replacing something with a modeless CONST_INT, a
CONST_INT is already (supposed to be) a valid sign ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85321
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85321
--- Comment #2 from Segher Boessenkool ---
Author: segher
Date: Tue Apr 10 18:54:08 2018
New Revision: 259296
URL: https://gcc.gnu.org/viewcvs?rev=259296&root=gcc&view=rev
Log:
rs6000: Improve --help=target (PR85321)
This updates the help text
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85321
--- Comment #3 from Segher Boessenkool ---
So this leaves:
-mblock-compare-inline-limit - option not documented in manual
-mblock-compare-inline-loop-limit - likewise
-mcall-* - possible values are not listed in --help=target
-mstring-compare-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85287
--- Comment #5 from Segher Boessenkool ---
Author: segher
Date: Tue Apr 10 21:37:34 2018
New Revision: 259299
URL: https://gcc.gnu.org/viewcvs?rev=259299&root=gcc&view=rev
Log:
rs6000: Fix stack clash for big residuals (PR85287)
The stack clash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85287
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
FAIL: gfortran.dg/do_concurrent_5.f90 -O (test for excess errors)
Excess errors:
gfortran: error: libgomp.spec: No such file or
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
error: use of 'long long' in AltiVec types is invalid without '-mvsx'
This is without --with-cpu=, so defaulting to power4, so indeed no VSX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85291
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85291
--- Comment #6 from Segher Boessenkool ---
Author: segher
Date: Thu Apr 12 20:01:37 2018
New Revision: 259354
URL: https://gcc.gnu.org/viewcvs?rev=259354&root=gcc&view=rev
Log:
rs6000: Fix an ICE with -mno-direct-move (PR85291)
PR targ
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85394
Segher Boessenkool changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402
--- Comment #12 from Segher Boessenkool ---
Author: segher
Date: Fri Apr 13 23:13:40 2018
New Revision: 259380
URL: https://gcc.gnu.org/viewcvs?rev=259380&root=gcc&view=rev
Log:
rs6000: Fix _mm_slli_epi{32,64} for shift values 16 through 31 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85293
--- Comment #2 from Segher Boessenkool ---
Author: segher
Date: Sat Apr 14 21:13:20 2018
New Revision: 259386
URL: https://gcc.gnu.org/viewcvs?rev=259386&root=gcc&view=rev
Log:
rs6000: Disable -m[no-]direct-move (PR85293)
The -mno-direct-move o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85293
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #31 from Segher Boessenkool ---
(In reply to John Paul Adrian Glaubitz from comment #30)
> > The announcement of the intent to obsolete the port has been posted already
> > more than a year ago, if you look in the comments in this PR,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #47 from Segher Boessenkool ---
(In reply to Eric Botcazou from comment #35)
> > A port does not need maintenance only for that port, and its users, but also
> > for GCC itself. All ports are a cost to _all_ GCC developers. If a por
||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503
Segher Boessenkool changed:
What|Removed |Added
Target Milestone|--- |8.0
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #3 from Segher Boessenkool ---
I have some combine patches (for GCC 9) to do more 2->2 combinations. Still
needs more tuning (but it fixes this testcase).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83748
--- Comment #9 from Segher Boessenkool ---
[ Please remove irrelevant parts of the email when replying to bugzilla mail ].
https://gcc.gnu.org/r205896 tells you this commit resolved four PRs:
PR middle-end/23623
PR middle-end/48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
--- Comment #5 from Segher Boessenkool ---
saw edge from trace 1 to 4 (via jump_insn 42)
...
Processing trace 3 : start at code_label 507
saw edge from trace 3 to 4 (via fallthru 0)
Inconsistent CFI state!
SHOULD have:
.cfi_def_cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
--- Comment #6 from Segher Boessenkool ---
It goes wrong in cprop_hardreg, which replaces
insn/f 482 43 483 5 (set (reg:SI 25 25)
(reg:SI 65 lr)) 502 {*movsi_internal1}
(expr_list:REG_DEAD (reg:SI 65 lr)
(expr_list:REG_CFA_R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
--- Comment #7 from Segher Boessenkool ---
Or actually, rnreg is the culprit (it was reg 0, rnreg moved this to reg 25)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
--- Comment #8 from Segher Boessenkool ---
Started at r259672.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
--- Comment #9 from Segher Boessenkool ---
Author: segher
Date: Wed May 9 12:12:33 2018
New Revision: 260074
URL: https://gcc.gnu.org/viewcvs?rev=260074&root=gcc&view=rev
Log:
regcprop: Avoid REG_CFA_REGISTER notes (PR85645)
Changing a SET tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
--- Comment #10 from Segher Boessenkool ---
Author: segher
Date: Wed May 9 12:14:39 2018
New Revision: 260075
URL: https://gcc.gnu.org/viewcvs?rev=260075&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=85645
--- Comment #11 from Segher Boessenkool ---
Author: segher
Date: Wed May 9 12:48:43 2018
New Revision: 260076
URL: https://gcc.gnu.org/viewcvs?rev=260076&root=gcc&view=rev
Log:
shrink-wrap: Improve spread_components (PR85645)
In the testcase f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
--- Comment #12 from Segher Boessenkool ---
Author: segher
Date: Wed May 9 12:51:00 2018
New Revision: 260077
URL: https://gcc.gnu.org/viewcvs?rev=260077&root=gcc&view=rev
Log:
rs6000: Give an argument to every REG_CFA_REGISTER (PR85645)
The o
501 - 600 of 3228 matches
Mail list logo
