[Bug tree-optimization/49937] [4.7 Regression] g++.dg/tree-ssa/fwprop-align.C

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
          Component|middle-end                  |tree-optimization
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-09 12:19:20 UTC ---
The folding happens (and is supposed to happen) in CCP for x86_64 (that was
the idea when removing the forwprop duplicate, which has correctness issues,
instead of "fixing" it).

CCP uses get_value_from_alignment, the difference between x86_64 and the
cross is:

Visiting statement:
D.2090_3 = (long int) foo;
which is likely CONSTANT
Lattice value changed to CONSTANT Lattice value changed to CONSTANT
0x00000000000000000 (0xfffffffffffffffffffffffffffffffe).  Adding SSA edges to
worklist.

Visiting statement:
D.2091_4 = D.2090_3 & 1;
which is likely CONSTANT
Lattice value changed to CONSTANT 0.  Adding SSA edges to worklist.

vs. cris:

Visiting statement:
D.1722_3 = (long int) foo;
which is likely CONSTANT
Lattice value changed to VARYING.  Adding SSA edges to worklist.

Visiting statement:
D.1723_4 = D.1722_3 & 1;
which is likely CONSTANT
Lattice value changed to CONSTANT Lattice value changed to CONSTANT
0x00000000000000000 (0x00000000000000001).  Adding SSA edges to worklist.

which is because

  else if (base
           && ((align = get_object_alignment (base, BIGGEST_ALIGNMENT))
                > BITS_PER_UNIT))

even though the FUNCTION_DECL has align 16, BIGGEST_ALIGNMENT is 8 on cris
(which means we can't rely on any DECL_ALIGN or other stuff
get_object_alignment
uses if it is bigger than that value?).

Thus, the get_object_alignment_1 hunk

  if (DECL_P (exp)
      && TREE_CODE (exp) != LABEL_DECL)
    {
      if (TREE_CODE (exp) == FUNCTION_DECL)
        {
          /* Function addresses can encode extra information besides their
             alignment.  However, if TARGET_PTRMEMFUNC_VBIT_LOCATION
             allows the low bit to be used as a virtual bit, we know
             that the address itself must be 2-byte aligned.  */
          if (TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_pfn)
            align = 2 * BITS_PER_UNIT;
          else
            align = BITS_PER_UNIT;
        }

is non-functional for cris.

>From looking at the docs for BIGGEST_ALIGNMENT I wonder why we use that
for all callers of get_object_alignment and not, for example,
MAX_OFILE_ALIGNMENT?

CCP certainly doesn't care - as long as it can trust the value returned.
CCP wants to use get_object_alignment_1 anyway.

hp, can you maybe answer the question about correctness for aligns
bigger than BIGGEST_ALIGNMENT?  And eventually audit other callers?