[Bug c++/105256] New: ICE compiling firefox-99

[Bug c++/105256] New: ICE compiling firefox-99

[chris2553 at googlemail dot com]

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

            Bug ID: 105256
           Summary: ICE compiling firefox-99
           Product: gcc
           Version: 11.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chris2553 at googlemail dot com
  Target Milestone: ---

I get the following ICE bump when compiling firefox-99.0 (and 99.0.1) with a
gcc installation built from the gcc-11-20220409 snapshot. The same ICE occurs
with gcc-11-20220402.

30:42.01 In file included from Unified_cpp_layout_style2.cpp:92:
30:42.01 /home/chris/rpm/BUILD/firefox-99.0.1/layout/style/PreferenceSheet.cpp:
In member function 'void mozilla::PreferenceSheet::Prefs::Load(bool)':
30:42.01
/home/chris/rpm/BUILD/firefox-99.0.1/layout/style/PreferenceSheet.cpp:181:12:
internal compiler error: Segmentation fault
30:42.01   181 |   *this = {};
30:42.01       |            ^
30:42.03 0x16b0e03 diagnostic_impl(rich_location*, diagnostic_metadata const*,
int, char const*, __va_list_tag (*) [1], diagnostic_t)
30:42.03        ???:0
30:42.03 0x16b1247 internal_error(char const*, ...)
30:42.03        ???:0
30:42.03 0xc8edbf crash_signal(int)
30:42.03        ???:0
30:42.03 0x8674f3 ggc_free(void*)
30:42.03        ???:0
30:42.04 0x62a075 gimplify_asm_expr(tree_node**, gimple**, gimple**) [clone
.isra.0] [clone .cold]
30:42.04        ???:0
30:42.04 Please submit a full bug report,
30:42.04 with preprocessed source if appropriate.
30:42.04 Please include the complete backtrace with any bug report.
30:42.04 See <https://gcc.gnu.org/bugs/> for instructions.
30:42.11 gmake[4]: ***
[/home/chris/rpm/BUILD/firefox-99.0.1/config/rules.mk:660:
Unified_cpp_layout_style2.o] Error 1
30:42.11 gmake[3]: ***
[/home/chris/rpm/BUILD/firefox-99.0.1/config/recurse.mk:72:
layout/style/target-objects] Error 2
30:42.11 gmake[3]: *** Waiting for unfinished jobs....

The same build completes successfully with gcc-12-20220410 and with
gcc-10-20220408.

[Bug c++/105256] ICE compiling firefox-99

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-04-13
     Ever confirmed|0                           |1
                 CC|                            |marxin at gcc dot gnu.org
             Status|UNCONFIRMED                 |WAITING

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Can you provide preprocessed source of Unified_cpp_layout_style2.cpp and the
compiler command line that compiles it?

[Bug c++/105256] ICE compiling firefox-99

[chris2553 at googlemail dot com]

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

--- Comment #2 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 52802
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52802&action=edit
First requested file

[Bug c++/105256] ICE compiling firefox-99

[chris2553 at googlemail dot com]

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

--- Comment #3 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 52803
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52803&action=edit
Second requested file - part1

[Bug c++/105256] ICE compiling firefox-99

[chris2553 at googlemail dot com]

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

--- Comment #4 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 52804
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52804&action=edit
Second Requested file - part2

[Bug c++/105256] ICE compiling firefox-99

[chris2553 at googlemail dot com]

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

--- Comment #5 from Chris Clayton <chris2553 at googlemail dot com> ---
The .ii file was huge so I've had to split it and then compress the parts

[Bug c++/105256] ICE compiling firefox-99

[chris2553 at googlemail dot com]

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

--- Comment #6 from Chris Clayton <chris2553 at googlemail dot com> ---
I'm struggling to get the compiler command line. The build system is wrapped in
a build tool called mach and I'm darned if I can find an argument that will
cause it to report the command it is about to launch. The -verbose argument
seems to have very little effect on the messages that are output as does the
--log-file argument. Hey ho.

