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.
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
From a3748f8a02ae510d2631fb7db4829efae12733bb Mon Sep 17 00:00:00 2001
From: Andre Vehreschild <[email protected]>
Date: Thu, 4 Sep 2025 08:20:04 +0200
Subject: [PATCH] Fix uninitialized variable in frontend.
gcc/ChangeLog:
* gcc.cc (for_each_path): Initialize return value.
---
gcc/gcc.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 722d42c6968..8da821e92ac 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -2788,7 +2788,7 @@ for_each_path (const struct path_prefix *paths,
const char *multi_suffix;
const char *just_multi_suffix;
char *path = NULL;
- decltype (callback (nullptr)) ret;
+ decltype (callback (nullptr)) ret = nullptr;
bool skip_multi_dir = false;
bool skip_multi_os_dir = false;
--
2.51.0
