https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710
--- Comment #8 from Segher Boessenkool ---
Patch is bootstrapping.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710
--- Comment #7 from Segher Boessenkool ---
Needs -mvsx -mlittle -O0 to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94708
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2020-04-22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
--- Comment #17 from Segher Boessenkool ---
[ Please don't add other email addresses for me; I get enough mail already,
I don't need all bugzilla mail in duplicate :-) ]
(In reply to z.zhanghaij...@huawei.com from comment #16)
> Ok, I will
|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
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 #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
Status|RESOLVED|REOPENED
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
--- 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
|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
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:
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=94613
Segher Boessenkool changed:
What|Removed |Added
Target|s390x |s390x powerpc*-*-*
Last
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
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
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=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=94291
--- Comment #7 from Segher Boessenkool ---
Doesn't it still need backports?
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=94451
Segher Boessenkool changed:
What|Removed |Added
Priority|P2 |P1
--- Comment #4 from Segher
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=91886
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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
--- 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
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 @@
|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
Segher Boessenkool changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
--- Comment #7
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
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
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=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
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 #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.
|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=87163
--- Comment #13 from Segher Boessenkool ---
If both compilers default to ibmlongdouble, both should use TFmode, no?
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=86715
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |WONTFIX
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
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=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
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?
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
Segher Boessenkool changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
---
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=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=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=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=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=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=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 #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 #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 #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
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 #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 #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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94176
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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
>
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
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=94042
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc64-suse-linux|powerpc*
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=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,
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
|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 #3 from Segher Boessenkool ---
C11 6.6/9 says it *always* is constant, even.
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=94135
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
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=94123
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=94148
Segher Boessenkool changed:
What|Removed |Added
Blocks||94042
Target Milestone|---
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=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 #38 from Segher Boessenkool ---
Then, how did you do that?
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 #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
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 #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
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
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 #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),
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 #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
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=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=49854
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=85170
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=37759
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=81628
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Target
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=86133
Segher Boessenkool changed:
What|Removed |Added
Target Milestone|--- |8.5
901 - 1000 of 3115 matches
Mail list logo
