On 5 October 2011 20:06, Jakub Jelinek wrote:
> Hi!
>
> If vect_recog_func fails (or the other spot where vect_pattern_recog_1
> returns early), the vector allocated in the function isn't freed, leading
> to memory leak. But, more importantly, doing a VEC_alloc + VEC_free
> num_stmts_in_loop * NU
Unfortunately, only 64-bit versions of popc and lzd exist, so I have
to play some shenanigans to make SImode and v8plus cases work. But
it's definitely worth it. I plan to tweak this stuff and perhaps also
add some explicit ffs patterns as well later.
There are only two sets of VIS3 instruction
On Thu, 6 Oct 2011, Artem Shinkarov wrote:
> On Thu, Oct 6, 2011 at 3:27 AM, Hans-Peter Nilsson wrote:
> > Write that changelog entry as:
> >
> > PR middle-end/50607
> > * c-tree.h (c_expr_t): New typedef for struct c_expr.
> > (C_EXPR_APPEND): New macro.
> > * c-parser
Bernd Schmidt writes:
> This appears to be because the split prologue contains a jump, which
> means the find_many_sub_blocks call reorders the block numbers, and our
> indices into bb_flags are off.
>
> I'm testing the following patch, but it won't finish today - feel free
> to test and check it
I merged mainlined revision 179565 to the gccgo branch. I included a
patch disabling -fshrink-wrap if -fstack-prologue is enabled.
Ian
On Thu, Oct 6, 2011 at 3:27 AM, Hans-Peter Nilsson wrote:
> On Thu, 6 Oct 2011, Artem Shinkarov wrote:
>> Successfully regtested on x86-unknown-linux-gnu. Committed to the
>> mainline with the revision 179588.
>>
>> ChangeLog:
>> 2011-10-06 Artjoms Sinkarovs
>> * c-tree.h (c_expr_t): Ne
On Thu, 6 Oct 2011, Artem Shinkarov wrote:
> Successfully regtested on x86-unknown-linux-gnu. Committed to the
> mainline with the revision 179588.
>
> ChangeLog:
> 2011-10-06 Artjoms Sinkarovs
> * c-tree.h (c_expr_t): New typedef for struct c_expr.
> (C_EXPR_APPEND): New macro.
On Wed, Oct 5, 2011 at 5:32 PM, Artem Shinkarov
wrote:
> On Wed, Oct 5, 2011 at 5:28 PM, Joseph S. Myers
> wrote:
>> On Wed, 5 Oct 2011, Artem Shinkarov wrote:
>>
>>> Joseph, is it possible to commit the patch together with the space fixes?
>>
>> You should not commit whitespace fixes to lines n
Hi,
2011-10-04 Jonathan Wakely
* include/ext/alloc_traits.h (__alloc_traits::max_size): Define.
(__alloc_traits::rebind): Define.
* include/bits/stl_vector.h: Use them.
* testsuite/util/testsuite_allocator.h (SimpleAllocator): Define.
* testsuite/23_conta
On 10/05/2011 05:15 PM, Jakub Jelinek wrote:
If optimize_specialization_lookup_p (tmpl) doesn't change return value in
between the two calls, then you are right. But perhaps in that case
you could avoid the second call and use slot != NULL instead.
That makes sense too.
Jason
Hi,
committed to mainline.
Paolo.
2011-10-05 Paolo Carlini
* include/ext/pod_char_traits.h: Avoid warnings in C++0x mode
when int_type is unsigned.
Index: include/ext/pod_char_traits.h
===
-
Hi,
the below hunk seems spurious?!?
Paolo.
/
Index: include/bits/locale_facets.tcc
===
--- include/bits/locale_facets.tcc (revision 179579)
+++ include/bits/locale_facets.tcc (working copy)
@@ -635,15 +635,1
On 10/06/11 01:04, Ian Lance Taylor wrote:
> On Wed, Oct 5, 2011 at 10:17 AM, Bernd Schmidt
> wrote:
>>
>> I've committed the following after a x86_64-linux bootstrap.
>
> This patch appears to have broken the Go bootstrap when compiling a C
> file in libgo. Here is a reduced test case:
>
> st
> I'm going to let this chill a bit on mainline and then check in to
> 4.6.x.
Seems fine so I dropped this into the 4_6-branch
tested x86/linux
-benjamin
2011-10-05 Benjamin Kosnik
PR libstdc++/48698
* acinclude.m4 (GLIBCXX_ENABLE_SYMVERS): Set libtool_VERSION here.
On 10/05/2011 03:23 AM, Nick Clifton wrote:
> The final fix was pointed out by Richard Henderson. The recently
> added support for narrow mode min and max instructions did not work
> for the SMAX insn, as the RX does not have narrow mode versions of
> this insn.
The SMIN pattern has the s
On 10/05/2011 02:28 PM, Anatoly Sokolov wrote:
> * system.h (OUTPUT_ADDR_CONST_EXTRA): Poison.
> * doc/tm.texi.in (OUTPUT_ADDR_CONST_EXTRA): Remove documentation.
> * doc/tm.texi: Regenerate.
> * target.def (output_addr_const_extra): Use
> hook_bool_FILEptr_r
On Wed, Oct 5, 2011 at 10:17 AM, Bernd Schmidt wrote:
>
> I've committed the following after a x86_64-linux bootstrap.
This patch appears to have broken the Go bootstrap when compiling a C
file in libgo. Here is a reduced test case:
static struct
{
int n;
unsigned int m;
_Bool f;
} g;
_B
>> If you have a cute idea how to elegantly introduce warnings into this
>> mechanism, I'm all ears.
> I'm not sure that it qualifies as cute, but we could produce multi-line
> diagnostics in the same way c++ does (for template candidates for example),
> like:
> error/warning: #the error/warning
>
On 10/05/11 23:23, Steven Bosscher wrote:
> On Wed, Oct 5, 2011 at 10:48 PM, Bernd Schmidt
> wrote:
>> Bootstrapped and tested on i686-linux. Ok?
>
>> +/* Return true if BB has any active insns. */
>> +static bool
>> +bb_active_p (basic_block bb)
>> +{
>> + rtx label;
>> +
>> + /* Test whethe
Hi.
No one back end does not use OUTPUT_ADDR_CONST_EXTRA macro now, this patch
remove it. The TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA target hook should be use
instead.
The patch has been bootstrapped on and regression tested on
x86_64-unknown-linux-gnu for c and c++.
This patch is pre-approv
On Wed, Oct 5, 2011 at 10:48 PM, Bernd Schmidt wrote:
> Bootstrapped and tested on i686-linux. Ok?
> +/* Return true if BB has any active insns. */
> +static bool
> +bb_active_p (basic_block bb)
> +{
> + rtx label;
> +
> + /* Test whether there are active instructions in the last block. */
>
On Wed, Oct 05, 2011 at 05:03:45PM -0400, Jason Merrill wrote:
> On 10/05/2011 04:05 PM, Jakub Jelinek wrote:
> >BTW, register_specialization has the same problems. If slot != NULL and fn
> >== NULL, it can still return without storing non-NULL into *slot
> >(when optimize_specialization_lookup_p
On 10/05/2011 11:55 AM, Ed Smith-Rowland wrote:
+ int num_parms = TREE_VEC_LENGTH (parameter_list);
+ if (num_parms != 1)
+ ok = false;
+ else
+ {
+ tree parm_list = TREE_VEC_ELT (parameter_list, 0);
+ tree parm = INNERMOST_TEMPL
On 10/05/2011 10:46 AM, Richard Guenther wrote:
> On Tue, Oct 4, 2011 at 6:28 PM, Tom de Vries wrote:
>> On 10/04/2011 03:03 PM, Richard Guenther wrote:
>>> On Tue, Oct 4, 2011 at 9:43 AM, Tom de Vries wrote:
On 10/01/2011 05:46 PM, Tom de Vries wrote:
> On 09/30/2011 03:29 PM, Richard G
On 10/05/2011 04:05 PM, Jakub Jelinek wrote:
BTW, register_specialization has the same problems. If slot != NULL and fn
== NULL, it can still return without storing non-NULL into *slot
(when optimize_specialization_lookup_p (tmpl) returns non-zero).
You can do else if (slot != NULL&& fn == NULL
This adds a little mini-pass to shrink-wrapping, to eliminate a common
case that often makes shrink-wrapping unavailable. If a move insn copies
an argument registers to a call-saved register, the prologue must be
emitted before this insn. We should therefore try to delay such moves
for as long as p
On Wed, 2011-10-05 at 21:01 +0200, Paolo Bonzini wrote:
> On 10/05/2011 07:22 PM, William J. Schmidt wrote:
> > I don't know off the top of my head -- I'll have to gather that
> > information. The issue is that the profitability is really
> > context-sensitive, so just the isolated costs of insns
On Wed, Oct 05, 2011 at 03:49:38PM -0400, Diego Novillo wrote:
> Jason, I don't think this is affecting any bugs in trunk, but it looks
> worth fixing. OK for trunk?
Well, it can cause problems. Consider 3 entries in the hash table
with the same hash. (1) inserted first, then (2), then (3), then
This fixes the problem I described in
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00376.html
The tests are now failing assembly comparisons because the elements in
these tables are emitted in different sequence in the pph and non-pph
case. Other than that, the assembly produced is identical.
T
I found this bug while debugging a failure in pph images with template
classes. When writing the decl_specializations table, the writer
calls htab_elements() to output the length of the table. It then
traverses the table with htab_traverse_noresize() to emit all the
entries.
The reader uses tha
On Wed, Oct 5, 2011 at 7:42 PM, Uros Bizjak wrote:
> 2011-10-05 Uros Bizjak
>
> * gcc.dg/vect/vect.exp (VEC_CFLAGS): Move initialization after
> DEFAULT_VECTFLAGS initialization.
>
Actually, these testcases need a bit more surgery...
2011-10-05 Uros Bizjak
* gcc.dg/
On 10/05/2011 07:22 PM, William J. Schmidt wrote:
I don't know off the top of my head -- I'll have to gather that
information. The issue is that the profitability is really
context-sensitive, so just the isolated costs of insns aren't enough.
The forward propagation of the add into (mem (reg REG
On Wed, Oct 5, 2011 at 14:20, Mike Stump wrote:
> On Oct 5, 2011, at 6:18 AM, Diego Novillo wrote:
>> I think we need to find a solution for this situation.
>
> The solution Apple found and implemented is a __nodebug__ attribute, as can
> be seen in Apple's gcc.
>
> We use it like so:
>
> #define
On Oct 5, 2011, at 6:18 AM, Diego Novillo wrote:
> I think we need to find a solution for this situation.
The solution Apple found and implemented is a __nodebug__ attribute, as can be
seen in Apple's gcc.
We use it like so:
#define __always_inline__ __always_inline__, __nodebug__
#undef __alwa
On Wed, Oct 5, 2011 at 12:49 PM, Kirill Yukhin wrote:
> We're prepared and bunch of tests which checks autogeneration of FMA3
> instructions family.
> FMA3 typo in .md file is fixed as well (it was catched by tests).
>
> ChangeLog entry:
>
> 2011-10-04 Kirill Yukhin
> Yakovlev Vladim
Hi!
If vect_recog_func fails (or the other spot where vect_pattern_recog_1
returns early), the vector allocated in the function isn't freed, leading
to memory leak. But, more importantly, doing a VEC_alloc + VEC_free
num_stmts_in_loop * NUM_PATTERNS times seems to be completely unnecessary,
the f
On 10/05/2011 10:19 AM, Bernd Schmidt wrote:
> * function.c (thread_prologue_and_epilogue_insns): Don't shrink-wrap
> if profiling after the prologue.
Ok.
r~
---
gcc/testsuite/ChangeLog| 11 ++
.../gcc.c-torture/execute/vect-shuffle-1.c | 98 +++---
.../gcc.c-torture/execute/vect-shuffle-2.c | 96 +++--
.../gcc.c-torture/execute/vect-shuffle-3.c | 90 ++--
.
1: Handle TARGET_XOP.
2: Reduce code duplication.
3: Use ASHIFT instead of MULT for scaling.
4: Fix errors in building convert-to-v16qi indicies.
5: Handle v2di without sse4.1.
---
gcc/ChangeLog |6 +
gcc/config/i386/i386-protos.h |2 +-
gcc/config/i386/i386.c| 208
1: It can never fail.
2: It should mask the input indicies.
---
gcc/ChangeLog |8 ++
gcc/tree-vect-generic.c | 276 +--
2 files changed, 107 insertions(+), 177 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 4bdda3d..a88854d
The first problem is that the generic lowering to scalar implementation
didn't match the documentation in that the shuffle indicies are to be
masked to the range of the inputs. Or, perhaps more exactly, the generic
lowering didn't match the SSE implementation which does do the masking.
The OpenCL
Hello!
2011-10-05 Uros Bizjak
* gcc.dg/vect/vect.exp (VEC_CFLAGS): Move initialization after
DEFAULT_VECTFLAGS initialization.
Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline SVN.
Uros.
Index: gcc.dg/vect/vect.exp
=
On Wed, 2011-10-05 at 18:21 +0200, Paolo Bonzini wrote:
> On 10/05/2011 06:13 PM, William J. Schmidt wrote:
> > One other general question about the pattern-match transformation: Is
> > this an appropriate transformation for all targets, or should it be
> > somehow gated on available addressing mo
Hello!
No functional change.
2011-10-05 Uros Bizjak
* config/i386/i386.c (distance_non_agu_define): Simplify calculation
of "found". Simplify return value calculation.
(distance_agu_use): Ditto.
Tested on x86_64-pc-linux-gnu {,-m32} with shrink-wrapping disabled,
com
On 10/05/11 00:29, Richard Henderson wrote:
> As a followup, I think this option needs to be disabled for profiling
> and profile_after_prologue. Should be a mere matter of frobbing the
> options at startup.
The other code seems to test crtl->profile rather than an option flag,
so how's this? Boo
On 10/05/11 18:21, Richard Henderson wrote:
> On 10/05/2011 08:59 AM, Bernd Schmidt wrote:
>> Bootstrapping the following now. Ok? (Alternatively, could keep the
>> redzone logic, but make it depend on !flag_shrink_wrap).
>
> It's a good space-saving optimization, that redzone logic. We
> should
On Wed, 2011-10-05 at 18:29 +0200, Steven Bosscher wrote:
> On Wed, Oct 5, 2011 at 6:13 PM, William J. Schmidt
> wrote:
> >* tree-ssa-loop-ivopts.c (copy_ref_info): Remove static token.
>
> Rather than this, why not move the function to common code somewhere?
>
> Ciao!
> Steven
An alter
On Wed, Oct 5, 2011 at 6:19 PM, Michael Matz wrote:
>> Looking at this topic again, I'd propose that x86 adopts approach from
>> rs6000. The rs6000 approach is more extensible, and offers the same
>> flexibility, due to "!".
>>
>> So, x86 could have "-mrecip=", with all, default, none, div,
>> ve
On Oct 5, 2011, at 12:47 AM, Sharad Singhai wrote:
> This patch adds an intermediate coverage format (enabled via 'gcov
> -i'). This is a compact format as it does not require source files.
I don't like any of the tags, I think if you showed them to 100 people that had
used gcov before, very few
On Wed, Oct 5, 2011 at 11:28, Diego Novillo wrote:
> On Wed, Oct 5, 2011 at 10:51, Richard Guenther
> wrote:
>
>> Did you also mark the function with always_inline? That's a requirement
>> as artificial only works for inlined function bodies.
>
> Yeah. It doesn't quite work as I expect it to.
On Fri, 2011-09-30 at 10:37 -0700, Janis Johnson wrote:
> Patch http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00625.html was
> approved by Jason last December but I never got around to checking
> it in. Paolo Carlini said in PR44473 that it was already approved
> and doesn't need a new approval, so
On Wed, Oct 5, 2011 at 5:28 PM, Joseph S. Myers wrote:
> On Wed, 5 Oct 2011, Artem Shinkarov wrote:
>
>> Joseph, is it possible to commit the patch together with the space fixes?
>
> You should not commit whitespace fixes to lines not otherwise modified by
> a patch, except in a separate commit th
On Wed, Oct 5, 2011 at 6:13 PM, William J. Schmidt
wrote:
> * tree-ssa-loop-ivopts.c (copy_ref_info): Remove static token.
Rather than this, why not move the function to common code somewhere?
Ciao!
Steven
On Wed, 5 Oct 2011, Artem Shinkarov wrote:
> Joseph, is it possible to commit the patch together with the space fixes?
You should not commit whitespace fixes to lines not otherwise modified by
a patch, except in a separate commit that *only* has whitespace or other
formatting fixes, so that "sv
On Wed, Oct 5, 2011 at 4:22 PM, Joseph S. Myers wrote:
> On Wed, 5 Oct 2011, Artem Shinkarov wrote:
>
>> On Tue, Oct 4, 2011 at 11:51 PM, Joseph S. Myers
>> wrote:
>> > On Tue, 4 Oct 2011, Artem Shinkarov wrote:
>> >
>> >> Hi
>> >>
>> >> Here is the patch tho fix bconstp-3.c failure in the bug 50
On 10/05/2011 06:13 PM, William J. Schmidt wrote:
One other general question about the pattern-match transformation: Is
this an appropriate transformation for all targets, or should it be
somehow gated on available addressing modes on the target processor?
Bootstrapped and regression tested on
On 10/05/2011 08:59 AM, Bernd Schmidt wrote:
> Bootstrapping the following now. Ok? (Alternatively, could keep the
> redzone logic, but make it depend on !flag_shrink_wrap).
It's a good space-saving optimization, that redzone logic. We
should be able to keep it based on crtl->shrink_wrapped; that
> "Jakub" == Jakub Jelinek writes:
Jakub> I don't mind if it goes into gdb, but IMHO the blacklisting should
Jakub> definitely default to blacklisting DW_AT_artificial inline functions
Jakub> (and allowing to unblacklist them), because the artificial attribute
Jakub> has been designed for tha
Hi,
On Mon, 19 Sep 2011, Uros Bizjak wrote:
> Looking at this topic again, I'd propose that x86 adopts approach from
> rs6000. The rs6000 approach is more extensible, and offers the same
> flexibility, due to "!".
>
> So, x86 could have "-mrecip=", with all, default, none, div,
> vec-div, divf
> "Diego" == Diego Novillo writes:
Tom> http://sourceware.org/bugzilla/show_bug.cgi?id=8287
Diego> I think this could work. I'm not sure I like the idea of having to
Diego> specify all these blacklist commands, but I appreciate how it can make
Diego> debugging more flexible.
Yeah, that'
This patch addresses the poor code generation in PR46556 for the
following code:
struct x
{
int a[16];
int b[16];
int c[16];
};
extern void foo (int, int, int);
void
f (struct x *p, unsigned int n)
{
foo (p->a[n], p->c[n], p->b[n]);
}
Prior to the fix for PR32698, gcc calculated the off
Ping!
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01855.html
On Wed, 2011-09-28 at 17:15 +0100, Sameera Deshpande wrote:
> Hi!
>
> This patch generates ARM epilogue in RTL form.
>
> The work defines new functions and reuses most of the static functions and
> patterns defined in the previous pa
Ping!
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01854.html
On Wed, 2011-09-28 at 17:15 +0100, Sameera Deshpande wrote:
> Hi!
>
> This patch generates Thumb2 epilogues in RTL form.
>
> The work involves defining new functions, predicates and patterns along with
> few changes in existing code:
On 10/05/11 17:13, Richard Guenther wrote:
> On Wed, Oct 5, 2011 at 12:29 AM, Richard Henderson wrote:
>> On 10/04/2011 03:10 PM, Bernd Schmidt wrote:
>>> * doc/invoke.texi (-fshrink-wrap): Document.
>>> * opts.c (default_options_table): Add it.
>>> * common.opt (fshrink-wrap): A
On Wed, Oct 05, 2011 at 11:42:51AM -0400, Diego Novillo wrote:
> Richi, Jakub, Lawrence, would you be OK with this approach? IIUC,
> this means we'd have to add a bunch of blacklist commands to
> gcc/gdbinit.in.
I don't mind if it goes into gdb, but IMHO the blacklisting should
definitely default
Hi Richard, Hi Paul, Hi Ramana,
Well my idea to have a header file containing all of the possible
binary file attributes does not seem to have taken off, so here is a
much simpler patch for the GCC ARM backend. It just adds comments to
the .eabi_directives (when -dA or -fverbose-asm are i
On Wed, Oct 5, 2011 at 11:27, Tom Tromey wrote:
> Diego> I proposed extending #pragma GCC options to bracket these functions
> Diego> with -g0. This would help reduce the impact of debug info size.
>
> I think this is fixing the wrong component: it means making a
> one-size-fits-all decision in
On 10/05/2011 05:27 PM, Tom Tromey wrote:
FWIW, I wrote the "macro define" stuff that Paolo posted back when I
was actively hacking on gcc.
Yes, thanks Tom! Actually, I suspected that, but couldn't remember where
I actually got it from, maybe you posted it on a public discussion
thread somewher
On Wed, Oct 5, 2011 at 10:51, Richard Guenther
wrote:
> Did you also mark the function with always_inline? That's a requirement
> as artificial only works for inlined function bodies.
Yeah. It doesn't quite work as I expect it to. It steps into the
function at odd places.
Diego.
> "Diego" == Diego Novillo writes:
Diego> Tom, Cary, Ian, any suggestions? We are trying to figure out a
Diego> compromise for tiny inline functions that are generally a nuisance
Diego> when debugging. The scenario is a call like this: big_function_foo
Diego> (inlined_f (x), inlined_g (y));
On Wed, 5 Oct 2011, Artem Shinkarov wrote:
> On Tue, Oct 4, 2011 at 11:51 PM, Joseph S. Myers
> wrote:
> > On Tue, 4 Oct 2011, Artem Shinkarov wrote:
> >
> >> Hi
> >>
> >> Here is the patch tho fix bconstp-3.c failure in the bug 50607. The
> >> failure was cause because the new parser routine did
On Wed, Oct 5, 2011 at 12:29 AM, Richard Henderson wrote:
> On 10/04/2011 03:10 PM, Bernd Schmidt wrote:
>> * doc/invoke.texi (-fshrink-wrap): Document.
>> * opts.c (default_options_table): Add it.
>> * common.opt (fshrink-wrap): Add.
>> * function.c (emit_return_into_block
Hi Guys,
I am applying the attached patch to add support for position
independent data to the RX backend. When this mode is enabled
constant data is referenced via an offset from a base address held in
a fixed register. This allows the position of this data to be
determined at run-time
On Tue, 4 Oct 2011, David Miller wrote:
There are only a few VIS 3.0 instructions left after this,
Hello,
I am happy to see all this work, but I was wondering: are these
instructions documented somewhere? It makes sense for gcc to only provide
a list in extend.texi, but I couldn't find the
On Wed, Oct 5, 2011 at 4:10 PM, Diego Novillo wrote:
> On Wed, Oct 5, 2011 at 09:45, Richard Guenther
> wrote:
>> On Wed, Oct 5, 2011 at 3:18 PM, Diego Novillo wrote:
>>> On 11-09-27 03:37 , Richard Guenther wrote:
On Tue, Sep 27, 2011 at 9:35 AM, Richard Guenther
wrote:
>
>
Diego Novillo writes:
>> It is much more important to optimize my debugging time as experienced
>> developer resources are more scarce than some random unexperienced
>> guy that happens to dig into GCC.
>>
>> ;)
>>
>> or not really ;).
>
> You are being facetious, I hope. Part of the reason that
On Wed, Oct 05, 2011 at 10:10:44AM -0400, Diego Novillo wrote:
> > Why
> > not use the artificial attribute on them instead? At least what is
> > documented
> > is exactly what we want (well, at least it seems to me).
>
> Yes, I forgot to mention in my reply. I tried it, but you still step
> in
On Wed, Oct 5, 2011 at 09:45, Richard Guenther
wrote:
> On Wed, Oct 5, 2011 at 3:18 PM, Diego Novillo wrote:
>> On 11-09-27 03:37 , Richard Guenther wrote:
>>>
>>> On Tue, Sep 27, 2011 at 9:35 AM, Richard Guenther
>>> wrote:
On Tue, Sep 27, 2011 at 9:14 AM, Jakub Jelinek wrote:
>
I'm testing a pair of patches to fix PR38885 (for constants)
and PR38884 (for non-constants) stores to complex/vector memory
and CSE of component accesses from SCCVN.
This is the piece that handles stores from constants and partial
reads of it. We can conveniently re-use fold-const native
encode
On Wed, Oct 5, 2011 at 3:18 PM, Diego Novillo wrote:
> On 11-09-27 03:37 , Richard Guenther wrote:
>>
>> On Tue, Sep 27, 2011 at 9:35 AM, Richard Guenther
>> wrote:
>>>
>>> On Tue, Sep 27, 2011 at 9:14 AM, Jakub Jelinek wrote:
On Mon, Sep 26, 2011 at 03:05:00PM -0700, Lawrence Crowl w
On 11-09-27 03:37 , Richard Guenther wrote:
On Tue, Sep 27, 2011 at 9:35 AM, Richard Guenther
wrote:
On Tue, Sep 27, 2011 at 9:14 AM, Jakub Jelinek wrote:
On Mon, Sep 26, 2011 at 03:05:00PM -0700, Lawrence Crowl wrote:
There a non-transparent change in behavior that may affect some users.
T
Hello!
Atom does not vectorize DFmode arrays by default, so add
-mtune=generic to dg-options to fix scan-assembler failures [1].
2011-10-05 Uros Bizjak
* gcc.target/i386/avx256-unaligned-load-3.c (dg-options): Add
-mtune=generic.
* gcc.target/i386/avx256-unaligned-stor
Noticed from vector lowering testcases.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-10-05 Richard Guenther
* tree-ssa-sccvn.c (vn_get_expr_for): Handle CONSTRUCTOR of
vector type.
(simplify_unary_expression): Handle BIT_FIELD_
On Wed, Oct 5, 2011 at 1:31 PM, Jakub Jelinek wrote:
> Hi!
>
> I didn't consider that the rhs1 of a gimple cast might be something
> other than SSA_NAME. Fixed thusly, bootstrapped/regtested on x86_64-linux
> and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
> 2011-10-05 Jakub Jelinek
>
>
On Wed, Oct 5, 2011 at 1:28 PM, Artem Shinkarov
wrote:
> On Wed, Oct 5, 2011 at 9:40 AM, Richard Guenther
> wrote:
>> On Wed, Oct 5, 2011 at 12:18 AM, Artem Shinkarov
>> wrote:
>>> Hi
>>>
>>> Here is a patch to inform a programmer about the expanded vector operation.
>>> Bootstrapped on x86-unkn
Hi!
I didn't consider that the rhs1 of a gimple cast might be something
other than SSA_NAME. Fixed thusly, bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk?
2011-10-05 Jakub Jelinek
PR tree-optimization/50613
* tree-ssa-strlen.c (find_equal_ptrs): If CASE_C
On Wed, Oct 5, 2011 at 9:40 AM, Richard Guenther
wrote:
> On Wed, Oct 5, 2011 at 12:18 AM, Artem Shinkarov
> wrote:
>> Hi
>>
>> Here is a patch to inform a programmer about the expanded vector operation.
>> Bootstrapped on x86-unknown-linux-gnu.
>>
>> ChangeLog:
>>
>> * gcc/tree-vect-gener
Hi,
as analyzed by Jakub in the audit trail, after changes made by Mark back
in 2005, constant_value_1 doesn't return aggregate constants for fear of
inadvertent copies (in general their addresses must be the same
everywhere). However, for the purpose of format checking in
check_format_arg it
When making COND_EXPR/VEC_COND_EXPR a gimple ternary op I forgot
to update ternary handling in gimple_fold_stmt_to_constant_1 to also
valueize and fold the embedded comparison. Done so. This also
adjusts SCCVN to accept a SSA name result from that folder, when
simplifying A > 1 ? 2 : C to C, whi
2011/10/5 Georg-Johann Lay :
>
> Ping #1: http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01690.html
>
> Georg-Johann Lay wrote:
>
>> This is just a code clean-up.
>>
>> The bulky code from *addhi3_sp_R_pc2 and *addhi3_sp_R_pc3 is done by a small
>> C
>> function that does the same (except that it pr
Hi Guys,
I am applying the patch below to fix a couple of bugs in the RX's
machine description patterns. The first concerns the tablejump
pattern, which needs to include a label to be referenced by the
ASM_OUTPUT_ADDR_DIFF_ELT macro.
The second problem is the ADDDI3 spiltter which was
Thank you guys for your support!
K
Ping #1: http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01690.html
Georg-Johann Lay wrote:
> This is just a code clean-up.
>
> The bulky code from *addhi3_sp_R_pc2 and *addhi3_sp_R_pc3 is done by a small C
> function that does the same (except that it prints some comment depending on
> -dp or -fv
> On Tue, Oct 4, 2011 at 9:02 PM, Maxim Kuvyrkov wrote:
> > On 5/10/2011, at 1:49 AM, Richard Guenther wrote:
> >
> >> On Tue, Oct 4, 2011 at 9:17 AM, Maxim Kuvyrkov
> >> wrote:
> >>> Richard,
> >>>
> >>> The following patch fixes a CFG consistency problem.
> >>>
> >>> When early IPA optimizatio
we have, like specifying the set of symbols _defined_ by a toplevel
asm, right? I might misremember but sth like
extern void foo (void);
asm("" "foo");
was supposed to do the trick. Or should we treat those as outputs
(given you use inputs for symbol uses)?
I don't recall any discussi
On Tue, Oct 4, 2011 at 6:28 PM, Tom de Vries wrote:
> On 10/04/2011 03:03 PM, Richard Guenther wrote:
>> On Tue, Oct 4, 2011 at 9:43 AM, Tom de Vries wrote:
>>> On 10/01/2011 05:46 PM, Tom de Vries wrote:
On 09/30/2011 03:29 PM, Richard Guenther wrote:
> On Thu, Sep 29, 2011 at 3:15 PM,
On Tue, Oct 4, 2011 at 10:58 PM, Richard Henderson wrote:
> On 10/04/2011 01:17 PM, Tom de Vries wrote:
>> In general, to fold vlas (which are lowered to allocas) to normal
>> declarations,
>> if the alloca argument is constant.
>
> Ah. Ok, I suppose. How often are you seeing this happening? I
On Wed 05 Oct 2011 09:33:09 BST, Andreas Krebbel wrote:
Hi,
the optab_handler uses in expand_mult_highpart_optab haven't been
replaced with the widening_optab_handler yet.
Apologies, I don't know how I missed that one? :(
Andrew
> Jan Hubicka writes:
>
> > Hi,
> > GNU LD has bug about reporting references to hidden symbol sthat has been
> > optimized out.
> > This however made me notice that we do output into LTO symbol tables things
> > that do
> > not belong there. In partiuclar we often output extern inline function
On Wed, Oct 5, 2011 at 12:18 AM, Artem Shinkarov
wrote:
> Hi
>
> Here is a patch to inform a programmer about the expanded vector operation.
> Bootstrapped on x86-unknown-linux-gnu.
>
> ChangeLog:
>
> * gcc/tree-vect-generic.c (expand_vector_piecewise): Adjust to
> produce the warn
1 - 100 of 104 matches
Mail list logo
