https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116400
--- Comment #7 from kargls at comcast dot net --- (In reply to Iain Sandoe from comment #6) > (In reply to kargls from comment #4) > > FX, Iain, > > > > Can one of you please fix this bug or revert your patch? > > It would be unfortunate to return to the situation where we cannot use > autoreconf to regenerate the Fortran configurations. It's unfortunate that I wasted a day ... > > I wasted an entire day trying to understand why I could not generate > > new files with --enable-maintainer-mode. > > Please could you identify steps needed to reproduce the problem? > > (it seems that folks have managed to generate changes recently, so there is > some usable method). Assume pristine GCC sources are in gcc/gccx, the object tree is gcc/objx, and one has functioning autoconf, automake, autogen, and guile. Apply the patch from comment #2 in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120431 This patch only touches gcc/gccx/libgfortran/m4/spread.m4. % cd gcc/objx % ../gccx/configure --prefix=$HOME/work/x --enable-languages=c,c++,fortran,lto \ --enable-bootstrap --disable-nls --disable-multilib --disable-libssp \ --enable-initfini-array --enable-maintainer-mode % gmake -j15 bootstrap <wait an hour> % cd ../gccx % git status The last command shows that only spread.m4 is modified. Historically, the libgfortran/generated/spread*.c files are modified. The regenerated source files, as this PR indicates, end up in gcc/objx/x86_64-unknown-freebsd15.0/libgfortran/generated. This is not where I expected the files to end up. My workaround is to diff the misplaced new files (now that I know where they are) against the old files to ensure that the new files in fact are correct, and then either copy the misplaced files to the proper location or do a diff/patch tango.
