Hi,
We've decided to apply the following patch to ARM/embedded-6-branch.
Best regards,
Thomas
--- Begin Message ---
Hi,
This patch is part of a patch series to add support for atomic operations on
ARMv8-M Baseline targets in GCC. This specific patch adapts atomic and exclusive
load and stor
Hi,
We've decided to apply the following patch to ARM/embedded-6-branch.
Best regards,
Thomas
--- Begin Message ---
Hi,
This patch is part of a patch series to add support for atomic operations on
ARMv8-M Baseline targets in GCC. This specific patch refactors the expander and
splitter for a
Hi,
We've decided to apply the following patch to ARM/embedded-6-branch.
Best regards,
Thomas
--- Begin Message ---
Hi,
This patch is part of a patch series to add support for atomic operations on
ARMv8-M Baseline targets in GCC. This specific patch makes the necessary change
for compare an
Hi,
We've decided to apply the following patch to ARM/embedded-6-branch.
Best regards,
Thomas
--- Begin Message ---
Hi,
This patch is part of a patch series to add support for atomic operations on
ARMv8-M Baseline targets in GCC. This specific patch adds support for remaining
atomic operati
Hi,
We've decided to apply the following patch to ARM/embedded-6-branch.
Best regards,
Thomas
--- Begin Message ---
Sorry, noticed an error in the patch. It was not caught during testing because
GCC was built with --with-mode=thumb. Correct patch attached.
Best regards,
Thomas
On 22/09/16
Hi,
We've decided to apply the following patch to ARM/embedded-6-branch.
Best regards,
Thomas
--- Begin Message ---
Hi,
This patch is part of a patch series to add support for atomic operations on
ARMv8-M Baseline targets in GCC. This specific patch enables atomic and
synchronization suppor
Hi,
I'm going to hookize TARGET_FLT_EVAL_METHOD, so the current definition
of TARGET_FLT_EVAL_METHOD_NON_DEFAULT will stop working.
I looked in to ways of redefining this macro, but each that I explored would
require pulling in target.h in front-ends that don't otherwise need it.
Rather than do
This patch from Marek Polacek adds a missing break statement in the Go
frontend code. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERG
On 22/09/16 16:28, Richard Earnshaw (lists) wrote:
> On 22/09/16 16:04, Andre Vieira (lists) wrote:
>>
>> I reworked the patch according to the comments above.
>>
>> Is this OK?
>>
>> gcc/ChangeLog:
>> 2016-09-22 Andre Vieira
>> Terry Guo
>>
>> * target.def (elf_flags_numer
On Wed, 21 Sep 2016, John David Anglin wrote:
> The alignment of 16 arises in code that used the ldcw instruction.
> Although this could be avoided in glibc there are numerous other
> packages with objects requiring 16-byte alignment. So, I'm tending
> to think the typedef for max_align_t should
On Wed, 21 Sep 2016, Marek Polacek wrote:
> > > > And let's refer to "expression of type bool" rather than "boolean
> > > > expression".
> > >
> > > Adjusted (and in the C FE too).
> >
> > Hmm, I'm not sure that change is right for C. But the C++ hunk is OK.
>
> Thanks. Joseph, how about the
On 09/21/2016 06:28 PM, Martin Sebor wrote:
PR target/77676 - powerpc64 and powerpc64le stage2 bootstrap fail
gcc/testsuite/ChangeLog:
2016-09-21 Martin Sebor
PR target/77676
* gcc.dg/tree-ssa/builtin-sprintf-2.c: Fix typo.
* gcc.dg/tree-ssa/builtin-sprintf-3.c: New
On 04/27/2016 09:47 AM, Bernd Edlinger wrote:
Am 27.04.2016 um 17:37 schrieb Rainer Orth:
Bernd Edlinger writes:
On 26.04.2016 22:14, Joseph Myers wrote:
On Tue, 26 Apr 2016, Bernd Edlinger wrote:
Hi,
as we all know, it's high time now to adjust the minimum supported
gmp/mpfr/mpc versio
Dear Andre,
Yes, this is fine for trunk. Thanks for fixing it so quickly.
Best regards
Paul
On 22 September 2016 at 17:09, Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes compatibility with opencoarrays by using the old coarray
> interface of caf_get() as long as possible.
>
> Boot
On Thu, 22 Sep 2016, Martin Sebor wrote:
> In light of this risk and given that the recommended MPFR version
> is still 2.4 I wonder if the download_prerequisites script shouldn't
> instead download the minimum supported version. That way those of
No, it should download the latest version known
On 09/22/16 19:26, Martin Sebor wrote:
> On 04/27/2016 09:47 AM, Bernd Edlinger wrote:
>>
>>
>> Yes, when they are pre-installed there should be no problem.
>> Also newer versions than these seem to work.
>>
>> In-tree only the versions that download_prerequisite picks are
>> tested and guaranteed
On Thu, 22 Sep 2016, Prathamesh Kulkarni wrote:
> Would that be acceptable ? I am not sure how to make %Z check if the
> argument has type vec *
> since vec is not really a builtin C type.
> Could you suggest me a better solution so that the format checker will check
> if arg has type vec * instea
On Thu, 22 Sep 2016, James Greenhalgh wrote:
> The relaxation isn't portable, and keeping it in place is tricky, so this
> patch removes it, and poisons TARGET_FLT_EVAL_METHOD_NON_DEFAULT in
> system.h to prevent future use.
>
> Bootstrapped and tested on x86_64 with --enable-languages=all,ada,go
On September 22, 2016 8:00:40 PM GMT+02:00, Joseph Myers
wrote:
>On Thu, 22 Sep 2016, Bernd Edlinger wrote:
>
>> There is no feasible way how to make all gmp/mpfr/mpc versions from
>> minimal to latest build for all targets and all possible
>> cross-configurations.
>>
>> I hope that we do not "r
On Thu, 22 Sep 2016, Bernd Edlinger wrote:
> There is no feasible way how to make all gmp/mpfr/mpc versions from
> minimal to latest build for all targets and all possible
> cross-configurations.
>
> I hope that we do not "recommend" these versions.
>
> They are only the minimum versions for pre
Martin Sebor writes:
> [...]
>
>> In-tree only the versions that download_prerequisite picks are
>> tested and guaranteed to work.
>
> I was made aware today that my recent patch for pr49905 broke
> bootstrap with MPFR 2.4:
>
> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01507.html
>
> In lig
On 09/22/16 20:00, Joseph Myers wrote:
> On Thu, 22 Sep 2016, Bernd Edlinger wrote:
>
>> There is no feasible way how to make all gmp/mpfr/mpc versions from
>> minimal to latest build for all targets and all possible
>> cross-configurations.
>>
>> I hope that we do not "recommend" these versions.
>
2016-09-22 Uros Bizjak
* gcc.dg/ifcvt-1.c: Compile also for 64-bit i?86-*-* target.
* gcc.dg/ifcvt-2.c: Ditto.
* gcc.dg/zero_bits_compound-1.c: Ditto.
* gcc.dg/zero_bits_compound-1.c: Ditto.
* gcc.dg/pr40550.c: Simplify target selectors.
Use dg-additional-options.
*
On Thu, 22 Sep 2016, Moritz Klammler wrote:
> As some of you might already be aware of, I'm currently trying to get a
> new version of the `contrib/download_prerequisites` script approved that
> will verify the checksums of the tarballs it downloads and also provides
> additional options. If it i
This patch broke bootstrap.
In file included from
/nasfarm/edelsohn/src/src/gcc/target-def.h:106:0, from
/nasfarm/edelsohn/src/src/gcc/config/rs6000/rs6000.c:77:./target-hooks-def.h:92:38:
error: 'hook_uint_uintp_false' was not declared in this scope
#define TARGET_ASM_ELF_FLAGS_
On 09/22/16 20:07, Moritz Klammler wrote:
> Martin Sebor writes:
>
>> [...]
>>
>>> In-tree only the versions that download_prerequisite picks are
>>> tested and guaranteed to work.
>>
>> I was made aware today that my recent patch for pr49905 broke
>> bootstrap with MPFR 2.4:
>>
>>https://gcc.
On 22 September 2016 at 15:25, Jonathan Wakely wrote:
> On 22/09/16 12:15 +0100, Jonathan Wakely wrote:
>>
>> On 22/09/16 11:16 +0100, Jonathan Wakely wrote:
>>>
>>> (Somebody should fix PR58938 so exception_ptr is portable).
>>
>>
>> Christophe, would you be able to test this patch?
>>
>> It uses
On 22 September 2016 11:11:42 CEST, Andreas Schwab wrote:
>On Sep 22 2016, Sebastian Huber
>wrote:
>
>> diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
>> index 6d897be..d7db435 100644
>> --- a/libstdc++-v3/acinclude.m4
>> +++ b/libstdc++-v3/acinclude.m4
>> @@ -3490,9 +3490,10
I noticed the loop unroller peels an extra copy of the loop before it enters
the switch block code to round the iteration count to a multiple of the unroll
factor. This peeled copy is only needed for the case where the exit test is at
the beginning of the loop since in that case it inserts the t
Hi Andre,
On 22 September 2016 at 19:04, Andre Vieira (lists)
wrote:
> On 22/09/16 16:28, Richard Earnshaw (lists) wrote:
>> On 22/09/16 16:04, Andre Vieira (lists) wrote:
>>>
>>> I reworked the patch according to the comments above.
>>>
>>> Is this OK?
>>>
>>> gcc/ChangeLog:
>>> 2016-09-22 And
On 21 September 2016 at 22:20, Bernd Edlinger wrote:
> On 09/21/16 21:57, Christophe Lyon wrote:
>> Hi,
>>
>> The new testcase pr77550.C fails on arm:
>> /testsuite/g++.dg/pr77550.C:39:43: error: 'operator new' takes type
>> 'size_t' ('unsigned int') as first parameter [-fpermissive]
>> compiler e
This patch breaks compilation on power:
g++ -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength
Hi!
The discovered 5 unnecessary C++ static locals with ctors prompted me to
look at other cases, which from looking at the optimized or non-optimized
code are just terrible.
We don't need to initialize static vectors with vNULL, because that implies
runtime initialization, static vars are zero in
Hi!
This is something I've been unhappy for a long time with, and finally got to
write something for it.
When some test expects more than one error or warning or message on the same
source line, people have to use absolute line number on the dg-* directives
that is not on the right line, as DejaGN
Hi!
I've noticed lots of vec_safe_length (CONSTRUCTOR_ELTS (...)) uses
in the sources, which IMHO are less readable than the much more often
used CONSTRUCTOR_NELTS (...) macro that does the same thing.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-09-22 Jakub Jelinek
The powerpc target had a movmemsi pattern which supports memcpy() but
did not have anything for memcmp(). This adds support for builtin
expansion of memcmp() into inline code for modest constant lengths.
Performance on power8 is in the range of 3-7x faster than calling
memcmp() for lengths under 40
Hi,
On 22/09/2016 19:04, Andre Vieira (lists) wrote:
diff --git a/gcc/hooks.c b/gcc/hooks.c
index
99ec4014adb6fcbb073bf538dd00fe8695ee6cb2..1e925645c3173f8d97e104b9b2f480fca2ede438
100644
--- a/gcc/hooks.c
+++ b/gcc/hooks.c
@@ -481,3 +481,13 @@ void
hook_void_gcc_optionsp (struct gcc_options
ping?
On Thu, Sep 15, 2016 at 4:09 PM, Roland McGrath wrote:
> This fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77609 (which I've
> just filed).
>
> OK for trunk?
>
> I'm not sure if this kind of fix is appropriate for gcc-6-branch or not,
> but I'd like to backport it there too if it is a
FYI (to help avoid raising duplicate bugs), I opened bug 77695
for the bootstrap failure.
Martin
On 09/22/2016 01:33 PM, Bill Seurer wrote:
This patch breaks compilation on power:
g++ -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowi
On 22 September 2016 at 13:15, Jonathan Wakely wrote:
> On 22/09/16 11:16 +0100, Jonathan Wakely wrote:
>>
>> (Somebody should fix PR58938 so exception_ptr is portable).
>
>
> Christophe, would you be able to test this patch?
>
> It uses a single global mutex for exception_ptr objects, which doesn
On 09/22/16 21:30, Christophe Lyon wrote:
> On 21 September 2016 at 22:20, Bernd Edlinger
> wrote:
>> On 09/21/16 21:57, Christophe Lyon wrote:
>>> Hi,
>>>
>>> The new testcase pr77550.C fails on arm:
>>> /testsuite/g++.dg/pr77550.C:39:43: error: 'operator new' takes type
>>> 'size_t' ('unsigned
This patch to the Go frontend compilers the runtime functions
getcallerpc and getcallersp into calls to __builtin_return_address and
__builtin_frame_address. This is how we currently handle those
functions in the C code, using #define's in runtime.h. This handles
the functions the same way in the
diff --git a/gcc/hooks.c b/gcc/hooks.c
index
99ec4014adb6fcbb073bf538dd00fe8695ee6cb2..1e925645c3173f8d97e104b9b2f480fca2ede438
100644
--- a/gcc/hooks.c
+++ b/gcc/hooks.c
@@ -481,3 +481,13 @@ void
hook_void_gcc_optionsp (struct gcc_options *opts ATTRIBUTE_UNUSED)
{
}
+
+/* Generic hook that
Hi Aaron,
On Thu, Sep 22, 2016 at 03:10:24PM -0500, Aaron Sawdey wrote:
> The powerpc target had a movmemsi pattern which supports memcpy() but
> did not have anything for memcmp(). This adds support for builtin
> expansion of memcmp() into inline code for modest constant lengths.
> Performance on
> From: Richard Biener [rguent...@suse.de]
> Sent: Thursday, September 22, 2016 12:43 AM
> To: Doug Gilmore
> Cc: gcc-patches@gcc.gnu.org; rgue...@gcc.gnu.org
> Subject: RE: [PATCH] Fix PR tree-optimization/77654
>
> On Wed, 21 Sep 2016, Doug Gilmore wrote:
>
> ...
> > Sorry I that missed point.
Hi,
As Richard pointed out in PR77677, TREE_OVERFLOW is not cleared in
IPA-VRP. There are three places in which we set value_range:
1. When value ranges are obtained from SSA_NAME with get_range_info with
wide_int_to_tree. In this case we will not have TREE_OVERFLOW set.
2. When we vrp_meet
There's a bug with ACC DECLARE clauses involving VLA variables that
causes lower_omp_target to thow an ICE on VLA decls. The problem
occurred because those clauses are never gimplified. This patch resolves
that ICE by teaching gimplify_oacc_declare how to gimplify them.
It turns out that gimplify_
As of revision 240383 , i386.c isn't compiling. The errors are:
In file included from ../../gcc_trunk/gcc/target-def.h:106:0,
from ../../gcc_trunk/gcc/config/i386/i386.c:81:
./target-hooks-def.h:92:38: error: ‘hook_uint_uintp_false’ was not declared in
this scope
#def
On 09/21/2016 02:43 PM, Jason Merrill wrote:
On Tue, Sep 20, 2016 at 1:01 PM, Martin Sebor wrote:
On 09/16/2016 12:19 PM, Jason Merrill wrote:
On 09/14/2016 01:03 PM, Martin Sebor wrote:
+ /* Type of the member. */
+ tree fldtype = TREE_CODE (fld) == FIELD_DECL ? TREE_TYPE (fld)
:
On Sep 22, 2016, at 1:05 PM, Jakub Jelinek wrote:
> This is something I've been unhappy for a long time with
:-) Me too.
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok. Thanks.
Hi,
> extern unsigned hook_uint_void_0 (void);
> extern unsigned int hook_uint_mode_0 (machine_mode);
> +extern bool hook_uint_uintp_false (unsigned int, unsigned int *);
I'm seeing the same build issue on ppc64le, and your patch fixes it.
Thanks.
Anton
On 09/22/2016 07:52 AM, Richard Earnshaw (lists) wrote:
On 11/07/16 17:56, Andre Vieira (lists) wrote:
+
diff --git a/gcc/target.def b/gcc/target.def
index
a4df363698ce776b51d11c187baed2069ba88a52..a3d46fa48d919a16699c33b2b78236e62a33e025
100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -43
The fixincl executable uses system function to call applyfix or to
direcly patch a header file, with parameters enclosed in single
quotes. This problem is that MinGW system function just calls cmd.exe,
which doesn't strip quotes from parameters and completely ignores
quotes for embedding spaces in
Prevent paths relative to sysroot directory from being transformed to
Windows form with MSYS prefix.
See: http://www.mingw.org/wiki/Posix_path_conversion
2016-09-23 Tadek Kijkowski
* gcc/Makefile.in: Fix sysroot relative paths for MinGW
Index: gcc/Makefile.in
On Thu, 22 Sep 2016, Jakub Jelinek wrote:
> Hi!
>
> The discovered 5 unnecessary C++ static locals with ctors prompted me to
> look at other cases, which from looking at the optimized or non-optimized
> code are just terrible.
> We don't need to initialize static vectors with vNULL, because that
On Thu, 22 Sep 2016, Jakub Jelinek wrote:
> Hi!
>
> I've noticed lots of vec_safe_length (CONSTRUCTOR_ELTS (...)) uses
> in the sources, which IMHO are less readable than the much more often
> used CONSTRUCTOR_NELTS (...) macro that does the same thing.
>
> Bootstrapped/regtested on x86_64-linux
101 - 156 of 156 matches
Mail list logo
