Solaris SPARC GCC 11.1 build with Ada fails: $ pwd /builds/psumbera/userland-gcc-11.1/components/gcc10/build/sparcv9/gcc/ada/rts_32 $ /builds/psumbera/userland-gcc-11.1/components/gcc10/build/sparcv9/./gcc/xgcc -B/builds/psumbera/userland-gcc-11.1/components/gcc10/build/sparcv9/./gcc/ -B/usr/gcc/11/sparcv9-sun-solaris2.11/bin/ -B/usr/gcc/11/sparcv9-sun-solaris2.11/lib/ -isystem /usr/gcc/11/sparcv9-sun-solaris2.11/include -isystem /usr/gcc/11/sparcv9-sun-solaris2.11/sys-include -fchecking=1 -c -g -O2 -m32 -fPIC -W -Wall -gnatpg -nostdinc -m32 g-calend.adb -o g-calend.o | less i-cexten.ads:278:28: modulus exceeds limit (2 ** 64) i-cexten.ads:281:28: modulus exceeds limit (2 ** 64) ... i-cexten.ads:659:22: integer type definition bounds out of range i-cexten.ads:662:22: integer type definition bounds out of range i-cexten.ads:665:22: integer type definition bounds out of range .. vi i-cexten.ads: 278 type Unsigned_65 is mod 2 ** 65; 279 for Unsigned_65'Size use 65; .. 659 type Signed_65 is range -2 ** 64 .. 2 ** 64 - 1; 660 for Signed_65'Size use 65; -- GCC 10.3 builds with Ada without problems. GCC 11.1 on intel builds with Ada without problems.
I think it's related to: [Ada] Clean up in Interfaces.C.Extensions https://github.com/gcc-mirror/gcc/commit/eafbde5131d2926fdc48b1c663d03865c9a37302
This is known to work though, so could you post the configure line?
(cd /builds/psumbera/userland-gcc-11.1/components/gcc10/build/sparcv9 ; /usr/bin/env CONFIG_SHELL="/bin/sh" PKG_CONFIG_PATH="/usr/lib/sparcv9/pkgconfig" CC="/builds/psumbera/gcc10/bin/gcc" CXX="/builds/psumbera/gcc10/bin/g++" PATH="/usr/bin/sparcv9:/builds/psumbera/gcc10/bin:/usr/gnu/bin:/usr/bin:/usr/perl5/bin" CC_FOR_BUILD="/builds/psumbera/gcc10/bin/gcc -m64" CXX_FOR_BUILD="/builds/psumbera/gcc10/bin/g++ -m64" CPPFLAGS="-m64" "ac_cv_func_realloc_0_nonnull=yes" "NM=/usr/gnu/bin/nm" INTLTOOL_PERL="/usr/perl5/5.22/bin/perl" LDFLAGS="" http_proxy= https_proxy= ftp_proxy= PYTHON="/usr/bin/python3.7" /bin/sh \ /builds/psumbera/userland-gcc-11.1/components/gcc10/gcc-11.1.0/configure --prefix=/usr/gcc/11 --mandir=/usr/gcc/11/share/man --bindir=/usr/gcc/11/bin --sbindir=/usr/gcc/11/sbin --libdir=/usr/gcc/11/lib --infodir=/usr/gcc/11/share/info --libexecdir=/usr/gcc/11/lib --enable-languages="ada,c,c++,fortran,go,objc" --enable-shared --enable-initfini-array --disable-rpath --with-system-zlib --with-build-config=no --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/gnu/bin/as BOOT_CFLAGS='-g -O2' sparcv9-sun-solaris2.11)
> (cd /builds/psumbera/userland-gcc-11.1/components/gcc10/build/sparcv9 ; > /usr/bin/env CONFIG_SHELL="/bin/sh" > PKG_CONFIG_PATH="/usr/lib/sparcv9/pkgconfig" > CC="/builds/psumbera/gcc10/bin/gcc" CXX="/builds/psumbera/gcc10/bin/g++" > PATH="/usr/bin/sparcv9:/builds/psumbera/gcc10/bin:/usr/gnu/bin:/usr/bin:/usr/ > perl5/bin" CC_FOR_BUILD="/builds/psumbera/gcc10/bin/gcc -m64" > CXX_FOR_BUILD="/builds/psumbera/gcc10/bin/g++ -m64" CPPFLAGS="-m64" > "ac_cv_func_realloc_0_nonnull=yes" "NM=/usr/gnu/bin/nm" > INTLTOOL_PERL="/usr/perl5/5.22/bin/perl" LDFLAGS="" http_proxy= https_proxy= > ftp_proxy= PYTHON="/usr/bin/python3.7" /bin/sh \ > > /builds/psumbera/userland-gcc-11.1/components/gcc10/gcc-11.1.0/configure > --prefix=/usr/gcc/11 --mandir=/usr/gcc/11/share/man --bindir=/usr/gcc/11/bin > --sbindir=/usr/gcc/11/sbin --libdir=/usr/gcc/11/lib > --infodir=/usr/gcc/11/share/info --libexecdir=/usr/gcc/11/lib > --enable-languages="ada,c,c++,fortran,go,objc" --enable-shared > --enable-initfini-array --disable-rpath --with-system-zlib > --with-build-config=no --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as > --with-as=/usr/gnu/bin/as BOOT_CFLAGS='-g -O2' sparcv9-sun-solaris2.11) Thanks. What configure line do you use for the Intel build?
(In reply to Eric Botcazou from comment #4) > Thanks. What configure line do you use for the Intel build? (cd /builds/psumbera/userland-gcc-11.1/components/gcc10/build/amd64 ; /usr/bin/env CONFIG_SHELL="/bin/sh" PKG_CONFIG_PATH="/usr/lib/amd64/pkgconfig" CC="/builds/psumbera/gcc10/bin/gcc" CXX="/builds/psumbera/gcc10/bin/g++" PATH="/usr/bin/amd64:/builds/psumbera/gcc10/bin:/usr/gnu/bin:/usr/bin:/usr/perl5/bin" CC_FOR_BUILD="/builds/psumbera/gcc10/bin/gcc -m64" CXX_FOR_BUILD="/builds/psumbera/gcc10/bin/g++ -m64" CPPFLAGS="-m64" "ac_cv_func_realloc_0_nonnull=yes" "NM=/usr/gnu/bin/nm" INTLTOOL_PERL="/usr/perl5/5.22/bin/perl" LDFLAGS="" http_proxy= https_proxy= ftp_proxy= PYTHON="/usr/bin/python3.7" /bin/sh \ /builds/psumbera/userland-gcc-11.1/components/gcc10/gcc-11.1.0/configure --prefix=/usr/gcc/11 --mandir=/usr/gcc/11/share/man --bindir=/usr/gcc/11/bin --sbindir=/usr/gcc/11/sbin --libdir=/usr/gcc/11/lib --infodir=/usr/gcc/11/share/info --libexecdir=/usr/gcc/11/lib --enable-languages="ada,c,c++,fortran,go,objc" --enable-shared --enable-initfini-array --disable-rpath --with-system-zlib --with-build-config=no --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/gnu/bin/as BOOT_CFLAGS='-g -O2' x86_64-pc-solaris2.11)
> /builds/psumbera/userland-gcc-11.1/components/gcc10/gcc-11.1.0/configure > --prefix=/usr/gcc/11 --mandir=/usr/gcc/11/share/man --bindir=/usr/gcc/11/bin > --sbindir=/usr/gcc/11/sbin --libdir=/usr/gcc/11/lib > --infodir=/usr/gcc/11/share/info --libexecdir=/usr/gcc/11/lib > --enable-languages="ada,c,c++,fortran,go,objc" --enable-shared > --enable-initfini-array --disable-rpath --with-system-zlib > --with-build-config=no --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as > --with-as=/usr/gnu/bin/as BOOT_CFLAGS='-g -O2' x86_64-pc-solaris2.11) Thanks. A bit of mystery then, the configurations are exactly symmetrical. Have you made local modifications to the source code or is it pristine?
(In reply to Eric Botcazou from comment #6) > Have you made local modifications to the source code or is it pristine? No local changes. I wonder where i-cexten.ads is being modified...
> No local changes. > > I wonder where i-cexten.ads is being modified... Unlikely I'd say. Could you go into the $(buildir]/gcc/ada directory and do: ls -l rts/i-cexten.ads ls -l rts_32/i-cexten.ads They should not point to the same source file.
(In reply to Eric Botcazou from comment #8) > Unlikely I'd say. Could you go into the $(buildir]/gcc/ada directory and do: > ls -l rts/i-cexten.ads > ls -l rts_32/i-cexten.ads > They should not point to the same source file. There is indeed some problem: intel: rts/i-cexten.ads -> /builds/psumbera/userland-gcc-11.1/components/gcc10/gcc-11.1.0/gcc/ada/libgnat/i-cexten__128.ads rts_32/i-cexten.ads -> /builds/psumbera/userland-gcc-11.1/components/gcc10/gcc-11.1.0/gcc/ada/libgnat/i-cexten.ads SPARC: rts/i-cexten.ads -> /builds/psumbera/userland-gcc-11.1/components/gcc10/gcc-11.1.0/gcc/ada/libgnat/i-cexten__128.ads rts_32/i-cexten.ads -> /builds/psumbera/userland-gcc-11.1/components/gcc10/gcc-11.1.0/gcc/ada/libgnat/i-cexten__128.ads
Rainer, what's the name of the RTS subdir for the 32-bit Ada runtime in your sparcv9-sun-solaris2.11 builds? It's really rts_32 or rts_sparcv8plus? -print-multi-directory
Can you post the contents of $(srcdir)/gcc/config/sparc/t-sol2 in your setup?
(In reply to Eric Botcazou from comment #11) > Can you post the contents of $(srcdir)/gcc/config/sparc/t-sol2 in your setup? $ cat gcc-11.1.0/gcc/config/sparc/t-sol2 MULTILIB_OPTIONS = m32/m64 MULTILIB_DIRNAMES = 32 sparcv9 MULTILIB_MATCHES = MULTILIB_OSDIRNAMES = . sparcv9
> $ cat gcc-11.1.0/gcc/config/sparc/t-sol2 > MULTILIB_OPTIONS = m32/m64 > MULTILIB_DIRNAMES = 32 sparcv9 > MULTILIB_MATCHES = > MULTILIB_OSDIRNAMES = . sparcv9 So you have a local modification after all, here is the pristine file: eric@fomalhaut:~/tmp/gcc-11.1.0> cat gcc/config/sparc/t-sol2 MULTILIB_OPTIONS = m32/m64 MULTILIB_DIRNAMES = sparcv8plus sparcv9 MULTILIB_MATCHES = MULTILIB_OSDIRNAMES = . sparcv9 You need to do s/sparcv8plus/32/ on $(srcdir)/gcc/ada/Makefile.rtl as well.
(In reply to Eric Botcazou from comment #13) > > $ cat gcc-11.1.0/gcc/config/sparc/t-sol2 > > MULTILIB_OPTIONS = m32/m64 > > MULTILIB_DIRNAMES = 32 sparcv9 > > MULTILIB_MATCHES = > > MULTILIB_OSDIRNAMES = . sparcv9 > > So you have a local modification after all, here is the pristine file: > > eric@fomalhaut:~/tmp/gcc-11.1.0> cat gcc/config/sparc/t-sol2 > MULTILIB_OPTIONS = m32/m64 > MULTILIB_DIRNAMES = sparcv8plus sparcv9 > MULTILIB_MATCHES = > MULTILIB_OSDIRNAMES = . sparcv9 > > You need to do s/sparcv8plus/32/ on $(srcdir)/gcc/ada/Makefile.rtl as well. Thank you very much! I'm trying it now. I don't know the history of the change: https://github.com/oracle/solaris-userland/blob/master/components/gcc10/patches/001-multilib-sparc.patch It has following comment: # We want sparc/i386 to match locations for their 32 bit support when building # multilib. For now use the more generic /32. This has not been filed # upstream. I wonder whether it makes sense to have it in upstream?
> --- Comment #14 from Petr Sumbera <sumbera at volny dot cz> --- [...] > It has following comment: > > # We want sparc/i386 to match locations for their 32 bit support when building > # multilib. For now use the more generic /32. This has not been filed > # upstream. > > I wonder whether it makes sense to have it in upstream? I'd seen that change before in solaris-userland, but never understood the point. Those directories are only used inside the build trees.
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #15) > > --- Comment #14 from Petr Sumbera <sumbera at volny dot cz> --- > [...] > > It has following comment: > > > > # We want sparc/i386 to match locations for their 32 bit support when building > > # multilib. For now use the more generic /32. This has not been filed > > # upstream. > > > > I wonder whether it makes sense to have it in upstream? > > I'd seen that change before in solaris-userland, but never understood > the point. Those directories are only used inside the build trees. Ok. I will see if we can remove it for GCC 11.
(In reply to Petr Sumbera from comment #16) > (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #15) > > I'd seen that change before in solaris-userland, but never understood > > the point. Those directories are only used inside the build trees. > > Ok. I will see if we can remove it for GCC 11. I think it was done because of packaging. So that SPARC and Intel would have more similar paths (in one manifest file). But it can be overcome. I will try to avoid the patch file.