On Fri, 3 Feb 2017, Gerald Pfeifer wrote:
> Of course, an innocent grep after providing this input in a review
> of a patch by David revealed that we have a number more cases where
> we used "test suite" instead of "testsuite".
And now a recursive grep.
Applied.
Gerald
Index: bugs/minimize.html
On 02/02/2017 10:10 PM, Martin Sebor wrote:
Bug 79352 points out that the gimple-ssa-printf pass doesn't allow
for an array at the end of a struct to be treated as a poor man's
flexible array member and hold a string that's longer than the upper
bound of the array. Rather, the pass assumes that
On Fri, 14 Oct 2016, David Malcolm wrote:
> On Fri, 2016-10-14 at 16:27 +0100, Pedro Alves wrote:
>> FYI, I pushed these in now. I also bootstrapped with the
>> jit included in the selected languages, and hacked the
>> jit code a bit to trigger the problems OVERRIDE intends to
>> catch, just to ma
On Fri, 7 Oct 2016, Georg-Johann Lay wrote:
Mentioning some AVR target specific improvements.
Below some small editorial changes that I just applied on top
of this.
Gerald
Index: gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/
On 02/02/2017 02:31 AM, Alan Modra wrote:
Revised patch that cures the lra related -m32 -Os regression too.
The code that I'm patching here is changing a REG_EQUAL note to
REG_EQUIV, ie. asserting that the value of the reg is always the value
set by the current instruction. Which is not always
Hi!
As mentioned in the PR, for the following testcase we emit a power9
instruction even with -mcpu=power8. Similar movsf_hardfloat instruction
uses wb constraint for the stxssp insn source rather than wu, which it
only uses for stxsspx (power7?).
Bootstrapped/regtested on powerpc64{,le}-linux,
Hello.
Installed as obvious as r245147.
Martin
>From 705314a0d896e5434dcb30b6e5790fc5dab132b4 Mon Sep 17 00:00:00 2001
From: marxin
Date: Fri, 3 Feb 2017 10:07:05 +0100
Subject: [PATCH] Document default value for
use-after-scope-direct-emission-threshold
gcc/ChangeLog:
2017-02-03 Martin Lisk
> On 2 Feb 2017, at 08:08, Richard Biener wrote:
>
> On Wed, 1 Feb 2017, Segher Boessenkool wrote:
>
>> On Wed, Feb 01, 2017 at 03:53:09PM -0600, Segher Boessenkool wrote:
>>> On Wed, Feb 01, 2017 at 11:59:10AM +0100, Richard Biener wrote:
Wasn't successful in making a cross to ppc64-linux
On 3 February 2017 at 07:56, Gerald Pfeifer wrote:
> On Mon, 30 Jan 2017, Jonathan Wakely wrote:
>>
>> This adds the porting to guide for GCC 7. So far it only has details
>> of C++ changes, mostly in the std::lib.
>
>
> Thanks for doing that, Jonathan!
>
> One minor observation: This has reference
Hi!
Some formatting nits:
On Thu, Feb 02, 2017 at 10:10:32PM -0700, Martin Sebor wrote:
> else if (gimple_assign_rhs_code (def_stmt) == COND_EXPR)
> {
> tree op2 = gimple_assign_rhs2 (def_stmt);
> tree op3 = gimple_assign_rhs3 (def_stmt);
> - return get_r
On Fri, 3 Feb 2017, Martin Liška wrote:
> Installed as obvious as r245147.
Yes, but...
I think you wanted to say "is 256", not "in 256" and make this a
full sentence? Looking at the entire entry I noticed a few other
issues ("smaller of equal" instead of "smaller or equal", missing
articles, pas
On 03/02/17 06:57, Hurugalawadi, Naveen wrote:
Hi Andrew,
Thanks for clearing the confusion.
I don't understand this comment and how it relates to your updated patch
foo, foo1 and foo2 generates calls to "popcountdi2" which should have
been "popcountsi2" for foo1. When Kyrill commented on us
On Dez 16 2016, Kelvin Nilsen wrote:
> Index: gcc/testsuite/gcc.target/powerpc/pr78056-8.c
> ===
> --- gcc/testsuite/gcc.target/powerpc/pr78056-8.c (revision 0)
> +++ gcc/testsuite/gcc.target/powerpc/pr78056-8.c (working co
On 02/03/2017 10:45 AM, Gerald Pfeifer wrote:
> On Fri, 3 Feb 2017, Martin Liška wrote:
>> Installed as obvious as r245147.
>
> Yes, but...
Hi.
Thanks for that, stupid typos.
>
> I think you wanted to say "is 256", not "in 256" and make this a
> full sentence? Looking at the entire entry I no
Hi,
this patch fixes 'dyld: Symbol not found: _memmem' linkage error on
Darwin 10.6.
Just cherry-pick r293992 from upstream, OK to apply?
-Maxim
libsanitizer/ChangeLog:
2017-02-03 Maxim Ostapenko
PR sanitizer/78663
* sanitizer_common/sanitizer_mac.cc: Cherry-pick upstream r293992.
* s
On Fri, Feb 03, 2017 at 02:46:39PM +0300, Maxim Ostapenko wrote:
> Hi,
>
> this patch fixes 'dyld: Symbol not found: _memmem' linkage error on Darwin
> 10.6.
> Just cherry-pick r293992 from upstream, OK to apply?
>
> -Maxim
> libsanitizer/ChangeLog:
>
> 2017-02-03 Maxim Ostapenko
>
>
> On Jan 30, 2017, at 7:35 PM, Andrew Pinski wrote:
>
> On Mon, Jan 30, 2017 at 3:48 AM, Maxim Kuvyrkov
> wrote:
>> This patch port prefetch configuration from aarch32 backend to aarch64.
>> There is no code-generation change from this patch.
>>
>> This patch also happens to address Kyrill's
> On Jan 30, 2017, at 5:50 PM, Maxim Kuvyrkov wrote:
>
>> On Jan 30, 2017, at 3:23 PM, Kyrill Tkachov
>> wrote:
>>
>> Hi Maxim,
>>
>> On 30/01/17 12:06, Maxim Kuvyrkov wrote:
>>> This patch enables prefetching at -O3 for aarch64 cores that set
>>> "simultaneous prefetches" parameter above 0.
Hi Andrew,
I took the liberty of rebasing your patch on top of my patchset. Does it look
correct?
I think I addressed all the comments you had about my review and posted updated
patches.
--
Maxim Kuvyrkov
www.linaro.org
> On Jan 30, 2017, at 7:25 PM, Andrew Pinski wrote:
>
> On Mon, Jan
On 02/02/2017 03:54 PM, Jan Hubicka wrote:
>> 2017-01-24 Martin Liska
>>
>> * cgraph.c (cgraph_node::dump): Dump function version info.
>> * symtab.c (symtab_node::dump_base): Add missing new line.
>> ---
>> gcc/cgraph.c | 10 ++
>> gcc/symtab.c | 1 +
>> 2 files changed, 11
On 02/02/2017 02:18 PM, Martin Liška wrote:
> Ok, I spent more time with understanding how that pass works and I believe it
> can be
> significantly simplified. I guess target_clones are very close to 'target'
> attribute
> that is handled by C++ FE. It creates cgraph_function_version_info and
>
On 02/02/2017 02:18 PM, Martin Liška wrote:
> Ok, I spent more time with understanding how that pass works and I believe it
> can be
> significantly simplified. I guess target_clones are very close to 'target'
> attribute
> that is handled by C++ FE. It creates cgraph_function_version_info and
>
On 02/02/17 15:21, Torvald Riegel wrote:
On Thu, 2017-02-02 at 14:48 +, Ramana Radhakrishnan wrote:
On 30/01/17 18:54, Torvald Riegel wrote:
This patch fixes the __atomic builtins to not implement supposedly
lock-free atomic loads based on just a compare-and-swap operation.
If there is no
On Fri, 2017-02-03 at 08:09 +0100, Gerald Pfeifer wrote:
> On Thu, 2 Feb 2017, David Malcolm wrote:
> > This patch to the website moves the section about the selftest
> > suite to
> > the bottom of "Other significant improvements" section, and
> > rewrites it
> > to also cover the GIMPLE and RTL "f
On Thu, Feb 02, 2017 at 10:24:34PM +0100, Gerald Pfeifer wrote:
> Hi Marek,
>
> a couple of comments (and minor changes) below. Once you have made
> those, this is okay to commit. Quite some stuff going into GCC 7!
>
> On Fri, 27 Jan 2017, Marek Polacek wrote:
> > Index: changes.html
> > ===
We now have a porting_to.html for gcc 7, so this patch uncomments the
link to it on gcc 7's changes page.
Validates.
I took the liberty of committing this, under the "obvious" rule.
Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs
On Fri, 2017-02-03 at 13:44 +, Ramana Radhakrishnan wrote:
> __atomic_load on ARM appears to be ok as well
>
> except for
>
> __atomic_load_di which should really be the ldrexd / strexd loop but we
> could ameliorate that similar to your option 3b.
This uses just ldrexd now, and thus is not
On Fri, Feb 03, 2017 at 04:07:22PM +0100, Torvald Riegel wrote:
> On Fri, 2017-02-03 at 13:44 +, Ramana Radhakrishnan wrote:
> > __atomic_load on ARM appears to be ok as well
> >
> > except for
> >
> > __atomic_load_di which should really be the ldrexd / strexd loop but we
> > could ameliora
Hi Jakub,
On Fri, Feb 03, 2017 at 10:10:47AM +0100, Jakub Jelinek wrote:
> As mentioned in the PR, for the following testcase we emit a power9
> instruction even with -mcpu=power8. Similar movsf_hardfloat instruction
> uses wb constraint for the stxssp insn source rather than wu, which it
> only
On 02/03/2017 12:35 AM, Jeff Law wrote:
On 02/02/2017 09:58 AM, Martin Sebor wrote:
Otherwise all the tests succeeded, though looking e.g. at the diff
between builtin-sprintf-warn-1.c diagnostics with your patch and with
the patch below instead, there are also differences like:
-builtin-sprintf
On 03/02/17 15:13, Jakub Jelinek wrote:
On Fri, Feb 03, 2017 at 04:07:22PM +0100, Torvald Riegel wrote:
On Fri, 2017-02-03 at 13:44 +, Ramana Radhakrishnan wrote:
__atomic_load on ARM appears to be ok as well
except for
__atomic_load_di which should really be the ldrexd / strexd loop but
On Fri, Feb 03, 2017 at 04:19:58PM +, Ramana Radhakrishnan wrote:
> > > Would it be acceptable for those users to have loads that perform like
> > > CAS loops, especially under contention? Or are these users more
> > > concerned about aarch64 not offering a true atomic 16-byte load?
> >
> > C
On Fri, 2017-02-03 at 17:21 +0100, Jakub Jelinek wrote:
> On Fri, Feb 03, 2017 at 04:19:58PM +, Ramana Radhakrishnan wrote:
> > > > Would it be acceptable for those users to have loads that perform like
> > > > CAS loops, especially under contention? Or are these users more
> > > > concerned a
On Fri, Feb 03, 2017 at 09:13:23AM -0700, Martin Sebor wrote:
> I'm not opposed to the changes, certainly not to cleaning things up,
> but I don't think now is the time to be making these tweaks. Jakub's
> patch is fine with me without those tweaks, and with the correction
What do you mean by my
On 02/03/2017 09:39 AM, Jakub Jelinek wrote:
On Fri, Feb 03, 2017 at 09:13:23AM -0700, Martin Sebor wrote:
I'm not opposed to the changes, certainly not to cleaning things up,
but I don't think now is the time to be making these tweaks. Jakub's
patch is fine with me without those tweaks, and wi
Hi all,
While evaluating Maxim's SW prefetch patches [1] I noticed that the aarch64
prefetch pattern is
overly restrictive in its address operand. It only accepts simple register
addressing modes.
In fact, the PRFM instruction accepts almost all modes that a normal 64-bit LDR
supports.
The res
On Fri, Feb 03, 2017 at 10:02:48AM -0700, Martin Sebor wrote:
> On 02/03/2017 09:39 AM, Jakub Jelinek wrote:
> > On Fri, Feb 03, 2017 at 09:13:23AM -0700, Martin Sebor wrote:
> > > I'm not opposed to the changes, certainly not to cleaning things up,
> > > but I don't think now is the time to be mak
On Fri, Feb 03, 2017 at 09:59:45AM -0600, Segher Boessenkool wrote:
> Hi Jakub,
>
> On Fri, Feb 03, 2017 at 10:10:47AM +0100, Jakub Jelinek wrote:
> > As mentioned in the PR, for the following testcase we emit a power9
> > instruction even with -mcpu=power8. Similar movsf_hardfloat instruction
>
On 02/03/2017 09:39 AM, Jakub Jelinek wrote:
On Fri, Feb 03, 2017 at 09:13:23AM -0700, Martin Sebor wrote:
I'm not opposed to the changes, certainly not to cleaning things up,
but I don't think now is the time to be making these tweaks. Jakub's
patch is fine with me without those tweaks, and wi
GCC Maintainers:
I have squashed the following two patches from mainline
commit r244943 Remove bogus entries for the P8V_BUILTIN_VEC_VGBBD
built-ins
commit r244904 Fix order of entries for ALTIVEC_BUILTIN_VEC_PACKS
and P8V_BUILTIN_VEC_VGBBD.
and back ported
On Fri, Feb 03, 2017 at 09:57:31AM -0800, Carl E. Love wrote:
> I have squashed the following two patches from mainline
>
> commit r244943 Remove bogus entries for the P8V_BUILTIN_VEC_VGBBD
> built-ins
> commit r244904 Fix order of entries for ALTIVEC_BUILTIN_VEC_PACKS
>
On 02/02/2017 07:12 AM, Jakub Jelinek wrote:
On Thu, Feb 02, 2017 at 10:52:18AM +0100, Jakub Jelinek wrote:
That said, as I've said in the PR and earlier in December on gcc-patches,
the way format_integer is structured is not really maintainable, has
very different code paths for arguments with
On 02/02/2017 03:15 PM, Jakub Jelinek wrote:
Plus there are certain notes removed:
-builtin-sprintf-warn-1.c:1311:3: note: using the range [1, -2147483648] for
directive argument
T (0, "%d", a); /* { dg-warning "into a region" } */
without replacement, here a has [-2147483648,
Hello!
This patch fixes asymmetry for TARGET_SSE4_1, where pinsr was used to
create vector copy, but not pextr when creating scalar copy with
-mstv.
2017-02-03 Uros Bizjak
* config/i386/i386.c (dimode_scalar_chain::convert_reg):
Use pextrd for TARGET_SSE4_1 when creating scalar copy.
On Fri, Feb 03, 2017 at 11:43:53AM -0700, Jeff Law wrote:
> > + if (TREE_CODE (argtype) == POINTER_TYPE)
> > {
> > - if (POINTER_TYPE_P (argtype))
> > - argmax = build_all_ones_cst (argtype);
> > - else if (TYPE_UNSIGNED (argtype))
> > - argmax = TYPE_MAX_VALUE (argtype
Move explicit instantiation definitions for string I/O functions into
their own files so that iostream and locale definitions are not needed
for uses of strings without I/O. Move functions for throwing C++11
exceptions into the individual files defining the exception types, so
that using any of th
On 02/02/2017 05:31 PM, Martin Sebor wrote:
- T (2, "%#hho",a); /* { dg-warning "nul past the end"
} */
- T (2, "%#hhx",a); /* { dg-warning ".%#hhx. directive
writing between 3 and . bytes into a region of size 2" } */
+ T (2, "%#hho",a);
+ T (2, "%#hhx",
On 02/02/2017 05:49 PM, Martin Sebor wrote:
That is unrelated to the patch, both in the current trunk, with your
patch as well as with my patch there is just
res.range.likely = res.knownrange ? res.range.max : res.range.min;
res.range.unlikely = res.range.max;
for these cases.
Do you want l
On 02/03/2017 12:02 PM, Jeff Law wrote:
On 02/02/2017 05:31 PM, Martin Sebor wrote:
- T (2, "%#hho",a); /* { dg-warning "nul past the end"
} */
- T (2, "%#hhx",a); /* { dg-warning ".%#hhx. directive
writing between 3 and . bytes into a region of size 2" } */
+ T (2, "%
This patch fixes PR target/78862. Add blockage to prevent the
scheduler from reordering a LR save with a subsequent instruction that
changes the CFA register. This trips up the dwarf generating logic.
Bootstrapped and tested on TILEPro/TILE-Gx hardware, also backported
to GCC 6.
* config/tileg
On 16/01/17 15:57 +, Jonathan Wakely wrote:
This changes the version of std::ios_base::failure thrown by
libstdc++.so to be the new __cxx11 ABI one, matching the default for
headers that are trying to catch the exception.
There's no simple way to do this as an easy transition, but hopefully
On Thu, Feb 2, 2017 at 4:21 AM, Richard Biener wrote:
> On Wed, 1 Feb 2017, Richard Biener wrote:
>
>> On Wed, 1 Feb 2017, Jakub Jelinek wrote:
>>
>> > On Wed, Feb 01, 2017 at 02:14:20PM +0100, Richard Biener wrote:
>> > >
>> > > Looks like we cache the answer to maybe_constant_value (INTEGER_CST)
In this testcase, if we saw a value-dependent expression we were
leaving its type unchanged, leading to an abort at the end of the
function. Instead, we should complain about an argument with the
wrong type.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 336288e5f6a35f54003b4d16e840cc2fd34
Hi,
In looking at PR 79365 I found that the problem is actually in the
combiner. The combiner sometimes applies scalar optimizations to
vector context where they are invalid. i.e. (a > b) >> 1 can optimize
to 0 if ">" is a scalar op but not if it is a vector op. The reason
this shows up on til
On Fri, Feb 03, 2017 at 09:59:45AM -0600, Segher Boessenkool wrote:
> Hi Jakub,
>
> On Fri, Feb 03, 2017 at 10:10:47AM +0100, Jakub Jelinek wrote:
> > As mentioned in the PR, for the following testcase we emit a power9
> > instruction even with -mcpu=power8. Similar movsf_hardfloat instruction
>
On Fri, Feb 03, 2017 at 03:05:58PM -0500, Michael Meissner wrote:
> > > --- gcc/testsuite/gcc.target/powerpc/pr79354.c.jj 2017-02-03
> > > 02:37:44.147938375 +0100
> > > +++ gcc/testsuite/gcc.target/powerpc/pr79354.c2017-02-03
> > > 02:38:34.838303987 +0100
> > > @@ -0,0 +1,23 @@
> > > +/* PR
Scheduling should never move very expensive instructions to places they
are executed more frequently. This patch fixes that, reducing the
execution time of c-ray by over 40% (I tested on a BE Power7 system).
This introduces a new target hook sched.can_speculate_insn which returns
whether the sche
On 2/3/2017 3:03 PM, Walter Lee wrote:
Hi,
In looking at PR 79365 I found that the problem is actually in the
combiner. The combiner sometimes applies scalar optimizations to
vector context where they are invalid. i.e. (a > b) >> 1 can optimize
to 0 if ">" is a scalar op but not if it is a vec
On 02/02/2017 01:53 PM, David Malcolm wrote:
PR c++/79300 identifies an issue in which diagnostics_show_locus
prints the wrong end-point for a range within a macro:
assert ((p + val_size) - buf == encoded_len);
~^~~~
as opposed to:
assert ((p + val_size) -
On Thu, 02 Feb 2017 17:08:06 PST (-0800), Palmer Dabbelt wrote:
> On Thu, 02 Feb 2017 09:58:32 PST (-0800), jos...@codesourcery.com wrote:
>> On Thu, 2 Feb 2017, Palmer Dabbelt wrote:
>>
>>> Additionally, here's a diff against wwwdocs. This is really just to check
>>> this
>>> is all I'm supposed
On Fri, 2017-02-03 at 13:28 -0700, Jeff Law wrote:
> On 02/02/2017 01:53 PM, David Malcolm wrote:
> > PR c++/79300 identifies an issue in which diagnostics_show_locus
> > prints the wrong end-point for a range within a macro:
> >
> >assert ((p + val_size) - buf == encoded_len);
> >
On Fri, Feb 03, 2017 at 09:11:38PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 03, 2017 at 03:05:58PM -0500, Michael Meissner wrote:
> > > > --- gcc/testsuite/gcc.target/powerpc/pr79354.c.jj 2017-02-03
> > > > 02:37:44.147938375 +0100
> > > > +++ gcc/testsuite/gcc.target/powerpc/pr79354.c 201
Hi,
It turns out due to a hardware issue, LSE support is turned off.
This patch updates the thunderx cores to disable LSE and 8.1 where as
needed.
OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.
Thanks,
Andrew Pinski
ChangeLog:
* config/aarch64/aarch64-cores.def (thunder
This patch improves the code generation for:
vector char
compare_vc (vector char a, vector char b)
{
return a == b;
}
Previously it generated:
vcmpequb 2,2,3
vspltisw 1,-1
vspltisw 0,0
xxsel 34,32,33,34
and now it generat
On 02/03/2017 01:52 PM, David Malcolm wrote:
IIRC you had another issue that was borderline,
but which we did want to move forward on gcc-7. The reported
testcase
was a problem with a new warning, but the underlying issue could (in
theory) be tripped for existing warnings. RIght?
I think you
On Fri, 3 Feb 2017, Palmer Dabbelt wrote:
> How do these look?
Fine for readings.html. backends.html, not my cup of tea. ;-)
Gerald
On Fri, Feb 3, 2017 at 4:00 AM, Maxim Kuvyrkov
wrote:
> Hi Andrew,
>
> I took the liberty of rebasing your patch on top of my patchset. Does it
> look correct?
Yes this looks correct.
Thanks,
Andrew
>
> I think I addressed all the comments you had about my review and posted
> updated patches
GCC Maintainers:
The GCC 6 branch for the back port of the following two mainline commits
was approved and committed to GCC 6. The following patch is the back
port for the two commits for the GCC 5 branch. The only difference
relative to the GCC 6 patch is the line numbers.
mainline commits.
co
Hi!
As mentioned in the PR, on the gfortran.dg/forall_7.f90 testcase
we leak memory starting with r239542. vect_get_slp_defs allocates
a vector of vectors, elements corresponding to NULL in slp_ops
are .create (0) vectors that don't need freeing, but the rest
is safe_spliced into other vectors.
Hi!
On the gcc.dg/autopar/outer-4.c testcase we leak memory, because
vect_analyze_loop_form allocates vinfos for all the stmts in the loop
and when it calls vect_analyze_loop_form on the loop->inner before
the former is destroyed, we overwrite all those vinfo pointers for
stmts inside of the inner
On 02/03/2017 03:24 PM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, on the gfortran.dg/forall_7.f90 testcase
we leak memory starting with r239542. vect_get_slp_defs allocates
a vector of vectors, elements corresponding to NULL in slp_ops
are .create (0) vectors that don't need freeing, but
My patch for the new inheriting constructor semantics changed
tree-inline.c to avoid copying non-taken branches, in order to avoid
trying to refer to parameters that are omitted from base constructor
clones; this overlooked that we might enter such branches via goto.
This patch reverts that change,
On 02/03/2017 03:27 PM, Jakub Jelinek wrote:
Hi!
On the gcc.dg/autopar/outer-4.c testcase we leak memory, because
vect_analyze_loop_form allocates vinfos for all the stmts in the loop
and when it calls vect_analyze_loop_form on the loop->inner before
the former is destroyed, we overwrite all tho
Hi,
A couple of things. Firstly, we are in stage 4 now, so unless this
is a regression it will have to wait for GCC 8. I can carry the patch
or you can repost it when we are in stage 1.
Secondly, you forgot the changelog.
On Fri, Feb 03, 2017 at 03:03:06PM -0500, Walter Lee wrote:
> In looking
On 02/03/2017 01:12 PM, Segher Boessenkool wrote:
Scheduling should never move very expensive instructions to places they
are executed more frequently. This patch fixes that, reducing the
execution time of c-ray by over 40% (I tested on a BE Power7 system).
This introduces a new target hook sch
On 02/02/2017 02:31 AM, Alan Modra wrote:
Revised patch that cures the lra related -m32 -Os regression too.
The code that I'm patching here is changing a REG_EQUAL note to
REG_EQUIV, ie. asserting that the value of the reg is always the value
set by the current instruction. Which is not always
On Fri, Feb 03, 2017 at 04:25:00PM -0500, Michael Meissner wrote:
> +;; Return 1 if operand is either a vector constant of all 0 bits of a vector
> +;; constant of all 1 bits.
> +(define_predicate "vector_int_same_bit"
> + (match_code "const_vector")
> +{
> + if (GET_MODE_CLASS (mode) != MODE_VEC
On Fri, Feb 03, 2017 at 02:23:12PM -0800, Carl E. Love wrote:
> The GCC 6 branch for the back port of the following two mainline commits
> was approved and committed to GCC 6. The following patch is the back
> port for the two commits for the GCC 5 branch. The only difference
> relative to the GC
On Fri, Feb 03, 2017 at 06:07:56PM -0600, Segher Boessenkool wrote:
> On Fri, Feb 03, 2017 at 04:25:00PM -0500, Michael Meissner wrote:
> > +;; Return 1 if operand is either a vector constant of all 0 bits of a
> > vector
> > +;; constant of all 1 bits.
> > +(define_predicate "vector_int_same_bit"
Hi Jeff,
On Fri, Feb 03, 2017 at 04:31:58PM -0700, Jeff Law wrote:
> >+@deftypefn {Target Hook} bool TARGET_SCHED_CAN_SPECULATE_INSN (rtx_insn
> >*@var{insn})
> >+Some instructions should never be speculated by the schedulers, usually
> >+ because the instruction is too expensive to get this wron
Depending on the bootstrap compiler and configure options, we sometimes get a
compare failure
for gcc/function-tests.o on 32-bit hppa*-*-hpux*. The problem is a
"_GLOBAL__F_" label containing
a "random" string. For example,
.EXPORT _GLOBAL__F_.._.._gcc_gcc_function_tests.c_DFF67DD7_0x
On Fri, Feb 03, 2017 at 09:34:52AM +0100, Gerald Pfeifer wrote:
> On Fri, 14 Oct 2016, David Malcolm wrote:
> > On Fri, 2016-10-14 at 16:27 +0100, Pedro Alves wrote:
> >> FYI, I pushed these in now. I also bootstrapped with the
> >> jit included in the selected languages, and hacked the
> >> jit c
The attached change adds the -fno-common option to several tests that fail on
hppa*-*-hpux*.
Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2017-02-03 John David Anglin
* c-c++-common/Wunused-var-15.c: Add -fno-common additional option on
hppa*-*-hp
The attached change skips a couple of tests on hpux. The 32-bit hppa-hpux
target lacks support for
the dwarf debug format. We also lack the %hhd format except on 11.31.
Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2017-02-03 John David Anglin
* g++.dg/
This avoids test failure on 32-bit hppa*-*-hpux*. Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2017-02-03 John David Anglin
* gcc.dg/pr77587.c: Require alias support.
* gcc.dg/pr77587a.c: Likewise.
Index: gcc.dg/pr77587.c
We need to link against libatomic when available. Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2017-02-03 John David Anglin
* gfortran.dg/coarray_43.f90: Add "-latomic" option if
libatomic_available.
Index: gfortran.dg/coarray_43.f90
On Fri, Feb 03, 2017 at 06:57:54AM +, Hurugalawadi, Naveen wrote:
> Hi Andrew,
>
> Thanks for clearing the confusion.
>
> > I don't understand this comment and how it relates to your updated patch
>
> foo, foo1 and foo2 generates calls to "popcountdi2" which should have
> been "popcountsi2"
87 matches
Mail list logo
