[Bug other/102605] New: address instruction from -fdump-tree-*-gimple doesn't work with -fgimple

[Bug other/102605] New: address instruction from -fdump-tree-*-gimple doesn't work with -fgimple

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605

            Bug ID: 102605
           Summary: address instruction from -fdump-tree-*-gimple doesn't
                    work with -fgimple
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aldyh at gcc dot gnu.org
            Blocks: 101057
  Target Milestone: ---

The following snippet:

$ cat y.c
void bar();

char global[10];

void foo(char *p)
{
  if (&global[2] == p)
    bar();
}

...when converted to GIMPLE:

$ ./cc1 y.c -fdump-tree-ssa-gimple -quiet
$ cat y.c.022t.ssa 
void __GIMPLE (ssa)
foo (char * p)
{
  __BB(2):
  if (p_2(D) == &global[2])
    goto __BB3;
  else
    goto __BB4;

  __BB(3):
  bar ();
  goto __BB4;

  __BB(4):
  return;

}

Does not compile with -fgimple:

$ mv y.c.022t.ssa z.c

$ ./cc1 z.c -fgimple -quiet
z.c: In function ‘foo’:
z.c:5:17: error: expected expression before ‘&’ token
    5 |   if (p_2(D) == &global[2])
      |                 ^
z.c: At top level:
z.c:5:27: error: expected identifier or ‘(’ before ‘)’ token
    5 |   if (p_2(D) == &global[2])
      |                           ^
z.c:7:3: error: expected identifier or ‘(’ before ‘else’
    7 |   else
      |   ^~~~
z.c:10:8: error: expected declaration specifiers or ‘...’ before numeric
constant
   10 |   __BB(3):
      |        ^
z.c:12:3: error: expected identifier or ‘(’ before ‘goto’
   12 |   goto __BB4;
      |   ^~~~
z.c:14:8: error: expected declaration specifiers or ‘...’ before numeric
constant
   14 |   __BB(4):
      |        ^
z.c:17:1: error: expected identifier or ‘(’ before ‘}’ token
   17 | }
      | ^

Is the output from -fdump-tree-*-gimple suppose to be compilable by -fgimple? 
If not, what is the appropriate way of representing &global[2] in the gimple
FE?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101057
[Bug 101057] [gimplefe] GIMPLE frontend issues

[Bug other/102605] address instruction from -fdump-tree-*-gimple doesn't work with -fgimple

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2021-10-05

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
You need

  if (p_2(D) == _Literal (char *) &global[2])

and of course you need to provide the

char global[10];

declaration.  And then we still need to fix some sanity checking in the
frontend.

diff --git a/gcc/c/gimple-parser.c b/gcc/c/gimple-parser.c
index c8d9db61f0a..c43ee38a2cf 100644
--- a/gcc/c/gimple-parser.c
+++ b/gcc/c/gimple-parser.c
@@ -1622,16 +1622,20 @@ c_parser_gimple_postfix_expression (gimple_parser
&parser)
                  tree val = c_parser_gimple_postfix_expression (parser).value;
                  if (! val
                      || val == error_mark_node
-                     || (!CONSTANT_CLASS_P (val)
-                         && !(addr_p
-                              && (TREE_CODE (val) == STRING_CST
-                                  || DECL_P (val)))))
+                     || (!CONSTANT_CLASS_P (val) && !addr_p))
                    {
                      c_parser_error (parser, "invalid _Literal");
                      return expr;
                    }
                  if (addr_p)
