Still waiting for those minimized reproduction recipes for erroneous changes, and probably also for a volunteer who really wants to take a deep dive on autoupdate.

comment #3:

> Since autoupdate uses a "brittle" algorithm, as Zack wrote, I think what you report will be hard or impossible to reproduce if you don't attach the input file(s).

Hi, the input files can be found in my "autotools-tinkering" branch of gcc: https://github.com/gcc-mirror/gcc/compare/master...cooljeanius:me/autotools-tinkering
In particular commit 6b44b2c contains a lot of the screw-ups: https://github.com/gcc-mirror/gcc/commit/6b44b2c391c1132acc8cfdefe83e2e614b8e590d
I can try reducing some reproducers from it if you'd like; should I?

I've noticed a bunch of these, too:

1) Nested AC_TRY_COMPILE/AC_TRY_LINK/AC_TRY_RUN invocations lead to stray _au_m4_changequote([,])s when being autoupdated to AC_COMPILE_IF_ELSE/AC_LINK_IF_ELSE/AC_RUN_IF_ELSE
2) Macros in comments get expanded even when the new output spreads across more lines, meaning that stuff that ought to stay in a comment no longer is
3) Stuff inside AC_REQUIRE gets autoupdated even when that breaks the usage of AC_REQUIRE (similar to the previous)
4) If someone had been writing their configure.ac to abide by certain style rules (e.g. 80-character line limits), autoupdate will ignore those and reformat things

I've been noticing a bunch of these while autoupdating various stuff over the years but am only getting around to writing them down as of my beginning of work on autoupdating the GCC configury as per this bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103459

Should I open separate bugs for each additional item that I notice, or just continue to catalogue them here?

In https://lists.gnu.org/archive/html/bug-gnulib/2020-09/msg00158.html Zack Weinberg wrote:
"The diff produced by autoupdate is mostly not usable as is.   In fact, it looks to me more like a todo list for bugs and missing features in autoupdate itself :-/"

Here is another example, from GNU gperf. Find the input and the changes by autoupdate 2.69c attached.

1) Changing AC_PREREQ([2.64]) to AC_PREREQ([2.69c]) — or, once 2.70 is released, to AC_PREREQ([2.70]) — is unwelcome, because many distros which run autoreconf will not have autoconf 2.70 is installed.
While it is certainly OK to change AC_PREREQ([2.13]) to AC_PREREQ([2.64]) or so, AC_PREREQ([2.69c]) is a too strong requirement.

2) Changing AC_LANG_SAVE() to m4_warn(...) is nonsense.

3) Leaving AC_LANG_SAVE in the output is not good, because autoupdate is meant to eliminate this call.

The other parts are helpful, though.