On Wed, Sep 3, 2025 at 2:56 PM Harald Anlauf <anl...@gmx.de> 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 <g...@johnericson.me> > >> 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 <g...@johnericson.me> > >> 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 <g...@johnericson.me> > >> Reviewed-by: Jason Merrill <ja...@redhat.com> > >> --- > > 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?
