> Am 10.08.2026 um 17:39 schrieb Andrea Pinski <[email protected]>:
>
> On Mon, Aug 10, 2026 at 1:58 AM Richard Biener
> <[email protected]> wrote:
>>
>>> On Sun, Aug 9, 2026 at 12:20 AM Andrea Pinski
>>> <[email protected]> wrote:
>>>
>>> While fixing PR 126729 and PR 126570, I found it was hard
>>> to figure out if REF_REVERSE_STORAGE_ORDER was set on a MEM_REF.
>>> Even for the gimple fe was able to set it.
>>> This adds support to the gimple fe and also outputs
>>> REF_REVERSE_STORAGE_ORDER for MEM_REF in gimple mode.
>>>
>>> Bootstrapped and tested on x84_64-linux-gnu.
>>>
>>> gcc/c/ChangeLog:
>>>
>>> * gimple-parser.cc (c_parser_gimple_postfix_expression):
>>> Allow for an optional `, 1/0` in front of the cb pair
>>> for MEM_REF.
>>>
>>> gcc/ChangeLog:
>>>
>>> * tree-pretty-print.cc (dump_mem_ref): Dump REF_REVERSE_STORAGE_ORDER
>>> if it was set.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * gcc.dg/gimplefe-59.c: New test.
>>>
>>> Signed-off-by: Andrea Pinski <[email protected]>
>>> ---
>>> gcc/c/gimple-parser.cc | 34 ++++++++++++++++++++++++++++--
>>> gcc/testsuite/gcc.dg/gimplefe-59.c | 16 ++++++++++++++
>>> gcc/tree-pretty-print.cc | 6 ++++++
>>> 3 files changed, 54 insertions(+), 2 deletions(-)
>>> create mode 100644 gcc/testsuite/gcc.dg/gimplefe-59.c
>>>
>>> diff --git a/gcc/c/gimple-parser.cc b/gcc/c/gimple-parser.cc
>>> index 0fcb9ead83d..59cb29f420c 100644
>>> --- a/gcc/c/gimple-parser.cc
>>> +++ b/gcc/c/gimple-parser.cc
>>> @@ -1530,6 +1530,7 @@ c_parser_gimple_postfix_expression (gimple_parser
>>> &parser)
>>> /* __MEM '<' type-name [ ',' number ] '>'
>>> '(' [ '(' type-name ')' ] unary-expression
>>> [ '+' number ]
>>> + [ ',' number ]
>>
>> But this breaks existing IL, no? Also, why a number ... and why in
>> the deref part?
>
> No it does not break existing IL because the next part contains a `:`
> in its argument so it is easy to check.
> The reason for the number is it is easier to parse than anything else
But a -GIMPLE dump should be as easy to parse than a regular one (did you
adjust dumping)? I don’t like a 0/1 here.
>
>> I'd have expected this to be part of the <type-name ...> part,
>> alongside the alignment
>> specification?
>
> Alignment is part of the type while reverse is part of the mem_ref.
> I know it is a bit odd but that is the current situation we are in.
Note that we do not have to match 1:1, but I see your point.
>
>>
>>> [ ',' number ':' number ] ')' */
>>> location_t loc = c_parser_peek_token (parser)->location;
>>> c_parser_consume_token (parser);
>>> @@ -1542,6 +1543,8 @@ c_parser_gimple_postfix_expression (gimple_parser
>>> &parser)
>>> index2.value = NULL_TREE;
>>> unsigned short clique = 0;
>>> unsigned short base = 0;
>>> + bool reverse_order = false;
>>> + struct c_expr ro;
>>> if (c_parser_require (parser, CPP_OPEN_PAREN, "expected
>>> %<(%>"))
>>> {
>>> tree alias_type = NULL_TREE;
>>> @@ -1626,10 +1629,29 @@ c_parser_gimple_postfix_expression (gimple_parser
>>> &parser)
>>> if (c_parser_next_token_is (parser, CPP_COMMA))
>>> {
>>> struct c_expr cl, ba;
>>> + bool has_clb = true;
>>> c_parser_consume_token (parser);
>>> cl = c_parser_gimple_postfix_expression (parser);
>>> - if (c_parser_require (parser,
>>> - CPP_COLON, "expected %<:%>"))
>>> + if (!c_parser_next_token_is (parser, CPP_COLON))
>>> + {
>>> + ro = cl;
>>> + unsigned HOST_WIDE_INT tmp = 0;
>>> + if (!tree_fits_uhwi_p (ro.value)
>>> + || (tmp = tree_to_uhwi (ro.value)) > 1)
>>> + error_at (ro.get_start (),
>>> + "invalid reverse order value");
>>> + reverse_order = tmp;
>>> + has_clb = false;
>>> + if (c_parser_next_token_is (parser, CPP_COMMA))
>>> + {
>>> + c_parser_consume_token (parser);
>>> + cl = c_parser_gimple_postfix_expression
>>> (parser);
>>> + has_clb = true;
>>> + }
>>> + }
>>> + if (has_clb
>>> + && c_parser_require (parser,
>>> + CPP_COLON, "expected %<:%>"))
>>> {
>>> ba = c_parser_gimple_postfix_expression (parser);
>>> if (!tree_fits_uhwi_p (cl.value)
>>> @@ -1665,6 +1687,14 @@ c_parser_gimple_postfix_expression (gimple_parser
>>> &parser)
>>> MR_DEPENDENCE_CLIQUE (expr.value) = clique;
>>> MR_DEPENDENCE_BASE (expr.value) = base;
>>> }
>>> + if (reverse_order)
>>> + {
>>> + if (TREE_CODE (expr.value) == MEM_REF)
>>> + REF_REVERSE_STORAGE_ORDER (expr.value) = reverse_order;
>>> + else
>>> + error_at (ro.get_start (),
>>> + "target mem ref cannot have reverse order");
>>> + }
>>> break;
>>> }
>>> else if (strcmp (IDENTIFIER_POINTER (id), "__VIEW_CONVERT") == 0)
>>> diff --git a/gcc/testsuite/gcc.dg/gimplefe-59.c
>>> b/gcc/testsuite/gcc.dg/gimplefe-59.c
>>> new file mode 100644
>>> index 00000000000..296c088a2a0
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.dg/gimplefe-59.c
>>> @@ -0,0 +1,16 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-fgimple" } */
>>> +
>>> +/* test REF_REVERSE_STORAGE_ORDER parsing of gimple fe. */
>>> +
>>> +int __GIMPLE (ssa,guessed_local(1073741824))
>>> +f2 (void * a, bool b, bool bb)
>>> +{
>>> + int _1;
>>> +
>>> + __BB(2,guessed_local(1073741824)):
>>> + _1 = __MEM <int> (a_5(D), 1);
>>> + return _1;
>>> +
>>> +}
>>> +
>>> diff --git a/gcc/tree-pretty-print.cc b/gcc/tree-pretty-print.cc
>>> index bd60e5c15c1..316945c00ed 100644
>>> --- a/gcc/tree-pretty-print.cc
>>> +++ b/gcc/tree-pretty-print.cc
>>> @@ -2075,6 +2075,12 @@ dump_mem_ref (pretty_printer *pp, tree node, int
>>> spc, dump_flags_t flags)
>>> spc, flags | TDF_SLIM, false);
>>> }
>>> }
>>> + if (TREE_CODE (node) == MEM_REF
>>> + && REF_REVERSE_STORAGE_ORDER (node))
>>> + {
>>> + pp_string (pp, ", ");
>>> + pp_decimal_int (pp, REF_REVERSE_STORAGE_ORDER (node));
>>> + }
>>> if (MR_DEPENDENCE_CLIQUE (node) != 0)
>>> {
>>> pp_string (pp, ", ");
>>> --
>>> 2.43.0
>>>
