On Tue, Oct 29, 2013 at 05:15:24PM -0700, Konstantin Serebryany wrote:
> Actually, I guessed the flags:
You don't have to guess them, if you look into
testsuite/g++/g++.log (or testsuite/gcc/gcc.log etc.), you can find them
there.
> % ../gcc-inst/bin/g++ -g -fsanitize=address -static-libasan -O2
> so in the end I guess I have nothing against the original patch
> (with whatever form of the copy to reg call is desirable).
So ok to commit?
-Y
On Wed, Oct 30, 2013 at 11:32:14AM +0400, Yury Gribov wrote:
> > so in the end I guess I have nothing against the original patch
> > (with whatever form of the copy to reg call is desirable).
>
> So ok to commit?
Ok with the change suggested by Richard, I think it was:
addr = copy_to_mode_reg (
Jason Merrill wrote:
On 10/28/2013 05:48 PM, Tobias Burnus wrote:
DEFTREECODE (RANGE_FOR_STMT, "range_for_stmt", tcc_statement, 4)
has now a 5th operator (RANGE_FOR_IVDEP), which has the value
boolean_true_node - or NULL_TREE (via begin_range_for_stmt).
You don't need to add an operand, you
On Tue, Oct 29, 2013 at 8:48 PM, Ilya Enkovich wrote:
> 2013/10/29 Jeff Law :
>> On 10/29/13 07:52, Ilya Enkovich wrote:
>>>
>>>
>>> Yeah. I'm working on it right now. I've fixed known issues and now
>>> I'm looking for others. Meanwhile here is a new patch version with
>>> required renames and
On Tue, Oct 29, 2013 at 10:53 PM, Ilya Enkovich wrote:
> On 29 Oct 13:39, Jeff Law wrote:
>> On 10/24/13 08:43, Ilya Enkovich wrote:
>> >
>> >+/* Return the number of arguments used by call statement GS. */
>> >+
>> >+static inline unsigned
>> >+gimple_call_num_nobnd_args (const_gimple gs)
>> >+{
On Tue, Oct 29, 2013 at 6:18 PM, Cong Hou wrote:
>>> For the define_expand I added as below, the else body is there to
>>> avoid fall-through transformations to ABS operation in optabs.c.
>>> Otherwise ABS will be converted to other operations even that we have
>>> corresponding instructions from
> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Monday, October 28, 2013 11:07 PM
> To: Zhenqiang Chen; Richard Earnshaw; 'Richard Biener'
> Cc: GCC Patches
> Subject: Re: [PATCH 1/n] Add conditional compare support
>
> On 10/28/2013 01:32 AM, Zhenqiang Che
On Tue, Oct 29, 2013 at 10:36 PM, Jeff Law wrote:
>
> Marc pointed out that the handling of various BUILT_IN_MEM* and
> BUILT_IN_STR* functions in tree-ssa-alias.c probably wasn't working as
> intended because the code wasn't prepared for a common return value from
> ao_ref_base, particularly retu
On Tue, Oct 29, 2013 at 11:23 PM, Marc Glisse wrote:
> On Tue, 29 Oct 2013, Jeff Law wrote:
>
>> Marc pointed out that the handling of various BUILT_IN_MEM* and
>> BUILT_IN_STR* functions in tree-ssa-alias.c probably wasn't working as
>> intended because the code wasn't prepared for a common retur
> Hi!
>
> I've noticed that this testcase doesn't clean up after itself.
> Fixed thusly, committed as obvious to trunk.
This was nagging me last weekend.. ;)
What about automating this?
Manual part is attached.
The "Adjust all callers" below is too big to send to the list:
git grep -l -E "(cleanu
On Wed, Oct 30, 2013 at 1:09 AM, Marc Glisse wrote:
> On Tue, 29 Oct 2013, Richard Biener wrote:
>
>> For the POINTER_PLUS_EXPR offset argument you should use
>> int_cst_value () to access it (it will unconditionally sign-extend)
>> and use host_integerp (..., 0). That leaves the overflow possibi
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Hans-Peter Nilsson
> Sent: Tuesday, October 29, 2013 10:38 AM
> To: Zhenqiang Chen
> Cc: Richard Earnshaw; 'Richard Biener'; GCC Patches
> Subject: RE: [PATCH 1/n] Add conditi
Hi!
Yesterday I've noticed that for AVX which allows unaligned operands in
AVX arithmetics instructions we still don't combine unaligned loads with the
AVX arithmetics instructions. So say for -O2 -mavx -ftree-vectorize
void
f1 (int *__restrict e, int *__restrict f)
{
int i;
for (i = 0; i < 1
On Wed, Oct 30, 2013 at 1:55 AM, Sharad Singhai wrote:
> This patch removes a deprecated option -ftree-vectorizer-verbose. It
> was already implemented in terms of -fopt-info and makes little sense
> to keep it around longer. It causes needless confusion as reported in
> PR middle-end/58134.
>
> I
2013/10/30 Richard Biener :
> On Tue, Oct 29, 2013 at 8:48 PM, Ilya Enkovich wrote:
>> 2013/10/29 Jeff Law :
>>> On 10/29/13 07:52, Ilya Enkovich wrote:
Yeah. I'm working on it right now. I've fixed known issues and now
I'm looking for others. Meanwhile here is a new patch v
On Wed, Oct 30, 2013 at 10:47:13AM +0100, Jakub Jelinek wrote:
> Hi!
>
> Yesterday I've noticed that for AVX which allows unaligned operands in
> AVX arithmetics instructions we still don't combine unaligned loads with the
> AVX arithmetics instructions. So say for -O2 -mavx -ftree-vectorize
> vo
Hi,
The pch-init leaves check objects lying around, remove them.
While at it, i noticed that i was getting warnings from the check since
it was invoced with xg++ -nostdinc++ on C source (in one of the two
iterations the check is run -- once per tool).
My suggestion is to use the correct tool to p
On Tue, 29 Oct 2013, Mike Stump wrote:
> On Oct 29, 2013, at 5:43 AM, Richard Sandiford
> wrote:
> > Richard Biener writes:
> >>
> >> I think the cases Mike added should only be enabled when we can figure
> >> them out at compile-time, too.
> >
> > Well, the idea with most of these functions
On Wed, Oct 30, 2013 at 10:53:58AM +0100, Ondřej Bílka wrote:
> > Yesterday I've noticed that for AVX which allows unaligned operands in
> > AVX arithmetics instructions we still don't combine unaligned loads with the
> > AVX arithmetics instructions. So say for -O2 -mavx -ftree-vectorize
> > void
On Wed, Oct 30, 2013 at 11:00:13AM +0100, Jakub Jelinek wrote:
> But the above is 16 byte unaligned load. Furthermore, GCC supports
> -mavx256-split-unaligned-load and can emit 32 byte loads either as an
> unaligned 32 byte load, or merge of 16 byte unaligned loads. The patch
> affects only the c
> In C++ all classes have destructors, but we try to defer building the
> implicit declaration. My patch causes us to build those implicit
> declarations more often, which is probably a bit of a memory regression,
> but it would be good for your code to handle the dtor being declared.
OK, patch a
On 30 Oct 10:26, Richard Biener wrote:
>
> Ick - you enlarge all return statements? But you don't set the actual value?
> So why allocate it with 2 ops in the first place??
When return does not return bounds it has operand with zero value similar to
case when it does not return value. What is t
Without that patch, which I have copied from asan-dg.exp, I get tons of
failures because "ld" cannot find libcilkrts.
OK for committal?
Tobias
2013-10-30 Tobias Burnus
* gcc.dg/cilk-plus/cilk-plus.exp: Add the libcilkrts library
path to the compile flags.
diff --git a/gcc/testsuite/gcc.d
On 24 Oct 23:34, Jeff Law wrote:
> On 10/21/13 05:59, Ilya Enkovich wrote:
> >Hi,
> >
> >This patch adds attributes 'bnd_variable_size' and 'bnd_legacy' used by
> >Pointers Checker.
> >
> >Bootstrapped and tested on linux-x86_64.
> >
> >Thanks,
> >Ilya
> >--
> >
> >gcc/
> >
> >2013-10-21 Ilya Enk
On 24 Oct 23:55, Jeff Law wrote:
> On 10/21/13 06:10, Ilya Enkovich wrote:
> >Hi,
> >
> >This patch introduces two new contructor types supported by
> >cgraph_build_static_cdtor.
> >
> >'B' type is used to initialize static objects (bounds) created by Pointers
> >Checker. The difference of this t
On Wed, Oct 30, 2013 at 11:34 AM, Ilya Enkovich wrote:
> On 30 Oct 10:26, Richard Biener wrote:
>>
>> Ick - you enlarge all return statements? But you don't set the actual value?
>> So why allocate it with 2 ops in the first place??
>
> When return does not return bounds it has operand with zero
On Wed, Oct 30, 2013 at 11:48 AM, Richard Biener
wrote:
> On Wed, Oct 30, 2013 at 11:34 AM, Ilya Enkovich
> wrote:
>> On 30 Oct 10:26, Richard Biener wrote:
>>>
>>> Ick - you enlarge all return statements? But you don't set the actual
>>> value?
>>> So why allocate it with 2 ops in the first p
On Wed, Oct 30, 2013 at 11:05:58AM +0100, Jakub Jelinek wrote:
> On Wed, Oct 30, 2013 at 11:00:13AM +0100, Jakub Jelinek wrote:
> > But the above is 16 byte unaligned load. Furthermore, GCC supports
> > -mavx256-split-unaligned-load and can emit 32 byte loads either as an
> > unaligned 32 byte loa
On Wed, Oct 30, 2013 at 10:47 AM, Jakub Jelinek wrote:
> Yesterday I've noticed that for AVX which allows unaligned operands in
> AVX arithmetics instructions we still don't combine unaligned loads with the
> AVX arithmetics instructions. So say for -O2 -mavx -ftree-vectorize
This is actually P
PR58854 is another manifestation of the usual issue with the scheduler
not understanding sp fp overlap issues and hoisting such adjustments
(see PR38644 for a long history on an earlier one) over accesses from
the frame. The usual bodge in the backend is attached.
Tested arm-none-eabi cross -
On Tue, 29 Oct 2013, Jakub Jelinek wrote:
> On Tue, Oct 29, 2013 at 12:55:04PM +0100, Richard Biener wrote:
> > Surely you can't rely on CCP and VRP compute exactly the same
> > nonzero_bits. As you don't record/compute zero_bits you can't
> > tell whether a not set bit in nonzer_bits is "don't k
Kenneth Zadeck writes:
> On 10/29/2013 06:37 PM, Richard Sandiford wrote:
>> This patch tries to update the main wide_int comment to reflect the current
>> implementation.
>>
>> - bitsizetype is TImode on x86_64 and others, so I don't think it's
>>necessarily true that all offset_ints are sign
On Tue, 29 Oct 2013, Jakub Jelinek wrote:
> Hi!
>
> On Tue, Oct 29, 2013 at 04:29:56PM +0100, Jakub Jelinek wrote:
> > > Surely you can't rely on CCP and VRP compute exactly the same
> > > nonzero_bits. As you don't record/compute zero_bits you can't
> > > tell whether a not set bit in nonzer_bi
On Tue, 29 Oct 2013, Jakub Jelinek wrote:
> On Tue, Oct 29, 2013 at 01:11:53PM +0100, Richard Biener wrote:
> > > +/* Return number of known trailing zero bits in EXPR, or, if the value of
> > > + EXPR is known to be zero, the precision of it's type. */
> > > +
> > > +int
> >
> > unsigned int?
On Wed, Oct 30, 2013 at 11:55:44AM +0100, Uros Bizjak wrote:
> On Wed, Oct 30, 2013 at 10:47 AM, Jakub Jelinek wrote:
>
> > Yesterday I've noticed that for AVX which allows unaligned operands in
> > AVX arithmetics instructions we still don't combine unaligned loads with the
> > AVX arithmetics i
On Tue, 29 Oct 2013, Cong Hou wrote:
> Hi
>
> SAD (Sum of Absolute Differences) is a common and important algorithm
> in image processing and other areas. SSE2 even introduced a new
> instruction PSADBW for it. A SAD loop can be greatly accelerated by
> this instruction after being vectorized. Th
On Wed, 30 Oct 2013, Zhenqiang Chen wrote:
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Hans-Peter Nilsson
> > One thing I don't see other people mentioning, is that this patch has just
> too
> > much code inside #if
2013/10/30 Richard Biener :
> On Wed, Oct 30, 2013 at 11:34 AM, Ilya Enkovich
> wrote:
>> On 30 Oct 10:26, Richard Biener wrote:
>>>
>>> Ick - you enlarge all return statements? But you don't set the actual
>>> value?
>>> So why allocate it with 2 ops in the first place??
>>
>> When return does
This adds a struct function taking variant of
pre_and_rev_post_order_compute that also drops the assert that
all blocks were visited (consistent with the function comment).
This makes graph.c not ICE on CFGs with unreachable blocks
which it tries to handle already, but it didn't notice that
RPO o
Hi,
I'm having a look at this very old parsing issue. We reject things like:
struct S { void operator () (); };
void foo ()
{
( S()() );
}
because the parenthesized S()() triggers an hard error from groktypename
as called at the end of cp_parser_type_id (called by
cp_parser_cast_expression
Il 18/09/2013 11:45, Zhenqiang Chen ha scritto:
> +;; Expand conditional compare according to the instruction patterns.
> +(define_expand "conditional_compare"
> + [(set (match_operand 0 "s_register_operand" "")
> + (match_operator 1 ""
> + [(match_operator:SI 2 "arm_comparison_operator"
On Wed, 30 Oct 2013, Richard Biener wrote:
On Wed, Oct 30, 2013 at 1:09 AM, Marc Glisse wrote:
On Tue, 29 Oct 2013, Richard Biener wrote:
For the POINTER_PLUS_EXPR offset argument you should use
int_cst_value () to access it (it will unconditionally sign-extend)
and use host_integerp (..., 0
On 10/30/2013 07:01 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 10/29/2013 06:37 PM, Richard Sandiford wrote:
This patch tries to update the main wide_int comment to reflect the current
implementation.
- bitsizetype is TImode on x86_64 and others, so I don't think it's
necessar
Partially fixing a bug that caused lookup errors in valid programs. For example:
template
pair::type void f(T, U); // Error, no such pair
When entering a template scope, we tried to match the template to one
having the same constraints. Obviously pair doesn't have Int and Float
constraints, and
On Mon, Oct 28, 2013 at 09:01:45PM +, Iyer, Balaji V wrote:
> Thanks! I will extract and check in the Cilk_spawn and _Cilk_sync for C work.
This broke bootstrap on i686-linux, fixed thusly, committed as obvious:
2013-10-30 Jakub Jelinek
* cilk.c (create_cilk_helper_decl): Use HOST
Applying a patch from Ville that adds diagnostics for the concept
specifier. Thanks Ville!
2013-10-30 Ville Voutilainen
* gcc/cp/decl.c (grokdeclarator): Reject concept keyword
in typedefs, function parameters, data members, non-static
member functions and variables. All
On Wed, Oct 30, 2013 at 1:43 PM, Marc Glisse wrote:
> On Wed, 30 Oct 2013, Richard Biener wrote:
>
>> On Wed, Oct 30, 2013 at 1:09 AM, Marc Glisse wrote:
>>>
>>> On Tue, 29 Oct 2013, Richard Biener wrote:
>>>
For the POINTER_PLUS_EXPR offset argument you should use
int_cst_value () to a
On Tue, Oct 29, 2013 at 10:18 AM, bin.cheng wrote:
> Hi,
> I noticed that IVOPT generates complex address expressions like below for iv
> base.
> &arr_base[0].y
> &arr[0]
> &MEM[p+o]
> It's even worse for targets support auto-increment addressing mode because
> IVOPT adjust
On Fri, Oct 25, 2013 at 03:04:41PM -0400, Jason Merrill wrote:
> >I'm sorry, you want me to move the c++1y VLA check into
> >compute_array_index_type, or just do the ubsan instrumentation in
> >there? Thanks,
>
> Both.
Unfortunately, I'm having quite a lot of trouble with side-effects. :(
For e.
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58784
LRA has an old check of legitimate addresses. It was written before a
newer address decomposition code which makes more correct checks of
addresses.
So I removed the old check.
Committed as rev. 204215.
2013-10-30
Hello Everyone,
What I ideally wanted to do with my testsuite files was that I want all
the Cilk keywords test to compile no matter what the architecture is, but it
should only run in certain architectures where the runtime is enabled (this is
known statically and thus the testsuite does
The following patch fixes:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58785
LRA chooses constraint 'm' for const_int operand. It means that the
const_int should be placed in memory but it does not happen as preferred
reload class hook returns LO_REGS for class NO_REGS which is result of
LRA
This isn't a regression but is tiny and removes an unnecessary
pessimisation, so I'm committing it to the 4.7 and 4.8 branches. The
problem doesn't exist on the trunk.
Tested x86_64-linux.
2013-10-30 Chris Studholme
PR libstdc++/58912
* include/bits/shared_ptr_base.h (_Sp_cou
On 10/29/2013 01:37 PM, Dehao Chen wrote:
If we're actually emitting the name now, we need to give it a name different
from the complete constructor. I suppose it makes sense to go with C4/D4 as
in the decloning patch,
Shall we do it in a separate patch? And I suppose binutils also need
to be
I find -Wformat warnings about unknown % codes when building with an
older GCC to be mildly annoying noise; this patch avoids them by passing
-Wno-format during stage 1.
Tested x86_64-pc-linux-gnu. Is this OK for trunk? Do you have another
theory of how this should work?
commit c40b06619fc
On 10/30/2013 10:52 AM, Marek Polacek wrote:
+ if ((flag_sanitize & SANITIZE_VLA)
+ && !processing_template_decl
You don't need to check processing_template_decl; the template case was
already handled above.
+ tree x = cp_save_expr (size);
+ x = b
On 10/30/13 03:34, Richard Biener wrote:
* tree-ssa-alias.c (stmt_kills_ref_p_1): Handle case where
ao_ref_base returns a MEM_REF.
* gcc.dg/tree-ssa/alias-26.c: New test.
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/alias-26.c
b/gcc/testsuite/gcc.dg/tree-ssa/alias-26.c
On Tue, 2013-09-10 at 15:36 +0200, Jan Hubicka wrote:
> > Amongst other things, the rename_symtab.py script converts
> > "symtab_node" to "symtab_node *".
> >
> > This will lead to broken code on declarations that declare
> > more than one variable (only the first would get a "*"), so split
> > up
On 10/30/13 00:09, Zhenqiang Chen wrote:
On 30 October 2013 02:47, Jeff Law wrote:
On 10/24/13 02:20, Zhenqiang Chen wrote:
Hi,
REG_INC note is lost in subreg2 pass when resolve_simple_move, which
might lead to wrong dependence for ira. e.g. In function
validate_equiv_mem of ira.c, it checks
Il 30/10/2013 16:47, Jason Merrill ha scritto:
> I find -Wformat warnings about unknown % codes when building with an
> older GCC to be mildly annoying noise; this patch avoids them by passing
> -Wno-format during stage 1.
>
> Tested x86_64-pc-linux-gnu. Is this OK for trunk?
Ok.
On 10/30/13 03:26, Richard Biener wrote:
diff --git a/gcc/gimple.c b/gcc/gimple.c
index 3ddceb9..20f6010 100644
--- a/gcc/gimple.c
+++ b/gcc/gimple.c
@@ -174,7 +174,7 @@ gimple_build_with_ops_stat (enum gimple_code code, unsigned
subcode,
gimple
gimple_build_return (tree retval)
{
- gimpl
On Wed, Oct 30, 2013 at 11:56:25AM -0400, Jason Merrill wrote:
> On 10/30/2013 10:52 AM, Marek Polacek wrote:
> >+ if ((flag_sanitize & SANITIZE_VLA)
> >+ && !processing_template_decl
>
> You don't need to check processing_template_decl; the template case
> was already handled
On Wed, 30 Oct 2013, Richard Biener wrote:
Btw, get_addr_base_and_unit_offset may also return an offsetted
MEM_REF (from &MEM [p_3, 17] for example). As we are interested in
pointers this could be handled by not requiring a memory reference
but extracting the base address and offset, covering m
On 10/30/2013 02:47 AM, Jakub Jelinek wrote:
> 2013-10-30 Jakub Jelinek
>
> * config/i386/i386.c (ix86_avx256_split_vector_move_misalign): If
> op1 is misaligned_operand, just use *mov_internal insn
> rather than UNSPEC_LOADU load.
> (ix86_expand_vector_move_misalign): L
On 10/30/2013 06:14 AM, Eric Botcazou wrote:
+/* Return whether DECL, a method of a C++ TYPE, is trivial, that is to say
+ doesn't do anything for the objects of TYPE. */
+
+static bool
+is_trivial_method (const_tree decl, const_tree type)
+{
+ if (cpp_check (decl, IS_CONSTRUCTOR) && !TYPE_NE
On 10/30/13 04:34, Ilya Enkovich wrote:
On 30 Oct 10:26, Richard Biener wrote:
Ick - you enlarge all return statements? But you don't set the
actual value? So why allocate it with 2 ops in the first place??
When return does not return bounds it has operand with zero value
similar to case whe
I found my problem: I put DONE outside of if not inside. You are
right. I have updated my patch.
I appreciate your comment and test on it!
thanks,
Cong
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 8a38316..84c7ab5 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2013-10-22
Forget to attach the patch file.
thanks,
Cong
On Wed, Oct 30, 2013 at 10:01 AM, Cong Hou wrote:
> I found my problem: I put DONE outside of if not inside. You are
> right. I have updated my patch.
>
> I appreciate your comment and test on it!
>
>
> thanks,
> Cong
>
>
>
> diff --git a/gcc/Chan
On 10/30/13 09:09, Iyer, Balaji V wrote:
Hello Everyone, What I ideally wanted to do with my testsuite files
was that I want all the Cilk keywords test to compile no matter what
the architecture is, but it should only run in certain architectures
where the runtime is enabled (this is known static
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 30, 2013 1:08 PM
> To: Iyer, Balaji V; Tobias Burnus; gcc patches
> Subject: Re: Testsuite / Cilk Plus: Include library path in compile flags in
> gcc.dg/cilk-plus/cilk-plus.exp
>
> On 10/30/13 09:09,
On Wed, 30 Oct 2013, Jeff Law wrote:
> /* { dg-do compile } */
> /* { dg-do run { target i?86-*-* x86-64-*-* } } */
But with an effective-target keyword cilkplusrts or similar, rather than
hardcoding the same list of targets in lots of places, please.
--
Joseph S. Myers
jos...@codesourcery.com
> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Wednesday, October 30, 2013 1:15 PM
> To: Jeff Law
> Cc: Iyer, Balaji V; Tobias Burnus; gcc patches
> Subject: Re: Testsuite / Cilk Plus: Include library path in compile flags in
> gcc.dg/cilk-plus/cilk-plu
I ran into a build problem while doing a canadian cross build of GCC.
I was building on linux to create a Windows (mingw) GCC that generates
code for mips-mti-elf.
The mips-mti-elf target uses newlib for its system headers and libraries
and the headers do not include a fenv.h header file. Howeve
On 10/30/13 11:12, Iyer, Balaji V wrote:
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: Wednesday, October 30, 2013 1:08 PM
To: Iyer, Balaji V; Tobias Burnus; gcc patches
Subject: Re: Testsuite / Cilk Plus: Include library path in compile flags in
gcc.dg/cilk-plus/cilk-p
At the Chicago meeting the EWG agreed that we don't need to throw on
0-length VLAs.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 1e328cbd26bfb641db8e218e4a4c32fc1a9a8d9d
Author: Jason Merrill
Date: Fri Oct 25 06:15:01 2013 -0400
* decl.c (cp_finish_decl): Never throw for VLA bo
On Wed, Oct 30, 2013 at 6:01 PM, Cong Hou wrote:
> I found my problem: I put DONE outside of if not inside. You are
> right. I have updated my patch.
OK, great that we put things in order ;)
Does this patch need some extra middle-end functionality? I was not
able to vectorize char and short part
On 10/30/13 11:16, Iyer, Balaji V wrote:
-Original Message-
From: Joseph Myers [mailto:jos...@codesourcery.com]
Sent: Wednesday, October 30, 2013 1:15 PM
To: Jeff Law
Cc: Iyer, Balaji V; Tobias Burnus; gcc patches
Subject: Re: Testsuite / Cilk Plus: Include library path in compile flag
OK.
Jason
On 10/30/13 04:48, Richard Biener wrote:
foo (int * p, unsigned int size)
{
__bound_tmp.0;
long unsigned int D.2239;
long unsigned int _2;
sizetype _6;
int * _7;
:
__bound_tmp.0_4 = __builtin_ia32_arg_bnd (p_3(D));
:
_2 = (long unsigned int) size_1(D);
__builtin_i
On Wed, Oct 30, 2013 at 09:17:04AM -0700, Richard Henderson wrote:
> On 10/30/2013 02:47 AM, Jakub Jelinek wrote:
> > 2013-10-30 Jakub Jelinek
> >
> > * config/i386/i386.c (ix86_avx256_split_vector_move_misalign): If
> > op1 is misaligned_operand, just use *mov_internal insn
> > rat
On Wed, Oct 30, 2013 at 12:11 PM, Jakub Jelinek wrote:
>> > Yesterday I've noticed that for AVX which allows unaligned operands in
>> > AVX arithmetics instructions we still don't combine unaligned loads with
>> > the
>> > AVX arithmetics instructions. So say for -O2 -mavx -ftree-vectorize
>>
>
On Wed, Oct 30, 2013 at 6:42 PM, Uros Bizjak wrote:
> On Wed, Oct 30, 2013 at 12:11 PM, Jakub Jelinek wrote:
>
>>> > Yesterday I've noticed that for AVX which allows unaligned operands in
>>> > AVX arithmetics instructions we still don't combine unaligned loads with
>>> > the
>>> > AVX arithmeti
On 30 Oct 2013, at 08:16, "Vladimir Makarov" wrote:
> The following patch fixes:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58785
>
> LRA chooses constraint 'm' for const_int operand. It means that the
> const_int should be placed in memory but it does not happen as preferred
> reload c
On Wed, Oct 30, 2013 at 10:22 AM, Uros Bizjak wrote:
> On Wed, Oct 30, 2013 at 6:01 PM, Cong Hou wrote:
>> I found my problem: I put DONE outside of if not inside. You are
>> right. I have updated my patch.
>
> OK, great that we put things in order ;)
>
> Does this patch need some extra middle-en
Also, as the current expand for abs() on 8/16bit integer is not used
at all, should I comment them temporarily now? Later I can uncomment
them once I finished the pattern recognizer.
thanks,
Cong
On Wed, Oct 30, 2013 at 10:22 AM, Uros Bizjak wrote:
> On Wed, Oct 30, 2013 at 6:01 PM, Cong Hou
On 30 Oct 11:40, Jeff Law wrote:
> On 10/30/13 04:48, Richard Biener wrote:
> >foo (int * p, unsigned int size)
> >{
> >__bound_tmp.0;
> > long unsigned int D.2239;
> > long unsigned int _2;
> > sizetype _6;
> > int * _7;
> >
> > :
> > __bound_tmp.0_4 = __builtin_ia32_arg_bnd (p_3(D
On Wed, Oct 30, 2013 at 7:01 PM, Cong Hou wrote:
>>> I found my problem: I put DONE outside of if not inside. You are
>>> right. I have updated my patch.
>>
>> OK, great that we put things in order ;)
>>
>> Does this patch need some extra middle-end functionality? I was not
>> able to vectorize c
Kenneth Zadeck writes:
> On 10/30/2013 07:01 AM, Richard Sandiford wrote:
>> Kenneth Zadeck writes:
>>> On 10/29/2013 06:37 PM, Richard Sandiford wrote:
This patch tries to update the main wide_int comment to reflect the current
implementation.
- bitsizetype is TImode on x86_6
2013/10/30 Jeff Law :
> On 10/30/13 04:34, Ilya Enkovich wrote:
>>
>> On 30 Oct 10:26, Richard Biener wrote:
>>>
>>>
>>> Ick - you enlarge all return statements? But you don't set the
>>> actual value? So why allocate it with 2 ops in the first place??
>>
>>
>> When return does not return bounds i
> > +/* Return whether DECL, a method of a C++ TYPE, is trivial, that is to
> > say + doesn't do anything for the objects of TYPE. */
> > +
> > +static bool
> > +is_trivial_method (const_tree decl, const_tree type)
> > +{
> > + if (cpp_check (decl, IS_CONSTRUCTOR) && !TYPE_NEEDS_CONSTRUCTING
>
Hi,
to resolve this simple ICE we only have to check the return value of
mark_used, like we do in a number of other places. Tested x86_64-linux.
Thanks!
Paolo.
/
/cp
2013-10-30 Paolo Carlini
PR c++/58581
* call.c (build_over_call): Check return valu
On 10/18/13 14:17, Mikael Pettersson wrote:
> Thanks Mikael. My only concern is the lack of adjustment when the value
> found was already a SUBREG.
>
> ie, let's assume rld[r].in_reg was something like
> (subreg:XF (reg:DF) 0)
>
> and our target is (reg:DF)
>
> In this case it
Iyer, Balaji V wrote:
What I ideally wanted to do with my testsuite files was that I want
all the Cilk keywords test to compile no matter what the architecture
is, but it should only run in certain architectures where the runtime
is enabled (this is known statically and thus the testsuite doesn
> * * *
>
> Actually, I was wondering whether -fcilkplus should always automatically link
> libcilkrts - akin to -fopenmp which links libgomp. Currently, one has to
> specify it
> manually.*
Yes, I would like that to happen. Do you have any pointers about how to do that?
OK.
Jason
Iyer, Balaji V wrote:
* * *
Actually, I was wondering whether -fcilkplus should always automatically link
libcilkrts - akin to -fopenmp which links libgomp. Currently, one has to
specify it
manually.*
Yes, I would like that to happen. Do you have any pointers about how to do that?
Well, if y
On 10/30/13 13:27, Iyer, Balaji V wrote:
* * *
Actually, I was wondering whether -fcilkplus should always automatically link
libcilkrts - akin to -fopenmp which links libgomp. Currently, one has to
specify it
manually.*
Yes, I would like that to happen. Do you have any pointers about how to d
On 10/30/13 04:34, Tobias Burnus wrote:
Without that patch, which I have copied from asan-dg.exp, I get tons of
failures because "ld" cannot find libcilkrts.
OK for committal?
Tobias
cilk.diff
2013-10-30 Tobias Burnus
* gcc.dg/cilk-plus/cilk-plus.exp: Add the libcilkrts library
On 10/30/13 12:12, Ilya Enkovich wrote:
GIMPLE layout depending on flag_check_pointer_bounds sounds like
a recipie for desaster if you consider TUs compiled with and TUs
compiled without and LTO. Or if you consider using optimized
attribute with that flag.
Sorry, I don't follow. Can you elabo
1 - 100 of 154 matches
Mail list logo
