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.
