From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106218 invoked by alias); 3 Nov 2015 21:59:01 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 106201 invoked by uid 89); 3 Nov 2015 21:59:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_NONE,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: resqmta-po-05v.sys.comcast.net Received: from resqmta-po-05v.sys.comcast.net (HELO resqmta-po-05v.sys.comcast.net) (96.114.154.164) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 03 Nov 2015 21:58:58 +0000 Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-05v.sys.comcast.net with comcast id d9yx1r0035FMDhs019yx1P; Tue, 03 Nov 2015 21:58:57 +0000 Received: from [IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d] ([IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d]) by resomta-po-19v.sys.comcast.net with comcast id d9yt1r00B2ztT3H019yuZ2; Tue, 03 Nov 2015 21:58:55 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [ping] Fix PR debug/66728 From: Mike Stump In-Reply-To: <87wptztqpx.fsf@e105548-lin.cambridge.arm.com> Date: Tue, 03 Nov 2015 21:59:00 -0000 Cc: Bernd Schmidt , Ulrich Weigand , gcc-patches@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <29C8CB44-A0EC-4A9A-A4D3-3ABB6D66DA5B@comcast.net> References: <20151028115839.1E7C85C3D@oc7340732750.ibm.com> <87ziz3ta4t.fsf@e105548-lin.cambridge.arm.com> <5630D8AE.1090608@redhat.com> <87h9l4v2pi.fsf@e105548-lin.cambridge.arm.com> <87611kuzz4.fsf@e105548-lin.cambridge.arm.com> <871tc8unnx.fsf@e105548-lin.cambridge.arm.com> <87wptztqpx.fsf@e105548-lin.cambridge.arm.com> To: Richard Sandiford X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00275.txt.bz2 On Nov 3, 2015, at 12:46 AM, Richard Sandiford = wrote: > This isn't just an argument about the DWARF standard though. It's an > argument about GCC internals. Presumably these hypothetical BLKmode > types would need to support addition, I don=92t recall seeing that as a requirement in the dwarf standard, nor in= the language standard of the hypothetical language I posited. Further, I = don=92t recall seeing a prohibition on fetching from memory, combining thre= e byte to form a 24 bit value in a 64 bit register on x86_64, nor the prohi= bition on doing a 64-bit add on that architecture. Do you have a quote to = support your position? Further, I don=92t even see support that add must b= e supported in the language front end I posited. Since I control it, you c= an=92t can=92t require much of anything in it. > but plus:BLK is not well formed, BLKmode is well formed in gcc. I can=92t image what this even means. > and wouldn't distinguish between your 3-byte and 152-bit cases. A 3 byte value in dwarf has a byte length of 3, and a 152 bit value has a b= yte length of 19. I fail to see why in dwarf they cannot be distinguished.= A cleaver front end can track the values in that front end, and regions o= f memory that is uses to back objects, usually the front end does track obj= ects, and when asked to, will generate dwarf for them. I believe that fron= t ends are able to track object byte sized for objects. I believe that the= C++ front end does this for example, and will generate dwarf. > I don=92t think const_int and const_wide_int are logically different. They aren=92t. Indeed, the code for const_wide_int was copied from const_i= nt and/or const_double and only enhanced to have an arbitrary size. > There's the > historical decision that const_int doesn't have a stored mode, but I > don't think that was because we wanted to support const_ints that are > conceptually BLKmode. So, given that what must be, given the semantics of dwarf, and the totality= of semantics available to a front end, BLKmode values are perfectly well d= efined. I don=92t know why you would think otherwise. Further, arguing th= at we must break them, because=85 is silly, without the because elaborated= . A constant value that is known at compile time to be an arbitrary value = whose type is a signed n byte int can be represented in const_int when n fi= ts, and can be expressed as a const_wide_int when n fits and can be express= ed in dwarf. Further, const_int is not unreasonable to represent constants= , further, there is no prohibition on a front end having constants, nor on = the size of those constants being n bytes in size, at least for values of n= where n can be supported directly by const_wide_int. If there were one, yo= u could be able to quote it. > I think from an rtl perspective the only sensible way for frontends to > cope with integers whose size doesn't match an rtl mode is to promote > to the next widest mode, No, again, to support your position, you=92d have to quote the part of gcc = that disclaims support. You have not. You can think there is a prohibitio= n on 3 byte ints, if you want. I can=92t fix that. What I can object to, = is adding a line to the document that says that gcc cannot be used to write= a front end that supports 3 byte ints, or 19 byte ints. > which is what the stor-layout.c code I quoted > does. Obviously if your 3 byte type is actually 3 bytes in memory rather > than 4, and no 3-byte mode is available, you can't just load and store > the value using a normal rtl move. You have to use bitfield extraction > and insertion instead. So? Another technique that a front end could use is to fetch a HImode, and= a QImode value, shift and or them together, but no matter. > I picked this PR up because it was wide-int-related, even though > (as is probably all too obvious from this thread) I'm not familiar > with the dwarf2out.c code. It's actually your commit that I'm trying > to fix here (r201707). Would you mind taking the PR over and handling > it the way you think it should be handled? So, I did up the patch: Index: rtl.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- rtl.h (revision 229720) +++ rtl.h (working copy) @@ -2086,6 +2086,15 @@ inline unsigned int wi::int_traits ::get_precision (const rtx_mode_t &x) { + /* VOIDmode CONST_WIDE_INT pairings are used for debug information + when the type of the underlying object has not been tracked and + is unimportant so we form a precision from the value of the + constant. This is sufficient for dwarf generation as dwarf can + track the type separately from the value. */ + if (x.second =3D=3D VOIDmode + && CONST_WIDE_INT_P (x.first)) + return CONST_WIDE_INT_NUNITS (x.first) * HOST_BITS_PER_WIDE_INT; + return GET_MODE_PRECISION (x.second); } =20 Index: wide-int.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- wide-int.h (revision 229720) +++ wide-int.h (working copy) @@ -156,6 +156,10 @@ rtx r =3D ... wide_int x =3D std::make_pair (r, mode); =20 + If the mode is VOIDmode, then the precision of the wide_int will be + the number of bits used to represent the rtl's value. This is used for + untyped constants for dwarf debug information. + Similarly, a wide_int can only be constructed from a host value if the target precision is given explicitly, such as in: =20 The intent is to exactly match what gcc did before, to have wide-int handli= ng match what const_int does, and what const_double did in the past, merely= extended to support arbitrarily large values. I find, in this case, what = was done in the past to be valid and desirable. I don=92t find any reason = to deviate from what was done before. The test case from the PR changes like this: --- t-bad.s 2015-11-03 16:19:13.786248224 -0500 +++ t-fixed.s 2015-11-03 16:02:48.414290258 -0500 @@ -23,7 +23,7 @@ test: .Letext0: .section .debug_info,"",@progbits .Ldebug_info0: - .long 0x63 # Length of Compilation Unit Info + .long 0x74 # Length of Compilation Unit Info .value 0x4 # DWARF version number .long .Ldebug_abbrev0 # Offset Into Abbrev. Section .byte 0x8 # Pointer Size (in bytes) @@ -41,25 +41,28 @@ test: .byte 0x1 # DW_AT_decl_file (t.c) .byte 0x1 # DW_AT_decl_line # DW_AT_prototyped - .long 0x5a # DW_AT_type + .long 0x6b # DW_AT_type .quad .LFB0 # DW_AT_low_pc .quad .LFE0-.LFB0 # DW_AT_high_pc .uleb128 0x1 # DW_AT_frame_base .byte 0x9c # DW_OP_call_frame_cfa # DW_AT_GNU_all_call_sites - .long 0x5a # DW_AT_sibling + .long 0x6b # DW_AT_sibling .uleb128 0x3 # (DIE (0x4e) DW_TAG_variable) .long .LASF3 # DW_AT_name: "two127" .byte 0x1 # DW_AT_decl_file (t.c) .byte 0x3 # DW_AT_decl_line - .long 0x61 # DW_AT_type + .long 0x72 # DW_AT_type + .byte 0x10 + .quad 0 # DW_AT_const_value + .quad 0x8000000000000000 # (null) .byte 0 # end of children of DIE 0x2d - .uleb128 0x4 # (DIE (0x5a) DW_TAG_base_type) + .uleb128 0x4 # (DIE (0x6b) DW_TAG_base_type) .byte 0x10 # DW_AT_byte_size .byte 0x7 # DW_AT_encoding .long .LASF4 # DW_AT_name: "__int128 unsigned" - .uleb128 0x5 # (DIE (0x61) DW_TAG_const_type) - .long 0x5a # DW_AT_type + .uleb128 0x5 # (DIE (0x72) DW_TAG_const_type) + .long 0x6b # DW_AT_type .byte 0 # end of children of DIE 0xb .section .debug_abbrev,"",@progbits I=92m not a dwarf expert, but, I see the addition of two quads for a const = value, and that value seems to be 1 << 127 to my untrained eye. If I had t= o theorizes, I=92d say this is what the debug information was before. [ ch= ecking ] I checked gcc-4.8 on x86_64, and the debug information is now virt= ually the same: *** t-48.s 2015-11-03 16:24:23.286235021 -0500 --- t-fixed.s 2015-11-03 16:02:48.414290258 -0500 *************** test: *** 28,35 **** .long .Ldebug_abbrev0 # Offset Into Abbrev. Section .byte 0x8 # Pointer Size (in bytes) .uleb128 0x1 # (DIE (0xb) DW_TAG_compile_unit) ! .long .LASF0 # DW_AT_producer: "GNU C 4.8.4 -mtune=3Dgeneric -march=3Dx8= 6-64 -g -O -fstack-protector" ! .byte 0x1 # DW_AT_language .ascii "t.c\0" # DW_AT_name .long .LASF1 # DW_AT_comp_dir: "/home/mrs/net/gcc-linuxO0/gcc" .quad .Ltext0 # DW_AT_low_pc --- 28,35 ---- .long .Ldebug_abbrev0 # Offset Into Abbrev. Section .byte 0x8 # Pointer Size (in bytes) .uleb128 0x1 # (DIE (0xb) DW_TAG_compile_unit) ! .long .LASF0 # DW_AT_producer: "GNU C11 6.0.0 20151103 (experimental) [t= runk revision 229720] -O -g" ! .byte 0xc # DW_AT_language .ascii "t.c\0" # DW_AT_name .long .LASF1 # DW_AT_comp_dir: "/home/mrs/net/gcc-linuxO0/gcc" .quad .Ltext0 # DW_AT_low_pc *************** test: *** 55,61 **** .long 0x72 # DW_AT_type .byte 0x10 .quad 0 # DW_AT_const_value ! .quad 0x8000000000000000 .byte 0 # end of children of DIE 0x2d .uleb128 0x4 # (DIE (0x6b) DW_TAG_base_type) .byte 0x10 # DW_AT_byte_size --- 55,61 ---- .long 0x72 # DW_AT_type .byte 0x10 .quad 0 # DW_AT_const_value ! .quad 0x8000000000000000 # (null) .byte 0 # end of children of DIE 0x2d .uleb128 0x4 # (DIE (0x6b) DW_TAG_base_type) .byte 0x10 # DW_AT_byte_size *************** test: *** 162,168 **** .Ldebug_line0: .section .debug_str,"MS",@progbits,1 .LASF0: ! .string "GNU C 4.8.4 -mtune=3Dgeneric -march=3Dx86-64 -g -O -fstack-prot= ector" .LASF1: .string "/home/mrs/net/gcc-linuxO0/gcc" .LASF3: --- 162,168 ---- .Ldebug_line0: .section .debug_str,"MS",@progbits,1 .LASF0: ! .string "GNU C11 6.0.0 20151103 (experimental) [trunk revision 229720] -= O -g" .LASF1: .string "/home/mrs/net/gcc-linuxO0/gcc" .LASF3: *************** test: *** 171,175 **** .string "test" .LASF4: .string "__int128 unsigned" ! .ident "GCC: (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4" .section .note.GNU-stack,"",@progbits --- 171,175 ---- .string "test" .LASF4: .string "__int128 unsigned" ! .ident "GCC: (GNU) 6.0.0 20151103 (experimental) [trunk revision 229720]" .section .note.GNU-stack,"",@progbits The language seems weird, but, I bet it is inconsequential and an artifact = of how I ran the test case. The # (null) is unfortunate, I don=92t think t= his is better than what gcc-4.8 did, but, I don=92t think that was caused b= y my patch. So, this would be my proposal to fix the issue. I'd invite anyone that thi= nks the dwarf information was wrong in gcc-4.8 or wrong post the patch, to = let us know why. If there are reasons why my position is wrong, I=92d like= to hear about it, otherwise I=92ll plan on checking this in with my wide-i= nt hat on. Since this is a serious regression in debug quality, this has t= o go the the release branches that contain wide-int.