"John Ericson" <g...@johnericson.me> writes: > The change looks good to me. Sorry about the breakage. > > (For context, after making the return type polymorphic, I was experiment with > removing assumptions that it is even a > pointer, but I never actually did that. The removal of the `= NULL` was just > a stray bit of those experiments that > accidentally made it into my submitted patch.) > > John
I'll push it shortly. Thanks. > > On Thu, Sep 4, 2025, at 11:13 AM, Richard Biener wrote: > > On Thu, Sep 4, 2025 at 10:53 AM Andre Vehreschild <ve...@gmx.de> wrote: > > > > 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. > > Heh. CCing the author of the offending change for that then. > > Richard. > > > 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
