On 1/25/26 15:59, Andrew Pinski wrote:
On Sun, Jan 25, 2026 at 2:56 PM Sandra Loosemore <[email protected]> wrote:My recent commits for PR122243 added index entries for -fno-* options as well as their normal positive forms. Apparently the "urlifier" used to insert option URLS into diagnostic messages can find the anchor for either form, but its self-tests are hard-wired to match only the positive form for the two specific options it's looking up. This patch robustifies it to allow it to match the anchor for either the positive or negative forms. gcc/ChangeLog * gcc-urlifier.cc (test_gcc_urlifier): Match either positive or negative option URLS.Ok.
I pushed this patch last night to fix the build failure, but I spent some more time today looking at the problem.
The regenerate-opt-urls.py script processes the entries in the generated HTML file for the options sequentially -- it's alphabetized, so it sees the entry for -fno-pack-struct before -fpack-struct, but -finline before -fno-inline. And it uses the anchor from the first one it sees, even though it always strips any "no-" from the option name associated with that index entry.
I think what it ought to be doing is always using the anchor for the positive option with the positive form of the option name and ignoring the no- anchor, unless there isn't an index entry for the positive form at all. (There are, in fact, some options that only exist in the negative form, or where the negative form is the only one documented.) While both anchors ought to be in the same place in the output text, it's pretty weird for anybody who looks at the links to see a reference to -fpack-struct pointing at the anchor for -fno-pack-struct instead.
I am unfortunately not very fluent in Python (I use it so rarely that I have to re-learn it from scratch every time I have to do anything). Does anybody else want to take a stab at this? Should I just file an issue and throw it in the pile?
-Sandra
