Re: Help needed with maintainer-mode

[Thomas Schwinge]

Hi!

On 2024-03-04T00:30:05+, Sam James  wrote:
> Mark Wielaard  writes:
>> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
>>> [...], I read
>>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
>>> which basically says "run autoreconf in every dir where there is a
>>> configure script"
>>> but this is not exactly what autoregen.py is doing. IIRC it is based
>>> on a script from Martin Liska, do you know/remember why it follows a
>>> different process?
>>
>> CCing Sam and Arsen who helped refine the autoregen.py script, who
>> might remember more details. We wanted a script that worked for both
>> gcc and binutils-gdb. And as far as I know autoreconf simply didn't
>> work in all directories. We also needed to skip some directories that
>> did contain a configure script, but that were imported (gotools,
>> readline, minizip).
>
> What we really need to do is, for a start, land tschwinge/aoliva's patches [0]
> for AC_CONFIG_SUBDIRS.

Let me allocate some time this week to get that one completed.

> Right now, the current situation is janky and it's nowhere near
> idiomatic autotools usage. It is not a comfortable experience
> interacting with it even as someone who is familiar and happy with using
> autotools otherwise.
>
> I didn't yet play with maintainer-mode myself but I also didn't see much
> point given I knew of more fundamental problems like this.
>
> [0] https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/


Grüße
 Thomas

Re: About gsoc

[Jonathan Wakely via Gcc]

On Mon, 4 Mar 2024 at 06:58, mokshagnareddyc--- via Gcc  wrote:
>
> Hello sir/mam
> I am mokshagna reddy from Mahindra university and i am currently in my second 
> year of under graduation in Btech artificial intelligence i had intrest in 
> your organization and i know programming languages like c, c++,python   how 
> can i contribute from now and can u send details about the project . Thank 
> you hope i will get reply as soon as possible.

If you want to apply for GSoC and convince people you're a suitable
candidate and would invest the necessary time and effort, maybe you
should find details of the project for yourself instead of asking
others to provide them.

A simple web search would have found https://gcc.gnu.org/wiki/SummerOfCode

Re: Help needed with maintainer-mode

[Christophe Lyon via Gcc]

Hi!

On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge  wrote:
>
> Hi!
>
> On 2024-03-04T00:30:05+, Sam James  wrote:
> > Mark Wielaard  writes:
> >> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
> >>> [...], I read
> >>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
> >>> which basically says "run autoreconf in every dir where there is a
> >>> configure script"
> >>> but this is not exactly what autoregen.py is doing. IIRC it is based
> >>> on a script from Martin Liska, do you know/remember why it follows a
> >>> different process?
> >>
> >> CCing Sam and Arsen who helped refine the autoregen.py script, who
> >> might remember more details. We wanted a script that worked for both
> >> gcc and binutils-gdb. And as far as I know autoreconf simply didn't
> >> work in all directories. We also needed to skip some directories that
> >> did contain a configure script, but that were imported (gotools,
> >> readline, minizip).
> >
> > What we really need to do is, for a start, land tschwinge/aoliva's patches 
> > [0]
> > for AC_CONFIG_SUBDIRS.
>
> Let me allocate some time this week to get that one completed.
>
> > Right now, the current situation is janky and it's nowhere near
> > idiomatic autotools usage. It is not a comfortable experience
> > interacting with it even as someone who is familiar and happy with using
> > autotools otherwise.
> >
> > I didn't yet play with maintainer-mode myself but I also didn't see much
> > point given I knew of more fundamental problems like this.
> >
> > [0] 
> > https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/
>

Thanks for the background. I didn't follow that discussion at that time :-)

So... I was confused because I noticed many warnings when doing a simple
find . -name configure |while read f; do echo $f;d=$(dirname $f) &&
autoreconf -f $d && echo $d; done
as suggested by https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration

Then I tried with autoregen.py, and saw the same and now just
checked Sourceware's bot logs and saw the same numerous warnings at
least in GCC (didn't check binutils yet). Looks like this is
"expected" 

I started looking at auto-regenerating these files in our CI a couple
of weeks ago, after we received several "complaints" from contributors
saying that our precommit CI was useless / bothering since it didn't
regenerate files, leading to false alarms.
But now I'm wondering how such contributors regenerate the files
impacted by their patches before committing, they probably just
regenerate things in their subdir of interest, not noticing the whole
picture :-(

As a first step, we can probably use autoregen.py too, and declare
maintainer-mode broken. However, I do notice that besides the rules
about regenerating configure/Makefile.in/..., maintainer-mode is also
used to update some files.
In gcc:
fixincludes: fixincl.x
libffi: doc/version.texi
libgfortran: some stuff :-)
libiberty: functions.texi

in binutils/bfd:
gdb/sim
bfd/po/SRC-POTFILES.in
bfd/po/BLD-POTFILES.in
bfd/bfd-in2.h
bfd/libbfd.h
bfd/libcoff.h
binutils/po/POTFILES.in
gas/po/POTFILES.in
opcodes/i386*.h
gdb/copying.c
gdb/data-directory/*.xml
gold/po/POTFILES.in
gprof/po/POTFILES.in
gfprofng/doc/version.texi
ld/po/SRC-POTFILES.in
ld/po/BLD-POTFILES.in
ld: ldgram/ldlex... and all emulation sources
libiberty/functions.texi
opcodes/po/POTFILES.in
opcodes/aarch64-{asm,dis,opc}-2.c
opcodes/ia64 msp430 rl78 rx z8k decoders

How are these files "normally" expected to be updated? Do people just
manually uncomment the corresponding maintainer lines in the Makefiles
and update manually?   In particular we hit issues several times with
files under opcodes, that we don't regenerate currently. Maybe we
could build binutils in maintainer-mode at -j1 but, well

README-maintainer-mode in binutils/gdb only mentions a problem with
'make distclean' and maintainer mode
binutils/README-how-to-make-a-release indicates to use
--enable-maintainer-mode, and the sample 'make' invocations do not
include any -j flag, is that an indication that only -j1 is supposed
to work?
Similarly, the src-release.sh script does not use -j.

Thanks,

Christophe

>
> Grüße
>  Thomas

Re: Help needed with maintainer-mode

[Jonathan Wakely via Gcc]

On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc  wrote:
>
> Hi!
>
> On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge  wrote:
> >
> > Hi!
> >
> > On 2024-03-04T00:30:05+, Sam James  wrote:
> > > Mark Wielaard  writes:
> > >> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
> > >>> [...], I read
> > >>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
> > >>> which basically says "run autoreconf in every dir where there is a
> > >>> configure script"
> > >>> but this is not exactly what autoregen.py is doing. IIRC it is based
> > >>> on a script from Martin Liska, do you know/remember why it follows a
> > >>> different process?
> > >>
> > >> CCing Sam and Arsen who helped refine the autoregen.py script, who
> > >> might remember more details. We wanted a script that worked for both
> > >> gcc and binutils-gdb. And as far as I know autoreconf simply didn't
> > >> work in all directories. We also needed to skip some directories that
> > >> did contain a configure script, but that were imported (gotools,
> > >> readline, minizip).
> > >
> > > What we really need to do is, for a start, land tschwinge/aoliva's 
> > > patches [0]
> > > for AC_CONFIG_SUBDIRS.
> >
> > Let me allocate some time this week to get that one completed.
> >
> > > Right now, the current situation is janky and it's nowhere near
> > > idiomatic autotools usage. It is not a comfortable experience
> > > interacting with it even as someone who is familiar and happy with using
> > > autotools otherwise.
> > >
> > > I didn't yet play with maintainer-mode myself but I also didn't see much
> > > point given I knew of more fundamental problems like this.
> > >
> > > [0] 
> > > https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/
> >
>
> Thanks for the background. I didn't follow that discussion at that time :-)
>
> So... I was confused because I noticed many warnings when doing a simple
> find . -name configure |while read f; do echo $f;d=$(dirname $f) &&
> autoreconf -f $d && echo $d; done
> as suggested by https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
>
> Then I tried with autoregen.py, and saw the same and now just
> checked Sourceware's bot logs and saw the same numerous warnings at
> least in GCC (didn't check binutils yet). Looks like this is
> "expected" 
>
> I started looking at auto-regenerating these files in our CI a couple
> of weeks ago, after we received several "complaints" from contributors
> saying that our precommit CI was useless / bothering since it didn't
> regenerate files, leading to false alarms.
> But now I'm wondering how such contributors regenerate the files
> impacted by their patches before committing, they probably just
> regenerate things in their subdir of interest, not noticing the whole
> picture :-(
>
> As a first step, we can probably use autoregen.py too, and declare
> maintainer-mode broken. However, I do notice that besides the rules
> about regenerating configure/Makefile.in/..., maintainer-mode is also
> used to update some files.
> In gcc:
> fixincludes: fixincl.x
> libffi: doc/version.texi
> libgfortran: some stuff :-)
> libiberty: functions.texi

My recently proposed patch adds the first of those to gcc_update, the
other should be done too.
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647027.html



>
> in binutils/bfd:
> gdb/sim
> bfd/po/SRC-POTFILES.in
> bfd/po/BLD-POTFILES.in
> bfd/bfd-in2.h
> bfd/libbfd.h
> bfd/libcoff.h
> binutils/po/POTFILES.in
> gas/po/POTFILES.in
> opcodes/i386*.h
> gdb/copying.c
> gdb/data-directory/*.xml
> gold/po/POTFILES.in
> gprof/po/POTFILES.in
> gfprofng/doc/version.texi
> ld/po/SRC-POTFILES.in
> ld/po/BLD-POTFILES.in
> ld: ldgram/ldlex... and all emulation sources
> libiberty/functions.texi
> opcodes/po/POTFILES.in
> opcodes/aarch64-{asm,dis,opc}-2.c
> opcodes/ia64 msp430 rl78 rx z8k decoders
>
> How are these files "normally" expected to be updated? Do people just
> manually uncomment the corresponding maintainer lines in the Makefiles
> and update manually?   In particular we hit issues several times with
> files under opcodes, that we don't regenerate currently. Maybe we
> could build binutils in maintainer-mode at -j1 but, well
>
> README-maintainer-mode in binutils/gdb only mentions a problem with
> 'make distclean' and maintainer mode
> binutils/README-how-to-make-a-release indicates to use
> --enable-maintainer-mode, and the sample 'make' invocations do not
> include any -j flag, is that an indication that only -j1 is supposed
> to work?
> Similarly, the src-release.sh script does not use -j.
>
> Thanks,
>
> Christophe
>
> >
> > Grüße
> >  Thomas

GCC 14.0.1 Status Report (2024-03-04)

[Richard Biener via Gcc]

Status
==

The GCC development branch which will become GCC 14 is still
in regression and documentation fixes only mode (Stage 4).

GCC 14.1 will be released when we reach the milestone of
zero P1 regressions.

We've been into regression fixing for a good month now and at
least the pace of new important bugs reported is slowing.  We
still have to make good quite a number of regressions, esp.
also on the testsuite side.


Quality Data


Priority  #   Change from last report
---   ---
P1   14-  18
P2  506+   2
P3  244+   3
P4  228+  17
P5   26+   1   
---   ---
Total P1-P3 764-  13
Total  1018+   5


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2024-January/243148.html

Re: Help needed with maintainer-mode

[Christophe Lyon via Gcc]

On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely  wrote:
>
> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc  wrote:
> >
> > Hi!
> >
> > On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge  wrote:
> > >
> > > Hi!
> > >
> > > On 2024-03-04T00:30:05+, Sam James  wrote:
> > > > Mark Wielaard  writes:
> > > >> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
> > > >>> [...], I read
> > > >>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
> > > >>> which basically says "run autoreconf in every dir where there is a
> > > >>> configure script"
> > > >>> but this is not exactly what autoregen.py is doing. IIRC it is based
> > > >>> on a script from Martin Liska, do you know/remember why it follows a
> > > >>> different process?
> > > >>
> > > >> CCing Sam and Arsen who helped refine the autoregen.py script, who
> > > >> might remember more details. We wanted a script that worked for both
> > > >> gcc and binutils-gdb. And as far as I know autoreconf simply didn't
> > > >> work in all directories. We also needed to skip some directories that
> > > >> did contain a configure script, but that were imported (gotools,
> > > >> readline, minizip).
> > > >
> > > > What we really need to do is, for a start, land tschwinge/aoliva's 
> > > > patches [0]
> > > > for AC_CONFIG_SUBDIRS.
> > >
> > > Let me allocate some time this week to get that one completed.
> > >
> > > > Right now, the current situation is janky and it's nowhere near
> > > > idiomatic autotools usage. It is not a comfortable experience
> > > > interacting with it even as someone who is familiar and happy with using
> > > > autotools otherwise.
> > > >
> > > > I didn't yet play with maintainer-mode myself but I also didn't see much
> > > > point given I knew of more fundamental problems like this.
> > > >
> > > > [0] 
> > > > https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/
> > >
> >
> > Thanks for the background. I didn't follow that discussion at that time :-)
> >
> > So... I was confused because I noticed many warnings when doing a simple
> > find . -name configure |while read f; do echo $f;d=$(dirname $f) &&
> > autoreconf -f $d && echo $d; done
> > as suggested by https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
> >
> > Then I tried with autoregen.py, and saw the same and now just
> > checked Sourceware's bot logs and saw the same numerous warnings at
> > least in GCC (didn't check binutils yet). Looks like this is
> > "expected" 
> >
> > I started looking at auto-regenerating these files in our CI a couple
> > of weeks ago, after we received several "complaints" from contributors
> > saying that our precommit CI was useless / bothering since it didn't
> > regenerate files, leading to false alarms.
> > But now I'm wondering how such contributors regenerate the files
> > impacted by their patches before committing, they probably just
> > regenerate things in their subdir of interest, not noticing the whole
> > picture :-(
> >
> > As a first step, we can probably use autoregen.py too, and declare
> > maintainer-mode broken. However, I do notice that besides the rules
> > about regenerating configure/Makefile.in/..., maintainer-mode is also
> > used to update some files.
> > In gcc:
> > fixincludes: fixincl.x
> > libffi: doc/version.texi
> > libgfortran: some stuff :-)
> > libiberty: functions.texi
>
> My recently proposed patch adds the first of those to gcc_update, the
> other should be done too.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647027.html
>

This script touches files such that they appear more recent than their
dependencies,
so IIUC even if one uses --enable-maintainer-mode, it will have no effect.
For auto* files, this is "fine" as we can run autoreconf or
autoregen.py before starting configure+build, but what about other
files?
For instance, if we have to test a patch which implies changes to
fixincludes/fixincl.x, how should we proceed?
1- git checkout (with possibly "wrong" timestamps)
2- apply patch-to-test
3- contrib/gcc_update -t
4- configure --enable-maintainer-mode

I guess --enable-maintainer-mode would be largely (if not completely)
disabled by step 3 above?
And we should probably swap steps 2 and 3, so that the effects of
patch-to-test are handled by make?

Thanks,

Christophe

>
>
> >
> > in binutils/bfd:
> > gdb/sim
> > bfd/po/SRC-POTFILES.in
> > bfd/po/BLD-POTFILES.in
> > bfd/bfd-in2.h
> > bfd/libbfd.h
> > bfd/libcoff.h
> > binutils/po/POTFILES.in
> > gas/po/POTFILES.in
> > opcodes/i386*.h
> > gdb/copying.c
> > gdb/data-directory/*.xml
> > gold/po/POTFILES.in
> > gprof/po/POTFILES.in
> > gfprofng/doc/version.texi
> > ld/po/SRC-POTFILES.in
> > ld/po/BLD-POTFILES.in
> > ld: ldgram/ldlex... and all emulation sources
> > libiberty/functions.texi
> > opcodes/po/POTFILES.in
> > opcodes/aarch64-{asm,dis,opc}-2.c
> > opcodes/ia64 msp430 rl78 rx z8k decoders
> >
> > How are these files "normally" expected to be updated? Do people just
> > manually uncomment the 

GNU Tools Cauldron 2024

[Jeremy Bennett]

Hi all,

We are starting to put together the plans for this year's Cauldron.  We 
have a suggested date of 13-15 September, the weekend before LPC.


We have not finalized a host for the meeting. If you wish to host, 
please let me, David Edelsohn, Carlos O'Donnell or Jan Hubicka know ASAP.


Thanks,


Jeremy
--
Cell: +44 7970 676050 (UK), +49 172 683 5745 (Germany)
SkypeID: jeremybennett
Twitter: @jeremypbennett
Email: jeremy.benn...@embecosm.com
Web: www.embecosm.com
PGP key: 1024D/BEF58172FB4754E1 2009-03-20


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Help needed with maintainer-mode

[Richard Earnshaw (lists) via Gcc]

On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely  wrote:
>>
>> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc  wrote:
>>>
>>> Hi!
>>>
>>> On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge  wrote:

 Hi!

 On 2024-03-04T00:30:05+, Sam James  wrote:
> Mark Wielaard  writes:
>> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
>>> [...], I read
>>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
>>> which basically says "run autoreconf in every dir where there is a
>>> configure script"
>>> but this is not exactly what autoregen.py is doing. IIRC it is based
>>> on a script from Martin Liska, do you know/remember why it follows a
>>> different process?
>>
>> CCing Sam and Arsen who helped refine the autoregen.py script, who
>> might remember more details. We wanted a script that worked for both
>> gcc and binutils-gdb. And as far as I know autoreconf simply didn't
>> work in all directories. We also needed to skip some directories that
>> did contain a configure script, but that were imported (gotools,
>> readline, minizip).
>
> What we really need to do is, for a start, land tschwinge/aoliva's 
> patches [0]
> for AC_CONFIG_SUBDIRS.

 Let me allocate some time this week to get that one completed.

> Right now, the current situation is janky and it's nowhere near
> idiomatic autotools usage. It is not a comfortable experience
> interacting with it even as someone who is familiar and happy with using
> autotools otherwise.
>
> I didn't yet play with maintainer-mode myself but I also didn't see much
> point given I knew of more fundamental problems like this.
>
> [0] 
> https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/

>>>
>>> Thanks for the background. I didn't follow that discussion at that time :-)
>>>
>>> So... I was confused because I noticed many warnings when doing a simple
>>> find . -name configure |while read f; do echo $f;d=$(dirname $f) &&
>>> autoreconf -f $d && echo $d; done
>>> as suggested by https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
>>>
>>> Then I tried with autoregen.py, and saw the same and now just
>>> checked Sourceware's bot logs and saw the same numerous warnings at
>>> least in GCC (didn't check binutils yet). Looks like this is
>>> "expected" 
>>>
>>> I started looking at auto-regenerating these files in our CI a couple
>>> of weeks ago, after we received several "complaints" from contributors
>>> saying that our precommit CI was useless / bothering since it didn't
>>> regenerate files, leading to false alarms.
>>> But now I'm wondering how such contributors regenerate the files
>>> impacted by their patches before committing, they probably just
>>> regenerate things in their subdir of interest, not noticing the whole
>>> picture :-(
>>>
>>> As a first step, we can probably use autoregen.py too, and declare
>>> maintainer-mode broken. However, I do notice that besides the rules
>>> about regenerating configure/Makefile.in/..., maintainer-mode is also
>>> used to update some files.
>>> In gcc:
>>> fixincludes: fixincl.x
>>> libffi: doc/version.texi
>>> libgfortran: some stuff :-)
>>> libiberty: functions.texi
>>
>> My recently proposed patch adds the first of those to gcc_update, the
>> other should be done too.
>> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647027.html
>>
> 
> This script touches files such that they appear more recent than their
> dependencies,
> so IIUC even if one uses --enable-maintainer-mode, it will have no effect.
> For auto* files, this is "fine" as we can run autoreconf or
> autoregen.py before starting configure+build, but what about other
> files?
> For instance, if we have to test a patch which implies changes to
> fixincludes/fixincl.x, how should we proceed?
> 1- git checkout (with possibly "wrong" timestamps)
> 2- apply patch-to-test
> 3- contrib/gcc_update -t
> 4- configure --enable-maintainer-mode

If you ran

git reset --hard master // restore state to 'master'
contrib/gcc_update // pull latest code

then anything coming from upstream will be touched automatically.  You really 
don't want to re-touch the files after patching unless you're sure they've all 
been patched correctly, it will break if there's anything regenerated that's 
missing.

R.

> 
> I guess --enable-maintainer-mode would be largely (if not completely)
> disabled by step 3 above?
> And we should probably swap steps 2 and 3, so that the effects of
> patch-to-test are handled by make?
> 
> Thanks,
> 
> Christophe
> 
>>
>>
>>>
>>> in binutils/bfd:
>>> gdb/sim
>>> bfd/po/SRC-POTFILES.in
>>> bfd/po/BLD-POTFILES.in
>>> bfd/bfd-in2.h
>>> bfd/libbfd.h
>>> bfd/libcoff.h
>>> binutils/po/POTFILES.in
>>> gas/po/POTFILES.in
>>> opcodes/i386*.h
>>> gdb/copying.c
>>> gdb/data-directory/*.xml
>>> gold/po/POTFILES.in
>>>

Re: Help needed with maintainer-mode

[Richard Earnshaw via Gcc]

On 04/03/2024 15:36, Richard Earnshaw (lists) wrote:
> On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
>> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely  wrote:
>>>
>>> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc  
>>> wrote:

 Hi!

 On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge  
 wrote:
>
> Hi!
>
> On 2024-03-04T00:30:05+, Sam James  wrote:
>> Mark Wielaard  writes:
>>> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
 [...], I read
 https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration 
 
 which basically says "run autoreconf in every dir where there is a
 configure script"
 but this is not exactly what autoregen.py is doing. IIRC it is based
 on a script from Martin Liska, do you know/remember why it follows a
 different process?
>>>
>>> CCing Sam and Arsen who helped refine the autoregen.py script, who
>>> might remember more details. We wanted a script that worked for both
>>> gcc and binutils-gdb. And as far as I know autoreconf simply didn't
>>> work in all directories. We also needed to skip some directories that
>>> did contain a configure script, but that were imported (gotools,
>>> readline, minizip).
>>
>> What we really need to do is, for a start, land tschwinge/aoliva's 
>> patches [0]
>> for AC_CONFIG_SUBDIRS.
>
> Let me allocate some time this week to get that one completed.
>
>> Right now, the current situation is janky and it's nowhere near
>> idiomatic autotools usage. It is not a comfortable experience
>> interacting with it even as someone who is familiar and happy with using
>> autotools otherwise.
>>
>> I didn't yet play with maintainer-mode myself but I also didn't see much
>> point given I knew of more fundamental problems like this.
>>
>> [0] 
>> https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/
>>  
>> 
>

 Thanks for the background. I didn't follow that discussion at that time :-)

 So... I was confused because I noticed many warnings when doing a simple
 find . -name configure |while read f; do echo $f;d=$(dirname $f) &&
 autoreconf -f $d && echo $d; done
 as suggested by https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration 
 

 Then I tried with autoregen.py, and saw the same and now just
 checked Sourceware's bot logs and saw the same numerous warnings at
 least in GCC (didn't check binutils yet). Looks like this is
 "expected" 

 I started looking at auto-regenerating these files in our CI a couple
 of weeks ago, after we received several "complaints" from contributors
 saying that our precommit CI was useless / bothering since it didn't
 regenerate files, leading to false alarms.
 But now I'm wondering how such contributors regenerate the files
 impacted by their patches before committing, they probably just
 regenerate things in their subdir of interest, not noticing the whole
 picture :-(

 As a first step, we can probably use autoregen.py too, and declare
 maintainer-mode broken. However, I do notice that besides the rules
 about regenerating configure/Makefile.in/..., maintainer-mode is also
 used to update some files.
 In gcc:
 fixincludes: fixincl.x
 libffi: doc/version.texi
 libgfortran: some stuff :-)
 libiberty: functions.texi
>>>
>>> My recently proposed patch adds the first of those to gcc_update, the
>>> other should be done too.
>>> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647027.html 
>>> 
>>>
>> 
>> This script touches files such that they appear more recent than their
>> dependencies,
>> so IIUC even if one uses --enable-maintainer-mode, it will have no effect.
>> For auto* files, this is "fine" as we can run autoreconf or
>> autoregen.py before starting configure+build, but what about other
>> files?
>> For instance, if we have to test a patch which implies changes to
>> fixincludes/fixincl.x, how should we proceed?
>> 1- git checkout (with possibly "wrong" timestamps)
>> 2- apply patch-to-test
>> 3- contrib/gcc_update -t
>> 4- configure --enable-maintainer-mode
> 
> If you ran
> 
> git reset --hard master // restore state to 'master'
> contrib/gcc_update // pull latest code
> 
> then anything coming from upstream will be touched automatically.  You really 
> don't want to re-touch the files after patching unless you're sure they've 
> all been patched correctly, it will break if there's anything regenerated 
> that's missing.
> 
> R.

Alternatively, if you did 

git reset --hard master

Re: Help needed with maintainer-mode

[Christophe Lyon via Gcc]

On Mon, 4 Mar 2024 at 16:41, Richard Earnshaw  wrote:
>
>
>
> On 04/03/2024 15:36, Richard Earnshaw (lists) wrote:
> > On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
> >> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely  wrote:
> >>>
> >>> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc  
> >>> wrote:
> 
>  Hi!
> 
>  On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge  
>  wrote:
> >
> > Hi!
> >
> > On 2024-03-04T00:30:05+, Sam James  wrote:
> >> Mark Wielaard  writes:
> >>> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
>  [...], I read
>  https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration 
>  
>  which basically says "run autoreconf in every dir where there is a
>  configure script"
>  but this is not exactly what autoregen.py is doing. IIRC it is based
>  on a script from Martin Liska, do you know/remember why it follows a
>  different process?
> >>>
> >>> CCing Sam and Arsen who helped refine the autoregen.py script, who
> >>> might remember more details. We wanted a script that worked for both
> >>> gcc and binutils-gdb. And as far as I know autoreconf simply didn't
> >>> work in all directories. We also needed to skip some directories that
> >>> did contain a configure script, but that were imported (gotools,
> >>> readline, minizip).
> >>
> >> What we really need to do is, for a start, land tschwinge/aoliva's 
> >> patches [0]
> >> for AC_CONFIG_SUBDIRS.
> >
> > Let me allocate some time this week to get that one completed.
> >
> >> Right now, the current situation is janky and it's nowhere near
> >> idiomatic autotools usage. It is not a comfortable experience
> >> interacting with it even as someone who is familiar and happy with 
> >> using
> >> autotools otherwise.
> >>
> >> I didn't yet play with maintainer-mode myself but I also didn't see 
> >> much
> >> point given I knew of more fundamental problems like this.
> >>
> >> [0] 
> >> https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/
> >>  
> >> 
> >
> 
>  Thanks for the background. I didn't follow that discussion at that time 
>  :-)
> 
>  So... I was confused because I noticed many warnings when doing a simple
>  find . -name configure |while read f; do echo $f;d=$(dirname $f) &&
>  autoreconf -f $d && echo $d; done
>  as suggested by https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration 
>  
> 
>  Then I tried with autoregen.py, and saw the same and now just
>  checked Sourceware's bot logs and saw the same numerous warnings at
>  least in GCC (didn't check binutils yet). Looks like this is
>  "expected" 
> 
>  I started looking at auto-regenerating these files in our CI a couple
>  of weeks ago, after we received several "complaints" from contributors
>  saying that our precommit CI was useless / bothering since it didn't
>  regenerate files, leading to false alarms.
>  But now I'm wondering how such contributors regenerate the files
>  impacted by their patches before committing, they probably just
>  regenerate things in their subdir of interest, not noticing the whole
>  picture :-(
> 
>  As a first step, we can probably use autoregen.py too, and declare
>  maintainer-mode broken. However, I do notice that besides the rules
>  about regenerating configure/Makefile.in/..., maintainer-mode is also
>  used to update some files.
>  In gcc:
>  fixincludes: fixincl.x
>  libffi: doc/version.texi
>  libgfortran: some stuff :-)
>  libiberty: functions.texi
> >>>
> >>> My recently proposed patch adds the first of those to gcc_update, the
> >>> other should be done too.
> >>> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647027.html 
> >>> 
> >>>
> >>
> >> This script touches files such that they appear more recent than their
> >> dependencies,
> >> so IIUC even if one uses --enable-maintainer-mode, it will have no effect.
> >> For auto* files, this is "fine" as we can run autoreconf or
> >> autoregen.py before starting configure+build, but what about other
> >> files?
> >> For instance, if we have to test a patch which implies changes to
> >> fixincludes/fixincl.x, how should we proceed?
> >> 1- git checkout (with possibly "wrong" timestamps)
> >> 2- apply patch-to-test
> >> 3- contrib/gcc_update -t
> >> 4- configure --enable-maintainer-mode
> >
> > If you ran
> >
> > git reset --hard master // restore state to 'master'
> > contrib/gcc_update // pull latest code
> >
> > then anythi

Re: Help needed with maintainer-mode

[Richard Earnshaw (lists) via Gcc]

On 04/03/2024 16:42, Christophe Lyon wrote:
> On Mon, 4 Mar 2024 at 16:41, Richard Earnshaw  
> wrote:
>>
>>
>>
>> On 04/03/2024 15:36, Richard Earnshaw (lists) wrote:
>> > On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
>> >> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely  
>> >> wrote:
>> >>>
>> >>> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc  
>> >>> wrote:
>> 
>>  Hi!
>> 
>>  On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge  
>>  wrote:
>> >
>> > Hi!
>> >
>> > On 2024-03-04T00:30:05+, Sam James  wrote:
>> >> Mark Wielaard  writes:
>> >>> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
>>  [...], I read
>>  https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration 
>>   
>>  >  >
>>  which basically says "run autoreconf in every dir where there is a
>>  configure script"
>>  but this is not exactly what autoregen.py is doing. IIRC it is based
>>  on a script from Martin Liska, do you know/remember why it follows a
>>  different process?
>> >>>
>> >>> CCing Sam and Arsen who helped refine the autoregen.py script, who
>> >>> might remember more details. We wanted a script that worked for both
>> >>> gcc and binutils-gdb. And as far as I know autoreconf simply didn't
>> >>> work in all directories. We also needed to skip some directories that
>> >>> did contain a configure script, but that were imported (gotools,
>> >>> readline, minizip).
>> >>
>> >> What we really need to do is, for a start, land tschwinge/aoliva's 
>> >> patches [0]
>> >> for AC_CONFIG_SUBDIRS.
>> >
>> > Let me allocate some time this week to get that one completed.
>> >
>> >> Right now, the current situation is janky and it's nowhere near
>> >> idiomatic autotools usage. It is not a comfortable experience
>> >> interacting with it even as someone who is familiar and happy with 
>> >> using
>> >> autotools otherwise.
>> >>
>> >> I didn't yet play with maintainer-mode myself but I also didn't see 
>> >> much
>> >> point given I knew of more fundamental problems like this.
>> >>
>> >> [0] 
>> >> https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/
>> >>  
>> >> 
>> >>  
>> >> > >>  
>> >> >
>> >
>> 
>>  Thanks for the background. I didn't follow that discussion at that time 
>>  :-)
>> 
>>  So... I was confused because I noticed many warnings when doing a simple
>>  find . -name configure |while read f; do echo $f;d=$(dirname $f) &&
>>  autoreconf -f $d && echo $d; done
>>  as suggested by https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration 
>>   
>>  >  >
>> 
>>  Then I tried with autoregen.py, and saw the same and now just
>>  checked Sourceware's bot logs and saw the same numerous warnings at
>>  least in GCC (didn't check binutils yet). Looks like this is
>>  "expected" 
>> 
>>  I started looking at auto-regenerating these files in our CI a couple
>>  of weeks ago, after we received several "complaints" from contributors
>>  saying that our precommit CI was useless / bothering since it didn't
>>  regenerate files, leading to false alarms.
>>  But now I'm wondering how such contributors regenerate the files
>>  impacted by their patches before committing, they probably just
>>  regenerate things in their subdir of interest, not noticing the whole
>>  picture :-(
>> 
>>  As a first step, we can probably use autoregen.py too, and declare
>>  maintainer-mode broken. However, I do notice that besides the rules
>>  about regenerating configure/Makefile.in/..., maintainer-mode is also
>>  used to update some files.
>>  In gcc:
>>  fixincludes: fixincl.x
>>  libffi: doc/version.texi
>>  libgfortran: some stuff :-)
>>  libiberty: functions.texi
>> >>>
>> >>> My recently proposed patch adds the first of those to gcc_update, the
>> >>> other should be done too.
>> >>> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647027.html 
>> >>>  
>> >>> > >>> 

Re: Help needed with maintainer-mode

[Vladimir Mezentsev via Gcc]

On 3/4/24 09:38, Richard Earnshaw (lists) wrote:

Tools like git (and svn before it) don't try to maintain time-stamps on 
patches, the tool just modifies the file and the timestamp comes from the time 
of the modification.  That's fine if there is nothing regenerated within the 
repository (it's pure original source), but will cause problems if there are 
generated files as their time stamps aren't necessarily correct.  `gcc_update 
--touch` addresses that by ensuring all the generated files are retouched when 
needed.


Why do we save generated files in the source tree?
What will be the problem if we remove Makefile.in and configure from 
source tree and will run `autoreconf -i -f` before building ?

Re: Help needed with maintainer-mode

[Jonathan Wakely via Gcc]

On Mon, 4 Mar 2024 at 19:27, Vladimir Mezentsev
 wrote:
>
>
>
> On 3/4/24 09:38, Richard Earnshaw (lists) wrote:
> > Tools like git (and svn before it) don't try to maintain time-stamps on 
> > patches, the tool just modifies the file and the timestamp comes from the 
> > time of the modification.  That's fine if there is nothing regenerated 
> > within the repository (it's pure original source), but will cause problems 
> > if there are generated files as their time stamps aren't necessarily 
> > correct.  `gcc_update --touch` addresses that by ensuring all the generated 
> > files are retouched when needed.
>
> Why do we save generated files in the source tree?
> What will be the problem if we remove Makefile.in and configure from
> source tree and will run `autoreconf -i -f` before building ?

Having the exact correct versions of autoconf and automake increases
the barrier for new contributors to start work. And to regenerate
everything, they also need autogen, mkinfo, etc.

Re: [GSoC][Improve nothrow detection]: Suggestions to get started

[Ken Matsui via Gcc]

Ping for [GSoC][Improve nothrow detection]: Suggestions to get started.

Could you please take a look when you get a chance?

Sincerely,
Ken Matsui

On Wed, Feb 28, 2024 at 8:00 AM Ken Matsui  wrote:
>
> Hi Jan,
>
> My name is Ken Matsui.  I am highly interested in contributing to your
> GSoC 2024 project idea, "Improve nothrow detection in GCC."  To get
> started with understanding your project (and, if possible, making
> small patches), could you please give me some suggestions on what
> files to read (and edit) and what to do first?
>
> Thank you for your help!
>
> Sincerely,
> Ken Matsui

Re: About gsoc

[Dave Blanchard]

On Mon, 4 Mar 2024 10:06:34 +
Jonathan Wakely via Gcc  wrote:

> On Mon, 4 Mar 2024 at 06:58, mokshagnareddyc--- via Gcc  
> wrote:
> >
> > Hello sir/mam
> > I am mokshagna reddy from Mahindra university and i am currently in my 
> > second year of under graduation in Btech artificial intelligence i had 
> > intrest in your organization and i know programming languages like c, 
> > c++,python   how can i contribute from now and can u send details about the 
> > project . Thank you hope i will get reply as soon as possible.
> 
> If you want to apply for GSoC and convince people you're a suitable
> candidate and would invest the necessary time and effort, maybe you
> should find details of the project for yourself instead of asking
> others to provide them.
> 
> A simple web search would have found https://gcc.gnu.org/wiki/SummerOfCode

Wow, what a fucking prick this guy is.

My apologies to our friend Mr. Mokshagna Reddy for this extreme rudeness. 

Maybe he did you a favor with such a response. Why should anyone waste their 
time and energy donating free work to a dumpster fire project like GCC, when 
this is the thanks you get? I recommend contributing your valuable time to 
LLVM/clang or some other non-GNU project instead, where it will likely be more 
appreciated.

Dave