Re: Incremental LTO Project

[Thomas Schwinge]

Hi!

On 2023-09-07T19:00:49-0400, James Hu via Gcc  wrote:
> I noticed that adding incremental LTO was a GSoC project that was not
> claimed this cycle (
> https://summerofcode.withgoogle.com/programs/2023/organizations/gnu-compiler-collection-gcc).
> I was curious about working on this project, but wanted to check on the
> state of the project.

Thanks for your interest!  (... as a potential contributor, I presume?)

> Has it already been completed? Is someone actively
> working on it?

Yesterday, when browsing the schedule of the GNU Tools Cauldron 2023,
, I noticed there's going to be a
presentation on "Incremental LTO in GCC" (Michal Jireš),
.

> If not, what would be the appropriate method to contact the
> mentor (Jan Hubička)?

He's reading this list, but I've now also put Honza in CC.


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: Last call for bikeshedding on attribute sym/exalias/reverse_alias

[Jonathan Wakely via Gcc]

On Fri, 8 Sept 2023, 06:58 Dave Blanchard,  wrote:

> On Fri, 08 Sep 2023 02:25:38 -0300
> Alexandre Oliva via Gcc  wrote:
>
> > Attribute sym, named after symver, is the one in the latest version of
> > the patch.  mnemonic_alias, convenience_alias and asm_alias are other
> > possibilities that comes to mind.  The 2020-August thread has many more.
>
> Sounds like a useful feature. Since it specifically deals with C++ name
> mangling, how about 'demangle'?
>

It doesn't demangle though, it provides an alternative mangled name.



> C++ is an abomination and name mangling is a perfect example of the brain
> damage surrounding this abortion of a language, but I digress...
>

Re: Last call for bikeshedding on attribute sym/exalias/reverse_alias

[Jonathan Wakely via Gcc]

On Fri, 8 Sept 2023, 06:26 Alexandre Oliva via Gcc,  wrote:

> Since 2020 I've been trying to introduce an attribute that operates a
> bit like alias, but instead of defining a declaration as an alias to
> another defined declaration, it merely exposes the present declaration
> with an alternate mnemonic symbol name, so that it can be further
> aliased, imported or referenced elsewhere with an invariant name, rather
> than with a mangled name.  E.g.:
>
> // C++
> namespace foo {
>   int __attribute__ ((__???__ ("FOOVAR")))
>   var = 42; // FOOVAR is an asm alias to the mangled name for foo::var
> }
>
> --  Ada
> package Foo is
>   Var : Integer;
>   pragma Import (CPP, FooVar, "FOOVAR");
>   --  use the mnemonic alias rather than the mangled name.
>
>
> The implementation also handles C++ cdtors, modifying the mnemonic alias
> of each clone so that they don't clash, and typeinfo objects generated
> for classes when the attribute is associated with a class.
>

Very cool, we have immediate uses for this in libstdc++.

Personally I think calling it some form of "alias" focuses on the
implementation details of how its done behind the scenes, not what its
practical effects are. On the other hand, it would relate it to the
existing alias attribute which is related.

I think "symname" or "symalias" would be better than just "sym".

Have you contacted anybody in the llvm community to see if they would
implement it, or maybe already have something similar by another name?




>
> There don't seem to be objections to the feature per se, but discussions
> about it have invariably got stuck in debating the attribute name.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551614.html
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624560.html
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624977.html
>
>
> The customer report that motivated this development didn't require its
> full generality, and asm("symbol") satisfies it.  But I've implemented
> the feature, I find it useful, others seem to have liked it, and so I'd
> like it to find its way into GCC.  However, I'm advised to not spend
> much more time on it.
>
> So, instead of updating the patch for every suggested attribute name, my
> last-attempt plan is to try to reach consensus on the attribute name,
> and then adjust the patch and submit it one more time.  If that doesn't
> succeed, I'll leave it for anyone else to take it from there.
>
> Attribute sym, named after symver, is the one in the latest version of
> the patch.  mnemonic_alias, convenience_alias and asm_alias are other
> possibilities that comes to mind.  The 2020-August thread has many more.
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> More tolerance and less prejudice are key for inclusion and diversity
> Excluding neuro-others for not behaving ""normal"" is *not* inclusive
>

Re: Last call for bikeshedding on attribute sym/exalias/reverse_alias

[Roy Jacobson via Gcc]

There's a related [[preferred_name]] attribute in Clang but it's not a
success story. If you come up with something more usable I think we'll be
happy to implement it as well :)

https://clang.llvm.org/docs/AttributeReference.html#preferred-name


On Fri, 8 Sept 2023, 11:34 Jonathan Wakely via Gcc,  wrote:

