[Bug middle-end/101586] New: ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

[Bug middle-end/101586] New: ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

[qinzhao at gcc dot gnu.org]

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

            Bug ID: 101586
           Summary: ICE:in clear_padding_type, at gimple-fold.c:4783 with
                    call to __builtin_clear_padding for C++
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

gcc12 failed with the following small testing case:

namespace std {
inline namespace __cxx11 {}
typedef char string;
namespace __cxx11 {
template <typename _CharT, typename = _CharT, typename = _CharT>
class basic_stringstream;
}
typedef basic_stringstream<char> stringstream;
template <typename _CharT, typename> class basic_ios {
  typedef _CharT char_type;
  char_type _M_fill;
};
template <typename _CharT, typename _Traits>
class basic_istream : virtual basic_ios<_CharT, _Traits> {};
template <typename _CharT, typename _Traits>
class basic_iostream : basic_istream<_CharT, _Traits> {};
namespace __cxx11 {
template <typename _CharT, typename _Traits, typename>
class basic_stringstream : basic_iostream<_CharT, _Traits> {};
} // namespace __cxx11
} // namespace std
class cMessage {
  std::string info() const;
};
std::string cMessage::info() const 
{ 
  std::stringstream out;
  __builtin_clear_padding (&out);
}

compiled with g++ -std=c++03 -m64, and got:

tf.c: In member function ‘std::string cMessage::info() const’:
tf.c:29:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   29 | }
      | ^
during GIMPLE pass: lower
tf.c:25:13: internal compiler error: in clear_padding_type, at
gimple-fold.c:4783
   25 | std::string cMessage::info() const
      |             ^~~~~~~~
0x10e2037 clear_padding_type
        ../../latest-gcc-2/gcc/gimple-fold.c:4783
0x10e1fae clear_padding_type
        ../../latest-gcc-2/gcc/gimple-fold.c:4779
0x10e1fae clear_padding_type
        ../../latest-gcc-2/gcc/gimple-fold.c:4779
0x10e3216 gimple_fold_builtin_clear_padding
        ../../latest-gcc-2/gcc/gimple-fold.c:4981
0x10e39f5 gimple_fold_builtin
        ../../latest-gcc-2/gcc/gimple-fold.c:5155
0x10e5c95 gimple_fold_call
        ../../latest-gcc-2/gcc/gimple-fold.c:5563
0x10e916c fold_stmt_1
        ../../latest-gcc-2/gcc/gimple-fold.c:6265
0x10e94eb fold_stmt(gimple_stmt_iterator*)
        ../../latest-gcc-2/gcc/gimple-fold.c:6361
0x253052f lower_stmt
        ../../latest-gcc-2/gcc/gimple-low.c:388
0x2530093 lower_sequence
        ../../latest-gcc-2/gcc/gimple-low.c:217
0x253025e lower_stmt
        ../../latest-gcc-2/gcc/gimple-low.c:286
0x2530093 lower_sequence
        ../../latest-gcc-2/gcc/gimple-low.c:217
0x25309b0 lower_gimple_bind
        ../../latest-gcc-2/gcc/gimple-low.c:473
0x252fc89 lower_function_body
        ../../latest-gcc-2/gcc/gimple-low.c:110
0x252ffdc execute
        ../../latest-gcc-2/gcc/gimple-low.c:195
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
ubuntu@qinzhao-ubuntu-x86:~/Bugs/uninit/bug_1$ 


This testing case is Reduced from CPU2017 benchmark and has been modified a
little bit (by adding the call to __builtin_clear_padding).

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-07-23
     Ever confirmed|0                           |1

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with the introduction commit r11-5196-g1bea0d0aa5936cb3.

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Reduced testcase:
struct A { char a; };
struct B : virtual A {};
struct C : B {};

void
foo ()
{ 
  C c;
  __builtin_clear_padding (&c);
}

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 51201
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51201&action=edit
gcc12-pr101586.patch

