[patch] Revert: "Don't build insn-extract.o with rtl checking"

[Matthias Klose]

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] RISC-V: Implment __builtin_thread_pointer

[Matthias Klose]

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

Re: [PATCH] analyzer: Recognize __builtin_free as a matching deallocator

[Matthias Klose]

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: Porting the Docs to Sphinx - project status

[Matthias Klose]

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

[ada, patch] fix libgnat build on x86_64-linux-gnux32 with glibc <= 2.31

[Matthias Klose]

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: libgo patch committed: Update to Go1.17rc2 release

[Matthias Klose]

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: libgo patch committed: Always mark assembly file as non-executable stack

[Matthias Klose]

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

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v3)

[Matthias Klose]

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: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v3)

[Matthias Klose]

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

[patch] factor out common files for compare_exclusions

[Matthias Klose]

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 into the GCC tree on master

[Matthias Klose]

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] PR jit/87808: Allow libgccjit to work without an external gcc driver

[Matthias Klose]

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] PR jit/87808: Allow libgccjit to work without an external gcc driver

[Matthias Klose]

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

mention x86-64-vX micro-architecture levels in the release notes

[Matthias Klose]

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] offload-defaulted: Config option to silently ignore uninstalled offload compilers

[Matthias Klose]

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

Re: [Patch] offload-defaulted: Config option to silently ignore uninstalled offload compilers

[Matthias Klose]

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.

[patch] fix libsanitizer build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 on 32bit architectures

[Matthias Klose]

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

[patch] boehm-gc: link libgcjgc with -ldl

[Matthias Klose]

The boehm-gc tests currently fail to build with a linker with
--no-copy-dt-needed-entries as the default. dlopen is referenced in the libgcjgc
library itself, so link it with -ldl.  The macro name EXTRA_TEST_LIBS is a bit
unfortunate now, but it is the right way to find the library name, as done for
the tests itself.

Ok for the trunk and the 4.8 branch?

  Matthias

* Makefile.am (libgcjgc_la_LIBADD): Add EXTRA_TEST_LIBS.
* Makefile.in: Regenerate.

--- a/src/boehm-gc/Makefile.am
+++ a/src/boehm-gc/Makefile.am
@@ -35,7 +35,7 @@
 
 # Include THREADLIBS here to ensure that the correct versions of
 # linuxthread semaphore functions get linked:
-libgcjgc_la_LIBADD = $(addobjs) $(THREADLIBS)
+libgcjgc_la_LIBADD = $(addobjs) $(THREADLIBS) $(EXTRA_TEST_LIBS)
 libgcjgc_la_DEPENDENCIES = $(addobjs)
 libgcjgc_la_LDFLAGS = $(extra_ldflags_libgc) -version-info 1:2:0 -rpath 
$(toolexeclibdir)
 libgcjgc_la_LINK = $(LINK) $(libgcjgc_la_LDFLAGS)

Re: [patch] boehm-gc: link libgcjgc with -ldl

[Matthias Klose]

Am 04.09.2013 12:21, schrieb Andrew Haley:
> On 09/04/2013 11:00 AM, Matthias Klose wrote:
>> The boehm-gc tests currently fail to build with a linker with
>> --no-copy-dt-needed-entries as the default.
> 
> Hmm, isn't that a bug in the linker?

No, it's the default in gold and in the bfd linker since 2.23.

  Matthias

[patch] fix libbacktrace build failure on arm-linux

[Matthias Klose]

current trunk fails to build on arm-linux with:

In file included from ../../../../src/libbacktrace/backtrace.c:35:0:
../libgcc/unwind.h: In function '_Unwind_decode_typeinfo_ptr':
../libgcc/unwind.h:42:45: error: unused parameter 'base' 
[-Werror=unused-parameter]
   _Unwind_decode_typeinfo_ptr (_Unwind_Word base, _Unwind_Word ptr)
 ^
../libgcc/unwind.h: In function '__gnu_unwind_24bit':
../libgcc/unwind.h:68:41: error: unused parameter 'context'
[-Werror=unused-parameter]
   __gnu_unwind_24bit (_Unwind_Context * context, _uw data, int compact)
 ^
../libgcc/unwind.h:68:54: error: unused parameter 'data' 
[-Werror=unused-parameter]
   __gnu_unwind_24bit (_Unwind_Context * context, _uw data, int compact)
  ^
../libgcc/unwind.h:68:64: error: unused parameter 'compact'
[-Werror=unused-parameter]
   __gnu_unwind_24bit (_Unwind_Context * context, _uw data, int compact)
^
cc1: all warnings being treated as errors
make[8]: *** [backtrace.lo] Error 1

the immediate fix is to mark all arguments as unused, however I don't know if
this function should be used by libbacktrace, if it returns _URC_FAILURE
unconditionally.

* config/arm/unwind-arm.h (__gnu_unwind_24bit): Mark parameters
as unused.


--- libgcc/config/arm/unwind-arm.h  (revision 192162)
+++ libgcc/config/arm/unwind-arm.h  (working copy)
@@ -64,8 +64,11 @@
   return tmp;
 }

+#define __unused __attribute__((unused))
+
   static inline _Unwind_Reason_Code
-  __gnu_unwind_24bit (_Unwind_Context * context, _uw data, int compact)
+  __gnu_unwind_24bit (_Unwind_Context * context __unused, _uw data __unused,
+  int compact __unused)
 {
   return _URC_FAILURE;
 }

Re: [patch] fix libbacktrace build failure on arm-linux

[Matthias Klose]

On 06.10.2012 22:46, Ian Lance Taylor wrote:
> On Sat, Oct 6, 2012 at 8:09 AM, Matthias Klose  wrote:
>> current trunk fails to build on arm-linux with:
>>
>> In file included from ../../../../src/libbacktrace/backtrace.c:35:0:
>> ../libgcc/unwind.h: In function '_Unwind_decode_typeinfo_ptr':
>> ../libgcc/unwind.h:42:45: error: unused parameter 'base' 
>> [-Werror=unused-parameter]
>>_Unwind_decode_typeinfo_ptr (_Unwind_Word base, _Unwind_Word ptr)
>>  ^
>> ../libgcc/unwind.h: In function '__gnu_unwind_24bit':
>> ../libgcc/unwind.h:68:41: error: unused parameter 'context'
>> [-Werror=unused-parameter]
>>__gnu_unwind_24bit (_Unwind_Context * context, _uw data, int compact)
>>  ^
>> ../libgcc/unwind.h:68:54: error: unused parameter 'data' 
>> [-Werror=unused-parameter]
>>__gnu_unwind_24bit (_Unwind_Context * context, _uw data, int compact)
>>   ^
>> ../libgcc/unwind.h:68:64: error: unused parameter 'compact'
>> [-Werror=unused-parameter]
>>__gnu_unwind_24bit (_Unwind_Context * context, _uw data, int compact)
>> ^
>> cc1: all warnings being treated as errors
>> make[8]: *** [backtrace.lo] Error 1
>>
>> the immediate fix is to mark all arguments as unused, however I don't know if
>> this function should be used by libbacktrace, if it returns _URC_FAILURE
>> unconditionally.
> 
> The function is not used by libbacktrace.  It's an inline function
> defined in the header file, and the warning is about the inline
> function definition.  That is, this is a libgcc bug, not a
> libbacktrace bug, it just happens to show up when compiling
> libbacktrace for ARM
> 
> 
>> * config/arm/unwind-arm.h (__gnu_unwind_24bit): Mark parameters
>> as unused.
>>
>>
>> --- libgcc/config/arm/unwind-arm.h  (revision 192162)
>> +++ libgcc/config/arm/unwind-arm.h  (working copy)
>> @@ -64,8 +64,11 @@
>>return tmp;
>>  }
>>
>> +#define __unused __attribute__((unused))
>> +
>>static inline _Unwind_Reason_Code
>> -  __gnu_unwind_24bit (_Unwind_Context * context, _uw data, int compact)
>> +  __gnu_unwind_24bit (_Unwind_Context * context __unused, _uw data __unused,
>> +      int compact __unused)
>>  {
>>return _URC_FAILURE;
>>  }
> 
> Don't #define __unused.  Just write __attribute__ ((unused)) on the
> parameters.  Break the lines as needed.
> 
> This is OK with that change.

committed the following. the base parameter in _Unwind_decode_typeinfo_ptr
is unused too.

  Matthias

2012-10-07  Matthias Klose  

* config/arm/unwind-arm.h (__gnu_unwind_24bit): Mark parameters
as unused.
(_Unwind_decode_typeinfo_ptr): Mark base as unused.

Index: libgcc/config/arm/unwind-arm.h
===
--- a/src/libgcc/config/arm/unwind-arm.h(revision 192162)
+++ b/src/libgcc/config/arm/unwind-arm.h(working copy)
@@ -39,7 +39,8 @@
 #endif
   /* Decode an R_ARM_TARGET2 relocation.  */
   static inline _Unwind_Word
-  _Unwind_decode_typeinfo_ptr (_Unwind_Word base, _Unwind_Word ptr)
+  _Unwind_decode_typeinfo_ptr (_Unwind_Word base __attribute__ ((unused)),
+   _Unwind_Word ptr)
 {
   _Unwind_Word tmp;

@@ -65,7 +66,9 @@
 }

   static inline _Unwind_Reason_Code
-  __gnu_unwind_24bit (_Unwind_Context * context, _uw data, int compact)
+  __gnu_unwind_24bit (_Unwind_Context * context __attribute__ ((unused)),
+  _Unwind_Context *_uw data __attribute__ ((unused)),
+  int compact __attribute__ ((unused)))
 {
   return _URC_FAILURE;
 }

Re: [patch] fix libbacktrace build failure on arm-linux

[Matthias Klose]

