public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/102295] ELF symbol sizes for variable-length objects are too small (C++)
Date: Wed, 15 Sep 2021 20:22:39 +0000	[thread overview]
Message-ID: <bug-102295-4-3Tyua3FPrD@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-102295-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #7 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:e5d1af8a07ae9fcc40ea5c781c3ad46d20ea12a6

commit r12-3556-ge5d1af8a07ae9fcc40ea5c781c3ad46d20ea12a6
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Sep 15 22:21:17 2021 +0200

    c++: Fix handling of decls with flexible array members initialized with
side-effects [PR88578]

    > > Note, if the flexible array member is initialized only with
non-constant
    > > initializers, we have a worse bug that this patch doesn't solve, the
    > > splitting of initializers into constant and dynamic initialization
removes
    > > the initializer and we don't have just wrong DECL_*SIZE, but nothing is
    > > emitted when emitting those vars into assembly either and so the
dynamic
    > > initialization clobbers other vars that may overlap the variable.
    > > I think we need keep an empty CONSTRUCTOR elt in DECL_INITIAL for the
    > > flexible array member in that case.
    >
    > Makes sense.

    So, the following patch fixes that.

    The typeck2.c change makes sure we keep those CONSTRUCTORs around (although
    they should be empty because all their elts had side-effects/was
    non-constant if it was removed earlier), and the varasm.c change is to
avoid
    ICEs on those as well as ICEs on other flex array members that had some
    initializers without side-effects, but not on the last array element.

    The code was already asserting that the (index of the last elt in the
    CONSTRUCTOR + 1) times elt size is equal to TYPE_SIZE_UNIT of the
local->val
    type, which is true for C flex arrays or for C++ if they don't have any
    side-effects or the last elt doesn't have side-effects, this patch changes
    that to assertion that the TYPE_SIZE_UNIT is greater than equal to the
    offset of the end of last element in the CONSTRUCTOR and uses
TYPE_SIZE_UNIT
    (int_size_in_bytes) in the code later on.

    2021-09-15  Jakub Jelinek  <jakub@redhat.com>

            PR c++/88578
            PR c++/102295
    gcc/
            * varasm.c (output_constructor_regular_field): Instead of assertion
            that array_size_for_constructor result is equal to size of
            TREE_TYPE (local->val) in bytes, assert that the type size is
greater
            or equal to array_size_for_constructor result and use type size as
            fieldsize.
    gcc/cp/
            * typeck2.c (split_nonconstant_init_1): Don't throw away empty
            initializers of flexible array members if they have non-zero type
            size.
    gcc/testsuite/
            * g++.dg/ext/flexary39.C: New test.
            * g++.dg/ext/flexary40.C: New test.

  parent reply	other threads:[~2021-09-15 20:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-12 22:46 [Bug c++/102295] New: " pinskia at gcc dot gnu.org
2021-09-12 23:15 ` [Bug c++/102295] " pinskia at gcc dot gnu.org
2021-09-13 16:34 ` jakub at gcc dot gnu.org
2021-09-13 16:38 ` jakub at gcc dot gnu.org
2021-09-13 20:40 ` pinskia at gcc dot gnu.org
2021-09-14 14:57 ` cvs-commit at gcc dot gnu.org
2021-09-14 14:59 ` jakub at gcc dot gnu.org
2021-09-15 20:22 ` cvs-commit at gcc dot gnu.org [this message]
2021-09-15 23:05 ` cvs-commit at gcc dot gnu.org
2021-09-15 23:05 ` cvs-commit at gcc dot gnu.org
2021-09-16  8:50 ` jakub at gcc dot gnu.org
2022-05-10  8:20 ` cvs-commit at gcc dot gnu.org
2022-05-10  8:20 ` cvs-commit at gcc dot gnu.org
2022-05-11  6:22 ` cvs-commit at gcc dot gnu.org
2022-05-11  6:22 ` cvs-commit at gcc dot gnu.org
2022-05-11  6:36 ` jakub at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-102295-4-3Tyua3FPrD@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).