[Bug c/92720] New: cc1 accepts #include /dev/stdin inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720
Bug ID: 92720
Summary: cc1 accepts #include /dev/stdin inline
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dclarke at blastwave dot org
Target Milestone: ---
Strangely I see recent cc1 accept this :
/* echo '"hell"' | cc -o tmp tmp.c && ./tmp */
#include
int main(void) {
printf("%s\n",
#include"/dev/stdin"
);
}
For example this is accepted :
$ echo '\042hello botfelk\\n\042' | gcc -m64 -std=iso9899:1999 \
> -pedantic -pedantic-errors -Wpedantic -fno-builtin -O0 -v \
> -o /tmp/botfelk /tmp/botfelk.c
That is considered acceptable whereas Oracle Studio 12.6 c99
clearly complains :
beta$ echo '\042hello botfelk\\n\042' | $CC $CFLAGS $CPPFLAGS -\# -H -o
/tmp/botfelk /tmp/botfelk.c
### c99: Note: NLSPATH =
/opt/developerstudio12.6/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/developerstudio12.6/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
### c99: Note: TMPDIR = /var/tmp/dclarke
### command line files and options (expanded):
### -m64 -xarch=sparc -Xc -xdebuginfo=line,param,variable,tagtype,codetag,decl
-xglobalize=yes -xpatchpadding=fix -xkeep_unref=funcs,vars -mc -xs=yes
-errfmt=error -erroff=%none -errshort=full -errtags=yes -errwarn=%none
-ftrap=%none -xbuiltin=%none -xlibmieee -xstrconst -xcode=pic32 -xmemalign=8s
-xnolibmil -xunroll=1 -xregs=no%appl -xdebugformat=dwarf -I/usr/local/include
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO
-D_XOPEN_SOURCE=600 -# -H -o/tmp/botfelk /tmp/botfelk.c
/opt/developerstudio12.6/lib/compilers/bin/acomp -D_POSIX_PTHREAD_SEMANTICS
-D_LARGEFILE64_SOURCE -D_TS_ERRNO -D_XOPEN_SOURCE=600 -H -Qy -Xc -xc99=%all
-features=no%mergestrings,extinl,no%typeof,no%extensions,conststrings,no%zla,no%iddollar,no%gcc_enums
-i /tmp/botfelk.c -D__SunOS_5_10 -D__SunOS_RELEASE=0x051000 -D__SUNPRO_C=0x5150
-D__unix -D__SVR4__ -D__svr4__ -D__SVR4 -D__sun -D__sun__ -D__SunOS -D__sparcv9
-D__sparc_v9__ -D__sparc -D__sparc__ -D_LP64 -D__LP64__ -D__arch64__
-D__ORDER_LITTLE_ENDIAN__=1234 -D__ORDER_BIG_ENDIAN__=4321
-D__BYTE_ORDER__=__ORDER_BIG_ENDIAN__ -D__BUILTIN_VA_ARG_INCR -D__C99FEATURES__
-D__PRAGMA_REDEFINE_EXTNAME -D__FLT_EVAL_METHOD__=0 -D__SUN_PREFETCH
-I/usr/local/include -I-xbuiltin
-I/opt/developerstudio12.6/lib/compilers/include/cc -I/usr/xpg6/include
-I/usr/xpg4/include -2K -errfmt=error -erroff=%none -errshort=full
-errwarn=%none -errtags -xwarn_include_dir=permission -xbuiltin=%none -strconst
-fsimple=0 -m64 -fparam_ir -fparam_ir -xglobalize=yes
-xdebuginfo=line,param,variable,tagtype,codetag,decl -xkeep_unref=funcs,vars
-xF=%none -xdbggen=dwarf+usedonly+incl+line+param+variable+tagtype+codetag+decl
-xldscope=global -xivdep=loop -xanalyze=code -c99OS
"-g/opt/developerstudio12.6/bin/c99 -m64 -xarch=sparc -Xc -g -mc -xs
-errfmt=error -erroff=%none -errshort=full -errtags=yes -errwarn=%none
-ftrap=%none -xbuiltin=%none -xildoff -xlibmieee -xstrconst -xcode=pic32
-xmemalign=8s -xnolibmil -xunroll=1 -xregs=no%appl -xdebugformat=dwarf
-I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
-D_TS_ERRNO -D_XOPEN_SOURCE='600' -H " -destination_ir=iropt -r
/var/tmp/dclarke/acomp.1574993356.16502.01.ir
/usr/include/stdio.h
/usr/include/sys/feature_tests.h
/usr/include/sys/ccompile.h
/usr/include/sys/isa_defs.h
/usr/include/iso/stdio_iso.h
/usr/include/sys/va_list.h
/usr/include/stdio_tag.h
/usr/include/stdio_impl.h
/usr/include/iso/stdio_c99.h
/dev/stdin
"/tmp/botfelk.c", line 8: error: syntax error before or at: )
c99: acomp failed for /tmp/botfelk.c
beta$
beta$
This may require a bit of a dive into the specifications however
an inline include of /dev/stdin seems wrong for some definition
of wrong.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
[Bug c/92720] cc1 accepts #include /dev/stdin inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720 --- Comment #5 from Dennis Clarke --- Glad someone looked at this. I was going to try again with LLVM/Clang and then a few other places on a few other architectures. Why bother? However if this is "implementation defined" then we should see a paragraph somewhere in a standards doc regarding this. Somewhere.
[Bug c/92720] cc1 accepts #include /dev/stdin inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720 --- Comment #7 from Dennis Clarke --- Looking at the document n1256 "ISO/IEC 9899:TC3 WG14/N125" ye C99 specifications we see section 6.10.2 Source file inclusion subsection 1 which almost seems clear : A #include directive shall identify a header or source file that can be processed by the implementation. Sort of a vague idea there. Whatever "can be" means. However the file /dev/stdin really is neither a "header" nor is it a "source" file. As people are saying, this is all "implementation" defined perhaps. I feel that no file shall be included if it is neither a "source" file nor a valid "header". No idea how one would verify such a condition at the pre-processing translation stage. However I also see : 5.1.1.2 Translation phases The precedence among the syntax rules of translation is specified by the following phases.[5] 1. Physical source file multibyte characters are mapped, in an implementation-defined manner, to the source character set (introducing new-line characters forend-of-line indicators) if necessary. Trigraph sequences are replaced by corresponding single-character internal representations. Where the footnote [5] states : 5 Implementations shall behave as if these separate phases occur, even though many are typically folded together in practice. Source files, translation units, and translated translation units need not necessarily be stored as files, nor need there be any one-to-one correspondence between these entities and any external representation. The description is conceptual only, and does not specify any particular implementation. That seems to imply I could just as easily do an include of /dev/random. Dennis
[Bug c/92720] cc1 accepts #include /dev/stdin inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720 --- Comment #8 from Dennis Clarke --- (In reply to jos...@codesourcery.com from comment #6) . . . > In turn, that section "Include Operation" has more details. It doesn't > mention includes with an absolute path, but I think that's because the > general concept of resolving a path relative to a directory, and how that > handles absolute paths, is one for the underlying operating system, not > for any particular application running on that operating system. I hope someone agrees that this seems like black magic : esther$ esther$ uname -a Linux esther 5.3.0-2-686 #1 SMP Debian 5.3.9-3 (2019-11-19) i686 GNU/Linux esther$ cat /proc/version Linux version 5.3.0-2-686 (debian-ker...@lists.debian.org) (gcc version 9.2.1 20191109 (Debian 9.2.1-19)) #1 SMP Debian 5.3.9-3 (2019-11-19) esther$ gcc --version gcc (Debian 9.2.1-19) 9.2.1 20191109 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. esther$ ( /usr/bin/printf "\042"; dd if=/dev/urandom bs=16 count=1 2>/dev/null | od -Ax -t x1 -v | tr -d '\012' | cut -c8-54 | tr -d '\012';/usr/bin/printf "\042\n" ) | gcc -std=iso9899:1999 -pedantic -pedantic-errors -Wpedantic -fno-builtin -O0 -D_XOPEN_SOURCE=600 -o /tmp/wtf /tmp/wtf.c esther$ /tmp/wtf 1e e8 6e 82 6a a4 0b 66 0f d5 48 33 2a 86 21 6b esther$ Which makes one wonder what would happen if I were to merely include /dev/urandom directly. Dennis
[Bug bootstrap/88633] New: stage2 failure due to undefined reference to libintl_dgettext on armv7l-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88633 Bug ID: 88633 Summary: stage2 failure due to undefined reference to libintl_dgettext on armv7l-linux-gnueabihf Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dclarke at blastwave dot org Target Milestone: --- This has been repeatable and while configure and stage 1 seems fine the process fails in stage 2 thus : arm7$ uname -a Linux arm7 4.4.132+ #1 SMP Tue Oct 23 18:03:49 CST 2018 armv7l GNU/Linux arm7$ cat /etc/debian_version 9.6 arm7$ date -u Fri Dec 28 12:42:15 UTC 2018 A set of essential tools and libs are already built, tested and installed into the path /opt/bw and that includes libiconv and gettext. arm7$ LD_RUN_PATH=/opt/bw/lib LD_FLAGS=\-L/opt/bw/lib \ > RUNPATH=/opt/bw/lib \ > ../gcc-8.2.0/configure \ > --build=armv7l-linux-gnueabihf \ > --target=armv7l-linux-gnueabihf \ > --host=armv7l-linux-gnueabihf \ > --prefix=/opt/intermediate/gcc8 \ > --disable-nls --enable-threads=posix --enable-shared --enable-bootstrap \ > --enable-linker-build-id --libexecdir=/opt/bw/lib --libdir=/opt/bw/lib \ > --with-system-zlib --with-target-system-zlib \ > --enable-multiarch --with-arch=armv7-a --with-fpu=vfpv4-d16 \ > --with-float=hard --with-mode=thumb --enable-checking=release \ > --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-__cxa_atexit \ > --with-long-double-128 --enable-stage1-languages=c,c++ \ > --enable-stage1-checking=misc --with-as=/usr/bin/as --with-ld=/usr/bin/ld \ > --enable-languages=c,c++,fortran,go,lto,objc,obj-c++ \ > --with-pkgversion='genunix intermediate Fri Dec 28 12:42:15 UTC 2018' checking build system type... armv7l-unknown-linux-gnueabihf checking host system type... armv7l-unknown-linux-gnueabihf checking target system type... armv7l-unknown-linux-gnueabihf checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /bin/sed checking for gawk... no checking for mawk... mawk checking for libatomic support... yes checking for libitm support... yes checking for libsanitizer support... yes checking for libvtv support... yes checking for libmpx support... no checking for libhsail-rt support... no checking for armv7l-linux-gnueabihf-gcc... /usr/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/gcc accepts -g... yes checking for /usr/bin/gcc option to accept ISO C89... none needed checking whether we are using the GNU C++ compiler... yes checking whether /usr/bin/g++ accepts -g... yes checking whether g++ accepts -static-libstdc++ -static-libgcc... yes checking for armv7l-linux-gnueabihf-gnatbind... no checking for gnatbind... no checking for armv7l-linux-gnueabihf-gnatmake... no checking for gnatmake... no checking whether compiler driver understands Ada... no checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for objdir... .libs configure: WARNING: using in-tree isl, disabling version check *** This configuration is not supported in the following subdirectories: zlib target-libmpx gnattools target-libada target-libhsail-rt target-liboffloadmic (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug checking for --enable-vtable-verify... no checking for bison... bison -y checking for bison... bison checking for gm4... /opt/bw/bin/m4 checking for flex... no checking for lex... no checking for flex... no checking for makeinfo... no /opt/bw/build/gcc-8.2.0/missing: 81: /opt/bw/build/gcc-8.2.0/missing: makeinfo: not found checking for expect... no checking for runtest... no checking for ar... (cached) /usr/bin/ar checking for armv7l-linux-gnueabihf-ar... (cached) /usr/bin/ar checking for as... (cached) /usr/bin/as checking for armv7l-linux-gnueabihf-as... (cached) /usr/bin/as checking for armv7l-linux-gnueabihf-dlltool... no checking for dlltool... no checking for ld... (cached) /usr/bin/ld checking for armv7l-linux-gnueabihf-ld... (cached) /usr/bin/ld checking for armv7l-linux-gnueabihf-lipo... no checking for lipo... no checking for armv7l-linux-gnueabihf-nm... no checking for nm... nm checking for ranlib... (cached) /usr/bin/ranlib checking for armv7l-linux-gnueabihf-ranlib... (cached) /usr/bin/ranlib checking for strip... (cached) /usr/bin/strip checking for armv7l-linux-gnueabihf-strip... (cached) /usr/bin/strip checking for armv7l-linux-gnueabihf-windres.
[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686 --- Comment #12 from Dennis Clarke --- Thanks .. I'll give that a try. The real objective here is to get a simple native bootstrap going which includes libquadmath. My concern is that there is no support for that unless the ppc64 system has the POWER AVX support and that certainly isn't the older PPC970 chips.
[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686 --- Comment #13 from Dennis Clarke --- Finally managed to get a decent looking three stage bootstrap to complete without bizarre errors. Thanks to Matthias Klose for the suggestion to get away from that gc issue entirely. Testsuite is running however I am not thrilled with what I see : === gcc Summary === # of expected passes112961 # of unexpected failures910 # of unexpected successes 22 # of expected failures 347 # of unresolved testcases 1 # of unsupported tests 2794 /usr/local/build/gcc-7.3.0_linux_4.15.0-2-powerpc64_ppc64.005/gcc/xgcc version 7.3.0 (genunix Mon Apr 16 00:04:56 GMT 2018) I'll followup with the libquadmath issues that may yet exist. Not sure yet. Dennis
[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686 --- Comment #14 from Dennis Clarke --- Since this bug was a "bootstrap" issue I think I should close it as simply an issue related to the garbage collector libs needed.
[Bug libquadmath/85440] New: libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
Bug ID: 85440
Summary: libquadmath and quadmath.h do not exist on ppc64
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libquadmath
Assignee: unassigned at gcc dot gnu.org
Reporter: dclarke at blastwave dot org
Target Milestone: ---
Seems fairly clear that while the info file does get installed
into share/info/libquadmath.info the actual lib and header do
not exist.
Could be bug 55821 here again.
You can see the testsuite report at :
https://gcc.gnu.org/ml/gcc-testresults/2018-04/msg01351.html
The ramifications here seem to be that one can not compile much of
anything that uses the new 128-bit IEEE 754-2008 datatypes on this
platform and any attempt to do so results in :
foo.c:3:10: fatal error: quadmath.h: No such file or directory
#include
^~~~
compilation terminated.
Any attempt to use the -mabi=ieeelongdouble option results in horrific
results that are no where even remotely close to correct :
nix$ cat ld.c
#define _XOPEN_SOURCE 600
#include
#include
int main ( int argc, char *argv[] ) {
int j;
/* correct 128 bit big endian hex representation of pi is
* 0x40 00 92 1f b5 44 42 d1 84 69 89 8c c5 17 01 b8 */
long double pi = 3.14159265358979323846264338327950288419716939937510L;
printf("\nstack address of variable \"pi\" is %p\n", &pi );
printf("\ncontents : 0x" );
for ( j=0; jhttps://sourceware.org/ml/libc-alpha/2017-08/msg00010.html
The GNU C Library version 2.27 is now available
https://sourceware.org/ml/libc-announce/2018/msg0.html
Or perhaps non-IBM Power variations are simply not supported?
[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686 --- Comment #15 from Dennis Clarke --- The real issue here is libquadmath which seems to be based on sources from Sun Microsystems software implementation of the 128-bit floating point operations. see 85440
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #2 from Dennis Clarke --- Thank you very much Sir! So then .. where is this gcc 8 that you speak of ? Still just a nightly test release or is there an actual tarball hidden away?
[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686 --- Comment #16 from Dennis Clarke --- Can we close this as a non-issue?
[Bug bootstrap/82037] Debian 8.8 powerpc64-unknown-linux-gnu bootstrap breaks in stage1 with gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037 --- Comment #10 from Dennis Clarke --- Can we close this as a non-issue?
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 Dennis Clarke changed: What|Removed |Added Known to work|8.0 | --- Comment #4 from Dennis Clarke --- Why was the "Known to work" changed to "8.0" when no such release exists? I am going to delete that. For the moment it seems that a git pull and build from trunk needs to be done in order to test the "theory" that libquadmath will actually work in various places. This will include sparc64 on both Debian linux and Solaris.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #6 from Dennis Clarke --- Following the instructions at https://gcc.gnu.org/wiki/GitMirror there is no branch anywhere that claims to be a version 8 type. Where is this ver 8 code hidden away ?
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #7 from Dennis Clarke --- found this : https://gcc.gnu.org/pub/gcc/snapshots/LATEST-8/ I will give that a try.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #9 from Dennis Clarke --- Thank you Sir. I think it best if I stay with the nightly/test tarball found at https://gcc.gnu.org/pub/gcc/snapshots/LATEST-8/ and then I won't have to fiddle with automake/reconf etc or be too concerned with configure.am and all that jazz.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #10 from Dennis Clarke --- Well, current gcc 8 snapshot doesn't work : nix_$ nix_$ /usr/local/gcc8/bin/gcc --version gcc (genunix Wed Apr 18 19:16:29 GMT 2018) 8.0.1 20180415 (experimental) Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. nix_$ /usr/local/gcc8/bin/gcc -m64 -mcpu=970 -o s s.c s.c:82:10: fatal error: quadmath.h: No such file or directory #include ^~~~ compilation terminated. nix_$
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 Dennis Clarke changed: What|Removed |Added Known to work|8.0 | --- Comment #14 from Dennis Clarke --- We are going in circles here. Neither libquadmath nor the required header exist nor function on the powerpc64 target wherein the processor is NOT an IBM power type unit. It is NOT known to work with gcc version 8 either as I have tested for that and the answer is a clear no. This is NOT a power8 nor a power7 nor any version thereof. This is the classic IBM PowerPC 970FX processor. This is big endian. There is NOT an option for "VSX by default". The real issue seems to lay down inside glibc, which I was looking at from the very beginning and I had already said the "non-IBM Power variations are simply not supported" and in glibc 2.26 we see : On ia64, powerpc64le, x86-32, and x86-64, the math library now implements 128-bit floating point as defined by ISO/IEC/IEEE 60559:2011 (IEEE 754-2008) and ISO/IEC TS 18661-3:2015. Contributed by Paul E. Murphy, Gabriel F. T. Gomes, Tulio Magno Quites Machado Filho, and Joseph Myers. To compile programs that use this feature, the compiler must support 128-bit floating point with the type name _Float128 (as defined by TS 18661-3) or __float128 (the nonstandard name used by GCC for C++, and for C prior to version 7). _GNU_SOURCE or __STDC_WANT_IEC_60559_TYPES_EXT__ must be defined to make the new interfaces visible. The new functions and macros correspond to those present for other floating-point types (except for a few obsolescent interfaces not supported for the new type), with F128 or f128 suffixes; for example, strtof128, HUGE_VAL_F128 and cosf128. Following TS 18661-3, there are no printf or scanf formats for the new type; the strfromf128 and strtof128 interfaces should be used instead. This was soon followed by 2.27 wherein : On platforms where long double has the IEEE binary128 format (aarch64, alpha, mips64, riscv, s390 and sparc), the math library now implements _Float128 interfaces for that type, as defined by ISO/IEC TS 18661-3:2015. These are the same interfaces added in version 2.26 for some platforms where this format is supported but is not the format of long double. However the gcc version 8 20180415 will compile C source and produce assembly that clearly uses the 128-bit IEEE 754-2008 format for floating point data however the options for -mfloat128 and -mfloat128-hardware clearly won't work here. The manual page is slightly misleading for "RS/6000 and PowerPC" options as really there needs to exist a page for "IBM Power" options. The options for abi ibmlongdouble and ieeelongdouble both work as expected and I have already shown that along with the output assembly wherein we do actually get both 128-bit datatypes : gcc: warning: using IBM extended precision long double cc1: warning: using IBM extended precision long double .quad 0x400921fb54442d18,0x3ca1a62633145c06 $ /usr/local/gcc7/bin/gcc -m64 -g -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec -mfull-toc -mregnames -mabi=ieeelongdouble -S -o ld.s ld.c ; grep "quad" ld.s | grep "0x" gcc: warning: using IEEE extended precision long double cc1: warning: using IEEE extended precision long double .quad 0x4000921fb54442d1,0x8469898cc51701b8 Regardless how you slice it here and want to say "works in ver 8" it simply does not and I have a powerpc 64-bit big-endian machine right here that bootstraps both version 7.3.0 and the available ver 8 test tarball just fine. Neither can do anything with libquadmath on this architecture as it is clearly not one of the IBM Power variants under Power ISA v.2.07 spec. Perhaps there needs to be a new manual page for "IBM RS/6000 and PowerPC Options" because really there exists the "IBM Power" systems and then the older "IBM RS/6000 and PowerPC Options". That may also cover the whole SoC type chips that we saw so many of from FreeScale and Motorola at one point. Someone, whomever it is, stop flipping this as "known to work on 8" where that just isn't true.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #16 from Dennis Clarke --- Dear Jakub Jelinek : Exactly. Yes, I think the libmpfr/libgmp seem to work perfectly here but the real issue is that the old 970 and pre Power ISA v.2.03 spec type hardware is a historical artifact like the old DEC Alpha. I see that in gcc 7.3.0 we do get share/info/libquadmath.info installed BUT in gcc 8 we do not. This is good. It is annoying that the gcc compiler will produce the correct assembly for both the IBM long double and the IEEE 754-2008 type 128-bit floating point. One sort of works and the other does not at all. A value for pi becomes 2.0713495408... etc. The gcc manual page for "IBM RS/6000 and PowerPC Options" needs a bit of a re-write to address the strange results one may get from the use of "-mabi" ieeelongdouble or ibmlongdouble. At the very least the "warning" exists to let a user know that something is amiss here and strange results may occur. Dennis Clarke
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #18 from Dennis Clarke --- We are saying the same thing here. Those same emulation routines exist elsewhere and are called _Qp_div, _Qp_mul and _Qp_add on Solaris SPARC systems whereas those are implemented into other places with more or less the same names. Let's not go in circles here. I see the issue and the old 970 is a historical artifact.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
--- Comment #19 from Dennis Clarke ---
status : RESOLVED FIXED <-- seems to not apply.
For the sake of showing how there really is a problem here, we can
neatly compile some trivial code and get bizarre results simply
because the platform would prefer to use the non-standard IBM long
double data type. Any attempt to "add" two long doubles will result
in a call to _q_add which doesn't exist and ld fails.
ppc64$ cat foo.c
#define _XOPEN_SOURCE 600
#include
#include
#include
#include
#include
int main ( int argc, char *argv[] ) {
int j;
struct utsname uname_data;
long double pi = 3.14159265358979323846264338327950288419716939937510L;
long double one = 1.0L;
long double two = 2.0L;
setlocale( LC_MESSAGES, "C" );
if ( uname( &uname_data ) < 0 ) {
fprintf ( stderr,
"WARNING : Could not attain system uname data.\n" );
perror ( "uname" );
} else {
printf ("system name = %s\n", uname_data.sysname );
printf (" node name = %s\n", uname_data.nodename );
printf ("release = %s\n", uname_data.release );
printf ("version = %s\n", uname_data.version );
printf ("machine = %s\n", uname_data.machine );
}
printf ("\n");
/* correct 128 bit big endian hex representation of pi is
* 0x40 00 92 1f b5 44 42 d1 84 69 89 8c c5 17 01 b8 */
printf("\naddr \"pi\" is %p\n", &pi );
printf("\ncontents : " );
for ( j=0; j -Wfatal-errors -pedantic-errors -mcpu=970 -mfull-toc \
> -mregnames -mabi=ieeelongdouble -o foo foo.c
gcc: warning: using IEEE extended precision long double
cc1: warning: using IEEE extended precision long double
ppc64$
ppc64$ ./foo
system name = Linux
node name = nix
release = 4.16.2-genunix
version = #1 SMP Wed Apr 18 16:41:48 GMT 2018
machine = ppc64
addr "pi" is 0x7fffe4399650
contents : 40 00 92 1f b5 44 42 d1 84 69 89 8c c5 17 01 b8
+2.07134954084936184770526779175270348787
+3.1415926535897932384626433832795028841971 <- pi
addr "one" is 0x7fffe4399660
contents : 3f ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+1.937500
addr "two" is 0x7fffe4399670
contents : 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+2.00
ppc64$
ppc64$
ppc64$ /usr/local/gcc7/bin/gcc -m64 -std=iso9899:2011 \
> -Wfatal-errors -pedantic-errors -mcpu=970 -mfull-toc \
> -mregnames -mabi=ibmlongdouble -o foo foo.c
gcc: warning: using IBM extended precision long double
cc1: warning: using IBM extended precision long double
ppc64$ ./foo
system name = Linux
node name = nix
release = 4.16.2-genunix
version = #1 SMP Wed Apr 18 16:41:48 GMT 2018
machine = ppc64
addr "pi" is 0x75eef3e0
contents : 40 09 21 fb 54 44 2d 18 3c a1 a6 26 33 14 5c 06
+3.14159265358979323846264338327948122706
+3.1415926535897932384626433832795028841971 <- pi
addr "one" is 0x75eef3f0
contents : 3f f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+1.00
addr "two" is 0x75eef400
contents : 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+2.00
ppc64$
Like you say "...it doesn't work at all unless you provide your own library."
So very true.
Well this has been fun and I think a POWER9 server is needed to do
any real work and certainly the hardware support will be fun.
[Bug bootstrap/82037] Debian 8.8 powerpc64-unknown-linux-gnu bootstrap breaks in stage1 with gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037 Dennis Clarke changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #11 from Dennis Clarke --- Given that I have both gcc 7.3.0 and gcc 8 rc bootstrapping fine I would say this is a closed non-issue.
[Bug other/15210] gcc-3.4.0.tar.gz fails to unpack on SunOS 5.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15210 Dennis Clarke changed: What|Removed |Added CC||dclarke at blastwave dot org --- Comment #4 from Dennis Clarke --- Off the shelf old /usr/bin/tar in Solaris 10 can not extract released gcc-8.1.0.tar files as it issues : tar: ././@LongLink: typeflag 'L' not recognized, converting to regular file Feels like an old 'non-bug' has awoken .. however gnu tar has no issues and neither does Jörg Schilling's POSIX tar. ( called star for standard tar ). Merely an update here ... nothing to see .. moving along.
[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686 --- Comment #10 from Dennis Clarke --- I had not yet tested a build of gcc previous to gcc 7.x regarding this issue. Seemed counter intuitive to revert backwards but now I have to agree that "something changed" again in the world of doing a bootstrap of gcc. This seems to be happening more and more and getting gcc to reasonably build is becoming more and more of a black art as opposed to a science. I will, for the sake of experimentation, go try a bootstrap of the gcc 6.4.0 and then if that works out move on to 7.3.0. I know that our friend Jonathan Wakely in comment 5 of this bug report. Also there is question if this is a bug at all. I tend to look at the existence of a bootstrap problem based on testing across multiple platforms and I can not run into this same problem on a sparc based Solaris 10 server wherein I do get multi-arch or at least multi-lib successful build results. There are no test results posted on the GCC site anymore : https://gcc.gnu.org/gcc-7/buildstat.html That seems to have died at least a year ago or more so it is very difficult to search the vast noise of the maillist using some format https://gcc.gnu.org/ml/gcc-testresults/-MM/ as a target string and then the platform and version. Simply said it is becoming more and more a black art. Jonathan says " This library needs to be available for each multilib variant" from the docs however this is not true at all on some platforms. Certainly sparc has no issues. I will try gcc 6.4.0 for the sake of a test and then move onwards. Dennis Clarke
[Bug c/55293] New: Attempt to bootstrap 7.7.2 on Solaris 10 Sparc fails with gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 Bug #: 55293 Summary: Attempt to bootstrap 7.7.2 on Solaris 10 Sparc fails with gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive] Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcla...@blastwave.org On a Solaris 10 server : $ uname -a SunOS node002 5.10 Generic_147440-23 sun4v sparc SUNW,T5240 With gcc 4.5.1 from Blastwave : $ which gcc /opt/csw/gcc4/bin/gcc $ gcc --version gcc (Blastwave.org Inc. Mon Aug 9 07:10:45 GMT 2010) 4.5.1 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See test report filed : http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg01023.html With gmp-5.0.5, mpfr-3.1.1, and mpc-1.0.1 all previously built, tested clean and installed into /usr/local. Configure of GCC 4.7.2 looks fine thus : $ pwd /usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou $ CC='gcc -m64' CXX='g++ -m64' ../gcc-4.7.2/configure --prefix=/usr/local/gcc4 \ > --build=sparc64-sun-solaris2.10 --without-gnu-as --without-gnu-ld \ > --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local \ > --with-ld=/usr/ccs/bin/ld --enable-nls --enable-threads=posix --enable-shared > \ > --libdir=/usr/local/gcc4/lib --with-local-prefix=/usr/local/gcc4 \ > --with-cpu=v9 --enable-stage1-languages=c --disable-multilib \ > --libexecdir=/usr/local/gcc4/lib \ > --with-pkgversion=Blastwave.org\ Inc.\ Mon\ Nov\ 12\ 04\:18\:15\ GMT\ 2012 \ > --with-bugurl=http\:\/\/www.blastwave.org\/support \ > --enable-languages=c,c++,objc,fortran,ada --enable-bootstrap checking build system type... sparc64-sun-solaris2.10 checking host system type... sparc64-sun-solaris2.10 checking target system type... sparc64-sun-solaris2.10 checking for a BSD-compatible install... ../gcc-4.7.2/install-sh -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /usr/local/bin/gsed checking for gawk... gawk checking for libitm support... yes checking for gcc... gcc -m64 checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -m64 accepts -g... yes checking for gcc -m64 option to accept ISO C89... none needed checking whether we are using the GNU C++ compiler... yes checking whether g++ -m64 accepts -g... yes checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16 checking for objdir... .libs checking for the correct version of gmp.h... yes checking for the correct version of mpfr.h... yes checking for the correct version of mpc.h... yes checking for the correct version of the gmp/mpfr/mpc libraries... yes checking for PWL_handle_timeout in -lpwl... no checking for version 0.11 (revision 0 or later) of PPL... no The following languages will be built: c,ada,c++,fortran,lto,objc *** This configuration is not supported in the following subdirectories: target-libmudflap target-libgo target-libffi target-zlib target-libjava target-boehm-gc (Any other directories should still work fine.) checking for default BUILD_CONFIG... checking for bison... bison -y checking for bison... bison checking for gm4... /usr/local/bin/gm4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for ar... (cached) /usr/ccs/bin/ar checking for as... (cached) /usr/ccs/bin/as checking for dlltool... no checking for ld... (cached) /usr/ccs/bin/ld checking for lipo... no checking for nm... nm checking for ranlib... ranlib checking for strip... strip checking for windres... no checking for windmc... no checking for objcopy... no checking for objdump... no checking for readelf... no checking for cc... cc checking for c++... c++ checking for gcc... gcc checking for gcj... no checking for gfortran... gfortran checking for gccgo... no checking for ar... no checking for ar... ar checking for as... no checking for as... as checking for dlltool... no checking for dlltool... no checking for ld... no checking for ld... ld checking for lipo... no checking for lipo
[Bug c/55293] Attempt to bootstrap GCC 4.7.2 on Solaris 10 Sparc fails with gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 --- Comment #3 from Dennis Clarke 2012-11-12 22:07:29 UTC --- OKay, I am extracting a fresh gcc 4.7.2 tarball and then running a new bootstrap with the defines suggested. Results should appear in seven hours or so, however I am hoping for results in 24 hours as that would be a full three stage bootstrap.
[Bug c/55293] Attempt to bootstrap GCC 4.7.2 on Solaris 10 Sparc fails with gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 --- Comment #4 from Dennis Clarke 2012-11-12 22:10:01 UTC --- bootstrap fails in 71 seconds : $ mkdir gcc-4.7.2_sparc64-sun-solaris2.10 $ cd gcc-4.7.2_sparc64-sun-solaris2.10 $ env | sort > ../gcc-4.7.2_sparc64-sun-solaris2.10.env $ ls -la total 20 drwxr-xr-x 2 dclarke other 2 Nov 12 21:58 . drwxrwxr-x 138 root adbs 247 Nov 12 21:58 .. $ $ pwd /usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10 $ uname -a SunOS node002 5.10 Generic_147440-23 sun4v sparc SUNW,T5240 $ $ env | sort AR=/usr/ccs/bin/ar AS=/usr/ccs/bin/as BUILD=/usr/local/build CC=/opt/csw/gcc4/bin/gcc COLUMNS=124 CONFIG_SHELL=/bin/bash CPPFLAGS=-I/usr/local/include:/opt/csw/gcc4/include CXX=/opt/csw/gcc4/bin/g++ EDITOR=/usr/xpg4/bin/vi HOME=/export/home/dclarke LANG=C LC_ALL=C LC_COLLATE=C LC_CTYPE=C LC_MESSAGES=C LC_MONETARY=C LC_NUMERIC=C LC_TIME=C LD=/usr/ccs/bin/ld LD_LIBRARY_PATH=/usr/local/lib:/opt/csw/gcc4/lib/sparcv9:/opt/csw/gcc4/lib LD_OPTIONS=-R/usr/local/lib:/opt/csw/gcc4/lib/$ISALIST:/opt/csw/gcc4/lib -L/usr/local/lib:/opt/csw/gcc4/lib/$ISALIST:/opt/csw/gcc4/lib LD_RUN_PATH=/usr/local/lib:/opt/csw/gcc4/lib/$ISALIST LINES=43 LOGNAME=dclarke M4=/usr/local/bin/gm4 MACHTYPE=sparc-sun-solaris MAIL=/usr/mail/dclarke MAKE=/usr/local/bin/gmake MANPATH=/usr/local/man:/usr/local/share/man:/usr/share/man:/usr/X11/share/man OSTYPE=solaris PAGER=/usr/xpg4/bin/more PATH=/opt/csw/gcc4/bin:/usr/local/bin:/usr/local/sbin:/usr/xpg6/bin:/usr/xpg4/bin:/usr/ccs/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/dt/bin:/usr/openwin/bin:/opt/schily/bin:/usr/local/texlive/2012/bin/sparc-solaris PERL=/usr/local/bin/perl PKG_CONFIG_PATH=/usr/local/lib/pkgconfig PWD=/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10 SED=/usr/local/bin/gsed SHELL=/bin/ksh SRC=/usr/local/src SSH_CLIENT=66.103.52.207 33595 22 SSH_CONNECTION=66.103.52.207 33595 66.225.151.250 22 SSH_TTY=/dev/pts/1 STY=4301.pts-1.node002 TERM=vt100 TZ=GMT0 USER=dclarke VISUAL=/usr/xpg4/bin/vi WINDOW=3 _=/usr/xpg4/bin/env $ $ which gcc /opt/csw/gcc4/bin/gcc $ $ gcc --version gcc (Blastwave.org Inc. Mon Aug 9 07:10:45 GMT 2010) 4.5.1 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ $ ls -lad ../gcc-4.7.2 drwxr-xr-x 33 dclarke other 75 Oct 29 04:04 ../gcc-4.7.2 $ $ which as /usr/ccs/bin/as $ which ld /usr/ccs/bin/ld $ $ echo $CFLAGS $ echo $CXXFLAGS $ $ CC='gcc -m64 -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO' \ > CXX='g++ -m64 -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -g -mno-app-regs > -mcpu=v9 -D_TS_ERRNO' \ > ../gcc-4.7.2/configure --prefix=/usr/local/gcc4 \ > --build=sparc64-sun-solaris2.10 --without-gnu-as --without-gnu-ld \ > --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local \ > --with-ld=/usr/ccs/bin/ld --enable-nls --enable-threads=posix --enable-shared > \ > --libdir=/usr/local/gcc4/lib --with-local-prefix=/usr/local/gcc4 \ > --with-cpu=v9 --enable-stage1-languages=c --disable-multilib \ > --libexecdir=/usr/local/gcc4/lib \ > --with-pkgversion=Blastwave.org\ Inc.\ Mon\ Nov\ 12\ 22\:02\:41\ GMT\ 2012 \ > --with-bugurl=http\:\/\/www.blastwave.org\/support \ > --enable-languages=c,c++,objc,fortran,ada --enable-bootstrap checking build system type... sparc64-sun-solaris2.10 checking host system type... sparc64-sun-solaris2.10 checking target system type... sparc64-sun-solaris2.10 checking for a BSD-compatible install... ../gcc-4.7.2/install-sh -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /usr/local/bin/gsed checking for gawk... gawk checking for libitm support... yes checking for gcc... gcc -m64 -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -m64 -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO accepts -g... yes checking for gcc -m64 -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO option to accept ISO C89... unsupported checking whether we are using the GNU C++ compiler... yes checking whether g++ -m64 -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO accepts -g... yes checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects...
[Bug c/55293] Attempt to bootstrap GCC 4.7.2 on Solaris 10 Sparc fails with gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 --- Comment #5 from Dennis Clarke 2012-11-12 22:44:19 UTC --- okay, exact same failure happens with -D_POSIX_C_SOURCE=200112L by itself. Am trying with _XOPEN_SOURCE=600 defined. Thus far ( well past 70 secs ) the stage 1 phase seems to be running. So I will report what I see in seven hours or more .. hopefully a lot lot more. dc
[Bug c/55293] Attempt to bootstrap GCC 4.7.2 on Solaris 10 Sparc fails with gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 --- Comment #6 from Dennis Clarke 2012-11-12 23:06:56 UTC --- the following fails also .. and it fails early : $ $ CC='gcc -m64 -g -D_XOPEN_SOURCE=600' CXX='g++ -m64 -g -D_XOPEN_SOURCE=600' \ > ../gcc-4.7.2/configure --prefix=/usr/local/gcc4 > --build=sparc64-sun-solaris2.10 --without-gnu-as \ > --without-gnu-ld --with-gmp=/usr/local --with-mpfr=/usr/local > --with-mpc=/usr/local --with-ld=/usr/ccs/bin/ld \ > --enable-nls --enable-threads=posix --enable-shared > --libdir=/usr/local/gcc4/lib --with-local-prefix=/usr/local/gcc4 \ > --with-cpu=v9 --enable-stage1-languages=c --disable-multilib > --libexecdir=/usr/local/gcc4/lib \ > --with-pkgversion=Blastwave.org\ Inc.\ Mon\ Nov\ 12\ 22\:56\:32\ GMT\ 2012 \ > --with-bugurl=http\:\/\/www.blastwave.org\/support > --enable-languages=c,c++,objc,fortran,ada --enable-bootstrap checking build system type... sparc64-sun-solaris2.10 checking host system type... sparc64-sun-solaris2.10 checking target system type... sparc64-sun-solaris2.10 checking for a BSD-compatible install... ../gcc-4.7.2/install-sh -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /usr/local/bin/gsed checking for gawk... gawk checking for libitm support... yes checking for gcc... gcc -m64 -g -D_XOPEN_SOURCE=600 checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -m64 -g -D_XOPEN_SOURCE=600 accepts -g... yes checking for gcc -m64 -g -D_XOPEN_SOURCE=600 option to accept ISO C89... unsupported checking whether we are using the GNU C++ compiler... yes checking whether g++ -m64 -g -D_XOPEN_SOURCE=600 accepts -g... yes checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16 checking for objdir... .libs checking for the correct version of gmp.h... yes checking for the correct version of mpfr.h... yes checking for the correct version of mpc.h... yes checking for the correct version of the gmp/mpfr/mpc libraries... yes checking for PWL_handle_timeout in -lpwl... no checking for version 0.11 (revision 0 or later) of PPL... no The following languages will be built: c,ada,c++,fortran,lto,objc *** This configuration is not supported in the following subdirectories: target-libmudflap target-libgo target-libffi target-zlib target-libjava target-boehm-gc (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug checking for bison... bison -y checking for bison... bison checking for gm4... /usr/local/bin/gm4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for ar... (cached) /usr/ccs/bin/ar checking for as... (cached) /usr/ccs/bin/as checking for dlltool... no checking for ld... (cached) /usr/ccs/bin/ld checking for lipo... no checking for nm... nm checking for ranlib... ranlib checking for strip... strip checking for windres... no checking for windmc... no checking for objcopy... no checking for objdump... no checking for readelf... no checking for cc... cc checking for c++... c++ checking for gcc... gcc checking for gcj... no checking for gfortran... gfortran checking for gccgo... no checking for ar... no checking for ar... ar checking for as... no checking for as... as checking for dlltool... no checking for dlltool... no checking for ld... no checking for ld... ld checking for lipo... no checking for lipo... no checking for nm... no checking for nm... nm checking for objdump... no checking for objdump... no checking for ranlib... no checking for ranlib... ranlib checking for readelf... no checking for readelf... no checking for strip... no checking for strip... strip checking for windres... no checking for windres... no checking for windmc... no checking for windmc... no checking where to find the target ar... host tool checking where to find the target as... host tool checking where to find the target cc... just compiled checking where to find the target c++... just compiled checking where to find the target c++ for libstdc++... just compiled checking where to find the target dlltool... host tool checking where to find the target gcc... just compiled checking where to find the target gcj... host tool checking where to find the target gfortran... just compiled checking where to find the target gccgo... host tool checking where to find the target ld... host tool checking where to find the target lipo... host tool checking wher
[Bug c/55293] bootstrap failure: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 Dennis Clarke changed: What|Removed |Added Component|bootstrap |c --- Comment #10 from Dennis Clarke 2012-11-13 06:01:17 UTC --- (In reply to comment #7) > The workaround is to add --disable-nls to the configure line. That being > said, > we should probably do something. Actually I just tried this : $ pwd /usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10 $ date -u Tue Nov 13 03:37:19 GMT 2012 $ CC='gcc -m64 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO' \ > CXX='g++ -m64 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO' \ > ../gcc-4.7.2/configure --prefix=/usr/local/gcc4 \ > --build=sparc64-sun-solaris2.10 --without-gnu-as --without-gnu-ld \ > --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local \ > --with-ld=/usr/ccs/bin/ld --disable-nls --enable-threads=posix > --enable-shared \ > --libdir=/usr/local/gcc4/lib --with-local-prefix=/usr/local/gcc4 \ > --with-cpu=v9 --enable-stage1-languages=c --disable-multilib \ > --libexecdir=/usr/local/gcc4/lib \ > --with-pkgversion=Blastwave.org\ Inc.\ Tues\ Nov\ 13\ 03\:37\:19\ GMT\ 2012 \ > --with-bugurl=http\:\/\/www.blastwave.org\/support \ > --enable-languages=c,c++,objc,fortran,ada --enable-bootstrap checking build system type... sparc64-sun-solaris2.10 checking host system type... sparc64-sun-solaris2.10 checking target system type... sparc64-sun-solaris2.10 checking for a BSD-compatible install... ../gcc-4.7.2/install-sh -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /usr/local/bin/gsed checking for gawk... gawk checking for libitm support... yes checking for gcc... gcc -m64 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -m64 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO accepts -g... yes checking for gcc -m64 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO option to accept ISO C89... none needed checking whether we are using the GNU C++ compiler... yes checking whether g++ -m64 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO accepts -g... yes checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16 checking for objdir... .libs checking for the correct version of gmp.h... yes checking for the correct version of mpfr.h... yes checking for the correct version of mpc.h... yes checking for the correct version of the gmp/mpfr/mpc libraries... yes checking for PWL_handle_timeout in -lpwl... no checking for version 0.11 (revision 0 or later) of PPL... no The following languages will be built: c,ada,c++,fortran,lto,objc *** This configuration is not supported in the following subdirectories: target-libmudflap target-libgo target-libffi target-zlib target-libjava target-boehm-gc (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug checking for bison... bison -y checking for bison... bison checking for gm4... /usr/local/bin/gm4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for ar... (cached) /usr/ccs/bin/ar checking for as... (cached) /usr/ccs/bin/as checking for dlltool... no checking for ld... (cached) /usr/ccs/bin/ld checking for lipo... no checking for nm... nm checking for ranlib... ranlib checking for strip... strip checking for windres... no checking for windmc... no checking for objcopy... no checking for objdump... no checking for readelf... no checking for cc... cc checking for c++... c++ checking for gcc... gcc checking for gcj... no checking for gfortran... gfortran checking for gccgo... no checking for ar... no checking for ar... ar checking for as... no checking for as... as checking for dlltool... no checking for dlltool... no checking for ld... no checking for ld... ld checking for lipo... no checking for lipo... no checking for nm... no checking for nm... nm checking for objdump... no checking for objdump... no checking for ranlib... no checking for ranlib... ranlib checking for readelf... no checking for readelf... no checking for strip... no checking for strip... strip checking for windres... no checking for windres... no checking for windmc... no checking for windmc... no checking where to find the target ar... host tool checking where to find the target as... host tool checking where to find the
[Bug c/55293] bootstrap failure: invalid conversion from 'char**' to 'const char**' [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 Dennis Clarke changed: What|Removed |Added Component|bootstrap |c --- Comment #12 from Dennis Clarke 2012-11-13 07:40:05 UTC --- (In reply to comment #11) > > Actually I just tried this : > > > > $ pwd > > /usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10 > > $ date -u > > Tue Nov 13 03:37:19 GMT 2012 > > > > $ CC='gcc -m64 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO' \ > > > CXX='g++ -m64 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO' \ > > > ../gcc-4.7.2/configure --prefix=/usr/local/gcc4 \ > > > --build=sparc64-sun-solaris2.10 --without-gnu-as --without-gnu-ld \ > > > --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local \ > > > --with-ld=/usr/ccs/bin/ld --disable-nls --enable-threads=posix > > > --enable-shared \ > > > --libdir=/usr/local/gcc4/lib --with-local-prefix=/usr/local/gcc4 \ > > > --with-cpu=v9 --enable-stage1-languages=c --disable-multilib \ > > > --libexecdir=/usr/local/gcc4/lib \ > > > --with-pkgversion=Blastwave.org\ Inc.\ Tues\ Nov\ 13\ 03\:37\:19\ GMT\ > > > 2012 \ > > > --with-bugurl=http\:\/\/www.blastwave.org\/support \ > > > --enable-languages=c,c++,objc,fortran,ada --enable-bootstrap > > Why on Earth are you *again* using all these flags? Remove all the flags you > added back to CC and CXX. Remove --with-cpu=v9 --enable-stage1-languages=c > and > -enable-bootstrap as well. > > > The end result of the long long experiment is that there is something wrong > > in > > gcc 4.7.2 that make it near impossible to bootstrap. > > > > OR > > > > There is something wrong with the headers in Oracle Solaris 10 that makes it > > impossible ( or near impossible ) to bootstrap GCC 4.7.2. > > Neither of course, people do it routinely and this works fine *if you follow > the documented procedures*. Just to annoy you? No. I have gcc 4.7.2 bootstrapping on a few Solaris 8 servers, flawlessly. At least thus far. Every attempt and incantation of attempts on Solaris 10, within or without the "documented" approach has failed. So, go easy on me. I have in fact, done this before. Just never on Solaris 10.
[Bug go/81926] New: go/parse.o differs between stage2 and stage3 for gcc 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 Bug ID: 81926 Summary: go/parse.o differs between stage2 and stage3 for gcc 7.2.0 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: dclarke at blastwave dot org CC: cmang at google dot com Target Milestone: --- configure ran thus : $ ../gcc-7.2.0/configure --build=sparc64-sun-solaris2.10 \ --target=sparc64-sun-solaris2.10 \ --host=sparc64-sun-solaris2.10 \ --prefix=/usr/local/gcc7 \ --without-gnu-as --without-gnu-ld \ --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/sparcv9/ld \ --disable-nls --enable-threads=posix --enable-shared \ --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local \ --with-isl=/usr/local \ --with-build-time-tools=/usr/local/bin --with-cpu=v9 \ --enable-bootstrap \ --enable-languages=ada,c,c++,fortran,go,objc,obj-c++ \ --with-pkgversion=genunix Tue Aug 22 00:36:56 GMT 2017 This resulted in : checking build system type... sparc64-sun-solaris2.10 checking host system type... sparc64-sun-solaris2.10 checking target system type... sparc64-sun-solaris2.10 checking for a BSD-compatible install... ../gcc-7.2.0/install-sh -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /usr/local/bin/sed checking for gawk... /usr/local/bin/gawk checking for libatomic support... yes checking for libcilkrts support... yes checking for libitm support... yes checking for libsanitizer support... no checking for libvtv support... no checking for libmpx support... no checking for libhsail-rt support... no checking for sparc64-sun-solaris2.10-gcc... sparc64-sun-solaris2.10-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether sparc64-sun-solaris2.10-gcc accepts -g... yes checking for sparc64-sun-solaris2.10-gcc option to accept ISO C89... none needed checking for sparc64-sun-solaris2.10-g++... sparc64-sun-solaris2.10-g++ checking whether we are using the GNU C++ compiler... yes checking whether sparc64-sun-solaris2.10-g++ accepts -g... yes checking whether g++ accepts -static-libstdc++ -static-libgcc... yes checking for sparc64-sun-solaris2.10-gnatbind... no checking for gnatbind... gnatbind checking for sparc64-sun-solaris2.10-gnatmake... no checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16 checking for objdir... .libs checking for the correct version of gmp.h... yes checking for the correct version of mpfr.h... yes checking for the correct version of mpc.h... yes checking for the correct version of the gmp/mpfr/mpc libraries... yes checking for isl 0.15 or later... yes The following languages will be built: c,ada,c++,fortran,go,lto,objc,obj-c++ *** This configuration is not supported in the following subdirectories: target-libsanitizer target-libvtv target-libmpx target-libhsail-rt target-liboffloadmic (Any other directories should still work fine.) checking for default BUILD_CONFIG... checking for --enable-vtable-verify... no checking for bison... bison -y checking for bison... bison checking for gm4... /usr/local/bin/m4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for ar... (cached) /usr/xpg4/bin/ar checking for sparc64-sun-solaris2.10-ar... (cached) /usr/xpg4/bin/ar checking for as... (cached) /usr/ccs/bin/as checking for sparc64-sun-solaris2.10-as... (cached) /usr/ccs/bin/as checking for sparc64-sun-solaris2.10-dlltool... no checking for dlltool... no checking for ld... (cached) /usr/ccs/bin/ld checking for sparc64-sun-solaris2.10-ld... (cached) /usr/ccs/bin/ld checking for sparc64-sun-solaris2.10-lipo... no checking for lipo... no checking for nm... (cached) /usr/ccs/bin/sparcv9/nm -p checking for sparc64-sun-solaris2.10-nm... (cached) /usr/ccs/bin/sparcv9/nm -p checking for ranlib... (cached) /usr/ccs/bin/ranlib checking for sparc64-sun-solaris2.10-ranlib... (cached) /usr/ccs/bin/ranlib checking for strip... (cached) /usr/ccs/bin/strip checking for sparc64-sun-solaris2.10-strip... (cached) /usr/ccs/bin/strip checking for sparc64-sun-solaris2.10-windres... no checking for windres... no checking for sparc64-sun-solaris2.10-windmc... no checking for windmc... no checking for sparc64-sun-solaris2.10-objcopy... no checking for objcopy... no checking for sparc64-sun-solaris2.10-objdump... no checking for objdump... no checking for sparc64-sun-solaris2.10-readelf... no
[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #2 from Dennis Clarke ---
the ELF section header table seems
to be in a slightly different place between the two files :
d$ elfdump -delv stage2-gcc/go/parse.o
ELF Header
ei_magic: { 0x7f, E, L, F }
ei_class: ELFCLASS64 ei_data: ELFDATA2MSB
ei_osabi: ELFOSABI_NONE ei_abiversion: 0
e_machine: EM_SPARCV9 e_version: EV_CURRENT
e_type: ET_REL
e_flags:[ EF_SPARCV9_TSO ]
e_entry: 0 e_ehsize: 64 e_shstrndx: 1
e_shoff: 0x3b7cd8 e_shentsize: 64 e_shnum: 86
e_phoff: 0 e_phentsize: 0 e_phnum: 0
d$ elfdump -delv stage3-gcc/go/parse.o
ELF Header
ei_magic: { 0x7f, E, L, F }
ei_class: ELFCLASS64 ei_data: ELFDATA2MSB
ei_osabi: ELFOSABI_NONE ei_abiversion: 0
e_machine: EM_SPARCV9 e_version: EV_CURRENT
e_type: ET_REL
e_flags:[ EF_SPARCV9_TSO ]
e_entry: 0 e_ehsize: 64 e_shstrndx: 1
e_shoff: 0x3b7cd0 e_shentsize: 64 e_shnum: 86
e_phoff: 0 e_phentsize: 0 e_phnum: 0
d$
So there I see 0x3b7cd8 in stage2 and 0x3b7cd0 in stage3.
At first glance there appears to be only an 8 byte difference in the
size of the file but looking down through the various sections in the
ELF data for both files I see the same data represented in very similar
places but yet, slightly different. For example the ELF header offset
is 0x3b7cd0 in one of them and 0x3b7cd8 in the other. Is this a valid
functional difference at all? Perhaps a bug lay inside the linker which
created the actual object file? Looking at both files and the ELF data
between them I see the exact same data in both and yet in different
addresses :
stage 2 :
Section Header[44]: sh_name: .bss
sh_addr: 0 sh_flags: [ SHF_WRITE SHF_ALLOC ]
sh_size: 0x11sh_type:[ SHT_NOBITS ]
sh_offset:0x204458sh_entsize: 0
sh_link: 0 sh_info:0
sh_addralign: 0x4
stage 3 :
Section Header[44]: sh_name: .bss
sh_addr: 0 sh_flags: [ SHF_WRITE SHF_ALLOC ]
sh_size: 0x11sh_type:[ SHT_NOBITS ]
sh_offset:0x204450sh_entsize: 0
sh_link: 0 sh_info:0
sh_addralign: 0x4
That sort of difference lay between the two files in many many places.
Slightly different by 8 bytes again however nm tells me that the symbol
listing is identical between the two files. Perhaps there is no actual
"functional" difference between the files at all.
[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #4 from Dennis Clarke --- elfdump in Solaris says stage2 section ".debug_info" size is 0x1636a2: Section Header[37]: sh_name: .debug_info sh_addr: 0 sh_flags: 0 sh_size: 0x1636a2sh_type:[ SHT_PROGBITS ] sh_offset:0x1faa0 sh_entsize: 0 sh_link: 0 sh_info:0 sh_addralign: 0x1 Whereas stage3 reports : Section Header[37]: sh_name: .debug_info sh_addr: 0 sh_flags: 0 sh_size: 0x163698sh_type:[ SHT_PROGBITS ] sh_offset:0x1faa0 sh_entsize: 0 sh_link: 0 sh_info:0 sh_addralign: 0x1 Not exactly 8 bytes. Looks like 10 bytes diff. All other "sh_size" section size data matches. The output from elfdump is 75k lines long with 1134 lines of diff : d$ elfdump ./stage3-gcc/go/parse.o > /tmp/go_parse_elfdump.3 d$ elfdump ./stage2-gcc/go/parse.o > /tmp/go_parse_elfdump.2 d$ wc -l /tmp/go_parse_elfdump.3 75428 /tmp/go_parse_elfdump.3 d$ wc -l /tmp/go_parse_elfdump.2 75428 /tmp/go_parse_elfdump.2 d$ diff /tmp/go_parse_elfdump.2 /tmp/go_parse_elfdump.3 | wc -l 1134
[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #5 from Dennis Clarke --- Minor note, the gcc 6.4.0 compiler I am using was not built with support for "go". I rarely ever build "go" as I have never had a use for it however I really should. It is possible some small bug has slipped under the radar because I just did a three stage bootstrap of 7.2.0 without "go" with success. Perhaps something subtle at work strictly in the "go" code area. I will run a testsuite and then get back to perhaps a build with stage1 languages as just C, C++ and then stage2 onwards as "all".
[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #8 from Dennis Clarke --- (In reply to Eric Botcazou from comment #7) > See PR bootstrap/77995 for a similar issue on x86-64/Solaris. Looks like a distant relation at best. That seemed to have something to do with complex types and build_complex_type() requiring a second "named" bool parameter. In the same ballpark perhaps but only as the ballboy selling hot dogs watching the game. My bootstrap of 7.2.0 did complete fine and the testsuite is running. I think I shall circle back to 6.4.0 and try a bootstrap with "go" as an enabled language after stage1 and see what happens. On sparc only. I could try this on Solaris x86_64 but I don't have any of that around and have not seen it in the wild for some years.
[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #9 from Dennis Clarke --- If I remove the "go" language from the mix then I get reasonable results : https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg02064.html I will install that and then try again with the "all" languages selection after stage1.
[Bug tree-optimization/81934] New: after install of 7.2.0 the libcilkrts.la has extra quote chars in it for dependency_libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81934 Bug ID: 81934 Summary: after install of 7.2.0 the libcilkrts.la has extra quote chars in it for dependency_libs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dclarke at blastwave dot org Target Milestone: --- After installation of gcc 7.2.0 there exists two libtool "dot-la" files both named libcilkrts.la but for 32-bit and 64-bit as this is sparc. Thus : /usr/local/gcc7/lib/libcilkrts.la and /usr/local/gcc7/lib/sparcv9/libcilkrts.la They both have extra single quote chars inside the dependency_libs value and had to be manually scrubbed out : # diff ./gcc7/lib/libcilkrts.la /usr/local/gcc7/lib/libcilkrts.la 20c20 < dependency_libs=' -lpthread /usr/local/gcc7/lib/libstdc++.la' --- > dependency_libs=' -lpthread '/usr/local/gcc7/lib'/libstdc++.la' # diff gcc7/lib/sparcv9/libcilkrts.la /usr/local/gcc7/lib/sparcv9/libcilkrts.la 20c20 < dependency_libs=' -lpthread /usr/local/gcc7/lib/sparcv9/libstdc++.la' --- > dependency_libs=' -lpthread '/usr/local/gcc7/lib/sparcv9'/libstdc++.la' Not sure how they ended up in there but all the other .la type files seem fine. Also, for this bug there is no clear component for "install" and I can not choose "no component" so I randomly took "tree-optimization". That will need to be fixed most likely.
[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #12 from Dennis Clarke ---
I don't mean to ask what may seem obvious but does it make sense to
add a not required "dummy .text" section? I mean to say, is there a
valid reason why gas would add in a blank ".text" where none is actually
required?
Also, as a follow up, I did actually get a full three stage bootstrap of
7.2.0 while using --enable-languages=ada,c,c++,fortran,go,lto,objc,obj-c++.
This surprised me however at this point I had already installed the
previous 7.2.0 build and also did specify --enable-stage1-languages=c,c++
to get a minimal stage1 compiler. The test results looked like :
https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg02494.html
I question those results because neither the bootstrap nor the testsuite
would complete without a strange error at the last moment. The bootstrap
will fail because of a complaint for "missing-objcopy" in stage 3 thus :
libtool: compile:
/usr/local/build/gcc-7.2.0_SunOS5.10_sparc64vii+.008/./gcc/gccgo
-B/usr/local/build/gcc-7.2.0_SunOS5.10_sparc64vii+.008/./gcc/
-B/usr/local/gcc7/sparc64-sun-solaris2.10/bin/
-B/usr/local/gcc7/sparc64-sun-solaris2.10/lib/ -isystem
/usr/local/gcc7/sparc64-sun-solaris2.10/include -isystem
/usr/local/gcc7/sparc64-sun-solaris2.10/sys-include -O2 -g -I . -c
-fgo-pkgpath=runtime/internal/atomic -fgo-compiling-runtime
../../../gcc-7.2.0/libgo/go/runtime/internal/atomic/gccgo.go
../../../gcc-7.2.0/libgo/go/runtime/internal/atomic/stubs.go -o
runtime/internal/atomic.o >/dev/null 2>&1
f=`echo runtime/internal/atomic.lo | sed -e 's/.lo$/.o/'`; missing-objcopy -j
.go_export $f runtime/internal/atomic.s-gox.tmp; /usr/local/bin/bash
../../../gcc-7.2.0/libgo/mvifdiff.sh runtime/internal/atomic.s-gox.tmp `echo
runtime/internal/atomic.s-gox | sed -e 's/s-gox/gox/'`
/usr/local/bin/bash: missing-objcopy: command not found
mv: cannot access runtime/internal/atomic.s-gox.tmp
gmake[4]: *** [Makefile:3331: runtime/internal/atomic.s-gox] Error 2
gmake[4]: Leaving directory
'/usr/local/build/gcc-7.2.0_SunOS5.10_sparc64vii+.008/sparc64-sun-solaris2.10/libgo'
gmake[3]: *** [Makefile:2746: all-recursive] Error 1
gmake[3]: Leaving directory
'/usr/local/build/gcc-7.2.0_SunOS5.10_sparc64vii+.008/sparc64-sun-solaris2.10/libgo'
gmake[2]: *** [Makefile:1344: all] Error 2
gmake[2]: Leaving directory
'/usr/local/build/gcc-7.2.0_SunOS5.10_sparc64vii+.008/sparc64-sun-solaris2.10/libgo'
gmake[1]: *** [Makefile:23963: all-target-libgo] Error 2
gmake[1]: Leaving directory
'/usr/local/build/gcc-7.2.0_SunOS5.10_sparc64vii+.008'
gmake: *** [Makefile:28139: bootstrap] Error 2
The testsuite fails with a strange error also :
=== libatomic Summary ===
# of expected passes54
gmake[4]: Leaving directory
'/usr/local/build/gcc-7.2.0_SunOS5.10_sparc64vii+.009/sparc64-sun-solaris2.10/libatomic/testsuite'
gmake[3]: Leaving directory
'/usr/local/build/gcc-7.2.0_SunOS5.10_sparc64vii+.009/sparc64-sun-solaris2.10/libatomic/testsuite'
gmake[3]: Entering directory
'/usr/local/build/gcc-7.2.0_SunOS5.10_sparc64vii+.009/sparc64-sun-solaris2.10/libatomic'
/usr/local/bin/gmake DO=all multi-do # /usr/local/bin/gmake
gmake[4]: Entering directory
'/usr/local/build/gcc-7.2.0_SunOS5.10_sparc64vii+.009/sparc64-sun-solaris2.10/libatomic'
if [ -z "sparcv8plus" ]; then \
true; \
else \
rootpre=`${PWDCMD-pwd}`/; export rootpre; \
srcrootpre=`cd ../../../gcc-7.2.0/libatomic; ${PWDCMD-pwd}`/; export
srcrootpre; \
lib=`echo "${rootpre}" | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \
compiler="/usr/local/build/gcc-7.2.0_SunOS5.10_sparc64vii+.009/./gcc/xgcc
-B/usr/local/build/gcc-7.2.0_SunOS5.10_sparc64vii+.009/./gcc/
-B/usr/local/gcc7/sparc64-sun-solaris2.10/bin/
-B/usr/local/gcc7/sparc64-sun-solaris2.10/lib/ -isystem
/usr/local/gcc7/sparc64-sun-solaris2.10/include -isystem
/usr/local/gcc7/sparc64-sun-solaris2.10/sys-include "; \
for i in `${compiler} --print-multi-lib 2>/dev/null`; do \
dir=`echo $i | sed -e 's/;.*$//'`; \
if [ "${dir}" = "." ]; then \
true; \
else \
if [ -d ../${dir}/${lib} ]; then \
flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
if (cd ../${dir}/${lib}; /usr/local/bin/gmake \
CFLAGS="-g -O2 ${flags}" \
CCASFLAGS="-g -O2 ${flags}" \
FCFLAGS=" ${flags}" \
FFLAGS=" ${flags}" \
ADAFLAGS=" ${flags}" \
prefix="/usr/local/gcc7" \
exec_prefix="/usr/local/gcc7" \
GOCFLAGS="-O2 -g ${flags}" \
CXXFLAGS="-g -O2 ${flags}" \
LIBCFLAGS="-g -O2 ${flags}" \
LIBCXXFLAGS="-g -O2 -fno-implicit-templates ${flags}" \
LDFLAGS=" ${flags}" \
MULTIFLAGS="${flags}" \
DESTDIR="" \
INSTALL
[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #16 from Dennis Clarke ---
This is excellent follow up and it looks like GNU binutils must be around
somewhere on the system for "Go" to build. Also, I always run "gmake -k check"
for the testsuite and not sure why it would look otherwise.
Here is the diff on 7.2.0 gcc/config/sparc/sparc.c based on your patch :
v9_7++ $ diff -c ./gcc/config/sparc/sparc.c_20170829115516
./gcc/config/sparc/sparc.c
*** ./gcc/config/sparc/sparc.c_20170829115516 Thu Jul 27 12:57:23 2017
--- ./gcc/config/sparc/sparc.c Tue Aug 29 11:59:32 2017
***
*** 652,657
--- 652,658
static int sparc_arg_partial_bytes (cumulative_args_t,
machine_mode, tree, bool);
static void sparc_output_dwarf_dtprel (FILE *, int, rtx) ATTRIBUTE_UNUSED;
+ static void sparc_file_start (void);
static void sparc_file_end (void);
static bool sparc_frame_pointer_required (void);
static bool sparc_can_eliminate (const int, const int);
***
*** 834,839
--- 835,843
#define TARGET_ASM_OUTPUT_DWARF_DTPREL sparc_output_dwarf_dtprel
#endif
+ #undef TARGET_ASM_FILE_START
+ #define TARGET_ASM_FILE_START sparc_file_start
+
#undef TARGET_ASM_FILE_END
#define TARGET_ASM_FILE_END sparc_file_end
***
*** 12121,12126
--- 12125,12144
fputs (")", file);
}
+ /* Do whatever processing is required at the start of a file. */
+
+ static void
+ sparc_file_start (void)
+ {
+ default_file_start ();
+
+ #ifdef TARGET_SOLARIS
+ /* The Solaris/SPARC assembler doesn't always emit a .text section,
+ leading to comparison failures. */
+ switch_to_section (text_section);
+ #endif
+ }
+
/* Do whatever processing is required at the end of a file. */
static void
v9_7++ $
I do have GNU objcopy laying about also :
v9_7++ $ /usr/local/bin/gobjcopy --version
GNU objcopy (GNU Binutils) 2.23.1
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
v9_7++ $
v9_7++ $ ../gcc-7.2.0/configure \
> --build=sparc64-sun-solaris2.10 \
> --target=sparc64-sun-solaris2.10 \
> --host=sparc64-sun-solaris2.10 \
> --prefix=/usr/local/gcc7 \
> --without-gnu-as --without-gnu-ld \
> --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/sparcv9/ld \
> --disable-nls --enable-threads=posix --enable-shared \
> --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local \
> --with-isl=/usr/local --with-build-time-tools=/usr/local/bin \
> --with-cpu=v9 --enable-bootstrap \
> --enable-stage1-languages=c,c++ --enable-stage1-checking=misc \
> --enable-languages=ada,c,c++,fortran,go,lto,objc,obj-c++ \
> --with-pkgversion="genunix Tue Aug 29 11:48:17 GMT 2017"
checking build system type... sparc64-sun-solaris2.10
checking host system type... sparc64-sun-solaris2.10
checking target system type... sparc64-sun-solaris2.10
checking for a BSD-compatible install... ../gcc-7.2.0/install-sh -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /usr/local/bin/sed
checking for gawk... /usr/local/bin/gawk
checking for libatomic support... yes
checking for libcilkrts support... yes
checking for libitm support... yes
checking for libsanitizer support... no
checking for libvtv support... no
checking for libmpx support... no
checking for libhsail-rt support... no
checking for sparc64-sun-solaris2.10-gcc... sparc64-sun-solaris2.10-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether sparc64-sun-solaris2.10-gcc accepts -g... yes
checking for sparc64-sun-solaris2.10-gcc option to accept ISO C89... none
needed
checking for sparc64-sun-solaris2.10-g++... sparc64-sun-solaris2.10-g++
checking whether we are using the GNU C++ compiler... yes
checking whether sparc64-sun-solaris2.10-g++ accepts -g... yes
checking whether g++ accepts -static-libstdc++ -static-libgcc... yes
checking for sparc64-sun-solaris2.10-gnatbind... no
checking for gnatbind... gnatbind
checking for sparc64-sun-solaris2.10-gnatmake... no
checking for gnatmake... gnatmake
checking whether compiler driver understands Ada... yes
checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16
checking for objdir... .libs
checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... yes
checking for the correct version of mpc.h... yes
checking for the correct version of the gmp/mpfr/mpc libraries... yes
checking for isl 0.15 or later... yes
The following languages will be built: c,ada,c++,fortran,go,lto,objc,obj-c++
*** This co
[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #19 from Dennis Clarke --- Regarding "BUILD_CONFIG" I have about ten log files and they all say : checking for default BUILD_CONFIG... I have never set that var to anything.
[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #20 from Dennis Clarke --- (In reply to r...@cebitec.uni-bielefeld.de from comment #17) > > --- Comment #16 from Dennis Clarke --- > > This is excellent follow up ... > > Here is the diff on 7.2.0 gcc/config/sparc/sparc.c based on your patch : > > Thanks. Before trying a backport, we probably should go for the > different solution Richard suggested, though. Please see my question below. > > > I do have GNU objcopy laying about also : > > > > v9_7++ $ /usr/local/bin/gobjcopy --version > > GNU objcopy (GNU Binutils) 2.23.1 > > Copyright 2012 Free Software Foundation, Inc. > > This program is free software; you may redistribute it under the terms of > > the GNU General Public License version 3 or (at your option) any later > > version. > > This program has absolutely no warranty. > > This won't help right now: libgo's configure will only look for objcopy > (or sparc64-sun-solaris2.10-objcopy in your case) and doesn't know about > gobjcopy. > yikes ... however see info below. > AFAICS toplevel configure checks for the g-prefixed tools and passes the > result to gcc/configure which heeds them, while libgo/configure does > not. > > Probably an issue for a separate libgo bug report. > > Rainer Just a bit of info and a question. info : I have set the env var OBJCOPY=/usr/local/bin/gobjcopy and also set env var OBJDUMP=/usr/local/bin/gobjdump where both those tools exist and are from binutils 2.23.1 ques : Richard Bierner had said earlier "I'd rather do that where the assemby_start debug hook is called instead..." however I already applied Rainer's patch to gcc/config/sparc/sparc.c and am running a stage3 bootstrap now. Should that change have been done elsewhere other than in a sparc specific target related source?
[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #21 from Dennis Clarke --- update : after 11.7 hours the bootstrap completes with no errors. running gmake -k check now.
[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #22 from Dennis Clarke --- I think Rainer's patch as well as the addition of the env vars that point to "gobjcopy" and "gobjdump" have sorted this out. I get a clean three stage bootstrap now on an sparc-sun-solaris2.10 arch which is an Oracle SPARC M4000 server. I don't think the SPARC64-VII+ type processors will make a difference as all the output ELF files are clearly portable to the EF_SPARCV9_TSO per the ELF header e_flags. I can try again on a few other sparc servers to verify but at the moment this looks resolved with the added dummy .text section for an empty input file to the platform assembler as. However the testsuite still fails. For now at least. Dennis Clarke
[Bug bootstrap/82037] New: powerpc64-unknown-linux-gnu bootstrap breaks in stage2 with gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037 Bug ID: 82037 Summary: powerpc64-unknown-linux-gnu bootstrap breaks in stage2 with gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64 Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dclarke at blastwave dot org Target Milestone: --- Debian 8.8 on powerpc64-unknown-linux-gnu thus : ppc64$ ../gcc-7.2.0/config.guess powerpc64-unknown-linux-gnu ppc64$ ppc64$ uname -a Linux charon 3.16.0-4-powerpc64 #1 SMP Debian 3.16.43-2 (2017-04-30) ppc64 GNU/Linux ppc64$ configure looked good : ppc64$ ../gcc-7.2.0/configure --build=powerpc64-unknown-linux-gnu \ > --target=powerpc64-unknown-linux-gnu --host=powerpc64-unknown-linux-gnu \ > --enable-targets=powerpc-linux,powerpc64-linux --prefix=/usr/local/gcc7 \ > --disable-nls --enable-threads=posix --enable-shared \ > --with-cpu=970 --enable-bootstrap \ > --enable-libstdcxx-debug --enable-libstdcxx-time=yes \ > --enable-__cxa_atexit --with-system-zlib --enable-objc-gc \ > --enable-multiarch --with-long-double-128 --enable-multilib \ > --enable-stage1-languages=c,c++ --enable-stage1-checking=misc \ > --enable-languages=ada,c,c++,fortran,go,lto,objc,obj-c++ \ > --with-pkgversion='genunix Wed Aug 30 02:32:29 UTC 2017' checking build system type... powerpc64-unknown-linux-gnu checking host system type... powerpc64-unknown-linux-gnu checking target system type... powerpc64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /bin/sed checking for gawk... no checking for mawk... mawk checking for libatomic support... yes checking for libcilkrts support... no checking for libitm support... yes checking for libsanitizer support... yes checking for libvtv support... no checking for libmpx support... no checking for libhsail-rt support... no checking for powerpc64-unknown-linux-gnu-gcc... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for powerpc64-unknown-linux-gnu-g++... no checking for powerpc64-unknown-linux-gnu-c++... no checking for powerpc64-unknown-linux-gnu-gpp... no checking for powerpc64-unknown-linux-gnu-aCC... no checking for powerpc64-unknown-linux-gnu-CC... no checking for powerpc64-unknown-linux-gnu-cxx... no checking for powerpc64-unknown-linux-gnu-cc++... no checking for powerpc64-unknown-linux-gnu-cl.exe... no checking for powerpc64-unknown-linux-gnu-FCC... no checking for powerpc64-unknown-linux-gnu-KCC... no checking for powerpc64-unknown-linux-gnu-RCC... no checking for powerpc64-unknown-linux-gnu-xlC_r... no checking for powerpc64-unknown-linux-gnu-xlC... no checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking whether g++ accepts -static-libstdc++ -static-libgcc... yes checking for powerpc64-unknown-linux-gnu-gnatbind... no checking for gnatbind... gnatbind checking for powerpc64-unknown-linux-gnu-gnatmake... no checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for objdir... .libs configure: WARNING: using in-tree isl, disabling version check The following languages will be built: c,ada,c++,fortran,go,lto,objc,obj-c++ checking for bdw garbage collector... using bdw-gc in default locations *** This configuration is not supported in the following subdirectories: zlib target-libcilkrts target-libvtv target-libmpx target-libhsail-rt target-liboffloadmic (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug checking for --enable-vtable-verify... no checking for bison... bison -y checking for bison... bison checking for gm4... no checking for gnum4... no checking for m4... m4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for powerpc64-unknown-linux-gnu-ar... no checking for ar... ar checking for powerpc64-unknown-linux-gnu-as... no checking for as... as checking for powerpc64-unknown-linux-gnu-dlltool... no checking for dlltool... no checking for powerpc64-unknown-linux-gnu-ld... no checking for ld... ld checking for powerpc64-unknown-linux-gnu-lipo... no checki
[Bug bootstrap/82037] powerpc64-unknown-linux-gnu bootstrap breaks in stage2 with gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037 --- Comment #2 from Dennis Clarke --- Seems to be a 32-bit PowerPC ELF : ppc64$ ls -lap /usr/bin/ld lrwxrwxrwx 1 root root 6 Jan 12 2017 /usr/bin/ld -> ld.bfd ppc64$ ls -lap /usr/bin/ld.bfd -rwxr-xr-x 1 root root 700284 Jan 12 2017 /usr/bin/ld.bfd ppc64$ file /usr/bin/ld.bfd /usr/bin/ld.bfd: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 2.6.32, BuildID[sha1]=bf837c229beabc8073b38307339991ed9a58418a, stripped Not sure how that helps.
[Bug bootstrap/82037] powerpc64-unknown-linux-gnu bootstrap breaks in stage2 with gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037 --- Comment #4 from Dennis Clarke --- What if the objective was to have a final 64-bit gcc binary the same as I have on sparc : d # ls -lap /usr/local/gcc7/bin/gcc -rwxr-xr-x 3 root root 6275104 Aug 30 18:40 /usr/local/gcc7/bin/gcc d# file /usr/local/gcc7/bin/gcc /usr/local/gcc7/bin/gcc: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped
[Bug bootstrap/82037] powerpc64-unknown-linux-gnu bootstrap breaks in stage2 with gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037 --- Comment #5 from Dennis Clarke --- ppc64$ pwd /usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003 ppc64$ date Fri Sep 1 03:01:16 GMT 2017 ppc64$ ../gcc-7.2.0/configure --build=powerpc64-unknown-linux-gnu \ > --target=powerpc64-unknown-linux-gnu --host=powerpc64-unknown-linux-gnu \ > --enable-targets=powerpc-linux,powerpc64-linux --prefix=/usr/local/gcc7 \ > --disable-nls --enable-threads=posix --enable-shared \ > --with-cpu=default32 --enable-bootstrap \ > --enable-libstdcxx-debug --enable-libstdcxx-time=yes \ > --enable-__cxa_atexit --with-system-zlib --enable-objc-gc \ > --enable-multiarch --with-long-double-128 --enable-multilib \ > --enable-stage1-languages=c,c++ --enable-stage1-checking=misc \ > --enable-languages=ada,c,c++,fortran,go,lto,objc,obj-c++ \ > --with-pkgversion='genunix Fri Sep 1 03:01:16 GMT 2017' checking build system type... powerpc64-unknown-linux-gnu checking host system type... powerpc64-unknown-linux-gnu checking target system type... powerpc64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /bin/sed checking for gawk... no checking for mawk... mawk checking for libatomic support... yes checking for libcilkrts support... no checking for libitm support... yes checking for libsanitizer support... yes checking for libvtv support... no checking for libmpx support... no checking for libhsail-rt support... no checking for powerpc64-unknown-linux-gnu-gcc... gcc -m64 checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -m64 accepts -g... yes checking for gcc -m64 option to accept ISO C89... none needed checking whether we are using the GNU C++ compiler... yes checking whether g++ -m64 accepts -g... yes checking whether g++ accepts -static-libstdc++ -static-libgcc... yes checking for powerpc64-unknown-linux-gnu-gnatbind... no checking for gnatbind... gnatbind checking for powerpc64-unknown-linux-gnu-gnatmake... no checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for objdir... .libs configure: WARNING: using in-tree isl, disabling version check The following languages will be built: c,ada,c++,fortran,go,lto,objc,obj-c++ checking for bdw garbage collector... using bdw-gc in default locations *** This configuration is not supported in the following subdirectories: zlib target-libcilkrts target-libvtv target-libmpx target-libhsail-rt target-liboffloadmic (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug checking for --enable-vtable-verify... no checking for bison... bison -y checking for bison... bison checking for gm4... no checking for gnum4... no checking for m4... m4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for powerpc64-unknown-linux-gnu-ar... no checking for ar... ar checking for powerpc64-unknown-linux-gnu-as... no checking for as... as checking for powerpc64-unknown-linux-gnu-dlltool... no checking for dlltool... no checking for powerpc64-unknown-linux-gnu-ld... no checking for ld... ld checking for powerpc64-unknown-linux-gnu-lipo... no checking for lipo... no checking for powerpc64-unknown-linux-gnu-nm... no checking for nm... nm checking for powerpc64-unknown-linux-gnu-ranlib... no checking for ranlib... ranlib checking for powerpc64-unknown-linux-gnu-strip... no checking for strip... strip checking for powerpc64-unknown-linux-gnu-windres... no checking for windres... no checking for powerpc64-unknown-linux-gnu-windmc... no checking for windmc... no checking for powerpc64-unknown-linux-gnu-objcopy... no checking for objcopy... objcopy checking for powerpc64-unknown-linux-gnu-objdump... no checking for objdump... objdump checking for powerpc64-unknown-linux-gnu-readelf... no checking for readelf... readelf checking for powerpc64-unknown-linux-gnu-cc... no checking for cc... cc checking for powerpc64-unknown-linux-gnu-c++... no checking for c++... c++ checking for powerpc64-unknown-linux-gnu-gcc... no checking for gcc... gcc checking for powerpc64-unknown-linux-gnu-gfortran... no checking for gfortran... gfortran checking for powerpc64-unknown-linux-gnu-gccgo... no checking for gccgo... no checking for ar... no checking for powerpc64-unknown-linux-gnu-ar... no checking for ar... ar checking for as... no checking for powerpc64-unknown-linux-gnu-as... no checking for as... as checking for dlltool... no checking for powerpc64
[Bug bootstrap/82037] powerpc64-unknown-linux-gnu bootstrap breaks in stage2 with gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037 --- Comment #6 from Dennis Clarke --- Well that change fails in stage 1 : /usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003/./gcc/xgcc -B/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003/./gcc/ -B/usr/local/gcc7/powerpc64-unknown-linux-gnu/bin/ -B/usr/local/gcc7/powerpc64-unknown-linux-gnu/lib/ -isystem /usr/local/gcc7/powerpc64-unknown-linux-gnu/include -isystem /usr/local/gcc7/powerpc64-unknown-linux-gnu/sys-include-O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o 64/libgcc_s.so.1.tmp -g -O2 -m64 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o ibm-ldouble_s.o tramp_s.o ppc64-fp_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f 64/libgcc_s.so && if [ -f 64/libgcc_s.so.1 ]; then mv -f 64/libgcc_s.so.1 64/libgcc_s.so.1.backup; else true; fi && mv 64/libgcc_s.so.1.tmp 64/libgcc_s.so.1 && (echo "/* GNU ld script"; echo " Use the shared library, but some functions are only in"; echo " the static library. */"; echo "GROUP ( libgcc_s.so.1 -lgcc )" ) > 64/libgcc_s.so /usr/bin/ld: /usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003/./gcc/liblto_plugin.so: error loading plugin: /usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003/./gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64 collect2: error: ld returned 1 exit status gmake[5]: *** [libgcc_s.so] Error 1 gmake[5]: Leaving directory `/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003/powerpc64-unknown-linux-gnu/64/libgcc' gmake[4]: *** [multi-do] Error 1 gmake[4]: Leaving directory `/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003/powerpc64-unknown-linux-gnu/libgcc' gmake[3]: *** [all-multi] Error 2 gmake[3]: Leaving directory `/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003/powerpc64-unknown-linux-gnu/libgcc' gmake[2]: *** [all-stage1-target-libgcc] Error 2 gmake[2]: Leaving directory `/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003' gmake: *** [bootstrap] Error 2 Command exited with non-zero status 2
[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #25 from Dennis Clarke --- So this seems to be related to some env var BUILD_CONFIG ? Ehere is this "BUILD_CONFIG" documented?
[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #27 from Dennis Clarke --- Okay .. thank you. So that should not be needed for a release version bootstrap.
[Bug bootstrap/81926] [7 regression] go/parse.o differs between stage2 and stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #30 from Dennis Clarke --- If that is on gcc master I have to backport to 7.2.0 and then give it a try.
[Bug bootstrap/82037] powerpc64-unknown-linux-gnu bootstrap breaks in stage2 with gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037 --- Comment #7 from Dennis Clarke --- At this point I don't see what the real issue is here on powerpc64. The configuration stage runs fine but everything fails in stage1 because the wrong ELF class is being used. Really the entire compiler should be a 64-bit tool but have the ability to compile code with the option -m32 also. This is a Debian 8.8 system and I see no reason why this should fail over and over. deb8_ppc64$ date Tue Oct 3 23:28:41 GMT 2017 deb8_ppc64$ CC='gcc -m64' CXX='g++ -m64' \ > LD_RUN_PATH='/usr/local/lib:/usr/local/gcc7/lib' \ > ../gcc-7.2.0/configure --build=powerpc64-unknown-linux-gnu \ > --target=powerpc64-unknown-linux-gnu --host=powerpc64-unknown-linux-gnu \ > --enable-targets=powerpc-linux,powerpc64-linux --prefix=/usr/local/gcc7 \ > --disable-nls --enable-threads=posix --enable-shared \ > --with-cpu=default64 --enable-bootstrap \ > --enable-libstdcxx-debug --enable-libstdcxx-time=yes \ > --enable-__cxa_atexit --with-system-zlib --enable-objc-gc \ > --enable-multiarch --with-long-double-128 --enable-multilib \ > --enable-stage1-languages=c,c++ --enable-stage1-checking=misc \ > --enable-languages=ada,c,c++,fortran,go,lto,objc,obj-c++ \ > --with-pkgversion='genunix Tue Oct 3 23:28:41 GMT 2017' This config looks fine and fails in stage1 : . . . /usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.004/./gcc/xgcc -B/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.004/./gcc/ -B/usr/local/gcc7/powerpc64-unknown-linux-gnu/bin/ -B/usr/local/gcc7/powerpc64-unknown-linux-gnu/lib/ -isystem /usr/local/gcc7/powerpc64-unknown-linux-gnu/include -isystem /usr/local/gcc7/powerpc64-unknown-linux-gnu/sys-include-O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o 32/libgcc_s.so.1.tmp -g -O2 -m32 -B./ addsf3_s.o subsf3_s.o negsf2_s.o mulsf3_s.o divsf3_s.o eqsf2_s.o nesf2_s.o gesf2_s.o gtsf2_s.o lesf2_s.o ltsf2_s.o unordsf2_s.o fixsfsi_s.o floatsisf_s.o floatunsisf_s.o adddf3_s.o subdf3_s.o negdf2_s.o muldf3_s.o divdf3_s.o eqdf2_s.o nedf2_s.o gedf2_s.o gtdf2_s.o ledf2_s.o ltdf2_s.o unorddf2_s.o fixdfsi_s.o floatsidf_s.o floatunsidf_s.o extendsfdf2_s.o truncdfsf2_s.o _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o ibm-ldouble_s.o tramp_s.o ppc64-fp_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f 32/libgcc_s.so && if [ -f 32/libgcc_s.so.1 ]; then mv -f 32/libgcc_s.so.1 32/libgcc_s.so.1.backup; else true; fi && mv 32/libgcc_s.so.1.tmp 32/libgcc_s.so.1 && (echo "/* GNU ld script"; echo " Use the shared library, but some functions are only in"; echo " the static library. */"; echo "GROUP ( libgcc_s.so.1 -lgcc )" ) > 32/libgcc_s.so /usr/bin/ld: /usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.004/./gcc/liblto_plugin.so: error loading plugin: /usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.004/./gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64 collect2: error: ld returned 1 exit status gmake[5]: *** [Makefile:982: libgcc_s.so] Error 1 gmake[5]: Leaving directory '/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.004/powerpc64-unknown-linux-gnu/32/libgcc' gmake[4]: *** [Makefile:1198: multi-do] Error 1 gmake[4]: Leaving directory '/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.004/powerpc64-unknown-linux-gnu/libgcc' gmake[3]: *** [Makefile:125: all-multi] Error 2 gmake[3]: *** Waiting for unfinished jobs gmake[3]: Leaving directory '/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.004/powerpc64-unknown-linux-gnu/libgcc' gmake[2]: *** [Makefile:20768: all-stage1-target-libgcc] Error 2 gmake[2]: Leaving directory '/usr/local/build/gcc-7.2.0_linux_3.16.
[Bug bootstrap/82037] Debian 8.8 powerpc64-unknown-linux-gnu bootstrap breaks in stage1 with gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82037 --- Comment #9 from Dennis Clarke --- OKay, this is a surprise to me but I will take it as a given in the linux world that a 32-bit linker binary is not able to perform linkage with objects that are in a different ELF class. My experiences in the SPARC world of Solaris don't help me here ( no surprise ) so I will get the binutils sources and fall down that rabbit hole a while and then return here with 64-bit binutils in hand. So let's keep this bug open for now.
[Bug bootstrap/82686] New: Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686 Bug ID: 82686 Summary: Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dclarke at blastwave dot org Target Milestone: --- Late in stage 3 of a perfect looking bootstrap I see : [after many hours] libtool: link: /usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.002/./gcc/xgcc -B/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.002/./gcc/ -B/usr/local/gcc7/powerpc64-unknown-linux-gnu/bin/ -B/usr/local/gcc7/powerpc64-unknown-linux-gnu/lib/ -isystem /usr/local/gcc7/powerpc64-unknown-linux-gnu/include -isystem /usr/local/gcc7/powerpc64-unknown-linux-gnu/sys-include -m32 -shared -fPIC -DPIC .libs/bounds.o .libs/compile_options.o .libs/memory.o .libs/string.o .libs/select.o .libs/backtrace.o .libs/convert_char.o .libs/environ.o .libs/error.o .libs/fpu.o .libs/main.o .libs/pause.o .libs/stop.o .libs/all_l1.o .libs/all_l2.o .libs/all_l4.o .libs/all_l8.o .libs/all_l16.o .libs/any_l1.o .libs/any_l2.o .libs/any_l4.o .libs/any_l8.o .libs/any_l16.o .libs/count_1_l.o .libs/count_2_l.o .libs/count_4_l.o .libs/count_8_l.o .libs/count_16_l.o .libs/maxloc0_4_i1.o .libs/maxloc0_8_i1.o .libs/maxloc0_16_i1.o .libs/maxloc0_4_i2.o .libs/maxloc0_8_i2.o .libs/maxloc0_16_i2.o .libs/maxloc0_4_i4.o .libs/maxloc0_8_i4.o .libs/maxloc0_16_i4.o .libs/maxloc0_4_i8.o .libs/maxloc0_8_i8.o .libs/maxloc0_16_i8.o .libs/maxloc0_4_i16.o .libs/maxloc0_8_i16.o .libs/maxloc0_16_i16.o .libs/maxloc0_4_r4.o .libs/maxloc0_8_r4.o .libs/maxloc0_16_r4.o .libs/maxloc0_4_r8.o .libs/maxloc0_8_r8.o .libs/maxloc0_16_r8.o .libs/maxloc0_4_r10.o .libs/maxloc0_8_r10.o .libs/maxloc0_16_r10.o .libs/maxloc0_4_r16.o .libs/maxloc0_8_r16.o .libs/maxloc0_16_r16.o .libs/maxloc1_4_i1.o .libs/maxloc1_8_i1.o .libs/maxloc1_16_i1.o .libs/maxloc1_4_i2.o .libs/maxloc1_8_i2.o .libs/maxloc1_16_i2.o .libs/maxloc1_4_i4.o .libs/maxloc1_8_i4.o .libs/maxloc1_16_i4.o .libs/maxloc1_4_i8.o .libs/maxloc1_8_i8.o .libs/maxloc1_16_i8.o .libs/maxloc1_4_i16.o .libs/maxloc1_8_i16.o .libs/maxloc1_16_i16.o .libs/maxloc1_4_r4.o .libs/maxloc1_8_r4.o .libs/maxloc1_16_r4.o .libs/maxloc1_4_r8.o .libs/maxloc1_8_r8.o .libs/maxloc1_16_r8.o .libs/maxloc1_4_r10.o .libs/maxloc1_8_r10.o .libs/maxloc1_16_r10.o .libs/maxloc1_4_r16.o .libs/maxloc1_8_r16.o .libs/maxloc1_16_r16.o .libs/maxval_i1.o .libs/maxval_i2.o .libs/maxval_i4.o .libs/maxval_i8.o .libs/maxval_i16.o .libs/maxval_r4.o .libs/maxval_r8.o .libs/maxval_r10.o .libs/maxval_r16.o .libs/minloc0_4_i1.o .libs/minloc0_8_i1.o .libs/minloc0_16_i1.o .libs/minloc0_4_i2.o .libs/minloc0_8_i2.o .libs/minloc0_16_i2.o .libs/minloc0_4_i4.o .libs/minloc0_8_i4.o .libs/minloc0_16_i4.o .libs/minloc0_4_i8.o .libs/minloc0_8_i8.o .libs/minloc0_16_i8.o .libs/minloc0_4_i16.o .libs/minloc0_8_i16.o .libs/minloc0_16_i16.o .libs/minloc0_4_r4.o .libs/minloc0_8_r4.o .libs/minloc0_16_r4.o .libs/minloc0_4_r8.o .libs/minloc0_8_r8.o .libs/minloc0_16_r8.o .libs/minloc0_4_r10.o .libs/minloc0_8_r10.o .libs/minloc0_16_r10.o .libs/minloc0_4_r16.o .libs/minloc0_8_r16.o .libs/minloc0_16_r16.o .libs/minloc1_4_i1.o .libs/minloc1_8_i1.o .libs/minloc1_16_i1.o .libs/minloc1_4_i2.o .libs/minloc1_8_i2.o .libs/minloc1_16_i2.o .libs/minloc1_4_i4.o .libs/minloc1_8_i4.o .libs/minloc1_16_i4.o .libs/minloc1_4_i8.o .libs/minloc1_8_i8.o .libs/minloc1_16_i8.o .libs/minloc1_4_i16.o .libs/minloc1_8_i16.o .libs/minloc1_16_i16.o .libs/minloc1_4_r4.o .libs/minloc1_8_r4.o .libs/minloc1_16_r4.o .libs/minloc1_4_r8.o .libs/minloc1_8_r8.o .libs/minloc1_16_r8.o .libs/minloc1_4_r10.o .libs/minloc1_8_r10.o .libs/minloc1_16_r10.o .libs/minloc1_4_r16.o .libs/minloc1_8_r16.o .libs/minloc1_16_r16.o .libs/minval_i1.o .libs/minval_i2.o .libs/minval_i4.o .libs/minval_i8.o .libs/minval_i16.o .libs/minval_r4.o .libs/minval_r8.o .libs/minval_r10.o .libs/minval_r16.o .libs/product_i1.o .libs/product_i2.o .libs/product_i4.o .libs/product_i8.o .libs/product_i16.o .libs/product_r4.o .libs/product_r8.o .libs/product_r10.o .libs/product_r16.o .libs/product_c4.o .libs/product_c8.o .libs/product_c10.o .libs/product_c16.o .libs/sum_i1.o .libs/sum_i2.o .libs/sum_i4.o .libs/sum_i8.o .libs/sum_i16.o .libs/sum_r4.o .libs/sum_r8.o .libs/sum_r10.o .libs/sum_r16.o .libs/sum_c4.o .libs/sum_c8.o .libs/sum_c10.o .libs/sum_c16.o .libs/bessel_r4.o .libs/bessel_r8.o .libs/bessel_r10.o .libs/bessel_r16.o .libs/iall_i1.o .libs/iall_i2.o .libs/iall_i4.o .libs/iall_i8.o .libs/iall_i16.o .libs/iany_i1.o .libs/iany_i2.o .libs/iany_i4.o .libs/iany_i8.o .libs/iany_i16.o .libs/iparity_i1.o .libs/iparity_i2.o .libs/iparity_i4.o .libs/iparity_i8.o .libs/iparity_i16.o .libs/norm2_r4.o .libs/norm2_r8.o .libs/norm2_r10.o .libs/norm2_r16.o
[Bug bootstrap/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686 Dennis Clarke changed: What|Removed |Added CC||dclarke at blastwave dot org --- Comment #1 from Dennis Clarke --- As extra information that configure options were : nix_$ pwd /usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.002 nix_$ date Sun Oct 22 21:06:26 GMT 2017 nix_$ ../gcc-7.2.0/config.guess powerpc64-unknown-linux-gnu nix_$ CC='gcc -m64' CXX='g++ -m64' \ > LD_RUN_PATH='/usr/local/lib:/usr/local/gcc7/lib' \ > ../gcc-7.2.0/configure --build=powerpc64-unknown-linux-gnu \ > --target=powerpc64-unknown-linux-gnu --host=powerpc64-unknown-linux-gnu \ > --enable-targets=powerpc64-linux --prefix=/usr/local/gcc7 \ > --disable-nls --enable-threads=posix --enable-shared \ > --with-cpu=default64 --enable-bootstrap \ > --enable-libstdcxx-debug --enable-libstdcxx-time=yes \ > --enable-__cxa_atexit --with-system-zlib --enable-objc-gc \ > --enable-multiarch --with-long-double-128 --enable-multilib \ > --enable-stage1-languages=c,c++ --enable-stage1-checking=misc \ > --enable-languages=ada,c,c++,fortran,go,lto,objc,obj-c++ \ > --with-pkgversion='genunix Sun Oct 22 21:06:26 GMT 2017' That should result in a fully 64-bit gcc with the ability to do multi-lib compiles ( both 64-bit and 32-bit ) however there isn't clear documentation on the required libc package dependencies. Regardless, seems to work fine until late late ( many hours ) into stage3.
[Bug bootstrap/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686 --- Comment #2 from Dennis Clarke --- There may be a hard requirement for the "Boehm-Demers-Weiser conservative garbage collector" from here : http://www.hboehm.info/gc/ I will have resuls in about ten hours.
[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686 --- Comment #4 from Dennis Clarke --- So this is not at all clear about how to continue. I did install the new requirement or at least the "undocumented" dependency from the Debian pkg tree : nix:~# apt-get install libgc-dev Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libgc1c2 The following NEW packages will be installed: libgc-dev libgc1c2 0 upgraded, 2 newly installed, 0 to remove and 14 not upgraded. Need to get 569 kB of archives. After this operation, 1,553 kB of additional disk space will be used. Do you want to continue? [Y/n] . . . However the bootstrap still fails in the stage3 phase : . . . checking whether the target supports thread-local storage... yes checking if the type of bitfields matters... yes checking for bdw garbage collector... checking for system boehm-gc... configure: error: system bdw-gc required but not found gmake[1]: *** [Makefile:22695: configure-target-libobjc] Error 1 gmake[1]: Leaving directory '/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.003' gmake: *** [Makefile:941: all] Error 2 Command exited with non-zero status 2 nix_$ nix_$ cat stage_current stage3 So what exactly is needed in order to get past this? Documented or otherwise?
[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686 --- Comment #6 from Dennis Clarke --- Actually first thing I did was remove a few options from configure stage such that I could at least get past this small bump in the road : --enable-multiarch and --enable-multilib removed. Configure went fine and the bootstrap went past the previous gc bump and then crashed into some sort of an ada problem, again, in stage 3 : $ /usr/bin/time -p /usr/bin/nice -n +19 /usr/local/bin/gmake -k 4 . . . a long while later . . /usr/local/bin/ranlib rts_32/libgnarl.a /usr/local/bin/ar rc rts_32/libgmem.a \ rts_32/memtrack.o /usr/local/bin/ranlib rts_32/libgmem.a chmod a-wx rts_32/*.ali touch ../stamp-gnatlib-rts_32 gmake[7]: Leaving directory '/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.004/gcc/ada' mv -f libgna*.so rts_32 mv -f libgnat_pic.a rts_32 mv -f libgnarl_pic.a rts_32 gmake[6]: Leaving directory '/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.004/gcc/ada' gmake[5]: Leaving directory '/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.004/gcc/ada' rm -rf adainclude rm -rf adalib ln -s ../../.././gcc/ada/rts_32 adainclude ln -s ../../.././gcc/ada/rts_32 adalib true DO=all multi-do # /usr/local/bin/gmake gmake[4]: Leaving directory '/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.004/powerpc64-unknown-linux-gnu/32/libada' gmake[3]: Leaving directory '/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.004/powerpc64-unknown-linux-gnu/libada' gmake[2]: Leaving directory '/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.004/powerpc64-unknown-linux-gnu/libada' gmake[1]: Leaving directory '/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.004' gmake: *** [Makefile:941: all] Error 2 Command exited with non-zero status 2 real 12929.78 user 41765.84 sys 2214.94 nix_$ nix_$ nix_$ cat stage_current stage3 nix_$ So there really are problems in this bootstrap process and it isn't just a new requirement for gc. In any case I will remove "ada" from the language list and try again without multilib or multiarch and see what happens. I expect that the need for multiple arch builds of gc can be sorted out after I see at least a single arch complete, once.
[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686
--- Comment #8 from Dennis Clarke ---
That helps actually. However I am concerned that the folks from IBM are
entirely focused on a particular power architecture and old powerpc cpus
are not considered. Freescale implementations even less so. I note this
only because currect gcc demands the vector scalar hardware in order to
perform some floating point operations and any attempt to work around this
will fail. I will come back to that -mfloat128 option later and for now
just focus on a basic bootstrap.
Since I am seeing a "Makefile:941" error I will assume it is GNU make having
an issue with line 941 of the Makefile and just now I see it again once I
remove ada from the mix :
gmake[6]: Leaving directory
'/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.005/powerpc64-unknown-linux-gnu/32/libssp'
gmake[5]: Leaving directory
'/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.005/powerpc64-unknown-linux-gnu/32/libssp'
gmake[4]: Leaving directory
'/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.005/powerpc64-unknown-linux-gnu/libssp'
gmake[3]: Leaving directory
'/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.005/powerpc64-unknown-linux-gnu/libssp'
gmake[2]: Leaving directory
'/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.005/powerpc64-unknown-linux-gnu/libssp'
libtool: compile:
/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.005/./gcc/xgcc
-B/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.005/./gcc/
-B/usr/local/gcc7/powerpc64-unknown-linux-gnu/bin/
-B/usr/local/gcc7/powerpc64-unknown-linux-gnu/lib/ -isystem
/usr/local/gcc7/powerpc64-unknown-linux-gnu/include -isystem
/usr/local/gcc7/powerpc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-7.2.0/libbacktrace -I ../../../gcc-7.2.0/libbacktrace/../include
-I ../../../gcc-7.2.0/libbacktrace/../libgcc -I ../libgcc -funwind-tables
-frandom-seed=mmap.lo -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-Wcast-qual -Werror -g -O2 -c ../../../gcc-7.2.0/libbacktrace/mmap.c -o mmap.o
>/dev/null 2>&1
/bin/bash ./libtool --tag=CC --mode=link
/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.005/./gcc/xgcc
-B/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.005/./gcc/
-B/usr/local/gcc7/powerpc64-unknown-linux-gnu/bin/
-B/usr/local/gcc7/powerpc64-unknown-linux-gnu/lib/ -isystem
/usr/local/gcc7/powerpc64-unknown-linux-gnu/include -isystem
/usr/local/gcc7/powerpc64-unknown-linux-gnu/sys-include-funwind-tables
-frandom-seed=libbacktrace.la -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-Wcast-qual -Werror -g -O2 -o libbacktrace.la atomic.lo dwarf.lo
fileline.lo posix.lo print.lo sort.lo state.lo backtrace.lo simple.lo elf.lo
mmapio.lo mmap.lo
libtool: link: /usr/local/bin/ar rc .libs/libbacktrace.a .libs/atomic.o
.libs/dwarf.o .libs/fileline.o .libs/posix.o .libs/print.o .libs/sort.o
.libs/state.o .libs/backtrace.o .libs/simple.o .libs/elf.o .libs/mmapio.o
.libs/mmap.o
libtool: link: /usr/local/bin/ranlib .libs/libbacktrace.a
libtool: link: ( cd ".libs" && rm -f "libbacktrace.la" && ln -s
"../libbacktrace.la" "libbacktrace.la" )
gmake[3]: Leaving directory
'/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.005/powerpc64-unknown-linux-gnu/libbacktrace'
gmake[2]: Leaving directory
'/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.005/powerpc64-unknown-linux-gnu/libbacktrace'
gmake[1]: Leaving directory
'/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.005'
gmake: *** [Makefile:941: all] Error 2
Command exited with non-zero status 2
real 11053.27
user 36092.39
sys 1976.30
nix_$
However there is no line 941 there :
nix_$ wc -l powerpc64-unknown-linux-gnu/libbacktrace/Makefile
838 powerpc64-unknown-linux-gnu/libbacktrace/Makefile
Perhaps the primary build dir Makefile ?
935 # The target built for a native non-bootstrap build.
936 .PHONY: all
937 all:
938 [ -f stage_final ] || echo stage3 > stage_final
939 @r=`${PWD_COMMAND}`; export r; \
940 s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
941 $(MAKE) $(RECURSE_FLAGS_TO_PASS) `cat stage_final`-bubble
942 @: $(MAKE); $(unstage)
943 @r=`${PWD_COMMAND}`; export r; \
944 s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
945 if [ -f stage_last ]; then \
946TFLAGS="$(STAGE$(shell test ! -f stage_last || sed s,^stage,,
stage_last)_TFLAGS)"; \
947$(MAKE) $(TARGET_FLAGS_TO_PASS) all-host all-target; \
948 else \
949$(MAKE) $(RECURSE_FLAGS_TO_PASS) all-host all-target \
950 ; \
951 fi \
952 && :
953
Hard to say really.
I will circle back to the top of this mess and go deal with a 32-bit gc and
see if that makes and difference in this process.
[Bug bootstrap/81934] after install of 7.2.0 the libcilkrts.la has extra quote chars in it for dependency_libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81934 --- Comment #2 from Dennis Clarke --- So then, this is a case of "wait and see" wherein any previous release of the gcc tarballs will just continue to fail?
[Bug target/97939] ICE on sparc64 with UBsan for "i + 4096" on long: unrecognizable insn during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939 Dennis Clarke changed: What|Removed |Added CC||dclarke at blastwave dot org --- Comment #4 from Dennis Clarke --- Merely a little followup here. I did see that a unit test in the new libgmp was failing in strange ways on sparc64 and thus I did a round of tests with the previous libgmp and with two versions of gcc on Debisn sid. In all cases the libgmp test failed but only on one platform. https://gmplib.org/list-archives/gmp-bugs/2020-November/004962.html The idea on the table is that we have a compiler fault here and then Vincent Lefèvre seems to have isolated the code test down to a trivial test case. To add on here I see the same sort of behavior with gcc 8.1.0 on a Solaris sparcv9 server : isc $ isc $ uname -a SunOS isc 5.10 Generic_150400-44 sun4u sparc SUNW,UltraAX-i2 isc $ /usr/local/gcc8/bin/gcc --version gcc (genunix Fri May 11 08:23:40 GMT 2018) 8.1.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. isc $ $CC -fsanitize=undefined -v -c tst.c Using built-in specs. COLLECT_GCC=/usr/local/gcc8/bin/gcc Target: sparc64-sun-solaris2.10 Configured with: ../gcc-8.1.0/configure --prefix=/usr/local/gcc8 --build=sparc64-sun-solaris2.10 --target=sparc64-sun-solaris2.10 --host=sparc64-sun-solaris2.10 --without-gnu-as --without-gnu-ld --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/sparcv9/ld --disable-nls --enable-threads=posix --enable-shared --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --with-isl=/usr/local --with-build-time-tools=/usr/local/bin --with-cpu=v9 --enable-bootstrap --enable-stage1-languages=c,c++ --enable-stage1-checking=misc --enable-languages=ada,c,c++,fortran,go,lto,objc,obj-c++ --with-pkgversion='genunix Fri May 11 08:23:40 GMT 2018' Thread model: posix gcc version 8.1.0 (genunix Fri May 11 08:23:40 GMT 2018) COLLECT_GCC_OPTIONS='-fsanitize=undefined' '-v' '-c' '-mcpu=v9' /usr/local/gcc8/libexec/gcc/sparc64-sun-solaris2.10/8.1.0/cc1 -quiet -v -D__arch64__ -D__sparcv9 tst.c -quiet -dumpbase tst.c -mcpu=v9 -auxbase tst -version -fsanitize=undefined -o /var/tmp//ccI8b25O.s GNU C17 (genunix Fri May 11 08:23:40 GMT 2018) version 8.1.0 (sparc64-sun-solaris2.10) compiled by GNU C version 8.1.0, GMP version 6.1.2, MPFR version 4.0.1-p6, MPC version 1.1.0, isl version isl-0.19-GMP warning: MPFR header version 4.0.1-p6 differs from library version 4.0.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/gcc8/lib/gcc/sparc64-sun-solaris2.10/8.1.0/../../../../sparc64-sun-solaris2.10/include" #include "..." search starts here: #include <...> search starts here: /usr/local/gcc8/lib/gcc/sparc64-sun-solaris2.10/8.1.0/include /usr/local/include /usr/local/gcc8/include /usr/local/gcc8/lib/gcc/sparc64-sun-solaris2.10/8.1.0/include-fixed /usr/include End of search list. GNU C17 (genunix Fri May 11 08:23:40 GMT 2018) version 8.1.0 (sparc64-sun-solaris2.10) compiled by GNU C version 8.1.0, GMP version 6.1.2, MPFR version 4.0.1-p6, MPC version 1.1.0, isl version isl-0.19-GMP warning: MPFR header version 4.0.1-p6 differs from library version 4.0.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 56c9e74e9d01ca812c9fcd9ec58a5d7d tst.c: In function 'f': tst.c:5:1: error: unrecognizable insn: } ^ (insn 7 6 8 2 (parallel [ (set (reg:CCXV 100 %icc) (compare:CCXV (plus:DI (reg:DI 112) (const_int 4096 [0x1000])) (unspec:DI [ (reg:DI 112) (const_int 4096 [0x1000]) ] UNSPEC_ADDV))) (set (reg:DI 111) (plus:DI (reg:DI 112) (const_int 4096 [0x1000]))) ]) "tst.c":4 -1 (nil)) during RTL pass: vregs tst.c:5:1: internal compiler error: in extract_insn, at recog.c:2304 0x100daff3b _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc-8.1.0/gcc/rtl-error.c:108 0x100daff73 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc-8.1.0/gcc/rtl-error.c:116 0x1005e15eb extract_insn(rtx_insn*) ../../gcc-8.1.0/gcc/recog.c:2304 0x1003c0a57 instantiate_virtual_regs_in_insn ../../gcc-8.1.0/gcc/function.c:1648 0x1003c0a57 instantiate_virtual_regs ../../gcc-8.1.0/gcc/function.c:1969 0x1003c0a57 execute ../../gcc-8.1.0/gcc/function.c:2018 Please submit a full bug report, with preprocessed source if
[Bug target/97939] ICE on sparc64 with UBsan for "i + 4096" on long: unrecognizable insn during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
--- Comment #5 from Dennis Clarke ---
Not sure how useful this is but all of the following toss the same ICE :
long f(long arg){return arg + 4096;}
long f(long arg){return arg - 4096;}
long f(long arg){return 4096 + arg;}
long f(long arg){return arg - 4096;}
However these work fine :
long f(long arg){return 4096 - arg;}
long f(long arg){return arg * 4096;}
long f(long arg){return 4096 * arg;}
long f(long arg){return arg / 4096;}
etc etc etc as well as other powers of 2.
very strange.
[Bug ada/108472] New: gcc/ada/b_gnat1.adb:363: undefined reference to `system__assertions___elabs'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472 Bug ID: 108472 Summary: gcc/ada/b_gnat1.adb:363: undefined reference to `system__assertions___elabs' Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: dclarke at blastwave dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Not at all sure how to proceed here thus I will file this bug report in hopes that it is not environmental. Not sure how to make any sense from this : . . . /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada ada/g-graphs.adb -o ada/g-graphs.o mkdir -p ada/ /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada ada/g-lists.adb -o ada/g-lists.o mkdir -p ada/ /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada ada/g-sets.adb -o ada/g-sets.o mkdir -p ada/ /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada ada/s-pehage.adb -o ada/s-pehage.o mkdir -p ada/ /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada ada/s-utf_32.adb -o ada/s-utf_32.o mkdir -p ada/ /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada ../../gcc-12.2.0/gcc/ada/back_end.adb -o ada/back_end.o mkdir -p ada/ /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada ../../gcc-12.2.0/gcc/ada/gnat1drv.adb -o ada/gnat1drv.o x86_64-linux-gnu-gnatbind -t -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada -o b_gnat1.adb -n ada/gnat1drv.ali warning: "s-stalib.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-except.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "ada.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-elchha.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "system.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-soflin.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-secsta.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-parame.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-stoele.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-soliin.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-stache.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-exctab.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-except.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-excmac.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-excdeb.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-imgint.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-traceb.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-traent.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-trasym.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-contai.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-exctra.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "interfac.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "i-c.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-boustr.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-crtl.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-dwalin.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-charac.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-chahan.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-chlat1.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-string.ads" and "gnat1drv.adb" compiled with different GNAT versio
[Bug ada/108472] gcc/ada/b_gnat1.adb:363: undefined reference to `system__assertions___elabs'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472 --- Comment #1 from Dennis Clarke --- Tried again with the system binutils and I see the same error : /bin/ld: ada/b_gnat1.o: in function `adainit': /opt/bw/build/gcc-12.2.0_linux_amd64.004/gcc/ada/b_gnat1.adb:363: undefined reference to `system__assertions___elabs' collect2: error: ld returned 1 exit status make[3]: *** [../../gcc-12.2.0/gcc/ada/gcc-interface/Make-lang.in:744: gnat1] Error 1
[Bug ada/108472] gcc/ada/b_gnat1.adb:363: undefined reference to `system__assertions___elabs'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472 --- Comment #4 from Dennis Clarke --- (In reply to Andrew Pinski from comment #2) > >warning: "s-stalib.adb" and "gnat1drv.adb" compiled with different GNAT > >versions > > Is the first thing you should look into. > > Since you are setting the PATH to include /opt/imed/gcc12/bin but you don't > set LD_LIBRAR_PATH to include /opt/imed/gcc12/lib64 ... Actually I have never heard of such a thing. Let's give that a whirl !
[Bug ada/108472] gcc/ada/b_gnat1.adb:363: undefined reference to `system__assertions___elabs'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472 --- Comment #5 from Dennis Clarke --- (In reply to Andreas Schwab from comment #3) > You are mixing two different ada compilers: > > /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. > -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada > ../../gcc-12.2.0/gcc/ada/gnat1drv.adb -o ada/gnat1drv.o > x86_64-linux-gnu-gnatbind -t -I- -I. -Iada/generated -Iada > -I../../gcc-12.2.0/gcc/ada -o b_gnat1.adb -n ada/gnat1drv.ali Brilliant! I shall dpkg --purge all other gnat/ada and then use the previously built and bootstrapped version I have in the /opt/imed directory structure. Thank you !
[Bug ada/108472] gcc/ada/b_gnat1.adb:363: undefined reference to `system__assertions___elabs'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472 Dennis Clarke changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Dennis Clarke --- The bootstrap now completes just fine. However the testsuite shows a very large number of failures : https://gcc.gnu.org/pipermail/gcc-testresults/2023-January/776331.html 371 "unexpected failures" seems like a very large amount of fail for the gcc compiler. The g++ seems very good as do the other components. Also there is not even a single report of test results from anyone anywhere for 12.2.0 this month and mybe that explains why this page is broken : https://gcc.gnu.org/gcc-12/buildstat.html In fact ALL of those "buildstat" pages are broken and have been for years. That is another topic entirely. NOTE : I did *not* set LD_LIBRAR_PATH at all as I have never heard of that thing nor do I know of any document that suggests we need that. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
[Bug bootstrap/88633] stage2 failure due to undefined reference to libintl_dgettext on armv7l-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88633 Dennis Clarke changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Dennis Clarke --- I have never seen this again and I have since been able to do a full bootstrap of gcc 12.1.0 on the very same armv7l hardware. May as well close this as "fixed". -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
[Bug ada/110668] New: gcc/ada/gcc-interface/Make-lang.in:1012: ada/b_gnat1.adb] Error 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110668 Bug ID: 110668 Summary: gcc/ada/gcc-interface/Make-lang.in:1012: ada/b_gnat1.adb] Error 5 Product: gcc Version: 10.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: dclarke at blastwave dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Not sure where this arrived from however here are the particulars : System is very off the shelf devuan/debian with a lean kernel : d# uname -a Linux dev 6.4.2-genunix #1 SMP PREEMPT_DYNAMIC Fri Jul 7 18:41:16 UTC 2023 x86_64 GNU/Linux d# Compiler used for the bootstrap : d# which gcc /opt/bw/gcc13/bin/gcc d# d# gcc --version gcc (GENUNIX Mon Jun 26 19:37:30 UTC 2023) 13.1.0 Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. see https://gcc.gnu.org/pipermail/gcc-testresults/2023-June/788747.html So I suspect that compiler to be good stuff. With gnat in there also : d# ls /opt/bw/gcc13/bin/ c++ gfortran gnatprep cpp gnat lto-dump g++ gnatbind x86_64-pc-linux-gnu-c++ gcc gnatchop x86_64-pc-linux-gnu-g++ gcc-ar gnatclean x86_64-pc-linux-gnu-gcc gcc-nm gnatkr x86_64-pc-linux-gnu-gcc-13.1.0 gcc-ranlib gnatlink x86_64-pc-linux-gnu-gcc-ar gcovgnatls x86_64-pc-linux-gnu-gcc-nm gcov-dump gnatmake x86_64-pc-linux-gnu-gcc-ranlib gcov-tool gnatname x86_64-pc-linux-gnu-gfortran d# So imagine my total surprise when configure looks so nice and the whole compile/bootstrap takes off nicely but then falls over quickly : d# d# pwd /opt/bw/build/gcc-10.5.0_linux-6.4.2_x86_64.001 d# date -u Fri Jul 14 14:14:46 UTC 2023 d# ../gcc-10.5.0/configure --prefix=/opt/imed/gcc10 \ > --enable-languages=c,ada,c++,fortran,objc,obj-c++ \ > --enable-shared --without-included-gettext \ > --enable-threads=posix --enable-bootstrap --with-system-zlib \ > --enable-checking=misc --disable-multilib --disable-nls \ > --enable-__cxa_atexit --enable-tls \ > --with-pkgversion='GENUNIX Fri Jul 14 14:14:46 UTC 2023' 2>&1 | tee > ../gcc-10.5.0_linux-6.4.2_x86_64.001.config.log checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... x86_64-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /bin/sed checking for gawk... no checking for mawk... mawk checking for libatomic support... yes checking for libitm support... yes checking for libsanitizer support... yes checking for libvtv support... yes checking for libhsail-rt support... yes checking for libphobos support... yes checking for gcc... /opt/bw/gcc13/bin/gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /opt/bw/gcc13/bin/gcc accepts -g... yes checking for /opt/bw/gcc13/bin/gcc option to accept ISO C89... none needed checking whether we are using the GNU C++ compiler... yes checking whether /opt/bw/gcc13/bin/g++ accepts -g... yes checking whether g++ accepts -static-libstdc++ -static-libgcc... yes checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for objdir... .libs configure: WARNING: using in-tree isl, disabling version check The following languages will be built: c,ada,c++,fortran,lto,objc,obj-c++ *** This configuration is not supported in the following subdirectories: zlib gotools target-libhsail-rt target-libphobos target-zlib target-libgo target-libffi target-liboffloadmic (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug checking for --enable-vtable-verify... no checking for bison... bison -y checking for bison... bison checking for gm4... no checking for gnum4... no checking for m4... m4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for ar... ar checking for as... as checking for dlltool... no checking for dsymutil... no checking for ld... ld checking for lipo... no checking for nm... nm checking for ranlib... ranlib checking for strip... strip checking for windres... no checking for windmc... no checking for o
[Bug ada/110668] gcc/ada/gcc-interface/Make-lang.in:1012: ada/b_gnat1.adb] Error 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110668 --- Comment #2 from Dennis Clarke --- Oh darn. Is this documented anywhere in the build instructions?
[Bug ada/110668] gcc/ada/gcc-interface/Make-lang.in:1012: ada/b_gnat1.adb] Error 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110668 Dennis Clarke changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Dennis Clarke --- Lets call this invalid !
