On Mon, Jan 24, 2022 at 09:43:07PM -0500, John Reagan wrote:
> Yes, on OpenVMS we have 2 32-bit floats (VAX f_float, IEEE s_float), 3
> 64-bit floats (VAX d_float, VAX g_float, IEEE t_float), and 1 128-bit
> float (IEEE x_float). We had a 2nd 128-bit float back on the VAX but we
> don't support th
John Reagan tells me his message didn't go to the list,
but Jakub quotes it in his reply. My comments below.
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, January 25, 2022 7:10 AM
> To: John Reagan
> Cc: Robinson, Paul ; ja...@redhat.com; dwarf-
> disc...@lists.dwarfstd.or
On Tue, Jan 25, 2022 at 01:55:40PM +, paul.robin...@sony.com wrote:
> > If s_float and f_float or t_float and g_float coexist on the same platform
> > in the same ABI, I'm afraid DW_AT_precision to distinguish between them,
>
> Did you mean, DW_AT_precision isn't enough to distinguish between
For the sake of history, I don't recall much of the technical issues, but I
do recall working with Paul way back when (we were both with HP at the
time) to come up with a single common HP-wide list of base types and codes
for all the floating-point types in use across HP.
I support Paul's suggesti
>
> For ATE codes, the problem is with standardization if we wanted
> to standardize it in some way for DWARF6.
> The current DW_ATE_{,complex_}float is way too unspecific and historically
> can be about various formats.
> So, we'd need something like DW_ATE_{,complex_}ieee754_float
> (or ieee754_
On Mon, Jan 24, 2022 at 5:37 PM Adrian Prantl wrote:
>
>
> On Jan 23, 2022, at 2:53 PM, David Blaikie wrote:
>
> A rather common "quality of implementation" issue seems to be lambda
> naming.
>
> I came across this due to non-canonicalization of lambda names in template
> parameters depending on
> On Jan 23, 2022, at 2:53 PM, David Blaikie wrote:
>
> A rather common "quality of implementation" issue seems to be lambda naming.
>
> I came across this due to non-canonicalization of lambda names in template
> parameters depending on how a source file is named in Clang, and GCC's seem
>
