This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/54547] [4.8 regression] FAIL: gcc.dg/tree-ssa/pr37508.c scan-tree-dump-times vrp1 "Folding" 3


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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |
   Target Milestone|---                         |4.8.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2012-11-28 09:52:42 UTC ---
I seem to remember the test is quite fragile even on x86 (though it passes
there at the moment).  It depends on whether fold converted some of the
memory accesses to BIT_FIELD_REFs or not.

For x86 we see:

test1 (struct foo1 * x)
{
  int _1;
  unsigned char _4;
  unsigned char _5;
  unsigned char _6;

  <bb 2>:
  _4 = BIT_FIELD_REF <*x_3(D), 8, 0>;
  _5 = _4 & 1;
  if (_5 == 0)
    goto <bb 5>;
  else
    goto <bb 3>;

  <bb 3>:
  _6 = ASSERT_EXPR <_5, _5 != 0>;


but for arm:

test1 (struct foo1 * x)
{
  int _1;
  <unnamed-signed:1> _4;
  <unnamed-signed:1> _5;

  <bb 2>:
  _4 = x_3(D)->i;
  if (_4 != 0)
    goto <bb 3>;
  else
    goto <bb 5>;

  <bb 3>:
  _5 = ASSERT_EXPR <_4, _4 != 0>;
  if (_5 == -1)

and for x86 we get then
Found new range for _6: [1, 1]
while arm has
Found new range for _5: ~[0, +INF]

(it prefers ~[0,0] over [-1,-1], but doesn't know to simplify
~[0,0] == -1 for 1-bit ranges).  I'll try to fix that.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]