On 07.10.2012 12:01, Matthias Klose wrote:
> On 06.10.2012 22:46, Ian Lance Taylor wrote:
>> On Sat, Oct 6, 2012 at 8:09 AM, Matthias Klose  wrote:
>>> current trunk fails to build on arm-linux with:
>>>
>>> In file included from ../../../../src/libbacktrace/backtrace.c:35:0:
>>> ../libgcc/unwind.h: In function '_Unwind_decode_typeinfo_ptr':
>>> ../libgcc/unwind.h:42:45: error: unused parameter 'base' 
>>> [-Werror=unused-parameter]
>>>_Unwind_decode_typeinfo_ptr (_Unwind_Word base, _Unwind_Word ptr)
>>>  ^
>>> ../libgcc/unwind.h: In function '__gnu_unwind_24bit':
>>> ../libgcc/unwind.h:68:41: error: unused parameter 'context'
>>> [-Werror=unused-parameter]
>>>__gnu_unwind_24bit (_Unwind_Context * context, _uw data, int compact)
>>>  ^
>>> ../libgcc/unwind.h:68:54: error: unused parameter 'data' 
>>> [-Werror=unused-parameter]
>>>__gnu_unwind_24bit (_Unwind_Context * context, _uw data, int compact)
>>>   ^
>>> ../libgcc/unwind.h:68:64: error: unused parameter 'compact'
>>> [-Werror=unused-parameter]
>>>__gnu_unwind_24bit (_Unwind_Context * context, _uw data, int compact)
>>> ^
>>> cc1: all warnings being treated as errors
>>> make[8]: *** [backtrace.lo] Error 1
>>>
>>> the immediate fix is to mark all arguments as unused, however I don't know 
>>> if
>>> this function should be used by libbacktrace, if it returns _URC_FAILURE
>>> unconditionally.
>>
>> The function is not used by libbacktrace.  It's an inline function
>> defined in the header file, and the warning is about the inline
>> function definition.  That is, this is a libgcc bug, not a
>> libbacktrace bug, it just happens to show up when compiling
>> libbacktrace for ARM
>>
>>
>>> * config/arm/unwind-arm.h (__gnu_unwind_24bit): Mark parameters
>>> as unused.
>>>
>>>
>>> --- libgcc/config/arm/unwind-arm.h  (revision 192162)
>>> +++ libgcc/config/arm/unwind-arm.h  (working copy)
>>> @@ -64,8 +64,11 @@
>>>return tmp;
>>>  }
>>>
>>> +#define __unused __attribute__((unused))
>>> +
>>>static inline _Unwind_Reason_Code
>>> -  __gnu_unwind_24bit (_Unwind_Context * context, _uw data, int compact)
>>> +  __gnu_unwind_24bit (_Unwind_Context * context __unused, _uw data 
>>> __unused,
>>> +  int compact __unused)
>>>  {
>>>return _URC_FAILURE;
>>>  }
>>
>> Don't #define __unused.  Just write __attribute__ ((unused)) on the
>> parameters.  Break the lines as needed.
>>
>> This is OK with that change.
> 
> committed the following. the base parameter in _Unwind_decode_typeinfo_ptr
> is unused too.
> 
>   Matthias
> 
> 2012-10-07  Matthias Klose  
> 
> * config/arm/unwind-arm.h (__gnu_unwind_24bit): Mark parameters
> as unused.
> (_Unwind_decode_typeinfo_ptr): Mark base as unused.
> 
> Index: libgcc/config/arm/unwind-arm.h
> ===
> --- a/src/libgcc/config/arm/unwind-arm.h(revision 192162)
> +++ b/src/libgcc/config/arm/unwind-arm.h(working copy)
> @@ -39,7 +39,8 @@
>  #endif
>/* Decode an R_ARM_TARGET2 relocation.  */
>static inline _Unwind_Word
> -  _Unwind_decode_typeinfo_ptr (_Unwind_Word base, _Unwind_Word ptr)
> +  _Unwind_decode_typeinfo_ptr (_Unwind_Word base __attribute__ ((unused)),
> +   _Unwind_Word ptr)
>  {
>_Unwind_Word tmp;
> 
> @@ -65,7 +66,9 @@
>  }
> 
>static inline _Unwind_Reason_Code
> -  __gnu_unwind_24bit (_Unwind_Context * context, _uw data, int compact)
> +  __gnu_unwind_24bit (_Unwind_Context * context __attribute__ ((unused)),
> +  _Unwind_Context *_uw data __attribute__ ((unused)),
> +  int compact __attribute__ ((unused)))
>  {
>return _URC_FAILURE;
>  }
> 

and as a follow-up, fix the typo, committed as obvious

--- config/arm/unwind-arm.h (revision 192181)
+++ config/arm/unwind-arm.h (working copy)
@@ -67,7 +67,7 @@

   static inline _Unwind_Reason_Code
   __gnu_unwind_24bit (_Unwind_Context * context __attribute__ ((unused)),
-  _Unwind_Context *_uw data __attribute__ ((unused)),
+  _uw data __attribute__ ((unused)),
   int compact __attribute__ ((unused)))
 {
   return _URC_FAILURE;

Re: [patch] [gcc/libgcc/ada/libstdc++] Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI

[Matthias Klose]

On 26.06.2012 11:10, Richard Earnshaw wrote:
> On 25/06/12 22:30, Matthias Klose wrote:
>> On 25.06.2012 18:21, Matthias Klose wrote:
>>> On 25.06.2012 15:22, Richard Earnshaw wrote:
>>>> On 25/06/12 13:08, Matthias Klose wrote:
>>>>> gcc/config.gcc now allows matching arm*-*-linux-*eabi* instead of
>>>>> arm*-*-linux-*eabi for ARM Linux/GNU EABI.  This changes the matching in 
>>>>> various
>>>>> other places as well. arm-linux-gnueabihf is used as a triplet by some
>>>>> distributions.
>>>>>
>>>>> Ok for the trunk?
>>>>>
>>>>
>>>> now that all arm-linux ports are EABI conforming, why can't this just 
>>>> become
>>>>
>>>>arm*-*-linux*
>>>> ?
>>>
>>> I assume it could. But I didn't check for other places where this would be 
>>> needed.
>>
>> $ grep -r 'arm[^_]*eabi' . |egrep -v 'ChangeLog|\.svn/'|wc -l
>> 87
>>
>> this seems to be a larger change, which should have been committed when the 
>> old
>> abi targets were deprecated.  I'd like to get the eabi* change in first.
>>
>>   Matthias
>>
>>
> 
> Removal of the FPA support is still ongoing, but beware that it doesn't
> mean that all supported ARM configurations will be EABI conforming (some
> configurations did not use the FPA and are thus not affected by this
> change); but all ARM Linux configurations will be.

Updated patch to just match arm*-*-linux*, searched for additional files with
grep -r 'arm[^_]*linux[^_]*eabi' . |egrep -v 'ChangeLog|\.svn/'

  Matthias




2012-10-15  Matthias Klose  

gcc/

* config.gcc: Match arm*-*-linux-* for ARM Linux/GNU.
* doc/install.texi:

gcc/testsuite/
2012-10-15  Matthias Klose  

* lib/target-supports.exp (check_profiling_available): Match
arm*-*-linux-* for ARM Linux/GNU.
    * g++.dg/torture/predcom-1.C: Match arm*-*-linux-* for ARM Linux/GNU.
* gfortran.dg/enum_10.f90: Likewise.
* gfortran.dg/enum_9.f90: Likewise.
* gcc.target/arm/synchronize.c: Likewise.
* g++.old-deja/g++.jason/enum6.C: Likewise.
* g++.old-deja/g++.other/enum4.C: Likewise.
* g++.old-deja/g++.law/enum9.C: Likewise.

gcc/ada/
2012-10-15  Matthias Klose  

* gcc-interface/Makefile.in: Match arm*-*-linux-*eabi* for
ARM Linux/GNU.

libgcc/
2012-10-15  Matthias Klose  

* config.host: Match arm*-*-linux-* for ARM Linux/GNU.

libstdc++-v3/
2012-10-15  Matthias Klose  

* configure.host: Match arm*-*-linux-* for ARM Linux/GNU.
* testsuite/20_util/make_signed/requirements/typedefs-2.cc: Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs-2.cc: Likewise.

libjava/
2012-10-15  Matthias Klose  

* configure.ac: Match arm*-*-linux-* for ARM Linux/GNU.
* configure: Regenerate.

Index: libgcc/config.host
===
--- libgcc/config.host  (revision 192459)
+++ libgcc/config.host  (working copy)
@@ -316,7 +316,7 @@
 arm*-*-linux*) # ARM GNU/Linux with ELF
tmake_file="${tmake_file} arm/t-arm t-fixedpoint-gnu-prefix"
case ${host} in
-   arm*-*-linux-*eabi)
+   arm*-*-linux-*)
  tmake_file="${tmake_file} arm/t-elf arm/t-bpabi arm/t-linux-eabi 
t-slibgcc-libgcc"
  tm_file="$tm_file arm/bpabi-lib.h"
  unwind_header=config/arm/unwind-arm.h
Index: libjava/configure.ac
===
--- libjava/configure.ac(revision 192459)
+++ libjava/configure.ac(working copy)
@@ -931,7 +931,7 @@
 # on Darwin -single_module speeds up loading of the dynamic libraries.
 extra_ldflags_libjava=-Wl,-single_module
 ;;
-arm*linux*eabi)
+arm*-*-linux-*)
 # Some of the ARM unwinder code is actually in libstdc++.  We
 # could in principle replicate it in libgcj, but it's better to
 # have a dependency on libstdc++.
Index: gcc/testsuite/gfortran.dg/enum_10.f90
===
--- gcc/testsuite/gfortran.dg/enum_10.f90   (revision 192459)
+++ gcc/testsuite/gfortran.dg/enum_10.f90   (working copy)
@@ -1,7 +1,7 @@
 ! { dg-do run }
 ! { dg-additional-sources enum_10.c }
 ! { dg-options "-fshort-enums -w" }
-! { dg-options "-fshort-enums -w -Wl,--no-enum-size-warning" { target 
arm*-*-linux*eabi } }
+! { dg-options "-fshort-enums -w -Wl,--no-enum-size-warning" { target 
arm*-*-linux* } }
 ! Make sure short enums are indeed interoperable with the
 ! corresponding C type.
 
Index: gcc/testsuite/gfortran.dg/enum_9.f

Re: gcc 4.7 libgo patch committed: Set libgo version number

[Matthias Klose]

On 23.10.2012 06:55, Ian Lance Taylor wrote:
> PR 54918 points out that libgo is not using version numbers as it
> should.  At present none of libgo in 4.6, 4.7 and mainline are
> compatible with each other.  This patch to the 4.7 branch sets the
> version number for libgo there.  Bootstrapped and ran Go testsuite on
> x86_64-unknown-linux-gnu.  Committed to 4.7 branch.

changing the soname of a runtime library on the branch? I don't like this idea
at all.

  Matthias

Re: LRA has been merged into trunk.

[Matthias Klose]

On 24.10.2012 08:55, Marc Glisse wrote:
> On Tue, 23 Oct 2012, Vladimir Makarov wrote:
> 
>>  Hi, I was going to merge LRA into trunk last Sunday.  It did not happen. LRA
>> was actively changed last 4 weeks by implementing reviewer's proposals which
>> resulted in a lot of new LRA regressions on GCC testsuite in comparison with
>> reload.  Finally, they were fixed and everything looks ok to me.
> 
> That's great, thanks!
> 
> Note that bootstrap with java enabled is broken for me on x86_64-linux, I'll
> file a PR tonight if nobody beats me to it.

PR55048, seen on i686-linux-gnu as well.

[patch] make the libstdc++ pretty printers compatible with both Python 2 and Python3

[Matthias Klose]

Starting with gdb 7.6, gdb can be linked with both Python 2.x and Python 3.x.
Therefore the pretty printers should be compatible with both Python versions.

This patch should be backported to 4.7 and 4.8 as well.

Ok for the trunk?

  Matthias


* python/libstdcxx/v6/printers.py: Make pretty printers compatible with
Both python 2.x and 3.x.

Index: python/libstdcxx/v6/printers.py
===
--- python/libstdcxx/v6/printers.py (revision 204231)
+++ python/libstdcxx/v6/printers.py (working copy)
@@ -15,8 +15,14 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see .
 
+# Keep this module compatible with both Python 2 and Python 3
+
 import gdb
-import itertools
+import sys
+if sys.version_info[0] < 3:
+import itertools
+map = itertools.imap
+zip = itertools.izip
 import re
 
 # Try to use the new-style pretty-printing if available.
@@ -51,7 +57,7 @@
 # anything fancier here.
 field = typ.fields()[0]
 if not field.is_base_class:
-raise ValueError, "Cannot find type %s::%s" % (str(orig), name)
+raise ValueError("Cannot find type %s::%s" % (str(orig), name))
 typ = field.type
 
 class SharedPointerPrinter:
@@ -97,7 +103,7 @@
 def __iter__(self):
 return self
 
-def next(self):
+def __next__(self):
 if self.base == self.head:
 raise StopIteration
 elt = self.base.cast(self.nodetype).dereference()
@@ -105,6 +111,7 @@
 count = self.count
 self.count = self.count + 1
 return ('[%d]' % count, elt['_M_data'])
+next = __next__
 
 def __init__(self, typename, val):
 self.typename = typename
@@ -144,7 +151,7 @@
 def __iter__(self):
 return self
 
-def next(self):
+def __next__(self):
 if self.base == 0:
 raise StopIteration
 elt = self.base.cast(self.nodetype).dereference()
@@ -152,6 +159,7 @@
 count = self.count
 self.count = self.count + 1
 return ('[%d]' % count, elt['_M_data'])
+next = __next__
 
 def __init__(self, typename, val):
 self.val = val
@@ -198,7 +206,7 @@
 def __iter__(self):
 return self
 
-def next(self):
+def __next__(self):
 count = self.count
 self.count = self.count + 1
 if self.bitvec:
