Re: lang/gcc* built via --disable-bootstrap via using just-clang instead of a gcc* vs. armv7 and armv6 using --disable-bootstrap by default

See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 and https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631611.html .

-Dimitry

> On 26 Feb 2024, at 14:39, Lorenzo Salvadore <developer@lorenzosalvadore.it> wrote:
> 
> On Monday, February 26th, 2024 at 03:33, Mark Millard <marklmi@yahoo.com <mailto:marklmi@yahoo.com>> wrote:
> 
>> 
>> 
>> I learned some about the technical criteria for use of --disable-bootstrap as
>> part of an exchange for a submittal that I made.
>> 
>> There are 2 quotes that are relevant. One explains a relationship not
>> explicitly in the wording that is explicit about --disable-boostrap .
>> The other is more general (and not explicit about command line options)
>> but that the --disable-boostrap fits in.
>> 
>> First QUOTE ( specific to --disable-boostrap )
>> 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.
>> END QUOTE
>> 
>> In other words: all other stages/parts are allowed to do things that
>> clang/libc++ does not provide compatibility for.
>> 
>> Turns out that internal name-poisoning to validate some gcc internal
>> scope-of-use criteria are an example of the issue that can make libc++'s
>> lack of design for the poisoning a problem. Such has been hit in new
>> contexts in lang/gcc14-devel porting. It was also involved in the
>> older a4831f4933d0 ( "lang/gcc12 lang/gcc12-devel lang/gcc13
>> lang/gcc13-devel lang/gcc14-devel: fix build without bootstrap" ).
>> 
>> The above QUOTE can make it messy to determine if one has hit a
>> front-end problem vs. not for making upstream bugzilla submittals.
>> If not viewed by GCC as a front-end issue but from/for code from
>> other stages/parts, support for changing things may be unlikely.
>> In lang/gcc* terms, if STANDARD_BOOTSTRAP works, effectively the
>> response to a submittal may be saying: "so use STANDARD_BOOTSTRAP".
>> 
>> 
>> 
>> The following quote is from:
>> 
>> https://gcc.gnu.org/install/prerequisites.html
>> 
>> and so is explicitly official GCC material:
>> 
>> Second QUOTE ( more general than --disable-boostrap )
>> To build all languages in a cross-compiler or other configuration where
>> 3-stage bootstrap is not performed, you need to start with an existing
>> GCC binary (version 4.8.3 or later) because source code for language
>> frontends other than C might use GCC extensions.
>> END QUOTE
>> 
>> (There is a missing /C++ in the wording. Also, not wording explicitly
>> inicating which option syntaxes have which implications.)
>> 
>> One has to read into that that the name-poisoning imposition of
>> scope-of-use design rules is an example of a GCC extension, one
>> that libc++ does not follow (i.e., does not support). Various
>> parts of the code make no claim to support a context that does
>> not follow the design rule. (The front-end's code must not impose
>> the design rule for its build.) In general, gcc producing gcc
>> has to be involved for some stages in order to be supported
>> and those stages can use the scope-of-rule rule imposed by
>> name poisoning, as an example.https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631611.html
>> 
>> 
>> Ultimately these may lead to the need to avoiding --disable-bootstrap
>> ever being a default for some lang/gcc* examples. A contrinbuting
>> issue is getting support from upstream. Another could be how
>> complicated things get as gcc progresses.
> 
> Thanks a lot Mark for your analysis, both in this email and in the other
> email thread.
> 
> I am proceeding to slowly dump the possibility to build GCC ports without
> bootstrap: indeed, building lang/gcc14-devel port without bootstrap is broken
> at the moment (which is the starting poing of the whole discussion) and it will
> not be fixed.
> I am keeping this possibility for older GCC versions for now: they build, they
> are not broken, even without bootstrap. If future updates break them too, I
> will require bootstrap for them too.
> But starting from GCC 14 ports, all GCC ports will require to select a bootstrap
> option (STANDARD_BOOTSTRAP being the default).
> 
> This also means that I need to make some changes to my testing environment...
> I am already working on it and I am fairly confident that I can find a decent
> solution.
> 
> Thanks,
> 
> Lorenzo Salvadore