-                   val = build1 (ADDR_EXPR, type, val);
+                   {
+                     val = build1 (ADDR_EXPR, type, val);
+                     if (!is_gimple_invariant_address (val))
+                       {
+                         c_parser_error (parser, "invalid _Literal");
+                         return expr;
+                       }
+                   }
                  if (neg_p)
                    {
                      val = const_unop (NEGATE_EXPR, TREE_TYPE (val), val);

[Bug other/102605] address instruction from -fdump-tree-*-gimple doesn't work with -fgimple

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> You need
> 
>   if (p_2(D) == _Literal (char *) &global[2])
> 
> and of course you need to provide the
> 
> char global[10];
> 
> declaration.  And then we still need to fix some sanity checking in the
> frontend.

Thanks for the patch.  I'll need something like it in order to write some jump
threading tests for missing MEM_REF cases.

It would be nice if -fdump-tree-*-gimple would match what -fgimple expects, at
the least with regards to this _Literal business.

BTW, the __MEM_REF output from the dumps does not work in -fgimple either. 
More errors.

Thanks.

[Bug other/102605] address instruction from -fdump-tree-*-gimple doesn't work with -fgimple

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:d4f6dbe18374385b8199ca3d6121e37a1189b589

commit r12-4187-gd4f6dbe18374385b8199ca3d6121e37a1189b589
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Oct 5 14:18:09 2021 +0200

    Allow more kinds of invariant addresses in GIMPLE FE

    The gimple FE is too restrictive in what it accepts as
    literals, the following makes it also accept &a[10] for example.

    2021-10-05  Richard Biener  <rguenther@suse.de>

            PR c/102605
    gcc/c/
            * gimple-parser.c (c_parser_gimple_postfix_expression):
            Accept more address _Literals.

    gcc/testsuite/
            * gcc.dg/gimplefe-46.c: New testcase.

[Bug other/102605] address instruction from -fdump-tree-*-gimple doesn't work with -fgimple

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 5 Oct 2021, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605
> 
> --- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #1)
> > You need
> > 
> >   if (p_2(D) == _Literal (char *) &global[2])
> > 
> > and of course you need to provide the
> > 
> > char global[10];
> > 
> > declaration.  And then we still need to fix some sanity checking in the
> > frontend.
> 
> Thanks for the patch.  I'll need something like it in order to write some jump
> threading tests for missing MEM_REF cases.
> 
> It would be nice if -fdump-tree-*-gimple would match what -fgimple expects, at
> the least with regards to this _Literal business.

Yeah, I have posted a patch but that has some testsuite fallout (meh).

> BTW, the __MEM_REF output from the dumps does not work in -fgimple either. 
> More errors.

Can you share an example?

Thanks,
Richard.

[Bug other/102605] address instruction from -fdump-tree-*-gimple doesn't work with -fgimple

[aldyh at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605

--- Comment #5 from Aldy Hernandez <aldyh at redhat dot com> ---
> > BTW, the __MEM_REF output from the dumps does not work in -fgimple either.
> > More errors.
>
> Can you share an example?

This is from gcc.c-torture/execute/961125-1.c compiled with -fgimple:

char * begfield (int tab, char * ptr, char * lim, int sword, int schar);

int __GIMPLE (ssa)
main ()
{
  char * lim;
  char * s;
  char * _1;

  __BB(2):
  _1 = begfield (58, ":ab", &__MEM <char[4]> ((void *)":ab" + _Literal
(void *) 3), 1, 1);
  if (_1 != &__MEM <char[4]> ((void *)":ab" + _Literal (void *) 2))
    goto __BB3;
  else
    goto __BB4;

  __BB(3):
  abort ();

  __BB(4):
  exit (0);

}

$ ./cc1 x.c -quiet -fgimple
x.c: In function ‘main’:
x.c:11:55: error: invalid type of ‘__MEM’ operand
   11 |   _1 = begfield (58, ":ab", &__MEM <char[4]> ((void *)":ab" +
_Literal (void *) 3), 1, 1);
      |                                                       ^
x.c:11:60: error: expected ‘)’ before ‘+’ token
   11 |   _1 = begfield (58, ":ab", &__MEM <char[4]> ((void *)":ab" +
_Literal (void *) 3), 1, 1);
      |                                                            ^~
      |                                                            )
x.c:12:13: error: expected expression before ‘&’ token
   12 |   if (_1 != &__MEM <char[4]> ((void *)":ab" + _Literal (void *) 2))
      |             ^
x.c: At top level:
x.c:12:67: error: expected identifier or ‘(’ before ‘)’ token
   12 |   if (_1 != &__MEM <char[4]> ((void *)":ab" + _Literal (void *) 2))
      |                                                                   ^
x.c:14:3: error: expected identifier or ‘(’ before ‘else’
   14 |   else
      |   ^~~~
x.c:17:8: error: expected declaration specifiers or ‘...’ before
numeric constant
   17 |   __BB(3):
      |        ^
x.c:20:8: error: expected declaration specifiers or ‘...’ before
numeric constant
   20 |   __BB(4):
      |        ^
x.c:23:1: error: expected identifier or ‘(’ before ‘}’ token
   23 | }
      | ^