@@ -220,6 +228,7 @@
 elt = self.item.dereference()
 self.item = self.item + 1
 return ('[%d]' % count, elt)
+next = __next__
 
 def __init__(self, typename, val):
 self.typename = typename
@@ -276,20 +285,20 @@
 # Set the actual head to the first pair.
 self.head  = self.head.cast (nodes[0].type)
 elif len (nodes) != 0:
-raise ValueError, "Top of tuple tree does not consist of a 
single node."
+raise ValueError("Top of tuple tree does not consist of a 
single node.")
 self.count = 0
 
 def __iter__ (self):
 return self
 
-def next (self):
+def __next__ (self):
 nodes = self.head.type.fields ()
 # Check for further recursions in the inheritance tree.
 if len (nodes) == 0:
 raise StopIteration
 # Check that this iteration has an expected structure.
 if len (nodes) != 2:
-raise ValueError, "Cannot parse more than 2 nodes in a tuple 
tree."
+raise ValueError("Cannot parse more than 2 nodes in a tuple 
tree.")
 
 # - Left node is the next recursion parent.
 # - Right node is the actual class contained in the tuple.
@@ -309,6 +318,7 @@
 return ('[%d]' % self.count, impl)
 else:
 return ('[%d]' % self.count, impl['_M_head_impl'])
+next = __next__
 
 def __init__ (self, typename, val):
 self.typename = typename
@@ -353,7 +363,7 @@
 def __len__(self):
 return int (self.size)
 
-def next(self):
+def __next__(self):
 if self.count == self.size:
 raise StopIteration
 result = self.node
@@ -374,6 +384,7 @@
 node = parent
 self.node = node
 return result
+next = __next__
 
 # This is a pretty printer for std::_Rb_tree_iterator (which is
 # std::map::iterator), and has nothing to do with the RbtreeIterator
@@ -414,9 +425,9 @@
 def __iter__(self):
 return self
 
-def next(self):
+def __next__(self):
 if self.count % 2 == 0:
-n = self.rbiter.next()
+n = next(self.rbiter)
 n = n.cast(self.type).dereference

Re: [PATCH] New version of libmpx with new memmove wrapper

[Matthias Klose]

On 11.12.2015 15:34, Ilya Enkovich wrote:

I fixed it, bootstrapped, regtested and applied to trunk.  Here is committed 
version.


this left libmpx/libtool-version, which now is unused and outdated. Ok to 
remove?

Matthias

Re: RFA: MIPS: Fix race condition causing PR 69129

[Matthias Klose]

On 19.01.2016 14:52, Nick Clifton wrote:

Hi Catherine, Hi Eric, Hi Matthew,

   GCC PR 69129 reports a problem with the MIPS backend:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69129

   I traced the problem down to a race condition in
   mips_compute_frame_info.  This calls mips_global_pointer, which
   through a torturous chain of inferior calls can end up with
   mips_get_cprestore_base_and_offset trying to use the information in
   the frame structure which has yet to be computed...

   The attached patch fixes the problem by moving the initialisation of
   the global_pointer field in the frame structure to after the args_size
   and hard_frame_pointer_offset fields have been initialised.

   Tested with no regressions on a mipsisa32-elf toolchain.  (I know that
   there are lots of different possible mips configurations.  I was not
   sure which one(s) I should test, so I chose one at random).


this fixes the bootstrap errors for me, seen in both libgnat and libgfortran.

[patch] fix gccjit build failure

[Matthias Klose]

gccjit currently fails to build, needing an additional header. Ok to install on 
the trunk?


Matthias


* jit-playback.c: Include .

--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -43,6 +43,8 @@ along with GCC; see the file COPYING3.
 #include "jit-builtins.h"
 #include "jit-tempdir.h"

+#include 
+

 /* gcc::jit::playback::context::build_cast uses the convert.h API,
which in turn requires the frontend to provide a "convert"

Re: Fix PR67639

[Matthias Klose]

On 08.02.2016 15:26, Bernd Schmidt wrote:

On 12/21/2015 08:39 PM, Jeff Law wrote:

On 12/18/2015 11:38 AM, Bernd Schmidt wrote:

In an earlier fix, the following change was made in varasm.c for invalid
register variables:

--- trunk/gcc/varasm.c2014/08/26 14:59:59214525
+++ trunk/gcc/varasm.c2014/08/26 17:06:31214526
@@ -1371,6 +1371,11 @@ make_decl_rtl (tree decl)
/* As a register variable, it has no section.  */
return;
  }
+  /* Avoid internal errors from invalid register
+ specifications.  */
+  SET_DECL_ASSEMBLER_NAME (decl, NULL_TREE);
+  DECL_HARD_REGISTER (decl) = 0;
+  return;
  }

As seen in PR67639, this makes the IL inconsistent and triggers another
internal error where we expect to see an SSA_NAME instead of a VAR_DECL.

The following patch extends the above slightly, by also setting
DECL_EXTERNAL to pretend that the erroneous variable is actually a
global.

Bootstrapped and tested on x86_64-linux, ok?

OK.


Turns out 65702 is a dup and this should go into gcc-5 as well. Ok to backport?


ChangeLog entry is not backported.

[patch] introduce aarch64 as a Go architecture

[Matthias Klose]

This patch introduces aarch64 as a Go architecture.

  Matthias
# DP: Introduce aarch64 goarch.

--- a/src/libgo/go/go/build/syslist.go
+++ a/src/libgo/go/go/build/syslist.go
@@ -5,4 +5,4 @@
 package build
 
 const goosList = "darwin dragonfly freebsd linux netbsd openbsd plan9 windows 
solaris "
-const goarchList = "386 amd64 arm alpha m68k mipso32 mipsn32 mipsn64 mipso64 
ppc ppc64 sparc sparc64 "
+const goarchList = "386 amd64 arm aarch64 alpha m68k mipso32 mipsn32 mipsn64 
mipso64 ppc ppc64 sparc sparc64 "
--- a/src/libgo/configure.ac
+++ a/src/libgo/configure.ac
@@ -172,6 +172,7 @@
 
 dnl N.B. Keep in sync with gcc/testsuite/go.test/go-test.exp (go-set-goarch).
 is_386=no
+is_aarch64=no
 is_alpha=no
 is_arm=no
 is_m68k=no
@@ -183,6 +184,10 @@
 is_x86_64=no
 GOARCH=unknown
 case ${host} in
+  aarch64*-*-*)
+is_aarch64=yes
+GOARCH=aarch64
+;;
   alpha*-*-*)
 is_alpha=yes
 GOARCH=alpha
@@ -265,6 +270,7 @@
 ;;
 esac
 AM_CONDITIONAL(LIBGO_IS_386, test $is_386 = yes)
+AM_CONDITIONAL(LIBGO_IS_AARCH64, test $is_aarch64 = yes)
 AM_CONDITIONAL(LIBGO_IS_ALPHA, test $is_alpha = yes)
 AM_CONDITIONAL(LIBGO_IS_ARM, test $is_arm = yes)
 AM_CONDITIONAL(LIBGO_IS_M68K, test $is_m68k = yes)
--- a/src/gcc/testsuite/go.test/go-test.exp
+++ a/src/gcc/testsuite/go.test/go-test.exp
@@ -187,6 +187,9 @@
 global target_triplet
 
 switch -glob $target_triplet {
+   "aarch64*-*-*" {
+   set goarch "aarch64"
+   }
"alpha*-*-*" {
set goarch "alpha"
}

[patch] Pass -fuse-ld=gold to gccgo on targets supporting -fsplit-stack

[Matthias Klose]

to get full advantage of the -fsplit-stack option, gccgo binaries have to be
linked with gold, not the bfd linker.  When the system linker defaults to the
bfd linker, then gccgo should explicitly use the gold linker, passing
fuse-ld=gold, unless another -fuse-ld option is present.  Tested with and
without having ld.gold on the system.

  Matthias
# DP: Pass -fuse-ld=gold to gccgo on targets supporting -fsplit-stack

gcc/go/ 
 
* gospec.c (lang_specific_driver): Pass -fuse-ld=gold on targets
supporting -fsplit-stack, unless overwritten.   
 

 
gcc/
 
* configure.ac: New define HAVE_GOLD_NON_DEFAULT.  
* config.in: Regenerate.
  

 
libgo/  
 
* configure.ac (libgo_cv_c_linker_supports_split_stack): Fix quoting. 
Check the linker used by the gccgo driver.

Index: b/src/gcc/go/gospec.c
===
--- a/src/gcc/go/gospec.c
+++ b/src/gcc/go/gospec.c
@@ -117,6 +117,10 @@
   /* Whether the -S option was used.  */
   bool saw_opt_S = false;
 
+  /* "-fuse-ld=" if it appears on the command line.  */
+  bool saw_use_ld = false;
+  int need_gold = 0;
+
   /* The first input file with an extension of .go.  */
   const char *first_go_file = NULL;  
 
@@ -217,6 +221,11 @@
}
 
  break;
+
+   case OPT_fuse_ld_bfd:
+   case OPT_fuse_ld_gold:
+ saw_use_ld = true;
+ break;
}
 }
 
@@ -226,8 +235,14 @@
   shared_libgcc = 0;
 #endif
 
+#if defined(TARGET_CAN_SPLIT_STACK) && defined(HAVE_GOLD_NON_DEFAULT)
+  if (!saw_use_ld)
+need_gold = 1;
+#endif
+
   /* Make sure to have room for the trailing NULL argument.  */
-  num_args = argc + need_math + shared_libgcc + (library > 0) * 5 + 10;
+  num_args = argc + need_math + shared_libgcc + need_gold +
+(library > 0) * 5 + 10;
   new_decoded_options = XNEWVEC (struct cl_decoded_option, num_args);
 
   i = 0;
@@ -244,6 +259,14 @@
   &new_decoded_options[j]);
   j++;
 }
+#ifdef HAVE_GOLD_NON_DEFAULT
+  if (need_gold)
+{
+  generate_option (OPT_fuse_ld_gold, NULL, 1, CL_DRIVER,
+  &new_decoded_options[j]);
+  j++;
+}
+#endif
 #endif
 
   /* NOTE: We start at 1 now, not 0.  */
Index: b/src/libgo/configure.ac
===
--- a/src/libgo/configure.ac
+++ b/src/libgo/configure.ac
@@ -348,10 +348,10 @@
 dnl others.
 AC_CACHE_CHECK([whether linker supports split stack],
 [libgo_cv_c_linker_supports_split_stack],
-libgo_cv_c_linker_supports_split_stack=no
-if $LD --help 2>/dev/null | grep split-stack-adjust-size >/dev/null 2>&1; then
+[libgo_cv_c_linker_supports_split_stack=no
+if $GOC -Wl,--help 2>/dev/null | grep split-stack-adjust-size >/dev/null 2>&1; 
then
   libgo_cv_c_linker_supports_split_stack=yes
-fi)
+fi])
 if test "$libgo_cv_c_linker_supports_split_stack" = yes; then
   AC_DEFINE(LINKER_SUPPORTS_SPLIT_STACK, 1,
[Define if the linker support split stack adjustments])
Index: b/src/gcc/config.in
===
--- a/src/gcc/config.in
+++ b/src/gcc/config.in
@@ -1133,6 +1133,12 @@
 #endif
 
 
