[llvm-bugs] [Bug 51813] New: GDB. test gdb.base/infcall-nested-structs-c++.exp failing after 6f7f5b54c

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=51813

            Bug ID: 51813
           Summary: GDB. test gdb.base/infcall-nested-structs-c++.exp
                    failing after 6f7f5b54c
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: douglas_yung at playstation.sony.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Internally we run the GDB test suite, and one test
gdb.base/infcall-nested-structs-c++.exp started to fail after commit
6f7f5b54c81be59ec7876649d1f9aa6b104658ec.

I have reduced the test to the following source which should reproduce the
failure.

/* complex.c */
typedef float _Complex tfc;

struct struct_01_01 { struct { } es1; struct { struct { tfc a; } s1; } s2; };

struct struct_01_01 ref_val_struct_01_01 = { {}, { { 'a' } } };

int __attribute__((noinline))
cmp_struct_01_01 (struct struct_01_01 a, struct struct_01_01 b){
  return a.s2.s1.a == b.s2.s1.a;
}

extern int __attribute__((noinline)) check_arg_struct_01_01 (struct
struct_01_01 arg) {
  return cmp_struct_01_01 (arg, ref_val_struct_01_01);
}

struct struct_01_01 __attribute__((noinline))
rtn_str_struct_01_01 (void) {
  return (ref_val_struct_01_01);
}

int volatile v = 1;

void __attribute__((noinline))
breakpt (void)
{  v++; }

int main () {
  int res;

  res = check_arg_struct_01_01 (ref_val_struct_01_01);
  breakpt ();
  return res; /* Break here */
}
/* End complex.c */

Compile the file with "clang++ complex.c -x c++ -O2 -g -o test.out". Then start
up GDB to debug the resulting executable. Within GDB, set a breakpoint on the
line with the comment "Break here" (line 32 in my copy), and run the debugger.
When the debugger stops at line 32, run the command "p/d check_arg_struct_01_01
(ref_val_struct_01_01)". The result of that should be 1, but after upstream
commit 6f7f5b54c81be59ec7876649d1f9aa6b104658ec it is now 0.

Sample good debug session:
dyung at aldebaran:~/sandbox/gdb$ gdb good.out
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
...
Reading symbols from good.out...
(gdb) b 32
Breakpoint 1 at 0x4011ad: file complex.c, line 32.
(gdb) r
Starting program: /home/dyung/sandbox/gdb/good.out 

Breakpoint 1, main () at complex.c:32
32        return res; /* Break here */
(gdb) p/d check_arg_struct_01_01 (ref_val_struct_01_01)
$1 = 1


Sample bad debug session:
dyung at aldebaran:~/sandbox/gdb$ gdb bad.out
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
...
Reading symbols from bad.out...
(gdb) b 32
Breakpoint 1 at 0x40121c: file complex.c, line 32.
(gdb) r
Starting program: /home/dyung/sandbox/gdb/bad.out 

Breakpoint 1, main () at complex.c:32
32        return res; /* Break here */
(gdb) p/d check_arg_struct_01_01 (ref_val_struct_01_01)
$1 = 0


In my sample gdb output, good.out was built using a compiler built from
b978df4af4c8a668550fa035b70795312bf41f44, while bad.out was built using a
compiler built from 6f7f5b54c81be59ec7876649d1f9aa6b104658ec.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210909/7acd88b0/attachment-0001.html>