Hi Richard,
thanks for the "OK". But please don't expect me to merge this. I have no
experience in that part of the compiler and haven't regression tested the
patch. I hope someone with more experience in that area is willing to merge
the patch and be able to answer future questions.
Regards,
Andre
On Thu, 4 Sep 2025 10:01:05 +0200
Richard Biener <richard.guent...@gmail.com> wrote:
> On Thu, Sep 4, 2025 at 8:22 AM Andre Vehreschild <ve...@gmx.de> 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 <ppa...@redhat.com> wrote:
> >
> > > 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?
> > >
> >
> >
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
--
Andre Vehreschild * Email: vehre ad gmx dot de