[Bug c++/105256] ICE compiling firefox-99

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I see this ICE with GCC 11 with just -O2.  Mainline doesn't crash.

/home/chris/rpm/BUILD/firefox-99.0.1/layout/style/PreferenceSheet.cpp:181:12:
internal compiler error: in gimplify_expr, at gimplify.c:14924
0x126cac0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
        /home/mpolacek/src/gcc11/gcc/gimplify.c:14924
0x1236bab gimplify_compound_lval
        /home/mpolacek/src/gcc11/gcc/gimplify.c:3079
0x1269991 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
        /home/mpolacek/src/gcc11/gcc/gimplify.c:14091
0x123c263 gimplify_init_ctor_preeval
        /home/mpolacek/src/gcc11/gcc/gimplify.c:4546
0x123c212 gimplify_init_ctor_preeval
        /home/mpolacek/src/gcc11/gcc/gimplify.c:4532
0x123c212 gimplify_init_ctor_preeval
        /home/mpolacek/src/gcc11/gcc/gimplify.c:4532
0x123dc3f gimplify_init_constructor
        /home/mpolacek/src/gcc11/gcc/gimplify.c:5127
0x123e99f gimplify_modify_expr_rhs
        /home/mpolacek/src/gcc11/gcc/gimplify.c:5421
0x123fbae gimplify_modify_expr
        /home/mpolacek/src/gcc11/gcc/gimplify.c:5784
0x1269b2f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
        /home/mpolacek/src/gcc11/gcc/gimplify.c:14139
0x1244105 gimplify_stmt(tree_node**, gimple**)
        /home/mpolacek/src/gcc11/gcc/gimplify.c:6888
0x124361e gimplify_cleanup_point_expr
        /home/mpolacek/src/gcc11/gcc/gimplify.c:6630
0x126b5c8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
        /home/mpolacek/src/gcc11/gcc/gimplify.c:14532
0x1244105 gimplify_stmt(tree_node**, gimple**)
        /home/mpolacek/src/gcc11/gcc/gimplify.c:6888
0x12330a6 gimplify_statement_list
        /home/mpolacek/src/gcc11/gcc/gimplify.c:1880
0x126b975 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
        /home/mpolacek/src/gcc11/gcc/gimplify.c:14584
0x1244105 gimplify_stmt(tree_node**, gimple**)
        /home/mpolacek/src/gcc11/gcc/gimplify.c:6888
0x126e341 gimplify_body(tree_node*, bool)
        /home/mpolacek/src/gcc11/gcc/gimplify.c:15363
0x126ea3e gimplify_function_tree(tree_node*)
        /home/mpolacek/src/gcc11/gcc/gimplify.c:15517
0xfe3aba cgraph_node::analyze()
        /home/mpolacek/src/gcc11/gcc/cgraphunit.c:670

[Bug c++/105256] ICE compiling firefox-99

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
In fact I see the ICE even without any options.

Looks like <PLACEHOLDER_EXPR struct Colors> for the NSDMI of mFocusText leaks
into the gimplifier.  But I cannot reproduce this with gcc 11 on a different
box, weird.

[Bug c++/105256] ICE compiling firefox-99

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #8)
> In fact I see the ICE even without any options.
> 
> Looks like <PLACEHOLDER_EXPR struct Colors> for the NSDMI of mFocusText
> leaks into the gimplifier.  But I cannot reproduce this with gcc 11 on a
> different box, weird.

Maybe PR 104583?

[Bug c++/105256] ICE compiling firefox-99

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Marek Polacek from comment #8)
> > In fact I see the ICE even without any options.
> > 
> > Looks like <PLACEHOLDER_EXPR struct Colors> for the NSDMI of mFocusText
> > leaks into the gimplifier.  But I cannot reproduce this with gcc 11 on a
> > different box, weird.
> 
> Maybe PR 104583?

I think that's unlikely.  I'm trying to reduce the #c3/#c4 .ii.  Let's see if I
get anywhere...

[Bug c++/105256] ICE compiling firefox-99

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška <marxin at gcc dot gnu.org> ---
Marek, what -std do you use? I see the following compilation errors:

