[Bug c/57915] New: ICE in set_address_disp, at rtlanal.c:5537

[Bug c/57915] New: ICE in set_address_disp, at rtlanal.c:5537

[etienne_lorrain at yahoo dot fr]

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

            Bug ID: 57915
           Summary: ICE in set_address_disp, at rtlanal.c:5537
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: etienne_lorrain at yahoo dot fr

On latest Fedora, with: gcc version 4.8.1 20130603 (Red Hat 4.8.1-1) (GCC)
I get:
  $ /usr/bin/gcc -m32 -Os bug.c
  bug.c: In function ‘menu’:
  bug.c:59:1: internal compiler error: in set_address_disp, at rtlanal.c:5537
   }
   ^
  Please submit a full bug report,

possibly related to  asm(... "X" (*str)) , I use "X" mostly because I had
problems using "m" when the pointer points to local variable on the stack.
The problem do not exists with previous compiler versions, not a new code.

The simplified source code I finished to get after few hours is:

$ cat bug.c
extern inline const char *
_strnchr (const char *str, char c, unsigned size)
{
  asm ("cld ; repne scasb %%es:(%%edi),%%al"
    : "+c" (size), "+D" (str): "a" (c), "X" (*str):"cc");
  return str - 1;
}

extern inline unsigned
strlen (const char *str)
{
  return _strnchr (str, '\0', (~0)) - str;
}

extern inline void
_strncpy (char *dst, const char *src, unsigned nb)
{

  unsigned len = strlen (src);
  if (len > nb)
    len = nb;

  __builtin_memcpy (dst, src, len);
  dst[len] = '\0';

}

extern inline char *
strcpy (char *dst, const char *src)
{
  _strncpy (dst, src, (~0));
  return dst;
}

typedef struct
{
  char go_msg[8];
  char scanpath[16];
} gujin_param_t;

extern gujin_param_t copy_gujin_param;
enum { kernel_bottom_menu, setup_bottom_menu } type;

unsigned short getkey(void);
unsigned timeout;
unsigned menu (void)
{
    char local_scanpath[sizeof (copy_gujin_param.scanpath)];
    strcpy (local_scanpath, copy_gujin_param.scanpath);

    for (;;)
      {
    unsigned short key = getkey();
    if ((type == kernel_bottom_menu) ? (key == (0x1312)) : key == (0x3900 | '
'))
      {
        strcpy (local_scanpath, copy_gujin_param.scanpath);
      }
      }
}

Regards, Etienne.
>From gcc-bugs-return-426303-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 17 01:57:56 2013
Return-Path: <gcc-bugs-return-426303-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10970 invoked by alias); 17 Jul 2013 01:57:56 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8339 invoked by uid 48); 17 Jul 2013 01:55:53 -0000
From: "brooks at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
Date: Wed, 17 Jul 2013 01:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: brooks at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-56888-4-TOHFjIRoyt@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56888-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56888-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00810.txt.bz2
Content-length: 979

http://gcc.gnu.org/bugzilla/show_bug.cgi?idV888

Brooks Moses <brooks at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brooks at gcc dot gnu.org

--- Comment #10 from Brooks Moses <brooks at gcc dot gnu.org> ---
FWIW, this issue also affected GLIBC.  Pointer to discussion, along with fixes,
here:
http://sourceware.org/ml/libc-alpha/2013-07/msg00306.html

It seems to me -- based on my own experience, as well as Max's -- that the
-ftree-distribute-patterns documentation could be notably improved.  In my
case, I read it clearly and understood it to mean that it was only responsible
for the loop-distribution portion of the rearrangement in the code examples,
and that the replacement of a loop by a memcpy call was some other optimization
pass.

Other than the documentation issues, this seems like a non-bug.

[Bug rtl-optimization/57915] [4.8/4.9 Regression] ICE in set_address_disp, at rtlanal.c:5537

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Somewhat reduced...

void
bar (int *dst, int *src)
{
  asm ("cld ; repne scasb %%es:(%%edi),%%al": "+c" (dst), "+DaX" (*src));
}

struct
{
  int a;
  int p[];
} s;

void
foo (void)
{
  while (1)
    bar (0, s.p);
}

[Bug rtl-optimization/57915] [4.8/4.9 Regression] ICE in set_address_disp, at rtlanal.c:5537

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r192719 aka LRA merge.
extern struct T { char a[8]; char b[16]; } t;
int c;
void foo (void);

extern inline char *
baz (char *x, const char *y)
{
  const char *e = y;
  unsigned long f, g;
  asm ("repne scasb" : "+c" (f), "+D" (e) : "a" ('\0'), "X" (*e));
  g = e - 1 - y;
  __builtin_memcpy (x, y, g);
  x[g] = '\0';
  return x;
}

void
bar (void)
{
  char d[16];
  baz (d, t.b);

  for (;;)
    {
      foo ();
      if (c)
        baz (d, t.b);
    }
}

[Bug rtl-optimization/57915] [4.8/4.9 Regression] ICE in set_address_disp, at rtlanal.c:5537

[vmakarov at redhat dot com]

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

Vladimir Makarov <vmakarov at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at redhat dot com

--- Comment #4 from Vladimir Makarov <vmakarov at redhat dot com> ---
The address in question is

(plus (symbol_ref ...) (const_int 4))

LRA finds two displacements (symbol_ref and const_int) although only one
displacement is allowed.

The correct canonical address should be:

(const (plus (symbol_ref ...) (const_int 4)))

Non-canonical address is created from

(reg ...)

by 1st constant propagation pass (cprop1).

