I see. Thank you for the clarification!
On Thu, Mar 30, 2023 at 5:23 AM Jonathan Wakely <jwak...@redhat.com> wrote: > > On Thu, 30 Mar 2023 at 09:33, Ken Matsui wrote: > > > > Hi François, > > > > On Wed, Mar 29, 2023 at 10:11 PM François Dumont <frs.dum...@gmail.com> > > wrote: > > > > > > Hi > > > > > > Do not hesitate to dig into library doc. Especially this page: > > > > > > https://gcc.gnu.org/onlinedocs/gcc-8.1.0/libstdc++/manual/manual/test.html > > > > > > You can also find it in your git clone in > > > <gcc-repo>/libstdc++-v3/doc/html. > > > > > > You'll see also how to run test in different std modes like --std=c++98 > > > to catch the kind of issue reported by Jonathan. > > > > This is what I wanted to know! Thank you so much! > > > > > Regarding your patches I wonder if it's not too splitted. 1 patch per > > > builtin would sound more logical, at least for an easy one like __is_void. > > > > I see. I will squash is_void-related commits into the commit of > > __is_void implementation. Thank you for pointing it out! > > > Yes, good point, François. These kind of changes for the front-end and > library should be in one patch. Otherwise, if they were committed > separately then you would create a revision where bootstrap fails. If > the front-end change is committed without the library change, then you > can't build the library because it still uses __is_void which is now a > keyword. If the library change is committed first then you don't break > bootstrap, but you're adding support to the library for a new built-in > which doesn't actually exist (yet). They should be a single revision, > so that the tree can always be built. >
