Re: git: d46106eb4b6d - main - lang/gcc14: Add jit language

Lorenzo Salvadore <developer_at_lorenzosalvadore.it> wrote on
Date: Thu, 21 Aug 2025 08:53:00 UTC :

> On Tuesday, August 19th, 2025 at 19:57, Charlie Li <vishwin@freebsd.org> wrote:
> 
> > 
> > 
> > Lorenzo Salvadore wrote:
> > 
> > > On Wednesday, September 4th, 2024 at 15:16, Charlie Li vishwin@freebsd.org wrote:
> > > 
> > > > Lorenzo Salvadore wrote:
> > > > 
> > > > > lang/gcc14: Add jit language
> > > > > 
> > > > > The jit language was missing by accident. Restore it.
> > > > 
> > > > jit fails to build on -CURRENT, at least when *_BOOTSTRAP is disabled:
> > > > 
> > > > In file included from
> > > > /wrkdirs/usr/ports/lang/gcc14/work/gcc-14.2.0/gcc/jit/dummy-frontend.cc:23:
> > > > In file included from
> > > > /wrkdirs/usr/ports/lang/gcc14/work/gcc-14.2.0/gcc/jit/jit-playback.h:24:
> > > > In file included from /usr/include/c++/v1/string:594:
> > > > In file included from
> > > > /usr/include/c++/v1/__memory_resource/polymorphic_allocator.h:20:
> > > > In file included from /usr/include/c++/v1/tuple:1455:
> > > > In file included from /usr/include/c++/v1/exception:82:
> > > > /usr/include/c++/v1/__exception/exception_ptr.h:111:3: error: no member
> > > > named 'fancy_abort' in namespace 'std'; did you mean simply 'fancy_abort'?
> > > > 111 | std::abort();
> > > > | ^~~~~
> > > > /wrkdirs/usr/ports/lang/gcc14/work/gcc-14.2.0/gcc/system.h:808:13: note:
> > > > 'fancy_abort' declared here
> > > > 808 | extern void fancy_abort (const char , int, const char )
> > > > | ^
> > > > 
> > > > In file included from
> > > > /wrkdirs/usr/ports/lang/gcc14/work/gcc-14.2.0/gcc/jit/dummy-frontend.cc:23:
> > > > In file included from
> > > > /wrkdirs/usr/ports/lang/gcc14/work/gcc-14.2.0/gcc/jit/jit-playback.h:26:
> > > > In file included from /usr/include/c++/v1/vector:325:
> > > > In file included from /usr/include/c++/v1/__format/formatter_bool.h:20:
> > > > In file included from /usr/include/c++/v1/__format/formatter_integral.h:35:
> > > > /usr/include/c++/v1/locale:288:32: error: attempt to use a poisoned
> > > > identifier
> > > > 288 | __status = (unsigned char)malloc(__nkw);
> > > > | ^
> > > > /usr/include/c++/v1/locale:1385:24: error: attempt to use a poisoned
> > > > identifier
> > > > 1385 | __ob = (char_type)malloc(2 * static_cast<size_t>(__nc) *
> > > > 
> > > > sizeof(char_type));
> > > > | ^
> > > > /usr/include/c++/v1/locale:2429:31: error: attempt to use a poisoned
> > > > identifier
> > > > 2429 | _Tp* __t = (_Tp*)std::realloc(__owns ? __b.get() : 0,
> > > > __new_cap);
> > > > | ^
> > > > /usr/include/c++/v1/locale:2632:24: error: attempt to use a poisoned
> > > > identifier
> > > > 2632 | __h.reset((char*)malloc(static_cast<size_t>(__wn -
> > > > 
> > > > __wb.get() + 2)));
> > > > | ^
> > > > /usr/include/c++/v1/locale:2910:28: error: attempt to use a poisoned
> > > > identifier
> > > > 2910 | __hd.reset((char_type*)malloc(static_cast<size_t>(__n) *
> > > > 
> > > > sizeof(char_type)));
> > > > | ^
> > > > /usr/include/c++/v1/locale:2936:28: error: attempt to use a poisoned
> > > > identifier
> > > > 2936 | __hw.reset((char_type*)malloc(__exn * sizeof(char_type)));
> > > > | ^
> > > > /usr/include/c++/v1/locale:2974:27: error: attempt to use a poisoned
> > > > identifier
> > > > 2974 | __h.reset((char_type*)malloc(__exn * sizeof(char_type)));
> > > > | ^
> > > > 
> > > > and more of these "attempt to use a poisoned identifier" scattered later.
> > > 
> > > Thanks for reporting, I was not aware of this issue. I had tested the commit
> > > on RELEASEs only.
> > > This is definitely an issue that needs to be addressed and I will work on it
> > > as soon as possible.
> > 
> > This is still failing on lang/gcc15 (and by extension lang/gcc15-devel).
> > I see the condition for i386 removing jit from lang/gcc14-devel in
> > lang/gcc15 but this fail has always been the case on amd64 too, at least
> > when *_BOOTSTRAP is disabled.
> 
> Thanks a lot for reminding this issue: I had completely forgotten it!
> Have you tested lang/gcc16-devel too by chance?
> 
> The most immediate fix is to add the jit language to the build only when
> bootstrap is enabled. Most probably, the issue is that we are trying
> to build GCC on a FreeBSD machine using a non-GCC compiler (default compiler
> is llvm): this kind of situation is exactly the reason why bootstrapping
> exists.
> 
> Of course we can try to improve GCC building process so that building jit
> works without bootstrap, but right now the priority is to upgrade
> GCC_DEFAULT: it is 13 and it should be 15, we are two versions behind.
> We are almost ready for the GCC_DEFAULT update to 14.
> Still, patches are welcome.

I'll remind that this is upstream designing jit's build to require
that the libstdc++ internal design's poisoning principles be followed,
something libc++ does not do.

It gets back into the issue that upstream repeatedly reverts
to requiring that --disable-bootstrap builds is not really
supported for use by other than gcc/g++ itself. They require
libstdc++ poisoning principles to have been followed, something
that is not from the language standards. An old example quote
that was about this was:

QUOTE (that contains another --and I've made a typo correction)
As I was afraid of, part of the reply to the reference to using
--[disable]-bootstrap is:

QUOTE
This should not be done unless you are building with GCC itself. The reason
is only the C, C++ front-ends are supposed to be able to compile with a
(non-GCC) C++11 compiler. So FreeBSD is doing it wrong anyways.
END QUOTE

In other words: gcc defines that --disable-bootstrap is only valid
(supported) where one already has a gcc* to work with that it will
put to use. They freely use gcc internal specifics outside the
code for the front ends, possibly more than clang/libc++ support.

So Lorenzo's intended use (free cirrus) may get only a limited
response, possibly not enough to make it work.
END QUOTE

Enabling jit enables code that requires the libstdc++ poisoning
principles be followed. ("attempt to use a poisoned identifier"
and "no member named 'fancy_abort' in namespace 'std'")

Hacks/patches that avoid this tend to break as gcc/g++ progresses.

You sometimes get statements from gcc that indicate otherwise for
the requirement --but the repeated behavior is to revert parts of
the code to make the requirement again.

===
Mark Millard
marklmi at yahoo.com