[Bug tree-optimization/16437] New c-torture failures after bitfield patch

["jsm at polyomino dot org dot uk" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From jsm at polyomino dot org dot uk  2004-07-08 15:57 -------
Subject: Re:  New: New c-torture failures after
 bitfield patch

On Thu, 8 Jul 2004, dnovillo at gcc dot gnu dot org wrote:

> gcc.c-torture/execute/991118-1.c and gcc.c-torture/execute/bf64-1.c started
> failing after the fix for PR2511 and PR3325 went into mainline.

Those are the ones that (on i686-pc-linux-gnu, where they don't now fail,
and before tree-ssa) prompted the changes to expr.c because
shorten_compare created trees that confused expand_expr (now
gcc.c-torture/execute/bitfld-3.c tests directly and more thoroughly that
arithmetic on these bit-field types is working properly and serves to show
the need for the expr.c changes).  My original analysis of this is at
<http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00651.html>, but given this:

> We are getting confused very early on.  Probably in fold.  Here's a diff between
> the bad .03.original (-) and the good .03.original dumps (+).

the problem here is clearly something entirely separate, which I'll
investigate.  Does the cut-down bf64-1.c

struct tmp
{
  long long int pad : 12;
  long long int field : 52;
};

main()
{
  struct tmp tmp = {0x123, 0xFFF000FFF000FLL};

  if (tmp.field != 0xFFFFFF000FFF000FLL)
    abort();

  exit (0);
}

from my previous message also fail now?  If so, that should speed up
investigating this one.  If not, I'll start from the full bf64-1.c.



-- 


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