+/* Define if the gold linker is available as a non-default */
+#ifndef USED_FOR_TARGET
+#undef HAVE_GOLD_NON_DEFAULT
+#endif
+
+
 /* Define if you have the iconv() function. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_ICONV
Index: b/src/gcc/configure.ac
===
--- a/src/gcc/configure.ac
+++ b/src/gcc/configure.ac
@@ -2060,6 +2060,12 @@
 fi
 AC_MSG_RESULT($ld_is_gold)
 
+# Check to see if ld is used, and gold is available
+if test x$ld_is_gold = xno && which ${gcc_cv_ld}.gold >/dev/null 2>&1; then
+  AC_DEFINE(HAVE_GOLD_NON_DEFAULT, 1,
+   [Define if the gold linker is available as a non-default])
+fi
+
 ORIGINAL_LD_FOR_TARGET=$gcc_cv_ld
 AC_SUBST(ORIGINAL_LD_FOR_TARGET)
 case "$ORIGINAL_LD_FOR_TARGET" in

[patch] Remove empty directories

[Matthias Klose]

trunk has some empty directories. ok to remove?

gcc/testsuite/go.test/test/fixedbugs/bug478.dir
libstdc++-v3/testsuite/experimental/string_view/requirements/exception
libstdc++-v3/testsuite/experimental/string_view/capacity/wchar_t
libstdc++-v3/testsuite/experimental/string_view/capacity/char

Re: [patch] introduce aarch64 as a Go architecture

[Matthias Klose]

Please let's pick aarch64. Everybody names it this way, except of course Debian
:-/  If I understand ARM developers correctly, there will be something like
aarch32 in the future (x32 for ARM), and I think you don't want to call it 
arm32.

  Matthias

Am 29.11.2013 20:22, schrieb Ian Lance Taylor:
> I've gotten a patch from Michael Hudson-Doyle to set GOARCH to arm64
> on an Aarch64 system (https://codereview.appspot.com/34830045/).  I've
> gotten a patch from Matthias Klose to set GOARCH to aarch64 on such a
> system (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03765.html).
> 
> I don't care one way or another myself, but we need to pick one.
> 
> Ian
> 
> 
> On Fri, Nov 29, 2013 at 5:23 AM, Matthias Klose  wrote:
>> This patch introduces aarch64 as a Go architecture.
>>
>>   Matthias

[ping] Re: [patch] Pass -fuse-ld=gold to gccgo on targets supporting -fsplit-stack

[Matthias Klose]

ping patch

Am 29.11.2013 14:29, schrieb Matthias Klose:
> to get full advantage of the -fsplit-stack option, gccgo binaries have to be
> linked with gold, not the bfd linker.  When the system linker defaults to the
> bfd linker, then gccgo should explicitly use the gold linker, passing
> fuse-ld=gold, unless another -fuse-ld option is present.  Tested with and
> without having ld.gold on the system.
> 
>   Matthias
> 

Re: [PATCH, AARCH64] MULTIARCH_DIRNAME breaks multiarch build

[Matthias Klose]

Am 10.01.2014 09:23, schrieb Zhenqiang Chen:
> Hi,
> 
> MULTIARCH_DIRNAME was removed @r196649 since the dir info had been
> combined in MULTILIB_OSDIRNAMES.
> 
> But MULTIARCH_DIRNAME was re-added @r201164. With this change, the
> final multiarch_dir is combined as
> "aarch64-linux-gnu:aarch64-linux-gnu", which is incorrect and leads to
> multiarch build fail if the sysroot is in correct multiarch layout.
> 
> Any reason to add MULTIARCH_DIRNAME? If it is not necessary, can we
> remove it as the patch?

see the thread "[patch] set MULTIARCH_DIRNAME for multilib architectures" from
June 2013.  I think it is necessary to have the default defined.  Yesterday's
build looks ok for me, looking at default and include paths, so maybe I don't
yet understand the issue.

I think aarch64 is the only architecture which introduces MULTILIB_* macros
without actually building any multilib, just to set the default library name to
lib64. So maybe this has some side effects.

  Matthias

Re: [PATCH, AARCH64] MULTIARCH_DIRNAME breaks multiarch build

[Matthias Klose]

Am 10.01.2014 10:49, schrieb Zhenqiang Chen:
> On 10 January 2014 17:23, Matthias Klose  wrote:
>> Am 10.01.2014 09:23, schrieb Zhenqiang Chen:
>>> Hi,
>>>
>>> MULTIARCH_DIRNAME was removed @r196649 since the dir info had been
>>> combined in MULTILIB_OSDIRNAMES.
>>>
>>> But MULTIARCH_DIRNAME was re-added @r201164. With this change, the
>>> final multiarch_dir is combined as
>>> "aarch64-linux-gnu:aarch64-linux-gnu", which is incorrect and leads to
>>> multiarch build fail if the sysroot is in correct multiarch layout.
>>>
>>> Any reason to add MULTIARCH_DIRNAME? If it is not necessary, can we
>>> remove it as the patch?
>>
>> see the thread "[patch] set MULTIARCH_DIRNAME for multilib architectures" 
>> from
>> June 2013.  I think it is necessary to have the default defined.  Yesterday's
>> build looks ok for me, looking at default and include paths, so maybe I don't
>> yet understand the issue.
> 
> In our build, we configure eglbc with
> rtlddir=/lib
> libdir=/usr/lib/aarch64-linux-gnu
> slibdir=/lib/aarch64-linux-gnu
> 
> And we configure gcc with "--disable-multilib --enable-multiarch",
> But when building gcc libraries, configure FAIL since it can not find
> the C libraries. And I try
> ./xgcc --print-multiarch
> the output is "aarch64-linux-gnu:aarch64-linux-gnu"
> 
> Any comments?

> 
> Thanks!
> -Zhenqiang
> 
> 
> 
>> I think aarch64 is the only architecture which introduces MULTILIB_* macros
>> without actually building any multilib, just to set the default library name 
>> to
>> lib64. So maybe this has some side effects.

sorry, I have a local patch applied after the lib64 change, which I forgot to
forward.

* Makefile.in (s-mlib): Only pass MULTIARCH_DIRNAME if
MULTILIB_OSDIRNAMES is not defined.

--- a/src/gcc/Makefile.in
+++ b/src/gcc/Makefile.in
@@ -1837,7 +1837,7 @@
"$(MULTILIB_EXCLUSIONS)" \
"$(MULTILIB_OSDIRNAMES)" \
"$(MULTILIB_REQUIRED)" \
-   "$(MULTIARCH_DIRNAME)" \
+   "$(if $(MULTILIB_OSDIRNAMES),,$(MULTIARCH_DIRNAME))" \
"$(MULTILIB_REUSE)" \
"@enable_multilib@" \
> tmp-mlib.h; \

applied/tested since July 2013 on the Debian/Ubuntu distro builds. It doesn't
affect the non-multiarch case.

Ok for the trunk?

  Matthias

[patch] install missing rs6000 header, needed to build plugins

[Matthias Klose]

This installs the rs6000-cpus.def file for powerpc targets (included by
default64.h), which is needed to build plugins on powerpc64* targets.

Ok for the trunk, and the 5 branch? Tested with a build and installation.

Matthias

PR target/66840
* config/rs6000/t-rs6000 (TM_H): Add rs6000-cpus.def.

--- gcc/config/rs6000/t-rs6000
+++ gcc/config/rs6000/t-rs6000
@@ -19,6 +19,7 @@
 # .
 
 TM_H += $(srcdir)/config/rs6000/rs6000-builtin.def
+TM_H += $(srcdir)/config/rs6000/rs6000-cpus.def
 
 rs6000-c.o: $(srcdir)/config/rs6000/rs6000-c.c
$(COMPILE) $<

Re: dejagnu version update?

[Matthias Klose]

On 09/15/2015 09:23 PM, Bernhard Reutner-Fischer wrote:
> On September 15, 2015 7:39:39 PM GMT+02:00, Mike Stump 
>  wrote:
>> On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:
 Maybe GCC-6 can bump the required
 dejagnu version to allow for getting rid of all these superfluous
 load_gcc_lib? *blink* :)
>>> I'd support that as a direction.
>>>
>>> Certainly dropping the 2001 version from our website in favor of 1.5
>> (which is what I'm using anyway) would be a step forward.
>>
>> So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to
>> 1.5.  I don’t know of any reason to not update and just require 1.5 at
>> this point.  I’m not a fan of feature chasing dejagnu, but an update
>> every 2-4 years isn’t unreasonable.
>>
>> So, let’s do it this way…  Any serious and compelling reason to not
>> update to 1.5?  If none, let’s update to 1.5 in another week or two, if
>> no serious and compelling reasons not to.
>>
>> My general plan is, slow cycle updates on dejagnu, maybe every 2 years.
>> LTS style releases should have the version in it before the requirement
>> is updated.  I take this approach as I think this should be the maximal
>> change rate of things like make, gcc, g++, ld, if possible.
> 
> Yea, although this means that 1.5.3 (a Version with the libdirs tweak) being 
> just 5 months old will have to wait another bump, I fear. For my part going 
> to plain 1.5 is useless WRT the load_lib situation. I see no value in 
> conditionalizing simplified libdir handling on a lucky user with recentish 
> stuff so i'm just waiting another 2 or 4 years for this very minor cleanup.

is this libdirs tweak backportable to 1.5.1 (Debian stable), or 1.5 (Ubuntu 
LTS)?

Re: patch to fix PR66424

[Matthias Klose]

This was marked as a regression in 5 and 6, but never backported to the 
gcc-5-branch. Is it time to backport?


Matthias

On 21.07.2015 21:54, Vladimir Makarov wrote:

   The following patch fixes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66424

   The patch was tested and bootstrapped on x86/x86-64.

   Committed as rev. 226053.

2015-07-21  Vladimir Makarov  

 PR ipa/66424.
 * lra-remat.c (operand_to_remat): Prevent using insns with input
 subregs processed separately by IRA.

2015-07-21  Vladimir Makarov  

 PR ipa/66424.
 * gcc.target/i386/pr66424.c: New.

Re: [PATCH] DWARF support for AIX v5

[Matthias Klose]

On 25.09.2015 20:59, David Edelsohn wrote:

This version adds extra tests for HAVE_XCOFF_DWARF_EXTRAS.  I placed
the default in dwarf2out.c instead of defaults.h.

Because eh_frame is internal to GCC with its own section, I emit the
length, but inhibit the length for AIX debug_frame section.

This allows DWARF debugging to work on older AIX 7.1 systems within
the limitations of the available sections.  It also allows it to build
and test on a wider variety of AIX 7.1 systems.

I also changed the TLS decorations to use a switch statement, as suggested.

Thanks, David

 * dwarf2out.c (XCOFF_DEBUGGING_INFO): Default 0 definition.
 (HAVE_XCOFF_DWARF_EXTRAS): Default to 0 definition.
 (output_fde): Don't output length for debug_frame on AIX.
 (output_call_frame_info): Don't output length for debug_frame on AIX.
 (have_macinfo): Force to False for XCOFF_DEBUGGING_INFO and not
 HAVE_XCOFF_DWARF_EXTRAS.
 (add_AT_loc_list): Return early if XCOFF_DEBUGGING_INFO and not
 HAVE_XCOFF_DWARF_EXTRAS.
 (output_compilation_unit_header): Don't output length on AIX.
 (output_pubnames): Don't output length on AIX.
 (output_aranges): Delete argument. Compute length locally. Don't
 output length on AIX.
 (output_line_info): Don't output length on AIX.
 (dwarf2out_finish): Don't compute aranges_length.
 * dwarf2asm.c (XCOFF_DEBUGGING_INFO): Default 0 definition.
 (dw2_asm_output_nstring): Emit .byte not .ascii on AIX.
 * config/rs6000/rs6000.c (rs6000_output_dwrf_dtprel): Emit correct
 symbol decoration for AIX.
 (rs6000_xcoff_debug_unwind_info): New.
 (rs6000_xcoff_asm_named_section): Emit .dwsect pseudo-op
 for SECTION_DEBUG.
 (rs6000_xcoff_declare_function_name): Emit different
 .function pseudo-op when DWARF2_DEBUG. Don't call
 xcoffout_declare_function for DWARF2_DEBUG.
 * config/rs6000/xcoff.h (TARGET_DEBUG_UNWIND_INFO):
 Redefine.
 * config/rs6000/aix71.h (DWARF2_DEBUGGING_INFO): Define.
 (PREFERRED_DEBUGGING_TYPE): Define.
 (DEBUG_INFO_SECTION): Define.
 (DEBUG_ABBREV_SECTION): Define.
 (DEBUG_ARANGES_SECTION): Define.
 (DEBUG_LINE_SECTION): Define.
 (DEBUG_PUBNAMES_SECTION): Define.
 (DEBUG_PUBTYPES_SECTION): Define.
 (DEBUG_STR_SECTION): Define.
 (DEBUG_RANGES_SECTION): Define.


I see a build failure on powerpc64le-linux-gnu:

/home/doko/gcc/gcc-snapshot-20150929/src/gcc/configure: line 26465: syntax error 
near unexpected token `$target'
/home/doko/gcc/gcc-snapshot-20150929/src/gcc/configure: line 26465: `case 
$target in'

Makefile:4165: recipe for target 'configure-stage1-gcc' failed
make[4]: *** [configure-stage1-gcc] Error 2
make[4]: Leaving directory '/home/doko/gcc/gcc-snapshot-20150929/build'

$ bash -n src/gcc/configure
src/gcc/configure: line 26465: syntax error near unexpected token `$target'
src/gcc/configure: line 26465: `case $target in'

The above ChangeLog entry doesn't mention the patch to configure.ac and the 
regeneration of configure, but it is included in the commit message.  It looks 
like that gcc/configure was manually fixed without fixing gcc/configure.ac. 
Committing as obvious (although I see some whitespace changes with an unmodified 
autoconf2.64 downloaded from ftp.gnu.org).


Matthias

gcc/

2015-09-30  Matthias Klose  

* configure.ac: Remove extraneous ;;.
* configure: Regenerate.

Index: configure.ac
===
--- configure.ac(revision 228280)
+++ configure.ac(working copy)
@@ -4326,7 +4326,6 @@
[Define if your assembler supports .ref])])
;;
 esac
-;;

 case $target in
   *-*-aix*)

Re: Openacc launch API

[Matthias Klose]

On 25.08.2015 15:29, Nathan Sidwell wrote:

Jakub,

This patch changes the launch API for openacc parallels.


this broke the jit build.

The following patch fixes the build for me. Ok to commit?

  Matthias

2015-09-30  Matthias Klose  

* jit-builtins.h Define DEF_FUNCTION_TYPE_VAR_6,
remove DEF_FUNCTION_TYPE_VAR_11.
* jit-builtins.c (builtins_manager::make_type): Define and handle
DEF_FUNCTION_TYPE_VAR_6, remove DEF_FUNCTION_TYPE_VAR_11.


Index: gcc/jit/jit-builtins.c
===
--- gcc/jit/jit-builtins.c  (revision 228287)
+++ gcc/jit/jit-builtins.c  (working copy)
@@ -320,15 +320,14 @@
 #define DEF_FUNCTION_TYPE_VAR_5(ENUM, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5) \
   case ENUM: return make_fn_type (ENUM, RETURN, 1, 5, ARG1, ARG2, ARG3, \
  ARG4, ARG5);
+#define DEF_FUNCTION_TYPE_VAR_6(ENUM, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5, \
+   ARG6)   \
+  case ENUM: return make_fn_type (ENUM, RETURN, 1, 6, ARG1, ARG2, ARG3, \
+ ARG4, ARG5, ARG6);
 #define DEF_FUNCTION_TYPE_VAR_7(ENUM, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5, \
ARG6, ARG7) \
   case ENUM: return make_fn_type (ENUM, RETURN, 1, 7, ARG1, ARG2, ARG3, \
  ARG4, ARG5, ARG6, ARG7);
-#define DEF_FUNCTION_TYPE_VAR_11(ENUM, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5, \
-ARG6, ARG7, ARG8, ARG9, ARG10, ARG11) \
-  case ENUM: return make_fn_type (ENUM, RETURN, 1, 11, ARG1, ARG2, ARG3, \
- ARG4, ARG5, ARG6, ARG7, ARG8, ARG9, \
- ARG10, ARG11);
 #define DEF_POINTER_TYPE(ENUM, TYPE) \
   case ENUM: return make_ptr_type (ENUM, TYPE);
 
@@ -350,8 +349,8 @@
 #undef DEF_FUNCTION_TYPE_VAR_3
 #undef DEF_FUNCTION_TYPE_VAR_4
 #undef DEF_FUNCTION_TYPE_VAR_5
+#undef DEF_FUNCTION_TYPE_VAR_6
 #undef DEF_FUNCTION_TYPE_VAR_7
-#undef DEF_FUNCTION_TYPE_VAR_11
 #undef DEF_POINTER_TYPE
 
 default:
Index: gcc/jit/jit-builtins.h
===
--- gcc/jit/jit-builtins.h  (revision 228287)
+++ gcc/jit/jit-builtins.h  (working copy)
@@ -50,10 +50,10 @@
 #define DEF_FUNCTION_TYPE_VAR_4(NAME, RETURN, ARG1, ARG2, ARG3, ARG4) NAME,
 #define DEF_FUNCTION_TYPE_VAR_5(NAME, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5) \
NAME,
+#define DEF_FUNCTION_TYPE_VAR_6(NAME, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5, \
+   ARG6) NAME,
 #define DEF_FUNCTION_TYPE_VAR_7(NAME, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5, \
ARG6, ARG7) NAME,
-#define DEF_FUNCTION_TYPE_VAR_11(NAME, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5, \
-ARG6, ARG7, ARG8, ARG9, ARG10, ARG11) NAME,
 #define DEF_POINTER_TYPE(NAME, TYPE) NAME,
 #include "builtin-types.def"
 #undef DEF_PRIMITIVE_TYPE
@@ -73,7 +73,6 @@
 #undef DEF_FUNCTION_TYPE_VAR_4
 #undef DEF_FUNCTION_TYPE_VAR_5
 #undef DEF_FUNCTION_TYPE_VAR_7
-#undef DEF_FUNCTION_TYPE_VAR_11
 #undef DEF_POINTER_TYPE
   BT_LAST
 }; /* enum jit_builtin_type */