Untested fix.

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

[qinzhao at gcc dot gnu.org]

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

--- Comment #4 from qinzhao at gcc dot gnu.org ---
I applied the attached patch and tested CPU2017 with
-ftrivial-auto-var-init=pattern, now all the corresponding C++ failures get
resolved.

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

[qinzhao at gcc dot gnu.org]

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

--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
> Reduced testcase:
> struct A { char a; };
> struct B : virtual A {};
> struct C : B {};
> 
> void
> foo ()
> { 
>   C c;
>   __builtin_clear_padding (&c);
> }

is the bug related to virtual table in the object? what's the root cause of the
failure? thanks.

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It is related to the weird FIELD_DECLs the C++ FE creates for the virtual
inheritence, there is e.g. a FIELD_DECL with B type (where B has 16 byte size
and includes the 8 byte virtual pointer and 1 byte A), but the size of the
FIELD_DECL is just 8 bytes, which is something the clear padding code didn't
expect to see.

BTW, if you are using the clear padding code for -ftrivial*, unless it is
clear_type_padding_in_mask, it can error e.g. on flexible array members, which
is fine for the builtin, but probably not fine for -ftrivial*.

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

[qing.zhao at oracle dot com]

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

--- Comment #7 from Qing Zhao <qing.zhao at oracle dot com> ---
> On Jul 23, 2021, at 10:10 AM, jakub at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586
> 
> --- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> It is related to the weird FIELD_DECLs the C++ FE creates for the virtual
> inheritence, there is e.g. a FIELD_DECL with B type (where B has 16 byte size
> and includes the 8 byte virtual pointer and 1 byte A), but the size of the
> FIELD_DECL is just 8 bytes, which is something the clear padding code didn't
> expect to see.

So, is such type information generated by C++FE correct?
> 
> BTW, if you are using the clear padding code for -ftrivial*, unless it is
> clear_type_padding_in_mask, it can error e.g. on flexible array members, which
> is fine for the builtin, but probably not fine for -ftrivial*.

I noticed this,  and then I fixed this by adding a third argument for
__builtin_clear_padding to indicate whether it’s for auto init or not.
If for auto init, then not emit the error, is this fix good?

(BTW, what’s clear_type_padding_in_mask try to do? Should I use it instead?)

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Qing Zhao from comment #7)
> So, is such type information generated by C++FE correct?

Yes.  It is needed that way to follow the Itanium C++ ABI.

> > BTW, if you are using the clear padding code for -ftrivial*, unless it is
> > clear_type_padding_in_mask, it can error e.g. on flexible array members, which
> > is fine for the builtin, but probably not fine for -ftrivial*.
> 
> I noticed this,  and then I fixed this by adding a third argument for
> __builtin_clear_padding to indicate whether it’s for auto init or not.
> If for auto init, then not emit the error, is this fix good?
> 
> (BTW, what’s clear_type_padding_in_mask try to do? Should I use it instead?)

I'd need to see a patch.  The builtin itself has a single argument and
shouldn't accept more than one, gimple_fold_builtin_clear_padding has also just
a single argument.  clear_type_padding_in_mask doesn't emit code to clear any
memory, but fills in an array with bitmask which bits contain padding and which
don't.

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

[qing.zhao at oracle dot com]

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

--- Comment #9 from Qing Zhao <qing.zhao at oracle dot com> ---
> On Jul 23, 2021, at 10:34 AM, jakub at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586
> 
> --- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to Qing Zhao from comment #7)
>> So, is such type information generated by C++FE correct?
> 
> Yes.  It is needed that way to follow the Itanium C++ ABI.