I believe the problem should be fixed there.

As for reload pass, it has code transforming address (plus some const some
const) into (const (plus some const some const)).  It was probably a problem
fix in a wrong place.  There is no need to complicate LRA more and implement
analogous code in LRA.  As I wrote I believe it should be fixed in cprop1 by
generating the correct canonical address.

[Bug rtl-optimization/57915] [4.8/4.9 Regression] ICE in set_address_disp, at rtlanal.c:5537

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |i?86-*-*
   Target Milestone|---                         |4.8.3

[Bug rtl-optimization/57915] [4.8/4.9 Regression] ICE in set_address_disp, at rtlanal.c:5537

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Still happens.

[Bug rtl-optimization/57915] [4.8/4.9 Regression] ICE in set_address_disp, at rtlanal.c:5537

[abel at gcc dot gnu.org]

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

Andrey Belevantsev <abel at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |abel at gcc dot gnu.org

--- Comment #6 from Andrey Belevantsev <abel at gcc dot gnu.org> ---
The cprop pass doesn't care much in this case, it only passes the resulting set
to simplify_rtx which does nothing.  Fwprop does the right thing with the
similar insn (insn 9) but doesn't work for insn in question (insn 58) because
it is inside the loop:

1466      Do not forward propagate addresses into loops until after unrolling.
1467      CSE did so because it was able to fix its own mess, but we are not. 
*/

But come on, in this case the def/use are in the same basic block(!) so this
stuff not fixed by fwprop is later fixed (wrongly) by _local_ cprop.  Fwprop2
is supposed to fix this but it surely runs after the 1st cprop so it doesn't
have a chance.

So either we:

1) drop the loop check altogether -- forward_propagate_into already has code
not to propagate into the inner loop; this might be too risky as I don't know
all reasons of why the first fwprop does not propagate inside loops;

2) allow at least propagating into the same blocks to offset the local cprop
code as in the below patch;

3) teach cprop to leave it for the second fwprop_addr -- but there's a lot of
stuff happening in between;

4) teach cprop to simplify rtxes in line with the fwprop's propagate rtx code,
i.e. diving inside and when looking at a mem, pass its address to
simplify_gen_binary and other address-related things.

The below patch is the simplest option 2) and fixes the test case.

diff --git a/gcc/fwprop.c b/gcc/fwprop.c
index 4317f51..c62a501 100644
--- a/gcc/fwprop.c
+++ b/gcc/fwprop.c
@@ -1469,11 +1469,14 @@ fwprop (void)
   for (i = 0; i < DF_USES_TABLE_SIZE (); i++)
     {
       df_ref use = DF_USES_GET (i);
+      df_ref def;
       if (use)
     if (DF_REF_TYPE (use) == DF_REF_REG_USE
         || DF_REF_BB (use)->loop_father == NULL
         /* The outer most loop is not really a loop.  */
-        || loop_outer (DF_REF_BB (use)->loop_father) == NULL)
+        || loop_outer (DF_REF_BB (use)->loop_father) == NULL
+        || ((def = get_def_for_use (use))
+        && DF_REF_BB (use) == DF_REF_BB (def)))
       need_cleanup |= forward_propagate_into (use);
     }

[Bug rtl-optimization/57915] [4.8/4.9 Regression] ICE in set_address_disp, at rtlanal.c:5537

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'd say if (plus:SI (symbol_ref:SI ...) (const_int ...)) not surrounded by
(const:SI ) is considered invalid IL, then trying to workaround cprop bug in
some other pass is still workaround rather than fix.
So, either we make sure that it is simplified (will attach an untested patch
for that), or do some minimal sanity checking for 'X' operands in
asm_operand_ok (basically verify it is valid RTL, say start with testing for
this missing CONST), or both.

[Bug rtl-optimization/57915] [4.8/4.9 Regression] ICE in set_address_disp, at rtlanal.c:5537

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 32001
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32001&action=edit
gcc49-pr57915.patch

Untested fix.

[Bug rtl-optimization/57915] [4.8/4.9 Regression] ICE in set_address_disp, at rtlanal.c:5537

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Tue Feb  4 12:14:52 2014
New Revision: 207460

URL: http://gcc.gnu.org/viewcvs?rev=207460&root=gcc&view=rev
Log:
    PR rtl-optimization/57915
    * recog.c (simplify_while_replacing): If all unary/binary/relational
    operation arguments are constant, attempt to simplify those.

    * gcc.target/i386/pr57915.c: New test.

Added:
    trunk/gcc/testsuite/gcc.target/i386/pr57915.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/recog.c
    trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/57915] [4.8 Regression] ICE in set_address_disp, at rtlanal.c:5537

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
      Known to work|                            |4.9.0
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
            Summary|[4.8/4.9 Regression] ICE in |[4.8 Regression] ICE in
                   |set_address_disp, at        |set_address_disp, at
                   |rtlanal.c:5537              |rtlanal.c:5537
      Known to fail|4.9.0                       |

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

[Bug rtl-optimization/57915] [4.8 Regression] ICE in set_address_disp, at rtlanal.c:5537

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57915

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.3                       |4.8.4

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 4.8.3 is being released, adjusting target milestone.

[Bug rtl-optimization/57915] [4.8 Regression] ICE in set_address_disp, at rtlanal.c:5537

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57915

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.

[Bug rtl-optimization/57915] [4.8 Regression] ICE in set_address_disp, at rtlanal.c:5537

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57915

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|4.8.5                       |4.9.0
      Known to fail|                            |4.8.5

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed for 4.9.0.