/home/chris/rpm/BUILD/firefox-99.0.1/layout/generic/nsContainerFrame.h:638:74:
error: ‘static void nsFrameList::operator delete(void*)’ is private within this
context
In file included from
/home/chris/rpm/BUILD/firefox-99.0.1/layout/base/nsFrameManager.h:14,
                 from
/home/chris/rpm/BUILD/firefox-99.0.1/obj-dir/dist/include/mozilla/PresShell.h:36,
                 from
/home/chris/rpm/BUILD/firefox-99.0.1/obj-dir/dist/include/mozilla/dom/DocumentInlines.h:11,
                 from
/home/chris/rpm/BUILD/firefox-99.0.1/layout/style/ImageLoader.cpp:14:
/home/chris/rpm/BUILD/firefox-99.0.1/layout/generic/nsFrameList.h:571:8: note:
declared private here
/home/chris/rpm/BUILD/firefox-99.0.1/layout/generic/nsContainerFrame.h: In
member function ‘nsFrameList*
nsContainerFrame::SetOverflowContainers(nsFrameList&&)’:
/home/chris/rpm/BUILD/firefox-99.0.1/layout/generic/nsContainerFrame.h:648:78:
error: ‘static void nsFrameList::operator delete(void*)’ is private within this
context
/home/chris/rpm/BUILD/firefox-99.0.1/layout/generic/nsFrameList.h:571:8: note:
declared private here
/home/chris/rpm/BUILD/firefox-99.0.1/layout/generic/nsContainerFrame.h: In
member function ‘nsFrameList*
nsContainerFrame::SetExcessOverflowContainers(nsFrameList&&)’:
/home/chris/rpm/BUILD/firefox-99.0.1/layout/generic/nsContainerFrame.h:661:75:
error: ‘static void nsFrameList::operator delete(void*)’ is private within this
context

Both with master and GCC 11.x.

[Bug c++/105256] ICE compiling firefox-99

[mpolacek at gcc dot gnu.org]

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

--- Comment #12 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #11)
> Marek, what -std do you use? I see the following compilation errors:

-std=c++17, but I saw that error too, followed by a crash with GCC 11.

[Bug c++/105256] ICE compiling firefox-99

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
This reduced code crashes with GCC 8 up to trunk:

struct S {
  struct Prefs {
    struct {
      int i = i;
    } p;
    void Load();
  };
};

void S::Prefs::Load() {
  *this = {};
};

$ xg++ -c ff.C
ff.C: In member function ‘void S::Prefs::Load()’:
ff.C:11:12: internal compiler error: in gimplify_expr, at gimplify.cc:15905
   11 |   *this = {};
      |            ^
0x1370253 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
        /home/mpolacek/src/gcc/gcc/gimplify.cc:15905
0x13360f8 gimplify_compound_lval
        /home/mpolacek/src/gcc/gcc/gimplify.cc:3272
0x136cfa4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
        /home/mpolacek/src/gcc/gcc/gimplify.cc:15050
0x133bc99 gimplify_init_ctor_preeval
        /home/mpolacek/src/gcc/gcc/gimplify.cc:4781
0x133bc48 gimplify_init_ctor_preeval
        /home/mpolacek/src/gcc/gcc/gimplify.cc:4767
0x133bc48 gimplify_init_ctor_preeval
        /home/mpolacek/src/gcc/gcc/gimplify.cc:4767
0x133d603 gimplify_init_constructor
        /home/mpolacek/src/gcc/gcc/gimplify.cc:5357
0x133e452 gimplify_modify_expr_rhs
        /home/mpolacek/src/gcc/gcc/gimplify.cc:5674
0x133f66f gimplify_modify_expr
        /home/mpolacek/src/gcc/gcc/gimplify.cc:6040
0x136d142 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
        /home/mpolacek/src/gcc/gcc/gimplify.cc:15098
0x1343c11 gimplify_stmt(tree_node**, gimple**)
        /home/mpolacek/src/gcc/gcc/gimplify.cc:7151
