[PATCH] Silence some dwarf2out UNSPEC related notes (PR debug/88723)

[PATCH] Silence some dwarf2out UNSPEC related notes (PR debug/88723)

[Jakub Jelinek]

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  <jakub@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

Re: [PATCH] Silence some dwarf2out UNSPEC related notes (PR debug/88723)

[Richard Biener]

On Mon, 7 Jan 2019, Jakub Jelinek wrote:

> 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?

OK.

Richard.

> 2019-01-07  Jakub Jelinek  <jakub@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
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)

UNSPEC related notes and libbacktrace (was: [PATCH] Silence some dwarf2out UNSPEC related notes (PR debug/88723))

[Gerald Pfeifer]

On Mon, 7 Jan 2019, Jakub Jelinek wrote:
> Apparently my recent patch turned on many non-delegitimized UNSPEC notes
> (it is checking only note, goes away in release builds, but anyway).

I've been seeing the following in my testsuite runs which I didn't
get a month or so ago.  Are these due to your changes, Jakub, or 
some changes around libbacktrace?

i586-unknown-freebsd11 (and not on amd64-unknown-freebsd12, so may
be another 32-bit-specific issue)?

/scratch/tmp/gerald/GCC-HEAD/libbacktrace/pecoff.c: In function 'coff_nosyms':
/scratch/tmp/gerald/GCC-HEAD/libbacktrace/pecoff.c:209:1: note: non-delegitimized UNSPEC UNSPEC_SET_GOT (14) found in variable location
  209 | coff_nosyms (struct backtrace_state *state ATTRIBUTE_UNUSED,
      | ^~~~~~~~~~~
/scratch/tmp/gerald/GCC-HEAD/libbacktrace/pecoff.c: In function 'coff_nosyms':
/scratch/tmp/gerald/GCC-HEAD/libbacktrace/pecoff.c:209:1: note: non-delegitimized UNSPEC UNSPEC_SET_GOT (14) found in variable location
  209 | coff_nosyms (struct backtrace_state *state ATTRIBUTE_UNUSED,
      | ^~~~~~~~~~~
xcoff_32.c: In function 'xcoff_nosyms':
xcoff_32.c:431:1: note: non-delegitimized UNSPEC UNSPEC_SET_GOT (14) found in variable location
  431 | xcoff_nosyms (struct backtrace_state *state ATTRIBUTE_UNUSED,
      | ^~~~~~~~~~~~
xcoff_32.c: In function 'xcoff_nosyms':
xcoff_32.c:431:1: note: non-delegitimized UNSPEC UNSPEC_SET_GOT (14) found in variable location
  431 | xcoff_nosyms (struct backtrace_state *state ATTRIBUTE_UNUSED,
      | ^~~~~~~~~~~~
xcoff_64.c: In function 'xcoff_nosyms':
xcoff_64.c:431:1: note: non-delegitimized UNSPEC UNSPEC_SET_GOT (14) found in variable location
  431 | xcoff_nosyms (struct backtrace_state *state ATTRIBUTE_UNUSED,
      | ^~~~~~~~~~~~
xcoff_64.c: In function 'xcoff_nosyms':
xcoff_64.c:431:1: note: non-delegitimized UNSPEC UNSPEC_SET_GOT (14) found in variable location
  431 | xcoff_nosyms (struct backtrace_state *state ATTRIBUTE_UNUSED,
      | ^~~~~~~~~~~~

Gerald

Re: UNSPEC related notes and libbacktrace

[Martin Liška]

On 1/22/19 10:50 AM, Gerald Pfeifer wrote:
> I've been seeing the following in my testsuite runs which I didn't
> get a month or so ago.  Are these due to your changes, Jakub, or 
> some changes around libbacktrace?

I can confirm that and I've just created a PR for it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89006

Martin