public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/99388] Invalid debug info for __fp16 Date: Tue, 20 Apr 2021 23:33:46 +0000 [thread overview] Message-ID: <bug-99388-4-mkQvbppEJc@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-99388-4@http.gcc.gnu.org/bugzilla/> 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)
next prev parent reply other threads:[~2021-04-20 23:33 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-04 14:49 [Bug debug/99388] New: " 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 [this message] 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
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-99388-4-mkQvbppEJc@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).