Re: [gimple-ssa] result_decl and ssa_name
On Fri, Apr 5, 2024 at 3:44 PM Pierrick Philippe
wrote:
>
> 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.
It might make sense to record the analysis of the return value in
meta-data that the analyzer keeps and access it that way.
Other than that you'd have to do it the way I said with finding the
greturn stmts again and look at what is returned there.
> 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: Sourceware mitigating and preventing the next xz-backdoor
On Fri, Apr 5, 2024 at 11:18 PM Andrew Sutton via Gcc wrote: > > > > > > > > > > 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. proc macro execution should be heavily sandboxed, otherwise it seems compiling something is enough to get arbitrary code executed with the permission of the compiling user. I mean it's not rocket science - browsers do this for javascript. Hmm, we need a webassembly target ;) Richard.
Re: Sourceware mitigating and preventing the next xz-backdoor
Am Samstag, dem 06.04.2024 um 15:00 +0200 schrieb Richard Biener: > On Fri, Apr 5, 2024 at 11:18 PM Andrew Sutton via Gcc wrote: > > > > > > > > > > > > > > > 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. > > proc macro execution should be heavily sandboxed, otherwise it seems > compiling something is enough to get arbitrary code executed with the > permission of the compiling user. I mean it's not rocket science - browsers > do this for javascript. Hmm, we need a webassembly target ;) This would be useful anyhow. And locking down the compiler using landlock to only access specified files / directories would also be nice in general. Martin
Re: Patches submission policy change
Hi, On Fri, 2024-04-05 at 09:17 +0200, Christophe Lyon wrote: > On 4/4/24 23:35, Mark Wielaard wrote: > > 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. I added Simon for gdb, Marc for gcc and you as admin for binutils. So all three projects now have at least two moderators. Thanks so much for volunteering. And please reach out to overseers if this becomes too much of a burden (it really should not be more than a handful of messages each week). Then we'll see if we can adjust the (spam) settings so only oversized messages reach the moderation queues (or raise the limits if that makes more sense). Thanks, Mark
gcc-13-20240406 is now available
Snapshot gcc-13-20240406 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20240406/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-13 revision 045de0ab586409ce2e447ed4dd5c6786fe46254f You'll find: gcc-13-20240406.tar.xz Complete GCC SHA256=f9d34bce1465b6eb04b1562860682ab1eb40065e380c987532fb5004b7a763f4 SHA1=b0f2b733b645fabed4eb09847ae1d064bcb47488 Diffs from 13-20240330 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 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.
