On Tue, Nov 14, 2023 at 5:00 PM Marek Polacek <pola...@redhat.com> wrote:
>
> On Tue, Nov 14, 2023 at 08:46:16AM +0100, Richard Biener wrote:
> > On Fri, Nov 3, 2023 at 11:51 PM Marek Polacek <pola...@redhat.com> wrote:
> > >
> > > On Thu, Oct 26, 2023 at 05:55:56PM +0200, Richard Biener wrote:
> > > >
> > > >
> > > > > Am 24.10.2023 um 21:09 schrieb Marek Polacek <pola...@redhat.com>:
> > > > >
> > > > > On Tue, Oct 24, 2023 at 09:22:25AM +0200, Richard Biener wrote:
> > > > >>> On Mon, Oct 23, 2023 at 9:26 PM Marek Polacek <pola...@redhat.com>
> > > > >>> wrote:
> > > > >>>
> > > > >>> On Thu, Oct 19, 2023 at 02:24:11PM +0200, Richard Biener wrote:
> > > > >>>> Can you see how our
> > > > >>>> primary and secondary targets (+ host OS) behave here?
> > > > >>>
> > > > >>> That's very reasonable. I tried to build gcc on Compile Farm 119
> > > > >>> (AIX) but
> > > > >>> that fails with:
> > > > >>>
> > > > >>> ar -X64 x ../ppc64/libgcc/libgcc_s.a shr.o
> > > > >>> ar: 0707-100 ../ppc64/libgcc/libgcc_s.a does not exist.
> > > > >>> make[2]: ***
> > > > >>> [/home/polacek/gcc/libgcc/config/rs6000/t-slibgcc-aix:98: all]
> > > > >>> Error 1
> > > > >>> make[2]: Leaving directory
> > > > >>> '/home/polacek/x/trunk/powerpc-ibm-aix7.3.1.0/libgcc'
> > > > >>>
> > > > >>> and I tried Darwin (104) and that fails with
> > > > >>>
> > > > >>> *** Configuration aarch64-apple-darwin21.6.0 not supported
> > > > >>>
> > > > >>> Is anyone else able to build gcc on those machines, or test the
> > > > >>> attached
> > > > >>> patch?
> > > > >>>
> > > > >>>> I think the
> > > > >>>> documentation should elaborate a bit on expectations for
> > > > >>>> non-Linux/GNU
> > > > >>>> targets, specifically I think the default configuration for a
> > > > >>>> target should
> > > > >>>> with -fhardened _not_ have any -Whardened diagnostics. Maybe we
> > > > >>>> can
> > > > >>>> have a testcase for this?
> > > > >>>
> > > > >>> Sorry, I'm not sure how to test that. I suppose if -fhardened
> > > > >>> enables
> > > > >>> something not supported on those systems, and it's something for
> > > > >>> which
> > > > >>> we have a configure test, then we shouldn't warn. This is already
> > > > >>> the
> > > > >>> case for -pie, -z relro, and -z now.
> > > > >>
> > > > >> I was thinking of
> > > > >>
> > > > >> /* { dg-do compile } */
> > > > >> /* { dg-additional-options "-fhardened -Whardened" } */
> > > > >>
> > > > >> int main () {}
> > > > >>
> > > > >> and excess errors should catch "misconfigurations"?
> > > > >
> > > > > I see. fhardened-3.c is basically just like this (-Whardened is on
> > > > > by default).
> > > > >
> > > > >>> Should the docs say something like the following for features
> > > > >>> without
> > > > >>> configure checks?
> > > > >>>
> > > > >>> @option{-fhardened} can, on certain systems, attempt to enable
> > > > >>> features
> > > > >>> not supported on that particular system. In that case, it's
> > > > >>> possible to
> > > > >>> prevent the warning using the @option{-Wno-hardened} option.
> > > > >>
> > > > >> Yeah, but ideally
> > > > >>
> > > > >> @option{-fhardened} can, on certain systems, not enable features not
> > > > >> available on those systems and @option{-Whardened} will not diagnose
> > > > >> those as missing.
> > > > >>
> > > > >> But I understand it doesn't work like that?
> > > > >
> > > > > Right. It will not diagnose missing features if they have a configure
> > > > > check, otherwise it will. And I don't know if we want a configure
> > > > > check
> > > > > for every feature. Maybe we can add them in the future if the current
> > > > > patch turns out to be problematical in practice?
> > > >
> > > > Maybe we can have a switch on known target triples and statically
> > > > configure based
> > > > On that, eventually even not support -fhardened for targets not listed.
> > > > That’s certainly easier than detecting the target system features
> > > > (think of cross compilers)
> > >
> > > You mean like the following? The only difference is the addition of
> > > HAVE_FHARDENED_SUPPORT and updating the tests to only run on gnu/linux
> > > targets. If other OSs want to use -fhardened, they need to update the
> > > configure test. Thanks,
> >
> > Yes, something like this. IMHO we should aim to at least support all
> > our primary platforms (and maybe secondary if they have a relevant
> > host OS part).
>
> That sounds good. Do you want to see any other changes in this patch
> or are you fine with it as-is (provided that someone else also acks it)?
I'm fine with it as-is if somebody else also acks it.
Richard.
> Thanks,
>
> Marek
>
