[Bug tdep/31278] New: GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[Bug tdep/31278] New: GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[thiago.bauermann at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31278

            Bug ID: 31278
           Summary: GDB on arm-linux-gnueabihf fails
                    gdb.reverse/func-map-to-same-line.exp
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: tdep
          Assignee: unassigned at sourceware dot org
          Reporter: thiago.bauermann at linaro dot org
  Target Milestone: ---

Created attachment 15319
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15319&action=edit
Testsuite log from today's trunk with the testcase failing.

gdb.reverse/func-map-to-same-line.exp was introduced recently.
It fails on arm-linux-gnueabihf with:

Running
/home/thiago.bauermann/src/binutils-gdb-wt/gdb/testsuite/gdb.reverse/func-map-to-same-line.exp
...
FAIL: gdb.reverse/func-map-to-same-line.exp: column_info_flag=column-info:
step-test: reverse-step into func2
FAIL: gdb.reverse/func-map-to-same-line.exp: column_info_flag=column-info:
step-test: reverse-step into func1
FAIL: gdb.reverse/func-map-to-same-line.exp: column_info_flag=no-column-info:
step-test: reverse-step into func2
FAIL: gdb.reverse/func-map-to-same-line.exp: column_info_flag=no-column-info:
step-test: reverse-step into func1

Attaching the gdb.log file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31278] GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31278

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vries at gcc dot gnu.org

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Reproduces for me on pinebook (using gcc 10.2.1), with
--target_board=unix/-mthumb, not with --target_board=unix/-marm.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31278] GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[thiago.bauermann at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31278

--- Comment #2 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
(In reply to Tom de Vries from comment #1)
> Reproduces for me on pinebook (using gcc 10.2.1), with
> --target_board=unix/-mthumb, not with --target_board=unix/-marm.

Thanks for checking! I have the same results, actually.

I hadn't realised this earlier, but I don't specify an explicit option, the
system compiler is generating Thumb:

$ readelf -a
testsuite/outputs/gdb.reverse/func-map-to-same-line/func-map-to-same-line |
grep -e func1 -e func2
    83: 000004d9    14 FUNC    GLOBAL DEFAULT   13 func1
    97: 000004e7    14 FUNC    GLOBAL DEFAULT   13 func2

This is on Ubuntu 22.04.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31278] GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31278

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Thiago Jung Bauermann from comment #2)
> (In reply to Tom de Vries from comment #1)
> > Reproduces for me on pinebook (using gcc 10.2.1), with
> > --target_board=unix/-mthumb, not with --target_board=unix/-marm.
> 
> Thanks for checking! I have the same results, actually.
> 
> I hadn't realised this earlier, but I don't specify an explicit option, the
> system compiler is generating Thumb:
> 

Yep, same on my system.  After analyzing a few failures:
- PR31087 "[gdb/tdep, arm] FAIL: gdb.base/func-ptrs.exp: continue to decr"
- PR31089 "[gdb/tdep, arm] FAIL: gdb.base/longjmp-until-in-main.exp: until
$line,
  in main"
I came to the realization that the thumb bit in function address thingy is
pretty poorly supported by gdb, so I decided to start running with unix/-marm
by default to filter those out.

> $ readelf -a
> testsuite/outputs/gdb.reverse/func-map-to-same-line/func-map-to-same-line |
> grep -e func1 -e func2
>     83: 000004d9    14 FUNC    GLOBAL DEFAULT   13 func1
>     97: 000004e7    14 FUNC    GLOBAL DEFAULT   13 func2
> 
> This is on Ubuntu 22.04.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31278] GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31278

Luis Machado <luis.machado at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luis.machado at arm dot com

--- Comment #4 from Luis Machado <luis.machado at arm dot com> ---
Yes, the thumb situation in 32-bit Arm is a bit delicate. Various things have
not been well thought out with this metadata in mind. For instance, probes
don't carry any thumb information, stripped binaries sometimes lack the
information.

Is the specific problem with this testcase that the line table PC processing is
getting confused with the LSB bit set? Or is it not stepping backwards
correctly because of thumbness?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31278] GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31278

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
I compared with -marm and x86_64, and in both cases we have:
...
$ gdb -q -batch outputs/gdb.reverse/func-map-to-same-line/func-map-to-same-line
-ex start -ex record -ex "break 36" -ex continue -ex "set debug infrun 1" -ex
"reverse-step" 2>&1 | grep process_event_stop_test
  [infrun] process_event_stop_test: stepped into subroutine
  [infrun] process_event_stop_test: stepped into subroutine
  [infrun] process_event_stop_test: stepped into subroutine
  [infrun] process_event_stop_test: stepped into subroutine
...
but with -mthumb:
...
  [infrun] process_event_stop_test: stepped into subroutine
  [infrun] process_event_stop_test: updated step range, start = 0xaaaaa4f2, end
