This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/82628] [8 Regression] wrong code at -Os on x86_64-linux-gnu in the 32-bit mode
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 20 Oct 2017 19:03:39 +0000
- Subject: [Bug rtl-optimization/82628] [8 Regression] wrong code at -Os on x86_64-linux-gnu in the 32-bit mode
- Auto-submitted: auto-generated
- References: <bug-82628-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82628
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, for the -1UL <= 1UL comparison, the cmpl instruction sets the CF, and then
sbbl subtracts -1U (2nd operand) + 1U (CF) from 0U (1st operand/destination)
and sets CF flag, but the RTL representation of this, i.e. comparison of (2nd
operand + CF) and (1st operand), i.e. 0 and 0, doesn't set the CF.
From the description of SBBL, it is unclear if it sets CF according to
op1 - (SImode) (op2 + CF) or (DImode) op1 - ((DImode) op2 + CF), but from the
above it looks like in order to do this we rely on the latter, i.e. it is
actually 0 - (0xffffffffULL + 1) == 0 - 0x100000000ULL = 0 with CF.
So, do we need to represent it differently in the instruction, as comparison in
twice as wide mode? I think we'd then need different patterns for signed and
unsigned comparisons, one would sign-extend, the other zero-extend, and then
perhaps just use CCOmode or CCZmode.
Do we need to fix also subborrow<mode>? What about the addcarry<mode>?