On 23/11/15 16:24, Jakub Jelinek wrote:
On Mon, Nov 23, 2015 at 04:21:34PM +0300, Maxim Ostapenko wrote:
Yeah, right. I've asked about kernel headers just to make sure I correctly
understand the issue.
Actually, I see such code in
lib/sanitizer_common/sanitizer_platform_limits_posix.cc:
#if de
Calling rs6000_is_valid_and_mask on a reg instead of on a const_int is
not a good idea, as PR68332 and PR67677 as well as testing with
--enable-checking=yes,rtl show. Fix this.
Bootstrapped and tested on powerpc64-linux. Is this okay for trunk?
Segher
2015-11-24 Segher Boessenkool
Some users of is_parallel_of_n_reg_sets disregard the clobbers in a
parallel after it has returned "yes, this is a parallel of N sets and
maybe some clobbers". But combine uses a clobber of const0_rtx to
indicate substitution failure, so this leads to disaster.
Fix this by checking for such speci
Hi,
the attached testcase shows that we can not use types_compatible_p to check
if two declarations are compatible in cross-language decl merging.
For example Fortran's C_SIZE_T should be compatible with C size_t while
one is signed and other unsigned.
This patch simply makes us to use TBAA and si
> On November 23, 2015 5:50:25 PM GMT+01:00, Jan Hubicka wrote:
> >>
> >> I think it also causes the following and one related ICE
> >>
> >> FAIL: gcc.dg/vect/pr62021.c -flto -ffat-lto-objects (internal
> >compiler
> >> error)
> >>
> >>
> >/space/rguenther/src/svn/trunk3/gcc/testsuite/gcc.dg/v
On Mon, Nov 23, 2015 at 9:53 PM, H.J. Lu wrote:
> On Mon, Nov 23, 2015 at 7:22 PM, Patrick Palka wrote:
>> On Mon, Nov 23, 2015 at 3:53 PM, H.J. Lu wrote:
>>> On Mon, Nov 23, 2015 at 1:57 AM, Richard Biener
>>> wrote:
On Sat, Nov 21, 2015 at 12:46 AM, H.J. Lu wrote:
> On Fri, Nov 20,
On Mon, Nov 23, 2015 at 7:22 PM, Patrick Palka wrote:
> On Mon, Nov 23, 2015 at 3:53 PM, H.J. Lu wrote:
>> On Mon, Nov 23, 2015 at 1:57 AM, Richard Biener
>> wrote:
>>> On Sat, Nov 21, 2015 at 12:46 AM, H.J. Lu wrote:
On Fri, Nov 20, 2015 at 2:17 PM, Jason Merrill wrote:
> On 11/20/20
From: Trevor Saunders
Hi,
This fixes several leaks where a hash_map user expected deleting the map to
destruct the value part of entries as well as the key. A couple of these bugs
have already been fixed, but there are more of them for example some of the
sanitizer code, and tree-if-conv.c). T
From: Trevor Saunders
Hi,
this is pretty trivial cleanup after the previous patch, but could wait for
next stage 1 if people don't like the very small risk.
boostrappped + regtested on x86_64-linux-gnu, ok?
Trev
gcc/ChangeLog:
2015-11-20 Trevor Saunders
* tree-ssa-uncprop.c (stru
On 11/16/2015 05:07 PM, Alexandre Oliva wrote:
The check is not in my patch, indeed. That's because the previous block
performs the runtime check, and it only lets through two cases: the one
we handle, and the one nobody uses.
That was the conclusion I was starting to come to, but expressed so
On 11/23/2015 01:54 PM, Nathan Sidwell wrote:
On 11/23/15 15:41, Jeff Law wrote:
In the 'put' function, why not just make all targets go through
putchar? It's not like this is performance critical code and I
don't think it compromises any of the tests, does it?
I contemplated that, but wond
> I don't understand why we need this (testcase?) because get_alias_set ()
> is supposed to do the alias-set of pointer globbing for us.
Hi,
After some experimentation I managed to derive self contained testcase (other
than GCC itself).
struct a/b/c gets the same TYPE_CANONICAL which is different
Hi,
this patch fixes ICE triggered by extra sanity check I added while fixing
another type checking ICE during Ada bootstrap.
The canonical types of verctor typs are not constructed correctly. If
make_vector_type is called with INNERTYPE being a variant (say const char),
it builds first the main
On Mon, Nov 23, 2015 at 3:53 PM, H.J. Lu wrote:
> On Mon, Nov 23, 2015 at 1:57 AM, Richard Biener
> wrote:
>> On Sat, Nov 21, 2015 at 12:46 AM, H.J. Lu wrote:
>>> On Fri, Nov 20, 2015 at 2:17 PM, Jason Merrill wrote:
On 11/20/2015 01:52 PM, H.J. Lu wrote:
>
> On Tue, Nov 17, 2015 a
On Sat, Nov 21, 2015 at 1:39 AM, Richard Earnshaw
wrote:
> On 20/11/15 08:31, Bin.Cheng wrote:
>> On Thu, Nov 19, 2015 at 10:32 AM, Bin.Cheng wrote:
>>> On Tue, Nov 17, 2015 at 6:08 PM, James Greenhalgh
>>> wrote:
On Tue, Nov 17, 2015 at 05:21:01PM +0800, Bin Cheng wrote:
> Hi,
> GI
Hi Richard,
Thanks for you comments. I am attaching an updated patch with details
below.
On 19/11/15 02:06, Richard Biener wrote:
> On Wed, Nov 18, 2015 at 3:04 PM, Richard Biener
> wrote:
>> On Sat, Nov 14, 2015 at 2:15 AM, Kugan
>> wrote:
>>>
>>> Attached is the latest version of the patch.
On Thu, Nov 19, 2015 at 03:20:22PM +, Kyrill Tkachov wrote:
> Hmmm, so the answer to that is a bit further down the validate_replacement:
> path.
> It's the code after the big comment:
> /* See if this is a PARALLEL of two SETs where one SET's destination is
> a register that is unused
Segher Boessenkool reminded me that the lround define_expand should not have
the wa and =d constraints. This patch fixes that problem. The little endian
power8 system has passed the bootstrap and make check tests.
The big endian power7 system is chugging away on the stage2 build if I use a
more
On Mon, Nov 23, 2015 at 4:56 PM, Michael Meissner
wrote:
> David ping'ed me on internal IRC, and I had a thinko in terms of the use of
> the
> mode attribute. In some of the uses (such as abs, smax, etc.) we want to
> use ISA 2.06 instructions on SFmode, while in other uses (add, mul, etc.) we
On 11/24/2015 12:09 AM, Mikhail Maltsev wrote:
The attached patch fixes a problem introduced in r229567: the assertion
gcc_assert (is_sse);
is checked if flag_checking is false, and this causes an ICE when compiling with
-fno-checking.
Ok.
Bernd
As I mentioned in a prior message on the subject, this is only a problem
when the source/dest of the extension are the same. When the
source/dest of the extension are different, we only optimize when the
original set and extension are in the same block and we verify that all
affected registers ar
---
gcc/graphite-optimize-isl.c | 20 +---
gcc/graphite-poly.c | 2 -
gcc/graphite-poly.h | 3 -
gcc/graphite-sese-to-poly.c | 235 ++--
4 files changed, 58 insertions(+), 202 deletions(-)
diff --git a/gcc/graphite-optimize-isl.c b/gcc/
Hi!
The attached patch fixes a problem introduced in r229567: the assertion
gcc_assert (is_sse);
is checked if flag_checking is false, and this causes an ICE when compiling with
-fno-checking.
Bootstrapped and regtested on x86_64-pc-linux-gnu. OK for trunk?
--
Regards,
Mikhail Maltsev
gc
> > > If you have any clue how to debug it further, I would be happy to try.
> > > That atree code is real software engineering treat BTW
> >
> > I'll have a look at some point, once things have stabilized a bit.
>
> OK, I will push out the remaining patches needed to get LTO into a shape to
> co
> > If you have any clue how to debug it further, I would be happy to try.
> > That atree code is real software engineering treat BTW
>
> I'll have a look at some point, once things have stabilized a bit.
OK, I will push out the remaining patches needed to get LTO into a shape to
compile gnat1 an
On Mon, Nov 23, 2015 at 02:48:37PM +0100, marxin wrote:
> gcc/ChangeLog:
>
> 2015-11-20 Martin Liska
>
> * ipa-devirt.c (ipa_devirt): Use auto_vec instead
> of a local-scope vec. Release final_warning_records.
> ---
> gcc/ipa-devirt.c | 5 +++--
> 1 file changed, 3 insertions(+),
> If you have any clue how to debug it further, I would be happy to try.
> That atree code is real software engineering treat BTW
I'll have a look at some point, once things have stabilized a bit.
--
Eric Botcazou
Just noticed that I forgot to crosspost this mail to the rtems-devel list.
If someone with commit rights could check and push the patches we might get it
into the next release.
Cheers,
Jan--- Begin Message ---
Hello,
The paperwork seems to have gone through.
Here is the patch again for the
David ping'ed me on internal IRC, and I had a thinko in terms of the use of the
mode attribute. In some of the uses (such as abs, smax, etc.) we want to
use ISA 2.06 instructions on SFmode, while in other uses (add, mul, etc.) we
want to use it only if we have the ISA 2.07 instrucitons.
I have s
PR 68496 points out a bug in the handling of reflect.Call calling a
function that returns a zero-sized type. libffi doesn't understand
zero-sized types, which don't exist in C, so they require special
handling. This patch fixes the problem. Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gn
On 08/31/2015 03:28 AM, Pierre-Marie de Rodat wrote:
On 07/20/2015 02:45 PM, Pierre-Marie de Rodat wrote:
On PowerPC targets with -mlongcall, most subprogram calls are turned
into indirect calls: the call target is read from a register even though
it is compile-time known. This makes it difficul
On 11/23/2015 08:53 AM, Pierre-Marie de Rodat wrote:
Do you think the other patches could make it before the branch? (if they
could, I will rebase+retest them as quick as possible).
Probably, yes. I can't find the DW_AT_static_link patch, though; it
doesn't seem to have been attached to you
On November 23, 2015 8:14:59 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>The patches that removed VEC_RSHIFT_EXPR regressed the first of these
>testcases on i?86/-msse2, because can_vec_perm_p returns false for
>that,
>and indeed as can_vec_perm_p is given only the mode and mask indices,
>there is
On Nov 23, 2015, at 3:13 AM, Joseph Myers wrote:
> On Sun, 22 Nov 2015, David Malcolm wrote:
>
>> Is there (or could there be) a precanned dg- directive to ask if ObjC is
>> available?
>
> I don't think so. Normal practice is that each language's tests are in
> appropriate directories for th
On November 23, 2015 6:09:33 PM GMT+01:00, Marek Polacek
wrote:
>On Mon, Nov 23, 2015 at 05:40:14PM +0100, Richard Biener wrote:
>> On November 23, 2015 5:31:11 PM GMT+01:00, Marek Polacek
> wrote:
>> >We blow up on the following testcase because we find ourselves
>passing
>> >[_13 + 1, INT_MAX]
On 08/31/2015 03:26 AM, Pierre-Marie de Rodat wrote:
On 07/25/2015 09:44 PM, Pierre-Marie de Rodat wrote:
This change makes GCC materialize subprogram renamings in Ada as
imported declarations (DW_TAG_imported_declarations). For instance,
procedure Foo renames Bar;
will output:
DW_T
On 11/23/15 15:41, Jeff Law wrote:
In the 'put' function, why not just make all targets go through putchar? It's
not like this is performance critical code and I don't think it compromises any
of the tests, does it?
I contemplated that, but wondered if someone would complain. I'm happy eith
On Mon, Nov 23, 2015 at 1:57 AM, Richard Biener
wrote:
> On Sat, Nov 21, 2015 at 12:46 AM, H.J. Lu wrote:
>> On Fri, Nov 20, 2015 at 2:17 PM, Jason Merrill wrote:
>>> On 11/20/2015 01:52 PM, H.J. Lu wrote:
On Tue, Nov 17, 2015 at 4:22 AM, Richard Biener
wrote:
>
> On Tue,
On 11/23/2015 12:50 PM, David Malcolm wrote:
On Mon, 2015-11-23 at 10:25 -0700, Jeff Law wrote:
On 11/23/2015 04:13 AM, Joseph Myers wrote:
On Sun, 22 Nov 2015, David Malcolm wrote:
Is there (or could there be) a precanned dg- directive to ask if ObjC is
available?
I don't think so. Normal
On 11/23/2015 01:16 PM, Nathan Sidwell wrote:
The gcc.dg/sso tests gratuitously fail on PTX because they use IO
facilities that don't exist there. This patch changes the dumping to
use the putchar function call (and not a macro), and not use fputs.
With this they all pass.
I'm not quite sure
On 23.11.2015 19:13, Joel Brobecker wrote:
In GCC zlib is only used for libjava; for binutils and gdb it is used when
building without --with-system-zlib. This just updates zlib from 1.2.7 to
1.2.8 (released in 2013). Applies cleanly, libjava still builds and doesn't
show any regressions in the
> diff --git a/gcc/c-family/cilk.c b/gcc/c-family/cilk.c
> index e75e20c..1167b2b 100644
> --- a/gcc/c-family/cilk.c
> +++ b/gcc/c-family/cilk.c
> @@ -844,6 +844,7 @@ gimplify_cilk_spawn (tree *spawn_p)
> call2, build_empty_stmt (EXPR_LOCATION (call1)));
>append_to_sta
The gcc.dg/sso tests gratuitously fail on PTX because they use IO facilities
that don't exist there. This patch changes the dumping to use the putchar
function call (and not a macro), and not use fputs.
With this they all pass.
I'm not quite sure where the maintainer boundaries lie for this
The core analysis was from Nick. Essentially:
(insn 44 (set (reg:QI r11) (mem:QI (reg:HI r20)))
(insn 45 (set (reg:QI r10) (mem:QI (reg:HI r18)))
[...]
(insn 71 (set (reg:HI r14) (zero_extend:HI (reg:QI r11)))
[...]
(insn 88 (set (reg:HI r10) (zero_extend:HI (reg:QI
On 11/23/2015 06:48 AM, marxin wrote:
gcc/cp/ChangeLog:
2015-11-23 Martin Liska
* parser.c (cp_parser_late_parsing_cilk_simd_fn_info):
Release tokens.
There's a vec of objects in cilk_simd_fn_info, so unless that vec is
copied elsewhere, we definitely want to release them be
On Mon, 2015-11-23 at 10:25 -0700, Jeff Law wrote:
> On 11/23/2015 04:13 AM, Joseph Myers wrote:
> > On Sun, 22 Nov 2015, David Malcolm wrote:
> >
> >> Is there (or could there be) a precanned dg- directive to ask if ObjC is
> >> available?
> >
> > I don't think so. Normal practice is that each la
gcc/testsuite/ChangeLog
+2015-10-27 Tsvetkova Alexandra
+
+ * gcc.target/i386/mpx/memmove.c: New test for __mpx_wrapper_memmove.
libmpx/ChangeLog
+2015-10-28 Tsvetkova Alexandra
+
+ * mpxrt/Makefile.am (libmpx_la_LDFLAGS): Add -version-info option.
+ * libmpxwrap/Makefile.am (libmpx_la_LDFLA
On 11/23/2015 12:07 PM, Marek Polacek wrote:
On Mon, Nov 23, 2015 at 05:57:54PM +0100, Jakub Jelinek wrote:
On Mon, Nov 23, 2015 at 11:53:40AM -0500, David Malcolm wrote:
Does the following look like the kind of thing you had in mind? (just
the tree.def part for now). Presumably usable for b
Hi!
The patches that removed VEC_RSHIFT_EXPR regressed the first of these
testcases on i?86/-msse2, because can_vec_perm_p returns false for that,
and indeed as can_vec_perm_p is given only the mode and mask indices,
there is nothing it can do about it. The former VEC_RSHIFT_EXPR
is a special VEC
---
gcc/graphite-poly.c| 1 -
gcc/graphite-poly.h| 6 +-
gcc/graphite-sese-to-poly.c| 103 ++---
gcc/graphite-sese-to-poly.h| 26 ---
gcc/graphite.c
---
gcc/graphite-isl-ast-to-gimple.c | 9 -
gcc/sese.c | 4
2 files changed, 13 deletions(-)
diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c
index 557c44c..30c3a21 100644
--- a/gcc/graphite-isl-ast-to-gimple.c
+++ b/gcc/graphite-
---
gcc/graphite-isl-ast-to-gimple.c| 2 ++
gcc/testsuite/gcc.dg/graphite/pr68493.c | 34 +
2 files changed, 36 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/graphite/pr68493.c
diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-t
On 11/21/2015 01:30 AM, Richard Biener wrote:
What happens if we remove the nops stripping from integer_zerop? Do other
integer predicates strip nops?
Many predicates do, but removing that doesn't break anything in the
testsuite. So, how about this?
commit b4714ac166ce22b54e89ebb860d5263
BTW for the LTO type merging issues one could probably just drop those types
and all derivations to alias set 0. But indeed rewriting them to pointers would
be better, especially for ABI compatibility.
The Ada ICE I get is:
Continuing.
+===GNAT BUG DETECTED=
On Mon, 2015-11-23 at 18:59 +0100, Bernd Schmidt wrote:
> On 11/23/2015 06:52 PM, David Malcolm wrote:
> > This patch fixes PR c/68473 by bulletproofing the new
> > diagnostic_show_locus implementation against ranges that finish before
> > they start (which can happen when using the C preprocessor)
> In GCC zlib is only used for libjava; for binutils and gdb it is used when
> building without --with-system-zlib. This just updates zlib from 1.2.7 to
> 1.2.8 (released in 2013). Applies cleanly, libjava still builds and doesn't
> show any regressions in the testsuite. Ok to apply (even if we
On 11/23/2015 06:52 PM, David Malcolm wrote:
This patch fixes PR c/68473 by bulletproofing the new
diagnostic_show_locus implementation against ranges that finish before
they start (which can happen when using the C preprocessor), falling
back to simply printing a caret.
Hmm, wouldn't it be bet
This patch fixes PR c/68473 by bulletproofing the new
diagnostic_show_locus implementation against ranges that finish before
they start (which can happen when using the C preprocessor), falling
back to simply printing a caret.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu; adds 7 new
PA
On 11/22/2015 09:37 PM, Matthias Klose wrote:
In GCC zlib is only used for libjava; for binutils and gdb it is used
when building without --with-system-zlib. This just updates zlib from
1.2.7 to 1.2.8 (released in 2013). Applies cleanly, libjava still
builds and doesn't show any regressions in
On 11/23/2015 04:13 AM, Joseph Myers wrote:
On Sun, 22 Nov 2015, David Malcolm wrote:
Is there (or could there be) a precanned dg- directive to ask if ObjC is
available?
I don't think so. Normal practice is that each language's tests are in
appropriate directories for that language, with run
> > You are right, TYPE_NONALIASED_COMPONENT is the wrong way. I will fix it
> > and try to come up with a testcase (TYPE_NONALIASED_COMPONENT is quite
> > rarely used beast)
>
> It's only used in Ada as far as I know, but is quite sensitive and quickly
> leads to wrong code if not handled prope
On Mon, Nov 23, 2015 at 05:40:14PM +0100, Richard Biener wrote:
> On November 23, 2015 5:31:11 PM GMT+01:00, Marek Polacek
> wrote:
> >We blow up on the following testcase because we find ourselves passing
> >[_13 + 1, INT_MAX] as a vr1 to extract_range_from_multiplicative_op_1;
> >that's bad bec
On November 23, 2015 5:50:25 PM GMT+01:00, Jan Hubicka wrote:
>>
>> I think it also causes the following and one related ICE
>>
>> FAIL: gcc.dg/vect/pr62021.c -flto -ffat-lto-objects (internal
>compiler
>> error)
>>
>>
>/space/rguenther/src/svn/trunk3/gcc/testsuite/gcc.dg/vect/pr62021.c:7:1:
>
>
> Please in future leave patches for review again if you do such
> big changes before committing...
Uhm, sorry, next time I will be more cureful. It seemed rather easy after
debugging it but indeed it is somewhat surprising issue.
>
> I don't understand why we need this (testcase?) because ge
On Mon, Nov 23, 2015 at 05:57:54PM +0100, Jakub Jelinek wrote:
> On Mon, Nov 23, 2015 at 11:53:40AM -0500, David Malcolm wrote:
> > Does the following look like the kind of thing you had in mind? (just
> > the tree.def part for now). Presumably usable for both lvalues and
> > rvalues, where the
On Mon, Nov 23, 2015 at 11:53:40AM -0500, David Malcolm wrote:
> Does the following look like the kind of thing you had in mind? (just
> the tree.def part for now). Presumably usable for both lvalues and
> rvalues, where the thing it wraps is what's important. It merely exists
> to add an EXPR_
On Mon, 2015-11-23 at 10:59 +0100, Richard Biener wrote:
> On Sat, Nov 21, 2015 at 9:21 AM, Jakub Jelinek wrote:
> > On Sat, Nov 21, 2015 at 02:16:49AM -0500, Jason Merrill wrote:
> >> On 11/19/2015 03:46 PM, Jason Merrill wrote:
> >> >On 11/15/2015 12:01 AM, David Malcolm wrote:
> >> >>As with th
On Mon, Nov 09, 2015 at 19:41:21 +0100, Bernd Schmidt wrote:
> On 11/09/2015 05:47 PM, tbsaunde+...@tbsaunde.org wrote:
> >-#ifdef ENABLE_OFFLOADING
> >/* If the user didn't specify any, default to all configured offload
> > targets. */
> >if (offload_targets == NULL)
> > handle
>
> I think it also causes the following and one related ICE
>
> FAIL: gcc.dg/vect/pr62021.c -flto -ffat-lto-objects (internal compiler
> error)
>
> /space/rguenther/src/svn/trunk3/gcc/testsuite/gcc.dg/vect/pr62021.c:7:1:
> internal compiler error: in get_alias_set, at alias.c:880^M
> 0x7528a7
> On Fri, Nov 20, 2015 at 9:03 PM, Jakub Jelinek wrote:
> > Hi!
> >
> > node->get_body () can run various IPA passes and ggc_collect in them
>
> Aww. Looks like we never implemented that ggc_defer_collecting idea
> (don't remember the context this popped up, maybe it was when we
> introduced TOD
On November 23, 2015 5:31:11 PM GMT+01:00, Marek Polacek
wrote:
>We blow up on the following testcase because we find ourselves passing
>[_13 + 1, INT_MAX] as a vr1 to extract_range_from_multiplicative_op_1;
>that's bad because this function immediately calls vrp_int_const_binop
>which just doesn
On 23/11/15 12:24, James Greenhalgh wrote:
On Tue, Oct 27, 2015 at 03:32:04PM +, Matthew Wahab wrote:
On 24/10/15 08:16, Bernhard Reutner-Fischer wrote:
On October 23, 2015 2:24:26 PM GMT+02:00, Matthew Wahab
wrote:
The ARMv8.1 architecture extension adds two Adv.SIMD instructions,.
This
On November 23, 2015 4:37:18 PM GMT+01:00, Tom de Vries
wrote:
>On 23/11/15 12:31, Richard Biener wrote:
From the dump below I understand you want no memory references in
> >the outer loop?
> >So the issue seems to be that store motion fails
> >to insert the preheader load /
We blow up on the following testcase because we find ourselves passing
[_13 + 1, INT_MAX] as a vr1 to extract_range_from_multiplicative_op_1;
that's bad because this function immediately calls vrp_int_const_binop
which just doesn't work for symbolic ranges, it only wants int_csts.
This started wit
> > Will it also fix
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61954
>
> Yes, probably, as well as the m68k issue, if that's really doable.
Right, that's also why I think it's a more promising approach.
Pretending that system.address is just an unsigned integer is bound to cause
troub
> Will it also fix
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61954
Yes, probably, as well as the m68k issue, if that's really doable.
--
Eric Botcazou
On Mon, Nov 23, 2015 at 8:02 AM, Eric Botcazou wrote:
>> But can't you on the GENERIC side drop System.Address to void_ptr_node
>> again and just not make use of the "heavy lifting" you were talking about?
>
> No "heavy lifting" in this thread, just a heavy machinery in the language. :-)
>
>> That
Hi,
On Fri, 20 Nov 2015, Jeff Law wrote:
> > I'm undecided on whether cs-elim is safe wrt the store speculation vs
> > locks concerns raised in the thread discussing Ian's
> > noce_can_store_speculate_p, but that's not something we have to consider
> > to solve the problem at hand.
> I don't thin
> But can't you on the GENERIC side drop System.Address to void_ptr_node
> again and just not make use of the "heavy lifting" you were talking about?
No "heavy lifting" in this thread, just a heavy machinery in the language. :-)
> That is, why is that speciality of System.Address not a Ada FE thi
Hi,
On Fri, 20 Nov 2015, Bernd Schmidt wrote:
> On 11/19/2015 12:49 AM, Jeff Law wrote:
> > On 11/18/2015 12:16 PM, Bernd Schmidt wrote:
> > > I don't think so, actually. One safe option would be to rip it out and
> > > just stop transforming this case, but let's start by looking at the code
> >
Hi Richard,
Did you have a chance to look at this?
Thanks.
Yuri.
2015-11-13 13:35 GMT+03:00 Yuri Rumyantsev :
> Hi Richard,
>
> Here is updated version of the patch which 91) is in sync with trunk
> compiler and (2) contains simple cost model to estimate profitability
> of scalar epilogue elimin
On Mon, Nov 23, 2015 at 16:31:42 +0100, Richard Biener wrote:
> I think it also causes the following and one related ICE
>
> FAIL: gcc.dg/vect/pr62021.c -flto -ffat-lto-objects (internal compiler
> error)
>
> /space/rguenther/src/svn/trunk3/gcc/testsuite/gcc.dg/vect/pr62021.c:7:1:
> internal co
On Mon, Nov 23, 2015 at 2:45 PM, Ilya Enkovich wrote:
> On 23 Nov 14:29, Richard Biener wrote:
>> On Mon, Nov 23, 2015 at 12:33 PM, Ilya Enkovich
>> wrote:
>> >
>> > I see. But it should still be OK to check type in case of strict
>> > aliasing, right?
>>
>> No, memcpy is always "no-strict-ali
On Mon, 23 Nov 2015, Martin Jambor wrote:
> Hi,
>
> On Mon, Nov 23, 2015 at 12:00:25AM +0100, Jan Hubicka wrote:
> > Hi,
> > here is updated patch which I finally comitted today. It addresses all the
> > comments
> > and also fixes one nasty bug that really cost me a lot of time to
> > underst
On 23/11/15 12:31, Richard Biener wrote:
From the dump below I understand you want no memory references in
> >the outer loop?
> >So the issue seems to be that store motion fails
> >to insert the preheader load / exit store to the outermost loop
> >possible and thus another LIM pass is needed to
Hi all,
In this PR we fail to if-convert a case where in the expression x = c ? a : b;
'a' and 'b' are something like x + 1 and x - 1.
So x appears in a and b.
The code that checks that nothing from the else block modifies the registers
used in a
rejects this case. It should accept when the modi
On 11/22/2015 09:58 PM, Uros Bizjak wrote:
On Sun, Nov 22, 2015 at 11:38 AM, Richard Henderson wrote:
* optabs.def (uaddv4_optab, usubv4_optab): New.
* internal-fn.c (expand_addsub_overflow): Use them.
* doc/md.texi (Standard Names): Add uaddv4, usubv4.
* config/i386/i386.c (ix86_cc_mode): Ext
The following fixes CH - FRE - LIM not doing store-motion across a loop
nest for redundant header checks. FRE is supposed to do such
redundant comparison "threading" but didn't do it because of latch
edges confusing the single_pred_p check.
The following fixes it by disregarding edges that come
On 12/11/15 11:30, Szabolcs Nagy wrote:
> The documentation for -fpic and -fPIC explicitly mentions some targets
> where the difference matters, but not AArch64. Specifying the GOT size
> limit is not entirely correct as it can depend on the -mcmodel setting,
> but probably better than leaving the
Hi Bernd,
On 20/11/15 01:41, Bernd Schmidt wrote:
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_eq
On 11/23/2015 03:36 PM, Bernd Schmidt wrote:
> On 11/23/2015 02:49 PM, marxin wrote:
>> Following series has been just bootregtested on x86_64-linux-gnu
>> (all patches together).
>
> All ok except 5/6 which I'm not finding obvious. Better to have a cilk/c++
> person have a look.
Hi.
Sure, let'
On 23/11/15 14:58, James Greenhalgh wrote:
On Mon, Nov 23, 2015 at 10:33:01AM +, Kyrill Tkachov wrote:
On 12/11/15 12:05, James Greenhalgh wrote:
On Tue, Nov 03, 2015 at 03:43:24PM +, Kyrill Tkachov wrote:
Hi all,
Bootstrapped and tested on aarch64.
Ok for trunk?
Comments in-line.
On 06/11/15 13:32, Szabolcs Nagy wrote:
> 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 conform
On Mon, Nov 23, 2015 at 10:33:01AM +, Kyrill Tkachov wrote:
>
> On 12/11/15 12:05, James Greenhalgh wrote:
> >On Tue, Nov 03, 2015 at 03:43:24PM +, Kyrill Tkachov wrote:
> >>Hi all,
> >>
> >>Bootstrapped and tested on aarch64.
> >>
> >>Ok for trunk?
> >Comments in-line.
> >
>
> Here's an
On 12/11/15 11:30, Szabolcs Nagy wrote:
The documentation for -fpic and -fPIC explicitly mentions some targets
where the difference matters, but not AArch64. Specifying the GOT size
limit is not entirely correct as it can depend on the -mcmodel setting,
but probably better than leaving the impre
On 06/11/15 13:32, Szabolcs Nagy wrote:
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
On Mon, Nov 16, 2015 at 01:21:48PM +, Kyrill Tkachov wrote:
> Hi all,
>
> This RTL checking ICE occurs when processing an rtx_insn* in
> aarch64_madd_needs_nop that apparently holds JUMP_TABLE_DATA. This shouldn't
> be passed to recog. So instead reject it with the INSN_P check. Such
> rtx_in
On Mon, Nov 23, 2015 at 03:35:48PM +0100, Martin Jambor wrote:
> +/* If the value is directly embeded in target argument, it should be a 16-bit
> + at most and shifted by tis many bits. */
this
Jakub
Hi,
the following patch against the HSA branch makes it call
GOMP_offload_register_ver and GOMP_offload_unregister_ver as opposed
to the routines without version information and adds a version check
to the libgomp plugin along the lines other plugins do it.
Committed to the branch, any feedback w
On 11/23/2015 02:49 PM, marxin wrote:
Following series has been just bootregtested on x86_64-linux-gnu
(all patches together).
All ok except 5/6 which I'm not finding obvious. Better to have a
cilk/c++ person have a look.
In the future, a few more explanations would help with reviewing. Let'
1 - 100 of 183 matches
Mail list logo
