Re: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d

[Ron Brender via Dwarf-discuss]

It appears that DW_LNAME_HIP, proposed in 230120.4,  never got incorporated
into the DWARF working document (so there is no duplication). Perhaps
because the Issue status is "Code Assigned" rather than Approved. That
status really only applies to the V5 code assignment actually.

Anyway, I'll fix it for V6.

The next available code is 0x0027. What makes you think the code should be
0x0029?

Ron


On Tue, Apr 23, 2024 at 8:06 PM Adrian Prantl via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> # Error: Duplicate DW_AT_LNAME 1d
>
> ## Overview
>
> The list of DWARF Version 6 Language and Version Codes double-assigns the
> DW_AT_LNAME code 0x001d to "HIP" and "Assembly".
>
> ## Proposed Changes
>
> Reassign HIP to 0x0029.
>
> ## References
>
> https://dwarfstd.org/languages-v6.html
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d

[Adrian Prantl via Dwarf-discuss]

> On Apr 24, 2024, at 5:46 AM, Ron Brender  wrote:
> 
> It appears that DW_LNAME_HIP, proposed in 230120.4,  never got incorporated 
> into the DWARF working document (so there is no duplication). Perhaps because 
> the Issue status is "Code Assigned" rather than Approved. That status really 
> only applies to the V5 code assignment actually.
> 
> Anyway, I'll fix it for V6.
> 
> The next available code is 0x0027. What makes you think the code should be 
> 0x0029?

I was looking at https://dwarfstd.org/languages-v6.html where the last assigned 
langiage is DW_LNAME_Hylo 0x0028.

-- adrian

> 
> Ron
> 
> 
> On Tue, Apr 23, 2024 at 8:06 PM Adrian Prantl via Dwarf-discuss 
> mailto:dwarf-discuss@lists.dwarfstd.org>> 
> wrote:
>> # Error: Duplicate DW_AT_LNAME 1d
>> 
>> ## Overview
>> 
>> The list of DWARF Version 6 Language and Version Codes double-assigns the 
>> DW_AT_LNAME code 0x001d to "HIP" and "Assembly".
>> 
>> ## Proposed Changes
>> 
>> Reassign HIP to 0x0029.
>> 
>> ## References
>> 
>> https://dwarfstd.org/languages-v6.html
>> 
>> -- 
>> Dwarf-discuss mailing list
>> Dwarf-discuss@lists.dwarfstd.org 
>> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d

[Cary Coutant via Dwarf-discuss]

>
> It appears that DW_LNAME_HIP, proposed in 230120.4,  never got
> incorporated into the DWARF working document (so there is no duplication).
> Perhaps because the Issue status is "Code Assigned" rather than Approved.
> That status really only applies to the V5 code assignment actually.
>
> Anyway, I'll fix it for V6.
>
> The next available code is 0x0027. What makes you think the code should be
> 0x0029?
>
>
> I was looking at https://dwarfstd.org/languages-v6.html where the last
> assigned langiage is DW_LNAME_Hylo 0x0028.
>

DW_LANG_HIP/DW_LNAME_HIP was assigned first, but for some reason, the list
was out of order, so when I assigned DW_LNAME_Assembly, it looked like
0x001c was the last code assigned. I think it would be safer to reassign
DW_LNAME_Assembly as 0x0029.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d

[Cary Coutant via Dwarf-discuss]

>
>
> It appears that DW_LNAME_HIP, proposed in 230120.4,  never got
> incorporated into the DWARF working document (so there is no duplication).
> Perhaps because the Issue status is "Code Assigned" rather than Approved.
> That status really only applies to the V5 code assignment actually.
>

I've been following Michael's protocol of using the status "Language Code
Assigned" for new language codes, where no committee discussion is
necessary. Would it help your process if I added the word "Accepted" to the
issue status?

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d

[Ron Brender via Dwarf-discuss]

Cary,

Actually, it would help my process if you would announce at each meeting
what language names and their corresponding issue numbers were processed in
the prior period. The point is to get that information into the Minutes. No
discussion needed, just an announcement. Actually if that information is
presented in the Agenda for a meeting that would probably suffice, although
it is the minutes that should be complete and definitive.

Thanks,
Ron


On Wed, Apr 24, 2024 at 12:30 PM Cary Coutant  wrote:

