On Fri, Dec 11, 2015 at 11:54 AM, Andrew Pinski wrote:
> Hi,
> The Linux kernel calls lse as atomics in /proc/cpuinfo. We should
> change aarch64-option-extensions.def to take that into account.
>
> OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions
> and tested with -mcpu=na
On Fri, Dec 18, 2015 at 4:17 AM, Nick Clifton wrote:
>
> 2015-12-18 Nick Clifton
>
> PR 66827
> * regex.c (EXTRACT_NUMBER): Cast sign byte to unsigned before left
> shifting.
This is OK.
Thanks.
Ian
On Fri, Dec 18, 2015 at 11:20 PM, Yury Gribov wrote:
> On 12/17/2015 03:51 PM, Richard Biener wrote:
>>
>> On Thu, 17 Dec 2015, Yury Gribov wrote:
>>
>>> On 12/17/2015 02:57 PM, Richard Biener wrote:
On Thu, 17 Dec 2015, Yury Gribov wrote:
> That's an interesting one. The origin
On December 18, 2015 6:29:10 PM GMT+01:00, Nick Clifton
wrote:
>Hi Guys,
>
> The gcc test gcc.dg/lto/pr55113_0.c is currently generating an ICE
> when compiled for x86 and x86_64 targets using the mainline sources
> (revision 231805):
>
>: internal compiler error: in layout_type, at
>stor-layo
Similar to the C++ case in the previous patch, but more involved as
the location of the pertinent token isn't readily available; the patch
adds it as a param to build_component_ref. All callers are updated to
provide the info, apart from objc_build_component_ref; fixing the latter
would lead to a
When we emit a hint about a misspelled member name, it will slightly
aid readability if we use a fixit-hint to show the proposed
name in context within the source code (and in the future this
might support some kind of auto-apply in an IDE).
This patch adds such a hint to the C++ frontend, taking
The following patch adds a fix-it insertion hint for missing
"template <> " in explicit specializations.
This is more of an enhancement than a bug fix (PR 62314 is more of a
catch-all for adding fix-its), but it's low-risk and a user-visible
improvement, and this specific example is called out as
Looking over the discussion of missing semicolons in
"Quality of Implementation and Attention to Detail"
within
http://clang.llvm.org/diagnostics.html
and comparing with
https://gcc.gnu.org/wiki/ClangDiagnosticsComparison
I noticed that of the cases we do handle [1], there's room for
improvem
>
> The debug info on your testcase looks as expected (though,
> we really don't emit the DW_OP_GNU_parameter_ref for aggregates anyway
> - not sure if we could do something about those at least in the easy cases
> where the argument used to be stored into the struct shortly before the
> call.
Co
On 18/12/15 21:59 +0200, Ville Voutilainen wrote:
Here's a fix for the regression that the patch introduced. Tested with
-m32 on Linux-X64.
OK, thanks for the quick turnaround.
On 12/18/15 09:59, Rainer Orth wrote:
Hi Jakub,
ok, I see. I'm uncomfortable declaring the requirement this
indirectly/unobviously. I'd rather add a requirement on cilkplus (we
have that effective-target keyword already) and update
check_effective_target_cilkplus in target-supports.exp for nv
On Fri, 18 Dec 2015, Marek Polacek wrote:
> + tree sz = TYPE_SIZE_UNIT (TREE_TYPE (lhs_type));
> + rhs = fold_build2_loc (loc, MULT_EXPR, rhs_type, rhs,
> + convert (rhs_type, sz));
Converting the size to rhs_type seems wrong, as does multiplying in
rhs_t
On 12/18/2015 06:56 PM, Jason Merrill wrote:
These broke a lot of tests in the GDB C++ testsuite. Specifically, the
commit
DWARF: handle variable-length records and variant parts
Arg, sad to hear that! I did testing at some point with the GDB
testsuite… I’ll investigate on Monday, thank
This patch relaxes some of the ptx-specific predicates to allow hard regs. We
also can use some regular predicates for the mov insns and a couple of openacc
hooks.
More cleanup coming soon ...
nathan
2015-12-18 Nathan Sidwell
* config/nvptx/nvptx.c (nvptx_maybe_convert_symbolic_operand):
On 12/17/2015 03:51 PM, Richard Biener wrote:
On Thu, 17 Dec 2015, Yury Gribov wrote:
On 12/17/2015 02:57 PM, Richard Biener wrote:
On Thu, 17 Dec 2015, Yury Gribov wrote:
That's an interesting one. The original comparison function assumes that
operand_equal_p(a,b) is true iff compare_tree(a
On Thu, Dec 17, 2015 at 10:10:48PM +0100, Jan Hubicka wrote:
> here is better testcase that also trigger splitting
> struct a {int a;int b;};
The debug info on your testcase looks as expected (though,
we really don't emit the DW_OP_GNU_parameter_ref for aggregates anyway
- not sure if we could do
> > Hi,
> > the alias-2.c testcase fails on targets with anchors. The reason is that
> > the variable itself is anchored while the alias is not and they point to the
> > same location. I folllowed the docs of SYMBOL_REF claiming that
> > SYMBOL_REF_DECL if the symbol is label and tought it is sa
On 12/18/2015 11:07 PM, Jakub Jelinek wrote:
On Fri, Dec 18, 2015 at 10:40:40PM +0300, Yury Gribov wrote:
So it seems most people generally agree that self-comparisons (cmp(x,x) ==
0) are useless and don't need to be checked or fixed. What about ensuring
symmetry i.e. that cmp(x, y) == -cmp(y, x
On Fri, Dec 18, 2015 at 10:40:40PM +0300, Yury Gribov wrote:
> So it seems most people generally agree that self-comparisons (cmp(x,x) ==
> 0) are useless and don't need to be checked or fixed. What about ensuring
> symmetry i.e. that cmp(x, y) == -cmp(y, x) forall x, y? One of the bugs
> (pair_cm
libcpp has a degraded fallback mode for large source files where if a
location_t > LINE_MAP_MAX_LOCATION_WITH_COLS
we fall back to just tracking lines, not columns&ranges
(currently 0x6000), and every location_t expands to having a
column == 0.
Sadly we're more likely to see this case in gcc 6
When debugging PR c++/68819 I noticed an inefficiency during
the handling of locations > LINE_MAP_MAX_LOCATION_WITH_COLS.
When combining ranges for locations with
start == caret == finish (with a NULL data ptr)
get_combined_adhoc_loc was always building an ad-hoc entry
rather than simply returnin
On 18 December 2015 at 16:47, Jonathan Wakely wrote:
> It only occurs to me now (rather than when I first suggested this
> change) that it changes behaviour for users who have replaced operator
> new, but not replaced the nothrow_t version.
>
> But I can't believe that anyone would replace operato
On 12/17/2015 10:36 PM, Vladimir Makarov wrote:
On 12/17/2015 04:00 AM, Yury Gribov wrote:
This patch fixes intransitive comparison in
reload_pseudo_compare_func. Imagine the following
situation:
1) bitmap_bit_p is unset for A and B but set for C
2) A < B (due to early ira_reg_class_max_nregs co
On 12/17/2015 03:04 PM, Yury Gribov wrote:
On 12/17/2015 02:39 PM, Jakub Jelinek wrote:
On Thu, Dec 17, 2015 at 11:58:30AM +0300, Yury Gribov wrote:
2015-12-17 Yury Gribov
* c-family/c-common.c (resort_field_decl_cmp):
Make symmteric.
* cp/class.c (method_name_cmp): Ditto.
(
Hi Steve,
The patch is almost exactly as you reviewed before. The tweaks to
trans.c came about because of other patches that prevented this one
from applying. Please concentrate on the modified testcase and let me
know if you would like me to make it work as it does in 6 branch. I
will take a quic
On Thu, 2015-12-17 at 19:21 +0100, Bernd Schmidt wrote:
> On 12/17/2015 07:32 PM, David Malcolm wrote:
> > + if (close_paren_loc)
>
> close_paren_loc != UNKNOWN_LOCATION - it's very confusing otherwise.
>
>
> Bernd
Here's an updated version; the only change since v1 is:
-
On Fri, Dec 18, 2015 at 07:12:47PM +0100, Paul Richard Thomas wrote:
>
> I have just applied the patch to 5 branch and have found that, apart
> from two minor tweaks in trans.c, all was well. It bootstrapped
> and regtested fine, apart from deferred_character_2.f90. In this
> latter, deferred len
In an earlier fix, the following change was made in varasm.c for invalid
register variables:
--- trunk/gcc/varasm.c 2014/08/26 14:59:59 214525
+++ trunk/gcc/varasm.c 2014/08/26 17:06:31 214526
@@ -1371,6 +1371,11 @@ make_decl_rtl (tree decl)
/* As a register variable, it has
> I'm also seeing
> +FAIL: gnat.dg/specs/debug1.ads scan-assembler-times DW_AT_artificial 17
> and from what I can see in gcc-testresults, I'm not alone.
Minor oversight, adjusted like so:
* gnat.dg/specs/debug1.ads: Bump final count to 18.
--
Eric Botcazou
Index: gnat.dg/specs/debug1.a
Dear All,
In running through the PRs assigned to me, I realised that I have not
closed these PRs because I had promised to see if the patch would
apply to 4.9 and 5 branch.
I have just applied the patch to 5 branch and have found that, apart
from two minor tweaks in trans.c, all was well. It boot
On Fri, Dec 18, 2015 at 12:56:07PM -0500, Jason Merrill wrote:
> On 12/17/2015 09:10 AM, Pierre-Marie de Rodat wrote:
> >On 12/16/2015 10:30 PM, Jason Merrill wrote:
> >>OK with those changes.
> >
> >All changes done, and all patches pushed. Thank you very much!!
>
> These broke a lot of tests in
OK.
Jason
OK.
Jason
On 12/17/2015 09:10 AM, Pierre-Marie de Rodat wrote:
On 12/16/2015 10:30 PM, Jason Merrill wrote:
OK with those changes.
All changes done, and all patches pushed. Thank you very much!!
These broke a lot of tests in the GDB C++ testsuite. Specifically, the
commit
DWARF: handle variabl
Before my patch for PR c++/21802, the function build_x_modify_expr() did
not call build_new_op() during template processing (and thus did not do
operator lookup); instead, it just built and returned a raw MODOP_EXPR.
After my patch, the function build_x_modify_expr() now calls
build_new_op() even
The new dg test for stabs support quite reasonably expects an error if there is
no support. PTX was silently ignoring debug info requests. stabs is never
gonna work though, so be noisy for that.
also noticed another place I should be calling nvptx_assemble_decl_end
nathan
2015-12-18 Nath
---
gcc/graphite-dependences.c | 63 ++--
gcc/graphite-isl-ast-to-gimple.c | 2 ++
gcc/graphite-optimize-isl.c | 12
gcc/graphite-sese-to-poly.c | 28 --
4 files changed, 56 insertions(+), 49 deletions(-)
diff --git a/g
---
gcc/graphite-optimize-isl.c | 96 -
gcc/graphite-poly.c | 19 +
gcc/graphite.h | 2 +
gcc/params.def | 2 +-
4 files changed, 108 insertions(+), 11 deletions(-)
diff --git a/gcc/graphite-optimize-isl.c b/g
---
gcc/graphite-isl-ast-to-gimple.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c
index 64183c4..7e00b17 100644
--- a/gcc/graphite-isl-ast-to-gimple.c
+++ b/gcc/graphite-isl-ast-to-gimple.c
@@ -1245,6 +1245,15 @@ t
---
gcc/graphite-isl-ast-to-gimple.c | 56 +++
gcc/graphite-optimize-isl.c | 317 +--
gcc/graphite-poly.c | 24 +--
3 files changed, 40 insertions(+), 357 deletions(-)
diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-
Hi Guys,
The gcc test gcc.dg/lto/pr55113_0.c is currently generating an ICE
when compiled for x86 and x86_64 targets using the mainline sources
(revision 231805):
: internal compiler error: in layout_type, at stor-layout.c:2212
0xaee2c9 layout_type(tree_node*)
/work/sources/gcc/curr
On Fri, Dec 18, 2015 at 06:15:11PM +0100, Marek Polacek wrote:
> As outlined in the PR, build_atomic_assign can do a better job. It seems
> profitable to use __atomic_fetch_* built-ins when possible rather than the
> generic CAS loop. This patch attempts to implement that.
>
> There are two ???s
Andreas recently reported a bug on aarch64. However, when I first
scanned the report I missed the fact that it was aarch64. Instead my
brain saw Andreas's m68k-linux.org address and locked in on m68k. Then
I looked quickly at the bug and it looked like I was going to need a
native system
As outlined in the PR, build_atomic_assign can do a better job. It seems
profitable to use __atomic_fetch_* built-ins when possible rather than the
generic CAS loop. This patch attempts to implement that.
There are two ???s in the patch. For the first one, I think let's just
ignore enums, the p
Hi Guys,
PR 68913 notes that the test gcc.dg/lto/pr61886_0.c test fails on
targets whose C library does not provide a __fread_chk function.
Since the purpose of the test is to show that GCC will correctly
discard the invocation of __fread_chk_warn, we do not need to actually
link agains
On Thu, Nov 12, 2015 at 4:03 AM, Ilya Enkovich wrote:
> Hi,
>
> This patch fixes a way operand is chosen by its num for COND_EXPR.
> Bootstrapped and regtested on x86_64-unknown-linux-gnu. OK for trunk?
>
> Thanks,
> Ilya
> --
> gcc/
>
> 2015-11-12 Ilya Enkovich
>
> PR tree-optimizat
> On 12/11/2015 03:05 AM, Richard Biener wrote:
> > On Thu, Dec 10, 2015 at 9:08 PM, Jeff Law wrote:
> >> On 12/03/2015 07:38 AM, Richard Biener wrote:
> >>>
> >>> This pass is now enabled by default with -Os but has no limits on
> >>> the amount of stmts it copies.
> >>
> >> The more statements i
Hi Jakub,
>> ok, I see. I'm uncomfortable declaring the requirement this
>> indirectly/unobviously. I'd rather add a requirement on cilkplus (we
>> have that effective-target keyword already) and update
>> check_effective_target_cilkplus in target-supports.exp for nvptx.
>
> That is what we have
On Fri, Dec 18, 2015 at 03:49:59PM +0100, Rainer Orth wrote:
> Hi Nathan,
>
> > On 12/18/15 09:36, Rainer Orth wrote:
> >> Hi Nathan,
> >>
> >>> c-c++-common/attr-simd-3.c's use of -fcilkplus means it requires
> >>> pthreads.
> >>
> >> why would this matter for a compile test? What happens wit
Hi Nathan,
> On 12/18/15 09:36, Rainer Orth wrote:
>> Hi Nathan,
>>
>>> c-c++-common/attr-simd-3.c's use of -fcilkplus means it requires pthreads.
>>
>> why would this matter for a compile test? What happens without?
>
> Executing on host: nvptx-none-gcc
> /scratch/nsidwell/openacc/trunk-ptx-sh
On 17/12/15 00:38 +0200, Ville Voutilainen wrote:
On 17 December 2015 at 00:12, Ville Voutilainen
wrote:
Tested on Linux-PPC64.
2015-12-17 Ville Voutilainen
PR libstdc++/68276
* src/c++11/ios.cc (_M_grow_words): Use nothrow new.
* testsuite/27_io/ios_base/storage/11584.cc: Adj
On 12/18/15 09:36, Rainer Orth wrote:
Hi Nathan,
c-c++-common/attr-simd-3.c's use of -fcilkplus means it requires pthreads.
why would this matter for a compile test? What happens without?
Executing on host: nvptx-none-gcc
/scratch/nsidwell/openacc/trunk-ptx-shared/src/gcc-mainline/gcc/t
This patch removes the special case instructions for handling the worker
broadcast buffer. Also commonizes the emission of the reduction and broadcast
buffer variables.
This is a step towards merging the convaddr instruction into a regular mov.
nathan
2015-12-18 Nathan Sidwell
* config/n
On 12/18/2015 03:29 PM, Kyrill Tkachov wrote:
Bootstrapped and tested on arm, aarch64, x86_64.
As before, there were no codegen differences for SPEC2006 on x86_64.
aarch64 SPEC2006 sees the effects described above.
I think this is OK. There may be some question as to whether this is a
bug fix,
Hi Nathan,
> c-c++-common/attr-simd-3.c's use of -fcilkplus means it requires pthreads.
why would this matter for a compile test? What happens without?
Rainer
--
-
Rainer Orth, Center for Biotechnology, Biele
When looking at ipa's creation of calls to main
(https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01812.html), I discovered this
piece of code in tree-inline.c.
Explicitly calling main is a strange thing to do from anywhere but crt0 (and
ill-formed c++). However, we should probably not consider
c-c++-common/attr-simd-3.c's use of -fcilkplus means it requires pthreads.
nathan
--
Nathan Sidwell - Director, Sourcery Services - Mentor Embedded
2015-12-18 Nathan Sidwell
* c-c++-common/attr-simd-3.c: Requires pthreads.
Index: c-c++-common/attr-simd-3.c
=
Hi all,
Following up from https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01723.html
here is the patch that makes combine canonicalise x + x expressions into x << 1.
This allows for more simplification opportunities, as well as increases the
recognition
opportunities on targets that support combin
Hi,
yesterday I forgot to post here a patch I committed to the HSA branch
which hopefully addresses all of the issues raised in the review:
- kernel_phony flags were turned into bits in gimple subcode, with
the happy consequence that GIMPLE_OMP_TEAMS no longer needs its
own storage layo
On Fri, Dec 18, 2015 at 05:09:14PM +0300, Yuri Rumyantsev wrote:
> James,
>
> We implemented slightly different patch - we restrict number of SET
> instructions for if-conversion through new parameter and add check in
> bb_ok_for_noce_convert_multiple_sets:
>
> + unsigned limit = MIN (ii->branch
Hi Christophe,
On 17/12/15 22:17, Christophe Lyon wrote:
Hi,
Here is an updated version of this patch.
I did test it with
-mthumb/-march=armv8-a/-mfpu=crypto-neon-fp-armv8/-mfloat-abi=hard in
addition to my usual set of options.
Compared to the previous version:
- I added some doc in sourcebui
James,
We implemented slightly different patch - we restrict number of SET
instructions for if-conversion through new parameter and add check in
bb_ok_for_noce_convert_multiple_sets:
+ unsigned limit = MIN (ii->branch_cost,
+ (unsigned) PARAM_VALUE (PARAM_MAX_IF_CONV_SET_INSNS));
..
- if (count
Hi,
a simple issue: we fail to reject such declarations. While working on
it, I noticed a tad of inconsistency in our error messages, where we
have a mix of, eg, "... declared %..." and "... declared
virtual...". I think we should prefer the former and spotted a few
places needing adjustment.
On 18/12/15 13:16, Bernd Schmidt wrote:
On 12/18/2015 02:07 PM, Kyrill Tkachov wrote:
In this PR we have a THEN and an ELSE block where one uses the condition
reg from the preceeding comparison
but the other block has an arithmetic operation that clobbers the CC reg.
ifcvt emits the latter firs
Hi,
PR68920 talks about undesirable if-conversion in the x86 back-end.
The if-conversion cost model simply uses BRANCH_COST (I want to revisit
this for GCC 7), but BRANCH_COST is overloaded in the compiler and reducing
it causes other optimisations to be disabled.
Consequently, to fix the PR we
The following should fix PR68776, a testism with the new mult pattern.
The patch changes pattern recog to print a more specific 'pattern
recognized' and make the two offending testcases scan for what it is
looking.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-12
On 12/18/2015 02:07 PM, Kyrill Tkachov wrote:
In this PR we have a THEN and an ELSE block where one uses the condition
reg from the preceeding comparison
but the other block has an arithmetic operation that clobbers the CC reg.
ifcvt emits the latter first and dead code elimination later sees thi
Hi all,
In this PR we have a THEN and an ELSE block where one uses the condition reg
from the preceeding comparison
but the other block has an arithmetic operation that clobbers the CC reg.
ifcvt emits the latter first and dead code elimination later sees this and
eliminates the first compariso
Here's a revised version of this patch, written to use the
any_mem_operand predicate.
Thanks,
Andrew
--
The use of the arc specific predicate store_update_operand is broken,
this commit fixes the error, switching to use 'any_mem_operand' instead.
Currently store_update_operand is used with matc
* Joern Wolfgang Rennecke [2015-12-17 10:20:44 +]:
> On 16/12/15 00:15, Andrew Burgess wrote:
> >
> > * config/arc/arc.md (*loadqi_update): Use 'memory_operand' and fix
> > RTL pattern to include the plus.
> > (*load_zeroextendqisi_update): Likewise.
> > (*load_signextendqisi_
Hi DJ, Hi Ian,
GCC PR 66827 reports some problems with left shifting a negative
value:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66827
Of the problems reported only two remain - in libiberty/regex.c:
libiberty/regex.c:6970:11: runtime error: left shift of negative value -1
libibert
On Mon, Dec 14, 2015 at 11:49:26AM +, Marcus Shawcroft wrote:
> On 14 December 2015 at 11:01, James Greenhalgh
> wrote:
> > On Wed, Dec 09, 2015 at 01:13:20PM +, Marcus Shawcroft wrote:
> >> On 27 November 2015 at 13:01, James Greenhalgh
> >> wrote:
> >>
> >> > 2015-11-27 James Greenh
Dear All,
This is a rather trivial patch... going on 'obvious' in fact. However,
I must confess to not being entirely sure why the problem is
occurring. Deferred arrays are emanating from the finalizer that are
being presented as ARRAY_TYPES rather than descriptors. What ever is
the reason, the fi
> Hi,
> the alias-2.c testcase fails on targets with anchors. The reason is that
> the variable itself is anchored while the alias is not and they point to the
> same location. I folllowed the docs of SYMBOL_REF claiming that
> SYMBOL_REF_DECL if the symbol is label and tought it is safe to disa
On 12/18/2015 11:21 AM, Dominik Vogt wrote:
> Latest patch for r2 to r4, including a test case.
gcc/ChangeLog
* config/s390/s390.c (s390_init_frame_layout): Try r4 to r2 for the
literal pool pointer.
gcc/testsuite/ChangeLog
* gcc.target/s390/litpool-r3-1.c: New test.
Appl
Latest patch for r2 to r4, including a test case.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
gcc/ChangeLog
* config/s390/s390.c (s390_init_frame_layout): Try r4 to r2 for the
literal pool pointer.
gcc/testsuite/ChangeLog
* gcc.target/s390/litpool-r3-1.c: New te
Hi Richard,
Here is updated patch for middle-end part of the whole patch which
fixes all your remarks I hope.
Regression testing and bootstrapping did not show any new failures.
Is it OK for trunk?
Yuri.
ChangeLog:
2015-12-18 Yuri Rumyantsev
PR middle-end/68542
* fold-const.c (fold_binary_o
On 12/17/2015 10:51 AM, Robin Dapp wrote:
> 2015-12-15 Robin Dapp
>
> * config/s390/predicates.md: Change and rename
> constm1_operand to all_ones_operand
> * config/s390/s390.c (s390_expand_vcond): Use all_ones_operand
> * config/s390/vector.md: Likewise
Applied. Thanks
On 12/15/2015 10:53 AM, Robin Dapp wrote:
> gcc/ChangeLog:
>
> 2015-12-15 Robin Dapp
>
> * config/s390/s390.c (s390_expand_vcond): Convert vector
> conditional into shift.
> * config/s390/vector.md: Change operand predicate.
>
> gcc/testsuite/ChangeLog:
>
> 2015-12-15
Dominik Vogt writes:
> The attached patch fixes the handling of LABEL_REF in genrecog and
> genpreds.
>
> The current code assumes that X can have only a mode than PRED (X,
> MODE) if X is CONST_INT, CONST_DOUBLE or CONST_WIDE_INT, but
> actually that can be also the case for a LABEL_REF with VOID
This is a multi-part message in MIME format.
--2.2.0.1.gd394abb.dirty
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
Hi,
PR68232 is a testsuite failure for targets with very low branch costs.
As the test is looking for if-conversion, it will fai
On 17/12/15 17:24, James Greenhalgh wrote:
On Thu, Dec 17, 2015 at 03:36:40PM +, Kyrill Tkachov wrote:
2015-12-17 Kyrylo Tkachov
PR rtl-optimization/68796
* config/aarch64/aarch64.md (*and3nr_compare0_zextract):
New pattern.
* config/aarch64/aarch64.c (aarch64_select
"Ulrich Weigand" writes:
> Richard Sandiford wrote:
>> "Ulrich Weigand" writes:
>> > The problem is not DImode LABEL_REFs, but rather VOIDmode LABEL_REFs when
>> > matched against a match_operand:DI.
>>
>> It'd be good to fix this in a more direct way though, rather than
>> hack around it. It's
On 17/12/15 11:44, Marcus Shawcroft wrote:
On 10 September 2015 at 12:28, Jiong Wang wrote:
TLS instruction sequences are always with fixed format, there is no need
to use operand modifier, we can hardcode the relocation modifiers into
instruction pattern, all those redundant checks in aarch6
Dear Steve,
Thanks - committed as revision 231807. I will have a poke around to
see if there are any more similar opportunities for infinite recursion
in trans-array.c (structure_alloc_comps). This turned out to be the
most difficult part of the patch for recursive allocatable components
(on hold
Hi,
Here is a trivial patch to fix boolean vector invariants. Bootstrapped and
tested on x86_64-pc-linux-gnu. Applied to trunk.
Thanks,
Ilya
--
gcc/
2015-12-18 Ilya Enkovich
PR tree-optimization/68956
* tree-vect-stmts.c (vect_init_vector): Fix constants
used for b
Hi,
I've committed the attached patch which emits warnings whenever g5 or
g6 are being used explicitely as -march/-mtune parameters. These
machines can only be seen in museums nowadays and have no practical
use anymore. They do not support the z/Architecture mode required for
64 bit. The Linux k
Sorry, yes; proc_ptr_48.f90
! { dg-do run }
!
! Checks the fix for PR68196, comment #8
!
! Contributed by Damian Rouson
!
type Bug ! Failed at trans--array.c:8269
real, allocatable :: scalar
procedure(boogInterface),pointer :: boog
end type
interfa
On 18/12/15 08:57, Richard Biener wrote:
On Thu, 17 Dec 2015, Kyrill Tkachov wrote:
On 14/12/15 15:14, Richard Biener wrote:
The following fixes PR68852 - so I finally needed to sit down and
fix the "build-from-scalars" hack in the SLP vectorizer by pretending
we'd have a sane vectorizer IL.
On Thu, 17 Dec 2015, Kyrill Tkachov wrote:
>
> On 14/12/15 15:14, Richard Biener wrote:
> > The following fixes PR68852 - so I finally needed to sit down and
> > fix the "build-from-scalars" hack in the SLP vectorizer by pretending
> > we'd have a sane vectorizer IL. Basically I now mark the SLP
90 matches
Mail list logo
