[patch] fix libsanitizer build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 on 32bit architectures
libsanitizer fails to build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64, triggering an #error in /usr/include/features-time64.h --- a/libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cpp +++ b/libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cpp @@ -11,6 +11,7 @@ // Before Solaris 11.4, doesn't work in a largefile environment. #undef _FILE_OFFSET_BITS +#undef _TIME_BITS #include "sanitizer_platform.h" #if SANITIZER_SOLARIS # include --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp @@ -18,6 +18,7 @@ // depends on _FILE_OFFSET_BITS setting. // To get this "true" dirent definition, we undefine _FILE_OFFSET_BITS below. #undef _FILE_OFFSET_BITS +#undef _TIME_BITS #endif // Must go after undef _FILE_OFFSET_BITS. The patch to sanitizer_platform_limits_posix.cpp is already present in trunk, but missing from the branches. Because all platform files are built in GCC, you also see the failure in sanitizer_procmaps_solaris.cpp. Just doing the same as for the posix files fixes the issue and libsanitizer builds again. Does this have any effect on the solaris builds? If not, ok for the trunk and the branches? Matthias
Re: [PATCHv2] Use toplevel configure for GMP and MPFR for gdb
On 10.11.22 20:05, apinski--- via Binutils wrote: From: Andrew Pinski This patch uses the toplevel configure parts for GMP/MPFR for gdb. The only thing is that gdb now requires MPFR for building. Before it was a recommended but not required library. Also this allows building of GMP and MPFR with the toplevel directory just like how it is done for GCC. We now error out in the toplevel configure of the version of GMP and MPFR that is wrong. OK after GDB 13 branches? Build gdb 3 ways: with GMP and MPFR in the toplevel (static library used at that point for both) With only MPFR in the toplevel (GMP distro library used and MPFR built from source) With neither GMP and MPFR in the toplevel (distro libraries used) this still seems to be broken for a gdb trunk build, using GMP and MPFR system libraries: linking gdb: [...] ../gnulib/import/libgnu.a -Lyes/lib -lmpfr -lgmp -lsource-highlight -lboost_regex -lxxhash -ldebuginfod -ldl -Wl,--dynamic-list=/<>/gdb/proc-service.list ./libtool: line 5209: cd: yes/lib: No such file or directory libtool: link: cannot determine absolute directory name of `yes/lib' make[3]: *** [Makefile:2174: gdb] Error 1 make[3]: Leaving directory '/<>/build/default/gdb' full build log at https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/15065515/+listing-archive-extra the toplevel config.log has: configure:8183: checking for the correct version of gmp.h configure:8202: x86_64-linux-gnu-gcc -c -Iyes/include -fPIC conftest.c >&5 configure:8202: $? = 0 configure:8220: x86_64-linux-gnu-gcc -c -Iyes/include -fPIC conftest.c >&5 configure:8220: $? = 0 configure:8221: result: yes configure:8237: checking for the correct version of mpfr.h configure:8255: x86_64-linux-gnu-gcc -c -Iyes/include -fPIC conftest.c >&5 configure:8255: $? = 0 configure:8272: x86_64-linux-gnu-gcc -c -Iyes/include -fPIC conftest.c >&5 configure:8272: $? = 0 configure:8273: result: yes configure:8342: checking for the correct version of the gmp/mpfr libraries configure:8366: x86_64-linux-gnu-gcc -o conftest -Iyes/include -fPIC conftest.c -Lyes/lib -lmpfr -lgmp >&5 configure:8366: $? = 0 configure:8367: result: yes configure:8615: checking for isl 0.15 or later configure:8628: x86_64-linux-gnu-gcc -o conftest -Iyes/include -fPIC -lisl -Lyes/lib -lmpfr -lgmp conftest.c -lisl -lgmp >&5 configure:8628: $? = 0
[ada, patch] fix libgnat build on x86_64-linux-gnux32 with glibc <= 2.31
This was introduced with the fix and backports of PR103530 on x86_64-linux-gnux32 with older glibc versions (checked with 2.31), where dladdr is still in the libdl.so library, and not included in libc.so as in newer glibc versions. Linking of libgnat.so fails with [...] /usr/x86_64-linux-gnux32/bin/ld: s-trasym.o: in function `system__traceback__symbolic__module_na me__getXnn': collect2: error: ld returned 1 exit status make[8]: *** [gcc-interface/Makefile:677: gnatlib-shared-default] Error 1 https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=9d6c63ba490ec92245f04b5cbafc56abd28e8d22 -- a/gcc/ada/Makefile.rtl +++ b/gcc/ada/Makefile.rtl @@ -2650,13 +2650,18 @@ ifeq ($(strip $(filter-out %x32 linux%,$(target_cpu) $(target_os))),) s-tasinf.adbThe addition of s-tsmona.adbto dladdr, however not setting MISCLIB to -ldl as on other architectures Proposed patch: PR ada/107475 * Makefile.rtl: Set MISCLIB for x86_64-linux-gnux32. --- a/gcc/ada/Makefile.rtl +++ b/gcc/ada/Makefile.rtl @@ -2584,6 +2584,7 @@ ifeq ($(strip $(filter-out %x32 linux%,$(target_cpu) $(target_os))),) EXTRA_GNATRTL_TASKING_OBJS=s-linux.o a-exetim.o EH_MECHANISM=-gcc THREADSLIB=-lpthread -lrt + MISCLIB = -ldl GNATLIB_SHARED=gnatlib-shared-dual GMEM_LIB = gmemlib LIBRARY_VERSION := $(LIB_VERSION) Ok for the trunk and the branches? Matthias
Re: Porting the Docs to Sphinx - project status
On 1/31/22 15:06, Martin Liška wrote: > Hello. > > It's about 5 months since the last project status update: > https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577108.html > Now it's pretty clear that it won't be merged before GCC 12.1 gets released. > > So where we are? I contacted documentation maintainers (Gerald, Sandra and > Joseph) at the > end of the year in a private email, where I pinged the patches. My take away > is > that both > Gerald and Joseph are fine with the porting, while Sandra has some concerns. > Based on her > feedback, I was able to improve the PDF generated output significantly and I'm > pleased by the > provided feedback. That led to the following 2 Sphinx pulls requests that need > to be merged > before we can migrate the documentation: [1], [2]. > > Since the last time I also made one more round of proofreading and the layout > was improved > (mainly for PDF part). Current version of the documentation can be seen here: > https://splichal.eu/scripts/sphinx/ > > I would like to finish the transition once GCC 12.1 gets released in May/June > this year. > There are still some minor regressions, but overall the Sphinx-based > documentation should > be a significant improvement over what we've got right now. > > Please take this email as urgent call for a feedback! Please take care about the copyrights. I only checked the D frontend manual, and this one suddenly has a copyright with invariant sections, compared to the current gdc.texi which has a copyright *without* the invariant sections. Debian doesn't allow me to ship documentation with invariant sections ... I didn't look how much you reorganized the sources, but it would nice to split the files into those documenting command line options (used to generate the man pages) and other documentation. This is already done for gcc/doc, but not for other frontends. It would allow having manual pages with a copyright requiring front and back cover texts in the manual pages. It would also be nice to require the latest sphinx version (and probably some plugins), so that distros can build the docs with older sphinx versions as well. Matthias
Re: libgo patch committed: Update to Go1.17rc2 release
On 8/31/21 3:24 PM, H.J. Lu via Gcc-patches wrote: > On Thu, Aug 12, 2021 at 8:24 PM Ian Lance Taylor via Gcc-patches > wrote: >> >> This patch updates libgo from the Go1.16.5 release to the Go 1.17rc2 >> release. As usual with these version updates, the patch itself is too >> large to attach to this e-mail message. I've attached the changes to >> files that are specific to gccgo. Bootstraped and ran Go testsuite on >> x86_64-pc-linux-gnu. Committed to mainline. >> >> Ian > > This breaks build with x32: This is PR/102102 Also seen on x86_64-linux-gnu, when configuring with --with-multilib-list=m32,m64,mx32 Matthias
Re: [PATCH] analyzer: Recognize __builtin_free as a matching deallocator
On 7/28/21 1:44 PM, David Malcolm via Gcc-patches wrote: > On Wed, 2021-07-28 at 10:34 +0530, Siddhesh Poyarekar wrote: >> Recognize __builtin_free as being equivalent to free when passed into >> __attribute__((malloc ())), similar to how it is treated when it is >> encountered as a call. This fixes spurious warnings in glibc where >> xmalloc family of allocators as well as reallocarray, memalign, >> etc. are declared to have __builtin_free as the free function. >> >> gcc/analyzer/ChangeLog: >> * sm-malloc.cc >> (malloc_state_machine::get_or_create_deallocator): Recognize >> __builtin_free. >> >> gcc/testsuite/ChangeLog: >> * gcc.dg/analyzer/attr-malloc-1.c (compatible_alloc, >> compatible_alloc2): New extern allocator declarations. >> (test_9, test_10): New tests. > > Looks good to me, thanks > Dave > > Please could this be backported to all active branches?
Re: [patch] PR jit/87808: Allow libgccjit to work without an external gcc driver
On 7/13/21 8:41 AM, Richard Biener wrote: > On Mon, Jul 12, 2021 at 11:00 PM Matthias Klose wrote: >> >> On 3/26/19 12:52 PM, Matthias Klose wrote: >>> On 22.03.19 23:00, David Malcolm wrote: >>>> On Thu, 2019-03-21 at 12:26 +0100, Matthias Klose wrote: >>>>> Fix PR jit/87808, the embedded driver still needing the external gcc >>>>> driver to >>>>> find the gcc_lib_dir. This can happen in a packaging context when >>>>> libgccjit >>>>> doesn't depend on the gcc package, but just on binutils and libgcc- >>>>> dev packages. >>>>> libgccjit probably could use /proc/self/maps to find the gcc_lib_dir, >>>>> but that >>>>> doesn't seem to be very portable. >>>>> >>>>> Ok for the trunk and the branches? >>>>> >>>>> Matthias >>>> >>>> [CCing the jit list] >>>> >>>> I've been trying to reproduce this bug in a working copy, and failing. >>>> >>>> Matthias, do you have a recipe you've been using to reproduce this? >>> >>> the JIT debug log shows the driver names that it wants to call. Are you >>> sure >>> that this driver isn't available anywhere? I configure the gcc build with >>> --program-suffix=-8 --program-prefix=x86_64-linux-gnu-, and that one was >>> only >>> available in one place, /usr/bin. >>> >>> Matthias >> >> David, the bug report now has two more comments from people that the current >> behavior is broken. Please could you review the patch? > > I think libgccjit should use the same strathegy for finding the install > location > like the driver does itself. I couldn't readily decipher its magic but at > least > there's STANDARD_EXEC_PREFIX which seems to be used as possible > fallback. No, it's crtbeginS.o, and libgcc.* which are are not found in the STANDARD_EXEC_PREFIX. > In particular your patch doesn't seem to work with a DESTDIR= > install? it does. usually you build as configure && make && make install with a DESTDIR set for only the last step, which doesn't rebuild any object file. > Can we instead add a --with-gccjit-install-dir= or sth like that (whatever > path to whatever files the JIT exactly looks for)? that should be possible, moving the definition of FALLBACK_GCC_EXEC_PREFIX from the Makefile to a value specified by a configure value. Or is there already a macro, that doesn't get prefixed by DESTDIR? Matthias
Re: [patch] PR jit/87808: Allow libgccjit to work without an external gcc driver
On 3/26/19 12:52 PM, Matthias Klose wrote: > On 22.03.19 23:00, David Malcolm wrote: >> On Thu, 2019-03-21 at 12:26 +0100, Matthias Klose wrote: >>> Fix PR jit/87808, the embedded driver still needing the external gcc >>> driver to >>> find the gcc_lib_dir. This can happen in a packaging context when >>> libgccjit >>> doesn't depend on the gcc package, but just on binutils and libgcc- >>> dev packages. >>> libgccjit probably could use /proc/self/maps to find the gcc_lib_dir, >>> but that >>> doesn't seem to be very portable. >>> >>> Ok for the trunk and the branches? >>> >>> Matthias >> >> [CCing the jit list] >> >> I've been trying to reproduce this bug in a working copy, and failing. >> >> Matthias, do you have a recipe you've been using to reproduce this? > > the JIT debug log shows the driver names that it wants to call. Are you sure > that this driver isn't available anywhere? I configure the gcc build with > --program-suffix=-8 --program-prefix=x86_64-linux-gnu-, and that one was only > available in one place, /usr/bin. > > Matthias David, the bug report now has two more comments from people that the current behavior is broken. Please could you review the patch? Thanks, Matthias
Re: [PATCH] Modula-2 into the GCC tree on master
On 6/19/21 9:53 AM, Gaius Mulley wrote: > Matthias Klose writes: > >> x86_64-linux-gnu-g++-10 is the compiler used for the bootstrap. I haven't >> checked if that is also seen for a normal bootstrap. Apparently it tries to >> re-bootstrap the compiler. >> >> The build is configured with --with-build-config=bootstrap-lto-lean, built >> with >> make profiledbootstrap-lean > > many thanks for the patch - committed. I've also fixed the make install > bug (causing the re-bootstrap mentioned above), the build now fails already in stage1 with [...] gm2.a m2/mc-boot-ch/Glibc.o m2/mc-boot-ch/Gmcrts.o libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lm /usr/bin/x86_64-linux-gnu-ld: cannot find libcommon.a: No such file or directory collect2: error: ld returned 1 exit status Matthias
Re: [PATCH] Modula-2 into the GCC tree on master
On 6/18/21 12:26 AM, Gaius Mulley wrote: > > > Hello Richard, David, Matthias and GCC Steering Committee, > > here are a set of patches which merge the gm2 front end into the > GCC tree. The patches have been bootstrapped under aarch64 GNU/Linux > Debian Stretch using make -j 4, x86_64 GNU/Linux Debian Stretch built > using make -j 24 and also under x86_64 GNU/Linux Debian Buster using > make -j 4. > > Tested on Debian Stretch x86_64 > === > > built GCC bootstrap 3 times: > > 1. built vanilla GCC (enabling bootstrap) enabling front ends: > c,c++,go,d,fortran and ran the regression tests. (make -j 4). > > 2. the patches below were applied and associated tarball untarred. > The same front ends c,c++,go,d,fortran (again building from > bootstrap) were enabled (no m2) and ran the regression tests. > There were no changes to the regression test results between 1 and > 2. > > 3. Then it was rebuilt (from bootstrap) enabling the front ends > c,c++,go,d,fortran,m2 and ran the > regression tests and again no extra failures were seen. > > 4. It has been built in source tree (./configure --enable-languages=m2) > and out of source tree with make -j 24. > > Built on Debian Buster x86_64 > = > > 1. built vanilla GCC (enabling bootstrap) enabling front ends: > c,c++,go,d,fortran and ran the regression tests. > > 2. the patches below were applied and associated tarball untarred. > The same front ends c,c++,go,d,fortran (again building from > bootstrap) were enabled (no m2) and ran the regression tests. > There were no changes to the regression test results between 1 and > 2. > > 3. Then it was rebuilt (from bootstrap) enabling the front ends > c,c++,go,d,fortran,m2 and ran the > regression tests and again no extra failures were seen. > > Built a patched tree enabling bootstrap make -j 4 for front ends > c,c++,m2 all compiled and bootstrapped. I checked that with a profiled lto build. The build succeeds with the attached patch to respect the parallel linking limitations, which you can configure with --enable-link-serialization=N However the build fails in the installation step with: [...] Linking stage1/m2/cc1gm2 |>>>>>>>>>>>>>>>>--| 0% x86_64-linux-gnu-g++-10 -std=c++11 -no-pie -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-q ual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -Wc++-compat - fno-common -DHAVE_CONFIG_H -o stage1/m2/cc1gm2 m2/gm2-lang.o m2/stor-layout.o m2/m2pp.o m2/gm2-gcc/m2assert.o m2/gm2-gcc/m2block.o m2/gm2-gcc/m2builtins.o m2/gm2-gcc/m2except.o m2/gm2-gcc/m2convert.o m2/gm2-gcc/m2color.o m2/gm2-gcc/m2decl.o m2/gm2-gcc/m2expr.o m2/gm2-gcc/m2linemap.o m2/gm2-gcc/m2statement.o m2/gm2-gcc/m2type.o m2/gm2-gcc/m2tree.o m2/gm2-gcc/m2treelib.o m2/gm2-gcc/m2top.o m2/gm2-gcc/m2misc.o m2/gm2-gcc/init.o m2/gm2-compiler-boot/m2flex.o \ attribs.o \ m2/gm2-compiler-boot/gm2.a m2/gm2-libs-boot/libgm2.a m2/mc-boot-ch/Glibc.o m2/mc-boot-ch/Gmcrts.o m2/gm2-gcc/rtegraph.o \ libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lisl -lmpc -lmpfr -lgmp -rdynamic -ldl -lz -lzstd lto1: fatal error: bytecode stream in file 'm2/gm2-compiler-boot/m2flex.o' generated with LTO version 12.0 instead of the expected 9.2 compilation terminated. lto-wrapper: fatal error: x86_64-linux-gnu-g++-10 returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status Command exited with non-zero status 1 x86_64-linux-gnu-g++-10 is the compiler used for the bootstrap. I haven't checked if that is also seen for a normal bootstrap. Apparently it tries to re-bootstrap the compiler. The build is configured with --with-build-config=bootstrap-lto-lean, built with make profiledbootstrap-lean Matthias 2021-06-18 Matthias Klose * Make-lang.in (m2.serial): New target. (cc1gm2): Depend on $(m2.prev). (stageN/m2/cc1gm2): Call LLINKER, also call LINK_PROGRESS. --- a/gcc/m2/Make-lang.in +++ b/gcc/m2/Make-lang.in @@ -82,6 +82,7 @@ TEXISRC = $(objdir)/m2/images/gnu.eps \ # Define the names for selecting GNU Modula-2 in LANGUAGES. m2 modula-2 modula2: gm2$(exeext) xgcc$(exeext) cc1gm2$(exeext) \ $(GCC_TOOLS_FOR_GM2) +m2.serial = cc1gm2$(exeext) # Tell GNU make to ignore these if they exist. .PHONY: m2 modula-2 modula2 @@ -530,7 +531,7 @@ GM2_LIBS_PARANOID = m2/gm2-compiler-para
Re: [PATCH] Modula-2 into the GCC tree on master
On 1/18/21 2:55 PM, Gaius Mulley via Gcc-patches wrote: > Richard Biener writes: >> I've just done ./configure --enable-languages=m2; make -j24 >> >> I would suggest to not rush this in now during stage4 >> but instead take the opportunity of this "quiet" phase >> to prepare an integration branch with all the issues above >> sorted out which we can merge at the beginning of stage1 >> for GCC 12 (or later during stage4 if everyone is happy >> and/or backport for GCC 11.2 when it landed in trunk). > > ok sure - this sounds a good plan Gaius, now with the 1.1 relase out of the door, please could you clarify about your plans getting this into trunk, and do you plan to get this into 11.2 as well? Thanks, Matthias
Re: [Patch] offload-defaulted: Config option to silently ignore uninstalled offload compilers
On 4/28/21 6:56 PM, Tobias Burnus wrote: > On 28.04.21 16:13, Matthias Klose wrote: > >> On 4/27/21 12:22 PM, Tobias Burnus wrote: >>> Hence, the distro behaviour is only active when configured with >>> --enable-offload-defaulted. >> please document that option in gcc/doc/install.texi. > > Like attached? Or do you have some other wording suggestions? looks fine.
Re: [Patch] offload-defaulted: Config option to silently ignore uninstalled offload compilers
On 4/27/21 12:22 PM, Tobias Burnus wrote: > This is based on Jakub's patch* which is used with many distributions – and > is has > to be maintained by all of them; otherwise issues like lp #1878760 might > creep in, > as discussed in #gcc yesterday. - As I am a huge fan of reducing code > duplication > and local patches, I propose to add it to GCC proper behind a configure flag. > > The patch idea is: offloading support is configured for one or multiple > offload > devices > but compilation silently ignores a target if its offload compiler is not > found at > compile time and also dlopen errors of the associated libgomp plugin is also > silently ignored such that also the system where the program is run do not > show > a run-time error. > > This makes a lot of sense for distribution compilers – as it permits to > configure > GCC to support offloading to one/multiple offload targets, but the actual > offload compiler and the run-time support can be put into separate, optional > packages. > > (When -foffload=$TARGET is specified explicitly, it still gives > an error if the offload compiler is not installed; this does not not affect > the > libgomp/run-time side.) > > However, for nondistro builds, compilers are usually installed "as is" and not > split into different packages – thus, compilation or run-time issues should > give > an error. > > Hence, the distro behaviour is only active when configured with > --enable-offload-defaulted. > > Comments? OK for mainline? please document that option in gcc/doc/install.texi. Matthias
mention x86-64-vX micro-architecture levels in the release notes
Just saw, these are not mentioned on the release notes. Ok to document these? Matthias --- a/htdocs/gcc-11/changes.html +++ b/htdocs/gcc-11/changes.html @@ -690,6 +690,10 @@ You may also want to check out our GCC now supports AMD CPUs based on the znver3 core via -march=znver3. + GCC now supports micro-architecture levels defined in the x86-64 psABI +via -march=x86-64-v2, -march=x86-64-v3 and +-march=x86-64-v4. +
Re: [PATCH] PR target/97250: i386: Add support for x86-64-v2, x86-64-v3, x86-64-v4 levels for x86-64
On 9/30/20 2:27 PM, Florian Weimer wrote:
> These micro-architecture levels are defined in the x86-64 psABI:
>
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9
>
> PTA_NO_TUNE is introduced so that the new processor alias table entries
> do not affect the CPU tuning setting in ix86_tune.
>
> The tests depend on the macros added in commit 92e652d8c21bd7e66cbb0f900
> ("i386: Define __LAHF_SAHF__ and __MOVBE__ macros, based on ISA flags").
I would like to see this series backported to the gcc-10 branch (already doing
that for distro builds). With the backport for PR target/95842 from March 30,
these can now be backported without changes: That consists of:
i386: Define __LAHF_SAHF__ and __MOVBE__ macros, based on ISA flags
commit 92e652d8c21bd7e66cbb0f9001542a2f55345af0
Add support for x86-64-v2, x86-64-v3, x86-64-v4 levels for x86-64
commit 324bec558e95584e8c1997575ae9d75978af59f1
Add support for x86-64-v2, x86-64-v3, x86-64-v4 levels for x86-64
commit 16664e6e4fb4281be6477c13989740d44c963c77
Add support for x86-64-v2, x86-64-v3, x86-64-v4 levels for x86-64
commit 552ed3ea761324bdd42c1a40d4bbef91432da29a
i386: Make -march=x86-64-v[234] behave more like other -march= options
commit 59482fa1e7243bd905c7e27c92ae2b89c79fff87
and
Fix up plugin header install
9a83366b62e585cce5577309013a832f895ccdbf
the latter one needed anyway on the gcc-10 branch.
I know, it's late, but the PR target/95842 backport only happened two days ago.
Matthias
[patch] fix installation of jit headers, usage of $(mkinstalldirs)
The installation of the jit headers can fail, because the directory might not be created yet, a missing dependency on the installdirs target. Also the Makefile hardcodes mkdir -p, instead of using $(mkinstalldirs). Ok for the trunk and the branches? Matthias diff --git a/gcc/jit/Make-lang.in b/gcc/jit/Make-lang.in index f9b0df850bd..663772aba63 100644 --- a/gcc/jit/Make-lang.in +++ b/gcc/jit/Make-lang.in @@ -249,7 +249,7 @@ jit.texinfo.install-pdf: doc/libgccjit.pdf SPHINX_BUILD_DIR=jit/sphinx-build jit.sphinx.html: - mkdir -p $(SPHINX_BUILD_DIR) + $(mkinstalldirs) $(SPHINX_BUILD_DIR) (cd $(srcdir)/jit/docs && \ make html BUILDDIR=$(PWD)/$(SPHINX_BUILD_DIR) ) @@ -270,7 +270,7 @@ jit.sphinx.install-html: jit.sphinx.html # see https://bugzilla.redhat.com/show_bug.cgi?id=1148845 ) jit.sphinx.pdf: $(SPHINX_BUILD_DIR)/latex/libgccjit.pdf $(SPHINX_BUILD_DIR)/latex/libgccjit.pdf: - mkdir -p $(SPHINX_BUILD_DIR) + $(mkinstalldirs) $(SPHINX_BUILD_DIR) (cd $(srcdir)/jit/docs && \ make latexpdf BUILDDIR=$(PWD)/$(SPHINX_BUILD_DIR) ) @@ -305,7 +305,7 @@ selftest-jit: # # Install hooks: -jit.install-headers: +jit.install-headers: installdirs $(INSTALL_DATA) $(srcdir)/jit/libgccjit.h \ $(DESTDIR)$(includedir)/libgccjit.h $(INSTALL_DATA) $(srcdir)/jit/libgccjit++.h \
Re: [Ada] Fix PR ada/99264
Jakub reported that for glibc 2.34 (trunk, unreleased), Richard said it was working for glibc 2.33 (latest release), your commit says "Fix build breakage with latest glibc release" (which is 2.33). What is correct? The change also caused CI test failures in Debian and Ubuntu as seen at https://ci.debian.net/data/autopkgtest/unstable/amd64/a/ahven/10908933/log.gz fail libgnat-10 10.2.1-21 (experimental) https://ci.debian.net/data/autopkgtest/unstable/amd64/a/ahven/10908997/log.gz pass libgnat-10 10.2.1-6 (unstable) Citing Nicolas, """ The symptom "/usr/lib/x86_64-linux-gnu/ada/adalib/ahven/ahven-framework.ali" is obsolete and read-only looks exactly like the scenario described by the Debian Ada Policy. https://people.debian.org/~lbrenta/debian-ada-policy.html Example with a simple dependency chain: libahven depends on libgnat ahven-tests depend on libahven libahven contains, in ahven-framework.ali, a checksum of each source it depends upon, including some libgnat sources. When libgnat changes, libahven must be rebuilt before ahven-tests. Else… The error above is reported when building ahven-tests. It mentions ahven-framework.ali from the libahven-dev package. It actually originates in a change in libgnat. The Debian Ada policy requires that such dependencies are encoded in -dev package names so that dpkg later automatically prevents inconsistent sets of .ali files and related cryptic messages. In the special case of libgnat, built by GCC, there is only one libgnatMAJOR package, containing the files usually expected in libgnatSO and libgnatALI-dev. The sources are not expected to change for a given MAJOR inside unstable. """ Assuming that the change is only required for glibc trunk (2.34), I'll revert that for Debian's package builds for the gcc branches. I'll see what to do if I still need gnat-10 when glibc 2.34 is in use. Otoh, the patch could be conditional on the glibc version detected. Matthias On 3/5/21 12:45 PM, Eric Botcazou wrote: > This fixes the build breakage introduced by the latest glibc release. > > Tested on x86-64/Linux, applied on mainline, 10 and 9 branches. > > > 2021-03-05 Eric Botcazou > > PR ada/99264 > * init.c (__gnat_alternate_sta) [Linux]: Remove preprocessor test on > MINSIGSTKSZ and bump size to 32KB. > * libgnarl/s-osinte__linux.ads (Alternate_Stack_Size): Bump to 32KB. >
[patch] substitute @tie{} with a space for the man pages
The gcc man page currently has untranslated @tie{} patterns in the man page.
Just replace these with a white space. Ok for the trunk and branches?
Matthias
--- a/contrib/texi2pod.pl
+++ b/contrib/texi2pod.pl
@@ -210,6 +210,7 @@ while(<$inf>) {
s/\@TeX\{\}/TeX/g;
s/\@pounds\{\}/\#/g;
s/\@minus(?:\{\})?/-/g;
+s/\@tie\{\}/ /g;
s/\\,/,/g;
# Now the ones that have to be replaced by special escapes
Re: [PATCH] RISC-V: Implment __builtin_thread_pointer
On 7/8/20 9:59 PM, Jim Wilson wrote: > On Tue, Jul 7, 2020 at 2:52 AM Kito Cheng wrote: >> gcc/ChangeLog: >> * gcc/config/riscv/riscv.md (): New. >> (TP_REGNUM): Ditto. >> * doc/extend.texi (Target Builtins): Add RISC-V built-in section. >> Document __builtin_thread_pointer. >> gcc/testsuite/ChangeLog: >> * gcc.target/riscv/read-thread-pointer.c: New. > > It looks OK to me in general. > > You added builtin_thread_pointer but not builtin_set_thread_pointer. > Maybe we should implement both as long as we are implementing one? If > clang only implements one, maybe it should implement the other also? > This doesn't have to be part of this patch. This could be a separate > issue. > > The builtin_thread_pointer docs looks out-of-date. It is documented > for alpha and SH, but it is implemented in gcc/builtins.c not in the > backends. A scan of md files show that quite a few targets support it > but don't document it. I think it should be documented in the generic > builtins section not in the target dependent builtins sections with > some language that says not all targets support it. This doesn't have > to be part of this patch. This could be a separate issue. > > We have two existing undocumented builtins. __builtin_riscv_fsflags > and __builtin_riscv_frflags for setting or reading the FP flags. I > don't know if anyone uses them though. newlib and glbic both use > extended asms for these operations. This doesn't have to be part of > this patch. This could be a separate issue. > > There is a document https://github.com/riscv/riscv-c-api-doc for > coordinating gcc and llvm work that has an empty list of builtin > functions. I'm not sure if this document is still useful. If this is > a RISC-V specific builtin then it should be listed here, but I don't > think it should be considered a RISC-V specific builtin. There is an > unresolved pull request for the frflags and fsflags builtins. I guess > I forgot about that. > > Jim LLVM 12 now uses __builtin_thread_pointer, and fails to build with GCC 10 (but builds with GCC 11). Could you consider backporting this one to GCC 10? Thanks, Matthias
[patch] Revert: "Don't build insn-extract.o with rtl checking"
Revert: "Don't build insn-extract.o with rtl checking". PR target/98746 is now fixed, compilation is now below 100MB from 8GB. Approved on irc by Richard Biener. Matthias --- a/gcc/genextract.c +++ b/gcc/genextract.c @@ -365,8 +365,6 @@ print_header (void) #define IN_TARGET_CODE 1\n\ #include \"config.h\"\n\ #include \"system.h\"\n\ -#undef ENABLE_RTL_CHECKING\n\ -#undef ENABLE_RTL_FLAG_CHECKING\n\ #include \"coretypes.h\"\n\ #include \"tm.h\"\n\ #include \"rtl.h\"\n\
Re: [PATCH] Modula-2 into the GCC tree on master
On 1/18/21 2:09 AM, Gaius Mulley via Gcc-patches wrote:
> gcc/
>
> * gcc/brig/brigspec.c (lang_register_spec_functions): Added.
> * gcc/c-family/cppspec.c (lang_register_spec_functions): Added.
> * gcc/c/gccspec.c (lang_register_spec_functions): Added.
> * gcc/cp/g++spec.c (lang_register_spec_functions): Added.
> * gcc/d/d-spec.cc (lang_register_spec_functions): Added.
> * gcc/fortran/gfortranspec.c(lang_register_spec_functions): Added.
> * gcc/gcc.c (allow_linker): Global variable to disable
> linker by the front end. (xputenv) available externally.
> (xgetenv) New function. (save_switch) available externally.
> (fe_add_linker_option) New function. (handle_OPT_B) New function.
> (fe_add_infile) New function. (fe_mark_compiled) New function.
> (driver_handle_option) call handle_OPT_B. (print_option) New
> function. (print_options) New function. (dbg_options) New function.
> (fe_add_spec_function) New function. (lookup_spec_function)
> checks front end registered functions.
> (driver::set_up_specs): call lang_register_spec_functions.
> (maybe_run_linker): Check allow_linker before running the linker.
> * gcc/gcc.h (fe_save_switch): Prototype.
> (handle_OPT_B) Prototype. (fe_add_infile) Prototype.
> (fe_add_linker_option) Prototype. (fe_add_spec_function) Prototype.
> (xputenv) Prototype. (xgetenv) Prototype. (print_options) Prototype.
> (print_option) Prototype. (dbg_options) Prototype.
> (lang_register_spec_functions) Prototype.
> (allow_linker): Extern.
> * gcc/go/gospec.c (lang_register_spec_functions): Added.
this is mising the definition of lang_register_spec_functions for the jit build.
2020-03-23 Matthias Klose
* jit-spec.c (lang_register_spec_functions): New, not used for jit.
--- a/gcc/jit/jit-spec.c
+++ b/gcc/jit/jit-spec.c
@@ -39,3 +39,9 @@ lang_specific_pre_link (void)
/* Number of extra output files that lang_specific_pre_link may generate. */
int lang_specific_extra_outfiles = 0; /* Not used for jit. */
+
+/* lang_register_spec_functions. Not used for jit. */
+void
+lang_register_spec_functions (void)
+{
+}
Re: [PATCH] x86: Error on -fcf-protection with incompatible target
On 1/14/21 4:18 PM, H.J. Lu via Gcc-patches wrote:
> On Thu, Jan 14, 2021 at 6:51 AM Uros Bizjak wrote:
>>
>> On Thu, Jan 14, 2021 at 3:05 PM H.J. Lu wrote:
>>>
>>> -fcf-protection with CF_BRANCH inserts ENDBR32 at function entries.
>>> ENDBR32 is NOP only on 64-bit processors and 32-bit TARGET_CMOVE
>>> processors. Issue an error for -fcf-protection with CF_BRANCH when
>>> compiling for 32-bit non-TARGET_CMOVE targets.
>>>
>>> gcc/
>>>
>>> PR target/98667
>>> * config/i386/i386-options.c (ix86_option_override_internal):
>>> Issue an error for -fcf-protection with CF_BRANCH when compiling
>>> for 32-bit non-TARGET_CMOVE targets.
>>>
>>> gcc/testsuite/
>>>
>>> PR target/98667
>>> * gcc.target/i386/pr98667-1.c: New file.
>>> * gcc.target/i386/pr98667-2.c: Likewise.
>>> * gcc.target/i386/pr98667-3.c: Likewise.
>>> ---
>>> gcc/config/i386/i386-options.c| 9 -
>>> gcc/testsuite/gcc.target/i386/pr98667-1.c | 9 +
>>> gcc/testsuite/gcc.target/i386/pr98667-2.c | 9 +
>>> gcc/testsuite/gcc.target/i386/pr98667-3.c | 7 +++
>>> 4 files changed, 33 insertions(+), 1 deletion(-)
>>> create mode 100644 gcc/testsuite/gcc.target/i386/pr98667-1.c
>>> create mode 100644 gcc/testsuite/gcc.target/i386/pr98667-2.c
>>> create mode 100644 gcc/testsuite/gcc.target/i386/pr98667-3.c
>>>
>>> diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
>>> index 4e0165ff32c..1489871b36f 100644
>>> --- a/gcc/config/i386/i386-options.c
>>> +++ b/gcc/config/i386/i386-options.c
>>> @@ -3016,8 +3016,15 @@ ix86_option_override_internal (bool main_args_p,
>>> }
>>>
>>>if (opts->x_flag_cf_protection != CF_NONE)
>>> -opts->x_flag_cf_protection
>>> +{
>>> + if ((opts->x_flag_cf_protection & CF_BRANCH) == CF_BRANCH
>>> + && !TARGET_64BIT
>>> + && !TARGET_CMOVE)
>>
>> You need TARGET_CMOV (note, no E) here. Also, please put both tests on one
>> line.
>>
>> LGTM with the above change.
>
> This is the patch I am checking in.
I might be doing something wrong, but this breaks the -m32 multilib build for
me. looking at a trunk 20210110 build, -fcf-protection -mshstk are passed to the
-m32 build as well, and now errors out.
Matthias
Re: [patch] fix -Wformat-diag warnings in rs6000-call.c
On 1/10/21 10:18 PM, Martin Sebor wrote:
> On 1/10/21 3:29 AM, Matthias Klose wrote:
>> is the newline intended? It's followed by a debug_rtx call.
>
> To avoid the warning there shouldn't be any trailing punctuation
> or whitespace in the message. The GCC quoting directives should
> be preferred over the literal characters (as per GCC Coding
> Conventions). %qc and %qs are preferable to %<%c%>.
>
> Symbols/identifiers should be formatted using the appropriate
> directives or quoted in %< %>. Underscores in words like
> emit_insn are taken as indicators that the word is an identifier
> and to trigger warnings.
is this?
https://gcc.gnu.org/codingconventions.html#Diagnostics
I think that's a bit terse, and grepping sources for %< shows many more
occurences than %qX.
>> ../../src/gcc/rtl.c:860:42: warning: unquoted sequence of 2 consecutive
>> punctuation characters '',' in format [-Wformat-diag]
>> 860 | ("RTL check: expected elt %d type '%c', have '%c' (rtx %s) in
>> %s, at
>> %s:%d",
>>
>> `%c', or some %q quoting?
>
> The purpose of the -Wformat-diag warnings is to improve the consistency
> of user-visible messages and make them easier to translate. There was
> a discussion some time back about whether internal errors should fall
> into this category. I'm not sure if it reached a conclusion one way
> or the other but in similar situations elsewhere in GCC we have
> suppressed the warning via #pragma GCC diagnostic. If it takes too
> much effort to clean them up it might make sense to do the same here
> (the downside is that it doesn't help translators). Otherwise,
> the messages are not really phrased in a way that's comprehensible
> either to users or to tranlators (acronyms like elt or rtx aren't universally
> understood).
[...]
>> again, `' quotes, or some %q option?
>>
>
> The latter: %qs with an argument is best in general (it can reduce
> translation effort between repeated messages parameterized on
> the quoted string).
if the URL above is the correct place for the conventions, then maybe make it
more explicit there about the preferred choice.
Matthias
Re: --enable-link-serialization=1 doesn't work
On 1/9/21 7:52 PM, Matthias Klose wrote: > The attached patch makes the link targets a little bit more verbose. Ok to > commit? approved by Jakub on IRC, checked in. > It shows that --enable-link-serialization=1 doesn't work: > > $ grep ^Linking ../log > Linking gnat1 |==-- | 9% > Linking cc1 |--| 0% > Linking cc1 |==| 9% > Linking gnat1 | | 18% > Linking brig1 |--| 18% > Linking brig1 |==| 27% > Linking cc1plus |==-- | 27% > Linking cc1plus | | 36% > Linking d21 |--| 36% > Linking d21 |==| 45% > Linking f951 |==-- | 45% > Linking f951 | | 54% > Linking go1 |--| 54% > Linking go1 |==| 63% > Linking lto1 |==-- | 63% > Linking lto1 | | 72% > Linking lto-dump |--| 72% > Linking lto-dump |==| 81% > Linking cc1obj |==-- | 81% > Linking cc1obj | | 90% > Linking cc1objplus |--| 90% > Linking cc1objplus |==| 100% > > At least the gnat1 link is started before the cc1 link finishes. Jakub has a patch pending for that. Thanks for debugging. Matthias
Re: [patch] fix -Wformat-diag warnings in rs6000-call.c
On 1/9/21 11:22 PM, Jakub Jelinek wrote:
> On Sat, Jan 09, 2021 at 07:44:31PM +0100, Matthias Klose wrote:
>> These warnings, including the suggested fixes are seen on power*-linux
>> builds.
>>
>> warning: misspelled term 'builtin function' in format; use 'bult-in function'
>
> Are you sure it printed bult-in ?
>
>> fatal_error (input_location,
>> - "internal error: builtin function %qs already processed",
>> + "internal error: builtin-function %qs already processed",
>
> It meant built-in function instead of builtin-function I'm pretty sure.
>
>> name);
>>
>>rs6000_builtin_decls[(int)code] = t =
>> @@ -11219,7 +11219,7 @@ altivec_expand_builtin (tree exp, rtx target, bool
>> *expandedp)
>> {
>>size_t uns_fcode = (size_t) fcode;
>>const char *name = rs6000_builtin_info[uns_fcode].name;
>> - error ("Second argument of %qs must be in the range [0, 3].", name);
>> + error ("Second argument of %qs must be in the range [0, 3]", name);
>
> Diagnostics shouldn't start with capital letter either, so it should be
> "second ..."
>> - "internal error: builtin function %qs had an unexpected "
>> + "internal error: builtin-function %qs had an unexpected "
>> "return type %qs", name, GET_MODE_NAME (h.mode[0]));
>> - "internal error: builtin function %qs, argument %d "
>> + "internal error: builtin-function %qs, argument %d "
>
> See above.
ahh, my bad. verschlimmbessert ...
fixed version attached. While looking at all -Wformat-diag warnings ...
../../src/gcc/emit-rtl.c: In function 'rtx_insn* make_insn_raw(rtx)':
../../src/gcc/emit-rtl.c:4038:25: warning: unquoted identifier or keyword
'emit_insn' in format [-Wformat-diag]
4038 | warning (0, "ICE: emit_insn used where emit_jump_insn needed:\n");
| ^
../../src/gcc/emit-rtl.c:4038:46: warning: unquoted identifier or keyword
'emit_jump_insn' in format [-Wformat-diag]
4038 | warning (0, "ICE: emit_insn used where emit_jump_insn needed:\n");
| ^~
../../src/gcc/emit-rtl.c:4038:68: warning: unquoted whitespace character '\x0a'
in format [-Wformat-diag]
4038 | warning (0, "ICE: emit_insn used where emit_jump_insn needed:\n");
|
genautomata has `%s' hardcoded, while other places have %q+F. What is the
preferred way?
is the newline intended? It's followed by a debug_rtx call.
../../src/gcc/rtl.c:860:42: warning: unquoted sequence of 2 consecutive
punctuation characters '',' in format [-Wformat-diag]
860 | ("RTL check: expected elt %d type '%c', have '%c' (rtx %s) in %s, at
%s:%d",
`%c', or some %q quoting?
../../src/gcc/config/rs6000/rs6000.c: In function 'void rs6000_emit_move(rtx,
rtx, machine_mode)':
../../src/gcc/config/rs6000/rs6000.c:10330:16: warning: contraction 'can't' in
format; use 'cannot' instead [-Wformat-diag]
10330 | error ("%qs is an opaque type, and you can't set it to other
values.",
|
^~
../../src/gcc/config/rs6000/rs6000.c:10330:16: warning: spurious trailing
punctuation sequence '.' in format [-Wformat-diag]
../../src/gcc/config/rs6000/rs6000.c: In function 'tree_node*
rs6000_handle_altivec_attribute(tree_node**, tree, tree, int, bool*)':
../../src/gcc/config/rs6000/rs6000.c:19811:12: warning: misspelled term
'floating point' in format; use 'floating-point' instead [-Wformat-diag]
19811 | error ("use of decimal floating point types in AltiVec types is
invalid");
|
^
../../src/gcc/config/rs6000/rs6000.c: In function 'tree_node*
rs6000_get_function_versions_dispatcher(void*)':
../../src/gcc/config/rs6000/rs6000.c:24597:17: warning: unquoted keyword 'ifunc'
in format [-Wformat-diag]
24597 | "multiversioning needs ifunc which is not supported "
| ^
24598 | "on this target");
again, `' quotes, or some %q option?
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 2308cc8b4a2..18e85ee6f9c 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -8741,7 +8741,7 @@ def_builtin (const char *name, tree type, enum rs6000_builtins code)
if (rs6000_builtin_decls[(int)code])
fatal_error (input_location,
- "internal error: builtin function %qs already processed",
+ "internal
--enable-link-serialization=1 doesn't work
The attached patch makes the link targets a little bit more verbose. Ok to
commit?
It shows that --enable-link-serialization=1 doesn't work:
$ grep ^Linking ../log
Linking gnat1 |==-- | 9%
Linking cc1 |--| 0%
Linking cc1 |==| 9%
Linking gnat1 | | 18%
Linking brig1 |--| 18%
Linking brig1 |==| 27%
Linking cc1plus |==-- | 27%
Linking cc1plus | | 36%
Linking d21 |--| 36%
Linking d21 |==| 45%
Linking f951 |==-- | 45%
Linking f951 | | 54%
Linking go1 |--| 54%
Linking go1 |==| 63%
Linking lto1 |==-- | 63%
Linking lto1 | | 72%
Linking lto-dump |--| 72%
Linking lto-dump |==| 81%
Linking cc1obj |==-- | 81%
Linking cc1obj | | 90%
Linking cc1objplus |--| 90%
Linking cc1objplus |==| 100%
At least the gnat1 link is started before the cc1 link finishes.
Matthias
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1793,7 +1793,7 @@ DO_LINK_SERIALIZATION = @DO_LINK_SERIALIZATION@
ifeq ($(DO_LINK_SERIALIZATION),)
LINK_PROGRESS = :
else
-LINK_PROGRESS = msg="Linking |"; cnt=0; if test "$(2)" = start; then \
+LINK_PROGRESS = msg="Linking $@ |"; cnt=0; if test "$(2)" = start; then \
idx=0; cnt2=$(DO_LINK_SERIALIZATION); \
while test $$cnt2 -le $(1); do msg="$${msg}=="; cnt2=`expr $$cnt2 + 1`; idx=`expr $$idx + 1`; done; \
cnt=$$idx; \
[patch] fix -Wformat-diag warnings in rs6000-call.c
These warnings, including the suggested fixes are seen on power*-linux builds.
warning: misspelled term 'builtin function' in format; use 'bult-in function'
instead [-Wformat-diag]
warning: spurious trailing punctuation sequence '].' in format [-Wformat-diag]
warning: misspelled term 'floating point' in format; use 'floating-point'
instead [-Wformat-diag]
Ok to fix these?
Matthias
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 2308cc8b4a2..3988dd81481 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -8741,7 +8741,7 @@ def_builtin (const char *name, tree type, enum rs6000_builtins code)
if (rs6000_builtin_decls[(int)code])
fatal_error (input_location,
- "internal error: builtin function %qs already processed",
+ "internal error: builtin-function %qs already processed",
name);
rs6000_builtin_decls[(int)code] = t =
@@ -11219,7 +11219,7 @@ altivec_expand_builtin (tree exp, rtx target, bool *expandedp)
{
size_t uns_fcode = (size_t) fcode;
const char *name = rs6000_builtin_info[uns_fcode].name;
- error ("Second argument of %qs must be in the range [0, 3].", name);
+ error ("Second argument of %qs must be in the range [0, 3]", name);
return expand_call (exp, target, false);
}
break;
@@ -11479,7 +11479,7 @@ rs6000_invalid_builtin (enum rs6000_builtins fncode)
else if ((fnmask & RS6000_BTM_HARD_FLOAT) != 0)
error ("%qs requires the %qs option", name, "-mhard-float");
else if ((fnmask & RS6000_BTM_FLOAT128_HW) != 0)
-error ("%qs requires ISA 3.0 IEEE 128-bit floating point", name);
+error ("%qs requires ISA 3.0 IEEE 128-bit floating-point", name);
else if ((fnmask & RS6000_BTM_FLOAT128) != 0)
error ("%qs requires the %qs option", name, "%<-mfloat128%>");
else if ((fnmask & (RS6000_BTM_POPCNTD | RS6000_BTM_POWERPC64))
@@ -14582,7 +14582,7 @@ builtin_function_type (machine_mode mode_ret, machine_mode mode_arg0,
if (!ret_type)
fatal_error (input_location,
- "internal error: builtin function %qs had an unexpected "
+ "internal error: builtin-function %qs had an unexpected "
"return type %qs", name, GET_MODE_NAME (h.mode[0]));
for (i = 0; i < (int) ARRAY_SIZE (arg_type); i++)
@@ -14604,7 +14604,7 @@ builtin_function_type (machine_mode mode_ret, machine_mode mode_arg0,
if (!arg_type[i])
fatal_error (input_location,
- "internal error: builtin function %qs, argument %d "
+ "internal error: builtin-function %qs, argument %d "
"had unexpected argument type %qs", name, i,
GET_MODE_NAME (m));
}
Re: libgo patch committed: Update to Go1.16beta1 release
On 1/2/21 12:11 AM, Ian Lance Taylor wrote:
> On Thu, Dec 31, 2020 at 7:40 AM Matthias Klose wrote:
>>
>> On 12/31/20 12:14 AM, Ian Lance Taylor via Gcc-patches wrote:
>>> I've committed a patch to update libgo to the Go 1.16beta1 release.
>>>
>>> This patch does not include support for the new //go:embed directive
>>> that will be available in Go 1.16.1 (https://golang.org/issue/41191)
>>> Support for that requires compiler changes, which will come later.
>>>
>>> As usual with these big updates, I have not included the complete
>>> changes in this e-mail message, only changes that are gccgo-specific.
>>>
>>> Testing this requires some changes to gotools.
>>>
>>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
>>> to mainline.
>>
>> also breaks the s390x 32bit multilib build (s390).
>>
>> ../../../../src/libgo/go/internal/cpu/cpu.go:123:9: error: reference to
>> undefined name 'doinit'
>> 123 | doinit()
>> | ^
>
> The problems building the internal/cpu and golang.org/x/sys/cpu
> packages on less common architectures should be fixed by this patch.
> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
> to mainline.
still ftbfs on power*, tested with a multilib build on powerpc64-linux-gnu.
patch attached, didn't check on aix.
../../../src/libgo/go/internal/cpu/cpu.go:123:9: error: reference to undefined
name 'doinit'
123 | doinit()
| ^
../../../src/libgo/go/internal/cpu/cpu_ppc64x_linux.go:26:26: error: reference
to undefined name 'isSet'
26 | PPC64.IsPOWER9 = isSet(HWCap2, hwcap2_ARCH_3_00)
| ^
../../../src/libgo/go/internal/cpu/cpu_ppc64x_linux.go:27:25: error: reference
to undefined name 'isSet'
27 | PPC64.HasDARN = isSet(HWCap2, hwcap2_DARN)
| ^
../../../src/libgo/go/internal/cpu/cpu_ppc64x_linux.go:28:24: error: reference
to undefined name 'isSet'
28 | PPC64.HasSCV = isSet(HWCap2, hwcap2_SCV)
|^
Matthias
--- a/libgo/go/internal/cpu/cpu_ppc64x_aix.go
+++ b/libgo/go/internal/cpu/cpu_ppc64x_aix.go
@@ -12,10 +12,14 @@ const (
_IMPL_POWER9 = 0x2
)
-func osinit() {
+func doinit() {
impl := getsystemcfg(_SC_IMPL)
PPC64.IsPOWER9 = isSet(impl, _IMPL_POWER9)
}
+func isSet(hwc uint, value uint) bool {
+return hwc != 0
+}
+
// getsystemcfg is defined in runtime/os2_aix.go
func getsystemcfg(label uint) uint
--- a/libgo/go/internal/cpu/cpu_ppc64x_linux.go
+++ b/libgo/go/internal/cpu/cpu_ppc64x_linux.go
@@ -22,8 +22,12 @@ const (
hwcap2_SCV = 0x0010
)
-func osinit() {
+func doinit() {
PPC64.IsPOWER9 = isSet(HWCap2, hwcap2_ARCH_3_00)
PPC64.HasDARN = isSet(HWCap2, hwcap2_DARN)
PPC64.HasSCV = isSet(HWCap2, hwcap2_SCV)
}
+
+func isSet(hwc uint, value uint) bool {
+return hwc != 0
+}
Re: libgo patch committed: Update to Go1.16beta1 release
On 12/31/20 12:14 AM, Ian Lance Taylor via Gcc-patches wrote: > I've committed a patch to update libgo to the Go 1.16beta1 release. > > This patch does not include support for the new //go:embed directive > that will be available in Go 1.16.1 (https://golang.org/issue/41191) > Support for that requires compiler changes, which will come later. > > As usual with these big updates, I have not included the complete > changes in this e-mail message, only changes that are gccgo-specific. > > Testing this requires some changes to gotools. > > Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed > to mainline. ../../../src/libgo/go/internal/cpu/cpu.go:123:9: error: reference to undefined name 'doinit' 123 | doinit() | ^ also on sparc64, and most likely on the 32bit multilib. Until now I didn't find any build which is surviving this patch. Let's hope that 2021 gets a better ... Matthias
Re: libgo patch committed: Update to Go1.16beta1 release
On 12/31/20 12:14 AM, Ian Lance Taylor via Gcc-patches wrote: > I've committed a patch to update libgo to the Go 1.16beta1 release. > > This patch does not include support for the new //go:embed directive > that will be available in Go 1.16.1 (https://golang.org/issue/41191) > Support for that requires compiler changes, which will come later. > > As usual with these big updates, I have not included the complete > changes in this e-mail message, only changes that are gccgo-specific. > > Testing this requires some changes to gotools. > > Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed > to mainline. also breaks the s390x 32bit multilib build (s390). ../../../../src/libgo/go/internal/cpu/cpu.go:123:9: error: reference to undefined name 'doinit' 123 | doinit() | ^
Re: libgo patch committed: Update to Go1.16beta1 release
On 12/31/20 11:36 AM, Matthias Klose wrote:
> On 12/31/20 11:12 AM, Andreas Schwab wrote:
>> I'm getting this error in ia64:
>>
>> ../../../libgo/go/internal/cpu/cpu.go:123:9: error: reference to undefined
>> name 'doinit'
>> 123 | doinit()
>> | ^
>> make[4]: *** [internal/cpu.lo] Error 1
>>
>> Andreas.
>>
>
> also on x32, or with the x32 multilib target.
fixed for x32 with the attached patch
Matthias
--- a/libgo/go/internal/cpu/cpu_no_name.go
+++ b/libgo/go/internal/cpu/cpu_no_name.go
@@ -4,6 +4,7 @@
// +build !386
// +build !amd64
+// +build !amd64p32
package cpu
--- a/libgo/go/internal/cpu/cpu_x86.go
+++ b/libgo/go/internal/cpu/cpu_x86.go
@@ -2,7 +2,7 @@
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
-// +build 386 amd64
+// +build 386 amd64 amd64p32
package cpu
@@ -56,7 +56,7 @@ func doinit() {
{Name: "ssse3", Feature: },
// These capabilities should always be enabled on amd64:
- {Name: "sse2", Feature: , Required: GOARCH == "amd64"},
+ {Name: "sse2", Feature: , Required: GOARCH == "amd64" || GOARCH == "amd64p32"},
}
maxID, _, _, _ := cpuid(0, 0)
--- /dev/null
+++ b/libgo/go/internal/cpu/cpu_amd64p32.go
@@ -0,0 +1,7 @@
+// Copyright 2020 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+package cpu
+
+const GOARCH = "amd64p32"
Re: libgo patch committed: Update to Go1.16beta1 release
On 12/31/20 11:12 AM, Andreas Schwab wrote: > I'm getting this error in ia64: > > ../../../libgo/go/internal/cpu/cpu.go:123:9: error: reference to undefined > name 'doinit' > 123 | doinit() > | ^ > make[4]: *** [internal/cpu.lo] Error 1 > > Andreas. > also on x32, or with the x32 multilib target.
Re: [PATCH 3/3] Support the PGO build for binutils+gdb
On 10/29/20 8:11 PM, H.J. Lu via Binutils wrote: > diff --git a/configure.ac b/configure.ac > index 7c4bdff0fa..eea9a21099 100644 > --- a/configure.ac > +++ b/configure.ac > + if test "$enable_pgo_build" = "lto"; then > +AC_MSG_CHECKING([whether the compiler supports -flto=jobserver]) > +old_CFLAGS="$CFLAGS" > +PGO_BUILD_LTO_CFLAGS="-flto=jobserver" that should add -ffat-lto-objects unless you are configuring with --disable-static. > +CFLAGS="$CFLAGS $PGO_BUILD_LTO_CFLAGS" > +AC_COMPILE_IFELSE([AC_LANG_SOURCE([int foo;])],, > + [PGO_BUILD_LTO_CFLAGS=]) > +CFLAGS="$old_CFLAGS" > +if test -n "$PGO_BUILD_LTO_CFLAGS"; then > + AC_MSG_RESULT([yes]) > +else > + AC_MSG_RESULT([no]) > + AC_MSG_WARN([LTO is disabled for the PGO build]) > +fi > + fi Matthias
Re: [PATCH 3/3] Support the PGO build for binutils+gdb
On 10/29/20 8:11 PM, H.J. Lu via Binutils wrote: > diff --git a/Makefile.tpl b/Makefile.tpl > index a280a1498c..38f0b021f4 100644 > --- a/Makefile.tpl > +++ b/Makefile.tpl > +@if pgo-build > + && $(MAKE) $(RECURSE_FLAGS_TO_PASS) \ shouldn't make called with -i here? you're not interested letting some test failures to stop the build. > + $(PGO_BUILD_TRAINING_FLAGS_TO_PASS) \ > + $(PGO_BUILD_TRAINING) \ > + && $(MAKE) $(RECURSE_FLAGS_TO_PASS) clean \ > + && $(MAKE) $(RECURSE_FLAGS_TO_PASS) \ > + $(PGO_BUILD_USE_FLAGS_TO_PASS) all-host all-target \ > +@endif pgo-build > @if gcc-bootstrap > ; \ > fi \ Matthias
Re: [PATCH] RISC-V: Explicitly call python when using multilib generator
On 12/9/20 3:03 PM, Simon Cook wrote: > When building GCC for RISC-V with the --with-multilib-generator option, > it may not be possible to call arch-canonicalize as an executable when > building on Windows. Instead directly invoke the expected python > interpreter for this step. > > gcc/ChangeLog: > > * config/riscv/multilib-generator (arch_canonicalize): Invoke > python interpreter when calling arch-canonicalize script. > --- > gcc/config/riscv/multilib-generator | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/gcc/config/riscv/multilib-generator > b/gcc/config/riscv/multilib-generator > index 53c51dfa53f..79948518118 100755 > --- a/gcc/config/riscv/multilib-generator > +++ b/gcc/config/riscv/multilib-generator > @@ -54,7 +54,8 @@ def arch_canonicalize(arch): >this_file = os.path.abspath(os.path.join( __file__)) >arch_can_script = \ > os.path.join(os.path.dirname(this_file), "arch-canonicalize") > - proc = subprocess.Popen([arch_can_script, arch], stdout=subprocess.PIPE) > + proc = subprocess.Popen(['python', arch_can_script, arch], > + stdout=subprocess.PIPE) >out, err = proc.communicate() >return out.strip() > that's again hard-coding 'python'.
[patch] [ada] Fix PR ada/97504 for mips*-linux
Fix PR ada/97504 for mips*-linux, the bootstrap works again on mips*-linux. Ok for the trunk? gcc/ada/ PR ada/97504 * Makefile.rtl (LIBGNAT_TARGET_PAIRS) : Use wraplf version of Aux_Long_Long_Float. --- a/gcc/ada/Makefile.rtl +++ b/gcc/ada/Makefile.rtl @@ -2288,6 +2288,7 @@ endif ifeq ($(strip $(filter-out mips% linux%,$(target_cpu) $(target_os))),) LIBGNAT_TARGET_PAIRS = \ a-intnam.ads
[patch] don't build insn-extract.o with rtl checking
As seen in PR98144, building insn-extract.o with rtl checking takes some memory, and it doesn't work on 32bit architectures at all (PR97314). Richard suggested on irc to disable rtl checking for this auto-generated file, like it's already done for genconditions.c. Patching it like done for genconditons.c. Ok for the trunk? Matthias --- a/gcc/genextract.c +++ b/gcc/genextract.c @@ -365,6 +365,8 @@ print_header (void) #define IN_TARGET_CODE 1\n\ #include \"config.h\"\n\ #include \"system.h\"\n\ +#undef ENABLE_RTL_CHECKING\n\ +#undef ENABLE_RTL_FLAG_CHECKING\n\ #include \"coretypes.h\"\n\ #include \"tm.h\"\n\ #include \"rtl.h\"\n\
Re: [PATCH] RISC-V: Canonicalize --with-arch
On 12/4/20 2:38 PM, Matthias Klose wrote: > On 12/4/20 9:07 AM, Kito Cheng via Gcc-patches wrote: >> Committed, thanks :) >> >> On Thu, Dec 3, 2020 at 8:51 AM Jim Wilson wrote: >>> >>> On Tue, Dec 1, 2020 at 12:13 AM Kito Cheng wrote: >>>> >>>> - We would like to canonicalize the arch string for --with-arch for >>>>easier handling multilib, so split canonicalization part to a stand >>>>along script to shared the logic. >>>> >>>> gcc/ChangeLog: >>>> >>>> * config/riscv/multilib-generator (arch_canonicalize): Move >>>> code to arch-canonicalize, and call that script to canonicalize >>>> arch >>>> string. >>>> (canonical_order): Move code to arch-canonicalize. >>>> (LONG_EXT_PREFIXES): Ditto. >>>> (IMPLIED_EXT): Ditto. >>>> * config/riscv/arch-canonicalize: New. >>>> * config.gcc (riscv*-*-*): Canonicalize --with-arch. >>> >>> >>> Looks OK to me. > > that breaks the bootstrap if python is not available. The python command might > not be available, so please check for python3, python, or python2. same for config/riscv/arch-canonicalize
Re: [PATCH] RISC-V: Canonicalize --with-arch
On 12/4/20 9:07 AM, Kito Cheng via Gcc-patches wrote: > Committed, thanks :) > > On Thu, Dec 3, 2020 at 8:51 AM Jim Wilson wrote: >> >> On Tue, Dec 1, 2020 at 12:13 AM Kito Cheng wrote: >>> >>> - We would like to canonicalize the arch string for --with-arch for >>>easier handling multilib, so split canonicalization part to a stand >>>along script to shared the logic. >>> >>> gcc/ChangeLog: >>> >>> * config/riscv/multilib-generator (arch_canonicalize): Move >>> code to arch-canonicalize, and call that script to canonicalize arch >>> string. >>> (canonical_order): Move code to arch-canonicalize. >>> (LONG_EXT_PREFIXES): Ditto. >>> (IMPLIED_EXT): Ditto. >>> * config/riscv/arch-canonicalize: New. >>> * config.gcc (riscv*-*-*): Canonicalize --with-arch. >> >> >> Looks OK to me. that breaks the bootstrap if python is not available. The python command might not be available, so please check for python3, python, or python2. And it adds an unconditional build dependency on python for building the riscv targets. Matthias
Re: [PATCH] INSTALL: Default to --enable-cet=auto
On 11/27/20 3:54 PM, H.J. Lu via Gcc-patches wrote:
> On Fri, Nov 27, 2020 at 6:24 AM Richard Biener wrote:
>>
>> OK.
>>
>> On Fri, 27 Nov 2020, H.J. Lu wrote:
>>
>>> PR other/98027
>>> * doc/install: Default to --enable-cet=auto.
>>> ---
>>> gcc/doc/install.texi | 9 -
>>> 1 file changed, 4 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
>>> index 5f879ca4cea..021c347cc09 100644
>>> --- a/gcc/doc/install.texi
>>> +++ b/gcc/doc/install.texi
>>> @@ -2259,11 +2259,10 @@ instrumentation, see @option{-fcf-protection}
>>> option. When
>>> to add @option{-fcf-protection} and, if needed, other target
>>> specific options to a set of building options.
>>>
>>> -The option is disabled by default. When @code{--enable-cet=auto}
>>> -is used, it is enabled on Linux/x86 if target binutils
>>> -supports @code{Intel CET} instructions and disabled otherwise.
>>> -In this case the target libraries are configured to get additional
>>> -@option{-fcf-protection} option.
>>> +@code{--enable-cet=auto} is default. CET is enabled on Linux/x86 if
>>> +target binutils supports @code{Intel CET} instructions and disabled
>>> +otherwise. In this case, the target libraries are configured to get
>>> +additional @option{-fcf-protection} option.
>>>
>>> @item --with-riscv-attribute=@samp{yes}, @samp{no} or @samp{default}
>>> Generate RISC-V attribute by default, in order to record extra build
>>>
>>
>
> OK for backport to GCC 10?
I only found that because of failing package builds in a test rebuild. See
PR98025. Is it safe to backport that, if it breaks the ABI of a runtime library
shipped with GCC 10?
Matthias
Re: [Ada] Build support units for 128-bit integer types on 64-bit platforms
On 10/22/20 2:12 PM, Pierre-Marie de Rodat wrote: > This enables the build of the support units for 128-bit integer types > in the full runtime of 64-bit platforms. > > Tested on x86_64-pc-linux-gnu, committed on trunk > > gcc/ada/ > > * Makefile.rtl (64-bit platforms): Add GNATRTL_128BIT_PAIRS to > the LIBGNAT_TARGET_PAIRS list and also GNATRTL_128BIT_OBJS to > the EXTRA_GNATRTL_NONTASKING_OBJS list. > that broke the build of an ada cross compiler targeting powerpc64le-linux-gnu. target_cpu is powerpc64le which is not matched by the Makefile logic. Ok for the trunk? PR ada/97859 * Makefile.rtl (powerpc% linux%): Also match powerpc64le cpu. --- a/gcc/ada/Makefile.rtl +++ b/gcc/ada/Makefile.rtl @@ -2305,7 +2305,7 @@ ifeq ($(strip $(filter-out powerpc% linux%,$(target_cpu) $(target_os))),) $(ATOMICS_BUILTINS_TARGET_PAIRS) \ system.ads
[nvptx, aarch64] Define TARGET_OFFLOAD_OPTIONS for AArch64
Trying to build a nvptx offload compiler on aarch64-linux-gnu, the libgomp tests
error out with
unrecognizable argument of option -foffload-abi
Passing that option goes a step further, hitting PR target/96265. Define that
hook, as it was done for rs6000 in 2015. Ok for the trunk?
Matthias
* config/aarch64/aarch64.c (+aarch64_offload_options,
TARGET_OFFLOAD_OPTIONS): New.
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -22739,6 +22739,16 @@ aarch64_stack_protect_guard (void)
return NULL_TREE;
}
+/* Implement the TARGET_OFFLOAD_OPTIONS hook. */
+static char *
+aarch64_offload_options (void)
+{
+ if (TARGET_ILP32)
+return xstrdup ("-foffload-abi=ilp32");
+ else
+return xstrdup ("-foffload-abi=lp64");
+}
+
/* Return the diagnostic message string if conversion from FROMTYPE to
TOTYPE is not allowed, NULL otherwise. */
@@ -23079,6 +23089,9 @@ aarch64_libgcc_floating_mode_supported_p
#undef TARGET_NARROW_VOLATILE_BITFIELD
#define TARGET_NARROW_VOLATILE_BITFIELD hook_bool_void_false
+#undef TARGET_OFFLOAD_OPTIONS
+#define TARGET_OFFLOAD_OPTIONS aarch64_offload_options
+
#undef TARGET_OPTION_OVERRIDE
#define TARGET_OPTION_OVERRIDE aarch64_override_options
Re: [patch] fix PR lto/95604, -flto and -fcf-protection
On 6/17/20 3:11 PM, Richard Biener wrote:
> On Wed, 17 Jun 2020, H.J. Lu wrote:
>
>> On Wed, Jun 17, 2020 at 5:33 AM Richard Biener wrote:
>>>
>>> On Wed, 17 Jun 2020, H.J. Lu wrote:
>>>
>>>> On Wed, Jun 17, 2020 at 5:00 AM Richard Biener wrote:
>>>>>
>>>>> On Wed, 17 Jun 2020, H.J. Lu wrote:
>>>>>
>>>>>> On Wed, Jun 17, 2020 at 1:59 AM Richard Biener
>>>>>> wrote:
>>>>>>>
>>>>>>> On Mon, Jun 15, 2020 at 5:30 PM Matthias Klose wrote:
>>>>>>>>
>>>>>>>> PR lto/95604 was seen when checking for binaries without having CET
>>>>>>>> support in a
>>>>>>>> distro archive, for binaries built with LTO optimization. The
>>>>>>>> hardening flag
>>>>>>>> -fcf-protection=full is passed in CFLAGS, and maybe should be passed
>>>>>>>> in LDFLAGS
>>>>>>>> as well. However to make it work when not passed to the link step, it
>>>>>>>> should be
>>>>>>>> extracted from the options found in the lto opts section.
>>>>>>>>
>>>>>>>> Richard suggested two solutions offline. I checked that both fix the
>>>>>>>> test case.
>>>>>>>> Which one to install? Also ok for the 9 and 10 branches?
>>>>>>>
>>>>>>> I guess even though variant two is simpler it doesn't make much sense to
>>>>>>> have differing settings of -fcf-protection between different functions?
>>>>>>> HJ?
>>>>>>
>>>>>> -fcf-protection is applied to a file, not a function since CET marker
>>>>>> is per file.
>>>>>>
>>>>>>> So looking at variant one,
>>>>>>>
>>>>>>> @@ -287,6 +287,18 @@
>>>>>>> foption->orig_option_with_args_text);
>>>>>>> break;
>>>>>>>
>>>>>>> + case OPT_fcf_protection_:
>>>>>>> + /* Append or check identical. */
>>>>>>> + for (j = 0; j < *decoded_options_count; ++j)
>>>>>>> + if ((*decoded_options)[j].opt_index == foption->opt_index)
>>>>>>> + break;
>>>>>>> + if (j == *decoded_options_count)
>>>>>>> + append_option (decoded_options, decoded_options_count,
>>>>>>> foption);
>>>>>>> + else if (strcmp ((*decoded_options)[j].arg, foption->arg))
>>>>>>> + warning (input_location, "option %s with different values",
>>>>>>> +foption->orig_option_with_args_text);
>>>>>>> + break;
>>>>>>>
>>>>>>> you are always streaming a -fcf-protection option so the if (j ==
>>>>>>> *decoded_options_count)
>>>>>>> case shouldn't ever happen but I guess it's safe to leave the code
>>>>>>> as-is. Can you
>>>>>>> amend the warning with the option that prevails? Maybe
>>>>>>>
>>>>>>> + else if (strcmp ((*decoded_options)[j].arg, foption->arg))
>>>>>>>{
>>>>>>> static bool noted;
>>>>>>> + warning (input_location, "option %s with different values",
>>>>>>> +foption->orig_option_with_args_text);
>>>>>>> if (!noted)
>>>>>>> {
>>>>>>>inform ("%s will be used instead",
>>>>>>> (*decoded_options)[j].orig_option_with_args_text);
>>>>>>>noted = true;
>>>>>>> }
>>>>>>>
>>>>>>> I guess input_location is simply zero so the diagnostic doesn't
>>>>>>> contain the actual file we're
>>>>>>> looking at. Something to improve I guess (also applyign to other
>>>>>>> diagnostics we emit).
>>>>>>>
>>>>>>> Otherwise looks OK.
>>>>>>>
>>>>>>> Please wait for HJ in
[patch] fix PR lto/95604, -flto and -fcf-protection
PR lto/95604 was seen when checking for binaries without having CET support in a
distro archive, for binaries built with LTO optimization. The hardening flag
-fcf-protection=full is passed in CFLAGS, and maybe should be passed in LDFLAGS
as well. However to make it work when not passed to the link step, it should be
extracted from the options found in the lto opts section.
Richard suggested two solutions offline. I checked that both fix the test case.
Which one to install? Also ok for the 9 and 10 branches?
Thanks, Matthias
PR lto/95604
* lto-wrapper.c (merge_and_complain): Warn about different
values for -fcf-protection.
(append_compiler_options): Pass -fcf-protection option.
* lto-opts.c (lto_write_options): Pass -fcf-protection option.
--- a/src/gcc/lto-opts.c
+++ b/src/gcc/lto-opts.c
@@ -94,6 +94,21 @@ lto_write_options (void)
: "-fno-pie");
}
+ if (!global_options_set.x_flag_cf_protection)
+{
+ append_to_collect_gcc_options (
+_obstack, _p,
+ global_options.x_flag_cf_protection == CF_NONE
+ ? "-fcf-protection=none"
+ : global_options.x_flag_cf_protection == CF_FULL
+ ? "-fcf-protection=full"
+ : global_options.x_flag_cf_protection == CF_BRANCH
+ ? "-fcf-protection=branch"
+ : global_options.x_flag_cf_protection == CF_RETURN
+ ? "-fcf-protection=RETURN"
+ : "");
+}
+
/* If debug info is enabled append -g. */
if (debug_info_level > DINFO_LEVEL_NONE)
append_to_collect_gcc_options (_obstack, _p, "-g");
--- a/src/gcc/lto-wrapper.c
+++ b/src/gcc/lto-wrapper.c
@@ -287,6 +287,18 @@
foption->orig_option_with_args_text);
break;
+ case OPT_fcf_protection_:
+ /* Append or check identical. */
+ for (j = 0; j < *decoded_options_count; ++j)
+ if ((*decoded_options)[j].opt_index == foption->opt_index)
+ break;
+ if (j == *decoded_options_count)
+ append_option (decoded_options, decoded_options_count, foption);
+ else if (strcmp ((*decoded_options)[j].arg, foption->arg))
+ warning (input_location, "option %s with different values",
+ foption->orig_option_with_args_text);
+ break;
+
case OPT_O:
case OPT_Ofast:
case OPT_Og:
@@ -645,6 +677,7 @@
case OPT_fopenacc:
case OPT_fopenacc_dim_:
case OPT_foffload_abi_:
+ case OPT_fcf_protection_:
case OPT_g:
case OPT_O:
case OPT_Ofast:
* common.opt (fcf-protection, fcf-protection=): Mark as optimization.
--- a/src/gcc/common.opt
+++ b/src/gcc/common.opt
@@ -1739,10 +1739,10 @@
Inline __atomic operations when a lock free instruction sequence is available.
fcf-protection
-Common RejectNegative Alias(fcf-protection=,full)
+Common Optimization RejectNegative Alias(fcf-protection=,full)
fcf-protection=
-Common Report Joined RejectNegative Enum(cf_protection_level) Var(flag_cf_protection) Init(CF_NONE)
+Common Optimization Report Joined RejectNegative Enum(cf_protection_level) Var(flag_cf_protection) Init(CF_NONE)
-fcf-protection=[full|branch|return|none] Instrument functions with checks to verify jump/call/return control-flow transfer
instructions have valid targets.
Re: zstd not found if installed in non-system prefix
On 5/27/20 3:36 PM, Martin Liška wrote: > On 5/20/20 9:32 PM, Michael Kuhn wrote: >> Hi, >> >> when specifying a non-system prefix with --with-zstd, the build fails >> because the header and library cannot be found (see >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95005). >> >> The attached patch fixes the problem and is what we use in Spack to >> make GCC build with zstd support. > > Hello. > > I support the patch, but we need to wait for an approval of a maintainer. but please don't allow configuration via environment variables.
Re: zstd not found if installed in non-system prefix
On 5/20/20 9:32 PM, Michael Kuhn wrote:
> Hi,
>
> when specifying a non-system prefix with --with-zstd, the build fails
> because the header and library cannot be found (see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95005).
>
> The attached patch fixes the problem and is what we use in Spack to
> make GCC build with zstd support.
documentation for this is missing in gcc/doc/install.texi. Also please don't
introduce configurations via environment variables, but add options like for
gmp. See
@item --with-gmp=@var{pathname}
@itemx --with-gmp-include=@var{pathname}
@itemx --with-gmp-lib=@var{pathname}
Matthias
Re: [committed] libphobos: Add --enable-libphobos-checking configure option (PR94305)
On 4/9/20 12:47 AM, Iain Buclaw via Gcc-patches wrote: > Hi, > > As GDCFLAGS is overriden by the top-level make file with '-O2 -g', > libphobos ends up always being built with all contracts, invariants, and > asserts compiled in. This adds a new configurable that defaults to omit > compiling any run-time checks into the library using '-frelease'. > > Other choices either set the flags '-fno-release', enabling all run-time > checks, or '-fassert', which only compiles in asserts. > > The omission of compiling in contracts results in a smaller library > size, with faster build times. please could you document these in gcc/doc/install.texi, maybe together with other undocumented options? Thanks, Matthias
Re: [PATCH] rs6000: Check -+0 and NaN for smax/smin generation
On 3/19/20 7:22 AM, Jiufu Guo via Gcc-patches wrote: > Jiufu Guo writes: > > Backported to GCC 9, preapproved by Segher. > > Thanks, > > Jiufu this checks in a file diff --git a/a b/a new file mode 100644 index 000..a4f422403ef --- /dev/null +++ b/a @@ -0,0 +1,81 @@ +commit 5b075372b47b87bde46e5acc58531c410fb65f8c +Author: Jiufu Guo +AuthorDate: Tue Mar 10 13:51:57 2020 +0800 +Commit: Jiufu Guo +CommitDate: Thu Mar 19 10:04:00 2020 +0800 [...] please remove.
Re: Patch to fix PR93272
On 1/28/20 9:52 PM, Vladimir Makarov wrote: > The following patch fixes > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272 > > The patch was successfully tested and bootstrapped on x86_64. > > Unfortunately it is hard to create a test case for the patch. So there is no > test for this PR. the bug report asks for a backport to the gcc-8 and gcc-9 branches.
[patch] factor out common files for compare_exclusions
the toplevel configure.ac repeats common exclusion files for specific targets. Just factor those out. Maybe not required, but gm2 is adding more files to be ignored on every target, so make it easy to only have these files mentioned in one place. Ok for the trunk? Matthias 2019-12-11 Matthias Klose * configure.ac: Factor out common cases for compare_exclusions. * configure: Regenerate. Index: configure.ac === --- configure.ac (revision 279204) +++ configure.ac (working copy) @@ -3628,8 +3628,8 @@ compare_exclusions="gcc/cc*-checksum\$(objext) | gcc/ada/*tools/*" case "$target" in hppa*64*-*-hpux*) ;; - hppa*-*-hpux*) compare_exclusions="gcc/cc*-checksum\$(objext) | */libgcc/lib2funcs* | gcc/ada/*tools/* | gcc/function-tests.o" ;; - powerpc*-ibm-aix*) compare_exclusions="gcc/cc*-checksum\$(objext) | gcc/ada/*tools/* | *libgomp*\$(objext)" ;; + hppa*-*-hpux*) compare_exclusions="$compare_exclusions | */libgcc/lib2funcs* | gcc/function-tests.o" ;; + powerpc*-ibm-aix*) compare_exclusions="$compare_exclusions | *libgomp*\$(objext)" ;; esac AC_SUBST(compare_exclusions)
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v3)
On 09.12.19 17:41, Gaius Mulley wrote: > Matthias Klose writes: > >> On 17.11.19 07:49, Gaius Mulley wrote: >>> >>> Hello, >>> >>> while spending the weekend on the Howland and Baker islands :-) I >>> thought I'd post version three of the patches which introduce Modula-2 >>> into the GCC trunk. The patches include: >> >> [...] >> >>> At a later point (after it is reviewed/approved) the gm2 tree >>> http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/m2/ could >>> be included. Together with the gm2 testsuite. >>> >>> But for now here are the proposed patches and ChangeLogs and new files >>> (gm2-v3.tar.gz) (after the patches): >> >> I have updated my distro packaging to build gcc-10, including gm2 from the >> trunk. Both native and cross builds seem to work, with some glitches: >> >> - For native builds, the profiled build doesn't work, failing to link >>the gcov library. Failing that, I can't check the lto+profiled build. >>Both the profiled and lto+profiled builds are working on your gcc-9 >>branch. >> >> - For cross builds, the libgm2 libraries install as host libraries, >>not target libraries (but are correctly built). I sent one patch >>to Gaius, but couldn't figure out yet, why the libs are not >>installed as target libraries. >> >> The packages are publicly available in Debian experimental [1] and Ubuntu >> focal >> [2], test results are sent to the gcc-testresults ML. >> >> Are you still aiming for inclusion in GCC 10? >> >> Matthias >> >> [1] https://tracker.debian.org/pkg/gcc-10 >> [2] >> https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/10781708/+listing-archive-extra > > Hello, > > yes I'm still aiming for inclusion in GCC 10. I'm still examining the > target/host bugs in the libgm2 build infrastructure (and slowly going > insane :-). I'll also look at the lto+profiled build - great to hear > the gcc-9/gm2 branch works. How do the GCC 10 gm2 v3 patches look? I didn't have to modify any of these for my gcc-10 packaging, from my point of view these look ok. However I can't officially review any of those. Matthias
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v3)
On 17.11.19 07:49, Gaius Mulley wrote: > > Hello, > > while spending the weekend on the Howland and Baker islands :-) I > thought I'd post version three of the patches which introduce Modula-2 > into the GCC trunk. The patches include: [...] > At a later point (after it is reviewed/approved) the gm2 tree > http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/m2/ could > be included. Together with the gm2 testsuite. > > But for now here are the proposed patches and ChangeLogs and new files > (gm2-v3.tar.gz) (after the patches): I have updated my distro packaging to build gcc-10, including gm2 from the trunk. Both native and cross builds seem to work, with some glitches: - For native builds, the profiled build doesn't work, failing to link the gcov library. Failing that, I can't check the lto+profiled build. Both the profiled and lto+profiled builds are working on your gcc-9 branch. - For cross builds, the libgm2 libraries install as host libraries, not target libraries (but are correctly built). I sent one patch to Gaius, but couldn't figure out yet, why the libs are not installed as target libraries. The packages are publicly available in Debian experimental [1] and Ubuntu focal [2], test results are sent to the gcc-testresults ML. Are you still aiming for inclusion in GCC 10? Matthias [1] https://tracker.debian.org/pkg/gcc-10 [2] https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/10781708/+listing-archive-extra
Re: libgo patch committed: Always mark assembly file as non-executable stack
On 06.12.19 12:28, Rainer Orth wrote: > I Ian, > >> This libgo patch arranges for go-context.S to always be marked as >> using a non-executable stack. This is not required for all targets, >> but should do little harm. Bootstrapped on x86_64-pc-linux-gnu. >> Committed to mainline. > > unfortunately, it does, breaking bootstrap on Solaris/SPARC and x86 with > the native assembler: > > * Solaris/SPARC with as: > > /usr/ccs/bin/as: "/var/tmp//ccSl12Nb.s", line 7: error: invalid character > (0x40) > /usr/ccs/bin/as: "/var/tmp//ccSl12Nb.s", line 7: error: quoted-string operand > required > /usr/ccs/bin/as: "/var/tmp//ccSl12Nb.s", line 7: error: statement syntax > make[4]: *** [Makefile:1433: runtime/go-context.lo] Error 1 > > * Solaris/x86 with as: > > Assembler: > "/vol/gcc/src/hg/trunk/local/libgo/runtime/go-context.S", line 74 : > Syntax error > Near line: " .section .note.GNU-stack,"",@progbits" > make[4]: *** [Makefile:1433: runtime/go-context.lo] Error 1 also on arm-linux-gnueabi*. Patch in PR go/92820 Matthias
[patch] install the lto-dump man page
GCC 10 comes with a new lto-dump texi file, but the man page isn't built and installed. Fix with the attached patch. Ok to install? Matthias * Makefile.in (SOURCES): Add doc/lto-dump.1. (install-man): Add $(LTO_DUMP_INSTALL_NAME)$(man1ext). ($(LTO_DUMP_INSTALL_NAME)$(man1ext): New. Index: gcc/Makefile.in === --- gcc/Makefile.in (revision 278870) +++ gcc/Makefile.in (working copy) @@ -3202,7 +3202,8 @@ gcov.texi trouble.texi bugreport.texi service.texi \ contribute.texi compat.texi funding.texi gnu.texi gpl_v3.texi \ fdl.texi contrib.texi cppenv.texi cppopts.texi avr-mmcu.texi \ - implement-c.texi implement-cxx.texi gcov-tool.texi gcov-dump.texi lto-dump.texi + implement-c.texi implement-cxx.texi gcov-tool.texi gcov-dump.texi \ + lto-dump.texi # we explicitly use $(srcdir)/doc/tm.texi here to avoid confusion with # the generated tm.texi; the latter might have a more recent timestamp, @@ -3325,7 +3326,8 @@ $(SHELL) $(srcdir)/doc/install.texi2html MANFILES = doc/gcov.1 doc/cpp.1 doc/gcc.1 doc/gfdl.7 doc/gpl.7 \ - doc/fsf-funding.7 doc/gcov-tool.1 doc/gcov-dump.1 + doc/fsf-funding.7 doc/gcov-tool.1 doc/gcov-dump.1 \ + $(if $(filter yes,@enable_lto@),doc/lto-dump.1) generated-manpages: man @@ -3722,6 +3724,7 @@ $(DESTDIR)$(man1dir)/$(GCOV_INSTALL_NAME)$(man1ext) \ $(DESTDIR)$(man1dir)/$(GCOV_TOOL_INSTALL_NAME)$(man1ext) \ $(DESTDIR)$(man1dir)/$(GCOV_DUMP_INSTALL_NAME)$(man1ext) \ + $(if $(filter yes,@enable_lto@),$(DESTDIR)$(man1dir)/$(LTO_DUMP_INSTALL_NAME)$(man1ext)) \ $(DESTDIR)$(man7dir)/fsf-funding$(man7ext) \ $(DESTDIR)$(man7dir)/gfdl$(man7ext) \ $(DESTDIR)$(man7dir)/gpl$(man7ext) @@ -3756,6 +3759,11 @@ -$(INSTALL_DATA) $< $@ -chmod a-x $@ +$(DESTDIR)$(man1dir)/$(LTO_DUMP_INSTALL_NAME)$(man1ext): doc/lto-dump.1 installdirs + -rm -f $@ + -$(INSTALL_DATA) $< $@ + -chmod a-x $@ + # Install all the header files built in the include subdirectory. install-headers: $(INSTALL_HEADERS_DIR) # Fix symlinks to absolute paths in the installed include directory to
Re: [PATCH 0/4] Eliminate cc0 from m68k
On 20.11.19 22:38, Richard Earnshaw wrote: > On 20/11/2019 20:48, Bernd Schmidt wrote: >> On 11/20/19 8:27 PM, Mikael Pettersson wrote: >>> On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt >>> wrote: Probably best to just run tests on stage1 and hope something shows up. >>> >>> Ok, how do I did that? I've always just done 'make -k check' after >>> full bootstraps. >>> I assume the stage 1 artifacts are the ones in the prev-* directories. >> >> There's a --disable-bootstrap configure option. >> What distro are you using for native builds? The m68k debian I'm using does not have an installable gcc package. >>> >>> I run a bespoke distro on m68k and sparc64, derived from Fedora but >>> massively cut down in size, with target patches done by myself or >>> ported from Debian and Gentoo as necessary. >>> >>> Debian/m68k not having a gcc package? That sounds odd; I see e.g. a >>> gcc-9 in http://ftp.ports.debian.org/debian-ports/pool-m68k/main/g/ >> >> Turns out I wasn't sufficiently familiar with how debian works. I was >> missing an "apt update" step. I kind of assumed a package like gcc would >> install out of the box (others did, things like emacs). >> >> >> Bernd >> > > If you're building gcc on debian/ubuntu you probably also want > > apt build-dep gcc > > to install all the packages needed for building the compiler. that would be apt build-dep gcc-9. The former would only install the build dependencies of the gcc-defaults package.
Re: [PATCH] Make LTO link pick up compile-time -g
On 09.09.19 15:51, Richard Biener wrote:
On Mon, 9 Sep 2019, Matthias Klose wrote:
On 09.09.19 14:02, Richard Biener wrote:
So this is really a very poor mans solution that also might
uncover issues with -g0 at compile-time vs. -g at link-time
if there are mixed -g0/g TUs in the LTO link.
Could this be documented, at least in the man page? e.g. invoke.texi. As a
bonus I would very much welcome a section in the user manual about LTO
building. E.g. what will work, what currently doesn't work, etc. Happy to
review and extend such documentation, but I don't feel comfortable to write
that on my own.
Like the following?
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 275454)
+++ gcc/doc/invoke.texi (working copy)
@@ -10335,6 +10335,14 @@ conflicting translation units. Specific
precedence; and for example @option{-ffp-contract=off} takes precedence
over @option{-ffp-contract=fast}. You can override them at link time.
+To enable debug info generation you need to supply @option{-g} at
+compile-time. If any of the input files at link time were built
+with debug info generation enabled the link will enable debug info
+generation as well. Any elaborate debug info settings
+like the dwarf level @option{-gdwarf-5} need to be explicitely repeated
+at the linker command line and mixing different settings in different
+translation units is discouraged.
+
If LTO encounters objects with C linkage declared with incompatible
types in separate translation units to be linked together (undefined
behavior according to ISO C99 6.2.7), a non-fatal diagnostic may be
Thanks!
Re: [PATCH] Make LTO link pick up compile-time -g
On 09.09.19 14:02, Richard Biener wrote: So this is really a very poor mans solution that also might uncover issues with -g0 at compile-time vs. -g at link-time if there are mixed -g0/g TUs in the LTO link. Could this be documented, at least in the man page? e.g. invoke.texi. As a bonus I would very much welcome a section in the user manual about LTO building. E.g. what will work, what currently doesn't work, etc. Happy to review and extend such documentation, but I don't feel comfortable to write that on my own. Matthias
Re: [PATCH, libphobos] Committed merge with upstream druntime 5bb8ce19
On 21.08.19 10:02, Iain Buclaw wrote: > Hi, > > This patch merges the libdruntime library with upstream druntime 5bb8ce19. > > Synchronizes extern(C) bindings with the latest release, mostly this > is just Musl target support. > > Bootstrapped and regression tested on x86_64-linux-gnu and x86_64-linux-musl. > > Committed to trunk as r274773. Does the change the ABI? Asking, because apparently the out-of-tree libgphobos for GCC 8, and the one in GCC 9 don't seem to be ABI compatible. Matthias
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)
On 14.06.19 15:09, Gaius Mulley wrote: I checked that gm2 cross compilers can be built. One minor nit: The man page is installed without suffix and prefix. gcc/gm2/Make-lang.in has GM2_CROSS_NAME = `echo gm2|sed '$(program_transform_cross_name)'` The program_transform_cross_name macro was removed in 2003, and doesn't do anything. The installation of the man page shouldn't be special-cased for a cross build. Matthias
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)
On 14.06.19 15:09, Gaius Mulley wrote: > > Hello, > > here is version two of the patches which introduce Modula-2 into the > GCC trunk. The patches include: > > (*) a patch to allow all front ends to register a lang spec function. >(included are patches for all front ends to provide an empty > callback function). fyi, the hook patches for brig, D, Fortran and Go are not yet part of your gm2 repository for the trunk (while they are for gcc-9). The patches are also duplicated as trunc and trunk. Matthias
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)
On 08.07.19 23:19, Matthias Klose wrote: > On 14.06.19 15:09, Gaius Mulley wrote: >> >> Hello, >> >> here is version two of the patches which introduce Modula-2 into the >> GCC trunk. The patches include: >> >> (*) a patch to allow all front ends to register a lang spec function. >>(included are patches for all front ends to provide an empty >> callback function). >> (*) patch diffs to allow the Modula-2 front end driver to be >>built using GCC Makefile and friends. >> >> The compressed tarball includes: >> >> (*) gcc/m2 (compiler driver and lang-spec stuff for Modula-2). >>Including the need for registering lang spec functions. >> (*) gcc/testsuite/gm2 (a Modula-2 dejagnu test to ensure that >>the gm2 driver is built and can understands --version). >> >> These patches have been re-written after taking on board the comments >> found in this thread: >> >>https://gcc.gnu.org/ml/gcc-patches/2013-11/msg02620.html >> >> it is a revised patch set from: >> >>https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00220.html >> >> I've run make bootstrap and run the regression tests on trunk and no >> extra failures occur for all languages touched in the ChangeLog. >> >> I'm currently tracking gcc trunk and gcc-9 with gm2 (which works well >> with amd64/arm64/i386) - these patches are currently simply for the >> driver to minimise the patch size. There are also > 1800 tests in a >> dejagnu testsuite for gm2 which can be included at some future time. > > I had a look at the GCC 9 version of the patches, with a build including a > make > install. Some comments: A look at the licenses: libgm2/p2c/*: GPL 3+ libgm2/libiso/*: LGPL 2.1+ libgm2/libmin/libc.c: GPL 3+ libgm2/liblog/*: LGPL 2.1+ libgm2/libpim/*: LGPL 2.1+ libgm2/libpim/Selective.c: GPL 3+ libgm2/libpim/wrapc.c: GPL 3+ libgm2/libpth/*: LGPL 2.1+ gcc/gm2/ulm-lib-gm2/* GPL 3+, Ulm copyright holder? gcc/gm2/gm2-libs/*.def GPL 3+ gcc/gm2/gm2-libs/Break.def LGPL 2.1+ gcc/gm2/gm2-libs/*.mod LGPL 2.1+ gcc/gm2/gm2-libs/Builtins.mod GPL 3+ I didn't look at everything in gcc/gm2, however it's not clear for me when a file is LGPL or GPL. And at least in gm2-libs, it seems to be mixed randomly. First I thought all definition modules were GPL, and implementation modules were LGPL, but that's not the case. So currently all code linked with the runtime libs becomes GPL 3+? For the ulm lib, the files mention the Ulm university as the copyright holder, but it's not clear which license these files had before they were imported. libgm2 seems to be mostly LGPL except for two files. Intended? Matthias
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)
On 08.07.19 23:19, Matthias Klose wrote: > On 14.06.19 15:09, Gaius Mulley wrote: >> >> Hello, >> >> here is version two of the patches which introduce Modula-2 into the >> GCC trunk. The patches include: >> >> (*) a patch to allow all front ends to register a lang spec function. >>(included are patches for all front ends to provide an empty >> callback function). >> (*) patch diffs to allow the Modula-2 front end driver to be >>built using GCC Makefile and friends. >> >> The compressed tarball includes: >> >> (*) gcc/m2 (compiler driver and lang-spec stuff for Modula-2). >>Including the need for registering lang spec functions. >> (*) gcc/testsuite/gm2 (a Modula-2 dejagnu test to ensure that >>the gm2 driver is built and can understands --version). >> >> These patches have been re-written after taking on board the comments >> found in this thread: >> >>https://gcc.gnu.org/ml/gcc-patches/2013-11/msg02620.html >> >> it is a revised patch set from: >> >>https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00220.html >> >> I've run make bootstrap and run the regression tests on trunk and no >> extra failures occur for all languages touched in the ChangeLog. >> >> I'm currently tracking gcc trunk and gcc-9 with gm2 (which works well >> with amd64/arm64/i386) - these patches are currently simply for the >> driver to minimise the patch size. There are also > 1800 tests in a >> dejagnu testsuite for gm2 which can be included at some future time. > > I had a look at the GCC 9 version of the patches, with a build including a > make > install. Some comments: Had a test build based on the gcc-9 branch, https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/10331180/+listing-archive-extra powerpc64le-linux-gnu fails to build (search for "unfinished" in the build log) during RTL pass: final ../../src/gcc/gm2/gm2-libs-coroutines/SYSTEM.def: In function '_M2_SYSTEM_init': ../../src/gcc/gm2/gm2-libs-coroutines/SYSTEM.def:20: internal compiler error: in rs6000_output_function_epilogue, at conf ig/rs6000/rs6000.c:29169 20 | DEFINITION MODULE SYSTEM ; | 0x10b6b7c7 rs6000_output_function_epilogue ../../src/gcc/config/rs6000/rs6000.c:29169 0x1043f80f final_end_function() ../../src/gcc/final.c:1887 0x10445313 rest_of_handle_final ../../src/gcc/final.c:4667 0x10445313 execute ../../src/gcc/final.c:4737 Please submit a full bug report, with preprocessed source if appropriate. this is using GCC 8 as the bootstrap compiler. search the build logs for "test_summary" to see the test results. The binary packages gcc-9-test-results contain the log/sum files for the tests. all the link tests fail with: xgm2: fatal error: cannot execute 'gm2l': execvp: No such file or directory compilation terminated. compiler exited with status 1 Matthias
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)
On 10.07.19 22:07, Gaius Mulley wrote:
> Matthias Klose writes:
>
>> On 09.07.19 23:30, Matthias Klose wrote:
>>> On 09.07.19 21:48, Gaius Mulley wrote:
>>>> Matthias Klose writes:
>>>>
>>>>>> - libpth.{a,so} is installed in the system libdir, which
>>>>>>conflicts with the installation of the libpth packages
>>>>>>on most distros.
>>>>>
>>>>> found out that a system provided libpth can be used. Otoh if you build
>>>>> the
>>>>> in-tree libpth, it shouldn't be installed, but built as a convenience
>>>>> library,
>>>>> like libgo using libffi, or libgphobos using zlib.
>>>>
>>>> Hi Matthias,
>>>>
>>>> as far as I know Redhat doesn't support libpth-dev - therefore it was
>>>> decided to include libpth in the gm2 tree and autodetect build/install
>>>> it as necessary.
>>>
>>> That's ok, but then please don't install it as a system library. that's
>>> what
>>> convenience libraries are for (a libpth.a built with -fPIC, which you can
>>> link
>>> against).
>>
>> I still think installing libpth is wrong, however currently all multilib
>> variants install into $libdir, and not into the system multilib dir, e.g.
>> lib64,
>> lib32, ... So the last multilib wins, and you end up with the wrong arch in
>> your $libdir.
>
> Hi Matthias,
>
> ah thanks for the explanation. The multilib build system is still new
> to me. So regarding the libpth issue, what happens if the native os
> does not provide libpth? From your experience with building multilib
> and shared library packages on multiple platforms - what is the best
> solution :-)
I don't know about a best solution, but I contributed changes to
DRUNTIME_LIBRARIES_ZLIB in libphobos/m4/druntime/libraries.m4 and
gcc/doc/install.texi (--with-target-system-zlib).
Or you look at libffi/libgo, with libgo always linking the convenience libffi
library.
Matthias
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)
On 09.07.19 23:30, Matthias Klose wrote:
> On 09.07.19 21:48, Gaius Mulley wrote:
>> Matthias Klose writes:
>>
>>>> - libpth.{a,so} is installed in the system libdir, which
>>>>conflicts with the installation of the libpth packages
>>>>on most distros.
>>>
>>> found out that a system provided libpth can be used. Otoh if you build the
>>> in-tree libpth, it shouldn't be installed, but built as a convenience
>>> library,
>>> like libgo using libffi, or libgphobos using zlib.
>>
>> Hi Matthias,
>>
>> as far as I know Redhat doesn't support libpth-dev - therefore it was
>> decided to include libpth in the gm2 tree and autodetect build/install
>> it as necessary.
>
> That's ok, but then please don't install it as a system library. that's what
> convenience libraries are for (a libpth.a built with -fPIC, which you can link
> against).
I still think installing libpth is wrong, however currently all multilib
variants install into $libdir, and not into the system multilib dir, e.g. lib64,
lib32, ... So the last multilib wins, and you end up with the wrong arch in
your $libdir.
Matthias
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)
On 09.07.19 23:35, Matthias Klose wrote: > On 08.07.19 23:19, Matthias Klose wrote: >> On 14.06.19 15:09, Gaius Mulley wrote: >>> >>> Hello, >>> >>> here is version two of the patches which introduce Modula-2 into the >>> GCC trunk. The patches include: >>> >>> (*) a patch to allow all front ends to register a lang spec function. >>>(included are patches for all front ends to provide an empty >>> callback function). >>> (*) patch diffs to allow the Modula-2 front end driver to be >>>built using GCC Makefile and friends. >>> >>> The compressed tarball includes: >>> >>> (*) gcc/m2 (compiler driver and lang-spec stuff for Modula-2). >>>Including the need for registering lang spec functions. >>> (*) gcc/testsuite/gm2 (a Modula-2 dejagnu test to ensure that >>>the gm2 driver is built and can understands --version). >>> >>> These patches have been re-written after taking on board the comments >>> found in this thread: >>> >>>https://gcc.gnu.org/ml/gcc-patches/2013-11/msg02620.html >>> >>> it is a revised patch set from: >>> >>>https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00220.html >>> >>> I've run make bootstrap and run the regression tests on trunk and no >>> extra failures occur for all languages touched in the ChangeLog. >>> >>> I'm currently tracking gcc trunk and gcc-9 with gm2 (which works well >>> with amd64/arm64/i386) - these patches are currently simply for the >>> driver to minimise the patch size. There are also > 1800 tests in a >>> dejagnu testsuite for gm2 which can be included at some future time. >> >> I had a look at the GCC 9 version of the patches, with a build including a >> make >> install. Some comments: > > [...] > >> - The internal tools in the gcclibdir are installed twice, with >>both vanilla names and prefixed/suffixed names. >> The installed tree: >> >> ./usr/bin >> ./usr/bin/x86_64-linux-gnu-gm2-9 >> ./usr/bin/x86_64-linux-gnu-gm2m-9 >> ./usr/lib/gcc/x86_64-linux-gnu >> ./usr/lib/gcc/x86_64-linux-gnu/9 >> ./usr/lib/gcc/x86_64-linux-gnu/9/cc1gm2 >> ./usr/lib/gcc/x86_64-linux-gnu/9/gm2l >> ./usr/lib/gcc/x86_64-linux-gnu/9/gm2lcc >> ./usr/lib/gcc/x86_64-linux-gnu/9/gm2lgen >> ./usr/lib/gcc/x86_64-linux-gnu/9/gm2lorder >> ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-cc1gm2-9 >> ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2l-9 >> ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2lcc-9 >> ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2lgen-9 >> ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2lorder-9 >> ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2m-9 > > With a fresh build, configured with > > --program-suffix=-9 > --program-prefix=x86_64-linux-gnu- > > the latter set of internal binaries is installed, while I would expect just > the > un-pre/post-fixed tool names. fixed by the attached patch. diff --git a/gcc-versionno/gcc/gm2/Make-lang.in b/gcc-versionno/gcc/gm2/Make-lang.in index 6fc4ee84..81f5cbbc 100644 --- a/gcc-versionno/gcc/gm2/Make-lang.in +++ b/gcc-versionno/gcc/gm2/Make-lang.in @@ -373,12 +373,11 @@ gm2.install-common: installdirs $(GM2_LINK_TOOLS_BOOT) \ chmod a+x $(DESTDIR)$(bindir)/$(GM2_INSTALL_NAME)$(exeext); \ for tool in stage1/gm2/cc1gm2$(exeext) \ $(GM2_LINK_TOOLS_BOOT) stage1/gm2/gm2m$(exeext) ; do \ -toolbase=`basename $$tool` ; \ -tool_transformed_name=`echo $$toolbase|sed '$(program_transform_name)'`; \ +tool_name=`basename $$tool` ; \ if [ -f $$tool ]; then \ - rm -f $(DESTDIR)$(libexecsubdir)/$$tool_transformed_name; \ - $(INSTALL_PROGRAM) $$tool $(DESTDIR)$(libexecsubdir)/$$tool_transformed_name; \ - chmod a+x $(DESTDIR)$(libexecsubdir)/$$tool_transformed_name; \ + rm -f $(DESTDIR)$(libexecsubdir)/$$tool_name; \ + $(INSTALL_PROGRAM) $$tool $(DESTDIR)$(libexecsubdir)/$$tool_name; \ + chmod a+x $(DESTDIR)$(libexecsubdir)/$$tool_name; \ else \ echo "odd cannot find $$tool" ; \ fi ; \
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)
On 08.07.19 23:19, Matthias Klose wrote: > On 14.06.19 15:09, Gaius Mulley wrote: >> >> Hello, >> >> here is version two of the patches which introduce Modula-2 into the >> GCC trunk. The patches include: >> >> (*) a patch to allow all front ends to register a lang spec function. >>(included are patches for all front ends to provide an empty >> callback function). >> (*) patch diffs to allow the Modula-2 front end driver to be >>built using GCC Makefile and friends. >> >> The compressed tarball includes: >> >> (*) gcc/m2 (compiler driver and lang-spec stuff for Modula-2). >>Including the need for registering lang spec functions. >> (*) gcc/testsuite/gm2 (a Modula-2 dejagnu test to ensure that >>the gm2 driver is built and can understands --version). >> >> These patches have been re-written after taking on board the comments >> found in this thread: >> >>https://gcc.gnu.org/ml/gcc-patches/2013-11/msg02620.html >> >> it is a revised patch set from: >> >>https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00220.html >> >> I've run make bootstrap and run the regression tests on trunk and no >> extra failures occur for all languages touched in the ChangeLog. >> >> I'm currently tracking gcc trunk and gcc-9 with gm2 (which works well >> with amd64/arm64/i386) - these patches are currently simply for the >> driver to minimise the patch size. There are also > 1800 tests in a >> dejagnu testsuite for gm2 which can be included at some future time. > > I had a look at the GCC 9 version of the patches, with a build including a > make > install. Some comments: [...] > - The internal tools in the gcclibdir are installed twice, with >both vanilla names and prefixed/suffixed names. > The installed tree: > > ./usr/bin > ./usr/bin/x86_64-linux-gnu-gm2-9 > ./usr/bin/x86_64-linux-gnu-gm2m-9 > ./usr/lib/gcc/x86_64-linux-gnu > ./usr/lib/gcc/x86_64-linux-gnu/9 > ./usr/lib/gcc/x86_64-linux-gnu/9/cc1gm2 > ./usr/lib/gcc/x86_64-linux-gnu/9/gm2l > ./usr/lib/gcc/x86_64-linux-gnu/9/gm2lcc > ./usr/lib/gcc/x86_64-linux-gnu/9/gm2lgen > ./usr/lib/gcc/x86_64-linux-gnu/9/gm2lorder > ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-cc1gm2-9 > ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2l-9 > ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2lcc-9 > ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2lgen-9 > ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2lorder-9 > ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2m-9 With a fresh build, configured with --program-suffix=-9 --program-prefix=x86_64-linux-gnu- the latter set of internal binaries is installed, while I would expect just the un-pre/post-fixed tool names.
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)
On 09.07.19 21:48, Gaius Mulley wrote:
> Matthias Klose writes:
>
>>> - libpth.{a,so} is installed in the system libdir, which
>>>conflicts with the installation of the libpth packages
>>>on most distros.
>>
>> found out that a system provided libpth can be used. Otoh if you build the
>> in-tree libpth, it shouldn't be installed, but built as a convenience
>> library,
>> like libgo using libffi, or libgphobos using zlib.
>
> Hi Matthias,
>
> as far as I know Redhat doesn't support libpth-dev - therefore it was
> decided to include libpth in the gm2 tree and autodetect build/install
> it as necessary.
That's ok, but then please don't install it as a system library. that's what
convenience libraries are for (a libpth.a built with -fPIC, which you can link
against).
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)
On 09.07.19 17:53, Gaius Mulley wrote: > Rainer Orth writes: > >> Hi Matthias, >> >>> I had a look at the GCC 9 version of the patches, with a build including a >>> make >>> install. Some comments: >>> >>> - A parallel build (at least with -j4) isn't working. A sequental >>>build works fine. I think forcing a sequential build will not >>>work well, increasing the build time too much. >> >> absolutely: I'd go as far as claiming that this is the number one >> priority. Otherwise build and test times are just too long for all but >> the most dedicated testers, and forcing a sequential build would be a >> showstopper for trunk integration. > > Hi, > > Many thanks for all the feedback/bugs/patches. > I've been working through some of these. The parallel build is now done. It seems to work, however I see make[11]: Entering directory '/home/packages/gcc/9/u/gcc-9-9.1.1/build/x86_64-linux-gnu/32/libgm2/libpth/pth' make[11]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. /bin/bash: line 0: test: !=: unary operator expected ../../../../../../src/libgm2/libpth/pth/shtool scpp -o pth_p.h -t ../../../../../../src/libgm2/libpth/pth/pth_p.h.in -Dcpp -Cintern -M '==#==' \ not sure what's going wrong. In both gcc/gm2 and libgm2, there are explicit calls to make, which probably should bre replaced by $(MAKE).
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)
On 09.07.19 15:41, Gaius Mulley wrote:
> Matthias Klose writes:
>
>>> the libraries ./usr/lib/x86_64-linux-gnu/lib{ulm,pim,gm2,cor,iso,min}.a
>>> are not needed the correct locations of the static libraries are:
>>>
>>> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/ulm/libulm.a
>>> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/min/libmin.a
>>> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/libcor.a
>>> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/pim/libgm2.a
>>> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/log/liblog.a
>>> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/libiso.a
>>
>> ok, then I assume that could be the place for the .so files as well (not the
>> .so.* files/links), if I don't want to install those in the system libdir.
>
> yes sure this should work fine,
but then you'll end up with separate m2 subdirs for each multilib build? That's
maybe not what you want.
And an unrelated one: You are introducing python2 as a build-dependency.
Afaics, it's only one invocation
python ../../src/gcc/gm2/tools-src/def2texi.py -uLibraries -s../../src/gcc/gm2
-b/home/packages/gcc/9/u/gcc-9-9.1.1/build/gcc/gm2 >
/home/packages/gcc/9/u/gcc-9-9.1.1/build/gcc/gm2/gm2-libs.texi
but there might be more implicit python calls via a shebang line.
Also it's python2, not ready to run with python3. I think you should not rely
on python2 only code anymore.
Matthias
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)
On 09.07.19 14:02, Gaius Mulley wrote:
> Matthias Klose writes:
>
>>> - There are three letter libraries with pretty generic
>>>names installed into the system libdir: log, iso, cor,
>>>min, ulm. At least for log, you have a file conflict
>>>with another library. Shouldn't these libraries named
>>>mpre specific, like libgm2log?
>
>>> The installed tree:
>>
>>> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/ulm/libulm.a
>>> ./usr/lib/x86_64-linux-gnu/libulm.a
>>
>> and all static libraries are installed twice, not just libulm.a. What is the
>> correct location?
>>
>> Matthias
>
> Hi Matthias,
>
> the libraries ./usr/lib/x86_64-linux-gnu/lib{ulm,pim,gm2,cor,iso,min}.a
> are not needed the correct locations of the static libraries are:
>
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/ulm/libulm.a
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/min/libmin.a
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/libcor.a
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/pim/libgm2.a
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/log/liblog.a
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/libiso.a
ok, then I assume that could be the place for the .so files as well (not the
.so.* files/links), if I don't want to install those in the system libdir.
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)
On 08.07.19 23:19, Matthias Klose wrote:
> On 14.06.19 15:09, Gaius Mulley wrote:
>>
>> Hello,
>>
>> here is version two of the patches which introduce Modula-2 into the
>> GCC trunk. The patches include:
>>
>> (*) a patch to allow all front ends to register a lang spec function.
>>(included are patches for all front ends to provide an empty
>> callback function).
>> (*) patch diffs to allow the Modula-2 front end driver to be
>>built using GCC Makefile and friends.
>>
>> The compressed tarball includes:
>>
>> (*) gcc/m2 (compiler driver and lang-spec stuff for Modula-2).
>>Including the need for registering lang spec functions.
>> (*) gcc/testsuite/gm2 (a Modula-2 dejagnu test to ensure that
>>the gm2 driver is built and can understands --version).
>>
>> These patches have been re-written after taking on board the comments
>> found in this thread:
>>
>>https://gcc.gnu.org/ml/gcc-patches/2013-11/msg02620.html
>>
>> it is a revised patch set from:
>>
>>https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00220.html
>>
>> I've run make bootstrap and run the regression tests on trunk and no
>> extra failures occur for all languages touched in the ChangeLog.
>>
>> I'm currently tracking gcc trunk and gcc-9 with gm2 (which works well
>> with amd64/arm64/i386) - these patches are currently simply for the
>> driver to minimise the patch size. There are also > 1800 tests in a
>> dejagnu testsuite for gm2 which can be included at some future time.
>
> I had a look at the GCC 9 version of the patches, with a build including a
> make
> install. Some comments:
>
> - A parallel build (at least with -j4) isn't working. A sequental
>build works fine. I think forcing a sequential build will not
>work well, increasing the build time too much.
>
> - libgm2 multilib builds are not working. //32/libgm2
>is configured, but not built.
>
> - The internal tools in the gcclibdir are installed twice, with
>both vanilla names and prefixed/suffixed names.
>
> - libgm2/configure.a has a libtool version 14:0:0, however all
>shared libraries are installed with soversion 0.
>
> - no manual page for gm2m.
>
> - libpth.{a,so} is installed in the system libdir, which
>conflicts with the installation of the libpth packages
>on most distros.
>
> - There are three letter libraries with pretty generic
>names installed into the system libdir: log, iso, cor,
>min, ulm. At least for log, you have a file conflict
>with another library. Shouldn't these libraries named
>mpre specific, like libgm2log?
>
> Matthias
>
> The installed tree:
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/ulm/libulm.a
> ./usr/lib/x86_64-linux-gnu/libulm.a
and all static libraries are installed twice, not just libulm.a. What is the
correct location?
Matthias
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)
On 08.07.19 23:19, Matthias Klose wrote:
> On 14.06.19 15:09, Gaius Mulley wrote:
>>
>> Hello,
>>
>> here is version two of the patches which introduce Modula-2 into the
>> GCC trunk. The patches include:
>>
>> (*) a patch to allow all front ends to register a lang spec function.
>>(included are patches for all front ends to provide an empty
>> callback function).
>> (*) patch diffs to allow the Modula-2 front end driver to be
>>built using GCC Makefile and friends.
>>
>> The compressed tarball includes:
>>
>> (*) gcc/m2 (compiler driver and lang-spec stuff for Modula-2).
>>Including the need for registering lang spec functions.
>> (*) gcc/testsuite/gm2 (a Modula-2 dejagnu test to ensure that
>>the gm2 driver is built and can understands --version).
>>
>> These patches have been re-written after taking on board the comments
>> found in this thread:
>>
>>https://gcc.gnu.org/ml/gcc-patches/2013-11/msg02620.html
>>
>> it is a revised patch set from:
>>
>>https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00220.html
>>
>> I've run make bootstrap and run the regression tests on trunk and no
>> extra failures occur for all languages touched in the ChangeLog.
>>
>> I'm currently tracking gcc trunk and gcc-9 with gm2 (which works well
>> with amd64/arm64/i386) - these patches are currently simply for the
>> driver to minimise the patch size. There are also > 1800 tests in a
>> dejagnu testsuite for gm2 which can be included at some future time.
>
> I had a look at the GCC 9 version of the patches, with a build including a
> make
> install. Some comments:
>
> - A parallel build (at least with -j4) isn't working. A sequental
>build works fine. I think forcing a sequential build will not
>work well, increasing the build time too much.
>
> - libgm2 multilib builds are not working. //32/libgm2
>is configured, but not built.
>
> - The internal tools in the gcclibdir are installed twice, with
>both vanilla names and prefixed/suffixed names.
>
> - libgm2/configure.a has a libtool version 14:0:0, however all
>shared libraries are installed with soversion 0.
>
> - no manual page for gm2m.
>
> - libpth.{a,so} is installed in the system libdir, which
>conflicts with the installation of the libpth packages
>on most distros.
found out that a system provided libpth can be used. Otoh if you build the
in-tree libpth, it shouldn't be installed, but built as a convenience library,
like libgo using libffi, or libgphobos using zlib.
> - There are three letter libraries with pretty generic
>names installed into the system libdir: log, iso, cor,
>min, ulm. At least for log, you have a file conflict
>with another library. Shouldn't these libraries named
>mpre specific, like libgm2log?
>
> Matthias
>
> The installed tree:
>
> ./usr/bin
> ./usr/bin/x86_64-linux-gnu-gm2-9
> ./usr/bin/x86_64-linux-gnu-gm2m-9
> ./usr/lib/gcc/x86_64-linux-gnu
> ./usr/lib/gcc/x86_64-linux-gnu/9
> ./usr/lib/gcc/x86_64-linux-gnu/9/cc1gm2
> ./usr/lib/gcc/x86_64-linux-gnu/9/gm2l
> ./usr/lib/gcc/x86_64-linux-gnu/9/gm2lcc
> ./usr/lib/gcc/x86_64-linux-gnu/9/gm2lgen
> ./usr/lib/gcc/x86_64-linux-gnu/9/gm2lorder
> ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-cc1gm2-9
> ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2l-9
> ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2lcc-9
> ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2lgen-9
> ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2lorder-9
> ./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2m-9
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/Debug.def
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/Debug.mod
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/Executive.def
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/Executive.mod
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/KeyBoardLEDs.def
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/libcor.a
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/SYSTEM.def
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/SYSTEM.mod
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/TimerHandler.def
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/TimerHandler.mod
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/ChanConsts.def
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/ChanConsts.mod
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/CharClass.def
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/CharClass.mod
> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/ClientSocket.def
> ./usr/lib/gcc/x86_6
Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)
On 14.06.19 15:09, Gaius Mulley wrote:
>
> Hello,
>
> here is version two of the patches which introduce Modula-2 into the
> GCC trunk. The patches include:
>
> (*) a patch to allow all front ends to register a lang spec function.
>(included are patches for all front ends to provide an empty
> callback function).
> (*) patch diffs to allow the Modula-2 front end driver to be
>built using GCC Makefile and friends.
>
> The compressed tarball includes:
>
> (*) gcc/m2 (compiler driver and lang-spec stuff for Modula-2).
>Including the need for registering lang spec functions.
> (*) gcc/testsuite/gm2 (a Modula-2 dejagnu test to ensure that
>the gm2 driver is built and can understands --version).
>
> These patches have been re-written after taking on board the comments
> found in this thread:
>
>https://gcc.gnu.org/ml/gcc-patches/2013-11/msg02620.html
>
> it is a revised patch set from:
>
>https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00220.html
>
> I've run make bootstrap and run the regression tests on trunk and no
> extra failures occur for all languages touched in the ChangeLog.
>
> I'm currently tracking gcc trunk and gcc-9 with gm2 (which works well
> with amd64/arm64/i386) - these patches are currently simply for the
> driver to minimise the patch size. There are also > 1800 tests in a
> dejagnu testsuite for gm2 which can be included at some future time.
I had a look at the GCC 9 version of the patches, with a build including a make
install. Some comments:
- A parallel build (at least with -j4) isn't working. A sequental
build works fine. I think forcing a sequential build will not
work well, increasing the build time too much.
- libgm2 multilib builds are not working. //32/libgm2
is configured, but not built.
- The internal tools in the gcclibdir are installed twice, with
both vanilla names and prefixed/suffixed names.
- libgm2/configure.a has a libtool version 14:0:0, however all
shared libraries are installed with soversion 0.
- no manual page for gm2m.
- libpth.{a,so} is installed in the system libdir, which
conflicts with the installation of the libpth packages
on most distros.
- There are three letter libraries with pretty generic
names installed into the system libdir: log, iso, cor,
min, ulm. At least for log, you have a file conflict
with another library. Shouldn't these libraries named
mpre specific, like libgm2log?
Matthias
The installed tree:
./usr/bin
./usr/bin/x86_64-linux-gnu-gm2-9
./usr/bin/x86_64-linux-gnu-gm2m-9
./usr/lib/gcc/x86_64-linux-gnu
./usr/lib/gcc/x86_64-linux-gnu/9
./usr/lib/gcc/x86_64-linux-gnu/9/cc1gm2
./usr/lib/gcc/x86_64-linux-gnu/9/gm2l
./usr/lib/gcc/x86_64-linux-gnu/9/gm2lcc
./usr/lib/gcc/x86_64-linux-gnu/9/gm2lgen
./usr/lib/gcc/x86_64-linux-gnu/9/gm2lorder
./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-cc1gm2-9
./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2l-9
./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2lcc-9
./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2lgen-9
./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2lorder-9
./usr/lib/gcc/x86_64-linux-gnu/9/x86_64-linux-gnu-gm2m-9
./usr/lib/gcc/x86_64-linux-gnu/9/m2
./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor
./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/Debug.def
./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/Debug.mod
./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/Executive.def
./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/Executive.mod
./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/KeyBoardLEDs.def
./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/libcor.a
./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/SYSTEM.def
./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/SYSTEM.mod
./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/TimerHandler.def
./usr/lib/gcc/x86_64-linux-gnu/9/m2/cor/TimerHandler.mod
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/ChanConsts.def
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/ChanConsts.mod
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/CharClass.def
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/CharClass.mod
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/ClientSocket.def
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/ClientSocket.mod
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/ComplexMath.def
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/ComplexMath.mod
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/ConvStringLong.def
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/ConvStringLong.mod
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/ConvStringReal.def
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/ConvStringReal.mod
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/ConvTypes.def
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/ConvTypes.mod
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/COROUTINES.def
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/COROUTINES.mod
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/ErrnoCategory.def
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/EXCEPTIONS.def
./usr/lib/gcc/x86_64-linux-gnu/9/m2/iso/EXCEPTIONS.mod
Re: [PATCH] [Ada] Make clockid_t type public on GNU/kFreeBSD
On 04.07.19 08:50, Arnaud Charlet wrote: > OK, thanks. checked in. Ok for the gcc-9 branch as well? Matthias >> From: James Clarke >> >> Monotonic_Clock and RT_Resolution in the recently-added s-tpopmo.adb >> call clock_gettime/clock_getres with the integral constants from OSC and >> thus rely on clockid_t being an integral type, so we cannot hide it on >> GNU/kFreeBSD. Instead, make the definition public to match all the other >> implementations. >> >> gcc/ada >> * libgnarl/s-osinte__kfreebsd-gnu.ads (clockid_t): Make type >> definition public. >> (CLOCK_REALTIME): Make value public. >> --- >> gcc/ada/libgnarl/s-osinte__kfreebsd-gnu.ads | 8 ++-- >> 1 file changed, 2 insertions(+), 6 deletions(-) >> >> diff --git a/gcc/ada/libgnarl/s-osinte__kfreebsd-gnu.ads >> b/gcc/ada/libgnarl/s-osinte__kfreebsd-gnu.ads >> index 408187314..b60ffd2c0 100644 >> --- a/gcc/ada/libgnarl/s-osinte__kfreebsd-gnu.ads >> +++ b/gcc/ada/libgnarl/s-osinte__kfreebsd-gnu.ads >> @@ -206,9 +206,8 @@ package System.OS_Interface is >> function nanosleep (rqtp, rmtp : access timespec) return int; >> pragma Import (C, nanosleep, "nanosleep"); >> >> - type clockid_t is private; >> - >> - CLOCK_REALTIME : constant clockid_t; >> + type clockid_t is new int; >> + CLOCK_REALTIME : constant clockid_t := 0; >> >> function clock_gettime >> (clock_id : clockid_t; >> @@ -607,9 +606,6 @@ private >> end record; >> pragma Convention (C, timespec); >> >> - type clockid_t is new int; >> - CLOCK_REALTIME : constant clockid_t := 0; >> - >> type pthread_attr_t is record >>detachstate : int; >>schedpolicy : int; >> -- >> 2.17.1 >>
Re: [RFC] D support for S/390
On 27.04.19 14:08, Iain Buclaw wrote: > On Sat, 27 Apr 2019 at 12:24, Jakub Jelinek wrote: >> >> On Sat, Apr 27, 2019 at 11:26:15AM +0200, Matthias Klose wrote: >>> On 15.03.19 16:49, Robin Dapp wrote: >>>> during the last few days I tried to get D running on s390x (apparently >>>> the first Big Endian platform to try it?). I did not yet go through the >>>> code systematically and add a version(SystemZ) in every place where it >>>> might be needed but rather tried to fix test failures as they arose. >>> >>> this now fails on trunk and the gcc-9-branch with a multilib build: >>> >>> >>> /<>/src/libphobos/libdruntime/core/sys/posix/ucontext.d:769:9: >>> error: static assert "unimpleme >>> nted" >>> 769 | static assert(0, "unimplemented"); >>> | ^ >>> make[10]: *** [Makefile:2149: core/thread.lo] Error 1 >>> make[10]: Leaving directory >>> '/<>/build/s390x-linux-gnu/32/libphobos/libdruntime' >>> make[9]: *** [Makefile:473: all-recursive] Error 1 >>> make[10]: *** [Makefile:2149: core/thread.lo] Error 1 >>> make[10]: Leaving directory >>> '/<>/build/s390x-linux-gnu/32/libphobos/libdruntime' >>> make[9]: *** [Makefile:473: all-recursive] Error 1 >> >> Ugh, can we disable D for GCC 9.1 on s390x then, on the trunk look through >> all files that only use version (SystemZ) and don't use version (S390) at >> least >> find -type f | xargs grep -l SystemZ | xargs grep -L S390 >> ./src/std/uni.d >> ./src/std/math.d >> ./src/std/experimental/allocator/building_blocks/region.d >> ./libdruntime/gcc/sections/elf_shared.d >> ./libdruntime/core/sys/linux/link.d >> ./libdruntime/core/sys/posix/setjmp.d >> ./libdruntime/core/sys/posix/ucontext.d >> ./libdruntime/core/sys/posix/sys/stat.d >> and make sure it works also for s390 31-bit and finally backport to 9.2? >> >> E.g. in src/std/math.d I wonder if it just shouldn't be done through >> version (S390) version = IBMZ_Any; >> version (SystemZ) version = IBMZ_Any; >> and using later version (IBMZ_Any) instead of version (SystemZ). Guess >> in various other spots, except for those where structure sizes are needed. >> >> Robin, have you been testing with --disable-multilib or something similar? >> > > I built all compilers last night from config-list.mk, so I had a ready > cross compiler available. With the following patch, all compiles > successfully with -fsyntax-only for both s390x-linux and s390-linux, > though checking on native hardware would be preferred. builds with the gcc-9 branch and trunk, natively and cross.
Re: [RFC] D support for S/390
On 15.03.19 16:49, Robin Dapp wrote: > Hi, > > during the last few days I tried to get D running on s390x (apparently > the first Big Endian platform to try it?). I did not yet go through the > code systematically and add a version(SystemZ) in every place where it > might be needed but rather tried to fix test failures as they arose. this now fails on trunk and the gcc-9-branch with a multilib build: /<>/src/libphobos/libdruntime/core/sys/posix/ucontext.d:769:9: error: static assert "unimpleme nted" 769 | static assert(0, "unimplemented"); | ^ make[10]: *** [Makefile:2149: core/thread.lo] Error 1 make[10]: Leaving directory '/<>/build/s390x-linux-gnu/32/libphobos/libdruntime' make[9]: *** [Makefile:473: all-recursive] Error 1 make[10]: *** [Makefile:2149: core/thread.lo] Error 1 make[10]: Leaving directory '/<>/build/s390x-linux-gnu/32/libphobos/libdruntime' make[9]: *** [Makefile:473: all-recursive] Error 1
Re: [PATCH] Add target-zlib to top-level configure, use zlib from libphobos
On 29.03.19 23:23, Iain Buclaw wrote: > On Mon, 18 Feb 2019 at 14:26, Matthias Klose wrote: >> >> >> sorry, I didn't mean to propose to rename the option, so >> --with-target-system-zlib=auto sounds fine. > > OK, a bit belated, but here it is --with-target-system-zlib=auto. yes, this does the job.
Re: [patch] PR jit/87808: Allow libgccjit to work without an external gcc driver
On 22.03.19 23:00, David Malcolm wrote: > On Thu, 2019-03-21 at 12:26 +0100, Matthias Klose wrote: >> Fix PR jit/87808, the embedded driver still needing the external gcc >> driver to >> find the gcc_lib_dir. This can happen in a packaging context when >> libgccjit >> doesn't depend on the gcc package, but just on binutils and libgcc- >> dev packages. >> libgccjit probably could use /proc/self/maps to find the gcc_lib_dir, >> but that >> doesn't seem to be very portable. >> >> Ok for the trunk and the branches? >> >> Matthias > > [CCing the jit list] > > I've been trying to reproduce this bug in a working copy, and failing. > > Matthias, do you have a recipe you've been using to reproduce this? the JIT debug log shows the driver names that it wants to call. Are you sure that this driver isn't available anywhere? I configure the gcc build with --program-suffix=-8 --program-prefix=x86_64-linux-gnu-, and that one was only available in one place, /usr/bin. Matthias
Re: [PATCH] Fix PR89505
On 26.02.19 15:06, Richard Biener wrote: > > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk > sofar. That was backported to the gcc-8 branch, and now Richard approved the backport the gcc-7 branch. Matthias
[patch] PR jit/87808: Allow libgccjit to work without an external gcc driver
Fix PR jit/87808, the embedded driver still needing the external gcc driver to
find the gcc_lib_dir. This can happen in a packaging context when libgccjit
doesn't depend on the gcc package, but just on binutils and libgcc-dev packages.
libgccjit probably could use /proc/self/maps to find the gcc_lib_dir, but that
doesn't seem to be very portable.
Ok for the trunk and the branches?
Matthias
# DP: Fix PR jit/87808.
* Make-lang.in (CFLAGS-jit/jit-playback.o): Pass fallback
GCC_EXEC_PREFIX.
* jit-playback.c (invoke_embedded_driver): Use fallback GCC_EXEC_PREFIX
when external driver is not present.
--- a/src/gcc/jit/Make-lang.in
+++ b/src/gcc/jit/Make-lang.in
@@ -84,6 +84,9 @@
jit/jit-spec.o \
gcc.o
+CFLAGS-jit/jit-playback.o += \
+ -DFALLBACK_GCC_EXEC_PREFIX=\"$(libdir)/gcc/$(target_subdir)/$(version)\"
+
# Use strict warnings for this front end.
jit-warn = $(STRICT_WARN)
--- a/src/gcc/jit/jit-playback.c
+++ b/src/gcc/jit/jit-playback.c
@@ -39,6 +39,7 @@
#include "opt-suggestions.h"
#include "gcc.h"
#include "diagnostic.h"
+#include "file-find.h"
#include
@@ -2482,7 +2483,31 @@
playback::context::
invoke_embedded_driver (const vec *argvec)
{
+ static char* gcc_driver_file = NULL;
+
JIT_LOG_SCOPE (get_logger ());
+
+ /* process_command() uses make_relative_prefix(), searches PATH
+ for the external driver, which might not be found. In this case
+ fall back to the configured default. */
+#ifdef FALLBACK_GCC_EXEC_PREFIX
+ if (gcc_driver_file == NULL && ::getenv ("GCC_EXEC_PREFIX") == NULL)
+{
+ struct path_prefix path;
+
+ prefix_from_env ("PATH", );
+ gcc_driver_file = find_a_file (, gcc_driver_name, X_OK);
+ if (gcc_driver_file == NULL)
+{
+ char *str = concat ("GCC_EXEC_PREFIX=",
+ FALLBACK_GCC_EXEC_PREFIX, NULL);
+ ::putenv (str);
+ log ("gcc driver %s not found, using fallback GCC_EXEC_PREFIX=%s",
+ gcc_driver_name, FALLBACK_GCC_EXEC_PREFIX);
+}
+}
+#endif
+
driver d (true, /* can_finalize */
false); /* debug */
int result = d.main (argvec->length (),
Re: [C++ PATCH] Toplevel asm volatile (PR c++/89585)
On 07.03.19 00:39, Jakub Jelinek wrote: > Hi! > > The following patch tries to improve diagnostics of toplevel asm qualifiers > in C++ by actually parsing them and complaining if they appear at toplevel, > instead of just emitting a parse error that ( is expected, e.g. some > versions of Qt do use toplevel asm volatile and apparently the Qt code is > copied into lots of various projects. > > In addition to that, it mentions in the documentation that qualifiers are > not allowed at toplevel asm statements; apparently our documentation at > least from r220506 for GCC 5 says that at toplevel Basic Asm needs to be > used and for Basic Asm lists volatile qualifier as optional and its behavior > (that it is ignored for Basic Asm). Makes me wonder if we don't want to > keep accepting/ignoring volatile at toplevel for both C and C++ instead of > rejecting it (and rejecting just the other qualifiers). Thoughts on this? > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > Attached is an untested backport of this patch to 8.4, which does allow > asm volatile at toplevel, so that we don't break in 8.4 what has been > accepted in 8.2. Ok if it passes bootstrap/regtest there? isn't that required for the gcc-7 branch as well? r267536 backported these patches to the 7 branch as well. Matthias
Re: [PATCH] Fix -print-multiarch for powerpc{,le}-linux (PR target/89587)
On 05.03.19 16:22, Jakub Jelinek wrote:
> Hi!
>
> powerpc-linux-gnu is apparently the only target that provides
> MULTIARCH_DIRNAME unconditionally, all others properly wrap that with
> if_multiarch, which decides if it should be used (--enable-multiarch,
> or if the test for automatic multiarch succeeds), or should be empty
> (--disable-multiarch, or the auto test failed).
>
> Fixed thusly, bootstrapped/regtested on powerpc64{,le}-linux, also
> tested without and with this patch in powerpc-linux non-bootstrap and
> testing what -print-multiarch prints. Ok for trunk?
>
> 2019-03-05 Jakub Jelinek
>
> PR target/89587
> * config/rs6000/t-linux (MULTIARCH_DIRNAME): Set to non-empty only
> if_multiarch.
>
> --- gcc/config/rs6000/t-linux.jj 2017-06-13 22:01:42.887779444 +0200
> +++ gcc/config/rs6000/t-linux 2019-03-05 11:07:55.076963345 +0100
> @@ -4,7 +4,7 @@ ifeq (,$(filter $(with_cpu),$(SOFT_FLOAT
> ifneq (,$(findstring powerpc64,$(target)))
> MULTILIB_OSDIRNAMES := .=../lib64$(call if_multiarch,:powerpc64-linux-gnu)
> else
> -MULTIARCH_DIRNAME := powerpc-linux-gnu
> +MULTIARCH_DIRNAME := $(call if_multiarch,powerpc-linux-gnu)
> endif
> ifneq (,$(findstring powerpcle,$(target)))
> MULTIARCH_DIRNAME := $(subst -linux,le-linux,$(MULTIARCH_DIRNAME))
looks fine, although I cannot approve it.
Matthias
Re: [PATCH] Add target-zlib to top-level configure, use zlib from libphobos
On 17.02.19 17:07, Iain Buclaw wrote: > On Sat, 16 Feb 2019 at 13:44, Matthias Klose wrote: >> >> On 12.02.19 21:54, Iain Buclaw wrote: >>> On Tue, 12 Feb 2019 at 10:40, Richard Biener >>> wrote: >>>> >>>> On Sat, Feb 9, 2019 at 10:37 AM Iain Buclaw wrote: >>>>> >>>>> On Mon, 28 Jan 2019 at 13:10, Richard Biener >>>>> wrote: >>>>>> >>>>>> On Mon, Jan 21, 2019 at 7:35 PM Iain Buclaw >>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Following on from the last, this adds target-zlib to target_libraries >>>>>>> and updates libphobos build scripts to link to libz_convenience.a. >>>>>>> The D front-end already has target-zlib in d/config-lang.in. >>>>>>> >>>>>>> Is the top-level part OK? I considered disabling target-zlib if >>>>>>> libphobos is not being built, but decided against unless it's >>>>>>> requested. >>>>>> >>>>>> Hmm, you overload --with-system-zlib to apply to both host and target >>>>>> (I guess it already applied to build), not sure if that's really desired? >>>>>> I suppose libphobos is the first target library linking against zlib? >>>>>> >>>>> >>>>> Originally, libgcj linked to zlib. >>>>> >>>>>> You are also falling back to in-tree zlib if --with-system-zlib was >>>>>> specified but no zlib was found - I guess for cross builds that >>>>>> will easily get not noticed... The toplevel --with-system-zlib makes >>>>>> it much harder and simply fails. >>>>>> >>>>> >>>>> OK, so keep --with-target-system-zlib to distinguish between the two? >>>> >>>> Yes, and fail if specificed but not found. >>>> >>> >>> Updated patch. Checked that it correctly fails when >>> --with-target-system-zlib and zlib missing. >> >> For the GC enabled libobjc I added an --enable-objc-gc=auto to fall-back to >> the >> in-tree library when no system library is found. Could you do the same for >> zlib? >> There might be some multilib variants missing in distros. >> > > Granted that zlib is a standalone module within phobos, there's not > much trouble giving the option to disable it entirely. > > Though I would prefer if the meaning of it were > --with-target-system-zlib=auto. sorry, I didn't mean to propose to rename the option, so --with-target-system-zlib=auto sounds fine.
Re: [PATCH] Add target-zlib to top-level configure, use zlib from libphobos
On 12.02.19 21:54, Iain Buclaw wrote: > On Tue, 12 Feb 2019 at 10:40, Richard Biener > wrote: >> >> On Sat, Feb 9, 2019 at 10:37 AM Iain Buclaw wrote: >>> >>> On Mon, 28 Jan 2019 at 13:10, Richard Biener >>> wrote: On Mon, Jan 21, 2019 at 7:35 PM Iain Buclaw wrote: > > Hi, > > Following on from the last, this adds target-zlib to target_libraries > and updates libphobos build scripts to link to libz_convenience.a. > The D front-end already has target-zlib in d/config-lang.in. > > Is the top-level part OK? I considered disabling target-zlib if > libphobos is not being built, but decided against unless it's > requested. Hmm, you overload --with-system-zlib to apply to both host and target (I guess it already applied to build), not sure if that's really desired? I suppose libphobos is the first target library linking against zlib? >>> >>> Originally, libgcj linked to zlib. >>> You are also falling back to in-tree zlib if --with-system-zlib was specified but no zlib was found - I guess for cross builds that will easily get not noticed... The toplevel --with-system-zlib makes it much harder and simply fails. >>> >>> OK, so keep --with-target-system-zlib to distinguish between the two? >> >> Yes, and fail if specificed but not found. >> > > Updated patch. Checked that it correctly fails when > --with-target-system-zlib and zlib missing. For the GC enabled libobjc I added an --enable-objc-gc=auto to fall-back to the in-tree library when no system library is found. Could you do the same for zlib? There might be some multilib variants missing in distros. Matthias
Re: libgo patch committed: Add S/390 support to internal/cpu package
On 15.02.19 15:52, Ian Lance Taylor wrote: > This patch by Robin Dapp adds S/390 support to the internal/cpu > package. This partially addresses PR 89123. I bootstrapped it on > x86_64-pc-linux-gnu, which means little. Committed to mainline. fails in the -m31 multilib variant with libtool: compile: /<>/build/./gcc/xgcc -B/<>/build/./gcc/ -B/usr/s390x-linux-gnu/bin/ -B/usr/s390x-linux-gnu/lib/ -isystem /usr/s390x-linux-gnu/include -isystem /usr/s390x-linux-gnu/sys-include -isys tem /<>/build/sys-include -m31 -DHAVE_CONFIG_H -I. -I../../../../src/libgo -I ../../../../src/libgo/ runtime -I../../../../src/libgo/../libffi/include -I../libffi/include -pthread -L../libatomic/.libs -fexceptions -fnon-call-exceptions -fno-stack-protector -fsplit-stack -Wall -Wextra -Wwrite-strings -Wcast-qual -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I ../../../../src/libgo/../libgcc -I ../../../../src/libgo/../libback trace -I ../../../gcc/include -g -O2 -m31 -c ../../../../src/libgo/go/internal/cpu/cpu_gccgo.c -fPIC -DPIC -o in ternal/cpu/.libs/cpu_gccgo.o ../../../../src/libgo/go/internal/cpu/cpu_gccgo.c: Assembler messages: ../../../../src/libgo/go/internal/cpu/cpu_gccgo.c:91: Error: Unrecognized opcode: `lghi' ../../../../src/libgo/go/internal/cpu/cpu_gccgo.c:105: Error: Unrecognized opcode: `lghi' ../../../../src/libgo/go/internal/cpu/cpu_gccgo.c:119: Error: Unrecognized opcode: `lghi' ../../../../src/libgo/go/internal/cpu/cpu_gccgo.c:134: Error: Unrecognized opcode: `lghi' ../../../../src/libgo/go/internal/cpu/cpu_gccgo.c:149: Error: Unrecognized opcode: `lghi' ../../../../src/libgo/go/internal/cpu/cpu_gccgo.c:164: Error: Unrecognized opcode: `lghi' ../../../../src/libgo/go/internal/cpu/cpu_gccgo.c:179: Error: Unrecognized opcode: `lghi' make[10]: *** [Makefile:2899: internal/cpu/cpu_gccgo.lo] Error 1 make[10]: *** Waiting for unfinished jobs make[10]: Leaving directory '/<>/build/s390x-linux-gnu/32/libgo' make[9]: *** [Makefile:2242: all-recursive] Error 1 make[9]: Leaving directory '/<>/build/s390x-linux-gnu/32/libgo' make[8]: *** [Makefile:1167: all] Error 2 make[8]: Leaving directory '/<>/build/s390x-linux-gnu/32/libgo' make[7]: *** [Makefile:3062: multi-do] Error 1 using binutils 2.32
Re: [PATCH] Updated patches for the port of gccgo to GNU/Hurd
On 07.02.19 06:04, Ian Lance Taylor wrote: > On Thu, Jan 31, 2019 at 7:40 AM Svante Signell > wrote: >> >> As advised by the Debian gcc maintainer Matthias Klose and golang >> developer Ian Lance Taylor I'm re-submitting the patches for >> the port of gccgo to GNU/Hurd again. Now GOOS value is changed from gnu >> to hurd as requested. >> >> The 12 patches are: >> src_libgo_build.diff >> src_libgo_runtime.diff >> src_libgo_go_crypto.diff >> src_libgo_go_internal.diff >> src_libgo_go_net.diff >> src_libgo_go_os.diff >> src_libgo_go_runtime.diff >> src_libgo_go_syscall.diff >> src_libgo_go_test.diff >> >> src_libgo_testsuite_gotest.diff >> add-hurd-to-libgo-headers.diff >> add-hurd-to-libgo-test-headers.diff > > Thanks. I've committed versions of all of these patches other than > src_libgo_testsuite_gotest.diff. I omitted that one because as far as > I can tell it won't work. While the original code may not run on the > Hurd, the modified version won't work. > > I made various changes, and I'm sure I broke some things. Take a look > at GCC trunk and see how it seems. libtool: compile: /<>/build/./gcc/gccgo -B/<>/build/./gcc/ -B/usr/i686-gnu/bin/ -B/usr/i6 86-gnu/lib/ -isystem /usr/i686-gnu/include -isystem /usr/i686-gnu/sys-include -isystem /<>/build/sys-in clude -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=syscall -fPIC -o .libs/syscall.o gccgo: fatal error: no input files compilation terminated. Makefile:2844: recipe for target 'syscall.lo' failed make[6]: *** [syscall.lo] Error 1 make[6]: Leaving directory '/<>/build/i686-gnu/libgo' Makefile:2242: recipe for target 'all-recursive' failed make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory '/<>/build/i686-gnu/libgo' Makefile:1167: recipe for target 'all' failed make[4]: *** [all] Error 2 make[4]: Leaving directory '/<>/build/i686-gnu/libgo' Makefile:20078: recipe for target 'all-target-libgo' failed make[3]: *** [all-target-libgo] Error 2 make[3]: Leaving directory '/<>/build' Makefile:24129: recipe for target 'bootstrap' failed make[2]: *** [bootstrap] Error 2
Re: libgo patch committed: Update to Go1.12beta2
On 18.01.19 20:04, Ian Lance Taylor wrote: > I have committed a patch to update libgo to the Go 1.12beta2 release. > > As usual this sort of update is too large to include all changes in > this e-mail. I've included changes to gccgo-specific files below. > > Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed > to mainline. this broke the ARM32 builds: libtool: compile: /<>/build/./gcc/gccgo -B/<>/build/./gcc/ -B/usr/arm-linux-gnueabihf/bin/ -B/usr/arm-linux-gnueabihf/lib/ -isystem /usr /arm-linux-gnueabihf/include -isystem /usr/arm-linux-gnueabihf/sys-include -isystem /<>/build/sys-include -fchecking=1 -O2 -g -I . -c -fgo-pkgpath=int ernal/cpu ../../../src/libgo/go/internal/cpu/cpu.go cpugen.go -fPIC -o internal/.libs/cpu.o ../../../src/libgo/go/internal/cpu/cpu.go:138:2: error: reference to undefined name 'doinit' 138 | doinit() | ^ make[6]: *** [Makefile:2843: internal/cpu.lo] Error 1 make[6]: Leaving directory '/<>/build/arm-linux-gnueabihf/libgo' make[5]: *** [Makefile:2241: all-recursive] Error 1 on the HURD (without any local patches): gccgo: fatal error: no input files compilation terminated. Makefile:2843: recipe for target 'runtime.lo' failed make[6]: *** [runtime.lo] Error 1 make[6]: Leaving directory '/<>/build/i686-gnu/libgo' Makefile:2241: recipe for target 'all-recursive' failed make[5]: *** [all-recursive] Error 1
Re: [gofrontend-dev] Re: libgo patch committed: Add precise stack scan support
Cherry, see https://gcc.gnu.org/ml/gcc-testresults/2018-12/msg02241.html https://gcc.gnu.org/ml/gcc-testresults/2018-12/msg02240.html still shows ~180 test failures on ARM32. Sorry, no access to an ARM32 box until next year. Matthias On 13.12.18 00:27, Ian Lance Taylor wrote: > On Wed, Dec 12, 2018 at 8:10 AM Cherry Zhang wrote: >> >> Thank you, Matthias! >> >> From the log, essentially all the tests aborted. The only place the new code >> can cause abort on all programs that I can think of is in the runtime >> startup code, probestackmaps, which calls value_size, which aborts due to an >> unhandled case. I haven't been able to try out on an ARM machine, but I >> managed to cross-compile a Go program and visually inspect the exception >> table. The type table's encoding is DW_EH_PE_absptr, which is indeed not >> handled, which will cause abort. >> >> I send https://go-review.googlesource.com/c/gofrontend/+/153857 (also as >> below). Hopefully this will fix the problem. >> >> Thanks, >> Cherry >> >> diff --git a/libgo/runtime/go-unwind.c b/libgo/runtime/go-unwind.c >> index c44755f9..f4bbfb60 100644 >> --- a/libgo/runtime/go-unwind.c >> +++ b/libgo/runtime/go-unwind.c >> @@ -318,6 +318,8 @@ value_size (uint8_t encoding) >>case DW_EH_PE_sdata8: >>case DW_EH_PE_udata8: >> return 8; >> + case DW_EH_PE_absptr: >> +return sizeof(uintptr); >>default: >> break; >> } > > > Thanks. > > Committed to mainline. > > Ian > > > >> On Tue, Dec 11, 2018 at 7:03 PM Matthias Klose wrote: >>> >>> On 11.12.18 22:01, Cherry Zhang wrote: >>>> On Tue, Dec 11, 2018 at 3:51 PM Ian Lance Taylor wrote: >>>> >>>>> On Tue, Dec 11, 2018 at 6:52 AM Matthias Klose wrote: >>>>>> >>>>>> On 10.12.18 16:54, Cherry Zhang wrote: >>>>>>> On Mon, Dec 10, 2018 at 1:41 AM Matthias Klose >>>>> wrote: >>>>>>> >>>>>>>> On 06.12.18 00:09, Ian Lance Taylor wrote: >>>>>>>>> This libgo patch by Cherry Zhang adds support for precise stack >>>>>>>>> scanning to the Go runtime. This uses per-function stack maps stored >>>>>>>>> in the exception tables in the language-specific data area. The >>>>>>>>> compiler needs to generate these stack maps; currently this is only >>>>>>>>> done by a version of LLVM, not by GCC. Each safepoint in a function >>>>>>>>> is associated with a (real or dummy) landing pad, and its "type info" >>>>>>>>> in the exception table is a pointer to the stack map. When a stack is >>>>>>>>> scanned, the stack map is found by the stack unwinding code. >>>>>>>>> >>>>>>>>> For precise stack scan we need to unwind the stack. There are three >>>>>>>> cases: >>>>>>>>> >>>>>>>>> - If a goroutine is scanning its own stack, it can unwind the stack >>>>>>>>> and scan the frames. >>>>>>>>> >>>>>>>>> - If a goroutine is scanning another, stopped, goroutine, it cannot >>>>>>>>> directly unwind the target stack. We handle this by switching >>>>>>>>> (runtime.gogo) to the target g, letting it unwind and scan the stack, >>>>>>>>> and switch back. >>>>>>>>> >>>>>>>>> - If we are scanning a goroutine that is blocked in a syscall, we >>>>> send >>>>>>>>> a signal to the target goroutine's thread, and let the signal handler >>>>>>>>> unwind and scan the stack. Extra care is needed as this races with >>>>>>>>> enter/exit syscall. >>>>>>>>> >>>>>>>>> Currently this is only implemented on GNU/Linux. >>>>>>>>> >>>>>>>>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed >>>>>>>>> to mainline. >>>>>>>> >>>>>>>> this broke the libgo build on ARM32: >>>>>>>> >>>>>>>> ../../../src/libgo/runtime/go-unwind.c: In function >>>>>>>> 'scanstackwithmap_callback': >>>&g
Re: [gofrontend-dev] Re: libgo patch committed: Add precise stack scan support
On 11.12.18 22:01, Cherry Zhang wrote: > On Tue, Dec 11, 2018 at 3:51 PM Ian Lance Taylor wrote: > >> On Tue, Dec 11, 2018 at 6:52 AM Matthias Klose wrote: >>> >>> On 10.12.18 16:54, Cherry Zhang wrote: >>>> On Mon, Dec 10, 2018 at 1:41 AM Matthias Klose >> wrote: >>>> >>>>> On 06.12.18 00:09, Ian Lance Taylor wrote: >>>>>> This libgo patch by Cherry Zhang adds support for precise stack >>>>>> scanning to the Go runtime. This uses per-function stack maps stored >>>>>> in the exception tables in the language-specific data area. The >>>>>> compiler needs to generate these stack maps; currently this is only >>>>>> done by a version of LLVM, not by GCC. Each safepoint in a function >>>>>> is associated with a (real or dummy) landing pad, and its "type info" >>>>>> in the exception table is a pointer to the stack map. When a stack is >>>>>> scanned, the stack map is found by the stack unwinding code. >>>>>> >>>>>> For precise stack scan we need to unwind the stack. There are three >>>>> cases: >>>>>> >>>>>> - If a goroutine is scanning its own stack, it can unwind the stack >>>>>> and scan the frames. >>>>>> >>>>>> - If a goroutine is scanning another, stopped, goroutine, it cannot >>>>>> directly unwind the target stack. We handle this by switching >>>>>> (runtime.gogo) to the target g, letting it unwind and scan the stack, >>>>>> and switch back. >>>>>> >>>>>> - If we are scanning a goroutine that is blocked in a syscall, we >> send >>>>>> a signal to the target goroutine's thread, and let the signal handler >>>>>> unwind and scan the stack. Extra care is needed as this races with >>>>>> enter/exit syscall. >>>>>> >>>>>> Currently this is only implemented on GNU/Linux. >>>>>> >>>>>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed >>>>>> to mainline. >>>>> >>>>> this broke the libgo build on ARM32: >>>>> >>>>> ../../../src/libgo/runtime/go-unwind.c: In function >>>>> 'scanstackwithmap_callback': >>>>> ../../../src/libgo/runtime/go-unwind.c:754:18: error: >> '_URC_NORMAL_STOP' >>>>> undeclared (first use in this function) >>>>> 754 | return _URC_NORMAL_STOP; >>>>> | ^~~~ >>>>> ../../../src/libgo/runtime/go-unwind.c:754:18: note: each undeclared >>>>> identifier >>>>> is reported only once for each function i >>>>> t appears in >>>>> ../../../src/libgo/runtime/go-unwind.c: In function >>>>> 'probestackmaps_callback': >>>>> ../../../src/libgo/runtime/go-unwind.c:802:10: error: >> '_URC_NORMAL_STOP' >>>>> undeclared (first use in this function) >>>>> 802 | return _URC_NORMAL_STOP; >>>>> | ^~~~ >>>>> ../../../src/libgo/runtime/go-unwind.c:803:1: warning: control >> reaches end >>>>> of >>>>> non-void function [-Wreturn-type] >>>>> 803 | } >>>>> | ^ >>>>> make[6]: *** [Makefile:1474: runtime/go-unwind.lo] Error 1 >>>>> make[6]: Leaving directory >>>>> '/<>/build/arm-linux-gnueabihf/libgo' >>>>> >>>>> >>>> Hell Matthias, >>>> >>>> Thank you for the report. And sorry about the breakage. Does >>>> https://go-review.googlesource.com/c/gofrontend/+/153417 (or the patch >>>> below) fix ARM32 build? I don't have an ARM32 machine at hand to test. >>> >>> this fixes the build. >>> >>> currently running the testsuite, almost every test case core dumps on >>> arm-linux-gnueabihf >> >> I committed Cherry's patch to trunk, since it looks reasonable to me. >> Cherry, Matthias, let me know if you figure out why programs are >> failing. >> >> > Thank you. > > I don't know for the moment. I'm trying to find an ARM32 machine so I can > test. > > Matthias, is it convenient for you to share a stack trace for the failing > programs? That would be very helpful. Thanks! I'll do a local build this weekend. For now you find the build log at https://launchpad.net/ubuntu/+source/gcc-snapshot/1:20181210-0ubuntu1/+build/15759748
Re: [gofrontend-dev] Re: libgo patch committed: Add precise stack scan support
On 10.12.18 16:54, Cherry Zhang wrote: > On Mon, Dec 10, 2018 at 1:41 AM Matthias Klose wrote: > >> On 06.12.18 00:09, Ian Lance Taylor wrote: >>> This libgo patch by Cherry Zhang adds support for precise stack >>> scanning to the Go runtime. This uses per-function stack maps stored >>> in the exception tables in the language-specific data area. The >>> compiler needs to generate these stack maps; currently this is only >>> done by a version of LLVM, not by GCC. Each safepoint in a function >>> is associated with a (real or dummy) landing pad, and its "type info" >>> in the exception table is a pointer to the stack map. When a stack is >>> scanned, the stack map is found by the stack unwinding code. >>> >>> For precise stack scan we need to unwind the stack. There are three >> cases: >>> >>> - If a goroutine is scanning its own stack, it can unwind the stack >>> and scan the frames. >>> >>> - If a goroutine is scanning another, stopped, goroutine, it cannot >>> directly unwind the target stack. We handle this by switching >>> (runtime.gogo) to the target g, letting it unwind and scan the stack, >>> and switch back. >>> >>> - If we are scanning a goroutine that is blocked in a syscall, we send >>> a signal to the target goroutine's thread, and let the signal handler >>> unwind and scan the stack. Extra care is needed as this races with >>> enter/exit syscall. >>> >>> Currently this is only implemented on GNU/Linux. >>> >>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed >>> to mainline. >> >> this broke the libgo build on ARM32: >> >> ../../../src/libgo/runtime/go-unwind.c: In function >> 'scanstackwithmap_callback': >> ../../../src/libgo/runtime/go-unwind.c:754:18: error: '_URC_NORMAL_STOP' >> undeclared (first use in this function) >> 754 | return _URC_NORMAL_STOP; >> | ^~~~ >> ../../../src/libgo/runtime/go-unwind.c:754:18: note: each undeclared >> identifier >> is reported only once for each function i >> t appears in >> ../../../src/libgo/runtime/go-unwind.c: In function >> 'probestackmaps_callback': >> ../../../src/libgo/runtime/go-unwind.c:802:10: error: '_URC_NORMAL_STOP' >> undeclared (first use in this function) >> 802 | return _URC_NORMAL_STOP; >> | ^~~~ >> ../../../src/libgo/runtime/go-unwind.c:803:1: warning: control reaches end >> of >> non-void function [-Wreturn-type] >> 803 | } >> | ^ >> make[6]: *** [Makefile:1474: runtime/go-unwind.lo] Error 1 >> make[6]: Leaving directory >> '/<>/build/arm-linux-gnueabihf/libgo' >> >> > Hell Matthias, > > Thank you for the report. And sorry about the breakage. Does > https://go-review.googlesource.com/c/gofrontend/+/153417 (or the patch > below) fix ARM32 build? I don't have an ARM32 machine at hand to test. this fixes the build. currently running the testsuite, almost every test case core dumps on arm-linux-gnueabihf Matthias
Re: libgo patch committed: Add precise stack scan support
On 06.12.18 00:09, Ian Lance Taylor wrote: > This libgo patch by Cherry Zhang adds support for precise stack > scanning to the Go runtime. This uses per-function stack maps stored > in the exception tables in the language-specific data area. The > compiler needs to generate these stack maps; currently this is only > done by a version of LLVM, not by GCC. Each safepoint in a function > is associated with a (real or dummy) landing pad, and its "type info" > in the exception table is a pointer to the stack map. When a stack is > scanned, the stack map is found by the stack unwinding code. > > For precise stack scan we need to unwind the stack. There are three cases: > > - If a goroutine is scanning its own stack, it can unwind the stack > and scan the frames. > > - If a goroutine is scanning another, stopped, goroutine, it cannot > directly unwind the target stack. We handle this by switching > (runtime.gogo) to the target g, letting it unwind and scan the stack, > and switch back. > > - If we are scanning a goroutine that is blocked in a syscall, we send > a signal to the target goroutine's thread, and let the signal handler > unwind and scan the stack. Extra care is needed as this races with > enter/exit syscall. > > Currently this is only implemented on GNU/Linux. > > Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed > to mainline. this broke the libgo build on ARM32: ../../../src/libgo/runtime/go-unwind.c: In function 'scanstackwithmap_callback': ../../../src/libgo/runtime/go-unwind.c:754:18: error: '_URC_NORMAL_STOP' undeclared (first use in this function) 754 | return _URC_NORMAL_STOP; | ^~~~ ../../../src/libgo/runtime/go-unwind.c:754:18: note: each undeclared identifier is reported only once for each function i t appears in ../../../src/libgo/runtime/go-unwind.c: In function 'probestackmaps_callback': ../../../src/libgo/runtime/go-unwind.c:802:10: error: '_URC_NORMAL_STOP' undeclared (first use in this function) 802 | return _URC_NORMAL_STOP; | ^~~~ ../../../src/libgo/runtime/go-unwind.c:803:1: warning: control reaches end of non-void function [-Wreturn-type] 803 | } | ^ make[6]: *** [Makefile:1474: runtime/go-unwind.lo] Error 1 make[6]: Leaving directory '/<>/build/arm-linux-gnueabihf/libgo'
Re: [RS6000] Use config/linux.h for powerpc*-*-linux*
On 27.11.18 00:56, Alan Modra wrote: > On Mon, Nov 26, 2018 at 05:16:38PM -0600, Segher Boessenkool wrote: >> On Mon, Nov 12, 2018 at 09:56:37PM +1030, Alan Modra wrote: >>> Using the macros in config/linux.h rather than duplicating them helps >>> stop future bitrot, and repairs existing bitrot (4 choices for libc in >>> linux.h, fewer in the rs6000 files not that it matters much). Also >>> fixes the fact that __gnu_linux__ was always defined rather than just >>> when glibc was the libc of choice. >> >> Sorry for the slow review. This is okay for trunk. Thanks! > > Thanks, committed revision 266493. would that be appropriate to backport to the 7 and 8 branches as well?
Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.
On 26.11.18 13:20, Martin Liška wrote: > On 11/23/18 7:08 PM, Joseph Myers wrote: >> In the multiarch case, do you want >> /include/finclude/ or >> /include//finclude? (This is where I'd hope Debian >> / Ubuntu GCC people would comment.) > > Mathias can you please reply to this? this should not matter, as long as you use the multilib name, and the correct directory is used with the -m32/-m64/-mabi options. Are other compilers like a clang based compiler supposed to access this directory as well? In that case the include directories should be documented. One more question: Will GCC itself install header files in these directories, or will you have different directories depending on the GCC version (or gfortran module version)? Matthias
Re: not posted ada patch breaks ada build on alpha-linux-gnu
On 26.11.18 14:30, Arnaud Charlet wrote: >> that fixes the build, taken from the sparc64 file. not sure if that is >> appropriate. > > The patch looks good, you can go ahead and commit it. done. >> The build continues, but then fails with: >> >> /home/packages/cross/9/p/gcc-cross-ports/gcc/build/./gcc/xgcc >> -B/home/packages/cross/9/p/gcc-cross-ports/gcc/build/./gcc/ - >> B/usr/alpha-linux-gnu/bin/ -B/usr/alpha-linux-gnu/lib/ -isystem >> /usr/alpha-linux-gnu/include -isystem /usr/alpha-linux-gnu/ >> sys-include -isystem >> /home/packages/cross/9/p/gcc-cross-ports/gcc/build/sys-include-c >> -g -O2 -W >> -Wall -gnatpg -nostdi >> nc -gnatn s-secsta.adb -o s-secsta.o >> >> raised STORAGE_ERROR : stack overflow or erroneous memory access > > This is definitely an unrelated issue. opened PR ada/88200. Matthias
Re: not posted ada patch breaks ada build on alpha-linux-gnu
On 26.11.18 10:22, Arnaud Charlet wrote: >> r266136 broke the ada build on alpha-linux-gnu, filed as PR88191. I didn't >> find this patch posted to gcc-patches. > > Thanks for the heads up. > > This is this change: > > [Ada] Update signal constants for GNU/Linux > > Add the signal SIGSYS and mark the glibc reserved real-time signals > (32-34) as reserved rather than not maskable. > > 2018-11-14 Patrick Bernardi > > gcc/ada/ > > * libgnarl/a-intnam__linux.ads: Add SIGSYS. > * libgnarl/s-linux__alpha.ads, libgnarl/s-linux__android.ads, > libgnarl/s-linux__hppa.ads, libgnarl/s-linux__mips.ads, > libgnarl/s-linux__riscv.ads, libgnarl/s-linux__sparc.ads, > libgnarl/s-linux__x32.ads: Rename SIGLTHRRES, SIGLTHRCAN and > SIGLTHRDBG to SIG32, SIG33 and SIG34 as their names are > implementation specific. > * libgnarl/s-osinte__linux.ads, libgnarl/s-linux.ads: Add > SIGSYS. Move SIG32, SIG33 and SIG34 from the unmasked list to > the reserved list. > > Pat, can you have a look? Matthias, can you suggest a suitable change since > we don't have access to an alpha-linux setup? > that fixes the build, taken from the sparc64 file. not sure if that is appropriate. --- gcc/ada/libgnarl/s-linux__alpha.ads (revision 266457) +++ gcc/ada/libgnarl/s-linux__alpha.ads (working copy) @@ -87,6 +87,7 @@ SIGKILL: constant := 9; -- kill (cannot be caught or ignored) SIGBUS : constant := 10; -- bus error SIGSEGV: constant := 11; -- segmentation violation + SIGSYS : constant := 12; -- bad system call SIGPIPE: constant := 13; -- write on a pipe with no one to read it SIGALRM: constant := 14; -- alarm clock SIGTERM: constant := 15; -- software termination signal from kill The build continues, but then fails with: /home/packages/cross/9/p/gcc-cross-ports/gcc/build/./gcc/xgcc -B/home/packages/cross/9/p/gcc-cross-ports/gcc/build/./gcc/ - B/usr/alpha-linux-gnu/bin/ -B/usr/alpha-linux-gnu/lib/ -isystem /usr/alpha-linux-gnu/include -isystem /usr/alpha-linux-gnu/ sys-include -isystem /home/packages/cross/9/p/gcc-cross-ports/gcc/build/sys-include-c -g -O2 -W -Wall -gnatpg -nostdi nc -gnatn s-secsta.adb -o s-secsta.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[8]: *** [../gcc-interface/Makefile:299: s-secsta.o] Error 1
[patch] [jit] Fix compilation of jit test with -Wformat-security
test-long-names.c fails to build when -Wformat-security is turned on. Fixed by the below patch. Alternatives would be to use a plain strcpy, or to turn off the option in a dg header. Ok to commit, including active branches? Matthias gcc/testsuite/ 2018-11-26 Matthias Klose * jit.dg/test-long-names.c: Fix build with -Wformat-security. Index: gcc/testsuite/jit.dg/test-long-names.c === --- gcc/testsuite/jit.dg/test-long-names.c (revision 266426) +++ gcc/testsuite/jit.dg/test-long-names.c (working copy) @@ -24,7 +24,7 @@ int i; /* Begin with the given prefix: */ - sprintf (buffer, prefix); + sprintf (buffer, "%s", prefix); /* Populate the rest of the buffer with 0123456789 repeatedly: */ for (i = strlen (prefix); i < NAME_LENGTH - 1; i++)
not posted ada patch breaks ada build on alpha-linux-gnu
r266136 broke the ada build on alpha-linux-gnu, filed as PR88191. I didn't find this patch posted to gcc-patches. Matthias
Re: [PATCH, d] Disable D on systems where it is known not to work.
On 31.10.18 05:37, Alan Modra wrote: > On Tue, Oct 30, 2018 at 09:07:30PM +0100, Iain Buclaw wrote: >> On Tue, 30 Oct 2018 at 20:50, Andreas Schwab wrote: >>> >>> On Okt 30 2018, Iain Buclaw wrote: >>> This turns off D front-end where there's been reported bootstrap problems that need further investigation. Also added a configure.tgt for libphobos to allow enabling for targets where there's known good runtime support backed by existing continuous integration. >>> >>> Why do you need that? The D frontend isn't built by default. >>> >> >> As far as I have seen, all automated builders for gcc are configured >> with --enable-languages=all however, which is pulling the D frontend >> in. > > You can add powerpc64*-*-* to the list of targets that fail bootstrap > with --enable-languages=all > > ../libphobos/src/std/math.d:242:5: error: static assert > "Only 64-bit, 80-bit, and 128-bit reals are supported for LittleEndian CPUs" > 242 | static assert(real.mant_dig == 53 || real.mant_dig == 64 > | ^ the frontend builds, just libphobos ftbfs
Fix build of the D frontend on the Hurd and KFreeBSD
Fix build of the D frontend on the Hurd and KFreeBSD. Where should these changes go, when they are not yet applied upstream? Ok to commit? Matthias # DP: Fix build of the D frontend on the Hurd and KFreeBSD. Index: b/src/gcc/d/dfrontend/object.h === --- a/src/gcc/d/dmd/root/object.h +++ b/src/gcc/d/dmd/root/object.h @@ -10,7 +10,7 @@ #ifndef OBJECT_H #define OBJECT_H -#define POSIX (__linux__ || __APPLE__ || __FreeBSD__ || __OpenBSD__ || __sun) +#define POSIX (__linux__ || __GLIBC__ || __gnu_hurd__ || __APPLE__ || __FreeBSD__ || __OpenBSD__ || __sun) #if __DMC__ #pragma once
Re: [PATCH] libsanitizer: Use pre-computed size of struct ustat for Linux
On 24.05.2018 21:59, Jakub Jelinek wrote: > On Thu, May 24, 2018 at 12:56:23PM -0700, H.J. Lu wrote: This patch uses pre-computed size of struct ustat for Linux. PR sanitizer/85835 * sanitizer_common/sanitizer_platform_limits_posix.cc: Don't include for Linux. (SIZEOF_STRUCT_USTAT): New. (struct_ustat_sz): Use SIZEOF_STRUCT_USTAT for Linux. >>> >>> Ok, thanks. >>> >> >> OK to backport to released branches? > > Yes. Backported to the gcc-6-branch as well. Matthias