Re: Openacc launch API

[Matthias Klose]

On 30.09.2015 14:40, Bernd Schmidt wrote:

On 09/30/2015 02:37 PM, Matthias Klose wrote:


this broke the jit build.

The following patch fixes the build for me. Ok to commit?

   Matthias

2015-09-30  Matthias Klose  

 * jit-builtins.h Define DEF_FUNCTION_TYPE_VAR_6,
 remove DEF_FUNCTION_TYPE_VAR_11.
 * jit-builtins.c (builtins_manager::make_type): Define and handle
 DEF_FUNCTION_TYPE_VAR_6, remove DEF_FUNCTION_TYPE_VAR_11.


Yeah, I think that qualifies as obvious.


Ok, committed.

[patch] Remove empty libstdc++ directories

[Matthias Klose]

Removing two empty directories, approved by Jonathan on IRC.

  Matthias

2015-09-30  Matthias Klose  

* config/cpu/alpha, config/cpu/ia64: Remove empty directories.

Re: Do not describe -std=c11 etc. as experimental in c.opt help text

[Matthias Klose]

On 01.10.2015 19:01, Joseph Myers wrote:

I noticed that c.opt still described -std=c11 and related options as
experimental in the --help text.  This patch fixes this.


this seems to be true for the gcc-5 branch as well. Could you fix it there as 
well?

  Matthias

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

[Matthias Klose]

On 01.10.2015 01:07, Ian Lance Taylor wrote:

On Thu, Sep 17, 2015 at 12:13 PM, Lynn A. Boger
 wrote:

Here is my updated patch, with the changes suggested by
Ian for gcc/gospec.c and David for gcc/configure.ac.

Bootstrap built and tested on ppc64le, ppc64 multilib.

2015-09-17Lynn Boger 
gcc/
 PR target/66870
 config/rs6000/sysv4.h:  Define TARGET_CAN_SPLIT_STACK_64BIT
 config.in:  Set up HAVE_GOLD_ALTERNATE_SPLIT_STACK
 configure.ac:  Define HAVE_GOLD_ALTERNATE_SPLIT_STACK
 on Power based on gold linker version
 configure:  Regenerate
 gcc.c:  Add -fuse-ld=gold to STACK_SPLIT_SPEC if
 HAVE_GOLD_ALTERNATE_SPLIT_STACK defined
 go/gospec.c:  (lang_specific_driver):  Set appropriate split
stack
 options for 64 bit compiles based on
TARGET_CAN_SPLIT_STACK_64BIT


Thanks.  I had to add ATTRIBUTE_UNUSED to the new variable in
go/gospec.c.  Committed with these ChangeLog entries:

2015-10-01  Lynn Boger  

PR target/66870
* config/rs6000/sysv4.h (TARGET_CAN_SPLIT_STACK_64BIT): Define.
* configure.ac: Define HAVE_GOLD_ALTERNATE_SPLIT_STACK on Power
based on gold linker version.
* gcc.c: Add -fuse-ld=gold to STACK_SPLIT_SPEC if
HAVE_GOLD_ALTERNATE_SPLIT_STACK defined.
* configure, config.in: Regenerate.

2015-10-01  Lynn Boger  

PR target/66870
* gospec.c (lang_specific_driver): Set appropriate split stack
options for 64 bit compiles based on TARGET_CAN_SPLIT_STACK_64BIT.

Ian



this causes the build to fail on powerpc-linux-gnu:

make[4]: Entering directory '/home/doko/gcc/gcc-snapshot-20151003/build/gotools'
/home/doko/gcc/gcc-snapshot-20151003/build/./gcc/gccgo 
-B/home/doko/gcc/gcc-snapshot-20151003/build/./gcc/ -g -O2  -static-libstdc++ 
-static-libgcc -Wl,-z,relro -L ../powerpc-linux-gnu/libgo -L 
../powerpc-linux-gnu/libgo/.libs -o go 
../../src/gotools/../libgo/go/cmd/go/build.go 
../../src/gotools/../libgo/go/cmd/go/clean.go 
../../src/gotools/../libgo/go/cmd/go/context.go 
../../src/gotools/../libgo/go/cmd/go/discovery.go 
../../src/gotools/../libgo/go/cmd/go/env.go 
../../src/gotools/../libgo/go/cmd/go/fix.go 
../../src/gotools/../libgo/go/cmd/go/fmt.go 
../../src/gotools/../libgo/go/cmd/go/generate.go 
../../src/gotools/../libgo/go/cmd/go/get.go 
../../src/gotools/../libgo/go/cmd/go/go11.go 
../../src/gotools/../libgo/go/cmd/go/help.go 
../../src/gotools/../libgo/go/cmd/go/http.go 
../../src/gotools/../libgo/go/cmd/go/list.go 
../../src/gotools/../libgo/go/cmd/go/main.go 
../../src/gotools/../libgo/go/cmd/go/pkg.go 
../../src/gotools/../libgo/go/cmd/go/run.go 
../../src/gotools/../libgo/go/cmd/go/signal.go 
../../src/gotools/../libgo/go/cmd/go/signal_unix.go 
../../src/gotools/../libgo/go/cmd/go/test.go 
../../src/gotools/../libgo/go/cmd/go/testflag.go 
../../src/gotools/../libgo/go/cmd/go/tool.go 
../../src/gotools/../libgo/go/cmd/go/vcs.go 
../../src/gotools/../libgo/go/cmd/go/version.go 
../../src/gotools/../libgo/go/cmd/go/vet.go 
../powerpc-linux-gnu/libgo/zstdpkglist.go zdefaultcc.go
go1: error: '-fsplit-stack' currently only supported on PowerPC64 GNU/Linux with 
glibc-2.18 or later

go1: error: '-fsplit-stack' is not supported by this compiler configuration
Makefile:667: recipe for target 'go' failed
make[4]: *** [go] Error 1
make[4]: Leaving directory '/home/doko/gcc/gcc-snapshot-20151003/build/gotools'
Makefile:12908: recipe for target 'all-gotools' failed
make[3]: *** [all-gotools] Error 2

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

[Matthias Klose]

On 07.10.2015 17:36, Lynn A. Boger wrote:

Pretty sure this is the fix, but still doing some testing.


linux.h isn't included for multilib enabled builds defaulting to 
powerpc-linux-gnu, I am currently testing


--- gcc/config/rs6000/sysv4.h   (revision 228571)
+++ gcc/config/rs6000/sysv4.h   (working copy)
@@ -943,8 +943,9 @@
 /* On ppc64 and ppc64le, split stack is only support for
64 bit. */
 #undef TARGET_CAN_SPLIT_STACK_64BIT
-#if TARGET_GLIBC_MAJOR > 2 \
-  || (TARGET_GLIBC_MAJOR == 2 && TARGET_GLIBC_MINOR >= 18)
+#if TARGET_64BIT \
+  && (TARGET_GLIBC_MAJOR > 2 \
+  || (TARGET_GLIBC_MAJOR == 2 && TARGET_GLIBC_MINOR >= 18))
 #define TARGET_CAN_SPLIT_STACK_64BIT
 #endif

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

[Matthias Klose]

On 08.10.2015 20:56, Lynn A. Boger wrote:

I think my original fix with linux.h doing the #undef on
TARGET_CAN_SPLIT_STACK_64BIT is the right fix at least
for powerpc-linux-gnu 32 bit only.

It works for powerpc-linux-gnu without multilib and doesn't break
powerpc64-linux-gnu or powerpc64le-linux-gnu.

Can you tell me how you are configuring the multilib build that defaults to
powerpc-linux-gnu and how it
fails?  Maybe there is another problem for that combination.


Configured with: -v
 --with-pkgversion='Ubuntu 20151005-0ubuntu1'
 --with-bugurl='file:///usr/share/doc/gcc-snapshot/README.Bugs'
 --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
 --prefix=/usr/lib/gcc-snapshot
 --enable-shared
 --enable-linker-build-id
 --disable-nls
 --with-sysroot=/
 --enable-clocale=gnu
 --enable-libstdcxx-debug
 --enable-libstdcxx-time=yes
 --with-default-libstdcxx-abi=new
 --enable-gnu-unique-object
 --disable-libitm
 --disable-libquadmath
 --enable-plugin
 --with-system-zlib
 --disable-browser-plugin
 --enable-java-awt=gtk
 --enable-gtk-cairo
 --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-snap-powerpc/jre
 --enable-java-home
 --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-snap-powerpc
 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-snap-powerpc
 --with-arch-directory=ppc
 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
 --enable-objc-gc
 --enable-secureplt
 --disable-softfloat
 --with-cpu=default32
 --disable-softfloat
 --enable-targets=powerpc-linux,powerpc64-linux
 --enable-multiarch
 --disable-werror
 --with-long-double-128
 --enable-multilib
 --enable-checking=yes
 --build=powerpc-linux-gnu
 --host=powerpc-linux-gnu
 --target=powerpc-linux-gnu

fails in gotools with:
cc1: error: '-fsplit-stack' currently only supported on PowerPC64 GNU/Linux with 
glibc-2.18 or later

cc1: error: '-fsplit-stack' is not supported by this compiler configuration

this information is from the log below, but it's a parallel build, so a bit 
useless
https://launchpadlibrarian.net/220374353/buildlog_ubuntu-wily-powerpc.gcc-snapshot_20151005-0ubuntu1_BUILDING.txt.gz


As David noted, the use of TARGET_64BIT or TARGET_POWERPC64 won't work for this
#define.


I found that out too =)  Note that ada builds are currently broken on the trunk.

Matthias

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

[Matthias Klose]

On 10.10.2015 16:00, David Edelsohn wrote:

On Fri, Oct 9, 2015 at 3:51 PM, Lynn A. Boger
 wrote:

Here's a new one.

Tried all the variations, verified that split stack is still enabled and
uses gold linker for 64 bit targets
when using a 64 bit default compiler, and does not give the split stack
error for 32 bit default
compilers.


This is okay if Matthias confirms that it works.


yes, that fixes the build error.

using the preprocessor for this kind of check, you get wrong results for gcc 
-m32 on powerpc64, and for gcc -m64 on powerpc.  The former looks like wrong 
code, while the latter is just missed optimization.  Not sure if it is worth 
fixing this.


I lost track of the x86 status. Is this now enabled there as well?

Matthias

[ping] Re: [patch] fix gotools cross build

[Matthias Klose]

still needed, both on the trunk and the branch.

On 06.05.2015 14:34, Matthias Klose wrote:

Yes, it's documented that there is still some work to do for cross builds,
however a cross build for gotools currently fails.

The toplevel make always passes the GOC variable in the environment, overwriting
anything configured in gotools own configure.ac. Fixed by explictly using @GOC@
for GOCOMPILER.

gotools is a host project, and the cross_compiling check always fails. Not sure
if the $host != $target test is any better, but it works for me.

Ok for the trunk and the gcc-5 branch?

   Matthias

* Makefile.am: Use GOC configured in configure.ac for cross builds.
 * configure.ac: Fix NATIVE conditional.
 * Makefile.in, configure: Regenerate.

--- gotools/Makefile.am
+++ gotools/Makefile.am
@@ -33,7 +33,7 @@
  # Use the compiler we just built.
  GOCOMPILER = $(GOC_FOR_TARGET)
  else
-GOCOMPILER = $(GOC)
+GOCOMPILER = @GOC@
  endif

  GOCFLAGS = $(CFLAGS_FOR_TARGET)
--- gotools/configure.ac
+++ gotools/configure.ac
@@ -46,7 +46,7 @@
  AC_PROG_CC
  AC_PROG_GO

