libstdc++: Allow new-abi-baseline target to overwrite existing file

  There doesn't seem to be much benefit to writing the symbols to
baseline_symbols.txt.new when an existing file is already present. It
just adds a manual step for maintainers to move the .txt.new file to
replace the .txt one. Overwriting the file directly allows you to use
git diff to see what changed immediately, and you can easly use git
commands to revert to the original file too.

libstdc++-v3/ChangeLog:

	* testsuite/Makefile.am (new-abi-baseline): Overwrite existing
	file instead of creating baseline_symbols.txt.new.
	* testsuite/Makefile.in: Regenerate.
---

Does anybody prefer the way it works now? I don't, but I'd like to hear
from target maintainers who do most of the work to update the baseline
files.

Tested x86_64-linux.

No doc updates needed as far as I can tell, we don't mention the .new
file in the manual, we just say "written to a file under
libsrcdir/config/abi/post/target/"

 libstdc++-v3/testsuite/Makefile.am | 8 +-------
 libstdc++-v3/testsuite/Makefile.in | 8 +-------
 2 files changed, 2 insertions(+), 14 deletions(-)
  

Hi Jonathan,

> There doesn't seem to be much benefit to writing the symbols to
> baseline_symbols.txt.new when an existing file is already present. It
> just adds a manual step for maintainers to move the .txt.new file to
> replace the .txt one. Overwriting the file directly allows you to use
> git diff to see what changed immediately, and you can easly use git
> commands to revert to the original file too.
>
> libstdc++-v3/ChangeLog:
>
> 	* testsuite/Makefile.am (new-abi-baseline): Overwrite existing
> 	file instead of creating baseline_symbols.txt.new.
> 	* testsuite/Makefile.in: Regenerate.
> ---
>
> Does anybody prefer the way it works now? I don't, but I'd like to hear
> from target maintainers who do most of the work to update the baseline
> files.

I've one concern, though: sometimes you need to remove some changes from
the regenerated baselines (don't have an examply handy, but am pretty
sure this has happened in the past).  If you make updating the baseline
too easy, something like this might be missed more easily :-)

Apart from that, no objections from me.

	Rainer
  

On Wed, 7 Jan 2026 at 15:00, Rainer Orth wrote:
>
> Hi Jonathan,
>
> > There doesn't seem to be much benefit to writing the symbols to
> > baseline_symbols.txt.new when an existing file is already present. It
> > just adds a manual step for maintainers to move the .txt.new file to
> > replace the .txt one. Overwriting the file directly allows you to use
> > git diff to see what changed immediately, and you can easly use git
> > commands to revert to the original file too.
> >
> > libstdc++-v3/ChangeLog:
> >
> >       * testsuite/Makefile.am (new-abi-baseline): Overwrite existing
> >       file instead of creating baseline_symbols.txt.new.
> >       * testsuite/Makefile.in: Regenerate.
> > ---
> >
> > Does anybody prefer the way it works now? I don't, but I'd like to hear
> > from target maintainers who do most of the work to update the baseline
> > files.
>
> I've one concern, though: sometimes you need to remove some changes from
> the regenerated baselines (don't have an examply handy, but am pretty
> sure this has happened in the past).  If you make updating the baseline
> too easy, something like this might be missed more easily :-)

I did consider that, because when I ran it to test the changes, 'git
diff' showed the TLS symbols that we don't want to commit to the
x86_64-pc-linux-gnu baseline.

But I'm not sure if it really makes it too easy? I doubt anybody is
copying individual changes from the .new file to the real one, surely
they just do 'mv foo.txt.new foo.txt' and then use 'git diff', and in
that case, they still need to manually remove some changes.

It would only be a problem if people run the make target, then do git
commit without checking the diff. But they could already do that today
after mv'ing the file.

I actually find it easier to remove individual changes using git,
because I can do 'git diff add -p' to choose which changes to stage,
then 'git restore --staged' to discard the unwanted changes from the
working tree. And to do that, the existing file needs to have been
overwritten by the new one.

> Apart from that, no objections from me.
>
>         Rainer
>
> --
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
  

Hi Jonathan,

>> I've one concern, though: sometimes you need to remove some changes from
>> the regenerated baselines (don't have an examply handy, but am pretty
>> sure this has happened in the past).  If you make updating the baseline
>> too easy, something like this might be missed more easily :-)
>
> I did consider that, because when I ran it to test the changes, 'git
> diff' showed the TLS symbols that we don't want to commit to the
> x86_64-pc-linux-gnu baseline.
>
> But I'm not sure if it really makes it too easy? I doubt anybody is
> copying individual changes from the .new file to the real one, surely
> they just do 'mv foo.txt.new foo.txt' and then use 'git diff', and in
> that case, they still need to manually remove some changes.
>
> It would only be a problem if people run the make target, then do git
> commit without checking the diff. But they could already do that today
> after mv'ing the file.

I'd hope this would be caught during review, though: I believe that even
baseline updates need to go through patch review first, right?

As I said: it not a serious concern, just something to think about.

	Rainer
  

On Wed, 7 Jan 2026 at 15:35, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
>
> Hi Jonathan,
>
> >> I've one concern, though: sometimes you need to remove some changes from
> >> the regenerated baselines (don't have an examply handy, but am pretty
> >> sure this has happened in the past).  If you make updating the baseline
> >> too easy, something like this might be missed more easily :-)
> >
> > I did consider that, because when I ran it to test the changes, 'git
> > diff' showed the TLS symbols that we don't want to commit to the
> > x86_64-pc-linux-gnu baseline.
> >
> > But I'm not sure if it really makes it too easy? I doubt anybody is
> > copying individual changes from the .new file to the real one, surely
> > they just do 'mv foo.txt.new foo.txt' and then use 'git diff', and in
> > that case, they still need to manually remove some changes.
> >
> > It would only be a problem if people run the make target, then do git
> > commit without checking the diff. But they could already do that today
> > after mv'ing the file.
>
> I'd hope this would be caught during review, though: I believe that even
> baseline updates need to go through patch review first, right?

Right

>
> As I said: it not a serious concern, just something to think about.
>
>         Rainer
>
> --
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
  

I've pushed this to trunk now.

On Wed, 7 Jan 2026 at 15:42, Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On Wed, 7 Jan 2026 at 15:35, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
> >
> > Hi Jonathan,
> >
> > >> I've one concern, though: sometimes you need to remove some changes from
> > >> the regenerated baselines (don't have an examply handy, but am pretty
> > >> sure this has happened in the past).  If you make updating the baseline
> > >> too easy, something like this might be missed more easily :-)
> > >
> > > I did consider that, because when I ran it to test the changes, 'git
> > > diff' showed the TLS symbols that we don't want to commit to the
> > > x86_64-pc-linux-gnu baseline.
> > >
> > > But I'm not sure if it really makes it too easy? I doubt anybody is
> > > copying individual changes from the .new file to the real one, surely
> > > they just do 'mv foo.txt.new foo.txt' and then use 'git diff', and in
> > > that case, they still need to manually remove some changes.
> > >
> > > It would only be a problem if people run the make target, then do git
> > > commit without checking the diff. But they could already do that today
> > > after mv'ing the file.
> >
> > I'd hope this would be caught during review, though: I believe that even
> > baseline updates need to go through patch review first, right?
>
> Right
>
> >
> > As I said: it not a serious concern, just something to think about.
> >
> >         Rainer
> >
> > --
> > -----------------------------------------------------------------------------
> > Rainer Orth, Center for Biotechnology, Bielefeld University
> >