|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #2 from Segher Boessenkool ---
I have a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83341
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83361
--- Comment #3 from Segher Boessenkool ---
Author: segher
Date: Mon Dec 11 21:23:08 2017
New Revision: 20
URL: https://gcc.gnu.org/viewcvs?rev=20&root=gcc&view=rev
Log:
ifcvt: Call fixup_partitions (PR83361)
After converting a condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83363
--- Comment #2 from Segher Boessenkool ---
I cannot reproduce the problem. It generates better optimised code
than before (removing half the insns in foo), but it is still correct
and does not abort.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83364
--- Comment #2 from Segher Boessenkool ---
I cannot reproduce this one, either. I built with r29.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83393
--- Comment #3 from Segher Boessenkool ---
In the original code, r108 as set by insn 14 is dead after insn 16. The
combination 15->20 should have changed that, but apparently didn't.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83393
--- Comment #4 from Segher Boessenkool ---
Author: segher
Date: Wed Dec 13 14:05:57 2017
New Revision: 255606
URL: https://gcc.gnu.org/viewcvs?rev=255606&root=gcc&view=rev
Log:
combine: Fix PR83393
In move_deaths we move a REG_DEAD note if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83393
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83437
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #32 from Segher Boessenkool ---
Yes, it does hurt. Quite many people use casts to void automatically on
all function calls where they do not use the result. They of course need
to be re-educated on that. Casts to void do not portab
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #2 from Segher Boessenkool ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83361
--- Comment #5 from Segher Boessenkool ---
No, it probably needs backports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83424
--- Comment #3 from Segher Boessenkool ---
Author: segher
Date: Mon Dec 18 20:16:19 2017
New Revision: 255787
URL: https://gcc.gnu.org/viewcvs?rev=255787&root=gcc&view=rev
Log:
rtlanal: dead_or_set_regno_p should handle CLOBBER (PR83424)
In PR8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83424
--- Comment #4 from Segher Boessenkool ---
This is latent on the branches; queued for backports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83424
Segher Boessenkool changed:
What|Removed |Added
Target Milestone|8.0 |6.4
Summary|[8 Regressio
||2017-12-19
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Segher Boessenkool ---
The testcase looks for
/* { dg-final { scan-rtl-dump-times "\\\(compare:CC \\\(subreg:SI \\\(r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81010
--- Comment #4 from Segher Boessenkool ---
But I see the same for LE ELFv2? I wonder what's going on...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81010
--- Comment #5 from Segher Boessenkool ---
Oh, heh, the testcase isn't run at all on powerpc64le. That should be fixed,
too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791
--- Comment #11 from Segher Boessenkool ---
In the 64-bit Power ABIs, an int is passed as a sign-extended 64-bit register.
Take this trivial example:
int f(int x) { return x*x; }
which compiles to (on powerpc64-linux, BE):
.L.f:
mullw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399
Segher Boessenkool changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #7 from Segher Boessenkool ---
(In reply to Sergei Trofimovich from comment #5)
> gcc's try_combine() scares me lots :)
It's an acquired taste.
> Segher, can you guide me here what changes size of zero_extract in here from
> 0x1f to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #9 from Segher Boessenkool ---
#0 means subreg 0; in this case, (subreg:DI (reg:SI 357) 0) etc.
(The "slim" RTL dumps are lossy in places btw; in _this_ case you
can deduce it has to be DImode, but not always. OTOH slim dumps
take
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #14 from Segher Boessenkool ---
(In reply to Jim Wilson from comment #11)
> This part
>
> >r358 is known to have the high half zero:
> > 22: r358:DI=r357:SI#0^r341:SI#0
>
> is wrong. The upper bits of both registers are unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #24 from Segher Boessenkool ---
Binary size (of vmlinux) grows by 0.09%. I don't know about performance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #16 from Segher Boessenkool ---
> > > --- gcc/config/rs6000/rs6000.c(revision 255700)
> > > +++ gcc/config/rs6000/rs6000.c(working copy)
> > > @@ -11095,7 +11095,8 @@ rs6000_discover_homogeneous_aggregate (m
> > > homoge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc64*-*-* |powerpc*-*-*
--- Comment #3 from Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83628
--- Comment #5 from Segher Boessenkool ---
The MULT is not canonical.
For some reason we do not realise we can do the ASHIFT as SI instead of DI.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507
--- Comment #1 from Segher Boessenkool ---
I cannot reproduce this on either powerpc-linux or powerpc64-linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507
Segher Boessenkool changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507
--- Comment #8 from Segher Boessenkool ---
Ah yes, I can reproduce it with all those options and -m32. I could
swear to have tried exactly that yesterday; pilot error I guess.
CA is not just a hard register, but a fixed register, btw.
||segher at gcc dot gnu.org
Resolution|--- |WORKSFORME
--- Comment #3 from Segher Boessenkool ---
It is more than plenty: what is the default for new ports only concerns
developers of GCC itself. Everyone else is free to read some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83629
--- Comment #2 from Segher Boessenkool ---
Needs e.g. -mcpu=603 to fail.
||2018-01-08
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #3 from Segher Boessenkool ---
I have a fuller patch; it's testing (your variant 1).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399
--- Comment #5 from Segher Boessenkool ---
That last testcase needs -mabi=elfv2 to fail (but doesn't need that -O3).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83743
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399
Segher Boessenkool changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83743
--- Comment #4 from Segher Boessenkool ---
Which is perfectly fine, except the error message is a bit confusing if you
don't know what's going on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83629
--- Comment #4 from Segher Boessenkool ---
Author: segher
Date: Wed Jan 10 15:13:07 2018
New Revision: 256432
URL: https://gcc.gnu.org/viewcvs?rev=256432&root=gcc&view=rev
Log:
rs6000: Wrap diff of immediates in const (PR83629)
In various of ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83629
--- Comment #5 from Segher Boessenkool ---
Fixed on trunk; awaiting backports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68834
--- Comment #2 from Segher Boessenkool ---
Likely the same issue as pr83629 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78875
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79140
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83629
--- Comment #6 from Segher Boessenkool ---
Author: segher
Date: Fri Jan 12 12:10:16 2018
New Revision: 256577
URL: https://gcc.gnu.org/viewcvs?rev=256577&root=gcc&view=rev
Log:
rs6000: Tune new testcase (PR83629)
It has some problems running on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83629
--- Comment #7 from Segher Boessenkool ---
Author: segher
Date: Mon Jan 15 22:08:12 2018
New Revision: 256711
URL: https://gcc.gnu.org/viewcvs?rev=256711&root=gcc&view=rev
Log:
Backport from mainline
2018-01-10 Segher Boessenkoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83629
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83789
--- Comment #2 from Segher Boessenkool ---
(In reply to Kaushikp from comment #0)
> Should we modify the testcase so it runs only for 64-bit targets,
> or should this builtin work for 32-bit targets as well?
It shouldn't ICE for 32-bit either,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83424
--- Comment #5 from Segher Boessenkool ---
Author: segher
Date: Tue Jan 16 16:20:10 2018
New Revision: 256750
URL: https://gcc.gnu.org/viewcvs?rev=256750&root=gcc&view=rev
Log:
rtlanal: dead_or_set_regno_p should handle CLOBBER (PR83424)
In PR8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83424
--- Comment #6 from Segher Boessenkool ---
Author: segher
Date: Tue Jan 16 16:30:43 2018
New Revision: 256752
URL: https://gcc.gnu.org/viewcvs?rev=256752&root=gcc&view=rev
Log:
rtlanal: dead_or_set_regno_p should handle CLOBBER (PR83424)
In PR8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83424
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43871
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83789
--- Comment #3 from Segher Boessenkool ---
Does not reproduce with powerpc64-linux-gcc -m32 (not on trunk and
not on current 7).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399
Segher Boessenkool changed:
What|Removed |Added
Target Milestone|--- |6.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83969
--- Comment #2 from Segher Boessenkool ---
Where do you get TImode with this testcase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81550
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81550
--- Comment #8 from Segher Boessenkool ---
Yes, but that does not work if ivopts decides to make a loop that cannot
work with bdnz ;-)
cc:ing Bin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964
--- Comment #3 from Segher Boessenkool ---
No, many other builtins are also problematic (there are a few more PRs open).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926
--- Comment #7 from Segher Boessenkool ---
It is first V2DI in the RTL, which exists just fine (but there is no
such divide insn); then when it is split to two DImode divides, it
just generates div:DI etc., which does not exist for -m32.
So we e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83985
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83985
--- Comment #10 from Segher Boessenkool ---
Ah, #c6 made me think you wanted to do something else. I didn't look close
enough, sorry. That patch looks good.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83946
--- Comment #11 from Segher Boessenkool ---
Author: segher
Date: Fri Jan 26 21:31:37 2018
New Revision: 257110
URL: https://gcc.gnu.org/viewcvs?rev=257110&root=gcc&view=rev
Log:
rs6000: Fix safe-indirect-jump-[18].c
Thist patch merges the safe-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010
--- Comment #10 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> >> This kernel AT_PLATFORM name should strip the '+' off:
> >> .platform = "power7+", -> "power7"
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496
--- Comment #12 from Segher Boessenkool ---
It's the dbr ("reorg") pass that is deleting the insn.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496
--- Comment #13 from Segher Boessenkool ---
There are *two* conditional branches leading to that "return 1". After
dbr one is a delay-slot seq, and the other has lost the assignment of the
return value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84123
--- Comment #2 from Segher Boessenkool ---
That looks good, please send the patch!
What about the third case? The first in the "if" tree. Does that need
this as well? (The third and last case already has a similar check).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
Segher Boessenkool changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #11 from Segher Boessenkool ---
It will be fixed. But not many people have access to powerpc-darwin systems
to test on.
Does this still happen on trunk as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84157
--- Comment #5 from Segher Boessenkool ---
Hi Tom,
That looks good. But maybe the REG_P check should be in the outer "if"?
Slightly easier and safer to exit as early as possible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #16 from Segher Boessenkool ---
Darwin has its own ABI, and that is what those assembler routines are for.
This has nothing to do with this bug report; please use the mailing lists
for other questions/discussions/etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84157
--- Comment #7 from Segher Boessenkool ---
(In reply to Tom de Vries from comment #6)
> (In reply to Segher Boessenkool from comment #5)
> > That looks good.
> that patch was by Uros though.
Yes I misread. Uros: that patch is pre-approved.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84157
--- Comment #9 from Segher Boessenkool ---
I've tested this on powerpc64-linux {-m64,-m32} as well (change_zero_ext
is pretty important for us; we have big testcases for this and related code).
No issues found.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84169
--- Comment #3 from Segher Boessenkool ---
Confirmed. Does not happen with a compiler a few months old.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84169
--- Comment #4 from Segher Boessenkool ---
This starts to fail with r249850 (don't know yet what the problem is).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #23 from Segher Boessenkool ---
(In reply to Douglas Mencken from comment #22)
> as for https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02040.html
> I think that optimizing epilogues is a good idea, but not of a cost of
> unbuildability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #25 from Segher Boessenkool ---
Please test https://gcc.gnu.org/ml/gcc-testresults/2017-01/txtnZhWiDkC4z.txt .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #27 from Segher Boessenkool ---
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #29 from Segher Boessenkool ---
The patch has never been sent to gcc-patches. It also still never was
properly tested. Can you do that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #32 from Segher Boessenkool ---
Yes, run "make -k check" (add -jN to taste if you have multiple CPUs).
And then run contrib/test_summary. See if that is as expected (compare
it to previous powerpc-darwin results on gcc-testresults@;
||2018-02-05
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #36 from Segher Boessenkool ---
I'll take care of it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84264
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84264
--- Comment #2 from Segher Boessenkool ---
It ICEs on
gcc_assert (!lra_in_progress && !reload_completed);
but this is called from the movv4si expander, and that is something LRA is
allowed to use.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83789
--- Comment #4 from Segher Boessenkool ---
Kaushik: is this fixed with r256762?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78303
--- Comment #4 from Segher Boessenkool ---
If -maltivec=be is not used, I support removing it. Deprecating it with a
warning on use will show if anyone care enough to tell us they do use it ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83969
--- Comment #6 from Segher Boessenkool ---
r256598 deleted *movti_string (and all other string instructions); does
this bug still happen? That patch was committed 20180112.
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #8 from Segher Boessenkool ---
input_operand allows any MEM, and Y is fine here (we could remove Q though).
The problem is that VECTOR_MEM_NONE_P (TImode) isn't true, and we do not
handle that for !TARGET_POWERPC64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84154
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84226
--- Comment #3 from Segher Boessenkool ---
Many other ports use bswap on vectors though?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84226
--- Comment #4 from Segher Boessenkool ---
I mean, the documentation is out-of-date no matter what...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83969
--- Comment #9 from Segher Boessenkool ---
Duh, input_operand does _not_ allow any MEM: it allows any memory_operand.
Which apparently we do not have here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #20 from Segher Boessenkool ---
(In reply to Richard Biener from comment #19)
> Not sure if it
> is generally advised/done to use scratch registers by simply clobbering
> them.
It is often done. Advised... I cannot think of a good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57591
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
In GCC 8 and earlier, this generates
mtvsrwz 32,3
#APP
# 10 "vsx-simode2.c" 1
xxlor 32,32,32 # v, v c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
Segher Boessenkool changed:
What|Removed |Added
Known to work||8.0
Version|unknown
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
gcc
701 - 800 of 3228 matches
Mail list logo