-AM_CONDITIONAL(NATIVE, test "$cross_compiling" = no)
+AM_CONDITIONAL(NATIVE, test "$host" = "$target")

  dnl Test for -lsocket and -lnsl.  Copied from libjava/configure.ac.
  AC_CACHE_CHECK([for socket libraries], gotools_cv_lib_sockets,

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

[Matthias Klose]

On 13.10.2015 00:53, Alan Modra wrote:

On Mon, Oct 12, 2015 at 10:15:04AM -0500, Lynn A. Boger wrote:

Thanks for doing this Alan.  I agree this looks better to me.

I assume by "etc" you mean you did biarch builds for your bootstraps on BE?


By "etc" I meant "and regression tested".

I built four configurations, powerpc-linux 32-bit only,
powerpc64le-linux 64-bit only, biarch powerpc-linux with 32-bit
default, and biarch powerpc64-linux with 64-bit default.


thanks, that works for me as well (biarch powerpc-linux-gnu).

[PATCH] [4.9] Re: [PATCH][5] Backport ISL 0.15 support

[Matthias Klose]

On 12.10.2015 12:58, Richard Biener wrote:


This backports the patch to allow bootstrapping with ISL 0.15 to the
GCC 5 branch (the GCC 4.9 branch will require backporting of some
dependencies).


I don't think so. 4.8 and 4.9 don't use as much ISL code as 5 does.  I had a 
look at the backport and came up with something which is just mechanical changes 
for the cpp conditional.


The version check in the toplevel configure needs to be extended.  I'm currently 
not checking non matching isl and cloog versions.


Now build for 4.9 using ISL 0.15 and 0.14. Ok to commit to the branch?

Matthias


2015-11-18  Matthias Klose  

	* configure.ac: Permit also ISL 0.15 with CLooG.
	* configure: Regenerate.

gcc/
2015-11-18  Matthias Klose  

	Backport from the gcc-5-branch

	Backport from mainline
	2015-07-21  Mike Frysinger  
		Bernhard Reutner-Fischer  

	* configure.ac: Add check for new options in isl-0.15.
	* config.in, configure: Rebuilt.
	* graphite-blocking.c: Include 
	* graphite-interchange.c,  graphite-poly.c: Likewise.
	* graphhite-scop-detection.c, graphite-sese-to-poly.c: Likewise.
	* graphite.c, graphite-poly.c: Likewise.
	* graphite-dependences.c: Include .
	(max_number_of_out_dimensions): Returns isl_stat.
	(extend_schedule_1): Likewise
	(extend_schedule): Corresponding changes.
	* graphite-optimize-isl.c: Include  and
	.
	(getSingleMap): Change return type of isl_stat.
	(optimize_isl): Conditionally use
	isl_options_set_schedule_serialize_sccs.
	* graphite-poly.h (isl_stat, isl_stat_ok): Define fallbacks
	if not HAVE_ISL_OPTIONS_SET_SCHEDULE_SERIALIZE_SCCS.


Index: configure.ac
===
--- configure.ac	(revision 230544)
+++ configure.ac	(working copy)
@@ -1660,6 +1660,9 @@
   ISL_CHECK_VERSION(0,12)
   if test "${gcc_cv_isl}" = no ; then
 ISL_CHECK_VERSION(0,14)
+if test "${gcc_cv_isl}" = no ; then
+  ISL_CHECK_VERSION(0,15)
+fi
   fi
 fi
   fi
Index: gcc/config.in
===
--- gcc/config.in	(revision 230544)
+++ gcc/config.in	(working copy)
@@ -1223,6 +1223,12 @@
 #endif
 
 
+/* Define if isl_options_set_schedule_serialize_sccs exists. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_ISL_OPTIONS_SET_SCHEDULE_SERIALIZE_SCCS
+#endif
+
+
 /* Define if isl_schedule_constraints_compute_schedule exists. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_ISL_SCHED_CONSTRAINTS_COMPUTE_SCHEDULE
Index: gcc/configure.ac
===
--- gcc/configure.ac	(revision 230544)
+++ gcc/configure.ac	(working copy)
@@ -5535,6 +5535,8 @@
 
   # Check whether isl_schedule_constraints_compute_schedule is available;
   # it's new in ISL-0.13.
+  # Check whether isl_options_set_schedule_serialize_sccs is available;
+  # it's new in ISL-0.15.
   saved_CFLAGS="$CFLAGS"
   CFLAGS="$CFLAGS $ISLINC"
   saved_LIBS="$LIBS"
@@ -5547,6 +5549,13 @@
   [ac_has_isl_schedule_constraints_compute_schedule=no])
   AC_MSG_RESULT($ac_has_isl_schedule_constraints_compute_schedule)
 
+  AC_MSG_CHECKING([Checking for isl_options_set_schedule_serialize_sccs])
+  AC_TRY_LINK([#include ],
+  [isl_options_set_schedule_serialize_sccs (NULL, 0);],
+  [ac_has_isl_options_set_schedule_serialize_sccs=yes],
+  [ac_has_isl_options_set_schedule_serialize_sccs=no])
+  AC_MSG_RESULT($ac_has_isl_options_set_schedule_serialize_sccs)
+
   LIBS="$saved_LIBS"
   CFLAGS="$saved_CFLAGS"
 
@@ -5554,6 +5563,11 @@
  AC_DEFINE(HAVE_ISL_SCHED_CONSTRAINTS_COMPUTE_SCHEDULE, 1,
[Define if isl_schedule_constraints_compute_schedule exists.])
   fi
+
+  if test x"$ac_has_isl_options_set_schedule_serialize_sccs" = x"yes"; then
+ AC_DEFINE(HAVE_ISL_OPTIONS_SET_SCHEDULE_SERIALIZE_SCCS, 1,
+   [Define if isl_options_set_schedule_serialize_sccs exists.])
+  fi
 fi
 
 
Index: gcc/graphite-blocking.c
===
--- gcc/graphite-blocking.c	(revision 230544)
+++ gcc/graphite-blocking.c	(working copy)
@@ -24,6 +24,7 @@
 #include "config.h"
 
 #ifdef HAVE_cloog
+#include 
 #include 
 #include 
 #include 
Index: gcc/graphite-dependences.c
===
--- gcc/graphite-dependences.c	(revision 230544)
+++ gcc/graphite-dependences.c	(working copy)
@@ -22,6 +22,7 @@
 #include "config.h"
 
 #ifdef HAVE_cloog
+#include 
 #include 
 #include 
 #include 
@@ -183,7 +184,7 @@
 /* Helper function used on each MAP of a isl_union_map.  Computes the
maximal output dimension.  */
 
-static int
+static isl_stat
 max_number_of_out_dimensions (__isl_take isl_map *map, void *user)
 {
   int global_max = *((int *) user);
@@ -195,7 +196,7 @@
 
   isl_map_fr

Re: [PATCH] [4.9] Re: [PATCH][5] Backport ISL 0.15 support

[Matthias Klose]

On 19.11.2015 09:07, Richard Biener wrote:

On Wed, 18 Nov 2015, Matthias Klose wrote:


On 12.10.2015 12:58, Richard Biener wrote:


This backports the patch to allow bootstrapping with ISL 0.15 to the
GCC 5 branch (the GCC 4.9 branch will require backporting of some
dependencies).


I don't think so. 4.8 and 4.9 don't use as much ISL code as 5 does.  I had a
look at the backport and came up with something which is just mechanical
changes for the cpp conditional.

The version check in the toplevel configure needs to be extended.  I'm
currently not checking non matching isl and cloog versions.

Now build for 4.9 using ISL 0.15 and 0.14. Ok to commit to the branch?


Ok.  I wonder if we have a cloog version in infrastructure that builds
against ISL 0.1[45]?  IIRC cloog 0.18.1 doesn't.


No, that would be 0.18.4, the minimum requirement for isl 0.15.

Trying to rebuild 0.15 against 0.12.2 results in test failures (below), 
rebuilding against 0.14 doesn't show test failures.


Matthias

--- ./reservoir/QR.c 2014-10-02 14:33:50.0 +
+++ cloog_temp  2015-11-19 15:12:15.844164292 +
@@ -1,12 +1,6 @@
-/* Generated from ./reservoir/QR.cloog by CLooG 0.18.1-2-g43fc508 gmp bits in 
0.07s. */
+/* Generated from ./reservoir/QR.cloog by CLooG 0.18.4-b2b4f77 gmp bits in 
0.13s. */

 if (N >= 1) {
   S1(0);
-  if ((M <= 0) && (N >= 2)) {
-S3(0);
-S10(0);
-S1(1);
-S5(0);
-  }
   if ((M >= 1) && (N == 1)) {
 for (c4=0;c4<=M-1;c4++) {
   S2(0,c4);
@@ -34,6 +28,12 @@
 S10(0);
 S1(1);
 S5(0);
+  }
+  if ((M <= 0) && (N >= 2)) {
+S3(0);
+S10(0);
+S1(1);
+S5(0);
   }
   for (c2=2;c2<=min(M,N-1);c2++) {
 for (c4=c2-1;c4<=N-1;c4++) {
FAIL: ./reservoir/QR.c has a problem

--- ./isl/jacobi-shared.c  2014-10-02 16:33:52.0 +
+++ cloog_temp  2015-11-19 15:12:17.260192519 +
@@ -3,7 +3,7 @@
   if ((16*floord(t0-1,16) >= -N+g1+t0+1) && (16*floord(g1+t0-3,16) >= 
-N+g1+t0+1) && (32*floord(t1-1,32) >= -N+g2+t1+1) && (32*floord(g2+t1-3,32) >= 
t1-32)) {
 for 
(c0=max(-16*floord(t0-1,16)+t0,-16*floord(g1+t0-3,16)+t0);c0<=min(32,N-g1-1);c0+=16) 
{

   for (c1=-32*floord(t1-1,32)+t1;c1<=min(32,N-g2-1);c1+=32) {
-if (c1 >= 1) {
+if ((c1 >= 1) && (c1 <= 32)) {
   S1((c0+g1-1),(c1+g2-1));
 }
   }
FAIL: ./isl/jacobi-shared.c has a problemE

update zlib to 1.2.8

[Matthias Klose]

In GCC zlib is only used for libjava; for binutils and gdb it is used when 
building without --with-system-zlib.  This just updates zlib from 1.2.7 to 1.2.8 
(released in 2013).  Applies cleanly, libjava still builds and doesn't show any 
regressions in the testsuite.  Ok to apply (even if we already are in stage3)?


Matthias

zlib/ChangeLog.gcj

+2015-11-23  Matthias Klose  
+
+   * Imported zlib 1.2.8; merged local changes.

zlib/ChangeLog

+Changes in 1.2.8 (28 Apr 2013)
+- Update contrib/minizip/iowin32.c for Windows RT [Vollant]
+- Do not force Z_CONST for C++
+- Clean up contrib/vstudio [Ro]
+- Correct spelling error in zlib.h
+- Fix mixed line endings in contrib/vstudio
+
+Changes in 1.2.7.3 (13 Apr 2013)
+- Fix version numbers and DLL names in contrib/vstudio/*/zlib.rc
+
+Changes in 1.2.7.2 (13 Apr 2013)
+- Change check for a four-byte type back to hexadecimal
+- Fix typo in win32/Makefile.msc
+- Add casts in gzwrite.c for pointer differences
+
+Changes in 1.2.7.1 (24 Mar 2013)
+- Replace use of unsafe string functions with snprintf if available
+- Avoid including stddef.h on Windows for Z_SOLO compile [Niessink]
+- Fix gzgetc undefine when Z_PREFIX set [Turk]
+- Eliminate use of mktemp in Makefile (not always available)
+- Fix bug in 'F' mode for gzopen()
+- Add inflateGetDictionary() function
+- Correct comment in deflate.h
+- Use _snprintf for snprintf in Microsoft C
+- On Darwin, only use /usr/bin/libtool if libtool is not Apple
+- Delete "--version" file if created by "ar --version" [Richard G.]
+- Fix configure check for veracity of compiler error return codes
+- Fix CMake compilation of static lib for MSVC2010 x64
+- Remove unused variable in infback9.c
+- Fix argument checks in gzlog_compress() and gzlog_write()
+- Clean up the usage of z_const and respect const usage within zlib
+- Clean up examples/gzlog.[ch] comparisons of different types
+- Avoid shift equal to bits in type (caused endless loop)
+- Fix unintialized value bug in gzputc() introduced by const patches
+- Fix memory allocation error in examples/zran.c [Nor]
+- Fix bug where gzopen(), gzclose() would write an empty file
+- Fix bug in gzclose() when gzwrite() runs out of memory
+- Check for input buffer malloc failure in examples/gzappend.c
+- Add note to contrib/blast to use binary mode in stdio
+- Fix comparisons of differently signed integers in contrib/blast
+- Check for invalid code length codes in contrib/puff
+- Fix serious but very rare decompression bug in inftrees.c
+- Update inflateBack() comments, since inflate() can be faster
+- Use underscored I/O function names for WINAPI_FAMILY
+- Add _tr_flush_bits to the external symbols prefixed by --zprefix
+- Add contrib/vstudio/vc10 pre-build step for static only
+- Quote --version-script argument in CMakeLists.txt
+- Don't specify --version-script on Apple platforms in CMakeLists.txt
+- Fix casting error in contrib/testzlib/testzlib.c
+- Fix types in contrib/minizip to match result of get_crc_table()
+- Simplify contrib/vstudio/vc10 with 'd' suffix
+- Add TOP support to win32/Makefile.msc
+- Suport i686 and amd64 assembler builds in CMakeLists.txt
+- Fix typos in the use of _LARGEFILE64_SOURCE in zconf.h
+- Add vc11 and vc12 build files to contrib/vstudio
+- Add gzvprintf() as an undocumented function in zlib
+- Fix configure for Sun shell
+- Remove runtime check in configure for four-byte integer type
+- Add casts and consts to ease user conversion to C++
+- Add man pages for minizip and miniunzip
+- In Makefile uninstall, don't rm if preceding cd fails
+- Do not return Z_BUF_ERROR if deflateParam() has nothing to write


zlib.diff.gz
Description: application/gzip

Re: update zlib to 1.2.8

[Matthias Klose]

On 23.11.2015 19:13, Joel Brobecker wrote:

In GCC zlib is only used for libjava; for binutils and gdb it is used when
building without --with-system-zlib.  This just updates zlib from 1.2.7 to
1.2.8 (released in 2013).  Applies cleanly, libjava still builds and doesn't
show any regressions in the testsuite.  Ok to apply (even if we already are
in stage3)?



+2015-11-23  Matthias Klose  
+
+   * Imported zlib 1.2.8; merged local changes.


Should not be a problem for GDB, since we're not near branching time.

Out of curiosity, what prompted this update? Just to be in sync with
the latest? Or was there an actual bug that you hit which 1.2.8 fixes?


No, just a packaging issue with somebody mentioning a static binutils build. 
That's when I saw the outdated version.


Now updated in the GCC VCS.

Matthias

[rfc] Skip non-default multilib and libstdc++-v3 debug builds in bootstrap builds

[Matthias Klose]

The attached patch avoids building the non-default multilib and libstdc++-v3 
debug builds in bootstrap builds during bootstrap builds, resulting in some 
speedup for bootstrap builds for targets with multilibs enabled.  On 
x86_64-linux-gnu with 64/32/x32 multilibs enabled and the libstdc++ debug build 
enabled the bootstrap with -j8 takes 34:10 without, and with the patch 26:55, 
making the build ~20% faster (standard languages plus go enabled).  It's faster 
because it avoids the rather sequential libcc/libstdc++/libgomp configury during 
stage1 and stage2.  The gain by not building the libstdc++ debug library is not 
that measurable, the config is copied, there is no separate configure run.  Is 
relying on stage_current/stage_final the correct approach?  Should that be 
enabled using a configure option, or by default?


Matthias

# DP: Skip non-default multilib and libstdc++-v3 debug builds in bootstrap builds

--- a/src/config-ml.in
+++ b/src/config-ml.in
@@ -498,6 +498,17 @@
 # Tests like `if [ -n "$multidirs" ]' require it.
 multidirs=`echo "$multidirs" | sed -e 's/^[ ][ ]*//' -e 's/[ ][ ]*$//' -e 's/[ ][ ]*/ /g'`
 
+# stage1 and stage2 builds of the non-default multilib configurations
+# are not needed; skip these to save some build time.
+if [ -f ../../stage_final ] && [ -f ../../stage_current ]; then
+stage_final=`cat ../../stage_final`
+stage_current=`cat ../../stage_current`
+if [ "$stage_current" != "$stage_final" ]; then
+	echo "Skip `basename $ml_realsrcdir` non-default multilibs for bootstrap stage $stage_current"
+	multidirs=
+fi
+fi
+
 # Add code to library's top level makefile to handle building the multilib
 # subdirs.
 
--- a/src/libstdc++-v3/acinclude.m4
+++ b/src/libstdc++-v3/acinclude.m4
@@ -2503,7 +2503,20 @@
 AC_DEFUN([GLIBCXX_ENABLE_DEBUG], [
   AC_MSG_CHECKING([for additional debug build])
   GLIBCXX_ENABLE(libstdcxx-debug,$1,,[build extra debug library])
+  if test x$enable_libstdcxx_debug = xyes; then
+if test -f $toplevel_builddir/../stage_final && test -f $toplevel_builddir/../stage_current; then
+  stage_final=`cat $toplevel_builddir/../stage_final`
+  stage_current=`cat $toplevel_builddir/../stage_current`
+  if test x$stage_current != x$stage_final ; then
+	skip_debug_build=yes
+	enable_libstdcxx_debug=no
+  fi
+fi
+  fi
   AC_MSG_RESULT($enable_libstdcxx_debug)
+  if test x$skip_debug_build = xyes ; then
+AC_MSG_NOTICE([Skip libstdc++-v3 debug build for bootstrap stage $stage_current])
+  fi
   GLIBCXX_CONDITIONAL(GLIBCXX_BUILD_DEBUG, test $enable_libstdcxx_debug = yes)
 ])
 

[patch] link libgccjit using LDFLAGS

[Matthias Klose]

link libgccjit using LDFLAGS (which is empty by default), but could be used to 
pass hardening options like -Wlz,relro.


Matthias

	* Make-lang.in ($(LIBGCCJIT_FILENAME)): Link using $(LDFLAGS).

--- a/gcc/jit/Make-lang.in
+++ b/gcc/jit/Make-lang.in
@@ -86,7 +86,7 @@ $(LIBGCCJIT_FILENAME): $(jit_OBJS) \
 	 $(CPPLIB) $(LIBDECNUMBER) $(LIBS) $(BACKENDLIBS) \
 	 $(EXTRA_GCC_OBJS) \
 	 -Wl,--version-script=$(srcdir)/jit/libgccjit.map \
-	 -Wl,-soname,$(LIBGCCJIT_SONAME)
+	 -Wl,-soname,$(LIBGCCJIT_SONAME) $(LDFLAGS)
 
 $(LIBGCCJIT_SONAME_SYMLINK): $(LIBGCCJIT_FILENAME)
 	ln -sf $(LIBGCCJIT_FILENAME) $(LIBGCCJIT_SONAME_SYMLINK)

Re: Solaris vtv port breaks x32 build

[Matthias Klose]

On 02.12.2015 13:29, Rainer Orth wrote:

Exactly: moving AM_ENABLE_MULTILIB up as Matthias suggested sets
cross_compiling=maybe for non-default multilibs early, which should
achieve the desired behaviour.  All other libraries that invoke both
macros already do so in this order.


now committed.

2015-12-02  Matthias Klose  

* configure.ac: Move AM_ENABLE_MULTILIB before
GCC_LIBSTDCXX_RAW_CXX_FLAGS.
* configure: Regenerate.

Re: Patch to fix PR93272

[Matthias Klose]

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.

Re: [PATCH] rs6000: Check -+0 and NaN for smax/smin generation

[Matthias Klose]

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] fix PR lto/95604, -flto and -fcf-protection

[Matthias Klose]

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.
>>>>>>>
>>>>>>&g

[nvptx, aarch64] Define TARGET_OFFLOAD_OPTIONS for AArch64

[Matthias Klose]

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: [committed] libphobos: Add --enable-libphobos-checking configure option (PR94305)

[Matthias Klose]

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: zstd not found if installed in non-system prefix

[Matthias Klose]

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: zstd not found if installed in non-system prefix

[Matthias Klose]

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: [PATCH 3/3] Support the PGO build for binutils+gdb

[Matthias Klose]

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 3/3] Support the PGO build for binutils+gdb

[Matthias Klose]

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: libgo patch committed: Update to Go1.16beta1 release

[Matthias Klose]

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: libgo patch committed: Update to Go1.16beta1 release

[Matthias Klose]

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: &X86.HasSSSE3},
 
 		// These capabilities should always be enabled on amd64:
-		{Name: "sse2", Feature: &X86.HasSSE2, Required: GOARCH == "amd64"},
+		{Name: "sse2", Feature: &X86.HasSSE2, 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

[Matthias Klose]

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

[Matthias Klose]

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

[Matthias Klose]

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&value != 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&value != 0
+}

[patch] fix -Wformat-diag warnings in rs6000-call.c

[Matthias Klose]

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));
 }

--enable-link-serialization=1 doesn't work

[Matthias Klose]

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; \

Re: [patch] fix -Wformat-diag warnings in rs6000-call.c

[Matthias Klose]

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

Re: --enable-link-serialization=1 doesn't work

[Matthias Klose]

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

[Matthias Klose]

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: [PATCH] x86: Error on -fcf-protection with incompatible target

[Matthias Klose]

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] Modula-2 into the GCC tree on master

[Matthias Klose]

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)
+{
+}

[patch] fix PR lto/95604, -flto and -fcf-protection

[Matthias Klose]

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 (
+&temporary_obstack, &first_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 (&temporary_obstack, &first_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: [Ada] Build support units for 128-bit integer types on 64-bit platforms

[Matthias Klose]

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

Re: [PATCH] INSTALL: Default to --enable-cet=auto

[Matthias Klose]

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: [PATCH] RISC-V: Canonicalize --with-arch

[Matthias Klose]

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] RISC-V: Canonicalize --with-arch

[Matthias Klose]

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

[patch] don't build insn-extract.o with rtl checking

[Matthias Klose]

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\

[patch] [ada] Fix PR ada/97504 for mips*-linux

[Matthias Klose]

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

Re: [PATCH] RISC-V: Explicitly call python when using multilib generator

[Matthias Klose]

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] substitute @tie{} with a space for the man pages

[Matthias Klose]

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: [Ada] Fix PR ada/99264

[Matthias Klose]

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] fix installation of jit headers, usage of $(mkinstalldirs)