Okay. I see.
Then with such type info, can clear_type_padding fill all the paddings for such
type?
> 
>>> BTW, if you are using the clear padding code for -ftrivial*, unless it is
>>> clear_type_padding_in_mask, it can error e.g. on flexible array members, which
>>> is fine for the builtin, but probably not fine for -ftrivial*.
>> 
>> I noticed this,  and then I fixed this by adding a third argument for
>> __builtin_clear_padding to indicate whether it’s for auto init or not.
>> If for auto init, then not emit the error, is this fix good?
>> 
>> (BTW, what’s clear_type_padding_in_mask try to do? Should I use it instead?)
> 
> I'd need to see a patch.  

Do you want me send my current patch to you for some comments for this part?
Then I can email to you with a separate email.
> The builtin itself has a single argument and
> shouldn't accept more than one, gimple_fold_builtin_clear_padding has also just
> a single argument.

Currently, in gimplification phase, we already added one more argument to this
call: (gimplify.c)

====
      case BUILT_IN_CLEAR_PADDING:
        if (call_expr_nargs (*expr_p) == 1)
          {
            /* Remember the original type of the argument in an internal
               dummy second argument, as in GIMPLE pointer conversions are
               useless.  */
            p = CALL_EXPR_ARG (*expr_p, 0);
            *expr_p
              = build_call_expr_loc (EXPR_LOCATION (*expr_p), fndecl, 2, p,
                                     build_zero_cst (TREE_TYPE (p)));
            return GS_OK;
=====

So, I just added one more argument in the above to distinguish the auto init.
>  clear_type_padding_in_mask doesn't emit code to clear any
> memory, but fills in an array with bitmask which bits contain padding and which
> don't.
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:a21bd3cebd6f54af70a37c18b8fbeae933fb6515

commit r12-2522-ga21bd3cebd6f54af70a37c18b8fbeae933fb6515
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Jul 27 09:59:37 2021 +0200

    gimple-fold: Fix up __builtin_clear_padding on classes with virtual
inheritence [PR101586]

    For the following testcase, B is 16-byte type, containing 8-byte
    virtual pointer and 1-byte A member, and C contains two FIELD_DECLs,
    one with B type and size of just 8-byte and then a field with type
    A and 1-byte size.
    The __builtin_clear_padding code was upset about the B typed FIELD_DECL
    containing FIELD_DECLs beyond the field size and triggered
    assertion failure.
    This patch makes it ignore all FIELD_DECLs that are (fully) beyond the sz
    passed from the caller (except for the flexible array member
    diagnostics that is kept).

    2021-07-27  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/101586
            * gimple-fold.c (clear_padding_type): Ignore FIELD_DECLs with byte
            positions above or equal to sz except for diagnostics of flexible
            array members.

            * g++.dg/torture/builtin-clear-padding-4.C: New test.

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk.
Can be backported to 11.3, though it isn't much useful there as libstdc++ still
doesn't use the builtin.

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:117a880acb67e06caf06d83469d64a698927e719

commit r11-8805-g117a880acb67e06caf06d83469d64a698927e719
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Jul 27 09:59:37 2021 +0200

    gimple-fold: Fix up __builtin_clear_padding on classes with virtual
inheritence [PR101586]

    For the following testcase, B is 16-byte type, containing 8-byte
    virtual pointer and 1-byte A member, and C contains two FIELD_DECLs,
    one with B type and size of just 8-byte and then a field with type
    A and 1-byte size.
    The __builtin_clear_padding code was upset about the B typed FIELD_DECL
    containing FIELD_DECLs beyond the field size and triggered
    assertion failure.
    This patch makes it ignore all FIELD_DECLs that are (fully) beyond the sz
    passed from the caller (except for the flexible array member
    diagnostics that is kept).

    2021-07-27  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/101586
            * gimple-fold.c (clear_padding_type): Ignore FIELD_DECLs with byte
            positions above or equal to sz except for diagnostics of flexible
            array members.

            * g++.dg/torture/builtin-clear-padding-4.C: New test.

    (cherry picked from commit a21bd3cebd6f54af70a37c18b8fbeae933fb6515)

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed also for 11.3, 10.x doesn't have the builtin.