https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #27 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:465a9c51e7d5bafa7a81195b5af20f2a54f22210
commit r13-5652-g465a9c51e7d5bafa7a81195b5af20f2a54f22210
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #26 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #25)
> Now, I believe the fix was incorrect and the other PR has all the details on
> it.
S/Now/No/, ouch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #25 from Jakub Jelinek ---
Now, I believe the fix was incorrect and the other PR has all the details on
it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #24 from Segher Boessenkool ---
So this PR can be marked resolved now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #23 from Jakub Jelinek ---
See PR108463 and
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610778.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #22 from Joseph S. Myers ---
The fix introduced a regression building glibc for ia64-linux-gnu, see bug
108484.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #21 from Segher Boessenkool ---
As far as we (me, you; everybody) can tell it is fixed now. If one day we get
a testcase showing it has in fact not been fixed, the problem is still there,
we can reopen or link the testcases or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #20 from Alexandre Oliva ---
The bug is now either fixed or latent in the trunk, I'm not sure which, because
I have not got as far as figuring out why removing unnecessary address cselib
lookups in debug insns made a difference to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #19 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:3c99493bf39a7fef9213e6f5af94b78bb15fcfdc
commit r13-5252-g3c99493bf39a7fef9213e6f5af94b78bb15fcfdc
Author: Alexandre Oliva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #18 from Jakub Jelinek ---
Thanks for looking into this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #17 from Alexandre Oliva ---
Created attachment 54272
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54272=edit
patch that fixes the problem for reasons not fully understood
It seems that looking up the MEM exprs in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #16 from Alexandre Oliva ---
Sorry it took me so long to react, I'd missed the question.
IIRC the scheduler was the hardest part of GCC to make work with debug insns.
The general strategy is that nondebug insns never depend on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #15 from Segher Boessenkool ---
Yup. I don't consider DEBUG_INSNs to be scheduled at all, only real things
are, but that is just vague terminology :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #14 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #13)
> DEBUG_INSNs should never influence any scheduling decisions, or any other
> decisions that influence what machine code we generate.
Well, with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #13 from Segher Boessenkool ---
DEBUG_INSNs should never influence any scheduling decisions, or any other
decisions that influence what machine code we generate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #12 from Jakub Jelinek ---
Alex, please correct me if I'm wrong, but I think the scheduling DEBUG_INSN
decision was that DEBUG_INSNs are somehow taken into account during scheduling,
not completely ignored, so that they actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #10 from H.J. Lu ---
(In reply to Roger Sayle from comment #9)
> I'm curious why the zero_extend behaves so differently to a sign_extend,
> perhaps a missing simplification or pattern. Presumably the CONCAT in the
> debug_insn is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #9 from Roger Sayle ---
I'm curious why the zero_extend behaves so differently to a sign_extend,
perhaps a missing simplification or pattern. Presumably the CONCAT in the
debug_insn is there whether or not a sign_extend or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #8 from H.J. Lu ---
(In reply to H.J. Lu from comment #3)
> This debug INSN:
>
> (debug_insn 29 28 30 2 (var_location:BLK D#2 (concatn:BLK [
> (mem/j:SI (plus:DI (plus:DI (ashift:DI (zero_extend:DI (and:SI
> (mem:SI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #7 from H.J. Lu ---
Specifically,
/* We can canonicalize SIGN_EXTEND (op) as ZERO_EXTEND (op) when
we know the sign bit of OP must be clear. */
if (val_signbit_known_clear_p (GET_MODE (op),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
H.J. Lu changed:
What|Removed |Added
CC||richard.sandiford at arm dot
com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #5 from H.J. Lu ---
(In reply to H.J. Lu from comment #4)
> This simple change:
>
> diff --git a/gcc/config/i386/i386-modes.def b/gcc/config/i386/i386-modes.def
> index e2e1e18d24d..b49daaef253 100644
> ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #4 from H.J. Lu ---
This simple change:
diff --git a/gcc/config/i386/i386-modes.def b/gcc/config/i386/i386-modes.def
index e2e1e18d24d..b49daaef253 100644
--- a/gcc/config/i386/i386-modes.def
+++ b/gcc/config/i386/i386-modes.def
@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #3 from H.J. Lu ---
This debug INSN:
(debug_insn 29 28 30 2 (var_location:BLK D#2 (concatn:BLK [
(mem/j:SI (plus:DI (plus:DI (ashift:DI (zero_extend:DI (and:SI
(mem:SI (plus:DI (reg/f:DI 7 sp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #2 from H.J. Lu ---
A slight change in the variable makes the problem to go away. It looks
like a latent bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
Martin Liška changed:
What|Removed |Added
CC||lingling.kong7 at gmail dot
com,
29 matches
Mail list logo