[Matthias Klose]

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: [PATCH] PR target/97250: i386: Add support for x86-64-v2, x86-64-v3, x86-64-v4 levels for x86-64

[Matthias Klose]

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

Re: [PATCH] Modula-2 into the GCC tree on master

[Matthias Klose]

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/gm

Re: [PATCH] Modula-2 into the GCC tree on master

[Matthias Klose]

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 0/4] Eliminate cc0 from m68k

[Matthias Klose]

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.

[patch] install the lto-dump man page

[Matthias Klose]

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] Fix build with ISL 0.20

[Matthias Klose]

On 01.08.2018 09:13, Richard Biener wrote:
> 
> The following fixes build with ISL 0.20, tested by building with
> ISL 0.20 and 0.15 (the oldest supported ISL).
> 
> Applied to trunk, will commit to the branches as well.

that was committed to the 7 and 8 branches, but not the 6 branch. Now done as 
well.

Matthias

> 
> Richard.
> 
> 2018-08-01  Richard Biener  
> 
>   PR bootstrap/86724
>   * graphite.h: Include isl/id.h and isl/space.h to allow build
>   with ISL 0.20.
> 
> Index: gcc/graphite.h
> ===
> --- gcc/graphite.h(revision 263190)
> +++ gcc/graphite.h(working copy)
> @@ -37,6 +37,8 @@ along with GCC; see the file COPYING3.
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  typedef struct poly_dr *poly_dr_p;
>  
> 

Re: [PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace

[Matthias Klose]

On 16.06.2017 17:39, Denis Khalikov wrote:
> Hello everyone,
> 
> This is a patch for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77631
> 
> Can some one please review attached patch.

not a full review, but it looks like the system debug files based on build-id's
are not found.  In newer distro releases you find these at

$ ls /usr/lib/debug/.build-id/
00/ 0d/ 1a/ 25/ 2e/ 3a/ 45/ 4d/ 57/ 64/ 6d/ 77/ 82/ 8b/ 94/ a0/ a9/ b7/ c1/ cd/
d6/ e0/ eb/ f6/
01/ 0e/ 1b/ 26/ 2f/ 3b/ 46/ 4e/ 58/ 65/ 6e/ 78/ 83/ 8c/ 95/ a1/ ac/ b9/ c4/ ce/
d7/ e1/ ec/ f7/
02/ 11/ 1c/ 27/ 30/ 3d/ 47/ 50/ 59/ 66/ 6f/ 79/ 84/ 8e/ 96/ a2/ ae/ ba/ c5/ d0/
d8/ e3/ ee/ f9/
03/ 15/ 1d/ 28/ 32/ 3e/ 48/ 51/ 5b/ 67/ 70/ 7a/ 85/ 8f/ 99/ a3/ b0/ bb/ c6/ d1/
d9/ e4/ ef/ fb/
05/ 16/ 1e/ 29/ 35/ 41/ 49/ 52/ 5c/ 68/ 72/ 7b/ 87/ 90/ 9a/ a4/ b1/ bc/ c8/ d2/
db/ e5/ f1/ fc/
08/ 17/ 1f/ 2a/ 36/ 42/ 4a/ 53/ 5e/ 69/ 73/ 7c/ 88/ 91/ 9b/ a5/ b2/ be/ c9/ d3/
dc/ e6/ f2/ fd/
09/ 18/ 20/ 2b/ 37/ 43/ 4b/ 54/ 60/ 6a/ 75/ 7f/ 89/ 92/ 9c/ a6/ b4/ bf/ cb/ d4/
dd/ e7/ f3/ fe/
0a/ 19/ 24/ 2d/ 39/ 44/ 4c/ 55/ 61/ 6b/ 76/ 80/ 8a/ 93/ 9f/ a7/ b5/ c0/ cc/ d5/
de/ e8/ f5/ ff/

the first two bytes of the crc make the sub dir name, the debug file name has
these first two bytes omitted.

$ ls /usr/lib/debug/.build-id/0d
c55467dc9eb81a00c7715a790844e7cf035345.debug

objdump/objcopy in binutils 2.28 has these lookups properly working.

Matthias

Re: [PATCH] multiarch support for non-glibc linux systems

[Matthias Klose]

On 07.06.2017 19:22, Szabolcs Nagy wrote:
> Current multiarch directory name is always *-linux-gnu* on linux,
> this patch configures different names for uclibc and musl targets.
> (tested by the debian rebootstrap scripts for various *-linux-musl
> and *-linux-uclibc targets see debian bug #861588)
> 
> gcc/
> 2017-06-07  Szabolcs Nagy  
> 
>   * config.gcc (*-linux-musl*): Add t-musl tmake_file.
>   (*-linux-uclibc*): Add t-uclibc tmake_file.
>   * config/t-musl: New.
>   * config/t-uclibc: New.

I can't formally approve that, but this looks ok.

Matthias

Re: Hurd port for gcc-7 go PATCH 1-3(15)

[Matthias Klose]

On 06.11.2017 16:36, Svante Signell wrote:
> Hi,
> 
> Attached are patches to enable gccgo to build properly on Debian
> GNU/Hurd on gcc-7 (7-7.2.0-12).

sysinfo.go:6744:7: error: redefinition of 'SYS_IOCTL'
 const SYS_IOCTL = _SYS_ioctl
   ^
sysinfo.go:6403:7: note: previous definition of 'SYS_IOCTL' was here
 const SYS_IOCTL = 0
   ^
the patches break the build on any Linux architecture.  Please could you test
your patches against a linux target as well?

Re: [Patch][Aarch64] Fix multi-arch support in ILP32 mode

[Matthias Klose]

On 21.12.2017 22:59, Steve Ellcey wrote:
> On Thu, 2017-12-21 at 20:55 +, James Greenhalgh wrote:
>> On Thu, Dec 21, 2017 at 06:56:22PM +, Steve Ellcey wrote:
>>>
>>> This one line patch for multi-arch support on Aarch64 and ILP32 was
>>> submitted over a year ago and pinged a number of time since then,
>>> since no one has objected and since it is only one line I am going
>>> to check it in as an obvious fix.
>> I think this is not obvious, and worse incorrect. I contacted Andrew
>> off-list back in September to ask about this patch, the problem is
>> the
>> triplet used here:
>>
>>>
>>> -MULTILIB_OSDIRNAMES += mabi.ilp32=../libilp32
>>> +MULTILIB_OSDIRNAMES += mabi.ilp32=../libilp32$(call
>>> if_multiarch,:aarch64$(AARCH_BE)_ilp32-linux-gnu)
>> As far as I understand it from Linaro connect and conversations with
>> Debian/Ubuntu port maintainers, the correct triplet should be:
>>
>>   aarch64-none-linux-gnu_ilp32
>>
>> If you're revisiting this patch, it is OK to go in, but please use the
>> agreed triplet.

well, it's called triplet, not quadruplet. No other multiarch tuple contains an
explicit vendor field. Do you really want to use that?

>> Thanks,
>> James
> 
> OK, I fixed the triplet and checked it in.

hmm ...

Matthias