On Nov 09 2016, Andrew Pinski wrote:
> Either this patch or the patch for "Handle unary pass-through jump
> functions for ipa-vrp" caused a bootstrap failure on
> aarch64-linux-gnu.
> Bootstrap comparison failure!
> gcc/go/types.o differs
> gcc/fortran/class.o differs
> gcc/tree-ssa-live.o differ
On Wednesday 09 November 2016 08:05 PM, Georg-Johann Lay wrote:
On 09.11.2016 10:14, Pitchumani Sivanupandi wrote:
On Tuesday 08 November 2016 02:57 PM, Georg-Johann Lay wrote:
On 08.11.2016 08:08, Pitchumani Sivanupandi wrote:
I have updated patch to include the flash size as well. Took that
On Wed, Nov 9, 2016 at 9:46 PM, Christophe Lyon
wrote:
> Hi Bin
>
> On 8 November 2016 at 13:37, Bin Cheng wrote:
>> Hi,
>> Test gcc.dg/vect/vect-cond-2.c can be vectorized by GCC now, this patch
>> drops the xfail.
>>
>> Thanks,
>> bin
>>
>> gcc/testsuite/ChangeLog
>> 2016-11-04 Bin Cheng
>>
On Wed, 9 Nov 2016, Christophe Lyon wrote:
> On 9 November 2016 at 09:36, Bin.Cheng wrote:
> > On Tue, Nov 8, 2016 at 9:11 AM, Richard Biener wrote:
> >> On Mon, 7 Nov 2016, Christophe Lyon wrote:
> >>
> >>> Hi Richard,
> >>>
> >>>
> >>> On 7 November 2016 at 09:01, Richard Biener wrote:
> >>>
Ping.
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00040.html
Andrew, do you have any objections to this version?
Thanks,
Kyrill
On 01/11/16 15:21, Kyrill Tkachov wrote:
On 31/10/16 11:54, Kyrill Tkachov wrote:
On 24/10/16 17:15, Andrew Pinski wrote:
On Mon, Oct 24, 2016 at 7:27 AM, Kyrill
On Thu, Nov 10, 2016 at 1:04 AM, Kyrill Tkachov
wrote:
> Ping.
> https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00040.html
>
> Andrew, do you have any objections to this version?
Not really.
Thanks,
Andrew
> Thanks,
> Kyrill
>
> On 01/11/16 15:21, Kyrill Tkachov wrote:
>>
>>
>> On 31/10/16 11:54
Hi Janus,
well, is it really that obvious? It fixes the ICE, correct. But what about
cases where the actual has an explicit interface, but is not a variable? Like
in:
function f()
integer :: f
end function
call sub(f())
! sub() defined as in the pr.
I haven't checked whether that is valid Fo
On 09/11/16 21:29, Christophe Lyon wrote:
> Hi,
>
> PR 78253 shows that the handling of weak references has changed for
> ARM with gcc-5.
>
> When r220674 was committed, default_binds_local_p_2 gained a new
> parameter (weak_dominate), which, when true, implies that a reference
> to a weak symbol
On 04/11/16 15:47, Siddhesh Poyarekar wrote:
> This adds an mcpu option for the upcoming Qualcomm Falkor core. This
> is identical to the qdf24xx part that was added earlier and hence
> retains the same tuning structure and continues to have the a57
> pipeline for now. The part number has also be
On Wed, Nov 9, 2016 at 1:02 PM, Bin.Cheng wrote:
> On Thu, Nov 3, 2016 at 4:00 PM, Bin.Cheng wrote:
>> On Thu, Nov 3, 2016 at 1:35 PM, Evgeny Kudryashov
>> wrote:
>>> Hello,
>>>
>>> I'm facing the following problem related to ivopts. The problem is that GCC
>>> generates a lot of induction vari
On Wed, Nov 9, 2016 at 11:13 PM, Pat Haugen wrote:
> The following fixes a problem introduced by my earlier loop unroller patch,
> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01612.html. In instances where
> the niter expr is not reliable we need to still emit an initial peel copy of
> the lo
Another minor cleanup. We currently have two enumeration types for the
list of CPUs. This patch gets rid of one of them and merges the uses
together.
* arm.h (target_cpus): Delete.
* arm-opts.h (enum processor_type): Prefix entries with TARGET_CPU_.
* arm.c (all_cores):
Hi Jakub,
this patch set is a port of the OpenACC tile clause functionality from the gomp4
branch. The tile clause allows the programmer to specify the tiling of an
OpenACC loop nest.
These patches were mostly implemented by Nathan, with the Fortran
front-end bits by Cesar. I'm just upstreaming th
On Thu, Nov 10, 2016 at 12:05 AM, Segher Boessenkool
wrote:
> On Wed, Nov 09, 2016 at 11:29:45PM +0100, Marc Glisse wrote:
>> >>>This patch makes RTL simplify transform (xor (and (xor A B) C) B) back
>> >>>to (ior (and A C) (and B ~C)) for constant C (and similar with A instead
>> >>>of B for that
This patch contains a few supporting changes that adjusts how
OMP_CLAUSE_TILE is handled. This is in support of the more
elaborate omp-low.c changes in another patch.
Thanks,
Chung-Lin
2016-XX-XX Nathan Sidwell
* tree.h (OMP_CLAUSE_TILE_ITERVAR, OMP_CLAUSE_TILE_COUNT): New.
*
This part is the bulk of the patch set. It consists of
the definition of the GOACC_TILE internal fn, the lowering/expanding
of this in omp-low, as well as loop auto-partitioning adjustments
that help improve generated code.
This patch corresponds to the gomp4 committed patches:
https://gcc.gnu.org
These are the patches for the C/C++ front-ends, along with the
testsuite patches.
Thanks,
Chung-Lin
2016-XX-XX Nathan Sidwell
c/
* c-parser.c (c_parser_omp_clause_collapse): Disallow tile.
(c_parser_oacc_clause_tile): Disallow collapse. Fix parsing and
semantic
Some additional tests and adjustments to existing ones were made.
2016-XX-XX Nathan Sidwell
Chung-Lin Tang
libgomp/
* testsuite/libgomp.oacc-c-c++-common/tile-1.c: New.
* testsuite/libgomp.oacc-c-c++-common/loop-auto-1.c: Adjust and
add additional
The Fortran front-end patches. These were originally written by Cesar.
Thanks,
Chung-Lin
2016-XX-XX Cesar Philippidis
fortran/
* openmp.c (resolve_oacc_positive_int_expr): Promote the warning
to an error.
(resolve_oacc_loop_blocks): Use integer zero to represen
On Thu, Nov 10, 2016 at 6:25 AM, Jim Wilson wrote:
> This fixes a bug in code adding edges to the dependence graph. Values
> for this_dir can be -1 (backward edge), 0 (no edge), 1 (forward edge),
> and 2 (both backward and forward edges). There can be multiple
> dependencies checked, creating mult
On 11/09/2016 02:47 PM, Martin Liška wrote:
> On 11/09/2016 02:29 PM, Jakub Jelinek wrote:
>> On Wed, Nov 09, 2016 at 02:16:45PM +0100, Martin Liška wrote:
>>> As shown in the attached test-case, the assert cannot always be true.
>>> Patch can bootstrap on ppc64le-redhat-linux and survives regressi
Hi,
Please find the revised patch which includes the refurbishing of
mmpy-option option, and a new comment on DEFAULT_arc_fpu_build
define. As for the last suggestion, my proposal is to have a latter
patch on the topic of .cpu, synced with a related binutils patch.
OK to apply?
Claudiu
gcc/
2016
On 11/09/2016 10:02 AM, Richard Biener wrote:
Using scan-assembler-times on the dwarf?
I always have a bad feeling about this kind of check as I imagine it can
break very easily with legit changes. But I have nothing better to
contribute, so I’ve added one such testcase. ;-)
Ok to commit?
On Thu, Nov 10, 2016 at 12:02:45PM +0100, Martin Liška wrote:
> >From fb4b852a17656309e6acfb8da97cf9bce4b3b176 Mon Sep 17 00:00:00 2001
> From: marxin
> Date: Wed, 9 Nov 2016 11:52:00 +0100
> Subject: [PATCH] Create live_switch_vars conditionally (PR sanitizer/78270)
>
> gcc/testsuite/ChangeLog:
On Thu, Nov 03, 2016 at 05:42:51PM +0100, Jakub Jelinek wrote:
> Bootstrapped/regtested on x86_64-linux and i686-linux and Rainer has kindly
> tested it on Solaris, ok for trunk?
>
> 2016-11-03 Jakub Jelinek
>
> * dwarf2out.c (size_of_discr_list): Fix typo in function comment.
>
>
On Thu, 2016-11-03 at 18:39 +0100, Mark Wielaard wrote:
> Adds Rust symbol demangler. Rust mangles symbols using GNU_V3 style,
> adding a hash and various special character subtitutions. This adds
> a new rust style to cplus_demangle and adds 3 helper functions
> rust_demangle, rust_demangle_sym an
On Tue, 8 Nov 2016, Yuri Rumyantsev wrote:
> Richard,
>
> Here is updated 3 patch.
>
> I checked that all new tests related to epilogue vectorization passed with it.
>
> Your comments will be appreciated.
A lot better now. Instead of the ->aux dance I now prefer to
pass the original loops loo
On Thu, 10 Nov 2016, Richard Biener wrote:
> On Tue, 8 Nov 2016, Yuri Rumyantsev wrote:
>
> > Richard,
> >
> > Here is updated 3 patch.
> >
> > I checked that all new tests related to epilogue vectorization passed with
> > it.
> >
> > Your comments will be appreciated.
>
> A lot better now.
On Thu, 2016-10-13 at 18:12 +0200, Pierre-Marie de Rodat wrote:
> Currently, the DWARF description does not specify the signedness of the
> representation of enumeration types. This is a problem in some
> contexts where DWARF consumers need to determine if value X is greater
> than value Y.
>
> F
On Thu, Oct 27, 2016 at 09:36:09AM -0400, Jason Merrill wrote:
> Currently, the way gengtype works it scans the list of source files
> with front end files at the end, and pushes data structures onto a
> stack. It then processes the stack in LIFO order, so that data
> structures from front ends ar
Hello.
Following patch fixes indentation of print_node when printing a constructor
that has some equal elements. Current implementation caches tree to prevent deep
debug outputs. Such behavior is undesired for ctor elements. Apart from that,
I switch to hash_set for a table that is used for tree n
On Tue, Nov 8, 2016 at 5:03 AM, Martin Sebor wrote:
> It's taken me longer than I expected to finally get back to this
> project. Sorry about the delay.
>
> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01110.html
>
> Attached is an updated patch with this enhancement and reflecting
> you previ
PING^2
On 10/31/2016 10:13 AM, Martin Liška wrote:
> PING^1
>
> On 10/13/2016 05:34 PM, Martin Liška wrote:
>> Hello.
>>
>> As it's very hard to guess from GCC driver whether a target supports atomic
>> updates
>> for GCOV counter or not, I decided to come up with a new option value
>> (maybe-a
Kugan
Is there a PR for this failure? It broke bootstrap on AIX as well and
I only was able to track it to your patch last night.
Thanks, David
The following fixes PR71762 via reverting the transforms of
~X & Y to X < Y and similar because when the bools they apply to
are expanded to RTL undefined values are not reliably zero-extended
and thus the transform is invalid. Ensuring the zero-extension
is too costly IMHO and the proper fix is
Hi Andre,
> well, is it really that obvious?
well ... what can I say. If you wanna be strict about it, I guess
there is no such thing as an "obvious patch". There is basically
always something that you can miss, or that can be improved. Mikael's
patch was obvious to me in the sense that it is cle
On 10 November 2016 at 11:05, Richard Earnshaw
wrote:
> On 09/11/16 21:29, Christophe Lyon wrote:
>> Hi,
>>
>> PR 78253 shows that the handling of weak references has changed for
>> ARM with gcc-5.
>>
>> When r220674 was committed, default_binds_local_p_2 gained a new
>> parameter (weak_dominate),
On 10 November 2016 at 09:34, Richard Biener wrote:
> On Wed, 9 Nov 2016, Christophe Lyon wrote:
>
>> On 9 November 2016 at 09:36, Bin.Cheng wrote:
>> > On Tue, Nov 8, 2016 at 9:11 AM, Richard Biener wrote:
>> >> On Mon, 7 Nov 2016, Christophe Lyon wrote:
>> >>
>> >>> Hi Richard,
>> >>>
>> >>>
>
Hi all,
This patch implements the new separate shrink-wrapping hooks for aarch64.
In separate shrink wrapping (as I understand it) we consider each register
save/restore as
a 'component' that can be performed independently of the other save/restores in
the prologue/epilogue
and can be moved out
Hi Dominique.
snip
> I have a last glitch (which can be deferred if needed):
snip
Fixed by the new patch, which is attached. Bootstraps and regtests OK.
OK for trunk?
Paul
2016-11-10 Paul Thomas
PR fortran/44265
* gfortran.h : Add fn_result_spec bitfield to gfc_symb
Hi,
As reported in PR78255 there is currently an issue with indirect sibling
calls in ARM when the address of the sibling call is loaded into 'r3'
and that same register is chosen to align the stack. See the report for
further information.
As I mentioned in the bugzilla ticket I am not sure this
The libstdc++ part of the following patch
[fixincludes, v3] Don't define libstdc++-internal macros in Solaris 10+
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00330.html
has remained unreviewed for a week. Bruce already approved the
fixincludes part.
In the meantime, full tes
I've just noticed that tree-ssa-dse wrongly prints a new line to dump file.
For the next stage1, I'll go through usages of print_gimple_stmt and remove
extra new lines like:
gcc/auto-profile.c: print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM);
gcc/auto-profile.c- fprintf (dump_file, "\n"
Hello,
Sorry for top-posting, but this is a ping for the attached patch.
The patch doesn't seem to have been applied nor refused. So I'm
pinging to see if I need to change something? I already have a
copyright assignment now.
I'm attaching a updated patch that doesn't conflict in the Changelog
f
On 11/10/2016 05:19 AM, Martin Liška wrote:
On 10/13/2016 05:34 PM, Martin Liška wrote:
Hello.
As it's very hard to guess from GCC driver whether a target supports atomic
updates
for GCOV counter or not, I decided to come up with a new option value
(maybe-atomic),
that would be transformed i
On Thu, Nov 10, 2016 at 1:39 PM, Felipe Magno de Almeida
wrote:
> Hello,
>
> Sorry for top-posting, but this is a ping for the attached patch.
>
> The patch doesn't seem to have been applied nor refused. So I'm
> pinging to see if I need to change something? I already have a
> copyright assignment
On Thu, Nov 10, 2016 at 10:43 AM, Nathan Sidwell wrote:
> On 11/10/2016 05:19 AM, Martin Liška wrote:
>
>>> On 10/13/2016 05:34 PM, Martin Liška wrote:
Hello.
As it's very hard to guess from GCC driver whether a target supports
atomic updates
for GCOV counter or not,
On Wed, Nov 09, 2016 at 10:16:35PM +, Joseph Myers wrote:
> On Wed, 9 Nov 2016, Bernd Edlinger wrote:
>
> > Yes, but maybe introduce a test if the half-wide value fits?
> >
> > like:
> >
> > #define M_OK2(M, T) ((M) > sizeof(T) * CHAR_BIT / 2 - 1)
>
> Something like that.
In patch form, that
On 11/10/2016 04:43 PM, Nathan Sidwell wrote:
> On 11/10/2016 05:19 AM, Martin Liška wrote:
>
>>> On 10/13/2016 05:34 PM, Martin Liška wrote:
Hello.
As it's very hard to guess from GCC driver whether a target supports
atomic updates
for GCOV counter or not, I decided to c
Hi Mike,
> I have built the spec 2006 CPU benchmark suite with these changes, and the
> power8 (ISA 2.07) code generation does not change.
Very good to hear :-)
Just some nits; okay for trunk with that fixed:
> +(define_split
> + [(set (match_operand:EXTHI 0 "altivec_register_operand" "")
> +
On 11/10/2016 07:43 AM, Nathan Sidwell wrote:
On 11/10/2016 05:19 AM, Martin Liška wrote:
On 10/13/2016 05:34 PM, Martin Liška wrote:
Hello.
As it's very hard to guess from GCC driver whether a target supports
atomic updates
for GCOV counter or not, I decided to come up with a new option
valu
On Thu, Nov 10, 2016 at 11:14 AM, Nathan Sidwell wrote:
> On 11/10/2016 07:43 AM, Nathan Sidwell wrote:
>>
>> On 11/10/2016 05:19 AM, Martin Liška wrote:
>>
On 10/13/2016 05:34 PM, Martin Liška wrote:
>
> Hello.
>
> As it's very hard to guess from GCC driver whether a target s
On 11/10/2016 07:55 AM, David Edelsohn wrote:
gcc.c now imposes profile-update=atomic if -pthread is used, even if
the target does not support profile-update=atomic.
ah, that's where this is coming from.
nathan
--
Nathan Sidwell
On 11/10/2016 05:17 PM, David Edelsohn wrote:
> Maybe instead of adding "maybe", we need to change the severity of the
> warning so that the warning is not emitted by default.
Adding the warning option to -Wextra can be solution. Is it acceptable
approach?
Martin
Hi!
Great to see this. Just a few comments...
On Thu, Nov 10, 2016 at 02:25:47PM +, Kyrill Tkachov wrote:
> +/* Implement TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS. */
> +
> +static sbitmap
> +aarch64_get_separate_components (void)
> +{
> + /* Calls to alloca further extend the stack fram
Hi,
this patch enabled AVX512_4FMAPS and AVX512_4VNNIW instructions.
It requires additional patch for register allocator from Vladimir
Makarov to be committed before.
gcc/
* common/config/i386/i386-common.c
(OPTION_MASK_ISA_AVX5124FMAPS_SET,
OPTION_MASK_ISA_AVX5124FMAPS_U
On Thu, Nov 10, 2016 at 07:27:00PM +0300, Andrew Senkevich wrote:
> Hi,
>
> this patch enabled AVX512_4FMAPS and AVX512_4VNNIW instructions.
>
> It requires additional patch for register allocator from Vladimir
> Makarov to be committed before.
Your MUA ate tabs (and in the ChangeLog you're usin
On Thu, Nov 10, 2016 at 10:58 AM, Martin Liška wrote:
> On 11/10/2016 04:43 PM, Nathan Sidwell wrote:
>> On 11/10/2016 05:19 AM, Martin Liška wrote:
>>
On 10/13/2016 05:34 PM, Martin Liška wrote:
> Hello.
>
> As it's very hard to guess from GCC driver whether a target supports
>>
On 10/11/16 16:26, Segher Boessenkool wrote:
Hi!
Hi,
Great to see this. Just a few comments...
On Thu, Nov 10, 2016 at 02:25:47PM +, Kyrill Tkachov wrote:
+/* Implement TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS. */
+
+static sbitmap
+aarch64_get_separate_components (void)
+{
+ /* C
On Thu, 10 Nov 2016, James Greenhalgh wrote:
>
> On Wed, Nov 09, 2016 at 10:16:35PM +, Joseph Myers wrote:
> > On Wed, 9 Nov 2016, Bernd Edlinger wrote:
> >
> > > Yes, but maybe introduce a test if the half-wide value fits?
> > >
> > > like:
> > >
> > > #define M_OK2(M, T) ((M) > sizeof(T) *
Hi!
It seems -Wabi/-Wc++1z-compat warns about mangling changes even for symbols
that are
not visible outside of its TU (so likely only inline asm or tools
looking at .symtab STB_LOCAL symbols would notice). Perhaps that is fine
for -Wabi that isn't enabled in -Wall/-Wextra, but -Wc++1z-compat is
OK.
On Thu, Nov 10, 2016 at 8:52 AM, Jakub Jelinek wrote:
> Hi!
>
> It seems -Wabi/-Wc++1z-compat warns about mangling changes even for symbols
> that are
> not visible outside of its TU (so likely only inline asm or tools
> looking at .symtab STB_LOCAL symbols would notice). Perhaps that is fi
Hi!
On arm/aarch64 we ICE because some decls that make it here has non-NULL
DECL_SIZE, which is a VAR_DECL rather than CONST_INT (or DECL_SIZE that
doesn't fit into shwi would ICE similarly). While it is arguably a FE bug
that it creates for VLA initialization from STRING_CST such a decl,
I belie
Hi!
I think it is better to announce 4.5 than 4.0 at the current state.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2016-11-10 Jakub Jelinek
gcc/fortran/
* cpp.c (cpp_define_builtins): Define _OPENMP to 201511 instead
of 201307.
* gfortr
The existing vector costs stop some beneficial vectorization. This is mostly
due
to vector statement cost being set to 3 as well as vector loads having a higher
cost than scalar loads. This means that even when we vectorize 4x, it is
possible
that the cost of a vectorized loop is similar to the
Hello,
I'd like to provide an overview of the gomp-nvptx branch status. In response to
this message I'll send two more emails, with libgomp and middle-end changes on
the branch. Some of the changes to libgomp such as build machinery adaptations
have already received substantial comments in 2015,
Currently the SBFM, UBFM and BFM instructions all use the attribute "bfm".
SBFM and UBFM include all shifts on AArch64, which are simpler than bitfield
insert. Add a new bfx attribute for these instructions so that they can be
modelled more accurately in the future. There is no difference in code
Hi, the following patch is necessary for generation of new Intel insns
requiring 4 aligned zmm regs.
Committed as rev. 242043.
Index: ChangeLog
===
--- ChangeLog (revision 242040)
+++ ChangeLog (working copy)
@@ -1,3 +1,12 @@
+2016
libgomp/
* Makefile.am (libgomp_la_SOURCES): Add atomic.c, icv.c, icv-device.c.
* Makefile.in. Regenerate.
* configure.ac [nvptx*-*-*] (libgomp_use_pthreads): Set and use it...
(LIBGOMP_USE_PTHREADS): ...here; new define.
* configure: Regenerate.
* c
gcc/
* internal-fn.c (expand_GOMP_SIMT_LANE): New.
(expand_GOMP_SIMT_VF): New.
(expand_GOMP_SIMT_LAST_LANE): New.
(expand_GOMP_SIMT_ORDERED_PRED): New.
(expand_GOMP_SIMT_VOTE_ANY): New.
(expand_GOMP_SIMT_XCHG_BFLY): New.
(expand_GOMP_SIMT_XCHG
On 11/10/2016 11:27 AM, Andrew Senkevich wrote:
Hi,
this patch enabled AVX512_4FMAPS and AVX512_4VNNIW instructions.
It requires additional patch for register allocator from Vladimir
Makarov to be committed before.
I've just committed the necessary patch.
The second patch updates the Cortex-A57 scheduler now that we can differentiate
between shifts and bitfield inserts. The Cortex-A57 Software Optimization Guide
indicates that BFM operations use the integer multi-cycle pipeline, while ARM
UXTB/H instructions use the Integer 1 or Integer 0 pipelines
Improve TI mode address offsets - these may either use LDP of 64-bit or
LDR of 128-bit, so we need to use the correct intersection of offsets.
When splitting a large offset into base and offset, use a signed 9-bit
unscaled offset.
Remove the Ump constraint on movti and movtf instructions as this
> On 10 Nov 2016, at 18:14, Wilco Dijkstra wrote:
>
> I think the XGene-1 scheduler might need a similar change as currently all
> AArch64
> shifts are modelled as 2-cycle operations.
Thanks for the heads-up. We’ll indeed need to update this.
Regards,
Philipp.
2016-11-10 19:36 GMT+03:00 Jakub Jelinek :
> On Thu, Nov 10, 2016 at 07:27:00PM +0300, Andrew Senkevich wrote:
>> Hi,
>>
>> this patch enabled AVX512_4FMAPS and AVX512_4VNNIW instructions.
>>
>> It requires additional patch for register allocator from Vladimir
>> Makarov to be committed before.
>
>
2016-11-10 20:14 GMT+03:00 Vladimir N Makarov :
>
>
> On 11/10/2016 11:27 AM, Andrew Senkevich wrote:
>>
>> Hi,
>>
>> this patch enabled AVX512_4FMAPS and AVX512_4VNNIW instructions.
>>
>> It requires additional patch for register allocator from Vladimir
>> Makarov to be committed before.
>>
>>
> I
Improve the logic when setting max_insns_skipped. Limit the maximum size of IT
to MAX_INSN_PER_IT_BLOCK as otherwise multiple IT instructions are needed,
increasing codesize. Given 4 works well for Thumb-2, use the same limit for ARM
for consistency.
ChangeLog:
2016-11-04 Wilco Dijkstra
Ping.
On Mon, Oct 31, 2016 at 05:15:53PM +, Segher Boessenkool wrote:
> If maybe_record_trace_start fails because the CFI is inconsistent on two
> paths into a block it currently just ICEs. This changes it to also dump
> the CFI on those two paths in the dump file; debugging it without that
>
On 11/10/2016 08:24 AM, Martin Liška wrote:
On 11/10/2016 05:17 PM, David Edelsohn wrote:
Maybe instead of adding "maybe", we need to change the severity of the
warning so that the warning is not emitted by default.
Adding the warning option to -Wextra can be solution. Is it acceptable
approac
On Thu, Nov 10, 2016 at 11:29:12AM -0600, Segher Boessenkool wrote:
> Ping.
>
> On Mon, Oct 31, 2016 at 05:15:53PM +, Segher Boessenkool wrote:
> > If maybe_record_trace_start fails because the CFI is inconsistent on two
> > paths into a block it currently just ICEs. This changes it to also d
On Fri, 28 Oct 2016, Richard Biener wrote:
> +/* Parse a gimple expression.
> +
> + gimple-expression:
> + gimple-unary-expression
> + gimple-call-statement
> + gimple-binary-expression
> + gimple-assign-expression
> + gimple-cast-expression
I don't see any comments expandin
OpenACC 2.0a has limited support for fortran derived types. Basically,
derived type variables are only supported in ACC UPDATE. Rather than
adding generalized support for derived times in the gimplifier, this
patch has the fortran FE pass both subarrays and arrays as void pointers
with an appropria
On Thu, Nov 10, 2016 at 10:05:25AM -0600, Segher Boessenkool wrote:
> Hi Mike,
>
> > I have built the spec 2006 CPU benchmark suite with these changes, and the
> > power8 (ISA 2.07) code generation does not change.
>
> Very good to hear :-)
>
> Just some nits; okay for trunk with that fixed:
>
This patch is for a long-standing issue with the way -fno-common is
documented. The specific bug report was about an ambiguous use of the
word "This", but as I looked more at the way this option was described,
I realized the whole thing was needlessly confusing because it didn't
use the correc
On Thu, 10 Nov 2016, Sandra Loosemore wrote:
> This patch is for a long-standing issue with the way -fno-common is
> documented. The specific bug report was about an ambiguous use of the word
> "This", but as I looked more at the way this option was described, I realized
> the whole thing was nee
Hi,
This patch documents the newly added flag in gcc 7 for the upcoming
Qualcomm Falkor processor core.
Siddhesh
Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.24
di
On Thu, 10 Nov 2016, Richard Biener wrote:
The following fixes PR71762 via reverting the transforms of
~X & Y to X < Y and similar because when the bools they apply to
are expanded to RTL undefined values are not reliably zero-extended
and thus the transform is invalid. Ensuring the zero-extens
On November 10, 2016 7:39:57 PM GMT+01:00, Marc Glisse
wrote:
>On Thu, 10 Nov 2016, Richard Biener wrote:
>
>> The following fixes PR71762 via reverting the transforms of
>> ~X & Y to X < Y and similar because when the bools they apply to
>> are expanded to RTL undefined values are not reliably z
On November 10, 2016 6:38:12 PM GMT+01:00, Joseph Myers
wrote:
>On Fri, 28 Oct 2016, Richard Biener wrote:
>
>> +/* Parse a gimple expression.
>> +
>> + gimple-expression:
>> + gimple-unary-expression
>> + gimple-call-statement
>> + gimple-binary-expression
>> + gimple-assign-ex
All,
The attached fixes an ICE-on-invalid-code, specifically due to invalid
anonymous structure declarations, as seen in the attached test case.
This also improves error handling in such cases- the anonymous
structure body will continue to be parsed even if the variable-decl
after the opening vari
Hi David,
Sorry about the breakage. I have already reverted this patch as this is
causing bootstrap failures. I will test it on more targets before
submitting this patch again.
Thanks,
Kugan
On 11/11/16 00:25, David Edelsohn wrote:
Kugan
Is there a PR for this failure? It broke bootstrap
Hi,
On 10 November 2016 at 18:00, Jakub Jelinek wrote:
> Hi!
>
> On arm/aarch64 we ICE because some decls that make it here has non-NULL
> DECL_SIZE, which is a VAR_DECL rather than CONST_INT (or DECL_SIZE that
> doesn't fit into shwi would ICE similarly). While it is arguably a FE bug
> that it
I've committed this patch to gomp-4_0-branch which removes
OMP_CLAUSE_DEVICE_RESIDENT. This standalone clause is no longer
necessary, and hasn't been for a while, because device_resident is
treated as a data mapping type for OMP_CLAUSE_MAP, and not a clause itself.
Cesar
2016-11-10 Cesar Philippi
On Wed, Nov 09, 2016 at 03:46:38PM +0100, Richard Biener wrote:
> On Wed, Nov 9, 2016 at 3:30 PM, Dominik Vogt wrote:
> > Something like the attached patch? Robin and me have spent quite
> > some time to figure out the new pattern. Two questions:
> >
> > 1) In the match expression you cannot jus
On Tue, Oct 18, 2016 at 1:06 AM, Uros Bizjak wrote:
>
>> This patch copies the code that implements the print and println
>> predeclared functions from the Go 1.7 runtime. The compiler is
>> changed to use the new names, and to call the printlock and
>> printunlock functions around a sequence of
On 11/09/2016 03:40 AM, Andreas Schwab wrote:
As seen by the testcase in PR77822, combine can generate out-of-range
bit pos in a bit-field insn, unless the pattern explicitly rejects it.
This only makes a difference for expressions that are undefined at
runtime. Without that we would either gene
On Nov 10 2016, Jeff Law wrote:
> On 11/09/2016 03:40 AM, Andreas Schwab wrote:
>> As seen by the testcase in PR77822, combine can generate out-of-range
>> bit pos in a bit-field insn, unless the pattern explicitly rejects it.
>> This only makes a difference for expressions that are undefined at
The constexpr lambda change introduced some problematic dependency
ordering, since instantiate constexpr functions aggressively so that
they are available for constexpr evaluation. The patch for 65942
delayed that instantiation by triggering it from constexpr evaluation
directly rather than earlie
On Thu, 10 Nov 2016, Richard Biener wrote:
> I'll address those comments. As you did not have any comments on the
> c-parser.[CH] parts does that mean you are fine with them? That is,
> does the above constitute a complete review of the patch?
I am fine with the c-parser.[ch] parts.
--
Jose
On Thu, Nov 10, 2016 at 01:42:20PM -0800, Jason Merrill wrote:
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp1y/auto-fn33.C
> @@ -0,0 +1,27 @@
> +// PR c++/77337
> +// { dg-do compile { target c++14 } }
> +
> +template
> +struct fix_type {
> + Functor functor;
> +
> + decltype(auto) operator()(
1 - 100 of 116 matches
Mail list logo
