https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81288
--- Comment #10 from Segher Boessenkool ---
Works in GCC 9, as in, the target does not exist any more in GCC 9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80700
Segher Boessenkool changed:
What|Removed |Added
Known to work||9.0
Summary|[8/9/10 Regr
||segher at gcc dot gnu.org
Resolution|--- |WONTFIX
--- Comment #1 from Segher Boessenkool ---
GCC 9 does not support powerpcspe.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772
Bug 86772 depends on bug 86801, which changed state.
Bug 86801 Summary: Powerpcspe port (may) need updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86801
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86133
Segher Boessenkool changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85121
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81628
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71012
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37759
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87083
Segher Boessenkool changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85170
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84302
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49854
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91638
--- Comment #5 from Segher Boessenkool ---
Yeah, not sure. A user can just do `-mlong-double-128`, and will get whichever
128-bit format is the default. That is the "old" way, when we only had the
ibm128 format, and it will be the new way too,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Segher Boessenkool changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #30 from Segher Boessenkool ---
r10-6919 isn't good for Power, btw. Why would it *ever* be a good idea?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #32 from Segher Boessenkool ---
So it sounds like this helps for targets with tiny register sets?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #34 from Segher Boessenkool ---
Yeah, 16 (or really 12-ish, not all are available) I call "tiny" :-)
It is very surprising (and not pleasantly so) that this overrides
REG_ALLOC_ORDER. We allocate GPR0 last (of the volatile GPRs), on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #30 from Segher Boessenkool ---
I cannot reproduce the problem, btw (I cannot build a 32-bit hosted toolchain).
Martin, you have a working recipe?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #32 from Segher Boessenkool ---
Sigh. No, this is *not* a target bug (or we certainly do not know it is),
please stop marking it that.
It seems to be a bug in shrink-wrapping, but the dump does not show enough
information (only cont
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #33 from Segher Boessenkool ---
(In reply to Martin Liška from comment #31)
> (In reply to Segher Boessenkool from comment #30)
> > I cannot reproduce the problem, btw (I cannot build a 32-bit hosted
> > toolchain).
> > Martin, you ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #34 from Segher Boessenkool ---
(In reply to Vladimir Makarov from comment #29)
> Sorry for all the troubles with my latest patch and thank you for fair
> criticism. I've decided to revert the patch as soon as git starts working.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #36 from Segher Boessenkool ---
> > I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
> > but that builds stage2 as 64-bit?
>
> Hm, that's possible. But the stage2 should not crash right?
It doesn't work, of c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #37 from Segher Boessenkool ---
Oh wait. I am dumb I guess? You did those dumps with a stage1 compiler?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #38 from Segher Boessenkool ---
Then, how did you do that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #42 from Segher Boessenkool ---
Okay, I see your dumps are 64-bit as well. But mine are very different, huh.
Still, it crashes in pretty much the same way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #46 from Segher Boessenkool ---
Thank you very much for that new testcase! I wish I had it before :-)
Yesterday I found the problem. It is in separate shrink-wrapping. The
fix is probably simple; hang on :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148
Segher Boessenkool changed:
What|Removed |Added
Blocks||94042
Target Milestone|---
mal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
df-core.c:df_worklist_dataflow_doublequeue uses bb->aux, clobbering it,
while that field is documented as
/* Auxiliar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94135
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94135
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #2 from Segher Boessenkool ---
How could the function address ever not be constant?
Hoisting it to somewhere where it is (dynamically) more expensive is a
bad idea, of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #3 from Segher Boessenkool ---
C11 6.6/9 says it *always* is constant, even.
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #2 from Segher Boessenkool ---
Yes, and it assumes it stays cleared for any new blocks, and some more
subtleties.
I have a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #10 from Segher Boessenkool ---
The resolved address can only change before the first call to it, so we
could even automatically insert code checking that, perhaps.
My other concern is not slowing down the code if LD_BIND_NOW is in u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94135
--- Comment #3 from Segher Boessenkool ---
Both subfic and neg are 1-2 if run on the integer units. neg can run on
more units, but it is always 2 cycles then! (And the conditions where you
*can* have 1 cycle are not very often satisfied, anyway
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148
--- Comment #3 from Segher Boessenkool ---
Fixed on trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc64-suse-linux|powerpc*
Host|powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148
--- Comment #4 from Segher Boessenkool ---
Fixed on trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148
--- Comment #5 from Segher Boessenkool ---
commit 5c7e6d4bdf879b437b43037e10453275acabf521
Author: Segher Boessenkool
Date: Thu Mar 12 07:12:50 2020 +
df: Don't abuse bb->aux (PR94148, PR94042)
The df dataflow solvers use the aux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #11 from Segher Boessenkool ---
(In reply to Rich Felker from comment #10)
> This is a rather huge bug to have been fixed silently. Could someone who
> knows the commit that fixed it and information on what versions are affected
> att
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
(This PR is just to test BZ commit integration).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94176
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #15 from Segher Boessenkool ---
(In reply to Rich Felker from comment #12)
> > You can work around it on older GCC by simply not using a register var
> > for more than one asm operand, I think?
>
> Nope. Making a syscall inherently r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #20 from Segher Boessenkool ---
Confirmed with various 7 and 8 (I don't have a mips 6 around).
Don't reopen this bug, it is not necessarily related. Instead, please
open a new PR. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #23 from Segher Boessenkool ---
It is harder for us to track it in an older bug with many older patches
for it, including stuff that needed fixups later. And, the "correct"
older bug for it would not be this one, anyway!
Before RA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #29 from Segher Boessenkool ---
(In reply to Rich Felker from comment #27)
> Also just realized:
>
> > Rich, forcing "n" to be in "$r10" seems to do the trick? Is that a
> > reasonable
> solution for you?
>
> It doesn't even work,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #31 from Segher Boessenkool ---
An asm clobber just means "may be an output", and no operand will be assigned
a register mentioned in a clobber. There is no magic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #32 from Segher Boessenkool ---
===
#define SYSCALL_CLOBBERLIST \
"$1", "$3", "$11", "$12", "$13", \
"$14", "$15", "$24", "$25", "hi", "lo", "memory"
long syscall6(long n, long a, long b, long c, long d, long e, long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #34 from Segher Boessenkool ---
Oh, your real code is different, and $10 doesn't work for that? I see.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #36 from Segher Boessenkool ---
The kernel jumps back to an instruction *before* the syscall?!?
(I do not want to know about that any more, then, I am sure :-) )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94135
--- Comment #5 from Segher Boessenkool ---
Please try it out on hardware (or on a cycle-accurate simulator) if you don't
believe me ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #36 from Segher Boessenkool ---
(In reply to Rich Felker from comment #34)
> Per the IBM docs, LE/elfv2 (which they confusingly equate)
Where do you see this, btw? The introduction of the ABI doc says
> The OpenPOWER ELF V2 ABI is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #37 from Segher Boessenkool ---
Oh, hrm, I am looking at an older version. Ugh.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87583
--- Comment #5 from Segher Boessenkool ---
commit 68dd57808f7c0147acdb5ca72c88ff655afcb0ce
Author: Carl Love
Date: Fri Mar 20 18:15:05 2020 -0500
rs6000: Add command line and builtin compatibility check
2020-03-20 Carl Love
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
--- Comment #8 from Segher Boessenkool ---
SFmode values are stored as DP IEEE float normally. There may be other
cases as well, but this is the obvious one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
Segher Boessenkool changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
--- Comment #12 from Segher Boessenkool ---
That patch looks fine, thank you!
Is there some way you can test if this works? Ideally in the testsuite
of course, but that can be hard :-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
--- Comment #15 from Segher Boessenkool ---
(In reply to rsand...@gcc.gnu.org from comment #13)
> (In reply to Segher Boessenkool from comment #12)
> > That patch looks fine, thank you!
> >
> > Is there some way you can test if this works? Idea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
--- Comment #16 from Segher Boessenkool ---
(In reply to Zdenek Sojka from comment #14)
> (In reply to rsand...@gcc.gnu.org from comment #11)
> > Created attachment 48088 [details]
> > Candidate patch
>
> It fixes the build for me.
> I am unable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594
--- Comment #5 from Segher Boessenkool ---
Hi Mike,
Please explain (in the code!) why we need a peephole here, why we cannot
generate the faster code earlier? Or why we choose not to? Etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594
--- Comment #7 from Segher Boessenkool ---
Peepholes catch fewer cases, and it is very hard to write correct peepholes.
The only reason to use peepholes is when the other passes leave some important
optimisation on the table, and you cannot feasi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86715
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #9 from Segher Boessenkool ---
So what causes this TF vs. IF? Cross and native should be exactly the same,
but perhaps there is a difference in the configurations you have for the two?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #13 from Segher Boessenkool ---
If both compilers default to ibmlongdouble, both should use TFmode, no?
|1
CC||segher at gcc dot gnu.org
Last reconfirmed||2020-03-30
--- Comment #2 from Segher Boessenkool ---
Earlier than that, we have
;; Function get_flags (null)
;; enabled by -tree-original
{
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389
--- Comment #3 from Segher Boessenkool ---
The C frontend dumps nothing for -fdump-lang-all, but the C++ frontend
shows (in .002l.raw) that the ?: is optimised to just a constant zero
there, already.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389
--- Comment #5 from Segher Boessenkool ---
The language frontend shouldn't do this kind of code transformations, whether
you think the warning should warn or not here, imo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389
--- Comment #7 from Segher Boessenkool ---
(In reply to felix from comment #6)
> I don’t mind the transformation being applied.
That is not what I said. I said the **language frontend** should not
do this. A language frontend should give an as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420
--- Comment #2 from Segher Boessenkool ---
Reserving a register that already *is* reserved (by the ABI) is undefined,
of course.
But we shouldn't ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420
--- Comment #4 from Segher Boessenkool ---
cprop1 has done
LOCAL COPY-PROP: Replacing reg 2 in insn 7 with reg 118
which is wrong: the insn isn't valid after that. But there is nothing
that expresses that, the "R" constraint "just" becomes uns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420
--- Comment #5 from Segher Boessenkool ---
It is undefined behaviour to access such a register in any way -- sure,
you *can* inspect it, there just is no guarantee at all what value you
will get.
It still is a useful thing to do in debug code an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420
Segher Boessenkool changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
--- Comment #7 fr
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #8 from Segher Boessenkool ---
I put it in the insn condition, testing it now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420
--- Comment #9 from Segher Boessenkool ---
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index dcccb03..11ab745 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -10311,7 +10311,8 @@ (define_in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #39 from Segher Boessenkool ---
commit 07fe4af4d51d74b63a76ea632d4db01d1f69f037
Author: Segher Boessenkool
Date: Wed Mar 18 21:58:45 2020 +
rs6000: Add back some w* constraints (PR91886)
In May and June last year I de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #41 from Segher Boessenkool ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94451
Segher Boessenkool changed:
What|Removed |Added
Priority|P2 |P1
--- Comment #4 from Segher Boess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61837
--- Comment #4 from Segher Boessenkool ---
If the ble 7,.L7 is taken once, it will be taken all of the time, since
cr7 isn't assigned to any more -- and then the whole loop does nothing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94291
--- Comment #7 from Segher Boessenkool ---
Doesn't it still need backports?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94291
--- Comment #9 from Segher Boessenkool ---
You mean you do not have a good enough testcase yet :-( Okay.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61837
--- Comment #6 from Segher Boessenkool ---
But -funswitch-loops is much stronger than we want here, and the wrong
thing to use at -O2 (it often generates *slower* code!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61837
--- Comment #8 from Segher Boessenkool ---
-funswitch-loops changes things like
for (...) {
if (...)
...1;
else
...2;
}
into
if (...) {
for (...)
...1;
} else {
for (...)
...2;
}
which often i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #23 from Segher Boessenkool ---
(cannot_substitute_mem_equiv_p,
"A target hook which returns @code{true} if @var{subst} can't\n\
substitute safely pseudos with equivalent memory values during\n\
register allocation.\n\
I guess "ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
Segher Boessenkool changed:
What|Removed |Added
Target|s390x |s390x powerpc*-*-*
Last reconfirm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94630
--- Comment #6 from Segher Boessenkool ---
Please mention in the TITLE that this is ONLY for the ELFv2 ABI?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420
Segher Boessenkool changed:
What|Removed |Added
Summary|[8/9/10 Regression] ICE |[8/9 Regression] ICE error:
|1
CC||segher at gcc dot gnu.org
Status|UNCONFIRMED |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
--- Comment #2 from Segher Boessenkool ---
If vara is a NaN, this is not the same; it needs -ffinite-math-only.
And in fact adding that option does the trick (on powerpc that is, I
don't have an aarch64 Fortran handy).
Could you check this pleas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
--- Comment #5 from Segher Boessenkool ---
Can you show the -fdump-rtl-combine-all dump where that insn is
created?
It is fine to generate min or max insns here; but you need to handle the
case where vara is NaN: you should return that NaN th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
--- Comment #7 from Segher Boessenkool ---
Can r94 or r93 be NaN there?
(I should build an aarch64 compiler... takes almost a day though :-) )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
--- Comment #10 from Segher Boessenkool ---
(Because it should handle NaNs, and SMAX etc. do not).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
--- Comment #15 from Segher Boessenkool ---
replacing flag_unsafe_math_operations by flag_finite_math_only isn't correct,
but you can add it instead, i.e.
- if ((! FLOAT_MODE_P (mode) || flag_unsafe_math_optimizations)
+ if (!FLOAT_MODE_P (mod
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
1 - 100 of 3228 matches
Mail list logo
