On 08/13/2011 06:02 PM, Sebastian Pop wrote:
> On Sat, Aug 13, 2011 at 10:32, Joseph S. Myers
> wrote:
>> I advise either removing the option for CLooG to use bundled ISL, or
>> making the bundled version the recommended version for GCC. Having too
>> many ways to configure things is bad.
>
> I
On 08/12/2011 04:16 PM, Ramana Radhakrishnan wrote:
>>> @@ -24183,4 +24306,13 @@ arm_attr_length_push_multi(rtx parallel_op, rtx
>>> first_op)
>>>return 4;
>>> }
>>>
>>> +/* Compute the number of instructions emitted by output_move_double. */
>>> +int
>>> +arm_count_output_move_double_insns
p://lists.debian.org/debian-mips/2006/03/msg4.html
2011-08-20 Matthias Klose
* doc/invoke.texi: Document -print-multiarch.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
* genmultilib: Add new option for the multiarch name.
* gcc.c (mu
document MULTILIB_OSDIRNAMES, copied from genmultilib.
Ok for the trunk?
Matthias
PR bootstrap/25508
* doc/fragments.texi: Document MULTILIB_OSDIRNAMES.
Index: gcc/doc/fragments.texi
===
--- gcc/doc/fragments.texi
On 08/21/2011 12:21 AM, Joseph S. Myers wrote:
> On Sat, 20 Aug 2011, Matthias Klose wrote:
>
>> +@findex MULTILIB_OSDIRNAMES
>> +@item MULTILIB_OSDIRNAMES
>> +If @code{MULTILIB_OPTIONS} is used, this variable specifies the list
>> +of OS subdirectory names. The f
On 08/20/2011 10:07 PM, Jakub Jelinek wrote:
> On Sat, Aug 20, 2011 at 09:51:33PM +0200, Matthias Klose wrote:
>> Tested on non-multilib'd and multilib'd systems, both native and cross
>> builds.
>> Ok for the trunk?
>
> I don't think we want to do this
On 08/20/2011 10:39 PM, Joseph S. Myers wrote:
> On Sat, 20 Aug 2011, Matthias Klose wrote:
>
>> The multiarch triplets are defined in the target specific tmake files, and
>> provided for all known existing multiarch implementations (currently Debian,
>> Ubuntu an
On 08/20/2011 09:51 PM, Matthias Klose wrote:
> Multiarch [1] is the term being used to refer to the capability of a system to
> install and run applications of multiple different binary targets on the same
> system. The idea and name of multiarch dates back to 2004/2005 [2] (to be
&
While looking at the multiarch patches, I noticed that a previous change is not
necessary. MULTILIB_DEFAULTS is handled in config/mips/mips.h.
Matthias
gcc/
2011-08-22 Matthias Klose
Revert:
2011-07-11 Arthur Loiret
Matthias Klose
* config
This did break libobjc and libjava on arm-linux-gnueabi.
libobjc now has an undefined reference to _Unwind_decode_target2, which can be
avoided with
--- libobjc/exception.c.orig2011-07-21 15:33:57.0 +
+++ libobjc/exception.c 2011-10-09 10:53:12.554940776 +
@@ -182,7 +182,7 @@
2011-10-10 Matthias Klose
* common/config/m32c: Remove empty directory.
committed as obvious. the last file in this directory was removed in r175969.
On 10/10/2011 12:32 PM, Andrew Haley wrote:
> On 10/09/2011 12:09 PM, Matthias Klose wrote:
>> This did break libobjc and libjava on arm-linux-gnueabi.
>>
>> libobjc now has an undefined reference to _Unwind_decode_target2, which can
>> be
>> avoided with
with
libgo currently has some empty directories. ok to remove?
D go/encoding/line
D go/exp/ogle
D go/exp/eval
D go/exp/draw
D go/exp/draw/x11
2011-10-10 Matthias Klose
* config/posix95: Remove empty directory.
The last files in config/posix95 were removed in r177568. Comitted as obvious.
Matthias
fix typo in message, committed as obvious.
Matthias
2011-12-03 Matthias Klose
* expr.c (SPECIAL_WIDE): Fix typo in message.
Index: gcc/java/expr.c
===
--- gcc/java/expr.c (revision 181969)
+++ gcc/java/expr.c
Ok to remove these three empty directories?
libgo/go/exp/template
libstdc++-v3/testsuite/30_threads/condition_variable_any/requirements
libgomp/config/linux/arm
On 24.01.2012 00:27, Benjamin Kosnik wrote:
This modularizes the libstdc++ sources such that the resulting library
binaries are now composed of three convenience libraries. In short:
this breaks builds configured with --enable-libstdcxx-debug. Tried the following
(not yet working) fix.
Ma
On 25.01.2012 06:26, Benjamin Kosnik wrote:
this breaks builds configured with --enable-libstdcxx-debug.
confirmed
Tried
the following (not yet working) fix.
OK. The attached is closer, but still not quite there.
one step further, to avoid the endless recursion in the install-debug t
two places. Afaics, there are no other places.
With the patch, both the include paths and the library paths start with a single
slash. No regressions seen running the testsuite on x86_64-linux-gnu.
Matthias
2012-01-24 Matthias Klose
* gcc.c (add_sysrooted_prefix): Don
On 25.01.2012 17:45, Joseph S. Myers wrote:
On Wed, 25 Jan 2012, Matthias Klose wrote:
This can end up in generation for dependency files, and other files parsing
the output. The solution I came up with is to check for sysroot set to '/' and
special case this in two places. Afaics,
on sparc-linux, the TIOCNOTTY and TIOCSCTTY constants are defined as
#define TIOCNOTTY _IO('t', 113)
which cannot be parsed by mksysinfo.sh. Just define these as TIOCGWINSZ is
defined. This lets the libgo build succeed, but I see the same failures as
reported in PR52084 for powerpc-linux-
On 26.01.2012 18:57, Joseph S. Myers wrote:
On Thu, 26 Jan 2012, Matthias Klose wrote:
On 25.01.2012 17:45, Joseph S. Myers wrote:
On Wed, 25 Jan 2012, Matthias Klose wrote:
This can end up in generation for dependency files, and other files
parsing
the output. The solution I came up with
On 08.02.2012 02:01, Joseph S. Myers wrote:
On Wed, 8 Feb 2012, Matthias Klose wrote:
there is one more issue, when configuring
--with-sysroot=/ --with-gxx-include-dir=/usr/include/c++/4.7
in that the leading / is stripped away in configure.ac. This case needs an
explicit check. Ok for the
On 04.03.2012 22:20, Anthony Green wrote:
Hello,
The attached patch includes changes that have been reviewed, approved and merged
into the stand-alone libffi release tree**.
** http://github.com/atgreen/libffi
does this correspond to a libffi release or release candidate?
Two issues with the installation of plugin header files.
- the c-family/* headers are used with the the c-family/ prefix
in include directives. therefore they must not installed into
the flattened plugin include dir, but kept in the subdir.
- PR45078; vxworks-dummy.h is included for cpu_t
On 06/20/2011 05:18 PM, Joseph S. Myers wrote:
> On Mon, 20 Jun 2011, Matthias Klose wrote:
>
>> - PR45078; vxworks-dummy.h is included for cpu_type in arm,
>>i386, mips, sh and sparc but only installed when it's i386; copy it
>>manually anytime.
>
needed to get access to the enable_shared macro.
I'm unsure about the check in the switch construct. Taken from libtool.m4, and
determining the value of enable_shared_with_static_runtimes.
Ok for the trunk?
2011-07-07 Matthias Klose
* Makefile.def (target_modules
On 07/07/2011 06:51 PM, David Daney wrote:
> On 07/07/2011 09:27 AM, Matthias Klose wrote:
>> As discussed at the Google GCC gathering, disable the build of static
>> libraries
>> in libjava, which should cut the build time of libjava by 50%. The static
>> libjava bu
On 07/07/2011 07:56 PM, Andrew Haley wrote:
> On 07/07/11 18:02, David Daney wrote:
>> On 07/07/2011 09:57 AM, Matthias Klose wrote:
>>> On 07/07/2011 06:51 PM, David Daney wrote:
>>>> On 07/07/2011 09:27 AM, Matthias Klose wrote:
>>>>> As discussed a
On 07/07/2011 10:35 PM, Ralf Wildenhues wrote:
> Hi Matthias,
>
> On Thu, Jul 07, 2011 at 10:26:59PM +0200, Jakub Jelinek wrote:
>> On Thu, Jul 07, 2011 at 10:22:37PM +0200, Matthias Klose wrote:
>>> +AC_PROG_LIBTOOL
>
> This tests the wrong compiler and toolchai
On 06/25/2009 11:23 AM, Arthur Loiret wrote:
> Hello,
>
> 2009/6/24, Matthias Klose :
>> Richard Sandiford schrieb:
>>> Thanks for the update.
>>>
>>> This patch didn't go in at the time because Arthur's copyright
>>> assignment we
On 03/25/2009 04:30 PM, Andreas Krebbel wrote:
>> 2009-03-23 Arthur Loiret
>>
>> * config.gcc (s390-*-linux*): If 'enabled_targets' is 'all', build
>> a bi-arch compiler defaulting to 31-bit. In this case:
>> (tmake_file): Add s390/t-linux64.
>> * doc/install.texi: Add s390-l
On 07/11/2011 05:18 PM, Romain Geissler wrote:
> This patch add a new exception to the plugin header flattering strategy.
> c-family files can't be installed in the plugin include root directory as some
> other files like cp/cp-tree.h will look for them in the c-family directory.
>
> Furthermore,
fix a typo in doc/extend.texi, committed as obvious.
Matthias
2011-07-14 Matthias Klose
* doc/extend.texi (optimize attribute): Fix typo.
Index: doc/extend.texi
===
--- doc/extend.texi (revision 176263)
+++ doc
On 07/14/2011 01:44 PM, Richard Guenther wrote:
> On Thu, Jul 14, 2011 at 1:41 PM, Matthias Klose wrote:
>> fix a typo in doc/extend.texi, committed as obvious.
>
> Specify the architecture to generate code for when compiling the
> -function. If you select the @code{&
On 07/15/2011 09:29 PM, Jason Merrill wrote:
> On 07/13/2011 04:28 PM, Jason Merrill wrote:
>> I'm using --tool_opts to pass the extra -std=c++0x argument to the
>> compiler. Previously in my own testing I've used
>> --target_board=unix/-std=c++0x, but that is problematic because options
>> from --
On 05/02/2011 09:53 PM, Diego Novillo wrote:
Since google/gcc-4_6 follows the 4.6 branch, changes in minor
revisions cause unnecessary churn in directory names.
Fixed with this. OK for google/gcc-4_6?
Google ref 4335466.
* BASE-VER: Change to 4.6.x-google.
diff --git a/gcc/BA
On 10.03.2011 17:04, Jakub Jelinek wrote:
> +default by -Wall flag and
> -Wunused-but-set-parameter
> +by -Wall -W flags.
-W is documented as "old option". Maybe use -Wextra instead?
Matthias
On 08.03.2011 20:52, Diego Novillo wrote:
> On Tue, Aug 17, 2010 at 04:58, Nick Clifton wrote:
>> Hi Raymes,
>>
>>> What is the status of this patch? I see the binutils part applied but
>>> not the gcc part.
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00402.html
>>
>> Mark Mitchell recent
On 17.03.2011 07:51, Benjamin Kosnik wrote:
>
> Needs some more work, here's a rough draft.
>
> -benjamin
+ As a workaround, remove -Werror until the new warnings
+ are fixed, or for conversion warnings
+ add -Wno-unused-but-set-variable
+ or -Wno-unused-but-set-parameter.
+
what about recomme
On 05.03.2011 15:37, Richard Sandiford wrote:
> Jakub Jelinek writes:
>> On Fri, Mar 04, 2011 at 01:56:55PM +, Richard Sandiford wrote:
>>> * dwarf2out.c (dw_loc_list_node): Add resolved_addr and replaced.
>>> (cached_dw_loc_list_def): New structure.
>>> (cached_dw_loc_list): New t
On 04.04.2011 20:17, Paul Pluzhnikov wrote:
> Greetings,
>
> Several Linux distributions (e.g. Fedora) carry local patches that turn
> on --hash-style=gnu for all links.
>
> Attached is a proposed patch (originally by Satoru Takabayashi) that makes
> default hash style a configure option.
>
> Te
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 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
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 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
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
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
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
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
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/
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
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
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
401 - 454 of 454 matches
Mail list logo
