[Bug tree-optimization/63828] New: g++.dg/ipa/devirt-47.C fails for x32

[Bug tree-optimization/63828] New: g++.dg/ipa/devirt-47.C fails for x32

[hjl.tools at gmail dot com]

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

            Bug ID: 63828
           Summary: g++.dg/ipa/devirt-47.C fails for x32
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
                CC: hubicka at ucw dot cz

On x32, g++.dg/ipa/devirt-47.C fails:

FAIL: g++.dg/ipa/devirt-47.C  -std=gnu++11  scan-ipa-dump-times inline
"Discovered a virtual call to a known target[^\\\\n]*C::_ZTh" 1
FAIL: g++.dg/ipa/devirt-47.C  -std=gnu++14  scan-ipa-dump-times inline
"Discovered a virtual call to a known target[^\\\\n]*C::_ZTh" 1
FAIL: g++.dg/ipa/devirt-47.C  -std=gnu++98  scan-ipa-dump-times inline
"Discovered a virtual call to a known target[^\\\\n]*C::_ZTh" 1
FAIL: g++.dg/guality/pr55665.C   -O2  line 23 p == 40

The problem is in possible_placement_new

bool
possible_placement_new (tree type, tree expected_type,
                        HOST_WIDE_INT cur_offset)
{
  return ((TREE_CODE (type) != RECORD_TYPE
           || !TYPE_BINFO (type)
           || cur_offset >= BITS_PER_WORD
           || !polymorphic_type_binfo_p (TYPE_BINFO (type)))
          && (!TYPE_SIZE (type)
              || !tree_fits_shwi_p (TYPE_SIZE (type))
              || (cur_offset
                  + (expected_type ? tree_to_uhwi (TYPE_SIZE (expected_type))
                     : GET_MODE_BITSIZE (Pmode))
                  <= tree_to_uhwi (TYPE_SIZE (type)))));
}

When cur_offset is 32, cur_offset >= BITS_PER_WORD is false since
BITS_PER_WORD is 64 for x32.  We got

ipa-prop: Discovered a virtual call to a speculative target (void test(A*)/5 ->
virtual int C::_ZThn4_N1C3fooEv()/4), for stmt _6 = OBJ_TYPE_REF(_4;a_2(D)->0)
(a_2(D));

instead of "known target".  What is the significance of BITS_PER_WORD here?

[Bug tree-optimization/63828] g++.dg/ipa/devirt-47.C fails for x32

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I notice this and many other failures devirt related failures with ILP32 on
aarch64-elf.

[Bug tree-optimization/63828] [5 Regression] g++.dg/ipa/devirt-47.C fails for x32

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization,
                   |                            |wrong-code
             Target|                            |x86_64-*-* (x32); aarch64-*
                   |                            |(ilp32)
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-12
   Target Milestone|---                         |5.0
            Summary|g++.dg/ipa/devirt-47.C      |[5 Regression]
                   |fails for x32               |g++.dg/ipa/devirt-47.C
                   |                            |fails for x32
     Ever confirmed|0                           |1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.cur_offset >= BITS_PER_WORD

[Bug tree-optimization/63828] [5 Regression] g++.dg/ipa/devirt-47.C fails for x32

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Aha, the BITS_PER_WORD really is intended to mean the pointer size (the
structure needs to be at least big enough to hold the VPTR pointer). What is
the correct way to get this value?

[Bug tree-optimization/63828] [5 Regression] g++.dg/ipa/devirt-47.C fails for x32

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #3)
> Aha, the BITS_PER_WORD really is intended to mean the pointer size (the
> structure needs to be at least big enough to hold the VPTR pointer). What is
> the correct way to get this value?

POINTER_SIZE will return the size of a pointer in bits.

[Bug tree-optimization/63828] [5 Regression] g++.dg/ipa/devirt-47.C fails for x32

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 33948
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33948&action=edit
A patch

Tested on Linux/32.

[Bug tree-optimization/63828] [5 Regression] g++.dg/ipa/devirt-47.C fails for x32

[hjl at gcc dot gnu.org]

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

--- Comment #6 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> ---
Author: hjl
Date: Thu Nov 13 13:08:12 2014
New Revision: 217483

URL: https://gcc.gnu.org/viewcvs?rev=217483&root=gcc&view=rev
Log:
Use POINTER_SIZE to check for pointer size

    PR tree-optimization/63828
    * ipa-polymorphic-call.c (possible_placement_new): Check
    POINTER_SIZE, instead of BITS_PER_WORD, for pointer size.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-polymorphic-call.c

[Bug tree-optimization/63828] [5 Regression] g++.dg/ipa/devirt-47.C fails for x32

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed.