[Bug c/109113] New: internal compiler error: in output_constructor_regular_field, at varasm.cc:5521

[Bug c/109113] New: internal compiler error: in output_constructor_regular_field, at varasm.cc:5521

[noe.lopez at epitech dot eu]

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

            Bug ID: 109113
           Summary: internal compiler error: in
                    output_constructor_regular_field, at varasm.cc:5521
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: noe.lopez at epitech dot eu
  Target Milestone: ---

Created attachment 54650
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54650&action=edit
The minimal code example

Hello :), I've recently come across an internal compiler error when trying to
compile my code.

The error seems to be triggered by assigning the result of a malloc of the size
of a structure containing static arrays of another structure containing static
arrays ???

It's a little complicated but I've done my best to produce a minimal example of
the bug that can be compiled with the following command:
`gcc minimal.c`

Here's my gcc -v output:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-unknown-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /builddir/gcc-12.2.0/configure
--build=x86_64-unknown-linux-gnu --enable-gnu-unique-object
--enable-vtable-verify --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --libexecdir=/usr/lib64 --libdir=/usr/lib64
--enable-threads=posix --enable-__cxa_atexit --disable-multilib
--with-system-zlib --enable-shared --enable-lto --enable-plugins
--enable-linker-build-id --disable-werror --disable-nls --enable-default-pie
--enable-default-ssp --enable-checking=release --disable-libstdcxx-pch
--with-isl --with-linker-hash-style=gnu --disable-sjlj-exceptions
--disable-target-libiberty --disable-libssp
--enable-languages=c,c++,objc,obj-c++,fortran,lto,go,ada
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC)

Here's the compiler output:

minimal.c:50:1: internal compiler error: in output_constructor_regular_field,
at varasm.cc:5521
   50 | int main(void) {}
      | ^~~
0x7f514864820b __libc_start_call_main
        ../sysdeps/nptl/libc_start_call_main.h:58
0x7f51486482bb __libc_start_main_impl
        ../csu/libc-start.c:381
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c/109113] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521

[noe.lopez at epitech dot eu]

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

--- Comment #1 from Noé Lopez <noe.lopez at epitech dot eu> ---
Created attachment 54651
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54651&action=edit
The preprocessed file

[Bug c/109113] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521

[noe.lopez at epitech dot eu]

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

--- Comment #2 from Noé Lopez <noe.lopez at epitech dot eu> ---
Here's the code in plain text:
#include <stdlib.h>

typedef struct menu_item_s {
    void *fn;
} menu_item_t;

typedef struct menu_list_s {
    int _a;
    menu_item_t items[];
} menu_list_t;

typedef struct menu_s {
    int _a;
    menu_list_t items[];
} menu_t;

typedef struct region_s {
    void *data;
} region_t;

static void fn(void) {
    // Bug does not trigger when doing something inside this function
    //int a = 0;
}

static const menu_list_t FILE_MENU = {
    .items = {
        { fn },
    }
};

const menu_t WINDOW_MENU = {
    .items = {
        FILE_MENU,
        FILE_MENU,
    },
};

void create_menu_region(region_t *dest, const menu_t *menu)
{
    // Bug only happens when putting output in the region_t struct
    dest->data = malloc(sizeof(menu));
    // Does not trigger bug:
    //menu_t *data = malloc(sizeof(menu));
    //  void *data = malloc(sizeof(menu));
    //  malloc(sizeof(menu));
}

// Just here so that ld doesn't complain
int main(void) {}

[Bug c/109113] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The code is invalid.
If you change the first `FILE_MENU` to `{0, { fn }}`, you get an error message:

<source>:31:13: error: initialization of flexible array member in a nested
context
   31 |         {0, { fn }},
      |             ^
<source>:31:13: note: (near initialization for 'WINDOW_MENU.items[0].items')

[Bug c/109113] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |8.1.0
   Last reconfirmed|                            |2023-03-13
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Reduced testcase:
```
struct menu_item_s {
    void (*fn)(void);
};
struct menu_list_s {
    int _a;
    struct menu_item_s items[];
};
struct menu_s {
    int _a;
    struct menu_list_s items[];
};
void fn(void);
const struct menu_list_s FILE_MENU = {
    .items = {
       { fn },
    }
};
struct menu_s WINDOW_MENU = {
    .items = {
        FILE_MENU,
        FILE_MENU,
    },
};
```
Note GCC 7 and before used to reject it with:
```
<source>:20:9: error: initializer element is not constant
         FILE_MENU,
         ^~~~~~~~~
<source>:20:9: note: (near initialization for 'WINDOW_MENU.items[0]')
```

