On Thu, 23 Jun 2016, Alexander Monakov wrote:
> Hi,
>
> I've discovered that this assert in my patch was too restrictive:
>
> + if (DECL_HAS_VALUE_EXPR_P (pv->decl))
> + {
> + gcc_checking_assert (lookup_attribute ("omp declare target link",
> +
On Thu, Jun 30, 2016 at 05:55:04PM -0500, Peter Bergner wrote:
> We currently don't allow TDmode values to use direct moves, since they
> live in register pairs and the most significant word is always in the
> even-numbered register which does not match subreg ordering in little
> endian mode. The
Aaron Sawdey was running tests on the Power9 simulator, and he noticed that the
XXSPLTW to splat the SFmode value into the vector accessed the wrong element.
When I added the more general code for vector splat for power9, I called an
insn that reversed the element numbers on little endian, when I s
On 06/30/2016 06:01 AM, Aldy Hernandez wrote:
On 06/18/2016 07:55 PM, Martin Sebor wrote:
On 06/16/2016 02:32 AM, Aldy Hernandez wrote:
p.s. The pass currently warns on all uses of VLAs. I'm not completely
sold on this idea, so perhaps we could remove it, or gate it with a
flag.
I also thi
On Thu, Jun 30, 2016 at 08:10:41PM -0400, Michael Meissner wrote:
> Aaron Sawdey was running tests on the Power9 simulator, and he noticed that
> the
> XXSPLTW to splat the SFmode value into the vector accessed the wrong element.
> When I added the more general code for vector splat for power9, I
We currently don't allow TDmode values to use direct moves, since they
live in register pairs and the most significant word is always in the
even-numbered register which does not match subreg ordering in little
endian mode. The following patch fixes PR71698 by disallowing reload
from using direct
On 06/20/2016 08:52 AM, Joseph Myers wrote:
On Sat, 18 Jun 2016, Martin Sebor wrote:
The attached patch slightly changes the order in which initializers
are checked for type compatibility to issue the same error for static
initializers of incompatible types as for automatic objects, rather
than
On Thu, 30 Jun 2016, Bill Schmidt wrote:
> # Return 1 if the target supports any special run-time requirements
>
> # for __float128 or _Float128,
>
> # 0 otherwise.
>
Hi!
On Thu, 21 Jan 2016 22:54:26 +0100, I wrote:
> Committed to gomp-4_0-branch in r232709:
>
> commit 41a76d233e714fd7b79dc1f40823f607c38306ba
> Author: tschwinge
> Date: Thu Jan 21 21:52:50 2016 +
>
> Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid
> offloa
On Thu, 2016-06-30 at 17:55 +, Joseph Myers wrote:
> On Thu, 30 Jun 2016, Bill Schmidt wrote:
>
> > +# Return 1 if the target supports __float128 at run time,
> > +# 0 otherwise.
> > +
> > +proc check_effective_target___float128_runnable { } {
>
> I'd think you should have an effective-target
On Fri, Jun 24, 2016 at 6:35 AM, Jakub Jelinek wrote:
> On Thu, Jun 23, 2016 at 05:23:21PM +0200, Jakub Jelinek wrote:
>> Thinking about this again, there could be another option - keep
>> __atomic_compare_exchange_N in the IL, but under certain conditions (similar
>> to what the patch uses in fol
On Thu, 2016-06-30 at 08:38 -0400, Nathan Sidwell wrote:
> Jan-Benedict,
>
> > I haven't given it any additional manual testing so far. It's
> > pre-installation though. Maybe I'd just set WIND_BASE to some
> > arbitrary value, just to make xgcc pass it's initial start-up test
> > so
> > that it c
On 29/06/2016 23:30, Jonathan Wakely wrote:
On 29/06/16 21:36 +0100, Jonathan Wakely wrote:
On 29/06/16 21:43 +0200, François Dumont wrote:
As asked here is now a patch to only fix the robustness issue. The
consequence is that it is reverting the latest optimization as,
without smart algo, we
On June 30, 2016 7:38:05 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>I thought for ADDR_EXPRs we couldn't reach this, but we actually can,
>when
>there is an SSA_NAME with POINTER_PLUS_EXPR of ADDR_EXPR and constant.
>
>The following patch handles it.
>
>Bootstrapped/regtested on x86_64-linux and i
The followup patch implements lookup_name_fuzzy for the C++ frontend.
It's cleaner for that implementation to return a const char *, so this
patch updates the implementation in the C frontend to have the same
return type.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu
(in combination wit
This is a port of the C frontend's r237714 [1] to the C++ frontend:
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01052.html
offering spelling suggestions for misspelled identifiers, macro names,
and some keywords (e.g. "singed" vs "signed" aka PR c/70339).
Unlike the C frontend, there doesn't s
Hi!
While usually the order of vars in block scope isn't that significant,
e.g. on the following testcase with -fopenmp -fstack-arrays it does matter
if we have local declaration of a temporary and then local declaration of
a VLA that uses that other temporary as the TYPE_SIZE_UNIT, or the other w
On Thu, 30 Jun 2016, Bill Schmidt wrote:
> +# Return 1 if the target supports __float128 at run time,
> +# 0 otherwise.
> +
> +proc check_effective_target___float128_runnable { } {
I'd think you should have an effective-target for this that's shared
between _Float128 and __float128, possibly one
On Thu, 30 Jun 2016, Bill Schmidt wrote:
> On Wed, 2016-06-29 at 16:37 +, Joseph Myers wrote:
> > On Tue, 28 Jun 2016, Bill Schmidt wrote:
> >
> > > -/* { dg-do compile { target ia64-*-* i?86-*-* x86_64-*-* } } */
> > > +/* { dg-do compile { target ia64-*-* i?86-*-* x86_64-*-* powerpc64*-*-*
Hi!
The following patch fixes ICE on target update construct clauses.
While the testcase is (at runtime) invalid in OpenMP 4.0, it is valid in
4.5, and we shouldn't ICE on it anyway.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk,
queued for 6.2 backport.
2016-06-30 J
Hi!
The Fortran parser apparently relies in functions that have still undecided
kind of the result that ST_GET_FCN_CHARACTERISTICS artificial statement is
returned before any executable statements in the function.
In normal statements that is ensured through decode_statement calling
decode_specifi
Hi!
I thought for ADDR_EXPRs we couldn't reach this, but we actually can, when
there is an SSA_NAME with POINTER_PLUS_EXPR of ADDR_EXPR and constant.
The following patch handles it.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-06-30 Jakub Jelinek
PR tree
Hi,
My previous patch added to the specific target list for the tests, and
Joseph suggested it would be better to use an effective target check.
This version does this. To avoid a name clash with Joseph's pending
patch, the effective target names include __float128 rather than
float128. I discov
On 29/06/16 22:31, Jiong Wang wrote:
Andreas Krebbel writes:
On 06/28/2016 04:16 PM, Jiong Wang wrote:
...
So my first impression is TARGET_LEGITIMATE_ADDRESS_P on s390 do need a
fix here. The following draft patch fix this, my fix may be in
correct as normally we will allow illegal constant o
Ping.
Looking back at this it's probably obvious, but since I had already asked for
approval...
Thanks,
Kyrill
On 17/06/16 15:38, Kyrill Tkachov wrote:
Ping.
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00821.html
Thanks,
Kyrill
On 10/06/16 15:55, Kyrill Tkachov wrote:
Hi all,
This functio
# of unexpected failures32
# of expected failures314
# of unresolved testcases6
# of unsupported tests 4169
/Users/manishearth/dev/gcc-build/gcc/testsuite/g++/../../xg++ version
7.0.0 20160630 (experimental) (GCC)
=== gcc tests ===
Running target unix
FAIL: c-c++-comm
On Thu, 30 Jun 2016, Richard Biener wrote:
points-to analysis already has the constraint that POINTER_PLUS_EXPR
cannot leave the object op0 points to. Of course currently nothing uses
the fact whether points-to computes pointed-to as nothing (aka NULL) -
so the argument may be moot.
Anyway,
Evandro Menezes wrote:
On 06/29/16 07:59, James Greenhalgh wrote:
> On Tue, Jun 21, 2016 at 02:39:23PM +0100, Wilco Dijkstra wrote:
>> ping
>>
>>
>> From: Wilco Dijkstra
>> Sent: 03 June 2016 11:51
>> To: GCC Patches
>> Cc: nd; philipp.toms...@theobroma-systems.com; pins...@gmail.com;
>> jim.wil..
On Jun 23, 2016, at 5:21 AM, Senthil Kumar Selvaraj
wrote:
>
> 2. Even if (1) is fixed, the custom section (.foo) is not mapped to
> any output section or region in the linker script. The linker can
> error out only if the contents overflow a region.
If the segment isn't loaded, then it's size
On Jun 23, 2016, at 4:00 AM, Georg-Johann Lay wrote:
> Binutils don't produce a message
That's unfortunate.
> so there is nothing to scan for. Hacking binutils is beyond my scope.
That's fine.
> avrtest behaves just as if the program under test would call abort.
That's unfortunate. Would be
On Wed, 2016-06-29 at 16:37 +, Joseph Myers wrote:
> On Tue, 28 Jun 2016, Bill Schmidt wrote:
>
> > -/* { dg-do compile { target ia64-*-* i?86-*-* x86_64-*-* } } */
> > +/* { dg-do compile { target ia64-*-* i?86-*-* x86_64-*-* powerpc64*-*-* }
> > } */
> > /* { dg-options "-pedantic" } */
>
Richard,
Could you please review additional simple fix for 70729 - we need to
nullify safelen field of loops containing simduid intrinsics like
GOMP_SIMD_LANE (introduced e.g. for private variables). I checked
that this fix cures regression which was missed by me since AVX2
machine is required fo
On 07/06/16 17:56, Kyrill Tkachov wrote:
> Hi all,
>
> This patch addresses an deficiency we have in handling vector
> lane-to-lane moves in the AArch64 backend.
> Generally we can use the INS (element) instruction but, as a user
> complains in https://gcc.gnu.org/ml/gcc-help/2016-05/msg00069.html
On May 5, 2016, at 8:14 AM, Robert Suchanek wrote:
>
> I'm resending this patch as it has been rebased and updated. I reverted a
> change
> to check_effective_target_vect_call_lrint procedure because it does not use
> cached result.
Ok.
Please ensure that the compilation flag is mixed into th
Hello,
This patch adds the -mpure-code option for ARM. This option ensures
functions are put into sections that contain only code and no data. To
ensure this throughout compilation we give these sections the ARM
processor-specific ELF section attribute "SHF_ARM_PURECODE". This option
is only suppo
On Thu, Jun 30, 2016 at 04:25:16PM +0200, Thomas Schwinge wrote:
> Hi!
>
> On Thu, 30 Jun 2016 16:48:25 +0300, Yuri Rumyantsev
> wrote:
> > Thanks for your help.
> > Could you please look at the following simple patch which cures
> > regression - we need to nullify loop safelen field in
> > adj
Ping.
Thanks,
Kyrill
On 22/06/16 11:07, Kyrill Tkachov wrote:
Ping.
Richard, Marcus, do you have any feedback on this?
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00502.html
Thanks,
Kyrill
On 14/06/16 10:36, James Greenhalgh wrote:
On Tue, Jun 07, 2016 at 05:56:47PM +0100, Kyrill Tkachov w
Hi!
On Thu, 30 Jun 2016 16:48:25 +0300, Yuri Rumyantsev wrote:
> Thanks for your help.
> Could you please look at the following simple patch which cures
> regression - we need to nullify loop safelen field in
> adjust_simduid_builtins:
>
> diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorize
On 31/03/16 14:11, Ramana Radhakrishnan wrote:
> Hi,
>
> In this PR we have a situation where we aren't really detecting
> weak references vs weak definitions. If one has a weak definition
> that binds locally there's no reason not to put out PC relative
> relocations.
>
> However if you ha
On Wednesday 29 June 2016 21:58:40 Jonathan Wakely wrote:
> On 29/06/16 13:49 -0700, Mike Stump wrote:
> >Please include the libstdc++ list, they don't all read the other list.
>
> And the documentation clearly says (in two places) that all libstdc++
> patches must go to the libstdc++ list.
Oops
I'm getting a failure on
./gcc/testsuite/c-c++-common/asan/strncpy-overflow-1.c with the latest
patch. Unsure if it's related; we're not doing any pointer arithmetic
there.
I'll test it again on trunk without the patch and see what happens.
-Manish
On Thu, Jun 30, 2016 at 7:18 PM, Richard Biener
The following patch fixes PR71632 by removing delayed expansion of
TERed defs. Instead it adds code to apply the scheduling effect
to the GIMPLE IL (so you also get better interleaved GIMPLE stmt
/ generated RTL dumps in .expand).
This removes the quadratic re-expansion of TERed RHS as seen in
t
On Thu, Jun 30, 2016 at 3:38 PM, Marc Glisse wrote:
> On Thu, 30 Jun 2016, Manish Goregaokar wrote:
>
>> Alright, the following patch was tested and it works
>>
>> diff --git a/gcc/fold-const.c b/gcc/fold-const.c
>> index 3b9500d..0d82018 100644
>> --- a/gcc/fold-const.c
>> +++ b/gcc/fold-const.c
Hi Jacub,
Thanks for your help.
Could you please look at the following simple patch which cures
regression - we need to nullify loop safelen field in
adjust_simduid_builtins:
diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c
index 2669813..f70380c 100644
--- a/gcc/tree-vectorizer.c
+++
On Thu, 30 Jun 2016, Manish Goregaokar wrote:
Alright, the following patch was tested and it works
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 3b9500d..0d82018 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -13199,6 +13199,9 @@ tree_binary_nonzero_warnv_p (enum tree_code cod
* Richard Sandiford [2016-06-15 19:07:56 +0100]:
> Andrew Burgess writes:
> > In md.texi it says:
> >
> > Predicates written with @code{define_special_predicate} do not get any
> > automatic mode checks, and are treated as having special mode handling
> > by @command{genrecog}.
> >
> > How
Alright, the following patch was tested and it works
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 3b9500d..0d82018 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -13199,6 +13199,9 @@ tree_binary_nonzero_warnv_p (enum tree_code code,
switch (code)
{
case POINTER_PLUS
On Thu, Jun 30, 2016 at 2:03 PM, Manish Goregaokar wrote:
> What about ptr + intptr_t? I guess we should check nonnegative for op1 then?
op1 will always be nonnegative as it is forced to sizetype type (which
is unsigned).
Richard.
> -Manish
>
>
> On Thu, Jun 30, 2016 at 5:25 PM, Richard Biener
Hi,
i sent the email before, but it seems it never left my machine. Sorry for
possible duplicates. This is updated version which does not overflow (by
capping nit), but still using widest_int for the calculatoins. It seems more
readable to do so than using wi:add/wi:mult/wi:lt and overflow checks,
Jan-Benedict,
I haven't given it any additional manual testing so far. It's
pre-installation though. Maybe I'd just set WIND_BASE to some
arbitrary value, just to make xgcc pass it's initial start-up test so
that it can continue with self-testing? Or shall we set some value
in gcc/Makefile.in fo
On Thu, Jun 30, 2016 at 03:16:51PM +0300, Yuri Rumyantsev wrote:
> Hi Grüße.
>
> Could you please tell me how to reproduce your regression - did not
> see any new failures in my local area:
>
> PASS: libgomp.fortran/examples-4/simd-2.f90 -O0 (test for excess errors)
> PASS: libgomp.fortran/exa
Hi Grüße.
Could you please tell me how to reproduce your regression - did not
see any new failures in my local area:
PASS: libgomp.fortran/examples-4/simd-2.f90 -O0 (test for excess errors)
PASS: libgomp.fortran/examples-4/simd-2.f90 -O0 execution test
PASS: libgomp.fortran/examples-4/simd-
What about ptr + intptr_t? I guess we should check nonnegative for op1 then?
-Manish
On Thu, Jun 30, 2016 at 5:25 PM, Richard Biener
wrote:
> On Thu, Jun 30, 2016 at 1:17 PM, Manish Goregaokar wrote:
>> gcc/ChangeLog:
>> PR c/71699
>> * fold-const.c (tree_binary_nonzero_warnv_p): Allow
On 06/18/2016 07:55 PM, Martin Sebor wrote:
On 06/16/2016 02:32 AM, Aldy Hernandez wrote:
p.s. The pass currently warns on all uses of VLAs. I'm not completely
sold on this idea, so perhaps we could remove it, or gate it with a flag.
I also think that VLA diagnostics would be better control
On 06/21/2016 05:50 PM, James Greenhalgh wrote:
For the default implementation, if the parameters are not set, I just
multiply BRANCH_COST through by COSTS_N_INSNS (1) for size and
COSTS_N_INSNS (3) for speed. I know this is not ideal, but I'm still short
of ideas on how best to form the default
On Thu, Jun 30, 2016 at 1:17 PM, Manish Goregaokar wrote:
> gcc/ChangeLog:
> PR c/71699
> * fold-const.c (tree_binary_nonzero_warnv_p): Allow
> pointer addition to also be considered nonzero.
> ---
> gcc/fold-const.c | 20 +---
> 1 file changed, 13 insertions(+), 7 del
Hi Nathan!
The recent self-testing fails for i686-wrs-vxworks:
/home/jbglaw/build-configlist_mk/i686-wrs-vxworks/build-gcc/mk/i686-wrs-vxworks/./gcc/xgcc
-B/home/jbglaw/build-configlist_mk/i686-wrs-vxworks/build-gcc/mk/i686-wrs-vxworks/./gcc/
-xc -S -c /dev/null -fself-test
xgcc: fatal error:
Improved wording after a chat with `redi` on IRC.
gcc/ChangeLog:
* doc/install.texi: Mention download_prerequisites
---
gcc/doc/install.texi | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 9248f0d..de43e36 100644
--- a/
gcc/ChangeLog:
PR c/71699
* fold-const.c (tree_binary_nonzero_warnv_p): Allow
pointer addition to also be considered nonzero.
---
gcc/fold-const.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 3b9500d
Small patches batch.
Ok to apply?
Claudiu
gcc/
2016-05-09 Claudiu Zissulescu
* config/arc/arc.c (arc_process_double_reg_moves): Change.
* config/arc/arc.md (movsi_insn): Disable unsupported move
instructions for ARCv2 cores.
(movdi): Use prepare_move_operands.
On 06/29/2016 02:26 PM, tbsaunde+...@tbsaunde.org wrote:
patches individually bootstrapped and regtested on x86_64-linux-gnu, ok?
I think these all look sensible. ChangeLogs ought to have slightly more
information than "Adjust" in some cases, especially when you're changing
function arguments
Update the INSN_LENGTH_ALIGNMENT macro to handle jump tables placed in
program memory.
Ok to apply?
Claudiu
gcc/
2016-06-20 Claudiu Zissulescu
* config/arc/arc.h (INSN_LENGTH_ALIGNMENT): Change.
---
gcc/config/arc/arc.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
di
The mululw instructions are wrongly used in the patterns, fix them.
Okt to apply?
Claudiu
gcc/
2016-06-28 Claudiu Zissulescu
* config/arc/arc.md (umul_600): Change.
(umul64_600): Likewise.
---
gcc/config/arc/arc.md | 18 +++---
1 file changed, 7 insertions(+), 11
On Thu, May 5, 2016 at 8:45 AM, Ramana Radhakrishnan
wrote:
> On Thu, Mar 31, 2016 at 2:11 PM, Ramana Radhakrishnan
> wrote:
>> Hi,
>>
>> In this PR we have a situation where we aren't really detecting
>> weak references vs weak definitions. If one has a weak definition
>> that binds loca
* Claudiu Zissulescu [2016-06-30 07:36:32
+]:
> I think the compactsi makes no sense for ARCv2 without the add_s
> reg, reg,PCL instruction. Moreover, I have proposed a patch about
> this issue months ago, See:
> https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01462.html. However,
> our main
Hi,
PR 71688 is about an ICE in cgraphunit.c caused by the fact that
Fortran FE creates two separate call-graph nodes for a single function
decl, if you are interested, complete backtraces leading to the point
of creating them are in bugzilla.
The intuitive fix, changing one of these points so th
On 06/29/2016 01:00 PM, Richard Biener wrote:
> Ok. Might want to backport the inline_call hunk to all affected branches.
>
> Richard.
Done in GCC-6 branch. Older branches are not affected.
On 29/06/16 18:03, Wilco Dijkstra wrote:
> This patch sets the branch cost to the same most optimal setting for all
> Cortex cores,
> reducing codesize and improving performance due to using more CSEL
> instructions.
> Set the autoprefetcher model in Cortex-A72 to weak like the others. Enable
>
On 28/06/16 08:54, Richard Biener wrote:
On Thu, 16 Jun 2016, Kyrill Tkachov wrote:
On 15/06/16 22:53, Marc Glisse wrote:
On Wed, 15 Jun 2016, Kyrill Tkachov wrote:
This is a respin of
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00952.html following
feedback.
I've changed the code to cast
On Thu, Jun 30, 2016 at 12:08 AM, Eric Botcazou wrote:
> Hi,
>
> this patch implements generic support for the elimination of stack trampolines
> and, consequently, of the need to make the stack executable when pointers to
> nested functions are used. That's done on a per-language and per-target
I think the compactsi makes no sense for ARCv2 without the add_s reg, reg,PCL
instruction. Moreover, I have proposed a patch about this issue months ago,
See: https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01462.html. However, our
maintainer is missing in action.
Cheers,
Claudiu
> -Origin
On Wed, 29 Jun 2016, Jakub Jelinek wrote:
> Hi!
>
> This issue is latent on the trunk/6.2, fails with checking in 5.x/4.9.
> As usually in fold_*_loc, arg0/arg1 is STRIP_NOPS op0/op1, so might have
> incompatible type, so we need to convert it to the right type first
> before optimizing.
>
> Boo
2016-06-30 Manish Goregaokar
gcc/ChangeLog:
* doc/install.texi: Mention download_prerequisites
---
gcc/doc/install.texi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 9248f0d..0070fdf 100644
--- a/gcc/doc/install.tex
73 matches
Mail list logo