= 0xaaaaa4fc, may_range_step = 1
  [infrun] process_event_stop_test: keep going
  [infrun] process_event_stop_test: reverse stepping, left a recursive call,
don't update step info so we remember we left a frame
  [infrun] process_event_stop_test: updated step range, start = 0xaaaaa4f2, end
= 0xaaaaa4fc, may_range_step = 1
  [infrun] process_event_stop_test: keep going
  [infrun] process_event_stop_test: reverse stepping, left a recursive call,
don't update step info so we remember we left a frame
  [infrun] process_event_stop_test: updated step range, start = 0xaaaaa4f2, end
= 0xaaaaa4fc, may_range_step = 1
  [infrun] process_event_stop_test: keep going
  [infrun] process_event_stop_test: reverse stepping, left a recursive call,
don't update step info so we remember we left a frame
  [infrun] process_event_stop_test: updated step range, start = 0xaaaaa4ee, end
= 0xaaaaa4f2, may_range_step = 1
  [infrun] process_event_stop_test: keep going
  [infrun] process_event_stop_test: stepped to a different line
...

So, the deviation starts when the second call to process_event_stop_test
doesn't detect "stepped into subroutine".

The condition looks like this:
...
  if ((get_stack_frame_id (frame)
       != ecs->event_thread->control.step_stack_frame_id)
      && get_frame_type (frame) != SIGTRAMP_FRAME
      && ((frame_unwind_caller_id (get_current_frame ())
           == ecs->event_thread->control.step_stack_frame_id)
          && ((ecs->event_thread->control.step_stack_frame_id
               != outer_frame_id)
              || (ecs->event_thread->control.step_start_function
                  != find_pc_function (ecs->event_thread->stop_pc ())))))
    {
...
and it fails because these two are not equal:
...
(gdb) p /x frame_unwind_caller_id (get_current_frame ())
$1 = {stack_addr = 0x12, code_addr = 0xaaaaa4fc, special_addr = 0x0,
stack_status = 0x1, code_addr_p = 0x1, 
  special_addr_p = 0x0, user_created_p = 0x0, artificial_depth = 0x0}
(gdb) p /x ecs->event_thread->control.step_stack_frame_id          
$2 = {stack_addr = 0xfffef4d8, code_addr = 0xaaaaa4fc, special_addr = 0x0,
stack_status = 0x1, code_addr_p = 0x1, 
  special_addr_p = 0x0, user_created_p = 0x0, artificial_depth = 0x0}
...
Note the difference in stack_addr.

With this demonstrator patch, limiting the comparison to code_addr, the
test-case passes:
...
diff --git a/gdb/infrun.c b/gdb/infrun.c
index 87965fb1274..600dda6b5c5 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -7816,8 +7816,8 @@ process_event_stop_test (struct execution_control_state
*ecs)
   if ((get_stack_frame_id (frame)
        != ecs->event_thread->control.step_stack_frame_id)
       && get_frame_type (frame) != SIGTRAMP_FRAME
-      && ((frame_unwind_caller_id (get_current_frame ())
-          == ecs->event_thread->control.step_stack_frame_id)
+      && ((frame_unwind_caller_id (get_current_frame ()).code_addr
+          == ecs->event_thread->control.step_stack_frame_id.code_addr)
          && ((ecs->event_thread->control.step_stack_frame_id
               != outer_frame_id)
              || (ecs->event_thread->control.step_start_function
...

So I guess the question is why the frame id has that strange stack_addr.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31278] GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31278

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #5)
> So I guess the question is why the frame id has that strange stack_addr.

I added this debug patch:
...
diff --git a/gdb/dwarf2/frame.c b/gdb/dwarf2/frame.c
index fc6704f434e..1f6a0a17305 100644
--- a/gdb/dwarf2/frame.c
+++ b/gdb/dwarf2/frame.c
@@ -980,6 +980,8 @@ dwarf2_frame_cache (frame_info_ptr this_frame, void
**this_cache)

   try
     {
+      frame_debug_printf ("Calculating CFA ... ");
+
       /* Calculate the CFA.  */
       switch (fs.regs.cfa_how)
        {
@@ -1001,6 +1003,9 @@ dwarf2_frame_cache (frame_info_ptr this_frame, void
**this_cache)
        default:
          internal_error (_("Unknown CFA rule."));
        }
+
+      frame_debug_printf (" ... CFA calculated: %llx", (unsigned long
long)cache->cfa);
+       
     }
   catch (const gdb_exception_error &ex)
     {
...

And then using:
...
$ gdb.sh -q -batch \
  outputs/gdb.reverse/func-map-to-same-line/func-map-to-same-line \
  -ex start \
  -ex record \
  -ex "break 36" \
  -ex continue \
  -ex reverse-stepi \
  -ex "set debug frame 1" \
  -ex reverse-stepi
...
I find:
...
    [frame] frame_unwind_register_value: enter
      [frame] frame_unwind_register_value: frame=0, regnum=7(r7)
      [frame] frame_unwind_register_value:   -> address=0xfffef4d8 lazy
    [frame] frame_unwind_register_value: exit
    [frame] dwarf2_frame_cache:  ... CFA calculated: 12
    [frame] frame_unwind_arch: next_frame=1 -> armv7
    [frame] frame_unwind_register_value: enter
      [frame] frame_unwind_register_value: frame=1, regnum=15(pc)
      [frame] frame_unwind_register_value: enter
        [frame] frame_unwind_register_value: frame=1, regnum=14(lr)
        [frame] frame_unwind_register_value:   -> address=0xe lazy
      [frame] frame_unwind_register_value: exit
    [frame] frame_unwind_register_value: exit
...

So r14 is read from address 0xe, which is caused by an incorrect CFA, of 0x12.

The CFA is calculated based on r7, which is read from to 0xfffef4d8, resulting
in '2'.

When stepping through func2, r7 is actually saved at 0xfffef4d4.

In the .s file we have:
...
        nop
        mov     sp, r7
        .cfi_def_cfa_register 13
        @ sp needed
        ldr     r7, [sp], #4
        .cfi_restore 7
        .cfi_def_cfa_offset 0
        bx      lr
        .cfi_endproc
...

I'm not sure why when stopped at the start of ldr we try to read from 7, though
cfa reg 13 also doesn't sound right for a thumb function.  Regardless, we're
reading r7 from the wrong place.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31278] GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31278

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
This is a reasonably minimal version:
...
$ gdb -q -batch -x gdb.in
+file outputs/gdb.reverse/func-map-to-same-line/func-map-to-same-line
+b *func2+8
Breakpoint 1 at 0x4f6: file
/home/rock/gdb/src/gdb/testsuite/gdb.reverse/func-map-to-same-line.c, line 27.
+run

Breakpoint 1, 0xaaaaa4f6 in func2 () at
/home/rock/gdb/src/gdb/testsuite/gdb.reverse/func-map-to-same-line.c:27
27      } /* END FUNC2 */
+record
+target record-full
+print $r13
$1 = (void *) 0xfffef4f4
+stepi
0xaaaaa4fa      27      } /* END FUNC2 */
+print $r13
$2 = (void *) 0xfffef4f8
+reverse-stepi
+stepi 

No more reverse-execution history.
0xaaaaa4f6 in func2 () at
/home/rock/gdb/src/gdb/testsuite/gdb.reverse/func-map-to-same-line.c:27
27      } /* END FUNC2 */
+print $r13
$3 = (void *) 0xfffef4f8
...

The insn is:
...
 4f6:   f85d 7b04       ldr.w   r7, [sp], #4
...
which modifies the sp by 4, but reverse execution fails to detect this and
revert the effect.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31278] [gdb/tdep, thumb2] GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31278

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|GDB on arm-linux-gnueabihf  |[gdb/tdep, thumb2] GDB on
                   |fails                       |arm-linux-gnueabihf fails
                   |gdb.reverse/func-map-to-sam |gdb.reverse/func-map-to-sam
                   |e-line.exp                  |e-line.exp

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31278] [gdb/tdep, thumb2] GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31278

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
Fixed by:
...
diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
index 861d50a6a3b..461efe50554 100644
--- a/gdb/arm-tdep.c
+++ b/gdb/arm-tdep.c
@@ -14182,7 +14182,8 @@ thumb2_record_ld_word (arm_insn_decode_record
*thumb2_ins
n_r)

   record_buf[0] = bits (thumb2_insn_r->arm_insn, 12, 15);
   record_buf[1] = ARM_PS_REGNUM;
