Question on updating Ada's changelog

2021-10-20 Thread Fernando Oleo Blanco via Gcc 
Hello everybody,

this is my first time sending anything to GCC. If there is anything
wrong with the message, please, point it out.

TLDR;
Ada (one of the supported languages by GCC) has not appeared in the
changes page since GCC 8, and even then and before it, its presence was
minimal. I would like to update the changelog to include its mayor
changes. What is the recommended procedure and how far could it be taken
(such as updating changes in older versions)?

Ada has seen tremendous amount of work in the past few years, but that
has not been reflected on the changes.html [1] since GCC 8. I would like
to update the changes.html to better reflect the state of Ada's
development, specially since a lot of work has been done on Ada 202X
(which will most likely become 2022). There have been some mayor changes
too, such as the deprecation of ASIS support since GCC 11.

So, my question is, can I just send a patch (to the patches ML) of the
changes.html page to update Ada's non-existent entry? And could this be
done for older versions which have already been released, such as GCC
11, 10 and 9? If older releases' changes.html cannot be updated to
reflect the changes that took place on them, could those changes be
included for GCC 12?

I am aware that it is recommended that whoever submits patches, should
have signed the legal prerequisites. But since this patch would not
contain any significant changes (just listing what has already been
done), I suppose that there should be no problem on me submitting it
directly.

Thank you,


[1] GCC's 11 changes page for reference
https://gcc.gnu.org/gcc-11/changes.html

--
Fernando Oleo Blanco
https://irvise.xyz

Re: Question on updating Ada's changelog

2021-10-20 Thread Jonathan Wakely via Gcc 
On Wed, 20 Oct 2021 at 09:44, Fernando Oleo Blanco wrote:
>
> Hello everybody,
>
> this is my first time sending anything to GCC. If there is anything
> wrong with the message, please, point it out.
>
> TLDR;
> Ada (one of the supported languages by GCC) has not appeared in the
> changes page since GCC 8, and even then and before it, its presence was
> minimal. I would like to update the changelog to include its mayor
> changes. What is the recommended procedure and how far could it be taken
> (such as updating changes in older versions)?

The /gcc-N/changes.html pages live in the wwwdocs repository, separate
from the actual GCC sources. That means there is no problem updating
them after a release (unlike the doc files actually shipped in the
release, which can't be changed after the release, because they've
already been released).


> Ada has seen tremendous amount of work in the past few years, but that
> has not been reflected on the changes.html [1] since GCC 8. I would like
> to update the changes.html to better reflect the state of Ada's
> development, specially since a lot of work has been done on Ada 202X
> (which will most likely become 2022). There have been some mayor changes
> too, such as the deprecation of ASIS support since GCC 11.
>
> So, my question is, can I just send a patch (to the patches ML) of the
> changes.html page to update Ada's non-existent entry?

Yes, exactly.

The wwwdocs repo is documented at https://gcc.gnu.org/about.html#git

A change to those pages should be sent to the gcc-patc...@gcc.gnu.org
mailing list like any other patch for GCC. You should include
"wwwdocs" in the email Subject so people know to pay attention (or
ignore it as appropriate!)

I would recommend also CCing one or more Ada maintainers, as they are
the ones most likely to know if your proposed changes to the release
notes are correct.



>And could this be
> done for older versions which have already been released, such as GCC
> 11, 10 and 9?

Yes, that's fine. It's obviously better if the release notes are
complete when the release happens, but better late than never.

> If older releases' changes.html cannot be updated to
> reflect the changes that took place on them, could those changes be
> included for GCC 12?
>
> I am aware that it is recommended that whoever submits patches, should
> have signed the legal prerequisites. But since this patch would not
> contain any significant changes (just listing what has already been
> done), I suppose that there should be no problem on me submitting it
> directly.

Yes, it seems unlikely your changes would be copyrightable, since they
would just be collating publicly available facts. In any case, GCC no
logner requires a copyright assignment for contributions, see
https://gcc.gnu.org/dco.html for another option.

Re: Question on updating Ada's changelog

2021-10-20 Thread Arnaud Charlet via Gcc 
> The wwwdocs repo is documented at https://gcc.gnu.org/about.html#git
> 
> A change to those pages should be sent to the gcc-patc...@gcc.gnu.org
> mailing list like any other patch for GCC. You should include
> "wwwdocs" in the email Subject so people know to pay attention (or
> ignore it as appropriate!)
> 
> I would recommend also CCing one or more Ada maintainers, as they are
> the ones most likely to know if your proposed changes to the release
> notes are correct.

Exactly. Feel free to cc: me on such patches and thanks for your (future)
contribution!

Arno

[Bug modula2/102344, 102339, 102323, 102325] confirmed and resolved

2021-10-20 Thread Gaius Mulley via Gcc 


Hello,

a huge apology as I'm sure this must be obvious - but I cannot see how
to set the status on bugzilla.  In summary the above bugs have been
resolved (I believe),


regards,
Gaius

Re: [Bug modula2/102344, 102339, 102323, 102325] confirmed and resolved

