Re: Patches submission policy change
Hi Mark, On 4/4/24 23:35, Mark Wielaard wrote: Hi Christophe, On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon via Gdb wrote: TL;DR: For the sake of improving precommit CI coverage and simplifying workflows, I’d like to request a patch submission policy change, so that we now include regenerated files. This was discussed during the last GNU toolchain office hours meeting [1] (2024-03-28). Benefits or this change include: - Increased compatibility with precommit CI - No need to manually edit patches before submitting, thus the “git send-email” workflow is simplified - Patch reviewers can be confident that the committed patch will be exactly what they approved - Precommit CI can test exactly what has been submitted Any concerns/objections? I am all for it. It will make testing patches easier for everyone. I do think we still need a better way to make sure all generated files can be regenerated. If only to check that the files were generated correctly with the correct versions. The autoregen buildbots are able to catch some, but not all such mistakes. wrt to the mailinglists maybe getting larger patches, I think most will still be under 400K and I wouldn't raise the limit (because most such larger emails are really just spam). But we might want to get more mailinglist moderators. gcc-patches, binutils and gdb-patches all have only one moderator (Jeff, Ian and Thiago). It would probably be good if there were more. Any volunteers? It shouldn't be more than 1 to 3 emails a week (sadly most of them spam). I'm happy to help with moderation of any/all of these 3 lists. Thanks, Christophe Cheers, Mark
Re: Patches submission policy change
On Thu, 4 Apr 2024 at 10:12, Jan Beulich wrote: > > On 03.04.2024 15:11, Christophe Lyon wrote: > > On Wed, 3 Apr 2024 at 10:30, Jan Beulich wrote: > >> > >> On 03.04.2024 10:22, Christophe Lyon wrote: > >>> Dear release managers and developers, > >>> > >>> TL;DR: For the sake of improving precommit CI coverage and simplifying > >>> workflows, I’d like to request a patch submission policy change, so > >>> that we now include regenerated files. This was discussed during the > >>> last GNU toolchain office hours meeting [1] (2024-03-28). > >>> > >>> Benefits or this change include: > >>> - Increased compatibility with precommit CI > >>> - No need to manually edit patches before submitting, thus the “git > >>> send-email” workflow is simplified > >>> - Patch reviewers can be confident that the committed patch will be > >>> exactly what they approved > >>> - Precommit CI can test exactly what has been submitted > >>> > >>> Any concerns/objections? > >> > >> Yes: Patch size. And no, not sending patches inline is bad practice. > > Not sure what you mean? Do you mean sending patches as attachments is > > bad practice? > > Yes. It makes it difficult to reply to them (with proper reply context). Agreed. > > >> Even assuming sending patches bi-modal (inline and as attachment) works > >> (please indicate whether that's the case), it would mean extra work on > >> the sending side. > >> > > For the CI perspective, we use what patchwork is able to detect as patches. > > Looking at recent patches submissions, it seems patchwork is able to > > cope with the output of git format-patch/git send-email, as well as > > attachments. > > There are cases where patchwork is not able to detect the patch, but I > > don't know patchwork's exact specifications. > > Question was though: If a patch was sent inline plus attachment, what > would CI use as the patch to apply? IOW would it be an option to > attach the un-stripped patch, while inlining the stripped one? > Sorry, I don't know how patchwork would handle such a case. Thanks, Christophe > Jan >
[gimple-ssa] result_decl and ssa_name
Hi all,
I do have a question regarding ssa_name and result_decl.
For example on the following gimple function:
int f ()
{
int x;
int D.2747;
int _2;
:
x_1 = 42;
_2 = x_1;
:
:
return _2;
}
On the above example, using the macro SSA_NAME_VAR() on _2 does not
yield anything usable.
Neither to call ssa_default_def() on the result of the result_decl
obtain through macro DECL_RESULT().
Is there a way to get the ssa_name corresponding to the result_decl of a
function obtained through the use of macro DECL_RESULT() on a fn_decl?
And/or the other way around? I.e., from the returned ssa_name of a
function to the result_decl of that function?
I totally might be missing something here, but I cannot figure out what.
Thanks for your time,
Pierrick
Re: [gimple-ssa] result_decl and ssa_name
On Fri, Apr 5, 2024 at 1:59 PM Pierrick Philippe
wrote:
>
> Hi all,
>
> I do have a question regarding ssa_name and result_decl.
>
> For example on the following gimple function:
>
> int f ()
> {
> int x;
> int D.2747;
> int _2;
>
>:
> x_1 = 42;
> _2 = x_1;
>
>:
> :
> return _2;
>
> }
>
> On the above example, using the macro SSA_NAME_VAR() on _2 does not
> yield anything usable.
> Neither to call ssa_default_def() on the result of the result_decl
> obtain through macro DECL_RESULT().
>
> Is there a way to get the ssa_name corresponding to the result_decl of a
> function obtained through the use of macro DECL_RESULT() on a fn_decl?
> And/or the other way around? I.e., from the returned ssa_name of a
> function to the result_decl of that function?
>
> I totally might be missing something here, but I cannot figure out what.
DECL_RESULT isn't always used (as in your example). Not all SSA names
have corresponding declarations, we have "anonymous" SSA names which
have a NULL_TREE SSA_NAME_VAR (such as the _2 in your example).
What do you try to find in the end? If you want to find all returns you can
walk predecessors of EXIT_BLOCK and look at their last stmt whether they
are greturn statements.
Richard.
> Thanks for your time,
>
> Pierrick
>
Re: [GSoC] Application RFC + Question - GENERIC dump
On Tue, Apr 2, 2024 at 1:16 PM Richard Biener wrote: > > On Tue, Apr 2, 2024 at 11:14 AM Thor Preimesberger via Gcc > wrote: > > > > Forgot to CC the mailing list - mea culpa. > > > > -- Forwarded message - > > From: Thor Preimesberger > > Date: Tue, Apr 2, 2024 at 5:57 PM > > Subject: Re: [GSoC] Application RFC + Question - GENERIC dump > > To: Richard Biener > > > > > > Thanks for the quick feedback, especially on such short notice - I'll > > get the actual GSoC application in, within a couple of hours. > > > > > This looks like a reasonable timeline and overall project structure. I > > > probably > > > pointed to it in my responses to the initial patch but to repeat here > > > it would be > > > very nice to integrate with the existing GENERIC dumping in > > > tree-pretty-print.cc > > > That's what you get when calling 'debug_tree ()' from the inferior > > > inside > > > gdb. Implementation-wise the JSON target would then be a new > > > dump flag (see the various TDF_* in dumpfiles.h). > > > > Understood - To check my understanding, is it correct to say that we > > essentially want to parse the output of tree-pretty-print.cc into > > JSON? > > No, we want to emit JSON directly from tree-pretty-print.cc conditional > of the new dump flag. Thanks for uploading the proposal. Can you please update it to remove the confusion around "parsing of the tree-pretty-print.cc output"? As said we instead want to emit JSON directly from the GENERIC representation as it is in memory, preferably as an output variant to the existing tree-pretty-print.cc output to make it easy to keep both variants in sync. As for the timeline and way of development I would strongly suggest to develop the JSON -> html (or JSON -> graphviz if you like that more) translator in parallel to be able to incrementally verify the user consumed output is as desired. Unimplemented JSON bits can be always implemented as text JSON nodes containing the textual tree-pretty-print.cc output. One of the important goals is to have the JSON output functionality in tree-pretty-print.cc implemented in a maintainable way, making it easy to adjust JSON/non-JSON output when the data structures change. Thanks, Richard. > > Then, this parser then would be used in a new dump pass, from > > either inside gdb or from gcc itself, to dump the JSON wherever it > > needs to go. > > For the actual -fdump-generic-nodes we would call the dumper with the > new flag and likely have set up the output to a file. > > > So ultimately the idea is to create both the parser and a new dump pass > > from it. > > I don't think there's a parser involved, in the end we'd have to > "parse" the JSON > to produce HTML or graphviz output, but the JSON emission would be from > inside dump_generic_node (and sibliings), conditional on the dump flag. Note > that a lot of things will be dumped the same such as identifiers or constants, > but all structured bits would be different. > > Richard. > > > I just read the notes you gave on the original patch. I'll edit the > > plan a bit to emphasize interworking with tree-pretty-print, and > > checking the bugs that mention easyhack. > > > > Best, > > Thor Preimesberger > > > > > > On Tue, Apr 2, 2024 at 4:20 PM Richard Biener > > wrote: > > > > > > On Mon, Apr 1, 2024 at 6:23 PM Thor Preimesberger via Gcc > > > wrote: > > > > > > > > Hey all, > > > > > > > > I'm joining the group of people submitting their GSoC applications > > > > over the holiday. I'm interested in the "Implement structured dumping > > > > of GENERIC" project idea, and the application I've written is below. > > > > > > Thank you for the interest in this project. > > > > > > > A quick question before though: > > > > > > > > - What would the expected use cases of the proposed > > > > -fdump-generic-nodes option be, in addition to, presumably, writing > > > > front ends into gcc? > > > > > > I think the main use case is better "visual" debugging and understanding > > > of GENERIC. Then a structured dumping would also allow to custom > > > processing like doing memory or other statistics. > > > > > > >I'm also curious about also targeting .gz/Graphviz; on a first > > > > blush, it doesn't seem like too much additional work, and it may be > > > > useful for the above applications. But I imagine there may be other > > > > ways to process the data that would ultimately be more useful. > > > > > > Reading your message top-down I think that dumping in a structured format > > > like > > > JSON would allow targeting graphviz as postprocessing. > > > > > > > Best, > > > > Thor Preimesberger > > > > > > > > > > > > > > > > > > > > Background: > > > > > > > > I'm an undergraduate student in pure mathematics who tinkers with > > > > technology in his free time. I've taken an interest in compilers as of > > > > last summer. I've written a couple of parsers, by hand, and a couple > > > > of toy passes in LLVM.
Re: [gimple-ssa] result_decl and ssa_name
On 05/04/2024 14:46, Richard Biener wrote:
> On Fri, Apr 5, 2024 at 1:59 PM Pierrick Philippe
> wrote:
>> Hi all,
>>
>> I do have a question regarding ssa_name and result_decl.
>>
>> For example on the following gimple function:
>>
>> int f ()
>> {
>> int x;
>> int D.2747;
>> int _2;
>>
>>:
>> x_1 = 42;
>> _2 = x_1;
>>
>>:
>> :
>> return _2;
>>
>> }
>>
>> On the above example, using the macro SSA_NAME_VAR() on _2 does not
>> yield anything usable.
>> Neither to call ssa_default_def() on the result of the result_decl
>> obtain through macro DECL_RESULT().
>>
>> Is there a way to get the ssa_name corresponding to the result_decl of a
>> function obtained through the use of macro DECL_RESULT() on a fn_decl?
>> And/or the other way around? I.e., from the returned ssa_name of a
>> function to the result_decl of that function?
>>
>> I totally might be missing something here, but I cannot figure out what.
> DECL_RESULT isn't always used (as in your example). Not all SSA names
> have corresponding declarations, we have "anonymous" SSA names which
> have a NULL_TREE SSA_NAME_VAR (such as the _2 in your example).
I see, that makes so much more sense to me now.
> What do you try to find in the end? If you want to find all returns you can
> walk predecessors of EXIT_BLOCK and look at their last stmt whether they
> are greturn statements.
I am implementing a state_machine within the analyzer, and I am trying
to understand where would be the best place to propagate the state of
the return value.
I intuitively thought it would be best to do so in the
state_machine::on_pop_frame() method, which is called by the analyzer
between the two frames of the caller and the callee. What I do have
access to is the struct function of the callee/caller, the gcall
instruction in the caller and the callee have been processed by my
analysis.
And to illustrate, here I do have the _2 ssa_name and its state which I
know in that case should be propagate to the lhs of the caller gcall
instruction.
Again I might be taking this in a wrong way.
> Richard.
>> Thanks for your time,
>>
>> Pierrick
Re: [GSoC] Application RFC + Question - GENERIC dump
Hello, On Fri, Apr 05 2024, Richard Biener via Gcc wrote: > On Tue, Apr 2, 2024 at 1:16 PM Richard Biener > wrote: >> >> On Tue, Apr 2, 2024 at 11:14 AM Thor Preimesberger via Gcc >> wrote: >> > >> > Forgot to CC the mailing list - mea culpa. >> > >> > -- Forwarded message - >> > From: Thor Preimesberger >> > Date: Tue, Apr 2, 2024 at 5:57 PM >> > Subject: Re: [GSoC] Application RFC + Question - GENERIC dump >> > To: Richard Biener >> > >> > >> > Thanks for the quick feedback, especially on such short notice - I'll >> > get the actual GSoC application in, within a couple of hours. >> > >> > > This looks like a reasonable timeline and overall project structure. I >> > > probably >> > > pointed to it in my responses to the initial patch but to repeat here >> > > it would be >> > > very nice to integrate with the existing GENERIC dumping in >> > > tree-pretty-print.cc >> > > That's what you get when calling 'debug_tree ()' from the inferior >> > > inside >> > > gdb. Implementation-wise the JSON target would then be a new >> > > dump flag (see the various TDF_* in dumpfiles.h). >> > >> > Understood - To check my understanding, is it correct to say that we >> > essentially want to parse the output of tree-pretty-print.cc into >> > JSON? >> >> No, we want to emit JSON directly from tree-pretty-print.cc conditional >> of the new dump flag. > > Thanks for uploading the proposal. Can you please update it to remove > the confusion around "parsing of the tree-pretty-print.cc output"? IIUC proposals cannot be altered past the Tuesday deadline. Still, they probably can clarified somewhat here even in the upcoming days (but really not much more than that), so that all involved parties are then not surprised if the project needs to take a slightly different direction (assuming it will be selected AND we get enough slots in the program from Google). Thanks, Martin > As > said we instead want to emit JSON directly from the GENERIC representation > as it is in memory, preferably as an output variant to the existing > tree-pretty-print.cc output to make it easy to keep both variants in sync. > > As for the timeline and way of development I would strongly suggest to > develop the JSON -> html (or JSON -> graphviz if you like that more) > translator in parallel to be able to incrementally verify the user consumed > output is as desired. Unimplemented JSON bits can be always > implemented as text JSON nodes containing the textual tree-pretty-print.cc > output. > > One of the important goals is to have the JSON output functionality > in tree-pretty-print.cc implemented in a maintainable way, making it > easy to adjust JSON/non-JSON output when the data structures change. > > Thanks, > Richard. > >> > Then, this parser then would be used in a new dump pass, from >> > either inside gdb or from gcc itself, to dump the JSON wherever it >> > needs to go. >> >> For the actual -fdump-generic-nodes we would call the dumper with the >> new flag and likely have set up the output to a file. >> >> > So ultimately the idea is to create both the parser and a new dump pass >> > from it. >> >> I don't think there's a parser involved, in the end we'd have to >> "parse" the JSON >> to produce HTML or graphviz output, but the JSON emission would be from >> inside dump_generic_node (and sibliings), conditional on the dump flag. Note >> that a lot of things will be dumped the same such as identifiers or >> constants, >> but all structured bits would be different. >> >> Richard. >> >> > I just read the notes you gave on the original patch. I'll edit the >> > plan a bit to emphasize interworking with tree-pretty-print, and >> > checking the bugs that mention easyhack. >> > >> > Best, >> > Thor Preimesberger >> > >> > >> > On Tue, Apr 2, 2024 at 4:20 PM Richard Biener >> > wrote: >> > > >> > > On Mon, Apr 1, 2024 at 6:23 PM Thor Preimesberger via Gcc >> > > wrote: >> > > > >> > > > Hey all, >> > > > >> > > > I'm joining the group of people submitting their GSoC applications >> > > > over the holiday. I'm interested in the "Implement structured dumping >> > > > of GENERIC" project idea, and the application I've written is below. >> > > >> > > Thank you for the interest in this project. >> > > >> > > > A quick question before though: >> > > > >> > > > - What would the expected use cases of the proposed >> > > > -fdump-generic-nodes option be, in addition to, presumably, writing >> > > > front ends into gcc? >> > > >> > > I think the main use case is better "visual" debugging and understanding >> > > of GENERIC. Then a structured dumping would also allow to custom >> > > processing like doing memory or other statistics. >> > > >> > > >I'm also curious about also targeting .gz/Graphviz; on a first >> > > > blush, it doesn't seem like too much additional work, and it may be >> > > > useful for the above applications. But I imagine there may be other >> > > > ways to process the data that would ultimate
GSoC "Nothrow detection" proposal review
Hello GCC Community, I am Pranil Dey and I had submitted a proposal for the project "Improve nothrow detection in GCC", but as the deadline period was a holiday time I wanted to ask you to review my proposal now. I am already getting familiar with the code but I wanted some pointers for now till selection time so as to read up some more and work more efficiently if selected. Proposal link - https://drive.google.com/file/d/1GynfephYrwaOHG4l7al3dNedrnjL9Dsr/view?usp=drive_link Thank You, -- Pranil Dey Student of Indian Institute of Technology Kharagpur Dept. of Computer Science and Engineering
RE: Project Selection Process and Timeline for GSoC 2024
Hello, I am a potential contributor for GSoC 2024, I made a submission for the project Extend the Static Analysis Pass, I was wondering about the process of ranking the proposals and the general timelines when the applicants will be notified if their proposals will be considered potentially? Would using Zulip be the best form of communication for faster responses compared to email? Thanking you for the clarification, Vedant
Re: [GSoC] Application RFC + Question - GENERIC dump
Hey all, I just checked, and it does appear to be the case that proposals can't be updated anymore. I do agree with all the proposed amendments (and would pick to move JSON to HTML), and I'll double-check to see if there's a way to push them into the application. I'm on JST for right now, if my emails are coming in at a weird time. Thanks! Thor On Fri, Apr 5, 2024, 11:27 PM Martin Jambor wrote: > Hello, > > On Fri, Apr 05 2024, Richard Biener via Gcc wrote: > > On Tue, Apr 2, 2024 at 1:16 PM Richard Biener > > wrote: > >> > >> On Tue, Apr 2, 2024 at 11:14 AM Thor Preimesberger via Gcc > >> wrote: > >> > > >> > Forgot to CC the mailing list - mea culpa. > >> > > >> > -- Forwarded message - > >> > From: Thor Preimesberger > >> > Date: Tue, Apr 2, 2024 at 5:57 PM > >> > Subject: Re: [GSoC] Application RFC + Question - GENERIC dump > >> > To: Richard Biener > >> > > >> > > >> > Thanks for the quick feedback, especially on such short notice - I'll > >> > get the actual GSoC application in, within a couple of hours. > >> > > >> > > This looks like a reasonable timeline and overall project > structure. I probably > >> > > pointed to it in my responses to the initial patch but to repeat > here > >> > > it would be > >> > > very nice to integrate with the existing GENERIC dumping in > tree-pretty-print.cc > >> > > That's what you get when calling 'debug_tree ()' from the > inferior inside > >> > > gdb. Implementation-wise the JSON target would then be a new > >> > > dump flag (see the various TDF_* in dumpfiles.h). > >> > > >> > Understood - To check my understanding, is it correct to say that we > >> > essentially want to parse the output of tree-pretty-print.cc into > >> > JSON? > >> > >> No, we want to emit JSON directly from tree-pretty-print.cc conditional > >> of the new dump flag. > > > > Thanks for uploading the proposal. Can you please update it to remove > > the confusion around "parsing of the tree-pretty-print.cc output"? > > IIUC proposals cannot be altered past the Tuesday deadline. Still, they > probably can clarified somewhat here even in the upcoming days (but > really not much more than that), so that all involved parties are then > not surprised if the project needs to take a slightly different > direction (assuming it will be selected AND we get enough slots in the > program from Google). > > Thanks, > > Martin > > > > As > > said we instead want to emit JSON directly from the GENERIC > representation > > as it is in memory, preferably as an output variant to the existing > > tree-pretty-print.cc output to make it easy to keep both variants in > sync. > > > > As for the timeline and way of development I would strongly suggest to > > develop the JSON -> html (or JSON -> graphviz if you like that more) > > translator in parallel to be able to incrementally verify the user > consumed > > output is as desired. Unimplemented JSON bits can be always > > implemented as text JSON nodes containing the textual > tree-pretty-print.cc > > output. > > > > One of the important goals is to have the JSON output functionality > > in tree-pretty-print.cc implemented in a maintainable way, making it > > easy to adjust JSON/non-JSON output when the data structures change. > > > > Thanks, > > Richard. > > > >> > Then, this parser then would be used in a new dump pass, from > >> > either inside gdb or from gcc itself, to dump the JSON wherever it > >> > needs to go. > >> > >> For the actual -fdump-generic-nodes we would call the dumper with the > >> new flag and likely have set up the output to a file. > >> > >> > So ultimately the idea is to create both the parser and a new dump > pass from it. > >> > >> I don't think there's a parser involved, in the end we'd have to > >> "parse" the JSON > >> to produce HTML or graphviz output, but the JSON emission would be from > >> inside dump_generic_node (and sibliings), conditional on the dump > flag. Note > >> that a lot of things will be dumped the same such as identifiers or > constants, > >> but all structured bits would be different. > >> > >> Richard. > >> > >> > I just read the notes you gave on the original patch. I'll edit the > >> > plan a bit to emphasize interworking with tree-pretty-print, and > >> > checking the bugs that mention easyhack. > >> > > >> > Best, > >> > Thor Preimesberger > >> > > >> > > >> > On Tue, Apr 2, 2024 at 4:20 PM Richard Biener > >> > wrote: > >> > > > >> > > On Mon, Apr 1, 2024 at 6:23 PM Thor Preimesberger via Gcc > >> > > wrote: > >> > > > > >> > > > Hey all, > >> > > > > >> > > > I'm joining the group of people submitting their GSoC > applications > >> > > > over the holiday. I'm interested in the "Implement structured > dumping > >> > > > of GENERIC" project idea, and the application I've written is > below. > >> > > > >> > > Thank you for the interest in this project. > >> > > > >> > > > A quick question before though: > >> > > > > >> > > > - What would the expected use cases of the p
Re: Sourceware mitigating and preventing the next xz-backdoor
> > > > > I think the key difference here is that Autotools allows arbitrarily > generated code to be executed at any time. More modern build systems > require the use of specific commands/files to run arbitrary code, e.g. > CMake (IIRC [`execute_process()`][2] and [`ExternalProject`][3]), Meson > ([`run_command()`][1]), Cargo ([`build.rs`][4]).\ > > To me it seems that Cargo is the absolute worst case with respect to > supply chain attacks. > > It pulls in dependencies recursively from a relatively uncurated > list of projects, puts the source of all those dependencies into a > hidden directory in home, and runs Build.rs automatically with > user permissions. > 100% this. Wait until you learn how proc macros work.
gcc-12-20240405 is now available
Snapshot gcc-12-20240405 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20240405/ 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 0611f480013fe998b9657a6b51d645c4b1489bbe You'll find: gcc-12-20240405.tar.xz Complete GCC SHA256=91a825307f0375c15f7ec2ea04e3465f65f0242d91d84aa65f0f0a6e6700fb04 SHA1=55dbfe90a09e8982a000478d1dde45a1d522c841 Diffs from 12-20240329 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.
