https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #52 from Shaohua Li ---
*** Bug 107257 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #51 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:69185294f322dd53d4e1592115014c5488302e2e
commit r14-1405-g69185294f322dd53d4e1592115014c5488302e2e
Author: Roger Sayle
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #48 from H.J. Lu ---
(In reply to Roger Sayle from comment #47)
> I really don't believe that using UNSPEC here is the correct way to go, but
> it appears to be the (only?) approach that Segher is prepared to approve.
> Hohum.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #47 from Roger Sayle ---
I really don't believe that using UNSPEC here is the correct way to go, but it
appears to be the (only?) approach that Segher is prepared to approve. Hohum.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #46 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:0e36a9c6915c713d30016cbade97a4b31dcc1350
commit r13-3530-g0e36a9c6915c713d30016cbade97a4b31dcc1350
Author: H.J. Lu
Date: Thu Oct 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #45 from Segher Boessenkool ---
Yes, that is fine afaics.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #44 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #42)
> (In reply to H.J. Lu from comment #41)
> > (In reply to Segher Boessenkool from comment #40)
> > > Let me repeat: A const_int cannot be assigned to a MODE_CC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
Andrew Pinski changed:
What|Removed |Added
CC||shaohua.li at inf dot ethz.ch
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #42 from Segher Boessenkool ---
(In reply to H.J. Lu from comment #41)
> (In reply to Segher Boessenkool from comment #40)
> > Let me repeat: A const_int cannot be assigned to a MODE_CC. It has no
> > meaning.
> > This is invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #41 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #40)
> Let me repeat: A const_int cannot be assigned to a MODE_CC. It has no
> meaning.
> This is invalid RTL. If it ever works, or worked, that is an accident.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #40 from Segher Boessenkool ---
Let me repeat: A const_int cannot be assigned to a MODE_CC. It has no meaning.
This is invalid RTL. If it ever works, or worked, that is an accident.
A MODE_CC stands for a comparison (in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #39 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #38)
> You cannot put a const_int in a MODE_CC. It is meaningless.
Reg 17 in
(insn 49 10 50 2 (parallel [
(set (reg:CCC 17 flags)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #38 from Segher Boessenkool ---
You cannot put a const_int in a MODE_CC. It is meaningless.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #37 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #33)
> (In reply to H.J. Lu from comment #32)
> > > There is no actual comparison with 0, that is just notation.
> >
> > True. But simplify-rtx.cc simplifies
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #36 from Richard Biener ---
*** Bug 107273 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #35 from Richard Biener ---
*** Bug 107269 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #34 from Hongtao.liu ---
There's 2 similar issues in PR107273 and PR107269.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #33 from Segher Boessenkool ---
(In reply to H.J. Lu from comment #32)
> > There is no actual comparison with 0, that is just notation.
>
> True. But simplify-rtx.cc simplifies
>
> (ltu (reg 17) (const_int 0))
>
> to false when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #32 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #30)
> (In reply to H.J. Lu from comment #26)
> > LTU/GEU are only used to check FLAGS_REG against constant 0.
>
> That is not what
> (ltu (reg 17) (const_int 0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #31 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #29)
> (In reply to Hongtao.liu from comment #23)
> > looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
> > (reg:CCCmode FLAG_REG) (const_int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #30 from Segher Boessenkool ---
(In reply to H.J. Lu from comment #26)
> LTU/GEU are only used to check FLAGS_REG against constant 0.
That is not what
(ltu (reg 17) (const_int 0))
means though?
Together with a previous
(set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #29 from Segher Boessenkool ---
(In reply to Hongtao.liu from comment #23)
> looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
> (reg:CCCmode FLAG_REG) (const_int 0)) means get carry flag.
> Not (LTU:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #28 from Segher Boessenkool ---
> So the issue is with the consumer:
>
> (insn 50 49 51 2 (parallel [
> (set (reg:SI 93)
> (neg:SI (ltu:SI (reg:CCC 17 flags)
> (const_int 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #27 from H.J. Lu ---
Another oddity is
(set (pc) (if_then_else
(eq (reg:CCO FLAGS_REG) (const_int 0))
(label_ref (match_operand 3))
(pc)))]
CCOmode means that the overflow flag is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #26 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #24)
> (In reply to Hongtao.liu from comment #23)
> > looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
> > (reg:CCCmode FLAG_REG) (const_int 0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #25 from Hongtao.liu ---
(In reply to Uroš Bizjak from comment #24)
> (In reply to Hongtao.liu from comment #23)
> > looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
> > (reg:CCCmode FLAG_REG) (const_int 0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #24 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #23)
> looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
> (reg:CCCmode FLAG_REG) (const_int 0)) means get carry flag.
> Not (LTU: (REG:CCCmode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #23 from Hongtao.liu ---
looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
(reg:CCCmode FLAG_REG) (const_int 0)) means get carry flag.
Not (LTU: (REG:CCCmode FLAGS_REG) (const_int 0)).
Now I got more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #22 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #21)
> (In reply to Hongtao.liu from comment #19)
> > (In reply to H.J. Lu from comment #18)
> > > (In reply to Segher Boessenkool from comment #16)
> > > > Hi Roger,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #21 from Segher Boessenkool ---
(In reply to Hongtao.liu from comment #19)
> (In reply to H.J. Lu from comment #18)
> > (In reply to Segher Boessenkool from comment #16)
> > > Hi Roger,
> > >
> > > (In reply to Roger Sayle from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #20 from Hongtao.liu ---
> generate:
> testl %edi, %edi
> movl$1, %edx
> movl$-1, %eax
> cmove %edx, %eax
>
> origin:
> negl%edi
> sbbl%eax, %eax
> orl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #19 from Hongtao.liu ---
(In reply to H.J. Lu from comment #18)
> (In reply to Segher Boessenkool from comment #16)
> > Hi Roger,
> >
> > (In reply to Roger Sayle from comment #15)
> > > Yes, a COMPARE rtx can be used to set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #18 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #16)
> Hi Roger,
>
> (In reply to Roger Sayle from comment #15)
> > Yes, a COMPARE rtx can be used to set various flags on x86, but many other
> > operations also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #17 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #14)
> (In reply to H.J. Lu from comment #13)
> > (In reply to Segher Boessenkool from comment #12)
> > >
> > > To determine the semantics of this piece of RTL you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #16 from Segher Boessenkool ---
Hi Roger,
(In reply to Roger Sayle from comment #15)
> Yes, a COMPARE rtx can be used to set various flags on x86, but many other
> operations also legitimately set and/or use MODE_CC, often in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #14 from Segher Boessenkool ---
(In reply to H.J. Lu from comment #13)
> (In reply to Segher Boessenkool from comment #12)
> >
> > To determine the semantics of this piece of RTL you need to see the
> > setter(s)
> > of reg 17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #13 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #12)
>
> To determine the semantics of this piece of RTL you need to see the setter(s)
> of reg 17 feeding this use. In this case, the setter was
> (set (reg:CCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #12 from Segher Boessenkool ---
(In reply to H.J. Lu from comment #11)
> Assuming (reg:CCC 17 flags) is set to 1 by compare properly, how should
A MODE_CC RTL reg is never set to "1". It is set to the result of a
comparison,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #11 from H.J. Lu ---
Assuming (reg:CCC 17 flags) is set to 1 by compare properly, how should
(insn 50 49 51 2 (parallel [
(set (reg:SI 93)
(neg:SI (ltu:SI (reg:CCC 17 flags)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #10 from Segher Boessenkool ---
The input to combine has
(insn 49 10 50 2 (parallel [
(set (reg:CCC 17 flags)
(ne:CCC (reg:SI 82 [ a.1_2 ])
(const_int 0 [0])))
(set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #9 from H.J. Lu ---
(In reply to Segher Boessenkool from comment #7)
> Please show the (relevant part of) output of -fdump-rtl-combine-all ? At
> least
> those parts where it decided (ltu:SI (const_int 1) (const_int 0)) is valid
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #8 from Segher Boessenkool ---
Bah, scratch that last part, of course it is valid (I thought this was using 0
in a MODE_CC but I just cannot read).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #6 from Roger Sayle ---
This sounds related to the discussion/patch originally proposed at
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598040.html
and then revised (based on reviewer comments) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #5 from H.J. Lu ---
i386 needs to change
(ltu:SI (const_int 1 [1])
(const_int 0 [0]))
to
(ne:SI (const_int 1 [1])
(const_int 0 [0]))
when checking the carry flag. But the mode info isn't passed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
49 matches
Mail list logo