0x1343164 gimplify_cleanup_point_expr
        /home/mpolacek/src/gcc/gcc/gimplify.cc:6892
0x136ebdb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
        /home/mpolacek/src/gcc/gcc/gimplify.cc:15491
0x1343c11 gimplify_stmt(tree_node**, gimple**)
        /home/mpolacek/src/gcc/gcc/gimplify.cc:7151
0x1371bfb gimplify_body(tree_node*, bool)
        /home/mpolacek/src/gcc/gcc/gimplify.cc:16355
0x13722f8 gimplify_function_tree(tree_node*)
        /home/mpolacek/src/gcc/gcc/gimplify.cc:16509
0x10c08c9 cgraph_node::analyze()
        /home/mpolacek/src/gcc/gcc/cgraphunit.cc:676
0x10c2955 analyze_functions
        /home/mpolacek/src/gcc/gcc/cgraphunit.cc:1241
0x10c5b05 symbol_table::finalize_compilation_unit()
        /home/mpolacek/src/gcc/gcc/cgraphunit.cc:2501

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |9.5
            Summary|ICE compiling firefox-99    |[9/10/11/12 Regression] ICE
                   |                            |compiling firefox-99
             Status|WAITING                     |NEW
           Priority|P3                          |P2

--- Comment #14 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
The testcase in the previous comment started to ICE with r258593:

commit 570f86f94eca76fbfab919dcbfe639a5ba69f20e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 16 13:46:12 2018 +0100

    re PR c++/79937 (ICE in replace_placeholders_r)

So confirmed.  I'm not sure this is the same ICE Chris saw though...

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code

--- Comment #15 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Better test:

struct S {
  struct Prefs {
    struct {
      int i = j;
      int j = 42;
    } p;
    void Load();
  };
};

void S::Prefs::Load() {
  *this = {};
};

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Don't both of those tests have UB (sure, we shouldn't ICE), using uninitialized
non-static data member?
Perhaps:

int
bar (int &)
{
  return 1;
}

struct S {
  struct T {
    struct U {
      int i = bar (i);
    } p;
    void foo ();
  };
};

void
S::T::foo ()
{
  *this = {};
};

is better?

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

[chris2553 at googlemail dot com]

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

--- Comment #17 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 52810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52810&action=edit
Compiler commands

Finally got them by running running "ps ax" in a while true loop, grepping the
output for the file name and writing any matches to a file. There must be an
easier way!

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The rationale for introduction of CONSTRUCTOR_PLACEHOLDER_BOUNDARY was given in
the
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-03/threads.html#00681
thread, not all PLACEHOLDER_EXPRs nested in an expression should be replaced by
the same object, if there are e.g. nested TARGET_EXPRs with PLACEHOLDER_EXPRs
in their initializers, those nested PLACEHOLDER_EXPRs should be replaced by the
TARGET_EXPR's slot rather than the outermost expression.
Before the r8-7334-g570f86f94eca76fbf, the PLACEHOLDER_EXPR was replaced from
build_over_call, but that has removed.  The expectation was that we'd always
have some object (var being constructed, TARGET_EXPR slot, etc. and we'd
replace_placeholders when gimplifying INIT_EXPR for it).
But on:

int bar (int &);

struct S {
  struct T {
    struct U {
      int i = bar (i);
    } u;
  };
};

void
foo (S::T *p)
{
  *p = {};
};

