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

--- Comment #17 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
<[email protected]>:

https://gcc.gnu.org/g:761efd0e18417cf386ace300af2f9f9b5d39d07c

commit r15-10363-g761efd0e18417cf386ace300af2f9f9b5d39d07c
Author: Jakub Jelinek <[email protected]>
Date:   Wed Sep 10 12:33:14 2025 +0200

    expr: Handle RAW_DATA_CST in store_constructor [PR121831]

    I thought this wouldn't be necessary because RAW_DATA_CST can only appear
    inside of (array) CONSTRUCTORs within DECL_INITIAL of TREE_STATIC vars,
    so there shouldn't be a need to expand it.  Except that we have an
    optimization when reading ARRAY_REF from such a CONSTRUCTOR which will
    try to expand the constructor if it either can be stored by pieces
    (I think that is just fine) or if it is mostly zeros (which is at least
    75% of the initializer zeros).  Now the second case is I think in some
    cases desirable (say 256MB initializer and just 20 elements out of that
    non-zero, so clear everything and store 20 elements must be fastest and
    short), but could be really bad as well (say 40GB initializer with
    10GB non-zero in it, especially if it doesn't result in the original
    variable being optimized away).  Maybe it would help if expand_constructor
    and store_constructor* etc. had some optional argument with addresses into
    the original VAR_DECL so that it could be copying larger amounts of data
    like larger RAW_DATA_CSTs from there instead of pushing those into new
    .rodata again.  And another problem is that we apparently expand the
    initializes twice, expand_constructor in store_constructor can expand
    the stores one and if expand_constructor returns non-NULL, we then
    expand_expr the CONSTRUCTOR again. to the same location.

    This patch doesn't address either of those issues, just adds RAW_DATA_CST
    support to store_constructor for now.  For the can_store_by_pieces
    cases it stores those by pieces using a new callback very similar to
    string_cst_read_str, for the rest (unfortunately) forces it into a memory
    and copies from there.

    2025-09-10  Jakub Jelinek  <[email protected]>

            PR middle-end/121831
            * expr.cc (raw_data_cst_read_str): New function.
            (store_constructor) <case ARRAY_TYPE>: Handle RAW_DATA_CST.

            * g++.dg/lto/pr121831_0.C: New test.
            * g++.dg/lto/pr121831_1.C: New test.

    (cherry picked from commit 225d13c01d4e231bfabfda1c1c9135e36f55946a)
  • [Bug middle-end/121831] [15 reg... cvs-commit at gcc dot gnu.org via Gcc-bugs

Reply via email to