Re: [RFC] MAINTAINERS: require a BZ account field
Hi, "Richard Earnshaw (lists)" writes: > On 24/06/2024 23:34, Arsen Arsenović via Gcc wrote: >> Hi, >> >> Sam James via Gcc writes: >> >>> Hi! >>> >>> This comes up in #gcc on IRC every so often, so finally >>> writing an RFC. >>> >>> What? >>> --- >>> >>> I propose that MAINTAINERS be modified to be of the form, >>> adding an extra field for their GCC/sourceware account: >>> >> sourceware account> >>> Joe Bloggsjoeblo...@example.com jblo...@gcc.gnu.org >>> >>> Further, that the field must not be blank (-> must have a BZ account; >>> there were/are some without at all)! >>> >>> Why? >>> --- >>> >>> 1) This is tied to whether or not people should use their committer email >>> on Bugzilla or a personal email. A lot of people don't seem to use their >>> committer email (-> no permissions) and end up not closing bugs, so >>> pinskia (and often myself these days) end up doing it for them. >>> >>> 2) It's standard practice to wish to CC the committer of a bisect result >>> - or to CC someone who you know wrote patches on a subject area. Doing >>> this on Bugzilla is challenging when there's no map between committer >>> <-> BZ account. >>> >>> Specifically, there are folks who have git committer+author as >>> joeblo...@example.com (or maybe even coold...@example.com) where the >>> local part of the address has *no relation* to their GCC/sw account, >>> so finding who to CC is difficult without e.g. trawling through gcc-cvs >>> mails or asking overseers for help. >> >> I was also proposing (and would like to re-air that here) enforcing that >> the committer field of each commit is a (valid) @gcc.gnu.org email. >> This can be configured repo-locally via: >> >> $ git config committer.email @gcc.gnu.org >> >> Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d >> (v2.22.0). >> >> This makes a permanent association of each commit to its authors >> Sourceware account. >> >> This should not inhibit pushes, as the committer should be a reflection >> of who /applied/ a patch, and anyone applying a patch that can also push >> has a Sourceware account. It also should not inhibit any workflow, as >> it should be automatic. > > > I think this presumes a strict 'git apply' model for incorporating patches > from > mailing lists, but what about contributors who do not have a sourceware > account > and rely on another developer to fetch from their tree and push it afterwards > (eg the linux bubble-up model)? In that case the patch fetched will show the > original author as the committer. Right - that is a problem that I didn't think of.. A soft requirement is better here for that reason. Thanks for pointing it out. -- Arsen Arsenović signature.asc Description: PGP signature
Re: [RFC] MAINTAINERS: require a BZ account field
"Richard Earnshaw (lists)" writes:
> On 25/06/2024 20:08, Arsen Arsenović via Gcc wrote:
>> Hi,
>>
>> Richard Biener writes:
>>
>>> [snip]
I was also proposing (and would like to re-air that here) enforcing
that the committer field of each commit is a (valid) @gcc.gnu.org
email. This can be configured repo-locally via:
$ git config committer.email @gcc.gnu.org
Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d
(v2.22.0).
This makes a permanent association of each commit to its authors
Sourceware account.
>>>
>>> I'd welcome this - care to create a patch for
>>> contrib/gcc-git-customization.sh?
>>
>> Sure - I've attached a partial patch. I didn't find the hook which runs
>> on each push to check commits, so the current patch is minimal. Is that
>> also in the tree? I could try hacking it to check commits.
>
> This won't work for developers who don't have a gcc account. Previously it
> didn't matter what you said here, but now it will mess up any personal tree
> you have.
>
> +git config "committer.email" "${remote_id}@gcc.gnu.org"
You're right - I will add a prompt before pushing (should that even
happen).
--
Arsen Arsenović
signature.asc
Description: PGP signature
Ccccc. C. C.
x CC from my iPhone
DW_TAG_compile_unit's references to .debug_line and .loc directive extension
I have noticed that Meta Platforms folks have a proposal to extend the
.loc directive
https://discourse.llvm.org/t/rfc-extending-llvm-mc-loc-directive-with-labeling-support/79608
.
I filed https://sourceware.org/bugzilla/show_bug.cgi?id=31955 ("gas:
Extend .loc directive to emit a label") and am sending this message in
case there are interest/opinions.
For your convenience, the gas documentation is at
https://sourceware.org/binutils/docs/as/Loc.html
> The .loc directive will add a row to the .debug_line line number matrix
> corresponding to the immediately following assembly instruction.
Here is my summary of their proposal:
Clang will add a new debug mode to emit a DW_AT_LLVM_stmt_sequence
attribute to each DW_TAG_subprogram DIE, referencing the start of a
line number program sequence associated with the subprogram.
(https://discourse.llvm.org/t/rfc-new-dwarf-attribute-for-symbolication-of-merged-functions/79434)
```
main:
.loc 0 1 13 debug_line_label .Lmain_line_entries
...
.section .debug_info,"",@progbits
...
.byte 1 # Abbrev [1] 0xc:0x78
DW_TAG_compile_unit
.long .Lline_table_start0 # DW_AT_stmt_list
...
.byte 14 # Abbrev [14]
DW_TAG_subprogram
...
.long .Lmain_line_entries - .Lline_table_start0# DW_AT_LLVM_stmt_sequence
.section.debug_line,"",@progbits # generated
.Lline_table_start0:
# Conceptually, the .Lmain_line_entries label is emitted at start of a
line number program sequence associated with `main`
```
Advantages.
*Faster symbolization*
Traditional address symbolization involves locating the
DW_TAG_compile_unit DIE and parsing the line number program from the
DW_AT_stmt_list offset.
This process requires skipping unrelated DW_TAG_subprogram DIEs. The
DW_AT_LLVM_stmt_sequence attribute directly points to the relevant
line number program sequence, eliminating unnecessary steps.
*Improved ICF disambiguating*
Identical Code Folding (ICF) can make two line number program
sequences (associated with folded subprograms) indistinguishable.
While DW_AT_LLVM_stmt_sequence doesn't resolve this, it identifies the
associated function. If the caller is known, this additional
information could help disambiguate the correct sequence.
---
ELF/COFF -fno-function-sections and Mach-O .subsections_via_symbols
allow consecutive functions to share the same line number program
sequence.
To utilize DW_AT_LLVM_stmt_sequence better, the sequences should be
split to resemble ELF/COFF -ffunction-sections.
Mach-O doesn't have -ffunction-sections -fno-function-sections
differences and normally needs very few relocations for .debug_line
and the new mode will introduce more like ELF/COFF
-ffunction-sections.
Re: [RFC] MAINTAINERS: require a BZ account field
Sam James via Gcc writes: > Hi! > > This comes up in #gcc on IRC every so often, so finally > writing an RFC. > > What? > --- > > I propose that MAINTAINERS be modified to be of the form, > adding an extra field for their GCC/sourceware account: >account> > Joe Bloggsjoeblo...@example.com jblo...@gcc.gnu.org > > Further, that the field must not be blank (-> must have a BZ account; > there were/are some without at all)! > > Why? > --- > > 1) This is tied to whether or not people should use their committer email > on Bugzilla or a personal email. A lot of people don't seem to use their > committer email (-> no permissions) and end up not closing bugs, so > pinskia (and often myself these days) end up doing it for them. > > 2) It's standard practice to wish to CC the committer of a bisect result > - or to CC someone who you know wrote patches on a subject area. Doing > this on Bugzilla is challenging when there's no map between committer > <-> BZ account. > > Specifically, there are folks who have git committer+author as > joeblo...@example.com (or maybe even coold...@example.com) where the > local part of the address has *no relation* to their GCC/sw account, > so finding who to CC is difficult without e.g. trawling through gcc-cvs > mails or asking overseers for help. > > Summary > --- > > TL;DR: The proposal is: > > 1) MAINTAINERS should list a field containing either the gcc.gnu.org > email in full, or their gcc username (bikeshedding semi-welcome); > > 2) It should become a requirement that to be in MAINTAINERS, one must > possess a Bugzilla account (ideally using their gcc.gnu.org email). How about the attached as a compromise? (gzipped as a poor protection against scraping.) It adds the gcc.gnu.org/bugzilla account name, without the @gcc.gnu.org, as a middle column to the Write After Approval section. I think this makes it clear that the email specified in the last column should be used for communication. It's awkward to add a new column to the area maintainer section, so this version also reverses the policy of removing entries from Write After Approval if they appear in a more specific section. I've also committed heresy and replaced the tabs with spaces. The account names are taken from the gcc-cvs archives (thanks to Andrew for the hint to look there). I've tried to make the process relatively conservative, in the hope of avoiding false positives or collisions. A handful of entries were derived manually. There were four that I couldn't find easily (search for " - "). James Norris had an entry without an email address. I've left that line alone. If this is OK, I'll need to update check-MAINTAINERS.py. Thanks, Richard MAINTAINERS.gz Description: application/gzip
gcc-12-20240704 is now available
Snapshot gcc-12-20240704 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20240704/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision cdeb7ce83f71d1527626975e70d294ef55535d03 You'll find: gcc-12-20240704.tar.xz Complete GCC SHA256=428e91dc94db5b8313315f7e23302d744a0f9a3317175b374bc3f376803d16f5 SHA1=3b5cd72fb8a846864db859aa5552b00b492233d1 Diffs from 12-20240627 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