cp_gimplify_init_expr is never called, gimplify_target_expr neither, because we
ICE earlier than that.
While we have there a TARGET_EXPR when we start gimplification:
*NON_LVALUE_EXPR <p> = *(struct T &) &TARGET_EXPR <D.2400, {.u={.i=bar ((int &)
&(&<PLACEHOLDER_EXPR struct U>)->i)}}>, seems something has elided it.

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The TARGET_EXPR is elided in gimplify_modify_expr_rhs:
        case TARGET_EXPR:
          {
            /* If we are initializing something from a TARGET_EXPR, strip the
               TARGET_EXPR and initialize it directly, if possible.  This can't
               be done if the initializer is void, since that implies that the
               temporary is set in some non-trivial way.

               ??? What about code that pulls out the temp and uses it
               elsewhere? I think that such code never uses the TARGET_EXPR as
               an initializer.  If I'm wrong, we'll die because the temp won't
               have any RTL.  In that case, I guess we'll need to replace
               references somehow.  */
            tree init = TARGET_EXPR_INITIAL (*from_p);

            if (init
                && (TREE_CODE (*expr_p) != MODIFY_EXPR
                    || !TARGET_EXPR_NO_ELIDE (*from_p))
                && !VOID_TYPE_P (TREE_TYPE (init)))
              {
                *from_p = init;
                ret = GS_OK;
                changed = true;
              }
          }
          break;

Though, can the TARGET_EXPR be elided if there are PLACEHOLDER_EXPRs in it?
If not, something should probably set TARGET_EXPR_NO_ELIDE somewhere.
If yes, perhaps we need to replace_placeholders perhaps through a language hook
at the
above point.  But it is unclear to what it should be replaced...

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

[mpolacek at gcc dot gnu.org]

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

--- Comment #20 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #16)
> Don't both of those tests have UB (sure, we shouldn't ICE), using
> uninitialized non-static data member?

NSDMIs are parsed at the end of the class, but I think I should have switched
the order of the initialization:

struct S {
  struct Prefs {
    struct P {
      int i = 42;
      int j = i;
    } p;
    void Load();
  };
};

void S::Prefs::Load() {
  *this = {};
};

but your test is good too.

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, we have:
    case TARGET_EXPR:
      if (TARGET_EXPR_INITIAL (stmt)
          && TREE_CODE (TARGET_EXPR_INITIAL (stmt)) == CONSTRUCTOR
          && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (TARGET_EXPR_INITIAL (stmt)))
        TARGET_EXPR_NO_ELIDE (stmt) = 1;
      break;
but that doesn't trigger in this case because the TARGET_EXPR's CONSTRUCTOR
is not CONSTRUCTOR_PLACEHOLDER_BOUNDARY, instead it is a CONSTRUCTOR that
contains a CONSTRUCTOR_PLACEHOLDER_BOUNDARY CONSTRUCTOR as one of its elements.

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, wonder if for a CONSTRUCTOR containing elements which are CONSTRUCTORs with
CONSTRUCTOR_PLACEHOLDER_BOUNDARY set we shouldn't move the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag to the outer CONSTRUCTOR (if not set
there already).
The reason why the flag was introduced was to catch e.g. those
X x { 1, bar (X{2}).n }; etc. cases where the X{2} contains an unrelated
PLACEHOLDER_EXPR to the outer one.
But when we have directly nested CONSTRUCTORs, we can replace_placeholders all
of those PLACEHOLDER_EXPRs from in there, the object will be simply some member
of the var or TARGET_EXPR slot etc.

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

[jakub at gcc dot gnu.org]

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

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

Untested patch to do that.

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

[chris2553 at googlemail dot com]

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

--- Comment #24 from Chris Clayton <chris2553 at googlemail dot com> ---
I see the patch is for gcc-12. As I said in comment, I don't get the ICE with
the latest gcc-12 snapshot, but is it worth me applying the patch to gcc-11
(with which I do get the ICE) and testing a build with that?

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

[chris2553 at googlemail dot com]

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

--- Comment #25 from Chris Clayton <chris2553 at googlemail dot com> ---
 I went ahead and patched gcc-11-0220409 and with the resultant compiler have
had two successful builds of firefox-99. I then reverted to the unpatched gcc
and a build of firefox-99 failed with the same ICE that I reported in comment
1.

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

[rguenth at gcc dot gnu.org]

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

--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
What's odd is that we could successfully build 99.0.1 with
r11-9662-g6a1150d1524aed but it now fails this reported way with the release
candidate.

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

[marxin at gcc dot gnu.org]

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

