On Fri, 21 Oct 2016, Richard Biener wrote:
>
> This is the main part of the early LTO debug support. The main parts
> of the changes are to dwarf2out.c where most of the changes are related
> to the fact that we eventually have to output debug info twice, once
> for the early LTO part and once f
On Thu, Nov 10, 2016 at 08:12:27PM +0300, Alexander Monakov wrote:
> 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.
>
On Thu, Nov 10, 2016 at 08:11:45PM +0300, Alexander Monakov wrote:
> 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_PTHRE
On Thu, Nov 10, 2016 at 08:09:51PM +0300, Alexander Monakov wrote:
> 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 machin
> > * affinity.c: ...here (new file). Guard use of PThreads-specific
>
> Never seen pthreads capitalized this way, use pthreads or Pthreads
> or POSIX Threads.
Right, sorry, not sure where I got that. Will use 'Pthreads'.
> > +void
> > +gomp_barrier_wait_last (gomp_barrier_t *bar)
> > +{
>
On Fri, Nov 11, 2016 at 11:43:06AM +0300, Alexander Monakov wrote:
> > > +void
> > > +gomp_barrier_wait_last (gomp_barrier_t *bar)
> > > +{
> > > +#if 0
> > > + gomp_barrier_state_t state = gomp_barrier_wait_start (bar);
> > > + if (state & BAR_WAS_LAST)
> > > +gomp_barrier_wait_end (bar, sta
On Fri, 11 Nov 2016, Jakub Jelinek wrote:
[...]
> the intended outlining of SIMT regions for PTX offloading done (IMHO the
> best place to do that is in omp expansion, not gimplification)
Sorry, I couldn't find a good way to implement that during omp expansion. The
reason I went for gimplificatio
On Thu, 10 Nov 2016, Christophe Lyon wrote:
> 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, Christ
On Thu, Nov 10, 2016 at 06:17:57PM -0600, Segher Boessenkool wrote:
> On Fri, Nov 11, 2016 at 12:47:02AM +0100, Dominik Vogt wrote:
> > On Thu, Nov 03, 2016 at 11:40:44AM +0100, Dominik Vogt wrote:
> > > The attached patch fixes the stack layout problems on AIX and
> > > Power as described here:
>
On 11/08/2016 03:38 PM, Dominik Vogt wrote:
> The attached patch fixes PR/77822 on s390/s390x dor gcc-6 *only*.
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822
>
> Bootstrapped and regression tested on s390 and s390x biarch on a
> zEC12.
>
> For gcc-7, there will be a different patch.
A
On Mon, Jun 20, 2016 at 02:41:21PM +0100, Dominik Vogt wrote:
> Patch:
> https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01587.html
>
> On Wed, Jan 27, 2016 at 10:39:44AM +0100, Dominik Vogt wrote:
> > g++.dg/tls/thread_local-order2.C no longer fail with Glibc-2.18 or
> > newer since this commit:
>
On Fri, Nov 11, 2016 at 11:52:58AM +0300, Alexander Monakov wrote:
> On Fri, 11 Nov 2016, Jakub Jelinek wrote:
> [...]
> > the intended outlining of SIMT regions for PTX offloading done (IMHO the
> > best place to do that is in omp expansion, not gimplification)
>
> Sorry, I couldn't find a good w
On Fri, 11 Nov 2016, Jakub Jelinek wrote:
> On Fri, Nov 11, 2016 at 11:52:58AM +0300, Alexander Monakov wrote:
> > On Fri, 11 Nov 2016, Jakub Jelinek wrote:
> > [...]
> > > the intended outlining of SIMT regions for PTX offloading done (IMHO the
> > > best place to do that is in omp expansion, not
On Fri, Nov 11, 2016 at 12:11:49AM -0500, David Edelsohn wrote:
> On Thu, Nov 10, 2016 at 6:47 PM, Dominik Vogt wrote:
> > On Thu, Nov 03, 2016 at 11:40:44AM +0100, Dominik Vogt wrote:
> >> The attached patch fixes the stack layout problems on AIX and
> >> Power as described here:
> >>
> >> http
Hi,
Test gcc.dg/vect/vect-cond-2.c still requires vect_max_reduc to be vectorized,
this patch adds the requirement.
Thanks,
bin
gcc/testsuite/ChangeLog
2016-11-09 Bin Cheng
* gcc.dg/vect/vect-cond-2.c: Only drop xfail for targets supporting
vect_max_reduc.diff --git a/gcc/tes
On 11.11.2016 09:58, Andreas Krebbel wrote:
> On 11/08/2016 03:38 PM, Dominik Vogt wrote:
>> The attached patch fixes PR/77822 on s390/s390x dor gcc-6 *only*.
>> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822
>>
>> Bootstrapped and regression tested on s390 and s390x biarch on a
>> zEC12.
>
Hi!
On Thu, Nov 10, 2016 at 06:44:52PM +0800, Chung-Lin Tang wrote:
Above this it is fine.
> @@ -9388,10 +9373,23 @@ gimplify_omp_for (tree *expr_p, gimple_seq *pre_p)
>(OMP_FOR_INIT (for_stmt))
> * 2);
On Thu, Nov 10, 2016 at 06:45:10PM +0800, Chung-Lin Tang wrote:
> 2016-XX-XX Nathan Sidwell
>
> * internal-fn.def (GOACC_DIM_POS): Comment may be overly conservative.
> (GOACC_TILE): New.
> * internal-fn.c (expand_GOACC_TILE): New.
>
> * omp-low.c (struct omp_fo
Hi Bruce,
> On 11/03/16 07:11, Rainer Orth wrote:
>>
>> Ok for mainline now, and for backports to the gcc-6 and gcc-5 branches
>> after some soak time?
>
> Yes, please. Thanks.
unfortunately, I didn't look closly enough when checking for failures.
There is one which I thought was preexisting:
m
On Fri, Nov 11, 2016 at 12:28:16PM +0300, Alexander Monakov wrote:
> On Fri, 11 Nov 2016, Jakub Jelinek wrote:
>
> > On Fri, Nov 11, 2016 at 11:52:58AM +0300, Alexander Monakov wrote:
> > > On Fri, 11 Nov 2016, Jakub Jelinek wrote:
> > > [...]
> > > > the intended outlining of SIMT regions for PTX
On 11/11/16 02:56, Andrew Pinski wrote:
> As I mentioned in my other emails, parsing /proc/cpuinfo has one issue
> is that the current parsing assumes many different things about the
> format. So the best way to do this is to parse
> /sys/devices/system/cpu/cpuN/regs/identification/midr_el1 files
On 10/11/16 23:28, Gerald Pfeifer wrote:
> On Fri, 11 Nov 2016, Siddhesh Poyarekar wrote:
>> This patch documents the newly added flag in gcc 7 for the upcoming
>> Qualcomm Falkor processor core.
>
> Looks good to me. Probably a good idea for one of the ARM maintainers
> to sign off, too.
>
> Ge
Since the recent libsanitizer import, macOS 10.12 bootstrap is broken:
* unconditionally uses the Blocks extension only support by
Clang without the customary #if __BLOCKS__ guard:
In file included from
/vol/gcc/src/hg/trunk/local/libsanitizer/sanitizer_common/sanitizer_mac.cc:39:0:
/usr/incl
On 10/11/16 17:10, Wilco Dijkstra wrote:
> 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
> possibl
On 10/11/16 23:39, Segher Boessenkool wrote:
On Thu, Nov 10, 2016 at 02:42:24PM -0800, Andrew Pinski wrote:
On Thu, Nov 10, 2016 at 6:25 AM, Kyrill Tkachov
I ran SPEC2006 on a Cortex-A72. Overall scores were neutral but there were
some interesting swings.
458.sjeng +1.45%
471.omnetpp +2.
On 10/11/16 17:11, Wilco Dijkstra wrote:
> 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 accurate
Hi,
Sorry for a very late reply as the mail was missed or overlooked.
>> could now move the test tree_expr_nonzero_p next to
>> tree_expr_nonnegative_p (it is redundant for the last case).
Done.
>> Often just a comment can really help here.
Comments updated as per the suggestion
>> when
On 10/11/16 17:14, Wilco Dijkstra wrote:
> 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/
On 10/11/16 17:16, Wilco Dijkstra wrote:
> 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 Um
On 10/11/16 14:54, Andre Vieira (lists) wrote:
> 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
On Thu, Nov 10, 2016 at 06:46:16PM +0800, Chung-Lin Tang wrote:
> 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 checking.
> * c-p
On 10/11/16 17:19, Wilco Dijkstra wrote:
> 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.
>
You don't provide any information about what benefits this brings.
On Thu, Nov 10, 2016 at 06:46:46PM +0800, Chung-Lin Tang wrote:
>
> 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 rep
Hi,
This small patch series addresses an issue uncovered by a recent binutils
master branch update, scheduled for the upcoming 2.28 release, where we
fail to annotate stray code labels -- generally produced for code marked
as unreachable -- that have no instruction following, with the `.insn'
On Thu, Nov 10, 2016 at 06:47:07PM +0800, Chung-Lin Tang wrote:
> 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
Add an assembly snippet for `mips_option_tests' to verify that the
target board can indeed run microMIPS code, support for which is
optional in the MIPS architecture.
Unlike with the `-mips16' option test for the MIPS16 ASE do not rely on
a function attribute to switch to the regular MIPS mode
Add an assembly snippet for `mips_option_tests' to verify that
instructions executed on the target board may freely access executable
sections.
Depending on target board's execution environment, which may map
executable pages with the Read Inhibit (RI) bit set in the TLB or may
have a split SP
On 11/11/2016 10:42 AM, Matthias Klose wrote:
> On 11.11.2016 09:58, Andreas Krebbel wrote:
>> On 11/08/2016 03:38 PM, Dominik Vogt wrote:
>>> The attached patch fixes PR/77822 on s390/s390x dor gcc-6 *only*.
>>> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822
>>>
>>> Bootstrapped and regres
Mark trailing labels, either at the end of a function or preceding a
MIPS16 constant pool, with the `.insn' assembly pseudo-op so that they
are considered code rather than data labels and consequently have ISA
annotation added in the symbol table by the assembler.
Such labels are created for some
On 11/10/2016 06:31 PM, Nathan Sidwell wrote:
> 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
Ramana Radhakrishnan wrote:
> On Thu, Nov 3, 2016 at 12:20 PM, Wilco Dijkstra
> wrote:
> HOST_WIDE_INT val = INTVAL (index);
> - /* ??? Can we assume ldrd for thumb2? */
> - /* Thumb-2 ldrd only has reg+const addressing modes. */
> - /* ldrd supports offsets o
On Mon, Nov 07, 2016 at 09:29:26PM +0100, Bernd Schmidt wrote:
> On 10/31/2016 08:56 PM, Dominik Vogt wrote:
>
> >combine_simplify_rtx() tries to replace rtx expressions with just two
> >possible values with an experession that uses if_then_else:
> >
> > (if_then_else (condition) (value1) (value2
Richard,
I prepare updated 3 patch with passing additional argument to
vect_analyze_loop as you proposed (untested).
You wrote:
tw, I wonder if you can produce a single patch containing just
epilogue vectorization, that is combine patches 1-3 but rip out
changes only needed by later patches?
Did
On Thu, Nov 10, 2016 at 6:18 PM, Andrew Senkevich
wrote:
> 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 regis
On Nov 11, 2016, at 2:15 AM, Rainer Orth wrote:
> The patch passes fixincludes make check (this time for real ;-) and
> restores macOS 10.12 bootstrap.
No objections from me.
Hi!
I've noticed preexisting:
On Thu, Nov 10, 2016 at 07:27:00PM +0300, Andrew Senkevich wrote:
> --- a/gcc/config/i386/i386-modes.def
> +++ b/gcc/config/i386/i386-modes.def
> @@ -84,6 +84,7 @@ VECTOR_MODES (FLOAT, 16); /* V8HF V4SF V2DF */
> VECTOR_MODES (FLOAT, 32); /*
Hi Janus,
sorry, when I stepped on your toes. That was not my intention. While looking at
your patch and its environment those thoughts came to me. Good that you could
destroy my doubts. Thank you very much.
> In fact I have not thought about any further cases. Since you're not
> giving full exam
Richard Earnshaw wrote:
> On 10/11/16 17:19, Wilco Dijkstra wrote:
> > 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.
>
> You don't provide any information
On 09/11/16 14:53, Andre Vieira (lists) wrote:
On 27/10/16 11:01, Andre Vieira (lists) wrote:
On 25/10/16 17:30, Andre Vieira (lists) wrote:
On 24/08/16 12:01, Andre Vieira (lists) wrote:
On 25/07/16 14:26, Andre Vieira (lists) wrote:
This patch extends support for the ARMv8-M Security Exten
On Thu, 10 Nov 2016, 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-expression
> > +
On Thu, Nov 10, 2016 at 4:36 PM, Martin Liška wrote:
> 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,
Hi!
The following testcase fails to link, because in one TU
(pr77285-2.C) we first mangle the TLS symbols and only afterwards
the TLS wrapper fn symbol (and don't emit TLS init fn symbol at all,
as there are no uses of the TLS var), while in the other TU
we first mangle TLS init and TLS wrapper sy
The following fixes a graphite ICE because of a bogus assert.
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2016-11-11 Richard Biener
PR tree-optimization/71575
* graphite-isl-ast-to-gimple.c (copy_cond_phi_nodes): Remove
bogus assert.
The following fixes an unwanted uninit warning.
Bootstrapped and tested on x86_64-unknown-linxu-gnu, applied.
Richard.
2016-11-11 Richard Biener
PR middle-end/78295
* tree-ssa-uninit.c (warn_uninitialized_vars): Do not warn
about uninitialized destination arg of BIT_
Hi Andre,
> sorry, when I stepped on your toes. That was not my intention.
well, I kind of got the impression that me committing 'obvious'
patches was somehow getting in conflict with _your_ toes (though I
don't quite understand why). I care as much about the quality of
gfortran as you do, trust
On 10/19/2016 12:39 PM, Bernd Schmidt wrote:
I'll refrain from any further comments on the topic. The ptx patches
don't look unreasonable iff someone else decides that this version of
OpenMP support should be merged and I'll look into them in more detail
if that happens. Patch 2/8 is ok now.
So
Richard Earnshaw wrote:
> Has this patch been truncated? The last line above looks to be part-way
> through a hunk.
Oops sorry, it seems the last few lines are missing. Here is the full version:
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index
3045e6d6447d5c1860fe
Hi all,
here is another rather simple patch for an ice-on-invalid problem. The
patch consists of three hunks, out of which the last two actually fix
two ICEs that occurred on the different test cases: The second one
removes an assert which seems unnecessary to me (since there are
anyway other case
It's OK to pass const pointers to __builtin_object_size(),
correct the documentation.
Signed-off-by: Jakub Kicinski
---
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 0669f7999beb..4378ab84b5d8 100644
--- a/
Hi!
This PR has been fixed by r240148. I've checked in the testcase as obvious,
so we can close it.
2016-11-11 Jakub Jelinek
PR c++/72774
* g++.dg/parse/pr72774.C: New test.
--- gcc/testsuite/g++.dg/parse/pr72774.C.jj 2016-11-11 14:37:39.073659504
+0100
+++ gcc/testsuit
On Fri, Nov 11, 2016 at 10:36 AM, Bin Cheng wrote:
> Hi,
> Test gcc.dg/vect/vect-cond-2.c still requires vect_max_reduc to be
> vectorized, this patch adds the requirement.
Ok.
Richard.
> Thanks,
> bin
>
> gcc/testsuite/ChangeLog
> 2016-11-09 Bin Cheng
>
> * gcc.dg/vect/vect-cond-2.
Hello.
Due to a stupid mistake I did, following patch is needed for the test-case
to properly save previous gimplify_ctxp->live_switch_vars.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
I was able to run asan bootstrap on x86_64-linux-gnu and kernel build with
allyes
Hello.
I spent quite time during this stage1 playing with predictors and we found
with Honza multiple situations where a prediction was oddly calculated.
Thus, we're suggesting to enhance default dump format to show BB frequencies
and edge probabilities, as follows:
main (int a)
{
int _1;
[
Hi Ian,
> This patch to the Go frontend and libgo copies the signal code from
> the Go 1.7 runtime.
>
> This adds a little shell script to auto-generate runtime.sigtable from
> the known signal names.
>
> This forces the main package to always import the runtime package.
> Otherwise some runtime p
2016-11-11 14:38 GMT+01:00 Janus Weil :
> [Btw, speaking of gfc_get_tbp_symtree: Can anyone tell me by chance
> why it is necessary to nullify 'result->n.tb' on a newly-created
> symtree?]
Removing the corresponding line does not do any harm to the testsuite,
as I just verified:
Index: gcc/fortra
Richard,
Sorry for confusion but my updated patch does not work properly, so I
need to fix it.
Yuri.
2016-11-11 14:15 GMT+03:00 Yuri Rumyantsev :
> Richard,
>
> I prepare updated 3 patch with passing additional argument to
> vect_analyze_loop as you proposed (untested).
>
> You wrote:
> tw, I w
On 09/11/16 21:46, Segher Boessenkool wrote:
This patch changes spread_components to use a simpler algorithm that
puts prologue components as early as possible, and epilogue components
as late as possible. This allows better scheduling, and also saves a
bit of code size. The blocks that run wi
Ping...
the latest version of the patch was here:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00505.html
Thanks
Bernd.
On 11/02/16 22:15, Bernd Edlinger wrote:
> On 11/02/16 18:51, Jason Merrill wrote:
>> On 11/02/2016 02:11 AM, Bernd Edlinger wrote:
>>> On 11/01/16 19:15, Bernd Edlinger wrote
Hello.
Motivation for the patch is to dump IPA clones that were created
by all inter-procedural optimizations. Usage of such input is to track
set of functions where a code from another function can eventually occur.
Usage of the dump file can be seen here: [1].
Patch can bootstrap on ppc64le-red
Some quick remarks:
+(define_insn "kmovb"
+ [(set (match_operand:QI 0 "nonimmediate_operand" "=k,k")
+ (unspec:QI
+ [(match_operand:QI 1 "nonimmediate_operand" "r,km")]
+ UNSPEC_KMOV))]
+ "!(MEM_P (operands[0]) && MEM_P (operands[1])) && TARGET_AVX512DQ"
+ "@
+ kmovb\t{%k1, %0|%0, %k1}
+
On 08/11/16 13:36, Thomas Preudhomme wrote:
Ping?
Best regards,
Thomas
On 25/10/16 18:07, Thomas Preudhomme wrote:
Hi,
Currently when a user compiles for a thumb-only target (such as Cortex-M
processors) without specifying the -mthumb option GCC throws the error "target
CPU does not support
Richard,
Here is fixed version of updated patch 3.
Any comments will be appreciated.
Thanks.
Yuri.
2016-11-11 17:15 GMT+03:00 Yuri Rumyantsev :
> Richard,
>
> Sorry for confusion but my updated patch does not work properly, so I
> need to fix it.
>
> Yuri.
>
> 2016-11-11 14:15 GMT+03:00 Yuri R
Hi,
To fix PR69714, code was added to disable bswap when the resulting symbolic
expression (a load or load + byte swap) is smaller than the source expression
(eg. some of the bytes accessed in the source code gets bitwise ANDed with 0).
As explained in [1], there was already two pieces of code
On Sat, Nov 5, 2016 at 6:01 AM, Andreas Schwab wrote:
> The alignment of int64 is 8 everywhere except m68k, where the biggest
> alignment is 2, and x86-32, where the biggest field alignment is 4.
> This fixes all select tests on powerpc -m32.
>
> Andreas.
>
> diff --git a/libgo/configure b/libgo/c
On Thu, Nov 3, 2016 at 10:39 AM, Mark Wielaard wrote:
>
> include/ChangeLog:
>
> 2016-11-03 David Tolnay
>Mark Wielaard
>
>* demangle.h (DMGL_RUST): New macro.
>(DMGL_STYLE_MASK): Add DMGL_RUST.
>(demangling_styles): Add dlang_rust.
>(RUST_DEMANGLING
On 11/11/2016 02:47 AM, Martin Liška wrote:
We use lists like for -fsanitize=address,undefined, however as -fprofile-update
has only 3 (and passing 'single,atomic' does not make sense), I would prefer
to s/maybe-atomic/prefer-atomic. I guess handling the option list in gcc.c and
doing substitu
On 11/11/2016 01:10 PM, Richard Biener wrote:
> On Thu, Nov 10, 2016 at 4:36 PM, Martin Liška wrote:
>> 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
On Fri, 11 Nov 2016, Andrew Senkevich wrote:
+extern __inline __mmask32
+__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
+_kand_mask32 (__mmask32 __A, __mmask32 __B)
+{
+ return (__mmask32) __builtin_ia32_kandsi ((__mmask32) __A, (__mmask32) __B);
+}
(picking one random ex
On 11/11/16 10:17, Kyrill Tkachov wrote:
On 10/11/16 23:39, Segher Boessenkool wrote:
On Thu, Nov 10, 2016 at 02:42:24PM -0800, Andrew Pinski wrote:
On Thu, Nov 10, 2016 at 6:25 AM, Kyrill Tkachov
I ran SPEC2006 on a Cortex-A72. Overall scores were neutral but there were
some interesting swi
Hi,
this patch fixes PR sanitizer/78307 by adding removed by last merge
(although unused in GCC) interface functions:
__ubsan_handle_cfi_bad_icall
__ubsan_handle_cfi_bad_icall_abort
__ubsan_handle_cfi_bad_type
__ubsan_handle_cfi_bad_type_abort
Just added missed stubs via corresponding argumen
On Fri, 11 Nov 2016, Bernd Schmidt wrote:
> On 10/19/2016 12:39 PM, Bernd Schmidt wrote:
> > I'll refrain from any further comments on the topic. The ptx patches
> > don't look unreasonable iff someone else decides that this version of
> > OpenMP support should be merged and I'll look into them in
Hi,
This patch set enables the _Float16 type specified in ISO/IEC TS 18661-3
for AArch64 and ARM. The patch set has been posted over the past two months,
with many of the target-independent changes approved. I'm reposting it in
entirity in the form I hope to commit it to trunk.
The patch set can
---
This patch has already been approved:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01554.html
---
This patch ports the logic from s390's TARGET_FLT_EVAL_METHOD to the new
target hook TARGET_C_EXCESS_PRECISION, following the guidance in this thread
https://gcc.gnu.org/ml/gcc-patches/2016-10
---
This patch has been approved:
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02402.html
---
This patch ports the logic from i386's TARGET_FLT_EVAL_METHOD to the new
target hook TARGET_C_EXCESS_PRECISION.
Bootstrapped and tested with no issues.
OK?
Thanks,
James
---
gcc/
2016-11-09 Jame
---
This patch has already been approved:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00781.html
---
This patch introduces TARGET_C_EXCESS_PRECISION. This hook takes a tri-state
argument, one of EXCESS_PRECISION_TYPE_IMPLICIT,
EXCESS_PRECISION_TYPE_STANDARD, EXCESS_PRECISION_TYPE_FAST. Which
---
This patch was approved in the original form, and the delta to here would
apply under the obvious rule:
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02414.html
---
On Fri, Sep 30, 2016 at 11:28:28AM -0600, Jeff Law wrote:
> On 09/30/2016 11:01 AM, James Greenhalgh wrote:
> >
> >Hi,
> >
> >
---
This patch was approved here:
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02405.html
Joseph had a comment in
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00335.html that the tests
should check FLT_EVAL_METHOD from rather than
__FLT_EVAL_METHOD__. Rather than implement that suggestion, I
---
This patch has already been approved:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00784.html
---
This patch moves the logic for excess precision from using the
TARGET_FLT_EVAL_METHOD macro to the TARGET_EXCESS_PRECISION hook
introduced earlier in the patch series.
Briefly; we have four t
On 11/11/2016 04:35 PM, Alexander Monakov wrote:
For the avoidance of doubt, is this a statement of intent, or an actual approval
for the patchset?
After these backend modifications and the rest of libgomp/middle-end changes are
applied, trunk will need the following flip-the-switch patch to al
---
This patch was approved:
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02401.html
---
Hi,
We've removed all uses of TARGET_FLT_EVAL_METHOD, so we can remove it
and poison it.
Bootstrapped and tested on x86-64 and AArch64. Tested on s390 and m68k
to the best of my ability (no execute test
---
This patch was approved:
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02403.html
---
Hi,
Now that we've worked on -fexcess-precision, the comment in targhooks.c
no longer holds. We can now permit _Float16 on any target which provides
HFmode and supports HFmode in libgcc.
Bootstrapped and
Hi,
As Joseph and I discussed in
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00239.html the
check_effective_target_float tests should add any options which the
target requires to enable those float types (add_options_for_float.
This patch ensures those options get added, which presently only c
---
This patch can be self approved
---
Hi,
This patch merges in the support added to glibc for HFmode conversions in
this patch:
commit 87ab10d6524fe4faabd7eb3eac5868165ecfb323
Author: James Greenhalgh
Date: Wed Sep 21 21:02:54 2016 +
[soft-fp] Add support for vario
Hi,
This patch enables the conversion functions we need for AArch64's _Float16
support. To do that we need to implement TARGET_SCALAR_MODE_SUPPORTED_P,
so do that now.
OK?
Thanks,
James
---
gcc/
2016-11-09 James Greenhalgh
* config/aarch64/aarch64-c.c (aarch64_scalar_mode_supporte
Hi,
This patch adds patterns for conversion from 64-bit integer to 16-bit
floating-point values under AArch64 targets which don't have support for
the ARMv8.2-A 16-bit floating point extensions.
We implement these by first saturating to a SImode (we know that any
values >= 65504 will round to in
Hi,
This patch adds the back-end wiring to get AArch64 support for
the _Float16 type working.
Bootstrapped on AArch64 with no issues.
OK?
Thanks,
James
---
2016-11-09 James Greenhalgh
* config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Update
__FLT_EVAL_METHOD__ a
Hi,
I'm adapting this patch from work started by Matthew Wahab.
Conversions from double precision floats to the ARM __fp16 are required
to round only once. A conversion function for double to __fp16 to
support this on soft-fp targets. This and the following patch add this
conversion function by
Hi,
This patch adds the half-to-double conversions, both as library functions,
or when supported in hardware, using the appropriate instructions.
That means adding support for the __gnu_d2h_{ieee/alternative} library calls
added in patch 2/4, and providing a more aggressive truncdfhf2 where we c
Hi,
Conversions from double precision floats to the ARM __fp16 are required
to round only once.
This patch adds a functions named __gnu_d2h_ieee and
__gnu_d2h_alternative for double to __fp16 conversions in IEEE and ARM
alternative format. The make use of the existing __gnu_float2h_internal
conv
Hi,
Finally, having added support for single-step DFmode to HFmode conversions,
this patch adds support for _Float16 to the ARM back-end.
That means making sure that only __fp16 promotes and adding similar hooks to
those used in the AArch64 port giving the excess precision rules, and
marking HFm
1 - 100 of 185 matches
Mail list logo
