public-inbox for gcc lists

[Mark Wielaard]

Hi gcc-hackers,

Given that gcc is part of the sourceware family the mailinglists are
now also available through the public-inbox instance at 
https://inbox.sourceware.org/

In particular:

https://inbox.sourceware.org/fortran
https://inbox.sourceware.org/gcc
https://inbox.sourceware.org/gcc-announce
https://inbox.sourceware.org/gcc-help
https://inbox.sourceware.org/gcc-patches
https://inbox.sourceware.org/gcc-rust
https://inbox.sourceware.org/jit
https://inbox.sourceware.org/libstdc++

There are also archives of some older not used anymore lists in case
people are interested in some history (we are aware that some of these
older lists contain spam, we will try to remove that). And some of the
automated lists like testresults, prs, cvs, etc. (but without full text
search, please use bugzilla, git or bunsen for that).

Note that you can now mirror these mailinglists through git (see the
mirror instructions on each list), there is an atom link to follow the
lists, you can download mboxes of search results and there are read-
only nntp news and imap archives of each list (in the inbox.gcc.*
hierarchy).

To handle patches you might want to look at b4 or piem for emacs:
https://git.kernel.org/pub/scm/utils/b4/b4.git
https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/man/b4.5.rst
https://git.kyleam.com/piem
https://docs.kyleam.com/piem.html

You will want the following in your .git/config:

[b4]
midmask = https://inbox.sourceware.org/gcc-patches/%s
linkmask = https://inbox.sourceware.org.org/gcc-patches/%s

There are currently some known issues:

- Message-IDs can contain slashes ('/') which are sometimes
  encoded as %2F. If you got an URL with "%2F" in the path change
  it to an actual '/' character to workaround it
  (which doesn't work if the Message-ID ends with a / which is
   the case for bugzilla generated emails).
  We are looking to see if we can get the slash handling more
  consistent.

- HTML emails aren't accepted. Even if the list would strip the
  text/html part. Please don't sent HTML email. We are looking
  at stripping the HTML part and only importing the text/plain
  part into public-inbox.

- Messages send to gcc-patches are sometimes not fully indexed,
  which
means they won't show up when doing a full text search,
  but they are
functional in all other ways that matter. We'll
  reindex the list
periodically and look into why this is
  happening (gcc-patches is the
largest list we have and we
  might just hit some limit).

Your friendly sourceware overseers team (with special thanks to Simon
Marchi for showing how to setup public-inbox and to Frank Eigler for
making sure the sourceware infrastructure was ready).

P.S. 
inbox.sourceware.org is one part of the Sourceware GNU Toolchain
Infrastructure roadmap to make email/git based workflow more fun,
secure and productive by automating contribution tracking and testing
across different distros and architectures:
https://inbox.sourceware.org/overseers/yrldfdwzq1t4k...@wildebeest.org/

There will be a Sourceware GNU Toolchain Infrastructure and beyond BoF
at the Cauldron next month for everybody who likes to discuss (and
wants to help with) automating the infrastructure to make contributing
to our projects more fun and more productive:
https://gcc.gnu.org/wiki/cauldron2022#cauldron2022talks.sourceware_gnu_toolchain_infrastructure_and_beyond

Re: public-inbox for gcc lists

[Alexander Monakov via Gcc]

On Thu, 25 Aug 2022, Mark Wielaard wrote:

> Hi gcc-hackers,
> 
> Given that gcc is part of the sourceware family the mailinglists are
> now also available through the public-inbox instance at 
> https://inbox.sourceware.org/

Thanks for this. At the moment something seems broken with a few lists,
as clicking on a thread results in a 404 page, e.g. any top link from
https://inbox.sourceware.org/gcc-bugs/

Alexander

Re: public-inbox for gcc lists

[Mark Wielaard]

Hi Alexander,

On Thu, 2022-08-25 at 15:45 +0300, Alexander Monakov wrote:
> On Thu, 25 Aug 2022, Mark Wielaard wrote:
> > Given that gcc is part of the sourceware family the mailinglists
> > are now also available through the public-inbox instance at 
> > https://inbox.sourceware.org/
> 
> Thanks for this. At the moment something seems broken with a few
> lists,
> as clicking on a thread results in a 404 page, e.g. any top link from
> https://inbox.sourceware.org/gcc-bugs/

Yes, sadly that is one of the known issues with bugzilla emails:

> - Message-IDs can contain slashes ('/') which are sometimes
>   encoded as %2F. If you got an URL with "%2F" in the path change
>   it to an actual '/' character to workaround it
>   (which doesn't work if the Message-ID ends with a / which is
>the case for bugzilla generated emails).
>   We are looking to see if we can get the slash handling more
>   consistent.

For now please use bugzilla to search through bugs.

Apologies for the brokenness. Hope other lists are more useful.

Cheers,

Mark

gcc-10-20220825 is now available

[GCC Administrator via Gcc]

Snapshot gcc-10-20220825 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20220825/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-10 revision cc40dcf4229f80d4b1b04ad3cf862ed90f46dac8

You'll find:

 gcc-10-20220825.tar.xz   Complete GCC

  SHA256=a84590fc177823236ee64d3d62d2c404684f858902f0b6eda43ab003bb5412fe
  SHA1=b7b5e4af36fe85fcd4ae97c6ee3a8cd3cae3e771

Diffs from 10-20220818 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
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.

Confused about coroutine behavior

[Rebecca Ribas via Gcc]

Hi gcc list,

I'm learning c++ coroutines but I ran into a behavior that I can't make
sense of.

Here is the godbolt link: https://godbolt.org/z/rdPo8ceKP

In some cases, it appears that temporaries are incorrectly freed, the code
shows test1 and test2 that works as expected, but test3 raises a "used
after free" error from address sanitizer that doesn't make sense to me.

I'm aware that there are some potential caveats with passing references to
a coroutine, so I'm possibly missing some subtle detail. But it looks like
it might be a gcc bug since the same doesn't happen with clang.

I tested a few different versions of g++ available on ubuntu and godbolt
but got the same result.

The compilations flags I used were: -ggdb3 -Og -std=c++20 -Wall -Wextra
-Werror -D_GLIBCXX_DEBUG -fsanitize=address

Cheers!