[Bug debug/112878] ICE: in ctf_add_slice, at ctfc.cc:499 with _BitInt > 255 in a struct and -gctf1

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Indu Bhagat <ibhagat@gcc.gnu.org>:

https://gcc.gnu.org/g:5c869aa8a4538b218d9e59de6c96133971e7b965

commit r14-9906-g5c869aa8a4538b218d9e59de6c96133971e7b965
Author: Indu Bhagat <indu.bhagat@oracle.com>
Date:   Wed Apr 10 17:27:52 2024 -0700

    ctf: fix PR debug/112878

    PR debug/112878: ICE: in ctf_add_slice, at ctfc.cc:499 with
    _BitInt > 255 in a struct and -gctf1

    The CTF generation in GCC does not have a mechanism to roll-back an
    already added type.  In this testcase presented in the PR, we hit a
    representation limit in CTF slices (for a member of a struct) and ICE,
    after the type for struct (CTF_K_STRUCT) has already been added to the
    container.

    To exit gracefully instead, we now check for both the offset and size of
    the bitfield to be explicitly <= 255.  If the check fails, we emit the
    member with type CTF_K_UNKNOWN.  Note that, the value 255 stems from the
    existing binutils libctf checks which were motivated to guard against
    malformed inputs.

    Although it is not accurate to say that this is a CTF representation
    limit, mark the code with TBD_CTF_REPRESENTATION_LIMIT for now so that
    this can be taken care of with the next format version bump, when
    libctf's checks for the slice data can be lifted as well.

    gcc/ChangeLog:
            PR debug/112878
            * dwarf2ctf.cc (gen_ctf_sou_type): Check for conditions before
            call to ctf_add_slice.  Use CTF_K_UNKNOWN type if fail.

    gcc/testsuite/ChangeLog:
            PR debug/112878
            * gcc.dg/debug/ctf/ctf-bitfields-5.c: New test.