For hotpatching it might be required to introduce new .text parts
while keep using the existing .data/.bss sections. To make this work
the backend needs to be prevented from using relative addressing
between code and data.
This only works when already building PIC
since the addressing will then be
Hi Sandra,
On 27 June 2017 at 18:05, Sandra Loosemore wrote:
> On 06/27/2017 06:19 AM, Yvan Roux wrote:
>
>> diff --git a/gcc/config/aarch64/aarch64.opt
>> b/gcc/config/aarch64/aarch64.opt
>> index 942a7d5..0fd1bfa 100644
>> --- a/gcc/config/aarch64/aarch64.opt
>> +++ b/gcc/config/aarch64/aarch64
On Tue, Jun 27, 2017 at 6:46 PM, Bin.Cheng wrote:
> On Tue, Jun 27, 2017 at 3:59 PM, Richard Biener
> wrote:
>> On June 27, 2017 4:27:17 PM GMT+02:00, "Bin.Cheng"
>> wrote:
>>>On Tue, Jun 27, 2017 at 1:58 PM, Richard Biener
>>> wrote:
On Fri, Jun 23, 2017 at 12:10 PM, Bin.Cheng
>>>wrote:
On Tue, Jun 27, 2017 at 7:54 PM, Joseph Myers wrote:
> On Tue, 27 Jun 2017, Joseph Myers wrote:
>
>> Current glibc no longer gives the ucontext_t type the tag struct
>> ucontext, to conform with POSIX namespace rules. This requires
>> various linux-unwind.h files in libgcc, that were previously u
On Tue, Jun 27, 2017 at 10:52:47AM -0700, Andrew Pinski wrote:
> On Tue, Jun 27, 2017 at 7:56 AM, Richard Biener
> wrote:
> > On June 27, 2017 4:52:28 PM GMT+02:00, Tamar Christina
> > wrote:
> >>> >> +(for cmp (gt ge lt le)
> >>> >> + outp (convert convert negate negate)
> >>> >> + outn
Hi all,
I've rebased the previous patch to trunk per Andrew's suggestion.
Original patch description/motivation/questions are in
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01869.html
-Y
safe-unwind-2.patch
Description: Binary data
#include
#include
struct _Unwind_Context;
typedef int (*_
This creates a SLP variant for get_initial_def_for_reduction thereby
cleaning up the get_defs interfaces to not pass in reduc_index.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2017-06-28 Richard Biener
* tree-vectorizer.h (vect_get_vec_defs): Rem
On Mon, 26 Jun 2017, Richard Biener wrote:
On Fri, Jun 23, 2017 at 3:12 PM, Marc Glisse wrote:
Hello,
here are a few simple transformations, mostly useful for types with
undefined overflow where we do not have reassoc.
I did not name the testcase reassoc-* to leave that namespace to the real
The manual says that the type of the 2nd argument of pthread_join is void **.
Now gcc.dg/tree-prof/val-profiler-threads-1.c does this:
int retval;
for(t=0;t
* gcc.dg/tree-prof/val-profiler-threads-1.c (main): Fix 2nd argument
passed to pthread_join.
--
Eric BotcazouIndex
All changes require release manager approval.
Thanks,
Richard.
On 06/27/2017 06:38 AM, Jakub Jelinek wrote:
On Tue, Jun 27, 2017 at 06:26:46AM -0400, Aldy Hernandez wrote:
How about this?
@@ -360,6 +363,22 @@ set_range_info (tree name, enum value_range_type
range_type,
}
}
+/* Store range information RANGE_TYPE, MIN, and MAX to tree ssa_name
On Wed, Jun 28, 2017 at 9:37 AM, Jakub Jelinek wrote:
> On Tue, Jun 27, 2017 at 10:52:47AM -0700, Andrew Pinski wrote:
>> On Tue, Jun 27, 2017 at 7:56 AM, Richard Biener
>> wrote:
>> > On June 27, 2017 4:52:28 PM GMT+02:00, Tamar Christina
>> > wrote:
>> >>> >> +(for cmp (gt ge lt le)
>> >>> >>
Hi Joseph,
On 8 June 2017 at 22:28, Joseph Myers wrote:
> genmultilib computes combination_space, a list of all combinations of
> options in MULTILIB_OPTIONS that might have multilibs built for them
> (some of which may end up not having multilibs built for them, and
> some of those may end up be
On Tue, Jun 27, 2017 at 6:40 PM, Jeff Law wrote:
> On 05/12/2017 05:28 AM, Bin Cheng wrote:
>> Hi,
>> This patch computes register pressure information on TREE SSA by a backward
>> live
>> range data flow problem. The major motivation is to estimate register
>> pressure
>> for inner-most loop o
On 28 June 2017 at 10:03, Christophe Lyon wrote:
> Hi Joseph,
>
> On 8 June 2017 at 22:28, Joseph Myers wrote:
>> genmultilib computes combination_space, a list of all combinations of
>> options in MULTILIB_OPTIONS that might have multilibs built for them
>> (some of which may end up not having m
On Jun 28 2017, Christophe Lyon wrote:
> diff --git a/gcc/genmultilib b/gcc/genmultilib
> index 0767e68..e65a0dd 100644
> --- a/gcc/genmultilib
> +++ b/gcc/genmultilib
> @@ -462,7 +462,7 @@ echo "};"
> # Generate a regular expression to validate option combinations.
> options_re=
> for set in
On 25 June 2017 at 23:28, Andrew Pinski wrote:
> On Sun, Jun 25, 2017 at 11:18 AM, Andrew Pinski wrote:
>> On Sun, Jun 25, 2017 at 1:28 AM, Marc Glisse wrote:
>>> +(for cmp (gt ge lt le)
>>> + outp (convert convert negate negate)
>>> + outn (negate negate convert convert)
>>> + /* Transf
On 28 June 2017 at 10:14, Andreas Schwab wrote:
> On Jun 28 2017, Christophe Lyon wrote:
>
>> diff --git a/gcc/genmultilib b/gcc/genmultilib
>> index 0767e68..e65a0dd 100644
>> --- a/gcc/genmultilib
>> +++ b/gcc/genmultilib
>> @@ -462,7 +462,7 @@ echo "};"
>> # Generate a regular expression to v
On Wed, 28 Jun 2017, Martin Sebor wrote:
> > I.e., just having blocks to remove qualifiers of kind X is not sufficient
> > without "remove all qualifiers (possibly except these kinds)" as well. I
> > suppose you could have __remove_quals (const volatile _Atomic, expr) and
> > __remove_quals_excep
On Wed, Jun 28, 2017 at 10:50 AM, Christophe Lyon
wrote:
> On 25 June 2017 at 23:28, Andrew Pinski wrote:
>> On Sun, Jun 25, 2017 at 11:18 AM, Andrew Pinski wrote:
>>> On Sun, Jun 25, 2017 at 1:28 AM, Marc Glisse wrote:
+(for cmp (gt ge lt le)
+ outp (convert convert negate negate
Hi,
This patch picks up a missed-optimization case in loop niter analysis. With
this
patch, niters information for loop as in added test can be analyzed. Bootstrap
and test on x86_64 and AArch64. Is it OK?
Thanks,
bin
2017-06-27 Bin Cheng
PR tree-optimization/81196
* tree-s
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
Hi,
This patch adds missing intrinsics:
- _mm256_permutexvar_epi32
- _mm256_permutex_epi64
- _mm256_permutexvar_epi64
gcc/
* config/i386/avx512vlintrin.h (_mm256_permutexvar_epi64,
_mm256_permutexvar_epi32,
_mm256_permutex_epi64): New intrinsics.
On Tue, Jun 27, 2017 at 4:07 PM, Bin.Cheng wrote:
> On Tue, Jun 27, 2017 at 1:44 PM, Richard Biener
> wrote:
>> On Fri, Jun 23, 2017 at 12:30 PM, Bin.Cheng wrote:
>>> On Tue, Jun 20, 2017 at 10:22 AM, Bin.Cheng wrote:
On Mon, Jun 12, 2017 at 6:03 PM, Bin Cheng wrote:
> Hi,
>>> Rebased
On Wed, Jun 28, 2017 at 10:09 AM, Bin.Cheng wrote:
> On Tue, Jun 27, 2017 at 6:40 PM, Jeff Law wrote:
>> On 05/12/2017 05:28 AM, Bin Cheng wrote:
>>> Hi,
>>> This patch computes register pressure information on TREE SSA by a backward
>>> live
>>> range data flow problem. The major motivation is
On 06/27/2017 05:29 PM, Michael Matz wrote:
> Hi,
>
> On Tue, 27 Jun 2017, Martin Liška wrote:
>
>> Following bug was for me very educative. I learned that we support
>> non-local gotos that can be combined with nested functions. Real fun :)
>> Well, the problem is that both cfun->nonlocal_goto
On 26/06/17 17:01, Thomas Preudhomme wrote:
On 26/06/17 15:16, Christophe Lyon wrote:
You mean the macro is expected not to be defined on ARMv8-A ?
Correct. Most instructions its value represent are not available on ARMv8-A and
for those that are the intrinsics are deprecated.
I've jus
Ping?
Best regards,
Thomas
On 26/06/17 12:32, Thomas Preudhomme wrote:
Hi,
As raised by Christophe Lyon, fpscr.c FAILs because arm_fp_ok and arm_fp
are not defined in GCC 5. This commit changes the test to use the same
recipe as gcc.target/arm/cmp-2.c
ChangeLog entry is as follows:
*** gcc
On Wed, Jun 28, 2017 at 11:58 AM, Richard Biener
wrote:
> On Tue, Jun 27, 2017 at 4:07 PM, Bin.Cheng wrote:
>> On Tue, Jun 27, 2017 at 1:44 PM, Richard Biener
>> wrote:
>>> On Fri, Jun 23, 2017 at 12:30 PM, Bin.Cheng wrote:
On Tue, Jun 20, 2017 at 10:22 AM, Bin.Cheng wrote:
> On Mon,
The following avoids generating TREE_OVERFLOW constants from VRPs
avoidance (sic!) of them when generating MAX - 1 for symbolic 1-bit
ranges with -fwrapv. The issue is that all constant folding is
agnostic of TREE_OVERFLOW_WRAPS but looks at TYPE_UNSIGNED only
and thus negation of signed -1 is ov
On Wed, Jun 28, 2017 at 1:46 PM, Bin.Cheng wrote:
> On Wed, Jun 28, 2017 at 11:58 AM, Richard Biener
> wrote:
>> On Tue, Jun 27, 2017 at 4:07 PM, Bin.Cheng wrote:
>>> On Tue, Jun 27, 2017 at 1:44 PM, Richard Biener
>>> wrote:
On Fri, Jun 23, 2017 at 12:30 PM, Bin.Cheng wrote:
> On Tue
On 06/28/2017 06:52 AM, Jeff Law wrote:
> On 03/15/2017 03:58 AM, Martin Liška wrote:
>> Huh, I forgot to attach the patch.
>>
>> Martin
>>
>> 0001-Introduce-IntegerRange-for-options-PR-driver-79659.patch
>>
>>
>> From bb89456e6cecfa9497cf8e265d2083e762d5bc3e Mon Sep 17 00:00:00 2001
>> From: marxi
On 06/27/2017 05:26 PM, Jan Hubicka wrote:
>> diff --git a/gcc/ipa-visibility.c b/gcc/ipa-visibility.c
>> index d5a3ae56c46..69e6e295d55 100644
>> --- a/gcc/ipa-visibility.c
>> +++ b/gcc/ipa-visibility.c
>> @@ -97,7 +97,8 @@ non_local_p (struct cgraph_node *node, void *data
>> ATTRIBUTE_UNUSED)
>>
From: Franklin “Snaipe” Mathieu
This patch makes the forementioned definitions `contexpr` when
compiling C++11 and above with GNU extensions.
gcc/cp/ChangeLog:
2017-06-27 Franklin “Snaipe” Mathieu
PR c++/66639
* decl.c (cp_make_fname_decl): Make declaration constexpr.
gcc/te
Ramana Radhakrishnan wrote:
>
> I'm about to run home for the day but this came in from
> https://gcc.gnu.org/ml/gcc-patches/2013-09/msg02109.html and James
> said in that email that this was put in to ensure no segfaults on
> cortex-a15 / cortex-a7 tuning.
The code is historical - an older ve
From: "Franklin \"Snaipe\" Mathieu"
This patch makes the forementioned definitions `contexpr` when
compiling C++11 and above with GNU extensions.
gcc/cp/ChangeLog:
2017-06-27 Franklin “Snaipe” Mathieu
PR c++/66639
* decl.c (cp_make_fname_decl): Make declaration constexpr.
gc
From: Snaipe
This patch makes the forementioned definitions `contexpr` when
compiling C++11 and above with GNU extensions.
gcc/cp/ChangeLog:
2017-06-27 Franklin “Snaipe” Mathieu
PR c++/66639
* decl.c (cp_make_fname_decl): Make declaration constexpr.
gcc/testsuite/ChangeLog:
Sorry about that, please ignore.
On Wed, Jun 28, 2017 at 1:52 PM, Franklin Snaipe Mathieu
wrote:
> From: "Franklin \"Snaipe\" Mathieu"
>
> This patch makes the forementioned definitions `contexpr` when
> compiling C++11 and above with GNU extensions.
>
> gcc/cp/ChangeLog:
> 2017-06-27 Franklin
Sorry about that (--dry-run fail), please ignore.
On Wed, Jun 28, 2017 at 1:53 PM, Snaipe wrote:
> From: Snaipe
>
> This patch makes the forementioned definitions `contexpr` when
> compiling C++11 and above with GNU extensions.
>
> gcc/cp/ChangeLog:
> 2017-06-27 Franklin “Snaipe” Mathieu
>
>
Upcoming refactoring likes the cond reduction special IV more in the
epilogue generation code, thus moved there. Some more TLC as well.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2017-06-28 Richard Biener
* tree-vect-loop.c (vectorizable_reducti
On 6/28/17 1:49 PM, Wilco Dijkstra wrote:
Ramana Radhakrishnan wrote:
I'm about to run home for the day but this came in from
https://gcc.gnu.org/ml/gcc-patches/2013-09/msg02109.html and James
said in that email that this was put in to ensure no segfaults on
cortex-a15 / cortex-a7 tuning.
Sorry about the two other failed attempts. I got confused about the
output of send-email and ended up sending two follow-up bogus emails.
This is the right email chain.
On Wed, Jun 28, 2017 at 1:49 PM, Franklin “Snaipe” Mathieu
wrote:
> From: Franklin “Snaipe” Mathieu
>
> This patch makes the f
On Wed, Jun 28, 2017 at 1:29 PM, Richard Biener
wrote:
> On Wed, Jun 28, 2017 at 1:46 PM, Bin.Cheng wrote:
>> On Wed, Jun 28, 2017 at 11:58 AM, Richard Biener
>> wrote:
>>> On Tue, Jun 27, 2017 at 4:07 PM, Bin.Cheng wrote:
On Tue, Jun 27, 2017 at 1:44 PM, Richard Biener
wrote:
>
Hi.
Following patch makes non-LTO and LTO mode to behave same.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
The test-case works on x86_64-linux-gnu.
Ready to be installed?
Martin
gcc/testsuite/ChangeLog:
2017-06-28 Martin Liska
PR target/71991
*
PING^2
On 06/20/2017 02:15 PM, Martin Liška wrote:
> PING^1
>
> On 06/13/2017 10:09 AM, Martin Liška wrote:
>> Hi.
>>
>> For a function that does not handle an expection (and calls
>> BUILT_IN_UNWIND_RESUME),
>> we need to emit call to BUILT_IN_ASAN_HANDLE_NO_RETURN. That will clean up
>> stack
PING^1
On 06/20/2017 03:06 PM, Martin Liška wrote:
> On 06/20/2017 11:32 AM, Jakub Jelinek wrote:
>> On Tue, Jun 20, 2017 at 11:23:36AM +0200, Martin Liška wrote:
Then something needs to be done for debugging too. If it is without VTA,
then probably just having DECL_VALUE_EXPR is good e
On Wed, Jun 28, 2017 at 01:49:26PM +0100, Wilco Dijkstra wrote:
> Ramana Radhakrishnan wrote:
> >
> > I'm about to run home for the day but this came in from
> > https://gcc.gnu.org/ml/gcc-patches/2013-09/msg02109.html and James
> > said in that email that this was put in to ensure no segfaults
Richard Biener writes:
> On Mon, Jun 26, 2017 at 1:50 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Mon, Jun 26, 2017 at 1:14 PM, Richard Sandiford
>>> wrote:
I don't think the problem is the lack of a cap. In the test case we
see that:
1. B is known at co
dr_analyze_innermost had a "struct loop *nest" parameter that acted
like a boolean. This was added in r179161, with the idea that a
null nest selected BB-level analysis rather than loop analysis.
The handling seemed strange though. If the DR was part of a loop,
we still tried to express the base
This patch records the base alignment in data_reference, to avoid the
second-guessing that was previously done in vect_compute_data_ref_alignment.
It also makes vect_analyze_data_refs use dr_analyze_innermost, instead
of having an almost-copy of the same code.
I'd originally tried to do the second
We know that if a vectorised loop is reached, all statements in that
loop execute at least once, so it should be safe to pool the alignment
information for all the statements we're vectorising. The only catch is
that DR_REFs for masked loads and stores only occur if the mask value is
nonzero. For
On Wed, Jun 28, 2017 at 2:36 PM, Richard Sandiford
wrote:
> Index: gcc/tree-data-ref.c
> ===
> --- gcc/tree-data-ref.c 2017-06-28 14:33:41.294720044 +0100
> +++ gcc/tree-data-ref.c 2017-06-28 14:35:30.475155670 +0100
> @@ -749,15 +749
Ping #3
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00096.html
On 02.06.2017 09:53, Georg-Johann Lay wrote:
> Hi,
>
> this small addition improves costs of PARALLELs in
> rtlanal.c:seq_cost(). Up to now, these costs are
> assumed to be 1 which gives gross inexact costs for,
> e.g. divmod whi
"Bin.Cheng" writes:
> On Wed, Jun 28, 2017 at 2:36 PM, Richard Sandiford
> wrote:
>> Index: gcc/tree-data-ref.c
>> ===
>> --- gcc/tree-data-ref.c 2017-06-28 14:33:41.294720044 +0100
>> +++ gcc/tree-data-ref.c 2017-06-28 14:35:30.4751
> - /* If callee has no option attributes, then it is ok to inline. */
> - if (!callee_tree)
> + /* If callee has no option attributes (or default),
> + then it is ok to inline. */
> + if (!callee_tree || callee_tree == target_option_default_node)
I am not sure this actually makes sense,
I have bootstrapped and tested this patch on
powerpc64le-unkonwn-linux-gnu with no regressions. Is this ok for
backporting to gcc 6?
On 03/22/2017 10:17 PM, Segher Boessenkool wrote:
> On Wed, Mar 22, 2017 at 05:55:53PM -0600, Kelvin Nilsen wrote:
>>> Or it could do -mpower9-dform-scalar but d
> ideally you'd use a wide-int here and defer the tree allocation to the result
Did that in the attached version.
> So I guess we never run into the outer_op == minus case as the above is
> clearly wrong for that?
Right, damn, not only was the treatment for this missing but it was
bogus in the o
On 06/28/2017 04:24 PM, Jan Hubicka wrote:
>> - /* If callee has no option attributes, then it is ok to inline. */
>> - if (!callee_tree)
>> + /* If callee has no option attributes (or default),
>> + then it is ok to inline. */
>> + if (!callee_tree || callee_tree == target_option_default
On 06/14/2017 06:40 PM, Joseph Myers wrote:
> On Wed, 14 Jun 2017, Richard Biener wrote:
>
are you sure this is needed? This seems to be solely arguments to
attributes.
>>>
>>> It's need for cases like:
>>> __intN_t (8, __QI__);
>>
>> But __QI__ is not processed in lookup_attribute, is
On 06/14/2017 07:24 PM, Jason Merrill wrote:
> On Tue, Jun 13, 2017 at 8:32 AM, Martin Liška wrote:
>> (canonize_attr_name): New function.
>
> I think this should be "canonicalize"; "canonize" means something else.
>
> Jason
>
Yes, I hope it's a cosmetic problem. In general, do you wel
On 20/06/17 13:44, Christophe Lyon wrote:
The results with a more recent trunk (r249356)) are here:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/249356-consistent_neon_check.patch/report-build-info.html
They are slightly different, but still tedious to check ;-)
On 6/27/17 6:53 PM, Michael Meissner wrote:
> This adds a target supports option in dejagnu so that future tests can use
> this
> to determine whether or not to test target_clones.
I like the idea, but some comments...
> + #ifdef __MACH__
> + asm volatile ("xxlor vs0,
Hi Thomas,
On 28/06/17 15:49, Thomas Preudhomme wrote:
On 20/06/17 13:44, Christophe Lyon wrote:
The results with a more recent trunk (r249356)) are here:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/249356-consistent_neon_check.patch/report-build-info.html
Th
On 28/06/17 15:59, Kyrill Tkachov wrote:
Hi Thomas,
On 28/06/17 15:49, Thomas Preudhomme wrote:
On 20/06/17 13:44, Christophe Lyon wrote:
The results with a more recent trunk (r249356)) are here:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/249356-consistent
ACLE explicitly states that when targetting the common subset of
ARMv7-A, ARMv7-R and ARMv7-M, the __ARM_ARCH_PROFILE macro should not be
set. We currently set it to 'M' which is clearly erroneous.
The logic for creating this is very convoluted and also somewhat
fragile, so I've taken the opportu
Ping?
*** gcc/ChangeLog ***
2017-06-13 Thomas Preud'homme
* config/arm/arm.c (arm_option_override): Forbid ARMv8-M Security
Extensions with more than 16 double VFP registers.
(cmse_nonsecure_entry_clear_before_return): Remove second entry of
to_clear_mask and
> On 06/28/2017 04:24 PM, Jan Hubicka wrote:
> >> - /* If callee has no option attributes, then it is ok to inline. */
> >> - if (!callee_tree)
> >> + /* If callee has no option attributes (or default),
> >> + then it is ok to inline. */
> >> + if (!callee_tree || callee_tree == target_op
I don't know if that wouldn't be overkill. Qualifiers on rvalues are
meaningless in C and that's why my __typeof_noqual strips them all.
We'd then need even e.g. __remove_restrict, not sure if there's need for
these. Maybe it is.
Unless __typeof__ (p) q = p; declares a restrict-qualified q whe
GCC Maintainers:
The following patch adds support for the vec_signed, vec_signede,
vec_signedo and vec_signed2 builtins. The patch has been tested on
powerpc64le-unknown-linux-gnu (Power 8 LE) and
powerpc64-unknown-linux-gnu(Power 8 BE).
Is the fix OK for gcc mainline?
Car
Is the attached refinement of this patch previously applied to mainline
ok for backport to gcc 6? I have bootstrapped and tested without
regressions on powerpc64le-unknown-linux-gnu.
This patch differs from the original mainline patch in the following
regards:
1. Certain commentary changes are
On 06/28/2017 03:19 AM, Joseph Myers wrote:
On Wed, 28 Jun 2017, Martin Sebor wrote:
I.e., just having blocks to remove qualifiers of kind X is not sufficient
without "remove all qualifiers (possibly except these kinds)" as well. I
suppose you could have __remove_quals (const volatile _Atomic,
On 06/28/2017 03:33 AM, Matthias Klose wrote:
> 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
On 20/06/17 16:01, Thomas Preudhomme wrote:
> Hi,
>
> Function cmse_nonsecure_entry_clear_before_return has code to deal with
> high VFP register (D16-D31) while ARMv8-M Baseline and Mainline both do
> not support more than 16 double VFP registers (D0-D15). This makes this
> security-sensitive cod
On Wed, Jun 28, 2017 at 3:04 PM, Richard Sandiford
wrote:
> "Bin.Cheng" writes:
>> On Wed, Jun 28, 2017 at 2:36 PM, Richard Sandiford
>> wrote:
>>> Index: gcc/tree-data-ref.c
>>> ===
>>> --- gcc/tree-data-ref.c 2017-06-28 14:33:41.2
On Wed, 28 Jun 2017, Martin Liška wrote:
> On 06/14/2017 07:24 PM, Jason Merrill wrote:
> > On Tue, Jun 13, 2017 at 8:32 AM, Martin Liška wrote:
> >> (canonize_attr_name): New function.
> >
> > I think this should be "canonicalize"; "canonize" means something else.
> >
> > Jason
> >
>
On Wed, 28 Jun 2017, Martin Sebor wrote:
> > that defines "remove qualifiers except"
> > operations for every combination of qualifiers in that version of the
> > compiler (because "remove qualifiers except _Atomic" and "remove
> > qualifiers except address spaces" cannot be composed into "remove
"Bin.Cheng" writes:
> On Wed, Jun 28, 2017 at 3:04 PM, Richard Sandiford
> wrote:
>> "Bin.Cheng" writes:
>>> On Wed, Jun 28, 2017 at 2:36 PM, Richard Sandiford
>>> wrote:
Index: gcc/tree-data-ref.c
===
--- gcc/tree-d
On 06/28/2017 10:09 AM, Joseph Myers wrote:
On Wed, 28 Jun 2017, Martin Sebor wrote:
that defines "remove qualifiers except"
operations for every combination of qualifiers in that version of the
compiler (because "remove qualifiers except _Atomic" and "remove
qualifiers except address spaces" c
On Wed, Jun 28, 2017 at 5:56 PM, Richard Sandiford
wrote:
> "Bin.Cheng" writes:
>> On Wed, Jun 28, 2017 at 3:04 PM, Richard Sandiford
>> wrote:
>>> "Bin.Cheng" writes:
On Wed, Jun 28, 2017 at 2:36 PM, Richard Sandiford
wrote:
> Index: gcc/tree-data-ref.c
> ===
On 05/24/2017 08:27 AM, Richard Sandiford wrote:
> Jeff Law writes:
>> On 12/09/2016 05:48 AM, Richard Sandiford wrote:
>>> This series includes most of the changes in group C from:
>>>
>>> https://gcc.gnu.org/ml/gcc/2016-11/msg00033.html
>>>
>>> The idea is to add wrapper classes around mach
On 06/09/2017 07:57 AM, Simon Wright wrote:
> 2017-06-09 Simon Wright
>
> PR target/80556
> * configure.ac (stage1_ldflags): For Darwin, include -lSystem.
> (poststage1_ldflags): likewise.
> * configure: regenerated.
I'm a bit confused here. Isn't -lSyst
On Wed, 28 Jun 2017, Martin Sebor wrote:
> I don't think there is an equivalent, dedicated trait in C++ to
> do that either. One would have to be composed of the lower-level
> ones. There also is no trait that would remove all type qualifiers
> (including extensions), or even traits for querying
GCC Maintainers:
The vec_reve builtin test builtins-3-vec_reve-runnable did not have a
minimum Power processor specified. The thought was the instructions for
the builtin were available on all the older processors. Unfortunately,
it turns out the builtin does require vsx hardware (-mvsx option).
Some minor changes to the PowerPC target_clones support:
1) I added a warning if target_clones was used and the compiler whas configured
with an older glibc where __builtin_cpu_supports always returns 0;
2) I reworked how the ifunc resolver function is generated, and always made it
a static funct
On Wed, Jun 28, 2017 at 09:58:40AM -0500, Peter Bergner wrote:
> On 6/27/17 6:53 PM, Michael Meissner wrote:
> > This adds a target supports option in dejagnu so that future tests can use
> > this
> > to determine whether or not to test target_clones.
>
> I like the idea, but some comments...
>
On Wed, Jun 28, 2017 at 12:05 PM, Joseph Myers wrote:
> On Wed, 28 Jun 2017, Martin Liška wrote:
>
>> On 06/14/2017 07:24 PM, Jason Merrill wrote:
>> > On Tue, Jun 13, 2017 at 8:32 AM, Martin Liška wrote:
>> >> (canonize_attr_name): New function.
>> >
>> > I think this should be "canonica
"Bin.Cheng" writes:
> On Wed, Jun 28, 2017 at 5:56 PM, Richard Sandiford
> wrote:
>> "Bin.Cheng" writes:
>>> Question is what would happen if simple_iv succeeds with non-ZERO step
>>> when called with nest==NULL? The patch skips simple_iv and forces
>>> ZERO step?
>>
>> Yeah, I mentioned that i
81204 is a regression whereby previously we would accidentally get the
parsing of res.template set right because when we did the lookup in
the surrounding context, we found the function template and then
ignored it. This patch partially reverts the handling of .template to
how it was in GCC 6.
Bu
In 61022, we were stripping the pack expansion from a template
argument for considering what kind of argument it is, and then
forgetting to put it back in the case of an unbound class template.
In 72801, we were doing unification wrong when trying to find partial
specialization bindings because we
In the testcase we SEGV due to infinite recursion because the
noexcept-specifier of f depends on itself. Fixed by keeping track of
which functions we're currently trying to instantiate noexcept for.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 7a938fed4c07c7e28008b56e6bac05376b1f99fa
Aut
Hi Martin,
> On 06/28/2017 06:52 AM, Jeff Law wrote:
>> On 03/15/2017 03:58 AM, Martin Liška wrote:
>>> Huh, I forgot to attach the patch.
>>>
>>> Martin
>>>
>>> 0001-Introduce-IntegerRange-for-options-PR-driver-79659.patch
>>>
>>>
>>> From bb89456e6cecfa9497cf8e265d2083e762d5bc3e Mon Sep 17 00:00
Georg-Johann Lay wrote:
@@ -5300,6 +5300,9 @@ seq_cost (const rtx_insn *seq, bool spee
set = single_set (seq);
if (set)
cost += set_rtx_cost (set, speed);
+ else if (INSN_P (seq)
+ && PARALLEL == GET_CODE (PATTERN (seq)))
+ cost += insn_rtx_cost (PATT
Hi Segher,
On Tue, 2017-06-27 at 18:35 -0500, Segher Boessenkool wrote:
> Hi Aaron,
>
> On Tue, Jun 27, 2017 at 11:43:57AM -0500, Aaron Sawdey wrote:
> > The function toc_relative_expr_p implicitly sets two static vars
> > (tocrel_base and tocrel_offset) that are declared in rs6000.c. The
> > rea
Hi!
On Tue, Jun 27, 2017 at 07:53:21PM -0400, Michael Meissner wrote:
> --- gcc/testsuite/lib/target-supports.exp (revision 249606)
> +++ gcc/testsuite/lib/target-supports.exp (working copy)
> @@ -1930,6 +1930,37 @@ proc check_effective_target_powerpc64_no
> } {-O2}]
> }
>
> +# Re
On Wed, Jun 28, 2017 at 12:01 PM, Peryt, Sebastian
wrote:
> Hi,
>
> This patch adds missing intrinsics:
> - _mm256_permutexvar_epi32
> - _mm256_permutex_epi64
> - _mm256_permutexvar_epi64
>
> gcc/
> * config/i386/avx512vlintrin.h (_mm256_permutexvar_epi64,
> _mm256
On Wed, Jun 28, 2017 at 08:30:21AM -0600, Kelvin Nilsen wrote:
> I have bootstrapped and tested this patch on
> powerpc64le-unkonwn-linux-gnu with no regressions. Is this ok for
> backporting to gcc 6?
Please wait until after 6.4.
Thanks,
Segher
On Wed, Jun 28, 2017 at 03:48:50PM -0500, Segher Boessenkool wrote:
> As Peter said, I'd rather test for "ppc32", so this works anywhere.
Fair enough.
> That would give
>
> proc check_cpu_supports_available { } {
> if { [istarget powerpc*-*-*] } {
> return [check_runtime cpu_supports
On Wed, Jun 28, 2017 at 8:06 PM, Richard Sandiford
wrote:
> "Bin.Cheng" writes:
>> On Wed, Jun 28, 2017 at 5:56 PM, Richard Sandiford
>> wrote:
>>> "Bin.Cheng" writes:
Question is what would happen if simple_iv succeeds with non-ZERO step
when called with nest==NULL? The patch skips
The problem in this testcase is that when we first parse C we look
up the canonical instantiation of C which doesn't see inside A
because it happens at global scope, but then in strip_typedefs we are
in the context of A, so the call to make_typename_type in
strip_typedefs was finding the error and
On Wed, 28 Jun 2017, Jason Merrill wrote:
In the testcase we SEGV due to infinite recursion because the
noexcept-specifier of f depends on itself. Fixed by keeping track of
which functions we're currently trying to instantiate noexcept for.
Hello,
in the testcase, it makes sense that this is
1 - 100 of 113 matches
Mail list logo
