public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/111716] New: call site parameter not matching with formal parameter
@ 2023-10-06 16:26 king.chung at manchester dot ac.uk
  2023-10-06 16:34 ` [Bug debug/111716] " pinskia at gcc dot gnu.org
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: king.chung at manchester dot ac.uk @ 2023-10-06 16:26 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 111716
           Summary: call site parameter not matching with formal parameter
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: king.chung at manchester dot ac.uk
  Target Milestone: ---

Created attachment 56070
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56070&action=edit
The C source code to produce the error

The call site information in the caller does not match the parameter of the
callee.

Caller call site DWARF:
 <2><ff3>: Abbrev Number: 17 (DW_TAG_call_site)
    <ff4>   DW_AT_call_return_pc: 0x10a10
    <ffc>   DW_AT_call_tail_call: 1
    <ffc>   DW_AT_call_origin : <0xa73>
 <3><1000>: Abbrev Number: 1 (DW_TAG_call_site_parameter)
    <1001>   DW_AT_location    : 1 byte block: 5a       (DW_OP_reg10 (a0))
    <1003>   DW_AT_call_value  : 3 byte block: a3 1 5a  (DW_OP_entry_value:
(DW_OP_reg10 (a0)))
 <3><1007>: Abbrev Number: 1 (DW_TAG_call_site_parameter)
    <1008>   DW_AT_location    : 1 byte block: 5b       (DW_OP_reg11 (a1))
    <100a>   DW_AT_call_value  : 6 byte block: a3 1 5a 23 80 20        
(DW_OP_entry_value: (DW_OP_reg10 (a0)); DW_OP_plus_uconst: 4096)
 <3><1011>: Abbrev Number: 1 (DW_TAG_call_site_parameter)
    <1012>   DW_AT_location    : 1 byte block: 5d       (DW_OP_reg13 (a3))
    <1014>   DW_AT_call_value  : 7 byte block: a3 1 5a 23 88 a0 2      
(DW_OP_entry_value: (DW_OP_reg10 (a0)); DW_OP_plus_uconst: 36872)
 <3><101c>: Abbrev Number: 1 (DW_TAG_call_site_parameter)
    <101d>   DW_AT_location    : 1 byte block: 5e       (DW_OP_reg14 (a4))
    <101f>   DW_AT_call_value  : 7 byte block: a3 1 5a 23 88 a2 2      
(DW_OP_entry_value: (DW_OP_reg10 (a0)); DW_OP_plus_uconst: 37128)
 <3><1027>: Abbrev Number: 0
 <2><1028>: Abbrev Number: 0

Callee parameter:
 <1><a73>: Abbrev Number: 30 (DW_TAG_subprogram)
    <a74>   DW_AT_external    : 1
    <a74>   DW_AT_name        : bfs
    <a78>   DW_AT_decl_file   : 6
    <a79>   DW_AT_decl_line   : 53
    <a7a>   DW_AT_decl_column : 6
    <a7b>   DW_AT_prototyped  : 1
    <a7b>   DW_AT_declaration : 1
    <a7b>   DW_AT_sibling     : <0xa99>
 <2><a7f>: Abbrev Number: 3 (DW_TAG_formal_parameter)
    <a80>   DW_AT_type        : <0xa99>
 <2><a84>: Abbrev Number: 3 (DW_TAG_formal_parameter)
    <a85>   DW_AT_type        : <0xa9e>
 <2><a89>: Abbrev Number: 3 (DW_TAG_formal_parameter)
    <a8a>   DW_AT_type        : <0x88e>
 <2><a8e>: Abbrev Number: 3 (DW_TAG_formal_parameter)
    <a8f>   DW_AT_type        : <0xaa3>
 <2><a93>: Abbrev Number: 3 (DW_TAG_formal_parameter)
    <a94>   DW_AT_type        : <0xaa8>
 <2><a98>: Abbrev Number: 0

This is using the same binary as Bug111680.

I used the following command to compile the code
`riscv64-unknown-linux-gnu-gcc -static -O3 -Wall -Wno-unused-label
-march=rv64imafd -g -fno-reorder-blocks -o bfs bfs.c local_support.c support.c
harness.c`

I also find that the type of the parameter is not propagated correctly. For
example, an array type is propagated as a pointer type. Should I open another
bug report for this?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug debug/111716] call site parameter not matching with formal parameter
  2023-10-06 16:26 [Bug debug/111716] New: call site parameter not matching with formal parameter king.chung at manchester dot ac.uk
@ 2023-10-06 16:34 ` pinskia at gcc dot gnu.org
  2023-10-06 16:50 ` pinskia at gcc dot gnu.org
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-06 16:34 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to King Lok Chung from comment #0) 
> I also find that the type of the parameter is not propagated correctly. For
> example, an array type is propagated as a pointer type. Should I open
> another bug report for this?

array types decay to pointers for parameters ...

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug debug/111716] call site parameter not matching with formal parameter
  2023-10-06 16:26 [Bug debug/111716] New: call site parameter not matching with formal parameter king.chung at manchester dot ac.uk
  2023-10-06 16:34 ` [Bug debug/111716] " pinskia at gcc dot gnu.org