> On Fri, 8 Sept 2023, 06:26 Alexandre Oliva via Gcc, 
> wrote:
>
> > Since 2020 I've been trying to introduce an attribute that operates a
> > bit like alias, but instead of defining a declaration as an alias to
> > another defined declaration, it merely exposes the present declaration
> > with an alternate mnemonic symbol name, so that it can be further
> > aliased, imported or referenced elsewhere with an invariant name, rather
> > than with a mangled name.  E.g.:
> >
> > // C++
> > namespace foo {
> >   int __attribute__ ((__???__ ("FOOVAR")))
> >   var = 42; // FOOVAR is an asm alias to the mangled name for foo::var
> > }
> >
> > --  Ada
> > package Foo is
> >   Var : Integer;
> >   pragma Import (CPP, FooVar, "FOOVAR");
> >   --  use the mnemonic alias rather than the mangled name.
> >
> >
> > The implementation also handles C++ cdtors, modifying the mnemonic alias
> > of each clone so that they don't clash, and typeinfo objects generated
> > for classes when the attribute is associated with a class.
> >
>
> Very cool, we have immediate uses for this in libstdc++.
>
> Personally I think calling it some form of "alias" focuses on the
> implementation details of how its done behind the scenes, not what its
> practical effects are. On the other hand, it would relate it to the
> existing alias attribute which is related.
>
> I think "symname" or "symalias" would be better than just "sym".
>
> Have you contacted anybody in the llvm community to see if they would
> implement it, or maybe already have something similar by another name?
>
>
>
>
> >
> > There don't seem to be objections to the feature per se, but discussions
> > about it have invariably got stuck in debating the attribute name.
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551614.html
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624560.html
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624977.html
> >
> >
> > The customer report that motivated this development didn't require its
> > full generality, and asm("symbol") satisfies it.  But I've implemented
> > the feature, I find it useful, others seem to have liked it, and so I'd
> > like it to find its way into GCC.  However, I'm advised to not spend
> > much more time on it.
> >
> > So, instead of updating the patch for every suggested attribute name, my
> > last-attempt plan is to try to reach consensus on the attribute name,
> > and then adjust the patch and submit it one more time.  If that doesn't
> > succeed, I'll leave it for anyone else to take it from there.
> >
> > Attribute sym, named after symver, is the one in the latest version of
> > the patch.  mnemonic_alias, convenience_alias and asm_alias are other
> > possibilities that comes to mind.  The 2020-August thread has many more.
> >
> > --
> > Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
> >Free Software Activist   GNU Toolchain Engineer
> > More tolerance and less prejudice are key for inclusion and diversity
> > Excluding neuro-others for not behaving ""normal"" is *not* inclusive
> >
>

Re: Incremental LTO Project

[James Hu via Gcc]

Ah, I see. I was interested as a contributor but outside of the official
GSoC program. But I'm assuming that because there is a talk on incremental
LTO, it has already been implemented, correct? Other than that, thanks for
your help!

On Fri, Sep 8, 2023 at 3:20 AM Thomas Schwinge 
wrote:

> Hi!
>
> On 2023-09-07T19:00:49-0400, James Hu via Gcc  wrote:
> > I noticed that adding incremental LTO was a GSoC project that was not
> > claimed this cycle (
> >
> https://summerofcode.withgoogle.com/programs/2023/organizations/gnu-compiler-collection-gcc
> ).
> > I was curious about working on this project, but wanted to check on the
> > state of the project.
>
> Thanks for your interest!  (... as a potential contributor, I presume?)
>
> > Has it already been completed? Is someone actively
> > working on it?
>
> Yesterday, when browsing the schedule of the GNU Tools Cauldron 2023,
> , I noticed there's going to be a
> presentation on "Incremental LTO in GCC" (Michal Jireš),
> <
> https://gcc.gnu.org/wiki/cauldron2023#cauldron2023talks.incremental_lto_in_gcc
> >.
>
> > If not, what would be the appropriate method to contact the
> > mentor (Jan Hubička)?
>
> He's reading this list, but I've now also put Honza in CC.
>
>
> Grüße
>  Thomas
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
> 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer:
> Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München;
> Registergericht München, HRB 106955
>

Cauldron schedule: diagnostics and security features talks

[Siddhesh Poyarekar]

Hello,

I want to begin by apologizing because I know from first hand experience 
that scheduling can be an immensely painful job.


The Cauldron 2023 schedule[1] looks packed and I noticed that Qing and 
David's talks on security features and diagnostics respectively are in 
the same time slot.  Both those sessions are likely to have pretty big 
overlaps in audience IMO since the topics are thematically related.  Is 
there a way in which they could be put in different time slots?


IIRC they were in different time slots before and were probably moved 
around to cater for another conflict (hence maybe making it harder to 
move them again) but I figured I'd rather air my request and be turned 
down than have to make the difficult choice :)


Thanks!
Sid

[1] https://gcc.gnu.org/wiki/cauldron2023

gcc-12-20230908 is now available

[GCC Administrator via Gcc]

Snapshot gcc-12-20230908 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20230908/
and on various mirrors, see http://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 1bfe036184e1b5e9bd1cecb94045da0f073657f9

You'll find:

 gcc-12-20230908.tar.xz   Complete GCC

  SHA256=7a8d4c905e7f1ff8df81a3ae5c0b1667a7302439cf57e430b65e0a9224226f3d
  SHA1=7dc0a67134265c8aa988d29f1d12908f177c5823

Diffs from 12-20230901 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.