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

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.


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.

===
Mark Millard
marklmi at yahoo.com