As mentioned in the PR and as can be seen on:
--- gcc/testsuite/gcc.dg/pch/pr104323-1.c.jj 2022-02-01 13:06:00.163192414 +0100
+++ gcc/testsuite/gcc.dg/pch/pr104323-1.c 2022-02-01 13:13:41.226712735 +0100
@@ -0,0 +1,16 @@
+/* PR target/104323 */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec" } */
+
+#include "pr104323-1.h"
+
+__vector int a1 = { 100, 200, 300, 400 };
+__vector int a2 = { 500, 600, 700, 800 };
+__vector int r;
+
+int
+main ()
+{
+ r = vec_add (a1, a2);
+ return 0;
+}
--- gcc/testsuite/gcc.dg/pch/pr104323-1.hs.jj 2022-02-01 13:06:03.180149978 +0100
+++ gcc/testsuite/gcc.dg/pch/pr104323-1.hs 2022-02-01 13:12:30.175706620 +0100
@@ -0,0 +1,5 @@
+/* PR target/104323 */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec" } */
+
+#include <altivec.h>
testcase which I'm not including into testsuite because for some reason
the test fails on non-powerpc* targets (is done even on those and fails
because of missing altivec.h etc.), PCH is broken on powerpc*-*-* since the
new builtin generator has been introduced.
The generator contains or emits comments like:
/* #### Cannot mark this as a GC root because only pointer types can
be marked as GTY((user)) and be GC roots. All trees in here are
kept alive by other globals, so not a big deal. Alternatively,
we could change the enum fields to ints and cast them in and out
to avoid requiring a GTY((user)) designation, but that seems
unnecessarily gross. */
Having the fntypes stored in other GC roots can work fine for GC,
ggc_collect will then always mark them and so they won't disappear from
the tables, but it definitely doesn't work for PCH, which when the
arrays with fntype members aren't GTY marked means on PCH write we create
copies of those FUNCTION_TYPEs and store in *.gch that the GC roots should
be updated, but don't store that rs6000_builtin_info[?].fntype etc. should
be updated. When PCH is read again, the blob is read at some other address,
GC roots are updated, rs6000_builtin_info[?].fntype contains garbage
pointers (GC freed pointers with random data, or random unrelated types or
other trees).
The following patch fixes that. It stops any user markings because that
is totally unnecessary, just skips fields we don't need to mark and adds
GTY(()) to the 2 array variables. We can get rid of all those global
vars for the fn types, they can be now automatic vars.
With the patch we get
{
&rs6000_instance_info[0].fntype,
1 * (RS6000_INST_MAX),
sizeof (rs6000_instance_info[0]),
>_ggc_mx_tree_node,
>_pch_nx_tree_node
},
{
&rs6000_builtin_info[0].fntype,
1 * (RS6000_BIF_MAX),
sizeof (rs6000_builtin_info[0]),
>_ggc_mx_tree_node,
>_pch_nx_tree_node
},
as the new roots which is exactly what we want and significantly more
compact than countless
{
&uv2di_ftype_pudi_usi,
1,
sizeof (uv2di_ftype_pudi_usi),
>_ggc_mx_tree_node,
>_pch_nx_tree_node
},
{
&uv2di_ftype_lg_puv2di,
1,
sizeof (uv2di_ftype_lg_puv2di),
>_ggc_mx_tree_node,
>_pch_nx_tree_node
},
{
&uv2di_ftype_lg_pudi,
1,
sizeof (uv2di_ftype_lg_pudi),
>_ggc_mx_tree_node,
>_pch_nx_tree_node
},
{
&uv2di_ftype_di_puv2di,
1,
sizeof (uv2di_ftype_di_puv2di),
>_ggc_mx_tree_node,
>_pch_nx_tree_node
},
cases (822 of these instead of just those 4 shown).
2022-02-01 Jakub Jelinek <jakub@redhat.com>
PR target/104323
* config/rs6000/t-rs6000 (EXTRA_GTYPE_DEPS): Append rs6000-builtins.h
rather than $(srcdir)/config/rs6000/rs6000-builtins.def.
* config/rs6000/rs6000-gen-builtins.cc (write_decls): Don't use
GTY((user)) for struct bifdata and struct ovlddata. Instead add
GTY((skip(""))) to members with pointer and enum types that don't need
to be tracked. Add GTY(()) to rs6000_builtin_info and rs6000_instance_info
declarations. Don't emit gt_ggc_mx and gt_pch_nx declarations.
(write_extern_fntype, write_fntype): Remove.
(write_fntype_init): Emit the fntype vars as automatic vars instead
of file scope ones.
(write_header_file): Don't iterate with write_extern_fntype.
(write_init_file): Don't iterate with write_fntype. Don't emit
gt_ggc_mx and gt_pch_nx definitions.
This directory contains the GNU Compiler Collection (GCC).
The GNU Compiler Collection is free software. See the files whose
names start with COPYING for copying permission. The manuals, and
some of the runtime libraries, are under different terms; see the
individual source files for details.
The directory INSTALL contains copies of the installation information
as HTML and plain text. The source of this information is
gcc/doc/install.texi. The installation information includes details
of what is included in the GCC sources and what files GCC installs.
See the file gcc/doc/gcc.texi (together with other files that it
includes) for usage and porting information. An online readable
version of the manual is in the files gcc/doc/gcc.info*.
See http://gcc.gnu.org/bugs/ for how to report bugs usefully.
Copyright years on GCC source files may be listed using range
notation, e.g., 1987-2012, indicating that every year in the range,
inclusive, is a copyrightable year that could otherwise be listed
individually.
fa882c3e3b