* [PATCH] c++/97197 - support TARGET_MEM_REF in C/C++ error pretty-printing
@ 2020-09-25 11:11 Richard Biener
2020-09-25 11:20 ` Jakub Jelinek
0 siblings, 1 reply; 4+ messages in thread
From: Richard Biener @ 2020-09-25 11:11 UTC (permalink / raw)
To: gcc-patches; +Cc: jakub
This adds rough support to avoid "'target_mem_ref' not supported by"
in diagnostics. There were recent patches by Martin to sanitize
dumping of MEM_REF so I'm not trying to interfere with this here.
Bootstrap & regtest pending.
OK?
2020-09-25 Richard Biener <rguenther@suse.de>
PR c++/97197
cp/
* error.c (dump_expr): Handle TARGET_MEM_REF as if it
were MEM_REF.
c-family/
* c-pretty-print.c (c_pretty_printer::postfix_expression):
Handle TARGET_MEM_REF as expression.
(c_pretty_printer::expression): Handle TARGET_MEM_REF as
unary_expression.
(c_pretty_printer::unary_expression): Handle TARGET_MEM_REF
as if it were MEM_REF.
---
gcc/c-family/c-pretty-print.c | 3 +++
gcc/cp/error.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/gcc/c-family/c-pretty-print.c b/gcc/c-family/c-pretty-print.c
index acffd7b872c..1a0edb82312 100644
--- a/gcc/c-family/c-pretty-print.c
+++ b/gcc/c-family/c-pretty-print.c
@@ -1693,6 +1693,7 @@ c_pretty_printer::postfix_expression (tree e)
break;
case MEM_REF:
+ case TARGET_MEM_REF:
expression (e);
break;
@@ -1833,6 +1834,7 @@ c_pretty_printer::unary_expression (tree e)
break;
case MEM_REF:
+ case TARGET_MEM_REF:
if (TREE_CODE (TREE_OPERAND (e, 0)) == ADDR_EXPR
&& integer_zerop (TREE_OPERAND (e, 1)))
expression (TREE_OPERAND (TREE_OPERAND (e, 0), 0));
@@ -2295,6 +2297,7 @@ c_pretty_printer::expression (tree e)
case ADDR_EXPR:
case INDIRECT_REF:
case MEM_REF:
+ case TARGET_MEM_REF:
case NEGATE_EXPR:
case BIT_NOT_EXPR:
case TRUTH_NOT_EXPR:
diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index ecb41e82d8c..c9a0c1e0288 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -2372,6 +2372,7 @@ dump_expr (cxx_pretty_printer *pp, tree t, int flags)
break;
case MEM_REF:
+ case TARGET_MEM_REF:
if (TREE_CODE (TREE_OPERAND (t, 0)) == ADDR_EXPR
&& integer_zerop (TREE_OPERAND (t, 1)))
dump_expr (pp, TREE_OPERAND (TREE_OPERAND (t, 0), 0), flags);
--
2.26.2
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] c++/97197 - support TARGET_MEM_REF in C/C++ error pretty-printing
2020-09-25 11:11 [PATCH] c++/97197 - support TARGET_MEM_REF in C/C++ error pretty-printing Richard Biener
@ 2020-09-25 11:20 ` Jakub Jelinek
2020-09-25 11:37 ` Richard Biener
0 siblings, 1 reply; 4+ messages in thread
From: Jakub Jelinek @ 2020-09-25 11:20 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
On Fri, Sep 25, 2020 at 01:11:37PM +0200, Richard Biener wrote:
> This adds rough support to avoid "'target_mem_ref' not supported by"
> in diagnostics. There were recent patches by Martin to sanitize
> dumping of MEM_REF so I'm not trying to interfere with this here.
Is that correct?
I mean, TARGET_MEM_REF encodes more than what MEM_REF encodes,
so printing it like MEM_REF will ignore many things from there.
I'd say we should print it like:
*(type *)(BASE + STEP * INDEX + INDEX2 + OFFSET)
rather than how we print MEM_REFs as
*(type *)(BASE + OFFSET)
(with skipping whatever is NULL in there).
So instead of adding case MEM_REF: in the second and last hunk
copy and edit it (perhaps kill the probably unnecessary
part that checks for *&foo and prints it as foo, because who would
create TARGET_MEM_REF when MEM_REF could have been used in that case).
>
> Bootstrap & regtest pending.
>
> OK?
>
> 2020-09-25 Richard Biener <rguenther@suse.de>
>
> PR c++/97197
> cp/
> * error.c (dump_expr): Handle TARGET_MEM_REF as if it
> were MEM_REF.
>
> c-family/
> * c-pretty-print.c (c_pretty_printer::postfix_expression):
> Handle TARGET_MEM_REF as expression.
> (c_pretty_printer::expression): Handle TARGET_MEM_REF as
> unary_expression.
> (c_pretty_printer::unary_expression): Handle TARGET_MEM_REF
> as if it were MEM_REF.
Jakub
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] c++/97197 - support TARGET_MEM_REF in C/C++ error pretty-printing
2020-09-25 11:20 ` Jakub Jelinek
@ 2020-09-25 11:37 ` Richard Biener
2020-09-25 13:38 ` [PATCH v2] " Jakub Jelinek
0 siblings, 1 reply; 4+ messages in thread
From: Richard Biener @ 2020-09-25 11:37 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
On Fri, 25 Sep 2020, Jakub Jelinek wrote:
> On Fri, Sep 25, 2020 at 01:11:37PM +0200, Richard Biener wrote:
> > This adds rough support to avoid "'target_mem_ref' not supported by"
> > in diagnostics. There were recent patches by Martin to sanitize
> > dumping of MEM_REF so I'm not trying to interfere with this here.
>
> Is that correct?
> I mean, TARGET_MEM_REF encodes more than what MEM_REF encodes,
> so printing it like MEM_REF will ignore many things from there.
> I'd say we should print it like:
> *(type *)(BASE + STEP * INDEX + INDEX2 + OFFSET)
> rather than how we print MEM_REFs as
> *(type *)(BASE + OFFSET)
> (with skipping whatever is NULL in there).
> So instead of adding case MEM_REF: in the second and last hunk
> copy and edit it (perhaps kill the probably unnecessary
> part that checks for *&foo and prints it as foo, because who would
> create TARGET_MEM_REF when MEM_REF could have been used in that case).
See my comment above for Martins attempts to improve things. I don't
really want to try decide what to do with those late diagnostic IL
printing but my commit was blamed for showing target-mem-ref unsupported.
I don't have much time to spend to think what to best print and what not,
but yes, printing only the MEM_REF part is certainly imprecise.
I'll leave the PR to FE folks.
Thanks,
Richard.
> >
> > Bootstrap & regtest pending.
> >
> > OK?
> >
> > 2020-09-25 Richard Biener <rguenther@suse.de>
> >
> > PR c++/97197
> > cp/
> > * error.c (dump_expr): Handle TARGET_MEM_REF as if it
> > were MEM_REF.
> >
> > c-family/
> > * c-pretty-print.c (c_pretty_printer::postfix_expression):
> > Handle TARGET_MEM_REF as expression.
> > (c_pretty_printer::expression): Handle TARGET_MEM_REF as
> > unary_expression.
> > (c_pretty_printer::unary_expression): Handle TARGET_MEM_REF
> > as if it were MEM_REF.
>
> Jakub
>
>
--
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend
^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH v2] c++/97197 - support TARGET_MEM_REF in C/C++ error pretty-printing
2020-09-25 11:37 ` Richard Biener
@ 2020-09-25 13:38 ` Jakub Jelinek
0 siblings, 0 replies; 4+ messages in thread
From: Jakub Jelinek @ 2020-09-25 13:38 UTC (permalink / raw)
To: Richard Biener, Jason Merrill, Joseph S. Myers; +Cc: gcc-patches
Hi!
On Fri, Sep 25, 2020 at 01:37:16PM +0200, Richard Biener wrote:
> See my comment above for Martins attempts to improve things. I don't
> really want to try decide what to do with those late diagnostic IL
> printing but my commit was blamed for showing target-mem-ref unsupported.
>
> I don't have much time to spend to think what to best print and what not,
> but yes, printing only the MEM_REF part is certainly imprecise.
Here is an updated version of the patch that prints TARGET_MEM_REF the way
it should be printed - as C representation of what it actually means.
Of course it would be better to have the original expressions, but with the
late diagnostics we no longer have them.
Ok for trunk if it passes bootstrap/regtest?
2020-09-25 Richard Biener <rguenther@suse.de>
Jakub Jelinek <jakub@redhat.com>
PR c++/97197
cp/
* error.c (dump_expr): Handle TARGET_MEM_REF.
c-family/
* c-pretty-print.c: Include langhooks.h.
(c_pretty_printer::postfix_expression): Handle TARGET_MEM_REF as
expression.
(c_pretty_printer::expression): Handle TARGET_MEM_REF as
unary_expression.
(c_pretty_printer::unary_expression): Handle TARGET_MEM_REF.
--- gcc/c-family/c-pretty-print.c.jj 2020-09-21 11:15:53.600520132 +0200
+++ gcc/c-family/c-pretty-print.c 2020-09-25 15:21:26.034477251 +0200
@@ -29,6 +29,7 @@ along with GCC; see the file COPYING3.
#include "intl.h"
#include "tree-pretty-print.h"
#include "selftest.h"
+#include "langhooks.h"
/* The pretty-printer code is primarily designed to closely follow
(GNU) C and C++ grammars. That is to be contrasted with spaghetti
@@ -1693,6 +1694,7 @@ c_pretty_printer::postfix_expression (tr
break;
case MEM_REF:
+ case TARGET_MEM_REF:
expression (e);
break;
@@ -1859,6 +1861,55 @@ c_pretty_printer::unary_expression (tree
}
break;
+ case TARGET_MEM_REF:
+ pp_c_star (this);
+ if (TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (TMR_BASE (e)))) == NULL_TREE
+ || !integer_onep (TYPE_SIZE_UNIT
+ (TREE_TYPE (TREE_TYPE (TMR_BASE (e))))))
+ {
+ if (TYPE_SIZE_UNIT (TREE_TYPE (e))
+ && integer_onep (TYPE_SIZE_UNIT (TREE_TYPE (e))))
+ {
+ pp_c_left_paren (this);
+ pp_c_type_cast (this, build_pointer_type (TREE_TYPE (e)));
+ }
+ else
+ {
+ pp_c_type_cast (this, build_pointer_type (TREE_TYPE (e)));
+ pp_c_left_paren (this);
+ pp_c_type_cast (this, build_pointer_type (char_type_node));
+ }
+ }
+ else if (!lang_hooks.types_compatible_p
+ (TREE_TYPE (e), TREE_TYPE (TREE_TYPE (TMR_BASE (e)))))
+ {
+ pp_c_type_cast (this, build_pointer_type (TREE_TYPE (e)));
+ pp_c_left_paren (this);
+ }
+ else
+ pp_c_left_paren (this);
+ pp_c_cast_expression (this, TMR_BASE (e));
+ if (TMR_STEP (e) && TMR_INDEX (e))
+ {
+ pp_plus (this);
+ pp_c_cast_expression (this, TMR_INDEX (e));
+ pp_c_star (this);
+ pp_c_cast_expression (this, TMR_STEP (e));
+ }
+ if (TMR_INDEX2 (e))
+ {
+ pp_plus (this);
+ pp_c_cast_expression (this, TMR_INDEX2 (e));
+ }
+ if (!integer_zerop (TMR_OFFSET (e)))
+ {
+ pp_plus (this);
+ pp_c_integer_constant (this,
+ fold_convert (ssizetype, TMR_OFFSET (e)));
+ }
+ pp_c_right_paren (this);
+ break;
+
case REALPART_EXPR:
case IMAGPART_EXPR:
pp_c_ws_string (this, code == REALPART_EXPR ? "__real__" : "__imag__");
@@ -2295,6 +2346,7 @@ c_pretty_printer::expression (tree e)
case ADDR_EXPR:
case INDIRECT_REF:
case MEM_REF:
+ case TARGET_MEM_REF:
case NEGATE_EXPR:
case BIT_NOT_EXPR:
case TRUTH_NOT_EXPR:
--- gcc/cp/error.c.jj 2020-07-28 15:39:09.780759362 +0200
+++ gcc/cp/error.c 2020-09-25 15:30:17.452823375 +0200
@@ -2400,6 +2400,57 @@ dump_expr (cxx_pretty_printer *pp, tree
}
break;
+ case TARGET_MEM_REF:
+ pp_cxx_star (pp);
+ pp_cxx_left_paren (pp);
+ if (TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (TMR_BASE (t)))) == NULL_TREE
+ || !integer_onep (TYPE_SIZE_UNIT
+ (TREE_TYPE (TREE_TYPE (TMR_BASE (t))))))
+ {
+ if (TYPE_SIZE_UNIT (TREE_TYPE (t))
+ && integer_onep (TYPE_SIZE_UNIT (TREE_TYPE (t))))
+ {
+ pp_cxx_left_paren (pp);
+ dump_type (pp, build_pointer_type (TREE_TYPE (t)), flags);
+ }
+ else
+ {
+ dump_type (pp, build_pointer_type (TREE_TYPE (t)), flags);
+ pp_cxx_right_paren (pp);
+ pp_cxx_left_paren (pp);
+ pp_cxx_left_paren (pp);
+ dump_type (pp, build_pointer_type (char_type_node), flags);
+ }
+ pp_cxx_right_paren (pp);
+ }
+ else if (!same_type_p (TREE_TYPE (t),
+ TREE_TYPE (TREE_TYPE (TMR_BASE (t)))))
+ {
+ dump_type (pp, build_pointer_type (TREE_TYPE (t)), flags);
+ pp_cxx_right_paren (pp);
+ pp_cxx_left_paren (pp);
+ }
+ dump_expr (pp, TMR_BASE (t), flags);
+ if (TMR_STEP (t) && TMR_INDEX (t))
+ {
+ pp_cxx_ws_string (pp, "+");
+ dump_expr (pp, TMR_INDEX (t), flags);
+ pp_cxx_ws_string (pp, "*");
+ dump_expr (pp, TMR_STEP (t), flags);
+ }
+ if (TMR_INDEX2 (t))
+ {
+ pp_cxx_ws_string (pp, "+");
+ dump_expr (pp, TMR_INDEX2 (t), flags);
+ }
+ if (!integer_zerop (TMR_OFFSET (t)))
+ {
+ pp_cxx_ws_string (pp, "+");
+ dump_expr (pp, fold_convert (ssizetype, TMR_OFFSET (t)), flags);
+ }
+ pp_cxx_right_paren (pp);
+ break;
+
case NEGATE_EXPR:
case BIT_NOT_EXPR:
case TRUTH_NOT_EXPR:
Jakub
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-09-25 13:38 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-25 11:11 [PATCH] c++/97197 - support TARGET_MEM_REF in C/C++ error pretty-printing Richard Biener
2020-09-25 11:20 ` Jakub Jelinek
2020-09-25 11:37 ` Richard Biener
2020-09-25 13:38 ` [PATCH v2] " Jakub Jelinek
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).