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

            Bug ID: 57230
           Summary: tree-ssa-strlen incorrectly optimizes a strlen to 0
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zackw at panix dot com

GCC 4.7 and 4.8 mis-optimize this test case:

  int main(void)
  {
    char pstring[] = " hello world";
    pstring[0] = (char) (__builtin_strlen(pstring) - 1);
    __builtin_printf("%zd\n", __builtin_strlen(pstring));
    return 0;
  }

The value written to pstring[0] is (char)11, which is nonzero, so both calls to
__builtin_strlen should return 12.  However, tree-ssa-strlen replaces the
second call with a constant 0.

Here are tree dumps right before (-fdump-tree-phiopt2) ...

  main ()
  {
    char pstring[13];
    long unsigned int _3;
    unsigned char _4;
    unsigned char _5;
    char _6;
    long unsigned int _8;

    <bb 2>:
    pstring = " hello world";
    _3 = __builtin_strlen (&pstring);
    _4 = (unsigned char) _3;
    _5 = _4 + 255;
    _6 = (char) _5;
    pstring[0] = _6;
    _8 = __builtin_strlen (&pstring);
    __builtin_printf ("%zd\n", _8);
    pstring ={v} {CLOBBER};
    return 0;
  }

... and right after (-fdump-tree-strlen):

  main ()
  {
    char pstring[13];
    long unsigned int _3;
    unsigned char _4;
    unsigned char _5;
    char _6;
    long unsigned int _8;

    <bb 2>:
    pstring = " hello world";
    _3 = __builtin_strlen (&pstring);
    _4 = (unsigned char) _3;
    _5 = _4 + 255;
    _6 = (char) _5;
    pstring[0] = _6;
    _8 = 0;
    __builtin_printf ("%zd\n", _8);
    pstring ={v} {CLOBBER};
    return 0;
  }

This is both a missed and an incorrect optimization; it should have replaced
the *first* call to __builtin_strlen with 12, and ideally also been able to
figure out that the second call was unaffected by the write to pstring[0]. 
However, only the replacement of the second call with 0 is a correctness issue.

Simplified from Debian #707118
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707118> (which I'm about to
reopen).  Observed with both 4.7.3 and 4.8.0.

Reply via email to