On 28/05/15 15:16, Julian Brown wrote:
On Thu, 28 May 2015 04:48:58 -0700
"H.J. Lu" wrote:
On Thu, May 21, 2015 at 4:10 AM, Jakub Jelinek
wrote:
On Thu, May 21, 2015 at 01:02:12PM +0200, Thomas Schwinge wrote:
Hi!
On Thu, 7 May 2015 19:32:26 +0100, Julian Brown
wrote:
Here's a new versio
On 05/30/2015 03:57 AM, Marc Glisse wrote:
On Fri, 29 May 2015, Jeff Law wrote:
c-common.c::shorten_compare has code to canonicalize the arguments of
a comparison so that the constant is the second argument. This patch
removes the implementation from c-common.c and instead implements it
in mat
On 06/01/2015 05:15 AM, Richard Biener wrote:
In addition to what Marc said we'd simplify 1 != 0 immediately anyway (to 1),
so I don't think the special-cases should make a difference (and if they
do I'd like to see a testcase!).
FWIW, I agree -- and across my testfiles I don't see any differenc
Hi, Ramana
Currently, I work for Marvell and the company have copyright assignment on file.
Hi, all
After adding the attribute and rebuild gcc, I got the assembler error message
load_n.s:39: Error: bad instruction `ldrbeq r0,[r0]'
When i look into armv8 ISA document, it seems ldrb Encoding A1
This patch adds support for broadcasting private variables to vector
threads inside acc loops. The algorithm I'm using is extremely
conservative. Basically, it walks each basic block inside an acc loop
and builds a USE and GEN set of decls. The GEN set contains all of the
variables declared inside
I noticed that poor code is emitted for a long double 0.0. This testcase
long double sub (void) { return 0.0; }
void sub2 (long double *ld) { *ld = 0.0; }
currently generates
sub:
ldr q0, .LC0
ret
...
sub2:
ldr q0, .LC1
str q0, [x0]
ret
where LC0 and LC1 are 16-byte constant table long double zero
On Wed, 3 Jun 2015, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-linux pending, ok if it passes?
>
> 2015-06-03 Marek Polacek
>
> PR c/66341
> * c-typeck.c (build_c_cast): Wrap VALUE into NON_LVALUE_EXPR if
> it is a lvalue.
>
> * gcc.dg/lvalue-8.c: New tes
> On Sat, 30 May 2015, Jan Hubicka wrote:
>
> > Joseph, Richard,
> > this is patch implementing the ENUM/INGEGER globbing and also
> > POINTER/REFERENCE
> > (though I don't know if that one follows by some standard rules).
> > Joseph, does the attached testcase make sense for you? Is it defined?
The attach patch fixes two issues with EQUIVALENCE statements
in modules.
The first issue was fixed by Russell Whitesides where an
EQUIVALENCE statement that is USEs associated into multiple
modules will appear multiple times in a new module if the
previous modules are USEd by the new module. Rus
On Feb 25, 2015, Alexandre Oliva wrote:
> This patch fixes a problem that has been with us for several years.
> Variable tracking has no idea about the end of the lifetime of inlined
> variables, so it keeps on computing locations for them over and over,
> even though the computed locations make
Hi!
I've bootstrapped/regtested on x86_64-linux and i686-linux
following backports and committed them to 4.8 branch.
Jakub
2015-06-03 Jakub Jelinek
Backported from mainline
2015-02-18 Jakub Jelinek
PR gcov-profile/64634
* tree-eh.c (frob_into_branch
Hi!
I've bootstrapped/regtested on x86_64-linux and i686-linux
following backports and committed them to 4.9 branch.
Jakub
2015-06-03 Jakub Jelinek
Backported from mainline
2015-02-18 Jakub Jelinek
PR gcov-profile/64634
* tree-eh.c (frob_into_branch
On 06/02/2015 09:04 AM, Jason Merrill wrote:
Ugh, I thought I had dealt with that issue. Looking...
Fixed thus.
commit 82343dca07986bd1db2759d2eca1cfd5b9728410
Author: Jason Merrill
Date: Tue Jun 2 13:24:11 2015 -0400
PR c++/44282
* mangle.c (mangle_decl): Always SET_IDENTIFIE
On Wed, 03 Jun 2015 16:55:24 +0200, Jeff Law wrote:
> On 05/30/2015 03:47 AM, Jan Kratochvil wrote:
> > > So I guess at some level it's not clear to me why we need to support the @
> > > operator in libcc1. So perhaps starting with a justification for
> > > wanting/needed that capability would be
On Wed, Jun 3, 2015 at 1:09 PM, Richard Henderson wrote:
> On 06/03/2015 11:38 AM, Sriraman Tallam wrote:
>> + { "no_plt", 0, 0, true, false, false,
>> + handle_no_plt_attribute, false },
>
> Call it noplt. We don't add the underscore for noinline, no
On 01/06/2015 22:09, Jonathan Wakely wrote:
On 01/06/15 22:04 +0200, François Dumont wrote:
Hi
I can't find how to fix 61347 for alternative modes. I started
with debug mode by providing a forward declaration for safe iterator
type which return to the __distance on normal iterator but gcc
Hello Jeff,
please find updated patch attached
03.06.2015 00:18, Jeff Law wrote:
> On 06/01/2015 04:12 AM, Alexander Basov wrote:
>> Hi,
>> this patch fixes ICE when compiling naked functions for arm targets.
>> It prevents register allocation for non-register things like volatile,
>> float, BLKMo
On 06/03/2015 11:38 AM, Sriraman Tallam wrote:
> + { "no_plt", 0, 0, true, false, false,
> + handle_no_plt_attribute, false },
Call it noplt. We don't add the underscore for noinline, noclone, etc.
> Index: config/i386/i386.c
>
Hi
Here is a patch to add heterogeneous lookup to alternative modes.
To do so I had to expose __is_transparent as __has_is_transparent to
avoid confilct with existing __is_transparent. Should I put it in
__detail namespace ?
* include/bits/stl_tree.h (_Rb_tree<>::__is_transparent<>):
On 06/02/2015 01:56 PM, Ramana Radhakrishnan wrote:
> I'm sorry I'm going to push back again for the same reason.
>
> Other than forcing targets to tweak their call insn patterns, the act
> of generating the indirect call should remain in target independent
> code.
How is that going to help?
Unl
On Wed, Jun 03, 2015 at 08:28:12PM +0100, Sandra Loosemore wrote:
> On 06/03/2015 12:05 PM, James Greenhalgh wrote:
> >
> > This has caused some issues for my multilib testing. Summarised below,
> > with some help from Alan Lawrence.
> >
> > Basically the problem occurs when a target which is not O
On 06/03/2015 12:05 PM, James Greenhalgh wrote:
This has caused some issues for my multilib testing. Summarised below,
with some help from Alan Lawrence.
Basically the problem occurs when a target which is not OK for Neon
runs before another target. The dg-do-what-default is not restored
when !
On Wed, Jun 03, 2015 at 06:02:12PM +, Joseph Myers wrote:
> I'm not clear on what trees you get in the problem case (or which of the
> tests in the testcase you added was broken before - they don't seem that
> similar to the tests in the bug). It would seem safer to me to use
> lvalue_p (va
Manuel> It should be possible to arrange the inferior code in
Manuel> such a way that GCC parses each side of @ independently and gives the
Manuel> info necessary to GDB such that it can interpret what @ means or give
Manuel> a reasonable error.
Only if this can be done without requiring gdb to le
>
> I agree now that it will be much cleaner just to punt this into the backend,
> so it may be worth noting that making this work properly for the non-PIC
> case requires quite a degree of massaging in the backends.
>
> Objections withdrawn.
Thanks!, I have attached the latest patch after making
On 03/06/15 18:30, Jeff Law wrote:
It's common to have something like the struct hack where the length of
the array is stored in the struct. Then when scripting gdb one can
write:
print s.array[0] @ s.length
Which is case that I've had use for a non-constant RHS as well. I just
haven't
On Thu, May 21, 2015 at 06:33:37AM +0100, Sandra Loosemore wrote:
> ARM testing shares the AArch64 advsimd-intrinsics execution tests. On
> ARM, though, the NEON support being tested is optional -- some arches
> are compatible with the NEON compilation options but hardware available
> for testi
On Wed, 3 Jun 2015, Marek Polacek wrote:
> Since a cast does not yield an lvalue, we shouldn't accept invalid
> code as in the attached testcase.
>
> The problem was that we weren't setting NON_LVALUE_EXPR properly;
> for comparing expressions we shouldn't use ==, because then a cast
> in an expr
Since a cast does not yield an lvalue, we shouldn't accept invalid
code as in the attached testcase.
The problem was that we weren't setting NON_LVALUE_EXPR properly;
for comparing expressions we shouldn't use ==, because then a cast
in an expression might confuse us.
Bootstrapped/regtested on x8
On 06/03/2015 08:11 AM, Martin Liška wrote:
That's fine, I would like to explain that difference. Each of these two
functions are called in a bit different way:
T::dump_header (mem_location::get_origin_name (origin)); // that's why the
function is static
total.dump_footer (); // that's why th
On Wed, Jun 03, 2015 at 06:59:55PM +0200, Marek Polacek wrote:
> On Wed, Jun 03, 2015 at 06:33:20PM +0200, Jakub Jelinek wrote:
> > Ok, thanks.
>
> Forgot to ask - can I also backport the fix to gcc-5 branch?
Sure.
Jakub
On Wed, Jun 03, 2015 at 06:33:20PM +0200, Jakub Jelinek wrote:
> Ok, thanks.
Forgot to ask - can I also backport the fix to gcc-5 branch?
Marek
On Wed, Jun 03, 2015 at 06:32:01PM +0200, Marek Polacek wrote:
> All right, that seems to work well. Done in the below.
>
> Bootstrap-ubsaned/regtested on x86_64-linux, ok for trunk?
Ok, thanks.
> 2015-06-03 Marek Polacek
>
> PR sanitizer/66190
> * cp-gimplify.c (struct cp_gener
On Fri, May 29, 2015 at 12:26:39PM +0200, Jakub Jelinek wrote:
> This seems strange. Normally DECL_INITIAL of vars isn't walked when
> processing DECL_EXPRs, so IMHO you shouldn't either.
> I think it would be much better to handle this case where the tree.c
> code handles it, thus in cp_genericiz
OK.
Jason
On 06/03/2015 09:29 AM, Tom Tromey wrote:
I did not realize that myself before. I do not think there is an
easy fix for the GCC patch, is it?
It seems like a VLA would work.
Right. It doesn't seem like a big stretch to me either.
Jeff> 99% of the time I've used a constant with the @ synta
OK, thanks.
Jason
Hi all,
This patch is part of a few prerequisites to get target attribute support in
AArch64.
This registers the fma steering pass unconditionally but gates its execution
instead.
This way the pass will be available if during the compilation of a file the user
specifies cortex-a57 tuning using
On Wed, 3 Jun 2015, Ilya Enkovich wrote:
> 2015-06-03 18:25 GMT+03:00 Joseph Myers :
> > On Wed, 3 Jun 2015, Ilya Enkovich wrote:
> >
> >> Spec files are not scanned by translator. I tried to split this spec
> >> into two parts to move message into a header file but with no success.
> >> Any ideas
2015-06-03 18:25 GMT+03:00 Joseph Myers :
> On Wed, 3 Jun 2015, Ilya Enkovich wrote:
>
>> Spec files are not scanned by translator. I tried to split this spec
>> into two parts to move message into a header file but with no success.
>> Any ideas how it can be done?
>
> If a spec in a .c or .h file
> Committed. Seems to cause half of the vectorizer tests to be dropped
> and test-summary breaking for me.
>
> Richard.
>
> 2015-06-02 Richard Biener
>
> * gcc.dg/vect/vect-outer-simd-1.c: Remove stray cleanup-tree-dump.
Whoops, I have fixed this yesterday morning, but for some (unknown to
me)
Hello!
As explained in the PR, we have to consider attribute that switches
target ABI also for ix86_function_arg_regno_p and
ix86_function_value_regno_p.
2015-06-03 Uros Bizjak
PR target/66275
* config/i386/i386.c (ix86_function_arg_regno): Use ix86_cfun_abi
to determine current
On Tue, Jun 2, 2015 at 8:02 PM, Michael Meissner
wrote:
> This is a convenience patch that would help those of us who work on the main
> GCC releases as well as backporting changes to the IBM Advance Toolchain. It
> adds a new configuration switch, --with-advance-toolchain= that
> configures
> t
>> I did not realize that myself before. I do not think there is an
>> easy fix for the GCC patch, is it?
It seems like a VLA would work.
Jeff> 99% of the time I've used a constant with the @ syntax in gdb.
I use a non-constant argument to @ quite a bit.
It's common to have something like the
On Wed, 3 Jun 2015, Ilya Enkovich wrote:
> Spec files are not scanned by translator. I tried to split this spec
> into two parts to move message into a header file but with no success.
> Any ideas how it can be done?
If a spec in a .c or .h file contains %e or %n immediately followed by the
mess
Hi,
no, I lost patience with this. Attached is the last version of this patch I will
provide. I have changed some things to fix the issues needed for
allocate_with_source_3.f90 (now called allocate_with_source_8.f08) to run. The
fix implies that source=[type_constructor(...)] generate a zero-bound
On 05/30/2015 03:47 AM, Jan Kratochvil wrote:
So I guess at some level it's not clear to me why we need to support the @
operator in libcc1. So perhaps starting with a justification for
wanting/needed that capability would be helpful.
It is not a simple /@[0-9]+$/ regex, the expression can be
On 06/03/2015 09:06 AM, Richard Biener wrote:
On Wed, Jun 3, 2015 at 3:04 PM, Aldy Hernandez wrote:
On 05/27/2015 03:34 PM, Jason Merrill wrote:
It occurs to me that the early-dwarf work should make
debug_abstract_function and most of the DECL_ABSTRACT handling obsolete.
All we need to do
Hi,
this is a first follow up to c++/65598, where I noticed that we should
probably use declspecs->locations more for more accurate locations.
Tested x86_64-linux.
Thanks,
Paolo.
///
/cp
2015-06-03 Paolo Carlini
* decl.c (check_tag_decl): Use declspecs->lo
Hi Sriraman,
Thanks for the detailed explanation, that was useful.
I'm sorry I'm going to push back again for the same reason.
Let me describe the problem I am having in a little more detail:
For the PIC case, I think there is no confusion. Both of us agree on
what is being done. Attribute
On 06/03/2015 03:18 PM, Jeff Law wrote:
> On 06/03/2015 03:14 AM, Martin Liška wrote:
>> On 06/02/2015 07:17 PM, Jeff Law wrote:
>>> On 06/02/2015 09:05 AM, Martin Liška wrote:
On 06/02/2015 03:58 PM, Jeff Law wrote:
> On 06/01/2015 10:16 AM, mliska wrote:
>> Hi.
>>
>> Followin
On 05/20/2015 05:01 PM, Martin Sebor wrote:
Now that I know a bit more from Jakub & Yuri's comments, I don't think
I opened compiler_rt/23600 and attached the sanitizer patch
to it:
http://llvm.org/bugs/show_bug.cgi?id=23600
If there are no objections to the bug I'll post the patch for
rev
On 05/28/2015 03:50 PM, Eric Botcazou wrote:
Thanks very much. ChangeLog entry:
2015-05-14 James Bowman
* configure.ac: FT32 target added
* libgcc/config.host: FT32 target added
* gcc/config/ft32/: FT32 target added
* libgcc/config/ft32/: FT32 target added
On 06/03/2015 07:47 AM, Richard Biener wrote:
On Tue, Jun 2, 2015 at 4:19 PM, Andrew MacLeod wrote:
On 06/02/2015 09:30 AM, Richard Biener wrote:
On Tue, Jun 2, 2015 at 2:34 PM, Andrew MacLeod
wrote:
On 06/02/2015 04:26 AM, Richard Biener wrote:
On Mon, Jun 1, 2015 at 11:02 PM, Andrew MacLe
On 05/30/2015 06:12 AM, Mike Frysinger wrote:
The current netbsd elf spec doesn't respect -symbolic which prevents
passing -Bsymbolic down to the linker. This causes problems when you
try to link the runtime linker as it creates an ELF with incorrect
sections in it leading it to crash at startup
On 05/18/2015 01:51 PM, andres.tirabos...@tallertechnologies.com wrote:
Hi, this patch adds two new plugin events PLUGIN_START_PARSE_FUNCTION and
PLUGIN_FINISH_PARSE_FUNCTION. These events are invoked at start_function and
finish_function in gcc/c/c-decl.c and gcc/cp/decl.c respectively in the
On Wed, 03 Jun 2015 10:25:20 +0200, Richard Biener wrote:
> gdb 7.9, python 2.7.6
attaching a fix; I do not know much Python so check it, please.
OK for check-in?
I have found it reproducible by :
gdb -ex 'source /home/jkratoch/redhat/gcchead/gcc/gdbhooks.py' -ex 'b
*0xec25b0' -ex r -ex
On 06/03/2015 03:41 AM, Martin Liška wrote:
From a52eecf7c78f2eee0ccac662459e89ddbedd0244 Mon Sep 17 00:00:00 2001
From: mliska
Date: Wed, 3 Jun 2015 11:37:01 +0200
Subject: [PATCH] Fix GNU coding style in memory statistics.
gcc/ChangeLog:
2015-06-03 Martin Liska
* alloc-pool.h (str
On 06/03/2015 03:14 AM, Martin Liška wrote:
On 06/02/2015 07:17 PM, Jeff Law wrote:
On 06/02/2015 09:05 AM, Martin Liška wrote:
On 06/02/2015 03:58 PM, Jeff Law wrote:
On 06/01/2015 10:16 AM, mliska wrote:
Hi.
Following 2 patches improve memory statistics infrastructure. First one
ports pool
On Wed, Jun 3, 2015 at 3:04 PM, Aldy Hernandez wrote:
> On 05/27/2015 03:34 PM, Jason Merrill wrote:
>
>> It occurs to me that the early-dwarf work should make
>> debug_abstract_function and most of the DECL_ABSTRACT handling obsolete.
>> All we need to do is set DW_AT_inline during early debug
On Tue, Jun 02, 2015 at 09:25:32PM +0200, Marek Polacek wrote:
> On Fri, May 29, 2015 at 08:49:58PM +, Joseph Myers wrote:
> > On Mon, 25 May 2015, Marek Polacek wrote:
> >
> > > +/* Warn if signed left shift overflows. Note that we don't warn
> > > + about left-shifting 1 into the sign bit
On 05/27/2015 03:34 PM, Jason Merrill wrote:
It occurs to me that the early-dwarf work should make
debug_abstract_function and most of the DECL_ABSTRACT handling obsolete.
All we need to do is set DW_AT_inline during early debug and update it
during late debug if the function is inlined.
Thi
Hi all,
Committed as obvious with r224075.
Cheers,
Kyrill
2015-06-03 Kyrylo Tkachov
* ifcvt (end_ifcvt_sequence): Fix typo in comment above.
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 986f28f..4e6c0d5 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -1043,7 +1043,7 @@ cc_in_cond (rt
On 06/03/2015 03:46 AM, Andrew Bennett wrote:
OK. Please install.
Committed as SVN revision 224064.
Hi Jeff,
Are you also happy for me to backport the patch on to the 4.9 and 5 branches?
Jakub, Joseph or Richi would need to make that decision as the release
managers. I think the patch is
"H.J. Lu" writes:
> On Thu, May 21, 2015 at 7:13 AM, Rainer Orth
> wrote:
>> "H.J. Lu" writes:
>>
>>> Here is the complete patch. Tested on Linux/x86-64. It is also
>>> available on hjl/pie/master branch in git mirror.
Now that the patch is in, I see a couple of testsuite regressions on
both
This allows all permutations we can generate (according to the target).
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Richard.
2015-06-03 Richard Biener
* tree-vect-stmts.c (vectorizable_load): Compute the pointer
adjustment for gaps at the end of a SLP load gro
The following fixes GROUP_GAP computation if the gaps are only within
the group but not at the boundaries. It also removes a restriction
in SLP detection that ultimatively is a restriction on supported
load permutations.
This allows us to basic-block vectorize the new testcase.
Bootstrapped on
On Tue, Jun 2, 2015 at 4:19 PM, Andrew MacLeod wrote:
> On 06/02/2015 09:30 AM, Richard Biener wrote:
>>
>> On Tue, Jun 2, 2015 at 2:34 PM, Andrew MacLeod
>> wrote:
>>>
>>> On 06/02/2015 04:26 AM, Richard Biener wrote:
On Mon, Jun 1, 2015 at 11:02 PM, Andrew MacLeod
wrote:
>
>
On Thu, 28 May 2015 16:37:04 +0200
Richard Biener wrote:
> On Thu, May 28, 2015 at 4:06 PM, Julian Brown
> wrote:
> > For NVPTX, it is vitally important that the divergence of threads
> > within a warp can be controlled: in particular we must be able to
> > generate code that we know "reconverge
On Mon, 1 Jun 2015, Jan Hubicka wrote:
> Hi,
> this patch removes the check for TREE_CODE of pointer types when computing
> canonical types. It also adds a testcase for fortran C_PTR type that should be
> compatible with all C pointers. Can someone familiar with Fortran double check
> that the tes
Hi!
On Mon, 01 Jun 2015 13:57:47 +0200, I wrote:
> On Mon, 1 Jun 2015 12:10:12 +0200, Tom de Vries
> wrote:
> > On 29/05/15 18:23, Bernd Schmidt wrote:
> > > When predicating the code for OpenACC, we should avoid the entry block
> > > in an offloaded region, which contains setup code that should
On Sat, 30 May 2015, Jan Hubicka wrote:
>
> Richard,
> this patch makes canonical_type to be computed via the hash only for main
> variants of types. The idea is to save some lookups because most types are
> variants and should match.
>
> I also added sanity checking about that.
>
> Bootstrapp
On Sat, 30 May 2015, Jan Hubicka wrote:
> Joseph, Richard,
> this is patch implementing the ENUM/INGEGER globbing and also
> POINTER/REFERENCE
> (though I don't know if that one follows by some standard rules).
> Joseph, does the attached testcase make sense for you? Is it defined? It is my
> fir
On Tue, Jun 2, 2015 at 7:33 PM, Jeff Law wrote:
> On 06/01/2015 05:07 AM, Richard Biener wrote:
>>>
>>> +(simplify
>>> + (cond @0 (convert @1) INTEGER_CST@2)
>>> + (if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
>>> + && COMPARISON_CLASS_P (@0)
>>> + && int_fits_type_p (@2, TREE_TYPE (@1))
>>>
On Tue, 2 Jun 2015, Tom de Vries wrote:
> On 02-06-15 15:58, Richard Biener wrote:
> > Btw, I wonder why you don't organize the oacc-kernel passes in
> > a new simple-IPA group after pass_local_optimization_passes.
>
> I've placed the pass group as early as possible (meaning after ealias) and put
On Wed, 3 Jun 2015, Tom de Vries wrote:
> On 22/04/15 09:39, Richard Biener wrote:
> > > Committed to gomp-4_0-branch in r81:
> > > >
> > > >commit 58c33a7965c379b55b549d50e3b79b2252bcc876
> > > >Author: tschwinge
> > > >Date: Tue Apr 21 19:48:16 2015 +
> > > >
> > > > Add pass_ch_o
On Wed, 3 Jun 2015, Tom de Vries wrote:
> On 22/04/15 09:39, Richard Biener wrote:
> > > Committed to gomp-4_0-branch in r81:
> > > >
> > > >commit 58c33a7965c379b55b549d50e3b79b2252bcc876
> > > >Author: tschwinge
> > > >Date: Tue Apr 21 19:48:16 2015 +
> > > >
> > > > Add pass_ch_o
On 06/02/2015 01:06 PM, Thomas Schwinge wrote:
On Mon, 1 Jun 2015 17:58:51 +0200, Bernd Schmidt
wrote:
This extends the previous vector-single support to also handle
worker-level predication. [...]
This causes the following regressions; would you please have a look?
I committed the followi
* John Marino, 2015-06-03 :
> I have this fixed in an interesting way on gnat-aux. I found that
> setting TARGET_96_ROUND_53_LONG_DOUBLE affects other front ends, so you
> have to choose which one you want to be correct, GNAT or the C (or
> whatever, can't remember which ones were affected now)
On 6/3/2015 11:39, Thomas Quinot wrote:
> Patch looks good to me. The story with floats is that on FreeBSD, the
> i386 FPU is set to 53-bit floats, but the GNAT runtime library always
> issues a "finit" instruction to reset it to full precision, so we need
> to reset TARGET_96_ROUND_53_LONG_DOUBLE
On 22/04/15 09:39, Richard Biener wrote:
Committed to gomp-4_0-branch in r81:
>
>commit 58c33a7965c379b55b549d50e3b79b2252bcc876
>Author: tschwinge
>Date: Tue Apr 21 19:48:16 2015 +
>
> Add pass_ch_oacc_kernels to pass_oacc_kernels
>
>gcc/
>* omp-low.c (loop
> > OK. Please install.
>
> Committed as SVN revision 224064.
Hi Jeff,
Are you also happy for me to backport the patch on to the 4.9 and 5 branches?
Many thanks,
Andrew
On 06/01/2015 06:16 PM, mliska wrote:
> Hi.
>
> Following 2 patches improve memory statistics infrastructure. First one
> ports pool allocator to the new infrastructure. And the second one makes
> column alignment properly.
>
> Both can bootstrap on x86_64-linux-pc and survive regression tests.
>
* Eric Botcazou, 2015-06-03 :
> > Note 2) I removed reference to FreeBSD 6 and earlier. These platforms
> > have been EOL for years (FreeBSD 8 is EOL in 4 weeks)
> >
> > Note 3) FreeBSD should have switched to use errno years ago, this patch
> > does that now.
> >
> > Note 4) For all BSD except
Richard Sandiford writes:
> Richard Henderson writes:
>> On 05/29/2015 10:23 AM, Richard Sandiford wrote:
>>> + /* Check whether the predicate accepts const scalar ints (which always
>>> + have a stored mode of VOIDmode, but logically have a real mode)
>>> + and whether it matches anythi
Hi, Ramana
I'm not sure what copyright assignment means ?
Does it mean the patch have copyright assignment or not ?
I update the patch to add "predicable" and "predicable_short_it"
attribute as suggestion.
However, I don't have svn write access yet.
Shiva
2015-06-03 16:36 GMT+08:00 Kyrill Tk
We have a copy_type function in gigi and the more stringent type checking
added by Jan revealed that we should also set TYPE_CANONICAL along with
TYPE_MAIN_VARIANT there.
Tested on x86_64-suse-linux, applied on the mainline.
2015-06-03 Eric Botcazou
* gcc-interface/utils.c (copy_ty
Tested on x86_64-suse-linux, applied on the mainline.
2015-06-03 Eric Botcazou
* gcc-interface/trans.c (gnat_to_gnu) : Fix
typo in latest change.
--
Eric BotcazouIndex: gcc-interface/trans.c
===
--- gcc-interfa
On Tue, Jun 02, 2015 at 07:35:15PM +0200, Jakub Jelinek wrote:
> I've only noticed now that reduction clause isn't covered in the tests, will
> add that tomorrow.
Here it is:
2015-06-03 Jakub Jelinek
* semantics.c (omp_clause_printable_decl): New function.
(finish_omp_reductio
On 22/04/15 09:39, Richard Biener wrote:
Committed to gomp-4_0-branch in r81:
>
>commit 58c33a7965c379b55b549d50e3b79b2252bcc876
>Author: tschwinge
>Date: Tue Apr 21 19:48:16 2015 +
>
> Add pass_ch_oacc_kernels to pass_oacc_kernels
>
>gcc/
>* omp-low.c (loop
> OK. Please install.
Committed as SVN revision 224064.
Many thanks,
Andrew
On 06/02/2015 07:17 PM, Jeff Law wrote:
> On 06/02/2015 09:05 AM, Martin Liška wrote:
>> On 06/02/2015 03:58 PM, Jeff Law wrote:
>>> On 06/01/2015 10:16 AM, mliska wrote:
Hi.
Following 2 patches improve memory statistics infrastructure. First one
ports pool allocator to the new
> Okay, so that means the Makefile.in patch needs changing in two ways:
> 1. Don't remove TOOL_TARGET_PAIRS lines from two FreeBSD targets
> 2. Add TOOL_TARGET_PAIRS line to new DragonFly target.
Right.
> Is a new submission necessary or can this be handled by committer?
Preferably yes.
> A n
2015-05-27 18:19 GMT+03:00 Jeff Law :
> On 05/26/2015 03:13 AM, Ilya Enkovich wrote:
>>
>> On 06 Apr 09:28, Jeff Law wrote:
>>>
>>> On 04/06/2015 09:17 AM, Ilya Enkovich wrote:
>
>
> To tell the truth, I can't figure out what this means from a user
> perspective. How does a user kn
On 03/06/15 09:32, Ramana Radhakrishnan wrote:
This pattern is not predicable though, i.e. it doesn't have the "predicable" attribute
set to "yes".
Therefore the compiler should be trying to branch around here rather than try
to do a cond_exec.
Why does the generated code above look like it's
Hi Shiva,
On 03/06/15 05:12, Shiva Chen wrote:
Hi,
I noticed that armv8(32 bit target) linux toolchain
run asan testcase would get the following message:
FAIL: c-c++-common/asan/heap-overflow-1.c -O0 output pattern test, is
Executing on host:
/home/gccbuilder-x86/test/mgcc5.0/testsuite/../to
On 03/06/15 05:12, Shiva Chen wrote:
It seems that stl should generate as stlne.
Otherwise, slt will get null reference when r3 is 0.
To fix the issue, add %? when output stl assembly pattern in sync.md.
Please also mark these patterns as predicable.
i.e. (set_attr "predicable" "yes"
On Mon, Mar 9, 2015 at 10:43 PM, Jan Kratochvil
wrote:
> Hi,
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65366
>
> GDB Python support upstream has always been compatible with Python3.
> Fedora since F-22 builds GDB with Python3 by default (<=F-21 GDB used
> Python2).
>
> gdbhooks.py in GCC t
On 6/3/2015 09:30, Arnaud Charlet wrote:
>>> Note 1) All TOOL_TARGET_PAIRS in gcc/ada/gcc-interface/Makefile.in
>>> should be removed for most (if not all) platforms as they were moved to
>>> gnattools/configure and are now no-ops. However, for this patch set I
>>> only removed them for FreeBSD.
The following fixes PR63916 teaching SCCVN (when not used by PRE) to
aggressively forward-propagate addresses (even with variable indexes)
into its memory reference representation.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2015-06-03 Richard Biener
1 - 100 of 105 matches
Mail list logo