public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/99388] New: Invalid debug info for __fp16
@ 2021-03-04 14:49 jakub at gcc dot gnu.org
2021-03-04 14:56 ` [Bug debug/99388] " jakub at gcc dot gnu.org
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-04 14:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388
Bug ID: 99388
Summary: Invalid debug info for __fp16
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
On:
void
foo (void)
{
__fp16 a = 1.0;
float b = 1.0;
asm ("nop");
a = 2.0;
b = 2.0;
asm ("nop");
a = 3.0;
b = 3.0;
asm ("nop");
}
with -g -O2 -dA on aarch64-linux we emit:
.LLST0:
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL0 // Location list begin address (*.LLST0)
.8byte .LVL1 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL1 // Location list begin address (*.LLST0)
.8byte .LVL2 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL2 // Location list begin address (*.LLST0)
.8byte .LFE0 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
.byte 0 // DW_LLE_end_of_list (*.LLST0)
This is invalid, the uleb128 0x2 should be always followed by the 2 byte value,
but there is nothing, so we interpret the DW_LLE_start_end or whatever as parts
of the values.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/99388] Invalid debug info for __fp16
2021-03-04 14:49 [Bug debug/99388] New: Invalid debug info for __fp16 jakub at gcc dot gnu.org
@ 2021-03-04 14:56 ` jakub at gcc dot gnu.org
2021-03-04 14:59 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-04 14:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-03-04
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 50299
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50299&action=edit
gcc11-pr99388.patch
Untested fix.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/99388] Invalid debug info for __fp16
2021-03-04 14:49 [Bug debug/99388] New: Invalid debug info for __fp16 jakub at gcc dot gnu.org
2021-03-04 14:56 ` [Bug debug/99388] " jakub at gcc dot gnu.org
@ 2021-03-04 14:59 ` jakub at gcc dot gnu.org
2021-03-21 16:29 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-04 14:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The above patch changes:
--- pr99388.s 2021-03-04 15:47:31.151944020 +0100
+++ pr99388.s 2021-03-04 15:51:51.404086604 +0100
@@ -267,18 +267,21 @@ foo:
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x3c00 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL1 // Location list begin address (*.LLST0)
.8byte .LVL2 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4000 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL2 // Location list begin address (*.LLST0)
.8byte .LFE0 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4200 // fp or vector constant word 0
.byte 0 // DW_LLE_end_of_list (*.LLST0)
.LVUS1:
.uleb128 .LVU3 // View list begin (*.LVUS1)
I fear there are other bugs related to handling vector constants, because for
vectors of floats/doubles/__fp16 etc. we use eltsize of the element size rather
than 4 (or for __fp16 2).
But then we throw such debug info on the floor during expansion, so maybe we
don't trigger that so often.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/99388] Invalid debug info for __fp16
2021-03-04 14:49 [Bug debug/99388] New: Invalid debug info for __fp16 jakub at gcc dot gnu.org
2021-03-04 14:56 ` [Bug debug/99388] " jakub at gcc dot gnu.org
2021-03-04 14:59 ` jakub at gcc dot gnu.org
@ 2021-03-21 16:29 ` cvs-commit at gcc dot gnu.org
2021-03-30 22:41 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-03-21 16:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388
--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:fc24ea2374259d401a46ce3526688b7e79d4cc13
commit r11-7753-gfc24ea2374259d401a46ce3526688b7e79d4cc13
Author: Jakub Jelinek <jakub@redhat.com>
Date: Sun Mar 21 17:27:39 2021 +0100
dwarf2out: Fix debug info for 2 byte floats [PR99388]
Aarch64, ARM and a couple of other architectures have 16-bit floats,
HFmode.
As can be seen e.g. on
void
foo (void)
{
__fp16 a = 1.0;
asm ("nop");
a = 2.0;
asm ("nop");
a = 3.0;
asm ("nop");
}
testcase, GCC mishandles this on the dwarf2out.c side by assuming all
floating point types have sizes in multiples of 4 bytes, so what GCC emits
is it says that e.g. the DW_OP_implicit_value will be 2 bytes but then
doesn't emit anything and so anything emitted after it is treated by
consumers as the value and then they get out of sync.
real_to_target which insert_float uses indeed fills it that way, but
putting
into an array of long 32 bits each time, but for the half floats it puts
everything into the least significant 16 bits of the first long no matter
what endianity host or target has.
The following patch fixes it. With the patch the -g -O2 -dA output changes
(in a cross without .uleb128 support):
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x3c00 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL1 // Location list begin address (*.LLST0)
.8byte .LVL2 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4000 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL2 // Location list begin address (*.LLST0)
.8byte .LFE0 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4200 // fp or vector constant word 0
.byte 0 // DW_LLE_end_of_list (*.LLST0)
Bootstrapped/regtested on x86_64-linux, aarch64-linux and
armv7hl-linux-gnueabi, ok for trunk?
I fear the CONST_VECTOR case is still broken, while HFmode elements of
vectors
should be fine (it uses eltsize of the element sizes) and likewise SFmode
could
be fine, DFmode vectors are emitted as two 32-bit ints regardless of
endianity
and I'm afraid it can't be right on big-endian. But I haven't been able to
create a testcase that emits a CONST_VECTOR, for e.g. unused vector vars
with constant operands we emit CONCATN during expansion and thus ...
DW_OP_*piece for each element of the vector and for
DW_TAG_call_site_parameter we give up (because we handle CONST_VECTOR only
in loc_descriptor, not mem_loc_descriptor).
2021-03-21 Jakub Jelinek <jakub@redhat.com>
PR debug/99388
* dwarf2out.c (insert_float): Change return type from void to
unsigned, handle GET_MODE_SIZE (mode) == 2 and return element size.
(mem_loc_descriptor, loc_descriptor, add_const_value_attribute):
Adjust callers.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/99388] Invalid debug info for __fp16
2021-03-04 14:49 [Bug debug/99388] New: Invalid debug info for __fp16 jakub at gcc dot gnu.org
` (2 preceding siblings ...)
2021-03-21 16:29 ` cvs-commit at gcc dot gnu.org
@ 2021-03-30 22:41 ` cvs-commit at gcc dot gnu.org
2021-04-20 23:33 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-03-30 22:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388
--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:d3dd3703f1d42b14c88b91e51a2a775fe00a2974
commit r10-9620-gd3dd3703f1d42b14c88b91e51a2a775fe00a2974
Author: Jakub Jelinek <jakub@redhat.com>
Date: Sun Mar 21 17:27:39 2021 +0100
dwarf2out: Fix debug info for 2 byte floats [PR99388]
Aarch64, ARM and a couple of other architectures have 16-bit floats,
HFmode.
As can be seen e.g. on
void
foo (void)
{
__fp16 a = 1.0;
asm ("nop");
a = 2.0;
asm ("nop");
a = 3.0;
asm ("nop");
}
testcase, GCC mishandles this on the dwarf2out.c side by assuming all
floating point types have sizes in multiples of 4 bytes, so what GCC emits
is it says that e.g. the DW_OP_implicit_value will be 2 bytes but then
doesn't emit anything and so anything emitted after it is treated by
consumers as the value and then they get out of sync.
real_to_target which insert_float uses indeed fills it that way, but
putting
into an array of long 32 bits each time, but for the half floats it puts
everything into the least significant 16 bits of the first long no matter
what endianity host or target has.
The following patch fixes it. With the patch the -g -O2 -dA output changes
(in a cross without .uleb128 support):
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x3c00 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL1 // Location list begin address (*.LLST0)
.8byte .LVL2 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4000 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL2 // Location list begin address (*.LLST0)
.8byte .LFE0 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4200 // fp or vector constant word 0
.byte 0 // DW_LLE_end_of_list (*.LLST0)
Bootstrapped/regtested on x86_64-linux, aarch64-linux and
armv7hl-linux-gnueabi, ok for trunk?
I fear the CONST_VECTOR case is still broken, while HFmode elements of
vectors
should be fine (it uses eltsize of the element sizes) and likewise SFmode
could
be fine, DFmode vectors are emitted as two 32-bit ints regardless of
endianity
and I'm afraid it can't be right on big-endian. But I haven't been able to
create a testcase that emits a CONST_VECTOR, for e.g. unused vector vars
with constant operands we emit CONCATN during expansion and thus ...
DW_OP_*piece for each element of the vector and for
DW_TAG_call_site_parameter we give up (because we handle CONST_VECTOR only
in loc_descriptor, not mem_loc_descriptor).
2021-03-21 Jakub Jelinek <jakub@redhat.com>
PR debug/99388
* dwarf2out.c (insert_float): Change return type from void to
unsigned, handle GET_MODE_SIZE (mode) == 2 and return element size.
(mem_loc_descriptor, loc_descriptor, add_const_value_attribute):
Adjust callers.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/99388] Invalid debug info for __fp16
2021-03-04 14:49 [Bug debug/99388] New: Invalid debug info for __fp16 jakub at gcc dot gnu.org
` (3 preceding siblings ...)
2021-03-30 22:41 ` cvs-commit at gcc dot gnu.org
@ 2021-04-20 23:33 ` cvs-commit at gcc dot gnu.org
2021-04-22 16:52 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-20 23:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:ce1bf41ff68a58512424daa473bea3e77de3eff4
commit r9-9435-gce1bf41ff68a58512424daa473bea3e77de3eff4
Author: Jakub Jelinek <jakub@redhat.com>
Date: Sun Mar 21 17:27:39 2021 +0100
dwarf2out: Fix debug info for 2 byte floats [PR99388]
Aarch64, ARM and a couple of other architectures have 16-bit floats,
HFmode.
As can be seen e.g. on
void
foo (void)
{
__fp16 a = 1.0;
asm ("nop");
a = 2.0;
asm ("nop");
a = 3.0;
asm ("nop");
}
testcase, GCC mishandles this on the dwarf2out.c side by assuming all
floating point types have sizes in multiples of 4 bytes, so what GCC emits
is it says that e.g. the DW_OP_implicit_value will be 2 bytes but then
doesn't emit anything and so anything emitted after it is treated by
consumers as the value and then they get out of sync.
real_to_target which insert_float uses indeed fills it that way, but
putting
into an array of long 32 bits each time, but for the half floats it puts
everything into the least significant 16 bits of the first long no matter
what endianity host or target has.
The following patch fixes it. With the patch the -g -O2 -dA output changes
(in a cross without .uleb128 support):
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x3c00 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL1 // Location list begin address (*.LLST0)
.8byte .LVL2 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4000 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL2 // Location list begin address (*.LLST0)
.8byte .LFE0 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4200 // fp or vector constant word 0
.byte 0 // DW_LLE_end_of_list (*.LLST0)
Bootstrapped/regtested on x86_64-linux, aarch64-linux and
armv7hl-linux-gnueabi, ok for trunk?
I fear the CONST_VECTOR case is still broken, while HFmode elements of
vectors
should be fine (it uses eltsize of the element sizes) and likewise SFmode
could
be fine, DFmode vectors are emitted as two 32-bit ints regardless of
endianity
and I'm afraid it can't be right on big-endian. But I haven't been able to
create a testcase that emits a CONST_VECTOR, for e.g. unused vector vars
with constant operands we emit CONCATN during expansion and thus ...
DW_OP_*piece for each element of the vector and for
DW_TAG_call_site_parameter we give up (because we handle CONST_VECTOR only
in loc_descriptor, not mem_loc_descriptor).
2021-03-21 Jakub Jelinek <jakub@redhat.com>
PR debug/99388
* dwarf2out.c (insert_float): Change return type from void to
unsigned, handle GET_MODE_SIZE (mode) == 2 and return element size.
(mem_loc_descriptor, loc_descriptor, add_const_value_attribute):
Adjust callers.
(cherry picked from commit d3dd3703f1d42b14c88b91e51a2a775fe00a2974)
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/99388] Invalid debug info for __fp16
2021-03-04 14:49 [Bug debug/99388] New: Invalid debug info for __fp16 jakub at gcc dot gnu.org
` (4 preceding siblings ...)
2021-04-20 23:33 ` cvs-commit at gcc dot gnu.org
@ 2021-04-22 16:52 ` cvs-commit at gcc dot gnu.org
2021-04-22 17:11 ` jakub at gcc dot gnu.org
2021-09-11 14:24 ` pinskia at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-22 16:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:dbdd062665903c88b89525573d7dfde233562e8c
commit r8-10898-gdbdd062665903c88b89525573d7dfde233562e8c
Author: Jakub Jelinek <jakub@redhat.com>
Date: Sun Mar 21 17:27:39 2021 +0100
dwarf2out: Fix debug info for 2 byte floats [PR99388]
Aarch64, ARM and a couple of other architectures have 16-bit floats,
HFmode.
As can be seen e.g. on
void
foo (void)
{
__fp16 a = 1.0;
asm ("nop");
a = 2.0;
asm ("nop");
a = 3.0;
asm ("nop");
}
testcase, GCC mishandles this on the dwarf2out.c side by assuming all
floating point types have sizes in multiples of 4 bytes, so what GCC emits
is it says that e.g. the DW_OP_implicit_value will be 2 bytes but then
doesn't emit anything and so anything emitted after it is treated by
consumers as the value and then they get out of sync.
real_to_target which insert_float uses indeed fills it that way, but
putting
into an array of long 32 bits each time, but for the half floats it puts
everything into the least significant 16 bits of the first long no matter
what endianity host or target has.
The following patch fixes it. With the patch the -g -O2 -dA output changes
(in a cross without .uleb128 support):
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x3c00 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL1 // Location list begin address (*.LLST0)
.8byte .LVL2 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4000 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL2 // Location list begin address (*.LLST0)
.8byte .LFE0 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e // DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4200 // fp or vector constant word 0
.byte 0 // DW_LLE_end_of_list (*.LLST0)
Bootstrapped/regtested on x86_64-linux, aarch64-linux and
armv7hl-linux-gnueabi, ok for trunk?
I fear the CONST_VECTOR case is still broken, while HFmode elements of
vectors
should be fine (it uses eltsize of the element sizes) and likewise SFmode
could
be fine, DFmode vectors are emitted as two 32-bit ints regardless of
endianity
and I'm afraid it can't be right on big-endian. But I haven't been able to
create a testcase that emits a CONST_VECTOR, for e.g. unused vector vars
with constant operands we emit CONCATN during expansion and thus ...
DW_OP_*piece for each element of the vector and for
DW_TAG_call_site_parameter we give up (because we handle CONST_VECTOR only
in loc_descriptor, not mem_loc_descriptor).
2021-03-21 Jakub Jelinek <jakub@redhat.com>
PR debug/99388
* dwarf2out.c (insert_float): Change return type from void to
unsigned, handle GET_MODE_SIZE (mode) == 2 and return element size.
(mem_loc_descriptor, loc_descriptor, add_const_value_attribute):
Adjust callers.
(cherry picked from commit d3dd3703f1d42b14c88b91e51a2a775fe00a2974)
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/99388] Invalid debug info for __fp16
2021-03-04 14:49 [Bug debug/99388] New: Invalid debug info for __fp16 jakub at gcc dot gnu.org
` (5 preceding siblings ...)
2021-04-22 16:52 ` cvs-commit at gcc dot gnu.org
@ 2021-04-22 17:11 ` jakub at gcc dot gnu.org
2021-09-11 14:24 ` pinskia at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-04-22 17:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/99388] Invalid debug info for __fp16
2021-03-04 14:49 [Bug debug/99388] New: Invalid debug info for __fp16 jakub at gcc dot gnu.org
` (6 preceding siblings ...)
2021-04-22 17:11 ` jakub at gcc dot gnu.org
@ 2021-09-11 14:24 ` pinskia at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-09-11 14:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |8.5
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-09-11 14:24 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-04 14:49 [Bug debug/99388] New: Invalid debug info for __fp16 jakub at gcc dot gnu.org
2021-03-04 14:56 ` [Bug debug/99388] " jakub at gcc dot gnu.org
2021-03-04 14:59 ` jakub at gcc dot gnu.org
2021-03-21 16:29 ` cvs-commit at gcc dot gnu.org
2021-03-30 22:41 ` cvs-commit at gcc dot gnu.org
2021-04-20 23:33 ` cvs-commit at gcc dot gnu.org
2021-04-22 16:52 ` cvs-commit at gcc dot gnu.org
2021-04-22 17:11 ` jakub at gcc dot gnu.org
2021-09-11 14:24 ` 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).