regenerate-opt-urls.py: fix transposed values for "vax" and "v850"

> On Tue, 2024-05-28 at 15:03 +0200, Mark Wielaard wrote:
> Hi Maciej (Hi David, added to CC),

>On Mon, 2024-05-27 at 05:19 +0100, Maciej W. Rozycki wrote:
> >  As reported in PR target/79646 and fixed by a change proposed by
> > Abe we 
> > have a couple of issues with the descriptions of the VAX
> > floating-point 
> > format options in the option definition file.  Additionally most of
> > these 
> > options are not documented in the manual.
> > 
> >  This mini patch series addresses these issues, including Abe's
> > change, 
> > slightly updated, and my new change.  See individual change
> > descriptions 
> > for details.
> > 
> >  Verified by inspecting output produced by `vax-netbsdelf-gcc -v
> > --help' 
> > and by eyeballing `gcc.info' and `gcc.pdf' files produced. 
> > Committed.
>
> This broke the gcc-autoregen checker because the
> gcc/config/vax/vax.opt.urls file wasn't regenerated:
> https://builder.sourceware.org/buildbot/#/builders/269/builds/5347
> 
> Producing the following diff:
> 
> diff --git a/gcc/config/vax/vax.opt.urls
> b/gcc/config/vax/vax.opt.urls
> index c6b1c418b61..ca78b31dd4c 100644
> --- a/gcc/config/vax/vax.opt.urls
> +++ b/gcc/config/vax/vax.opt.urls
> @@ -1,7 +1,13 @@
>  ; Autogenerated by regenerate-opt-urls.py from
> gcc/config/vax/vax.opt and generated HTML
>  
> +; skipping UrlSuffix for 'md' due to finding no URLs
> +
> +; skipping UrlSuffix for 'md-float' due to finding no URLs
> +
>  ; skipping UrlSuffix for 'mg' due to finding no URLs
>  
> +; skipping UrlSuffix for 'mg-float' due to finding no URLs
> +
>  ; skipping UrlSuffix for 'mgnu' due to finding no URLs
>  
>  ; skipping UrlSuffix for 'munix' due to finding no URLs
> 
> I am not completely clear on why though. Since it seems you actually
> did add documentation for exactly these options.
> 
> David, should the above diff just be checked in, or do we need to
> investigate why the URLs weren't found?

[adding Nick, re the v850 target]

I found the problem - I messed up when I was populating
TARGET_SPECIFIC_PAGES in regenerate-opt-urls.py, accidentally
transposing the entries for v850 and vax by writing:

    'gcc/V850-Options.html' : 'gcc/config/vax/',
    'gcc/VAX-Options.html' : 'gcc/config/v850/',

leading to both gcc/config/v850/v850.opt.urls and
gcc/config/vax/vax.opt.urls being full of such comments.

Sorry.

Fixing that leads to the files for both targets being populated with
correct-looking URL entries.

I'll push this to trunk (and backport to gcc 14) after suitable testing.

Dave

gcc/ChangeLog:
	* config/v850/v850.opt.urls: Regenerate, with fix.
	* config/vax/vax.opt.urls: Likewise.
	* regenerate-opt-urls.py (TARGET_SPECIFIC_PAGES): Fix transposed
	values for "vax" and "v850".

Signed-off-by: David Malcolm <dmalcolm@redhat.com>
---
 gcc/config/v850/v850.opt.urls | 81 +++++++++++++++++++++++------------
 gcc/config/vax/vax.opt.urls   | 21 +++++++--
 gcc/regenerate-opt-urls.py    |  4 +-
 3 files changed, 73 insertions(+), 33 deletions(-)

