public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/58726] [4.7/4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu (affecting trunk/4.7/4.6, but not 4.8)
Date: Tue, 03 Dec 2013 19:25:00 -0000	[thread overview]
Message-ID: <bug-58726-4-2NnqtZp6af@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-58726-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58726

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Testcase suitable for gcc.c-torture/execute/:

int a, c;
union { int f1; int f2 : 1; } b;

short
foo (short p)
{
  return p < 0 ? p : a;
}

int
main ()
{
  if (sizeof (short) * __CHAR_BIT__ != 16
      || sizeof (int) * __CHAR_BIT__ != 32)
    return 0;
  b.f1 = 56374;
  unsigned short d;
  int e = b.f2;
  d = e == 0 ? b.f1 : 0;
  c = foo (d);
  if (c != (short) 56374)
    __builtin_abort ();
  return 0;
}

This seems to be a bug in the combiner, during combination of:
(gdb) p debug_rtx (i3)
(insn 22 21 23 2 (parallel [
            (set (reg:CCGOC 17 flags)
                (compare:CCGOC (and:HI (reg/v:HI 83 [ d ])
                        (const_int -9162 [0xffffffffffffdc36]))
                    (const_int 0 [0])))
            (set (reg:HI 85 [ D.1789 ])
                (and:HI (reg/v:HI 83 [ d ])
                    (const_int -9162 [0xffffffffffffdc36])))
        ]) pr58726.c:7 395 {*andhi_2}
     (expr_list:REG_DEAD (reg/v:HI 83 [ d ])
        (nil)))
(gdb) p debug_rtx (i2)
(insn 55 54 56 2 (parallel [
            (set (subreg:SI (reg/v:HI 83 [ d ]) 0)
                (if_then_else:SI (ltu:SI (reg:CC 17 flags)
                        (const_int 0 [0]))
                    (const_int -1 [0xffffffffffffffff])
                    (const_int 0 [0])))
            (clobber (reg:CC 17 flags))
        ]) pr58726.c:19 925 {*x86_movsicc_0_m1}
     (expr_list:REG_DEAD (reg:CC 17 flags)
        (expr_list:REG_UNUSED (reg:CC 17 flags)
            (nil))))
(gdb) p debug_rtx (i1)
(insn 54 15 55 2 (set (reg:CC 17 flags)
        (compare:CC (reg:QI 98 [ D.1788 ])
            (const_int 1 [0x1]))) pr58726.c:19 5 {*cmpqi_1}
     (expr_list:REG_DEAD (reg:QI 98 [ D.1788 ])
        (nil)))
The problem is that reg:HI 83 is substed multiple twice (with unique_copy == 0)
and apparently force_to_mode seems to destructively modify the expression,
which is shared, around line 8533.  On the second occurrence it is first
force_to_mode'd with mask 0xdc36, and on the first occurrence later on
simplify_comparison performs:
11187          /* If this is a sign bit comparison and we can do arithmetic in
11188         MODE, say that we will only be needing the sign bit of OP0.  */
11189          if (sign_bit_comparison_p && HWI_COMPUTABLE_MODE_P (mode))
11190        op0 = force_to_mode (op0, mode,
11191                     (unsigned HOST_WIDE_INT) 1
11192                     << (GET_MODE_PRECISION (mode) - 1),
11193                     0);
with mask 0x8000, which destructively modifies also the second occurrence.
So the question is, do we have to copy_rtx always just in case, or should some
routines (e.g. force_to_mode) be documented as not modifying the argument in
place?  I guess this issue can be fixed easily just by changing those two
SUBSTs at the end of force_to_mode in IF_THEN_ELSE handling (and there is
another one for ROTATE{,RT}), but the question is if we don't have tons of
similar latent issues.  The changes in place were done using SUBST, so if we
undo_all, they are properly reverted, the problem is when they aren't reverted,
as in this case.


  parent reply	other threads:[~2013-12-03 19:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-14 18:38 [Bug rtl-optimization/58726] New: " su at cs dot ucdavis.edu
2013-10-15  8:22 ` [Bug rtl-optimization/58726] [4.7/4.8/4.9 Regression] " rguenth at gcc dot gnu.org
2013-10-18 19:55 ` mikpelinux at gmail dot com
2013-11-05 15:03 ` rguenth at gcc dot gnu.org
2013-12-03 19:25 ` jakub at gcc dot gnu.org [this message]
2013-12-03 19:51 ` jakub at gcc dot gnu.org
2013-12-04 11:25 ` jakub at gcc dot gnu.org
2013-12-04 15:51 ` jakub at gcc dot gnu.org
2013-12-04 15:56 ` [Bug rtl-optimization/58726] [4.7 " jakub at gcc dot gnu.org
2013-12-11 15:17 ` ebotcazou at gcc dot gnu.org
2014-02-22  8:57 ` ebotcazou at gcc dot gnu.org
2014-10-23  6:08 ` pinskia at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-58726-4-2NnqtZp6af@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).