Re: New function attribute __call_push_jmp__
On 01/12/2024 23:55, Frederick Virchanza Gotham via Gcc wrote: Some modern CPU's now have control flow enforcement. Here's how it works on Intel CPU's: "The shadow stack stores a copy of the return address of each CALL. On a RET, the processor checks if the return address stored in the normal stack and shadow stack are equal. If the addresses are not equal, the processor generates an INT #21 (Control Flow Protection Fault)." ... This would allow us to get around the control-flow enforcement (such as when debugging, or when intercepting a function call). You are asking for a feature to bypass a rather useful security feature that otherwise eliminates a major class of hacking and malware attack techniques. (I don't know how much the CET features are currently supported in gcc - I don't normally use x86 targets.) Why do you think it is at all relevant for debugging? Why do you think "intercepting a function call" is a useful thing to do? How would your suggestion differ from existing debug features or gcc flags (like -flive-patching, -fpatchable-function-entry, -mno-shstk) ?
Re: Align the gcc, glibc, and binutils DCO text to match community usage.
Hi Bradley, Thanks for following the discussion and your input. We have also been discussing some policy wording changes on gcc-patches: https://inbox.sourceware.org/gcc-patches/20241202101600.1041524-1-m...@klomp.org/T If you have any suggestions for improving the actual wording change that would be appreciated. On Sun, Nov 24, 2024 at 08:49:37AM -0800, Bradley M. Kuhn via Gcc wrote: > Carlos O'Donell wrote on Friday: > > The DCO was introduced to gcc, glibc and binutils in 2021 and 2022 > > to expand and align the contribution process with other free and open > > source software projects that had been effectively using DCO for > > contributions. > > > To that end I'm aligning the glibc usage following the Linux kernel > > changes from 2023-02-26 [1]. > > While the DCO text used by the kernel named Linux is a fine text and serves > many purposes, it is particularly aligned with the sub-maintainer model of > Linux development — whereby submaintainers take cascading responsibility as > patches work their way upstream, and are thus adding Signed-Off-By tags upon > existing Signed-Off-By tags, and thus strengthening the DCO attestation with > addition of more parties for the same patch. > > I am not aware that all of the toolchain projects have a similar model of > development and thus the DCO text that Linux uses may not be ideal. That is a good point. Most projects have a much flatter structure. And developers are often asked to commit patches directly themselves. Just adding Reviewed-by or Tested-by tags. > One size doesn't necessarily fit all. Perhaps if you're changing the DCO > text for the toolchain projects at this moment, it might be a good time to > consider if the Linux DCO text suits your project perfectly. Yeah, for elfutils, libabigail and debugedit we already made a some of clarifications: https://sourceware.org/cgit/elfutils/tree/CONTRIBUTING#n26 Specifically it explains that you contribute under all licenses applicable to the project. Which is important for elfutils since it uses a dual license for some of the included libraries. And we want to prevent someone claiming to have only contributed the code under a lax-permissive license without granting any additional GPL rights. This might be useful for GCC too for some of the code/documentation strings which are distributed under either the GPL or GFDL. > FWIW, my specific concern with the Linux DCO is, as Denver and I discussed in > licensing BoF at Cauldron, the Linux DCO text is specifically designed to > shift licensing liability from any *entity* who might be contributing or who > might hold copyright (such as a company or a non-profit) *onto* the > individual developer who submitted the patch. I suppose this structure works > well for Linux, but, especially given that contributors to the toolchain > projects have been used to all the liability shifting to the FSF through its > historical copyright assignment system, developers might be surprised to > learn that a DCO-based patch (as opposed to a copyright assigned one) puts > additional liability onto the contributor. That is an interesting point. One of the clarifications suggested on gcc-patches was that the DCO process isn't applicable to all contributing situations and following the FSF assignment process might be a good alternative. The FSF process also means you get an explicit company disclaimer. The Samba policy might be something to follow to get an explicit company disclaimer, while still following the "normal" Signed-off-by process. https://www.samba.org/samba/devel/copyright-policy.html We would just need someone to collect the explicit company declarations. Cheers, Mark
Re: gcc-wwwdocs branch python-formatting created. e1e17c97a8ae35cfb6b2f7428fb52b05f82450d1
Hi Gerald, On Mon, Dec 02, 2024 at 12:13:35AM +0100, Gerald Pfeifer wrote: > On Sun, 1 Dec 2024, Alexander Monakov wrote: > > You have to use the name of the branch in the remote repo, > > "python-formatting": > > > > git push --delete origin python-formatting > > That did the job, thank you! > > On Sun, 1 Dec 2024, Mark Wielaard wrote: > > > > If that doesn't work we'll have to clean it up on the server. > > I believe things are fine? > > % git branch -la | cat > * master > remotes/origin/HEAD -> origin/master > remotes/origin/master Yes, everything looks fine now, the (remote) branch is gone. Thanks, Mark
RE: [RFC] Enabling SVE with offloading to nvptx
> -Original Message-
> From: Jakub Jelinek
> Sent: 28 November 2024 17:39
> To: Prathamesh Kulkarni
> Cc: Andrew Stubbs ; Richard Biener
> ; Richard Biener ;
> gcc@gcc.gnu.org; Thomas Schwinge
> Subject: Re: [RFC] Enabling SVE with offloading to nvptx
>
> External email: Use caution opening links or attachments
>
>
> On Thu, Nov 14, 2024 at 08:29:26AM +, Prathamesh Kulkarni wrote:
> > + /* True if SIMD loop needs delayed lowering of artefacts like
> > + safelen and length of omp simd arrays that depend on target's
> > + max_vf. This is true for offloading, when max_vf is computed
> > + after
>
> 2 spaces after ., not just one.
Fixed in the attached patch.
>
> > + streaming out to device. */
> > + unsigned needs_max_vf_lowering: 1;
> > +
> >/* The number of times to unroll the loop. 0 means no
> information given,
> > just do what we always do. A value of 1 means do not unroll
> the loop.
> > A value of USHRT_MAX means unroll with no specific unrolling
> factor.
> > diff --git a/gcc/omp-expand.cc b/gcc/omp-expand.cc index
> > 80fb1843445..c9581e3d92e 100644
> > --- a/gcc/omp-expand.cc
> > +++ b/gcc/omp-expand.cc
> > @@ -7171,6 +7171,10 @@ expand_omp_simd (struct omp_region *region,
> struct omp_for_data *fd)
> >loop->latch = cont_bb;
> >add_loop (loop, l1_bb->loop_father);
> >loop->safelen = safelen_int;
> > + loop->needs_max_vf_lowering = is_in_offload_region (region);
> > + if (loop->needs_max_vf_lowering)
> > + cfun->curr_properties &= ~PROP_gimple_lomp_dev;
> > +
> >if (simduid)
> > {
> > loop->simduid = OMP_CLAUSE__SIMDUID__DECL (simduid); diff
> > --git a/gcc/omp-low.cc b/gcc/omp-low.cc index
> 70a2c108fbc..0f68876a2bc
> > 100644
> > --- a/gcc/omp-low.cc
> > +++ b/gcc/omp-low.cc
> > @@ -4660,7 +4660,16 @@ lower_rec_simd_input_clauses (tree new_var,
> omp_context *ctx,
> > }
> >else
> > {
> > - tree atype = build_array_type_nelts (TREE_TYPE (new_var),
> sctx->max_vf);
> > + poly_uint64 nelts;
> > + /* FIXME: If offloading is enabled, and max_vf is poly_int,
> avoid
> > + using it as length of omp simd array, and use a placeholder
> value
> > + instead to avoid streaming out poly_int to device. The arrays
> > + will be set to correct length later in omp_device_lower pass.
> > + */
>
> Likewise. I really don't like introducing FIXME comments. Describe
> what you want to say, but not with FIXME.
Fixed.
>
> > + if (omp_maybe_offloaded_ctx (ctx) && !sctx-
> >max_vf.is_constant ())
> > + nelts = INT_MAX;
>
> I'm not convinced INT_MAX is the right placeholder.
> On 32-bit arches whenever TREE_TYPE (new_var) is 2 or more bytes the
> array won't fit into address space anymore.
> Use some magic value like 64 and say in the comment it really doesn't
> matter much, as we'll change it later.
> 1 probably wouldn't be best, then I think some undesirable
> optimizations couild trigger (e.g. ignoring the exact value of the
> index).
Adjusted to use 64 in the patch.
>
> > + else
> > + nelts = sctx->max_vf;
> > + tree atype = build_array_type_nelts (TREE_TYPE (new_var),
> > + nelts);
> >tree avar = create_tmp_var_raw (atype);
> >if (TREE_ADDRESSABLE (new_var))
> > TREE_ADDRESSABLE (avar) = 1;
> > diff --git a/gcc/omp-offload.cc b/gcc/omp-offload.cc index
> > 372b019f9d6..9d6467cc6a6 100644
> > --- a/gcc/omp-offload.cc
> > +++ b/gcc/omp-offload.cc
> > @@ -2618,6 +2618,75 @@ find_simtpriv_var_op (tree *tp, int
> *walk_subtrees, void *)
> >return NULL_TREE;
> > }
> >
> > +/* Compute max_vf for target, and accordingly set loop->safelen and
> length
> > + of omp simd arrays. */
> > +
> > +static void
> > +adjust_max_vf (function *fun)
> > +{
> > + if (!fun->has_simduid_loops)
> > +return;
> > +
> > + poly_uint64 max_vf = omp_max_vf (false);
> > +
> > + /* FIXME: Since loop->safelen has to be an integer, it's not
> always possible
> > + to compare against poly_int. For eg 32 and 16+16x are not
> comparable at
> > + compile-time because 16+16x <= 32 for x < 2, but 16+16x > 32
> for x >= 2.
> > + Even if we could get runtime VL based on -mcpu/-march, that
> would not be
> > + portable across other SVE archs.
> > +
> > + For now, use constant_lower_bound (max_vf), as a "safer
> approximation" to
> > + max_vf that avoids these issues, with the downside that it
> will be
> > + suboptimal max_vf for SVE archs implementing SIMD width > 128
> > + bits. */
>
> Again, I don't like FIXMEs and . should be followed by 2 spaces.
Fixed.
>
> > + tree assign_stmt_lhs = gimple_assign_lhs
> (assign_stmt);
> > + if (TREE_CODE (assign_stmt_lhs) == ARRAY_REF)
> > + {
> > + tree array = TREE_OPERAND (assign_stmt_lhs,
> 0);
> > + tree& max = TYPE_MAX_VALUE (TYPE_DOMAIN
> (TREE_TYPE (array)));
> > +
Re: GCC devroom at FOSDEM 2025?
On Tue, 01 Oct 2024 11:48:34 +0200 Thomas Schwinge wrote: > I need two, three people as co-organizers: > for evaluating submissions (before 2024-12-15), Hi Thomas, I went to https://pretalx.fosdem.org/fosdem-2025/cfp today. It says the deadline isn't the 15th, but was yesterday! Am i really too late? I have two ideas in mind: 1. So, You Need a Symbol Table? Compiler textbooks wave their hands and say you might need a symbol table. Except for LISP, they doen't say what it looks like. I describe our experience with the one I designed. 2. Cobol is the Original Safe Language An exploration of what "safe language" means, how those properties were present in Cobol long before the concept had a name, and what "safety" looks like in gcobol. Please tell me what I should do. Thanks & regards, --jkl
Vrh
Sent from my iPhone