@ 2023-10-06 16:50 ` pinskia at gcc dot gnu.org
  2023-10-06 16:52 ` king.chung at manchester dot ac.uk
  2023-10-06 16:53 ` pinskia at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-06 16:50 UTC (permalink / raw)
  To: gcc-bugs

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|riscv64-linux-gnu           |riscv64-linux-gnu
                   |                            |x86_64-linux-gnu
                   |                            |aarch64-linux-gnu

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So it looks like the first argument is passed through with no change and that
is not recorded ...

It happens on x86_64, aarch64 too.

The testcase I was using was the preprocessed source from bug 111680 and add to
the following to the end:
```
void run_benchmark( void *vargs ) {
  struct bench_args_t *args = (struct bench_args_t *)vargs;
  bfs(args->nodes, args->edges, args->starting_node, args->level,
args->level_counts);
}
```

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug debug/111716] call site parameter not matching with formal parameter
  2023-10-06 16:26 [Bug debug/111716] New: call site parameter not matching with formal parameter king.chung at manchester dot ac.uk
  2023-10-06 16:34 ` [Bug debug/111716] " pinskia at gcc dot gnu.org
  2023-10-06 16:50 ` pinskia at gcc dot gnu.org
@ 2023-10-06 16:52 ` king.chung at manchester dot ac.uk
  2023-10-06 16:53 ` pinskia at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: king.chung at manchester dot ac.uk @ 2023-10-06 16:52 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from King Lok Chung <king.chung at manchester dot ac.uk> ---
(In reply to Andrew Pinski from comment #1)
> (In reply to King Lok Chung from comment #0) 
> > I also find that the type of the parameter is not propagated correctly. For
> > example, an array type is propagated as a pointer type. Should I open
> > another bug report for this?
> 
> array types decay to pointers for parameters ...

I know they are the same most of the time; however, knowing the variable is an
array will be more beneficial than just knowing it as a standard pointer, as an
array implies the data will be within a bounded area, while a pointer type will
not be able to make such an implication.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug debug/111716] call site parameter not matching with formal parameter
  2023-10-06 16:26 [Bug debug/111716] New: call site parameter not matching with formal parameter king.chung at manchester dot ac.uk
                   ` (2 preceding siblings ...)
  2023-10-06 16:52 ` king.chung at manchester dot ac.uk
@ 2023-10-06 16:53 ` pinskia at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-06 16:53 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Short testcase:
```
struct f
{
        int a[10];
        int b[10];
        int c;
        int d[10];
        int e[10];
};

void g(int a[10], int b[10], int e, int i[10], int j[10]);

void h(void *a1)
{
        struct f *a = (struct f*)a1;
        g(a->a, a->b, a->c, a->d, a->e);
}
```

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-10-06 16:53 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-06 16:26 [Bug debug/111716] New: call site parameter not matching with formal parameter king.chung at manchester dot ac.uk
2023-10-06 16:34 ` [Bug debug/111716] " pinskia at gcc dot gnu.org
2023-10-06 16:50 ` pinskia at gcc dot gnu.org
2023-10-06 16:52 ` king.chung at manchester dot ac.uk
2023-10-06 16:53 ` pinskia at gcc dot gnu.org

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).