-  thumb2_insn_r->reg_rec_count = 2;
+  record_buf[2] = bits (thumb2_insn_r->arm_insn, 16, 19);
+  thumb2_insn_r->reg_rec_count = 3;

   REG_ALLOC (thumb2_insn_r->arm_regs, thumb2_insn_r->reg_rec_count,
            record_buf);
...

I have no idea whether this is (always) complete and correct, I haven't found
the place in the arm manual that describes the encoding.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31278] [gdb/tdep, thumb2] GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31278

--- Comment #9 from Luis Machado <luis.machado at arm dot com> ---
I'm guessing this is probably LDR (immediate) T4 encoding Post Indexed, with a
write-back that is not being accounted for in gdb.

The write-back bit seems to be bit 8. Does it show up as 1 for your case?

It was probably an oversight, as we can that being handled in
thumb_stack_frame_destroyed_p:

  else if (insn == 0xf85d  /* ldr.w <Rt>, [sp], #4 */
           && (insn2 & 0x0fff) == 0x0b04)
    found_stack_adjust = 1;

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31278] [gdb/tdep, thumb2] GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31278

--- Comment #10 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Luis Machado from comment #9)
> I'm guessing this is probably LDR (immediate) T4 encoding Post Indexed, with
> a write-back that is not being accounted for in gdb.
> 

