On 11/18/2015 03:35 PM, Dominik Vogt wrote:
> The attached patch fixes the S/390 patterns using the "pfpo"
> instruction in s390.md. The instructions clobber r1, but the
> patterns did not reflect that.
Good catch!
Your testcase requires -mzarch in the options to enable pfpo with -m31 as well.
A cygwin hosted cross compiler to aarch64-linux, compiling a C version
of linpack with -Ofast, produces code that runs 17% slower than a
linux hosted compiler. The problem shows up in the vect dump, where
some different vectorization optimization decisions were made by the
cygwin compiler than the
The patch fixed the bootstrap failure.
Thanks, David
On Thu, Nov 19, 2015 at 3:37 PM, Sebastian Pop wrote:
> Fixed in r230625.
>
> David, please test on your systems, we were not able to reproduce the fails on
> x86_64-linux: the linker does optimize away the functions that are not used.
>
> Tha
On Thu, Nov 19, 2015 at 05:31:32PM -0800, Steve Kargl wrote:
> On Thu, Nov 19, 2015 at 04:58:36PM -0800, Steve Kargl wrote:
> > + else
> > +{
> > + int dm;
> > +
> > + if (dim)
> > + {
> > + if (!gfc_is_constant_expr (dim))
> > + return NULL;
> > +
> > + dm = mpz_get_
BTW, I'm with whoever said absolutely no way to the idea of making
automatic changes like this as part of a commit hook.
I think the whitespace change can go in if it hasn't already, but I
think the other one still has enough problems that I'll say - leave it
for the next stage 1.
@@ -178,8
I1 is def_insn, I3 is cand->insn. tmp_reg is 'ax'. What we want to do
is reject this transformation
because the destination of def_insn (aka I1), that is 'ax', is not the
operand of the extend operation
in cand->insn (aka I3). As you said, rtx_equal won't work on just
SET_SRC (PATTERN (cand->insn)
On Thu, Nov 19, 2015 at 04:58:36PM -0800, Steve Kargl wrote:
> + else
> +{
> + int dm;
> +
> + if (dim)
> + {
> + if (!gfc_is_constant_expr (dim))
> + return NULL;
> +
> + dm = mpz_get_si (dim->value.integer);
> + }
> + else
> + dm = 1;
> +
> +
The attached patch provides a partial implementation for
the simplification for CSHIFT. It is partial in that it
only applies to rank 1 arrays. For arrays with rank > 1,
gfc_simplify_cshift will issue an error. Here, the intent
is that hopefully someone that knows what they are doing
with supply
Minor fix, committed.
2015-11-19 DJ Delorie
* config/msp430/lib2hw_mul.S: Fix alignment.
Index: libgcc/config/msp430/lib2hw_mul.S
===
--- libgcc/config/msp430/lib2hw_mul.S (revision 230632)
+++ libgcc/config/msp430/lib
On Thu, Nov 19, 2015 at 4:08 AM, Kyrill Tkachov wrote:
> Hi Andrew,
>
> On 17/11/15 22:10, Andrew Pinski wrote:
>>
>> To Add support for -mcpu=thunderxt88pass1, I needed to fix up a few
>> things in the support for -mcpu=native. First was I wanted to do the same
>> cleanup that was done for some
---
gcc/testsuite/gfortran.dg/graphite/pr68335.f90 | 45 ++
1 file changed, 45 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/graphite/pr68335.f90
diff --git a/gcc/testsuite/gfortran.dg/graphite/pr68335.f90
b/gcc/testsuite/gfortran.dg/graphite/pr68335.f90
new
---
gcc/graphite-scop-detection.c | 6 +-
gcc/testsuite/gcc.dg/graphite/pr68428.c | 23 +++
2 files changed, 28 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.dg/graphite/pr68428.c
diff --git a/gcc/graphite-scop-detection.c b/gcc/graphite-sco
This turns out to be because we represent sizeof... as a sizeof a pack
expansion internally, and we generated a full new pack expansion one
element at a time rather than just look at how many elements there were
in the argument pack.
We already had an optimization in tsubst_parameter_pack to r
On 11/19/2015 02:44 PM, Martin Sebor wrote:
On 11/18/2015 09:26 PM, Jason Merrill wrote:
The rs6000 target was hitting a bootstrap failure due to
-Werror=type-limits. Since warn_tautological_cmp and other warnings
avoid warning if one of the operands comes from a macro, I thought it
would make
I've committed this patch to trunk, which adds weak symbol support to PTX. PTX
supports weak definitions but not weak declarations, so some of the tests need
explicitly skipping, however the overall change is for the better.
I did discover a bug in the PTX JIT, in that it resolved weak definit
On Thu, 19 Nov 2015, Ed Smith-Rowland wrote:
> Testing coverage is growing.
> I starting to build check_inf tests for everyone (but they aren't in the
> patch.
> I'll look at musl to see how you do check_denorm, etc.
FWIW, in glibc I've systematically put special cases and a representative
range
On 11/05/2015 06:09 PM, Evandro Menezes wrote:
2015-10-25 Evandro Menezes
gcc/
* config/aarch64/aarch64-cores.def: Use the Exynos M1 cost model.
* config/aarch64/aarch64.c (exynosm1_addrcost_table): New
variable.
(exynosm1_regmove_cost): Likewise.
(exynosm1_ve
On 11/10/2015 11:54 AM, Evandro Menezes wrote:
2015-11-10 Evandro Menezes
gcc/
* config/aarch64/aarch64-cores.def: Use the Exynos M1 sched model.
* config/aarch64/aarch64.md: Include "exynos-m1.md".
* config/arm/arm-cores.def: Use the Exynos M1 sched model.
* co
On 11/12/2015 11:32 AM, Evandro Menezes wrote:
On 11/12/2015 09:39 AM, Evandro Menezes wrote:
On 11/12/2015 08:55 AM, James Greenhalgh wrote:
On Tue, Nov 10, 2015 at 11:50:12AM -0600, Evandro Menezes wrote:
2015-11-10 Evandro Menezes
gcc/
* config/aarch64/aarch64.md (predic
On 11/05/2015 02:51 PM, Evandro Menezes wrote:
2015-11-05 Evandro Menezes
gcc/
* config/aarch64/aarch64.c (aarch64_override_options_internal):
Increase loop peeling limit.
This patch increases the limit for the number of peeled insns. With
this change, I noticed no major re
On 10/30/2015 05:24 AM, Marcus Shawcroft wrote:
On 20 October 2015 at 00:40, Evandro Menezes wrote:
In the existing targets, it seems that it's always faster to zero up a DF
register with "movi %d0, #0" instead of "fmov %d0, xzr".
This patch modifies the respective pattern.
Hi Evandro,
This
On Thu, 19 Nov 2015, Marek Polacek wrote:
> On Wed, Nov 18, 2015 at 09:14:46PM +, Joseph Myers wrote:
> > remove_c_maybe_const_expr doesn't seem to be quite what you want. Apart
> > from this not being a case covered by the comment on the function, you're
> > ignoring the possibility of the
OK, thanks.
Jason
---
gcc/graphite-isl-ast-to-gimple.c | 96 ++--
1 file changed, 62 insertions(+), 34 deletions(-)
diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c
index 3e0907d..91bda33 100644
--- a/gcc/graphite-isl-ast-to-gimple.c
+++ b/gcc/gra
Thanks for the explanation, it is much clearer.
So here is a the more limited patch.
Tested under Linux x86_64.
Ok to commit ?
François
On 18/11/2015 13:27, Jonathan Wakely wrote:
> On 17/11/15 20:49 +0100, François Dumont wrote:
>> On 16/11/2015 11:29, Jonathan Wakely wrote:
>>> Not doing th
On 11/15/2015 12:01 AM, David Malcolm wrote:
As with the C frontend, there's an issue with tree nodes that
don't have locations: VAR_DECL, INTEGER_CST, etc:
int test (int foo)
{
return foo * 100;
^^^ ^^^
}
where we'd like to access the source spelling ranges of the e
Fixed in r230625.
David, please test on your systems, we were not able to reproduce the fails on
x86_64-linux: the linker does optimize away the functions that are not used.
Thanks,
Sebastian
Aditya K wrote:
> Thanks for the update. I'll fix that asap.
>
>
> -Aditya
>
>
> ---
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68448
https://bugzilla.redhat.com/show_bug.cgi?id=1279406
echo -e '#include \nint main(){std::vector l;\nreturn 0;}'|g++ -g
-Wall -x c++ -;gdb -q ./a.out -batch -ex 'b 3' -ex r -ex 'p l' -ex r -ex 'p l'
Actual:
[...]
$1 = std::vector of length 0,
On 11/19/2015 07:40 AM, Jakub Jelinek wrote:
@@ -4502,6 +4509,7 @@ c_parse_final_cleanups (void)
locus_at_end_of_parsing = input_location;
at_eof = 1;
+ defer_mangling_aliases = false;
Let's clear this in generate_mangling_aliases rather than here. OK with
that change.
Jason
On 11/19/2015 09:44 PM, Bernd Schmidt wrote:
> It's one option, but it doesn't seem like the best one either. I was
> thinking of something not dissimilar to your approach, but with fewer
> bells and whistles. My class registrator would look something like this:
>
> static list test_callbacks;
>
On 11/18/2015 09:26 PM, Jason Merrill wrote:
The rs6000 target was hitting a bootstrap failure due to
-Werror=type-limits. Since warn_tautological_cmp and other warnings
avoid warning if one of the operands comes from a macro, I thought it
would make sense to do that here as well.
The also dis
On 11/18/2015 07:15 AM, Nick Clifton wrote:
Hi Guys,
I recently discovered a bug in the current Redundant Extension
Elimination optimization. If the candidate extension instruction
increases the number of hard registers used, the pass does not check
to see if these extra registers a
On 19 November 2015 at 17:54, Jeff Law wrote:
>> But there were a couple of patches from you some time ago, for
>> example: http://permalink.gmane.org/gmane.comp.gcc.patches/343476
>>
>> What happened with those?
>
> On hold pending fixing the type-limits warning placement. Essentially that
> has
in adding the complex double support I noticed some existing tests had commented
out sequences. These were broken tests
a) the multiplication reduction assumed that 0 * 99! was numerically stable in
the face of arbitrary re-association. While it did guess that results might
vary, it used an
On 11/19/2015 07:08 PM, David Malcolm wrote:
gcc_assert terminates the process and no further testing is done,
whereas the approach the kit tries to run as much of the testsuite as
possible, and then fail if any errors occurred.
Yeah, but let's say someone is working on bitmaps and one of the b
On Wed, Nov 18, 2015 at 09:14:46PM +, Joseph Myers wrote:
> remove_c_maybe_const_expr doesn't seem to be quite what you want. Apart
> from this not being a case covered by the comment on the function, you're
> ignoring the possibility of the side effects in the
> C_MAYBE_CONST_EXPR_PRE. So
On 11/19/2015 08:34 AM, Nick Clifton wrote:
Hi Bernd,
I had a look around. There's code testing HARD_REGNO_NREGS in
ree.c:combine_set_extension. It's inside #if 0, and labelled
"temporarily disabled". See if enabling that helps you? (Jeff, that #if
0 was added by you).
I suspect that the code
On 11/18/2015 06:22 PM, Torvald Riegel wrote:
The EH scheme that we had been using for TM / libitm doesn't work
properly. We fail to handle throwing exceptions whose constructors may
throw themselves. We also do not clean up properly in all situations
when a transactions abort while being in th
On 11/19/2015 09:35 AM, Ryan Burn wrote:
This fixes an issue where the return type of an auto-deduced function gets
classified as a parameter pack if it's called in a decltype expression
inside of a type expansion.
Thanks! Do you have a copyright assignment on file with the FSF? This
patch i
On Nov 19, 2015, at 10:08 AM, David Malcolm wrote:
> gcc_assert terminates the process and no further testing is done,
> whereas the approach the kit tries to run as much of the testsuite as
> possible, and then fail if any errors occurred.
Running as much as possible is desirable over stopping a
On Thu, 2015-11-19 at 18:35 +0100, Bernd Schmidt wrote:
> In general I'm much happier with this approach, and I think this series
> is close to ready, but I want to bring up some questions that could use
> wider discussion.
> > This patch adds a selftest.h/.c to gcc, with an API loosely
> > mode
On 11/19/2015 10:18 AM, Bernd Schmidt wrote:
On 11/19/2015 06:06 PM, Jeff Law wrote:
Frankly, the overall structure of ree is a mess -- I've found it
incredibly difficult to follow every time I've had to look at it.
Yeah, no kidding. The check seems to be in the wrong place - it's done
very l
On 11/19/2015 10:48 AM, Manuel López-Ibáñez wrote:
On 19 November 2015 at 17:09, Jeff Law wrote:
The even longer term direction for this code is to separate out the
type-limits warning from the canonicalization and shortening. I've got a
blob of code form Kai that goes in that direction, but i
On 19 November 2015 at 17:09, Jeff Law wrote:
> The even longer term direction for this code is to separate out the
> type-limits warning from the canonicalization and shortening. I've got a
> blob of code form Kai that goes in that direction, but it needs more
> engineering around it.
>
> Ideall
On 11/19/2015 12:54 PM, Martin Liška wrote:
> ContinuationIndentWidth: 2
> -ForEachMacros:
> ['_FOR_EACH','_FOR_EACH_1','FOR_EACH_AGGR_INIT_EXPR_ARG','FOR_EACH_ALIAS','FOR_EACH_ALLOCNO','FOR_EACH_ALLOCNO_OBJECT','FOR_EACH_ARTIFICIAL_DEF','FOR_EACH_ARTIFICIAL_USE','FOR_EACH_BB_FN','FOR_EACH_BB_REV
On 11/19/2015 10:33 AM, Torvald Riegel wrote:
On Thu, 2015-11-19 at 11:18 -0600, Peter Bergner wrote:
On Thu, 2015-11-19 at 09:35 -0600, Torvald Riegel wrote:
Tested using the libitm testsuite on x86_64-linux.
Tested on powerpc64le-linux with no regressions and I confirmed
the new eh-5.C test
On 11/19/2015 06:58 AM, Bernd Schmidt wrote:
On 11/19/2015 11:16 AM, Martin Liška wrote:
You are right, however as the original coding style was really broken,
it was much easier
to use the tool and clean-up fall-out.
Waiting for thoughts related to v2.
Better, but still some oddities. I hope
In general I'm much happier with this approach, and I think this series
is close to ready, but I want to bring up some questions that could use
wider discussion.
This patch adds a selftest.h/.c to gcc, with an API loosely
modelled on gtest (though without the use of CamelCase): it
supports eno
On Thu, 2015-11-19 at 11:18 -0600, Peter Bergner wrote:
> On Thu, 2015-11-19 at 09:35 -0600, Torvald Riegel wrote:
> > Tested using the libitm testsuite on x86_64-linux.
>
> Tested on powerpc64le-linux with no regressions and I confirmed
> the new eh-5.C test case passes.
Thanks. Then I'll commi
On 11/18/2015 11:20 PM, Senthil Kumar Selvaraj wrote:
On Wed, Nov 18, 2015 at 09:36:21AM +0100, Richard Biener wrote:
Otherwise ok.
See modified patch below. If you think vrp98.c is unnecessary, feel free
to dump it :).
If ok, could you commit it for me please? I don't have commit access.
R
On November 19, 2015 6:12:30 PM GMT+01:00, Bernd Schmidt
wrote:
>On 11/19/2015 05:31 PM, Ilya Enkovich wrote:
>> Currently we fold all memcpy/memmove calls with a known data size.
>> It causes two problems when used with Pointer Bounds Checker.
>> The first problem is that we may copy pointers as
On 11/19/2015 06:06 PM, Jeff Law wrote:
Frankly, the overall structure of ree is a mess -- I've found it
incredibly difficult to follow every time I've had to look at it.
Yeah, no kidding. The check seems to be in the wrong place - it's done
very late when we're replacing things, and IMO we s
On Thu, 2015-11-19 at 09:35 -0600, Torvald Riegel wrote:
> Tested using the libitm testsuite on x86_64-linux.
Tested on powerpc64le-linux with no regressions and I confirmed
the new eh-5.C test case passes.
Peter
On 11/19/2015 05:31 PM, Ilya Enkovich wrote:
Currently we fold all memcpy/memmove calls with a known data size.
It causes two problems when used with Pointer Bounds Checker.
The first problem is that we may copy pointers as integer data
and thus loose bounds. The second problem is that if we inl
On 11/18/2015 09:33 PM, David Edelsohn wrote:
On Wed, Nov 18, 2015 at 11:26 PM, Jason Merrill wrote:
The rs6000 target was hitting a bootstrap failure due to
-Werror=type-limits. Since warn_tautological_cmp and other warnings avoid
warning if one of the operands comes from a macro, I thought i
On 11/19/2015 09:53 AM, Bernd Schmidt wrote:
On 11/19/2015 04:34 PM, Nick Clifton wrote:
Hi Bernd,
I had a look around. There's code testing HARD_REGNO_NREGS in
ree.c:combine_set_extension. It's inside #if 0, and labelled
"temporarily disabled". See if enabling that helps you? (Jeff, that #if
Jeff approved an earlier version of this (as
unittests/test-rtl.c):
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03302.html
> OK if/when prereqs are approved. Minor twiddling if we end up
> moving it elsewhere or standardizing/reducing header files is
>pre-approved.
This version puts the tests i
On 11/19/2015 05:13 PM, Michael Matz wrote:
in an enabled-checking compiler gcc_checking_assert is always executed.
If that depends on things having happened under flag_checking being true,
but it's actually false during runtime due to -fno-checking things go
awry, like segfaulting in this case.
Jeff conditionally approved an earlier version of this (as
unittests/test-locations.c):
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03307.html
> OK if/when prereqs are approved. Minor twiddling if we end up
> moving it elsewhere or standardizing/reducing header files is
> pre-approved.
>
> Cons
On 11/19/2015 04:34 PM, Nick Clifton wrote:
Hi Bernd,
I had a look around. There's code testing HARD_REGNO_NREGS in
ree.c:combine_set_extension. It's inside #if 0, and labelled
"temporarily disabled". See if enabling that helps you? (Jeff, that #if
0 was added by you).
I suspect that the code
On Mon, 2015-11-16 at 19:17 +0100, Bernd Schmidt wrote:
> So Jeff and I just had a chat, and we came up with some thoughts about
> how to proceed. I think we both agree that it would be good to have a
> special testing backend, along with frontends designed to be able to
> read in gimple or rtl
Jeff approved an older version of this:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03285.html
with:
> Unless there's a good reason, drop the presumably redundant tests
> and this is OK. Save preapprovald for these changes as the bitmap
> patch.
This version removes the redundant tests, and mo
Jeff approved an earlier version of this (as
unittests/test-functions.c):
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03310.html
with:
> There's some if (0) code in here that needs to be eliminated.
(done)
> The RTL case in particular is probably stretching the limits of what
> we can do wit
Jeff approved an earlier version of this (as
unittests/test-vec.c):
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03308.html
> OK if/when prereqs are approved. Minor twiddling if we end up
> moving it elsewhere or standardizing/reducing header files is
> pre-approved.
This version puts the tests
Jeff approved an earlier version of this (as
unittests/test-ggc.c):
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03306.html
> Not terribly happy with that counter to used to create a big list
> to detect recursion. But I'm not offhand sure how to avoid without
> exposing more of the ggc system t
Jeff approved an older version of this (as a separate
unittests/test-folding.c):
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03305.html
> OK if/when prereqs are approved. Minor twiddling if we end up
> moving it elsewhere or standardizing/reducing header files
> is pre-approved.
gcc/ChangeLog:
Jeff approved an earlier version of this (as
unittests/test-hash-set.c):
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03300.html
> OK if/when prereqs are approved. Minor twiddling if we end up
> moving it elsewhere or standardizing/reducing header files is
> pre-approved.
This version moves the
Jeff approved an earlier version of this:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03295.html
> OK if/when prereqs are approved. Minor twiddling if we end up
> moving it elsewhere or standardizing/reducing header files
> is pre-approved.
gcc/ChangeLog:
* et-forest.c: Include "selfte
Jeff approved an earlier version of this (as
unittests/test-tree.c):
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03303.html
> OK if/when prereqs are approved. Minor twiddling if we end up
> moving it elsewhere or standardizing/reducing header files is
> pre-approved.
This version puts the tests
Upon porting from gtest.h to selftest.h I ran into this warning which
is fatal during bootstrap:
In file included from ../../../src/gcc/toplev.c:89:0:
../../../src/gcc/function-tests.c: In member function ‘virtual void
{anonymous}::function_test_fndecl_int_void::run()’:
../../../src/gcc/selftest.
This is effectively v4 of the unittests proposal; for the earlier
versions see:
* v1: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00765.html
* v2: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01224.html
* v3: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02947.html
This patch adds a selftest
Jeff approved an earlier version of this (as
unittests/test-hash-map.c):
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03301.html
> OK if/when prereqs are approved. Minor twiddling if we end up
> moving it elsewhere or standardizing/reducing header files is
> pre-approved.
This version moves the
Jeff approved an earlier version of this (as
unittests/test-gimple.c):
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03304.html
> Comment indicates addition. But code actually generates a
> MULT_EXPR. Please fix.
Fixed
> OK if/when prereqs are approved. Minor twiddling if we end
> up moving it e
Jeff pre-approved the plugin version of this (as a new
file unittests/test-bitmap.c):
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03284.html
with:
> OK if/when prereqs are approved. Minor twiddling if we end up moving it
> elsewhere or standardizing/reducing header files is pre-approved.
This
While porting the fortran acc routine changes from gomp4 to trunk, I
noticed that device was listed in the acc routine clause mask. That is
incorrect; it should be device_type not device. I fixed that problem in
the trunk patch submission. Here's the corresponding fix and test case
that I applied t
Hi,
Currently we fold all memcpy/memmove calls with a known data size.
It causes two problems when used with Pointer Bounds Checker.
The first problem is that we may copy pointers as integer data
and thus loose bounds. The second problem is that if we inline
memcpy, we also have to inline bounds
This patch extends the existing support for acc routines in fortran.
It's a little bit more invasive than what I remembered, but it's still
fairly straightforward. Basically, it adds support for the following:
- name routines
- gang, worker, vector and seq clauses
In addition, I've also taught
Jakub,
Here's the updated version of the Fortran changes. More test
cases have been added as well as the issues that Cesar
pointed on in error checking have been addressed (Thanks).
I've also addressed the issue, described below, in dealing
with declare directives when found within a BLOCK constr
Hi Michael,
On 19/11/15 16:13, Michael Matz wrote:
Hi,
in an enabled-checking compiler gcc_checking_assert is always executed.
If that depends on things having happened under flag_checking being true,
but it's actually false during runtime due to -fno-checking things go
awry, like segfaulting i
Hi,
in an enabled-checking compiler gcc_checking_assert is always executed.
If that depends on things having happened under flag_checking being true,
but it's actually false during runtime due to -fno-checking things go
awry, like segfaulting in this case. The fix is obvious and checked in
a
On 19 Nov 16:46, Bernd Schmidt wrote:
> On 11/19/2015 03:28 PM, Ilya Enkovich wrote:
> >This is a refactoring patch discussed in another thread [1]. It gets
> >rid of CODE_FOR_nothing usage in optabs-tree.c by introducing boolean
> >predicated in optabs-query. Bootstrapped and regtesed on
> >x86_
On Thu, Nov 19, 2015 at 06:47:28PM +0300, Ilya Verbin wrote:
> I will add this:
>
> diff --git a/liboffloadmic/plugin/libgomp-plugin-intelmic.cpp
> b/liboffloadmic/plugin/libgomp-plugin-intelmic.cpp
> index 6ee585e..f8c1725 100644
> --- a/liboffloadmic/plugin/libgomp-plugin-intelmic.cpp
> +++ b/l
On Thu, Nov 19, 2015 at 02:26:50PM +, Julian Brown wrote:
> OK, thanks -- as to what the standard says, it's so ill-specified in
> this area that nothing can be learned about the behaviour of offloaded
> regions within host_data constructs, and my question about that on the
> technical mailing
On Wed, 18 Nov 2015, Jeff Law wrote:
> Given that gnu-indent seems to muck up C++ badly in my
> experience, clang-format may be a better long term solution. I'd really like
> to get to a point one day where formatting is a commit hook so that things are
> always kept properly formatted.
I hope yo
On Thu, Nov 19, 2015 at 14:33:06 +0100, Jakub Jelinek wrote:
> On Mon, Nov 16, 2015 at 08:33:28PM +0300, Ilya Verbin wrote:
> > diff --git a/liboffloadmic/plugin/libgomp-plugin-intelmic.cpp
> > b/liboffloadmic/plugin/libgomp-plugin-intelmic.cpp
> > index 772e198..6ee585e 100644
> > --- a/liboffloa
On 11/19/2015 03:28 PM, Ilya Enkovich wrote:
This is a refactoring patch discussed in another thread [1]. It gets
rid of CODE_FOR_nothing usage in optabs-tree.c by introducing boolean
predicated in optabs-query. Bootstrapped and regtesed on
x86_64-unknown-linux-gnu.
Looks pretty reasonable, b
On Thu, 2015-11-19 at 09:35 -0600, Torvald Riegel wrote:
> The EH scheme that we had been using for TM / libitm doesn't work
> properly. We fail to handle throwing exceptions whose constructors may
> throw themselves. We also do not clean up properly in all situations
> when a transactions abort
On 11/19/2015 04:35 PM, Dhole wrote:
> On 11/17/2015 12:26 AM, Joseph Myers wrote:
>> fprintf to stderr is never appropriate. All diagnostics should go through
>> a diagnostic function that properly causes the message to be translated.
>>
>> If you want a fatal error (exit immediately after givin
On 11/17/2015 12:26 AM, Joseph Myers wrote:
> fprintf to stderr is never appropriate. All diagnostics should go through
> a diagnostic function that properly causes the message to be translated.
>
> If you want a fatal error (exit immediately after giving the message
> rather than continuing co
Hi Bernd,
I had a look around. There's code testing HARD_REGNO_NREGS in
ree.c:combine_set_extension. It's inside #if 0, and labelled
"temporarily disabled". See if enabling that helps you? (Jeff, that #if
0 was added by you).
I suspect that the code was disabled because it prevented too many
On Mon, Nov 16, 2015 at 06:40:43PM +0300, Ilya Verbin wrote:
> Here is WIP patch, not for check-in. There are still many FIXMEs, which I am
> going to resolve, however target-link-1.c testcase pass.
> Is this approach correct? Any comments on FIXMEs?
>
>
> diff --git a/gcc/c/c-parser.c b/gcc/c/
OK.
Jason
On 19/11/15 15:00, Kyrill Tkachov wrote:
On 19/11/15 14:41, Segher Boessenkool wrote:
On Thu, Nov 19, 2015 at 01:38:53PM +, Kyrill Tkachov wrote:
That is troublesome. Could you look deeper?
Yes.
Thanks.
So the bad case is when we're in subst and returning a CLOBBER of zero
and 'from'
Hi Richard,
I send you updated version of patch which contains fixes you mentioned
and additional early exit in
register_edge_assert_for() for gcond with vector comparison - it tries
to produce assert for
if (vect != {0,0,0,0}) but can't create such constant. This is not
essential since this is
Committed to trunk (as r230609) as obvious, having
verified that the docs build.
gcc/ChangeLog:
* doc/gty.texi (Support for inheritance): Fix missing
parentheses in example.
---
gcc/doc/gty.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/gty.te
On 19.11.2015 09:07, Richard Biener wrote:
On Wed, 18 Nov 2015, Matthias Klose wrote:
On 12.10.2015 12:58, Richard Biener wrote:
This backports the patch to allow bootstrapping with ISL 0.15 to the
GCC 5 branch (the GCC 4.9 branch will require backporting of some
dependencies).
I don't thin
On 2015.11.19 at 15:38 +0100, Martin Liška wrote:
>
> In last two weeks I've removed couple of memory leaks, mainly tight to
> middle-end. Currently, a user of the GCC compiler can pass
> '--enable-checking=valgrind' configure option that will run all
> commands within valgrind environment, but a
Thanks for the update. I'll fix that asap.
-Aditya
> Date: Thu, 19 Nov 2015 08:36:58 -0500
> Subject: Re: [PATCH 1/2] [graphite] Move codegen related functions to
> graphite-isl-ast-to-gimple.c
> From: dje@gmail.com
> To: hiradi...@msn.com; aditya..
On 19/11/15 14:41, Segher Boessenkool wrote:
On Thu, Nov 19, 2015 at 01:38:53PM +, Kyrill Tkachov wrote:
That is troublesome. Could you look deeper?
Yes.
Thanks.
So the bad case is when we're in subst and returning a CLOBBER of zero
and 'from' is (reg/v:SI 80 [ x ]) and 'to' is (zero_e
On November 19, 2015 3:57:03 PM GMT+01:00, Marek Polacek
wrote:
>This fixes a failure to optimize division by an unsigned. The comment
>before
>the condition I'm fixing says "When vr0.max < 0, vr1.min != 0 and ..."
>but
>"&& !compare_values (vr1.min, zero)" actually ensures that vr1.min is
>zero
1 - 100 of 137 matches
Mail list logo
