GFortran broken after f23bac62f46fc296a4d0526ef54824d406c3756c

[Harald Anlauf]

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 <git@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 <git@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 <git@JohnEricson.me>
>> Reviewed-by: Jason Merrill <jason@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.