I started looking at allowing non-type constrained-type-specifiers in
auto deduction and then realized that we didn't handle them in function
parameters either. Fixing that brought home to me the oddity of having
a type-specifier stand in for a non-type. Mind weighing in on that on
the core r
On Fri, Nov 6, 2015 at 6:32 AM, Bernd Schmidt wrote:
> On 11/06/2015 03:10 PM, Sebastian Pop wrote:
>>
>> On Fri, Nov 6, 2015 at 2:56 AM, Bernd Schmidt wrote:
>>>
>>> Formatting problem, here and in a few other places. I didn't fully read
>>> the
>>> patch this time around.
>>>
>>> I'm probably n
I was confused at first why tree-core.h was undefining DEF_BUILTIN_CHKP
before defining it, then undefining it again after including builtins.def.
This is because builtins.def provides a default definition of
DEF_BUILTIN_CHKP, but leaves it up to the caller to undefine it where
necessary. Similarl
2015-11-06 Arnout Vandecappelle
* gcc/config.gcc: fix typo for powerpc e6500 cpu_is_64bit
For GCC, please don't send ChangeLog entries as diffs.
Applied. Thanks.
- David
On Fri, Nov 6, 2015 at 3:07 PM, Yulia Koval wrote:
> Hi,
>
> I updated and reposted the patch. Regtested/bootstraped on
> x86_64/Linux and i686/Linux. Ok for trunk?
This version still emits insns from ix86_function_arg, so NAK.
Uros.
This patch moves folds that deal with constant string arguments and
return a constant integer or floating-point value. For example, it
handles strcmp ("foo", "bar") but not strstr ("foobar", "bar"),
which wouldn't currently be accepted by the gimple folders.
The builtins.c folding for strlen (via
In practice the definition of DEF_INTERNAL_FN is never reused after
including internal-fn.def, so we might as well #undef it there.
This becomes more obvious with a later patch that adds other
DEF_INTERNAL_* directives, such as DEF_INTERNAL_OPTAB_FN.
If the includer doesn't care about the informat
On 11/06/2015 05:55 AM, Rainer Orth wrote:
Martin Sebor writes:
If we use gcc_checking_assert it won't fire in release builds; let's go
with that.
Okay. Attached is an updated patch with that change.
Unfortunately, this breaks i386-pc-solaris2.10 bootstrap:
/vol/gcc/src/hg/trunk/local/gcc
The old code here laments not being able to reuse the CONST_DECL created
by process_template_parm, but we can get to it from the TEMPLATE_PARM_INDEX.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 02af5bca9bd6dbd3080bef614e411c56303d3c66
Author: Jason Merrill
Date: Thu Nov 5 16:20:12 2
On 11/06/2015 04:02 PM, Richard Sandiford wrote:
builtins.def says that rint sets errno, but it looks like this might
be a mistake. C99 says that rint doesn't set errno and the builtins.c
expansion code doesn't try to keep errno up to date.
[snip explanation of the history]
FWIW the manpage h
On 11/06/2015 04:05 PM, Richard Sandiford wrote:
Upcoming patches to fold-const-call.c want to use c_getstr, which is
currently defined in builtins.c. The function doesn't really do anything
related to built-ins, and I'd rather not make fold-const-call.c depend
on builtins.c and builtins.c depen
The only folds left in builtins.c were for constants, so we can remove
the builtins.c handling entirely.
Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabi.
OK to install?
Thanks,
Richard
gcc/
* builtins.c (fold_builtin_bitop, fold_builtin_bswap): Delete.
(fold_
Move the constant "is finite", "is infinite" and "is nan" queries
to fold-const-call.c.
Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabi.
OK to install?
Thanks,
Richard
gcc/
* builtins.c (fold_builtin_classify): Move constant cases to...
* fold-const-call.c (f
Hi,
reverting a patch in tree-inline.c in gomp-4_0-branch exposed a typo
already fixed on trunk. This patch fixes that.
Committed to gomp-4_0-branch.
Thanks,
- Tom
2015-11-06 Tom de Vries
backport from trunk:
2015-07-12 Aldy Hernandez
* tree-inline.c: Fix double word typos.
---
Hi,
this patch reverts the "Add dom_walker::walk_until" patch.
The dom_walker::walk_until functionality is no longer required now that
we've reverted pass_dominator::sese_mode_p.
Committed to gomp-4_0-branch.
Thanks,
- Tom
Revert "Add dom_walker::walk_until"
2015-11-06 Tom de Vries
rev
Upcoming patches to fold-const-call.c want to use c_getstr, which is
currently defined in builtins.c. The function doesn't really do anything
related to built-ins, and I'd rather not make fold-const-call.c depend
on builtins.c and builtins.c depend on fold-const-call.c, so this patch
moves the fun
builtins.def says that rint sets errno, but it looks like this might
be a mistake. C99 says that rint doesn't set errno and the builtins.c
expansion code doesn't try to keep errno up to date.
Perhaps this was because earlier versions of POSIX said that
rint sets errno on overflow:
http://pub
At the moment the ECF_* flags for a gimple call to a built-in
function are derived from the function decl, which in turn is
derived from the global command-line options. So if the compiler
is run with -fno-math-errno, we always assume functions don't set
errno, regardless of local optimization opt
On 11/06/2015 03:10 PM, Sebastian Pop wrote:
On Fri, Nov 6, 2015 at 2:56 AM, Bernd Schmidt wrote:
Formatting problem, here and in a few other places. I didn't fully read the
patch this time around.
I'm probably not reviewing further patches because I don't see this
progressing to a state where
OK.
Jason
On 06/11/15 00:56, Segher Boessenkool wrote:
On Thu, Nov 05, 2015 at 12:01:26PM +, Kyrill Tkachov wrote:
Thanks, that looks less intrusive. I did try it out on arm and aarch64.
It does work on the aarch64 testcase. However, there's also a correctness
regression, I'll try to explain inline..
On 11/06/2015 03:08 PM, Jakub Jelinek wrote:
On Fri, Nov 06, 2015 at 03:05:05PM +0100, Bernd Schmidt wrote:
This patch creates a new "omp target entrypoint" annotation that appears not
to be used - it would be better to just not annotate a function if it's not
going to need entrypoint treatment.
On Fri, Nov 6, 2015 at 2:56 AM, Bernd Schmidt wrote:
> Formatting problem, here and in a few other places. I didn't fully read the
> patch this time around.
>
> I'm probably not reviewing further patches because I don't see this
> progressing to a state where it's acceptable. Others may do so, but
On Fri, Nov 06, 2015 at 03:05:05PM +0100, Bernd Schmidt wrote:
> This patch creates a new "omp target entrypoint" annotation that appears not
> to be used - it would be better to just not annotate a function if it's not
> going to need entrypoint treatment. IMO a single type of attribute should be
Hi,
I updated and reposted the patch. Regtested/bootstraped on
x86_64/Linux and i686/Linux. Ok for trunk?
Implement x86 interrupt attribute
The interrupt and exception handlers are called by x86 processors. X86
hardware pushes information onto stack and calls the handler. The
requirements are
On Fri, Nov 06, 2015 at 03:00:30PM +0100, Bernd Schmidt wrote:
> >Sanity-checked by running the libgomp testsuite. I realize the #ifdef in
> >internal-fn.c is not appropriate: it's there to make the patch smaller, I'll
> >replace it with a target hook if otherwise this approach is ok.
>
> FWIW, n
On 10/30/2015 05:44 PM, Alexander Monakov wrote:
+ /* Ignore "omp target entrypoint" here: OpenMP target region functions are
+ called from gomp_nvptx_main. The corresponding kernel entry is emitted
+ from write_omp_entry. */
}
I'm probably confused, but didn't we agree that this s
Sanity-checked by running the libgomp testsuite. I realize the #ifdef in
internal-fn.c is not appropriate: it's there to make the patch smaller, I'll
replace it with a target hook if otherwise this approach is ok.
FWIW, no objections from me regarding the approach.
Bernd
Otherwise, it will not be treated as a 64-bit CPU even if the target
tuple specifies powerpc64.
---
This is a trivial fix so I hope no copyright assignment is required. I
submit this change in the public domain.
This is my first time submitting anything to gcc, so if I should do
someting different
On Thu, Nov 5, 2015 at 10:12 PM, Aditya Kumar wrote:
> Irreducible regions are not going to be optimized by ISL
> so discard them early.
>
> gcc/ChangeLog:
>
> 2015-11-06 Aditya Kumar
>
> * graphite-scop-detection.c (scop_detection::merge_sese):
> (scop_detection::can_represent_
Hi,
As mentioned by James a few weeks ago, the vqtbl[lx][234] intrinsics
are failing on aarch64_be.
The attached patch fixes them, and rewrites them using new builtins
instead of inline assembly.
I wondered about the names of the new builtins, I hope I got them
right: qtbl3, qtbl4, qtbx3, qtbx4
Jakub,
Ping.
Do you need more information before you can review this patch?
Thanks!
Jim
On 10/27/2015 03:18 PM, James Norris wrote:
Hi!
This patch adds the processing of OpenACC declare directive in C
and C++. (Note: Support in Fortran is already in trunk.)
Commentary on the
> Hi!
>
> I faced the same issue but I had somewhat different RTL for the consumer:
>
> (insn 20 15 21 2 (set (reg/i:SI 0 r0)
> (minus:SI (subreg:SI (reg:DI 117) 4)
> (mult:SI (reg:SI 123)
> (reg:SI 114 gasman.c:4 48 {*mulsi3subsi})
>
> wh
Jakub,
Ping
Do you need more information before you can review this patch?
Thanks!
Jim
On 11/04/2015 06:32 AM, James Norris wrote:
This patch updates the processing of OpenACC declare directive for
Fortran in the following areas:
1) module support
2) device_resi
On 11/06/15 01:50, Jakub Jelinek wrote:
On Thu, Nov 05, 2015 at 06:10:49PM -0800, Cesar Philippidis wrote:
I've applied this patch to trunk. It also includes the fortran and
template changes. Note that there is a new regression in
gfortran.dg/goacc/combined_loop.f90. Basically, the gimplifier is
On Fri, 6 Nov 2015, Richard Biener wrote:
>
> A few, spotted with valgrind. One is even mine ;)
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
And this is what I committed (one extra leak in postreload-gcse).
Richard.
2015-11-06 Richard Biener
* tree-ssa-sccvn.c (
On 11/05/15 21:10, Cesar Philippidis wrote:
I've applied this patch to trunk. It also includes the fortran and
template changes. Note that there is a new regression in
gfortran.dg/goacc/combined_loop.f90. Basically, the gimplifier is
complaining about reduction variables appearing in multiple cla
Hi all,
With Martins' patch at https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00492.html
I'm seeing an arm bootstrap error due to a warning in the print format
addressed in this patchlet.
bytes_avail is an unsigned HOST_WIDE_INT and so needs the %wu print format
rather than %lu which
may not be
libgcc/config/arm/linux-atomic-64bit.c uses __write to print an error
message if the 64bit cmpxchg method is not available in the kernel.
__write is not part of the public libc abi, so use write instead.
(user code may define write in iso c conforming mode and then the
error message may not be vi
The following patch has remained unrevied for a month:
[build] Support init priority on Solaris
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00716.html
It needs build and ia64 maintainers and someone familiar with the init
priority support to review.
Thanks.
Rainer
--
Richard,
I tried it but 256-bit precision integer type is not yet supported.
Yuri.
2015-11-06 15:56 GMT+03:00 Richard Biener :
> On Mon, Nov 2, 2015 at 4:24 PM, Yuri Rumyantsev wrote:
>> Hi Richard,
>>
>> I've come back to this optimization and try to implement your proposal
>> for comparison:
On Wed, Nov 4, 2015 at 11:18 AM, Bin Cheng wrote:
> Hi,
> PR52272 reported a performance regression in spec2006/410.bwaves once GCC is
> prevented from representing address of one memory object using address of
> another memory object. Also as I commented in that PR, we have two possible
> fixes
On Fri, Nov 6, 2015 at 10:10 AM, Martin Liška wrote:
> Hello.
>
> Following patch triggers hash calculation of items (functions and variables)
> in situations where LTO mode is not utilized.
>
> Patch survives regression tests and bootstraps on x86_64-linux-pc.
Why does that make a difference? D
On Fri, 6 Nov 2015, Tom de Vries wrote:
> Hi,
>
> This patch fixes a problem with -g compilation in
> transform_to_exit_first_loop_alt.
>
> Consider test-case test.c:
> ...
> void
> f (int *a, int n)
> {
> int i;
> for (i = 0; i < n; ++i)
> a[i] = 1;
> }
> ...
>
> If we add a "checking_
On Fri, 6 Nov 2015, Sujoy Saraswati wrote:
> > Shouldn't real_convert do this rather than the caller needing to do it?
>
> Yes, it should be. I had started by doing this within real_convert but
> then saw that there are quite a few callers where I should add the
> check for flag_signaling_nans. T
[ was: Re: [gomp4, committed] Revert "Add IFN_GOACC_DATA_END_WITH_ARG" ]
On 06/11/15 13:03, Tom de Vries wrote:
Now that we've got -foffload-alias, we're no longer concerned about
GOACC builtins being alias analysis optimization barriers, so the
IFN_GOACC_DATA_END_WITH_ARG patch has become obso
On Fri, Nov 6, 2015 at 2:34 AM, Mike Stump wrote:
> On Nov 5, 2015, at 4:32 AM, Richard Biener wrote:
>> No idea on location lists but maybe this means we should just use the
>> maximum supported integer mode for CONST_WIDE_INTs?
>
> Ah, yeah, that sounds like a fine idea. Below is that version.
Ian Lance Taylor writes:
> I have committed a patch to libgo to update it to the Go 1.5 release.
>
> As usual for libgo updates, the actual patch is too large to attach to
> this e-mail message. I've attached the changes to the gccgo-specific
> files.
>
> Bootstrapped and ran Go testsuite on x86
On Thu, Nov 5, 2015 at 5:16 PM, Ilya Enkovich wrote:
> Hi,
>
> This patch fixes a way vectype is computed in vectorizable_operation.
> Currently op0 is always used to compute vectype. If it is a loop invariant
> then its type is used to get vectype which is impossible for booleans
> requiring
On Mon, Nov 2, 2015 at 4:24 PM, Yuri Rumyantsev wrote:
> Hi Richard,
>
> I've come back to this optimization and try to implement your proposal
> for comparison:
>> Btw, you didn't try the simpler alternative of
>>
>> tree type = type_for_mode (int_mode_for_mode (TYPE_MODE (vectype)));
>> build2 (
On Thu, Nov 5, 2015 at 2:33 PM, Alan Lawrence wrote:
> On 03/11/15 13:39, Richard Biener wrote:
>> On Tue, Oct 27, 2015 at 6:38 PM, Alan Lawrence wrote:
>>>
>>> Say I...P are consecutive, the input would have gaps 0 1 1 1 1 1 1 1. If we
>>> split the load group, we would want subgroups with gaps
Martin Sebor writes:
>> If we use gcc_checking_assert it won't fire in release builds; let's go
>> with that.
>
> Okay. Attached is an updated patch with that change.
Unfortunately, this breaks i386-pc-solaris2.10 bootstrap:
/vol/gcc/src/hg/trunk/local/gcc/cp/init.c: In function 'void
warn_pla
I see this failure on m68k:
FAIL: g++.dg/warn/Wplacement-new-size.C -std=gnu++11 (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20151106/gcc/testsuite/g++.dg/warn/Wplacement-new-size.C:189:19:
warning: placement new constructing an object of type 'int' and size '
On 11/06/2015 12:29 PM, Bernd Schmidt wrote:
David Cc'ed so he can take the necessary steps.
Initially, I have created the file by copying out pieces of PDF
documentation but the latest version of the file (describing final
HSAIL 1.0) is actually taken from the HSAIL (dis)assembler developed
On Thu, Nov 5, 2015 at 2:22 PM, Alan Lawrence wrote:
> On 30/10/15 10:54, Eric Botcazou wrote:
>> On 30/10/15 10:44, Richard Biener wrote:
>>>
>>> I think you want to use wide-ints here and
>>>
>>> wide_int idx = wi::from (minidx, TYPE_PRECISION (TYPE_DOMAIN
>>> (...)), TYPE_SIGN (TYPE_DOMAIN
On 10/28/2015 01:07 PM, Kyrill Tkachov wrote:
Hi all,
This RTL checking error occurs on aarch64 in
aarch_accumulator_forwarding when processing an msubsi insn
with subregs:
(insn 15 14 16 3 (set (reg/v:SI 78 [ i ])
(minus:SI (subreg:SI (reg/v:DI 76 [ aul ]) 0)
(mult:SI (sub
On Fri, 6 Nov 2015, Alan Lawrence wrote:
> On 06/11/15 10:39, Richard Biener wrote:
> > > ../spec2000/benchspec/CINT2000/254.gap/src/polynom.c:358:11: error:
> > > location
> > > references block not in block tree
> > > l1_279 = PHI <1(28), l1_299(33)>
> >
> > ^^^
> >
> > this is the error to lo
On 06/11/15 10:39, Richard Biener wrote:
../spec2000/benchspec/CINT2000/254.gap/src/polynom.c:358:11: error: location
references block not in block tree
l1_279 = PHI <1(28), l1_299(33)>
^^^
this is the error to look at! It means that the GC heap will be corrupted
quite easily.
Thanks, I'll
A few, spotted with valgrind. One is even mine ;)
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2015-11-06 Richard Biener
* tree-ssa-sccvn.c (class sccvn_dom_walker): Add destructor.
* lra.c (init_reg_info): Truncate copy_vec instead of
re-allo
The previous allocator never initialized objects thus switch to
default initialization.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
Index: gcc/alloc-pool.h
===
--- gcc/alloc-pool.h(revision 229804)
+
Hi,
I've reverted the patch that added IFN_GOACC_DATA_END_WITH_ARG (
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02661.html ).
The patch attempted to fix a test failure, while at the same time
keeping the GOACC_data_start fnspec attributes to prevent it from
becoming an alias analysis opti
Committed r229844.
Thanks,
Simon
> -Original Message-
> From: Moore, Catherine [mailto:catherine_mo...@mentor.com]
> Sent: 03 November 2015 14:09
> To: Simon Dardis; Alan Lawrence; Matthew Fortune
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH, MIPS, PR/61114] Migrate to reduc_..._sc
On 29/10/15 14:14, Kyrill Tkachov wrote:
>
> On 29/10/15 14:00, Marcus Shawcroft wrote:
>> On 29 October 2015 at 13:50, Kyrill Tkachov wrote:
>>
> Ok for trunk?
rtl.h exposes reg_or_subregno() already doesn't that do what we need here?
>>>
>>> reg_or_subregno assumes that what it's pas
Ping.
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03170.html
Thanks,
Kyrill
On 29/10/15 14:14, Kyrill Tkachov wrote:
On 29/10/15 14:00, Marcus Shawcroft wrote:
On 29 October 2015 at 13:50, Kyrill Tkachov wrote:
Ok for trunk?
rtl.h exposes reg_or_subregno() already doesn't that do what w
On 06/11/15 11:37, Kyrill Tkachov wrote:
Ping.
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03170.html
My apologies, I meant to ping another patch.
Please disregard that.
Kyrill
Thanks,
Kyrill
On 30/10/15 15:47, Kyrill Tkachov wrote:
On 30/10/15 14:37, Ramana Radhakrishnan wrote:
On 2
Ping.
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03170.html
Thanks,
Kyrill
On 30/10/15 15:47, Kyrill Tkachov wrote:
On 30/10/15 14:37, Ramana Radhakrishnan wrote:
On 29/10/15 16:02, Kyrill Tkachov wrote:
Hi all,
An arm-none-eabi build with RTL checking and --with-cpu=cortex-a9 fails beca
Hi!
On Fri, 6 Nov 2015 12:03:25 +0100, Bernd Schmidt wrote:
> On 11/06/2015 11:30 AM, Richard Biener wrote:
> > On Fri, 6 Nov 2015, Bernd Schmidt wrote:
> >>
> >> Realistically we're probably not going to reject this work, but I still
> >> want
> >> to ask whether the approach was acked by the c
On 06/11/15 11:31, Bernd Schmidt wrote:
> On 11/06/2015 12:17 PM, Ramana Radhakrishnan wrote:
>> On 06/11/15 11:08, Bernd Schmidt wrote:
>>> This one is a fix for something that could currently only affect c6x, but I
>>> have code that exposes it on i386.
>>>
>>> When optionally gathering operan
On 11/06/2015 12:17 PM, Ramana Radhakrishnan wrote:
On 06/11/15 11:08, Bernd Schmidt wrote:
This one is a fix for something that could currently only affect c6x, but I
have code that exposes it on i386.
When optionally gathering operand info in regrename, we can overflow the array in certain
On 11/05/2015 11:05 PM, Martin Jambor wrote:
Initially, I have created the file by copying out pieces of PDF
documentation but the latest version of the file (describing final
HSAIL 1.0) is actually taken from the HSAIL (dis)assembler developed
by HSA foundation and released by "University of Ill
On Fri, 6 Nov 2015, Kyrill Tkachov wrote:
> Hi Richard,
>
> On 06/11/15 11:09, Richard Biener wrote:
> > On Fri, 6 Nov 2015, Richard Biener wrote:
> >
> > > The following patch makes the BB vectorizer not only handle BB heads
> > > (until the first stmt with a data reference it cannot handle) bu
On 06/11/15 11:08, Bernd Schmidt wrote:
> This one is a fix for something that could currently only affect c6x, but I
> have code that exposes it on i386.
>
> When optionally gathering operand info in regrename, we can overflow the
> array in certain situations. This can occur when we have a s
Hi!
On Thu, 5 Nov 2015 10:41:41 -0500, Nathan Sidwell wrote:
> On 11/05/15 10:29, Jakub Jelinek wrote:
> > I've merged the current state of gomp-4_5-branch into trunk, after
> > bootstrapping/regtesting it on x86_64-linux and i686-linux.
> >
> > There are
> > +FAIL: gfortran.dg/goacc/private-3.f9
Hi Richard,
On 06/11/15 11:09, Richard Biener wrote:
On Fri, 6 Nov 2015, Richard Biener wrote:
The following patch makes the BB vectorizer not only handle BB heads
(until the first stmt with a data reference it cannot handle) but
arbitrary regions in a BB separated by such stmts.
This improve
On Fri, 6 Nov 2015, Richard Biener wrote:
>
> The following patch makes the BB vectorizer not only handle BB heads
> (until the first stmt with a data reference it cannot handle) but
> arbitrary regions in a BB separated by such stmts.
>
> This improves the number of BB vectorizations from 469 t
This one is a fix for something that could currently only affect c6x,
but I have code that exposes it on i386.
When optionally gathering operand info in regrename, we can overflow the
array in certain situations. This can occur when we have a situation
where a value is constructed in multiple
On 11/06/2015 11:30 AM, Richard Biener wrote:
On Fri, 6 Nov 2015, Bernd Schmidt wrote:
Realistically we're probably not going to reject this work, but I still want
to ask whether the approach was acked by the community before you started. I'm
really not exactly thrilled about having two differe
On 11/06/2015 12:43 AM, Abe wrote:
Feedback from Bernd has also been applied.
But inconsistently, and I think not quite in the way I meant it in one case.
-/* Return true if a write into MEM may trap or fault. */
-
static bool
noce_mem_write_may_trap_or_fault_p (const_rtx mem)
{
- rtx
I have a patch which makes use of the renamer more often, and this
exposed a bug with earlyclobber operands. The code that does the
terminate_write step has the following comment:
/* Step 5: Close open chains that overlap writes. Similar to
step 2, we hide in-out operand
On 11/06/2015 11:12 AM, Bernd Schmidt wrote:
> On 11/05/2015 10:51 PM, Martin Jambor wrote:
>> Individual changes are described in slightly more detail in their
>> respective messages. If you are interested in how the HSAIL
>> generation works in general, I encourage you to have a look at my
>> Ca
On 06/17/2015 07:11 PM, Sandra Loosemore wrote:
Index: gcc/regrename.c
===
--- gcc/regrename.c (revision 224532)
+++ gcc/regrename.c (working copy)
@@ -942,19 +942,22 @@ regrename_do_replace (struct du_head *he
int r
Hi Nathan!
On Mon, 2 Nov 2015 11:38:47 -0500, Nathan Sidwell wrote:
> This patch are the initial set of tests. The libgomp tests use an idiom of
> summing thread identifiers and then checking the expected set of threads
> participated. They are all derived from the loop tests I recently added
Hi Nathan!
On Wed, 4 Nov 2015 11:59:28 -0500, Nathan Sidwell wrote:
> [PTX backend pieces of OpenACC reduction handling]
Merged your trunk r229768 into gomp-4_0-branch in r229836:
commit 089a0224af68e30b55f42734de48adc645eb7370
Merge: 2b76127 78a78aa
Author: tschwinge
Date: Fri Nov 6 09:38:1
Hi Nathan!
On Mon, 2 Nov 2015 11:18:37 -0500, Nathan Sidwell wrote:
> This is the core execution bits of OpenACC reductions.
> One thing not handled by this patch are reductions of variables of reference
> type. We have an implementation on gomp4 branch [...]
Trying to keep the existing code
Hi all,
In this wrong-code PR the vector setmem expansion and
arm_block_set_aligned_vect in particular
use the wrong offset when calling adjust_automodify_address. In the attached
testcase during the
initial zeroing out we get two V16QI stores, but they both are recorded by
adjust_automodify_a
On Fri, 6 Nov 2015, Alan Lawrence wrote:
> On 28/10/15 13:38, Richard Biener wrote:
> >
> > Applied as follows.
> >
> > Bootstrapped / tested on x86_64-unknown-linux-gnu.
> >
> > Richard.
> >
> > 2015-10-28 Richard Biener
> >
> > * fold-const.c (negate_expr_p): Adjust the division case
On 21/08/15 10:47, Jiong Wang wrote:
Richard Biener writes:
I see the following ICE:
t.c:13:1: internal compiler error: in decompose_normal_address, at
rtlanal.c:6090
}
^
0xc94a37 decompose_normal_address
/space/rguenther/tramp3d/trunk/gcc/rtlanal.c:6090
0xc94d25 decompose_addre
On 28/10/15 13:38, Richard Biener wrote:
Applied as follows.
Bootstrapped / tested on x86_64-unknown-linux-gnu.
Richard.
2015-10-28 Richard Biener
* fold-const.c (negate_expr_p): Adjust the division case to
properly avoid introducing undefined overflow.
(fold_negat
On Fri, 6 Nov 2015, Bernd Schmidt wrote:
> On 11/05/2015 10:51 PM, Martin Jambor wrote:
> > Individual changes are described in slightly more detail in their
> > respective messages. If you are interested in how the HSAIL
> > generation works in general, I encourage you to have a look at my
> > C
> Hmm, can you clarify, do you mean I should *not* replace constant pool
> values with their DECL_INITIAL? The attempt to substitute in the
> initial value is what leads to most of the problems. For example, in
> gnat/opt31.adb, create_access finds this expression accessing *.LC0:
>
> MEM[(interfa
On 11/04/2015 03:53 PM, David Malcolm wrote:
This patch adds hints to the option-not-found error in the driver,
using the Levenshtein distance implementation posted here:
"[PATCH 0/2] Levenshtein-based suggestions (v3)"
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03379.html
It splits out th
On 11/05/2015 10:51 PM, Martin Jambor wrote:
Individual changes are described in slightly more detail in their
respective messages. If you are interested in how the HSAIL
generation works in general, I encourage you to have a look at my
Cauldron slides or presentation, only very few things have
On 11/06/2015 01:56 AM, Jonathan Wakely wrote:
> On 5 November 2015 at 23:31, Daniel Gutson
>> The issue is, as I understand it, to do the actual work of operator
>> new, i.e. allocate memory. It should force
>> us to copy most of the code of the original code of operator new,
>> which may change
On Fri, 6 Nov 2015, Martin Liška wrote:
> On 11/06/2015 10:00 AM, Richard Biener wrote:
> > On Thu, 5 Nov 2015, Martin Jambor wrote:
> >
> >> Hi,
> >>
> >> we use C++ new operators based on alloc-pools a lot in the subsequent
> >> patches and realized that on the current trunk, such new operators
On 11/06/2015 10:00 AM, Richard Biener wrote:
> On Thu, 5 Nov 2015, Martin Jambor wrote:
>
>> Hi,
>>
>> we use C++ new operators based on alloc-pools a lot in the subsequent
>> patches and realized that on the current trunk, such new operators
>> would needlessly call the placement ::new operator
Thanks Paul. I believe PR53852 won't be fixed on 4.9/5 as it seems to depend on
the recent graphite cleanup work and recent isl. As such I'll commit to trunk
only.
The following patch makes the BB vectorizer not only handle BB heads
(until the first stmt with a data reference it cannot handle) but
arbitrary regions in a BB separated by such stmts.
This improves the number of BB vectorizations from 469 to 556
in a quick test on SPEC CPU 2006 with -Ofast on x
Dear Joost,
These two testcases look fine to me. PR53852 is marked as being a
4.9,5,6 regression. If I have understood correctly, it has only been
fixed on trunk. Do you know if there is any intention to fix it on the
other branches?
OK for trunk and, subject to the previous question being answer
On 4 November 2015 at 16:37, James Greenhalgh wrote:
>
> On Wed, Nov 04, 2015 at 12:04:19PM +0100, Bernd Schmidt wrote:
>> On 10/30/2015 07:03 PM, James Greenhalgh wrote:
>> >+ i = tmp_i; <- Should be cleaned up
>>
>> Maybe reword as "Subsequent passes are expected to clean up the
>> extra mov
Hello.
Following patch triggers hash calculation of items (functions and variables)
in situations where LTO mode is not utilized.
Patch survives regression tests and bootstraps on x86_64-linux-pc.
Ready for trunk?
Thanks,
Martin
>From 62266e21a89777c6dbd680f7c87f15abe603c024 Mon Sep 17 00:00:00
101 - 200 of 204 matches
Mail list logo
