gcc 8 ICEs on python 2 and 3 on hppa:
In file included from Include/Python.h:94,
from Objects/complexobject.c:8:
Objects/complexobject.c: In function '_Py_c_pow':
Include/complexobject.h:21:15: internal compiler error: in expand_expr_addr_expr_1, at expr.c:8026
#define c_pow _Py_c_pow
^~~~~~~~~
Objects/complexobject.c:128:1: note: in expansion of macro 'c_pow'
c_pow(Py_complex a, Py_complex b)
^~~~~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
I found this bug report and fix for gcc 9 that fixes the ICE
on hppa and opens up a bunch of ports to be built that depend
on python 2/3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89487
So far I've only tested this on hppa with small number of ports.
Can bulk builders include this patch on other arches to get better
test coverage?
Index: Makefile
===================================================================
RCS file: /cvs/ports/lang/gcc/8/Makefile,v
retrieving revision 1.39
diff -u -p -u -r1.39 Makefile
--- Makefile 24 Jan 2021 04:41:50 -0000 1.39
+++ Makefile 4 Feb 2021 13:30:19 -0000
@@ -18,7 +18,7 @@ DPB_PROPERTIES = parallel
V = 8.4.0
FULL_VERSION = $V
FULL_PKGVERSION = $V
-REVISION = 4
+REVISION = 5
ADASTRAP-amd64 = adastrap-amd64-8.3.0-2.tar.xz
ADASTRAP-arm = adastrap-arm-4.9.4-0.tar.xz
Index: patches/patch-gcc_tree-loop-distribution_c
===================================================================
RCS file: patches/patch-gcc_tree-loop-distribution_c
diff -N patches/patch-gcc_tree-loop-distribution_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-gcc_tree-loop-distribution_c 4 Feb 2021 13:30:19 -0000
@@ -0,0 +1,46 @@
+$OpenBSD$
+
+Backport fix for PR tree-optimization/89487
+
+Index: gcc/tree-loop-distribution.c
+--- gcc/tree-loop-distribution.c.orig
++++ gcc/tree-loop-distribution.c
+@@ -161,6 +161,9 @@ static vec<loop_p> loop_nest;
+ /* Vector of data references in the loop to be distributed. */
+ static vec<data_reference_p> datarefs_vec;
+
++/* If there is nonaddressable data reference in above vector. */
++static bool has_nonaddressable_dataref_p;
++
+ /* Store index of data reference in aux field. */
+ #define DR_INDEX(dr) ((uintptr_t) (dr)->aux)
+
+@@ -468,6 +471,7 @@ create_rdg_vertices (struct graph *rdg, vec<gimple *>
+ else
+ RDGV_HAS_MEM_WRITE (v) = true;
+ RDGV_DATAREFS (v).safe_push (dr);
++ has_nonaddressable_dataref_p |= may_be_nonaddressable_p (dr->ref);
+ }
+ }
+ return true;
+@@ -2734,6 +2738,7 @@ distribute_loop (struct loop *loop, vec<gimple *> stmt
+ }
+
+ datarefs_vec.create (20);
++ has_nonaddressable_dataref_p = false;
+ rdg = build_rdg (loop, cd);
+ if (!rdg)
+ {
+@@ -2862,8 +2867,10 @@ distribute_loop (struct loop *loop, vec<gimple *> stmt
+ if (partitions.length () > 1)
+ {
+ /* Don't support loop nest distribution under runtime alias check
+- since it's not likely to enable many vectorization opportunities. */
+- if (loop->inner)
++ since it's not likely to enable many vectorization opportunities.
++ Also if loop has any data reference which may be not addressable
++ since alias check needs to take, compare address of the object. */
++ if (loop->inner || has_nonaddressable_dataref_p)
+ merge_dep_scc_partitions (rdg, &partitions, false);
+ else
+ {
Index: patches/patch-gcc_tree-ssa-loop-ivopts_c
===================================================================
RCS file: patches/patch-gcc_tree-ssa-loop-ivopts_c
diff -N patches/patch-gcc_tree-ssa-loop-ivopts_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-gcc_tree-ssa-loop-ivopts_c 4 Feb 2021 13:30:19 -0000
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+Backport fix for PR tree-optimization/89487
+
+Index: gcc/tree-ssa-loop-ivopts.c
+--- gcc/tree-ssa-loop-ivopts.c.orig
++++ gcc/tree-ssa-loop-ivopts.c
+@@ -2247,6 +2247,10 @@ may_be_nonaddressable_p (tree expr)
+ {
+ switch (TREE_CODE (expr))
+ {
++ case VAR_DECL:
++ /* Check if it's a register variable. */
++ return DECL_HARD_REGISTER (expr);
++
+ case TARGET_MEM_REF:
+ /* TARGET_MEM_REFs are translated directly to valid MEMs on the
+ target, thus they are always addressable. */
No comments:
Post a Comment