On Fri, 6 Sept 2024 at 02:47, Jason Merrill <ja...@redhat.com> wrote: > > On 8/28/24 6:22 AM, Jason Merrill wrote: > > On 8/28/24 6:09 AM, Jonathan Wakely wrote: > >> On Wed, 28 Aug 2024 at 10:58, Jason Merrill <ja...@redhat.com> wrote: > >>> > >>> On 8/28/24 5:55 AM, Jonathan Wakely wrote: > >>>> On Wed, 28 Aug 2024 at 10:54, Jason Merrill wrote: > >>>>> > >>>>> Tested x86_64-pc-linux-gnu, OK for trunk? > >>>> > >>>> Redefining that macro to invalidate PCH is a bit of a hack, but it's > >>>> what we have for now, so OK for trunk, thanks. > >>> > >>> If it's just to invalidate PCH, do we want to #undef instead? > >> > >> It might not even be necessary now, since r14-3276-g91315f23ba127e > >> removed any -include bits/stdc++.h from the flags. I'd need to look > >> into that though. > > > > I suppose it could still find some random other PCH corresponding to the > > first #include, though that seems very unlikely. > > > >>> Does > >>> anything care about the actual value of the macro? > >> > >> No, I don't think so. > >> > >> But #undef would only work if it comes after including > >> <bits/c++config.h>, so we'd need to force an include of that into the > >> flags. > > > > I meant #undef before #define in c++config.h so we get the normal value. > > Like so. Do you prefer this or the original patch?
If this is still sufficient to invalidate the PCH then I prefer this second version. OK for trunk, thanks.
