Message ID | CABOHX+dL0wr2Q+4JZb-WwgnN0c1Q0FSpPWNOGkJmZB4PORZpwA@mail.gmail.com |
---|---|
State | New |
Headers | show |
Series | [d] Disable D on systems where it is known not to work. | expand |
On Okt 30 2018, Iain Buclaw <ibuclaw@gdcproject.org> wrote: > This turns off D front-end where there's been reported bootstrap > problems that need further investigation. Also added a configure.tgt > for libphobos to allow enabling for targets where there's known good > runtime support backed by existing continuous integration. Why do you need that? The D frontend isn't built by default. Andreas.
On Tue, 30 Oct 2018 at 20:50, Andreas Schwab <schwab@linux-m68k.org> wrote: > > On Okt 30 2018, Iain Buclaw <ibuclaw@gdcproject.org> wrote: > > > This turns off D front-end where there's been reported bootstrap > > problems that need further investigation. Also added a configure.tgt > > for libphobos to allow enabling for targets where there's known good > > runtime support backed by existing continuous integration. > > Why do you need that? The D frontend isn't built by default. > As far as I have seen, all automated builders for gcc are configured with --enable-languages=all however, which is pulling the D frontend in.
On Tue, Oct 30, 2018 at 09:07:30PM +0100, Iain Buclaw wrote: > On Tue, 30 Oct 2018 at 20:50, Andreas Schwab <schwab@linux-m68k.org> wrote: > > > > On Okt 30 2018, Iain Buclaw <ibuclaw@gdcproject.org> wrote: > > > > > This turns off D front-end where there's been reported bootstrap > > > problems that need further investigation. Also added a configure.tgt > > > for libphobos to allow enabling for targets where there's known good > > > runtime support backed by existing continuous integration. > > > > Why do you need that? The D frontend isn't built by default. > > > > As far as I have seen, all automated builders for gcc are configured > with --enable-languages=all however, which is pulling the D frontend > in. You can add powerpc64*-*-* to the list of targets that fail bootstrap with --enable-languages=all ../libphobos/src/std/math.d:242:5: error: static assert "Only 64-bit, 80-bit, and 128-bit reals are supported for LittleEndian CPUs" 242 | static assert(real.mant_dig == 53 || real.mant_dig == 64 | ^
On Wed, 31 Oct 2018 at 05:38, Alan Modra <amodra@gmail.com> wrote: > > On Tue, Oct 30, 2018 at 09:07:30PM +0100, Iain Buclaw wrote: > > On Tue, 30 Oct 2018 at 20:50, Andreas Schwab <schwab@linux-m68k.org> wrote: > > > > > > On Okt 30 2018, Iain Buclaw <ibuclaw@gdcproject.org> wrote: > > > > > > > This turns off D front-end where there's been reported bootstrap > > > > problems that need further investigation. Also added a configure.tgt > > > > for libphobos to allow enabling for targets where there's known good > > > > runtime support backed by existing continuous integration. > > > > > > Why do you need that? The D frontend isn't built by default. > > > > > > > As far as I have seen, all automated builders for gcc are configured > > with --enable-languages=all however, which is pulling the D frontend > > in. > > You can add powerpc64*-*-* to the list of targets that fail bootstrap > with --enable-languages=all > > ../libphobos/src/std/math.d:242:5: error: static assert > "Only 64-bit, 80-bit, and 128-bit reals are supported for LittleEndian CPUs" > 242 | static assert(real.mant_dig == 53 || real.mant_dig == 64 > | ^ > The default path for libphobos is to not build it, so that's covered by this patch.
On Tue, Oct 30, 2018 at 8:25 PM Iain Buclaw <ibuclaw@gdcproject.org> wrote: > > Hi, > > This turns off D front-end where there's been reported bootstrap > problems that need further investigation. Also added a configure.tgt > for libphobos to allow enabling for targets where there's known good > runtime support backed by existing continuous integration. > > For both, this can be overridden if either D or libphobos was > explicitly requested by configure. > > The guards will be loosened as I go through each target configuration. OK. Thanks, Richard. > -- > Iain > > --- > ChangeLog: > > 2018-10-30 Iain Buclaw <ibuclaw@gdcproject.org> > > PR bootstrap/87788 > PR d/87799 > * configure: Rebuild. > * configure.ac: Disable D on systems where it is known not to work. > > libphobos/ChangeLog: > > 2018-10-30 Iain Buclaw <ibuclaw@gdcproject.org> > > PR bootstrap/87789 > PR d/87818 > PR d/87819 > * configure.tgt: New file. > > ---
Hi Iain, > This turns off D front-end where there's been reported bootstrap > problems that need further investigation. Also added a configure.tgt > for libphobos to allow enabling for targets where there's known good > runtime support backed by existing continuous integration. > > For both, this can be overridden if either D or libphobos was > explicitly requested by configure. > > The guards will be loosened as I go through each target configuration. on unsupported targets with --enable-languages=all, this leads to gdc being built. However the gdc.dg tests all FAIL like this: FAIL: gdc.dg/gdc283.d -O0 (test for excess errors) Excess errors: gdc: fatal error: cannot read spec file 'libgphobos.spec': No such file or directory compilation terminated. They need to check if libphobos is present first. Rainer
Hi Iain > On 31 Oct 2018, at 19:35, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: > > Hi Iain, > >> This turns off D front-end where there's been reported bootstrap >> problems that need further investigation. Also added a configure.tgt >> for libphobos to allow enabling for targets where there's known good >> runtime support backed by existing continuous integration. >> >> For both, this can be overridden if either D or libphobos was >> explicitly requested by configure. >> >> The guards will be loosened as I go through each target configuration. > > on unsupported targets with --enable-languages=all, this leads to gdc > being built. However the gdc.dg tests all FAIL like this: > > FAIL: gdc.dg/gdc283.d -O0 (test for excess errors) > Excess errors: > gdc: fatal error: cannot read spec file 'libgphobos.spec': No such file or directory > compilation terminated. > > They need to check if libphobos is present first. maybe if building D .. then libphobos should be automatic (i.e. the opt-in/out for the targets under development is to choose to build/not build D explicitly)? [ that would avoid having to have the UNSUPPORTED stuff in the libphobos/config.tgt too .] would that be an adequate guard? i.e. is there any point to build D FE without also building libphobos? Iain
On 31.10.18 05:37, Alan Modra wrote: > On Tue, Oct 30, 2018 at 09:07:30PM +0100, Iain Buclaw wrote: >> On Tue, 30 Oct 2018 at 20:50, Andreas Schwab <schwab@linux-m68k.org> wrote: >>> >>> On Okt 30 2018, Iain Buclaw <ibuclaw@gdcproject.org> wrote: >>> >>>> This turns off D front-end where there's been reported bootstrap >>>> problems that need further investigation. Also added a configure.tgt >>>> for libphobos to allow enabling for targets where there's known good >>>> runtime support backed by existing continuous integration. >>> >>> Why do you need that? The D frontend isn't built by default. >>> >> >> As far as I have seen, all automated builders for gcc are configured >> with --enable-languages=all however, which is pulling the D frontend >> in. > > You can add powerpc64*-*-* to the list of targets that fail bootstrap > with --enable-languages=all > > ../libphobos/src/std/math.d:242:5: error: static assert > "Only 64-bit, 80-bit, and 128-bit reals are supported for LittleEndian CPUs" > 242 | static assert(real.mant_dig == 53 || real.mant_dig == 64 > | ^ the frontend builds, just libphobos ftbfs
On Wed, 31 Oct 2018, Iain Sandoe wrote: > maybe if building D .. then libphobos should be automatic > (i.e. the opt-in/out for the targets under development is to choose to > build/not build D explicitly)? > > [ that would avoid having to have the UNSUPPORTED stuff in the > libphobos/config.tgt too .] > > would that be an adequate guard? > > i.e. is there any point to build D FE without also building libphobos? Well, --enable-languages=all ought to work everywhere, and automatically disable (via configure.tgt) libraries that aren't supported. And building front ends for all targets (as done by contrib/config-list.mk, which doesn't attempt to build libraries at all) can e.g. show up issues with target macro definitions that only result in build failures in some front ends. (This is a use for being able to build it with --enable-languages=all for GCC development and testing purposes rather than a reason normal users would want that front end.) I haven't tried build-many-glibcs.py --full-gcc since D support went into GCC. The previous list of failures was <https://sourceware.org/ml/libc-alpha/2018-09/msg00110.html> and I expect many of the Ada and libgo issues, where not already fixed, wouldn't actually be that hard to fix.
On Wed, 31 Oct 2018 at 22:56, Joseph Myers <joseph@codesourcery.com> wrote: > > On Wed, 31 Oct 2018, Iain Sandoe wrote: > > > maybe if building D .. then libphobos should be automatic > > (i.e. the opt-in/out for the targets under development is to choose to > > build/not build D explicitly)? > > > > [ that would avoid having to have the UNSUPPORTED stuff in the > > libphobos/config.tgt too .] > > > > would that be an adequate guard? > > > > i.e. is there any point to build D FE without also building libphobos? > > Well, --enable-languages=all ought to work everywhere, and automatically > disable (via configure.tgt) libraries that aren't supported. And building > front ends for all targets (as done by contrib/config-list.mk, which > doesn't attempt to build libraries at all) can e.g. show up issues with > target macro definitions that only result in build failures in some front > ends. (This is a use for being able to build it with > --enable-languages=all for GCC development and testing purposes rather > than a reason normal users would want that front end.) > > I haven't tried build-many-glibcs.py --full-gcc since D support went into > GCC. The previous list of failures was > <https://sourceware.org/ml/libc-alpha/2018-09/msg00110.html> and I expect > many of the Ada and libgo issues, where not already fixed, wouldn't > actually be that hard to fix. > Whilst initially looking at one bootstrap failure, I got a couple more in that initially surprised me. I want to remove the disabling of the D front-end, but I would prefer checking each myself without too much pressure, as I don't readily have available all affected platforms.
diff --git a/configure b/configure index 77e7e1869ba..20741aef7e3 100755 --- a/configure +++ b/configure @@ -3345,6 +3345,40 @@ if test "${ENABLE_LIBSTDCXX}" = "default" ; then esac fi +# Disable D on systems where it is known to not work. +# For testing, you can override this with --enable-languages=d. +case ,${enable_languages}, in + *,d,*) + ;; + *) + case "${target}" in + *-*-darwin* | *-*-cygwin* | *-*-mingw*) + unsupported_languages="$unsupported_languages d" + ;; + esac + ;; +esac + +# Disable libphobos on unsupported systems. +# For testing, you can override this with --enable-libphobos. +if test -d ${srcdir}/libphobos; then + if test x$enable_libphobos = x; then + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for libphobos support" >&5 +$as_echo_n "checking for libphobos support... " >&6; } + if (srcdir=${srcdir}/libphobos; \ + . ${srcdir}/configure.tgt; \ + test -n "$UNSUPPORTED") + then + { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5 +$as_echo "no" >&6; } + noconfigdirs="$noconfigdirs target-libphobos" + else + { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5 +$as_echo "yes" >&6; } + fi + fi +fi + # Disable Fortran for some systems. case "${target}" in mmix-*-*) diff --git a/configure.ac b/configure.ac index 1e5979dc043..b10212b3be5 100644 --- a/configure.ac +++ b/configure.ac @@ -674,6 +674,37 @@ if test "${ENABLE_LIBSTDCXX}" = "default" ; then esac fi +# Disable D on systems where it is known to not work. +# For testing, you can override this with --enable-languages=d. +case ,${enable_languages}, in + *,d,*) + ;; + *) + case "${target}" in + *-*-darwin* | *-*-cygwin* | *-*-mingw*) + unsupported_languages="$unsupported_languages d" + ;; + esac + ;; +esac + +# Disable libphobos on unsupported systems. +# For testing, you can override this with --enable-libphobos. +if test -d ${srcdir}/libphobos; then + if test x$enable_libphobos = x; then + AC_MSG_CHECKING([for libphobos support]) + if (srcdir=${srcdir}/libphobos; \ + . ${srcdir}/configure.tgt; \ + test -n "$UNSUPPORTED") + then + AC_MSG_RESULT([no]) + noconfigdirs="$noconfigdirs target-libphobos" + else + AC_MSG_RESULT([yes]) + fi + fi +fi + # Disable Fortran for some systems. case "${target}" in mmix-*-*) diff --git a/libphobos/configure.tgt b/libphobos/configure.tgt new file mode 100644 index 00000000000..8afd350c755 --- /dev/null +++ b/libphobos/configure.tgt @@ -0,0 +1,36 @@ +# -*- shell-script -*- +# Copyright (C) 2018 Free Software Foundation, Inc. +# +# GCC is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3, or (at your option) +# any later version. +# +# GCC is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with GCC; see the file COPYING3. If not see +# <http://www.gnu.org/licenses/>. + +# This is the target specific configuration file. This is invoked by the +# autoconf generated configure script. Putting it in a separate shell file +# lets us skip running autoconf when modifying target specific information. + +# Disable the libphobos or libdruntime components on untested or known +# broken systems. More targets shall be added after testing. +case "${target}" in + arm*-*-linux*) + ;; + mips*-*-linux*) + ;; + x86_64-*-kfreebsd*-gnu | i?86-*-kfreebsd*-gnu) + ;; + x86_64-*-linux* | i?86-*-linux*) + ;; + *) + UNSUPPORTED=1 + ;; +esac