2021-10-20 Thread Jonathan Wakely via Gcc 
On Wed, 20 Oct 2021 at 15:33, Gaius Mulley wrote:

>
> Hello,
>
> a huge apology as I'm sure this must be obvious - but I cannot see how
> to set the status on bugzilla.  In summary the above bugs have been
> resolved (I believe),
>

Only GCC maintainers and the bug reporter can change the status. Use your @
gcc.gnu.org email address to login to be recognized as a maintainer

Old installation docs

2021-10-20 Thread Jonathan Wakely via Gcc 
https://gcc.gnu.org/install/ says:

"There are also some old installation instructions
, which are mostly obsolete but still
contain some information which has not yet been merged into the main part
of this manual."

But the link shows an empty page (except for the automated footer). Is
there a redirect that got lost in the last sourceware server move?

[RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (Oct 21, 2021)

2021-10-20 Thread 吴伟 
Hi all,

There is an agenda for tomorrow's meeting. If you have topics to
discuss or share, please let me know and I can add them to the agenda.

Agenda:

1. Status update for Krypto Scalar, DSP/P-ext, Vector, Zce, Zfinx, etc.
2. Preparing upstream for near-ratified extensions.
2. Open Discussion

Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting.

Topic: RISC-V GNU Toolchain Biweekly Sync-up

Join Zoom Meeting
https://zoom.com.cn/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09

Meeting ID: 893 9360 0951
Passcode: 899662

LONDON, United Kingdom, England
4:00pThu, Oct 21 2021
5:00pThu, Oct 21 2021

BEIJING, China
11:00pThu, Oct 21 2021
12:00aFri, Oct 22 2021

LOS ANGELES, United States, California
8:00aThu, Oct 21 2021
9:00aThu, Oct 21 2021

Please download and import the following iCalendar (.ics) files to
your calendar system.
Weekly: 
https://zoom.us/meeting/tZ0ufuqurjsjH9XTthkNg3MffX-QsRBuVBET/ics?icsToken=98tyKuGhrTIpHNSVuRyGRpx5A4r4b-7ziGJEgvplqAvtCA5UMS7wMNoPA6FNMs3m

-- 
Best wishes,
Wei Wu (吴伟)

Re: Old installation docs

2021-10-20 Thread Joseph Myers 
On Wed, 20 Oct 2021, Jonathan Wakely via Gcc wrote:

> https://gcc.gnu.org/install/ says:
> 
> "There are also some old installation instructions
> , which are mostly obsolete but still
> contain some information which has not yet been merged into the main part
> of this manual."

Those should have been removed in GCC commit 
431d26e1dd18c1146d3d4dcd3b45a3b04f7f7d59, it seems that forgot to remove 
the link in the HTML version.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Old installation docs

2021-10-20 Thread Jonathan Wakely via Gcc 
On Wed, 20 Oct 2021 at 17:40, Joseph Myers wrote:

> On Wed, 20 Oct 2021, Jonathan Wakely via Gcc wrote:
>
> > https://gcc.gnu.org/install/ says:
> >
> > "There are also some old installation instructions
> > , which are mostly obsolete but
> still
> > contain some information which has not yet been merged into the main part
> > of this manual."
>
> Those should have been removed in GCC commit
> 431d26e1dd18c1146d3d4dcd3b45a3b04f7f7d59, it seems that forgot to remove
> the link in the HTML version.
>
>
Aha, thanks. I will submit a patch to remove the link.

Re: Old installation docs

2021-10-20 Thread Martin Liška 

On 10/20/21 18:59, Jonathan Wakely via Gcc wrote:

On Wed, 20 Oct 2021 at 17:40, Joseph Myers wrote:


On Wed, 20 Oct 2021, Jonathan Wakely via Gcc wrote:


https://gcc.gnu.org/install/ says:

"There are also some old installation instructions
, which are mostly obsolete but

still

contain some information which has not yet been merged into the main part
of this manual."


Those should have been removed in GCC commit
431d26e1dd18c1146d3d4dcd3b45a3b04f7f7d59, it seems that forgot to remove
the link in the HTML version.



Aha, thanks. I will submit a patch to remove the link.



Please do so, I really forgot about it.

Thanks,
Martin

-Waggressive-loop-optimizations errors building glibc tests (32-bit only)

2021-10-20 Thread Joseph Myers 
My build-many-glibcs.py bot is showing new -Waggressive-loop-optimizations 
errors building the glibc testsuite for 32-bit architectures with GCC 
mainline:

In function 'dynarray_long_noscratch_resize',
inlined from 'test_long_overflow' at tst-dynarray.c:489:5,
inlined from 'do_test' at tst-dynarray.c:571:3:
../malloc/dynarray-skeleton.c:391:36: error: iteration 1073741823 invokes 
undefined behavior [-Werror=aggressive-loop-optimizations]
  391 | DYNARRAY_ELEMENT_INIT (&list->u.dynarray_header.array[i]);
tst-dynarray.c:39:37: note: in definition of macro 'DYNARRAY_ELEMENT_INIT'
   39 | #define DYNARRAY_ELEMENT_INIT(e) (*(e) = 23)
  | ^
In file included from tst-dynarray.c:42:
../malloc/dynarray-skeleton.c:389:37: note: within this loop
  389 | for (size_t i = old_size; i < size; ++i)
  |   ~~^~
In function 'dynarray_long_resize',
inlined from 'test_long_overflow' at tst-dynarray.c:479:5,
inlined from 'do_test' at tst-dynarray.c:571:3:
../malloc/dynarray-skeleton.c:391:36: error: iteration 1073741823 invokes 
undefined behavior [-Werror=aggressive-loop-optimizations]
  391 | DYNARRAY_ELEMENT_INIT (&list->u.dynarray_header.array[i]);
tst-dynarray.c:27:37: note: in definition of macro 'DYNARRAY_ELEMENT_INIT'
   27 | #define DYNARRAY_ELEMENT_INIT(e) (*(e) = 17)
  | ^
In file included from tst-dynarray.c:28:
../malloc/dynarray-skeleton.c:389:37: note: within this loop
  389 | for (size_t i = old_size; i < size; ++i)
  |   ~~^~

Preprocessed source for arm-linux-gnueabi attached; build with -O2 -Wall 
-Werror.  I don't know whether it's a GCC or glibc bug, but it seems 
likely to have been introduced by a GCC change (in the range 
4abc0c196b10251dc80d0743ba9e8ab3e56c61ed (exclusive) to 
d8edfadfc7a9795b65177a50ce44fd348858e844 (inclusive) - those are the 
commits of working and failing test runs) rather than a glibc change.

https://sourceware.org/pipermail/libc-testresults/2021q4/008740.html

-- 
Joseph S. Myers
jos...@codesourcery.com

tst-dynarray.i.gz
Description: application/gzip

Re: Old installation docs

2021-10-20 Thread Gerald Pfeifer 
On Wed, 20 Oct 2021, Joseph Myers wrote:
> Those should have been removed in GCC commit 
> 431d26e1dd18c1146d3d4dcd3b45a3b04f7f7d59, it seems that forgot to remove 
> the link in the HTML version.

I'm surprised my link checker has not found this broken link; I'll need 
to look into that.

Thanks for spotting Jonathan, and absolutely agreed with Joseph: yank it
(or I'll do, if you prefer).

Gerald

Re: Old installation docs

2021-10-20 Thread Jonathan Wakely via Gcc 
On Wed, 20 Oct 2021 at 18:10, Martin Liška wrote:

> On 10/20/21 18:59, Jonathan Wakely via Gcc wrote:
> > On Wed, 20 Oct 2021 at 17:40, Joseph Myers wrote:
> >
> >> On Wed, 20 Oct 2021, Jonathan Wakely via Gcc wrote:
> >>
> >>> https://gcc.gnu.org/install/ says:
> >>>
> >>> "There are also some old installation instructions
> >>> , which are mostly obsolete but
> >> still
> >>> contain some information which has not yet been merged into the main
> part
> >>> of this manual."
> >>
> >> Those should have been removed in GCC commit
> >> 431d26e1dd18c1146d3d4dcd3b45a3b04f7f7d59, it seems that forgot to remove
> >> the link in the HTML version.
> >>
> >>
> > Aha, thanks. I will submit a patch to remove the link.
> >
>
> Please do so, I really forgot about it.
>

Done by the attached patch, pushed as r12-4580.
commit 885f9b4ad59a1c37742b68505edc80c7f419d9a4
Author: Jonathan Wakely 
Date:   Wed Oct 20 19:39:15 2021

doc: Remove broken link to old.html docs

The target of this link was removed in r12-1061.

gcc/ChangeLog:

* doc/install.texi: Remove link to old.html

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index edcaae3f55a..7c775965964 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -198,12 +198,6 @@ remove that directory when you do not need that specific 
version of GCC
 any longer, and, if shared libraries are installed there as well, no
 more binaries exist that use them.
 
-@ifhtml
-There are also some @uref{old.html,,old installation instructions},
-which are mostly obsolete but still contain some information which has
-not yet been merged into the main part of this manual.
-@end ifhtml
-
 @html

Re: Old installation docs

2021-10-20 Thread Jonathan Wakely via Gcc 
On Wed, 20 Oct 2021 at 19:44, Gerald Pfeifer wrote:

> On Wed, 20 Oct 2021, Joseph Myers wrote:
> > Those should have been removed in GCC commit
> > 431d26e1dd18c1146d3d4dcd3b45a3b04f7f7d59, it seems that forgot to remove
> > the link in the HTML version.
>
> I'm surprised my link checker has not found this broken link; I'll need
> to look into that.
>

Do you only check links in the pages generated from wwwdocs? Because this
one comes from install.texi in the main sources.



> Thanks for spotting Jonathan, and absolutely agreed with Joseph: yank it
> (or I'll do, if you prefer).
>

I've done it, and refreshed the online copy (which would happen anyway
overnight, but I wanted to check it was OK).