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

Hello,

I believe the recent commits have fixed the issue for all GCC ports.
Applied solution is to build jit only if some BOOTSTRAP option is
enabled.

Cheers,

Lorenzo Salvadore

On Thursday, August 21st, 2025 at 14:09, Mark Millard <marklmi@yahoo.com> wrote:

> 
> 
> 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