Hi!
Apparently my recent patch turned on many non-delegitimized UNSPEC notes
(it is checking only note, goes away in release builds, but anyway).
The problem is that formerly UNSPECs were diagnosed that way only when
inside of CONST, but now also outside of them. The patch keeps ignoring
them if they don't have all constant arguments though as before, only tries
to handle them if they have all constant arguments and thus normally would
appear inside of CONST but we are processing parts of the CONST
individually.
The following patch fixes it by determining first if they have all
CONSTANT_P arguments, and only if they do, follows that with
const_ok_for_output_1 verification which can emit this diagnostics.
The patch also removes what appears to be a badly applied patch in r255862,
the posted patch contained just addition of if (CONST_POLY_INT_P (rtl)) return
false;
to the function, but added also the hunk I'm removing, so we have now
if (targetm.const_not_ok_for_debug_p (rtl))
{
if (GET_CODE (rtl) != UNSPEC)
{
diagnostics;
return false;
}
another diagnostics;
return false;
}
if (CONST_POLY_INT_P (rtl))
return false;
if (targetm.const_not_ok_for_debug_p (rtl))
{
diagnostics;
return false;
}
Calling it twice will not help in any way.
Bootstrapped/regtested on x86_64-linux and i686-linux, plus tested on the
testcase with -> sparc-solaris cross-compiler, ok for trunk?
2019-01-07 Jakub Jelinek <ja...@redhat.com>
PR debug/88723
* dwarf2out.c (const_ok_for_output_1): Remove redundant call to
const_not_ok_for_debug_p target hook.
(mem_loc_descriptor) <case UNSPEC>: Only call const_ok_for_output_1
on UNSPEC and subexpressions thereof if all subexpressions of the
UNSPEC are CONSTANT_P.
--- gcc/dwarf2out.c.jj 2019-01-05 12:10:36.630753817 +0100
+++ gcc/dwarf2out.c 2019-01-06 21:33:58.583426865 +0100
@@ -14445,13 +14445,6 @@ const_ok_for_output_1 (rtx rtl)
if (CONST_POLY_INT_P (rtl))
return false;
- if (targetm.const_not_ok_for_debug_p (rtl))
- {
- expansion_failed (NULL_TREE, rtl,
- "Expression rejected for debug by the backend.\n");
- return false;
- }
-
/* FIXME: Refer to PR60655. It is possible for simplification
of rtl expressions in var tracking to produce such expressions.
We should really identify / validate expressions
@@ -15660,8 +15653,17 @@ mem_loc_descriptor (rtx rtl, machine_mod
bool not_ok = false;
subrtx_var_iterator::array_type array;
FOR_EACH_SUBRTX_VAR (iter, array, rtl, ALL)
- if ((*iter != rtl && !CONSTANT_P (*iter))
- || !const_ok_for_output_1 (*iter))
+ if (*iter != rtl && !CONSTANT_P (*iter))
+ {
+ not_ok = true;
+ break;
+ }
+
+ if (not_ok)
+ break;
+
+ FOR_EACH_SUBRTX_VAR (iter, array, rtl, ALL)
+ if (!const_ok_for_output_1 (*iter))
{
not_ok = true;
break;
Jakub
