This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails


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

--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
So if I instrument build_string_literal with

Index: builtins.c
===================================================================
--- builtins.c  (revision 213814)
+++ builtins.c  (working copy)
@@ -59,6 +59,8 @@ along with GCC; see the file COPYING3.
 #include "builtins.h"
 #include "ubsan.h"
 #include "cilk.h"
+#include "dumpfile.h"
+#include "tree-pretty-print.h"


 static tree do_mpc_arg1 (tree, tree, int (*)(mpc_ptr, mpc_srcptr, mpc_rnd_t));
@@ -4695,6 +4697,15 @@ build_string_literal (int len, const cha
   elem = build_type_variant (char_type_node, 1, 0);
   index = build_index_type (size_int (len - 1));
   type = build_array_type (elem, index);
+  fprintf (stderr, "%s <%p> ", str, (void *)type);
+  print_generic_expr (stderr, type, TDF_SLIM);
+  if (TYPE_MAIN_VARIANT (type) == type)
+    ;
+  else
+    {
+      fprintf (stderr, " <%p> ", (void *)TYPE_MAIN_VARIANT (type));
+      print_generic_expr (stderr, TYPE_MAIN_VARIANT (type), TDF_SLIM);
+    }
+  fprintf (stderr, "\n");
   TREE_TYPE (t) = type;
   TREE_CONSTANT (t) = 1;
   TREE_READONLY (t) = 1;


then I get for building non-LTO stage2 build/genconfig.o

#ifndef MAX_INSNS_PER_SPLIT
 <0x7ffff5af4e70> const char[28]
#endif
 <0x7ffff5af6000> const char[7]
#define HAVE_cc0 1
 <0x7ffff5af6150> const char[19]
#define CC0_P(X) ((X) == cc0_rtx)
 <0x7ffff5af62a0> const char[34]
#define CC0_P(X) ((X) ? 0 : 0)
 <0x7ffff5aef540> const char[31] <0x7ffff5aef498> char[31]
#define HAVE_conditional_move 1
 <0x7ffff5aefe70> const char[32] <0x7ffff5de6d20> char[32]
#define HAVE_conditional_execution 1
 <0x7ffff5af6690> const char[37]
#define HAVE_lo_sum 1
 <0x7ffff5af67e0> const char[22]
#define HAVE_peephole 1
 <0x7ffff5af6930> const char[24]
#define HAVE_peephole2 1
 <0x7ffff5af45e8> const char[25] <0x7ffff5af4540> char[25]

and for stage3:

#ifndef MAX_INSNS_PER_SPLIT
 <0x7ffff5db9150> const char[28]
#endif
 <0x7ffff601bc78> const char[7] <0x7ffff601bbd0> char[7]
#define HAVE_cc0 1
 <0x7ffff5db93f0> const char[19]
#define CC0_P(X) ((X) == cc0_rtx)
 <0x7ffff5db9540> const char[34]
#define CC0_P(X) ((X) ? 0 : 0)
 <0x7ffff5db17e0> const char[31] <0x7ffff5db1738> char[31]
#define HAVE_conditional_move 1
 <0x7ffff5db4150> const char[32] <0x7ffff6017888> char[32]
#define HAVE_conditional_execution 1
 <0x7ffff5db9930> const char[37]
#define HAVE_lo_sum 1
 <0x7ffff5db9a80> const char[22]
#define HAVE_peephole 1
 <0x7ffff5db9bd0> const char[24]
#define HAVE_peephole2 1
 <0x7ffff5db5888> const char[25] <0x7ffff5db57e0> char[25]

so whether the #endif literal has a TYPE_MAIN_VARIANT or not changes.
Which means in one case somebody builds that very same array type
earlier.

Instrumenting build_array_type I see that stage3 doesn't build some
types stage2 builds.  Weird.

Ah.  Well - type_hash_table is marked as GC-able thus when using the
stage1 compiler we run with --param ggc-min-expand=30 --param
ggc-min-heapsize=4096 but when using the stage2 compiler we use
--param ggc-min-expand=100 --param ggc-min-heapsize=131072.

using the same --param settings for stage2 fixes this difference
(but not fully the miscompare in the LTO object).

But this _is_ an issue for reproducability of LTO IL (and types
in general).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]