For building ghdl, the compiler needs to be patched to know the "vhdl"
language. Could that patch be applied to the upstream GCC, so that not
everybody needs to patch GCC to build ghdl?
Thanks, Matthias
Make vhdl known to the PPC backend. See
see https://github.com/ghdl/ghdl/blob/master/doc/
This builds and installs the gcobol driver for a cross build, tested
with an amd64 -> arm64 cross build. Ok for the trunk?
Matthias
--- a/gcc/cobol/Make-lang.in
+++ b/gcc/cobol/Make-lang.in
@@ -38,6 +38,7 @@ GCOBOL_INSTALL_NAME := $(shell echo gcobol|sed '$(program_transform_name)')
GCOBOL_TAR
the gcobol and gcobc binaries are currently installed without honoring
the program prefix and program suffix. Honor these while installing.
Ok for the trunk?
Matthias
--- a/gcc/cobol/Make-lang.in
+++ b/gcc/cobol/Make-lang.in
@@ -34,8 +34,10 @@
# - the compiler proper (eg: cc1plus)
# - define
libgcobol/ChangeLog
* Makefile.in: New file.
* acinclude.m4: New file.
* aclocal.m4: New file.
* configure.ac: New file.
* configure.tgt: New file.
I had updated the configure.tgt, please find it attached here again.
also disabling cobol in the toplevel co
When configuring GCC with --program-suffix=-$(BASE_VERSION) to allow
installation multiple GCC versions in parallel, the executable of the
driver (gcc-$(BASE_VERSION)) gets recorded in the libgccjit.so.0
library. Assuming, that you only install the libgccjit.so.0 library
from the newest GCC, y
On 06.02.25 00:36, Robert Dubner wrote:
-Original Message-
From: Matthias Klose
Sent: Tuesday, December 17, 2024 04:26
To: Joseph Myers
Cc: gcc-patches@gcc.gnu.org; James K. Lowden
Subject: Re: The COBOL front end, in 8 notes + toplevel patch
On 17.12.24 00:58, Joseph Myers wrote
On 11.01.25 01:02, Jeff Law wrote:
On 1/7/25 7:24 PM, YunQiang Su wrote:
Jeff Law 于2025年1月8日周三 07:06写道：
On 1/1/25 6:42 PM, YunQiang Su wrote:
Matthias Klose 于2025年1月1日周三
22:37写道：
in https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641619.html
there are two typos in the patch
in https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641619.html
there are two typos in the patch, compared to the local Debian patch,
- the subst macro has an additional parameter
- the multilib subdirs are not subdirs in lib, but have
their multilib suffix attached to lib.
ok for th
On 17.12.24 00:58, Joseph Myers wrote:
On Mon, 16 Dec 2024, Matthias Klose wrote:
On 14.12.24 15:38, Matthias Klose wrote:
I tried to use the patches to build binary packages for Debian. Found some
issues:
tried to build libgcobol on more architectures, please find the attached patch
to
On 14.12.24 15:38, Matthias Klose wrote:
I tried to use the patches to build binary packages for Debian. Found
some issues:
tried to build libgcobol on more architectures, please find the attached
patch to disable building libgcobol on some architectures.
how should patches and build
I tried to use the patches to build binary packages for Debian. Found
some issues:
gcc/cobol:
- the config-lang.in is provided in both patch 04 and patch 08.
- the installation path for the gcobc script is missing the gcc/
subdir. Does it make sense to ship the script without the udf
files
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 Sola
On 10.11.22 20:05, apinski--- via Binutils wrote:
From: Andrew Pinski
This patch uses the toplevel configure parts for GMP/MPFR for
gdb. The only thing is that gdb now requires MPFR for building.
Before it was a recommended but not required library.
Also this allows building of GMP and MPFR wit
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-gnux3
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 document
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
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 fix
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:
>>
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. Th
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.
>>
>
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.p
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
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 optio
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
> duplic
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
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 se
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/g
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.
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;
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
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
pe.
> (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_funct
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_C
On 1/10/21 10:18 PM, Martin Sebor wrote:
> On 1/10/21 3:29 AM, Matthias Klose wrote:
>> is the newline intended? It's followed by a debug_rtx call.
>
> To avoid the warning there shouldn't be any trailing punctuation
> or whitespace in the message. The GCC qu
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 ..
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 &#
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 gn
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 p
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.
>>>
>>>
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 req
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 req
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(
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 wi
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])
> +o
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 lett
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
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 @
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 gencon
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:
>>>>
&g
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,
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
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_
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
*
ote:
>>>>>
>>>>> 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 M
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 lin
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 patc
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 Spac
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
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 5b075372b4
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 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
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
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) t
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.
>
> unfortuna
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/
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
On 09.09.19 15:51, Richard Biener wrote:
On Mon, 9 Sep 2019, Matthias Klose wrote:
On 09.09.19 14:02, Richard Biener wrote:
So this is really a very poor mans solution that also might
uncover issues with -g0 at compile-time vs. -g at link-time
if there are mixed -g0/g TUs in the LTO link
On 09.09.19 14:02, Richard Biener wrote:
So this is really a very poor mans solution that also might
uncover issues with -g0 at compile-time vs. -g at link-time
if there are mixed -g0/g TUs in the LTO link.
Could this be documented, at least in the man page? e.g. invoke.texi. As a
bonus I wou
On 21.08.19 10:02, Iain Buclaw wrote:
> Hi,
>
> This patch merges the libdruntime library with upstream druntime 5bb8ce19.
>
> Synchronizes extern(C) bindings with the latest release, mostly this
> is just Musl target support.
>
> Bootstrapped and regression tested on x86_64-linux-gnu and x86_64
On 14.06.19 15:09, Gaius Mulley wrote:
I checked that gm2 cross compilers can be built. One minor nit: The man page is
installed without suffix and prefix.
gcc/gm2/Make-lang.in has
GM2_CROSS_NAME = `echo gm2|sed '$(program_transform_cross_name)'`
The program_transform_cross_name macro was remov
On 14.06.19 15:09, Gaius Mulley wrote:
>
> Hello,
>
> here is version two of the patches which introduce Modula-2 into the
> GCC trunk. The patches include:
>
> (*) a patch to allow all front ends to register a lang spec function.
>(included are patches for all front ends to provide
On 08.07.19 23:19, Matthias Klose wrote:
> On 14.06.19 15:09, Gaius Mulley wrote:
>>
>> Hello,
>>
>> here is version two of the patches which introduce Modula-2 into the
>> GCC trunk. The patches include:
>>
>> (*) a patch to allow al
On 08.07.19 23:19, Matthias Klose wrote:
> On 14.06.19 15:09, Gaius Mulley wrote:
>>
>> Hello,
>>
>> here is version two of the patches which introduce Modula-2 into the
>> GCC trunk. The patches include:
>>
>> (*) a patch to allow al
On 10.07.19 22:07, Gaius Mulley wrote:
> Matthias Klose writes:
>
>> On 09.07.19 23:30, Matthias Klose wrote:
>>> On 09.07.19 21:48, Gaius Mulley wrote:
>>>> Matthias Klose writes:
>>>>
>>>>>> - libpth.{a,so} is installed in the sy
On 09.07.19 23:30, Matthias Klose wrote:
> On 09.07.19 21:48, Gaius Mulley wrote:
>> Matthias Klose writes:
>>
>>>> - libpth.{a,so} is installed in the system libdir, which
>>>>conflicts with the installation of the libpth packages
>>>>
On 09.07.19 23:35, Matthias Klose wrote:
> On 08.07.19 23:19, Matthias Klose wrote:
>> On 14.06.19 15:09, Gaius Mulley wrote:
>>>
>>> Hello,
>>>
>>> here is version two of the patches which introduce Modula-2 into the
>>> GCC trunk. The patc
On 08.07.19 23:19, Matthias Klose wrote:
> On 14.06.19 15:09, Gaius Mulley wrote:
>>
>> Hello,
>>
>> here is version two of the patches which introduce Modula-2 into the
>> GCC trunk. The patches include:
>>
>> (*) a patch to allow al
On 09.07.19 21:48, Gaius Mulley wrote:
> Matthias Klose writes:
>
>>> - libpth.{a,so} is installed in the system libdir, which
>>>conflicts with the installation of the libpth packages
>>>on most distros.
>>
>> found out that a system provid
On 09.07.19 17:53, Gaius Mulley wrote:
> Rainer Orth writes:
>
>> Hi Matthias,
>>
>>> I had a look at the GCC 9 version of the patches, with a build including a
>>> make
>>> install. Some comments:
>>>
>>> - A parallel build (at least with -j4) isn't working. A sequental
>>>build works fine
On 09.07.19 15:41, Gaius Mulley wrote:
> Matthias Klose writes:
>
>>> the libraries ./usr/lib/x86_64-linux-gnu/lib{ulm,pim,gm2,cor,iso,min}.a
>>> are not needed the correct locations of the static libraries are:
>>>
>>> ./usr/lib/gcc/x86_64-linux-gnu/
On 09.07.19 14:02, Gaius Mulley wrote:
> Matthias Klose writes:
>
>>> - There are three letter libraries with pretty generic
>>>names installed into the system libdir: log, iso, cor,
>>>min, ulm. At least for log, you have a file conflict
>>>
On 08.07.19 23:19, Matthias Klose wrote:
> On 14.06.19 15:09, Gaius Mulley wrote:
>>
>> Hello,
>>
>> here is version two of the patches which introduce Modula-2 into the
>> GCC trunk. The patches include:
>>
>> (*) a patch to allow al
On 08.07.19 23:19, Matthias Klose wrote:
> On 14.06.19 15:09, Gaius Mulley wrote:
>>
>> Hello,
>>
>> here is version two of the patches which introduce Modula-2 into the
>> GCC trunk. The patches include:
>>
>> (*) a patch to allow al
On 14.06.19 15:09, Gaius Mulley wrote:
>
> Hello,
>
> here is version two of the patches which introduce Modula-2 into the
> GCC trunk. The patches include:
>
> (*) a patch to allow all front ends to register a lang spec function.
>(included are patches for all front ends to provide
On 04.07.19 08:50, Arnaud Charlet wrote:
> OK, thanks.
checked in. Ok for the gcc-9 branch as well?
Matthias
>> From: James Clarke
>>
>> Monotonic_Clock and RT_Resolution in the recently-added s-tpopmo.adb
>> call clock_gettime/clock_getres with the integral constants from OSC and
>> thus rely
On 27.04.19 14:08, Iain Buclaw wrote:
> On Sat, 27 Apr 2019 at 12:24, Jakub Jelinek wrote:
>>
>> On Sat, Apr 27, 2019 at 11:26:15AM +0200, Matthias Klose wrote:
>>> On 15.03.19 16:49, Robin Dapp wrote:
>>>> during the last few days I tried to get D running on
On 15.03.19 16:49, Robin Dapp wrote:
> Hi,
>
> during the last few days I tried to get D running on s390x (apparently
> the first Big Endian platform to try it?). I did not yet go through the
> code systematically and add a version(SystemZ) in every place where it
> might be needed but rather tri
On 29.03.19 23:23, Iain Buclaw wrote:
> On Mon, 18 Feb 2019 at 14:26, Matthias Klose wrote:
>>
>>
>> sorry, I didn't mean to propose to rename the option, so
>> --with-target-system-zlib=auto sounds fine.
>
> OK, a bit belated, but here it is --with-target
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
&
On 26.02.19 15:06, Richard Biener wrote:
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
> sofar.
That was backported to the gcc-8 branch, and now Richard approved the backport
the gcc-7 branch.
Matthias
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_li
On 07.03.19 00:39, Jakub Jelinek wrote:
> Hi!
>
> The following patch tries to improve diagnostics of toplevel asm qualifiers
> in C++ by actually parsing them and complaining if they appear at toplevel,
> instead of just emitting a parse error that ( is expected, e.g. some
> versions of Qt do use
On 05.03.19 16:22, Jakub Jelinek wrote:
> Hi!
>
> powerpc-linux-gnu is apparently the only target that provides
> MULTIARCH_DIRNAME unconditionally, all others properly wrap that with
> if_multiarch, which decides if it should be used (--enable-multiarch,
> or if the test for automatic multiarch s
On 17.02.19 17:07, Iain Buclaw wrote:
> On Sat, 16 Feb 2019 at 13:44, Matthias Klose wrote:
>>
>> On 12.02.19 21:54, Iain Buclaw wrote:
>>> On Tue, 12 Feb 2019 at 10:40, Richard Biener
>>> wrote:
>>>>
>>>> On Sat, Feb 9, 2019 at 10:37 AM
On 12.02.19 21:54, Iain Buclaw wrote:
> On Tue, 12 Feb 2019 at 10:40, Richard Biener
> wrote:
>>
>> On Sat, Feb 9, 2019 at 10:37 AM Iain Buclaw wrote:
>>>
>>> On Mon, 28 Jan 2019 at 13:10, Richard Biener
>>> wrote:
On Mon, Jan 21, 2019 at 7:35 PM Iain Buclaw wrote:
>
> Hi,
>
On 15.02.19 15:52, Ian Lance Taylor wrote:
> This patch by Robin Dapp adds S/390 support to the internal/cpu
> package. This partially addresses PR 89123. I bootstrapped it on
> x86_64-pc-linux-gnu, which means little. Committed to mainline.
fails in the -m31 multilib variant with
libtool: com
On 07.02.19 06:04, Ian Lance Taylor wrote:
> On Thu, Jan 31, 2019 at 7:40 AM Svante Signell
> wrote:
>>
>> As advised by the Debian gcc maintainer Matthias Klose and golang
>> developer Ian Lance Taylor I'm re-submitting the patches for
>> the port of gccgo t
On 18.01.19 20:04, Ian Lance Taylor wrote:
> I have committed a patch to update libgo to the Go 1.12beta2 release.
>
> As usual this sort of update is too large to include all changes in
> this e-mail. I've included changes to gccgo-specific files below.
>
> Bootstrapped and ran Go testsuite on
n 8;
>> + case DW_EH_PE_absptr:
>> + return sizeof(uintptr);
>>default:
>> break;
>> }
>
>
> Thanks.
>
> Committed to mainline.
>
> Ian
>
>
>
>> On Tue, Dec 11, 2018 at 7:03 PM Matthias Klose
On 11.12.18 22:01, Cherry Zhang wrote:
> On Tue, Dec 11, 2018 at 3:51 PM Ian Lance Taylor wrote:
>
>> On Tue, Dec 11, 2018 at 6:52 AM Matthias Klose wrote:
>>>
>>> On 10.12.18 16:54, Cherry Zhang wrote:
>>>> On Mon, Dec 10, 2018 at 1:41 AM Matthias Klo
1 - 100 of 454 matches
Mail list logo
