On Thu, Sep 4, 2025 at 8:22 AM Andre Vehreschild <[email protected]> wrote: > > Hi Patrick, > > I applied attached patch, which resolves the issue for me. @Harald does it do > the trick for you, too? > > Thanks Patrick for quick resolution of the issue.
OK. Thanks, Richard. > Regards, > Andre > > On Wed, 3 Sep 2025 17:40:18 -0400 > Patrick Palka <[email protected]> wrote: > > > On Wed, Sep 3, 2025 at 2:56 PM Harald Anlauf <[email protected]> wrote: > > > > > > Am 03.09.25 um 20:40 schrieb Patrick Palka: > > > > On Wed, 3 Sep 2025, Tobias Burnus wrote: > > > > > > > >> > > > >> Hi Andre, hi all, > > > >> > > > >> Andre Vehreschild wrote: > > > >> > > > >> I am experiencing a strange issue with gfortran. Compiling a simple > > > >> program: > > > >> > > > >> $ cat end.f90 > > > >> end > > > >> $ gfortran end.f90 -o end > > > >> f951: Fatal Error: Cannot open pre-included file '\xe0\xd4\xf2,' > > > >> compilation terminated. > > > >> > > > >> From your description, it sounds as if your Stage 1 compiler > > > >> of Fedora 41 is miscompiling gfortran/f951. > > > >> > > > >> I have not understood whether a normal bootstrap, i.e. where > > > >> gfortran is only build during Stage 2 also fails or only a > > > >> non-bootstrap / --enable-stage1-languages=fortran,... built one. > > > >> > > > >> * * * > > > >> > > > >> Yes, the program is doing nothing, but can not be compiled. The > > > >> pre-included file name changes randomly. Looks like something is either > > > >> overwritten or not initialized properly. I bisected this issue down to > > > >> commit f23bac62f46fc296a4d0526ef54824d406c3756c > > > >> Author: John Ericson <[email protected]> > > > >> Date: Fri Aug 22 22:24:56 2025 -0400 > > > >> > > > >> driver: Rework for_each_path using C++ > > > >> > > > >> but I do not see, why this should affect gfortran's ability to build a > > > >> simple program. > > > >> > > > >> Well, from your valgrind output, the issue is in for_each_path > > > >> and 'pre-included' is also run for empty programs - as the name implies > > > >> And there is also a > > > >> -fpre-include=/usr/include/finclude/math-vector-fortran.h > > > >> in your f951 call, which is used to ensure that GLIBC's vector math > > > >> functions are used. > > > >> > > > >> * * * > > > >> > > > >> I don't feel like checking whether there is a bug in > > > >> commit r16-3354-gf23bac62f46fc2 itself or only an issue in the F41 > > > >> system > > > >> compiler. > > > > > > > > There seems to be a bug in r16-3354 that may be causing what the crash > > > > that you're seeing: > > > > > > > >> From f23bac62f46fc296a4d0526ef54824d406c3756c Mon Sep 17 00:00:00 2001 > > > >> From: John Ericson <[email protected]> > > > >> Date: Fri, 22 Aug 2025 22:24:56 -0400 > > > >> Subject: driver: Rework for_each_path using C++ > > > >> > > > >> The old C-style was cumbersome make making one responsible for manually > > > >> creating and passing in two parts a closure (separate function and > > > >> *_info class for closed-over variables). > > > >> > > > >> With C++ lambdas, we can just: > > > >> > > > >> - derive environment types implicitly > > > >> - have fewer stray static functions > > > >> > > > >> Also thanks to templates we can > > > >> - make the return type polymorphic, to avoid casting pointee types. > > > >> > > > >> Note that `struct spec_path` was *not* converted because it is used > > > >> multiple times. We could still convert to a lambda, but we would want > > > >> to > > > >> put the for_each_path call with that lambda inside a separate function > > > >> anyways, to support the multiple callers. Unlike the other two > > > >> refactors, it is not clear that this one would make anything shorter. > > > >> Instead, I define the `operator()` explicitly. Keeping the explicit > > > >> struct gives us some nice "named arguments", versus the wrapper > > > >> function > > > >> alternative, too. > > > >> > > > >> gcc/ChangeLog: > > > >> > > > >> * gcc.cc (for_each_path): templated, to make passing lambdas > > > >> possible/easy/safe, and to have a polymorphic return type. > > > >> (struct add_to_obstack_info): Deleted, lambda captures replace > > > >> it. > > > >> (add_to_obstack): Moved to lambda in build_search_list. > > > >> (build_search_list): Has above lambda now. > > > >> (struct file_at_path_info): Deleted, lambda captures replace > > > >> it. > > > >> (file_at_path): Moved to lambda in find_a_file. > > > >> (find_a_file): Has above lambda now. > > > >> (struct spec_path_info): Reamed to just struct spec_path. > > > >> (struct spec_path): New name. > > > >> (spec_path): Rnamed to spec_path::operator() > > > >> (spec_path::operator()): New name > > > >> (do_spec_1): Updated for_each_path call sites. > > > >> > > > >> Signed-off-by: John Ericson <[email protected]> > > > >> Reviewed-by: Jason Merrill <[email protected]> > > > >> --- > > > > > > I hit the same issue here on Suse 15.6 multiple times after that commit. > > > > > > The first time I resolved it by make clean and rebuilding (note that > > > I cannot afford a full bootstrap). > > > > > > It surfaced again after pulling and building gfortran/f951 in the gcc > > > subdirectory even if the related changes seemed harmless. > > > > > > As removing all .o files in gcc seemed to solve it for me later, > > > I began assuming a missing or broken dependency somewhere. > > > > Does zero-initializing 'ret' in gcc.cc:for_each_path fix things for you? > > > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de
