[Bug debug/103047] New: Inconsist arguments ordering for inlined subroutine

[Bug debug/103047] New: Inconsist arguments ordering for inlined subroutine

[liyd2021 at gmail dot com]

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

            Bug ID: 103047
           Summary: Inconsist arguments ordering for inlined subroutine
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: liyd2021 at gmail dot com
  Target Milestone: ---

Affected versions: gcc 11.2.0 with gdb (Ubuntu 20.04.2)

The `foo` function is inlined in O1 optimization, and gcc generates inconsist 
arguments ordering between `DW_TAG_inlined_subroutine` and `DW_TAG_subprogram`
in debug information.
This bug can also be reproduced in gcc 7, 8, 9.

(terminal) $ cat a.c && gcc -g -O1 a.c
int foo(int a0, double a1)
{
  return a0 != 0 || a1 != 1.0;
}

int v0 = 0;
double v1 = 1.0;

int main()
{
  return foo(v0, v1);
}
--------------------
(terminal) $ cat run.gdb
ptype foo
b foo
r
ptype foo
--------------------
(terminal) $ gdb -x run.gdb a.out
type = int (int, double)
Breakpoint 1 at 0x401169: foo. (2 locations)

Breakpoint 1, foo (a1=1, a0=0) at a.c:3
3         return a0 != 0 || a1 != 1.0;
type = int (double, int) <-- inconsist with previous print

[Bug debug/103047] Inconsistent arguments ordering for inlined subroutine

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-01-26
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
      Known to fail|                            |13.2.1
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed, still happens.  But maybe this is a also gdb issue as we have for
the similar case

static inline int foo (int a, int b)
{
  volatile int x = a + b;
  return x;
}

int main()
{
  int c = 1;
  int d = 2;
  int res = foo (c, d);
  return res;
}


 <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
    <2e>   DW_AT_external    : 1
    <2e>   DW_AT_name        : (indirect string, offset: 0x6f): main
...
 <2><79>: Abbrev Number: 5 (DW_TAG_inlined_subroutine)
    <7a>   DW_AT_abstract_origin: <0xca>
    <7e>   DW_AT_entry_pc    : 0
    <86>   DW_AT_GNU_entry_view: 4
    <87>   DW_AT_low_pc      : 0
    <8f>   DW_AT_high_pc     : 0xc
    <97>   DW_AT_call_file   : 1
    <98>   DW_AT_call_line   : 11
    <99>   DW_AT_call_column : 13
 <3><9a>: Abbrev Number: 6 (DW_TAG_formal_parameter)
    <9b>   DW_AT_abstract_origin: <0xe1>
    <9f>   DW_AT_location    : 0x27 (location list)
    <a3>   DW_AT_GNU_locviews: 0x25
 <3><a7>: Abbrev Number: 6 (DW_TAG_formal_parameter)
    <a8>   DW_AT_abstract_origin: <0xd7>
    <ac>   DW_AT_location    : 0x4d (location list)
    <b0>   DW_AT_GNU_locviews: 0x4b
...
 <1><ca>: Abbrev Number: 10 (DW_TAG_subprogram)
    <cb>   DW_AT_name        : foo
    <cf>   DW_AT_decl_file   : 1
    <d0>   DW_AT_decl_line   : 1
    <d1>   DW_AT_decl_column : 19
    <d2>   DW_AT_prototyped  : 1
    <d2>   DW_AT_type        : <0xbe>
    <d6>   DW_AT_inline      : 3        (declared as inline and inlined)
 <2><d7>: Abbrev Number: 11 (DW_TAG_formal_parameter)
    <d8>   DW_AT_name        : a
    <da>   DW_AT_decl_file   : 1
    <db>   DW_AT_decl_line   : 1
    <dc>   DW_AT_decl_column : 28
    <dd>   DW_AT_type        : <0xbe>
 <2><e1>: Abbrev Number: 11 (DW_TAG_formal_parameter)
    <e2>   DW_AT_name        : b
    <e4>   DW_AT_decl_file   : 1
    <e5>   DW_AT_decl_line   : 1
    <e6>   DW_AT_decl_column : 35
    <e7>   DW_AT_type        : <0xbe>

so it could look at the actual function for determining the order.

The order of the formal parameters are reversed because the fake
scope BLOCK the inliner adds has those as variables in that reverse order.
We output them via decls_for_scope.

static gimple *
setup_one_parameter (copy_body_data *id, tree p, tree value, tree fn,
                     basic_block bb, tree *vars)
{ 
...
  /* Declare this new variable.  */
  DECL_CHAIN (var) = *vars;
  *vars = var;


I have a patch.

[Bug debug/103047] Inconsistent arguments ordering for inlined subroutine

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from GCC 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:b702dc980215074a06535e3aa52a766bef38af4c

commit r14-8486-gb702dc980215074a06535e3aa52a766bef38af4c
Author: Richard Biener <rguenther@suse.de>
Date:   Fri Jan 26 15:11:47 2024 +0100

    debug/103047 - argument order of inlined functions

    The inliner puts variables for parameters of the inlined functions
    in the inline scope in reverse order.  The following reverses them
    again so that we get consistent ordering between the
    DW_TAG_subprogram DW_TAG_formal_parameter and the
    DW_TAG_inlined_subroutine DW_TAG_formal_parameter set.

    I failed to create a testcase with regexps since the inline
    instances have just abstract origins and so I can't match them up.

            PR debug/103047
            * tree-inline.cc (initialize_inlined_parameters): Reverse
            the decl chain of inlined parameters.

[Bug debug/103047] Inconsistent arguments ordering for inlined subroutine

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |14.0
   Target Milestone|---                         |14.0
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed for GCC 14.