On Tue, 2024-05-28 at 11:41 -0400, David Malcolm wrote:
> > On Tue, 2024-05-28 at 15:03 +0200, Mark Wielaard wrote:
> > Hi Maciej (Hi David, added to CC),
> 
> > On Mon, 2024-05-27 at 05:19 +0100, Maciej W. Rozycki wrote:
> > >  As reported in PR target/79646 and fixed by a change proposed by
> > > Abe we 
> > > have a couple of issues with the descriptions of the VAX
> > > floating-point 
> > > format options in the option definition file.  Additionally most
> > > of
> > > these 
> > > options are not documented in the manual.
> > > 
> > >  This mini patch series addresses these issues, including Abe's
> > > change, 
> > > slightly updated, and my new change.  See individual change
> > > descriptions 
> > > for details.
> > > 
> > >  Verified by inspecting output produced by `vax-netbsdelf-gcc -v
> > > --help' 
> > > and by eyeballing `gcc.info' and `gcc.pdf' files produced. 
> > > Committed.
> > 
> > This broke the gcc-autoregen checker because the
> > gcc/config/vax/vax.opt.urls file wasn't regenerated:
> > https://builder.sourceware.org/buildbot/#/builders/269/builds/5347
> > 
> > Producing the following diff:
> > 
> > diff --git a/gcc/config/vax/vax.opt.urls
> > b/gcc/config/vax/vax.opt.urls
> > index c6b1c418b61..ca78b31dd4c 100644
> > --- a/gcc/config/vax/vax.opt.urls
> > +++ b/gcc/config/vax/vax.opt.urls
> > @@ -1,7 +1,13 @@
> >  ; Autogenerated by regenerate-opt-urls.py from
> > gcc/config/vax/vax.opt and generated HTML
> >  
> > +; skipping UrlSuffix for 'md' due to finding no URLs
> > +
> > +; skipping UrlSuffix for 'md-float' due to finding no URLs
> > +
> >  ; skipping UrlSuffix for 'mg' due to finding no URLs
> >  
> > +; skipping UrlSuffix for 'mg-float' due to finding no URLs
> > +
> >  ; skipping UrlSuffix for 'mgnu' due to finding no URLs
> >  
> >  ; skipping UrlSuffix for 'munix' due to finding no URLs
> > 
> > I am not completely clear on why though. Since it seems you
> > actually
> > did add documentation for exactly these options.
> > 
> > David, should the above diff just be checked in, or do we need to
> > investigate why the URLs weren't found?
> 
> [adding Nick, re the v850 target]
> 
> I found the problem - I messed up when I was populating
> TARGET_SPECIFIC_PAGES in regenerate-opt-urls.py, accidentally
> transposing the entries for v850 and vax by writing:
> 
>     'gcc/V850-Options.html' : 'gcc/config/vax/',
>     'gcc/VAX-Options.html' : 'gcc/config/v850/',
> 
> leading to both gcc/config/v850/v850.opt.urls and
> gcc/config/vax/vax.opt.urls being full of such comments.
> 
> Sorry.
> 
> Fixing that leads to the files for both targets being populated with
> correct-looking URL entries.
> 
> I'll push this to trunk (and backport to gcc 14) after suitable
> testing.

I've pushed this to gcc trunk as r15-872-g7cc529fe514cc6 (having
bootstrapped and lightly tested it on x86_64-pc-linux-gnu)

Dave

On Tue, 28 May 2024, David Malcolm wrote:

> I've pushed this to gcc trunk as r15-872-g7cc529fe514cc6 (having
> bootstrapped and lightly tested it on x86_64-pc-linux-gnu)

 Thank you for fixing this up.  Is this a new requirement now for .opt 
file changes?  Why does it have to be called by hand then rather than 
being a make dependency?

  Maciej

On Mon, 2024-06-03 at 11:30 +0100, Maciej W. Rozycki wrote:
> On Tue, 28 May 2024, David Malcolm wrote:
> 
> > I've pushed this to gcc trunk as r15-872-g7cc529fe514cc6 (having
> > bootstrapped and lightly tested it on x86_64-pc-linux-gnu)
> 
>  Thank you for fixing this up.  Is this a new requirement now for
> .opt 
> file changes?  

Yes, as of GCC 14.

I posted the objectives here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636060.html

> Why does it have to be called by hand then rather than
> being a make dependency?

IIRC, the idea is:
(a) to avoid requiring Python 3 as a build dependency, and 
(b) to avoid requiring the HTML docs to be built before gcc's code can
be built

since missing a few URLs is a relatively minor issue that we don't want
to complicate the build for.

Hence we decided to check for it in CI instead.

Hope the trade-off sounds reasonable
Dave

On Mon, 3 Jun 2024, David Malcolm wrote:

> >  Thank you for fixing this up.  Is this a new requirement now for
> > .opt 
> > file changes?  
> 
> Yes, as of GCC 14.
> 
> I posted the objectives here:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636060.html

 Thank you for the pointer.

> > Why does it have to be called by hand then rather than
> > being a make dependency?
> 
> IIRC, the idea is:
> (a) to avoid requiring Python 3 as a build dependency, and 
> (b) to avoid requiring the HTML docs to be built before gcc's code can
> be built
> 
> since missing a few URLs is a relatively minor issue that we don't want
> to complicate the build for.

 Understood.  My overall experience with Python over the years has been 
very bad, with things breaking randomly depending on the phase of the 
moon, the tide, etc., so I think avoiding it as a build dependency in the 
field is a good idea.

> Hence we decided to check for it in CI instead.
> 
> Hope the trade-off sounds reasonable

 I have reviewed the thread referred and I note that a concern such as 
mine has already been raised in response to which you have added the 
`regenerate-opt-urls' make target (thanks!).

 I think it's a good direction given the circumstances, but I also think a 
more generic make target such as `generated-sources' or suchlike would be 
good having as an umbrella for any future additions we may make, and as 
one that might be easier to remember.  Perhaps it could be a dependency 
for `all' even, in the maintainer mode (which I confess to be guilty of 
not regularly using though), along with any autoconf stuff, etc.

  Maciej