--- Comment #27 from Martin Liška <marxin at gcc dot gnu.org> ---
So it started on gcc-11 branch with r11-9711-g6ba2a7e7474135.

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |102990

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #27)
> So it started on gcc-11 branch with r11-9711-g6ba2a7e7474135.

For

struct S {
  struct Prefs {
    struct P {
      int i = 42;
      int j = i;
    } p;
    void Load();
  };
};

void S::Prefs::Load() {
  *this = {};
};

that is, which probably means that the assumtion CTORs are already folded
is false and with the PR102990 change we no longer constant fold the
initializer.  Before:

;; Function void S::Prefs::Load() (null)
;; enabled by -tree-original


<<cleanup_point <<< Unknown tree: expr_stmt
  (void) (*(struct Prefs *) this = *(struct Prefs &) &TARGET_EXPR <D.2377,
{.p={.i=42, .j=42}}>) >>>>>;


After:

;; Function void S::Prefs::Load() (null)
;; enabled by -tree-original


<<cleanup_point <<< Unknown tree: expr_stmt
  (void) (*(struct Prefs *) this = *(struct Prefs &) &TARGET_EXPR <D.2377,
{.p={.i=42, .j=(&<PLACEHOLDER_EXPR struct P>)->i}}>) >>>>>;

which explains why the PR102990 change makes a difference here (and why it
is a recent regression for compiling Firefox on the branch).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102990
[Bug 102990] [9/10 Regression] ICE in tsubst_copy_and_build with NSDMI and
double to int conversion

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

[cvs-commit at gcc dot gnu.org]

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

--- Comment #29 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:eb03e424598d30fed68801af6d6ef6236d32e32e

commit r12-8196-geb03e424598d30fed68801af6d6ef6236d32e32e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Apr 19 18:27:41 2022 +0200

    c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256]

    The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate
    PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it
    (variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should
    be replaced by different objects or subobjects.
    The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not
    looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent
    elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer
    is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor.  The following testcase ICEs
    though, we don't replace the placeholders in there at all, because
    CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL
    ctor, but on a ctor nested in such a ctor.  replace_placeholders should be
    run on the whole TARGET_EXPR slot.

    So, the following patch fixes it by moving the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY
    bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only
    if it is closely nested, if there is some other tree sandwiched in between,
    it doesn't do it).

    2022-04-19  Jakub Jelinek  <jakub@redhat.com>

            PR c++/105256
            * typeck2.cc (process_init_constructor_array,
            process_init_constructor_record, process_init_constructor_union):
Move
            CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to
the
            containing CONSTRUCTOR.

            * g++.dg/cpp0x/pr105256.C: New test.

[Bug c++/105256] [9/10/11 Regression] ICE compiling firefox-99

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE
                   |compiling firefox-99        |compiling firefox-99

--- Comment #30 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.
Will test 11.3 backport overnight.

[Bug c++/105256] [9/10/11 Regression] ICE compiling firefox-99

[cvs-commit at gcc dot gnu.org]

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

--- Comment #31 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:691af15031e00227ba6d5935c1d737026cda4129

commit r11-9891-g691af15031e00227ba6d5935c1d737026cda4129
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Apr 19 18:27:41 2022 +0200

    c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256]

    The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate
    PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it
    (variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should
    be replaced by different objects or subobjects.
    The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not
    looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent
    elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer
    is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor.  The following testcase ICEs
    though, we don't replace the placeholders in there at all, because
    CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL
    ctor, but on a ctor nested in such a ctor.  replace_placeholders should be
    run on the whole TARGET_EXPR slot.

    So, the following patch fixes it by moving the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY
    bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only
    if it is closely nested, if there is some other tree sandwiched in between,
    it doesn't do it).

    2022-04-19  Jakub Jelinek  <jakub@redhat.com>

            PR c++/105256
            * typeck2.c (process_init_constructor_array,
            process_init_constructor_record, process_init_constructor_union):
Move
            CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to
the
            containing CONSTRUCTOR.

            * g++.dg/cpp0x/pr105256.C: New test.

    (cherry picked from commit eb03e424598d30fed68801af6d6ef6236d32e32e)

[Bug c++/105256] [9/10 Regression] ICE compiling firefox-99

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11 Regression] ICE    |[9/10 Regression] ICE
                   |compiling firefox-99        |compiling firefox-99
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #32 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 11.3 as well.