[Bug c/109113] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521

[noe.lopez at epitech dot eu]

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

--- Comment #5 from Noé Lopez <noe.lopez at epitech dot eu> ---
(In reply to Andrew Pinski from comment #3)
> The code is invalid.
> If you change the first `FILE_MENU` to `{0, { fn }}`, you get an error
> message:
> 
> <source>:31:13: error: initialization of flexible array member in a nested
> context
>    31 |         {0, { fn }},
>       |             ^
> <source>:31:13: note: (near initialization for 'WINDOW_MENU.items[0].items')

Thank you for pointing that out :) I'm gonna fix my code now have a good day!

[Bug c/109113] [10/11/12/13 Regression] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid
      Known to work|                            |7.5.0
            Summary|internal compiler error: in |[10/11/12/13 Regression]
                   |output_constructor_regular_ |internal compiler error: in
                   |field, at varasm.cc:5521    |output_constructor_regular_
                   |                            |field, at varasm.cc:5521
   Target Milestone|---                         |10.5
           Priority|P3                          |P2

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug c/109113] [10/11/12/13 Regression] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with my r8-6028-gb4923738ef57a441f6f9
struct A { int a; };
struct B { int b; struct A c[]; };
struct C { int d; struct B e[]; };
const struct B f = { .c = { 1 } };
struct C g = { .e = { f } };
struct C h = { .e = { f, f } };

The question is if we want to accept the g initializer and reject just the h
one, or reject both.  g compiles fine though and could be useful...

[Bug c/109113] [10/11/12/13 Regression] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And C++ ICEs on this starting with r8-4783-gd68ddd2b35078ab61f164b268b
(again, accepts the g case).
C++ used to ICE on
struct C i = { .e = { { .b = 0, .c = { 1 } }, f } };
since that revision but since r8-5342-ga8c55cacaf8fa1e90f9e26c it also rejects
it.

[Bug c/109113] [10/11/12/13 Regression] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |jsm28 at gcc dot gnu.org,
                   |                            |rsandifo at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And it is actually far worse than just the ICEs.
Consider:
struct A { int a; };
struct B { int b; struct A c[]; };
struct C { int d; struct B e[]; };
struct D { int f; int g[]; };
struct E { int h; struct D i[]; };
struct B j = { .c = { { 1 } } };
struct C k = { .e = { j, j } };
struct D l = { .g = { 1 } };
struct E m = { .i = { l, l } };
in C++, or say:
struct A { int a; };
struct B { int b; struct A c[]; };
struct D { int f; int g[]; };
struct B j = { .c = { { 1 } } };
struct D l = { .g = { 1 } };
struct B k;
struct D m;

int
main ()
{
  k = j;
  m = l;
}
in C/C++.  These compile fine, but at runtime copy not just the sizeof (int)
bytes that
the destination has for the type, but actually 8 bytes.
So, e.g. in the latter testcase, k and m are 4 byte, while j and l are 8 byte,
and at least for C since I think r0-73097-g1f0f7cebf9eccfa3c9ba the assignments
copy 8 bytes rather than 4 bytes they copied previously.  In C++ that is since
my
r12-3526-g818c505188ff5cd8eb048eb change.  So, I think we want to figure out
what to do about those runtime copies first (whether they only copy the type's
size or what else),
and once that is decided, handle the constant cases the same, since anything
else would be just weird.  But in that case #c7 would be valid and would just
copy into the initializer everything but the flexible array member from the
const vars.  Or do we want to treat that way only vars in the non-trailing
positions (where putting there their initializer by hand would result in the
above mentioned error) and for the use at the trailing position act as if the
complete initializer appeared there (i.e. initialize the flexible array member
also))?

[Bug c/109113] [10/11/12/13 Regression] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 54674
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54674&action=edit
gcc13-pr109113-tests.patch

I started writing tests related to this PR before running into the above issue,
which might change what is valid and what isn't.

[Bug c/109113] [11/12/13/14 Regression] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.