Thanks for improving all this.

[Bug other/102605] address instruction from -fdump-tree-*-gimple doesn't work with -fgimple

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 6 Oct 2021, aldyh at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605
> 
> --- Comment #5 from Aldy Hernandez <aldyh at redhat dot com> ---
> > > BTW, the __MEM_REF output from the dumps does not work in -fgimple either.
> > > More errors.
> >
> > Can you share an example?
> 
> This is from gcc.c-torture/execute/961125-1.c compiled with -fgimple:
> 
> char * begfield (int tab, char * ptr, char * lim, int sword, int schar);
> 
> int __GIMPLE (ssa)
> main ()
> {
>   char * lim;
>   char * s;
>   char * _1;
> 
>   __BB(2):
>   _1 = begfield (58, ":ab", &__MEM <char[4]> ((void *)":ab" + _Literal
> (void *) 3), 1, 1);

OK, here we're eliding the & before the ":ab" in duming, so it should
read

  _1 = begfield (58, ":ab", &__MEM <char[4]> ((void *)&":ab" + _Literal 
(void *) 3), 1, 1);

>   if (_1 != &__MEM <char[4]> ((void *)":ab" + _Literal (void *) 2))
>     goto __BB3;

Likewise here, and the patch I'm testing should fix the missing _Literal:

  if (_1 != _Literal (char *) &__MEM <char[4]> ((void *)&":ab" + _Literal 
(void *) 2))

then there needs to be an adjustment to the C frontend to allow
MEM_REFs as lvalue:

diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index f9eb0e5176f..efe70511b91 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -4969,6 +4969,8 @@ lvalue_p (const_tree ref)
       return true;

     case INDIRECT_REF:
+    case MEM_REF:
+    case TARGET_MEM_REF:
     case ARRAY_REF:
     case VAR_DECL:
     case PARM_DECL:

Then the code is accepted.

Btw, please report cases where -gimple doesn't produce valid GIMPLE FE
inputs (OK, there are known cases with mangled symbol names when
passes create temporaries whose name includes a '.' for example...)

[Bug other/102605] address instruction from -fdump-tree-*-gimple doesn't work with -fgimple

[aldyh at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605

--- Comment #7 from Aldy Hernandez <aldyh at redhat dot com> ---
On Wed, Oct 6, 2021 at 10:14 AM rguenther at suse dot de
<gcc-bugzilla@gcc.gnu.org> wrote:

> Btw, please report cases where -gimple doesn't produce valid GIMPLE FE
> inputs (OK, there are known cases with mangled symbol names when
> passes create temporaries whose name includes a '.' for example...)

Thanks, will do.

[Bug other/102605] address instruction from -fdump-tree-*-gimple doesn't work with -fgimple

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:90c3a62272313bb08cd5d9a948ff2d71af73b294

commit r12-4208-g90c3a62272313bb08cd5d9a948ff2d71af73b294
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Oct 5 14:49:42 2021 +0200

    More consistently dump GIMPLE FE consumable stmts

    The following makes more stmts consumable with the GIMPLE FE
    when dumping with -gimple.  In particular addresses in GIMPLE
    operand position require wrapping with _Literal.

    The TDF_ flag space is now exhausted and I've removed overlaps
    and re-ordered things as to how it is supposed to work and
    made it uint32_t and prepared the operator overloads for an
    easy migration to uint64_t once required.

    2021-10-05  Richard Biener  <rguenther@suse.de>

            PR c/102605
            * dumpfile.h (TDF_GIMPLE_VAL): New.
            (dump_flag): Re-order and adjust TDF_* flags.  Make
            the enum uint32_t.  Use std::underlying_type in the
            operator overloads.
            (optgroup_flag): Likewise for the operator overloads.
            * tree-pretty-print.c (dump_generic_node): Wrap ADDR_EXPR
            in _Literal if TDF_GIMPLE_VAL.
            * gimple-pretty-print.c (dump_gimple_assign): Add
            TDF_GIMPLE_VAL to flags when dumping operands where only
            is_gimple_val are allowed.
            (dump_gimple_cond): Likewise.

[Bug other/102605] address instruction from -fdump-tree-*-gimple doesn't work with -fgimple

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
All reported issues should have been fixed.  Please open a new bug if you find
additional things.