>
>> It appears that DW_LNAME_HIP, proposed in 230120.4,  never got
>> incorporated into the DWARF working document (so there is no duplication).
>> Perhaps because the Issue status is "Code Assigned" rather than Approved.
>> That status really only applies to the V5 code assignment actually.
>>
>
> I've been following Michael's protocol of using the status "Language Code
> Assigned" for new language codes, where no committee discussion is
> necessary. Would it help your process if I added the word "Accepted" to the
> issue status?
>
> -cary
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d

[Ron Brender via Dwarf-discuss]

Cary,

>DW_LANG_HIP/DW_LNAME_HIP was assigned first, but for some reason, the list
was out of order, so when I assigned >DW_LNAME_Assembly, it looked like
0x001c was the last code assigned. I think it would be safer to reassign
>DW_LNAME_Assembly as 0x0029.

I think it would be safer to just leave well-enough alone. I just updated
the document to match the website (and make DW_LNAME_HIP = 0x0029). So any
change causes work for me. Similarly it creates work for anyone who is
actually trying to use code DW_LNAME_Assembly. Why bother?

Ron




On Wed, Apr 24, 2024 at 12:25 PM Cary Coutant  wrote:

> It appears that DW_LNAME_HIP, proposed in 230120.4,  never got
>> incorporated into the DWARF working document (so there is no duplication).
>> Perhaps because the Issue status is "Code Assigned" rather than Approved.
>> That status really only applies to the V5 code assignment actually.
>>
>> Anyway, I'll fix it for V6.
>>
>> The next available code is 0x0027. What makes you think the code should
>> be 0x0029?
>>
>>
>> I was looking at https://dwarfstd.org/languages-v6.html where the last
>> assigned langiage is DW_LNAME_Hylo 0x0028.
>>
>
> DW_LANG_HIP/DW_LNAME_HIP was assigned first, but for some reason, the list
> was out of order, so when I assigned DW_LNAME_Assembly, it looked like
> 0x001c was the last code assigned. I think it would be safer to reassign
> DW_LNAME_Assembly as 0x0029.
>
> -cary
>
>
>
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

[Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics

[Adrian Prantl via Dwarf-discuss]

# C standard release dates for DW_AT_language_version, clarify semantics

## Background

The list of languages at https://dwarfstd.org/languages-v6.html does not list 
release dates for the ISO C standard. Producers need to know what version 
numbers they should produce though. I scanned the ISO website for appropriate 
dates to use.

## Proposed Changes

Augment the table of language encodings to add
C (K&R and ISO) DW_LNAME_C 0x0003 0 MM 

K&R 00
C89 198912
C99 199912
C11 201112
C17 201806 (sic!)
C2x >201806

Add the following non-normative wording: 

To convert a version number to a specific release, it is good practice to treat 
the YYYMM version numbers listed in this document as the maximum version that 
is interpreted as belonging to a specific release. This way consumers can emit 
version numbers for unreleased upcoming specifications, by using, e.g., the 
date the compiler was built.

## Dependencies

Issue 210419.1 

## References

https://iso-9899.info/wiki/The_Standard

C89: https://www.iso.org/standard/17782.html
C99: https://www.iso.org/standard/29237.html
C11: https://www.iso.org/standard/57853.html
C17: https://www.iso.org/standard/74528.html

https://dwarfstd.org/languages-v6.html
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

[Dwarf-discuss] Proposal: Add versioning scheme for Fortran

[Adrian Prantl via Dwarf-discuss]

# Add versioning scheme for Fortran

## Background

The list of languages at https://dwarfstd.org/languages-v6.html does not list a 
versioning scheme for Fortran, but we have DWARF 5 language constants for 
FORTRAN77 through Fortran08.

## Proposed Changes

Augment the table of language encodings to add `` to Fortran as a version 
scheme.

## Dependencies

Issue 210419.1 

## References

https://dwarfstd.org/languages-v6.html

-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics

[Adrian Prantl via Dwarf-discuss]

The back story here is that I am trying to implement the new language 
attributes in LLVM, which is why I'm finding all these bugs, omissions, and 
ambiguities:

https://github.com/llvm/llvm-project/pull/89980

cheers,
Adrian

> On Apr 24, 2024, at 2:25 PM, Adrian Prantl via Dwarf-discuss 
>  wrote:
> 
> # C standard release dates for DW_AT_language_version, clarify semantics
> 
> ## Background
> 
> The list of languages at https://dwarfstd.org/languages-v6.html does not list 
> release dates for the ISO C standard. Producers need to know what version 
> numbers they should produce though. I scanned the ISO website for appropriate 
> dates to use.
> 
> ## Proposed Changes
> 
> Augment the table of language encodings to add
> C (K&R and ISO) DW_LNAME_C 0x0003 0 MM 
> 
> K&R 00
> C89 198912
> C99 199912
> C11 201112
> C17 201806 (sic!)
> C2x >201806
> 
> Add the following non-normative wording: 
> 
> To convert a version number to a specific release, it is good practice to 
> treat the YYYMM version numbers listed in this document as the maximum 
> version that is interpreted as belonging to a specific release. This way 
> consumers can emit version numbers for unreleased upcoming specifications, by 
> using, e.g., the date the compiler was built.
> 
> ## Dependencies
> 
> Issue 210419.1 
> 
> ## References
> 
> https://iso-9899.info/wiki/The_Standard
> 
> C89: https://www.iso.org/standard/17782.html
> C99: https://www.iso.org/standard/29237.html
> C11: https://www.iso.org/standard/57853.html
> C17: https://www.iso.org/standard/74528.html
> 
> https://dwarfstd.org/languages-v6.html
> -- 
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics

[Jakub Jelinek via Dwarf-discuss]

On Wed, Apr 24, 2024 at 02:25:37PM -0700, Adrian Prantl via Dwarf-discuss wrote:
> # C standard release dates for DW_AT_language_version, clarify semantics
> 
> ## Background
> 
> The list of languages at https://dwarfstd.org/languages-v6.html does not list 
> release dates for the ISO C standard. Producers need to know what version 
> numbers they should produce though. I scanned the ISO website for appropriate 
> dates to use.
> 
> ## Proposed Changes
> 
> Augment the table of language encodings to add
> C (K&R and ISO) DW_LNAME_C 0x0003 0 MM 
> 
> K&R 00
> C89 198912
> C99 199912
> C11 201112
> C17 201806 (sic!)
> C2x >201806

That is not correct.
C99 199901
C11 201112
C17 201710
C23 202311

C89 with ammendment 1 would be
199409
C89 likely that 198912 indeed.

As for C++, the above page is missing
C++23 202302
> 
> Add the following non-normative wording: 
> 
> To convert a version number to a specific release, it is good practice to 
> treat the YYYMM version numbers listed in this document as the maximum 
> version that is interpreted as belonging to a specific release.

> This way consumers can emit version numbers for unreleased upcoming 
> specifications, by using, e.g., the date the compiler was built.

That is not a good suggestion.
If a compiler supports some part of e.g. C23 but not everything, it should
be something larger than 201710 but smaller than 202311, even when the date
the compiler was built could be 202404 or later.
GCC and Clang up to 17 used e.g. 202000 for C23 partial implementations,
GCC still does, Clang 18+ now uses 202311.

Jakub

-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics

[Adrian Prantl via Dwarf-discuss]

> On Apr 24, 2024, at 2:49 PM, Jakub Jelinek  wrote:
> 
> On Wed, Apr 24, 2024 at 02:25:37PM -0700, Adrian Prantl via Dwarf-discuss 
> wrote:
>> # C standard release dates for DW_AT_language_version, clarify semantics
>> 
>> ## Background
>> 
>> The list of languages at https://dwarfstd.org/languages-v6.html does not 
>> list release dates for the ISO C standard. Producers need to know what 
>> version numbers they should produce though. I scanned the ISO website for 
>> appropriate dates to use.
>> 
>> ## Proposed Changes
>> 
>> Augment the table of language encodings to add
>> C (K&R and ISO) DW_LNAME_C 0x0003 0 MM 
>> 
>> K&R 00
>> C89 198912
>> C99 199912
>> C11 201112
>> C17 201806 (sic!)
>> C2x >201806
> 
> That is not correct.
> C99 199901
> C11 201112
> C17 201710
> C23 202311

Thanks for correcting these! Do you happen to have a link to the source you 
used to look these up?

> 
> C89 with ammendment 1 would be
> 199409
> C89 likely that 198912 indeed.
> 
> As for C++, the above page is missing
> C++23 202302
>> 
>> Add the following non-normative wording: 
>> 
>> To convert a version number to a specific release, it is good practice to 
>> treat the YYYMM version numbers listed in this document as the maximum 
>> version that is interpreted as belonging to a specific release.
> 
>> This way consumers can emit version numbers for unreleased upcoming 
>> specifications, by using, e.g., the date the compiler was built.
> 
> That is not a good suggestion.
> If a compiler supports some part of e.g. C23 but not everything, it should
> be something larger than 201710 but smaller than 202311, even when the date
> the compiler was built could be 202404 or later.
> GCC and Clang up to 17 used e.g. 202000 for C23 partial implementations,
> GCC still does, Clang 18+ now uses 202311.

That is what I had in mind, but I didn't think about a compiler built after a 
standard was released. Do you have a suggestion for a better wording to capture 
that nuance?

thanks,
Adrian

> 
> Jakub


-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics

[Jakub Jelinek via Dwarf-discuss]

On Wed, Apr 24, 2024 at 02:57:17PM -0700, Adrian Prantl wrote:
> 
> 
> > On Apr 24, 2024, at 2:49 PM, Jakub Jelinek  wrote:
> > 
> > On Wed, Apr 24, 2024 at 02:25:37PM -0700, Adrian Prantl via Dwarf-discuss 
> > wrote:
> >> # C standard release dates for DW_AT_language_version, clarify semantics
> >> 
> >> ## Background
> >> 
> >> The list of languages at https://dwarfstd.org/languages-v6.html does not 
> >> list release dates for the ISO C standard. Producers need to know what 
> >> version numbers they should produce though. I scanned the ISO website for 
> >> appropriate dates to use.
> >> 
> >> ## Proposed Changes
> >> 
> >> Augment the table of language encodings to add
> >> C (K&R and ISO) DW_LNAME_C 0x0003 0 MM 
> >> 
> >> K&R 00
> >> C89 198912
> >> C99 199912
> >> C11 201112
> >> C17 201806 (sic!)
> >> C2x >201806
> > 
> > That is not correct.
> > C99 199901
> > C11 201112
> > C17 201710
> > C23 202311
> 
> Thanks for correcting these! Do you happen to have a link to the source you 
> used to look these up?

E.g. the C23 standard?
M.2 Fifth Edition
Major changes in this fifth edition (__STDC_VERSION__ 202311L) include:
...
M.3 Fourth Edition
There were no major changes in the fourth edition (__STDC_VERSION__ 201710L), 
only technical
corrections and clarifications.
M.4 Third Edition
Major changes in the third edition (__STDC_VERSION__ 201112L) included:
...
M.5 Second Edition
Major changes in the second edition (__STDC_VERSION__ 199901L) included:
...
M.6 First Edition, Amendment 1
Major changes in the amendment to the first edition (__STDC_VERSION__ 199409L) 
included:

The intent is for C versions which do have __STDC_VERSION__ to match that
macro, similarly for C++ versions which do have __cplusplus macro of the
MM form to match that macro.  The dates in there are when the standard
has been voted in (usually it takes then a few months to get officially
released as ISO standard).

> >> This way consumers can emit version numbers for unreleased upcoming 
> >> specifications, by using, e.g., the date the compiler was built.
> > 
> > That is not a good suggestion.
> > If a compiler supports some part of e.g. C23 but not everything, it should
> > be something larger than 201710 but smaller than 202311, even when the date
> > the compiler was built could be 202404 or later.
> > GCC and Clang up to 17 used e.g. 202000 for C23 partial implementations,
> > GCC still does, Clang 18+ now uses 202311.
> 
> That is what I had in mind, but I didn't think about a compiler built after a 
> standard was released. Do you have a suggestion for a better wording to 
> capture that nuance?

Compilers should simply choose some number which will be known to be later
than the latest released standards and expected to be smaller than the
upcoming standard.  E.g. using  of the last standard + 1 and MM of 00
is a good practice, but DWARF shouldn't enforce that.
Consumers aware of just C17 release should simply check for 201710 if
testing about exactly C17, or > 201710 if testing for something later than
that.

Jakub

-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss