* [PATCH] Silence some dwarf2out UNSPEC related notes (PR debug/88723)
@ 2019-01-07 9:49 Jakub Jelinek
2019-01-07 9:50 ` Richard Biener
2019-01-22 9:50 ` UNSPEC related notes and libbacktrace (was: [PATCH] Silence some dwarf2out UNSPEC related notes (PR debug/88723)) Gerald Pfeifer
0 siblings, 2 replies; 4+ messages in thread
From: Jakub Jelinek @ 2019-01-07 9:49 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] Silence some dwarf2out UNSPEC related notes (PR debug/88723)
2019-01-07 9:49 [PATCH] Silence some dwarf2out UNSPEC related notes (PR debug/88723) Jakub Jelinek
@ 2019-01-07 9:50 ` Richard Biener
2019-01-22 9:50 ` UNSPEC related notes and libbacktrace (was: [PATCH] Silence some dwarf2out UNSPEC related notes (PR debug/88723)) Gerald Pfeifer
1 sibling, 0 replies; 4+ messages in thread
From: Richard Biener @ 2019-01-07 9:50 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
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)
^ permalink raw reply [flat|nested] 4+ messages in thread* UNSPEC related notes and libbacktrace (was: [PATCH] Silence some dwarf2out UNSPEC related notes (PR debug/88723))
2019-01-07 9:49 [PATCH] Silence some dwarf2out UNSPEC related notes (PR debug/88723) Jakub Jelinek
2019-01-07 9:50 ` Richard Biener
@ 2019-01-22 9:50 ` Gerald Pfeifer
2019-01-23 9:29 ` UNSPEC related notes and libbacktrace Martin Liška
1 sibling, 1 reply; 4+ messages in thread
From: Gerald Pfeifer @ 2019-01-22 9:50 UTC (permalink / raw)
To: Jakub Jelinek, Tom de Vries, Ian Lance Taylor; +Cc: Richard Biener, gcc-patches
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-01-23 8:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-07 9:49 [PATCH] Silence some dwarf2out UNSPEC related notes (PR debug/88723) Jakub Jelinek
2019-01-07 9:50 ` Richard Biener
2019-01-22 9:50 ` UNSPEC related notes and libbacktrace (was: [PATCH] Silence some dwarf2out UNSPEC related notes (PR debug/88723)) Gerald Pfeifer
2019-01-23 9:29 ` UNSPEC related notes and libbacktrace Martin Liška
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).