Re: Improvement of CLOBBER descriptions
On 2/21/24 10:43, Michael Matz wrote:
Hello,
On Wed, 21 Feb 2024, Daniil Frolov wrote:
Following the recent introduction of more detailed CLOBBER types in GCC, a
minor inconsistency has been identified in the description of
CLOBBER_OBJECT_BEGIN:
/* Beginning of object lifetime, e.g. C++ constructor. */
CLOBBER_OBJECT_BEGIN
The "e.g." comment mixes concepts of the C++ language with a
middle-end/GIMPLE concept, and hence is a bit misleading. What the
clobbers are intended to convey to the middle-end is the low-level notion
of "storage associated with this and that object is now accessible
(BEGIN)/not accessible anymore (END), for purposes related to that very
object". The underlying motivation, _why_ that knowledge is interesting
to the middle-end, is to be able to share storage between different
objects.
"purposes related to that object" are any operations on the object:
construction, destruction, access, frobnification. It's not tied to a
particular frontend language (although it's the language semantics that
dictate when emitting the begin/end clobbers is appropriate). For the
middle-end the C++ concept of construction/deconstruction are simply
modifications (conceptual or real) of the storage associated with an
object ("object" not in the C++ sense, but from a low-level perspective;
i.e. an "object" doesn't only exist after c++-construction, it comes into
existence before that, even if perhaps in an indeterminate/invalid state
from the frontends perspective).
Initially these clobbers were only emitted when decls went ouf of
scope, and so did have some relation to frontend language semantics
(although a fairly universal one, namely "scope"). The
C++ frontend then found further uses (e.g. after a dtor for an
object _ends_ it's storage can also be reused), and eventually we also
needed the BEGIN clobbers to convey the meaning of "now storage use for
object potentially starts, don't share it with any other object".
If certain frontends find use for more fine-grained definitions of
life-times, then further note kinds need to be invented for those
frontends use. They likely won't have influence on the middle-end though
(perhaps for some sanitizers such new kinds might be useful?). But the
current BEGIN/END clobbers need to continue to mark the outermost borders
of storage validity for an object.
Yes. The current uses of CLOBBER_OBJECT_* also include the period of
construction/destruction, and we should clarify that in the comment,
including avoiding the word "lifetime".
Or perhaps they could just be CLOBBER_STORAGE_*, though that would also
be imprecise, since in various cases the storage duration of an object
can be longer than beginning of construction to end of destruction; if I
repeatedly construct and destroy objects in the same storage, I would
like to have clobbers to indicate the boundaries between them.
But still, I don't think it's useful to distinguish between the two:
what we want is clobbers to indicate the beginning and end of the use of
storage to represent a particular object. We don't need a clobber to
tell the middle-end when storage begins and ends, it can work that out
for itself, based in part on when individual objects begin and end.
So, my inclination is to remove STORAGE_* in favor of OBJECT_* and
adjust the misleading comments for the latter.
As Michael says, emitting a clobber at the end of the constructor or
beginning of the destructor seems inappropriate, as all clobbers
indicate that the target does not have a meaningful value at that point.
Probably better to use some front-end-local representation that gets
discarded by genericize.
Jason
GCC has been accepted as GSoC 2024 mentoring organization
Hello everyone, I am pleased that I can announce that we have been accepted to be a GSoC mentoring organization also in 2024!. This also means that students are now really starting to look at our idea page and so if anyone wants to add a project, it is still possible but we should not delay it much longer. Thanks to everyone who helped me with this so far. I am very happy that we'll get this chance to attract new contributors this year too. Martin On Mon, Jan 15 2024, Martin Jambor wrote: > Hello, > > another year has passed, Google has announced there will be again Google > Summer of Code (GsoC) in 2024 and the deadline for organizations to > apply is already approaching (February 6th). I'd like to volunteer to > be the main org-admin for GCC again but let me know if you think I > shouldn't or that someone else should or if you want to do it instead. > Otherwise I'll assume that I will and I hope that I can continue to rely > on David Edelsohn and Thomas Schwinge to back me up and help me with > some decision making along the way as my co-org-admins. > > The most important bit: > > I would like to ask all (moderately) seasoned GCC contributors to > consider mentoring a contributor this year and ideally also come up with > a project that they would like to lead. I'm collecting proposal on our > wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours > to the top list there. Or, if you are unsure, post your offer and > project idea as a reply here to the mailing list. > > Additionally, if you have added an idea to the list in the recent years, > please review it whether it is still up-to-date or needs adjusting or > should be removed altogether. > > = > > At this point, we need to collect list of project ideas. Eventually, > each listed project idea should have: > > a) a project title, > b) more detailed description of the project (2-5 sentences), > c) expected outcomes (we do have a catch-almost-all formulation that > outcome is generally patches at the bottom of the list on the > wiki), > d) skills required/preferred, > e) project size - whether it is expected to take approximately 350, > 175 or just 90 hours (the last option in new in 2024, see below), > f) difficulty (easy, hard or medium, but we don't really have easy > projects), and > g) expected mentors. > > Project ideas that come without an offer to also mentor them are always > fun to discuss, by all means feel free to reply to this email with yours > and I will attempt to find a mentor, but please be aware that we can > only use the suggestion it if we actually find one or ideally two. > > Everybody in the GCC community is invited to go over > https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or > otherwise bad project suggestions and help improve viable ones. > > Finally, please continue helping (prospective) students figure stuff out > about GCC like you have always done in the past. > > As far as I know, GSoC 2024 should be quite similar to the last year, > the most important parameters probably are these: > > - Contributors (formerly students) must either be full-time students > or be "beginners to open source." > > - There are now three project sizes: roughly 90 hors (small), roughly > 175 hours (medium-sized) and roughly 350 hours (large) of work in > total. The small option is new this year but because our projects > usually have a lengthy learning period, I think we will usually want > to stick to the medium and large variants. > > - Timing should be pretty much as flexible as last year. The > recommended "standard" duration is 12 weeks but depending on > contributor's and mentor's needs and circumstances, projects can > take anywhere between 10 and 22 weeks. There will be one mid-term > and one final evaluation. > > For further details you can see: > > - The announcement of GSoC 2024: > > https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html > > - GSoC rules: > https://summerofcode.withgoogle.com/rules > > - The detailed GSoC 2024 timeline: > https://developers.google.com/open-source/gsoc/timeline > > - Elaborate project idea guidelines: > https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list > > Thank you very much for your participation and help. Let's hope we > attract some great contributors again this year. > > Martin
Legal assignment forms for GCC
I anticipate making contributions to GCC on an ongoing basis, and according to https://gcc.gnu.org/contribute.html, there are some forms that need to be filled out by me and my employer for ".assignment.for all future changes, and an employer disclaimer.". I hereby request those forms. Thanks very much, Bob Dubner
Re: Legal assignment forms for GCC
Hi Robert, On Thu, Feb 22, 2024 at 02:29:03PM -0600, Robert Dubner wrote: > I anticipate making contributions to GCC on an ongoing basis, and > according to https://gcc.gnu.org/contribute.html, there are some forms > that need to be filled out by me and my employer for ".assignment.for all > future changes, and an employer disclaimer.". > > I hereby request those forms. The request-assign.future form is here: https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future Please fill it out and email it to ass...@gnu.org More background information can be found here: https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/conditions.text Cheers, Mark
gcc-11-20240222 is now available
Snapshot gcc-11-20240222 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20240222/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision 7d1fc80ddf5912f1823d5a5b850d1a98fbe18ab5 You'll find: gcc-11-20240222.tar.xz Complete GCC SHA256=6b9711dafd50c5f0b3c8897a3f35115a6319a6581f83c74c2511e5084b2f223c SHA1=c591ed3e9438c3f1b390b56e2d34ef91953d4caa Diffs from 11-20240215 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 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.