Thanks, it is indeed, this helped me find the encoding documentation.

> The write-back bit seems to be bit 8. Does it show up as 1 for your case?
> 

Yes.

> It was probably an oversight, as we can that being handled in
> thumb_stack_frame_destroyed_p:
> 
>   else if (insn == 0xf85d  /* ldr.w <Rt>, [sp], #4 */
>            && (insn2 & 0x0fff) == 0x0b04)
>     found_stack_adjust = 1;

OK, so how about this:
...
diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
index 861d50a6a3b..081e934cf86 100644
--- a/gdb/arm-tdep.c
+++ b/gdb/arm-tdep.c
@@ -14184,6 +14184,14 @@ thumb2_record_ld_word (arm_insn_decode_record
*thumb2_insn_r)
   record_buf[1] = ARM_PS_REGNUM;
   thumb2_insn_r->reg_rec_count = 2;

+  if ((thumb2_insn_r->arm_insn & 0xfff00900) == 0xf8500900)
+    {
+      /* Detected LDR(immediate), T4, with write-back bit set.  Record Rn
+        update.  */
+      record_buf[2] = bits (thumb2_insn_r->arm_insn, 16, 19);
+      thumb2_insn_r->reg_rec_count++;
+    }
+
   REG_ALLOC (thumb2_insn_r->arm_regs, thumb2_insn_r->reg_rec_count,
            record_buf);
   return ARM_RECORD_SUCCESS;
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31278] [gdb/tdep, thumb2] GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31278

--- Comment #11 from Luis Machado <luis.machado at arm dot com> ---
Looks good to me. Please go ahead and push it. Thanks for spotting this and for
the patch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31278] [gdb/tdep, thumb2] GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31278

--- Comment #12 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Luis Machado from comment #11)
> Looks good to me. Please go ahead and push it. Thanks for spotting this and
> for the patch.

Thanks for the review.

I've written a commit message, and posted at
https://sourceware.org/pipermail/gdb-patches/2024-February/206523.html with
approved-by tag.

I've you've still got comments on the commit message, let me know, otherwise
I'll push tomorrow.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31278] [gdb/tdep, thumb2] GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31278

--- Comment #13 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7e4208a3f5d60f43b4a8f02e583fa950b599cd00

commit 7e4208a3f5d60f43b4a8f02e583fa950b599cd00
Author: Tom de Vries <tdevries@suse.de>
Date:   Tue Feb 13 09:10:54 2024 +0100

    [gdb/tdep] Fix reverse execution of LDR(immediate) T4

    When running test-case gdb.reverse/func-map-to-same-line.exp on arm-linux
with
    target board unix/-mthumb, we run into:
    ...
    (gdb) reverse-step
    func2 () at func-map-to-same-line.c:26
    26      {
    (gdb) FAIL: gdb.reverse/func-map-to-same-line.exp: \
      column_info_flag=column-info: step-test: reverse-step into func2
    ...

    The FAIL is caused by incorrect recording of this insn:
    ...
    4f6:   f85d 7b04       ldr.w   r7, [sp], #4
    ...

    The insn updates the sp, but we don't record this:
    ...
    $ gdb -q -batch func-map-to-same-line \
      -ex "b *func2+8" \
      -ex run \
      -ex record \
      -ex "set debug record 2" \
      -ex stepi
    Breakpoint 1 at 0x4f6: file func-map-to-same-line.c, line 27.

    Breakpoint 1, 0xaaaaa4f6 in func2 () at func-map-to-same-line.c:27
    27      } /* END FUNC2 */
    Process record: arm_process_record addr = 0xaaaaa4f6
    Process record: add register num = 15 to record list.
    Process record: record_full_arch_list_add 0xabc6c460.
    Process record: add register num = 7 to record list.
    Process record: record_full_arch_list_add 0xabc3b868.
    Process record: add register num = 25 to record list.
    ...
    [ Note that sp is r13, and we see here only r15 (pc), r7, and r25 (ps). ]

    The problem is that the specific insn, an LDR(immediate) T4, is not handled
in
    thumb2_record_ld_word.

    Fix this by detecting the insn in thumb2_record_ld_word, and recording the
    updated base register.

    Tested on arm-linux.

    Reported-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
    Approved-By: Luis Machado <luis.machado@arm.com>

    PR tdep/31278
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31278

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31278] [gdb/tdep, thumb2] GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31278

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |15.1
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #14 from Tom de Vries <vries at gcc dot gnu.org> ---
Fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.