[Bug c++/105256] [9/10 Regression] ICE compiling firefox-99

[chris2553 at googlemail dot com]

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

--- Comment #33 from Chris Clayton <chris2553 at googlemail dot com> ---
On 20/04/2022 07:46, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256
> 
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Summary|[9/10/11 Regression] ICE    |[9/10 Regression] ICE
>                    |compiling firefox-99        |compiling firefox-99
>              Status|NEW                         |ASSIGNED
>            Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
> 
> --- Comment #32 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Fixed for 11.3 as well.

and I've successfully built firefox-99.0.1 using 11.3-RC with this patch
applied.

Thanks Jakub.
>

[Bug c++/105256] [9/10 Regression] ICE compiling firefox-99

[cvs-commit at gcc dot gnu.org]

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

--- Comment #34 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:f08ea45bad43024a1458dca6e37c5c1bcc02e234

commit r13-214-gf08ea45bad43024a1458dca6e37c5c1bcc02e234
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon May 9 18:21:08 2022 +0200

    testsuite: Remove superfluous semicolon [PR105256]

    2022-05-09  Jakub Jelinek  <jakub@redhat.com>

            PR c++/105256
            * g++.dg/cpp0x/pr105256.C: Remove superfluous semicolon.

[Bug c++/105256] [9/10 Regression] ICE compiling firefox-99

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-10709-gf8a34b4da971e6565a8d80e638c475bcfc06023f
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Apr 19 18:27:41 2022 +0200

    c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256]

    The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate
    PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it
    (variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should
    be replaced by different objects or subobjects.
    The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not
    looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent
    elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer
    is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor.  The following testcase ICEs
    though, we don't replace the placeholders in there at all, because
    CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL
    ctor, but on a ctor nested in such a ctor.  replace_placeholders should be
    run on the whole TARGET_EXPR slot.

    So, the following patch fixes it by moving the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY
    bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only
    if it is closely nested, if there is some other tree sandwiched in between,
    it doesn't do it).

    2022-04-19  Jakub Jelinek  <jakub@redhat.com>

            PR c++/105256
            * typeck2.c (process_init_constructor_array,
            process_init_constructor_record, process_init_constructor_union):
Move
            CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to
the
            containing CONSTRUCTOR.

            * g++.dg/cpp0x/pr105256.C: New test.

    (cherry picked from commit eb03e424598d30fed68801af6d6ef6236d32e32e)

[Bug c++/105256] [9/10 Regression] ICE compiling firefox-99

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:30895a25ea94e0ba47f97803137f2a0a42af848c

commit r9-10150-g30895a25ea94e0ba47f97803137f2a0a42af848c
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Apr 19 18:27:41 2022 +0200

    c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256]

    The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate
    PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it
    (variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should
    be replaced by different objects or subobjects.
    The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not
    looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent
    elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer
    is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor.  The following testcase ICEs
    though, we don't replace the placeholders in there at all, because
    CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL
    ctor, but on a ctor nested in such a ctor.  replace_placeholders should be
    run on the whole TARGET_EXPR slot.

    So, the following patch fixes it by moving the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY
    bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only
    if it is closely nested, if there is some other tree sandwiched in between,
    it doesn't do it).

    2022-04-19  Jakub Jelinek  <jakub@redhat.com>

            PR c++/105256
            * typeck2.c (process_init_constructor_array,
            process_init_constructor_record, process_init_constructor_union):
Move
            CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to
the
            containing CONSTRUCTOR.

            * g++.dg/cpp0x/pr105256.C: New test.

    (cherry picked from commit eb03e424598d30fed68801af6d6ef6236d32e32e)

[Bug c++/105256] [9/10 Regression] ICE compiling firefox-99

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #37 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.