Jakub Jelinek <ja...@redhat.com> writes:
> On Mon, Apr 21, 2025 at 10:16:39AM +0100, Sam James wrote:
>> Sam James <s...@gentoo.org> writes:
>>
>> > Richard Biener <richard.guent...@gmail.com> writes:
>> >
>> >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek <ja...@redhat.com> wrote:
>> >>>
>> >>> On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
>> >>> > That's one option, but maybe it's better the other way round: instead
>> >>> > of
>> >>> > excluding known-bad targets, restrict cobol to known-good ones
>> >>> > (i.e. x86_64-*-linux* and aarch64-*-linux*) instead.
>> >>> >
>> >>> > I've been using the following for this (should be retested for safety).
>> >>>
>> >>> I admit I don't really know what works and what doesn't out of the box
>> >>> now,
>> >>> but your patch looks reasonable to me for 15 branch.
>> >>>
>> >>> Richard, Robert and/or James, do you agree?
>> >>
>> >> I agree to restrict =all to enable cobol only for known-good platform
>> >> triples.
>> >> But IIRC that's what libgcobol configure.tgt does - IIRC intent was to
>> >> allow
>> >> a cobol build with explicit 'cobol' included even when configure.tgt
>> >> claims
>> >> unsupported? So why's *-*solaris now included in =all?
>> >>
>> >> I'm a bit confused, I thought we had =all restricted already.
>> >
>> > Think we may be missing some wiring.
>> >
>> > # Always enable COBOL for --enable-languages=*cobol*
>> > # Otherwise, enable COBOL only for known architectures
>> > case ,${enable_languages}, in
>> > [...]
>> > *)
>> > case "${target}" in
>> > *-*-darwin*)
>> > unsupported_languages="$unsupported_languages cobol"
>> > ;;
>> > x86_64-*-*|aarch64-*-*)
>> > ;;
>> > *-*-*)
>> > unsupported_languages="$unsupported_languages cobol"
>> > ;;
>> > esac
>> > [... ditto ${host} ...]
>> >
>> > We don't seem to ever add cobol to unsupported_languages if we added
>> > target-libgcobol to noconfigdirs.
>> >
>> > The earlier check for libgcobol being supported does match other runtime
>> > libraries but the only other *language-specific* runtime library it
>> > matches is libphobos, where D supports a minimal build without that, so
>> > it doesn't cater for this.
>>
>> so, untested simple:
>>
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -768,6 +768,7 @@ if test -d ${srcdir}/libgcobol; then
>> then
>> AC_MSG_RESULT([no])
>> noconfigdirs="$noconfigdirs target-libgcobol"
>> + unsupported_languages="$unsupported_languages cobol"
>> else
>> AC_MSG_RESULT([yes])
>> fi
>>
>> may do it for now. It still allows forcing libgcobol build with
>> --enable-libgcobol. But if doing --enable-languages=cobol, you'd need
>> --enable-libgcobol as well (but no idea if we really have tested cobol
>> w/o libgcobol at all yet, or what).
>
> I think we don't do this for any other language, do we?
We don't have any other languages needing a whitelist for the FE itself,
though - just target libraries (libada, phobos, etc).
> Sure, if one only configures a library and does not enable the language,
> the library is quite useless, and if one only configures the language and
> the library is not configured, one can only compile code written in that
> language but can't link it nor run it. E.g. for i686-linux (no multilib)
> libgcobol is not UNSUPPORTED at the toplevel and so
> --enable-languages=all,cobol
> at least we still build the FE but libgcobol is configured but doesn't build
> anything.
> So, the unsupported_languages="$unsupported_languages cobol" should IMHO be
> more about on which triplets it is known not to build the FE or have similar
> major issues with it.
> And to be honest, i686-linux is one of them, my patch to avoid depending on
> size_t being unsigned long int is not in, so there will be at least many
> warnings.
> So the previous patch made more sense to me.
>
My concern with that is it's still not the whitelist approach and we may
well get reports of --enable-languages=all regressing on FreeBSD or some
other target we didn't look at. OTOH, it has an easy workaround, and
further fixes will surely be backported to 15.2. So, your
https://inbox.sourceware.org/gcc-patches/aAJmt2ju0QXChcXI@tucnak/ WFM
too. Either way will work.
sam
