* [LTO][PATCH] Fix long double precision problem @ 2007-12-05 7:05 Doug Kwan (關振德) 2007-12-05 10:52 ` Andrew Pinski 0 siblings, 1 reply; 24+ messages in thread From: Doug Kwan (關振德) @ 2007-12-05 7:05 UTC (permalink / raw) To: gcc-patches, Diego Novillo, zadeck [-- Attachment #1: Type: text/plain, Size: 176 bytes --] Hi, Could someone review this patch. This fixes a problem where long double type has BLK mode instead of the correct XF mode. It fixes about 20 dejagnu failures. -Doug [-- Attachment #2: patches.txt --] [-- Type: text/plain, Size: 1505 bytes --] 2007-12-04 Doug Kwan <dougkwan@google.com> * lto.c (lto_real_type_precision): New. (lto_read_base_type_DIE): Use type size to compute precision of a scalar real base type instead of using type size as precision. Index: gcc/lto/lto.c =================================================================== --- gcc/lto/lto.c (revision 130614) +++ gcc/lto/lto.c (working copy) @@ -2899,6 +2899,20 @@ lto_read_subrange_type_DIE (lto_info_fd return type; } +static int +lto_real_type_precision (int size) +{ + if (size == TREE_INT_CST_LOW (TYPE_SIZE (float_type_node))) + return TYPE_PRECISION (float_type_node); + if (size == TREE_INT_CST_LOW (TYPE_SIZE (double_type_node))) + return TYPE_PRECISION (double_type_node); + if (size == TREE_INT_CST_LOW (TYPE_SIZE (long_double_type_node))) + return TYPE_PRECISION (long_double_type_node); + + gcc_unreachable (); + return 0; +} + static tree lto_read_base_type_DIE (lto_info_fd *fd, lto_die_ptr die ATTRIBUTE_UNUSED, @@ -3003,14 +3017,14 @@ lto_read_base_type_DIE (lto_info_fd *fd, case DW_ATE_float: type = make_node (REAL_TYPE); - TYPE_PRECISION (type) = bits; + TYPE_PRECISION (type) = lto_real_type_precision (bits); layout_type (type); break; case DW_ATE_complex_float: { tree base = make_node (REAL_TYPE); - TYPE_PRECISION (base) = bits / 2; + TYPE_PRECISION (base) = lto_real_type_precision (bits / 2); layout_type (base); type = build_complex_type (base); } ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-05 7:05 [LTO][PATCH] Fix long double precision problem Doug Kwan (關振德) @ 2007-12-05 10:52 ` Andrew Pinski 2007-12-05 12:55 ` Kenneth Zadeck 0 siblings, 1 reply; 24+ messages in thread From: Andrew Pinski @ 2007-12-05 10:52 UTC (permalink / raw) To: Doug Kwan (關振德); +Cc: gcc-patches, Diego Novillo, zadeck On 12/4/07, Doug Kwan (關振德) <dougkwan@google.com> wrote: > Hi, > > Could someone review this patch. This fixes a problem where long > double type has BLK mode instead of the correct XF mode. It fixes > about 20 dejagnu failures. I think for ia64-hpux, you can use both TFmode and XFmode so maybe this is not going to work for that. --Pinski ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-05 10:52 ` Andrew Pinski @ 2007-12-05 12:55 ` Kenneth Zadeck 2007-12-05 14:56 ` Diego Novillo 2007-12-05 16:34 ` Mark Mitchell 0 siblings, 2 replies; 24+ messages in thread From: Kenneth Zadeck @ 2007-12-05 12:55 UTC (permalink / raw) To: Andrew Pinski Cc: "Doug Kwan (關振德)", gcc-patches, Diego Novillo, Nathan Froyd, Mark Mitchell Andrew Pinski wrote: > On 12/4/07, Doug Kwan (éæ¯å¾·) <dougkwan@google.com> wrote: > >> Hi, >> >> Could someone review this patch. This fixes a problem where long >> double type has BLK mode instead of the correct XF mode. It fixes >> about 20 dejagnu failures. >> > > I think for ia64-hpux, you can use both TFmode and XFmode so maybe > this is not going to work for that. > > --Pinski > is the right solution to just serialize the size and restore it from that? kenny ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-05 12:55 ` Kenneth Zadeck @ 2007-12-05 14:56 ` Diego Novillo 2007-12-05 16:28 ` Doug Kwan (關振德) 2007-12-05 16:34 ` Mark Mitchell 1 sibling, 1 reply; 24+ messages in thread From: Diego Novillo @ 2007-12-05 14:56 UTC (permalink / raw) To: Kenneth Zadeck Cc: Andrew Pinski, "Doug Kwan (關振德)", gcc-patches, Nathan Froyd, Mark Mitchell On 12/5/07 7:54 AM, Kenneth Zadeck wrote: > is the right solution to just serialize the size and restore it from that? Unless there is already a target hook for doing this, I think it's safest to just serialize these bits. Diego. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-05 14:56 ` Diego Novillo @ 2007-12-05 16:28 ` Doug Kwan (關振德) 2007-12-05 19:02 ` Andrew Pinski 0 siblings, 1 reply; 24+ messages in thread From: Doug Kwan (關振德) @ 2007-12-05 16:28 UTC (permalink / raw) To: Diego Novillo Cc: Kenneth Zadeck, Andrew Pinski, gcc-patches, Nathan Froyd, Mark Mitchell Agree. I will change my patch and send it out when it's ready. 2007/12/5, Diego Novillo <dnovillo@google.com>: > On 12/5/07 7:54 AM, Kenneth Zadeck wrote: > > > is the right solution to just serialize the size and restore it from that? > > Unless there is already a target hook for doing this, I think it's > safest to just serialize these bits. > > > Diego. > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-05 16:28 ` Doug Kwan (關振德) @ 2007-12-05 19:02 ` Andrew Pinski 0 siblings, 0 replies; 24+ messages in thread From: Andrew Pinski @ 2007-12-05 19:02 UTC (permalink / raw) To: Doug Kwan (關振德) Cc: Diego Novillo, Kenneth Zadeck, gcc-patches, Nathan Froyd, Mark Mitchell On 12/5/07, Doug Kwan (關振德) <dougkwan@google.com> wrote: > Agree. I will change my patch and send it out when it's ready. I think this can fix bit fields too if you emit the TYPE_PRECISION for them. -- Pinski ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-05 12:55 ` Kenneth Zadeck 2007-12-05 14:56 ` Diego Novillo @ 2007-12-05 16:34 ` Mark Mitchell 2007-12-05 18:42 ` Doug Kwan (關振德) 2007-12-05 19:01 ` Doug Kwan (關振德) 1 sibling, 2 replies; 24+ messages in thread From: Mark Mitchell @ 2007-12-05 16:34 UTC (permalink / raw) To: Kenneth Zadeck Cc: Andrew Pinski, "Doug Kwan (關振德)", gcc-patches, Diego Novillo, Nathan Froyd Kenneth Zadeck wrote: >> I think for ia64-hpux, you can use both TFmode and XFmode so maybe >> this is not going to work for that. >> >> --Pinski >> > is the right solution to just serialize the size and restore it from that? Yes, and that's what the current code is doing; it looks at DW_AT_bit_size in the DWARF information to determine how many bits to use. If that's not sufficient because, for example, DW_AT_bit_size is the number of bits consumed in memory, but TYPE_PRECISION is supposed to be the number of bits of useful data, then we should add a DW_AT_gnu_precision attribute to the DWARF. This is exactly the kind of DWARF extension we want to make: in addition to being useful for LTO, we get better information for the debugger. Please make sure that any new DWARF attributes are clearly documented, without reference to GCC internals; the right documentation for DW_AT_gnu_precision is not "this is TYPE_PRECISION". However, first we should check if DW_AT_bit_size is being emitted correctly. Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-05 16:34 ` Mark Mitchell @ 2007-12-05 18:42 ` Doug Kwan (關振德) 2007-12-05 19:01 ` Doug Kwan (關振德) 1 sibling, 0 replies; 24+ messages in thread From: Doug Kwan (關振德) @ 2007-12-05 18:42 UTC (permalink / raw) To: Mark Mitchell Cc: Kenneth Zadeck, Andrew Pinski, gcc-patches, Diego Novillo, Nathan Froyd 2007/12/5, Mark Mitchell <mark@codesourcery.com>: > However, first we should check if DW_AT_bit_size is being emitted correctly. On i386, 80-bit extended floating point format is stored in 12 bytes (96 bits). It is a problem even if DW_AT_bit_size is being emitted correctly. -Doug ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-05 16:34 ` Mark Mitchell 2007-12-05 18:42 ` Doug Kwan (關振德) @ 2007-12-05 19:01 ` Doug Kwan (關振德) 2007-12-05 23:52 ` Mark Mitchell 1 sibling, 1 reply; 24+ messages in thread From: Doug Kwan (關振德) @ 2007-12-05 19:01 UTC (permalink / raw) To: Mark Mitchell Cc: Kenneth Zadeck, Andrew Pinski, gcc-patches, Diego Novillo, Nathan Froyd The reason why I did the patch that way is to avoid changing the external debugging interface. If we need to serialize precisions, we may not need another GNU dwarf extension. Currently already gcc emits DW_AT_bit_size and DW_AT_bit_offset pairs for integral types whose precisions are less than their bit width. We can just add code to handling real scalar types. I am not sure what changes, if any, are required on the client side of the debugging information (e.g. gdb). I am willing to implement those changes though. -Doug 2007/12/5, Mark Mitchell <mark@codesourcery.com>: > This is exactly the kind of DWARF extension we want to make: in addition > to being useful for LTO, we get better information for the debugger. > Please make sure that any new DWARF attributes are clearly documented, > without reference to GCC internals; the right documentation for > DW_AT_gnu_precision is not "this is TYPE_PRECISION". ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-05 19:01 ` Doug Kwan (關振德) @ 2007-12-05 23:52 ` Mark Mitchell 2007-12-11 23:15 ` Doug Kwan (關振德) 0 siblings, 1 reply; 24+ messages in thread From: Mark Mitchell @ 2007-12-05 23:52 UTC (permalink / raw) To: "Doug Kwan (關振德)" Cc: Kenneth Zadeck, Andrew Pinski, gcc-patches, Diego Novillo, Nathan Froyd Doug Kwan (éæ¯å¾·) wrote: > The reason why I did the patch that way is to avoid changing the > external debugging interface. If we need to serialize precisions, we > may not need another GNU dwarf extension. Currently already gcc emits > DW_AT_bit_size and DW_AT_bit_offset pairs for integral types whose > precisions are less than their bit width. We can just add code to > handling real scalar types. Yes, I think you're 100% right. I've reviewed the DWARF spec and, indeed, DW_AT_bit_size/DW_AT_bit_offset are designed for exactly this case. So, we should just arrange to emit that information in dwarf2out.c. > I am not sure what changes, if any, are required on the client side of > the debugging information (e.g. gdb). I am willing to implement those > changes though. I'm certainly not a GDB expert so I don't know what impact that might have either. It's just making the debug information more complete, so, hopefully, it should Just Work, but it could of course also be the case that something goes wrong. Running the GDB testsuite is probably a good first cut. I'd suggest asking on the GDB mailing list. Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-05 23:52 ` Mark Mitchell @ 2007-12-11 23:15 ` Doug Kwan (關振德) 2007-12-12 9:22 ` Mark Mitchell 0 siblings, 1 reply; 24+ messages in thread From: Doug Kwan (關振德) @ 2007-12-11 23:15 UTC (permalink / raw) To: Mark Mitchell Cc: Kenneth Zadeck, Andrew Pinski, gcc-patches, Diego Novillo, Nathan Froyd I got no reply from gdb mailing list. Apparently no one care :) There is another wrinkle. The complex extended float type has the same issue. I don't really think it is correct to use DW_AT_bit_size & DW_AT_bit_offset for this case since the bits are not contiguous. However, in the name of not complicating things, I prefer using existing DW_AT_bit_size and DW_AT_bit_offset than adding a new GNU extension. I am fine either way. What do you guys think? -Doug 2007/12/5, Mark Mitchell <mark@codesourcery.com>: > Doug Kwan (關振德) wrote: > > The reason why I did the patch that way is to avoid changing the > > external debugging interface. If we need to serialize precisions, we > > may not need another GNU dwarf extension. Currently already gcc emits > > DW_AT_bit_size and DW_AT_bit_offset pairs for integral types whose > > precisions are less than their bit width. We can just add code to > > handling real scalar types. > > Yes, I think you're 100% right. I've reviewed the DWARF spec and, > indeed, DW_AT_bit_size/DW_AT_bit_offset are designed for exactly this > case. So, we should just arrange to emit that information in dwarf2out.c. > > > I am not sure what changes, if any, are required on the client side of > > the debugging information (e.g. gdb). I am willing to implement those > > changes though. > > I'm certainly not a GDB expert so I don't know what impact that might > have either. It's just making the debug information more complete, so, > hopefully, it should Just Work, but it could of course also be the case > that something goes wrong. Running the GDB testsuite is probably a good > first cut. I'd suggest asking on the GDB mailing list. > > Thanks, > > -- > Mark Mitchell > CodeSourcery > mark@codesourcery.com > (650) 331-3385 x713 > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-11 23:15 ` Doug Kwan (關振德) @ 2007-12-12 9:22 ` Mark Mitchell 2007-12-12 20:23 ` Doug Kwan (關振德) 0 siblings, 1 reply; 24+ messages in thread From: Mark Mitchell @ 2007-12-12 9:22 UTC (permalink / raw) To: "Doug Kwan (關振德)" Cc: Kenneth Zadeck, Andrew Pinski, gcc-patches, Diego Novillo, Nathan Froyd [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=Big5, Size: 611 bytes --] Doug Kwan (Ãö®¶¼w) wrote: > There is another wrinkle. The complex extended float type has the same > issue. I don't really think it is correct to use DW_AT_bit_size & > DW_AT_bit_offset for this case since the bits are not contiguous. > However, in the name of not complicating things, I prefer using > existing DW_AT_bit_size and DW_AT_bit_offset than adding a new GNU > extension. I am fine either way. What do you guys think? What do you mean about the bits not being contiguous? Can you explain that a little bit? Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-12 9:22 ` Mark Mitchell @ 2007-12-12 20:23 ` Doug Kwan (關振德) 2007-12-12 20:45 ` Mark Mitchell 0 siblings, 1 reply; 24+ messages in thread From: Doug Kwan (關振德) @ 2007-12-12 20:23 UTC (permalink / raw) To: Mark Mitchell Cc: Kenneth Zadeck, Andrew Pinski, gcc-patches, Diego Novillo, Nathan Froyd I want ot use DW_AT_bit_size to represent the precision of 80-bit extended floats, which are stored in 96-bit (12 bytes) locations. For complex 80-bit extended floats, the two 80-bits real and imaginary parts have padding between them. The dwarf3 spec does not say if DW_AT_bit_size & DW_AT_bit_offset are for a contiguous chunk of bits but I am inclined to interpret this way. If it is too confusing to use DW_AT_bit_size and DW_AT_bit_offset to represent 80-bit floats stored in 96-bit storage locations, we might add an extension to dwarf3. -Doug 在 2007/12/11,Mark Mitchell <mark@codesourcery.com> 撰寫: > What do you mean about the bits not being contiguous? Can you explain > that a little bit? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-12 20:23 ` Doug Kwan (關振德) @ 2007-12-12 20:45 ` Mark Mitchell 2007-12-13 2:27 ` Doug Kwan (關振德) 2007-12-13 20:11 ` Jim Blandy 0 siblings, 2 replies; 24+ messages in thread From: Mark Mitchell @ 2007-12-12 20:45 UTC (permalink / raw) To: "Doug Kwan (關振德)", Jim Blandy Cc: Kenneth Zadeck, Andrew Pinski, gcc-patches, Diego Novillo, Nathan Froyd [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=Big5, Size: 974 bytes --] Doug Kwan (Ãö®¶¼w) wrote: > I want ot use DW_AT_bit_size to represent the precision of 80-bit > extended floats, which are stored in > 96-bit (12 bytes) locations. For complex 80-bit extended floats, the > two 80-bits real and imaginary parts have padding between them. The > dwarf3 spec does not say if DW_AT_bit_size & DW_AT_bit_offset are for > a contiguous chunk of bits but I am inclined to interpret this way. > > If it is too confusing to use DW_AT_bit_size and DW_AT_bit_offset to > represent 80-bit floats stored in 96-bit storage locations, we might > add an extension to dwarf3. I see. Jim, as someone whose participated in DWARF standardization, do you have an opinion about how these complex floats ought to be represented? Doug, in the near term, I don't think we need to worry about the padding. We should just use DW_AT_bit_{size,offset} for floating-point types. Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-12 20:45 ` Mark Mitchell @ 2007-12-13 2:27 ` Doug Kwan (關振德) 2007-12-13 11:02 ` Andreas Schwab 2007-12-13 20:11 ` Jim Blandy 1 sibling, 1 reply; 24+ messages in thread From: Doug Kwan (關振德) @ 2007-12-13 2:27 UTC (permalink / raw) To: gcc-patches, Diego Novillo, Kenneth Zadeck [-- Attachment #1: Type: text/plain, Size: 192 bytes --] Hi, Here is another attempt to fix this issue by emitting DW_AT_bit_size and DW_AT_bit_offset for float types which have precisions smaller than their storage size. Please review. -Doug [-- Attachment #2: patches-2.txt --] [-- Type: text/plain, Size: 2555 bytes --] ChangleLog.lto 2007-12-12 Doug Kwan <dougkwan@google.com> * dwarf2out.c (base_type_die): Emit extra DW_AT_bit_size and DW_AT_bit_offset pair for scalar and complex float types that have precisions smaller than storage sizes. lto/ChangeLog 2007-12-12 Doug Kwan <dougkwan@google.com> * lto.c (lto_read_base_type_DIE): Add support for float types in code that deals with DW_AT_bit_size and DW_AT_bit_offset. Index: gcc/dwarf2out.c =================================================================== --- gcc/dwarf2out.c (revision 130795) +++ gcc/dwarf2out.c (working copy) @@ -8494,7 +8494,8 @@ base_type_die (tree type) /* Emit extra information for integral types whose precision is less than the bit width of their containing object. */ - if (TREE_CODE (type) == INTEGER_TYPE + if ((TREE_CODE (type) == INTEGER_TYPE + || SCALAR_FLOAT_TYPE_P (type)) && TYPE_PRECISION (type) < byte_size * BITS_PER_UNIT) { add_AT_unsigned (base_type_result, DW_AT_bit_size, @@ -8502,6 +8503,20 @@ base_type_die (tree type) add_AT_unsigned (base_type_result, DW_AT_bit_offset, byte_size * BITS_PER_UNIT - TYPE_PRECISION (type)); } + else if (COMPLEX_FLOAT_TYPE_P (type)) + { + tree scalar_type = TREE_TYPE (type); + int bits_used = TYPE_PRECISION (scalar_type) * 2; + if (bits_used < byte_size * BITS_PER_UNIT) + { + /* FIXME: If the scalar type has precision smaller than half of the + storage size, the bits are possibly not contiguous. We are + probably abusing the DW_AT_bit_size/DW_AT_bit_offset semantics. */ + add_AT_unsigned (base_type_result, DW_AT_bit_size, bits_used); + add_AT_unsigned (base_type_result, DW_AT_bit_offset, + byte_size * BITS_PER_UNIT - bits_used); + } + } return base_type_result; } Index: gcc/lto/lto.c =================================================================== --- gcc/lto/lto.c (revision 130795) +++ gcc/lto/lto.c (working copy) @@ -3012,8 +3012,11 @@ lto_read_base_type_DIE (lto_info_fd *fd, { if (bits > maxbits) lto_file_corrupt_error ((lto_fd *)fd); - if (encoding != DW_ATE_unsigned && encoding != DW_ATE_signed) - sorry ("bit size attribute only supported for signed/unsigned types"); + if (encoding != DW_ATE_unsigned + && encoding != DW_ATE_signed + && encoding != DW_ATE_float + && encoding != DW_ATE_complex_float) + sorry ("bit size attribute only supported for some types"); if (offset != maxbits - bits) sorry ("unaligned base type not supported"); } ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-13 2:27 ` Doug Kwan (關振德) @ 2007-12-13 11:02 ` Andreas Schwab 2007-12-13 19:13 ` Doug Kwan (關振德) 0 siblings, 1 reply; 24+ messages in thread From: Andreas Schwab @ 2007-12-13 11:02 UTC (permalink / raw) To: Doug Kwan ; +Cc: gcc-patches, Diego Novillo, Kenneth Zadeck ""Doug Kwan (關振德)"" <dougkwan@google.com> writes: > Index: gcc/dwarf2out.c > =================================================================== > --- gcc/dwarf2out.c (revision 130795) > +++ gcc/dwarf2out.c (working copy) > @@ -8494,7 +8494,8 @@ base_type_die (tree type) > > /* Emit extra information for integral types whose precision is less > than the bit width of their containing object. */ > - if (TREE_CODE (type) == INTEGER_TYPE > + if ((TREE_CODE (type) == INTEGER_TYPE > + || SCALAR_FLOAT_TYPE_P (type)) > && TYPE_PRECISION (type) < byte_size * BITS_PER_UNIT) > { What if the padding is internal? Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-13 11:02 ` Andreas Schwab @ 2007-12-13 19:13 ` Doug Kwan (關振德) 2007-12-14 9:50 ` Andreas Schwab 0 siblings, 1 reply; 24+ messages in thread From: Doug Kwan (關振德) @ 2007-12-13 19:13 UTC (permalink / raw) To: Andreas Schwab; +Cc: gcc-patches, Diego Novillo, Kenneth Zadeck At I have mentioned earlier. That may not be a correct thing to do. On the x86, the 80-bit extended floating point formating is stored using one instruction and there is no internal padding. However, there is internal padding in complex long double. Any thing expecting a contiguous chunk of bits may be surprised. I have done some simple testing with gdb by compiling test and stepping them under gdb. The long double case worked but complex long double caused gdb to crash. That was more likely that it was a bug in gdb as gdb crashed with debug info generated from stock gcc also. In the long term, we need an appropriate dwarf extension. -Doug 2007/12/13, Andreas Schwab <schwab@suse.de>: > What if the padding is internal? > > Andreas. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-13 19:13 ` Doug Kwan (關振德) @ 2007-12-14 9:50 ` Andreas Schwab 2007-12-14 22:18 ` Doug Kwan (關振德) 0 siblings, 1 reply; 24+ messages in thread From: Andreas Schwab @ 2007-12-14 9:50 UTC (permalink / raw) To: Doug Kwan ; +Cc: gcc-patches, Diego Novillo, Kenneth Zadeck ""Doug Kwan (關振德)"" <dougkwan@google.com> writes: > At I have mentioned earlier. That may not be a correct thing to do. It doesn't handle endianess correctly either, AFAICS. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-14 9:50 ` Andreas Schwab @ 2007-12-14 22:18 ` Doug Kwan (關振德) 0 siblings, 0 replies; 24+ messages in thread From: Doug Kwan (關振德) @ 2007-12-14 22:18 UTC (permalink / raw) To: Andreas Schwab; +Cc: gcc-patches, Diego Novillo, Kenneth Zadeck At least for the LTO, we only care about the number of bit used. The bit offset is bogus. Also long as gcc and recover the floating point type based on the number of bits used, it is okay. Instead of abusing the DW_AT_bit_size and DW_AT_bit_offset pair, I can use a new dwarf extension as I mentioned earlier in this thread. -Doug 2007/12/14, Andreas Schwab <schwab@suse.de>: > ""Doug Kwan (關振德)"" <dougkwan@google.com> writes: > It doesn't handle endianess correctly either, AFAICS. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-12 20:45 ` Mark Mitchell 2007-12-13 2:27 ` Doug Kwan (關振德) @ 2007-12-13 20:11 ` Jim Blandy 2007-12-13 20:40 ` Doug Kwan (關振德) 1 sibling, 1 reply; 24+ messages in thread From: Jim Blandy @ 2007-12-13 20:11 UTC (permalink / raw) To: Mark Mitchell Cc: Doug Kwan (關振德), Kenneth Zadeck, Andrew Pinski, gcc-patches, Diego Novillo, Nathan Froyd Mark Mitchell <mark at codesourcery.com> writes: > Doug Kwan (關振德) wrote: >> I want ot use DW_AT_bit_size to represent the precision of 80-bit >> extended floats, which are stored in >> 96-bit (12 bytes) locations. For complex 80-bit extended floats, the >> two 80-bits real and imaginary parts have padding between them. The >> dwarf3 spec does not say if DW_AT_bit_size & DW_AT_bit_offset are for >> a contiguous chunk of bits but I am inclined to interpret this way. >> >> If it is too confusing to use DW_AT_bit_size and DW_AT_bit_offset to >> represent 80-bit floats stored in 96-bit storage locations, we might >> add an extension to dwarf3. > > I see. Jim, as someone whose participated in DWARF standardization, do > you have an opinion about how these complex floats ought to be > represented? From my reading, DW_AT_bit_size/DW_AT_bit_offset are intended to handle just this sort of case. Floating-point types are base types; Section 5.1, "Base Type Entries", says: If the value of an object of the given type does not fully occupy the storage unit described by the byte size attribute, the base type entry may have a DW_AT_bit_size attribute and a DW_AT_bit_offset attribute, both of whose values (see Section 2.19) are integers. The bit size attribute describes the actual size in bits used to represent a value of the given type. The bit offset attribute describes the offset in bits of the high order bit of a value of the given type from the high order bit of the storage unit used to contain that value. That sounds pretty much like the situation in hand. Section 5.6.6, "Data Member Entries", shows how those same two attributes are used to describe bitfields within a structure, in the little-endian and big-endian cases; we should try to use them consistently on base types. The process described there identifies a containing anonymous object some integral number of bytes in length, lays out that object's bits with the most significant on the left and least on the right, and then says that DW_AT_bit_offset counts from the leftmost bit of the anonymous object to the leftmost bit of the field of interest. So, for the eighty-bit float occupying a 12-byte slot, assuming the eighty meaningful bits appear at the low-addressed end of that slot regardless of endianess, you'd have a DW_AT_byte_size of 12, a DW_AT_bit_size of 80, and a DW_AT_bit_offset of 16 on little-endian machines, or zero on big-endian machines. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-13 20:11 ` Jim Blandy @ 2007-12-13 20:40 ` Doug Kwan (關振德) 2007-12-13 22:43 ` Jim Blandy 0 siblings, 1 reply; 24+ messages in thread From: Doug Kwan (關振德) @ 2007-12-13 20:40 UTC (permalink / raw) To: Jim Blandy Cc: Mark Mitchell, Kenneth Zadeck, Andrew Pinski, gcc-patches, Diego Novillo, Nathan Froyd Jim, What about complex long double? There are padding bits between the real and imaginary parts. -Doug 2007/12/13, Jim Blandy <jimb@codesourcery.com>: > > Mark Mitchell <mark at codesourcery.com> writes: > > Doug Kwan (關振德) wrote: > >> I want ot use DW_AT_bit_size to represent the precision of 80-bit > >> extended floats, which are stored in > >> 96-bit (12 bytes) locations. For complex 80-bit extended floats, the > >> two 80-bits real and imaginary parts have padding between them. The > >> dwarf3 spec does not say if DW_AT_bit_size & DW_AT_bit_offset are for > >> a contiguous chunk of bits but I am inclined to interpret this way. > >> > >> If it is too confusing to use DW_AT_bit_size and DW_AT_bit_offset to > >> represent 80-bit floats stored in 96-bit storage locations, we might > >> add an extension to dwarf3. > > > > I see. Jim, as someone whose participated in DWARF standardization, do > > you have an opinion about how these complex floats ought to be > > represented? > > From my reading, DW_AT_bit_size/DW_AT_bit_offset are intended to > handle just this sort of case. Floating-point types are base types; > Section 5.1, "Base Type Entries", says: > > If the value of an object of the given type does not fully occupy > the storage unit described by the byte size attribute, the base > type entry may have a DW_AT_bit_size attribute and a > DW_AT_bit_offset attribute, both of whose values (see Section > 2.19) are integers. The bit size attribute describes the actual > size in bits used to represent a value of the given type. The bit > offset attribute describes the offset in bits of the high order > bit of a value of the given type from the high order bit of the > storage unit used to contain that value. > > That sounds pretty much like the situation in hand. > > Section 5.6.6, "Data Member Entries", shows how those same two > attributes are used to describe bitfields within a structure, in the > little-endian and big-endian cases; we should try to use them > consistently on base types. The process described there identifies a > containing anonymous object some integral number of bytes in length, > lays out that object's bits with the most significant on the left and > least on the right, and then says that DW_AT_bit_offset counts from > the leftmost bit of the anonymous object to the leftmost bit of the > field of interest. > > So, for the eighty-bit float occupying a 12-byte slot, assuming the > eighty meaningful bits appear at the low-addressed end of that slot > regardless of endianess, you'd have a DW_AT_byte_size of 12, a > DW_AT_bit_size of 80, and a DW_AT_bit_offset of 16 on little-endian > machines, or zero on big-endian machines. > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-13 20:40 ` Doug Kwan (關振德) @ 2007-12-13 22:43 ` Jim Blandy [not found] ` <4765FBC0.8020400@codesourcery.com> 0 siblings, 1 reply; 24+ messages in thread From: Jim Blandy @ 2007-12-13 22:43 UTC (permalink / raw) To: Doug Kwan Cc: Mark Mitchell, Kenneth Zadeck, Andrew Pinski, gcc-patches, Diego Novillo, Nathan Froyd ""Doug Kwan (關振德)"" <dougkwan at google.com> writes: > What about complex long double? There are padding bits between the > real and imaginary parts. My understanding is that the base types are not meant to completely specify how the debugger should interpret a type it's never seen before; they're just meant to distinguish the source language's base types. For example, DWARF just has DW_ATE_float, not DW_ATE_ieee_float, nor DW_ATE_float with DW_AT_mantissa_bits and DW_AT_exponent_bias. Once the DWARF has identified the type, it's up to the ABI to specify the details of its representation. Under that interpretation, all GCC should do for long double complex is emit a DW_TAG_base_type with DW_ATE_complex_float and DW_AT_byte_size == 24. That's enough to distinguish long double complex from double complex or float complex. It's not necessary for the DWARF to explicitly mention the 80-bit length if the ABI dictates that for a lone 24-byte complex type. (Do you also have a full 12-byte floating point complex format that would be ambiguous with that?) But that interpretation doesn't square too well with providing data like DW_AT_bit_size and DW_AT_bit_offset. So the interpretation is unclear to me. I don't remember this coming up; it may simply not have been considered. ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <4765FBC0.8020400@codesourcery.com>]
* Re: [LTO][PATCH] Fix long double precision problem [not found] ` <4765FBC0.8020400@codesourcery.com> @ 2007-12-17 21:53 ` Doug Kwan (關振德) 2007-12-18 4:29 ` Mark Mitchell 0 siblings, 1 reply; 24+ messages in thread From: Doug Kwan (關振德) @ 2007-12-17 21:53 UTC (permalink / raw) To: Mark Mitchell, gcc-patches; +Cc: Jim Blandy Would that easier and less error prone if we just emit the precision? I looked at the i386 and ia64 backend and found float types with precisions 32, 64, 80, 82 and 128. I am not sure if there is an easy way to do the search in an architecture-indepedent manner? -Doug 2007/12/16, Mark Mitchell <mark@codesourcery.com>: > That seems reasonable enough. I guess the LTO front end can process a > complex type by dividing its size by two, and then searching for a > matching integral or floating-point base type, and using that information. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LTO][PATCH] Fix long double precision problem 2007-12-17 21:53 ` Doug Kwan (關振德) @ 2007-12-18 4:29 ` Mark Mitchell 0 siblings, 0 replies; 24+ messages in thread From: Mark Mitchell @ 2007-12-18 4:29 UTC (permalink / raw) To: "Doug Kwan (關振德)"; +Cc: gcc-patches, Jim Blandy Doug Kwan (éæ¯å¾·) wrote: > Would that easier and less error prone if we just emit the precision? > I looked at the i386 and ia64 backend and found float types with > precisions 32, 64, 80, 82 and 128. I am not sure if there is an easy > way to do the search in an architecture-indepedent manner? You could look at how things like type_for_mode/type_for_size (sp?) are implemented. I don't think we can easily go by the names of the types, since the "same type" will have different names in C, Ada, and Fortran for example. But, I think we're trying too hard for complex types, right at the moment. The bit_offset/bit_size thing is right for ordinary floating point types and we should be able to handle that easily. My guess is that for complex types we could add DW_AT_GNU_real_type that indicates which base type is in use. Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2007-12-18 4:07 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-12-05 7:05 [LTO][PATCH] Fix long double precision problem Doug Kwan (關振德) 2007-12-05 10:52 ` Andrew Pinski 2007-12-05 12:55 ` Kenneth Zadeck 2007-12-05 14:56 ` Diego Novillo 2007-12-05 16:28 ` Doug Kwan (關振德) 2007-12-05 19:02 ` Andrew Pinski 2007-12-05 16:34 ` Mark Mitchell 2007-12-05 18:42 ` Doug Kwan (關振德) 2007-12-05 19:01 ` Doug Kwan (關振德) 2007-12-05 23:52 ` Mark Mitchell 2007-12-11 23:15 ` Doug Kwan (關振德) 2007-12-12 9:22 ` Mark Mitchell 2007-12-12 20:23 ` Doug Kwan (關振德) 2007-12-12 20:45 ` Mark Mitchell 2007-12-13 2:27 ` Doug Kwan (關振德) 2007-12-13 11:02 ` Andreas Schwab 2007-12-13 19:13 ` Doug Kwan (關振德) 2007-12-14 9:50 ` Andreas Schwab 2007-12-14 22:18 ` Doug Kwan (關振德) 2007-12-13 20:11 ` Jim Blandy 2007-12-13 20:40 ` Doug Kwan (關振德) 2007-12-13 22:43 ` Jim Blandy [not found] ` <4765FBC0.8020400@codesourcery.com> 2007-12-17 21:53 ` Doug Kwan (關振德) 2007-12-18 4:29 ` Mark Mitchell
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).