Documentation for gcc 9.1 changes
Hello, looking at the changes for configuration in gcc 9.1, I noticed: 1) New configure options OTOOL/OTOOL_FOR_TARGET: Which I assume from google is the Darwin ldd replacement GDC_FOR_TARGET: Which with a bit of guess work I assume is the Gnu_D_Compiler Is this stuff documented anywhere? 2) D language documentation Also looking at the D documentation it appears missing in action: No manual here: https://gcc.gnu.org/onlinedocs/ and the release notes just say: "Support for the D programming language has been added to GCC, implementing version 2.076 of the language and run-time library." If this stuff is documented elsewhere a link to said documentation would be useful. 3) Stdlibc++ Release notes reference parallel algorithms requiring TBB 2018 or newer, again guess work suggests this is Thread Building Blocks. It would be nice to explicitly say that, and provide links to implementations. How is TBB detected and selected? I didn't see any configure switches relating to this either in the toplevel configure or stdc++ configure files. Can it be built in tree etc? Also while TBB may not be a prerequisite should it be at least documented on that page: https://gcc.gnu.org/install/prerequisites.html (or somewhere) The TBB release notes (written by Intel) seem to limit things to Intel or compatible processors, wikipedia suggests a wider range (sparc?, powerpc). Is ARM supported? Again it would be nice to document what range of systems this can work on. Thanks Andrew
gcc behavior on memory exhaustion
I routinely build the weekly snapshots and RC's, on x64, arm and aarch64.
The last gcc 8 snapshot and the two recent 7.2 RC's have failed to build
on aarch64 (Raspberry Pi 3, running Arch Linux ARM). I have finally
traced this to the system running out of memory. I guess a recent kernel
update had changed the memory page size and the swap file was no longer
being used because the page sizes didn't match.
Obviously this is my issue, but the error's I was getting from gcc did
not help. I was getting ICE's, thus:
/usr/local/gcc/bin/g++ -Wall -Wextra -Wno-ignored-qualifiers
-Wno-sign-compare -Wno-write-strings -std=c++14 -pipe -march=armv8-a
-mcpu=cortex-a53 -mtune=cortex-a53 -ftree-vectorize -O3
-DUNAME_S=\"linux\" -DUNAME_M=\"aarch64\" -DOSMESA=1 -I../libs/include
-DRASPBERRY_PI -I/usr/include/freetype2 -I/usr/include/harfbuzz
-I/usr/include/unicode -c -o glerr.o glerr.cpp
{standard input}: Assembler messages:
{standard input}: Warning: end of file not at end of a line; newline
inserted
{standard input}:204: Error: operand 1 must be an integer register -- `mov'
{standard input}: Error: open CFI at the end of file; missing
.cfi_endproc directive
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make: *** [: glerr.o] Error 4
make: *** Waiting for unfinished jobs
I was seeing the problem when building using make -j2. Both building gcc
and building large user projects.
There are two issues here:
1) There was discussion about increasing the amount of memory gcc would
reserve to help speed up compilation of large source files, I wondered
if this could be a factor.
2) It would be nice to see some sort of out of memory error, rather than
just an ICE.
The system has 858Mb of RAM without the swap file.
Building a single source file seems to use up to 97% of the available
memory (for a 2522 line C++ source file).
make -j2 is enough to cause the failure.
Regards
Andrew Roberts
Re: gcc behavior on memory exhaustion
On 09/08/17 14:05, Andrew Roberts wrote:
I routinely build the weekly snapshots and RC's, on x64, arm and aarch64.
The last gcc 8 snapshot and the two recent 7.2 RC's have failed to
build on aarch64 (Raspberry Pi 3, running Arch Linux ARM). I have
finally traced this to the system running out of memory. I guess a
recent kernel update had changed the memory page size and the swap
file was no longer being used because the page sizes didn't match.
Obviously this is my issue, but the error's I was getting from gcc did
not help. I was getting ICE's, thus:
/usr/local/gcc/bin/g++ -Wall -Wextra -Wno-ignored-qualifiers
-Wno-sign-compare -Wno-write-strings -std=c++14 -pipe -march=armv8-a
-mcpu=cortex-a53 -mtune=cortex-a53 -ftree-vectorize -O3
-DUNAME_S=\"linux\" -DUNAME_M=\"aarch64\" -DOSMESA=1 -I../libs/include
-DRASPBERRY_PI -I/usr/include/freetype2 -I/usr/include/harfbuzz
-I/usr/include/unicode -c -o glerr.o glerr.cpp
{standard input}: Assembler messages:
{standard input}: Warning: end of file not at end of a line; newline
inserted
{standard input}:204: Error: operand 1 must be an integer register --
`mov'
{standard input}: Error: open CFI at the end of file; missing
.cfi_endproc directive
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make: *** [: glerr.o] Error 4
make: *** Waiting for unfinished jobs
I was seeing the problem when building using make -j2. Both building
gcc and building large user projects.
There are two issues here:
1) There was discussion about increasing the amount of memory gcc
would reserve to help speed up compilation of large source files, I
wondered if this could be a factor.
2) It would be nice to see some sort of out of memory error, rather
than just an ICE.
The system has 858Mb of RAM without the swap file.
Building a single source file seems to use up to 97% of the available
memory (for a 2522 line C++ source file).
make -j2 is enough to cause the failure.
Regards
Andrew Roberts
For what its worth, if I disable the swap on a 32 bit Raspberry Pi3
(armv7l), with 936Kb free memory, building my project with make -j4,
only uses 33% of the memory, and does not ICE.
So there seems a huge memory usage regression for aarch64 vs arm. Nearly
3x the memory usage is more than you would expect by doubling pointer
sizes. Does aarch64 use a different default preallocation of memory?
Regards
Andrew
Re: gcc behavior on memory exhaustion
On 11/08/17 02:09, Pedro Alves wrote: Meanwhile, maybe just having the driver check for SIGKILL and enumerate likely causes would be better than the status quo. Pedro Alves I agree, having some indication it MIGHT be out of memory would stop people wasting a lot of time, and avoid spurious bug reports. Meanwhile, I'm testing memory usage and compile times with my code on gcc 5.4.0, 6.4.0, 7.2.0 and 8.0.0, across x64, arm and aarch64. I'll file a bug report on the memory-hog issue after I've narrowed down the issue. There certainly does seem to be far worse performance on aarch64 vs arm. Here's a flavour, for a single C++ file: aarch64 GCCCompileTimeMemoryUsed 5.4.04:18.24357328 6.4.02:57.14730020 7.2.03:03.38735748 8.0.03:29.16837316 arm 5.4.03:39.20247696 6.4.02:15.41287904 7.2.02:22.85294324 8.0.02:41.79306032 So there has been a massive blow up in memory usage on aarch64 vs arm. While compile times for a single file are better (and its not yet pagefaulting). For multiple files I'm getting 400+ pagefaults while building the entire project, vs none for arm. If anybody has some suggestions for things I should test I'll give it a go. I'll also play with: --param ggc-min-expand= --param ggc-min-heapsize= Is there a way of getting a list of individual optimizations enabled by -O3, so I can try removing individual ones? BTW the code is very simple and dumb. Its an automatically generated file which just populates a std::map using 2330 inserts. I'm sure there are better ways of doing this, but never discount how dumb your users are... Thanks Andrew
Re: gcc behavior on memory exhaustion
On 10/08/17 10:22, Richard Earnshaw (lists) wrote: If you think gcc is using an unreasonable amount of memory for a particular bit of code then please file a bug report, with pre-processed source code (don't assume that because the sources are part of gcc we can reproduce your setup). You should also set the keyword "memory-hog" on the report. If you have statistics for older versions of the compiler, or for other targets that will add evidence for us to look at. R. I've submitted bug number 81818 [aarch64 uses 2-3x memory and 2x time of arm at -Os, -O2, -O3 (memory-hog) ]for this issue. All gcc versions from 5.4.0 to 8.0.0 seem to be affected on aarch64. Andrew
Re: gcc behavior on memory exhaustion (bug 81818)
I've updated this bug [Bug 81818 - aarch64 uses 2-3x memory and 2x time of arm at -Os, -O2, -O3] with more info. It looks to be that on ARM systems with limited RAM optimizations are being skipped, but not on AARCH64. Is there a way I can check this is true? I checked all the optimizations enabled at -O2 which where not in -O1, and checked memory usage of each. -fgcse came out the winner, using huge amounts of memory. Comparing -O1, -O1 -fgcse and -O2, on Rasberry Pi 3, and odroid-c2. ARM (1Gb RAM): gcc -O1 -c testmap.cpp Time=2:25.26 Mem=318976 PageFaults=0 gcc -O1 -fgcse -c testmap.cpp Time=2:42.04 Mem=554872 PageFaults=123 gcc -O2 -c testmap.cpp Time=2:31.89 Mem=262828 PageFaults=11 <== Is this really running all -O2 opts? AARCH64 (1Gb RAM): gcc -O1 -c testmap.cpp Time=3:10.68 Mem=397248 PageFaults=3 gcc -O1 -fgcse -c testmap.cpp Time=5:15.26 Mem=771276 PageFaults=166 gcc -O2 -c testmap.cpp Time=11:06.06 Mem=820744 PageFaults=4266 <== blows up big time unlike ARM AARCH64 (2Gb RAM, odroid-c2, different clock speed etc): gcc -O1 -c ../testmap.cpp Time=1:47.58 Mem=394896 PageFaults=0 gcc -O1 -fgcse -c ../testmap.cpp Time=3:10.06 Mem=765460 PageFaults=0 gcc -O2 -c ../testmap.cpp Time=3:05.06 Mem=906624 PageFaults=0 <== ok if enough RAM though Andrew
gcc Bugzilla corrupt again?
I was adding a comment to bug: 81616 - Update -mtune=generic for the current Intel and AMD processors After clicking add comment it took me an an entirely different bug. I tried to add the comment again, and got a message about a "Mid Air Collision" The comment ended up the system twice (Comment 4/5). But I've never seen it take me to a different bug after adding a comment before.
Re: gcc Bugzilla corrupt again?
Its not my first bug, I've had plenty. But the first since the last bugzilla crash a couple of months ago. Perhaps the recovery from that altered the default or changed my account setup. I've now reset it. Part of my last bug was lost in the last crash, so I was just feeling paranoid. Thanks Andrew
Re: GNU MPFR 4.0.0 Release Candidate
MPFR 4.0.0-rc1 causes in-tree build of gcc to fail (error building mpc) Using: gcc-8-20171203 gmp 6.1.2 mpc 1.0.3 mpfr 4.0.0-rc1 isl 0.16.1 mpfr-3.1.6 works fine. /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../gcc-8.0.0/mpc/src -I.. -I/home/aroberts/gcc/gcc-build/./gmp -I/home/aroberts/gcc/gcc-8.0.0/mpfr/src -O2 -g -pipe -MT pow_d.lo -MD -MP -MF .deps/pow_d.Tpo -c -o pow_d.lo ../../../gcc-8.0.0/mpc/src/pow_d.c ../../../gcc-8.0.0/mpc/src/mul.c:175:1: error: conflicting types for ‘mpfr_fmma’ mpfr_fmma (mpfr_ptr z, mpfr_srcptr a, mpfr_srcptr b, mpfr_srcptr c, ^ In file included from ../../../gcc-8.0.0/mpc/src/mpc.h:25:0, from ../../../gcc-8.0.0/mpc/src/mpc-impl.h:30, from ../../../gcc-8.0.0/mpc/src/mul.c:22: /home/aroberts/gcc/gcc-8.0.0/mpfr/src/mpfr.h:731:21: note: previous declaration of ‘mpfr_fmma’ was here __MPFR_DECLSPEC int mpfr_fmma (mpfr_ptr, mpfr_srcptr, mpfr_srcptr, mpfr_srcptr, ^ make[4]: *** [Makefile:532: mul.lo] Error 1 I've also sent additional info to mpfr at inria.fr, but that was possibly rejected (sent to moderators), so this is just a heads up. And yes I know its not an officially supported combination etc etc... Regards Andrew
Re: mpc-1.1 release candidate
I've tested building: gcc version 8.0.0 20171210 (experimental) (GCC) With the following in tree: gmpver=6.1.2 mpfrver=4.0.0-rc1 mpcver=1.1-rc1 islver=0.16.1 This now works fine on: x86_64-unknown-linux-gnu armv7l-unknown-linux-gnueabihf aarch64-unknown-linux-gnu x86_64-apple-darwin17.3.0 I've also run the "make check" for mpfr and mpc, and all tests pass apart from those skipped. The following build is on going but has gotten past building mpfr/mpc etc. armv6l-unknown-linux-gnueabihf Regards Andrew
Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode
Boot strap on Darwin x86_64 with llvm now seems broken as of last 8.0.0 snapshot, it still is working fine with 7.2.0. I've added bug: 83903 x86_64, armv6, armv7, aarch64 all seem fine on linux. I've been building with latest gmp (6.1.2), mpfr (4.0.0) and mpc (1.1.) across all my systems. I observe isl was updated to 0.18 in the download_prerequisites script. Are the other's going to get updated before the 8.0.0 release?
Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode
It might be worth checking what MPFR is linking with in the test suite. I seemed to see it linking with the system libs when built in tree, rather than the in tree ones. This seems a regression in the MPFR test suite compared with 3.1.6 Andrew On 26/01/18 14:22, Rainer Orth wrote: I've given it a try with that combo on sparc-sun-solaris2.10 (a primary target) and i386-pc-solaris2.10 (32 and 64-bit each), with mixed results: * The gmp reuse test enters an infinite loop on 32-bit sparc. * The mpfr trint test FAILs on sparcv9. The failure vanishes with --disable-thread-safe. * Many mpfr tests FAIL on amd64. Again, they vanish with --disable-thread-safe. I have not yet tried building gcc with those versions yet. Beside, IMO we need to make sure that trunk and all open branches can be built with that version set; having to maintain two different sets isn't an option. Rainer
gcc 8.0.1 RC documentation broken
I filed a bug (85578) about the documentation in: gcc-8.0.1-RC-20180427/INSTALL being broken (links not working). I filed this under 'web' as I couldn't see any documentation component. It doesn't appear to have been looked at, so just wanted to flag it up before the release tomorrow.
Re: Broken links in INSTALL/specific.html
The reason I was looking at the versions in the RC tarball was that I
have never been clear as to what release the website
install/prerequisite/target info actually applies to.
It would be much better if this info was on a per release basis on the
web site, like the changelog and manuals. Thus any target
specific stuff which was removed wouldn't affect older releases
documentation.
Speaking of manuals, it might be worth documenting the make commands for
the documentation (make html, install-html and pdf, install-pdf) on the
build.html page.
The documentation can only get checked before the release if people are
aware how to build it.
Andrew
On 01/05/18 08:27, Jakub Jelinek wrote:
Hi!
PR web/85578 complains about broken links in INSTALL/specific.html inside of
the rc tarballs, I've looked at past releases and at least the releases I've
checked (4.7.0, 6.1, 7.1, 7.3, 8.1rc2) all have the broken links,
e.g.
aarch64*-*-*
and
aarch64*-*-*
Looking at online docs, they are ok.
I think this has been fixed for the online docs with:
Index: preprocess
===
RCS file: /cvs/gcc/wwwdocs/bin/preprocess,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -p -r1.38 -r1.39
--- preprocess 28 Aug 2003 13:05:38 - 1.38
+++ preprocess 5 Sep 2004 21:50:02 - 1.39
@@ -144,7 +144,10 @@ process_file()
cat $STYLE > $TMPDIR/input
printf '\n' `pwd` >>
$TMPDIR/input
cat $f >> $TMPDIR/input
-${MHC} $TMPDIR/input > $TMPDIR/output
+# Use sed to work around makeinfo 4.7 brokenness.
+${MHC} $TMPDIR/input \
+| sed -e 's/_002d/-/g' -e 's/_002a/*/g' \
+> $TMPDIR/output
# Copy the page only if it's new or there has been a change, and,
# first of all, if there was no problem when running MetaHTML.
revision 1.39
date: 2004/09/05 21:50:02; author: gerald; state: Exp; lines: +4 -1
Use sed to work around makeinfo 4.7 brokenness.
Isn't this something we should be doing in gcc/doc/install.texi2html
too (or somewhere else)?
Bugzilla is down, so can't discuss it there...
Jakub
